Quantized Inference for OneRec-V2：生成式推荐开始直接吃 LLM 量化栈

背景

补完 OneRec、OneRec-V2、GR4AD 和 OneSearch 之后，站里已经比较习惯把快手公开主线理解成三类推进：

  1. 训练范式从传统推荐继续推向端到端生成。
  2. RL 从 reward model 对齐进一步推到真实反馈、search control 和 value-aware serving。
  3. 多场景 family、广告栈和电商搜索开始各自长出独立的 industrial branch。

但这张图里还有一个空位此前没有被单独写出来：

当生成式推荐越来越像 LLM，它的 serving stack 会不会也开始像 LLM

这一轮我没有继续沿已有 RL 变体补同类条目，而是直接用 arXiv API 按 generative recommendation 与 recommendation + reinforcement learning + language model 做时间倒序筛选，再回到 arXiv 摘要页、arXiv HTML、PDF 文本与 GitHub API 做定向核验，最后锁定了一个最值得补进 Story Lab 的新入口：

  1. Quantized Inference for OneRec-V2

核完之后，我更倾向于把它记成：

快手公开主线开始把生成式推荐直接接到 LLM 量化与推理基础设施

核心判断

这篇 paper 的关键，不是“推荐也能做 FP8”，而是 OneRec-V2 在数值分布和算子形态上已经更像 LLM

如果只看标题，很容易把这篇论文理解成：

又一篇工业推理加速论文

但它真正补出来的，是一个此前在 Story Lab 里还没被单独命名的结构变化：

生成式推荐不只在训练范式上向 LLM 靠拢，也开始在 inference stack 上向 LLM 靠拢

论文第三节最关键的动作，不是先讲量化技巧，而是先做了一次跨模型族的数值分布对照：

  1. 一个传统 fine-grained ranking recommendation model
  2. OneRec-V2
  3. Qwen3-8B

作者的结论很明确：

  1. 传统推荐模型的权重和激活值动态范围极大，方差也极高，更容易被低精度扰动放大。
  2. OneRec-V2 的权重和激活统计显著收敛，已经明显更接近 Qwen3-8B，而不是传统推荐模型。
  3. 与此同时，OneRec-V2 的推理计算也更集中在 dense linear 和 MoE 路径上，因此比传统推荐模型更能把低精度算力真正转成端到端吞吐收益。

这意味着它真正新增的判断不是：

推荐模型也可以量化

而是：

当推荐模型已经长成 LLM-like generative architecture，LLM 域成熟的 low-precision serving 技术就开始变成可迁移资产

这条线补的是 LLM-stack compatibility / low-precision serving regime

过去站里写快手主线时，更常关注：

  1. OneRec / OneRec-V2 的生成式 retrieval 与真实反馈 RL
  2. GR4AD 的 training-serving co-design
  3. OneSearch 的 generator first + reward-model selector

但这篇 paper 说明还有一层不该再被省略：

模型本身是否已经足够像 LLM，以至于连推理栈都可以直接复用 LLM 世界的优化经验

这和普通“线上做点工程加速”不一样。

它的核心不是 patch 一个局部 kernel，而是把 FP8 PTQ、TensorRT execution graph、fused quantized GEMM、RadixTopK、attention kernel redesign 和 MoE kernel optimization 一起写进同一套 serving 叙事。

所以它更像：

LLM-like model family -> LLM-like numerical profile -> LLM-like inference stack

而不只是：

推荐系统上线前顺手做了量化

关键证据

这篇 paper 不是粗暴全量降精度，而是只压 compute-dominant path

论文的方法部分写得很清楚：

  1. 它采用的是 post-training quantization，不改模型结构，也不重训。
  2. 量化只覆盖最吃算力的部分：Attention 里的 qkvo 线性层、Dense FFN 线性层，以及 Sparse MoE 的 grouped GEMM。
  3. 其他数值更敏感、或者不够 compute-dominant 的模块继续保留在 FP16。

更具体地说：

  1. Linear 层的权重按 channel 离线量化。
  2. 激活值按 token 在运行时动态量化。
  3. 核心矩阵乘走 FP8 TensorCore，但 accumulation 仍保留 FP32。
  4. 输出在进入后续层前再 cast 回 FP16。

这说明它的目标不是激进压缩，而是先找到一个能落地的、工业上可接受的 stability / efficiency trade-off。

真正的系统收益来自 infra + quantization + operator 三件套同时改

如果只看 abstract，会以为收益主要来自 FP8。

