AI 技术日报
本期重点：Softmax 为什么会丢掉小梯度，以及数据直达 GPU 后，存储请求本身为什么仍会拖慢推理。
重点
Softmax：减去最大值之后，小梯度仍可能消失
Softmax 把模型输出的分数转换成概率。常见实现先减去最大分数，防止求指数时溢出，但仍可能丢掉接近零的训练信号。2026-10-23 提交的《A Fix for Softmax and Cross-Entropy》指出：当模型对正确类别非常确信时，它的概率会被舍入成 1。交叉熵对这个类别分数的梯度等于“预测概率减 1”，于是被算成零，其他类别的小梯度却还在。
论文通过改变计算顺序保留这个小量。设其他类别经过减最大值处理后的指数之和为 ，正确类别的梯度可从 改写为 。前一种写法可能先把概率算成 1，后一种把小量 留在分子中。论文还处理了蒸馏中学生与教师预测十分接近时的误差：先比较两者的原始输出分数，再计算概率差，避免两个已经舍入的概率相减。作者在所测的蒸馏实验中，消除了学生从与教师相同权重出发时，由数值误差导致的参数漂移。
https://arxiv.org/html/2610.31642v1
uGDS：数据直达 GPU，请求控制也移到用户态
GPU 直连存储让 SSD 中的数据直接进入 GPU 显存，省去 CPU 主机内存中的中转副本。但 CPU 仍要提交读写请求、管理队列并确认完成；大量请求经过内核时，这些操作本身也会带来开销。uGDS 把这部分工作移到用户态，由 CPU 上的库直接管理 NVMe 命令和硬件队列，内核模块主要负责初始化时的设备映射与内存注册。
读取保存在 SSD 上的键值缓存（KV Cache）时，一个请求往往需要恢复多个缓存块。这些块可以同时读取，GPU 只需等整批读完再使用它们。uGDS 按这种依赖组织批量读取，避免把彼此独立的块也排成串行等待。在 A100-SXM4-40GB、Samsung 990 PRO 和 Qwen3-0.6B 的 LMCache 实验中，关闭 vLLM 内存前缀缓存、只从 SSD 命中缓存后，32,768 token 输入的单请求中位首 token 延迟从 GDS 的 1915 ms 降至 715 ms。
这套原型直接管理 SSD 上的数据块，接入时需要应用自己管理数据位置；它没有提供普通文件系统的目录和文件锁接口。
https://arxiv.org/html/2610.30868v2
https://github.com/ScaleX-IO/uGDS
简讯
SARIA：按复用历史决定哪些 KV 值得写入 SSD
把所有 KV 缓存都写入 SSD，会增加写入量并消耗硬盘寿命。SARIA 根据缓存块被移出 CPU 主机内存的次数和复用次数，选择需要保存在 SSD 上的块。读取时，SSD 中的块直接进入 GPU 显存；完成输入处理后，再把其中一部分复制到 CPU 主机内存，供下一轮复用。这样，下次可同时从主机内存和 SSD 读取不同部分，减少 SSD 的读取量，也避免把所有副本都塞进主机内存。
https://arxiv.org/html/2610.31169v1
EGI-Bench：把 Agent 总分拆回可追查的能力
Agent 总分较高，也可能在工具选择或参数填写上频繁出错。Salesforce 的 EGI-Bench 汇集八个企业任务基准，把细项成绩归入任务结果、工具调用、规划、检索依据、安全和工程质量六个维度。评测者可以给工具调用和安全维度单独设最低分：即使总分很高，这两项不过线，也会被标记为尚不适合发布。这样，其他能力的高分就不会掩盖部署时关心的短板。
https://arxiv.org/html/2610.27234v1
DuoPD：在 HBM 逻辑芯片上承担 Decode
处理输入的 Prefill 阶段主要需要算力，逐个生成 token 的 Decode 阶段更依赖内存带宽。DuoPD 据此提出一种架构：GPU 负责 Prefill，在 HBM 逻辑芯片上增加靠近存储的计算单元，负责完整的 Decode。两者共享 HBM，让 Decode 利用 Prefill 没有用满的带宽。双方同时请求数据时，由内存管理单元决定先服务哪一方，这就是仲裁。论文用仿真评估了这种协作方式。
https://arxiv.org/html/2610.26131v1
RIFT：草稿缓存的选择也会随生成过程过时
投机解码由草稿模型先提出候选 token，再交给目标模型验证。为减少草稿模型每步读取的 KV 缓存，RIFT 同时保留重要历史和最近生成的内容，并在生成过程中重新选择：只按初始输入挑出的缓存，可能跟不上后续上下文的变化。动态重选需要保留可供访问的完整草稿模型 KV 缓存，也会增加重新评分的开销；缩小的是每步参与计算的缓存集合。
https://arxiv.org/html/2610.31098v1
Jepsen：任务未执行，工作流却已经完成
Orkes Conductor 负责按顺序调度工作流中的任务。Jepsen 发现，它在重试任务时要分别写入两条数据库记录：新增一次执行尝试，再把旧尝试标记为已被替代。如果前一次写入失败，程序却继续更新旧记录，就会留下“旧任务已被替代，新任务却不存在”的状态。后续检查误以为没有任务需要继续处理，把未执行完的工作流标成完成。5.5.6 的修复是在新增记录失败时立即中止这次处理。
https://jepsen.io/analyses/orkes-conductor-5.3.2
https://github.com/orkes-io/jepsen-conductor/issues/9
经典回顾
CheckFreq：快照完成与持久化完成是两件事
CheckFreq 研究如何更频繁地保存训练进度，同时减少训练等待。它先复制一份不会再被训练修改的模型状态，作为快照，再由后台写盘。快照可以直接从 GPU 显存复制到 CPU 主机内存，即 D2H；显存有余量时，也可以先在 GPU 内复制，随后再做 D2H。关键是下一次权重更新前，快照必须完整，避免混入两次迭代的状态。后台写盘后还要通过 fsync() 确认持久化。读这项早期工作，可以把异步保存的等待点分清：训练何时能继续修改权重，何时才有落盘的恢复点？