8月19日 CUDA 与 AI 系统加速速览：稀疏 GPU 64.34×、边缘 MoE 2.3×与 KV-Pipe 迭代时间 -9.8%
本期整理 DB-SpMSpV 动态稀疏 GPU kernel、FreeToken 边缘 MoE serving、KV-Pipe 流水并行和 FROG 范围过滤向量召回，给出性能数字、适用边界与最小验证动作。
本期四条更新把瓶颈落在三种具体条件上：动态稀疏输入会改变 GPU 的最佳执行路径，边缘 MoE 受制于带宽和可变资源，流水并行则受阶段失衡拖慢；向量召回还要同时处理数值范围过滤和 GPU 的分支发散。它们适合拿来做小规模复现，不适合直接把最高 speedup 写进容量预算。
快速判断
| 分组 | 更新 | 已报告结果 | 适用场景 | 先验证什么 | 行动窗口 |
|---|---|---|---|---|---|
| CUDA / GPU kernel | DB-SpMSpV：双视图分块 + push/pull 自适应 | A100 上相对 cuSPARSE 平均 5.48×–64.34×；单 token 稀疏线性层最高 4.50× 1 | 动态稀疏向量、图遍历、稀疏模型推理 | 输入块稀疏度、push/pull 选择、写回冲突和端到端延迟 | 有稀疏 kernel 原型时可立即做对照 |
| 推理 / 边缘 MoE | FreeToken：带宽自适应执行 + 语义感知缓存 | RTX 5090 上相对边缘 serving 基线 decode 吞吐 1.5×–2.3×；RTX 4060 笔记本可跑 35B 39.3 tok/s 2 | 本地 GPU、CPU-GPU 混合、工具调用 agent | PCIe/主存带宽、专家 cache 命中、TTFT 尾延迟 | 先在一台目标设备上重放真实 agent trace |
| 推理 / 流水并行 | KV-Pipe：按阶段瓶颈选择跨层 KV sharing | 训练 MFU 最高 +9.2%、迭代时间最高 -9.8%；GQA 解码吞吐在两模型上 +7.3% / +8.2% 34 | 中高 PP 度、长上下文、LM head 造成阶段不均衡 | FIR、PPL/下游质量、KV sharing 层数和 PP degree | 先做离线层选择，再进训练或服务压测 |
| 推荐 / 向量召回 | FROG：全局感知的范围过滤 ANN GPU 索引 | 六个数据集上，相对 44 核 CPU 14.7×–37.7×，相对最强 GPU 基线 4.5×–7.6×；建索引 2.4×–14.8× 5 | 带数值范围条件的向量召回、混合选择率查询 | 选择率、Recall@K、QPS/P99 和索引构建成本 | 先用线上过滤分布做六档选择率回放 |
动态稀疏 GPU：同一份块数据，运行时在 push 和 pull 之间切换
SpMSpV（稀疏矩阵—稀疏向量乘）常见于图遍历、稀疏线性代数和稀疏模型推理。它和普通 SpMV 的区别在于：输入向量本身也稀疏，而且每轮的活跃位置会变。输入块分布一变，GPU 最合适的遍历方向也会变。1
DB-SpMSpV 把矩阵切成固定大小的二维块，在高层同时维护块级 CSR 和 CSC 视图；底层块数据只保存一份。运行时先按输入块稀疏度选择 pull 或 push，再按局部矩阵和向量结构选择 COO、Dense、ForceCSR、ForceCSC 或 patched-CSR 微内核，同时用异步预取、路径感知负载均衡和分层写回处理不规则访存。这样做的关键不是多存一份完整矩阵，而是让遍历方向和块内 kernel 可以随输入变化。6
论文在 NVIDIA A100 和 RTX 4090 上，用 SuiteSparse 矩阵、对称图和三个开源 LLM 做测试。A100 上，DB-SpMSpV 相对 cuSPARSE 的平均 speedup 为 5.48×–64.34×，相对 TileSpMSpV 为 2.36×–14.01×；封装到 BFS 后，相对 TileBFS 的端到端提升平均为 2.66×，RTX 4090 上为 3.60×；单 token 稀疏线性层的 DB-Decoding 最高 4.50×。这些数字跨越不同输入稀疏度，不能压缩成一个与稀疏度无关的固定倍率。16
落地时先别改整个推理栈。把现有稀疏线性层的矩阵固定下来，记录每轮活跃向量块比例，再分别跑 dense、push、pull 和 DB-SpMSpV 四条路径。至少同时看 kernel 时间、global-memory transaction、原子写回冲突和输出一致性；如果线上稀疏模式很稳定，运行时选择的开销也要和收益单独核算。
边缘 MoE：把 PCIe 带宽变成调度信号
FreeToken 面向的是本地 GPU 和 CPU-GPU 混合执行。它把 prefill、decode、专家驻留、agent 状态复用和运行时显存管理放在同一个系统里处理，而不是固定采用某一种 offload 比例。prefill 阶段用双缓冲把下一层专家的 PCIe 搬运和当前层计算重叠；decode 阶段用共享 LRU 专家缓存捕捉相邻 token 的路由局部性，再用 q⋆ 策略决定 cache miss 是填入 GPU 还是直接在 CPU 上执行。27
论文主要测了 Qwen3.6-35B-A3B、DeepSeek-V4-Flash 和 GLM-5.2，覆盖 8 GB RTX 4060 笔记本到 RTX PRO 6000 工作站，并对比 llama.cpp、Ollama、KTransformers 和 MoE-Infinity。RTX 5090 上，Qwen3.6-35B-A3B 的 decode 吞吐为 77–83 tok/s，DeepSeek-V4-Flash 为 22–25 tok/s，相对边缘 serving 基线高 1.5×–2.3×；所有测试工作负载的最坏 TTFT 低于 44 秒，而每个基线至少在一种设置超过 150 秒。7
它还在 8 GB RTX 4060 笔记本上以 39.3 tok/s 服务 35B 模型，在 32 GB 游戏桌面上交互式服务 284B 模型，并在单张 RTX PRO 6000 上服务 753B GLM-5.2。这里的重点是资源编排方式，不是某张显卡可以普遍承载某个参数规模：模型量化、PCIe 代际、主存带宽、上下文长度和 agent trace 都会改变结果。27
最小复现应选一台目标设备和一条真实工具调用轨迹，固定模型、量化、上下文增长方式和并发数，然后分别测 prefill TTFT、decode tok/s、专家 cache 命中率、PCIe/主存带宽和最坏尾延迟。只测短 prompt 的单轮 decode，会漏掉 FreeToken 主要处理的重复 prefill 与动态资源竞争。
KV sharing：用模型结构改 pipeline 阶段负载
流水并行的瓶颈常常来自最后一个 stage 携带 LM head，或不同层的 attention / MoE 成本不均。KV-Pipe 从尾部 stage 开始，把一部分 attention 层改成跨层 KV sharing；每改一组层，就重新寻找当前瓶颈，直到 FLOPs Imbalance Ratio（FIR，阶段 FLOPs 不均衡比）接近 1。这个过程在离线完成，只需要 pipeline partition 和每层 FLOPs 估计，不需要在线调参。34
论文在多种 pipeline-parallel 配置上报告训练 MFU 最高提高 9.2%，迭代时间最高下降 9.8%；在 GQA 的长上下文解码案例里，LLaMA3-8B 和 Qwen2.5-14B 的吞吐分别提高约 7.3% 和 8.2%。收益随 PP degree 提高而变大：论文在 Ascend 910B 上报告 PP=2、4、8 的迭代时间下降分别为 4.90%、7.56% 和 9.80%。这些结果来自特定模型、层选择和调度配置，不能直接外推到 MoE 或混合 Transformer-SSM。4
质量约束需要和效率一起测。以 LLaMA2-7B、PP=8、8K 序列为例，论文的一组配置用四个 shared-KV 层而不是八个，验证 PPL 为 5.49，对照为 5.53；这个结果说明 layer budget 会影响 quality-efficiency 平衡，不能只按「共享越多越快」选层。4
适合先做一个离线脚本：读入现有 pipeline partition 和每层 FLOPs，输出 KV sharing 候选层、FIR 变化和预计 KV cache 节省，再用固定的 PPL/下游任务门槛筛选。只有当阶段确实失衡、PP 度达到中高水平、上下文较长时，才值得进入多卡压测；低 PP 或原本均衡的 partition，收益空间会小很多。
范围过滤向量召回：先按选择率设计 GPU 路径
FROG 面向 RFANNS（带数值范围过滤的近似最近邻搜索）：请求同时给出向量和数值范围，系统只在满足范围的对象中找 Top-K。普通 GPU 过滤会随选择率剧烈波动，直接移植 CPU 图索引又容易产生长搜索轨迹和重复距离计算。FROG 为每个顶点组织多样的扩展邻居候选，在查询时按范围识别可用邻居，并用 GPU 友好的布局、融合距离计算、控制流压缩和延迟去重完成建索引与查询。58
六个数据集的混合选择率查询中，FROG 相对 44 核 CPU 基线的吞吐提升为 14.7×–37.7×，相对最强 GPU 基线为 4.5×–7.6×；索引构建相对 GPU 基线提升 2.4×–14.8×。这组数字衡量的是 RFANNS 查询和建索引，不是推荐排序模型的 AUC，也没有说明线上业务的点击或转化收益。58
推荐系统接入时，先把现有召回日志按范围选择率分成几档，固定 K、ef 和过滤范围，再对比 CPU 图索引、现有 GPU 索引和 FROG。除了 Recall@K、QPS 和 P99，还要记录索引构建时间、显存占用和过滤条件变化后的退化曲线。只有当召回层延迟真的占预算，FROG 的 GPU 设计才会转化成排序链路的收益。
最小验证顺序
- 动态稀疏 kernel： 先记录真实输入块稀疏度，再对照 push/pull 和 DB-SpMSpV 的 kernel 时间、访存交易、写回冲突与输出一致性。
- 边缘 MoE： 用一条会反复调用工具的 agent trace，固定量化和上下文长度，测 cache 命中、带宽、TTFT 和最坏 decode 延迟。
- KV-Pipe： 离线计算 FIR 和候选 shared-KV 层，先过 PPL/任务质量门槛，再比较 PP=2/4/8 的迭代时间或解码吞吐。
- 向量召回： 按线上过滤选择率回放，分开记录 Recall@K、QPS、P99、建索引时间和显存，别把召回吞吐直接写成推荐收益。
这四条材料给出的共同动作很具体：先把工作负载分布、硬件路径和质量门槛固定下来，再比较 kernel、缓存或索引的变化。最高倍率适合决定是否值得试，不适合替代你自己的容量压测。
References
- 1DB-SpMSpV 摘要
arxiv.org
- 2FreeToken 摘要
arxiv.org
- 3KV-Pipe 摘要
arxiv.org
- 4KV-Pipe 全文
arxiv.org
- 5FROG 摘要
arxiv.org
- 6DB-SpMSpV 全文
arxiv.org
- 7FreeToken 全文
arxiv.org
- 8FROG 全文
arxiv.org
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.