Netflix 自建 LLM 推論平台
Netflix 把 LLM 推論整合進既有 JVM 服務平台：小模型直接在 CPU 程序內執行，大模型則交給 Model Serving System，由 NVIDIA Triton 負責模型載入、批次處理與 GPU 排程，vLLM 專心做推論。應用端仍使用同一套介面處理路由、特徵取用、候選生成與紀錄，實際可同時支援即時及批次工作，也能要求模型輸出有效 JSON 等固定格式。
現實應用
這套架構適合模型種類多、流量大，又不希望每個產品團隊自行管理 GPU 的公司。推薦系統、內容理解、搜尋、客服與內部自動化都用得上。平台團隊可以統一控管硬體、版本及部署方式；應用團隊只需面對穩定介面，不必跟著推論引擎頻繁改版。
期望評估
我認為低標期望是把 CPU 小模型與 GPU 大模型納入一致的上線流程，減少各團隊重複處理模型封裝、監控及部署。高標期望則是形成公司內部的 AI 基礎設施層，讓模型、推論引擎與產品服務各自演進。不過抽象層不會消除底層差異，效能調校和相容性問題仍得由專門團隊負責。
商業策略分析
受影響最大的是雲端模型 API、GPU 基礎設施與企業 AI 平台供應商。Netflix 證明大型企業可能保留 OpenAI-compatible 介面，卻把核心推論搬回自有平台，以換取成本、延遲及客製能力。我猜一般公司不值得照規模重做；但只要模型支出、資料治理或延遲已成為明顯問題，就值得跟進「統一入口、底層可替換」的設計。
實作細節
Netflix 沒有釋出可直接安裝的完整平台。其 GPU 路徑以 Triton 包住 vLLM，可選 Python backend 或 vLLM backend；後者讓模型與前端較能獨立升級。已知問題包括 Triton、vLLM 版本不合會讓 backend 載入失敗，因此必須測試後成對鎖版。自訂模型也可能超出 Hugging Face 相容範圍，需要使用 vLLM extension。受限解碼在請求暫停、恢復後可能狀態不同步，Netflix 額外重建 token 狀態；模型介面不相容時，則以 Versioned deployment 讓新舊版本並存遷移。