
8月21日 CUDA 与 AI 系统加速速览:分片推理 1.79×、ERASE +9.51%、OneModel 延迟 -66.7%
本期整理 FlashAttention-V、预编译 pipeline shards、ERASE 与 OneModel 四项更新,给出性能数字、适用边界和可以直接开始的小规模验证动作。
四项更新都在解决同一个工程问题:把原本浪费在内存往返、空闲计算或重复编码上的资源,换成更高的有效吞吐。但它们的数字都依赖具体硬件、负载和对照组,适合先做小规模复现,再决定是否改线上路径。
快速判断
| 分组 | 更新 | 已报告结果 | 适用场景 | 先验证什么 | 行动窗口 |
|---|---|---|---|---|---|
| CUDA / GPU kernel | FlashAttention-V:跨 attention head 做 inter-head packing,适配长向量寄存器 | Banana Pi 实测相对标量 FlashAttention 12×–14×;gem5 在 512-bit VL 的 prefill 22×–42×、decode 8×–11× 12 | RISC-V RVV / Arm SVE 边缘 CPU、1–10B 小模型、短上下文 decode | 你的 head dimension、VL、GQA 比例,以及 Q8_0 线性层是否已成为瓶颈 | 有 RVV / SVE 推理路径时可先做单层 kernel 对照 |
| 推理优化 / 系统 | Pre-Compiled Pipeline Shards:把模型层拆成 OpenVINO graph,跨 AI PC 做流水并行 | 两节点 Llama 3.1 8B、两路请求 + speculative decoding 聚合 43.97 tok/s,是单体单用户基线的 1.79×;四节点 70B、K=10 时相对 target-only 约 3.1× 34 | 单台 16GB 级 AI PC 放不下的大模型,或多台边缘设备共同 serving | stage 间网络 RTT、每用户编译图显存、聚合吞吐和单用户 P99 | 已有 Intel AI PC 集群或 70B 边缘部署需求时优先验证 |
| 推荐训练 / CUDA | ERASE:detach 子图输出,在独立 CUDA stream 上提前执行 backward | 8×H100 轻量 CTR 模型 p90 QPS 最高 +9.51%;1×A100 MLP 总 batch 时间 −30% 56 | kernel 没有占满 GPU、可以设置局部训练目标的轻量推荐模型 | 空闲 SM、detach 点后的质量变化、CUDA stream / collective 顺序 | CTR 代理模型可直接做 trace 与吞吐 A/B |
| 推荐 serving | OneModel:统一有机推荐、广告和商家行为序列,用场景门控减少跨场景干扰 | 小红书生产排序中延迟 270 ms → 90 ms;线上广告 CTR +8.18%,Explore Feed Engagement +1.25% 78 | 多业务流共享用户行为、需要降低重复 user-tower 计算的排序平台 | 共享用户表示的缓存命中、各场景 AUC、请求延迟和负迁移 | 适合已有跨场景日志与线上 A/B 基础设施的团队 |
CUDA / GPU kernel:FlashAttention-V 把长向量的空位拿来处理多个 head
FlashAttention-V 针对的是 CPU 侧 Transformer 推理。传统向量化 attention 主要沿单个 head 的维度
D 做计算;当向量长度超过 D 后,寄存器里剩下的空间没有新的并行工作可填。论文的改动是重排 head 循环,并把多个 head 打包进同一个向量寄存器,再配合分块、循环展开和 GQA 的 K/V 复用。这样,RVV 和 Arm SVE 可以使用超过 head dimension 的长向量。12作者把实现接入
ggml / llama.cpp,用 TinyLlama、Llama 3.2、Qwen2.5 和 Pythia-410M 做评估。实机平台是 Banana Pi BPI-F3,性能分析还用了 gem5 的 RVV 模拟;实机使用 256-bit 向量长度,模拟范围扩展到 512–8192 bit,所有推理 batch size 都是 1。对照组包括 ggml-scalar、ggml-vec-fp16 和 ggml-vec-fp32,因此这些数字是 attention 模块或单层分析结果,不是 GPU 上的端到端吞吐。2在 Banana Pi 上,FlashAttention-V 相对标量 FlashAttention 的 prefill 加速为 TinyLlama 12×、Qwen2.5 14×;相对向量化 FP32 baseline,两者都是 3.7×。在短上下文
N≤128 时,它相对 ggml-vec-fp16 的平均加速约为 1.2×–1.5×,Qwen2.5 在 N=64 和 N=128 时达到约 1.5×–2×。这些结果在短序列上更明显,因为分块设计能提高数据复用、减少内存压力。2gem5 的 512-bit VL 模拟给出更大的上限:prefill 相对标量实现 22×–42×,decode 8×–11×;向量长度扩展到 4096 bit 时,prefill 还可再获得约 2×–2.5×。但 decode 是单 token、内存受限的执行,继续增加向量宽度后的收益会变小。论文还发现,Q8_0 量化在线性层中的 packing 和 masked reduction 在 2048-bit VL 时能占到 60% 的执行周期,长向量因此会被前置的 GEMV 瓶颈限制。12
这条路线适合边缘 CPU,而不是 CUDA GPU:先在你的 RVV / SVE 后端固定模型、上下文长度和量化格式,分别测 attention、线性层和完整 decode。若 attention 只占 decode 的小部分,继续优化 FlashAttention 的收益会被 Q8_0 GEMV 吞掉;若请求以短上下文 prefill 或小模型 decode 为主,再看 inter-head packing 是否值得保留。
推理优化:预编译 pipeline shards 让多台 AI PC 合起来托住 70B
Pre-Compiled Pipeline Shards 把模型按连续层拆成多个 stage,每个 stage 导出为带状态 KV cache 的 OpenVINO graph,再通过持久 TCP 连接传递激活。作者在每个 shard 中注入
beam_idx + Gather,触发 OpenVINO GPU 插件的 IndirectKVCache 融合;两路请求再通过 micro-batching 交错经过各 stage。34这个细节决定了结果能否复现:同一台 Panther Lake Arc B390 上,单体 Llama 3.1 8B INT4 的 C++ pipeline 是 24.54 tok/s;注入
beam_idx 的一阶段 shard 是 24.45 tok/s,未注入时只有 21.26 tok/s。也就是说,论文先把拆分后的单 stage 恢复到单体水平,再谈跨节点流水。4两节点、两路请求时,2-stage Llama 3.1 8B 的无 speculative decoding 聚合吞吐为 29.34 tok/s;加入
K=3 的 speculative decoding 后达到 43.97 tok/s,相对单体单用户基线是 1.79×。但这不是单用户延迟的 1.79 倍:平均约 21.99 tok/s/用户。作者还报告,每增加一个 micro-batch stream 都要额外编译图;3-stage 配置下每个 stream 约占 6 GB iGPU 内存。4四节点部署把 Llama 3.1 70B-Instruct 拆成每个约 20 层、约 9 GB 的 INT4 shard。在 Tiber Cloud 的实际 WAN 条件下,单流 target-only 是 1.74 tok/s,
K=10 speculative decoding 是 5.42 tok/s,约 3.1×;两路请求时聚合吞吐为 6.43 tok/s,但单流降到 3.21 tok/s。完整 logits 经 relay 返回时只有 2.80 tok/s,只返回 top-1 token / probability 后升到 22.88 tok/s,说明跨节点通信格式和 relay 排队会直接决定效果。4最小验证应从一条 8B、两节点路径开始:先复现
beam_idx 融合前后的单 stage 吞吐,再逐步加入 micro-batching 和 speculative decoding,同时记录单用户 tok/s、聚合 tok/s、TTFT、每 stage 的显存和网络 RTT。论文的 70B 单体 OpenVINO baseline 因校准工作区 OOM 没有建立;因此 70B 的数字说明了「能否托住」和流水收益,不能直接当作相对单机 70B 的完整加速比。4推荐训练:ERASE 用 early backward 填满 GPU 空档
ERASE 把
detach 从梯度技巧改成调度工具:一个子图完成前向和局部损失后,就能在独立 CUDA stream 上启动 backward,同时让后续子图继续 forward。实现使用 CUDA stream、event、非阻塞提交和 CUDA Graphs;FUP(find_unused_parameters)用来控制最终梯度同步涉及的参数。56在 1×A100 的 MNIST MLP sanity check 中,backward 时间从 23.5 ms 降到 9.9 ms,总 batch 时间从 41.2 ms 降到 28.8 ms。在 8×H100 的轻量 CTR 模型中,常规 baseline 的 p90 QPS 是 184,535.51;non-blocking + CUDA Graphs 配置达到 198,145.28,相对提升 7.38%;论文表格中最高配置达到 202,078.43,相对提升 9.51%。6
吞吐和质量要一起看。7.38% 配置相对 baseline 的 Normalized Entropy(NE,越低越好)差距约 1.38%。此外,NanoChat 的 trace 显示,若融合 attention backward kernel 已经占满 GPU,就没有空余资源和后续 forward 重叠。ERASE 需要在子图之间切断梯度依赖,不能直接套到必须保留完整端到端梯度传播的结构上。6
工程上可以先不改完整训练框架:给一个轻量 CTR 代理模型画出 forward/backward trace,找出没有占满 SM 的子图,再只放置一个 detach 点,比较 blocking、non-blocking 和 CUDA Graphs 三种配置。若质量门槛不允许约 1.38% 的 NE gap,吞吐数字就不应直接换成生产配置。
推荐 serving:OneModel 用一次用户编码服务多个业务流
OneModel 把有机推荐、广告和商家推荐里的用户行为映射到共享事件序列,再用 Scenario-aware Information Modulation(场景感知信息调制)在共享 backbone 内做通道级门控。线上路径把长序列用户编码与候选打分解耦:用户状态在新交互后增量更新,缓存到低延迟 KV Store,请求到来时复用 user tower 结果。78
这套做法的系统收益很具体:生产基线 dense parameters 是 173M、延迟 270 ms;OneModel 是 230M、延迟 90 ms,参数增加 32.9%,延迟下降 66.7%。论文把收益归因于 feature decomposition、user feature prefetching、共享 user-tower 计算和 graph-level inference optimization。序列长度从 500 增至 1000 时 AUC 只提升 0.5‰,所以线上部署选择了长度 500。8
离线广告排序中,统一多场景 OneModel 的 Click AUC 为 0.7712,单场景 OneModel 为 0.7682,相对 GenRank 的 0.7648 分别高 6.4‰ 和 3.4‰。但推荐流统一训练相对独立训练的 Click AUC 基本不变(0.7906 → 0.7905),说明共享行为序列的收益会按业务流变化,不能只看某一个场景。8
线上 A/B 的结果来自小红书三个生产业务流:Explore Feed 的 Time Spent +0.33%、Engagement +1.25%;Feed Advertising 的广告价值 +3.43%、CTR +8.18%;Merchant Recommendation 的 DGMV +1.1867%、GPM +2.1585%。这些是具体业务流的相对变化,不是统一模型在所有推荐系统上的通用收益。78
如果你已有多业务流排序平台,第一步应把用户编码、候选打分和特征预取拆成独立时间段,测共享 user tower 能省多少重复计算,再做单场景与统一训练的 AUC / LogLoss 对照。只有当共享表示确实减少了重复请求成本、且场景门控没有带来负迁移时,统一模型才值得进入线上 A/B。
最小验证顺序
- 先确认瓶颈。 FlashAttention-V 先测 attention 在完整 decode 中的时间占比;ERASE 先看子图有没有空闲 SM;OneModel 先测重复 user-tower 计算;pipeline shards 先测每跳网络 RTT 和 stage 显存。
- 固定对照组。 分别保留 scalar / vectorized attention、单体 / shard pipeline、blocking / non-blocking backward,以及单场景 / 统一排序模型;同时固定模型、batch、序列长度、网络条件和质量指标。
- 把系统数字和质量数字放在一起。 推理看 tok/s、TTFT、P99 和显存;训练看 QPS、NE 和收敛;推荐排序看 AUC、LogLoss 与线上业务指标。单个 speedup 不能替代质量门槛。
- 最后才做线上压测。 先确认收益来自你的 workload,再测并发、回滚、缓存失效、网络抖动和异常流量下的 P99。
四项更新分别适合四种验证入口:边缘 CPU 先看向量宽度能否填满寄存器,多节点推理先看通信和流水是否盖过分片成本,推荐训练先看 GPU 空档能否安全重叠,推荐 serving 先看共享用户表示是否真的减少重复计算。把这四个前提量出来,数字才有迁移价值。
References
- 1
- 2FlashAttention-V HTML 全文
arxiv.org
- 3
- 4Pipeline Shards HTML 全文
arxiv.org
- 5
- 6ERASE HTML 全文
arxiv.org
- 7
- 8OneModel HTML 全文
arxiv.org

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.
More from this channel›
- 8月24日 CUDA 与 AI 系统加速速览:eStargz 冷启动 17 秒、边缘 RAG 能耗降 53.2%、Triton 跨函数 barrier
- 8月23日 CUDA 与 AI 系统加速速览:SGLang 启动 2.38×、KV 命中 93.2%、TP 配置省 6.9%
- 8月20日 CUDA 与 AI 系统加速速览:rl-triton 最高 5.70×、MoNe 128K 节省约 80%、OGR 线上 +1.120%
- 8月19日 CUDA 与 AI 系统加速速览:稀疏 GPU 64.34×、边缘 MoE 2.3×与 KV-Pipe 迭代时间 -9.8%
- 8月18日 CUDA 与 AI 系统加速速览:MoE 小 batch 1.33×、VLM 共享 1.30×与端云推荐
- 8月17日 CUDA 与 AI 系统加速速览:GPU kernel 契约违规 62.1%、移植 5.1×与边缘缓存 1.65×