2.1 生产环境配置

首先设定一个现实的生产环境：假设采用 72 张 H100 组成的集群，单卡每小时 2 美元，总成本为每小时 144 美元。

为满足生产环境的延迟要求，我们设定每个模型实例的批处理量（batch size）为 32 个并发请求，这比基准测试中可能出现的大批量处理更符合实际。通过对每个模型实例采用 8 路 GPU 进行张量并行，我们可在 72 颗 GPU 上同时运行 9 个模型实例。

2.2 预填充阶段（处理输入）

每张 H100 GPU 的显存（HBM）带宽约 3.35 TB/s，这将成为大多数工作负载的瓶颈。由于 37B 激活参数以 FP16 的精度存储需占用 74 GB 空间，每个实例每秒可完成约 3,350GB/s ÷ 74GB = 45 次前向传播（译者注：实际每秒能完成的前向传播次数不仅取决于显存带宽，还受到其他因素影响）。

关键在于：每次前向传播会同时处理所有序列中的所有词元（tokens）。当我们批量处理 32 条序列且每条序列平均包含 1000 个词元时，单次前向传播即可处理 32,000 个词元。这意味着每个实例每秒可处理 45 次前向传播 × 32k tokens = 144 万个 input tokens。9 个实例合计每秒处理 1300 万 input tokens，即每小时 468 亿 input tokens。

实际情况中，混合专家模型（MoE）可能需要为当前批次中不同词元加载不同的专家组合，若这些词元被路由到多样化的专家组合，可能使吞吐量降低 2-3 倍。然而在实际应用中，路由模式通常呈现围绕热门专家的聚集现象，且现代实现方案采用专家并行与容量因子等技术来维持效率，因此实际影响更可能接近 30%-50% 的降幅，而非最坏情况下的数值。

2.3 解码阶段（生成输出）

输出生成阶段则呈现完全不同的图景。此阶段需顺序生成词元 ------ 每次前向传播每个序列仅产生一个词元。因此每秒 45 次前向传播仅使每个实例每秒产生 45×32=1440 个 output tokens。9 个实例合计每秒 12,960 个 output tokens，即每小时 4670 万个 output tokens。

2.4 每个词元的原始成本

成本不对称性非常显著：input tokens 成本为 144 美元 ÷ 468 亿 = 每百万词元 0.003 美元，而 output tokens 成本为 144 美元 ÷ 4670 万 = 每百万词元 3.08 美元，存在千倍的差异！

2.5 当计算能力成为瓶颈

上述计算假设内存带宽是主要限制因素 ------ 这对典型工作负载确实成立。但在某些特定场景下，计算能力反而会成为系统瓶颈。当处理长上下文序列时，注意力计算量会随序列长度呈平方级增长。采用超大批处理数量并增加并行注意力头数，也会使系统从内存瓶颈转为计算瓶颈。

当上下文长度超过 128k 时，注意力矩阵会变得极其庞大，系统将从内存受限模式转为计算受限模式。对于超长上下文场景，这可能导致成本增长 2 到 10 倍。

这解释了某些有趣的产品决策：Claude Code 将上下文长度人为限制在 20 万词元 ------ 不仅是出于性能考量，更是为了将推理运算维持在低成本的内存受限状态，避免陷入高成本的计算受限长上下文场景。这也是为何服务商对 20 万 + 词元的上下文窗口会额外收费 ------ 因为其经济模型已发生本质变化。