AI-Infra分层实战：模型服务化、Agent基建与可靠性设计

1. 为什么一线工程师必须直面AI-Infra

我是在一次线上事故之后，才开始认真琢磨AI-Infra这件事的。

那会儿我们团队刚把一个微调过的行业大模型部署到生产环境，离线评测指标很好看，demo演示也顺畅，结果上线第一周就出了问题：晚高峰请求量一上来，推理服务延迟从200毫秒一路飙到4秒，部分用户直接超时；GPU显存偶尔被占满导致进程重启，重启期间所有请求全部失败。我们几个人围着监控面板查了半宿，最后才发现问题不止一层——服务框架的排队机制不合理、显存没有做有效的生命周期管理、日志和链路追踪缺失导致瓶颈根本定位不到。那一刻我彻底想明白一件事：模型训练和微调固然重要，但模型之后的路——部署、服务化、调度、观测、容错——这些看不见的底层设施，才真正决定了AI系统能不能在真实业务里站住脚。这就是AI-Infra要解决的事情。

如果你也是一线开发或者算法工程师，正在把手里的模型往生产环境推，这条路绕不开。这篇文章是我作为一线工程师搭建AI基础设施第一阶段的实战记录，包括技术栈怎么分层、模型服务化的具体方法、Agent系统对基建的特殊要求，以及可靠性设计的核心思路。适合刚接触AI工程化、正准备把大模型推向生产环境的同学参考。

1.1 模型能跑和系统能用是两回事

先澄清一个最常见的误解：很多团队在模型评测、业务效果上投入大量精力，却把部署环节当成"找个框架起个服务就行"。实际上，模型在离线测试集上跑得好，和在线业务里稳定低延迟地服务用户，是完全不同的两个战场。

离线环境里，你只管喂数据看输出，没人跟你抢GPU，不需要考虑并发、超时、排队、限流，也不用管服务崩了怎么恢复。生产环境则是另一套逻辑：请求是突发且不均匀的，GPU是共享且昂贵的，推理服务必须同时面对吞吐优先的离线批任务和延迟敏感的在线交互请求，两者对资源的争抢随时可能发生。更麻烦的是，大模型推理本身就是计算密集型任务，一个请求占着显存和算力很久，并发一上来，调度策略稍不合理，服务就变成一个堵死的路口。

所以，模型能跑只是起点，"系统能用"意味着要在资源调度、服务框架、数据管道、监控告警、容错恢复这几个维度上都做到可控。这也是为什么AI-Infra在一线团队里变得越来越重要——它不是在模型外面加个壳，而是搭一整层让模型能稳定、高效、安全地对外提供能力的底座。把这一层想清楚了，后面做的所有选型才有判断依据。

1.2 AI-Infra工程师的一天是什么样的

刚开始我以为AI-Infra是纯平台团队的事，自己做业务算法不太需要碰。真正介入之后才发现，一线工程师其实是AI-Infra最直接的受益者和反馈者——每天接触推理服务的，恰恰是写业务逻辑的这些人。

我日常的固定工作是这样的：早上先在监控面板上扫一眼昨晚的推理服务指标，看延迟曲线是否平稳、GPU利用率有无异常波动、有没有容器被OOM重启；然后跟进模型版本的灰度，把新微调的模型配到一部分流量上比对效果；下午更多时间花在排查问题上——某个请求链路变慢了，是模型推理本身的问题，还是前置的数据处理服务有瓶颈，亦或是背后的向量数据库查询太慢；偶尔还要处理Agent产生的大量日志，从里面找出失败的工具调用，调整超时和重试策略。这些事情没有一件是"训练出一个更聪明的模型"，但每一件都在决定这个系统能不能被信赖。

这种工作状态让我重新理解了AI-Infra的范畴：它不光是显卡和集群，还包括请求如何进出、数据如何流转、失败如何恢复、系统如何被观察。弄清楚这个范畴，后面的选型和落地才不会跑偏。

2. AI-Infra技术栈的五层拆分

AI-Infra这个词范围太大，不同公司定义也不一样。我按照一线工程师日常协作的视角，把它拆成五个核心层，每一层解决一类明确的问题。这样拆完，团队里聊需求、排优先级都清楚很多。

2.1 计算资源层：GPU的分配与共享

这一层解决的是"算力从哪里来、怎么高效地来"。大多数中大型团队会基于Kubernetes管理GPU节点，通过设备插件把GPU暴露给容器调度器。但Kubernetes原生调度GPU时有个痛点——它以整卡为最小单位，一旦容器只用半张卡，剩下半张就浪费了。所以很多团队会引入GPU共享方案，或者退一步用MIG（多实例GPU）把物理卡切分成多个实例。

