推理能耗计算器：一个 Token 到底烧多少电？

所有推理成本问题，最终都回到一个物理约束：GPU 每秒能产多少 token、每度电能换多少 token。这篇文章从底层物理出发，用 Roofline 模型把这件事算明白。

为什么从「1 度电」说起

AI 算力成本有太多中间层报价：按 token 计价的 API、按 GPU 小时计价的云租、按服务器计价的采购……报价体系各不相同，直接比就是鸡同鸭讲。而电力是最底层的统一度量——无论你用什么 GPU、什么云、什么框架，最终都烧电。先把「一度电换多少 token」想清楚，就拿到了把一切报价换算成同一把尺子的能力。

一、底层物理：token 和电是怎么对应的

什么是 FLOPs：token 的成本单位

LLM 的每一次计算，归根结底都是矩阵乘法。模型每生成一个 token，就要对所有参数做一次前向计算，需要的算力约为：

推理：每生成 1 个 token ≈ 2N FLOPs（N = 激活参数量）

一个 70 亿参数（7B）的模型，生成 1 个 token 需要约 140 亿次浮点运算。700 亿参数（70B）则是 1400 亿次。这就是「模型越大越贵」的物理根源——不是玄学，是乘法算得多。

GPU 能提供多少算力：标称 FLOPS 的真相

GPU 厂商给的数字叫「理论峰值」：

1 TFLOPS = 每秒 1 万亿次浮点运算。理论上 H100 每秒能做 989 万亿次运算，够 7B 模型前向算 989/14 ≈ 7 万个 token。但——这是「理想真空中的 GPU」。

利用率的真相：理论峰值永远到不了

真实跑起来，GPU 不会满负荷。原因很多：等待数据搬运、通信同步、内存墙、调度空隙。衡量实际用上了多少，叫 MFU（Model FLOPs Utilization，模型算力利用率）：

有效算力 = 标称TFLOPS × MFU

• 大规模预训练，优秀集群 MFU ≈ 35%~50%
• 推理 serving，取决于并发和 batching，常落在 20%~50%
• 裸奔/低并发，<10% 很常见

同样的 H100，算力利用率差 5 倍，成本就差 5 倍。这是最重要的一个「软变量」。

二、推理的另一个天花板：显存带宽

训练是算力受限（FLOPS 打满），但推理的 decode（逐字生成）阶段是显存带宽受限——GPU 每生成一个 token，都要把模型全部权重从显存搬到计算单元一次。搬 140GB（70B 的 FP16 权重）需要的时间，取决于显存带宽：

decode 单路吞吐上限 ≈ 显存带宽 ÷ 权重字节数
ms/token = 1000 ÷ token/s = 权重字节数 ÷ 显存带宽 × 1000

所以「单卡跑 70B 只有 20 token/s」不是没优化，是物理定律。 权重太大，搬不过来。

一个 500 token 的回复——8B 约 2.4 秒，70B 约 21 秒。模型大近 10 倍，同一个回答慢近 10 倍。

三、Roofline 模型：一张图统一「算力墙」和「带宽墙」

前文反复出现两个「墙」：算力墙（标称 TFLOPS × MFU）和带宽墙（显存带宽 ÷ 权重字节）。Roofline 模型就是把它们画在一张图上的标准方法。

每生成一个 token 需要的时间，取两者中的较大值：

t_compute = 2N / (TFLOPS × 1e12 × MFU)             ← 算力墙
t_memory  = (N_total × bytes) / (BW × 1e9 × batch)  ← 带宽墙
t         = max(t_compute, t_memory)

• 当 t_compute > t_memory，GPU 被算力卡住，叫 compute bound
• 当 t_memory > t_compute，GPU 被带宽卡住，叫 memory bound

关键洞察：小 batch 时推理几乎总是 memory bound——GPU 大部分时间在等数据搬运，不是在算。这就是为什么 batching 是推理省钱的第一杠杆。

