01
论文与 Benchmark
arXiv
·
CommBench 收录 101 个由专家编写或从生产代码提炼的任务，覆盖 P2P、Collective、Expert Parallel、通信—计算融合与工具函数，并涉及 CUDA Runtime、libibverbs、MSCCL++、NCCL、NVSHMEM、DeepEP、vLLM 和 SGLang。评测框架会在真实的节点内 NVLink 与跨节点 RDMA 环境中编译、执行并校验生成代码，再把功能正确性与相对参考实现的性能合并计分；作者报告，受测最强模型 GPT-5.5 的通过率为 57.4%，但同时达到正确且性能不差于参考实现 40% 以上阈值的 PASS+Good 仅为 30.7%。
为什么值得读：单 GPU Kernel 生成能力不能直接外推到 Collective 或 MoE 通信：跨设备同步、网络 API、拓扑和性能退化都会增加新的失败面。这个 Benchmark 把“能编译”与“可用于高性能数据路径”明确拆开，适合作为通信代码 Agent 的回归门槛；上述比例只代表论文定义的 101 项任务、模型版本与评测阈值。
02
硬件—推理系统论文
arXiv
·
论文面向百万 Token、检索式稀疏 Attention 的 Decode，将模型权重、Projection 与 MoE 留在 GPU，把 KV Cache、索引 Key 及所有读取它们的操作放到通用近内存设备 KARAT。设备以大容量 LPDDR 和足以运行检索索引器的通用计算核心为设计点；系统再用细粒度 Microbatch 调度把一个批次的 Expert All-to-All 隐藏到另一个批次的 GEMM 后，并按上下文长度重新平衡 Token。作者在三种模型和真实 Agent Trace 的模拟评估中报告，满足 SLO 时每 TDP 吞吐相对 GPU-only 提升 2.09—6.13 倍，训练免费稀疏 Attention 路径提升 1.36—3.21 倍。
为什么值得读：只把 KV 字节卸载到 Host/CXL，而把索引扫描留在 GPU，可能只是把容量瓶颈换成链路瓶颈；这项工作强调数据、索引与计算要共同放置。结果依赖作者的设备面积/功耗估计、模拟器、模型和 Trace，并非现成硅片的端到端实测，但为超长上下文基础设施提供了可讨论的软硬件分工。
03
正式会议论文
arXiv / IEEE SOCC 2026
·
这项已被 IEEE SOCC 2026 接收的研究系统评估 OPT-7B/70B 与 Mamba2-2.7B/70B 的 Decode，并把 DRAM 泄漏与刷新、GPU Idle Power 一起纳入 DRAM-PIM-GPU 设计空间。作者发现，仅按动态功耗计算，在 Mamba2-2.7B、Batch 1、128 Token 输入与 2048 Token 输出配置下，会把 tokens/s/W 最高高估 3.85 倍；增加 Channel 对所有测试都不会降低性能，但低 Batch 会较早进入平台期。Workload Mapping 在 Kernel 级最多降低 14.0% 延迟、17.4% 能耗，端到端收益最高 5.6%，不是首要瓶颈。
为什么值得读：PIM 方案很容易用“少搬字节”推导能效，但低利用率时，容量换来的 DRAM 背景功耗与等待中的 GPU 可能吞掉优势。论文提示架构研究和采购评估必须报告静态功耗、Batch、输入/输出长度与容量有效配置；其结果来自系统级模型和 A100 基线等设定，仍需真机验证。
04
开源发布
DeepSpeed
·
0.19.4 Patch Release 加入 AutoTP 与 ZeRO Stage 3 推理组合，修复 TP+DP 下 ZeRO-3 Checkpoint Consolidation，并保留 Hugging Face tp_plan 的 Universal Checkpoint 元数据。MoE 侧修复 Tutel 与 Tensor Parallel 组合可能产生的静默错误、从每专家计数交换推导 AutoEP Rank Split，并为 Ampere/Ada 专家加入 Triton Grouped-GEMM；版本还修复 DeepCompile 的 ZeRO-3 参数所有权、异步 I/O 与多组学习率调度等问题。
为什么值得读：训练基础设施最危险的故障往往不是 Crash，而是静默错误或不可恢复的 Checkpoint。使用 ZeRO-3、AutoTP、Tutel/Expert Parallel 或 DeepCompile 的团队应优先审查这次补丁，并用既有 Checkpoint、数值一致性和故障恢复测试验证升级，而不能只看吞吐。
05
开源发布
NVIDIA Dynamo
·
Dynamo 1.3.1 专门处理 GB200 上经 AWS EFA 运行 SGLang 分离式 Serving 时，KV Transfer 卡死并返回空响应的问题：SGLang EFA Runtime 改用已发布的 NIXL 1.3.2 Wheel，三类 EFA Image 升至 EFA Installer 1.49.0。Release 同时明确两项残留风险：libfabric EFA Provider 仍可能让新启动的 Decode Worker 在约 300 秒后返回空 HTTP 200；若 Kubernetes 分配的 GPU 与 EFA NIC 不在同一 PCIe Switch，也可能在 10—20 秒后失联，官方建议请求节点全部 EFA 设备，或结合 EFA DRA 与 NVIDIA DRA 做拓扑对齐。
为什么值得读：分离式推理的数据路径健康不等于请求成功：这里的故障可表现为无错误的空 200，传统网络丢包和 HTTP 状态监控都可能漏报。GB200/EFA 用户应增加 Completion Token、Worker Connection 与 GPU—NIC 拓扑校验，并把 Release 的 Known Issues 纳入上线 Gate。
06
官方工程博客
AMD ROCm Blog
·
AMD 为 Quark 增加 Hugging Face Diffusers 原生集成，量化后的 Diffusion 模型可以经 save_pretrained / from_pretrained 进入标准制品流；同时支持 SVDQuant，以 Channel Smoothing 搬移动态范围，再用 Rank 16—32 的低秩分支补偿 4-bit 权重和 Activation 无法表示的 Outlier。官方列出 W4A16、W4A4、MXFP4 与 NVFP4 等模式，并将此前单张 MI350 上 MXFP4 相对 BF16 Eager 最高 1.92 倍的结果作为背景；该数字属于 AMD 的特定 FLUX.1-dev、软件栈与质量设置。
为什么值得读：量化算法若不能融入模型保存、加载和部署 API，生产采用成本往往高于 Kernel 收益。Quark 的变化把校准、低秩补偿和 Diffusers 制品生命周期接起来，但 4-bit Activation 的图像质量、低秩分支成本及跨硬件可移植性仍需按目标 Pipeline 独立评测。
07
开源预发布
Apache TVM
·
0.26.0.rc0 是预发布候选，变更包含 TIRx 基础设施与后续 Codegen/TVMScript 衔接、Cooperative Tensor Builtin 及 Metal Storage Scope，并将 Device Runtime 拆成按 Backend 分离的 DSO。前端侧扩充 StableHLO 与 TFLite 的 Region、Control Flow、Quantized QDQ、Conv3D、RNN/LSTM 等导入覆盖；同时修复多项 ONNX/Relax 数值和 CUDA 编译问题，并加入基于 Git Tag 的版本与 PyPI Wheel 发布流程。
为什么值得读：这批变化同时触及 IR、前端兼容和 Runtime Packaging，可能影响自定义 Pass、部署制品与多后端集成。由于它仍是 RC，采用者应在冻结生产版本前重点回归 TIR/TVMScript API、模型导入数值一致性、CUDA/Metal Codegen 与 Wheel/DSO 装载。
08
实证研究
arXiv
·
研究从 GitHub Python 代码中识别 vLLM、SGLang、TensorRT-LLM、LMDeploy 与 FlashInfer 的 API 使用，并按 Star/Fork、近一年活跃度、Contributor 与 Commit 数过滤仓库；过滤后 vLLM 出现在 1821 个仓库，FlashInfer 虽在五者中 GitHub 热度最低，却以 52 个仓库排采用量第三。方法类别中，额外并行计算、内存管理与网络剪枝分别出现在 1010、451 与 203 个仓库。跨框架组合整体有限：vLLM 只有 1.54% 的仓库与其他受测框架同用，而 FlashInfer 为 44.23%，更像嵌入上层 Engine 的 Kernel/Attention 组件；作者公开了 Replication Package。
为什么值得读：生态采用量能帮助平台团队判断兼容优先级，也揭示 Serving Stack 更常以“一个主引擎 + 专用 Kernel 库”组合，而不是并列多个完整引擎。仓库挖掘依赖静态 API 匹配与过滤规则，不能等同于生产流量份额或性能排名，但公开数据让结论可被复核。
09
开源补丁发布
FlashInfer
·
0.6.16.post3 的唯一 Release Note 是从 0.6.16 分支回退此前引入的 SM90 CUTLASS MoE Backend 及依赖改动；同日的 0.6.17rc5 也执行了对应回退，并修复 B12x Unified MoE 测试中的配置调用。Release 没有给出性能数字或完整根因，因此不能推断受影响模型与配置范围。
为什么值得读：对被 vLLM、SGLang、TensorRT-LLM 等上层栈调用的 Kernel 库，后端回退意味着版本固定与端到端验证比追逐最新实现更重要。Hopper/SM90 MoE 用户应核对实际加载的 Backend、结果一致性和性能基线；在上游给出更多根因前，不应把这次回退解读为普遍性能结论。