算力吞吐与容量规划：单柜指标不等于全局过剩

一、争议的起点：一个被放大的单点指标

近期有观点称，某团队用一台高密度GPU机柜在一天内处理了数万亿个token，并据此推算“单柜几乎可以承接某开放模型聚合平台前一日转发的全部流量”，进而引申出“全球AI算力已极端过剩”的判断。这个推论链条看似顺滑，实则在中途发生了多次概念滑移，值得逐层拆解。

先厘清两类证据的性质。第一类是自报业务吞吐量：某团队声称单日处理了6.82万亿token。这是一个运营层面的统计数字，反映的是“跑过去了多少量”，而非“在给定响应时间与可靠性约束下能承载多少请求”。第二类是外推估算：“一柜几乎够用”是作者用上述数字与某平台转发流量做对比得出的粗略判断，并非把当日的真实请求按同等SLA重放一遍的压测结果。两者证据强度差异巨大，不能混为一谈。

还有一个容易被忽略的规模细节：一台高密度机柜并非“一台服务器”，按业界常见的高密度整机柜方案，单柜可能集成72颗GPU与36颗CPU，是数十台计算节点的聚合体。用“一台”来描述，容易让读者低估背后的设备规模与功耗、散热、网络配套成本。评价算力供需，首先要统一计量口径：是芯片数、机柜数、集群数，还是有效算力（考虑互联效率与利用率后的实际产出）？

二、同样是一万亿token，成本为何天差地别

理解吞吐量之前，必须先理解token的“成分”。推理请求的计费与计算成本，取决于三类截然不同的工作量：

• 缓存命中输入（cached input）：与上一轮完全相同的上下文前缀，服务端保留了之前的注意力键值缓存（KV Cache），可直接复用，无需重新做前向计算。
• 未命中缓存输入（uncached input）：首次读入的新上下文，需要完整前向计算并写入缓存。
• 生成输出（output tokens）：自回归逐token解码，每生成一个token都要跑一次前向，且无法并行加速，单位成本最高。

举个开发场景的例子。你让模型审查一段代码：第一轮它读入了很长的项目说明与历史对话；第二轮你只补了一句“再看看报错的位置”，客户端却往往把整段历史一并重发。若前缀完全一致且服务端缓存有效，这部分输入可以低成本复用；反之，如果是让它从零撰写一篇长文，新生成的每个token都要实打实地逐步计算。

业界主流推理服务普遍在计费口径上区分缓存命中与未命中，这是公开且通用的做法。因此，看到“6.82万亿”这样的数字，合理的追问是：

1. 其中缓存命中的输入占比多少？
2. 首次读取的输入占比多少？
3. 真正新生成的输出token有多少？
4. 首token延迟（TTFT）与端到端延迟处于什么水平？

如果输出token占比很低、缓存命中率很高，那么“数万亿token”对应的实际新增浮点运算量可能远小于直觉。不能把这个数字读成“一天新写出了数万亿个token”，更不能据此直接推算全球算力冗余度。

三、总量装得下，不等于峰值接得住

容量规划中最常见的误区，是把“日总量”当成“承载能力”。用一个简化模型说明：

假设某推理服务每小时可处理100份等长请求，全天理论容量为2400份。实际需求分布为：18个小时每小时40份，另外6个小时每小时160份。全天总需求为 18×40 + 6×160 = 1680 份，仅占全天容量的70%。从日总量看相当宽裕，但那6个高峰小时的每小时需求（160份）已超出每小时处理能力（100份），必然出现排队、超时甚至拒绝服务。

这个例子揭示了三个关键结论：

• 容量是时间的函数：日总量是积分，服务能力是每单位时间的上限，两者不可直接相除比较。
• 峰值由最忙的那一小时决定：系统可用性取决于峰值时段的排队长度与尾延迟，而非平均利用率。
• 弹性与调度是缓冲器：通过错峰调度、批处理合并、优先级队列、弹性扩缩容，可以把部分峰值压力转移至低谷时段，但这需要架构支持，且受限于冷启动时间与扩容速度。

对于推理服务，还要叠加一个约束：解码阶段的批处理会显著影响延迟。把更多请求塞进同一批次能提升吞吐，但会拉高单请求延迟；反之降低延迟就要牺牲吞吐。因此在给定SLA下，“每小时能处理多少请求”本身是一个随批策略变化的动态值，而非固定常数。

