本期窗口：2026/9/10—9/16，日期按 UTC 归档。 正式版、预发布版、主干代码和本周公开的工程复盘分别标明；复盘引用的早期 PR 不重复算成本周新合并。
这周有几项更新很适合沿着实际请求看：H3 生成结束后，VAE 解码还在搬哪些中间张量；Kimi K3 推测解码时，调度器究竟留了多少 token 预算；MoE 降到 4 bit 后，权重的排列能不能被当前 kernel 直接消费。
下文分八组展开。MiniMax-H3 是音视频生成模型，MiniMax M3 是另一条大模型推理路线，两者的硬件配方与性能数字分开讨论。
本周版本与状态
| 项目 | 本期依据 | 当前应如何使用这些信息 |
|---|---|---|
| ComfyUI v0.36.0 | 9/15 正式发布 | 包含 H3 VAE 优化、循环节点、YuE2、Marigold v2 等；按工作流回归 |
| vLLM-Omni H3 工作流 | 9/16 合并 PR #7423、#7483 | 主干工作流与参考输入适配，不是 H3 新权重 |
| Kimi K3 / DSpark | 9/13、9/15 官方工程文章与 draft 模型卡 | 固定 commit、模型和负载复现；部分优化早于本周合并 |
| Chord | 9/15 工程文章与公开仓库 | W4A16 内核；indexed 路径可接入，grouped 框架集成仍在进行 |
| SGLang | 9/16 合并通信内核与 AMD 确定性修正 | 主干变更，使用包含对应提交的构建 |
| Transformer Engine v2.19 | 9/11 正式发布 | 新量化路径与 API 变更并存，另有 GDN 已知问题 |
| FlashAttention 4 beta31 | 9/16 预发布 | 对照目标 GPU、head dimension 和 mask 做测试 |
| FlashInfer v0.7.0rc3 | 9/16 候选版 | 本次发布列出的变更是 trace 注册清理 |
一、MiniMax-H3：VAE 开始减掉重复工作，ComfyUI 工作流继续补齐
ComfyUI 0.36：VAE 的优化落在中间张量上
9 月 15 日合并的 H3 VAE 优化 #16187 随后进入 v0.36.0。它把 3D 卷积周围的归一化、SiLU、padding 和 residual add 接到 comfy-kitchen 的融合路径，减少独立算子及中间读写；Attention、FeedForward 也接入带 RMSNorm、SwiGLU 和 residual 参数的线性层接口。
两个使用条件尤其重要。FP16 卷积路径要求用户启用 --fast fp16_accumulation，否则走 cuDNN；INT8 Attention 面向已经量化为 INT8 的 decoder，不是给普通 BF16 VAE 自动换一种精度。相应 kernel 不可用时，代码保留 eager fallback。
tiled_decode 会按空闲显存将至多四块 tile 放在一批处理。这样能多利用一些并行度，但显存不足时批量会收缩；更新后没有看到四块同时跑，不一定是优化失效。权重仍通过动态显存管理的取用接口进入算子。
这组 PR 没有提供可直接外推的统一端到端加速倍数。建议分开计时 denoising、VAE、音频处理和文件保存，避免主干采样没有变化，却用整段耗时去解释 VAE 的效果。另有 #16332 继续降低 VAE 占用。
循环节点：上一轮的图像与 prompt 可以作为下一轮状态
Generic Loops #16227 提供成对的 Start Loop / End Loop，支持固定次数、区间和列表三种迭代。循环携带一个值，但这个值可以是图像与文本组成的混合列表；上一段视频的尾帧也可以继续作为下一段的首帧条件。
执行时每轮会投影成普通调度节点，仍由原有队列执行。cache_iterations 控制迭代体能否复用缓存；保存、预览等副作用需要接入结束边界，确保每轮完成。它方便组织长流程，但不会自动保证跨段身份、运动和音画连续性。
v0.36.0 还收录 YuE2 音乐、Marigold v2、视频拼接以及 H3 ControlNet 的编译兼容修正。AMD Windows 的“4TB”改动针对虚拟地址额度，不是要求 4TB 内存，也不是新增 4TB 显存支持。
这一版同时出现 Flux Video Edit、Bria、Gemini 等 Partner Nodes。它们是远程服务接入，不能与本地开源模型支持混为一谈，运行前要核对账号、计费和输入数据去向。
来源：v0.36.0 发布说明。
vLLM-Omni：文本生成与多参考输入各补了一条路径
9 月 16 日的 #7423 增加 H3 文生视频/音频工作流 JSON 和说明，复用既有节点及 API。作者用 vLLM 0.29.0、两张 H20-3e、TP2、TORCH_SDPA 做了运行验证：1344×768、24 FPS、124 帧，五步采样，ComfyUI 到保存完成为 131.55 秒，文件含 32kHz 双声道 AAC。
这个结果证明链路能完成并生成可解码音视频；它没有评估完整 50 步 Base 质量，也没有做主观音频质量评测。五步配置的时间不应当被写成标准 Base 配方速度。
同日合并的 #7483 增加 references 与 Ref2VA 工作流，支持至多九张图、三段视频、三段音频，总数不超过十二，且至少含一张图或一段视频。PR 报告了双 A100 80GB 的单图参考运行；混合多参考和 Turbo 组合主要由本地测试覆盖，合并前基线变化后也没有重新跑完整 GPU 验证。
实际升级时，先保存一条短的固定 seed 样例，检查音轨和帧数，再扩大参考数量和时长。远端服务地址、模型名与服务端 LoRA 路径也要逐项对应；节点图可以导入，只完成了前端检查。
二、Kimi K3：本周的两组结果，分别看服务优化与 draft 训练
2.8 倍吞吐对应什么负载
vLLM 9 月 13 日的复盘，将 v0.27.1 与主干提交 82a85dc1 比较。环境是 B300 节点、CUDA 13.3、TP8、8K 输入/1K 输出，并启用八 token DSpark 推测；两组均关闭 prefix caching，因为旧版有相关问题。
| 并发 | 旧版吞吐（token/s） | 新提交吞吐（token/s） | 新提交平均 TTFT |
|---|---|---|---|
| 1 | 83.3 | 183.3 | 376.3 ms |
| 4 | 166.7 | 416.7 | 640.5 ms |
| 16 | 258.3 | 725.0 | 1121.0 ms |
这是固定合成负载上的累计优化结果；不能将并发 16 的 2.8 倍写成任何场景下的统一提升，prefix cache 相关优化的单项收益也不包含在这张关闭缓存的表里。
来源：9/13 性能复盘。
有些等待来自调度预算，而非 GEMM 太慢
调度器过去按配置允许的最大请求数预留推测空间，实际只有少数请求时，也可能提前扣掉大量 token 预算，导致本来能一次处理的 prefill 被拆开。自适应预算改用当前请求数计算预留，避免这种空占。
另一条改动把 MXFP4 的 top-k 输出合并延后到 latent-tail kernel，省去一次 launch 和中间张量读写。两项都没有改变模型参数量，但能削减每轮必经的开销。
这里引用的是本周复盘中的实现解释，相关 PR 早于本周已合并。复现累计曲线应使用文中固定提交；单独摘取某一个早期 PR，未必具有同样的模型加载与初始化条件。
来源：自适应 token 预算 #51725、MXFP4 latent-tail 融合 #53152。
DSpark：八个草稿位置，不代表每轮稳定接受八个 token
9 月 15 日公开的工程文章介绍了 RedHatAI 的 Kimi K3 DSpark draft：五层、每次起草八个位置。模型卡报告 math reasoning 的平均 acceptance length 为 6.42，HumanEval 为 4.96，QA 为 3.28。任务分布明显影响接受长度，数学场景的速度不能直接移到通用问答。
训练用 Speculators，将目标模型的 hidden-state 提取与 draft 训练放在不同节点组，通过 Mooncake 传输；这解决了大目标模型与训练任务难以同时驻留的资源安排。模型卡同时提供了训练和部署说明，部署涉及多节点、指定 Attention 后端与 KV 精度，不是替换一个模型名就完成。
对团队已有的 Kimi 服务，可以先按线上任务类型测接受长度，再看目标模型验证成本、draft 成本和排队时延。只提高 acceptance，而不测每轮耗时，可能选到更大却不更快的草稿模型。
三、Chord：Kimi K2.x 的 W4A16，要同时匹配布局和专家负载
Novita 的 Chord 面向 Kimi K2.x 的 MoE 形状，权重为 INT4、激活为 BF16，group size 为 32，scale 使用 BF16。公开接口提供 indexed 路径，以及针对 SM90 的 grouped prefill/decode 算子。
9 月 15 日的报告中，H200 EP8 prefill 相对 Humming 的层级测试提升约 1.11—1.20 倍，decode 约 1.16—1.24 倍；B300 EP8 decode 的 1.81—2.15 倍比较对象是未针对该场景调优的 Humming 默认配置。这些是所列 MoE 层形状的结果，不能等同完整 Kimi 服务提速。
它有两类容易踩坑的约束。
第一是权重布局。Indexed 的 profile 在模型加载时选择相应打包方式；grouped 的 masked decode 与 contiguous prefill 又使用不同的打包规格，不能拿同一个 buffer 互换调用。调参时应记录每个专家收到的 token 数，它决定了 kernel 实际看到的 M。
第二是集成状态。Indexed 路径兼容 Humming 导入接口，因而安装时不能与原 Humming 包同时占用同一个 import 名称；SM90 grouped 路径与 vLLM Humming 后端的完整集成仍标为 WIP。仓库还明确列出不支持的组合，升级时应按实际 checkpoint 的量化 schema 检查。
从内核看，小 M decode 仍可能选择 mma.sync 的 m16n8k16 路线；运行在 Blackwell 并不意味着每一个 GEMM 都会调用 tcgen05。这里优化的是具体形状下的调度和数据复用，硬件代际只决定有哪些候选路径。
四、MiniMax M3 / MI355X：局部形状变了，最优后端也会变
9 月 10 日的 vLLM 文章复盘了 MiniMax M3 在 AMD MI355X 上的累计优化。固定 8K 输入、1K 输出、TP4/EP1 的 MXFP8 路径中，并发 32 的输出吞吐从 109.1 提升到 342.4 token/s/GPU，平均 TPOT 从 69.1ms 降到 22.1ms。
文章还列出更高的 MXFP4 和 P/D 数字，但其中包含拓扑变化与不同计量口径：MXFP4 后期由 TP4 改为 TP2；P/D 的 6370.5 是 total tokens/s/GPU，不能放进 output tokens/s/GPU 那一列直接比较。
一个具体实现是共享专家融合。原先共享专家有独立 gate/up、激活、down 以及输出相加；改动将它作为每个 token 必选的专家槽，与路由专家一起执行 grouped GEMM。模型需要的数学计算仍在，单独的调度与中间存储被省掉。单项 PR 报告并发 1 提升 30.2%，并发 128 提升 5.6%，低并发更受益。
同一模型调 TP 还会改变后端可用性。文中 AITER 稀疏 Attention 路径要求每 rank 一个 KV head，TP4 满足，TP2 则使用 Triton fallback。跨层复用 sparse index 又是另一项工作：固定 8K/1K 比较不允许减少这部分架构计算，因此不能把允许复用的 AgentX 结果混入固定曲线。
复现这类优化时，除了保存 TP、精度和 batch，还应记录运行时选中的后端及每 rank 的局部张量形状。配置名字相同，不代表走到了相同算子。
五、分层 KV offload：GPU 先交给主机，再由主机管理慢存储
vLLM 9 月 10 日的文章解释了 Tiered KV Offloading 的设计。框架从 v0.22 已提供，本周的变化是系统性公开说明，不是刚刚第一次支持 offload。
数据路径以主机内存为中心：GPU KV 先复制到 CPU DRAM，再进入文件系统、对象存储或远端 peer；恢复则反向进行。D2H 完成后即可释放 GPU 空间，慢存储写入继续使用主机副本；回载时，数据准备好才分配 GPU 空间。
主机层本身是缓存，不只是中转站。多个 TP rank 的片段会汇入统一布局，二级存储面对的是较少、较大的 I/O。相同缓存数据由不同 TP 配置的节点使用时，也有一个统一的主机表示可衔接。
混合模型还需要同时保存 Attention KV 和状态空间层状态。文章列出 DeepSeek V4、GLM 5.3 等架构支持，但这不替代具体模型与 connector 组合的恢复测试。本期论文篇的 GLM-5.3 实验，正好展示了 token 计数、边界与数值路径会怎样影响续写。
部署时可先观察三类指标：每层缓存的命中率、传输字节及延迟、GPU 内存释放与重新分配时间。若多数请求没有共享前缀，增加慢存储可能只增加搬运；是否划算仍由真实请求复用决定。
来源：分层 KV 设计说明、配置与监控指南。
六、SGLang：DeepSeek V4.1 通信基础件，以及 AMD 确定性修正
把 MoE 尾部、归约和归一化接起来
9 月 16 日合并的 #39653 增加 DeepSeek V4.1 相关通信 kernel 与 wrapper。CustomAllReduceV2 提供 push/pull 路径，覆盖 AllReduce、AllGather、ReduceScatter，并允许组合 residual 等操作。
其中一条融合路径将延后的 MoE finalize、push AllReduce、shared expert 与 RMSNorm 连起来，同时保留规定的 BF16 舍入位置。另有 mHC 后混合、归一化和 FP8 量化组合；词表处理则可以根据大小选不同通信策略，greedy 采样交换局部最大值与位置，无需总是汇集完整 vocab logits。
这次 PR 是通信基础件，并不等于模型的所有调用点已在同一变更中接完。讨论中把部分模型接入放在另一条 PR，也没有给出统一端到端性能数字。代码阅读时应从实际调用条件进入，再看融合 kernel，而不是看名字包含 V4.1 就推定默认启用。
确定性模式下，AMD 不再走 Lean Attention
同日的 #37740 更小，也更直接。Lean Attention 会随 batch 大小改变浮点计算的分组；启用 deterministic inference 时，现在强制使用标准 Triton 路径。
普通 AMD 非确定性模式仍保留原来的 Lean 选择，NVIDIA 路径不受这次修改影响。它修正的是已识别的路径冲突，不是对所有平台、算子和调度方式的全局 bitwise 保证。
上期关注 Lean 的性能收益，这周则补上它的适用边界。如果工作负载要求稳定重放，应把确定性开关加入性能记录，不宜拿关闭开关的数字为开启后的服务作承诺。
七、Transformer Engine 2.19：低精度路径更多，升级前先看约束
9 月 11 日发布的 v2.19 中，比较值得跟进的是 MXFP8 与专家并行的衔接：NCCL-EP dispatch forward、combine backward 支持 MXFP8，GroupedLinear 和融合 grouped MLP 可以接收预量化输入。权重还增加显式启用的二维 block scaling。
更灵活的 CustomRecipe 允许行、列方向选择不同 quantizer，目前属于实验功能。把“低精度训练”拆成不同方向、不同张量来看，才有可能解释 forward 很快、weight gradient 却退步的情况。
Attention 侧加入实验性的 cuDNN GatedDeltaNetAttention，并扩展 packed THD、context parallel 和 FlashAttention 4 路径。但发布说明仍记录 head_dim=32 的 GDN backward 可能产生 NaN；修复已合并到 cuDNN frontend，仍需等待对应发布。这不是一个可以忽略的精度误差。
此外，版本收录了 cuBLAS grouped GEMM 修复 #3475，禁用 B300/Rubin 上受影响的 cuBLAS 13.7 算法以防静默数据损坏；CUDA Graph 修复 #2937 则避免后续 replay 覆盖先前保留的参数梯度。训练结果异常时，应优先排查这些已知正确性问题。
升级还有 API 成本：mHC projection 的 H 输出固定为 FP32；NCCL-EP bootstrap 需要 num_topk，部分参数位置与 token-count 字段也有变化。不要直接让旧训练脚本跨版本运行后，再把 shape 或 dtype 报错归因于模型。
八、FlashAttention / FlashInfer：测试版要按具体路径验收
FlashAttention 4 在 9 月 16 日发布 fa4-v4.0.0.beta31。本轮覆盖的场景相当具体：SM100 FlashMLA attention sink、head_dim=256 的双 CTA 路径与 paged KV、变长调度和输出对齐，以及 SM90 backward 的布局与流水修正。
还有两类更像“补边界”的改动：空 Q/K 的零梯度，以及 PackGQA 中 padding head dimension 的 predication。它们不会自然出现在常规长序列性能图里，却会影响真实训练或服务能否覆盖全部 shape。
因此，升级测试最好保留自己用到的 GPU、head dimension、causal/noncausal、varlen、paged KV 与 backward 组合。某一项配置通过，不能替代其他组合；名称中仍有 beta，也不应当按稳定版承诺使用。
FlashInfer 同日的 v0.7.0rc3 则很克制：release 列出的变更是移除过时的 diffusion_ops.minimax_h3 trace registry 条目。这是注册信息清理，不能据此宣布 H3 新增一次推理加速，也不等于整体删除 H3 支持。
来源：FlashAttention 4 beta31、FlashInfer 0.7.0rc3。
升级前留一份什么样的记录
如果本周只试一条路径，做 H3 工作流的可以从 ComfyUI VAE 更新开始；服务 Kimi 的可以先复现固定负载与 draft acceptance；训练侧则优先检查 Transformer Engine 的正确性修复和 API 变化。
每次对照至少保存 commit、模型 revision、量化格式、硬件、请求长度和真实后端；视频再补帧数、分辨率、采样步数和音轨。把冷启动、模型加载与稳定运行分开，把 TTFT、decode 和整段完成时间分开，数字才有可比性。
本周研究代码也有几个入口：OmniKVQuant 提供 Qwen Omni 的 2-bit KV 实验，mKernel 展开跨节点计算通信融合，vidax 给 Wan、LTX、Cosmos 等模型提供 JAX/TPU 路径。具体方法、实验和限制见同期 AIGC 论文一周。