8月7日 CUDA 与 AI 系统加速速览：稀疏 GPU kernel 2.7×、云边推测解码 28× 与部署搜索
本期聚焦 SparseDitto 的按矩阵定制稀疏 kernel、AsymSpec 的云边推测解码、AFD-Ledger 部署搜索，以及 FlashInfer ABI hotfix 和直播推荐的延迟反馈建模，给出可复现边界、性能数字与验证动作。
先看结论
本期最值得拿回系统验证的，不是又一个大版本号，而是四个会改变工程决策的条件：稀疏矩阵的结构可能比算子名称更决定 kernel 速度；云边推测解码的收益取决于上行受限和跨请求调度；Attention–FFN 分离部署不能只看架构宣传，必须和同预算的混部方案一起搜索；推荐排序则再次说明，延迟反馈与用户分段要先拆开建模。
| 更新 | 适用场景 | 核心改动 | 已报告数字 | 先验证什么 |
|---|---|---|---|---|
| SparseDitto | 稀疏 SpMV、SpMM、SpGEMM；输入矩阵结构差异大 | 按矩阵、算子和目标 GPU 选择表示、执行策略与映射，并用测量结果迭代 kernel | 相对 cuSPARSE：RTX PRO 6000 2.68×、H200 2.79× 几何平均；最大 146.61×/78.5× | 先按自己的矩阵分布跑 selector，再把编译和搜索时间算进总成本。12 |
| CommBench | 需要让代码模型生成 NCCL、NVSHMEM、RDMA 或 MoE 通信代码 | 用隐藏 build-and-run、正确性检查和速度联合评价生成代码 | GPT-5.5 的正确且达到参考实现 95% 性能的比例为 30.7% | 不要把能编译当成能上线；必须在目标互联和目标库版本上做执行评测。34 |
| AsymSpec | 边缘 draft、云端 verifier，上行窄、下行宽，且有并发请求可调度 | 用非对称纠错和 confirmed-prefix pipeline 隐藏验证等待，避免同请求 runahead 的废弃工作 | 18 个 operating points 上相对最强基线 2.82–28.03×；几何平均约 7.96× | 先用真实上/下行带宽和请求并发重放；不要只测单请求或理想局域网。56 |
| AFD-Ledger | MoE serving，需要比较 Attention–FFN 分离与 collocated 部署 | 离线联合搜索硬件分配、worker 组织、batch、并行度和复制策略 | 完整部署评估减少 68.8–83.5%；物理验证中吞吐比误差 6.6–9.6% | 把 TPOT SLO、硬件目录和通信开销固定后再比较架构。78 |
FlashInfer v0.6.16.post2 | 已使用 FlashInfer、且依赖 tvm-ffi ABI 的 serving 环境 | 跟进 tvm-ffi v0.1.13-post2 ABI 兼容性 hotfix | release note 未报告性能 benchmark | 先在现有 wheel、扩展加载和多进程 worker 中做 ABI 回归，再决定是否全量升级。9 |
| 直播推荐多目标排序 | 观看、聊天、关注、付费反馈到达时间不同，且用户生命周期差异明显 | 即时信号与延迟信号分成 FSM/DSM，再用分段目标权重和 MMoE 合并稀疏目标 | 参数量较独立模型少 41.9%；线上 DAV +0.09%、高参与用户 capped ARPU +0.56% | 先核对标签窗口、分段权重和 ranking P99；论文报告线上 P99 <110 ms，但不等于你的链路预算。1011 |
CUDA 与 GPU kernel
SparseDitto：稀疏 kernel 的第一变量是矩阵结构
同一个 SpMM，换一种稀疏存储格式就可能换一套完全不同的执行路径。SparseDitto 的摘要给出一个很极端的例子：同一矩阵上，cuSPARSE 在 CSR 与 Blocked-ELL 之间出现 350× 性能差距。论文因此没有寻找一个对所有矩阵都最好的实现，而是为每个矩阵、算子和目标 GPU 选择表示、映射和执行策略。1
它在 SuiteSparse Matrix Collection 的 6060 个矩阵上评测 SpMV、SpMM 和 SpGEMM，覆盖 RTX PRO 6000 Blackwell 与 H200。相对 cuSPARSE，几何平均加速比在两张卡上分别为 2.68× 和 2.79×；最大值分别达到 146.61× 和 78.5×。SpMM 的收益随 dense width 增大而收窄：RTX PRO 6000 上 K=8、32、128、256 的加速比分别为 4.46×、2.81×、1.92×、1.68×。2
这组数字不能直接搬到稠密 Transformer kernel。它的适用条件是输入稀疏性、行长度分布和目标 GPU 与论文相近；论文还排除了 cuSPARSE 在 7 个最大 SpGEMM 矩阵上的资源不足样本。工程上更实际的动作是：先采样线上矩阵的行长度、NNZ 和稠密度，再比较 selector 的命中率、生成时间、warm-up 成本和稳定运行时，而不是只看最佳 kernel 的 benchmark。
CommBench：代码生成要过互联和性能两道门
如果团队正在用代码模型生成 NCCL、NVSHMEM、MSCCL++、DeepEP 或 RDMA 代码，CommBench 提供了一个比单元测试更接近生产的问题。它包含 101 个任务，覆盖点对点、集合通信、MoE expert parallel、通信-计算融合和通信工具函数；评测环境包括 8× B300 NVLink、GH200 跨节点 RDMA，以及 AMD MI325X 的 XGMI/RoCE。34
论文把「正确」和「够快」分开统计。对 GPT-5.5，能编译、通过正确性检查，并达到参考实现至少 95% 性能的任务比例是 30.7%；仅看通过正确性检查的比例则为 57.4%。DeepSeek-V4-Pro 经过 5 轮 refinement 后，Pass Rate 从 19.8% 升到 41.6%，说明反馈能修复一部分熟悉库的错误，却不能替代对专用库语义和拓扑的理解。4
验证动作：把生成代码放进和生产相同的 CUDA/ROCm、NCCL/RDMA、GPU 拓扑和消息大小矩阵里；记录编译成功率、correctness、通信带宽和尾延迟四列。对代码模型来说，单卡能运行不是通信 kernel 合格的证据。
推理、通信与部署
AsymSpec：云边推测解码的收益来自网络形状
AsymSpec 针对的是一种具体部署：轻量 draft model 在边缘网关，高质量 target model 在云端；上行带宽受限，下行更宽。普通 stop-and-wait 会让云端 verifier 等待上传，同请求 runahead 又会在拒绝或 bonus token 后产生无效工作。AsymSpec 把更丰富的纠错信息放到下行，并只让已确认前缀的独立请求进入边缘调度器。56
论文在 3 个 draft-target 配对、2 个 workload、3 种非对称带宽上测了 18 个 operating points。相对最强基线，输出 token 吞吐提升 2.82–28.03×，几何平均约 7.96×；测试吞吐范围为 201.31–823.65 tokens/s。从强网络切到弱网络时，Standard Spec、CoSine 和 PipeInfer 的几何平均吞吐分别下降 78.6%、71.4% 和 71.5%，AsymSpec 反而提升 1.9%。6
这里最不能忽略的是流量条件。论文的弱、中、强网络上行/下行分别是 50/150、150/1000、250/2500 Mbps；协议还依赖跨请求的 confirmed-prefix pipeline。复现时应把 uplink queue、请求并发、拒绝率、bonus token 和完整 fallback 都纳入压测。单请求局域网 benchmark 不能验证这套方法。
AFD-Ledger：先搜索部署，再决定要不要拆 Attention 和 FFN
AFD-Ledger 把 Attention–FFN Disaggregation 当成一个 provisioning 问题，而不是默认优于 collocated 的架构选项。它在相同模型、工作负载、TPOT SLO、硬件预算和硬件目录下，分别为 AFD 与 collocated 搜索硬件分配、worker 组织、batch、并行度、复制和 pipeline depth。78
在可以穷举的部署空间里，AFD-Ledger 将完整部署评估次数减少 68.8–83.5%，仍能找回全局最优。三个 LongCat 2.0 物理部署上的验证显示，它保持了正确的架构选择，预测的 AFD/collocated 吞吐比与实测相差 6.6–9.6%。但在 36 个 homogeneous settings 中，只有 7 个被选为 AFD；同一套硬件下，AFD 相对 collocated 的吞吐比在 0.483× 到 1.815× 之间变化。8
这对容量规划的含义很直接：先固定 TPOT SLO、硬件价格和通信模型，再比较架构。论文的分析模型忽略 kernel deficiency、scheduler latency 和 network contention；它适合缩小搜索空间，不适合替代真实流量压测。
FlashInfer v0.6.16.post2：这是 ABI 回归，不是性能升级
FlashInfer 的这个修订版说明只有一件事：包含
tvm-ffi v0.1.13-post2 的 ABI 兼容性 hotfix，并建议升级到该版本。release 页面没有给出性能 benchmark，因此不能把它和上一期的 FlashKDA 编译目标扩展放在同一类性能更新里。9适用场景是已经使用 FlashInfer wheel、预编译扩展或多进程 serving 的环境。升级前后至少跑三类检查：扩展加载和符号解析、不同 worker 启动路径、实际模型的首 token 与 steady-state 性能。若只在干净环境里
import 成功，仍可能漏掉旧 wheel 与新 tvm-ffi 混装造成的 ABI 问题。推荐系统工程
延迟反馈和用户分段，别塞进同一个权重
直播推荐的点击、观看、聊天、关注和付费信号到达时间不同。论文用 Fresh Signal Model 处理即时的 SMP，用 Delayed Signal Model 处理 chat、follow、spend 等稀疏目标，再用 Viewer Segment Targeting 区分 Early 与 Dedicated 用户；后续用 MMoE 联合建模延迟目标。相对独立模型，MMoE 参数量减少 41.9%。1011
线上 A/B 结果有几个工程上可复用的数字：多模型加延迟目标使整体 DAV 提升 0.09%，高参与用户的 capped ARPU 提升 0.56%；加入分段 targeting 后，Early 用户 DAV 额外提升 0.15%；换成 FSM + MMoE + VST 后，整体 DAV 提升 0.08%，new follows 提升 0.27%。论文还在 Twitch mobile live feed 上取得 positive user-channel interactions +1.12%。11
代价是标签不能马上定稿。实验对 7、14、21、28、35 天窗口做了比较，最终采用 14 天；线上 ranking P99 要求低于 110 ms。落地时应把标签成熟时间、分段样本量、模型参数量和 P99 放进同一张实验表，不能只报 AUC 或 DAV。
带回仓库的检查清单
- 稀疏 kernel：先按线上矩阵结构分桶，再比较 cuSPARSE、专用 kernel 和搜索成本；把 out-of-resources 样本单独记账。
- 通信代码生成：在目标 GPU 拓扑上同时测 correctness、带宽和尾延迟；「能编译」和「性能达标」分开设门槛。
- 云边推理：重放真实上下行带宽和多请求队列，覆盖拒绝、bonus token、fallback 与请求取消。
- AFD 部署：固定 TPOT SLO、硬件预算和价格目录后，再比较 AFD 与 collocated；不要把分析模型的吞吐当成线上保证。
- FlashInfer 升级：把
tvm-ffiABI、worker 启动和实际模型性能列入回归，不用 release 版本号代替 benchmark。 - 推荐排序：同时记录延迟标签成熟度、用户分段、参数量与 P99；线上业务提升必须和 serving 成本一起看。
References
- 1SparseDitto 摘要
arxiv.org
- 2SparseDitto 正文
arxiv.org
- 3CommBench 摘要
arxiv.org
- 4CommBench 正文
arxiv.org
- 5AsymSpec 摘要
arxiv.org
- 6AsymSpec 正文
arxiv.org
- 7AFD-Ledger 摘要
arxiv.org
- 8AFD-Ledger 正文
arxiv.org
- 9FlashInfer v0.6.16.post2 release
github.com
- 10直播推荐多目标排序摘要
arxiv.org
- 11直播推荐多目标排序正文
arxiv.org
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.