刷到信通院那份 token 相关的智算报告的时候，我正在后台盯监控。

屏幕上面 GPU 利用率上蹿下跳，一会冲到 90 多，又猛地掉下去一大截，一堆尖峰毛刺来回蹦。说实话第一眼看报告标题还以为又是一份满是套话的行业文档，往下翻才发现聊的都是线上跑服务天天要碰的糟心事。

很多人看大模型，第一反应就是看参数多大，各个榜单跑分多少。但是做推理运维那套视角完全不一样，不看什么评测得分，眼里全是 token 吞吐、单 token 延迟、QPS 乱跳、显存占比，还有那个折磨人的 KV‑Cache 命中率。

讲实话 KV‑Cache 真算是推理场景头号吞显存大户。自回归生成每跑一轮，前面一大段上下文全部要堆在显存里。上下文窗口一开大，缓存占用直接线性往上堆。一旦显存顶不住，开始往内存 swap，那延迟直接原地爆炸。我自己踩过这个坑，当时定位半天，一开始还以为是网络出问题，排查半天才发现是 KV 缓存溢出触发置换。

线上环境根本不是实验室那种稳定满负载状态。流量一阵一阵的，突发请求涌过来，瞬间就把集群干到压力高点。这时候就会出现很迷惑的现象：GPU 算力还剩不少余量，显存带宽先顶不住了，直接撞带宽墙。很多人只盯着 TFLOPS 浮点算力，忽略带宽约束，到生产环境就踩坑。

现在市面上不少智算集群调度器，底子还是给离线训练写的逻辑。对付在线推理就有点水土不服。推理服务是 7×24 小时常驻，请求乱七八糟混在一起：有的 prompt 很短几下就完事，有的上万 token 长文档慢慢跑。

最怕就是长上下文任务死死占住 KV 缓存池，把显存资源吃走，一堆短请求在后面排队干等着，活生生资源饿死。隔离没做好，业务之间互相内卷，一个异常请求拖累整个节点，这种情况并不少见。

还有混布集群的算力碎片化问题。一堆不同型号 GPU 混在一起，显存、带宽、卡间互联速度参差不齐。如果负载均衡还傻乎乎按任务数轮询分发，不去感知每个任务实际 token 体量，结果就是一部分节点忙到冒烟，另一部分摸鱼划水，看着负载数字均衡，实际上是假均衡。

现在圈内各种花样优化：动态 KV 淘汰、滑动窗口、KV 量化、prefill 和 decode 拆开跑。但这些都不是什么万能特效药，每一个优化都有取舍。比如 KV 量化会轻微损失语义；滑动窗口直接扔掉早期 token，长文档场景就会丢信息。PPT 演示里效果看着很美，上生产各种边角 case 就冒出来，所谓 PPT 战神，大概就是这个意思。

咱们普通开发者绝大多数不会自己从头撸一套智算底座。但是做应用、写 Agent，这些底层约束绕不开。

写 Agent 的时候不少朋友图省事，文档不管长短全部一股脑塞上下文里，迷信超大窗口就是强能力。但现实是每多出来一个 token 都是实打实成本。prefill 做批量计算，decode 反复读写 KV 缓存。遇到长文档优先 RAG 分块摘要，别暴力全量往 prompt 里怼，把压力全部甩到底层，纯粹是偷懒。

平时调参别光盯着 temperature、top‑k，心里最好大概估一下单次请求 token 量级，分得清 prefill 开销和 decode 开销。

这份报告不会丢给你几段可以直接复制粘贴的代码，更多是产业视角。模型版本不停迭代更新，但硬件限制、调度缺陷、缓存带来的麻烦，不会跟着版本更新自动消失。

看完这份资料，我回去调了下自己服务，改了单实例允许的最大上下文，加了一层简单限流，防止某条超长请求直接把节点打崩。也就这点改动，算不上什么大优化。

感兴趣的可以聊聊你们线上碰到过哪些跟 KV 缓存、token 吞吐有关的离谱状况。