为什么 FLOPS 越来越难以预测大模型的真实推理性能

示例文章 — 本文为布局测试用途，内容经过简化，不代表真实发布质量。

背景

在大模型发展的早期阶段，FLOPS（每秒浮点运算次数）是一个相当有用的代理指标： 给定模型参数量和序列长度，可以粗略估算一次前向传播的计算量，进而推断推理延迟和吞吐。

这个逻辑在 dense transformer 的静态推理场景下成立得相当好。

然而，随着推理系统变得越来越复杂，FLOPS 开始失去其预测力。

---

让 FLOPS 失效的几个机制

1. 稀疏激活（Sparse Activation）

以 Mixture-of-Experts（MoE）架构为例：

# 简化的 MoE 前向传播
def moe_forward(x, experts, router):
    gates = router(x)                      # [batch, n_experts]
    top_k_experts = gates.topk(k=2)        # 只激活 top-2
    output = sum(
        gate * expert(x)
        for gate, expert in top_k_experts
    )
    return output

一个拥有 8 个 expert 的 MoE 层，每次推理只激活 2 个。 从 FLOPS 角度看，这和激活全部 8 个 expert 差距显著； 但实际延迟取决于 routing 决策、expert 并行度和内存带宽，而非单纯的 FLOPS。

2. KV Cache 的内存带宽瓶颈

长序列推理的主要瓶颈通常不是计算，而是：

场景	主要瓶颈
Prefill（prompt 处理）	计算（FLOPS 相关）
Decode（逐 token 生成）	内存带宽（KV cache 读写）
长上下文（>100K tokens）	HBM 容量与带宽

在 decode 阶段，GPU 的利用率往往只有 20–40%，大量时间花在等待显存读写上。 此时堆砌 FLOPS 对实际吞吐几乎没有帮助。

3. 推测解码（Speculative Decoding）

推测解码用一个小的 draft model 预测多个 token，再用 target model 并行验证：

• 接受时：相当于用更少的实际 FLOPS 生成了更多 token
• 拒绝时：回退并重新生成，FLOPS 被浪费

最终有效吞吐取决于接受率（acceptance rate），而接受率又依赖 draft model 与 target model 的分布匹配程度 — 这完全不在 FLOPS 的预测范围内。

4. Test-Time Compute

Chain-of-thought、Best-of-N sampling、MCTS 式搜索等方法， 本质上是将推理时间换成更好的输出质量。

同样的模型，用 1 次 decode 和用 64 次 decode 做 Best-of-N， FLOPS 差了 64 倍，但对用户可见的”推理能力”来说，这个差距无法从模型参数量直接推断。

---

更合适的替代指标

当前的实践中，以下指标比 FLOPS 更直接地反映推理系统性能：

• TTFT（Time to First Token）：衡量 prefill 延迟
• TPOT（Time Per Output Token）：衡量 decode 吞吐
• MFU（Model FLOP Utilization）：衡量硬件利用率
• tokens/dollar：衡量经济效率

---

小结

FLOPS 仍然是理解模型训练成本的有效工具，但作为推理性能的预测指标， 它越来越像一个过度简化的抽象。 推理系统的性能已经被内存带宽、调度策略、稀疏性和 test-time 策略共同塑造。