最近我集中把一个方向的论文翻了底朝天LLM Infra。这个领域不像模型算法那样天天上头条但所有能跑起来的、能上线的、能被业务用起来的大模型系统底子都靠它撑着。无论是做推理优化的、搭RAG知识库的、设计网关路由的、还是搞模型评估的本质上都在解决同一个问题把模型的能力稳定、低成本、可控地变成产品能力。这篇博客我把整个LLM Infra方向拆成五条主线来讲Token生命周期、检索增强RAG/GraphRAG、知识库与本体、网关与部署、评测与落地。每一块我都会带出对应的关键论文和技术思路再结合我实际踩过的坑来解释为什么论文里的方案在真实业务中经常需要二次改造。适合正在做大模型落地的工程师、准备入门AI基础设施方向的研究生、以及想搞清楚“大模型上线前背后到底发生了什么”的产品和技术负责人。1. LLM Infra 到底在研究什么1.1 从“模型能用”到“系统好用”的鸿沟先把概念框定一下。当我们说LLM Infra说的是支撑大模型训练、推理、服务、检索、评估的一整套底层系统和工程方法。它横跨三个层次最底下是GPU集群和调度层中间是推理引擎和模型服务层上面是检索、路由、网关、评测等应用基础设施层。论文圈里最常被引用的工作基本都落在这三个层次上。比如vLLM背后的PagedAttention、Tensor Parallelism、Continuous Batching、投机采样Speculative Decoding这些是典型的推理层创新而GraphRAG、Self-RAG、Corrective RAG这些是检索层像LangChain和Semantic Kernel这类框架研究则偏向服务编排层。我见过很多团队拿到一个开源大模型跑了几个demo觉得效果不错就开始规划上线。结果一到并发、延迟、成本、知识更新这些问题上就傻眼了。模型权重只占整个系统复杂度的一小部分真正决定系统能不能落地的恰恰是围绕模型周围的那一圈基础设施。这就是为什么这两年AI Infra的岗位需求暴涨因为大家终于承认模型能力是上限基础设施决定你能不能摸到那个上限。1.2 为什么 Infra 论文往往比模型论文更值得精读模型算法类的论文通常是在某个基准上提高了零点几个点但基础设施类的论文一旦成立往往是数量级层面的提升。PagedAttention把KV Cache内存碎片问题解决了吞吐提升了几倍到几十倍这种收益是任何模型微调都给不了的。所以我的建议是做应用和系统的人读论文的时候优先把精力放在Infra方向。模型层的结构创新你可以知道个大概但推理引擎怎么管理显存、连续批处理怎么调度请求、RAG的切块策略怎么影响召回质量这些细节直接决定你写的每一行代码的效果。Infra方向的论文还有一个好处——可复现性通常更强。模型训练论文经常背着巨大的算力门槛你根本复现不起但Infra论文很多是纯系统设计逻辑自洽代码往往也开源了。你读完之后是真能转化成自己系统里的优化手段的。1.3 成本曲线决定技术选型聊LLM Infra绝对绕不开钱。GPU的账单是按秒跳的Prompt里多塞一个Token可能就意味着每个月多烧几万块。所以Infra论文里到处可见对成本、延迟、吞吐这类指标的执念不是因为研究者市侩而是因为这是生产系统最真实的约束。读这类论文时我建议你带着三个问题它优化了哪个指标牺牲了什么在什么条件下失效比如投机采样用小模型草稿加速大模型解码听起来完美但在低并发、小batch的场景下收益可能很小因为草稿验证本身也有开销。不做这个判断就直接上生产很容易得出“论文是骗人”的错误结论。2. Token 是 LLM Infra 的最小作战单元2.1 理解 Token 的 key/query/value 三要素LLM Infra处理的最基本对象不是句子不是单词是Token。这个词在工程语境下几乎每天都在被提到模型按Token计费、上下文按Token计数、嵌入按Token并行。但你有没有想过一个Token在模型内部到底扮演什么角色我们可以用大家常说的“key/query/value”框架来理解Key我是谁——Token的位置信息和身份标识决定了它在序列里和其他Token的关系。Query我在找什么——当前Token主动去“关注”其他Token时发出的匹配请求。Value我能提供什么——Token携带的实际语义信息当它的Key被匹配到时它贡献出的向量内容。这三者叠加起来就是Transformer里自注意力机制的本质。而在工程层面这个机制催生了LLM Infra最核心的优化对象——KV Cache。因为自注意力在生成阶段每来一个新Token都要重新计算和所有历史Token的注意力分数为了不做重复计算系统把历史Token的Key和Value缓存下来这就是KV Cache的由来。我建议所有搞LLM应用的人把这个机制想明白。因为后面凡是遇到上下文太长、并发上不去、显存不够这些问题根因几乎都在KV Cache身上。你能理解这一点就比很多人强一大截了。2.2 Tokenizer 与词表设计被忽视的第一环很多做RAG和Agent的人容易忽略Tokenizer的重要性但Tokenizer实际上决定了你花多少钱。同一个句子用不同Tokenizer切出来的Token数量能差出20%以上。中文场景更明显同样的内容用不同词表切分Token数可能差到一倍。经典的工作包括BPE、WordPiece、SentencePiece这些子词切分算法。到LLM时代比较有代表性的设计是TikToken系列一个核心思路是尽可能把高频词干脆切成单个Token这样英文文本的Token效率就大幅提升。但中文不一样汉字组合太灵活词表很难覆盖所有高频词所以中文章节经常要靠长Token拼接成本就上去了。实操建议如果做中文场景一定要专门测一下你们实际语料的Token消耗。很多团队用英文基准测出来的“便宜”模型放到中文语料下完全不是一回事。这块没有捷径拿真实语料去跑一遍分布统计比任何估算法都靠谱。另外不同模型用的Tokenizer不通用切换模型时要重新评估Token成本和上下文截断策略。2.3 KV Cache 与 PagedAttention推理优化的主战场KV Cache是生成式推理显存消耗的大头。比如一个7B模型如果上下文长度是2048KV Cache就可能吃掉接近1GB显存换成长上下文模型这个数值会涨得更快。所以KV Cache怎么存储、怎么复用、怎么压缩是Infra论文里的常青主题。最值得读的一篇是vLLM的PagedAttention。它的核心思路很朴素操作系统管理内存用分页机制那KV Cache能不能也分页答案是能。把连续的KV Cache切成固定大小的块用块表来管理映射关系。块内连续、块间不连续这样就消除了显存碎片并且多个序列可以直接共享同一个物理块的KV数据这对于并行采样和beam search这类场景收益极大。顺带一提SqueezeLLM、KVQuant这类论文则在研究KV Cache的量化压缩。原理是KV缓存里存在明显的离群值普通量化效果差所以需要做离群值感知的量化。这些工作落地之后长上下文场景的显存压力能降一个量级。实测下来PagedAttention这类优化在长上下文、高并发的场景下简直是必需品。我自己压测过开启PagedAttention之后同等显存下的吞吐提升非常可观尤其在序列长度分布不均匀的场景下有的请求很短、有的很长收益更明显因为它把碎片空间都拿出来了。2.4 实操监控 Token 消耗与上下文爆掉的排查方法说到实操我强烈建议你在系统里从第一天就埋好Token监控。不是只在日志里记总数而是按请求维度记录Prompt的Token数输入Completion的Token数输出模型返回的finish_reason是正常结束还是截断上下文窗口中KV Cache的估算占用为什么这么细因为出问题的时候你需要精确定位。比如用户反馈“回答突然不完整了”你先看finish_reason如果是length那就是输出截断了解决办法是调整max_tokens或者优化Prompt让输出更短。如果是上下文溢出就要看输入Token数是否超过了模型窗口这时需要考虑做切分或者走RAG路线压缩上下文。还有一个容易踩的坑不同模型厂商对Token的计数方式不完全一致。你本地用HuggingFace的Tokenizer测出来的数字和云端API返回的可能是两回事。尤其是带特殊Token角色标记、系统提示词的时候差出几百个Token很正常。所以所有客户端侧的Token计数一定要用和服务端完全相同的Tokenizer和规则并且要留出至少10%的余量别把上下文窗口用满。3. RAG 与 GraphRAG检索增强不是“加个向量库”那么简单3.1 RAG 原始论文与三阶段拆解RAGRetrieval-Augmented Generation这个概念出自Lewis等人2020年的论文。核心思路一句话让模型在回答前先去外部知识库检索相关内容把检索结果拼进上下文里再生成答案。这个设计同时缓解了大模型知识过期和幻觉两大问题而且不需要重新训练模型所以成了企业落地LLM最主流的手段。标准的RAG流程可以拆成三个阶段索引阶段把文档切块Chunking、向量化、写入向量库。检索阶段把用户Query向量化在向量库里做相似度检索拉回Top-K相关文本块。生成阶段把检索结果和原始Query一起组装成Prompt交给LLM生成最终答案。听起来简单但每个阶段都有大量陷阱。切块大小直接决定了检索的粒度向量模型的选择决定了语义相似度算得准不准Prompt的组装方式决定了模型是不是真的会参考检索内容。这里没有银弹只能针对业务语料逐步调优。3.2 GraphRAG当知识需要“连点成面”普通RAG有个天然短板它擅长回答“直接能查到的信息”但不太擅长处理需要跨文档推理的问题。比如“A公司在这个项目的合作方里哪几个曾经和B公司合作过”如果答案分散在几篇文档里纯向量检索很难把信息串联起来。GraphRAG就是为了解决这类问题出现的。它的做法是在索引阶段先用LLM从文档中抽取实体和关系构建知识图谱查询阶段不仅做向量检索还通过图结构去扩展相关的实体和路径把隐藏的关系链捞出来。微软开源的GraphRAG是这一派的代表性工作。它沿用了一种社区检测算法把知识图谱划分成不同层级的社区并预先为每个社区生成摘要回答全局性问题时直接基于社区摘要来回答。这套思路在企业内部的知识管理场景里特别好用因为它能回答一些“总结整个项目组过去半年解决的所有问题类型”这类跨文档综合题。实操建议GraphRAG绝不是简单替换向量库它的索引成本高很多要反复调LLM做实体抽取。我的经验是如果业务场景偏FAQ定位、答案都在单文档内朴素RAG就够了如果问题经常跨文档或者要“全局视角”的答案再上GraphRAG。两者也可以混用先向量检索命中候选再用图结构做关系扩展我实测这种混合方案在召回质量上比单用任一方案都好。3.3 LLM Wiki 与本体论Ontology把知识库建得更“聪明”热词里多次出现“LLM Wiki”它本质上指向一个方向把知识库建设从“塞文档”升级成“建体系”。很多团队的RAG知识库就是一堆PDF往里一扔效果全靠运气。LLM Wiki的思路是在索引之前先建立一套本体Ontology——也就是对领域内核心概念、属性、关系做形式化定义。比如做一个产品知识库就先定义产品、功能、参数、适用场景、常见问题这些类以及它们之间的“属于”“包含”“用于”等关系。有了本体之后切块和抽取都更有目标性。切块不再是按字符硬切而是按“一个产品描述块”“一条FAQ记录”来切实体抽取也更准确因为LLM已经有了明确的概念锚点。最近业界把这种“本体RAG”和GraphRAG、Wiki结构结合在一起形成了一套“先建立领域模型再构建检索索引最后基于索引生成”的完整链路。一个小的经验切入点不要贪大。我们当时做知识库一开始想把全公司的业务都建模结果本体建了半个月检索还乱成一团。后来改成先围绕一个高频场景建本体跑通了再横向扩展。本体要跟真实查询对齐不要为了建模而建模。3.4 实战案例本地 ERP RAG LLM 产品检索Semantic Kernel 实例拿一个具体场景举例本地ERP系统接入RAG做产品检索。传统ERP的产品搜索靠数据库模糊匹配用户搜“耐高温的密封圈”基本搜不到东西因为数据库里没有“耐高温”这个字段。用RAG接进来之后用户自然语言查询先变成向量检索再结合产品的结构化属性就能精准召回。我当时用Semantic Kernel微软的语义内核框架来做这个编排。Semantic Kernel提供了插件Plugin、函数Function和规划器Planner的抽象可以把ERP的查询接口封装成原生函数把RAG检索封装成语义函数然后用一个自然语言计划把它们串联起来用户输入“找出所有能承受80度以上高温的密封圈”语义函数完成Query向量化去向量库检索候选产品原生函数把候选产品ID传给ERP接口拉取实时库存和价格LLM汇总生成带条件的答案这里的关键在于RAG只负责召回候选最终以ERP结构化数据为准避免了大模型编造库存。这种“语义检索结构化校验”的混合架构我认为是LLM在传统企业软件里落地最稳的模式之一。顺带说一句Semantic Kernel和LangChain这条路子不要过度迷信它的“规划”能力。真实环境里复杂多步规划经常出错我的做法是能写死在编排逻辑里的就写死把LLM局限在“分支判断”这种小而稳的环节上。4. LLM 网关与部署模型落地前的最后 100 米4.1 为什么需要 LLM 网关路由、熔断、限流、可观测当你的系统里不止一个模型时你就会有网关需求。很多团队一开始只在调用OpenAI或某一家API觉得网关多余。但当你同时接了好几个模型或者自己部署的模型和API混用问题就来了不同模型能力不同、成本不同、延迟不同怎么路由某个供应商出故障了怎么快速切换用户请求量突增怎么限流防止雪崩LLM网关就是为这些场景服务的它位于应用和模型之间一般负责四件事路由根据请求内容、成本预算、模型能力要求把请求分发给合适的模型治理限流、熔断、重试、鉴权可观测记录每一次调用的Token、延迟、成本、错误码统一协议屏蔽多个模型服务商的API差异我自己搭过一个简单网关基于OpenAI兼容协议做的统一封装。内部路由逻辑用了规则成本权重简单分类任务走小模型复杂推理和生成走大模型。就这一层路由上线之后月度成本直接降了差不多一半同时大模型的负载也不再总是打满。4.2 语义内核Semantic Kernel与函数编排的边界Semantic Kernel这套框架的定位介于应用层和基础设施层之间。它的核心抽象是把AI能力和业务能力都封装成“函数”然后让LLM来选择和编排这些函数。这套思路在企业应用里最大的价值在于它给了你一个标准化的方式来组织Prompt、插件的调用链而不是让每块业务各自为政地写Prompt拼接逻辑。你在Semantic Kernel里可以给每个插件写详细的自然语言描述LLM在规划时会读这些描述来决定要不要调用、用什么参数调用。但说实话它的Prompt相关能力在实际中用得越来越少了现在团队更倾向于直接写代码编排。我自己更看重它对“函数注册和内存管理”的抽象——把用户历史、工作会话、检索到的上下文统一管理LLM调用链复用时不用每个请求重新组装。这块思想我觉得值得借鉴不一定非要全套用框架。4.3 ONNX 部署与推理引擎选型部署层面ONNX Runtime在LLM Infra里的角色越来越重要。ONNX是一种开放的模型交换格式你可以在PyTorch里训练好模型然后导出成ONNX再用ONNX Runtime在不同硬件上做推理。它的优势是可移植性强而且ONNX Runtime的图优化和量化工具链很成熟。不过LLM和传统CV模型的部署逻辑不太一样。LLM是自回归生成一次推理吐一个Token不能简单当普通网络跑一次前向。ONNX Runtime针对Transformer的生成模型提供了专门的优化包括注意力融合、KV Cache管理等算子级别的处理所以在CPU推理和边缘部署场景下ONNX是一条很值得走的路。选推理引擎的时候我建议按场景分高并发云端GPUvLLM、TensorRT-LLM这类专为吞吐优化的引擎通用CPU或异构设备ONNX Runtime胜在跨平台边缘小模型用ONNX量化INT8/INT4后部署体积和延迟都能接受踩过的坑ONNX导出时原始模型里的动态轴处理要格外小心。LLM的序列长度是动态的如果导出时固定了序列长度后面跑起来遇到更长的输入就直接报错。解决方法是善用动态轴Dynamic Axes这需要你对模型结构和服务框架都有比较深的理解。4.4 生产报错实录provider rejected request schema 怎么排查最后分享一个最常见的线上报错llm request failed: provider rejected the request schema or tool payload。这个报错的本质是你发给模型服务商的请求里某个字段不符合对方的API规范尤其容易出现在Function Calling/Tool Calling的载荷里。排查思路按顺序来看请求体原文不要只看报错摘要把实际发出的JSON打到日志里逐个字段对照API文档。重点查Tool定义函数名、参数名不能和系统保留名冲突参数类型要匹配尤其是嵌套对象里带枚举值的字段。查工具调用结果回传格式模型会自己生成一个包含函数调用的响应如果你把这个响应直接回传给API格式必须和规范严格一致多的、缺的字段都会触发这个报错。版本差异不同厂商、不同日期的API版本对Tool Payload的约束不一样升级SDK之后经常在这里踩雷。我的建议是给上游调用做一个schema校验层在发出请求之前先用JSON Schema校验一把把错误挡在自己家里比等供应商拒绝后再排查要省钱省力多了。5. 评测是这一切的度量衡榜单之外我们看什么5.1 Open LLM Leaderboard 与公开评测的盲区做LLM Infra的人离不开评测。Open LLM Leaderboard这类公开榜单是很多人选模型的起点但它的局限性必须认清。这类榜单的分数基于固定基准集考核的是通用能力而你的业务场景可能是领域问答、长文档摘要、结构化数据提取关联度不一定高。更要注意的是同一模型在不同Infra配置下表现会不一样。量化过的模型在基准上可能只掉零点几个点但在你的具体业务上可能表现为“偶尔出现语无伦次”。所以公开榜单只能用来初筛模型候选绝不能替代场景评测。5.2 面向场景的自建评测集与回归测试我比较推荐的做法是从第一天就建设“影子评测集”。把你的真实用户问题收集起来脱敏后组织专家或者用高能力模型标注标准答案形成几十到几百条的评测集并按难度和类型分层。每次更换模型、调整检索策略、修改Prompt模板时都在这个评测集上跑一遍看分是升是降。这块就是LLM系统的回归测试。我经历过最肉痛的一次调了一个检索的切块参数召回率看起来涨了结果有一个核心业务场景的答案质量掉了三成如果没有评测集这个回归就得等用户投诉才能发现。评测集要动态维护。每月把新出现的、模型答错的问题加进去把已经稳定答对的适度淘汰掉控制评测集规模和难度漂移。不是越多越好几百条高质量问题的分层评测集比几千条垃圾问题有用得多。5.3 评测指标的误区ROUGE、BLEU 与人类感受的差距做LLM Infra评测最难的是自动化指标和人类感受之间的鸿沟。像ROUGE、BLEU这类指标适合机器翻译和摘要任务但对话、问答场景里不同说法意思相同但词面差异很大的情况很常见传统指标会给出很低的分数但人看着都挺好。现在比较靠谱的做法是引入LLM-as-a-Judge让强模型给弱模型的回答打分。但它也有偏好评审判模型倾向于更喜欢自己风格的答案。所以要做双盲、要多个Judge投票、要定期抽一批结果人工复核。别把评测做成一锤子买卖更重要的是建立一套“业务效果反馈→评测集更新→系统迭代→再评测”的循环。评测不是用来证明系统好是用来让系统持续变好的。6. 几个容易把项目带偏的实操认知6.1 切块大小到底该听谁的RAG的Chunk Size是大家最爱纠结的参数。向量检索时代块越小召回越精准但上下文碎片化严重LLM难以获取完整语义块越大上下文越完整但向量检索精度下降且塞进Prompt的冗余Token越多、成本越高。没有全局最优的切块大小只有基于业务语料的局部最优。我的做法是对语料做统计计算文档里段落长度的分布、关键信息出现在哪一层级再定一个“语义完整优先”的切块策略同时保留块与块之间10%-15%的重叠避免上下文断裂。有一类语料特别适合“结构化切块”表格、清单、说明书。按行、按表格块切比按字符切效果天差地别。这一点很多人忽略了其实投入产出比极高。6.2 指标提升不等于业务体验提升你在评测集上把回答准确率从85%拉到90%这个提升有时在用户侧感知不明显。用户更在意的是回答是不是快、是不是稳定、信息是不是最新、出错时有没有兜底话术。准确率只是体验的一部分。所以做Infra优化时要同时盯着延迟P95、错误率、兜底触发率这些服务指标而不是只盯着模型质量指标。有一次我们专注优化检索召回质量分涨了但一次参数调整导致检索过慢P95延迟翻倍用户反而更不满意。好的Infra优化一定是在质量和服务稳定性之间找平衡而不是单点指标拉满。6.3 论文的可复现性陷阱很多Infra论文在开源环境里跑得很好到你的业务环境里就失灵了。原因通常不是论文有问题而是条件不同显存大小不同、算力卡型号不同、请求模式不同、数据分布不同。读论文时一定要把“实验条件”和“结论”分开看。PagedAttention在均匀长度序列下收益有限但论文里可能不会专门强调这一点。所以复现论文优化时先在你自己环境里做一个A/B压测拿数据说话试完如果收益不够就要果断放弃不要在花里胡哨的方案上无限投入。我自己有个原则任何Infra层的优化必须能在一个独立可比的压测环境里给出明确的收益数字否则不上生产。最后分享一个我最近的体会LLM Infra这个方向看起来很杂但底层逻辑是相通的——无非是管理好Token的流转、缓存好计算结果、控制好成本和质量之间的平衡。你不需要把所有论文都读完但把这几个核心脉络理清楚遇到实际问题时你自然会知道该往哪个方向查、该信谁的方法、该在什么地方存疑。论文是别人的地图最终路还得你在自己的生产环境里走一遍。