8月11日 CUDA 与 AI 系统加速速览：HiSparse 长上下文 4.7×、Muse Glimmer 单卡 20K tok/s 与 20K 推荐序列
本期聚焦 HiSparse 的分层 KV 管理、Muse Glimmer 的单卡长上下文推理，以及 TM20K 与 MISO 在推荐序列和排序模型上的验证边界，给出可复现实验条件与最小验证动作。
截至 8 月 11 日早晨，今天有四个更新值得进入工程验证清单：HiSparse 把长上下文稀疏注意力的 KV 历史下沉到主机内存，论文报告峰值生成吞吐最高提升 4.7×；NVIDIA 介绍的 Muse Glimmer 让 30B、120K+ 上下文模型走单卡本地推理；推荐系统一侧，TM20K 把电商行为序列扩到 20K，MISO 则用模型内部状态缩小排序模型的试错范围。下面的数字分别来自论文实验、官方技术博客和业务部署，不混作普遍保证。
先看结论
| 分组 | 更新 | 已报告结果 | 更适合谁先验证 |
|---|---|---|---|
| KV cache / 推理 | HiSparse：分层 KV 管理 | 长上下文峰值生成吞吐最高 4.7× | 稀疏注意力、主机内存和 GPU cache 之间有带宽余量的 decode 服务 |
| 本地推理 | Muse Glimmer：30B、120K+ 上下文 | Blackwell Ultra 单卡超过 20K tokens/sec/GPU | 想把长上下文 agent 放进单卡、边缘或工作站的团队 |
| 推荐序列 | TM20K：token merge + full-token teacher | ADSS +1.036%，serving latency +5.6%，序列长度 20K | 电商广告推荐中，行为序列已经成为主要成本的团队 |
| 排序优化 | MISO：模型内部状态驱动改动选择 | normalized entropy 改善，验证轮次明显少于两类基线；摘要未给绝对数值 | 每轮模型迭代昂贵、但能导出参数和激活的排序系统 |
推理与 CUDA：HiSparse 把 GPU cache 变成固定大小的工作集
适用场景
HiSparse 针对的是稀疏注意力 decode：模型需要访问很长的 KV 历史，但每个 token 实际只会命中其中一部分。它的做法不是把完整历史硬塞进 GPU，而是把完整 KV 放在主机内存，只在 GPU 上保留固定大小的 cache。论文在 DSA、NSA 和 Quest 三类稀疏注意力上，用 H200、B200 和 GH200 做了实验。1
核心改动与数字
它把命中检测、LRU 替换和 host-to-device fetch 融进 CUDA kernel，并放进 decode 的 CUDA Graph；跨层共享选择结果后，再做精确预取。论文报告，在长上下文设置下，峰值生成吞吐最高提升
4.7×，per-token latency 大致保持接近；高负载时 TTFT 也会下降。no-IO oracle 实验显示，解析和调度机制本身没有可测的 per-token 成本，主要代价来自主机到设备的 IO。1这组数字是论文在指定模型、注意力模式和 GPU 上的结果，不是所有稀疏注意力服务都能得到的加速。PCIe 或 CXL 带宽、cache 命中率、上下文长度、并发度和预取能否覆盖 IO，都会改变结果。特别是，如果访问模式接近均匀随机，GPU cache 的局部性会比论文设置差很多。
最小验证动作
- 先把现有实现拆成三段计时：cache 命中检测、host-to-device 搬运、真正的 attention / GEMM。
- 同时记录 cache hit rate、每 token 搬运字节数、H2D 带宽、TPOT、TTFT 和 P99；只看 tokens/s 会漏掉长尾。
- 做一个 no-IO 对照：把所需 KV 预先放在 GPU，测出算法本身和 IO 的收益上限，再判断硬件链路是否值得投入。
本地推理：Muse Glimmer 的重点是单卡容纳，而不是又一个吞吐榜
适用场景
NVIDIA 在 8 月 10 日发布的技术博客介绍 Meta 的 Muse Glimmer：一个
30B 参数、开放权重、120K+ 上下文的稠密模型，可通过 SGLang、vLLM、NVIDIA NIM 或托管端点部署，也列出了 Jetson、RTX 5090、DGX Spark 和 DGX Station 等平台。2对工程团队最有用的信息是部署边界：文章称，在 Blackwell Ultra 上，单张 GPU 可以把完整模型放进显存，同时为较大的 KV cache 留出空间，不需要模型分片、CPU offload 或外部端点。它适合先验证本地 agent、长上下文工具调用和工作站推理，而不是直接替代所有多卡服务。2
数字与边界
官方文章给出 Blackwell Ultra 上超过
20K tokens/sec/GPU 的吞吐表述，并把它放在 BF16 / NVF4 精度语境中；页面图注写的是 Blackwell Ultra 的 BF16 throughput。文章没有同时给出输入长度、输出长度、并发数、batch size 和完整的 P99，因此这个数字只能作为平台与 recipe 的方向性信号，不能直接外推到 RTX 5090、Jetson 或其他模型。2最小验证动作
先固定模型版本、精度、上下文长度、并发和 KV cache 配置，再分别测首 token 延迟、稳态生成吞吐、显存余量和长上下文下的 P99。对比 SGLang、vLLM 和 NIM 时，记录是否启用了不同的量化、CUDA Graph、chunked prefill 或 speculative decoding；否则测到的不是单纯运行时差异。
推荐系统：TM20K 用 token merge 把行为序列推到 20K
适用场景
电商广告推荐常见一个取舍：保留更多用户行为能提高兴趣建模能力，但 full-token attention 的训练和在线成本会随序列变长。TM20K 的路线是让教师和学生都使用 full attention，学生端用多种 token merge 压缩超长行为序列，再用一次性重训的 full-token teacher 做知识蒸馏。论文称该方法已部署在字节跳动电商广告推荐系统，序列长度扩展到
20K。3结果与边界
论文摘要报告关键业务指标 ADSS 提升
1.036%，serving latency 增加 5.6%，训练和 serving 成本接近线上 SOTA。这个结果说明 token merge 的目标不是单纯追求压缩率，而是在序列变长后把业务增益和延迟增量放在同一个约束里。3边界也很明确：这是一个电商广告推荐系统的部署结果，不能把
20K 当作所有行为序列都应采用的长度，更不能把 +1.036% 当作脱离数据切分、特征更新周期和 serving 负载后的固定收益。token merge 的具体策略、蒸馏损失和线上序列分布需要在自己的数据上重新校准。最小验证动作
- 先按用户活跃度、行为新鲜度和序列长度分桶，画出 full-token、merge-only 和蒸馏版本的业务指标与延迟曲线。
- 除平均 latency 外，补测 p95 / p99、显存峰值、训练 token 数和序列截断率；长尾用户往往决定是否值得把上限推到
20K。 - 把 teacher 只用于训练的成本单独记账，线上只比较 student 的推理成本，不要把一次性 teacher 重训混进日常 serving 成本。
推荐系统：MISO 把排序模型的局部改动从经验试错改成可解释候选
它解决什么问题
排序模型迭代时，团队经常知道要扩大、替换或删除某个模块，却不知道先改哪里。MISO（Model Internal State Optimization）从已训练模型中提取参数、激活值、梯度和归一化统计量，把它们聚合成 ranking、alignment 和 comparison 三类信号，再生成一小组可解释的候选编辑。每次重训后重新提取这些状态，因此可以随着数据分布和系统要求变化调整改动方向。4
结果为什么要保守解读
在一个广告排序案例中，论文摘要称 MISO 改善了 normalized entropy，并且比专家驱动流程和黑盒扩展流程需要更少的验证轮次。但摘要没有给出提升幅度、验证轮次数、样本规模或更细的线上指标，所以这里不能写成一个带百分比的性能承诺。4
它更像一套降低实验搜索成本的工作流，而不是新的排序网络结构。只有当团队已经能稳定导出中间状态，并且每次验证的成本高到足以覆盖采集开销时，这个方向才有工程价值。
最小验证动作
先在一个固定排序模型上保存每层的参数、激活、梯度和 normalization statistics，并为每类状态定义可解释的候选改动。然后用同一个验证预算对照三条路径：专家选择、MISO 候选和黑盒搜索。除了 normalized entropy，还要记录每轮训练时间、验证次数、改动接受率和线上延迟；如果只提升离线指标，却增加了状态采集与重训成本，结论仍不成立。
今天先验证什么
- 长上下文推理：先测 HiSparse 类方案的 H2D 搬运和 cache 命中，再谈
4.7×吞吐。 - 单卡 agent：先在目标 Blackwell GPU 上复现 Muse Glimmer 的精度、上下文和并发条件，确认
20K tokens/sec/GPU的测量口径。 - 长序列推荐：用
20K作为压测上限，先画 token merge 对业务指标、P99 和显存的曲线。 - 排序模型迭代：如果每轮验证成本很高，再给 MISO 分配一个固定验证预算；摘要没有绝对数字，先用本系统的轮次节省来判断。
这四项更新的共同点是：性能数字都带着硬件、模型、数据或统计口径。先把对照条件补齐，再决定是否移植，比直接追最高 headline 更省时间。
References
- 1
- 2
- 3
- 4
This story was produced automatically by a channel. One sentence is all it takes for Neodrop to keep producing for you.