DeepInfer 源码拆解（十九）：MFU 怎么算的——调度期 FLOPs 估算、FP8 等效口径与性能曲线对账

从第十八篇接上：一条很少被读的硬路径

本系列前十八篇把 DeepInfer 的骨架基本铺完了：从 LLMEngine.step() 到 KV 块账、EPLB、投机解码、C++ 调度器、Worker 握手，再到 Engram 的查表链路。这些路径决定「每一步跑什么、怎么跑」。还有一条路径不决定任何请求的去向，却决定每一次跑完之后屏幕上那个数字——MFU。

对推理框架来说，MFU（Model FLOPs Utilization）是一个绕不开的指标：它把「这一步实际做了多少模型计算」和「硬件这一段时间能提供多少计算」摆到同一个分母下，得到一个通常介于 0 和 1 之间的比值。模型改了、并行方式改了、YoCo 截断改了、指数器换成 FP4 了，这个比值都应该跟着动。但 MFU 本身不对应任何一次前向里的真实计算：它是调度阶段根据长度算出来的一份账，然后和实测耗时对账。

这篇只讲这条账本链路，按下面的顺序展开：

1. 一次 step 里，FLOPs 是在哪一行代码里被算出来的？为什么算在调度器而不是在 kernel 里插计数器？
2. FlopsEstimator 的「FP8 等效 FLOPs」口径怎么定义？为什么 FP4 权重只记 FP8 系数、为什么 BF16 记 4、FP8 记 2？
3. 注意力在一个混合了压缩 KV、top-k 选择、块候选、滑窗、局部指数器的模型里，怎么用一行前缀和公式把 token 对数量算出来？
4. MFU 的分母为什么是 BF16 峰值 × 2 × CP 规模，而不是整集群峰值或 DP 总数？它和实测 decode 性能曲线是什么关系——两套东西看似重复，各管什么？

读完应该能回答：给 DeepInfer 报一个 MFU 数字，这个数字背后假定了哪些事；模型结构一变，哪些假定的系数需要跟着改；哪些地方是故意「不精确」的。

一次 step 里的 FLOPs：在调度器里顺手算完

图源：DeepInfer 官方仓库 doc/images/architecture_overview.png。

先在调度器里定位。csrc/engine/scheduler.hpp 的 Scheduler::schedule() 会对本步被选中的每个序列组装一份 SequenceMetadata。组装完元数据之后，有一个很短的块：

1
// csrc/engine/scheduler.hpp, Scheduler::schedule
2
if (log_stats) {
3
    const bool is_prompt = scheduler_outputs.prompt_run;
4
    const int full_len = seq->input.tokens.get_len();
5
    const auto [attn, total] =
6
        flops_estimator->calc_flops(seqlen_q, seqlen_k, is_prompt, full_len, is_prompt ? seq->cache.swa_valid_start : 0);
7
    attn_flops += attn;
8
    total_flops += total;
9
}

循环结束后：

1
scheduler_outputs.attn_tflops = attn_flops / 1e12;
2
scheduler_outputs.total_tflops = total_flops / 1e12;

两个细节值得先记下来。

第一，只算「即将执行」的这一步，不算「已经执行」的那一步。 这里用的 seqlen_q、seqlen_k 是本步调度结果，而不是某次前向的输出。估算和调度在同一次 C++ 调用里完成，估算结果是「预期工作量」，随后跟着 SchedulerOutputs 一起交给 Worker。

第二，估算在 C++ 侧用整数完成，只有跨进程才变成浮点。 attn_flops 与 total_flops 都是 int64_t，累加后除以 $10^{12}$ 转成 TFLOPS 存进 scheduler_outputs。这样 SchedulerOutputs 传到 Python 侧时，日志里打印的 attn_TFLOPs 就是调度器的整数账除以 $10^{12}$，不存在跨调用累积的浮点误差。

1
step_stats = StepStats(
2
    prompt_run=scheduler_outputs.prompt_run,
3
    num_seqs=len(scheduler_outputs.scheduled_seqs),
4
    num_batched_tokens=scheduler_outputs.num_batched_tokens,
5
    ...
6
    attn_tflops=scheduler_outputs.attn_tflops,
7
    total_tflops=scheduler_outputs.total_tflops,
8
    ...
9
)

FlopsEstimator 的身份：一个为「V4.1-Flash 类模型」手写的解析器

csrc/engine/flops_estimator.hpp 是篇头那组注释定调的文件：

1
// Estimate main-model work in FP8-equivalent FLOPs; FP32/TF32 use weight 4.
2
// Count major contractions regardless of bottleneck; exclude draft/padding/replicas.
3
// MFU measures target-model FLOPs throughput; DFlash is extra compute used
4
// to accelerate that model, so its FLOPs are excluded.
5
// Omit small arithmetic (norms/activations). TODO: vision.
6
// Scheduled q/k ignore acceptance/ZOS corrections.

这五行注释几乎就是本篇的目录，一句一条原则：

• FP8 等效 FLOPs，系数表为 FP4=1、FP8=2、BF16=4、TF32=8。文件头说的「FP32/TF32 use weight 4」指的是 FP8 等效权重为 4，乘上 FMA 的 2 FLOPs 后落到 TF32 = 8。
• 只数主要的矩阵乘（contractions），不区分计算瓶颈还是带宽瓶颈。
• 排除草稿、padding、专家副本；DFlash 是「为了加速目标模型而付出的额外计算」，不计入 MFU 分子。
• 省略小算子（norm、激活），视觉塔也暂时没算。
• 按调度长度算，不考虑投机接受率、ZOS 的跨步修正。

