到 2027 年出货的 AI 芯片能跑多少 AI 智能体?
How many AI agents could run on the AI chips shipped through 2027?
按 2025–2027 年出货的 HBM 测算,这些硬件最终可支持数千万至数亿个并发的前沿模型智能体,相当于约 1.4 亿至 7.2 亿名全职员工的每周工时。若采用 DeepSeek V4 Pro 的服务基准,同一硬件可支持约 19 亿个并发智能体。即便只使用其中 20% 的容量,按 API 价格折算的年支出也将达 2.6 万亿至 5.3 万亿美元。
概述
AI 公司每年在芯片和数据中心上花费数千亿美元,其前提是这些芯片将运行 AI 智能体,完成今天由人类完成的工作。 这种硬件建设实际上能支持多少智能体?
- 到 2027 年出货的 AI 芯片可运行数千万到数亿个并发的前沿模型智能体。这些智能体不间断运行,所提供的每周工作时间相当于约 1.4 亿至 7.2 亿名全职员工。
- 更高效的模型有可能在相同硬件上支持数十亿个智能体。将 DeepSeek V4 Pro 的服务基准应用于预计的硬件供应,可得到约 19 亿个并发智能体,其提供的每周工作时间相当于 80 亿人每人每周工作 40 小时。
- 即使适度使用这一容量,也需要全球 AI 需求大幅增长。使用我们中心容量估计的 20%,意味着每年 2.6 万亿至 5.3 万亿美元的 API 等效支出,而按年增长五倍计算,到 2027 年底开发者收入约为 1 万亿美元。
- 智能体的每小时支出因模型和运行框架不同而差异很大。在我们对智能体轨迹的分析中,Codex 工作负载在智能体持续活动期间平均每小时约 16 至 18 美元,而 Claude Code 工作负载为 24 至 50 美元。
潜在的智能体容量与支出
Anthropic 的 Dario Amodei 曾描述过一个未来“数据中心里的天才之国”,但未来的数据中心实际上能支持多少 AI 智能体?这一规模对 AI 可能对经济和劳动力产生的影响至关重要。
我们发现,2025 至 2027 年出货的使用高带宽内存(HBM)的硬件,最终可支持数千万到数亿个并发的前沿模型智能体,前提是全面部署并分配给这些工作负载。2025 至 2026 年出货的 HBM 在部署后可支持 1600 万至 5600 万个并发智能体。将截至 2027 年的出货量纳入后,这一估计提高到约 3000 万至 1.7 亿。1
但与人类不同,AI 智能体每周可以工作全部 168 小时,是全职员工每周 40 小时工作制的 4.2 倍。因此,从截至 2026 年的硬件出货量来看,这些智能体每周的工作时间可相当于约 6700 万至 2.4 亿人;从截至 2027 年的出货量来看,可相当于约 1.4 亿至 7.2 亿人。作为规模参照,美国人口为 3.42 亿,知识工作者估计有 1 亿。这些比较仅计算工作时间。智能体的产出速度也可能远快于人类,尽管产出质量参差不齐。
即使我们只使用截至 2027 年出货的内存所提供容量的 20%,按 API 价格计算,硬件部署后隐含的支出也将达到每年 2.6 万亿至 5.3 万亿美元。2 作为对比,如果模型开发者的收入继续每年增长五倍,到 2027 年底,他们的合计年化收入将达到约 1 万亿美元。
需求可能落后于这一潜在供应,造成容量过剩。 关键的不确定性在于,AI 服务需求的持续快速增长是否会证明这笔投资是合理的。

