8月4日 CUDA 与 AI 系统加速速览：共享 GPU 隔离、DOPS 异构推理与 GEM/TransX 推荐系统

8月4日 CUDA 与 AI 系统加速速览：共享 GPU 隔离、DOPS 异构推理与 GEM/TransX 推荐系统

本期聚焦共享 GPU 的租户隔离、异构推理的算子与权重调度，以及 GEM 和 TransX 在推荐系统中的训练与在线加速边界。

CUDA 与 AI 系统加速日报
CUDA 与 AI 系统加速日报@zzq

先看结论

本期最值得拿回去验证的不是又一个孤立的 kernel 数字，而是调度边界：共享 GPU 要先分清时间片共享和显存隔离，异构推理要同时排算子和权重布局，推荐系统则把集群拓扑、变长负载和行为缓存一起纳入设计。NVIDIA、Meta 的工程文章与两篇 arXiv 预印本给出了四个可落地的切口，但数字都绑定硬件、模型和流量条件，不能直接当作通用加速承诺。

GPU 与推理系统

共享 GPU：KAI Scheduler + vCluster 解决的是租户边界

适用场景：多个团队共用一台 GPU 节点，希望保留各自的 Kubernetes 控制平面，又不想为每个团队单独占用物理 GPU。
NVIDIA 的方案用 KAI Scheduler 处理 GPU 调度、队列和配额，用 vCluster 为每个团队提供独立的虚拟 Kubernetes 控制平面。示例在 1 张 NVIDIA L40S、40 vCPU、160 GiB 内存的节点上运行 3 个团队队列，每队配置 0.33 GPU，最终 3 个 Pod 都落在同一物理节点。1
落地时最容易误读的是 0.33 GPU。文中的共享方式是 CUDA context 的时间片调度，不是硬件级显存隔离；需要硬件级隔离时仍应评估 MIG。示例使用 KAI Scheduler v0.16.4、vCluster 0.35.1，并通过 schedulerName、队列标签和 gpu-fraction 注解把工作负载绑定到租户队列。1
先做什么：在自己的节点上分别记录 GPU context 切换、显存峰值、P95/P99 延迟和队列等待时间；如果租户之间需要强显存边界，不要把 KAI 的时间片共享当成 MIG 的替代品。

DOPS：异构推理不再只拆 prefill 和 decode

适用场景：LLM serving 同时使用 NPU、PIM 或其他异构设备，单纯的 prefill/decode 分离已经无法解释算子放置和权重布局带来的差异。
DOPS 把推理过程建成带阶段信息的 DAG，用 Bifocal scheduler 动态决定算子放在哪个设备，再用 Weight Layout Arbiter 在内存约束下选择权重布局。论文摘要在代表性异构系统上报告：相对 prefill-decode disaggregation baseline，Bifocal 的几何平均加速为 1.20×–2.23×；加入 WLA 后，相对 Bifocal/Linear 再获得 1.28×–1.33× 的几何平均加速。2
这里的结果不是 GPU-only serving 的直接 benchmark，论文针对的是包含 NPU 和 PIM 的代表性平台。它给系统团队的启发是：压测时不要只记录设备利用率，至少要把算子放置、权重布局、阶段间依赖和内存上限作为四个可变因素逐一锁定。否则把算子搬到另一类设备后，布局转换和同步开销可能吃掉算子本身的收益。
先做什么：为一个实际模型画出 stage-aware DAG，先固定权重布局，只比较静态和动态算子放置；再固定放置策略，单独打开布局选择。两轮都记录端到端 token/s、P99、显存/内存峰值和跨设备搬运量。

推荐模型与 kernel 工程

Meta GEM：推荐基础模型的瓶颈在拓扑和变长负载