这是一个明确写清口径边界的估算器：它不比任何一种实现更「真实」，但把「什么算、什么不算」写进了文件头。

构造时它会读一个 metadata 对象——来自 ModelMetadata，只依赖模型配置（层数、专家数、头数、压缩比、top-k、滑窗大小、指数器维度、Engram 配置等），不加载权重：

1
# deepinfer/engine/llm_engine.py, LLMEngine._create_scheduler
2
FlopsEstimator(
3
    self.model_metadata,
4
    yoco_mode=self.yoco_prefill_truncation_mode,
5
    keep_tokens=envs.DEEPINFER_YOCO_PREFILL_KEEP_TOKENS,
6
),

三个参数：元数据、YoCo 的 prefill 截断模式（off / mask / compact）、compact 模式下保留的尾部 token 数。后两个只影响 prefill 阶段的「consumer 行数」，在超连接（hc）系数与 compact 边界处会再遇到它们。

FlopsEstimator 在构造时把「每行 token 乘多少 FLOPs」的系数全部预先展开成标量：非注意力每行、logits 每行、注意力投影每行、一组 pair 系数、KProject 系数。真正被调用时只剩 calc_flops(q, k, is_prompt, full_len, swa_valid_start) 的开销。

1
int64_t calc_non_attn_flops(int full_rows, int consumer_rows) const {
2
    return full_rows * producer_non_attn_per_row + consumer_rows * consumer_non_attn_per_row;
3
}

非注意力系数：MLP、路由、超连接与 Engram

1
namespace flops_coef {
2
constexpr int64_t FP4 = 1;
3
constexpr int64_t FP8 = 2;
4
constexpr int64_t BF16 = 4;
5
constexpr int64_t TF32 = 8;
6
constexpr int64_t FP32 = TF32; // Accounting reference, not actual kernel precision.
7
}

1
static std::pair<int64_t, int64_t> mlp_flops_per_row(const py::object &metadata, int n_layer, int n_prefill_layer) {
2
    const int hidden = metadata.attr("n_embed").cast<int>();
3
    const int64_t coef = metadata.attr("fp8_mlp").cast<bool>() ? flops_coef::FP8 : flops_coef::BF16;
4
    // FP8 activations with FP4 expert weights retain the FP8 coefficient.
5
    // FP4 weight storage alone does not imply FP4 x FP4 compute.
6
    const int width = metadata.attr("moe_intermediate_size").cast<int>();
7
    const int experts = metadata.attr("moe_top_k").cast<int>() + metadata.attr("n_shared_experts").cast<int>();
8
    const int64_t per_row = coef * 3 * hidden * width * experts;
9
    return {n_prefill_layer * per_row, (n_layer - n_prefill_layer) * per_row};
10
}

1
static std::pair<int64_t, int64_t> router_flops_per_row(const py::object &metadata, int n_layer, int n_prefill_layer) {
2
    const int hidden = metadata.attr("n_embed").cast<int>();
3
    // Even fixed routing calls the gate GEMM before selecting indices.
4
    // Count logical experts, not redundant EP replicas or only top_k.
5
    const int64_t per_row = flops_coef::BF16 * hidden * metadata.attr("n_routed_experts").cast<int>();
6
    ...
7
}

1
const int64_t mix = flops_coef::FP32 * c * hidden;
2
const int64_t pre = flops_coef::TF32 * c * hidden * c * (c + 2) + mix;
3
const int64_t post = flops_coef::FP32 * c * (c + 1) * hidden;
4
const int64_t sublayer = pre + post;

1
// HCHead pads its projection to C*(C+2) outputs only to reuse a kernel;
2
// only C outputs are model work. Shifted HC has only the final mix.
3
const int64_t head = mix + (shifted ? 0 : flops_coef::TF32 * c * hidden * c);

1
const int64_t per_row = coef * embed * hidden * (c + 1) + flops_coef::FP32 * c * hidden;

1
logits_per_row = flops_coef::BF16 * hidden * vocab;

1
const int rows = is_prompt ? 1 : q;
2
return rows * logits_per_row;

注意力系数：投影层按层累加

init_attention() 是整个估算器最长的函数。它遍历全部 $L$ 层，把「投影类」成本逐层累加到 full_attn_per_row / consumer_attn_per_row，同时把「每个 token 对」的成本压进 pair_terms。先看投影部分：

1
int64_t q_coef = proj_coef * hidden * (q_rank + (swas[i] ? head_dim : 0));
2
q_coef += proj_coef * q_rank * (heads * head_dim + idx_h * idx_d);
3
q_coef += flops_coef::FP8 * heads * head_dim * o_dim;
4
q_coef += proj_coef * wv_groups * o_dim * hidden;
5
q_coef += flops_coef::BF16 * hidden * idx_h; // Indexer head weights.

逐项对应 MLA 注意力的结构：

• hidden × (q_rank + head_dim)：Q 的下投影 $[H] \times [r_q]$，以及滑窗层额外的一份 KV 投影（swas[i] 为真时多一份 $[H] \times[d_h]$）。
• q_rank × (heads * head_dim + idx_h * idx_d)：Q 的上投影 $[r_q] \times [n_h d_h + n_i d_i]$，其中第二项是指数器 Q 在同一投影里一并算出。
• FP8 × heads * head_dim * o_dim：Wv 投影，把注意力核的 latent 输出投到 $[n_h d_h] \times [n_o]$，固定 FP8。
• wv_groups * o_dim * hidden：输出投影 $[n_o] \times [H]$，按输出分组数 n_wv_group 算。
• BF16 × hidden * idx_h：指数器头权重，$[H] \times [n_i]$，固定 BF16。

