AWS公布SageMaker AI上MoE融合内核的三项优化，H200吞吐提升最高 10%
AWS机器学习博客介绍其为融合MoE模型实现的内核优化：Swap-AB提升WGMMA利用率、FP8量化改走Triton后端、消除Triton JIT重复编译。AWS称这些优化合计带来最高 10% 吞吐提升、首Token延迟最高改善 9%，并已开源并合入vLLM。
AI解读：AWS称三项优化合计在H200上带来最高 10% 端到端吞吐提升与最高 9% 的首Token延迟改善，这些数字来自其自身测试与实现说明。
Swap-AB针对Hopper WGMMA指令对矩阵行维度M=64 的固定要求，在解码阶段M极小的场景下将专家输出维度N（文中示例为 8192）换到首个操作数位置；AWS称此改动在大规模MoE模型上带来 2%–4% 端到端吞吐提升，已合入vLLM 0.24.0及以上版本。
FP8张量量化模型的MoE计算后端由默认FLASHINFER_CUTLASS改为Triton，AWS称其为纯配置变更、未改内核代码，在H200上使FP8融合MoE端到端吞吐提升 10%，该改进在AWS LMI v28容器中可用。
Triton默认对整型参数做特化，num_tokens等变长参数变化会触发JIT重编译；为 _fused_inv_rope_fp8_quant_per_head内核加上do_not_specialize注解后，AWS称 8 路张量并行下首Token延迟改善 9%，已合入vLLM 0.22.0及以上版本。
这些优化的适用范围限定在Hopper（H200）架构与融合MoE模型，且吞吐与延迟数字均为AWS单方描述，博客未给出与第三方方案的对比或独立复现结果。
AWS机器学习博客发布文章，介绍其为融合MoE（Mixture-of-Experts）模型实现的多项内核优化，作者为Mona Mona。文章称这些优化已开源并应用于Amazon SageMaker AI上的LMI Deep Learning Container。
MoE是稀疏激活架构，其算子在总计算时间中占比高。文章称融合MoE把token路由、数据重排和专家网络计算合并为GPU上的单一批处理操作，替代原先分离的顺序循环执行，代价是内核实现与调试复杂度上升。
Swap-AB：让WGMMA在解码阶段吃满 64 行
文章解释，NVIDIA Hopper的WGMMA指令在汇编层面把矩阵行维度M固定为 64，列维度N可变；操作数A映射在固定的M维度，操作数B通过共享内存描述符映射在可变的N维度，两者位置不可互换。因此M需达到或超过 64 才能避免执行通道空转。
标准MoE层专家计算写作A[M,K] x B[K,N] → C[M,N]，其中M为token行数、K为隐藏特征维度、N为专家输出维度。解码阶段每条用户序列一次只处理一个token，M极小（文中描述为M<64 甚至M=1），与Hopper的固定块高要求冲突，形成性能瓶颈。
AWS的做法是在矩阵乘法到达PTX汇编层之前做转置，把专家维度N放到第一个操作数位置。文章称这带来两点：N足够大（示例为 8192）可满足 64 行阈值；Hopper的硬件拷贝引擎可异步把大的连续权重块从共享内存预取到寄存器。
AWS称该优化在大规模MoE模型上带来 2%–4% 的端到端输出吞吐提升，运行在H200上，已上游合入vLLM 0.24.0或更高版本。
FP8量化：MoE后端默认路径改为Triton
文章称，vLLM的MoE oracle会把不同量化方案路由到Triton、FlashInfer+CUTLASS等后端。对Hopper上的FP8张量量化模型做性能剖析后发现，Triton后端持续优于默认的FLASHINFER_CUTLASS路径。
AWS给出的原因是：CUTLASS把FP8张量缩放、矩阵乘法和专家聚合视为离散操作，而Triton后端将整条流水线合并为一次硬件执行，数据从HBM只读取一次后在GPU本地SRAM与寄存器中处理完再写回，减少全局显存往返。文章还称CUTLASS针对密集、大尺寸、可预测的矩阵维度优化，在解码生成阶段M<64 或M=1 的极薄批次下会出现线程利用率偏低或内存填充开销，Triton后端则可动态映射碎片化的小token数组。
AWS称这项路由策略调整是纯配置变更、未修改内核代码，在H200上使FP8量化的融合MoE模型端到端吞吐提升 10%，该改进在AWS LMI v28容器中可用。
消除Triton JIT重复编译，改善首Token延迟
文章称，Triton默认对整型参数做特化，每当某个被特化参数出现新取值就触发一次JIT编译。在线服务中序列长度和批量大小持续变化，会不断产生编译开销，推高首Token延迟（TTFT）。
MoE模型服务中的 _fused_inv_rope_fp8_quant_per_head内核（融合旋转位置编码与FP8量化）会在每个新的num_tokens取值上重编译。AWS为变长参数加上do_not_specialize注解后，消除了这些重编译，并称在H200、8 路张量并行下首Token延迟改善 9%（PR #42849）。
文章还提到多GPU集群需要 8 张卡在内核执行上保持微秒级同步：只要一张卡因本地token批大小变化停下来重编译，其余 7 张就会空等。消除全集群重编译后，AWS称首Token延迟获得 9% 的加速，该优化已上游合入vLLM 0.22.0或更高版本。
结论与适用范围
文章结尾称，AWS与vLLM社区合作实现并开源了多项针对融合MoE模型的内核优化，合计带来最高 10% 吞吐提升和最高 9% 首Token延迟改善。
上述效果数字均由AWS在博客中描述，测试限于Hopper（H200）架构与融合MoE模型；文章未提供与竞品方案的对比，也未说明在其他硬件或非MoE模型上的表现。