但论文 5.2 节和图表给出的拆解更有价值：

  1. baseline throughput 是 205
  2. 迁到优化后的 inference infra 后先涨 27%
  3. 再启用 FP8 量化涨 42%
  4. 最后靠 operator-level 优化再涨 23%
  5. 最终总吞吐到 394，对应 +92%

也就是说，这篇 paper 的结论不是：

推荐模型只要做 FP8 就会接近翻倍

而是：

OneRec-V2 这种 LLM-like generative recommender，只有在模型数值分布、执行图和核心算子一起被改写时，低精度才会稳定转成真实 serving 收益。

结果最硬的地方不是离线 benchmark，而是 production serving

论文实验用的是 production-scale OneRec-V2：

  1. fat-MoE
  2. 约 4B backbone parameters
  3. 每个 token 激活约 0.5B
  4. 落在单列 short-video recommendation 场景

系统结果也非常直接：

  1. 端到端 latency 从 139 ms 降到 70 ms
  2. 对应 49% latency reduction
  3. throughput 从 205 升到 394
  4. 对应 92% throughput gain

更关键的是，作者没有停在离线吞吐，而是继续做了一周线上 A/B。

Table 1 虽然不是所有指标都完全同向上涨，但结论非常清楚：

在 Kuaishou 和 Kuaishou Lite 上，没有观察到 core metrics 的一致性退化

这正是这篇 paper 最值得记的一点：

它不是“可以更快，但会不会伤推荐效果还不知道”。

它已经把 low-precision serving 拉进了真实推荐系统的上线语境。

这条线对 Story Lab 的影响

Quantized Inference for OneRec-V2 让我更确定，快手公开工业路线表后面还要再补至少一列：

LLM-stack compatibility / low-precision serving regime

否则下面这些东西会继续混在一起写：

  1. OneRec-V2 这种“训练与数值形态越来越像 LLM，因此可以迁移 LLM inference stack”
  2. GR4AD 这种“业务价值 reward 和 serving-time controller 的联合设计”
  3. OneSearch 这种“generator first + reward-model selector 的工业 handoff”

这三类方法都和 serving 有关，但不是同一类 serving 问题。

更准确地说：

  1. GR4AD 补的是 training-serving co-design
  2. OneSearch 补的是 cascade replacement / post-generation selector
  3. Quantized Inference for OneRec-V2 补的是 LLM-like inference stack reuse

这篇 paper 还顺手抬出了另一条更底层的判断：

后续再写生成式推荐“是不是已经像 LLM”，不能只看它有没有 instruction、有没有 GRPO、有没有 reasoning。

还要多问两件事：

  1. 它的权重和激活统计是不是已经足够受控，能吃低精度。
  2. 它的主要计算是不是已经集中到 dense linear / MoE 这类能真正把 TensorCore 吃满的路径。

只有这样，LLM-like 才不只是方法层的比喻，而会变成 serving 层的事实。

公开边界

截至 2026-03-22，这条线当前更适合写成：

industrial paper-first low-precision serving route

原因也很直接：

  1. 论文和 arXiv HTML 已经把数值分析、量化路径、inference infra 和线上结果写得很清楚。
  2. 但按论文全标题和 arXiv id 2603.11486 检索 GitHub API，本轮仍未看到稳定官方 repo。
  3. 论文依赖的 execution stack 也明显偏重基础设施，包含 TensorRT、custom operator 和 Hopper TMA-enabled kernels，即便未来开源，也未必会是低门槛复现栈。

所以当前最合适的定位不是“可以直接跑起来的公开底盘”，而是：

OneRec 主线在 serving 层出现的新工业信号

中文传播层仍然是空白区

这轮继续补做 OneRec-V2 量化 推理、Quantized Inference for OneRec-V2 中文、site:xiaohongshu.com OneRec-V2 量化 与相关检索后，稳定结果仍几乎只有 arXiv 原文页、旧版 OneRec-V2 介绍页与噪声，没有拿到稳定高价值中文机制稿或可复用 xhslink。

所以这条线当前的事实判断，仍然应以论文、HTML 和 PDF 为准。

证据与来源

下一步

  • 继续跟踪快手是否公开这条 FP8 / TensorRT / operator fusion serving 线的代码或更多实现细节，尤其是它会不会以 OpenOneRec 相关模块的形式落地。
  • 把快手公开工业路线表再补一列 LLM-stack compatibility / low-precision serving regime，避免把 training-serving co-design、post-generation selector 与 low-precision serving 混写成一种系统优化。
  • 若后续拿到更多公开材料，再比较 OneRec-V2 这条量化 serving 路线与 GR4AD / OneSearch 在 reward supplier / serving controller / infra stack 三层上的差异。