混合 RL rollout +53.3%、LLMVisor 解码误差降 4.4×：8月13日 CUDA 与 AI 系统加速速览 (2026)

今天的更新集中在一个共同问题上：GPU 变快不只靠换 kernel，还要把缓存容量、请求归因、量化格式和模型结构一起纳入调度。下面的数字不能横向比较：有的是 rollout 吞吐，有的是误差，有的是单卡 kernel 或推荐模型推理延迟。

快速判断

分组	更新	已报告结果	适用场景	今天先做什么
推理调度	MISA-T：按 workload 和 KV 驻留时间管理混合 RL rollout	Step3.7 端到端 rollout 吞吐 `+35.6%`；rollout-only 相对 sweep-tuned vLLM Router 最高 `+53.3%` 1	RLVR、RLHF、agentic rollout 共用异步推理服务，且 KV cache 容量成为瓶颈	先按 workload 标签统计 session 的 KV footprint 和驻留时间，再测 admission cap
多租户 serving	LLMVisor：把 prefill / decode 延迟拆给单个请求	相对 token-count baseline，decode 的 p90 / p99 相对误差最多改善 `3.5× / 4.4×`；调度路径为微秒级 2	需要按租户分摊 co-batching 成本，或在调度环里做延迟预算	用现有 profiling 数据拟合 FLOPs、内存流量、batch 和 context length 特征
量化 / kernel	CubicQuant：保留整数码流的非均匀 W1–W8 权重格式	`G=128`、W4 时，相对 clipped INT 的 RMSE 在 Gaussian / Laplace 样本上降 `13.49% / 28.14%`；H200 测到随 row 数变化的 A16 / Dynamic-A8 crossover 3	权重带宽是瓶颈，且 kernel 可以边重构边消费权重	先测代表性 GEMV 形状和 `G`，不要把重构误差直接写成端到端吞吐收益
推荐 serving	UniMoMo：按专家功能相似度压缩推荐 MoE	4-expert 版本在 A100 上 speedup `1.28×–1.63×`，NDCG@10 保持源模型的 `99.92%–102.30%`；2-expert top-1 最高 `2.21×` 4	已有训练好的推荐 MoE，愿意用代表性 calibration traffic 做离线压缩	先检查线上路由流量是否覆盖 calibration stream，再做单卡 batch 复测
推荐训练	固定显存预算时重新分配 batch 和 sampled negatives	理论规则偏向增大 batch、减少 negatives；四个序列推荐数据集的大多数实验收敛更快 5	sampled softmax 的最后分类层占显存，训练预算固定	固定 `B=n×k`，至少对比 `(32,512)`、`(64,256)`、`(128,128)` 的 AUL 和 NDCG@10

推理调度：MISA-T 处理的是 KV cache 的竞争关系

混合强化学习 rollout 的麻烦，不只是请求长度不同。RLVR、RLHF 和 agentic session 的序列结构、交互次数和 KV 驻留时间都不同；只按 prefix locality 路由，可能让长驻留的 agentic session 把缓存挤满，随后 prefix hit rate 下跌，吞吐一起掉。

MISA-T 在路由层增加三件事：自适应 session admission、按 workload 分配 session cap，以及把驻留时间纳入 KV demand 估计。没有 cap headroom 的新 session 会先 HOLD，而不是立即塞进某个实例。论文在 Step3.7 的 50 次迭代实验中，把 prefix-cache hit rate 从 74.5% 提到 96.2%，rollout 吞吐提升 35.6%，平均 iteration time 降低 22.8%。1

隔离 serving 效果后，Step3.7 相对 sweep-tuned vLLM Router 的 rollout throughput 提升 53.3%；Qwen3.6-35B-A3B 上提升 43.6%。实验使用 H200 节点，并为不同模型配置了不同的 TP 和 replica 组合。这些结果属于论文给定的 RL workload 和硬件条件，不能直接当作普通 LLM 对话 serving 的收益。1

最小验证动作：从服务日志中补齐 workload label、session KV footprint、驻留时间和 prefix hit rate。先做静态 cap、仅 admission、MISA、MISA-T 四组 replay；如果没有可靠的 serving-state snapshot，论文中的 cap 估计不会原样成立。

多租户 serving：先知道每个请求占了多少延迟

co-batching 能提高 GPU 利用率，却把一个 batch 的时间混成了所有租户的账。LLMVisor 用 roofline（计算与内存带宽上限）思路，为 prefill 和 decode 分别拟合分段线性模型，特征包括输入 token、上下文长度、输入长度平方项和 batch size。模型对请求级项是可加的，因此可以直接得到每个请求的延迟份额。2

