1. 从“Token 生产效率”说起：一个被低估的全栈命题

“Token 生产效率”这个词，第一次听到的人多半会愣一下——Token 不是大模型里的文本计量单位吗，怎么还跟芯片、供电、散热扯上关系了？我刚开始接触这个方向时也有同样的困惑。但真正做过一轮推理服务部署之后你就会明白：Token 的产出速度，从来不是模型单方面决定的，它是从硅片到机房、从调度器到业务层的一条完整链路共同作用的结果。任何一个环节掉链子，最终体现出来的都是“每秒吐字变慢”“首字延迟飙升”“单位成本下不去”。

这篇文章想聊的，就是这条链路上每一个关键节点的优化思路。核心关键词包括Token、芯片、推理引擎、集群调度、供电散热，我会把它们串成一条线来讲，而不是孤立地谈某一层。适合的读者是：正在做推理服务部署的工程师、负责算力集群运维的同学、以及想搞清楚“为什么我的模型跑得比别人慢”的算法同学。哪怕你只是刚接触这个概念，我也会尽量用生活化的类比把原理讲透。

先说一个我自己的观察：很多人优化 Token 生产效率，第一反应是换更强的卡、上更大的显存。这没错，但往往投入产出比很低。真正高效的优化，是先搞清楚瓶颈在哪一层——是芯片算力没吃满？是推理引擎的批处理策略太保守？是集群调度把请求打散了？还是机房供电和散热限制了芯片的持续输出？这四层里，任何一层的短板都会让其他层的投入打水漂。下面我按“芯片—引擎—调度—基础设施”的顺序，逐层拆解。

2. 芯片层：Token 产出的物理起点

2.1 为什么芯片决定了 Token 生产的“天花板”

Token 的生产，本质上是矩阵乘法和注意力计算在硬件上的反复执行。芯片的算力、显存带宽、显存容量这三个指标，直接决定了单卡每秒能产出多少 Token。我习惯用一个类比：算力像是工厂的机器数量，显存带宽像是传送带速度，显存容量像是仓库大小。机器再多，传送带跟不上，原料就送不进去；仓库太小，稍微大一点的模型就装不下，只能拆开跑，效率立刻打折。

具体到参数上，以常见的推理场景为例，一个 7B 参数的模型在 FP16 精度下大约需要 14GB 显存，加上 KV Cache 和中间激活值，实际占用会到 16-18GB。如果你的卡只有 16GB 显存，那就只能靠量化或者分片来跑，而量化本身会带来精度损失和额外的反量化开销。所以选芯片时，显存容量要留出至少 30% 的余量，这是我踩过坑之后的经验——把显存用到 95% 以上，一旦并发上来，KV Cache 一涨就直接 OOM，服务雪崩。

2.2 算力、带宽、容量：三个指标的取舍逻辑

很多人看芯片只看 TFLOPS，这其实是个误区。推理场景下，显存带宽往往比峰值算力更关键，因为大模型推理是典型的“内存墙”问题——计算单元经常在等数据从显存搬过来。我做过一个粗略的测算：一个 7B 模型生成一个 Token，需要读取大约 14GB 的权重数据（FP16），如果显存带宽是 1TB/s，那么理论上每秒最多生成约 70 个 Token。这就是为什么很多老卡算力不低，但 Token 产出速度上不去——带宽卡住了。

所以选型时的优先级，我的建议是：显存容量 > 显存带宽 > 峰值算力。容量决定你能不能跑，带宽决定你跑多快，算力决定你批量处理时的上限。当然，如果预算充足，三者兼得最好。另外要注意芯片的互联能力，多卡推理时卡间通信带宽不够，张量并行的效率会急剧下降，这时候再多的算力也是浪费。

2.3 芯片选型的实操清单

下面这张表是我在实际项目中总结的选型对照，供参考：

提示：芯片选型不是越新越好，而是要和你的模型规模、并发量、预算匹配。小模型跑在超大卡上，算力利用率可能只有 10%，纯属浪费。

3. 推理引擎层：把芯片算力“榨干”的关键

3.1 推理引擎到底在做什么

芯片是硬件，推理引擎就是让硬件真正跑起来的软件层。它的核心任务可以概括为三件事：把模型图优化成硬件友好的形式、把请求组织成高效的批、把显存管理得井井有条。我见过太多团队，卡买得很贵，但推理引擎用的是最朴素的逐条推理，结果 GPU 利用率长期在 20% 以下，Token 产出速度自然惨不忍睹。

