尧图网页设计 
上篇写完到现在快两个月后台一直有人追问“你转到LLM Infra之后到底每天在干什么”“值不值得转”“有没有栽跟头”。说实话转之前我也觉得LLM Infra不过就是装个推理框架、调调参数、看看显存占用真正扎进去才发现这一层的水远比我想象的深而且很多坑是外面文档根本不会告诉你的。这篇“下”篇我不打算再复述简历上的心路历程直接讲转行落地之后真正动手做的几件事网关、计量、RAG、推理层优化、线上治理。每条都是我在生产环境里踩过坑、怼过人、也被老板骂过之后才理顺的。想转LLM Infra的朋友或者已经在做但觉得处处别扭的朋友这篇应该对你有用。3. 从零搭一个OpenAI兼容网关成本、配额、路由和一周后被骂醒的教训3.1 为什么网关是LLM Infra的命门刚转过去那会儿我以为搞LLM Infra就是把模型部署到GPU上接口能通就行。直到第一周结束技术负责人扔给我一句话“你把网关搞出来不然下周一各个业务线就自己接原始模型端口了。”我那时候才意识到在一家同时跑着十几个业务部门的公司里你暴露一个裸的模型服务等于把信用卡放在大街上。任何一个业务方都可以上来发请求没人知道谁在调用、调用多少、成本算到谁头上模型一旦被某个写死循环的脚本打满全公司所有AI功能一起瘫痪。你需要的并不是一个简单的HTTP转发层而是一个完整的控制面。我最终搭的网关至少承担了四件事认证与授权所有请求必须先过API Key校验不同Key绑定不同部门和权限级别。令牌级计量每个Key消耗的输入token和输出token全部落库按部门分摊成本。速率限制与配额按部门设置每分钟请求数上限、每日token预算上限超额直接返回429。模型路由与故障转移同一个业务接口背后可以挂多个模型实例主模型不可用时自动切换到备用模型。这四件事看起来简单但每件背后都有一堆细节。比如令牌级计量你以为数token就是看API返回里的usage字段实测发现同一个请求发给不同模型返回的usage口径都未必一致有的框架会漏掉system prompt里的token有的把工具调用参数不计算在内。为了对账准确我最后不得不自己实现一套tokenizer缓存逻辑提前把prompt拆好、按tokenizer类型分别统计才勉强把账单做平。3.2 令牌级计费与配额把成本摊到每个业务部门头上说真的LLM Infra最容易被忽略但最要命的需求就是成本核算。模型推理不是一次性买断的服务器而是按token烧钱的业务方根本感知不到“一次普通对话”到底花了公司多少钱。我做了个简单的账单模型给每个部门开了一个仪表盘实时展示当日总token消耗区分输入和输出按模型分摊的费用近7天趋势标注突然翻倍的时间点超配额预警然后问题来了。有一周我收到告警——某个部门的每日token消耗突然从500万飙到了3000万。查日志发现他们新上了一个“批量数据分析”功能自己写了个循环拿一个超长文本反复拼接prompt再调用。这其实不是恶意刷单纯粹是业务方不了解token计费逻辑以为多调用几次没有成本。那次的教训是光有配额告警不够必须把token成本和业务行为关联起来解释给业务方听。我后来养成了一个习惯每次做账单分析都要附一行“换算说明”比如“3000万token约等于每天把《三体》全集读130遍”。这种直观表达比任何数字都有用。也是从那次以后我开始在网关里加了一类“异常调用模式识别”规则比如同一请求体在短时间被重复发送多次或者输出token量远超正常范围就直接标记给管理员复核。3.3 模型路由与回退从“全挂了”到“优雅降级”网关还有个我一开始完全没想到要做的功能——模型回退。我最初的思路很简单业务方调网关网关转发给一个模型实例实例挂了就报错。但真实情况是你一个内部平台业务方接口会直接请求你的模型服务如果模型挂了他们那边整个流程就断了。你要么保证模型永远不挂要么保证挂了之后有替代方案。“永远不挂”在LLM场景等于空话GPU卡故障、OOM、超时、模型加载失败哪种都可能随时发生。所以我做了三层回退策略同模型多实例同一模型部署在多个节点轮询分发单节点故障时自动摘除。不同规格回退主力模型是70B级回退模型是量化后的13B或7B。质量会降但流程不会断。Prompt兜底某些简单任务比如意图分类、关键词抽取直接用一个极小的规则模板兜住不走模型。分层回退做完之后有一次正好赶上GPU驱动被误升级主力推理服务全挂业务方那里居然没有任何感知因为他们拿到的回退回答质量虽然略有下降但API的响应结构完全一致。那一刻我才明白LLM Infra做得好不好不是看在正常时候跑得多快而是看在故障时大家多无感。4. RAG并不是“向量检索加一段Prompt”生产级RAG的基建难点4.1 检索质量的工程化chunk怎么切、重叠多少、embedding怎么选我接手RAG基建之前团队里已经有人用简单的方式跑通了一版文档丢进去按固定长度切块塞进向量库检索时取TopK拼进prompt。Demo效果不错一上生产就原形毕露。业务方反馈“问题稍微拐个弯就答不上来”“经常答到一半就瞎编”。我去看了一眼发现最大的问题不是模型而是切块方式。那版实现用的是固定字符长度切块比如每512字一刀切下去结果一句话被拦腰斩断一个技术概念被劈成两半检索时只召回其中一半语义自然缺失。后来我重新设计了切块策略核心思路是分层第一层按语义边界粗切比如标题、段落、空行、列表项作为天然边界保证切块尽量完整。第二层设置重叠区间相邻块之间的重叠量控制在10%-15%让跨块信息至少在一个块里能完整出现。第三层小块召回上下文重建检索时先取小块再往前追溯所属的文章或章节把上下文字段一并拉出来送进prompt。Embedding模型的选择也踩了坑。一开始我们用的是通用中文embedding模型在内部文档场景下效果一般。后来换成了更大参数且针对特定领域微调的向量模型检索命中率明显上升。但有一个代价embedding维度更高向量库的存储和检索延迟都涨了不少。我们最后才确认了一个折中方案——主embedding用领域微调模型同时对向量做降维处理用PCA把维度从1536降到768检索质量几乎没有损失但查询延迟降了差不多三分之一。4.2 从GraphRAG到LLM Ontology当单纯向量库不够用还有一个让我印象极深的需求用户问“A部门和B部门的职责边界在哪里”或者“这条流程在什么情况下会自动审批”。如果文档里没有一句话直接回答这种跨实体关系问题向量检索再怎么召回都是碎片。这就是传统RAG的边界向量的本质是语义相似度它擅长帮你找“哪段文字和这句话最像”但不擅长“把两段文字里的实体关系拼起来回答问题”。后来我改成了GraphRAG的思路在向量库之上建一层知识图谱。具体做法分三步实体抽取用LLM把文档中的实体人名、系统名、部门、术语抽取出来。关系抽取抽取实体之间的关系比如“A系统调用了B接口”“某流程依赖某审批节点”。图谱落库把关系和向量索引共同存储检索时不仅取相似文本块还同步查图谱路径把关联关系一起拼进上下文。做这个改造花了大概三周但上线后最直接的收益是跨文档关系类问题的正确率从不到40%升到了76%。其中有个关键心得——图谱里的关系定义不能太碎否则图谱变成毛线团。我们最后收敛到只有8种关系类型反而效果更好。GraphRAG本身还牵扯到“LLM Ontology”的取舍到底该让LLM自动构建本体还是人工约束本体我踩出来的结论是前期一定人工定好骨架让LLM在固定骨架里抽取千万别让它自由发挥不然每次跑出来的实体关系都可能不一样图谱一致性根本没法保证。4.3 检索链路中的超时、重试与缓存看似简单实则到处是雷RAG的检索链路从用户提问到返回答案中间要经过embedding模型、向量库查询、图谱查询、prompt拼装、LLM生成几个环节。哪个环节慢整体就慢。我在调优的时候发现最容易被忽视的是向量库查询的波动——你平时查一次耗时20毫秒但数据量一大或并发一高就可能冲到400毫秒以上而且聚类特别严重。为了把尾巴削掉我做了三件事超时分级embedding、向量检索、图谱查询分别设置独立的超时时间谁超时都不拖累整个链路。降级策略向量库超时后直接跳过向量检索用关键词检索全文匹配兜底还是失败就直接返回“暂时无法检索到相关资料”绝不硬撑着等。结果缓存对同一类型的常见问题做语义缓存——把用户问题embedding化后与历史问题算余弦相似度高于阈值就直接返回旧结果不再走完整链路。做完之后检索链路的P99延迟从1.2秒降到了350毫秒而且成本跟着降了20%左右因为很多重复问题不再反复调用LLM。那时候我才体会到RAG的Infra做得好不好最终拼的是响应时间、成本和质量三者的平衡而不仅仅是“能不能找到文档”。5. 模型推理层的取舍量化、KV Cache、批处理策略5.1 为什么非得做量化显存、吞吐与收益抠算我在上篇提到过刚转过去时对GPU资源完全没有概念以为一张A100能跑70B模型就能扛住所有业务。真正上线才发现部署一个70B模型FP16权重就要占140GB显存一张80GB的卡根本放不下更别提还要留显存给输入输出和KV Cache。所以模型量化不是“可选项”而是“不上线别想跑”的硬门槛。我们的主力模型从FP16换成INT8之后显存占用降了一半左右单卡能扛住的最大并发明显提升。后来又尝试了INT4量化显存占用进一步降低但评测分数在某些逻辑推理类任务上掉了几个点。最终我们采用的是一套动态拆分的思路入口简单任务走小模型的量化版本复杂推理任务再走大模型的原生精度版本。这样既保证了质量又控制了整体GPU成本。具体算账的话我们的实践是这样的一个70B模型在FP16下理论需要140GB显存加上每1000条输入token产生的KV Cache大约占0.7GB到1.4GB。假设同时处理32个并发请求每个请求上下文是4000 token光KV Cache就要额外吃掉90GB左右。这就是为什么部署推理服务时最大并发数经常不是看算力而是看KV Cache那边的显存够不够。量化省出来的每一GB最终都会反映到并发能力和单位请求成本上。5.2 从vLLM的PagedAttention到prefill/decode拆分理解吞吐瓶颈说到推理吞吐那就绕不开vLLM。我一开始用vLLM很简单粗暴以为它就是个部署工具。后来深入研究才发现它的核心优势在于两层设计一是PagedAttention机制——把KV Cache拆成固定大小的块按需分配不再为每个请求预留整块连续显存。你可以把它理解成操作系统的虚拟内存分页这个机制解决的是显存碎片化和浪费问题。二是连续批处理——一个请求decode完一个token后立刻让出计算资源下个请求可以马上进来不用等整个batch跑完。这两层设计配合起来吞吐是真的能翻倍。我们的基线测试显示在同样一张卡上用原生transformers写的推理脚本单卡吞吐只有vLLM的大概40%左右。但vLLM也不是银弹。我后来为了压延迟把prefill和decode阶段拆开部署在不同节点上前一个阶段负责处理用户输入prompt并预计算KV Cache后一个阶段只做逐token生成。这样拆的好处是prefill阶段的计算量大但并行度高decode阶段是串行延迟敏感型两者混在一起容易互相干扰拆开后可以分别做资源伸缩和容错。这种做法的一个副作用是prefill阶段结束后要把KV Cache从一张卡搬运到另一张卡如果网络带宽不够传输耗时能把你刚省下来的几十毫秒全部吐回去。我们最后是用RDMA网卡把传输延迟压缩到个位数毫秒才真正划算。如果你的集群没有这种网络条件我劝你不要轻易拆prefill和decode老老实实单机部署更省心。5.3 ONNX部署、TensorRT-LLM、vLLM的实际选型对比这里我整理一下我实际用过的三条推理栈给出我自己的选型结论给需要的人一点参考推理栈优势劣势适用场景vLLMPagedAttention显存管理优秀吞吐高生态活跃接口兼容OpenAI协议对部分定制算子支持较弱依赖CUDA环境通用对话、RAG、大多数在线推理场景TensorRT-LLM极致单卡性能量化支持丰富低延迟表现突出编译时间成本高模型结构改动后需重新构建引擎延迟苛刻、吞吐要求高且模型结构稳定的场景ONNX Runtime跨硬件部署灵活可在CPU/GPU混合环境运行不绑定特定厂商大模型场景性能优化浅复杂模型图优化有限边缘设备、CPU推理、多端统一部署我个人的实践感受是如果你的目标是快速上线且模型迭代频繁vLLM是最省心的如果你想拿同一批GPU榨出最大的吞吐而且模型结构已经稳定TensorRT-LLM值得投入只有当你的部署环境特别杂既要跑GPU又要跑CPU才需要ONNX这条路线。ONNX部署LLM还有个很现实的痛点动态序列长度处理较麻烦很多操作符图结构在动态形状下会被打回原形你写好的graph优化根本用不上所以用ONNX做生产级大模型推理我建议你先把动态形状问题掰扯清楚否则上线之后会发现一半的优化效果都没生效。6. 线上治理从“能跑通”到“7×24稳”监控与排障6.1 监控指标的选法TTFT、TPOT、Token级延迟、GPU利用率转行后我花了不少时间在监控体系上。以前在传统IT服务里监控的事情还算简单看一眼CPU、内存、磁盘、网络就大概知道系统状态。但是LLM推理服务不一样GPU的利用率高也不代表服务正常显存不满也不代表没有瓶颈。我现在每天盯的核心指标是这几项TTFTTime to First Token用户发出请求到返回第一个token的耗时。这个指标直接决定“转圈圈”时间用户对它的敏感度极高超过两秒就会感觉卡。TPOTTime Per Output Token生成一个token平均耗时。它决定后面整体速度TPOT太高长回答就让人等得抓狂。Prefill吞吐和Decode吞吐拆开看计算资源到底吃在哪一段。KV Cache使用率接近上限说明并发快见顶要找扩容或做请求排队。GPU利用率和显存利用率不能只看整体要按卡按进程看才能定位局部热点。6.2 一次耗时长尾问题的排查链路有一段时间我们的服务TTFT平均是900毫秒但P99居然能到6秒也就是说每100个请求里有一个特别倒霉。我排查这个长尾问题的过程可以说完整展示了一次LLM Infra排障的典型链路第一步先看是不是网络层。我在网关端抓到P99请求的耗时拆分发现网络传输只占不到5%问题不在网段。这个步骤很关键不要一上来就怀疑模型层先确认“慢”到底发生在哪个环节。第二步看是不是负载不均。查看四张卡上的请求分布发现其中一张卡上的请求量明显偏多原因是负载均衡策略是按照请求数散的但每个请求的输入长度差异极大一个超长prompt请求拆分成大量prefill算子后把整张卡的计算资源占满了后续请求全在排队。第三步定位到卡后看显存与KVCache分配。那张卡上的KV Cache容量被大量长上下文请求吃满新请求一直等待显存释放。到这里根因就基本清楚了不是模型慢而是长尾大请求把一张卡的资源挤爆了。第四步修复。改了两处一是负载均衡策略改成按预估显存和计算量加权而不是按请求数二是网关加了一层请求长度配额对超长上下文请求做限流和排队避免它直接冲垮单卡。这个坑的典型性在于如果你只看平均延迟指标完全发现不了问题只有把P99拆开按卡、按请求类型分维度看才能看到那张被长尾请求拖垮的卡到底发生了什么。6.3 LLM as Judge用模型来检查模型服务线上服务稳定之后还有一件绕不开的事——质量。常规做法是搞一套业务级评测集定期跑分。但问题在于评测集靠人打标的成本高、更新慢很多新场景根本来不及覆盖。我后来引入了LLM as Judge的机制做一个自动化质量看门狗。思路很简单设一个专门的裁判模型把用户问题和线上模型的实际回答一起送进去让裁判模型判断回答是否存在答非所问、胡编、内容缺失等问题。这个裁判模型不直接服务用户只做质量评判所以可以用一个相对小的模型把成本压得很低。实际运行之后我发现它最大的价值不是替代人工评测而是把“质量回归”从每周一次变成了每次发布后自动执行。做这个功能有几个细节坑裁判模型本身会被“带偏”的如果裁判模型的提示词里没有明确的评分标准它会倾向于给“看起来流畅”的回答打高分。必须给裁判模型提供参考答案或事实依据否则它只能评判流畅性没法评判正确性。裁判结果需要抽样复核不能完全自动放行我保留了一个10%的人工抽检口防止裁判模型自己越跑越偏。在LLM Infra里LLM as Judge看似不是基础设施层面的东西但它其实承担了“质量SLA”的职责。没有这套自动评判机制你对线上模型质量的理解只能靠用户骂声那就晚了。7. 关于转型最后想说的大实话7.1 三个最常见的认知误区从我自己的经历来看想从传统IT环境跳到LLM Infra的人通常带着几个误区**误区一LLM Infra就是会部署模型就行。**实际上部署只是入门门槛真正的价值在于网关、计量、RAG链路、推理优化、监控排障这些外围工程能力。你光会部署一个模型就相当于会开一辆车但不会保养更不会判断故障。LLM Infra是典型的“易进难深”领域入门只要一两周深入要按年算。**误区二算法才是核心工程是外围。**LLM Infra恰恰反过来你算法理解得再深控制不好显存、压不住延迟、做好了网关和计量模型照样没法上线或者上线了也没法长久稳定运行。工程能力在这个方向里就是核心生产力。**误区三跳过去就是要从零学一堆新东西。**实际不是的传统IT服务里练出来的交付纪律、排障流程、跨部门沟通能力放到LLM Infra照样吃香。你以前在业务系统上线前要做容量评估和压测现在只是把指标换成了token和GPU利用率底层逻辑完全一致。7.2 如果你也在传统IT环境里可以怎么迈出第一步我的建议是先别急着辞职先把你当前公司里能用到的场景摸一遍。哪怕只是在内部搭一个小模型服务让身边同事试起来就算迈出第一步了。用公司已有的GPU资源或云GPU把vLLM部署起来挂一个OpenAI兼容接口再写上几个业务prompt让同事们用真实需求去打。接着做两件事第一把接口日志接进你熟悉的监控系统里量化统计每天多少调用、多少token、多少延迟第二做一个小账单算清楚每天这些调用折算成GPU成本是多少。这两件事做完你就已经进入LLM Infra的核心逻辑了——因为一个只懂模型不懂成本、不懂稳定性的工程师在LLM Infra里是撑不过试用期的。说白了TCS带给我的并非行业认知而是一整套在混乱环境里把事做成的方法论。LLM Infra表面上是跟GPU、token、推理框架打交道本质上还是在跟不确定性打交道。模型会幻觉框架会出怪问题业务方的需求永远在变你能做的不是消除不确定性而是用工程手段把不确定性控制在别人感知不到的范围里。这跟我在传统IT服务里学到的那些东西本质上是一件事。转行之后我才意识到我真正带过来的不是手艺而是心态。 LLM Infra落地实战：网关、RAG与推理优化避坑指南
上篇写完到现在快两个月后台一直有人追问“你转到LLM Infra之后到底每天在干什么”“值不值得转”“有没有栽跟头”。说实话转之前我也觉得LLM Infra不过就是装个推理框架、调调参数、看看显存占用真正扎进去才发现这一层的水远比我想象的深而且很多坑是外面文档根本不会告诉你的。这篇“下”篇我不打算再复述简历上的心路历程直接讲转行落地之后真正动手做的几件事网关、计量、RAG、推理层优化、线上治理。每条都是我在生产环境里踩过坑、怼过人、也被老板骂过之后才理顺的。想转LLM Infra的朋友或者已经在做但觉得处处别扭的朋友这篇应该对你有用。3. 从零搭一个OpenAI兼容网关成本、配额、路由和一周后被骂醒的教训3.1 为什么网关是LLM Infra的命门刚转过去那会儿我以为搞LLM Infra就是把模型部署到GPU上接口能通就行。直到第一周结束技术负责人扔给我一句话“你把网关搞出来不然下周一各个业务线就自己接原始模型端口了。”我那时候才意识到在一家同时跑着十几个业务部门的公司里你暴露一个裸的模型服务等于把信用卡放在大街上。任何一个业务方都可以上来发请求没人知道谁在调用、调用多少、成本算到谁头上模型一旦被某个写死循环的脚本打满全公司所有AI功能一起瘫痪。你需要的并不是一个简单的HTTP转发层而是一个完整的控制面。我最终搭的网关至少承担了四件事认证与授权所有请求必须先过API Key校验不同Key绑定不同部门和权限级别。令牌级计量每个Key消耗的输入token和输出token全部落库按部门分摊成本。速率限制与配额按部门设置每分钟请求数上限、每日token预算上限超额直接返回429。模型路由与故障转移同一个业务接口背后可以挂多个模型实例主模型不可用时自动切换到备用模型。这四件事看起来简单但每件背后都有一堆细节。比如令牌级计量你以为数token就是看API返回里的usage字段实测发现同一个请求发给不同模型返回的usage口径都未必一致有的框架会漏掉system prompt里的token有的把工具调用参数不计算在内。为了对账准确我最后不得不自己实现一套tokenizer缓存逻辑提前把prompt拆好、按tokenizer类型分别统计才勉强把账单做平。3.2 令牌级计费与配额把成本摊到每个业务部门头上说真的LLM Infra最容易被忽略但最要命的需求就是成本核算。模型推理不是一次性买断的服务器而是按token烧钱的业务方根本感知不到“一次普通对话”到底花了公司多少钱。我做了个简单的账单模型给每个部门开了一个仪表盘实时展示当日总token消耗区分输入和输出按模型分摊的费用近7天趋势标注突然翻倍的时间点超配额预警然后问题来了。有一周我收到告警——某个部门的每日token消耗突然从500万飙到了3000万。查日志发现他们新上了一个“批量数据分析”功能自己写了个循环拿一个超长文本反复拼接prompt再调用。这其实不是恶意刷单纯粹是业务方不了解token计费逻辑以为多调用几次没有成本。那次的教训是光有配额告警不够必须把token成本和业务行为关联起来解释给业务方听。我后来养成了一个习惯每次做账单分析都要附一行“换算说明”比如“3000万token约等于每天把《三体》全集读130遍”。这种直观表达比任何数字都有用。也是从那次以后我开始在网关里加了一类“异常调用模式识别”规则比如同一请求体在短时间被重复发送多次或者输出token量远超正常范围就直接标记给管理员复核。3.3 模型路由与回退从“全挂了”到“优雅降级”网关还有个我一开始完全没想到要做的功能——模型回退。我最初的思路很简单业务方调网关网关转发给一个模型实例实例挂了就报错。但真实情况是你一个内部平台业务方接口会直接请求你的模型服务如果模型挂了他们那边整个流程就断了。你要么保证模型永远不挂要么保证挂了之后有替代方案。“永远不挂”在LLM场景等于空话GPU卡故障、OOM、超时、模型加载失败哪种都可能随时发生。所以我做了三层回退策略同模型多实例同一模型部署在多个节点轮询分发单节点故障时自动摘除。不同规格回退主力模型是70B级回退模型是量化后的13B或7B。质量会降但流程不会断。Prompt兜底某些简单任务比如意图分类、关键词抽取直接用一个极小的规则模板兜住不走模型。分层回退做完之后有一次正好赶上GPU驱动被误升级主力推理服务全挂业务方那里居然没有任何感知因为他们拿到的回退回答质量虽然略有下降但API的响应结构完全一致。那一刻我才明白LLM Infra做得好不好不是看在正常时候跑得多快而是看在故障时大家多无感。4. RAG并不是“向量检索加一段Prompt”生产级RAG的基建难点4.1 检索质量的工程化chunk怎么切、重叠多少、embedding怎么选我接手RAG基建之前团队里已经有人用简单的方式跑通了一版文档丢进去按固定长度切块塞进向量库检索时取TopK拼进prompt。Demo效果不错一上生产就原形毕露。业务方反馈“问题稍微拐个弯就答不上来”“经常答到一半就瞎编”。我去看了一眼发现最大的问题不是模型而是切块方式。那版实现用的是固定字符长度切块比如每512字一刀切下去结果一句话被拦腰斩断一个技术概念被劈成两半检索时只召回其中一半语义自然缺失。后来我重新设计了切块策略核心思路是分层第一层按语义边界粗切比如标题、段落、空行、列表项作为天然边界保证切块尽量完整。第二层设置重叠区间相邻块之间的重叠量控制在10%-15%让跨块信息至少在一个块里能完整出现。第三层小块召回上下文重建检索时先取小块再往前追溯所属的文章或章节把上下文字段一并拉出来送进prompt。Embedding模型的选择也踩了坑。一开始我们用的是通用中文embedding模型在内部文档场景下效果一般。后来换成了更大参数且针对特定领域微调的向量模型检索命中率明显上升。但有一个代价embedding维度更高向量库的存储和检索延迟都涨了不少。我们最后才确认了一个折中方案——主embedding用领域微调模型同时对向量做降维处理用PCA把维度从1536降到768检索质量几乎没有损失但查询延迟降了差不多三分之一。4.2 从GraphRAG到LLM Ontology当单纯向量库不够用还有一个让我印象极深的需求用户问“A部门和B部门的职责边界在哪里”或者“这条流程在什么情况下会自动审批”。如果文档里没有一句话直接回答这种跨实体关系问题向量检索再怎么召回都是碎片。这就是传统RAG的边界向量的本质是语义相似度它擅长帮你找“哪段文字和这句话最像”但不擅长“把两段文字里的实体关系拼起来回答问题”。后来我改成了GraphRAG的思路在向量库之上建一层知识图谱。具体做法分三步实体抽取用LLM把文档中的实体人名、系统名、部门、术语抽取出来。关系抽取抽取实体之间的关系比如“A系统调用了B接口”“某流程依赖某审批节点”。图谱落库把关系和向量索引共同存储检索时不仅取相似文本块还同步查图谱路径把关联关系一起拼进上下文。做这个改造花了大概三周但上线后最直接的收益是跨文档关系类问题的正确率从不到40%升到了76%。其中有个关键心得——图谱里的关系定义不能太碎否则图谱变成毛线团。我们最后收敛到只有8种关系类型反而效果更好。GraphRAG本身还牵扯到“LLM Ontology”的取舍到底该让LLM自动构建本体还是人工约束本体我踩出来的结论是前期一定人工定好骨架让LLM在固定骨架里抽取千万别让它自由发挥不然每次跑出来的实体关系都可能不一样图谱一致性根本没法保证。4.3 检索链路中的超时、重试与缓存看似简单实则到处是雷RAG的检索链路从用户提问到返回答案中间要经过embedding模型、向量库查询、图谱查询、prompt拼装、LLM生成几个环节。哪个环节慢整体就慢。我在调优的时候发现最容易被忽视的是向量库查询的波动——你平时查一次耗时20毫秒但数据量一大或并发一高就可能冲到400毫秒以上而且聚类特别严重。为了把尾巴削掉我做了三件事超时分级embedding、向量检索、图谱查询分别设置独立的超时时间谁超时都不拖累整个链路。降级策略向量库超时后直接跳过向量检索用关键词检索全文匹配兜底还是失败就直接返回“暂时无法检索到相关资料”绝不硬撑着等。结果缓存对同一类型的常见问题做语义缓存——把用户问题embedding化后与历史问题算余弦相似度高于阈值就直接返回旧结果不再走完整链路。做完之后检索链路的P99延迟从1.2秒降到了350毫秒而且成本跟着降了20%左右因为很多重复问题不再反复调用LLM。那时候我才体会到RAG的Infra做得好不好最终拼的是响应时间、成本和质量三者的平衡而不仅仅是“能不能找到文档”。5. 模型推理层的取舍量化、KV Cache、批处理策略5.1 为什么非得做量化显存、吞吐与收益抠算我在上篇提到过刚转过去时对GPU资源完全没有概念以为一张A100能跑70B模型就能扛住所有业务。真正上线才发现部署一个70B模型FP16权重就要占140GB显存一张80GB的卡根本放不下更别提还要留显存给输入输出和KV Cache。所以模型量化不是“可选项”而是“不上线别想跑”的硬门槛。我们的主力模型从FP16换成INT8之后显存占用降了一半左右单卡能扛住的最大并发明显提升。后来又尝试了INT4量化显存占用进一步降低但评测分数在某些逻辑推理类任务上掉了几个点。最终我们采用的是一套动态拆分的思路入口简单任务走小模型的量化版本复杂推理任务再走大模型的原生精度版本。这样既保证了质量又控制了整体GPU成本。具体算账的话我们的实践是这样的一个70B模型在FP16下理论需要140GB显存加上每1000条输入token产生的KV Cache大约占0.7GB到1.4GB。假设同时处理32个并发请求每个请求上下文是4000 token光KV Cache就要额外吃掉90GB左右。这就是为什么部署推理服务时最大并发数经常不是看算力而是看KV Cache那边的显存够不够。量化省出来的每一GB最终都会反映到并发能力和单位请求成本上。5.2 从vLLM的PagedAttention到prefill/decode拆分理解吞吐瓶颈说到推理吞吐那就绕不开vLLM。我一开始用vLLM很简单粗暴以为它就是个部署工具。后来深入研究才发现它的核心优势在于两层设计一是PagedAttention机制——把KV Cache拆成固定大小的块按需分配不再为每个请求预留整块连续显存。你可以把它理解成操作系统的虚拟内存分页这个机制解决的是显存碎片化和浪费问题。二是连续批处理——一个请求decode完一个token后立刻让出计算资源下个请求可以马上进来不用等整个batch跑完。这两层设计配合起来吞吐是真的能翻倍。我们的基线测试显示在同样一张卡上用原生transformers写的推理脚本单卡吞吐只有vLLM的大概40%左右。但vLLM也不是银弹。我后来为了压延迟把prefill和decode阶段拆开部署在不同节点上前一个阶段负责处理用户输入prompt并预计算KV Cache后一个阶段只做逐token生成。这样拆的好处是prefill阶段的计算量大但并行度高decode阶段是串行延迟敏感型两者混在一起容易互相干扰拆开后可以分别做资源伸缩和容错。这种做法的一个副作用是prefill阶段结束后要把KV Cache从一张卡搬运到另一张卡如果网络带宽不够传输耗时能把你刚省下来的几十毫秒全部吐回去。我们最后是用RDMA网卡把传输延迟压缩到个位数毫秒才真正划算。如果你的集群没有这种网络条件我劝你不要轻易拆prefill和decode老老实实单机部署更省心。5.3 ONNX部署、TensorRT-LLM、vLLM的实际选型对比这里我整理一下我实际用过的三条推理栈给出我自己的选型结论给需要的人一点参考推理栈优势劣势适用场景vLLMPagedAttention显存管理优秀吞吐高生态活跃接口兼容OpenAI协议对部分定制算子支持较弱依赖CUDA环境通用对话、RAG、大多数在线推理场景TensorRT-LLM极致单卡性能量化支持丰富低延迟表现突出编译时间成本高模型结构改动后需重新构建引擎延迟苛刻、吞吐要求高且模型结构稳定的场景ONNX Runtime跨硬件部署灵活可在CPU/GPU混合环境运行不绑定特定厂商大模型场景性能优化浅复杂模型图优化有限边缘设备、CPU推理、多端统一部署我个人的实践感受是如果你的目标是快速上线且模型迭代频繁vLLM是最省心的如果你想拿同一批GPU榨出最大的吞吐而且模型结构已经稳定TensorRT-LLM值得投入只有当你的部署环境特别杂既要跑GPU又要跑CPU才需要ONNX这条路线。ONNX部署LLM还有个很现实的痛点动态序列长度处理较麻烦很多操作符图结构在动态形状下会被打回原形你写好的graph优化根本用不上所以用ONNX做生产级大模型推理我建议你先把动态形状问题掰扯清楚否则上线之后会发现一半的优化效果都没生效。6. 线上治理从“能跑通”到“7×24稳”监控与排障6.1 监控指标的选法TTFT、TPOT、Token级延迟、GPU利用率转行后我花了不少时间在监控体系上。以前在传统IT服务里监控的事情还算简单看一眼CPU、内存、磁盘、网络就大概知道系统状态。但是LLM推理服务不一样GPU的利用率高也不代表服务正常显存不满也不代表没有瓶颈。我现在每天盯的核心指标是这几项TTFTTime to First Token用户发出请求到返回第一个token的耗时。这个指标直接决定“转圈圈”时间用户对它的敏感度极高超过两秒就会感觉卡。TPOTTime Per Output Token生成一个token平均耗时。它决定后面整体速度TPOT太高长回答就让人等得抓狂。Prefill吞吐和Decode吞吐拆开看计算资源到底吃在哪一段。KV Cache使用率接近上限说明并发快见顶要找扩容或做请求排队。GPU利用率和显存利用率不能只看整体要按卡按进程看才能定位局部热点。6.2 一次耗时长尾问题的排查链路有一段时间我们的服务TTFT平均是900毫秒但P99居然能到6秒也就是说每100个请求里有一个特别倒霉。我排查这个长尾问题的过程可以说完整展示了一次LLM Infra排障的典型链路第一步先看是不是网络层。我在网关端抓到P99请求的耗时拆分发现网络传输只占不到5%问题不在网段。这个步骤很关键不要一上来就怀疑模型层先确认“慢”到底发生在哪个环节。第二步看是不是负载不均。查看四张卡上的请求分布发现其中一张卡上的请求量明显偏多原因是负载均衡策略是按照请求数散的但每个请求的输入长度差异极大一个超长prompt请求拆分成大量prefill算子后把整张卡的计算资源占满了后续请求全在排队。第三步定位到卡后看显存与KVCache分配。那张卡上的KV Cache容量被大量长上下文请求吃满新请求一直等待显存释放。到这里根因就基本清楚了不是模型慢而是长尾大请求把一张卡的资源挤爆了。第四步修复。改了两处一是负载均衡策略改成按预估显存和计算量加权而不是按请求数二是网关加了一层请求长度配额对超长上下文请求做限流和排队避免它直接冲垮单卡。这个坑的典型性在于如果你只看平均延迟指标完全发现不了问题只有把P99拆开按卡、按请求类型分维度看才能看到那张被长尾请求拖垮的卡到底发生了什么。6.3 LLM as Judge用模型来检查模型服务线上服务稳定之后还有一件绕不开的事——质量。常规做法是搞一套业务级评测集定期跑分。但问题在于评测集靠人打标的成本高、更新慢很多新场景根本来不及覆盖。我后来引入了LLM as Judge的机制做一个自动化质量看门狗。思路很简单设一个专门的裁判模型把用户问题和线上模型的实际回答一起送进去让裁判模型判断回答是否存在答非所问、胡编、内容缺失等问题。这个裁判模型不直接服务用户只做质量评判所以可以用一个相对小的模型把成本压得很低。实际运行之后我发现它最大的价值不是替代人工评测而是把“质量回归”从每周一次变成了每次发布后自动执行。做这个功能有几个细节坑裁判模型本身会被“带偏”的如果裁判模型的提示词里没有明确的评分标准它会倾向于给“看起来流畅”的回答打高分。必须给裁判模型提供参考答案或事实依据否则它只能评判流畅性没法评判正确性。裁判结果需要抽样复核不能完全自动放行我保留了一个10%的人工抽检口防止裁判模型自己越跑越偏。在LLM Infra里LLM as Judge看似不是基础设施层面的东西但它其实承担了“质量SLA”的职责。没有这套自动评判机制你对线上模型质量的理解只能靠用户骂声那就晚了。7. 关于转型最后想说的大实话7.1 三个最常见的认知误区从我自己的经历来看想从传统IT环境跳到LLM Infra的人通常带着几个误区**误区一LLM Infra就是会部署模型就行。**实际上部署只是入门门槛真正的价值在于网关、计量、RAG链路、推理优化、监控排障这些外围工程能力。你光会部署一个模型就相当于会开一辆车但不会保养更不会判断故障。LLM Infra是典型的“易进难深”领域入门只要一两周深入要按年算。**误区二算法才是核心工程是外围。**LLM Infra恰恰反过来你算法理解得再深控制不好显存、压不住延迟、做好了网关和计量模型照样没法上线或者上线了也没法长久稳定运行。工程能力在这个方向里就是核心生产力。**误区三跳过去就是要从零学一堆新东西。**实际不是的传统IT服务里练出来的交付纪律、排障流程、跨部门沟通能力放到LLM Infra照样吃香。你以前在业务系统上线前要做容量评估和压测现在只是把指标换成了token和GPU利用率底层逻辑完全一致。7.2 如果你也在传统IT环境里可以怎么迈出第一步我的建议是先别急着辞职先把你当前公司里能用到的场景摸一遍。哪怕只是在内部搭一个小模型服务让身边同事试起来就算迈出第一步了。用公司已有的GPU资源或云GPU把vLLM部署起来挂一个OpenAI兼容接口再写上几个业务prompt让同事们用真实需求去打。接着做两件事第一把接口日志接进你熟悉的监控系统里量化统计每天多少调用、多少token、多少延迟第二做一个小账单算清楚每天这些调用折算成GPU成本是多少。这两件事做完你就已经进入LLM Infra的核心逻辑了——因为一个只懂模型不懂成本、不懂稳定性的工程师在LLM Infra里是撑不过试用期的。说白了TCS带给我的并非行业认知而是一整套在混乱环境里把事做成的方法论。LLM Infra表面上是跟GPU、token、推理框架打交道本质上还是在跟不确定性打交道。模型会幻觉框架会出怪问题业务方的需求永远在变你能做的不是消除不确定性而是用工程手段把不确定性控制在别人感知不到的范围里。这跟我在传统IT服务里学到的那些东西本质上是一件事。转行之后我才意识到我真正带过来的不是手艺而是心态。