1. 从一次线上告警说起Token 生产效率到底在优化什么凌晨两点推理集群的 P99 延迟从 800ms 飙到 4.2s值班同学在群里甩了一张监控图GPU 利用率 98%但每秒输出 Token 数反而掉了三成。这不是算力不够而是典型的 Token 生产效率塌陷——芯片在满负荷空转真正吐出来的有效 Token 却越来越少。我做了六年推理基础设施从早期单卡部署到现在的千卡集群踩过的坑基本都围绕一个核心命题如何让每一瓦电、每一块钱芯片成本产出尽可能多且稳定的 Token。这里的 Token 不只是大模型里的文本单元它已经变成衡量 AI 基础设施效率的通用货币。你去看任何一家做推理服务的团队内部考核指标里一定有单卡 Token 吞吐和每百万 Token 成本这两个数。这篇文章面向三类人一是正在做推理服务部署的工程师二是负责集群资源调度的运维同学三是需要给老板解释为什么加了卡还是慢的技术负责人。我会从芯片选型、推理引擎调优、集群调度、供电散热四个层面把 Token 生产效率这件事拆开讲透每个环节都给出可复现的参数和踩坑记录。全文基于我实际经手的几个生产集群数据做了脱敏但方法论可以直接抄。先说结论性的判断Token 生产效率不是单点优化它是一个从硅片到机柜到调度器的全栈问题。你在推理引擎里调一个 batch size可能让供电模块的温度上升 8 度进而触发降频最后 Token 吞吐反而下降。这种跨层耦合才是这件事真正难的地方。2. 芯片层算力、显存带宽与 Token 产出的真实关系2.1 为什么算力强不等于Token 多很多人选卡只看 TFLOPS这是个巨大的误区。大模型推理分两个阶段Prefill预填充阶段是计算密集型吃的是算力Decode解码阶段是访存密集型吃的是显存带宽。而 Token 生产效率主要由 Decode 阶段决定因为每生成一个 Token 都要把整个模型权重和 KV Cache 读一遍。我实测过一组数据在同一台机器上跑 7B 模型FP16 精度芯片类型标称算力显存带宽单卡 Token/sbatch1单卡 Token/sbatch32A 卡300 TFLOPS900 GB/s42680B 卡400 TFLOPS600 GB/s35510C 卡200 TFLOPS1200 GB/s58920你看算力最低的 C 卡Token 吞吐反而最高。原因很简单Decode 阶段每生成一个 Token 需要读取的字节数是固定的带宽决定了单位时间能读多少遍权重也就决定了能生成多少 Token。算力在这个阶段大部分时间是闲置的。提示选推理卡时先算你的模型在 Decode 阶段的带宽需求再去看卡的显存带宽最后才看算力。顺序反了钱就白花了。2.2 显存容量如何卡住你的并发上限显存带宽决定速度显存容量决定并发。KV Cache 是吃显存的大户它的计算公式是KV Cache 大小 2 × 层数 × 注意力头数 × 头维度 × 序列长度 × batch_size × 精度字节数以一个 13B 模型为例40 层40 个头头维度 128FP16 精度2 字节序列长度 4096单条序列 KV Cache 2 × 40 × 40 × 128 × 4096 × 2 3.35 GB也就是说光是一条 4K 上下文的请求就要占 3.35GB 显存。一张 24GB 的卡扣掉模型权重13B FP16 约 26GB得用两张卡或者量化留给 KV Cache 的空间非常紧张。这就是为什么很多团队发现卡没跑满但就是加不了并发——显存被 KV Cache 吃光了。我的做法是上 PagedAttention 类的显存管理方案把 KV Cache 按页切分碎片率能从 60% 降到 5% 以内。实测下来同样的卡并发数能提升 2.3 倍Token 吞吐直接翻倍。这个优化不需要换硬件纯软件层面就能拿到性价比极高。2.3 量化用精度换 Token 的边界在哪量化是提升 Token 生产效率最直接的手段。INT8 量化能让显存占用减半带宽压力减半Token 吞吐理论上翻倍。但这里有个边界量化会损失精度而精度损失在某些任务上会表现为生成的 Token 质量下降需要重试或人工修正反而拉低了有效 Token 产出。我做过一组对比测试用同一个模型跑代码生成任务量化方案显存占用Token/s代码通过率有效 Token 效率FP16100%10082%82INT852%18579%146INT428%31061%189注意最后一列有效 Token 效率是我自己定义的指标Token/s 乘以任务通过率。INT4 虽然原始吞吐最高但通过率掉得厉害有效效率反而不如 INT8。所以量化不是越激进越好要看你服务的任务类型。对话类任务对精度容忍度高INT4 可以上代码和数学推理类INT8 是更稳的选择。3. 推理引擎把芯片潜力榨干的调优实战3.1 推理引擎选型的三个硬指标市面上的推理引擎很多我评估时只看三个硬指标连续批处理Continuous Batching支持、PagedAttention 支持、量化内核成熟度。这三个决定了你能不能把芯片的 Token 生产效率压榨到极限。连续批处理是分水岭。传统静态批处理要等一个 batch 里所有请求都生成完才能接下一批短请求被长请求拖死GPU 利用率经常掉到 40%。连续批处理让每个请求生成完就立刻退出、新请求立刻补位利用率能稳定在 85% 以上。我实测过同一个模型同一张卡开连续批处理前后Token 吞吐差了 2.8 倍。PagedAttention 解决的是显存碎片问题前面讲过了。量化内核成熟度则决定了你敢不敢上 INT8/INT4——有些引擎的量化内核写得不好实际加速比只有 1.2 倍还不如不量化。3.2 关键参数调优batch size 不是越大越好这是我最想强调的一点。很多人以为 batch size 拉满就能最大化 Token 吞吐实际上存在一个拐点过了拐点吞吐反而下降。原因是batch size 增大单次前向的计算量增大但每个 Token 的边际收益递减同时 KV Cache 占用线性增长显存压力上升可能触发换页或 OOM。更隐蔽的是大 batch 会让单次前向耗时变长首 Token 延迟TTFT飙升用户体验崩掉。我的一般调优流程是这样的固定序列长度分布用真实流量采样从 batch8 开始每次翻倍记录每个 batch size 下的 Token/s 和 TTFT找到 Token/s 增长斜率明显变缓、且 TTFT 还在可接受范围内的点在这个点附近做细粒度扫描比如 24、32、40、48实测一个 7B 模型在 A 卡上的结果batch sizeToken/sTTFT (ms)显存占用82104538%163806252%326209874%4868015689%6465524096%拐点在 48 附近64 时吞吐已经下降TTFT 也翻倍了。最终我选的是 40留一点显存余量应对突发长序列。注意这个拐点会随模型大小、序列长度、卡型变化千万别照搬别人的数字一定要自己扫一遍。3.3 投机解码用一个小模型换 2 倍吞吐投机解码Speculative Decoding是我近一年用得最多的加速手段。原理是用一个小模型draft model先快速生成几个候选 Token再用大模型一次性验证。因为大模型验证多个 Token 的成本和生成一个差不多所以只要小模型的命中率够高整体吞吐就能大幅提升。我实测的数据7B 主模型配 0.5B draft 模型命中率 72% 时Token 吞吐提升 1.9 倍命中率 85% 时提升 2.4 倍。命中率取决于 draft 模型和主模型的分布接近程度一般同系列的小模型效果最好。这里有个坑draft 模型也要占显存和算力。如果你的卡本来就紧张加 draft 模型可能得不偿失。我的经验是显存占用在 70% 以下时上投机解码划算超过 85% 就别折腾了先把显存问题解决。4. 集群调度让 Token 产出在规模上不掉链子4.1 单机优化到顶后瓶颈转移到了哪里单卡调优做完Token 吞吐能提升 3 到 5 倍。但当你把规模扩到几十上百张卡时会发现整体吞吐并没有线性增长甚至出现加卡反而变慢的诡异现象。这时候瓶颈已经从芯片转移到了集群调度层。我遇到过最典型的问题请求分发不均。负载均衡器用的是轮询策略但每个请求的序列长度差异巨大有的 200 Token有的 8000 Token。轮询导致某些节点堆积了一堆长请求排队时间爆炸而另一些节点闲着。整体 GPU 利用率看着有 70%但有效 Token 产出只有理论值的 40%。解决办法是改成基于负载感知的调度每个节点实时上报自己的队列深度和预估完成时间调度器把新请求发给预估完成时间最短的节点。这个改动让我们的集群有效吞吐提升了 55%而且不需要加任何硬件。4.2 连续批处理在集群层面的坑单机的连续批处理很美好但集群层面会引入新问题请求在节点间迁移时KV Cache 怎么办早期我们的做法是请求一旦分配到某个节点就不再迁移但这导致节点故障时请求全部失败重试成本极高。后来改成 KV Cache 分片存储配合请求迁移故障时能把 KV Cache 一起搬走重试几乎无感。代价是引入了一层 KV Cache 的网络传输开销实测在万兆网络下迁移一个 4K 上下文的请求大约增加 120ms可以接受。另一个坑是批处理的公平性。连续批处理下长请求会一直占着位置短请求不断插队导致长请求的完成时间被无限推迟。我们后来加了优先级队列给每个请求设一个 deadline快超时的请求优先调度P99 延迟从 8s 降到了 2.3s。4.3 弹性扩缩容Token 需求波峰波谷的应对Token 需求有明显的波峰波谷白天高晚上低差两三倍很正常。如果按峰值配置资源低谷期就是纯浪费按均值配置高峰期就排队。我们的方案是分层扩缩容热层常驻实例覆盖日均需求的 60%响应延迟最低温层按需拉起覆盖到 90% 分位冷启动约 30 秒冷层峰值兜底冷启动约 3 分钟用更便宜的卡关键是温层和冷层的冷启动时间要压住。模型加载是主要耗时我们用内存映射加预加载把 7B 模型的加载时间从 45 秒压到了 12 秒。再配合请求排队时的预热用户基本感知不到扩容过程。5. 供电与散热被低估的 Token 生产效率杀手5.1 降频Token 吞吐的隐形天花板这一节是我最想写给那些机房温度一高就变慢的团队看的。GPU 有温度墙和功耗墙一旦触发就降频而降频直接表现为 Token 吞吐下降。我实测过一张标称 350W 的卡在散热良好的机柜里能稳定跑满Token/s 是 620换到散热差的机柜核心温度到 83 度触发降频Token/s 掉到 480降了 22%。更坑的是这种下降是渐进的监控上 GPU 利用率还是 98%你根本看不出问题只有对比 Token 吞吐才发现。所以我的第一条建议是把 GPU 核心温度和降频次数纳入核心监控指标和 Token 吞吐放在同一个看板上。一旦发现温度上升伴随吞吐下降先查散热别急着优化软件。5.2 供电质量对稳定性的影响供电问题比散热更隐蔽。GPU 瞬时功耗波动很大Decode 阶段相对平稳但 Prefill 阶段会有尖峰。如果电源功率余量不足或者供电线路压降大会导致 GPU 触发保护性降频甚至重启。我们的经验是电源功率按 GPU 标称功耗的 1.5 倍配置别按 1.2 倍省那点钱。另外同一路供电上不要挂太多 GPU瞬时尖峰叠加会超过线路承载。我们曾经把 8 张卡挂在同一路 30A 的电路上跑批量 Prefill 时频繁触发保护后来拆成两路就好了。还有一个细节供电模块的电容老化会导致电压纹波增大长期看会影响 GPU 稳定性。机房运行两年以上的建议定期检查供电质量用示波器看纹波超过规格就换电源模块。5.3 散热方案选型风冷、液冷还是浸没散热方案直接决定你能把 Token 生产效率压榨到什么程度。我三种都用过说说实际感受方案单机柜功率上限降频风险改造成本适用场景风冷15 kW中高低中小规模、旧机房冷板液冷50 kW低中中大规模、新建机房浸没液冷100 kW极低高超大规模、高密度风冷的问题是热空气回流机柜上层的卡总是比下层热降频不一致导致集群里各节点性能参差。我们后来用盲板封堵空位、调整风扇曲线把温差从 12 度压到了 4 度Token 吞吐的方差小了一半。冷板液冷是我目前最推荐的方案改造成本可控散热能力足够而且噪音小。浸没液冷散热最好但维护麻烦换卡要捞出来适合那种一两年不动的稳定集群。提示散热改造的投入产出比很高。我们花在液冷改造上的钱大约 8 个月就从提升的 Token 吞吐里赚回来了。6. 常见问题与排查技巧实录6.1 Token 吞吐突然下降的排查顺序线上最怕的就是吞吐突然掉。我总结了一套排查顺序按这个走基本能定位先看温度GPU 核心温度、显存温度、降频计数。温度问题占我遇到案例的 40%再看显存是否有 OOM、换页、碎片率飙升。显存问题占 25%看请求分布序列长度分布是否突变是否有异常长请求。占 20%看调度节点负载是否均衡是否有节点假死。占 10%最后看软件引擎版本、参数是否被改。占 5%这个顺序的逻辑是从硬件到软件从底层到上层先排除最容易被忽略的物理因素。6.2 常见问题速查表现象可能原因排查方法解决方向吞吐下降但利用率高降频查温度和降频计数改善散热、降功耗墙加卡不加速调度不均看各节点队列深度改负载感知调度并发上不去显存碎片看 KV Cache 碎片率上 PagedAttention首 Token 延迟高batch 过大扫 batch size 曲线降 batch、加优先级长请求拖慢整体批处理不公平看请求完成时间分布加 deadline 调度量化后质量下降量化过激对比任务通过率退回 INT86.3 几个反直觉的实操心得第一个心得别迷信峰值吞吐要看稳定吞吐。我见过太多团队把 batch size 调到极限跑分很好看但线上跑两小时就开始降频、OOM、重试实际有效吞吐还不如保守配置。我现在一律留 15% 的显存和功耗余量稳定性优先。第二个心得监控要成对看指标。单看 GPU 利用率没意义要和 Token 吞吐一起看。利用率高但吞吐低说明在做无用功利用率低但吞吐高说明优化到位了。我习惯把这两个指标画在同一张图上一眼就能看出问题。第三个心得优化要按投入产出比排序。软件优化调度、批处理、量化通常投入小见效快先做硬件优化换卡、液冷投入大后做。我一般先花两周把软件榨干再评估硬件投入这样能避免花冤枉钱。7. 一个真实集群的优化全过程复盘最后分享一个我经手的完整案例把前面讲的东西串起来。这是一个 32 卡的推理集群服务一个 13B 模型优化前日均 Token 产出 1.2 亿每百万 Token 成本 18 元。第一步做的是监控补齐。之前只有 GPU 利用率我加了 Token 吞吐、温度、降频计数、显存碎片率、队列深度五个指标。补完监控当天就发现有 6 张卡长期在降频原因是机柜下层进风被挡住。第二步是散热整改。清理进风、加盲板、调风扇曲线降频卡从 6 张降到 0 张。这一步没动任何软件Token 吞吐就涨了 18%。第三步是推理引擎调优。开连续批处理、上 PagedAttention、扫 batch size 到 40、加投机解码。这一套组合拳下来单卡 Token 吞吐从 380 涨到 890翻了 2.3 倍。第四步是集群调度改造。改成负载感知调度加优先级队列集群有效吞吐又涨了 55%P99 延迟从 6.8s 降到 2.1s。第五步是弹性扩缩容。上分层扩缩容低谷期关掉 40% 的实例成本直接降下来。最终结果日均 Token 产出从 1.2 亿涨到 4.7 亿每百万 Token 成本从 18 元降到 4.3 元。整个优化周期六周硬件投入只有散热整改那部分其余全是软件和调度层面的改动。这个案例最想说明的一点是Token 生产效率优化不是买更贵的卡而是把现有资源的每一分潜力都榨出来。芯片、引擎、调度、散热四个层面任何一个有短板整体效率就上不去。而补齐短板的过程往往不需要花大钱需要的是系统性的排查和调优。我个人在实际操作中的体会是这套方法论里最值钱的不是某个具体参数而是成对看指标、按投入产出比排序、留余量保稳定这三个习惯。参数会随硬件和模型变化习惯不会。你把这三个习惯养成了换任何芯片、任何模型都能快速找到优化路径。