推理引擎的优化手段，主要围绕几个方向：算子融合（把多个小算子合并成一个大算子，减少 kernel 启动开销）、量化（用 INT8/INT4 降低显存占用和带宽压力）、批处理（把多个请求合并成一个 batch 一起算）、KV Cache 管理（避免重复计算历史 Token 的注意力）。这些手段叠加起来，Token 产出效率提升三五倍是很常见的。

3.2 批处理策略：连续批处理为什么重要

传统的静态批处理，是等一批请求凑齐了再一起算，算完再返回。问题是每个请求的生成长度不一样，短的早就结束了，长的还在跑，短请求的槽位就空着浪费。连续批处理（Continuous Batching）的思路是：只要有请求结束，立刻把新请求塞进空出来的槽位，让 GPU 始终处于满载状态。这个策略对 Token 生产效率的提升非常明显，尤其是在请求长度差异大的场景下。

我实测过一个对比：同样的硬件，静态批处理下 GPU 利用率约 45%，换成连续批处理后提升到 80% 以上，单位时间 Token 产出量翻了将近一倍。代价是调度逻辑更复杂，对显存管理的要求更高，但收益完全值得。

3.3 量化：用精度换效率的边界在哪

量化是另一个提升 Token 生产效率的利器。把 FP16 降到 INT8，显存占用减半，带宽压力减半，理论上 Token 产出速度能提升接近一倍。但量化不是免费的午餐，精度损失在长文本生成和复杂推理任务上会明显放大。我的经验是：对话类、摘要类任务，INT8 量化基本无感；代码生成、数学推理这类对精度敏感的任务，要谨慎，最好做一轮效果对比再决定。

还有一个容易被忽略的点：量化后的反量化操作本身也有开销。如果推理引擎对量化支持不好，反量化可能吃掉一部分收益。所以选推理引擎时，要看它对量化的支持是不是原生的、有没有针对性的 kernel 优化。

3.4 推理引擎选型的几个考量

市面上推理引擎不少，选型时我主要看四点：对目标模型架构的支持程度、批处理和量化的成熟度、显存管理的精细度、以及社区活跃度。有些引擎对小模型优化得很好，但一上大模型就拉胯；有些引擎功能全但配置复杂，调优成本高。没有万能的选择，关键是对上你的实际场景。我一般会先用小流量做 A/B 测试，对比不同引擎在真实请求分布下的 Token 产出速度和延迟表现，再决定用哪个。

4. 集群调度层：让每一份算力都不闲着

4.1 调度为什么会影响 Token 生产效率

单卡优化得再好，如果集群调度拉胯，整体效率照样上不去。调度层的核心问题是：如何把请求分配到最合适的节点上，让每张卡都保持高利用率，同时不让任何一张卡过载。这听起来简单，做起来很难，因为请求的长度、优先级、到达时间都是动态变化的。

我遇到过最典型的问题，是调度器把长请求和短请求混在一起，导致长请求占着卡不放，短请求排队等半天。后来改成按预估长度分组调度，短请求走短请求的池子，长请求走长请求的池子，整体吞吐量立刻上来了。这个思路其实就是请求分级 + 资源隔离，让不同特征的请求各得其所。

4.2 负载均衡与弹性伸缩的配合

负载均衡的目标是让每张卡的负载尽量均衡，但“负载”怎么定义很关键。如果只看请求数量，那长请求和短请求的负载差异就被忽略了。更合理的做法是按预估的计算量来均衡，比如用请求的 prompt 长度加上预估生成长度作为权重。这样调度器才能做出真正均衡的决策。

弹性伸缩则是应对流量波动的利器。流量高峰时自动扩容，低谷时缩容，既保证 Token 产出速度，又控制成本。但伸缩有个坑：冷启动时间。新节点从拉起容器到能真正服务，可能需要几十秒甚至几分钟，这段时间请求会堆积。所以伸缩策略要提前触发，不能等队列满了才扩。我一般会设置一个水位线，队列长度超过阈值就提前扩容，留出缓冲时间。

4.3 调度策略的实操建议

注意：调度策略没有银弹，一定要结合你的真实请求分布来调。上线前用历史流量做回放测试，比拍脑袋强得多。

5. 供电与散热：被忽视的“持续输出”保障

5.1 为什么供电散热是 Token 生产效率的一部分

这一层最容易被忽略，但它直接决定了芯片能不能持续跑在高性能状态。芯片在高负载下功耗会飙升，如果供电跟不上，芯片会降频；如果散热跟不上，温度一高也会降频。降频意味着什么？意味着你花大价钱买的算力，实际只能用一半。我见过一个机房，夏天的时候推理速度比冬天慢 20%，查了半天才发现是散热余量不足，芯片在高温下自动降频了。