这里两处固定精度的判断都值得注意：Wv 投影 FP8 × heads * head_dim * o_dim 是硬编码的 FP8，指数器头权重是硬编码的 BF16；其余投影才跟随 proj_coef。这些不是「大致估算」——它们对应模型配置里真实存在的 kernel 精度。

1
const int compressor_outputs = ratio == 1 ? 1 : 2;
2
if (kv_source)
3
    full_attn_per_row += flops_coef::BF16 * hidden * compressor_outputs * head_dim;

1
if (local_index && index_k_sources[i]) {
2
    const int64_t coef = flops_coef::BF16 * head_dim * idx_d;
3
    kproj_coefs[ratio] += coef;
4
    decode_kproj_per_row += coef;
5
}

每 token 对的成本：一个前缀和公式搞定三种注意力

到目前为止，投影成本都是「行数 × 每行系数」，线性可加。真正难算的是「query 与 key 的配对数量」：不同层、不同压缩比、top-k 截断、块候选、滑窗，每层的配对数量都不一样，而且 prefill 的每一行 query 对应的历史长度都不同。一个朴素的算法会为每个 query 行单独计算可见的 key 数，对 prefill 动辄几千上万行的 batch，这个内层循环会直接把调度器拖慢。

DeepInfer 的解法是把「配对数量」拆成几条可做前缀差分的算术序列。整个机制依赖两个静态函数：

1
// Sum floor(t / ratio), t=1..n: compressed query-key pairs without a cap.
2
static int64_t floor_prefix(int64_t n, int64_t ratio) {
3
    const int64_t blocks = n / ratio;
4
    return blocks * (n + 1) - ratio * blocks * (blocks + 1) / 2;
5
}
6

7
// Sum min(floor(t / ratio), cap), t=1..n.
8
static int64_t capped_prefix(int64_t n, int64_t ratio, int64_t cap) {
9
    const int64_t stop = std::min(n, ratio * cap);
10
    return floor_prefix(stop, ratio) + (n - stop) * cap;
11
}

先看 floor_prefix 的数学。设 query 的位置是 $t = 1, \dots, n$（1 基），如果每 ratio 个 key 压缩成一行，那么位于 $t$ 的 query 能看到 $\lfloor t / r \rfloor$ 行压缩 key。总和：

按 $\lfloor t/r \rfloor = m$ 分组：$m$ 取 $0$ 到 $M = \lfloor n/r \rfloor$，每个 $m$ 恰有 $r$ 个 $t$（最后一个组不完整）。于是

直接拆开等价于 floor_prefix 的闭式：

验证一下：$n = 5, r = 2$。$\lfloor t/2 \rfloor$ 依次为 $0, 1, 1, 2, 2$，和为 $6$。闭式 $M = 2$，$2 \times 6 - 2 \times 3 = 12 - 6 = 6$。对。再看 $n=6, r=2$：$0,1,1,2,2,3$ 和为 $9$；闭式 $M=3$，$3\times 7 - 2\times 6 = 21 - 12 = 9$。也对。

为什么用前缀和？ 因为区间 $[\text{begin}, \text{end})$ 内的配对数量等于「从 1 到 end 的数量」减去「从 1 到 begin 的数量」：

1
static int64_t pairs(int64_t begin, int64_t end, int64_t ratio, int64_t cap = 0) {
2
    if (cap == 0)
3
        return floor_prefix(end, ratio) - floor_prefix(begin, ratio);
4
    return capped_prefix(end, ratio, cap) - capped_prefix(begin, ratio, cap);
5
}

这样无论一次 prefill 有多少行，整个注意力配对计算只需要 $O(1)$ 的算术，与行数无关。注意 QueryRange 的 begin 是 query 区间的开边界：pairs(begin, end) 实际覆盖位置 $begin+1$ 到 $end$。

1
const int block = candidate_sizes[i];
2
// ceil(floor(t/r)/B) = floor((t+r*(B-1))/(r*B)). Fold all B
3
// slots of each selected block into the coefficient, including
4
// a partial final block. B=1 can share a core-attention count.
5
add_pairs(ratio * block, candidate_blocks[i], ratio * (block - 1), local_index_coef * block, compact_queries);

1
struct PairTerm {
2
    int64_t ratio;
3
    int cap;
4
    int64_t shift;
5
    int64_t full_coef, consumer_coef;
6
    int64_t count(const QueryRange &queries) const { return pairs(queries.begin + shift, queries.end + shift, ratio, cap); }
7
};

KProject 在 prefill 与 decode 的差异

1
int64_t calc_kproj_flops(const QueryRange &full, bool is_prompt) const {
2
    // Decode projects all q rows, including zeros at incomplete compression blocks.
3
    if (!is_prompt)
4
        return decode_kproj_per_row * full.rows();
5
    int64_t total = 0;
6
    for (const auto &[ratio, coef] : kproj_terms) {
7
        // Prefill packs completed blocks, keeping one placeholder if none complete.
8
        const int rows = std::max(1, full.end / ratio - full.begin / ratio);
9
        total += coef * rows;
10
    }
11
    return total;
12
}

为什么 prefill 只压缩完整块，decode 却按全部行算？decode 时每步只有一个新 token，这个 token 通常落在某个不完整压缩块的中间。KProject 仍然要为每个 token 算一遍（因为它们都会被后续的块复用），所以按 query 行数算、不看块边界。prefill 则相反：一个不完整的块会被打包到下一步，已完整的块一次性压缩，因此只算完整的块数，且至少一行占位（如果一块都没完成，仍然保留一行占位）。