在 Llama 3.1-8B、Qwen 2.5-14B / 32B 的 A100 和 H100 测试中，token-count baseline 没有显式建模 context length 与 batch size，decode 尾部误差尤其明显。LLMVisor 将 decode 的平均相对误差从 p90 0.21、p99 0.44 降到 0.06、0.10；prefill 的 p90 / p99 则从 0.05 / 0.30 降到 0.02 / 0.09。论文还报告其每次调度计算为微秒级，适合放进 critical scheduling loop。2

这不是一个零成本的通用预测器：参数需要用 profiling / warm-up 数据拟合，而且模型按硬件、TP 配置和 workload 特征建立。最小验证动作：保留现有的 token-count 账本，增加 batch size、context length、prefill / decode 阶段和 TP size 四列，按 p50、p90、p99 比较归因误差；不要只看平均延迟。

量化与 kernel：CubicQuant 的数字还停留在格式和局部执行层

CubicQuant 用两个形状参数和一个 scale，把均匀整数码映射到组内的非均匀重构值。它保留稠密整数码流，组大小为 G 时每组增加 8 bytes 元数据，有效位宽为 B + 64/G。W4、G=128 的有限组实验使用每种分布 15,360 个样本：相对最优 clipped INT，Gaussian 样本的重构 RMSE 降 13.49%，Laplace 样本降 28.14%；Uniform 只有 3.90%。3

H200 上的 kernel 测量使用 G=512，比较 A16 model-dtype path 与 Dynamic-A8 path。小 row 数时 A16 更快，row 数增加后 Dynamic-A8 才出现优势；论文只给出单卡 H200、SM90a 和部分 W2 / W5 / W8 形状的 latency 比，尚未完成跨 GPU 世代和端到端模型质量验证。3

因此它适合进入「权重带宽是否已经是瓶颈」的验证清单，不适合直接写进容量规划。最小验证动作：在自己的 M/N/K、activation dtype、GPU 架构和 route topology 上同时测 A16、现有 W4 和 Dynamic-A8；确保权重在 tile 内重构后直接消费，避免先展开成全精度再计算。

推荐系统：压缩专家比删专家更需要流量证据

UniMoMo 把已训练的推荐 MoE checkpoint 转成更小的标准 MoE。它不按参数距离合并专家，而是用无标签 calibration set 观察专家输出，用功能相似度构图，再以 routing mass 加权合并。高流量专家会被保护，避免把线上最常走的路径一起压掉。4

主实验覆盖 Amazon Beauty、KuaiRec 和 TenRec，在 A100 80GB、BF16、batch size 256 上测量。4-expert checkpoint 的 NDCG@10 为源模型的 99.92%–102.30%，speedup 为 1.28×–1.63×；更激进的 2-expert top-1 配置把 speedup 推到 1.47×–2.21×，但质量比的范围也扩大到 98.36%–104.24%。4

这里最容易被忽略的是 calibration traffic。未出现在 calibration stream 里的用户行为不会参与专家 affinity 和 exposure 估计。最小验证动作：按时间切分一份近期流量作为 holdout，比较压缩前后各专家的 routing mass、长尾用户 NDCG@10、P99 延迟和显存占用；不要只在论文数据集上复现平均分。

训练侧还有一个更朴素、也更容易落地的调整。Batch Size or Negatives? 在固定 B=n×k 的 sampled-softmax 显存预算下，理论上偏向让 n 尽可能大、k 尽可能小。论文在 MovieLens-1M、Gowalla、Netflix 和 MovieLens-20M 上比较 (32,512)、(64,256) 和 (128,128)，大多数场景中较大 batch、较少 negatives 的配置带来更低的 AUL（曲线下面积，越低代表收敛更快）。但具体最优点仍受数据集和优化器影响，不能把规则写成固定超参数。5

今天的验证顺序

先查 serving 账本：给每个请求补齐 workload、context length、batch、KV footprint 和驻留时间；没有这些字段，MISA-T 与 LLMVisor 都只能停留在论文复现。
再查局部 kernel：对 CubicQuant 这类格式，先用真实 M/N/K 和目标 GPU 测 latency，再决定是否值得接入端到端路径。
然后做推荐 MoE holdout：用近期流量检验专家合并是否伤害长尾请求和尾延迟。
最后调训练预算：固定显存预算，扫几组 n×k 不变的配置，同时看 AUL、NDCG@10、step time 和有效吞吐。

性能数字只有和缓存拓扑、请求分布、矩阵形状、路由流量或显存预算放在一起，才足以决定下一步改哪一层。

混合 RL rollout +53.3%、LLMVisor 解码误差降 4.4×：8月13日 CUDA 与 AI 系统加速速览