算力这件事平时不显山不露水一旦模型规模往上走它立刻从后台成本项变成决定产品能不能上线的硬约束。我最早接触大模型推理部署的时候天真地以为把权重加载进去、接口调通就算完事结果第一次压测就被现实教育了并发一上来响应时间从几百毫秒飙到十几秒显存告警、请求排队、超时重试互相叠加整个服务像堵死的高架桥。后来花了很长时间才想明白大模型服务的核心矛盾不在能不能跑而在单位算力能稳定扛住多少有效请求。这篇内容就围绕这个矛盾展开把我在推理侧做算力优化时踩过的坑、试过的方案、最后沉淀下来的判断标准尽量完整地讲清楚。适合已经能把模型跑起来、但被成本和延迟卡住的中高级开发者也适合刚接触推理服务、想提前建立整体认知的朋友。1. 先把算力挑战翻译成工程语言很多人一谈大模型算力就笼统地说卡不够太贵了这种描述没法指导任何决策。我在实际项目里做的第一件事是把模糊的焦虑拆成可度量的指标否则优化永远无从下手。1.1 算力压力到底体现在哪几个维度大模型推理的算力消耗落到工程上其实是四类压力叠加它们的优化手段完全不同混在一起谈就会互相打架。第一类是显存压力。模型权重本身占一大块以常见的百亿参数级别模型为例FP16 精度下光权重就要二十多 GB再加上 KV Cache、激活值、框架自身的开销一张中等规格的加速卡很容易被吃满。显存一旦不够要么降精度要么减并发要么换硬件三条路各有代价。第二类是计算压力也就是单位时间内的浮点运算量。它决定了单条请求的推理耗时下限跟模型层数、隐藏维度、序列长度强相关。这部分靠软件优化能挤出的空间有限更多是选型和量化的问题。第三类是带宽压力包括显存带宽和卡间互联带宽。自回归生成是逐 token 输出的每一步都要把权重读一遍所以很多时候瓶颈不在算力而在搬运。这也是为什么批处理能显著提升吞吐——一次搬运服务多条请求。第四类是调度压力。请求长短不一、到达不均匀如果调度策略粗糙就会出现长请求占着资源、短请求干等的情况整体吞吐被拖垮。提示做优化前先给这四类压力各找一个可观测指标比如显存占用峰值、单 token 延迟、卡间通信耗时占比、请求排队时长。没有度量就没有优化这一步千万别跳。1.2 为什么加卡往往不是第一选择遇到算力不足最直觉的反应是加机器。我见过不少团队一上来就扩容结果成本翻倍、延迟没降多少。原因在于如果瓶颈是调度或批处理策略加卡只是把同样的低效复制了更多份。举个我实际遇到的场景某服务单卡吞吐上不去团队直接扩到四卡发现总吞吐只涨了不到一倍。排查后发现是请求分发不均部分卡空转、部分卡排队。后来改成更细粒度的负载均衡同样的硬件吞吐提升了近七成。这说明先诊断瓶颈类型再决定是优化软件还是加硬件顺序反了就是白花钱。我的经验判断顺序是先看调度和批处理有没有做对再看量化能不能上再看 KV Cache 管理是否合理最后才考虑扩容或换卡。前几步几乎都是纯软件投入性价比远高于买硬件。1.3 一个可复用的容量估算思路容量规划不能拍脑袋。我常用的粗算方法是先测出单条请求在目标序列长度下的平均延迟和显存占用再根据业务可接受的 P99 延迟反推单卡能承载的并发数最后乘以卡数并留出安全余量。这里有个容易忽略的点平均延迟好看不代表体验好。大模型请求的延迟分布往往长尾很重P99 可能是平均值的数倍。所以容量估算必须盯 P99 甚至 P999而不是平均值。我一般会留 30% 到 40% 的余量来吸收长尾和突发流量余量留太少高峰期就会雪崩。2. 批处理与调度不花钱提升吞吐的主战场如果说算力优化有性价比排名批处理调度绝对排第一。它不需要换硬件、不需要重训模型纯靠策略就能把吞吐拉高一大截但也是最容易被做粗糙的地方。2.1 连续批处理为什么比静态批处理强早期的推理服务多用静态批处理攒一批请求一起送进模型等整批全部生成完再返回。问题很明显——一批里只要有一条请求生成长其他短请求就得陪着等GPU 利用率在长尾阶段急剧下降。连续批处理也叫迭代级调度的思路是每生成一个 token 就重新组批已经结束的请求立刻退出、新到的请求立刻补位。这样 GPU 几乎一直在处理满员的批次利用率显著提升。我实测下来在请求长度差异大的场景里连续批处理相比静态批处理吞吐能提升两到三倍长尾延迟也明显改善。实现上要注意连续批处理对 KV Cache 的管理要求更高因为不同请求的缓存要能动态拼接和释放。这也是为什么它通常和分页式 KV Cache 管理配合使用。2.2 调度策略里的几个关键取舍调度不是能批就批这么简单里面有几个必须想清楚的取舍。批大小与延迟的权衡批越大吞吐越高但单条请求的排队和计算等待也越长。业务对延迟敏感时要设一个批大小上限宁可牺牲一点吞吐。长短请求的隔离长请求会长时间占用资源如果和短请求混在一起短请求的 P99 会被拖累。我的做法是给长短请求设不同的队列或优先级或者对超长请求单独限流。抢占与公平性资源紧张时是否允许高优先级请求抢占低优先级请求的批次位置这涉及业务语义得和产品侧对齐不能纯技术决定。下面这张表是我在不同业务场景下的调度参数取向供参考业务特征批大小策略长短请求处理优先级设计在线对话延迟敏感中等上限保延迟严格隔离按用户等级分级批量生成吞吐优先尽量打满可混合单一优先级混合负载动态调整队列隔离按任务类型分级2.3 实测中容易翻车的细节连续批处理听起来美好落地时有几个坑我踩过。一是批大小抖动。请求到达不均匀时批大小忽大忽小反而导致 GPU 利用率波动。解决办法是设一个短暂的组批窗口比如几毫秒让请求稍微攒一攒再组批平滑度会好很多。二是KV Cache 碎片。动态进出批次会让缓存频繁分配释放如果不做池化管理很快就会出现显存碎片最终 OOM。分页式管理基本能解决这个问题但要注意页大小别设得太小否则管理开销反而上升。三是超时与重试的连锁反应。调度不当导致延迟升高客户端超时重试重试请求又加重负载形成正反馈雪崩。所以调度层必须配合限流和熔断不能裸奔。3. 量化与精度在效果和成本之间找平衡点量化是降算力成本最直接的手段之一但它不是精度越低越省钱这么简单里面有一堆效果和工程上的细节。3.1 不同量化位数的实际影响我做过一轮系统的对比测试把同一个模型分别量化到不同精度观察效果损失和资源节省的关系。结论大致是从 FP16 降到 INT8效果损失通常很小资源节省明显是性价比最高的一档再往 INT4 走资源节省继续增加但效果损失开始变得不可忽略尤其在需要精细推理的任务上。需要强调的是量化对效果的影响高度依赖任务类型和校准数据。同样是 INT4有的任务几乎无损有的任务明显退化。所以不能照搬别人的结论必须用自己的业务数据做评测。精度档位显存节省相对 FP16典型效果影响适用场景FP16基准无效果优先INT8约一半很小大多数在线服务INT4约四分之三中等需评测成本敏感、任务宽容混合精度视策略而定可控精细调优3.2 校准数据怎么选才不翻车量化尤其是低位量化需要校准数据来确定数值范围。校准数据选得不对量化后的模型在真实输入上会严重失真。我的做法是校准数据必须来自真实业务分布覆盖主要输入类型和长度区间不能随便拿一批通用语料凑数。曾经有个项目图省事用了通用数据校准上线后特定类型的输入效果断崖式下跌回滚重做花了不少时间。后来固定流程从线上采样、按类型分层、保证每类都有足够样本问题就再没出现过。另外校准样本量不是越多越好几百到上千条覆盖充分的样本通常就够太多反而拖慢流程且收益递减。3.3 量化之外的精度优化手段除了权重量化还有几个常被忽略的精度优化点。KV Cache 量化缓存占用在长序列场景下非常可观对缓存做量化能省下不少显存且对效果影响通常比权重量化更小值得优先尝试。激活值量化难度更高收益也更大但工程复杂度上升适合有专门优化团队的情况。算子融合与内核优化不改精度纯靠更高效的算子实现来提速属于免费的性能提升前提是所用框架支持。注意任何量化方案上线前必须用业务评测集做 A/B 对比指标要覆盖效果和延迟两方面。只看资源节省不看效果等于给自己埋雷。4. 显存与缓存管理被低估的吞吐杠杆很多人把显存当成够用就行的硬指标其实显存管理做得好不好直接决定了能承载多少并发是吞吐的隐形杠杆。4.1 KV Cache 为什么会成为瓶颈自回归生成时每生成一个 token 都要用到之前所有 token 的键值缓存。序列越长缓存越大。在长对话、长文档场景下KV Cache 的占用甚至能超过模型权重本身。传统做法是给每条请求预分配一块连续显存按最大可能长度预留。问题是实际长度往往远小于最大值大量显存被浪费并发数上不去。这就是为什么长序列场景下显存明明看起来够并发却死活提不上去。4.2 分页式缓存管理的核心思路分页式管理的思路借鉴了操作系统的虚拟内存把缓存切成固定大小的页按需分配物理上不要求连续。这样显存利用率大幅提升碎片问题也基本消除。实际收益有多大我在一个长对话场景里做过对比改用分页管理后同等显存下支持的并发数提升了接近一倍长尾延迟也更稳定。代价是管理逻辑更复杂需要框架层面支持自己手写容易出 bug。4.3 缓存复用与淘汰策略除了分页还有两个能进一步榨取显存价值的手段。前缀缓存复用很多请求共享相同的前缀比如系统提示词、固定上下文。把这部分缓存复用起来能省下大量重复计算和显存。在线服务里这个优化收益非常可观尤其是系统提示词很长的场景。缓存淘汰策略显存紧张时按什么规则淘汰缓存常见的有 LRU 和按优先级。我的经验是结合请求状态来定——已经生成很多 token 的请求其缓存价值更高不该轻易淘汰刚起步的请求缓存可以优先释放。这里有个实操心得淘汰策略要和调度策略联动设计单独调任何一个都容易顾此失彼。比如调度层知道哪些请求快结束了就应该提前通知缓存层准备回收而不是等缓存层自己发现。5. 从压测到上线把优化落到可验证的流程里优化做得再多没有可靠的验证流程上线就是赌博。这一节讲我怎么把优化效果量化并安全地推到线上。5.1 压测方案怎么设计才有意义压测最容易犯的错是用均匀请求压。真实流量从来不是均匀的长度分布、到达间隔、并发模式都有明显特征。用均匀请求压出来的漂亮数字上线后往往对不上。我的压测方案会尽量还原真实分布请求长度按线上统计分布采样到达间隔模拟真实峰谷还要专门构造突发流量场景测试系统的弹性。压测指标除了吞吐和延迟还要盯显存峰值、错误率、排队时长这些过程指标它们能帮你定位瓶颈在哪。另外压测要分阶段做先单请求基线再逐步加并发找到拐点最后在拐点附近做长时间稳定性测试。拐点位置很关键它告诉你系统的真实容量边界。5.2 灰度上线与回滚预案优化上线我坚持灰度先小流量验证观察效果指标和延迟指标是否与压测一致再逐步放量。灰度期间要重点看两类信号一是效果有没有退化量化类优化尤其要看二是延迟分布有没有异常长尾。回滚预案必须提前准备好而且要在灰度前就验证过回滚流程可用。我见过回滚脚本平时没测过、真出事时跑不起来的案例那场面相当被动。回滚要能做到分钟级切换配置和模型版本都要能快速还原。5.3 上线后持续观测的几个关键指标上线不是终点。我日常盯的指标有这么几类吞吐每秒有效请求数、延迟分位数P50/P95/P99、显存占用趋势、缓存命中率、错误率和超时率。其中缓存命中率特别值得关注它直接反映前缀复用和缓存管理是否有效命中率下降往往预示着流量结构变化或配置漂移。还有显存占用趋势缓慢上涨通常意味着有泄漏或碎片累积早发现早处理别等 OOM 了才查。6. 几个反直觉的经验判断做了这么多轮优化有些结论和直觉相反单独拎出来说说可能对正在做类似事情的同行有点用。第一个反直觉吞吐和延迟不总是对立的。在批处理没做好的情况下提升批处理效率能同时改善两者——因为资源利用率上去了排队反而少了。真正对立的是批大小和单请求延迟这个要分开看。第二个反直觉最贵的优化往往不是最有效的。换更高端的卡、上更复杂的分布式方案收益可能不如把调度和缓存管理做扎实。软件层的优化空间比很多人想象的大。第三个反直觉效果评测比性能优化更耗精力。量化、缓存这些优化做完验证效果没退化往往要花掉大半时间。但这部分不能省省下来的时间迟早要加倍还回去。我个人在实际操作中的体会是大模型算力优化没有一招鲜它是一个度量—定位—优化—验证的循环每一轮循环都要靠数据说话。与其追新框架、新技巧不如把基础的可观测性和验证流程搭扎实这样任何新优化进来都能快速判断值不值得用。最后分享一个小技巧每次优化只改一个变量记录前后指标坚持一段时间你会发现自己对系统的理解会有一个质的飞跃比看十篇教程都管用。