Netflix 詳述內部 LLM 服務平台：結合 Triton 與 vLLM，並自建邏輯解決受限解碼狀態同步問題

Netflix 分享將 LLM 推論納入內部服務平台的生產經驗，探討結合 Triton 與 vLLM 的架構選擇與維運細節。該平台基於 Netflix 現有的 JVM 服務層構建，由其負責路由、特徵獲取與後處理；較小的模型在 CPU 執行，較大的請求則交由 Triton 負責模型載入、批次處理與 GPU 排程。 在 GPU 路徑中，Netflix 選擇由 vLLM 執行推論，Triton 負責模型管理。由於 Triton 與 vLLM 版本不匹配會導致部署載入失敗，Netflix 必須將相容的發布版本固定並共同測試。針對 vLLM 對 Hugging Face 相容性不足的問題，Netflix 利用 vLLM 的擴展點來支援自訂架構與解碼行為；在 Triton 打包方式上，則選擇 vLLM backend 取代 Python backend，使模型與前端能更獨立地演進。 在強制模型輸出合法 JSON 等格式的受限解碼（Constrained decoding）應用中，解碼器必須在整個請求過程中維護狀態。當 vLLM 為管理 GPU 資源而暫停並於後續恢復請求時，狀態可能與 token 歷史不同步，為此 Netflix 增加了偵測變化並在繼續生成前重建狀態的邏輯。 部署流程方面，Netflix 採用 Red-Black 與 Versioned 部署策略處理模型層級變更。Versioned 部署會保留新舊版本並行，讓使用者在適應不相容的輸入或輸出 schema 後逐步遷移。此外，Uber 的生成式 AI 網關亦採用類似的應用與後端分離概念，在外部與內部模型間提供相容 OpenAI 的介面，並集中處理認證與快取。