1. 第七十一期的位置：为什么系统学习后半程要重点啃"推理优化"
追过这套 LLM 大模型系统学习指南的朋友应该知道，前面的期数一直在做两件事：把模型从原理层面拆开，再把训练链路跑通。到了第 71 期，我打算换一个视角——不再关心模型是怎么训出来的，而是关心模型是怎么"伺候用户"的。说得直白点，就是推理优化和部署落地。这件事很多人误以为只是敲几行启动命令，等真上手才发现，它涉及的显存管理、调度策略、精度取舍，每一个单拎出来都够写一篇长文。
为什么这个阶段值得单独占一期？因为训练和推理虽然共用同一套模型结构，但优化目标完全相反。训练时你希望吞吐尽量高、显存尽量被榨干，容忍一定程度的延迟波动；推理时你面对的是一个个真实用户，每个请求都在等你的第一个 token，延迟的毛刺会直接变成用户感受到的"卡"。而且推理成本是持续性的，模型每响应一次都在烧钱，同样的 GPU 资源能扛多少并发，直接决定这个项目能不能长期跑下去。我见过不少团队，模型效果调得很好，最后死在推理成本压不下来，或者并发一高就 OOM，非常可惜。
这一期适合什么人看？如果你已经能独立微调一个中小规模模型，但对"把它变成稳定服务"还没有完整方法论，那这篇内容正好补上这块拼图。如果你还处在入门阶段，也不要紧，我会尽量把底层机制讲成人话，你哪怕暂时不实操，也能建立起一个正确的全局认知：推理优化到底在优化什么，为什么同样一块卡，别人能服务的用户数比你多好几倍。这一期不求把每个细节讲到极致，目标是帮你把推理这条链路的关键节点全部点亮，后续再遇到具体问题，你知道该往哪个方向查。
2. 慢从哪来：自回归解码的串行本质与 KV Cache 显存账本
2.1 一个 token 一个 token 蹦出来的硬约束
先聊一个很多人忽略的事实：大模型生成文本的方式，本质上是一个一个 token 往外蹦的。假设模型在生成一句话，第 10 个 token 的计算，必须依赖前面 9 个 token 的结果，无法并行。这个特性叫自回归解码，是当前绝大多数生成式语言模型的底层逻辑，也是推理"慢"的最根本来源。
你可以在任意一次请求里直观感受到这个约束：模型从你输入整段提示词到吐出第一个 token，这段时间叫首 token 延迟，它由一次大规模前向计算决定，通常还能接受；但之后每生成一个 token，都要做一次完整的前向推理，token 一个接一个串行产出，生成 500 个 token 就意味着至少 500 次串行计算。所以决定用户体验的，不只是模型快不快，还有一个很实在的指标——每秒能吐多少个 token。有的模型跑得快，单次前向计算只需要几十毫秒，但生成长文时用户还是觉得慢，关键就在这个串行节奏。
2.2 KV Cache 的显存账本：算给你们看
串行带来的另一个问题是浪费。既然每次生成新 token 都要重新看一遍前面的 token，那前面这些 token 的中间结果能不能缓存下来复用？能。Transformer 架构在做注意力计算时，每个 token 都要产生一对 Key 和 Value 向量，它们编码了"这个 token 在当前位置的上下文信息"。如果你不缓存，每生成一个 token，前面所有 token 的 K、V 都要重算一遍，浪费大量算力；缓存下来，每次只计算新 token 的 K、V，然后和缓存拼接，这就是 KV Cache 的基本思想。
显存消耗有多大？我给你算一笔实际账。假设一个 70 亿参数规模的模型，常见配置是 32 层 Transformer、隐藏维度 4096，模型权重用 FP16 存储。每缓存一个 token 的 KV，需要的显存大约是：层数 × 2（K 和 V 各一份）× 隐藏维度 × 每个数值的字节数，也就是 32 × 2 × 4096 × 2 字节，约等于 0.5 MB。听起来不多，但上下文越长越惊人：2048 token 的上下文，KV Cache 就要吃掉约 1 GB；如果把上下文加到 8192，光缓存就是 4 GB。你以为显卡主要被模型权重占着，实际上上下文一长，KV Cache 的分量一点都不小。这就是为什么同样一个模型，部署时有人在 context length 上抠得非常紧——不是不想支持长文本，是显存不支持。
2.3 把显存账本补齐：权重、激活值与缓存三方分账
很多人在显存规划上只盯着模型权重，这是一个非常容易踩的误区。完整的显存开销要分三块看：权重、激活值、KV Cache。以那个 70 亿参数的模型为例，FP16 权重约 14 GB（70 亿参数 × 2 字节），看起来是大头，但实际服务中激活值和 KV Cache 会在峰值时刻反超。激活值是指前向计算过程中每一层产生的中间张量，它和 batch size 直接相关，batch 越大越吃显存；KV Cache 则和总上下文长度直接相关。三者在同一张卡上争抢资源，任何一个失控都会触发 OOM。
理解了这三块账，再回头看那些推理框架做的事情，思路就清楚了：它们无非是在"省权重显存"（量化）、"省 KV 显存"（缓存管理和显存复用）、"省激活值显存"（梯度检查点思路的推理版本，以及控制 batch 调度）这几个方向上做文章。后面几节的内容，全是围绕这个账本展开的。
3. 服务化的两次架构升级：动态批处理与 KV Cache 分页管理
3.1 静态批处理为什么喂不饱 GPU
单请求串行已经是瓶颈，但只处理单请求，GPU 的利用率其实很低。因为一次前向计算里，矩阵运算的大头是"批量矩阵乘"，一个请求的矩阵乘远没有塞满计算单元。很自然的想法是：多个请求同时进来，拼成一个 batch 一起算。这就是批处理，也叫 batching。
早期的推理服务大多用静态批处理：攒够 N 个请求，一起前向计算，等这批全部生成完，再放下一批进来。这看起来合理，但有一个致命问题——每个请求的长度和生成速度不一样。有的请求上下文短，几秒就生成完了，有的请求要求生成 800 个 token，得跑几十秒。静态批处理要等最慢的那个请求彻底结束，整个 batch 才能释放。你去看 GPU 利用率的监控曲线，会发现大量时间片被浪费在"等待掉队者"上，吞吐根本拉不起来。
3.2 Continuous Batching：把"一整批"拆成"流水线"
后来社区的主流做法变成连续批处理，思路和工厂流水线很像：不再要求一批请求同时进、同时出，而是每个请求独立推进，它每生成一个 token 就算完成一步；某个请求生成完了，立刻把这个位置腾出来，让排队的新请求补进去参与下一轮计算。这样 GPU 每一轮前向都在为"当前活跃的请求集合"服务，而不是为一个固定 batch 服务，整体利用率大幅提升。
用一句话总结两种方式的差异：静态批处理是"等全班交卷才下课"，连续批处理是"谁交卷谁走，新同学随时进教室"。同样是 100 个请求，静态批处理的完成时间是所有请求生成时长之和的某种"最长路径"，连续批处理则能把吞吐拉高一个量级。这也是后来几乎所有主流推理服务框架都把连续批处理作为默认能力的原因。
3.3 给 KV Cache 做"虚拟内存"：分页管理
连续批处理解决的是利用率问题，但它也让显存管理变得更复杂。每个请求的 KV Cache 大小是动态增长的，因为 token 是一个一个往外蹦的。如果部署时给每个请求预先分配最大可能长度的 KV 空间，显存碎片和浪费会非常严重；如果动态分配，又面临高频内存分配和释放的开销，以及碎片化问题。
我最早看到工程上真正把这个问题解决干净，是某个开源推理框架引入的分页注意力机制，灵感直白得让人拍大腿——它把操作系统虚拟内存的分页思想搬到了 KV Cache 上：把连续的 KV Cache 逻辑空间切成固定大小的块（类似内存页），物理显存上也按块分配，逻辑上相邻的块在物理上可以散落各处，通过一张块表来映射。这样每个请求只在真正需要时才申请新的块，解决了动态增长的问题；多个请求如果共享相同的前缀上下文，还能直接共用同一批块，省下一大块显存。这就像一个酒店房间，不同客人入住时间不同、行李多少不同，你不可能给每个客人预租一整栋楼，而是按需给钥匙、按需加床。
这套设计对长上下文的帮助尤其明显。之前 KV Cache 需要一次性预留足够空间，很多请求实际用不到那么多，白白浪费；分页之后，显存是按实际生成量逐步消耗的，同样的显存能容纳的并发请求数量明显上升。
3.4 Prefill 与 Decode 分离：让不同阶段各跑各的
批处理优化到这一步，还有一个调度维度值得讲：请求的生命周期其实可以分为两个阶段。第一个阶段是 Prefill，也就是读取你输入的一大段提示词并计算它们的 KV 值，特点是计算密集、显存开销大、延迟敏感；第二个阶段是 Decode，也就是逐 token 生成，特点是访存密集、单步计算量小。这两个阶段的计算特征完全不同，混在一起调度会因为互相拖累导致吞吐下降。
现在主流方案里常见的一种做法，是把 Prefill 和 Decode 拆到不同的调度策略甚至不同的计算单元上去处理：Prefill 阶段用较大的 batch 做长矩阵运算，把计算单元打满；Decode 阶段用小步快跑的调度方式，优先保证每个请求都能及时产出 token。实际测下来，这种拆分能让首 token 延迟和后缘 token 生成速率同时受益，属于那种"原理讲了谁都懂，但做了收益显著"的工程优化。你在学习推理框架源码时，重点看调度器是怎么把请求从 Prefill 队列挪到 Decode 队列的，这一块的逻辑吃透了，你对整个服务化架构的理解就成型了一半。
4. 量化选型：精度、吞吐、成本的三角权衡实践
4.1 各家量化方案到底在干什么
权重显存往往是大模型部署里最直观的支出项，于是量化成了最热门的优化手段。量化的本质是用更少的数据位去表示权重数值：FP16 用 16 位，INT8 用 8 位，INT4 用 4 位。位数越低，显存占用越小，计算也能更快，但精度损失风险越高。现在主流方案大致分几类，学习的时候不要只记名字，要理解它们在解决什么问题。
一种思路是训练后量化，直接拿已经训练好的模型权重做转换，重点在于怎么把浮点数值映射到低比特范围，同时把误差控制在最小。最常见的是按组做缩放和偏移：把一个矩阵切成若干小组，每组独立计算一个缩放因子，把这一组的数值"塞"进低比特范围。组切得越小，精度越高，但额外开销也越大，128 和 64 是实践里最常见的两种组大小。另一种思路是"看数据说话"的量化：不是对所有权重一视同仁，而是先跑一批真实数据，统计哪些权重通道对激活值影响大，对这些关键通道保留更高精度，对不敏感的通道大胆压到低比特。这种方案在不少场景里效果比均匀量化好，因为语言模型的权重重要性本来就不是均匀分布的。另外还有一类思路是直接训练时就考虑低比特约束，但成本高、链路复杂，中小团队很少走这条路。
4.2 我的四组对照实验怎么设计
量化好不好，不能只看一张 benchmark 表。我当时做选型时，设计了一个简单的四组对照实验，这个思路建议你也复用：选用同一个 70 亿参数的模型，固定同一批测试数据集，分别在 FP16、INT8、按组 INT4、以及基于激活感知的 INT4 这四种配置下测了三件事——显存占用、推理吞吐、以及一段有明确事实性答案的任务上的回答准确率。
结果符合预期也很有参考价值：FP16 是基线；INT8 显存几乎减半，准确率下降几乎看不出来，属于"无脑可上"的配置；按组 INT4 显存进一步压到三分之一左右，吞吐提升明显，但在长文本生成和复杂推理任务上开始出现可感知的变差；基于激活感知的 INT4 在某些任务上能追平 INT8 的水平，但实现和调试复杂度更高，对部署环境也有额外要求。这里我特别想说一点：如果你只是在做内部演示或者短文本问答，INT4 的精度损失通常可以接受；如果你的场景涉及复杂的多步推理、数学计算或者严谨的事实抽取，那么省下来的显存可能抵不上回答质量的下降，量化前一定要做任务级验证，而不是只信跑分。
4.3 什么场景建议放弃量化
聊到这里，我必须泼一盆冷水：不是所有场景都适合量化，至少有三类情况我建议你保持 FP16。第一类是模型本身已经很接近能力边界，你依赖的就是它那一点推理上限，任何精度损失都可能让输出从"勉强能用"变成"不可用"。第二类是显存瓶颈其实不在权重，而在 KV Cache 的长上下文场景——这种情况下你压权重的收益，远不如去优化缓存管理来得直接。第三类是团队没有足够的评测条件，无法确认精度损失到底有多大，那就不应该在没有度量体系的情况下贸然上线一个精度未知的版本。
另外提一个经常被忽略的新方向：KV Cache 本身也可以量化。前面算过，长上下文下缓存显存是大头，现在有一些方案把 KV 从 FP16 压到低比特，效果据说在可接受范围。我还没有在生产环境全面铺开，但从账面上看，这是比权重量化更有潜力的方向，因为上下文越长收益越大。建议你把这块也放进学习清单，等到方案成熟度上来，直接用现成的经验。
5. 上线前必须补的评测闭环：指标分层与回归集维护
5.1 从离线指标到在线体验，中间隔着一层"体感"
这也是我见过最多团队翻车的地方。模型部署上线了，监控面板显示 GPU 利用率正常、平均延迟也合格，但是用户反馈依然说"变笨了""回答变短了"。问题出在哪？出在评测指标选错了。推理服务的评测至少分成两层，一层是系统性能指标，另一层是回答质量指标，两层都要管，但管法完全不同。
系统性能指标里，最核心的三个是首 token 延迟、单 token 生成间隔、以及整体吞吐。首 token 延迟直接决定用户"点了发送之后多久看到第一个字"，一般要求在几百毫秒到一两秒之间；单 token 生成间隔决定输出节奏，太慢会让人感觉在挤牙膏；吞吐决定你的硬件成本能支撑多大并发。这三个指标在压测工具里都能测，但要注意，平均延迟会掩盖长尾问题，我习惯上更关注 P95 甚至 P99 分位——那些最慢的请求往往才是用户真正会投诉的请求。
质量指标的难点在于它是非确定性的。同样的输入，两次调用结果可能不同，所以不能只靠一个样例判断好坏，需要一套相对稳定的评估方法。比较务实的做法是两类结合：能自动判定的任务用自动化评测，比如选择题、事实抽取、代码能否通过测试用例；不能自动判定的任务就建立人工抽样打分规范，定期抽一批线上请求，按清晰度、忠实度、完整性几个维度打分。把这两个维度整理成一张表，每次改动之后跑一遍，你才能知道优化到底有没有用。
5.2 回归集怎么维护才不骗自己
评测最怕的不是没有指标，而是指标失真。我见过某个项目，回归测试集里全是训练阶段见过的题目，模型答得漂亮，上线后一遇真实问题立刻露馅。维护回归集的核心原则是要"防泄漏"和"贴近线上"。具体来说，我给自己的项目定了三条规矩：第一，回归集里至少要包含一定比例的线上真实脱敏请求，按周轮换；第二，每一类典型场景要有固定数量的"钉子户"样例，专门盯易错点；第三，新增模型版本时，禁止把新版模型生成过的优质回答再塞回测试集——那等于开卷考试。
维护回归集的另一个关键点是版本管理。测试集本身要纳入版本管理，每次评测记录模型版本、推理配置、量化参数、测试集版本，四者缺一不可。否则你根本说不清某个指标变化是因为模型更新了，还是因为换了量化档位，还是因为测试集被人改了。这看起来像工程管理常识，但在小团队里真的很容易被忽略，最后排查问题时只能靠拍脑袋。
5.3 评测结果反推优化方向的具体套路
评测不只是为了判断"能不能上线"，它还能帮你定位瓶颈在哪。我有一个固定的排查顺序：先看 P99 首 token 延迟，如果偏高，大概率是 Prefill 阶段调度或显存的问题；再看单 token 生成间隔，如果偏高，大概率是 Decode 阶段的访存带宽或者量化后计算瓶颈；如果整体吞吐上不去，去看并发度和 batch 调度；如果回答质量下降，回头查量化档位和上下文管理。这套顺序帮我避开过很多无效优化，比如某次吞吐不达标，我先去调量化参数，折腾两天没效果，后来发现是批处理调度没开启，一个简单配置就解决了。
线上和离线指标之间还有一个常用技巧：把线上延迟指标和线上的回答长度做关联分析。如果发现低延迟请求的回答普遍偏短，往往是因为服务在负载高时悄悄截断输出，或者触发了某种应急机制。这种问题光看平均延迟看不出来，但用户体验已经很差了。评测体系的成熟度，往往就体现在这种"别人想不到要查的地方"上。
6. 三次线上事故式的踩坑复盘：碎片、假稳与带宽瓶颈
6.1 事故一：OOM 不是显存不够，是碎片太多
第一次遇到服务频繁 OOM 时，我第一反应是显存不够，连夜下单加卡。结果加上卡之后问题依旧，才开始怀疑方向错了。后来把显存监控打开，发现峰值显存远没到上限，但分配请求却频繁失败，典型的显存碎片化症状——大量小块空闲显存彼此不连续，凑不出一个大的连续块。这个坑在长上下文高并发场景下特别容易踩：每个请求的 KV Cache 动态增长，频繁分配和释放，很快就把显存切得稀碎。
解决思路当时有两个方向，一是换用带显存池和分页管理的推理框架，让缓存分配走框架自己的复用机制；二是限制单请求的最大上下文长度，从源头减少极端分配。我把两个方向都做了，碎片问题基本消失。这个复盘给我的教训是：看到 OOM，先看监控确认是"总量不足"还是"分配失败"，这两个问题的解法完全不同。
6.2 事故二：压测 10 分钟"看起来很稳"是假象
第二次事故是上线后第三天才爆发的。压测阶段我用固定的 prompt 长度、固定并发压了 10 分钟，指标一片漂亮，于是在完全信任的情况下上了生产。结果运行到第三天，延迟开始周期性飙高，最后直接把服务打挂。复盘时候查到一个关键变量：实际线上的 prompt 长度分布是高度不均匀的，长文本请求会在 Prefill 阶段抢占大量显存和算力，导致后续请求集体排队。我压测时犯的错误是用"平均长度 + 固定并发"模拟，完全没覆盖这种长尾冲击。
后来我把压测方案改成三个阶段：短文本高并发、长文本中并发、长短混合的随机波动并发，每个阶段至少跑 30 分钟以上，并且关注延迟的时序曲线而不是平均值。这套方案后来帮我提前发现了至少两个类似的稳定性隐患。要记住：压测最怕的就是"测了但没测到点上"，固定长度、固定并发、短时长的压测结果，保守一定没坏处。
6.3 事故三：单机指标正常，多机部署后吞吐反而下降
第三次事故发生在想把服务从单机扩到多机的时候。单机一切正常，多机部署后总吞吐没有线性增长，反而在某些请求下变慢了。查了很久才定位到瓶颈：多机之间的通信开销超过了并行计算带来的收益。大模型推理的多机并行，本质是让多个设备分担一个矩阵运算，每算一步都要同步一次中间结果，同步频率非常高，而跨节点的通信带宽远低于设备内部互联，于是通信成了瓶颈。
这次事故让我学会了在部署前先做一个简单评估：如果模型规模在单机显存能容纳的范围内，优先单机多卡甚至单卡部署，不要为了"听起来更高级"而强行上多机；如果确实需要多机，尽量用模型分片而不是流水线的方式把通信量压低，同时在压测里专门设计跨节点场景。这个经验现在回想起来非常简单，但在当时，它让我意识到"部署架构跟着硬件带宽走"这个朴素原则的重要性。
说到最后，我还是想强调那个最开始的观察：跑通模型只是起点，把模型跑稳、跑省、跑得可度量，才是一个完整项目的真正分水岭。第 71 期讲的这条路，从编码瓶颈到显存账本，从动态调度到量化取舍，再到评测闭环和故障复盘，每一步都是在补"从模型到服务"之间缺失的那一环。如果你正在学这套系统指南，我建议你学完这一期后，亲手把自己手头某个模型的延迟指标测一遍，把 KV Cache 的显存账也算一遍——这些动作比看十篇文章都管用。
