8月23日 CUDA 与 AI 系统加速速览：SGLang 启动 2.38×、KV 命中 93.2%、TP 配置省 6.9%
本期整理 SGLang v0.5.18、prefix KV 路由、SLO-aware fleet profiling、TVM/Triton 编译器修复、持续推荐蒸馏与 CPU 推理模型，给出条件化性能数字和第一步验证动作。
快速判断
| 条目 | 适用场景 | 第一步动作 | 行动窗口 |
|---|---|---|---|
| SGLang v0.5.18 | CUDA Graph 启动、TP 解码和 Blackwell all-reduce | 隔离启动、LMHead 和 all-reduce 三段 benchmark | 今天可做回归 |
| CacheRoute | 多租户、重复前缀明显的 LLM 服务 | 用真实 key 分布做 shadow replay | 改路由前 |
| FleetSieve | TP 度数、副本数和尾延迟共同决定容量的集群 | 把吞吐与 completion-p99 放进同一轮 profiling | 扩容前 |
| TVM / Triton | TIRx CUDA 发射控制、跨函数共享内存同步 | 先做编译产物和 IR 回归 | 工具链升级时 |
| SCoRD | 用户兴趣持续变化的召回—重排链路 | 用连续数据流复跑低置信样本更新 | 模型迭代时 |
| Daedalus-150M | 单用户、长上下文、普通 CPU 推理 | 在 0、1024、2048 token 上测解码曲线 | CPU 选型时 |
GPU / CUDA 与推理运行时
SGLang v0.5.18：启动、TP LMHead 和 all-reduce 都有可测改动
SGLang 在 8 月 22 日发布的 v0.5.18，把三条路径的变化写进了同一份 release note。1
- 启动阶段：checkpoint page 可以和 CUDA Graph capture 并行 staging。Qwen3-32B 在 H100 上，相比带 prefetch 的串行加载快 8.6%–11.7%；相比普通默认路径，启动时间从 84.8 秒降到 35.6 秒，即 2.38×。开关是
--startup-weight-load-mode overlap。 - TP LMHead：纯 DP attention 的 allgather 加 scatter 改成一次 all-to-all。在 DeepSeek-V4-Pro、B200 解码测试中，LMHead 从 320 μs 降到 169 μs，TPOT 从 36.97 ms 降到 35.67 ms。
- 纯 all-reduce：DeepSeek-V4-Flash、TP4、Blackwell 小 batch 测试的吞吐最高提升 6.9%。SGLang 对 DeepSeek-V3、V3.2、V4 自动启用 MNNVL 路径，其他模型需要显式打开
--enable-flashinfer-pure-allreduce。
这三个数字各自对应启动、单 token 解码和通信路径，不能合成一个端到端加速结论。升级后还要留意统一的
SGLANG_CACHE_DIR：Triton、FlashInfer、Inductor、DeepGEMM 和 CUDA driver cache 会集中到这个目录，首次启动会触发一次重新编译。第一步可以固定模型、并发和 batch，分别记录启动时间、LMHead 时间、TPOT 与 all-reduce 吞吐。推理 serving：先看缓存复用，再看容量决策
CacheRoute：prefix KV 命中率升到 93.2%，但要先做 shadow replay
CacheRoute 面向多租户对话服务：同一个业务 key 会反复带着相同前缀回来。它每个控制周期规划 prefix 亲和路由，把高频 key 放进稳定的 warm set，再按预期负载安排目的端。论文在 Llama 3.3 70B、FP8、60 张 H100 上，以 3.5 秒 p99 为约束得到 176±11 QPS，是五个基线中最强者的 2.3×；served KV-cache hit rate 从 cache-blind balancing 的 64.1%±1.3% 升到 93.2%±0.5%。23
这项结果依赖请求的 key 复用和热度分布。作者的第二组分布、8B 消融和 burst 实验把 prefix 亲和与负载摆放拆开；两个 32B 工作负载显示，prefix 能回收的计算量较少时，残余负载倾斜会吞掉收益。部署前应当用脱敏后的真实 key、到达间隔和 prefix 长度做 shadow replay，先找出自己的 KV 命中率—队列长度拐点，再决定是否启用固定亲和。
FleetSieve：TP 选择要同时看吞吐和 completion-p99
FleetSieve 解决另一个常见误区：TP4 可能和 TP8 有相近吞吐，尾延迟却让两者的 SLO 结论相反。它按照某次测量对最终 fleet allocation 的影响选择 profiling 点，并把容量与 tail latency 放进同一个决策。
在 31B 开源模型的 H100 测量网格上，FleetSieve 用 22,200 GPU-seconds 到达 oracle aggregate decision，比固定比较中的 uniform random profiling 少 6.9%；200 个随机揭示顺序的平均节省是 5.4%，95% bootstrap CI 为 3.5%–7.2%。在更重的 Chat C128 点，TP4 和 TP8 都服务 11.27 requests/s，completion-p99 却分别是 46.4 秒 和 25.2 秒，只有 TP8 满足 30 秒 SLO。45
这个方法适合扩容前的测量编排，不适合把一组机器上的 TP 结论直接搬到另一组机器。复现时应先固定模型、请求类别和 GPU 数，再为每个 TP/副本组合记录吞吐、completion-p99 和 max-min fulfillment；单看 tokens/s 会漏掉真正的 SLO 约束。
AI 编译器与 kernel 工具链
TVM TIRx CUDA：把寄存器上限和 cluster launch 控制交给 IR
Apache TVM 的一条主线 commit 为 TIRx 增加了
tirx.max_registers。CUDA 13 后端会把它发射为 __maxnreg__，并明确拒绝与 launch bounds 同时使用；运行时还会在 cluster 总大小超过 8 时设置 CU_FUNC_ATTRIBUTE_NON_PORTABLE_CLUSTER_SIZE_ALLOWED。commit 同时补了 CUDA codegen 测试：tirx.max_registers=92 要生成 __maxnreg__(92)，和 launch bounds 冲突时要报错。6这是一条编译控制面变化，官方 commit 附的是 codegen 与错误路径测试，端到端吞吐数字暂待自测。需要调 occupancy、寄存器压力或 Blackwell cluster launch 的团队，可以在固定 commit 上编译一个最小 TIRx kernel：分别检查生成的 CUDA、
__maxnreg__ 与 launch bounds 互斥错误，再用 Nsight Compute 对比寄存器数、active warps 和 kernel 时间。Triton MEMBAR：跨函数调用传播共享内存读写状态
Triton 的
MembarAnalysis 这次把函数入口状态、待处理访问和「所有入口路径都已同步」状态纳入函数摘要。调用点会把 callee 的入口状态映射回 caller；如果 caller 的 pending read 与 callee 的首个 write 冲突，编译器会在 call 前插入 local barrier。新增的 MLIR 回归用例覆盖了直接调用和嵌套调用，并检查 barrier 的位置。7这项变化先解决 kernel 正确性，再谈性能。自定义 Triton kernel 若把 shared-memory layout conversion 封装进函数，升级编译器后应重点复跑跨函数读写、循环回边和嵌套调用测试；官方 commit 目前提供的是分析与 MLIR 回归证据，端到端吞吐仍需在目标 GPU 上单独测量。
推荐系统工程
SCoRD：只给低置信序列做持续蒸馏
SCoRD 面向用户兴趣持续变化的两阶段推荐链路。它让 semantic reasoning assistant 从 LLM reranker 提取可复用的意图级提示，只对低置信序列选择性蒸馏；后续更新可以只改 retriever，减少每轮都重新调用 LLM 的需要，retriever 表示和意图漂移信号再反馈给 reranker。8
在 Book 数据集的 accuracy-efficiency 表中，SCoRD 的 semantic intent generation 用时 1.4 小时，CoT-Rec 为 15.4 小时；SCoRD 的 inference time 是 75 秒，N@5 为 0.5088，H@5 为 0.5846，CoT-Rec 对应 0.4682 和 0.5132。9
这组数字适合用来判断持续更新的成本结构，不能直接替换线上 A/B。落地前可以把线上日志切成连续时间块，先按置信度阈值分层，分别测 retriever-only update 的生成成本、训练时间、召回质量和 reranker 延迟，再决定 assistant 触发频率。
CPU 推理模型
Daedalus-150M：把 12 个 attention block 换成短卷积
Daedalus-150M 先固定普通 CPU、单用户、逐 token 解码和 4-bit 权重，再设计模型结构。18 个 block 中只有 6 个保留 full attention，另外 12 个使用只需保存两步状态的短卷积，因此长上下文时不必让整套网络反复读取增长中的 KV cache。
作者用同规模、同数据训练的全 attention 模型做对照：在 2048 token context，Daedalus 解码快 1.76×，4-bit 文件小 6.3%；与外部同量级模型对比是 2.08×。参数匹配对照的选定质量指标高 0.81%，下游任务相当。1011
这项收益随 context 增长，在空 context 附近接近于零；测量来自单个 seed，模型是英文模型，作者把可用范围写到训练过的 2048 token。CPU 或边缘设备选型时，应当把 0、1024、2048 token 的 decode 曲线和 4-bit 质量一起测，别只拿 2048 token 的峰值速度做结论。
今天怎么排验证顺序
- 正在升级 SGLang：先做启动、LMHead 和 all-reduce 三个隔离 benchmark，并把首次重新编译的时间单独记账。
- 服务有明显重复前缀：先做 shadow replay，观察 KV hit rate、队列长度和 p99，再决定 prefix 亲和路由。
- 正在做容量规划：把 TP/副本组合放进同一张 profiling 表，同时记录吞吐和 completion-p99。
- 正在改编译器或推荐链路：Triton/TVM 先过编译与正确性回归；SCoRD 先在连续时间块上验证低置信触发规则，再进入线上实验。
References
- 1SGLang v0.5.18
github.com
- 2CacheRoute 摘要
arxiv.org
- 3CacheRoute 实验全文
arxiv.org
- 4FleetSieve 摘要
arxiv.org
- 5FleetSieve 实验全文
arxiv.org
- 6TVM TIRx CUDA launch controls commit
github.com
- 7Triton MEMBAR cross-call commit
github.com
- 8SCoRD 摘要
arxiv.org
- 9SCoRD 实验全文
arxiv.org
- 10Daedalus-150M 摘要
arxiv.org
- 11Daedalus-150M 实验全文
arxiv.org
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.