Spotify 將生成式推薦推論從 vLLM 搬到 TensorRT-LLM
Spotify Engineering（與 NVIDIA 合著） · 2026-10-16
Spotify 把生成式推薦的線上推論，從「vLLM 做 beam search、SGLang 做候選打分」的拼裝架構，收斂到單一的 TensorRT-LLM 引擎，並與 NVIDIA 合作補齊它缺少的功能。依文中數據，以 1.7B 的 Qwen3 變體測得，beam search 成本最多降低 54%，打分最多降低 7%。
這次合作的目的，是讓 beam search、候選打分與使用者 soft token 三種工作負載共用一套服務。Spotify 的目標是用一個大型個人化語言模型，在即時情境下服務多個產品介面。
原本的問題
Spotify 的 Podcast 推薦在 2026 年 1 月上線，採用 PLUM 路線：模型生成語意 ID（semantic ID），再對應回目錄中的項目。初期引擎是 vLLM，但它的 beam search 在核心 GPU 引擎之外執行，造成 CPU 端瓶頸，部分填充的 KV block 也要多做 GPU 重算。為了壓低成本與負載，Spotify 當時只好改用較低階的加速器（文中未點名型號）。
候選打分是另一條路。最直接的做法是「fan-out」，每個候選各發一次推論；Spotify 改用 SGLang 的候選遮罩（candidate masking）做法，一個請求就能替多個候選打分。於是同一個模型要靠兩套引擎服務，各自維運。
三種個人化方式
- 純文字使用者歷史：把歷史轉成 prompt，prompt 很長、延遲高、GPU 用量大，只用在最近的即時串流。
- 使用者語意 ID：擴充模型詞彙表，prompt 短且不需自訂推論程式碼；微調初步結果不錯，但尚需更多研究才能上線。
- soft token：成效最好。把既有的使用者 embedding 投影到 LLM 的 embedding 空間，成為單一 soft token，只微調一部分權重。推論時，在第一次 forward 之前把投影後的向量插入 prompt。目前用於 Podcast 推薦，其他任務還在評估。
採用的方法：補齊 TensorRT-LLM
TensorRT-LLM 在 beam search 的硬體利用率較好，卻缺三樣東西：等同 SGLang 的 Score API、注入 soft token 的能力、以及一次回傳多條 beam。Spotify 與 NVIDIA 把這些補進上游：
| 功能 | 釋出版本 |
|---|---|
| beam search 回傳多條序列 | v1.2.0rc3 |
trtllm-serve 支援 out-of-tree 模型 | v1.2.0rc4 |
透過 image_embeds 傳入多模態 embedding | v1.3.0rc0 |
| Python API 的多項目打分 | v1.3.0rc20 |
實作上有三個重點。第一，beam search 改成在 sampler 內執行，降低主機端開銷，再配合 overlap scheduling 提高 GPU 使用率；原本的 C++ sampler 換成更依賴 PyTorch、也更有彈性的設計。第二，soft token 以客製化的 Qwen3 擴充實現，借用 out-of-tree 模型支援，透過多模態請求參數接收使用者向量，投影後取代 soft token 的位置。第三，多項目打分讓運算量隨候選數線性成長，不必每個候選發一個請求，但仍需自建服務層處理 tokenization 與請求批次化。
實際效果
文中的實測對象是 1.7B 的 Qwen3 變體：beam search 成本最多降 54%，打分最多降 7%。延遲、吞吐等細部數字只出現在文中的圖表，內文沒有列出，本文也不引用。
對自行跑生成式推薦的團隊，有兩個具體檢查點。若你的 beam search 跑在引擎之外，先量 CPU 端耗時與 KV block 重算的比例；若你靠 embedding 做個人化，soft token 路線加上 out-of-tree 模型支援，可以不改引擎核心就接入。文中也提到 TensorRT-LLM 近期新增了 prefill-only embedding 服務的支援。
後續工作包含量化與針對 NVIDIA Blackwell 的最佳化，文中未給時程。
原始來源：Spotify Engineering、PLUM（arXiv 2510.07784）、TensorRT-LLM PR 15424