从模型结构到计算负载

把模型中的计算拆出来测，需要先确定具体版本、输入输出、中间状态和数据移动方式。模型名字相同，不代表选取的计算内容相同。

这篇记录模型结构的阅读结果与 MoE 实验设计。材料核查日期是 2026-09-29，不包含 benchmark 测量结果。

先区分计算结构

现代大模型共享一些基础操作，同时在注意力、专家路由和残差连接上采用不同设计。下面的表格是阅读入口，具体语义仍需要沿代码核对。

模型	已核查的结构线索	相关计算
DeepSeek-V4-Pro	CSA/HCA 压缩注意力、DeepSeekMoE、mHC	KV 压缩、稀疏访问、专家计算与残差混合
Kimi K3	KDA 与 Gated MLA 混合、Stable LatentMoE、AttnRes	分块或递归状态、潜在空间专家计算、残差聚合
GLM-5.3	沿用 GLM-5.2 基座，配置含 MoE、稀疏索引与 IndexShare	索引生成、选择与聚集，以及跨层复用

GLM-5.3 与 GLM-5.3-Flash 需要分开记录。官方将后者描述为重新训练的基座，采用稀疏与线性混合注意力和 mHC；这些说明不能直接套到前者。

同一种模型的更新也不一定引入新算子。因此，后续目录会按计算语义和配置组织，再标记哪些模型使用它。

计划从 DeepSeek-V4-Pro 的一个常规 MoE 层开始。其参考实现区别了前部 hash-routing 层和后续常规路由，提取时需要先确定层类型。

在一个抽象的专家计算中，每个 token 被分配给若干专家，结果再按路由权重组合。计算可以分成以下环节：

MoE 子图的数据流示意。具体层还可能包含共享专家等分支，提取时逐项核对。

即便 token 总数相同，分到各专家的数量也可能不同。这会改变每个矩阵问题的形状、并行程度和数据移动。只观察一个 GEMM，容易漏掉重排和合并的代价。

先只考虑路由专家分支，可以用下面的抽象表达式界定合并语义：

y_t = \sum_{e \in S_t} g_{t,e}\, E_e(x_t)

这里 $S_t$ 是 token $t$ 选中的专家集合， $g_{t,e}$ 是对应权重， $E_e$ 是专家计算。这个表达式省略了共享专家等其他分支；具体的权重归一化和层内结构仍要对照所选实现核查。

实验关注专家负载偏斜和 token 布局怎样改变整个 MoE 子图的耗时。

这里的“子图”需要有明确边界。分别报告各环节和整体耗时，才能判断局部优化是否改变了总成本。

参考实现应先解释 token 如何选择专家、权重如何归一化、结果怎样合并，以及边界输入如何处理。随后用小规模输入核对优化实现。

这一阶段可以使用 BF16 或 FP32 参考精度，但必须标明它和原模型低精度路径的区别。结构相似并不自动意味着数值行为等价。

工作负载也需要注明来源：模型配置导出的规模、为了验证而缩小的规模、人工构造的路由分布，是三种不同的证据。人工分布有助于控制变量，但不能冒充真实推理 trace。

一张延迟图需要和复现条件一起阅读：

后续注意力实验还需要区分 prefill 与 decode，以及缓存或递归状态。不同语义的算法可以讨论代价与取舍，但不能作为同一个函数的等价实现来排名。

TritonBench 已提供算子性能测试；KernelBench 主要围绕模型生成 GPU kernel 的能力组织任务和评估工具。接下来会用一个案例检查它们的复用边界，再决定需要补充哪些工作负载描述和适配代码。

接下来先写清楚这个 MoE 子图要算什么、接受哪些输入，再动手写参考实现和测量代码。