算力过剩争议背后：从单柜吞吐看AI推理资源规划的账

算力过剩的争论：从一笔“单柜账”说起

最近，关于“AI 算力是否极端过剩”的讨论再次升温。起因是有团队公布了一项惊人数据：他们的一台标准机柜，在一天内处理了数万亿个 token（文本处理的基本单位），并据此推测，单台这样的设备几乎就能承接一个头部开放模型聚合平台一整天的转发流量。

表面看，这似乎是“算力过剩”的有力佐证。但如果我们把这句话拆开，就会发现其中的论证链条存在多处薄弱环节。这篇文章的目的，就是从工程与容量规划的角度，把“一台机柜到底能干多少活”这笔账算清楚。真正的争议点不在于“总量够不够”，而在于“统计口径是否一致”，以及“峰值时段能否扛住”。

关键一：统计口径远比想象中复杂

1. 单日吞吐量到底是什么量？

当看到“一天处理了 6.82 万亿 token”这类数据时，首先要追问的是：这 6.82 万亿到底统计了什么？

在推理服务中，token 的消耗可以分为三类：

• 输入 token（未命中缓存）：模型需要重新计算这些内容；
• 输入 token（命中缓存）：服务端已保存了相同前缀的计算结果，直接复用；
• 输出 token：模型新生成的文本，必须逐字计算。

在文本生成场景里，输入往往远大于输出。例如，让模型修改一段较长的代码，首轮需读取完整项目说明；后续追问时若未开启缓存，系统可能将前面的对话历史全部重发一遍，导致同样的输入被重复计费与计算。但如果服务端开启了前缀缓存，第二轮请求就能复用首轮的计算结果，看似“输入量很大”，实际新增算力消耗极小。

因此，“6.82 万亿”可能是一个包含大量命中缓存复用的累计值，并不代表同等规模的独立计算量。若把所有 token 都等同于“新生成的内容”或“完全重算的内容”，会严重高估算力消耗，从而误导对供给过剩的判断。

2. 响应时间与批量处理的天壤之别

另一个容易被忽略的维度是延迟要求。一台机柜可以在一天内消化大量请求，前提是将请求以较高并发批量跑完。但如果要求每个请求在 1 秒内返回首个 token，机柜能承载的并发能力会大幅缩水。

举一个直观的类比：一家餐厅一天能接待 2000 桌客人（总吞吐），但若要求每位客人从进门到上第一道菜不超过 3 分钟，餐厅的同时间接待能力就必须大幅降低。AI 推理也是如此，批大小越高、吞吐量越大，但单次请求的等待时间越长。真正生产环境中的交互式应用，对延迟有硬性约束，不能为了刷吞吐量无限加大批次。

关键二：总量装得下，不等于忙时接得住

1. 流量是波动的，不是均值的

算力规划的核心难点在于流量分布的不均匀。假设一套推理系统每小时能处理 100 个标准请求，全天理论容量为 2,400 个。如果实际流量在 18 个小时内每小时 40 个，剩余 6 个小时每小时 160 个，那么全天总需求为 1,680 个请求，仅为总容量的 70%。表面看资源绰绰有余，但在那 6 个高峰小时内，系统每秒需处理的请求数量是低峰时的 4 倍，很可能导致排队与超时。

这种情况在 AI 应用中极为常见：工作日白天是办公辅助类应用的高峰；晚上和周末是娱乐与创作类应用的高峰；新产品上线或营销活动期间，流量可能瞬间暴涨至平时的数倍。

2. 有效容量 vs 名义容量

因此，在评估算力是否过剩时，应当使用“有效容量”而非“名义容量”。有效容量指在满足性能指标（如 P95 延迟、错误率）前提下，系统能实际承载的峰值流量。若拿一天的总处理量除以 24 小时，算出“平均每小时够用”，就忽略了峰谷差异，属于统计上的乐观偏差。

实践中，一个常见做法是按“峰值小时需求”预留 30%-50% 的冗余。这意味着：即便一天的累计 token 数远低于理论产能，基础设施采购仍可能是合理的。算力规划的本质是在成本与体验之间找平衡，而这个平衡点随业务形态变化。

关键三：从“单柜”到“云”的全局视角

1. 分散部署与网络延迟

单台机柜处理能力强，不代表单点部署能覆盖所有用户。全球用户分布广泛，若仅在一地部署，远距离访问必然带来高延迟。为了保障体验，服务商通常需要在多个区域就近部署推理节点；且每个区域都要预留独立的峰值冗余。这意味着，即便全球总需求可被某一两个集群承接，实际采购的算力也会显著多于理论需求。

2. 弹性扩展与资源池化

与自建机房相比，云计算的一个核心优势在于资源池化与弹性伸缩。使用云服务时，你可以在流量高峰时扩容、低峰时缩容，只需按实际使用量付费。这种模式从机制上弱化了“算力吃紧”或“算力过剩”的二元判断，将问题转化为“单位 token 的成本优化”。

常见的云上推理架构大致如下：

客户端请求 → 负载均衡 → API 网关 → 推理服务集群（多节点）
                                    ↓
                    （可选）缓存服务（前缀缓存 / 语义缓存）

在这一架构中，缓存层能显著降低重复计算的资源消耗；自动扩缩容规则负责在流量陡增时快速拉起节点，并在空闲时释放资源。这既是成本控制手段，也是应对“结构过剩”的有效方案。

3. 不做“账房先生”，要做“精算师”

回到最初的争论：“算力是否极端过剩”目前没有统一答案。对单一团队而言，单柜吞吐高企，说明硬件效率远未到瓶颈；但若放到全行业看，大量未充分使用的资源也确实存在。关键的判别公式应包括：

• 总有效吞吐（扣除缓存命中与实际响应时间约束）
• 高峰时段需求 vs 有效容量
• 分布在不同地域的延迟敏感型任务占比

只有把这些变量纳入考量，才能完成一份及格的基础设施规划。

结论：与其争论过剩与否，不如优化单位 token 成本

与其在“过剩”和“紧缺”之间站队，不如把关注点聚焦到更务实的问题上：如何在满足延迟要求的前提下，让每一度电、每一颗芯片产出尽可能多的有效 token。

具体行动建议如下：

1. 开启上下文缓存：对于多轮对话、长文档摘要等场景，引入前缀缓存可显著减少重复计算；
2. 动态批处理：按延迟预算动态调整批大小，在吞吐与延迟之间寻找最优平衡点；
3. 按流量峰值扩缩容：在云环境中使用自动伸缩策略，避免全天候为峰值付费；
4. 建立有效容量监控：不只盯总量，更要统计高峰时段的成功率与响应时间，作为扩容依据。

算力过剩与否，取决于你站在哪一类业务、哪一种统计口径之上。一套严谨的容量评估体系，远比一个“过剩”或“不过剩”的结论更有价值。