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则更像一个通用的推理服务框架擅长多模型管理、动态批处理和灵活的调度策略适合需要同时服务多种模型的场景。我给出的选型参考基于实测经验整理如下对比维度vLLMTriton Inference Server我的建议主要定位大模型高性能推理引擎通用多模型推理服务框架不是替代关系显存管理PagedAttention分页优化效率高依赖后端实现传统策略为主LLM优先考虑vLLM多模型支持较单一多模型、多后端统一管理混合部署用Triton动态批处理自带Continuous Batching支持调度灵活高吞吐选vLLM运维复杂度较低较高配置项多小团队先vLLM我们最终的形态是用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基础设施的路上欢迎照着我这篇的思路先行自查把监控、容错和降级这三件事补上应该能帮你避开大多数初期暗坑。
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则更像一个通用的推理服务框架擅长多模型管理、动态批处理和灵活的调度策略适合需要同时服务多种模型的场景。我给出的选型参考基于实测经验整理如下对比维度vLLMTriton Inference Server我的建议主要定位大模型高性能推理引擎通用多模型推理服务框架不是替代关系显存管理PagedAttention分页优化效率高依赖后端实现传统策略为主LLM优先考虑vLLM多模型支持较单一多模型、多后端统一管理混合部署用Triton动态批处理自带Continuous Batching支持调度灵活高吞吐选vLLM运维复杂度较低较高配置项多小团队先vLLM我们最终的形态是用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基础设施的路上欢迎照着我这篇的思路先行自查把监控、容错和降级这三件事补上应该能帮你避开大多数初期暗坑。
