8月9日 CUDA 与 AI 系统加速速览：B300 16卡 53k tok/s、bursty 调度与直播排序
本期聚焦 B300 两节点微调的 53k tok/s 强扩展、vLLM ModelOpt FP8 兼容性修复、bursty 推理调度、GPU 执行计划排序和直播推荐的延迟反馈分离，区分实测、仿真与线上 A/B 的适用边界。
先看结论
本期最值得拿回系统验证的，是三类边界：B300 多卡训练是否真的被数据或通信拖慢；推理调度是否偷偷假设流量平稳；推荐排序是否把即时点击和延迟行为混进同一个目标。下面的数字分别来自两节点实测、A100 仿真、A6000/V100 测量和 Twitch A/B，不能横向相加。
| 更新 | 适用场景 | 核心改动 | 已报告数字 | 先验证什么 |
|---|---|---|---|---|
| B300 多节点微调 | 新 GPU 集群、FSDP/ZeRO-3 全量微调 | 用 board power 区分计算、通信、数据饥饿和 hang；启动前检查各 rank 的 token block 是否一致 | 16 卡 53.0k tok/s；单 epoch 5.3 h；强扩展效率 99%；启动 gate 2.71 s | 4/8/16 卡强扩展、每 rank packing 差异、功耗阈值；不要直接搬用 B300 的 watt 区间。12 |
vLLM v0.27.0rc1 | 依赖 ModelOpt FP8 权重的 serving 环境 | 修复转置后权重的 input_dim / output_dim 元数据保留 | 未报告性能收益；这是兼容性修复，不是 benchmark | 只在目标量化 checkpoint 上回归加载、首 token、steady state 和 worker 启动。34 |
| Modified WAIT | 到达率随时间突变的 LLM serving | 用观测到的 interarrival time 在线估计请求强度，动态调整 batching threshold | 在 Vidur/A100 的 MMPP 合成负载中，低 shift 场景吞吐优于 Sarathi 和 vLLM；论文未给出统一百分比 | 用真实 trace 重放，单独看 burst 切换、TTFT、平均延迟和 starvation；high-shift 结果仍不理想。56 |
| GPU contraction-plan 排序 | 张量网络、量子电路等需要在多个 contraction plan 中选一个的 GPU 工作负载 | 用 GPU 测量训练 listwise/pairwise ranker，先排序候选计划再执行 | A6000 的 ID test：Top-1 60%、Top-3 96%；QFT OOD：Top-1 38.71%、Top-3 62.90%；A6000→V100 的 same-best-plan 84.0% | 先固定候选计划集合，再在目标 GPU 上重新测标签；QFT family 对 backend 更敏感。78 |
| 直播推荐多目标排序 | 行为并发、反馈稀疏且有明显延迟的直播流 | 把即时 SMP 与延迟 chat/follow/spend 分到 FSM 与 MMoE，再按新老用户做 VST（viewer segment targeting） | 参数量从 26.7M 降到 15.5M（-41.9%）；线上 DAV +0.09%；高活跃用户 ARPU +0.56%；new follows +0.27% | 先检查标签窗口和用户分层；论文最终采用 14 天 delayed window，不能把它当成所有业务的默认值。910 |
GPU 训练：先看功耗，再看利用率
B300 field report 的价值不在于提出新算法，而在于把多节点训练中最容易误判的信号校准了一遍。作者在 16 张 B300、两节点上对 Qwen3-32B 做 FSDP/ZeRO-3 全量微调，16 卡吞吐为 53.0k tok/s，单 epoch 约 5.3 小时；4、8、16 卡分别为 13.4k、26.7k、53.0k tok/s，GPU·h 基本保持在 84 左右。12
这组数字的可复用部分不是「B300 一定能线性扩展」，而是排障顺序。一次 epoch 末尾 NCCL hang 中，GPU utilization 仍接近 100%，但 board power 只有约 190 W；根因是各 rank 的 token packing block 数不一致，有的 rank 已进入 checkpoint barrier，有的仍在 backward collective。作者用全局最小 block 数让各 rank 对齐，再用一个 2.71 秒的启动 gate 检查数据、残留进程、端口、磁盘和可选的 IB 带宽。2
数据路径的结论也有边界：当数据集能放进 page cache/RAM 时，每步从 NFS 读取与预 tokenized 本地 cache 都约为 53k tok/s；这不能外推到数据放不进内存或 NFS 受多租户竞争的场景。换硬件时，先重新测功耗区间，再把 utilization、board power、NCCL 状态和每 rank 的处理进度放进同一张 triage 表。
同一类「别只看理论复杂度」的思路出现在 GPU contraction-plan 排序。论文不是生成新 plan，而是在每个电路的 7 个候选计划里排序；A6000 的 ID test 中，listwise 模型 Top-3 命中率为 96%，QFT family 留作 OOD 后降到 62.90%。A6000 与 V100 的最佳计划一致率平均为 84.0%，但 QFT family 的稳定性明显更低。78
对工程实现而言，最小动作是把「候选生成」与「候选排序」分开：固定候选集，在真实目标 GPU 上测 contraction time，记录 plan 的 reduction 结构和内存流量，再评估 ranker 的 Top-k 和 regret。该论文只在 A6000、V100 两块 NVIDIA GPU 上验证，不能把 84% 当成硬件可移植性保证。
推理运行时：两个更新都没有直接给出通用加速
vLLM
v0.27.0rc1 于 8 月 7 日发布，所指向的 commit 修复了 ModelOpt FP8 权重转置后的维度元数据：在转置后补回 input_dim=0 和 output_dim=1，并加入对应测试。release 页面没有变更说明或 benchmark，所以它当前应被当成 FP8 兼容性回归点，而不是性能版本。34如果线上加载的是 ModelOpt FP8 checkpoint，升级验证应覆盖权重加载、量化层 shape、worker 启动、首 token 和 steady-state；如果只测默认 BF16 模型，测不出这次修复的价值。
Modified WAIT 针对另一种常见误设：把请求到达当成平稳或 Poisson 流量。它在 Vidur 中模拟 A100，用两状态 MMPP（Markov Modulated Poisson Process）生成 bursty 负载，再从 interarrival time 估计当前到达强度，在线改写 batch threshold。低 arrival-rate shift 下，吞吐优于 Sarathi 和 vLLM；high-shift 下，原始 WAIT 与修改版都仍需改进，且论文没有在真实生产 trace 或真机 serving 上验证。56
因此它适合先做 trace-driven 仿真，不适合直接把仿真结论写成线上加速百分比。验证时要把「流量切换速度」作为自变量，分别记录吞吐、TTFT、平均完成延迟和 starvation；否则一个平均值会掩盖 burst 边界的排队代价。
另一篇对 2023 年以后 GitHub 开源仓库的实证研究，统计了 vLLM、SGLang、TensorRT-LLM、LMDeploy 和 FlashInfer 的采用情况。它观察到 vLLM 在样本中的可见度和采用仓库数最高，FlashInfer 更常出现在多框架组合中；但该研究用的是仓库 stars、forks 和共现关系，不能推出性能优劣或因果关系，采用数据的时间点主要截至 2025 年 11 月。1112
这条观察对选型的用处很窄但明确：用采用面判断文档、样例和维护信号，用真实模型、真实请求和目标 GPU 的 benchmark 判断性能，不能把 GitHub 热度当作吞吐代理。
推荐系统：把时间尺度与用户阶段拆开
直播排序论文处理的不是一个「更大模型」问题，而是标签时间尺度不同。它在 Twitch 场景中把即时 SMP 放进 fresh-signal model，把 chat、follow、spend 等稀疏行为放进 delayed-signal model，再用 VST 在推理时区别 Early 与 Dedicated 用户；最终用 MMoE 合并延迟目标，参数量从 26.7M 降到 15.5M。910
线上结果是：整体 DAV +0.09%，高活跃用户 ARPU +0.56%，new follows +0.27%；新用户的 VST 实验额外带来 DAV +0.15%。这些数字来自 Twitch 直播推荐的 A/B，不是通用排序收益。论文的训练数据来自 600 万 viewers 的 7 天 impression，ground truth 用了 35 天 forward window，最后把 delayed window 选成 14 天。迁移到短视频、电商或广告前，先按行为的真实延迟分布重做窗口搜索。10
如果要验证推荐策略本身而不是离线指标，WatchLens 提供了一个较实用的实验基础设施：feed 与 watch page 的策略可以分别配置，事件在记录时绑定推荐策略和 ranking position，便于把曝光条件与后续播放、续看和导航行为连起来。它支持 Docker Compose 的单服务器部署，但没有给出吞吐、延迟或高并发上限 benchmark；更适合做可复现实验，不是 serving 性能组件。1314
带回系统的验证清单
- 多卡训练：在目标 GPU 上记录 board power 与 utilization 的联合分布；启动前做 per-rank token block 一致性检查，再跑 4/8/16 卡强扩展。
- 量化 serving：对 vLLM
v0.27.0rc1只挑 ModelOpt FP8 checkpoint 做回归，并保留旧版本的加载、首 token、steady-state 和 P99 对照。 - 突发流量：用真实到达时间生成 trace，按 burst 切换速度分桶，比较 batch threshold、TTFT、完成延迟和 starvation；不要只看平均吞吐。
- GPU 计划选择：把候选 plan 的生成、GPU 实测和 ranker 排序分别计时，并在 OOD 电路家族与目标 GPU 上重新测 regret。
- 推荐排序：先估计每个行为的延迟分布，再决定是否拆 fresh/delayed 模型；A/B 同时看 DAV、ARPU、LMP、follow 和新老用户分层，避免一个总指标覆盖掉目标冲突。
References
- 1B300 field report 摘要
arxiv.org
- 2B300 field report 实验
arxiv.org
- 3vLLM v0.27.0rc1
github.com
- 4vLLM ModelOpt FP8 修复
github.com
- 5Modified WAIT 摘要
arxiv.org
- 6Modified WAIT 实验
arxiv.org
- 7GPU contraction-plan 摘要
arxiv.org
- 8GPU contraction-plan 实验
arxiv.org
- 9直播推荐论文摘要
arxiv.org
- 10直播推荐线上实验
arxiv.org
- 11LLM Serving in the Wild 摘要
arxiv.org
- 12LLM Serving in the Wild 实证方法
arxiv.org
- 13WatchLens 摘要
arxiv.org
- 14WatchLens 系统与限制
arxiv.org
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.