7月31日 CUDA 与 AI 系统加速速览:GPU kernel 隔离评测、编译器回归与推荐检索

7月31日 CUDA 与 AI 系统加速速览:GPU kernel 隔离评测、编译器回归与推荐检索

围绕 GPU kernel 隔离评测、TPU 性能基准、TorchDynamo 编译器正确性和可预计算推荐召回,给出可直接执行的验证动作与性能数字。

先看结论

这次挑选的几项更新,给出四个可复用的工程动作:隔离 GPU kernel 评测环境;把推理瓶颈拆成网络、计算、内存和搬运;为编译器前端建立按根因组织的正确性回归集;让推荐模型的 item embedding 可以预计算并进入 ANN serving。

GPU kernel:隔离评测环境

Union.ai 让每个 LLM 生成的 GPU kernel 在独立子进程中运行,并使用文件系统、网络隔离、超时和干净 GPU 状态;计时阶段 warmup 5 次,再用 CUDA event 测 20 次。1
在 1,000 个曾被标记为失败的 kernel 中,L40S 复测后 259 个通过,683 个编译成功但校验失败,58 个无法编译;4 张 L40S 完成评测约需 1 小时。这个结果适合提醒团队:比较 kernel 性能时要同时记录 GPU、软件栈、输入校验、warmup 和计时方法。1

推理运行时:先定位瓶颈

Google 7 月 30 日公开的 TPU microbenchmark suite 将测量拆成 network、compute、HBM、host transfer 和 Ragged-Paged Attention,并用 Roofline 区分 compute-bound、memory-bound 与 network-bound。一个 110B MoE 案例在 4×4×4 TPU 7x 上报告 dense-core forward 达到 1.85 PFLOPS,调优后训练 step time 下降 21.2%。这些数字属于 TPU 7x 案例;可迁移到 CUDA GPU 的是测量顺序,不是结果本身。2

AI 编译器:前端正确性回归

一篇 7 月 28 日的预印本整理了 123 个 TorchDynamo frontend bugs,并在 PyTorch 2.10 上用根因导向的测试生成方法产生 170 个测试,发现 23 个失败或错误,其中 15 个被确认是新的 bug。对依赖动态 shape 或 graph capture 的服务,编译器升级应先测数值一致性,再测编译时间和端到端延迟。3

推荐召回:two-tower 配合可预计算 embedding

《The Case Against Generation for Retrieval》用 cross-encoder teacher 训练 two-tower student;用户塔和物品塔共享 LLM encoder,物品 embedding 可预先计算并进入 ANN 索引。论文内部 serving 结果报告:FSQ compression 带来 19.7% QPS 增益,depth pruning 带来 10.6%,post-training quantization 带来 13.6%,同时约有 0.003% 的 NE 回归。部署时应把召回、QPS、更新新鲜度和量化误差放在同一张验收表。4

带回仓库的检查清单

  1. 固定 GPU 型号、CUDA/PyTorch/Triton 版本、warmup 和数值校验阈值,再比较 kernel 时间。
  2. 对推理服务分别测网络、HBM、主机搬运和 attention 原语,确认瓶颈后再改 kernel 或并行策略。
  3. 把编译器 correctness 按根因分层,覆盖固定 shape、动态 batch 和长尾输入。
  4. 先验证 item embedding 能否预计算和增量更新,再测 ANN 召回、QPS 与量化后的 NE/Recall。

Related content

  • Sign in to comment.
More from this channel