01
论文预印本
arXiv
·
论文指出，带原生 Multi-Token Prediction 草稿头的 speculative decoding 在百万 token 上下文中可能反而被 draft 阶段拖慢：每个草稿步仍对完整 KV cache 做 attention，读取量随上下文线性增长。作者只对草稿 attention 使用滑动窗口与 attention sink，完整 target verification 保持不变；在单 GPU、SGLang、1M 上下文的三类 Qwen GDN-MoE / Mamba2-hybrid 模型实验中，自报每步 decode 成本较原生 MTP 降低 28%—44%，并用 ring buffer 回收草稿 KV 占用。
为什么值得读：它把 speculative decoding 的瓶颈从“接受率”扩展到 draft KV 工作集，说明长上下文服务需要分别设计提议路径与验证路径。方案训练无关，且最终 token 仍由完整 attention target 验证，适合 serving engine 评估是否能安全落地。
02
系统发布
AMD ROCm Blog
·
AMD 发布开源分布式推理参考方案 ROCm Infera，在 vLLM、SGLang 或 ATOM 多实例之上统一处理 KV 感知路由、prefill/decode 分离和 KV cache tiering。路由器根据各实例已缓存的 prompt blocks 与排队工作估算重算成本；跨主机 KV 传输使用 Mooncake 或 MoRI-IO 等 RDMA 路径，并校验是否意外回退到 TCP。AMD 的初步内部测试报告，在文中定义的真实 agentic workload 与 SLO 约束下，goodput/GPU 最高提升 2.6 倍。
为什么值得读：单个 engine 的 kernel 已不足以保证多轮 Agent 系统的端到端效率；请求落到哪里、何时拆分 prefill/decode、哪些 KV 值得保留会共同决定 TTFT 与 goodput。性能数据来自 AMD，需结合仓库 examples、自己的模型与缓存命中分布复测。
03
系统架构
AMD ROCm Blog
·
ROCm AMD Infinity Context（AIC）提出位于 GPU HBM 与 CPU DRAM 之外的共享 KV 存储层，首期栈由 llm-d / Kubernetes、vLLM、LMCache、NIXL、hipFile 以及 NFS over RDMA 组成。目标数据路径让 KV blocks 在网络存储与 GPU HBM 之间直接移动，避免经 CPU 内存中转，并支持跨节点缓存复用与 prefill/decode 分离；初始支持 MI300X、MI350 系列，MI450 / Helios 在路线图中。
为什么值得读：当上下文和并发增长后，KV cache 已同时成为 HBM 容量、网络和存储问题。AIC 值得关注的不是单一硬件，而是 LMCache、NIXL、vLLM 与标准 RDMA 存储的组合边界；当前文章包含路线图与厂商估算，正式容量规划前仍需等待技术预览和可复现 benchmark。
04
开源发布
vLLM
·
vLLM 0.26.0 汇集 411 次提交，重点包括 Inkling 模型族、按 KV-cache group 选择 attention backend、显式滑窗能力、混合模型 prefix cache 改进，以及对象存储 secondary tier、DP-replica-aware tiering 和 encoder-cache CPU offload。版本还扩展 Rust frontend 的视频、音频与原生 vllm-bench，并为 DeepSeek-V4、Qwen、ROCm、XPU、CPU 和多类 MoE / speculative decoding 路径加入优化与修复。
为什么值得读：这个版本反映 serving engine 正从单一 CUDA 快路径演化为混合 attention、分层缓存、多前端和多硬件的系统平台。Release 同时含安全修复、模型移除与依赖升级，生产团队应按实际 backend、量化和 disaggregation 配置做定向回归，而不是只看亮点数字。
05
开源发布
SGLang
·
SGLang 0.5.16 包含 574 个 PR，引入按草稿置信度动态决定验证窗口的 DSpark，并将 UnifiedRadixTree 设为 SWA、Mamba 与 DSA 模型默认缓存结构。Release 还报告：Qwen3.5-35B-A3B、TP1 的 ReplaySSM Ring Spec-Verify 将每 GPU speculative scratch 从 11.5GB 降至 1.8GB；GLM-5.2 在 cp_size=4、8192 tokens 的特定配置下，DSA cache layer split 将每 rank KV 内存从 0.77GB 降到 0.20GB。
为什么值得读：这批改动集中在混合 attention / SSM 模型最棘手的状态管理与 speculative decoding 内存成本上。Release 也列出温度 0 非确定性、FlashInfer pinning 和 Mamba 修复回退等已知问题，升级前应特别阅读 breaking changes 与 known issues。
06
编译器工程
PyTorch Blog
·
PyTorch 与 Google 为高层 kernel DSL Helion 增加 TPU backend，把 PyTorch 风格 kernel 编译到 Pallas，并在 autotuner 中选择 device-side pipeline 或把 K/V 全量预取到 VMEM 的 unroll 策略。项目方在 TPU v7 的特定 Flash Attention workload 上报告 838 TFLOPs、约 79% 单 tensor core MFU；更广的 kernel 表中，Helion 相对 TorchTPU eager 的几何平均加速为 1.55 倍，相对 torch.compile 为 1.12 倍，但标准 matmul / norm 并非总能胜出。
为什么值得读：硬件异构让 kernel 团队面临 CUDA/Triton/Pallas 多套实现的维护压力。Helion 展示了“相同高层程序 + 后端特定 codegen + shape-aware autotuning”的路线，同时也坦诚 VMEM 容量与 XLA 已优化算子上的边界；TPU backend 仍依赖尚未公开发布的 TorchTPU。
07
论文预印本
arXiv
·
MoX 面向光交换或 direct-connect 拓扑上的稀疏 MoE 通信，先构造 token-aware multicast trees 降低带宽税，再通过受限的 multicast tree-packing 求解静态链路权重以平衡流量。作者使用真实 MoE traffic、token traces 与 ASTRA-sim 报告，相比最短路由，完整 MoE block 最多加速 1.8 倍；在 1,024 TPU 的 Boardfly 模型上，dispatch 瓶颈链路负载最多降低 47%。
为什么值得读：MoE 让规则的 dense collective 变成运行时稀疏流量，常被视为必须动态重构网络。MoX 提供另一种系统设计点：不预测具体 traffic matrix，也不动态改拓扑，而是离线优化负载无关的路由；当前结果主要来自 trace 与模拟，仍需真实大规模网络验证。
08
论文预印本
arXiv
·
DGNA 提出一套不依赖架构 intrinsic 指令的 GPU 内存延迟测量方法，并用高斯混合模型过滤异常值、识别 L2 与 DRAM 延迟分布。作者把方法应用于 NVIDIA A100 与 H100，声称揭示了 GPU 内部 NUMA node、SM 与 NUMA 的对应关系，以及为维持 cache coherence 使用的 NUMA-aware memory allocation 策略。
为什么值得读：对 kernel、调度器和模拟器而言，把 GPU 当作均匀内存机器会掩盖 locality 差异。可重复的黑盒微基准能帮助验证 placement 与访问模式假设；该工作是预印本，结论依赖测量设计和统计解释，适合结合不同驱动、频率与 GPU SKU 复现。