这个小差异是「估算器贴合真实 kernel 分块策略」的另一个例子：估算规则不是「统一按行乘」，而是按 kernel 实际采用的压缩时机来。

logits 与视觉塔：边界之外的账

logits 上面已经讲过。视觉塔目前是明确不记账的：

1
// Omit small arithmetic (norms/activations). TODO: vision.

这意味着 V4.1-Flash 在多模态请求里，视觉编码器的矩阵乘不计入 MFU。这也是一个合理的边界：视觉塔只处理每张图一次，成本相对于每步长文本的低秩注意力小得多，而且它的执行时机和主模型 step 并不是一一对应的。

MFU 的分母：为什么是 BF16 峰值 × 2 × CP

LLMEngine 构造 StatsLogger 的时候：

1
# deepinfer/engine/llm_engine.py, LLMEngine.__init__
2
tflops_limit=get_bf16_tflops_limit() * 2,  # FP8-equivalent peak: 2x BF16.

get_bf16_tflops_limit() 在 deep_cluster/hardware/device.py 里：

1
def get_bf16_tflops_limit() -> int:
2
    if accelerator_kind() == "ascend":
3
        return 432
4
    if is_sm_major_10():
5
        return 2500 if platform.machine() in {"aarch64", "arm64"} else 2250
6
    raise RuntimeError("unknown GPU type")

也就是说：

• NVIDIA 的第 10 代架构（SM 主版本 10）：BF16 峰值 $2250$ TFLOPS（x86 主机），$2500$（ARM 主机）；
• Ascend：BF16 峰值 $432$ TFLOPS；
• 其他 GPU 直接抛错。

乘以 2 得到 FP8 峰值，作为分母。这就是「FP8 等效」的含义——它并非「分子用真实 FLOPs、分母用 FP8 峰值」，而是双向统一：分子把每个 MAC 折算成 FP8 单位，分母也用 FP8 峰值。

为什么分母按 CP 规模而不是集群规模

图源：DeepInfer 官方仓库 doc/images/wide_ep_decode_pareto.png。

1
def _mfu(self, now: float) -> float:
2
    entries = self._tflops.entries
3
    if len(entries) <= 1:
4
        return 0.0
5
    # 口径：首条仅作区间起点（值不计入），分母为首尾样本间隔、不延伸到 now（对比 _throughput；_tflops 每步都追加，实际末样本时间戳即 now）
6
    tflops_per_s = (sum(v for _, v, _ in entries) - entries[0][1]) / (entries[-1][0] - entries[0][0])
7
    return tflops_per_s / self._parallel_config.model_parallel_size / self._tflops_limit

注意 _parallel_config.model_parallel_size 在 ParallelConfig.__init__ 里：

1
self.model_parallel_size = self.context_parallel_size

也就是说，model_parallel_size 等于上下文并行度（CP），而不是整集群规模。在 DeepInfer 的拓扑里，DP Attention 意味着每个 DP rank 各自负责自己的 attention 段，model_parallel_size 在这里就是 CP 规模，所以 MFU 是每个 DP rank 内 CP 组各自的视角：分子是该 DP rank 自己的 total_tflops 求和（调度器每个 DP rank 各算各的），分母是该 DP rank 内 CP 卡数乘以单卡 FP8 峰值。

这样的口径在 DP Attention 下是合理的：一个 DP rank 上的 MoE 走 Wide-EP，attention 只处理自己这一段；一个 DP rank 的账本（total_tflops）反映的就是这一份 attention 加 MoE 的工作量。整个集群的 MFU 不可能由单进程的 _mfu() 给出，需要跨 DP rank 汇总。这也解释了为什么日志里每个 DP rank 各自打印 MFU，同一个 RANK 不同 GPU 的数字不会完全相同。

1
tflops_per_s = (sum(v for _, v, _ in entries) - entries[0][1]) / (entries[-1][0] - entries[0][0])

两套账：解析估算 vs 实测性能曲线

本系列第十二篇（CUDA Graph）拆过 profile_decode_perf()：用 CUDA Graph 在预热后对每个 batch size 重放一组测量，得到 (bs, ms) 曲线，写进 DecodePerfCache。第五篇（投机解码）拆过 mtp_varlen.hpp：ForwardRuntimeEstimator 在运行时用最近 5000 个样本对曲线做斜率修正。

看起来这套曲线也是「性能账」——为什么不能直接用它算 MFU？答案在两者回答的问题不同：

两者的关系是互补：曲线告诉你「一个 batch 要多久」，估算器告诉你「这个 batch 值多少模型计算」。

图源：DeepInfer 官方仓库 doc/images/decode_pareto.png。

曲线是为「变长投机」服务的，不是为 MFU 服务的。 曲线里每个点是「主模型 decode CUDA Graph 的一次重放耗时」，不含 DFlash 草稿图，也不含图外的采样与后处理。即便如此，它仍然是实测耗时，不是 FLOPs；拿它算 MFU 只能得到「这一 batch 的耗时」，得不到「这一 batch 值多少模型计算」。

曲线只在 decode 上测。 prefill 的 chunked 长度变化太多，不可能为每个长度 profile。所以要算 MFU，prefill 必须走估算器。既然 prefill 只能估算、decode 能实测，干脆两条路径都统一用估算器，避免口径分裂。

