7月29日 CUDA 与 AI 系统加速速览：GPU 搬运、编译器修复与推荐缓存
从模型冷启动、多 GPU 通信、Triton/CUTLASS/TVM 更新到推荐缓存与容量压测，提炼近期可直接复用的系统优化动作和性能数字。
先看结论
最近几项更新的共同点很明确：推理性能的账，越来越多记在数据搬运、缓存命中、批处理形状和编译正确性上，而不是只看 Tensor Core 峰值。工程上可以先抓三件事：
- 大模型副本扩容时，优先复用 GPU 侧已有权重和 JIT kernel cache，避免每个副本重新从对象存储冷启动。
- MoE 或多 GPU serving 先量通信路径，再谈算力利用率；all-to-all、KV cache 路由和跨节点带宽会直接改写 decode 吞吐。
- 推荐和排序服务的压测必须带真实流量回放、warmup 和动态 batching。单纯把并发实例数往上加，可能只是把排队和显存压力放大。
推理系统：先处理搬运，再处理算子
ModelExpress 把模型冷启动变成副本间传输
NVIDIA ModelExpress 的切入点是扩缩容时的重复下载。它会先查找已有的兼容权重副本，再优先通过 GPU 到 GPU 的 P2P RDMA 传输权重，也能沿着 ModelStreamer、GDS 和 host-staged POSIX I/O 回退。Model Cache Service 还能把多个副本对同一模型的并发下载合并为一次，Artifact Transfer API 则把 JIT kernel cache 一起纳入分发。
NVIDIA 给出的示例是，DeepSeek-V4 Pro 的权重和 JIT kernel cache 从一个服务副本传到新副本用时不到 10 秒，总启动时间从 8 分钟降到 1 分 44 秒；10 个副本同时拉取 806 GiB 模型时，重复下载会产生约 8 TiB 的传输量。这个数字属于文中的部署示例，落地时要先确认 GPU 拓扑、NIXL、存储后端和缓存一致性条件。1
可复用动作：把「权重、JIT cache、运行时配置」拆成可寻址的工件，分别测冷启动、同节点 fan-out 和跨节点回退路径。NVIDIA 还报告 pool registration 可减少 80% 至 99% 的注册次数，适合放进 RDMA 内存注册的 profiling 面板里核对。
NVLink 6 的收益只在通信成为瓶颈时兑现
NVIDIA 对第六代 NVLink 的定位是面向 MoE、专家并行、all-to-all 和解耦推理的 scale-up 网络。文章给出的规格包括每 GPU 双向 3.6 TB/s、72 GPU rack 总带宽 260 TB/s，以及相较现成 Ethernet 方案最高 2.3 倍的 decode throughput；在 NVIDIA 的口径里，Hopper 到 Blackwell 的 MoE 推理 tokens/watt 提升最高达 50 倍。2
这里最值得拿去做实验的不是单一带宽数字，而是把 all-to-all、KV-cache-aware routing 和解耦推理放在同一张 trace 里看。若 profiling 显示 GPU kernel 已经吃满，升级互联不会自动带来同等比例的收益；若 decode 在专家交换或 KV cache 传输处排队，通信拓扑才可能成为主要杠杆。
vLLM v0.26.0：小 kernel 优化也能落到 E2E
vLLM 最新 release 针对 DeepSeek-V4 serving 路径加入了 routing、MoE、attention、量化和分布式融合方面的改动。release notes 报告的可核对数字包括：
token_to_req_indices cache 带来 5 至 6 倍 kernel speedup，sequence parallelism 在部分设置下带来 1.9% 至 5.0% 的 E2E throughput 提升，fused_topk_bias kernel 提升约 1.5 至 2 倍。它们是 release 中对应测试的结果，不应直接外推到所有模型和 batch 形状。3编译器与 kernel：升级理由首先是正确性和可观测性
- Triton 3.7.1 是 patch release，没有新 API，重点修复 async copy/shared memory 的依赖与 fence 问题，以及 pinned LLVM 引入的 InstCombine 误编译。遇到偶发错误结果、不同编译器版本结果不一致时，这类修复比追逐新语法更值得优先验证。4
- CUTLASS 4.6.1 的 CuTe DSL 增加实验性的
cute.compile_to细粒度编译 API、IKET kernel 内 tracing 和不依赖额外 CUDA Toolkit 的 SASS dumping；C++ 路径继续补充 Blackwell SM120/SM121 的 tensor/token-scaled FP8 grouped GEMM。适合需要控制编译阶段、检查 SASS 或做 Hopper/Blackwell kernel 迁移的团队。5 - TVM 0.25.0 继续修正 Relax、TIR 和 runtime，同时包含 scatter_elements/scatter_nd 的 CUDA 编译修复、动态 batch size 的 attention 支持，以及按后端拆分 device runtime DSO。若模型转换链路依赖 ONNX、Torch 和 CUDA 后端，这些改动应配合算子覆盖率和生成代码回归一起验收。6
一个实用的回归矩阵是：固定输入形状测 correctness，覆盖动态 batch 测编译和首 token 延迟，再用代表性长尾形状测显存、kernel 数量和端到端吞吐。只看平均 latency，抓不到 shared-memory fence 或动态形状带来的问题。
推荐系统工程：训练、在线 serving、压测要分开看
TorchRec v1.7.0 把分布式 embedding 的问题暴露出来
TorchRec v1.7.0 增加了 Training Optimization Logger 和结构化事件日志，覆盖 planner、sharder、训练 pipeline 与 RecMetrics；还提供 multi-stream collective-overlap 的 PEC building blocks。release 同时修复了跨 stream 的 memory-usage race condition，减少 embedding dtype conversion 和 AllToAll 输入带来的峰值 HBM，但没有给出一个可泛化的统一性能百分比。7
这次更新适合先做可观测性改造：把 table assignment、storage reservation、kernel changed、cacheability 和 HBM peak 记到同一份训练事件里。出现 NaN 或显存尖峰时，先区分 sharding plan、stream overlap 和 dtype conversion 的责任边界，再改 planner 参数。
MTServe：用 GPU page 加 CPU chunk 保存用户历史
生成式推荐的瓶颈不总是模型本身，也可能是每个请求都重新编码用户长历史。MTServe 用两级 KV cache 复用这段工作：GPU 侧按 32 tokens/page 做细粒度缓存，CPU 侧按 1024 tokens/chunk 保存更大容量，通过异步 onload/offload、LRU 和 page table 管理两层之间的迁移。
在 KuaiRand-1K 和生产数据集 MT 上，论文报告最高分别为 3.04 倍和 3.10 倍加速；batch size 为 8 时，KuaiRand-1K 延迟为 47.3 ms，对比 recompute 的 143.6 ms，GPU hit ratio 为 64.36%，总 hit ratio 为 98.59%。这是预印本在特定模型和数据集上的结果，迁移到普通 DLRM 或多阶段排序链路前，先确认请求是否真的有用户历史局部性。8
MediaBrain 与 Vanguard 提供两个不同的工程提醒
一篇面向 Connected TV 内容发现的论文把 LLM 放在 topic 生成和召回，把传统 ML 留在低延迟个性化排序；其 MediaBrain 采用 Llama 3.2 1B 和四层 SID tokens。论文记录的优化路径是从约 2 QPS/A100 提升到 20、80，最终到 200 QPS，但 token generation 仍约 500 ms，prefix lookup 约 150 ms。结论很具体：把 LLM 移出用户热路径，靠异步 post-processing 和分层缓存消化延迟，比把所有排序环节都换成生成式模型更稳妥。9
另一篇关于 ML serving 压测的论文提出 Vanguard，覆盖 14 个工业模型，硬件包括 A100 80GB 和 H100，模型参数量为 80M 至 1.5B。它的全量方案 MAE 为 5.2%；去掉 warmup handling 后误差升到 27.4%，去掉 recorded replay 后升到 31.6%，去掉 batching awareness 后升到 14.3%。这组消融结果说明，推荐/排序服务压测时，真实流量形状和预热阶段不是附属条件，而是容量估计的一部分。10
可以直接带回工程仓库的检查清单
- 扩容链路：记录权重、JIT cache 和运行时工件的来源，分别测 P2P、GDS 和 host-staged 回退，不要只报总启动时间。
- 多 GPU 推理：把专家交换、KV cache 迁移和 decode 排队放在一张 trace 里，确认瓶颈到底在 kernel、互联还是调度。
- 编译器升级：为固定形状、动态 batch、长尾输入各留一组 correctness、编译时间、显存和 E2E 基线。
- 推荐模型上线：先判断用户历史能否复用，再选择 GPU page、CPU chunk 或普通 feature cache；命中率要和迁移开销一起看。
- 容量压测：用 recorded traffic replay，单独处理 warmup，保留 GPU health、动态 batching 和多指标 SLO。压测结果若只来自合成流量，不能直接当成生产容量。
References
- 1ModelExpress：Distributing Model Artifacts at the Speed of Light
developer.nvidia.com
- 2NVIDIA NVLink：The Scale-Up Network for AI Factories
developer.nvidia.com
- 3vLLM Releases：v0.26.0
github.com
- 4Triton Releases：v3.7.1
github.com
- 5NVIDIA CUTLASS README：4.6.1
github.com
- 6Apache TVM Releases：v0.25.0
github.com
- 7TorchRec Releases：v1.7.0
github.com
- 8
- 9
- 10
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.