我们如何估计智能体容量
我们估算潜在的并发智能体数量(\(A\)):假设完全部署并分配给所建模的工作负载,在 2025–27 年期间出货的内存上可以同时运行多少个智能体。 我们使用这些容量估算值,在所述运行时间、定价、分配和利用率假设下,推导出工作小时数和 API 等效支出数字。
我们对潜在并发智能体数量的估算由两项构成:
\[\begin{aligned} A &= E \times c, \\[6pt] \text{其中}\quad A &= \text{潜在并发智能体数量}, \\ E &= \text{以 GB300 等效单位计的有效硬件供应量}, \\ c &= \text{每个 GB300 等效单位的智能体数量}。 \end{aligned}\]
有效硬件供应量(\(E\)):以 GB300 等效推理单位衡量,类似于基于 FLOP 的 H100 等效单位。 对于这些工作负载,内存容量制约并发数,内存带宽制约流式传输速度。 我们统计 2025 年起出货的高带宽内存(HBM),包括 HBM3E 及更新世代,以 288 GB 为单位,与一块 GB300 GPU 相匹配。 然后我们根据更新硬件可支持的并发数进行调整:
\[E = \frac{H_3 + u \times H_4}{288},\]
其中 \(H_3\) 和 \(H_4\) 分别是 HBM3E 和 HBM4/4E 的累计供应量(GB)。 \(u\) 是 HBM4/4E 系统上每 GB 的智能体会话数与 HBM3E 系统上每 GB 的智能体会话数之比。
服务容量(\(c\)):每个 GB300 等效单位上并发活跃的智能体会话数。
我们使用
\[c = \frac{G \times K}{S}\]
用于闭源模型。 \(S\) 是每个活跃智能体小时的 API 支出(美元/智能体小时),使用调整后的时长以剔除已识别的人类等待时间并限制其他空闲间隔。 \(G\) 是 GPU 租赁成本(美元/GB300 小时)。 \(K\) 是 API 等效收入除以参考服务成本。
对于开放模型,我们使用基准测试的并发数。
主要假设: \(S = \$30/\text{agent-hour}\),\(G = \$5/\text{GB300-hour}\),\({K = 5\text{–}10\times}\),以及 \({u = 2\times}\)。我们还测试了 \({u = 1\times}\) 和 \(4\times\)。
开放模型基准测试使用每用户每秒 50 和 100 输出 token 的 P90 流式速度目标,并以 200 作为敏感性测试。我们保持当前模型和工作负载需求不变。
估算当今每块 GPU 的 agent 会话数
什么算作一个 agent?
我们用“agent”作为在 Codex 或 Claude Code 等 harness 中运行的 agentic 工作负载的简称。一个 agent 会话包括模型调用和工具使用,而不是连续的 token 生成。
我们依据两个来源:SemiAnalysis 针对开放模型的 AgentX 服务基准测试,以及 TraceLab——一个记录 agent 会话的公开数据集,用于闭源模型。 AgentX 将一个主 agent 及其子 agent 计为一个会话树;TraceLab 的统计分组并不总能捕捉到完整的树。在讨论容量时,我们互换使用“agent”和“agent 会话”。一个连续的 agent 会话包括等待工具调用所花费的时间。我们通过去除等待人工输入的时间,并对未识别的空闲时间设上限,来估算连续工作时间。这一调整后活动的一小时计为一个 agent-hour。
对于开放模型,服务基准测试直接测量硬件在给定输出速度下支持多少并发 agent 会话。对于闭源模型,我们根据每小时支出和服务成本假设来估算并发数。
开放模型:服务基准测试直接测量并发数
对于开放模型,我们使用 SemiAnalysis 的 InferenceX AgentX 的基准数据。AgentX 基准使用由 SemiAnalysis 收集的 Claude Code 智能体会话轨迹数据集。该基准回放使用合成文本,同时保留请求长度、共享上下文以及模型调用的时序和结构。更多细节见 AgentX 方法论。
AgentX 的并发数由启动的智能体会话数量定义。我们将并发数除以 GPU 总数,得出每 GPU 并发智能体会话数的指标。对于预填充-解码分离配置,我们计算合并后的 GPU 数量。图 2–3 展示了已发布的配置以及每 GPU 的智能体会话数。
速度目标:每用户每秒 50 和 100 个 token
我们使用 50 和 100 TPS/用户作为输出速度(以每秒 token 数计)的整数参考点。附录中还给出了 200 TPS/用户,以测试更严苛的场景。作为参考,OpenAI 和 Anthropic 都倾向于以约 50–70 TPS 的速度服务其前沿模型。在基准数据中,P90 交互性描述了分布较慢一端的输出速度(以 TPS/用户计)。这不包括首 token 时间(TTFT),也不衡量端到端延迟(见附录 A)。
这些图表使用表 2 中标注日期的 AgentX 快照,涵盖七个模型。我们排除了任何未直接通过 InferenceX 公共仓库运行的预览数据。

主要速度目标下的每 GPU 并发数

闭源前沿模型:从 API 支出推断并发数
由于闭源前沿模型缺乏透明硬件基准所需的架构细节,我们转而考察持续运行的智能体的 API 成本。我们分析了 TraceLab 的数据集,其中包含 Codex 和 Claude Code 智能体会话。我们调整了人工延迟(智能体等待人工响应),并将支出除以智能体工作时间,以归一化为每小时费率。使用表 A3 中列出的 API 价格,我们计算了每个智能体小时的 API 等效支出。
然后,我们使用 API 收入与服务成本的假定加价率,估算其中有多少支出覆盖了服务成本。将由此得出的每个智能体小时成本与 GB300 GPU 的租赁成本进行比较,可估算出每块 GPU 可支持多少个并发智能体。