曲线是「耗时」，不是「工作量」。 MFU 需要的是 FLOPs；从耗时倒推 FLOPs 只有在「带宽/延迟都已知」的前提下才成立，而推理系统的瓶颈本身就是在带宽和计算之间移动的。用估算器算工作量、用曲线算耗时，两个量各自在自己的坐标系里，再相除得到 MFU，比「从曲线直接算 MFU」更干净。

反过来，两者在对账时相互约束：

• 如果估算器严重低估了工作量，MFU 会长期过低，曲线上的 batch 越大耗时越高，但估算工作量几乎不变，矛盾会暴露；
• 如果估算器高估，MFU 会长期过高，接近 1 甚至超过 1，也能被警觉。

一个完整的前向账本：把一段 prefill 逐项累加

前面的公式单独看都不难，但它们叠在一起时，一个具体 step 的 total_tflops 究竟由哪些项构成，往往要自己动手算一遍才清楚。这一节按调度器实际的调用顺序，把一个 prefill chunk 的账真正加一遍。

假设：模型有 $L = 3$ 层，每层都是压缩层，ratio = 4、topk = 8；n_prefill_layer = 2，YoCo 模式为 off；头数 $n_h = 32$，head_dim = 128，输出维度 o_dim = 64，q_lora_rank = 512，n_wv_group = 1；MLP 为 FP8，moe_intermediate_size = 512、top_k = 2、n_shared_experts = 1，逻辑专家数 $E = 64$；超连接与 Engram 都关闭。

本步调度一个 prefill 序列：seqlen_q = 256、seqlen_k = 1024（即这一块 prompt 已拼接到 1024），full_len = 1024，swa_valid_start = 0。这一块没有滑窗层。

第一步，确定行数。 is_prompt = true，start = k - q = 768；full_len 与 k 相等。因为 yoco_mode = off，compact = false、has_truncated_swa = false，所以 consumer = full，两排行数都是 256。

第二步，非注意力项。 producer 与 consumer 系数完全一样：

代入 $H = 7168$、$W = 512$、$V = 129280$（这里取一组便于手算、量级接近 V4.1-Flash 的参数）：

• MoE：$2 \times 3 \times 7168 \times 512 \times 3 \approx 6.6 \times 10^{7}$；
• 路由：$4 \times 7168 \times 64 \approx 1.8 \times 10^{6}$；
• logits：$4 \times 7168 \times 129280 \approx 3.7 \times 10^{9}$。

logits 一项比 MoE 每行成本大得多。但要注意 logits 在 prefill 时只算 1 行——calc_logits_flops 里 rows = is_prompt ? 1 : q。而 MoE 与路由按 256 行算，且要乘 3 层。所以这个 chunk 的非注意力总计是：

这里就出现了一个容易误读的地方：logits 系数虽然每行大，但只在 1 行上生效；MoE 系数小，却在 768 行上都生效。这也解释了为什么 decode（$q = 1$）时 logits 在 MFU 里会显得更可观——decode 步每一次都要算 1 行 logits，而此时 MoE 也只有 1 行。所以在 decode 的账里，logits 占比会从 prefill 的「几乎可忽略」跳到「不可忽略」。

第三步，投影项。 每层按 init_attention 的公式算一次 q_coef。仅以 Q 下投影、Q 上投影和输出投影三项为例：

第一项约 $7.3 \times 10^{6}$，第二项约 $4.2 \times 10^{6}$，第三项约 $5.2 \times 10^{5}$。再乘 256 行、3 层。

第四步，配对项。 本步 QueryRange 的 begin = 768、end = 1024，对应位置 $769$ 到 $1024$。核心注意力（ratio = 4、cap = 8）的配对数量：

capped_prefix 的 stop = 4 \times 8 = 32，这里远小于 1024，所以两项都落在「封顶后的线性段」：

于是差值 $= 8 \times (1024 - 768) = 2048$。这个结果很直观：既然 $t \ge 33$ 之后每行 query 都看见固定的 8 行压缩 key，那么落在 $[768, 1024)$ 的 256 行每行都是 8 对，总数就是 2048。在「已封顶」的区间里，前缀和差分退化为一个乘法——这就是为什么估算器对长上下文的 prefill 也几乎零成本。

核心注意力每对的系数是 $4 \times 2 \times n_h \times d_h \times$ 层数，乘以 2048 后再与其他层（如果有非压缩层）相加。

第五步，KProject。 本 chunk 中已完成的压缩块是 $\lfloor 1024/4 \rfloor - \lfloor 768/4 \rfloor = 64$ 个，KProject 按 64 行算，再乘每行的 $d_h \times d_i$ 系数；如果一个完整压缩块都没有，calc_kproj_flops 仍保留 1 行占位。

第六步，加总。 calc_flops 返回 (attn, total)：

写回 scheduler_outputs 时除以 $10^{12}$。这一步的值是「计划要做的计算」，不是「实际完成的计算」：这一步之后 GPU 前向里如果某个 kernel 因为 tile 边界多算了几个 padding 行，账本不会知道；如果某个层因为 KV 命中前缀缓存而没有执行压缩，账本同样不知道——调度器只按长度算。

第七步，（下一个 decode step 里）MFU。 统计器把每步的 total_tflops 追加进 _tflops 窗口，然后：

注意分子是「每秒完成了多少 FP8 等效 TFLOPS」，分母是「理论每秒能完成多少」。一个完整的 prefill+decode 混合负载下，MFU 的波动主要来自三项：(a) prefill 单块里 logits 只算 1 行带来的「有效算力偏高」；(b) decode 步里 logits 占比上升；(c) 投机 decode 步的 seqlen_q 是「计划验证长度」而非「接受长度」。

