推薦系統
NVIDIA 生成式推薦堆疊重寫 KV 與 beam search，5K 上下文推論快 2.27 倍
NVIDIA 將 HSTU、動態 embedding 與 Semantic ID 生成式推薦整理成可執行的 PyTorch 參考堆疊。它針對「長歷史、只生成數個 token、beam width 極大」的推薦負載重寫快取及解碼路徑，但數據目前限於 NVIDIA 硬件與合成配置。
生成式推薦不是把聊天模型直接接到商品目錄。它把使用者歷史視為序列，再預測下一個商品或動作；實際負載往往包含數千個歷史 token、只輸出兩至三個 Semantic ID，卻要同時維持 128 或 256 條 beam。這與 vLLM、SGLang 擅長的多使用者、長時間自回歸聊天不同，也令一般分頁 KV cache 重複保存大量共同前綴。
NVIDIA 公開的 `recsys-examples` 把兩條路徑放進同一 PyTorch 堆疊。HSTU 路徑以 TorchRec 管理使用者、商品及事件 embedding，DynamicEmb 只為真正出現的 ID 分配列，並在 GPU HBM 與鎖頁主記憶體之間按分數淘汰。密集網路則接入 Megatron-Core、FBGEMM attention 與融合 CUDA kernel。官方在兩部 DGX H100 上報告，逐步套用這些最佳化後，模型 FLOP 利用率由 7.65% 提高至 31.40%。
Semantic ID 路徑把快取拆成所有 beam 共用的 `ContextKV`、各分支短暫使用的 `BeamKV`，以及只記錄祖先關係的 `BeamPath`，另加入連續批次、CUDA Graph 重播及受商品集合約束的 top-k。單張 H100、Qwen3-1.7B、5,000-token 上下文、batch 4、beam width 256、輸出三個 token 時，離線延遲由 SGLang 的 349.857 毫秒降至 154.224 毫秒，即快 2.27 倍；線上吞吐量則由約 10.7 升至 19.7 request/s。
這套程式碼的價值在於呈現推薦模型不能照搬聊天 serving 的原因，但並未證明推薦品質提高。測試使用理想 GPU 快取命中率、單一 Qwen 規模與 NVIDIA 加速器；大目錄的 SSD 或遠端參數伺服器命中、資料更新一致性及真實 P99 延遲，仍是部署前必須重測的部分。