每个智能体小时 30 美元介于 Codex 和 Claude Code 成本之间
每小时支出因模型和运行框架而异。在 Figure 4 的保留缓存4和五分钟间隔上限假设下,TraceLab 的汇总费率为:GPT-5.5 每小时 18.2 美元,GPT-5.6 Sol 为 15.5 美元,Opus 4.8 为 24.3 美元,Fable 5 为 50.2 美元。我们选择每小时 30 美元作为一个整数参考点,它略偏向较高的一端。未来的模型价格可能上涨,就像 Anthropic 的 Fable 和 OpenAI 的 GPT-6 Astra 带来的跃升一样,也可能因竞争和效率提升而下降。Figure 8 涵盖了从每智能体小时 10 美元到 100 美元的一系列价格。
设 \(S\) 为每智能体小时的 API 支出,\(K\) 为在我们参考 GPU 租赁价格下,API 等效收入与服务成本的比率。\({K = 10\times}\) 表示每 1 美元成本对应 10 美元的 API 计费。
每智能体小时的隐含服务成本为 \(S/K\)。将 GPU 小时租赁价格 \(G\) 除以该成本,得到每个 GB300 等效的智能体会话数:
\[\begin{aligned} \text{每个 GB300 等效的智能体会话数} &= \frac{G}{S/K} \\[4pt] &= \frac{G \times K}{S}. \end{aligned}\]
Table 1 使用每智能体小时 \(S = \$30\) 和 \(G\) = $5.00/GB300-hour,来自 SemiAnalysis 的 Rent – 3 Year Commit 档位。在 \({K = 10\times}\) 时,隐含服务成本为每智能体小时 3 美元。5 美元的 GPU 小时可支持 1.67 个并发智能体会话。
| 收入/成本 \(K\) | 隐含成本/智能体小时 | 智能体/GB300 等效 |
|---|---|---|
| 5× | $6.00 | 0.833 |
| 10× | $3.00 | 1.667 |
Table 1. 在每智能体小时 30 美元和每 GB300 小时 5 美元下的闭源模型假设。附录 B 测试了更高的收入/成本倍数。
我们的主要情形使用 \({K = 5\text{–}10\times}\),在每智能体小时 30 美元下,每个 GB300 可支持 0.833–1.667 个智能体会话。Table 2 显示,在 AgentX 上以 50 TPS/用户运行时,开源模型的比率 \(K\) 约为 4–10×。5
开源模型基准测试意味着 2–10× 的收入/成本比率
我们将假设的倍数与每个开源模型基准测试按其模型 API 费率、使用理论缓存命中率所能获得的收入进行比较。在每个 P90 速度目标下,我们选择每个并发智能体小时三年租赁成本最低的 GPU。
每个速度列报告 \(K\),即 API 等效收入与 GPU 租赁成本的比率。每个智能体会话租赁成本最低的 GPU 不一定具有最高的 \(K\)。
InferenceX 报告了理论上可复用前缀的输入量。我们将这些 token 按模型的缓存输入费率计价,其余按普通输入费率计价。如果提供商缓存的比例不同,实际 API 计费可能更高或更低。
| 模型 / API 档位 | GPU | 50 TPS/用户 | 100 TPS/用户 |
|---|---|---|---|
| DeepSeek V4 Pro 非高峰 | GB300 | 4.4× | 2.1× |
| DeepSeek V4 Pro 高峰 | GB300 | 8.8× | 4.2× |
| GLM-5.2 | GB300 | 10.5× | 9.3× |
| Kimi K3 | GB300 | 4.1× | 2.9× |
| MiniMax M3 | B300 | 4.8× | 4.1× |
Table 2. 在 AgentX 中选定的开源模型在所选 50 和 100 TPS/用户配置下,API 等效收入除以 GPU 租赁成本。MiniMax 使用短上下文 token 定价。6
我们使用 SemiAnalysis 报告的相同租赁费率,$5.00/GB300-hour 和 $4.25/B300-hour,来计算运行 AgentX 基准测试的 GPU 的 \(K\)。我们在每个前沿端点对理论缓存复用进行定价,并插值以在所需 TPS/用户下获得每 GPU 小时的并发数和 API 等效收入。当前沿保持在某个速度目标之上时,我们使用其观察到的最高并发数。
AgentX 和 TraceLab 的工作负载具有可比性
AgentX 从 WEKA 语料库中重放 Claude Code 会话树。由于 AgentX 的 WEKA 轨迹格式与 TraceLab 轨迹存在差异,我们绘制了两者中常见 Claude 模型的对比图,以检查这些工作负载是否足够相似、可以进行比较。图 5 比较了处理后按 token 类型划分的每小时 token 消耗量。

