别被纸面指标迷惑：推理集群的隐式短板

做过大模型线上推理的朋友应该深有体会，很多时候监控面板看GPU SM利用率还留有富余，但是整体 token吞吐上不去、P99时延随机飘高。绝大多数人的第一反应，是不是算力不够，要不要加卡扩容。实际定位下来，大量case并不是计算资源瓶颈，而是典型 访存密集型场景带来的带宽墙。

Decode阶段每一步自回归生成，要反复读写 KV‑Cache缓冲区。上下文越长，缓存占用线性膨胀。如果没有做内存池管控，长短请求混部跑业务，会话不断销毁重建，显存内部就会产生大量内存碎片。哪怕整体显存占用率看着尚可，新请求申请连续内存块失败，就会触发GPU显存swap降级。一旦swap跑起来，整个节点时延直接雪崩，这种属于很难复现的偶现坑，有时候压测环境看不出来，上生产才开始暴雷。

很多开源推理框架默认配置是开箱即用，但不会帮你处理碎片问题。滑动窗口、KV量化是目前行业普遍采用的缓解手段，但这里有个现实trade‑off： 软件优化属于妥协方案，不是根治手段。KV量化会引入embedding语义损失；滑动窗口直接丢弃远端上下文，长文档业务场景会出现信息丢失。PPT文档里面演示效果很漂亮，到生产环境各种边角case就冒出来，属于很常见的PPT战神现场。

传统调度器，对在线推理业务并不友好

现在不少智算平台调度内核，底子继承自离线训练任务调度逻辑。

训练任务一般是大包稳态任务，任务启动之后长时间跑批量计算；在线token推理完全另一个画风：请求碎片化，流量潮汐效应明显。短prompt Prefill任务、上万token长上下文Decode任务挤在同一个节点池。

长会话死死占住KV缓存资源池，短请求排队等待资源释放，发生 资源饥饿现象。外层负载均衡组件仅仅统计任务数量做轮询分发，不去感知每个任务实际token量级，就会出现一个很迷惑现象：集群整体负载看起来均衡，但是节点内部资源已经严重倾斜，也就是大家常说的伪均衡。

异构混布集群问题会进一步放大这个现象。不同代际GPU，HBM带宽、显存容量、NVLink互联能力参差不齐。如果调度层缺少token量级感知，强卡摸鱼空转，弱卡被打满，整体集群有效算力打折扣。很多团队只盯着TFLOPS浮点算力指标评估集群能力，忽略带宽这一块硬约束。

落到我们开发层面该怎么看待这件事

普通开发者大多不会从零自研整套智算底座，但是做Agent应用、RAG业务开发，底层约束绕不开。

写业务代码的时候，不少图省事的开发，直接把整篇文档一股脑塞进上下文，迷信超大上下文等于更强模型能力。实际上每增加一个token，都要付出Prefill计算开销以及Decode阶段反复读写KV缓存的代价。遇到超长文档场景，优先做分块、摘要、检索过滤，而不是暴力全量灌入prompt，把全部压力甩给推理底层，属于典型上层偷懒，底层背锅。

日常调参，不要只盯着temperature、top‑k这些模型生成参数，心里要有数，分清 Prefill开销与Decode开销差异。Prefill偏向计算密集，Decode偏向访存密集，两套资源模型完全不一样。生产环境可行的手段，长短请求做物理隔离部署，配置单会话最大上下文阈值，开启KV缓存动态回收策略，必要的时候引入碎片整理逻辑。

这份信通院报告，不会给你可以直接复制粘贴的代码片段，更多是产业视角的现状梳理。模型迭代节奏飞快，但是硬件带来物理约束，软件优化只能缓解，没法彻底消除。

今天运气还算不错，改调度相关逻辑没有陷入无尽debug泥潭，调完参数简单跑一轮压测，P99抖动明显收敛。没有什么惊天大改造，就是日常迭代里面一次平平无奇的微调。有做推理部署这块的朋友，可以聊聊你们线上遇到过哪些稀奇古怪的时延抖动问题。