decode 每个 token 只算 2N FLOPs，但要搬 2N 字节权重（FP16），强度 = 2N/2N = 1 FLOP/Byte——离 H100 的拐点（989T÷3.35T ≈ 295 FLOPs/Byte）差了近 300 倍。只有让字节数变小（量化）或一次搬运喂多个 token（batching）才有用。

四、batching：把同一份权重摊给更多人

模型权重是「读一次，所有人都能用」的。如果一次只服务一个请求，那权重搬一遍只产生 1 个 token；如果一批同时服务 128 个请求，权重还是搬一遍，但一次产出 128 个 token。

这就是 vLLM、TensorRT-LLM 这类推理引擎的核心魔法：

聚合吞吐涨 100 多倍，单请求时延几乎不变。 batching 是「白赚」的——前提是你的并发请求数足够多，能把 batch 喂满。

成本差异一目了然（1×H100，18 元/小时，8B 模型）：

同样的模型，100 倍成本差，只差一个 batching。

五、算一个真实例子

以 DeepSeek-V4-Flash（284B 总参数、13B 激活参数）在 H100 上为例：

FP16 精度，batch = 32，MFU = 0.4，overclock = 1.5，PUE = 1.2

t_compute = 2 × 13e9 / (989e12 × 0.4) = 65.7 微秒
t_memory  = (284e9 × 2) / (3350e9 × 32) = 5.3 毫秒

t = max(65.7 微秒, 5.3 毫秒) = 5.3 毫秒 → memory bound
吞吐 = 1 / t ≈ 190 tokens/s

总参数 284B 的 FP16 权重就有 568GB，搬一遍要 169 毫秒；batch=32 摊薄后仍要 5.3 毫秒/token。而算力只要 65.7 微秒——GPU 几乎全程在等权重搬运。这就是 MoE 大总参数模型的代价：激活参数少（算得省），但单卡 decode 被带宽卡死，吞吐远低于同卡上的稠密小模型。

H100 整卡功耗 700W，考虑 overclock 和 PUE 后实际 1260W：

每度电产出 token = 3.6e6 / (1.26 × 5.3e-3) ≈ 54 万 token/kWh
每百万 token 电费（电价 0.8 元）≈ 1.5 元

换一张卡试试：RTX 4090（330 TFLOPS、1008 GB/s 带宽、450W）

t_compute = 2 × 13e9 / (330e12 × 0.4) = 197 微秒
t_memory  = (284e9 × 2) / (1008e9 × 32) = 17.6 毫秒

t = 17.6 毫秒 → 仍然 memory bound
吞吐 ≈ 57 tokens/s
每度电产出 token = 3.6e6 / (0.81 × 17.6e-3) ≈ 25 万 token/kWh

H100 比 4090 快 3 倍多，每度电产出也高约 2 倍（54 万 vs 25 万）。显存受限场景下，能效由「功耗/带宽比」决定：H100 是 700W ÷ 3.35TB/s ≈ 0.21，4090 是 450W ÷ 1.0TB/s ≈ 0.45——贵的卡在 decode 场景既更快也更省电。

六、不同模型的对比

规律：单卡 decode 吞吐几乎完全由「总参数（权重大小）」决定——权重越小搬得越快。稠密小模型（8B）单卡吞吐最高；MoE 模型（Flash、Pro、K3）激活参数少、算力省，但总参数巨大，权重搬运把单卡 decode 卡到很低。它们的高吞吐要靠大量并发把 batch 喂满才能兑现——batching 对这类模型更重要。而 KV cache 压缩路线（88KB~110KB 级）则让并发下的显存占用大幅下降。

七、1 度电 = 多少 token？答案揭晓

把两端接起来。1 度电 = 1 kWh = 一个 700W 的 GPU 跑约 1.43 小时。