从高带宽内存估算未来产能
HBM 是 AI 加速器共同的瓶颈
HBM 为我们提供了一个跨 GPU 和定制 AI 加速器的通用供给衡量标准,因为它同时是推理的重要组件和芯片生产的主要瓶颈。HBM 的主要生产商只有三家:Micron、Samsung 和 SK hynix。Micron 报告称内存需求超过供给,而新建晶圆厂需要数年时间,同时 SK hynix 也报告称需求超过其供给能力。据报道,由于这些供给限制,Nvidia 也在评估为 Rubin Ultra 采用更低内存的配置。
HBM 容量限制了同时可以保持活跃的请求数量。内存必须容纳模型权重和 KV 缓存,而 KV 缓存会随每个请求的上下文长度增长。更长的上下文需要更多的缓存空间。当瓶颈是从内存中流式传输权重和 KV 缓存所需的时间时,HBM 带宽会以 TPS/用户为单位限制解码速度。
我们以 288 GB 为单位计算物理 HBM 容量,与基准测试中使用的 GB300 级 GPU 相匹配。8这提供了一个跨厂商的通用内存单位。然后我们根据更新系统的性能进行调整,以有效 GB300 当量来表示供给。9
| 加速器 | HBM 代际 | 每 GPU 内存 | 每 GPU 峰值带宽 |
|---|---|---|---|
| A100 80GB SXM | HBM2E | 80 GB | 2.039 TB/s |
| H100 SXM | HBM3 | 80 GB | 3.35 TB/s |
| Blackwell Ultra (GB300) | HBM3E | 288 GB | 8 TB/s |
| Rubin (VR200) | HBM4 | 288 GB | 22 TB/s |
表 3. 代表性 GPU 的已公布内存规格。数值为每 GPU 的值。附录 C 列出了各个 HBM 堆栈的容量和带宽规格。
更新的 HBM4 系统应支持每 GB 更多 agent
Nvidia 的 Blackwell Ultra 和 Rubin 规格显示,GB300 使用 288 GB 的 HBM3E,而 VR200 使用 288 GB 的 HBM4。虽然容量保持不变,但 HBM 代际的这一变化将带宽从 8 TB/s 提升到 22 TB/s(增长 2.75 倍)。
当内存容量是约束条件时,并发量受限于内存中可容纳的最大请求数。当带宽是瓶颈时,更多带宽可以在给定输出速度下支持更多 agent。10
我们的核心假设是,HBM4/4E 系统每 288 GB 支持的并发 agent 数量是 HBM3E 系统的两倍(\(u = 2\))。这一增益取决于工作负载及其瓶颈,因此我们也测试了无改进(\(u = 1\))和四倍改进(\(u = 4\))的情况。四倍的情况考虑了超出内存带宽的增益,例如更好的互连和更高效的服务软件。
我们统计了自 2025 年以来出货的所有 HBM3E 及更新代际的内存
这些出货年份标识了每个估算中所包含的硬件;部署则在其后发生。Epoch 的 AI 芯片组件方法论 假设从 HBM 进入加速器封装到加速器完成大约需要八周,包括最终组装和测试。当部署依赖于数据中心建设时,所需时间可能显著更长,且更难以预测。
我们根据 TrendForce 的公开报告重建年度供应量:2026 年 HBM 出货量超过 37.5 亿 GB,2026 年 HBM 使用量增长超过 70%,以及预计 2027 年出货量增长 50–60%。表 4 使用前两个阈值作为点估计,并使用 2027 年增长区间的中点。11 以下是我们推导出的估计值。详细计算见附录 B。
| 出货年份 | HBM 总 B GB | HBM3E 份额 | HBM4/4E 份额 |
|---|---|---|---|
| 2025 | 2.21 | 80% | 0% |
| 2026E | 3.75 | 62.5% | 37.5% |
| 2027E | 5.81 | 20% | 80% |
表 4. 年度 HBM 出货量(十亿 GB)及估计的代际份额。2026–27 年的份额为假设值。
所作假设:
- 对于 2025 年,TrendForce 预计 超过 80% 的 HBM 位需求为 HBM3E。我们采用 80%,并将剩余 20% 作为较旧的 HBM 排除在外。
- TrendForce 预计 HBM4 将在 2026 年下半年超过 HBM3E,但未给出全年份额。我们假设 HBM4 占年度出货量的 37.5%。
- 对于 2027 年,TrendForce 认定 HBM4 为主流代际。我们假设 HBM4/4E 占出货量的 80%,其余为 HBM3E。
到 2027 年的出货量可支持 3300 万至 1.71 亿个前沿模型智能体
我们分两步计算总并发智能体数:
\[\begin{aligned} E &= \frac{H_3 + u \times H_4}{288} \\[6pt] A &= E \times c \end{aligned}\]
\(H_3\) 和 \(H_4\) 是 HBM3E 和 HBM4/4E 的累计供应量,单位为 GB。 将 \(H_4\) 按 \(u\) 加权并除以 288,得到有效 GB300 当量 \(E\)。 将 \(E\) 乘以每个当量的智能体会话数 \(c\),得到潜在并发数。

图 7 使用主要的闭源模型估计值,即每个 GB300 当量 0.833–1.667 个智能体会话,基于 \(S = \$30\)/小时、\(G = \$5\)/GPU 小时以及 \({K = 5\text{–}10\times}\)。它假设完全部署并分配给该工作负载。

在中心硬件假设下,到 2026 年的出货量可支持约 2000 万至 4000 万个并发智能体,到 2027 年的出货量则升至 5000 万至 1.01 亿个。将一半内存分配给该工作负载将使这些数量减半。附录 B 给出了每种硬件假设的结果。
2027 年总数包含 2026 年总数。每个模型情景代表对同一硬件池的替代使用方式。
容量与每个智能体小时的支出成比例下降
图8显示了当agent-hour成本从原始的30美元中心估计值变化到10至100美元时,agent数量的变化。色带还显示了取决于加价倍率 \({K = 5\text{–}10\times}\) 和HBM4提升 \({u = 1\text{–}4\times}\) 的范围。这显示了总agent数量如何随agent-hour成本的升高而下降。附录B给出了数值网格。

来自开放模型基准的容量