我个人的建议是：先别急着上复杂的共享调度，把"整卡+亲和性"+节点池隔离跑稳，再考虑细粒度共享。因为共享GPU会引入显存隔离不彻底、性能相互干扰的问题，排查起来相当头疼。如果你刚起步，整卡调度配合合理的副本数规划，通常已经能覆盖大部分场景。

2.2 模型管理层：版本、镜像与仓库

模型本身也是一个需要版本管理的资产。我们的做法是，每个微调产物都打进一个标准化的模型仓库，记录基础模型版本、训练数据批次、微调参数、评测结果和上线时间。上线时通过模型仓库拉取指定版本，而不是靠同事口头告知"今天新训练的模型在某某目录"。

这里有个容易被忽略的细节：模型文件和推理代码要打包在一起形成可复现的推理镜像，镜像标签必须与模型版本一一对应。否则很容易出现"代码回滚了，模型还是新的"这种错位，线上表现异常时极难排查。把模型和代码当成同一个发布单元管理，能省掉大量协调成本。

2.3 数据与存储层：向量库、缓存与管道

AI应用的数据面比传统后端更复杂。除了业务数据库，还要处理非结构化文本的向量化存储、会话历史的临时缓存、以及对模型输入输出上下游数据的管道。向量数据库（如Milvus、Qdrant）负责支撑检索增强生成（RAG），缓存层（如Redis）保存热门请求的响应和用户会话状态。

我在数据层踩过比较大的坑是：向量库的召回延迟和准确性同样需要监控。很多人关注模型参数，却忽略了一旦向量库索引构建失败或者数据一致性出问题，整个问答效果会断崖式下跌。建议在数据层也建立独立的健康检查，定时跑一批标准检索用例，比对召回结果。

2.4 服务与推理层：框架与部署形态

这一层是AI-Infra里最核心的技术密集区，也是后面我重点展开的部分。它负责把训练好的模型包装成高性能、可扩展的在线服务，常见组件包括推理引擎（如vLLM、Triton Inference Server）、网关、负载均衡和水平伸缩策略。部署形态可以是Kubernetes上的Deployment，也可以是Serverless式的按需拉起。选型取决于业务实时性要求：内部工具允许秒级冷启动，可以直接用Serverless；对外交互产品通常需要常驻实例，配合弹性伸缩。

2.5 可观测与治理层：监控、日志与权限

最后这层相当于AI系统的"仪表盘和法律合规框架"。监控要覆盖三类指标：资源指标（GPU利用率、显存、CPU、内存）、服务指标（延迟、吞吐、错误率）、业务指标（回答满意度、召回命中率）。日志要带上trace ID串联全链路，Agent场景尤其如此。治理侧包括模型访问权限、Prompt注入防护、数据脱敏和内容安全策略。这一层做得越早，后面出问题时定位越快。

3. 模型服务化的实战路径

如果说分层是勾画地图，那模型服务化就是真正动手铺路。这部分我按一个完整项目落地的顺序来讲：模型优化、推理框架选型、上线参数调优、灰度发布，每一步都附上我踩过的坑。

3.1 模型优化：先压体积再上服务

直接拿PyTorch原始权重对外服务不是不行，但通常吞吐低、延迟高。我们第一步做的是模型格式转换和精度压缩。常见做法是把模型导出为ONNX或TensorRT格式，再根据业务容忍度选择FP16或INT8量化。以7B量级的模型为例，FP16相比FP32显存直接减半，INT8还能再砍一半，而多数业务场景的效果损失在可接受范围。如果你的模型在云端GPU部署，FP16是性价比最稳的选择，INT8适合对成本极度敏感、效果容忍度较高的场景。

优化时要注意：必须用与线上完全一致的推理入口和批次大小做压测对比，不能只看单条延迟。因为量化或格式转换后，某些算子可能在特定形状下性能反而变差，整体吞吐才是真正需要盯的指标。

3.2 推理框架选型：vLLM和Triton我怎么选

现阶段开源推理引擎里，我接触最多的是vLLM和Triton Inference Server。两者并非二选一，很多时候是组合使用。vLLM在LLM场景的吞吐优化上做得非常激进，尤其是PagedAttention机制，它把KV Cache分页管理，显存利用率比传统静态分配高不少，支持的模型也很广。Triton则更像一个通用的推理服务框架，擅长多模型管理、动态批处理和灵活的调度策略，适合需要同时服务多种模型的场景。

我给出的选型参考基于实测经验整理如下：

我们最终的形态是用vLLM作为LLM推理后端，Triton承载其他AI模型（如Embedding、视觉模型），前面统一挂一层网关。这个组合既保证了主模型吞吐，又不至于把团队精力耗在复杂框架维护上。