所以供电和散热不是“配套设施”，而是 Token 生产效率的保障层。设计集群时，供电容量要按芯片峰值功耗的 1.2-1.5 倍来配，散热能力要能覆盖持续满载的发热量，而不是只看瞬时峰值。

5.2 供电设计的关键参数

供电这块，核心是功率密度和冗余。单机柜的功率密度越来越高，传统机柜可能只能支撑 5-10kW，而高密度推理集群可能需要 20-40kW 甚至更高。如果机房基础设施跟不上，就只能降低部署密度，间接影响整体 Token 产出能力。

冗余方面，我建议供电模块做 N+1 冗余，避免单点故障导致整柜掉电。同时要监控每路供电的负载，避免某一路过载。这些细节平时看不出价值，一旦出问题就是大面积服务中断。

5.3 散热方案的取舍

散热方案主要有风冷和液冷两大类。风冷成本低、维护简单，但散热能力有限，适合中低功率密度；液冷散热能力强，适合高密度集群，但成本和维护复杂度都更高。我的经验是：单柜功率超过 15kW，就该认真考虑液冷了，否则风冷很难压住温度，芯片降频会成为常态。

除了方案选择，散热设计还要注意气流组织。冷热通道分离、避免热风回流，这些基础工作做到位，能显著提升散热效率。我见过一些机房，设备本身没问题，但气流组织混乱，导致局部热点，芯片频繁降频，Token 产出速度忽高忽低。

5.4 监控与告警：让问题早发现

供电散热的问题，往往是渐进式的，不会一下子爆发。所以监控很重要。我一般会盯几个关键指标：芯片温度、芯片频率、单柜功耗、进风口温度。芯片温度持续接近阈值、频率频繁波动，都是散热不足的信号。提前发现，提前调整，比等到服务变慢再排查要主动得多。

6. 常见问题与排查技巧实录

6.1 Token 产出速度突然下降，怎么排查

这是最常见的问题。我的排查顺序是：先看芯片频率和温度，再看推理引擎的批处理状态，最后看调度队列。如果芯片频率掉了，多半是供电散热问题；如果频率正常但 GPU 利用率低，多半是批处理没做好或者请求太少；如果队列堆积但 GPU 没吃满，多半是调度策略有问题。按这个顺序走，基本能定位到问题层。

6.2 显存溢出（OOM）的预防

OOM 是推理服务的常见故障。预防的核心是控制并发量和 KV Cache 上限。我一般会设置一个最大并发数，超过就排队，而不是无限接收。同时给 KV Cache 设一个上限，超了就淘汰最老的请求。这样虽然会牺牲一点吞吐，但能保证服务稳定，不会因为 OOM 整体崩掉。

6.3 量化后效果变差的应对

量化后效果变差，先别急着放弃量化。可以尝试混合量化：对精度敏感的层保持 FP16，其他层用 INT8。或者用更精细的量化方法，比如 GPTQ、AWQ 这类，比朴素的 round-to-nearest 效果好很多。如果还是不行，那就说明这个任务确实对精度敏感，老老实实用 FP16 吧。

6.4 多卡并行的效率问题

多卡并行时，如果卡间通信成为瓶颈，效率会大打折扣。排查时重点看通信时间占比，如果通信占了总时间的 30% 以上，就要考虑优化并行策略了。可以尝试调整张量并行的切分方式，或者改用流水线并行，减少通信频率。另外，确保卡间互联用的是高速通道，别用低速链路拖后腿。

6.5 常见问题速查表

7. 我个人的一些实操体会

做 Token 生产效率优化这几年，最大的体会是：不要孤立地看任何一层。芯片再好，推理引擎不行也是白搭；引擎调得再优，调度拉胯照样浪费；前面都做好了，供电散热跟不上，芯片一降频全白费。这是一个系统工程，需要全栈视角。

另一个体会是：优化要有数据支撑，别凭感觉。我见过太多团队，凭直觉换硬件、调参数，结果钱花了效果没出来。正确的做法是先建立监控体系，把每一层的指标都采集起来，找到真正的瓶颈，再针对性优化。这样投入产出比最高。

最后分享一个小技巧：做优化时，先做“减法”再做“加法”。先把明显的浪费去掉——比如空闲的卡、低效的批处理、不合理的调度，这些往往能带来立竿见影的提升。等这些都优化完了，再考虑加硬件、换引擎这些“加法”。很多时候，减法做完，你会发现根本不需要加法。

这个方向后续还可以往自适应调度和动态量化两个方向扩展。自适应调度是根据实时负载自动调整调度策略，动态量化是根据请求特征动态选择精度。这两个方向都还在演进中，有兴趣的同学可以持续关注。