对于DeepSeek,InferenceX GB300前沿在50 TPS/用户下给出每GPU 31.4个agent会话,在100 TPS/用户下给出14.4个,包括插值。我们将这些基准估计按有效硬件供应进行缩放,并将 \(u\) 从1×变化到4×。包含其他开放模型的数值表见附录B。
结论:总量对AI需求意味着什么
在我们的硬件和服务成本情景中,2025–27年间出货的存储在部署并完全分配给这些工作负载后,可支持约3000万至1.7亿个并发前沿模型agent,提供的每周工作小时数相当于约1.4亿至7.2亿名全职员工。这引出的问题是,需求是否足够大以利用这些容量。
为了将这一容量与推理市场的规模进行比较,我们考虑一个保守使用可用硬件的情景:40%分配给产生收入的推理,50%利用率,从而有效使用总容量的20%。一旦部署,使用2025–26年间出货的存储的硬件,在我们的中心硬件和参考服务成本假设下,可支持约1.1万亿至2.1万亿美元的年度API等效支出,当包括截至2027年的出货量时,在每agent-hour 30美元下升至2.6万亿至5.3万亿美元。13
作为比较,领先的模型开发者已经合计产生超过1000亿美元的年化收入。延续近期每年五倍的增长速度,到2027年底这将达到约1万亿美元,仍显著低于我们的容量情景所隐含的支出。14
服务容量的近期短缺可能与这一潜在供应并存。2025年末,Satya Nadella 表示微软有芯片滞留在库存中无法接入,因为没有合适的已供电数据中心空间。部署延迟给需求更多增长时间。随着这些瓶颈缓解,累积的硬件可以与新出货一起上线。
实现给定AI性能水平的成本正在迅速下降。Epoch的近期分析估计,自2023年以来,在所研究的基准上每季度下降47%。这对建设而言是一把双刃剑。更低的硬件拥有和运营成本可以减少证明投资合理性所需的收入。然而,更高效的模型和服务系统减少了每项任务所需的硬件。维持利用率将需要agent活动的需求增长到足以抵消这些效率提升。15
需求可能因智能体被更广泛采用、以及被用于更难、计算需求更高的任务而增长。像OpenAI 的 dots 这样的持久型智能体,还可以通过处理持续性的职责和更长期的项目,增加每个用户委派的工作量。更低的价格将使更多此类应用变得经济可行。如果由此带来的活动增长超过计算效率的提升,那么即便每项任务所需的计算量减少,总推理计算需求仍会上升,这正是杰文斯悖论的一个实例。16
这些估算表明存在一种风险:计算基础设施的建设可能超前于推理需求。能否消化这些产能,将取决于用户委派多少工作、这些工作需要多少计算量,以及他们愿意支付多少费用。当每小时成本与人类工资相当时,智能体需要创造足够价值来证明这笔支出是合理的。这场建设是一场押注:AI 将超越回答问题,进而在广泛的行业中执行具有经济价值的工作。
致谢
感谢 JS Denain、Jaime Sevilla、Venkat Somala 和 Josh You 提供的有益反馈。 特别感谢 Eleonora Dello Iacono 设计图表和缩略图,以及 Lynette Bye、Linda Petrini 和 Elliot Stewart 的编辑工作。
附录 A. 额外的基准测试与追踪数据
中位流式传输速度

200 TPS/用户 敏感性分析