3.3 上线参数调优：并发、批次与显存的平衡

框架装好只是开始，参数调优才是真正出经验的地方。几个直接影响体验的关键参数：max_batch_size决定一次推理最多合并多少请求，太大抬高延迟上限，太小浪费吞吐；max_seq_len决定上下文长度，设置过高会在长文本场景撑爆显存；max_num_seqs控制并发序列数，影响显存占用和排队行为。它们之间的关系就像一条水管——管径、水压、储水罐容量必须匹配，否则不是爆管就是出水量上不去。

实际操作中，我会先用压测工具按梯度加压，观察延迟的P99和吞吐曲线的拐点，同时盯住显存利用率和KV Cache的回收情况。调优的目标不是把某个指标拉到极限，而是在延迟SLA内把吞吐做到最大。记住一个原则：宁可让请求在网关层排队，也不要让推理引擎内部出现长时间的调度抖动，前者的排队是可控的，后者的抖动是随机的。

3.4 灰度发布：模型升级不搞一刀切

模型升级最忌讳直接全量切换。我们设计了基于流量权的灰度机制：新模型版本先接5%流量，观察业务指标和延迟指标，稳定后逐步扩大。灰度期间要对比的不只是回答质量，还有Token长度分布、首Token延迟、拒绝请求比例这些底层信号。有一次灰度，新模型在评测集上效果更好，上线后却发现输出Token明显变长，导致平均延迟超标——如果不是灰度期看到了Token长度指标，全量上线就是事故。所以模型评估一定要加上"成本影响"维度，输出长度直接关联算力和延时。

4. AI Agent的基础设施需求，和普通服务不太一样

大模型应用从"单轮问答"走向Agent形态之后，基础设施的要求又上了一个台阶。Agent不再是简单的请求-响应，而是一个会循环思考、调用工具、迭代执行的多步系统。这一节聊聊我为Agent系统补齐基建的实战经验。

4.1 Agent运行时：编排、状态与恢复

一个Agent任务本质上是一个状态机：接收任务、规划步骤、调用工具、观察结果、迭代直到完成。这个循环里，每一步都可能失败，而且失败原因比传统服务更复杂——可能是模型调用超时，可能是工具返回结果不符合预期，可能是上下文过长导致截断。所以Agent运行时首先要把每一步的状态持久化下来，这样即使进程崩溃，也能从最近的检查点恢复，而不是把整条任务推倒重来。

用生活化一点的方式理解：传统的接口调用像去柜台办一笔业务，排队、办理、结束，整个过程分钟级；Agent执行则像一个外包团队在工作，项目经理拆任务、成员分头执行、随时同步进度，任何环节掉链子都可能让整件事搁浅。基建要做的就是给这个"外包团队"配上项目管理工具——任务状态可见、失败可回溯、进度可恢复。

4.2 工具调用与权限控制的工程实现

Agent的价值在于能调用外部工具：查数据库、发消息、操作内部系统。但工具接入不是简单给个API地址就行，必须有清晰的接口规范。我们现在遵循的是类似MCP（模型上下文协议）的思路，把工具定义成标准化的描述——名字、参数schema、用途说明、返回结构。这一步非常关键：模型是靠工具描述来决策调用哪个工具的，描述写得不清楚，模型就会乱猜，或者频繁调用错误的工具。

权限控制是另一个重点。Agent的工具权限不能等于用户权限，必须基于"最小必需"原则。比如一个负责查报表的Agent，只能访问报表相关库表，不能让它顺手改数据。我们在工具层做了统一的权限拦截和审计日志，每一次工具调用都记录：谁触发的、用的什么参数、返回了什么。这个审计日志是我排查线上问题时的第一手材料，没有它，Agent出了问题就是一团迷雾。

4.3 多Agent协作的调度策略

当场景升级到多个Agent协作——一个负责拆解任务，一个负责检索知识，一个负责生成内容——就多了一层调度问题。我们把它做成一个优先级驱动的任务队列：规划Agent产出任务清单后，按依赖关系排入队列，执行Agent各自消费队列中的任务，再汇总结果。

多Agent协作要特别注意死锁和资源空转。我遇到过最典型的问题：两个Agent都在等对方产出的结果，同时都占着线程不释放，整个编排服务卡死。解决方法是给所有等待设置上限，超过等待时间就主动失败并走兜底逻辑。另一个经验是，Agent之间的通信不要传大文本，传任务ID和结果引用，实际内容放到共享存储里。这样既减少带宽压力，也让消息日志干净很多，方便回放整个协作过程。

5. 可靠性工程：让AI系统真正扛得住

