本期窗口：2026/9/10—9/16，按 UTC 首次提交日期收录。 共选 16 篇论文，实验数字保留模型、硬件和对照范围；代码入口以发布时可访问的项目资料为准。
这一周，长上下文的代价被拆得更细了：专家权重可以留在 SSD，但要重新安排读取；KV 可以放到主机，却不能忽略筛选索引本身的带宽；混合模型恢复缓存时，还得把递归状态和计算路径一起对齐。
视频生成也有两组值得对照的结果。MiniMax-H3 的评测在问模型能否从多模态线索推断事件，几篇蒸馏论文则在追查少步生成为什么越来越“像同一个视频”。前者关心生成是否合理，后者关心速度之外还留下了多少变化。
一、长上下文：权重、索引和状态分别占多少成本
1. SSD-LLaMA：万亿模型能装下，离流畅交互还有多远
《SSD-LLaMA: SSD-Native Inference for Trillion-Parameter MoE at 1+ Token/s on a Consumer PC》（9 月 16 日）把专家权重组织成对齐的数据块，通过并发直接读取、固定的 pinned-memory 缓冲池和异步 H2D 传输，连接 SSD、内存、显存三层缓存。每个被 router 选中的专家仍然执行，不靠跳过专家换速度。
主要测试机器是 RTX 5090 32GB、16GB 主机内存和 4TB NVMe SSD，磁盘顺序读写能力约 9 GiB/s，batch 固定为 1。模型包括 DeepSeek-V4-Flash、Kimi-K2.7-Code 和 GLM-5.2。论文还测了 CPU/GPU 专家分工：其 DeepSeek 配置中，分给 CPU 一部分专家反而更慢，最终采用全部专家在 GPU 执行、CPU 管 I/O 的方案。
标题的“1+ token/s”需要拆开读。扩展到 Kimi K3 时，文末给出的 prefill 是 1.217 token/s，decode 是 0.465 token/s，后者约每 2.15 秒一个 token。论文摘要与正文列出的加速区间也不完全一致，因此这里不摘一个最高倍数代表全部测试。
这项工作展示了低内存机器的容量可行性。若目标是日常交互，还要逐项核对模型量化格式、磁盘容量、实际随机读取带宽和生成速度，不能只看“5090 能跑万亿模型”。
来源：论文全文与实验配置。
2. Fathom：KV 已经卸载，筛选时仍可能把主机带宽读满
Fathom（9 月 15 日）研究的是 host-offloaded KV 的稀疏 decode。只取少量重要 token 参加 Attention，并不代表前面寻找这些 token 的过程便宜：若每次都扫描完整索引，长上下文仍会被主机读取带宽限制。
方法把 4-bit Key 按通道拆成 bit-plane，再依据当前 Query 的重要性和统计量分配读取深度。重要通道多读几层，不重要通道少读；总预算控制的是实际读取的 bit，而不只是最后留下多少 token。
在 A100、Qwen3-8B、百万上下文的测试中，作者将对照统一到 4-bit 存储：每个 token、每层、每个 KV head 扫描 32 个通道，加上 scale 共读取 136 bit。Fathom 的 GPU decode step 相对这些对照最高加速 1.67 倍。相比读取 16 个通道的 SparQ，在相同 GPU 时间下，它少读 18% 字节，七组设置中六组的 Attention 误差更低。
收益来自主机索引的读取瓶颈；索引完全驻留 GPU 时，论文没有观察到同样优势。这里计量的是 decode step 的 GPU 时间，服务排队、CPU 调度等开销仍在计时范围之外。
来源：Fathom。
3. GLM-5.3-Flash 缓存恢复：token 对了，计数和计算路径也要对
《Validating Hybrid-State Cache Recovery for GLM-5.3-Flash with vLLM and LMCache》（9 月 14 日）直接处理混合架构的缓存正确性。测试使用完整 45 层的 RedHatAI/GLM-5.3-Flash-NVFP4，TP4；恢复对象同时包含 Attention KV 与混合层状态。
难点出在几个很小的边界：全命中时恢复了完整 prompt，调度器却少记一个 token；部分前缀命中需要严格对齐；即使 checkpoint 一样，共享计算和各 rank 选择的 kernel 配置不同，也可能让续写分叉。
修正后，九种长度的串行检查从 34/36 提高到 36/36，比较的是后续 64 个 token ID。作者另在两个新容器内做了 72 组成对的 256-token 续写检查；120 个串行请求的对照中，CPU reload 的 TTFT 下降 46%—64%，端到端时间下降 1.9%—7%。
后一个差距很有解释力：省掉 prefill，不代表同样比例地省掉整个回答时间。实验还依赖指定修订和修改过的 recompute 对照，不宜直接推导高并发容量或所有版本的确定性。
来源：论文与恢复验证记录。
4. ASPIRE：同一个 batch 里，有的请求起草，有的请求验证
ASPIRE（9 月 16 日）采用稀疏 Attention 起草、完整 Attention 验证的自推测解码。常规同步调度要求一个 batch 的请求一起切换阶段；接受率不同的请求容易互相等待，统一 draft 长度也未必划算。
它把阶段推进下放到每个请求，在一次混合前向里同时容纳 draft 和 verification，再依据接受率与 batch 成本调整起草长度。起草过程中保留一个完整 Attention 刷新层，帮助稀疏路径跟上上下文。
实验在单张 H100 NVL 96GB 上使用 BF16、torch.compile 和 CUDA Graph，测试 Qwen3-1.7B、Qwen3-8B、DeepSeek-R1-Distill-LLaMA-8B。相对自回归基线，仅 decode 前向吞吐加速 1.70—4.58 倍；最高值来自 Qwen3-1.7B 的长上下文测试。计时不含 prefill，不能拿这个倍数估算首次响应。
复现时可以先对比固定 draft 长度与按请求调整两种调度：接受率相近时，差异就更多来自 batch 的组织与验证成本。
来源：ASPIRE。
二、低比特与 MoE：同样的预算，给谁更合适
5. OmniKVQuant：音频与视频的 KV 不必共用一套统计
OmniKVQuant（9 月 10 日）把 KV 量化推进到 Qwen2.5-Omni、Qwen3-Omni 一类音视频模型。论文指出，Key 的时间漂移与不同模态 Value 的分布差异，会削弱直接照搬文本量化方法的效果。
它用短时间窗估计 Key 范围，并为不同模态准备 Value 旋转。作者在七个音视频基准上评估 2-bit KV；实现上的重点是融合 Triton decode kernel，让 packed 2-bit 数据在 Attention 内部解包，而非先生成一整份 FP16 KV 再调用普通 Attention。
官方仓库已经提供旋转参数、量化缓存、融合内核、TurboQuant 对照和 WorldSense 评测入口。它属于免训练方法，但 Value 旋转仍有校准过程，仓库也提供重新校准脚本；“免训练”和“不需要任何数据准备”是两回事。
复现时值得同时看问答准确率、缓存实际占用和 decode 延迟。仅按 16 bit 降到 2 bit 计算，得到的八倍是原始数据位宽比，不包含 scale、索引和临时空间。
6. Colla-Q：别让量化误差集中压垮少数专家
Colla-Q（9 月 16 日）研究混合位宽的专家分配。只按路由频率分配 bit，容易把低频但承担特定能力的专家压得过低；只优化平均误差，也可能掩盖个别专家的严重退化。
论文使用激活熵衡量专家信息，再通过 minimax precision balancing 分配预算，优先缓解最薄弱专家的加权误差。这里的 minimax 是优化准则，与 MiniMax 模型系列无关。
实验覆盖 Mixtral 8×7B、DeepSeek-MoE-16B-Base 和 Phi3.5-MoE，并比较不同平均位宽、不同校准集下的零样本任务表现。证据范围仍是这三类模型。论文链接的官方仓库目前只有 LICENSE，尚无可运行的量化实现。
如果正在做专家混合精度，这篇适合与“按路由概率保留专家”的方法对读：位宽分配、专家选择和实际 GEMM 布局是三层问题。得到一份更好的 bit 配置后，还需要内核真正支持这些组合，才有部署收益。
来源：论文、官方仓库（实现尚未上传）。
三、训练与内核：峰值发生在哪一瞬间
7. Flattening Every Memory Peak：长上下文 MoE 不止一个显存峰
《Flattening Every Memory Peak in Long-Context Mixture-of-Experts Training》（9 月 13 日）把显存压力分成四处：专家 dispatch、词表投影、跨层 checkpoint 边界和 optimizer state。压下第一处后，下一处会成为新的 OOM 来源。
对应的四个改动是分块流水的 LLEP、环形分布式词表投影 Ring-DTP、长期激活的 CPU offload，以及分桶流水的 OffloadStreamAdamW。词表投影用在线 log-sum-exp 累积精确 loss，避免一次铺开完整 tokens×vocab 张量。
端到端实验使用同一架构的 120B、241B、667B 从头初始化模型，分别运行在 16、32、64 张 H200 上，并非三个同名公开 checkpoint。组合方案均能训练百万上下文；对照是作者在相同模型和卡数下搜索得到的 FSDP2 最佳配置。10.4 倍吞吐对应 667B、64K 长度的特定比较，不是所有百万上下文配置的统一提升。
排查长序列 OOM 时，这四类峰值可以直接作为检查顺序：dispatch 缓冲、词表 logits、checkpoint 边界、optimizer staging。静态参数量不变，它们的同时存活时间却能相差很大。
8. mKernel：把节点内与节点间通信放进同一个融合计划
mKernel（9 月 11 日）将持久化 kernel 的 SM 分给计算与通信，并由 GPU 侧控制器调整分工。Tile 产出后即可触发后续搬运，节点内走 NVLink，节点间通过 GPU 队列和主机代理提交 RDMA。
这保留了 host-assisted 网络路径，而非要求所有网络操作都由 GPU 直接驱动。论文在两个各含 16 张 H200 的集群上测试 InfiniBand 与 AWS EFA，GEMM+AllReduce 最高加速 1.72 倍，Ring Attention 最高 1.88 倍；其测试中 IBGDA 相比主机辅助并未带来很大额外收益。
代码已公开，默认构建目标是 Hopper sm_90a，提供 CX7 与 EFA 后端。它适合作为通信—计算融合的阅读材料，不能把“跨节点”理解成任意网络和任意 GPU 都可直接复用。
沿着 tile 的生产、通知、发送和消费次序读实现，能看到哪些等待被隐藏了；同时也要看通信占用 SM 后，GEMM 少了多少执行资源。
9. ForgeMegakernel：让代码生成经过中间状态检查
ForgeMegakernel（9 月 11 日）尝试自动生成完整 autoregressive decode megakernel。它把工作分成十个递进里程碑，除了最终输出，还设置独立的中间状态检查，避免错误被后续算子掩盖。
执行层使用每个 SM 的细粒度指令、依赖计数和共享内存池，让算子按真实依赖推进，减少全局 barrier。作者为八类模型生成 14 个 megakernel，覆盖 0.6B—13B，测试包括 Qwen3、Llama 和 MiniCPM。
在 H100 80GB 的匹配配置中，相对 SGLang 0.5.18 的几何平均加速为 1.21 倍，相对所比较的 megakernel compiler 为 1.54 倍，报告的显存带宽利用率为 50.5%—85.9%。这些结果集中在 decode 和单一 GPU 架构，不能替代高并发服务测试。
人工优化也能借用这种检查方式：让每一轮融合都经过独立中间张量对照，定位第一次偏离，再决定回退哪一步。最终 token 一致只是检查的最后一层。
来源：论文与验证流程。
10. OPEN-1B：开放训练过程，也提供逐步重放入口
OPEN-1B（9 月 15 日）关注可审计训练。其公开模型总参数约 1.61B、非 embedding 参数约 1.08B，使用 400B token 训练。项目为 80,957 次 optimizer step 记录状态哈希，并提供训练和重放工具。
要跨设备重放到相同 bit，仅固定 seed 不够。它同时固定算子归约、初始化随机流、数据顺序、跨 rank 梯度合并和裁剪次序，CPU、CUDA、Metal 的敏感操作走匹配实现。
仓库明确区分初始化检查与训练区间重放。相同哈希说明指定输入、代码和后端在所测区间产生了预期状态，对历史执行过程的证明范围有限；当前哈希也未覆盖全部运行时状态。
对复现研究而言，最有价值的是把检查单位降到单个区间。无需重新承担整次预训练成本，也能检查自己关心的一段；相应地，报告时必须写明检查了哪些 step、用的哪组制品。
四、视频生成：合理性、多样性与交互
11. MiniMax-H3 物理推理评测：线索给齐了，模型能接起来吗
《Can MiniMax-H3 Reason About the Physical World?》（9 月 16 日）没有让 prompt 把目标动作说明白，而是将必要信息分散到多个视角、声音和视频片段中，再检查生成结果是否完成了隐含任务。
四类场景分别考察多视角空间推理、声音消歧、视频决策和视听整合。517 个样本由三位专家独立评价并交叉检查，总成功率为 41.97%；视频决策为 56.00%，声音消歧为 27.40%。
各组任务、数据和生成目标不同，分项差距还不足以孤立比较视觉与音频能力。生成结果同时受理解、推理和渲染能力影响，失败案例也需要进一步拆解。这是一项独立评测，测试对象仍是已有的 H3。
它提供了一种比“画面看起来符合物理”更具体的测试方式：先说明哪个线索只能从某个输入获得，再看模型有没有真正用上。做多参考视频工作流时，也可以照这个思路构造自己的验收样本。
12. Uncertainty DMD：视频的多样性可能在第一块就丢了
Uncertainty DMD（9 月 10 日）分析少步自回归视频蒸馏中的多样性下降。作者观察到，首个 chunk 在不同 seed 下趋同后，后续确定性的缓存传递会继续延长这种相似性。
方案在首块加入时间步扰动，在后续块使用带随机性的 cache 写入，并让训练与推理使用一致的扰动机制。它不更换网络架构，目标是在接近原有质量的情况下恢复内容与运动变化。
这里改变的是蒸馏训练及其配套推理过程，不能直接解释为“给现成模型的 KV 随机加噪就会更好”。如果训练从未见过那种状态扰动，推理时临时加入反而可能让时间一致性更差。
看示例时不妨把同一 prompt 的多个 seed 并排放，而不是只挑一条最好看的视频。少步模型能否生成不同但合理的运动，往往在这种对照里更容易暴露。
来源：Uncertainty DMD。
13. CrossDistill：高噪声阶段保留选择，低噪声阶段修细节
CrossDistill（9 月 13 日）也处理质量与多样性的取舍，但从整条去噪轨迹入手。高噪声阶段决定较大的内容与运动模式，低噪声阶段则更多影响细节；同一种蒸馏目标未必适合从头用到尾。
它在高噪声部分使用保留轨迹的目标，在低噪声部分使用分布匹配，并通过 crossover state 连接两段。论文给出了 PCM、DMD 等目标的组合实例，重点在于两段轨迹怎样衔接，而非简单把两个 loss 相加。
实验主要提供文本生成视频结果，图生视频部分还包含定性展示。读者若想迁移到特定的 Wan 或 H3 工作流，应先核对训练目标、采样器和模型条件，而不要仅把 crossover 理解成一个通用的推理参数。
与上一项合起来看，两篇都提醒我们：多样性损失有具体发生位置。训练目标怎么分段、首块如何确定、缓存如何传下去，需要分别做消融。
来源：CrossDistill。
14. ReCAST：多奖励扩散 RL，奖励权重与时间步分配分开调
ReCAST（9 月 11 日）讨论多奖励在线扩散强化学习。用户给不同 reward 的权重，表达的是最终偏好；某项 reward 在哪一个去噪时刻最有区分力，则是另一个问题。
方法构造 reward×timestep 的分配矩阵：行约束保留给定奖励预算，列约束控制各时间步总负担，再用 Rényi 判别增益引导 credit assignment。这样调整更新位置时，不必暗中改变用户原本的奖励比例。
论文在 SD3.5-Medium 上测试两套四奖励配置，每套使用五种预算，并用未参与优化的评价模型检查泛化。它是图像扩散实验，不能直接当作视频 RL 已验证结果。
上期 LeanGRPO 处理 rollout/update 重算，这篇处理学习信号的位置。两者关注训练流程的不同环节，组合后的效果尚待验证。
来源：ReCAST。
15. Vidu S2：流式视频里途中新加的参考图，也要生效
Vidu S2（9 月 10 日）包含实时数字角色 Avatar 和实时视频 Editing 两条路径。相比固定参考图的一次性生成，它强调流式运行中更新参考、接受新指令，并让衣着、角色或背景修改接入正在播放的视频。
论文的一项做法是让主干在较低分辨率工作，再由轻量 Refiner 用一步提升到 720p。训练侧增加大幅肢体动作、按事件时间顺序组织的字幕，以及保留适度镜头运动的数据；服务侧再组合稀疏 Attention、低比特 GEMM、融合和多 GPU 流水。
这份报告值得看的，是数据和推理系统如何一起支撑交互。平均 FPS 即使超过播放帧率，也不自动保证用户新指令能迅速影响画面；首帧、指令响应和连续运行后的稳定性仍应分开观察。
当前可核查的入口是技术报告与在线演示，尚不能据此确认权重公开。选型时还需查 S2 自身的硬件和延迟配置，前代 S1 的消费卡测试不能替代它。
五、另一条执行路线：视频模型走向 JAX / TPU
16. vidax：搬到 TPU，先解决精度和编译，再谈速度
vidax（9 月 16 日）提供 JAX/Flax 视频推理与 PyTorch 权重转换，覆盖 Wan、Cosmos、LTX、HunyuanVideo 和 CogVideoX 五个家族。执行路径不依赖 PyTorch，张量并行与 Ulysses 序列并行放在同一套 JAX mesh 中管理。
论文测试使用 TPU v4-8，即四个芯片，分别记录编译、去噪延迟和峰值 HBM。逐层 offload 可以让部分原本放不下的参考分辨率运行，但搬运并未完全被计算隐藏，作者将其作为避免 OOM 的退路。
精度迁移也不是整棵参数树统一转 BF16：例如部分模型的 residual 或 AdaLN 参数需要保留 FP32。项目把这些 checkpoint 转换差异列出来，比一句“已支持该模型”更方便复查。
代码已公开，但仓库不附带模型权重；不同模型的权重许可、部分上游代码条款仍需分别遵守。若已有 TPU 资源，它提供了可研究的执行路径；论文没有建立与同档 NVIDIA GPU 的完整成本对照，暂时不适合据此判断哪一种硬件更划算。
本周阅读顺序
做推理服务，可以先读 GLM-5.3 缓存恢复和 ASPIRE：前者给出正确性检查的细节，后者说明同一 batch 的请求不必齐步走。遇到容量瓶颈，再看 SSD-LLaMA 与 Fathom，分别计算权重读取和 KV 索引读取的成本。
做训练系统，建议把显存峰值论文与 mKernel 连起来：先确定哪些张量必须同时存活，再看通信能否随着 tile 产出提前开始。做视频生成则可以从 H3 的失败案例读起，再看两篇蒸馏论文，避免最后只优化了速度，没有检查生成结果失去了什么。
本周可用版本、代码合并及部署更新见同期 AIGC 开源一周。