模拟器建模指南：显存与吞吐公式

模拟器的价值不是给出一个看似精确的数字，而是把理论估计、部署配置、实测校准和未知项分开。只要 scope 或 resident layout 混淆，显存和吞吐结论都可能差一个并行度或格式开销。

本文定义最小建模合同。模型特有结构应作为插件参数进入，不在通用公式里硬编码。

1. 建模对象与状态

组成	生命周期	主要 scope	首选证据
Weights	常驻	per-rank，受 TP/PP/EP/replica 影响	loader 日志 + resident memory
KV / recurrent state	随请求增长	per-rank、per-request、per-block	allocator / block table
Activations	单次 forward 瞬态	per-rank、per-step	peak allocation / trace
Kernel workspace	算子或 graph 生命周期	per-rank、shape-dependent	backend 实测
Communication buffers	collective / connector	per-rank、拓扑相关	runtime 配置 + 实测
Runtime reserve	allocator、graph、碎片	per-rank	启动后与压力下水位

每个输出还应带状态：measured（当前 identity 实测）、estimated（公式估算）、missing（输入缺失）、unavailable（能力无法提供）或 not_comparable（identity 不同）。

场景输入不是结果校准：先做可交换性检查

最容易犯的建模错误，是把改变系统工作量的场景输入当成结果出来后的校准参数。后处理通常更快，也容易被 API、缓存和持久化层统一接入；但如果参数会改变算子输入、执行图、资源约束或配置优先级，后处理只能形成近似，不能替代原生仿真。

令 $S(c,h)$ 表示在配置 $c$ 和场景参数 $h$ 下执行仿真，$C_h$ 表示对 0 场景结果做后处理。进入架构设计前，先检查：

$$C_h(S(c,0))\stackrel{?}{=}S(c,h)$$

如果不相等，这个变换就不与仿真可交换。若系统还会搜索 TP/DP/EP/MoE-TP、Batch 或 placement，则还要检查：

$$\arg\max_c C_h(S(c,0)) \stackrel{?}{=} \arg\max_c S(c,h)$$

第二式不成立时，即使某个固定配置的 TTFT 修正看起来合理，也不能据此声称找到了目标场景的最优配置。

四个问题决定参数归属

问题	若答案为“会”	归属
会改变算子输入 shape、有效 token 数或执行次数吗？	GEMM、Attention、MoE 等工作量改变	模型层
会改变执行图、通信 payload 或 overlap 依赖吗？	critical path 与瓶颈可能迁移	模型层
会改变显存、Batch 上限或其他可行性约束吗？	候选集合本身改变	模型层
会改变候选配置的排序吗？	必须重新执行配置搜索	模型层

只有不改变上述物理语义、只影响参数校验、任务编排、缓存身份、并发保护、持久化、版本、provenance 或结果表达的能力，才应留在编排层。

KV hit 是典型反例

Prefix KV hit ratio $h$ 不只是“把 TTFT 乘一个系数”。它至少可能改变：

• Attention 的 causal interaction 区域；
• QKV/O projection、Dense FFN 和 MoE 的 miss token 数；
• MoE dispatch/combine 与其他 token-dependent communication 的 payload；
• KV load/transfer、显存占用、可用 Batch 与 admission；
• TP/DP/EP/MoE-TP 等候选配置的排序；
• compute、communication 与 transfer 的 overlap 关系。

因此，prefix、miss tokens、算子计算、通信量、显存和候选配置搜索应由模型层统一计算。编排层可以透传 KV/transfer/overlap 策略并管理结果，但不应根据 Attention、Communication、MoE 等展示标签猜测物理缩放规则。后处理模型仍可用于固定配置的敏感性分析、历史结果兼容和 native 实现的对照，但必须标为 estimated，且不能代替目标场景重跑。

验收必须覆盖物理不变量

缓存、持久化、数值比例和 API 闭环只能证明结果被正确编排，不能证明模型物理正确。至少增加以下断言：

