小红书精读：DuoLM: Fast and Effective Personalized Recommendation with Language Models

一个向量替掉全文，吞吐涨60倍🔥

各位算法同学们，LLM做推荐时，瓶颈通常不是模型不够大，而是每个候选都要输入全文，线上无法承受计算量。DuoLM的做法有点反直觉：离线把商品文本压成一个向量，线上只运行排序模型，单卡H100跑到教师模型的60倍吞吐，质量还没掉多少。

📄 DuoLM: Fast and Effective Personalized Recommendation with Language Models

🔧 编码器LLM把每条商品文本压成最后一个token的隐状态向量，再经RMS归一化和可学习增益组成的连续接口喂给排序LLM；商品表示与用户无关，可以离线预先算好，并在不同用户的请求间复用。

🧩 排序端把历史物品向量、反馈文本和候选向量拼进同一条因果序列，一次前向直接输出分数，不走自回归解码，所以候选之间互不干扰。

⚙️ 服务端做了三件事：虚拟token ID直接查GPU常驻的向量表，请求体缩小90%以上；多候选打分共享历史前缀KV，用树状attention mask隔离候选分支；分段prefill的CUDA Graph回放减少CPU调度和kernel launch开销。

📊 Amazon Books上NDCG@10是0.5586，超过全文教师模型的0.5440；Video Games是0.5298对0.5313，基本打平。

📈 单张H100上约每秒26,400个候选打分，是vLLM+自动前缀缓存服务的教师模型的60.1倍，对SGLang是109.9倍。

✅ 训练用交叉熵加教师分布KL蒸馏，温度τ和权重β都写明了，把教师在同一候选组内的相对偏好迁移到小模型。

总结感想：对做LLM排序又要扛高QPS的团队比较对口，尤其是候选多、历史长的场景。要盯的是NDCG@10和单卡候选吞吐，顺带看请求体大小与KV复用率；潜在问题在商品向量的离线存储和更新一致性，以及蒸馏要预先缓存教师在固定历史下的分数，历史分布一变就得重跑。

原文：AlphaXiv