AI 技术日报
本期重点：H100 的线程块分组为何会减少可用计算资源，以及 PyTorch 2.15 怎样调整分布式通信。经典回顾用 Roofline 建立计算量与数据搬运量的分析框架。
重点
H100 分块：共享更多数据，可能反而多跑一轮
一项于 2026-10-28 提交的研究，解释了 Hopper 内核中一个反直觉现象：把线程块组成 cluster，让它们共享数据、减少重复加载，性能却可能下降。作者在四张 H100 SXM5 上观察到，单块或两块分组可以同时使用 132 个流式多处理器（SM），四块或八块分组却只能同时使用 120 个。作者用制造后屏蔽部分硬件资源，以及剩余资源的分组约束，解释这一限制。
当资源占用限制每个 SM 只能常驻一个线程块时，256 个块在 132 个 SM 上分两轮执行，在 120 个 SM 上则需要三轮。省下的搬运可能抵不过新增一轮的等待。作者据此比较不同分组所需的轮数，再选择 cluster 大小。论文还观察到，部分 FlashAttention 负载减少搬运后，SM 频率提高；作者将其归因于搬运耗电下降，为计算腾出了功耗预算。分析收益时，数据流量、执行轮数与实际频率需要一起看。
https://arxiv.org/html/2610.37466v1
PyTorch 2.15：默认通信后端重写，增加单边传输
2026-10-29 发布的 PyTorch 2.15，默认将 nccl 进程组切换到从 torchcomms 移植的重写后端。通信器随进程组提前创建；集合通信卡住时，诊断记录器可以保存各个 rank 当时的通信活动，帮助定位是哪一步停住。旧后端仍可通过配置切回。
另一项变化是单边传输接口。应用与对端建立连接后，可以直接发起数据读写，不必先组成进程组或发起集合通信。首个后端使用 NIXL，读写可排入 CUDA stream，并纳入 CUDA Graph。它为直接的数据搬运提供了不同于集合通信的组织方式；这些新接口仍标注为不稳定 API。
https://pytorch.org/blog/pytorch-2-15-release-blog/
https://github.com/pytorch/pytorch/releases/tag/v2.15.0
简讯
KV Cache 隔离：请求被拒绝，Decode 却仍读了预留页面
Cloudflare 与 SGLang 的联合复盘说明，一次容量不匹配怎样演变成跨请求数据暴露。负责处理输入的 Prefill 端，将超出键值缓存（KV Cache）容量的输入换成单 token 占位内容，但分离部署的交接仍把请求当作有效任务。负责生成的 Decode 端按原长度预留页面，实际只收到少量 KV，随后读到了未被本请求覆盖的旧内容。后续加固分别处理入口拒绝和传输中的页面回收；这两处对应不同的生命周期问题。
https://blog.cloudflare.com/kv-cache-exposure-remediation/
https://www.lmsys.org/blog/2026-10-26-cf-security
OS-Wizard：从可恢复的中间状态分叉收集操作轨迹
专业软件的训练轨迹难收集，既因为 Agent 不熟悉软件，也因为反复从头操作成本高。OS-Wizard 用教程指导探索，允许直接执行软件原生指令，并为适合分叉的中间状态保存虚拟机快照。探索新操作时，从最近的快照恢复，再重放剩余步骤。它把软件知识、操作接口和状态恢复放进同一套采集流程，说明高质量操作数据不只取决于多跑几条完整轨迹。
https://arxiv.org/html/2610.33907v1
Minerva：用硬件依赖关系定位拖慢训练的故障
NVIDIA 的 Minerva 技术介绍将 GPU、网卡、交换机、存储和当前作业连接到动态拓扑图，再结合同负载设备之间的比较寻找异常。这样，一个仍在线但性能下降的部件，可以沿依赖关系关联到受影响的训练任务。文中的 NVMe 案例先从慢任务定位到主机，再从日志发现设备无法退出低功耗状态；阅读价值在于把设备健康与实际作业耗时联系起来。
https://developer.nvidia.com/blog/how-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield/
多语言评测：覆盖了某种语言，不等于测全了它的能力
一项对 51 个多语言基准、242 个数据集和 219 种语言的审计发现，低资源语言通常只覆盖 1–3 类任务，高资源语言则覆盖更多任务。按“数据集—语言”组合计，56% 的条目由英语翻译而来。论文把语言数量、任务广度与内容是否贴近当地语境分开检查，帮助判断一个多语言总分究竟覆盖了哪些能力。
https://arxiv.org/html/2610.36990v1
GPU 共享：由节点运行时执行每个容器的显存上限
NVIDIA 对 CUDA 13.4 的技术介绍，把共享 GPU 的资源分配与实际执行分开：调度器选择设备和显存份额，GPU Fractioning Operator 在节点上配置 GPU 多进程服务（MPS），落实每个容器的显存上限。超额分配会失败，应用看到的也是受限后的容量。计算可选择轮流使用或并发共享 SM；后一种方式共享错误域，显存限额本身不等于完整的故障隔离。
https://developer.nvidia.com/blog/memory-enforced-gpu-sharing-in-kubernetes-with-nvidia-cuda-13-4/
经典回顾
Roofline：先看计算和搬运各自能把性能限制在哪里
Williams、Waterman 与 Patterson 的旧作 Roofline，面对的问题是：多核处理器越来越不同，怎样用简单模型判断优化方向。它用每在处理器与主存间搬运一字节所做的浮点运算数连接计算与内存，将可达吞吐限制在峰值算力和“带宽乘以运算强度”两者的较小值。原文还加入向量化、并行度和内存访问等性能上限，帮助解释程序为何离理论上限很远。现在读它，可以为 GEMM 分块、融合和搬运优化建立第一层判断。带着一个问题读：一次优化减少了搬运字节，却没有缩短耗时，应该先检查哪条性能上限？