适用场景：推荐模型同时包含大规模 sparse embedding、dense 参数和大量变长行为序列，需要扩展到数千张 GPU。
Meta 介绍的 GEM 同时处理数万亿级 sparse embedding 参数和数十亿级 dense 参数。集群拓扑是单机 8 卡 NVLink、机间 AI zone 内 RoCE、跨 zone oversubscribed RoCE；训练使用 5D parallelism，dense 参数采用 2D FSDP + Expert Parallelism，sparse 参数采用分片的 2D model parallelism。3
Meta 报告 GEM 的端到端训练效率达到 20%–25% MFU，较此前提高约 2 倍，12 个月内训练 FLOPs 提高 4 倍。更贴近 kernel 和通信的数字包括：JFA v4 带来 18.5% 的相对 local MFU 提升和 12% QPS 提升；BlockAttention 的 self-attention layer MFU 相对 Triton block attention 提高 30.6%。这些是 GEM 推荐负载上的工程结果，不是通用 LLM 训练基准。3
先做什么：如果推荐训练的序列长度高度不均，先把单卡 MFU 和跨 rank 通信分开看，再按序列长度做负载平衡；对 Triton 或自研 attention kernel，先复现相同 jagged shape、精度和 batch 组成，再比较 MFU，不能拿规则长度的 microbenchmark 代替线上形状。

TransX：把行为历史与 serving 事件拆开，在线计算对长历史不敏感

适用场景：候选级推荐需要同时读取长期行为和实时曝光/候选事件，行为序列很长，但线上必须维持高 QPS。
TransX 用独立的 behavior-stream encoder 处理长期行为，用 serving-event stream 表示实时候选，再通过 grouped sparse cross-attention 连接两者；行为表示可以离线或近线增量维护，在线侧使用 per-request KV cache 和并行 action decoder。论文在 LinkedIn 的大规模线上 A/B 测试中报告，相对 DLRM baseline，CTR +6.0%、转化率 +4.4%；在离线延迟消融里，n=500 时加入 amortized sequence encoding 和 KV caching 后，延迟下降 83%。4
这组数字的控制条件不能省略：论文使用 180 天行为窗口、H100 训练集群，线上部署面向数十万 QPS；A/B 结果来自 LinkedIn 的推荐流量，不能直接外推到短行为序列或候选数不同的业务。4
先做什么：先把行为编码从请求路径中移出，分别测全量重算、增量编码和 KV cache 三种方案的 P50/P99、内存占用与候选吞吐；离线 AUC 上升而在线 P99 变差时，优先检查缓存命中率、失效策略和候选 batch，而不是继续加深 Transformer。

带回仓库的检查清单

  1. 共享 GPU：先确认目标是时间片复用还是显存隔离；前者测 context 切换、队列等待和尾延迟，后者评估 MIG 或其他硬件边界。
  2. 异构推理：把算子放置与权重布局拆成两轮 ablation，保留 token/s、P99、内存峰值和搬运量四项指标。
  3. 推荐训练 kernel：按真实变长分布复现 Triton attention 对照，固定精度、shape 和 batch 后再看 MFU/QPS。
  4. 推荐在线推理：把行为编码、KV cache 和候选 batch 分开压测，业务指标与 P99 同时过线才算收益。

References

  1. 1
    How to Run Isolated Tenant Kubernetes Clusters on Shared GPU Infrastructuredeveloper.nvidia.com
  2. 2
    Beyond Prefill-Decode Disaggregation: Dissecting LLM Inference for Heterogeneous Platforms via Dynamic Operator Schedulingarxiv.org
  3. 3
    Training GEM at LLM Scale: Meta ads recommendation foundation modelengineering.fb.com
  4. 4
    TransX: Scaling Transformer-based Recommendation via Behavioral and Serving Stream Crossingsarxiv.org
CUDA 与 AI 系统加速日报

CUDA 与 AI 系统加速日报

面向工程与算法读者的日报频道，追踪 CUDA、GPU、性能加速、AI 编译器优化，以及推荐模型与推荐系统相关进展。

This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.

Related content

  • Sign in to comment.