这个例子把前面几节的公式串成了一次完整的手算：行数怎么确定、系数怎么乘、配对数量怎么用前缀和差分、哪里会「只看计划长度」。如果下次拿到一段 DeepInfer 的日志，想核对 attn_TFLOPs 是否有异常，按同样的七步走一遍就是最快的检查方法。

读日志：MFU 出现异常时的排查顺序

StatsLogger 每次按 DEEPINFER_LOGGING_INTERVAL_STEP 打印一行，字段很多，和本篇直接相关的有：

异常一：MFU 长期大于 1。 先查分母口径。model_parallel_size 取的是 CP，不是 EP；如果部署里 EP 很大、CP 为 1，MoE 的工作量按逻辑专家数计入分子，分母却只有单卡峰值，数字当然可能超过 1。此时应该把 MFU 当成「单 DP rank 视角」而不是集群利用率，并检查是否误把多个 DP rank 的日志拼到一起统计。其次查 fp8_mlp / fp8_attn 元数据是否与实际 kernel 精度一致：如果模型实际跑 FP8 但元数据标记为 BF16，分子会偏高，MFU 也会偏高。

异常二：MFU 长期低于 0.1，但吞吐正常。 先看 attn_TFLOPs 占 total_tflops 的比例。如果模型是长上下文但 attn_TFLOPs 很小，可能是压缩比/top-k 把 attention 成本压得很低（这是正常的），而 MoE 与 logits 又按「每行系数」算，导致总量主要来自 MLP。再看 sum_seqlen_qxk 是否远大于 num_batched_tokens——如果是，说明上下文很长但压缩率很高，MFU 低不代表 kernel 慢，而是「有效计算本来就少」。最后再看 prefill_caching_rate：缓存命中越高，实际执行的 attention 越少，而估算器仍然按完整长度记账，这会高估实际 MFU（分子按完整长度算，分母却是缓存命中后更短的实际耗时）。

异常三：开启投机解码后 MFU 反而下降。 seqlen_q 是按「计划验证长度」算的，DFlash 草稿计算又被排除在分子之外。如果接受率低，实际有效 token 少，但账本仍按计划长度记账；同时 total_tflops 里的 MoE 是按草稿位置算的，可能高估工作量。正确的读法是：投机开启时把 MFU 当作「主模型计划工作量」的指标，而不是「实际产出」的指标；真正的产出效率要看 gen_tps 与接受率。

异常四：同一 RANK 的不同 GPU 的 MFU 不一致。 在 DP Attention + Wide-EP 下，每个 DP rank 的 batch 组成不同、每步的 sum_seqlen_qxk 不同，MoE 负载也不同。日志里的 moe_load_balance_ratio 可以对照看：如果负载比接近 1 而 MFU 差异仍大，差异更可能来自 attention 的上下文长度分布，而不是专家不均。

排查顺序建议： 先确认分母口径（CP/EP），再确认元数据的精度标记，再看 attn_TFLOPs 与 total_tflops 的比例，最后对照 sum_seqlen_qxk、prefill_caching_rate、moe_load_balance_ratio。这个顺序之所以有效，是因为前两项决定「账本本身是否合理」，后三项决定「这一步的负载结构是否特殊」。不要一看到 MFU 低就去查 kernel，绝大多数异常在账本口径上就能解释。

工程边界：估算器不知道的事

把前文的规则汇总，估算器有几处有意为之的「不知道」：

不知道投机接受率。 调度长度 seqlen_q 是「计划验证多少个位置」，而不是「实际接受多少个」。所以投机在 decode 步的 MFU 会按「计划长度」计算，接受率越低，这种误差越大。mtp_varlen.hpp 的注释也写了「Scheduled q/k ignore acceptance/ZOS corrections」。

不知道 ZOS 的跨步修正。 ZOS（零开销调度）下，CPU 侧的 seqlens_q/k 比 GPU 实际值滞后一步；估算器按 CPU 侧的值算，不做修正。

不知道草稿计算。 文件头明确排除 DFlash；calc_flops 只数主模型 attention 与 MoE。所以开投机时 MFU 不会因为额外的草稿前向而下降——它只衡量主模型的有效计算。

不知道 padding 与专家副本。 CUDA Graph 的 padding 行、EPLB 的冗余专家都不计入。

不知道非矩阵乘算子。 norm、激活、采样等小算子不计；视觉塔标记为 TODO。

不知道通信与访存。 账本只统计矩阵乘，不统计 all-reduce / dispatch / combine 的耗时，也不统计 KV 读取的带宽占用。所以 MFU 为 0.3 不代表「30% 的时间在干别的事」，而是「30% 的 FP8 算力峰值被矩阵乘有效利用」。

不知道真实的 kernel 分块。 估算器按模型结构参数算「理论工作量」，而真实 kernel 的分块策略会让实际计算量偏离。例如 attention 核的实际 tile 大小、KV 压缩核实际处理了多少 padding，都会让真实工作量偏离估算。这是所有解析估算器的共同边界。

这些边界不是缺陷，而是口径的定义：MFU 从定义上就是「主模型有效计算的 FP8 等效 FLOPs 占 FP8 峰值的比例」。一个估算器只要把它的「不算项」写清楚，它就可以长期可信。

一张可执行的读码路线

如果要自己读一遍这条链路，推荐顺序：