1. KV hit 上升时，只由 miss tokens 驱动的 MoE dispatch/combine payload 单调下降；
2. 当 $h\to1$ 且 miss tokens 趋近于零时，token-dependent communication 趋近于零，只保留 launch、sync 等固定开销；
3. 在可解析的简单模型和固定配置上，native 仿真与后处理近似应在声明误差内一致；
4. workload 改变后必须重新评价候选配置，并允许排序发生变化；
5. 模型层输出算子、通信、显存和 overlap 证据；编排层只校验、缓存、持久化和展示这些证据。

可复用的判断规则是：

改变“系统看到的工作量”的参数放模型层；只改变“结果如何存取和表达”的能力放编排层。

2. Weights Memory [per-rank]

通用权重公式是：

$$M_{W,\text{rank}}=\sum_j\left(N_{j,\text{local}}b_{j,\text{payload}}+M_{j,\text{scale}}+M_{j,\text{metadata/padding}}\right)$$

其中 local 必须由真实 placement 得到。不能简单把总参数除以 tp × ep × pp：

• TP 只切其负责的矩阵；
• EP 只分散 routed experts，shared/dense 通常另有切法；
• PP 按 layer/stage 分配，不一定均匀；
• tied embedding、expert replica、padding 与冗余会改变结果。

FP4 的 scale 不能混写

4-bit payload 的逻辑下界约为：

$$M_{\text{payload}}=\left\lceil N_{\text{params}}/2\right\rceil\text{ bytes}$$

但两种常见配方的 block scale 不同：

格式	Block	Scale 类型	逻辑 block-scale 开销
NVFP4	16 values	E4M3	$\lceil N/16\rceil\times1$ byte
MXFP4	32 values	E8M0	$\lceil N/32\rceil\times1$ byte

NVFP4 还可能包含更高精度的 tensor-level scale；两者都可能因 tile 对齐、packing、padding 或 runtime 转换产生额外 resident bytes。不要再用一个通用 fp4 -> per-32 E8M0 分支同时代表 NVFP4 与 MXFP4；逻辑字节用于估算，容量判断优先使用实际 resident bytes。

3. KV / State Memory [per-rank, per-request]

对标准 KV Cache，可从每 token、每本地层的字节开始：

$$m_{\text{KV/token/layer/rank}}=2N_{\text{KV heads,local}}d_{\text{head}}b_{\text{KV}}$$

再叠加本地层数、请求和 block 分配：

$$M_{\text{KV,rank}}=\sum_rN_{\text{layers,local}}N_{\text{tokens,allocated}}(r)m_{\text{KV/token/layer/rank}}+M_{\text{metadata}}$$

Paged KV 使用已分配 block，而不是只用有效 token：

$$N_{\text{tokens,allocated}}=\left\lceil N_{\text{context}}/B_{\text{block}}\right\rceil B_{\text{block}}$$

MLA、稀疏/压缩 Attention、hybrid recurrent state 不能套同一个 head 公式；应提供 backend-specific layout，并分别标记 payload、index、state、load/transfer buffer。具体结构见 CSA/HCA 注意力 和 GDN 与 Chunked Prefill。

4. Activation / Workspace Memory [per-rank]

Activation 峰值随本轮 shape 变化，常出现在较大的 Prefill chunk，但这不是无需测量的定律。接口应接收 phase、scheduled tokens、hidden/intermediate dimensions、local heads/experts、dtype、kernel/backend 与 graph mode。

一个用于敏感性分析的粗估是：

$$M_A\propto N_{\text{scheduled tokens}}d_{\text{hidden}}b_{\text{activation}}\alpha_{\text{model/backend}}$$

$\alpha$ 不是固定常数：融合会复用 buffer，编译图可能预留 workspace，MoE、spec decode 与结构化输出还会新增瞬态张量。峰值必须以 allocator snapshot 或目标 shape 的运行结果校准。

5. MoE Workspace 与通信

MoE 需要分别建模 router/top-k metadata、dispatch/combine buffers、per-expert offsets/padding 与 grouped GEMM workspace。

Activation 发送量的起点可写为：