前提：H100（700W）、FP16 无量化、推理 MFU 0.4 / 训练按 45% MFU 折算（含 overclock 1.5、PUE 1.2）。

三个结论，请记住：

• 1 度电产出 token 在 10^5 ~ 10^7 之间，跨两个数量级。 差距主要来自两个旋钮：模型规模（权重 ×10，token/度电 ÷10）和 batching/利用率（差 100 多倍）。
• 训练和推理的单位电效同量级。 训练每个 token 要 6N FLOPs，但算力受限、能打满；推理 decode 单路被带宽卡死，要靠 batching 追回来——8B 批量 128 的每度电产出（~7,000 万）比 8B 训练（~2,700 万）还高 2 倍多。
• 「1 度电产出多少 token」不是固定常数，是你能主动调节的指标。 同样的 8B，调好 batching 比裸奔高效 100 多倍。成本管理的第一课，就是别让 GPU 闲着。

八、把电换成钱：电费只是账单的零头

电价（中国 2026 量级）： 工业/商业电价约 0.5~1.0 元/kWh，取 0.7 元；数据中心还要乘 PUE（制冷损耗）≈1.4。所以数据中心里的 1 度电 ≈ 1 元。

按电费折算的每百万 token 成本：

电费便宜到近乎免费。 那 AI 账单的钱去哪了？

GPU 机时才是大头。 一台 H100 级云 GPU 约 18 元/小时，其中电费仅约 0.7 元/小时——电费占比不足 4%。 剩下的全是折旧摊销、制冷网络等基础设施、以及运维人力。

按 GPU 机时折算每百万 token（自建/云租，高利用率）：

自建 8B 只比「最便宜的托管 API」便宜一点。 一旦利用率掉下来，立刻被 API 反超。旗舰模型 API 贵在模型本身，不是推理开销。

一句话：电是成本里最便宜的部分，GPU 时间才是。 算成本永远先把「每 GPU 小时多少钱」算出来，别盯着电费单。

九、别忘了时延与并发：成本之外的第三条腿

成本不是唯一指标。生产系统还要满足：

• 时延 SLA：batch 越大聚合吞吐越高，但排队等待会拉长响应。交互场景（客服）要控制 batch 别塞太满；离线场景（批量生成）可以塞满。
• 并发与峰值：你的 QPS 曲线是平缓还是像心电图？峰值 > 均值 3~5 倍，自建就要按峰值备卡，均值时闲置烧钱。
• 推理的「不可能三角」：成本、时延、质量（模型大小），三者你只能优先两个。

十、这个计算器能帮你做什么

推理能耗计算器把上面的公式封装成了交互式界面：

• 选模型、选硬件，结果即时刷新
• 自动判断 compute bound 还是 memory bound
• 生成 batch 1 到 512 的能效曲线
• 输入电价，直接看每百万 token 电费

适合谁用：

• 评估自建推理的能耗成本
• 对比不同硬件的推理能效
• 理解 batching 对成本的影响量级
• 给客户做成本方案时提供数据支撑

局限

Roofline 模型给的是物理上限。实际推理还受这些因素影响：

• Prefill vs Decode：长 prompt 的 prefill 阶段是 compute bound，短 decode 阶段是 memory bound
• KV Cache 管理：PagedAttention、prefix caching 等工程优化不在模型内
• 量化：INT8/INT4 改变 bytes 取值，同时影响精度和带宽需求
• 通信开销：多卡 tensor parallel 的通信成本不在单卡模型内

这些不影响数量级估算，但做精确预算时要留 20-30% 余量。

关键公式

每token成本 = GPU小时价 ÷ (token/s × 3600)
token/s     = 有效算力 ÷ 每tokenFLOPs（推理2N / 训练6N）
推理单路上限 = 显存带宽 ÷ 权重字节数
ms/token    = 权重字节数 ÷ 显存带宽 × 1000
每度电token  = token/s × 3600 ÷ 功率kW