Stanford CS25：服務 Transformers - 前線教訓

執行摘要

在大規模服務 transformer 模型時，需要從關注模型能力轉向優化「乏味基礎設施」的生產推論。核心挑戰在於 prefill（輸入處理）與 decode（產生 token）階段之間的落差，decode 階段通常受記憶體頻寬限制，導致硬體利用率低下。透過以服務等級目標（SLO）明確定義工作負載、根據效率與能力的界限選擇模型，並使用投機解碼、量化等激進優化技術，才能在生產推論中取得成功。

定義推論工作負載與 SLO

有效的推論工程始於對工作負載的清晰定義，這決定了硬體與軟體架構。工作負載大致可分為三種原型：

• Chatbot Plus： 人機互動系統（例如 ChatGPT、Claude），主要指標是互動性，以每位使用者每秒輸出 token 數衡量。
• Background Agents： 執行需數秒或數分鐘的複雜任務的系統（例如程式碼代理），主要指標是最後一個 token 的耗時。
• Data Processors： 高量、突發性的工作負載（例如文件索引），主要指標是總體吞吐量，常以每美元產生的 mega‑token 數衡量。

主要效能指標

為了管理這些工作負載，工程師必須追蹤每個副本的特定指標，以決定如何擴展系統：

• Time to First Token（TTFT）： 使用者看到第一個輸出位元組前的延遲。
• Inter‑token Latency： 連續 token 之間的時間間隔。
• Queries Per Second（QPS）： 請求量，通常具有高度季節性與變異性。
• Prefix Reuse： 輸入 token 重疊的頻率，允許 KV 快取以降低計算成本。

模型選擇：效率 vs. 能力界限

模型的選擇取決於任務是受效率限制還是受能力限制：

效率受限的工作負載

在這類任務中，所需的智慧程度相對較低且容易達成，成本成為主要驅動因素。這類工作負載通常使用開源模型（例如 Mistral、Gemma），且常在單 GPU 副本上執行，以最大化成本效能。

能力受限的工作負載

這些任務需要最高可得的智慧，且目前唯一的解決方案是規模化。此類模型（例如前沿專有模型）體積龐大，需要每個副本多個 GPU，甚至多個節點。它們通常作為多代理系統中的協調者，管理較小、效率受限的子代理。

推論堆疊：引擎與硬體

推論引擎

推論引擎由 token 化的伺服器程序、CPU 上的排程器以及 GPU 執行組成。排程器的主要工作是確保 GPU 永不閒置。當前領先的開源引擎包括：

• vLLM： 廣受採用且具開放治理。
• SGLang： 高度聚焦效能，採用激進優化。
• TensorRT‑LLM： NVIDIA 提供的編譯 C++ 執行時，對小模型與小批次大小最佳化。

硬體限制

生產推論主要由 NVIDIA 資料中心 GPU（SXM 形態）主導，因其具備高頻寬記憶體（HBM）。decode 階段嚴重受記憶體頻寬限制；雖然 Tensor Core 每位元組可執行上千次運算，decode 階段卻只執行少量運算。因此 HBM 與高速互連（NVLink）對避免計算單元閒置至關重要。

大規模部署與韌性

服務上千顆 GPU 會帶來顯著的可靠性與成本挑戰：

• 硬體故障： H100 GPU 的平均故障時間僅以天或週計算。系統必須具備冗餘設計，確保硬體故障不會導致系統失效。
• 冷啟動與擴展： 為避免在變化的流量下浪費閒置 GPU，系統需要快速的副本啟動。這可透過檔案系統的懶加載、多層雲端快取，以及 checkpoint‑restore 技術（如 CRIU）來避免數分鐘的 JIT 編譯與 CUDA graph 捕獲時間。

效能優化技術

優化應遵循層級：先從高衝擊的演算法變更開始，接著是主機端工程，最後才是低階 kernel 工作。

投機解碼

投機解碼針對 decode 階段的記憶體頻寬瓶頸。小型「草稿」模型預測未來幾個 token，較大的目標模型在一次前向傳播中驗證它們。此技術可帶來 2 倍至 8 倍的加速，尤其在使用特定應用的草稿模型時效果更佳。

量化

降低精度（例如從 FP8 到 FP4）在記憶體受限與計算受限情境下皆能提供線性加速，因為減少了傳輸的位元組數並提升了每秒運算次數。然而，必須透過「vibe check」與正式評估來謹慎驗證，因量化在長序列上可能因累積誤差而降低效能。

主機端優化

在撰寫自訂 CUDA kernel 之前，工程師應使用 py‑spy 等工具找出 Python 層面的瓶頸。簡單的改動，例如在字典中快取指標而非重新建立張量，便能帶來顯著收益（例如在多模態推論中提升 10%），且不需要 GPU 端的變更。

可觀測性與除錯

可觀測性被定義為僅透過日誌即可除錯系統的能力。關鍵做法包括：

• 記錄 Token ID： 僅記錄字串不足以除錯微妙的 tokenizer 與聊天模板問題，必須記錄 token ID。
• 監控功耗： GPU 功耗與溫度是「免費」的指標，可用來偵測主機端瓶頸（例如 GPU 只消耗 2 kW 而非 3 kW，表示 CPU 未能提供足夠工作負載）。
• 評估尾部延遲： P95 與 P99 延遲至關重要，因為它們代表使用者的「卡頓」體驗，即使中位數（P50）延遲很低。

摘要

Modal 的 Charles Frye 討論了在大規模服務 transformer 模型時的工程挑戰，重點在於 prefill 與 decode 階段的關鍵差異以及硬體利用率的最佳化。