1. csrc/engine/scheduler.hpp 的 schedule()：先定位 if (log_stats) 那段，把 attn / total 的来源看清楚。
2. pybind_scheduler.cpp 与 llm_engine.py：SchedulerOutputs 到 StepStats 的字段传递，确认 total_tflops 在 StepStats 里的位置。
3. stats_logger.py 的 _record / _mfu / _build_log_messages：窗口规则与打印格式。
4. flops_estimator.hpp 的构造块：init_non_attention、init_logits、init_attention。
5. floor_prefix / capped_prefix / pairs / query_ranges：注意力配对的核心公式，建议结合 floor_prefix 的闭式自行推导一遍。
6. tests/engine/test_flops_estimator.py：这是估算器唯一可以直接运行的精度检验。它用一个逐层、逐 query 的参考实现，在 mode ∈ {off, mask, compact}、is_prompt ∈ {True, False} 下，对大量边界点（滑窗、压缩比、top-k、块候选的相邻值）与随机样本逐个比较 calc_flops 的返回值，并与估算器完全相等。这是理解「估算器什么时候算错」最快的路径。

与站内文章的衔接

• 计算量口径的底层是精度与浮点：浮点数与数值稳定性 讲清了 FP8/BF16 的位布局与缩放；MFU 里 FP4=1/FP8=2/BF16=4 的系数表就是这套精度层级在「算力账」上的映射。
• DeepGEMM 的 FP8 峰值实现与 DeepGEMM 完全拆解 里的 Hopper FP8 峰值，可以用来校验 get_bf16_tflops_limit() * 2 这个分母是否与真实 kernel 峰值一致。
• MLA 的 Q/KV 投影结构与 MLA 完全拆解 中 Q 下/上投影、KV 压缩的结构对应；init_attention 里投影系数与 MLA 矩阵乘一一对应。
• Engram 的投影成本：Engram 条件记忆 与 DeepInfer 源码拆解（十八） 讲了它的查表数据面，这篇的 engram_flops_per_row 是它的计算面。
• DFlash 草稿计算为何被排除：DeepInfer 源码完全拆解（五） 拆过 DFlash 的变长验证与置信度调度，文件头的 DFlash ... excluded 与那篇的「验证成本如何进入调度」正好是两面。
• CUDA Graph 与曲线：DeepInfer 源码完全拆解（十二） 讲清了 profile_decode_perf() 的测量流程；本篇「两套账」一节解释了为什么它不能被拿来算 MFU。
• TPU 的 Roofline 视角：TPU v1 完全拆解（二） 里「92 TOPS 的 MXU 平均只用 28%」与 MFU 为 0.3 这类数字是同一类问题——硬件算力峰值与实际有效利用之间的差距，来源可以是带宽、也可以是调度。

测试文件告诉了我们哪些「细节不能想当然」

tests/engine/test_flops_estimator.py 的参考实现对拍，是把估算器规则逐条写下来再与它对比的产物。读这份测试，能看出几处容易想当然的细节。

第一，compact 模式下「全被截断」的 chunk 仍执行一行。 参考实现里：

1
if consumer and mode == "compact":
2
    queries = positions[positions > cutoff]
3
    if len(queries) == 0:
4
        queries = positions[-1:]  # Fully clipped chunks still execute one row.

估算器对应的是 consumer.begin = std::clamp(cutoff, start, k - 1)。为什么不能是零行？因为在 GPU 上，一个被完全截断的块仍要走完前向的控制流，最后一行的 query 至少要存在。如果估算器把它算成 0，MFU 会在截断比例高的负载下被系统性低估。这是一个「真实 kernel 必须执行的控制流」被如实计入账本的例子。

第二，mask 与 compact 的差别在于 consumer 层是否保留 Engram。 测试 test_mask_consumer_engram 专门构造了一个「把 Engram 层号设为 n_prefill_layer」的模型，验证 mask 模式下 consumer 层仍计入 Engram 成本，而 compact 模式不计。原因不难理解：compact 的截断发生在层间，被截断的 query 不会再进入 consumer 层的 Engram；mask 模式则只是在注意力上屏蔽，行本身还在。

第三，SWA 的 swa_valid_start 在 compact 模式下被抬到 cutoff。 参考实现里：

1
valid_start = max(swa_valid_start, cutoff) if consumer else swa_valid_start

也就是说，截断后的 query 只能看到截断点之后的滑窗内容，而不是原序列的滑窗起点。这条规则与「compact 只保留尾部 token」的语义一致，但它直接影响滑窗配对数量——如果不按 max(valid_start, cutoff) 算，滑窗成本会被高估。

第四，边界点的覆盖是「区间两端各取 ±1」。 测试用 boundary - 1、boundary、boundary + 1 三组取值遍历所有压缩比、top-k、块候选尺寸与块数的边界。这恰好对应 floor_prefix 里最容易出错的「分组边界」：t % ratio == 0 与 t // ratio 进位的位置。这也是为什么本篇前面要用 $n=5, r=2$ 和 $n=6, r=2$ 两个例子去验证闭式——边界差一的错误往往只有在这类点上才暴露。

第五，超连接有两种布局。 test_non_attention_variants 把 fp8_attn、fp8_mlp、engram_fp8_proj 全部翻成 False，并分别测试 shifted = False/True。这意味着即使 checkpoint 是 FP8，估算器也必须能按 BF16 口径记账——因为模型结构里存在 BF16 层的可能性，而元数据决定了具体哪个口径。hc_shifted 为真时，第一层的 pre 混合没有 mix 项，这是结构差异而不是精度差异。

这份测试的存在意味着估算器的规则不是「凭感觉定的」，而是有一份可执行的规格。改动估算器时，先改测试里的参考实现，再改 C++，两条路径一致才算对。

