7月29日 CUDA 与 AI 系统加速速览：GPU 搬运、编译器修复与推荐缓存 (2026)

先看结论

最近几项更新的共同点很明确：推理性能的账，越来越多记在数据搬运、缓存命中、批处理形状和编译正确性上，而不是只看 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。压测结果若只来自合成流量，不能直接当成生产容量。

7月29日 CUDA 与 AI 系统加速速览：GPU 搬运、编译器修复与推荐缓存