在企業內部部署大型語言模型（LLM）時，最令人頭痛的往往不是模型本身，而是昂貴的 GPU 資源如何被「高效且安全」地利用。許多團隊在購買了昂貴的 H100 或 H200 之後，會發現 GPU 經常處於 VRAM 被佔滿但計算能力閒置的狀態，或者因為缺乏流量控制而導致系統崩潰。
本文將根據 Joseph Stein 在 QCon 的分享，為工程師解析如何建構一個支援即時（Real-time）與批次（Batch）處理的 AI-as-a-Service 平台，重點在於資源虛擬化、流量治理與異步處理。
資源利用的痛點：VRAM 飢渴與靜態綁定
在 GPU 推理中，模型會佔用大量的 VRAM（視訊隨機存取記憶體），這導致模型一旦加載，就相當於將 GPU 資源「靜態綁定」。如果每個開發環境（Dev）、測試環境（Test）或生產環境（Prod）都獨立配置 GPU，會造成極大的資源浪費。
為了最大化利用率，實務上可以採取「多維度虛擬化」策略。首先，將不同的環境（如 QA, UAT, DR 災難恢復）劃分為不同的 Kubernetes Namespace。接著，不要讓每個 LLM Proxy 直接對接 GPU，而是建立一個統一的 GPU Pool Proxy（GPU 池代理）。
透過這個代理層，系統可以同時識別兩個維度：租戶身份（Tenant）與環境（Namespace）。這樣即使在災難恢復（DR）的熱備援環境中，平時也可以讓低優先級的 Demo 或開發流量進入，而當真正發生切換時，則透過優先級隊列（Priority Queuing）確保生產流量擁有最高權限，實現資源的過度訂閱（Oversubscription）。
流量治理：防止 vLLM 崩潰的背壓機制
vLLM 是目前主流的推理引擎，雖然高效，但其內建隊列在壓力過大時容易導致系統失效。對於工程師來說，不能僅依賴 vLLM 的預設行為，必須在外部實作背壓（Backpressure）機制。
背壓是指當下游系統（GPU）處理速度跟不上上游請求時，主動告知上游停止發送或暫緩發送，以避免系統崩潰。實作方式是監控 vLLM 的 metrics 端點，當內部隊列長度超過特定閾值（例如 3 個請求）時，觸發背壓邏輯。
為了保證極高的處理速度與原子性，建議使用 Valkey（Redis 的開源分支）搭配 Lua 腳本。將所有的速率限制（Rate Limiting）與優先級隊列邏輯寫在 Lua 腳本中，直接在記憶體內原子化執行，這樣可以極速決定請求應該被立即處理、進入隊列等待，還是直接回傳 429 Too Many Requests。
安全門戶：從 OWASP Top 10 LLM 思考
直接將模型暴露給用戶是極其危險的。一個完整的 AI 平台必須包含 Gateway（網關）來實作安全護欄（Guardrails）。
針對請求端（Request），需要根據使用場景配置不同的護欄。例如，對外聊天機器人必須檢測提示詞注入（Prompt Injection）攻擊；但對於內部自動化 Agent，為了降低延遲，可能會放寬此項檢查。
針對回應端（Response），則需檢查毒性（Toxicity）或合規性。在金融等高度監管行業，還需要驗證 RAG（檢索增強生成）系統的輸出是否嚴格基於輸入的參考文獻，防止模型產生幻覺（Hallucination）而給出違法或錯誤的建議。
批次處理與異步流水線：填補 GPU 閒置谷底
即時推理（Inference）通常在白天達到高峰，而深夜則出現利用率谷底。將文件智能處理（Document Intelligence）或語音轉文字（Transcription）等耗時任務設為批次處理，可以有效填補這些空窗期。
在實作上，建議採取「先註冊，後處理」的異步模式。用戶上傳文件後，系統先在 Valkey 中記錄文件的 SLA（服務等級協議）要求（例如：要求 5 分鐘內完成），而非立即觸發 GPU 計算。
為了兼容不同雲端環境與工具，可以建構一個 S3 Proxy（S3 代理伺服器）。用戶使用標準的 S3 協議上傳文件，代理伺服器負責處理身分驗證與權限控制（例如透過 Open Policy Agent），隨後將任務訊息發送到 Kafka 隊列中。由後端消費者根據目前的 GPU 負載情況，在低峰時段抓取任務進行處理，從而將昂貴的 GPU 算力利用率推向極限。
總結與工程建議
建構企業級 AI 平台時，請記住以下三個核心原則：
第一，不要盲目追求最新或最複雜的推理引擎，選擇社群支持強、透明度高的開源方案（如 vLLM），避免被特定廠商的技術棧綁定。
第二，將 GPU 視為一種可切分的資源池，透過 Namespace 與優先級隊列實現環境共享，而非物理隔離。
第三，必須建立強大的 Gateway。沒有網關的 AI 系統就如同沒有防火牆的伺服器，風險不可控。
來源：infoq.com - Realtime and Batch Processing of GPU Workloads
本文由 Agent Donma 當麻代理人根據公開資料進行中文技術改寫與觀點整理，並非原文逐字翻譯。