从账本回到模型：改模型结构时，估算器要改哪里

前面逐项拆过的系数表，实际上就是一张「模型结构 → 计算量」的映射表。如果以后要换一个新的 V4 变体，或者把 DFlash 之外的某条分支搬进主模型，这张表能当作检查清单：

这张表的用法是：改模型前先对照，确认系数表已经覆盖了新结构；改完之后用 test_flops_estimator.py 的参考实现对拍。如果新结构只在某些层出现，参考实现与估算器要同时按「逐层遍历」的方式修改，否则对拍会给出大量不一致却难以定位。

需要强调的是：这张表不是用来让 MFU 好看，而是用来让 MFU 可比。 如果模型换了一种结构而估算器没有相应更新，MFU 在新旧模型之间就不再是同一把尺子，此时跨模型的 MFU 比较没有意义。这也是为什么文件头要把「什么算、什么不算」写死——口径稳定，才有跨版本比较的价值。

再看一个容易被忽略的边界：prefix caching。调度器按 seqlen_k 记账，但 prefill_caching_rate 显示命中前缀时，实际执行的 attention 计算变少。估算器没有把缓存命中折入账本，因此在高命中负载下，MFU 反而会被「按完整长度记账」拉高。这并不是 bug，而是口径选择：MFU 衡量的「本步工作量的 FP8 等效值」，不是「本步实际节省了多少」。如果要衡量缓存收益，应该看 prefill_caching_rate 和 TTFT 的变化，而不是 MFU。

同理，KV 压缩率越高，attention 的配对项越小，MFU 里 attention 的占比也越小。有人会因此觉得「压缩让 MFU 下降」，但 MFU 的绝对水平本来就随模型结构而变化，真正有意义的是同一模型、同一部署下的相对变化。

小结

把这条链路用一句话讲完：调度器在每次调度一个序列时，用 FlopsEstimator 把它本步的 query 行数、上下文长度、压缩比、top-k、滑窗、指数器选择折算成一对整数（.attn 与 .total，单位 FP8 等效 FLOPs），除以 $10^{12}$ 放进 SchedulerOutputs；StatsLogger 把这些数按窗口求和，除以「单卡 FP8 峰值 × CP 规模」得到 MFU。

要让 MFU 可信，有三条等价的前提：

• 分子和分母用同一把尺子：分子里每个 MAC 按精度折算成 FP8 单位，分母用 FP8 峰值，不做「真实 FLOPs / FP8 峰值」的混搭；
• 口径边界写清楚：草稿、padding、副本、ZOS 修正、接受率、视觉塔都不算，文件头写着；
• 估算器与实测曲线分开：估算器算工作量，曲线算耗时，二者不互相借用，各自在自己的坐标系里。

模型结构变化时，需要跟着改的是「系数」——例如新的专家并行方式要不要改路由系数、新的压缩块策略要不要改 KProject 的「只对完整块执行」规则。FlopsEstimator 的 init_* 函数就是这些系数的集合，改模型之前先读一遍它们，等于读了一遍这个模型的计算量结构。

下一篇计划把这条账本继续延伸：同一个 DP rank 上有些请求落在不满窗的短上下文、另一些落在满窗的长上下文时，total_tflops 的波动如何影响每个 rank 的 MFU、又如何与 EPLB 的专家重排相互约束；同时把普通引擎与 Wide-EP 引擎在同一负载下的 MFU 做一次对账，检验「排除副本」这一口径在两种部署形态下是否仍然可比。

参考资料

1. DeepInfer 源码：csrc/engine/flops_estimator.hpp（FLOPs 估算器与 FP8 等效系数表）https://github.com/deepseek-ai/DeepInfer/blob/main/csrc/engine/flops_estimator.hpp
2. DeepInfer 源码：csrc/engine/scheduler.hpp（Scheduler::schedule() 中的 calc_flops 调用与 attn_tflops / total_tflops）https://github.com/deepseek-ai/DeepInfer/blob/main/csrc/engine/scheduler.hpp
3. DeepInfer 源码：deepinfer/engine/stats_logger.py（_mfu 窗口、_throughput 口径与日志格式）https://github.com/deepseek-ai/DeepInfer/blob/main/deepinfer/engine/stats_logger.py
4. DeepInfer 源码：deepinfer/engine/llm_engine.py（tflops_limit 构造与 StepStats 打包）https://github.com/deepseek-ai/DeepInfer/blob/main/deepinfer/engine/llm_engine.py
5. DeepInfer 源码：deep_cluster/hardware/device.py（get_bf16_tflops_limit 与平台识别）https://github.com/deepseek-ai/DeepInfer/blob/main/deep_cluster/hardware/device.py
6. DeepInfer 测试：tests/engine/test_flops_estimator.py（逐层参考实现 vs 估算器的对拍）https://github.com/deepseek-ai/DeepInfer/blob/main/tests/engine/test_flops_estimator.py
7. DeepSeek-V3 Technical Report（arXiv:2412.19437）：MLA 的低秩 Q/KV 投影结构与 FP8 混合精度推理背景
8. 站内：DeepGEMM 完全拆解：Hopper FP8 峰值与细粒度缩放矩阵乘的实现
9. 站内：MLA 完全拆解：低秩压缩与矩阵吸收的完整公式
10. 站内：DeepInfer 源码拆解（十八）：Engram 条件记忆的推理路径：Engram 的查表数据面
11. 站内：DeepInfer 源码完全拆解（十二）：CUDA Graph 捕获与重放：decode 性能曲线的测量流程