Useful work, padded work, and the critical path有效工作、填充开销与关键路径
Three distinctions to make before interpreting an optimization result.解读一次优化结果前，先分清三件事。
Start with the boundary
Before comparing two implementations, name the output that counts as finished. A kernel boundary, a routed MoE layer and a complete request measure different things.
Useful work and executed work
Suppose four experts receive [64, 0, 0, 0] tokens. There are 64 useful token–expert assignments. A hypothetical implementation that reserves 64 slots for each expert provides 256 slots. That capacity is not a measured operation count: an implementation might skip empty slots or run a different kernel.
Use the distinction to ask a concrete question: does the implementation save launch overhead while executing or moving more data? Inspect the code and traces before answering.
Find the critical path
A shorter kernel does not automatically imply a shorter request. Dependencies, communication, synchronization and preparation can determine when the result becomes available. Record both the local boundary and the end-to-end boundary when making a performance claim.
Next step
Run a small expert-load experiment, then plan a paired comparison. The MoEFlow project connects these ideas to repository reports.
先定义测量边界
比较两种实现之前，先说明什么输出才算完成。一个内核、一个路由 MoE 层和一个完整请求，测量的是不同的事情。
有效工作与实际执行
假设四个专家分别接收 [64, 0, 0, 0] 个 Token，有效的 Token–专家分配共 64 次。如果一种假想实现给每个专家都预留 64 个位置，容量就是 256。容量不等于实测运算量：实现可能跳过空位置，也可能使用不同内核。
利用这个区分提出具体问题：实现是否在节省启动开销的同时，执行或搬运了更多数据？回答前需要检查代码与 Trace。
找到关键路径
内核变短不意味着请求必然更快。依赖、通信、同步与准备工作，都可能决定结果何时可用。给出性能判断时，同时记录局部边界与端到端边界。
下一步
先运行专家负载小实验，再设计配对对比。MoEFlow 项目提供相应仓库报告的入口。