流式传输速度不包含首 token 等待时间
| P90 速度目标(TPS/用户) | P90 首 token 时间(秒) |
|---|---|
| 50 | 39.8 |
| 100 | 12.4 |
| 200 | 4.6 |
表 A1. 在满足各流式传输速度目标的最高并发实测 Kimi K3 GB300 配置下的 P90 首 token 时间。
这些配置使用不同的部署,因此结果并不能单独分离出流式传输速度对首 token 延迟的影响。主要并发估算也可以在实测配置之间进行插值。
TraceLab 样本摘要
| 模型与测试框架 | 智能体会话数(合并 / 绘图) | 调整后小时数 | 合并美元/小时 |
|---|---|---|---|
| GPT-5.5 · Codex | 1,069 / 513 | 866.4 | $18.19 |
| GPT-5.6 Sol · Codex | 206 / 140 | 319.7 | $15.50 |
| Opus 4.8 · Claude Code | 1,947 / 855 | 1,010.0 | $24.34 |
| Fable 5 · Claude Code | 168 / 55 | 100.8 | $50.16 |
| Opus 4.8 · Claude Code 峰值 >500k 子集 | 48 / 48 | 302.6 | $38.99 |
| Fable 5 · Claude Code 峰值 >500k 子集 | 10 / 9 | 41.6 | $104.75 |
表 A2. 图 4 所依据的 TraceLab 样本。合并美元/小时为总 API 等效成本除以总调整后小时数。两个计数分别显示所有纳入的会话/模型组,以及至少具有五个主要活跃分钟的组,后者用于绘制分布。较短的组仍保留在合并总计中。
“峰值 >500k”行包含至少有一个符合条件的请求超过 500,000 输入 token 的组。其成本和小时数覆盖整个组,且这些组已包含在全模型行中。四个全模型行包含来自 3,382 个源智能体会话的 3,390 个会话/模型组;一个会话可以贡献到多个模型的行中。
来源:TraceLab v0.0.2;包含的活动时间为 2026 年 4 月 23 日至 2026 年 7 月 24 日(UTC)。我们使用与图 4 相同的缓存、缺口上限和定价假设。Claude API 价格记录于 2026 年 8 月 21 日;Codex 费率核实于 2026 年 9 月 14 日。没有可用计时信息或我们无法定价的模型的组被排除。混合模型组内有五次调用无法定价;它们的时间仍被计入,但成本被省略。
使用的 token 价格
| 模型 | 输入 | 缓存输入 | 缓存写入 | 输出 |
|---|---|---|---|---|
| GPT-5.5 | $5.00 | $0.50 | — | $30.00 |
| GPT-5.6 Sol | $4.00 | $0.40 | $5.00* | $20.00 |
| Claude Opus 4.8 | $5.00 | $0.50 | $6.25 | $25.00 |
| Claude Fable 5 | $10.00 | $1.00 | $12.50 | $50.00 |
表 A3。 图 4 中四个模型行的冻结 token 价格(美元/百万 token)。标准 API 费率;不含快速模式、Batch、Flex、订阅或协商折扣。定价快照日期见上方来源注释。
* GPT-5.6 Sol 的非读取输入假定按 5 美元/百万 token 进行缓存写入,而非按 4 美元/百万 token 的普通输入费率计费;此分配在追踪中未被观测到。GPT-5.5 在分析中没有单独的写入附加费。Claude 写入价格为五分钟缓存写入费率。
对于输入上下文 token 超过 272,000 的 GPT 请求,输入和缓存费率乘以 2,输出费率乘以 1.5。纳入的 GPT-5.5 组均未超过该阈值。显示的 Claude 费率没有长上下文乘数。混合模型调用保留其各自的冻结费率。缓存保留和计时调整不变。
附录 B. 容量计算与敏感性
更高的收入/成本倍数
| 收入/成本 \(K\) | 隐含成本/智能体-小时 | 智能体/GB300 等效 |
|---|---|---|
| 5× | $6.00 | 0.833 |
| 10× | $3.00 | 1.667 |
| 20× | $1.50 | 3.333 |
| 40× | $0.75 | 6.667 |
表 B1。 在 \(S = \$30\)/小时和 \(G = \$5\)/GPU-小时下的服务成本与并发量。主要估计使用 \({K = 5\text{–}10\times}\);20× 和 40× 情形测试相对于 API 收入更低的服务成本。
HBM 重建细节
| 出货年份 | HBM 总 B GB | HBM3E 份额 | HBM4/4E 份额 | HBM3E B GB | HBM4/4E B GB |
|---|---|---|---|---|---|
| 2025 | 2.21 | 80% | 0% | 1.76 | 0 |
| 2026E | 3.75 | 62.5% | 37.5% | 2.34 | 1.41 |
| 2027E | 5.81 | 20% | 80% | 1.16 | 4.65 |
表 B2a。 年度 HBM 供应量(十亿 GB)。2025 年总供应量为 3.75 / 1.70,2027 年为 3.75 × 1.55。我们排除 2025 年供应中由较旧 HBM 构成的 20%。2026–27 年的代际份额为假设值。计算使用未舍入的输入。
我们假设 HBM4/4E 在 2026 年占出货量的 37.5%,2027 年占 80%,遵循正文中描述的过渡。来源未明确这些年度份额。
| 截至出货时间 | HBM3E(十亿 GB) | HBM4/4E(十亿 GB) | HBM3E 288 GB 单元(百万) | HBM4/4E 288 GB 单元(百万) | 有效 GB300 等效(百万;\(u = 2\)) |
|---|---|---|---|---|---|
| 2026 | 4.108 | 1.406 | 14.27 | 4.88 | 24.03 |
| 2027 | 5.271 | 6.056 | 18.30 | 21.03 | 60.36 |
表 B2b。 累计合格 HBM、物理 288 GB 内存单元和有效 GB300 等效供应。最后一列将 HBM3E 单元加上 HBM4/4E 单元的两倍(\(u = 2\))。计算使用未舍入的输入。
对于截至 2026 年的出货量,\(E = (4.10846 + 2 \times 1.40625)\text{ billion GB} / 288\text{ GB} \approx 24.03\) 百万 GB300 等效。乘以主要的每等效 0.833–1.667 个智能体会话(表 B1),在完全分配下得到约 2000 万–4000 万个并发智能体。
按硬件提升的容量
| 截至供应 | 1× 提升 | 2× 提升中心 | 4× 提升 |
|---|---|---|---|
| 2026 | 16.0–31.9 | 20.0–40.1 | 28.2–56.3 |
| 2027 | 32.8–65.6 | 50.3–100.6 | 85.3–170.7 |
表 B3。 在 \(S = \$30\)/小时和 \({K = 5\text{–}10\times}\) 下的并发智能体数(百万),假设完全部署和分配。两行均计入 2025 年起的出货量;2027 年总量包含 2026 年总量。
按每小时支出和模型的容量
| 情景 | 每 GB300 智能体数 | 截至 2026 年(百万智能体) | 截至 2027 年(百万智能体) |
|---|---|---|---|
| 面板 A. 闭源模型 — \({K = 5\text{–}10\times}\);\({u = 1\text{–}4\times}\) | |||
| 闭源模型 $2.5/小时 | 10.0–20.0 | 191.5–675.9 | 393.3–2,048.3 |
| 闭源模型 $5/小时 | 5.00–10.0 | 95.7–338.0 | 196.7–1,024.2 |
| 闭源模型 $10/小时 | 2.50–5.00 | 47.9–169.0 | 98.3–512.1 |
| 闭源模型 $20/小时 | 1.25–2.50 | 23.9–84.5 | 49.2–256.0 |
| 闭源模型 $30/小时 | 0.83–1.67 | 16.0–56.3 | 32.8–170.7 |
| 闭源模型 $50/小时 | 0.50–1.00 | 9.6–33.8 | 19.7–102.4 |
| 闭源模型 $75/小时 | 0.33–0.67 | 6.4–22.5 | 13.1–68.3 |
| 闭源模型 $100/小时 | 0.25–0.50 | 4.8–16.9 | 9.8–51.2 |
| 闭源模型 $150/小时 | 0.167–0.333 | 3.2–11.3 | 6.6–34.1 |
| 闭源模型 $200/小时 | 0.125–0.250 | 2.4–8.4 | 4.9–25.6 |
| 面板 B. 开源模型 — 基准并发;\({u = 1\text{–}4\times}\) | |||
| DeepSeek V4 Pro 50 TPS/用户 | 31.43 | 601.7–1,062.1 | 1,236.0–3,218.4 |
| DeepSeek V4 Pro 100 TPS/用户 | 14.42 | 276.2–487.4 | 567.2–1,477.0 |
| GLM-5.2 50 TPS/用户 | 9.46 | 181.1–319.7 | 372.1–968.9 |
| GLM-5.2 100 TPS/用户 | 7.85 | 150.3–265.3 | 308.7–804.0 |
| Kimi K3 50 TPS/用户 | 3.97 | 76.0–134.2 | 156.1–406.6 |
| Kimi K3 100 TPS/用户 | 1.77 | 33.9–59.8 | 69.6–181.3 |
表 B4. 两个面板使用相同的累计 HBM 供应量,并假设完全部署和分配。面板 A 将正文中的 $10–$100/小时敏感性扩展到 $2.50–$200/小时。面板 B 使用每个 P90 目标下基准测试的 GB300 并发数,包括插值。开源模型与闭源模型估计之间的工作负载、速度和能力有所不同。
API 等效支出
对于闭源模型情景,在完全部署、分配和利用率下的年度 API 等效支出为:
\[\begin{aligned} \text{年度支出} &= A \times 8{,}760 \times S \\ &= E \times G \times K \times 8{,}760. \end{aligned}\]
对于部分分配和利用率,将年度支出乘以两个份额。 我们的 20% 情景对创收推理应用 40% 分配和 50% 利用率。
在 \(G = \$5\) 每 GB300-小时、\({K = 5\text{–}10\times}\) 和 \({u = 1\text{–}4\times}\) 下,完全部署、分配和利用率给出 2026 年之前出货量每年 $4.2–14.8 万亿,2027 年之前每年 $8.6–44.9 万亿。在中心硬件假设(\(u = 2\))下,40% 分配用于创收推理和 50% 利用率给出 20% 有效使用,分别对应每年 $1.1–2.1 万亿和 $2.6–5.3 万亿。这些是硬件部署后的年化率。
在固定 \(K\) 下,估计的并发代理数量按 \(1/S\) 缩放,因此 \(S\) 在支出计算中抵消。
主要估计将 Nvidia 的服务性能应用于所有符合条件的 HBM,包括其他供应商使用的内存。
TrendForce 估计 Nvidia 在 2025 年占总 HBM 需求的 66%,并预测 2026 年为 58%。较早的 Epoch 估计将 2025 年份额定为 69%。这些需求和消费估计指导我们的敏感性范围,但不直接衡量我们出货量序列中的份额。
相对于主要估计的容量为 \(n + (1 - n)r\),其中 \(n\) 是 Nvidia 在符合条件的 HBM 中的份额,\(r\) 是其他供应商相对于 Nvidia 的每 GB 代理会话数。表 B5 对两者使用示例值。
| Nvidia 的 HBM 份额 | 非 Nvidia 性能 vs Nvidia | 总容量 vs 主要估计 |
|---|---|---|
| 70% | 75% | 92.5% |
| 70% | 50% | 85% |
| 60% | 75% | 90% |
| 60% | 50% | 80% |
| 50% | 75% | 87.5% |
| 50% | 50% | 75% |
表 B5. 不同加速器组合下相对于主要估计的容量。
这些情景将容量降低 7.5–25%,小于我们 \(K\) 和 HBM4 性能假设之间的数倍变化。
附录 C. HBM 规格
一个 HBM 堆栈包含多个垂直堆叠的 DRAM 裸片。表 C1 列出了代表性产品,而非每一代的固定限制。
| 代际 | 制造商 | 每堆栈容量 | 每堆栈 DRAM 裸片 | 每引脚数据速率 | 每堆栈带宽 |
|---|---|---|---|---|---|
| HBM2E | SK hynix | 16 GB | 8 | 3.6 Gb/s | 460 GB/s |
| HBM3 | SK hynix | 16 / 24 GB | 8 / 12 | 6.4 Gb/s | 819 GB/s |
| HBM3E | Micron | 24 / 36 GB | 8 / 12 | >9.2 Gb/s | >1,200 GB/s |
| HBM4 | Micron | 36 GB | 12 | >11 Gb/s | >2,800 GB/s |
表 C1. 每个 HBM 堆栈的制造商规格。GPU 可能以低于内存供应商标称最大值的运行速度使用多个堆栈。
附录 D. 代码
用于复现图表和追踪分析的代码:https://github.com/epoch-research/compute-to-agents
注释
-
这些区间假设每个活跃 agent 小时 30 美元,GB300 小时的参考租赁成本为 5 美元,API 收入/服务成本比为 5–10 倍。假设 HBM4/4E 系统每单位内存支持的 agent 数量是 HBM3E 系统的 1–4 倍。
-
20% 情景假设 40% 分配给产生收入的推理,利用率为 50%。我们使用中心硬件假设,以及 API 收入为参考服务成本的 5–10 倍,基于每 GB300 小时 5 美元的租赁价格。利用率衡量相对于估计服务容量的实际 agent 活动,考虑了流量波动、调度和机队管理摩擦。这些支出估计并非盈亏平衡收入要求。
-
我们在原始单位中,在相邻的前沿点之间进行线性插值。如果最慢的前沿点超过目标速度,我们使用该点而不进行外推。在两个目标上都没有合格结果的 GPU,包括 MI300X 和 MI325X,被省略。
-
我们认为闭源模型将处于这一范围的高端,因为与开源服务框架相比效率更高,并且能够收取溢价 API 价格。AgentX 基准比率在可预测的基准负载下,将假设的 API 计费与 GPU 租赁成本进行比较。\(K\) 是假设的收入/成本倍数。它并不衡量提供商的利润率。在固定 \(K\) 下,每个 agent 小时的支出越高,意味着服务成本越高,每个 GPU 的 agent 会话越少。如果只有 API 价格上涨,\(S\) 和 \(K\) 会一起上升,而物理容量保持不变。
-
两个数据集分析都将间隔上限设为五分钟,但对哪些间隔计入有不同的规则。TraceLab 移除明确标记的人类等待,并对未识别的间隔设上限,排除已知的工具调用工作。WEKA 合并父级和子级(子 agent)模型调用区间,并对它们之间的间隔设上限。WEKA 根据 token ID 计算理论前缀复用,而 TraceLab 使用观察到的缓存命中并根据缓存过期进行调整。绘制的样本包括 1,883 个 TraceLab 会话/模型组和 388 个 WEKA 根会话树,包括父级和子 agent 调用。两者都要求至少五个主要活跃分钟和正调整小时数。合并比率使用所有 5,079 个 TraceLab 组和 393 个 WEKA 树,包括短单元。
-
系统配置在同一 GPU 代际内也很重要。HGX B300 和 GB300 NVL72 使用 Blackwell Ultra GPU,但在互连和周边硬件上有所不同。我们的估计假设有合适的系统可用,以实现参考服务性能。如果 GPU 和 HBM 生产是约束瓶颈,持续需求可能会将生产转向这些配置,前提是其他组件和部署基础设施能够相应扩展。
-
对于图 2 中的曲线,更高的带宽可能意味着曲线向右移动,因为在相同并发下解码速度会提高。更高的容量则可能在顶部和左侧增加数据点,随着更高并发成为可能而延伸曲线。
-
中心估计假设 HBM4/4E 系统每单位内存支持的智能体数量是 HBM3E 系统的两倍;阴影部分将此范围从一倍到四倍变化。开放模型基准使用每用户每秒 50 token 的 P90 输出速度。闭源模型估计假设 API 收入是参考服务成本的 5–10 倍。参考服务成本使用每 GB300 小时 5 美元的租赁价格。两个轴均为对数轴,范围代表情景而非置信区间。
-
我们假设 API 收入是参考服务成本的 5–10 倍,使用每 GB300 小时 5 美元的租赁价格。这些是建模假设,并非对提供商实际利润率的估计。利用率衡量的是相对于估计服务容量的实际智能体活动,并考虑了流量波动、调度和机群管理摩擦;它不是 GPU FLOP 利用率。支出估计并非盈亏平衡收入要求。
-
我们用于外推的观测数据来自 Epoch 的收入数据集,总计 1105 亿美元,主要涉及 2026 年 7 月至 8 月。将每个观测数据从各自日期按年增长五倍进行外推,到 2027 年底年化收入约为 1.07 万亿美元。这是一个说明性的增长情景,并非预测或日历年收入估计。公司收入包含智能体 API 以外的产品。
-
我们的 HBM4/4E 提升考虑了每单位内存支持更多智能体,而支出比较则按不变的参考 API 价格对该活动进行估值。它没有建模效率提升被传导至更低价格的情况。例如,在硬件成本不变的情况下将服务容量翻倍,将允许价格减半,同时保持相同的收入/服务成本比和给定利用率下的收入。更低的单位硬件成本或更窄的利润率可能进一步降低价格。
-
例如,如果每项任务所需的计算量减半,任务量必须增加一倍以上,总计算使用量才会增加。Epoch 估计的价格下降涉及固定基准性能下的价格,而非直接涉及计算需求。
来源:Hacker News · epoch.ai