對於許多剛接觸 AI 工程的開發者來說，部署一個大語言模型（LLM）可能只需要跑一個 Python 腳本或調用 API。但在 Netflix 這種規模的生產環境中，挑戰在於如何將 LLM 整合進現有的微服務體系，同時面對模型大小不一、硬體需求多變以及推論引擎更新極快的現實。
Netflix 分享了他們如何建構內部 LLM 推論平台的實務經驗，核心目標在於建立一套標準化的介面，讓應用端不需要在意後端是用 CPU 還是 GPU，或是使用了哪個版本的推論引擎。
混合推論架構的設計邏輯
Netflix 並沒有將所有 LLM 請求全部丟給 GPU 叢集，而是採取了分級處理的策略。
他們保留了原有的基於 JVM 的服務層，負責路由、特徵提取與日誌紀錄等通用邏輯。對於體積較小的模型，直接在 CPU 上以 In-process（進程內）方式執行，以降低延遲並節省成本。而對於大型模型，則會將請求委派給模型服務系統（MSS）。
在 MSS 中，他們選擇了 NVIDIA Triton Inference Server 作為核心管理層。Triton 的角色就像是一個模型管家，負責模型的載入、請求批處理（Batching）、GPU 資源調度以及支援多種框架的部署。這樣設計的好處是，無論底層硬體如何變動，對外的生產工作流都能保持一致。
vLLM 與 Triton 的協作關係
在 GPU 推論路徑上，Netflix 選擇了 vLLM 作為實際執行推論的引擎。vLLM 是一個專為 LLM 優化的推論庫，以高效的記憶體管理（如 PagedAttention）著稱。
這裡有一個關鍵的架構分工：Triton 負責管理服務環境（外殼），而 vLLM 負責執行推論（核心）。
然而，這種組合也帶來了版本相依性的挑戰。Netflix 發現 Triton 與 vLLM 的版本如果不匹配，可能會導致模型無法載入。因此，他們在實務上採取了版本釘死（Pinning）策略，必須將經過測試的相容版本成對綁定，才能部署到生產環境。
針對自定義模型的需求，由於 vLLM 對 Hugging Face 的原生支援有時不足以滿足 Netflix 的特殊模型架構或解碼行為，他們利用 vLLM 提供的擴展點（Extension points）來開發自定義的邏輯。
解決 Constrained Decoding 的狀態同步問題
在實務應用中，我們經常需要模型輸出特定格式（例如有效的 JSON），這需要用到 Constrained Decoding（約束解碼）。這是一種在模型生成每個 Token 時，透過過濾非法 Token 來強制導向正確格式的技術。
這類技術要求解碼器必須記錄目前的狀態（State），以判斷下一個 Token 該輸出什麼。但 vLLM 為了優化 GPU 資源，會採取暫停與恢復請求的機制。Netflix 發現，當請求被恢復時，解碼器的狀態可能會與之前的 Token 歷史紀錄失去同步。
為了修復這個問題，Netflix 增加了偵測機制，一旦發現狀態不一致，會在繼續生成之前重新構建解碼狀態，確保輸出的格式依然正確。
部署策略與解耦的價值
為了確保模型更新不會導致服務中斷，Netflix 採用了紅黑部署（Red-Black Deployment）與版本化部署（Versioned Deployment）。版本化部署允許新舊版本的模型同時存在，讓調用端可以在適應新的輸入輸出格式（Schema）後，再逐步遷移。
這種設計的核心在於解耦。無論是 Netflix 的做法，還是 Uber 建立的 Generative AI Gateway（將所有模型統一為 OpenAI 相容介面），目的都在於將應用端與底層的運行時（Runtime）和 hosting 環境隔離開來。
對工程師的啟示
Netflix 的經驗告訴我們，即便有了強大的抽象層（如 Triton 或 OpenAI 相容 API），底層的工程工作依然無法省略。封裝雖然能給予開發者穩定的介面，但維運人員仍需處理模型封裝、版本相容性、狀態同步以及部署隔離等繁瑣的細節。
在設計 AI 基礎設施時，不要過度迷信單一工具能解決所有問題，而應思考如何透過分層架構，在靈活性（快速更換推論引擎）與穩定性（版本控制與狀態管理）之間取得平衡。
來源：infoq.com
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。