Token越卷越猛，可智算的那些老瓶颈还没翻篇
刷到信通院那份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吞吐有关的离谱状况。