$$V_{\text{dispatch}}\propto N_{\text{tokens}}\times k\times d_{\text{hidden}}\times b_{\text{act}}$$

但 local expert 命中、路由倾斜、容量/padding、低精度通信与双缓冲都会改变 per-rank 字节。通信时间也不能只写 bytes / peak bandwidth：

$$T_{\text{comm}}=L(\text{message,topology,ranks})+V/B_{\text{effective}}$$

若与计算 overlap，模型只扣除未隐藏部分，并以 trace 校准 overlap ratio。MoE 数据流见 MoE 推理。

6. 低精度运行时能力合同

Checkpoint 名称不等于运行时能力。能力矩阵的 identity 至少包含 checkpoint recipe、GPU architecture、engine/version、kernel backend、operand dtype 与 scale layout；输出包括 executed kernel、resident bytes、workspace、conversion/fallback、质量/性能状态和证据。

FP4 checkpoint 可能原生执行、运行时转换、回退到更高精度或不支持。只有加载日志、resident memory 和 kernel trace 一致时，才能把“checkpoint 格式”提升为“实际执行格式”。

7. 吞吐、延迟与 Spec Decode

单步执行时间可以分解为：

$$T_{\text{step}}\approx\max(T_{\text{compute}},T_{\text{memory}},T_{\text{comm,overlapped}})+T_{\text{comm,unhidden}}+O_{\text{runtime}}$$

端到端还要加入 queue、scheduler、KV load/transfer 与 sampling。Prefill 和 Decode 应使用不同 shape 与校准曲线。

Speculative Decoding / MTP 不能建模成固定倍数。至少需要 draft/extra-head weights、workspace、draft tokens per verify、accepted-token distribution、verify cost、extra KV/state 与 scheduler interaction。模型原生 MTP 与独立 draft model 不能共享同一开销公式。

8. Per-rank vs Global/Cluster

量	Per-rank	Global / Cluster
Weights	当前 rank 实际 resident bytes	同一 replica 各 shard 求和；cluster 还包含 DP replica 与冗余
KV / state	当前 rank 的 pool 与占用	仅在 scope 一致时对 owner ranks 求和
Activation peak	当前 rank、当前 step 的峰值	通常看所有 rank 的最大值；不拿求和判断单卡 OOM
Throughput	rank/instance 口径需注明	可对独立 replica 求和；shard 内不能重复计 token
Batch / capacity	受最紧 rank 与 stage 约束	不是 per-rank × GPU 数 的通用关系

字段名最好直接编码 scope，例如 weight_resident_bytes_per_rank、request_tokens_per_second_per_replica 和 cluster_slo_goodput。

9. 配置项 vs Calibration Table

配置项描述部署计划：model/checkpoint、TP/EP/PP/DP/CP 与 placement、batch/concurrency、context/token budget、KV layout/dtype、weight recipe、engine/version/backend 与硬件拓扑。

Calibration Table描述精确 identity 下测到的 kernel_time(shape)、resident bytes、all-to-all latency、grouped GEMM efficiency、KV load/transfer latency 与 runtime reserve。

Calibration key 至少包含 model、hardware、engine version、kernel backend、precision recipe、parallelism 与 workload bucket。

Identity 不同的记录应是 not_comparable，而不是自动平均。

10. 不能硬编码的结论

1. Prefill 恒为 compute-bound、Decode 恒为 memory-bound；
2. 峰值 FLOPS/HBM/互联带宽等于有效能力；
3. expert 路由均匀、collective 完全 overlap；
4. prefix hit 免费，或 KV fragmentation 固定；
5. FP4 checkpoint 必然以 FP4 kernel 执行；
6. 某个框架/硬件组合固定快多少倍；
7. 未提供的数据等于零。

模拟器应同时输出假设、敏感性与最紧约束，让读者能回答“数字为什么是这样”和“换哪个输入会改变结论”。

相关页面

• MoE 推理
• 推理并行策略
• FP4/FP8 量化
• KV Cache Hit Ratio 修正模型
• Chunked Prefill 深入分析
• Serving Stack 与框架选型