四、评估真实承载力的方法论

要判断“单柜能否承接某平台全部流量”，需要一套可复算的方法，而不是单点数字对比。建议按以下步骤建模：

第一步：定义请求画像。 统计输入长度分布（区分缓存命中与未命中）、输出长度分布、请求到达的时间分布（泊松到达还是突发洪峰）、并发会话数。这些决定了计算量与显存占用。

第二步：测量单请求成本。 在目标硬件上实测不同输入输出组合下的首token延迟与每token解码耗时，得到服务时间分布，而非单一均值。尾延迟（P99）往往比均值更能反映用户体验。

第三步：建立排队模型。 用M/M/c或更贴合实际的半解析模型估算在给定并发度下的排队长度与超时率。核心公式直觉是：利用率ρ越接近1，排队时间非线性上升。ρ=0.9时的平均等待可能是ρ=0.5时的数倍。

第四步：按SLA反推容量。 给定可接受的首token延迟与超时率，反推单柜可持续承载的请求速率（QPS或tokens/s），再与目标流量对比。此时才谈得上“够不够”。

第五步：做故障域与冗余核算。 真实系统需要预留N+1冗余、滚动升级窗口、缓存预热时间。有效容量通常低于理论峰值，规划时需打折扣。

一个示意性的容量核算伪代码：

def sustainable_capacity(hourly_qps_curve, service_time_p99, sla_wait_s, redundancy=0.8):
    # 找出峰值小时，按P99服务时间与SLA等待约束估算所需并发
    peak_qps = max(hourly_qps_curve)
    required_concurrency = peak_qps * (service_time_p99 + sla_wait_s)
    # 单柜有效并发受显存与算力约束，此处以实测上限表示
    per_rack_concurrency = measure_max_concurrency()
    racks_needed = ceil(required_concurrency / (per_rack_concurrency * redundancy))
    return racks_needed

这段代码的重点不在语法，而在思路：用峰值小时而非日均值做输入，用P99而非均值做服务时间，并显式引入冗余系数。

五、从单点指标到供需判断：还需哪些证据

即便单柜吞吐量数据真实可靠，要得出“全球算力极端过剩”的结论，仍然缺少至少三类证据：

1. 需求侧的全景数据：单平台转发流量只是开放模型调用的一部分，大量用户可能直连模型服务商，还有企业私有部署、微调训练、多模态生成等未纳入统计的负载。仅凭一个平台的转发量推断全球需求，样本代表性不足。
2. 供给侧的有效算力口径：全球GPU出货量要扣除训练占用、研发自用、库存与在建产能，还要考虑互联带宽、电力与散热对实际出力的约束。名义算力与可用算力之间存在显著折损。
3. 价格与利用率的市场信号：若真属极端过剩，推理单价应持续快速下行、集群平均利用率长期低迷、新建数据中心投资明显放缓。这些是可观测的宏观指标，比单点吞吐量更有说服力。

更审慎的判断或许是：面向开放模型的推理服务供给扩张速度，可能快于愿意持续付费的应用需求增长，这在局部市场、特定模型、特定时段可能表现为价格竞争与利用率不足。但把局部现象扩大为“全球极端过剩”，现有证据还差得远。

六、给开发者的实践建议

• 不要用日总量做容量承诺。对外承诺SLA前，按峰值小时与P99延迟做压测，并留足冗余。
• 优化缓存命中率。稳定复用的系统提示、工具定义、长文档前缀应保持字节级一致，以提升缓存复用比例，直接降低单位token成本与延迟。
• 区分输入输出计费口径做预算。按缓存命中输入、未命中输入、输出三类分别估算成本，避免用混合均价做决策。
• 设计削峰填谷机制。对延迟不敏感的批处理任务（如离线摘要、批量标注）调度至低谷时段，用队列与优先级隔离在线请求。
• 建立可观测性。持续采集首token延迟、tokens/s、缓存命中率、排队长度、超时率等指标，让容量决策基于数据而非单点新闻。

算力是否过剩，最终不是由某一个亮眼的吞吐数字决定的，而是由“在真实SLA约束下、按真实请求分布、可持续交付的有效容量”与“愿意持续付费的真实需求”之间的比值决定的。把这两个变量都测准，结论才站得住脚。