AI系统最怕的不是模型效果差，而是"时好时坏"——同一个问题，上午回答正常，下午开始胡言乱语，而且没人说得清为什么。这节讲的是我搭建可靠性体系时沉淀下来的核心思路，主要围绕容错控制、可观测性和演练机制展开。

5.1 容错控制：超时、重试、熔断与降级

所有容错设计都要从一个原则出发：任何环节都可能失败，系统要把失败当成常态来设计。我按下面几个机制逐层搭：

• 超时分级：区分模型调用超时、工具调用超时和整个Agent任务超时，短的若干秒，长的不超过分钟级，每级都有明确动作。
• 重试退避：可重试的失败（如瞬时网络抖动）采用指数退避加抖动重试，避免重试风暴；不可重试的失败（如参数校验错误）直接失败返回。
• 熔断降级：当某个依赖服务连续失败达到阈值，自动熔断并切换到降级方案。比如主模型不可用时切到备用模型，或返回带兜底的固定响应。

重点说一下"降级方案"——很多团队压根没准备。AI服务的降级不一定是有另一个模型顶上，也可以是把问题回答替换成一段预设文案，或者引导用户走人工流程。有降级路径和没有降级路径的区别，在于事故是"局部不可用"还是"全站崩溃"。这个兜底一定要提前想好，千万别等到线上炸了才临时凑。

5.2 可观测性：Agent日志不是简单堆文本

传统服务的监控在这里完全不够用。除了常规的延迟、吞吐、错误率，AI系统还必须回答两个问题："用户的体验为什么差"和"模型为什么这样回答"。我们围绕这两点建了一套分层观测体系：

• 基础设施层：GPU利用率、显存水位、容器重启次数、网络IO。
• 推理服务层：首Token延迟、Token生成速度、队列长度、拒绝请求率。
• 业务链路层：完整trace贯穿请求入口到模型调用，再到工具调用，记录每一步耗时和结果。
• 内容质量层：抽样记录每次回答，人工或模式自动标注"是否满意"、"是否超时"、"是否跑题"。

其中内容质量层是很多人忽略但价值最高的。原始日志里只有token流和图片，根本看不出用户体验，所以我们在Agent每次回答后增加了反馈埋点，把用户点赞点踩、追问频次、复制行为都归一化到trace里。有了这些数据，我才能把"模型效果变差了"这个模糊感觉，变成一个可以定位到具体模型版本和具体输入特征的准确结论。

5.3 混沌演练：提前把故障抛出来

可靠性不是配好方案就完了，必须通过演练验证。我们每个季度做一次"故障日"：人为制造GPU节点宕机、注入推理延迟、让向量库暂时不可用、给工具调用加重负载，然后观察整个系统是否能按预期降级。第一次演练结果惨不忍睹——超时配置互相矛盾，重试风暴把下游数据库打满了，兜底文案没有生效。这些问题如果不在演练室暴露，就会在真实事故里爆发。

演练的收获是沉淀了一套"故障响应手册"。手册里明确规定：服务挂了先做哪几步确认、什么情况下允许切流、切流需要谁审批、如何向业务方通报。事故发生时最怕临时讨论，有了预案才能冷静执行。AI系统的故障影响面往往比传统服务更大——因为它可能是部分用户的体验异常而非纯功能报错，更需要提前定义好"什么算事故、什么等级需要紧急响应"。

6. 第一章收尾，我先给后来者三个建议

本来写到这可以打住了，但作为一个踩了不少坑的人，还是想用我自己的体会收个尾。如果只能留三条建议给正在走AI-Infra之路的工程师，我会选这三条。

第一，先把"能跑"和"能用"分开。很多项目死在第一周的线上事故，不是模型不够好，而是基建太脆弱。别急着炫酷的框架，先把监控、日志、容错和降级方案补齐，这些"不性感"的东西才是系统能长期生存的根基。

第二，所有参数调优都要坚持用数据说话。延迟、吞吐、显存利用率、错误率、Token长度，这些指标比任何主观感受都真实。建立一套标准的压测和指标采集流程，会让团队在争论"该不该升级框架"时少很多口水战。

第三，主动去感受故障。不要等到真实事故才第一次面对异常，定期做演练，把失败看成系统设计的一部分。每次演练都是免费的低成本学习机会，多暴露一个弱点，生产环境就少一个炸弹。

第一章的实战记录就到这里。下一阶段我计划深入探索推理引擎的底层优化细节，以及多Agent协作场景下的状态一致性问题，到时候再继续整理成文分享。如果你也在搭建AI基础设施的路上，欢迎照着我这篇的思路先行自查，把监控、容错和降级这三件事补上，应该能帮你避开大多数初期暗坑。