从Token计量看智算基建：算力堆得再多不等于服务好

jinchanchan

今天看到信通院最新发布的《面向词元(Token)服务的智算基础设施发展研究报告》，刚好趁着摸鱼间隙翻完一遍。平时做推理服务，我们大多盯着TTFT、TBT这些业务指标，这份报告跳出模型本身，站在基础设施视角聊Token作为计量单元这件事，有些观点挺戳现实痛点。不知道大家有没有留意，早些年算力租赁基本按卡按时长计费。不管你是跑满GPU，还是空转挂机，一小时就收一小时的钱。现在越来越多业务转向按Token计费，把词元消耗量作为结算口径，理论上做到按量付费。想法很美，但落地的时候坑一点不少。

这里说的Token，不单单是输入输出文本词元，多模态场景图像、音频同样会换算成等效token。不同厂商之间换算口径各行其是，没有统一标准，这就带来第一个现实问题：跨平台做成本对比基本属于瞎子摸象，A厂商1000token和B厂商1000token，消耗的硬件资源可能完全不是一个量级。很多小伙伴做成本测算直接抄API文档的单价，很容易踩这个隐形坑。

推理集群里面，Token吞吐不等于GPU算力很多新人看监控面板，第一反应就是看GPU利用率。只要SM利用率上不去，第一判断就是资源没吃满，要优化并行、加大batch。但线上推理属于典型访存密集业务，尤其decode阶段，每生成一步token，就要反复读写KV‑Cache。经常会碰到一种诡异现象：GPU还有大量空闲算力，显存带宽先撞天花板，整个服务吞吐量直接被带宽墙锁死。
这个问题长短上下文混部场景会进一步放大。短请求prefill重，长会话疯狂吃KV缓存。当一堆长短请求挤在同一个节点，很容易出现KV‑Cache内存碎片化。明明整体显存占用率还没打满，但是连续内存块已经耗尽，系统被迫触发swap。一旦swap上来，P99延迟直接原地爆炸，故障排查的时候很容易被低显存占用这个表象迷惑，找半天定位不到根因。
市面上各种优化手段，KV量化、滑动窗口、动态缓存淘汰，很多PPT演示效果惊艳。但这些方案全部存在trade‑off。KV量化引入精度损失，滑动窗口丢弃远端上下文，属于拿业务效果换资源利用率，不能无脑一键打开全量特性。做线上配置的时候，一定要结合自己业务的上下文分布做压测，别直接把开源项目默认配置直接拉去生产环境，这种复制粘贴踩坑案例见过太多。
老调度框架适配Token服务的水土不服现在不少智算平台调度内核，底子是从离线训练任务演化过来。训练任务大多是大作业，任务生命周期长，资源申请之后基本稳态运行。而在线token推理服务完全是另一套逻辑：请求碎片化、流量潮汐效应明显，突发尖峰说来就来。
如果调度器只做简单轮询，只统计任务数量，不去感知每个任务预估token量级，就会出现伪负载均衡。有的节点挂满超长会话请求，显存池被吃的七七八八；另一些节点任务数量差不多，但都是短请求，GPU还在摸鱼划水。表面看各个节点任务数目均衡，实际资源已经严重倾斜，极端情况会出现资源饿死。
异构混布集群这个问题会进一步恶化。不同代际GPU显存大小、显存带宽、NVLink互联能力参差不齐。强卡弱卡混跑，没有token感知的调度策略，很容易出现弱卡先被打挂，强卡资源闲置。
报告里面提到一个方向，就是面向token的精细化调度，把预估token吞吐量作为调度权重，而不是单纯看卡的数量。现实中想做到完美并不容易，因为单条请求最终实际token生成量是动态的，属于未知变量，只能做预估值，会存在预估偏差。所以现在业界大多是预估值做参考，再叠加节点实时监控反馈做动态修正，没有银弹解决方案。
回到我们普通开发者视角绝大多数人不会去自研整套智算底座，但是做应用层开发，写Agent、做RAG服务，这些底层约束绕不开。
不少开发图省事，遇到长文档直接一股脑全部丢进上下文，迷信越大上下文窗口能力越强。每多一个token，prefill阶段消耗计算资源，decode阶段持续占用KV缓存资源。把全部压力一股脑甩给底层集群，属于上层偷懒转嫁底层压力。实际工程实践，优先做文档分块、摘要、检索过滤，控制单次请求最大上下文阈值，是性价比很高的手段。
调参的时候不要只盯着temperature、top‑k这类模型超参，心里要有一根弦，区分prefill开销和decode开销。同样token总数，prefill阶段吃算力，decode阶段吃带宽，两者资源模型完全不一样。
这份信通院报告更多偏向产业层面，不会给你几段复制即用代码。看完之后我回去翻了下自己部署的推理服务监控，微调了单实例最大上下文限制，加了简单的超长请求熔断，防止个别极端请求把节点干崩。算不上什么重磅优化，就是日常运维里面一次普通调参。
不知道大伙线上推理服务有没有遇到过这类奇葩问题，欢迎楼下聊聊自己踩过哪些和token、KV缓存相关的坑。