你打开 Spotify，推荐结果最好立刻出现。哪怕模型更懂你，只要它让页面多等几秒，或每次请求都耗掉太多 GPU 算力，就很难服务全站用户。Spotify 与 NVIDIA 的这次合作，盯住的正是生成式推荐从原型走向生产时最现实的一关：怎样让大模型的推理更快、更省。
这里的推理（inference），指训练好的模型接到请求后生成结果。Spotify Engineering 披露，公司正探索用 NVIDIA 的 TensorRT-LLM 改进这一过程。TensorRT-LLM 是面向大语言模型的推理软件栈，负责优化模型在 NVIDIA GPU 上的执行、内存使用和并行处理。不过，官方尚未公布延迟、吞吐量或成本降幅，现阶段更准确的说法是“正在做性能工程”，而不是“优化已经完成”。本文关于系统表现的描述均来自 Spotify 单一机构信源。
推荐不再只是“先找再排”
传统推荐通常分两步：先从海量内容中捞出一小批候选，再预测用户偏好并排序。不同页面还可能各用一套模型和规则。生成式推荐则尝试让大模型结合用户和内容信息，直接产生或选择推荐结果。流程有机会整合，但计算负担也随之上升。
据 Spotify Engineering，Spotify 在 2026 年 1 月把基于大语言模型的技术用于播客推荐。系统沿用了 PLUM 论文提出的思路，采用 semantic ID-based generative retrieval——不直接生成播客名称，而是生成代表内容的“语义编号”，再把编号映射回目录中的播客。
它使用 beam search，也就是“束搜索”。可以把模型的生成过程想成不断岔开的路线：系统不会每一步只押一条路，而会同时保留若干条得分较高的 token sequence（词元序列），继续向下探索。最后留下的高分序列就是 semantic IDs，用来找到实际播客。
GPU 很强，堵点却可能在旁边
Spotify 的初始版本使用 vLLM 作为推理引擎。但按 Spotify 的技术归因，vLLM 的束搜索运行在核心 GPU engine 之外，因此出现 CPU 侧瓶颈；部分尚未填满的 KV blocks 还需要重新计算，增加 GPU 工作量。KV blocks 可以理解为模型生成时保存中间结果的一格格“草稿纸”。草稿没有被顺畅复用，机器就得回头重算。
结果是，高端 GPU 没有得到充分利用。Spotify 称，它在 1 月上线时选择了档次较低的加速器，以控制成本，并让负载保持在更合适的水平。这一点很能说明生产系统的逻辑：硬件越强不等于单位请求越便宜。若软件调度喂不饱 GPU，为顶级算力付费反而不划算。
个性化也要压缩进请求预算
生成式推荐还要解决“怎样把你是谁告诉模型”。把完整收听和互动历史写成文字最直观，但提示词会变得很长，既增加延迟，也提高 GPU 使用量。Spotify 因而只在近期实时收听等较小场景中少量使用这种方法。
团队也试过用少量 token 表示用户的 semantic ID，但认为仍需研究，尚未准备好投入生产。其目前最成功的做法是 soft token：把已有的用户 embedding——概括偏好的一串数字——投影到大模型的表示空间，压成一个特殊 token，再放进提示词。Spotify 称，这一方法已用于播客推荐，并正为内部大模型的其他任务做集成和评估。
为什么值得关注
这项工作的重点并不是再证明“大模型也能做推荐”，而是把问题推进到上线层：搜索路径怎样执行，中间结果怎样复用，用户信息怎样缩短，以及该买哪一档 GPU。生成式推荐能否铺到更多页面，最终取决于效果、等待时间、吞吐量和单次成本能否同时过关。
Spotify 还在探索 candidate scoring，即利用模型输出的 log probabilities（模型给各候选结果的概率分数）进行排序。供稿提到，可借助 SGLang 的 candidate masking 在一次请求中评估多个候选，而不是为每个候选分别推理。但材料没有给出实现细节或收益数据。
局限与未知
- Spotify 没有披露所用 vLLM 版本、GPU 型号、模型规模、beam width、流量及成本口径，因此不能据此做跨系统比较。
- 官方未提供 TensorRT-LLM 的 benchmark，也未说明它已经上线；合作目前应视为探索中的优化工作。
- candidate scoring 的材料不完整，无法确认其最终实现、性能或成本收益。