推論 SLA
3 秒看懂
推論 SLA 是雲端廠商 / 模型平台對 AI 推論服務作出的可用性、響應速度、吞吐量等承諾，具體化為“首 Token 延遲 ≤ X 毫秒”“99.9% 請求在 Y 秒內完成”“月度可用性 ≥ 99.95%”等可量化指標。誰不達標，按約定賠付。它是大型模型從“玩具”到“生產級 API”的通行證，直接決定企業能否把 GPT-4o、Llama 3.1 等模型嵌入自動駕駛、金融風控、即時客服等關鍵業務。
3 分鐘產業解釋
傳統雲端 SLA 關注虛擬機器 / 容器的 uptime，而推論 SLA 面向模型服務化（Model‑as‑a‑Service），指標更具“模型味”：
- 延遲維度：首 Token 延遲（TTFT）、每 Token 延遲（TPOT）、端到端延遲（E2E Latency），通常以 P50/P95/P99 分位數給出。
- 吞吐維度：每 GPU/ 每例項的 requests per second（RPS）或 tokens per second（TPS），要求在一定併發下不降級。
- 可用性：請求成功率（如 HTTP 200 佔比）、模型存活探活（liveness/readiness）。
- 一致性：在低延遲／高吞吐壓力下，模型輸出質量不退化（如不出現亂碼、截斷、幻覺機率不飆升）。
產業邏輯：大型模型推論是高併發、低延遲、頻寬敏感、視訊記憶體密集的異構計算任務，任何環節（GPU 排程、KV‑cache 管理、網路轉發、令牌桶限流）的抖動都會被 SLA 放大。因此，提供硬推論 SLA 的平台必須在模型壓縮 / 量化、批處理策略（continuous batching）、投機解碼（speculative decoding）、分散式推論拓撲（張量並行 / 流水線並行）、跨地域負載均衡、算力冗餘等方面做足功課。
當前 AWS Bedrock、Azure AI、Together AI、Fireworks、國內阿里雲端百鍊、火山引擎等均已推出帶 SLA 的推論服務，競爭焦點逐步從“跑得通”過渡到“跑得穩、跑得快、賠得起”。
15 分鐘專家深入
推論 SLA 不僅是商業條款，更是推論系統工程能力的量化標尺。與訓練 SLA（少見，多以“作業完成時間”“失敗重試”形式存在）不同，推論 SLA 直接面對終端使用者，涉及線上服務全鏈路。
1. 推論 SLA 的核心矛盾
- 長尾延遲與分位數承諾：生成式模型一次推論的 token 數量可變（1 token～上千 token），且自迴歸生成天然序列，導致延遲分佈長尾。P99 延遲可能數倍於 P50。要求“P95 < 500 ms”需要針對性地減少尾部抖動，如 GPU 時間片搶佔、優先順序排程、推測解碼。
- 資源利用率與效能隔離：為了最大化 GPU 利用率，推論引擎通常採用動態批處理（continuous batching），但過量併發會引發排隊延遲和 KV‑cache 換頁爭搶。SLA 倒逼平台設計自適應 batching 策略，在超標前主動限流或彈性伸縮。
- 成本與冗餘：承諾 99.99% 可用性意味著必須多 AZ/ 地域部署，並預留顯著的緩衝算力（如 N+2 冗餘），直接拉高單位 token 成本。平台需要在 SLA 違約金和冗餘投入之間算賬。
2. 典型量化指標（行業標杆，未精確標數字，無據不編）
- TTFT：使用者發出請求到第一個 token 出現的時間。主流生產系統目標常為 < 100 ms（P50），對於 70B 引數 MoE 模型可能放寬到 <300 ms。[行業案例，未揭露具體平台]
- TPOT：連續兩個 token 之間的平均間隔（inter‑token latency），反映解碼效率。通常要求 P50 < 20 ms，使得生成速度超 50 token/s，達到人類閱讀舒適區。
- 可用性：類似雲端服務，每月請求成功率 ≥ 99.9%（“三個九”）是起步，關鍵業務要求 ≥ 99.99%。需要注意的是，“請求成功”不僅指 HTTP 200，還要求返回結果內容完整、語義正常。部分平台會在 SLA 中排除模型自身幻覺導致的失敗。[平台公開條款]
- 容量承諾：為每個開發者按訂閱級別保證 TPM（tokens per minute）或 RPM（requests per minute），超限返回 429 並明確不計入 SLA 異常（除非因平台故障誤限）。
3. 監控與賠付機制
推論 SLA 依賴細粒度的可觀測性：
- 監控：全鏈路埋點，從 API 閘道器 → 推論排程器 → GPU kernel 執行，每個環節打點延遲，聚合為分位數。平台通常提供即時 Dashboard 和告警。
- 賠付：若月度可用性低於承諾，按超出部分的時長折算服務信用或現金賠償，通常限制在月服務費的 100% 或某個倍數。生產關鍵應用通常要求對超額延遲也進行賠付（如每 100 萬個 503 請求賠 X 美元）。
技術原理
推論 SLA 的保障根植於模型推論系統（inference serving system）的全棧最佳化。下面建立一個從請求進入到 GPU 執行的簡化模型。
1. 推論服務架構與延遲分解
使用者請求
|
API 閘道器 (限流、認證、路由)
|
推論排程器 (排隊、batching、模型選擇)
|
KV‑cache 管理器 (視訊記憶體分配、分頁管理)
|
GPU 執行引擎 (kernel launch、attention、FFN)
|
響應拼接 & 流式輸出- 首次延遲 (TTFT) 核心在預填充（prefill）階段：對整個 prompt 做一次 Transformer 正向傳播，計算所有層的 KV‑cache，並生成第一個 token。該階段與 prompt 長度強相關（O(n²) 注意力），需高並行度。
- 每 token 延遲 (TPOT) 由自迴歸解碼決定：每次僅處理上一個 token，計算簡單但序列，且需讀取 KV‑cache，瓶頸在視訊記憶體頻寬和 kernel 排程。
2. 關鍵技術保障
a. Continuous Batching（連續批處理）
傳統靜態批處理等全批次完成再釋放，GPU 空泡嚴重。Continuous batching 允許請求隨時加入 / 離開批處理，GPU 計算資源被充分填滿。但過大的批次會擠佔 KV‑cache，引發換頁（paging），導致延遲抖動。為保障 SLA，排程器會監控佇列深度和 KV‑cache 水位，採用自適應批處理大小和搶佔式排程。
b. 投機解碼（Speculative Decoding）
用小模型快速生成多個候選 token，再由大型模型並行驗證，一次前向可產出多個 token，大幅降低 P50 延遲。但驗證失敗會回退，導致尾部延遲惡化，需精細控制候選步數以避免 P99 跳動。
c. 模型量化與稀疏化
INT8/FP8 甚至 4‑bit 量化減少視訊記憶體佔用和計算量，允許更大批次，降低排隊延遲。結構化稀疏（如 2:4 稀疏）可加快推論吞吐。量化需在精度損失可控範圍內，否則 SLA 中的“質量一致性”被打破。
d. 分散式推論拓撲
對於遠超單 GPU 的大型模型，採用張量並行（TP）將權重分片到多卡，流水線並行（PP）減少通訊開銷，或 DP‑TP‑PP 混合。通訊原語如 AllReduce、ReduceScatter 的微秒級延遲都會影響端到端 SLA，故需高速 NVLink、NVSwitch 和 RDMA 網路。
e. 彈性擴縮與冷啟動最佳化
當請求突發，動態拉起備用例項。模型載入從遠端儲存讀取數十 GB 權重，若冷啟動時間超 SLA 容忍，需熱備或預取。常見方案：保持部分例項 running，或使用 GPU 記憶體池化技術加速載入。
3. 示例：保障 P99 TTFT < 200 ms（估算口徑）
假定一個 7B 模型，prompt 512 tokens，GPU 為 H100。
- 預填充計算：約 512² 注意力，需要高效 FlashAttention kernel，理論上可控制在 50 ms 內。
- 排程排隊：若平均佇列長度 3，連續批處理下排隊等待 ≤ 50 ms。
- 網路與閘道器：10 ms。
- 總計目標 110 ms，留出緩衝區，P99 穩定在 200 ms 內。
一旦佇列積壓或 GC 停頓，P99 跳變，需通過擴縮容或流量限流恢復。
技術演進史
- 2018‑2020 年（BERT 時代）：推論主要面向分類 / 抽取，SLA 以簡單 QPS 和延遲衡量，批處理簡單，可用性依賴容器編排。
- 2021‑2022 年（GPT‑2/3 小規模部署）：生成式模型開始上線，首次 token 延遲和輸出長度成為痛點，推論引擎 TGI、NVIDIA Triton 等開始支援 continuous batching，SLA 概念萌芽。
- 2023 上半年（ChatGPT 爆發）：OpenAI 等提供 API，但 SLA 尚不成熟，爆紅 429 和延遲波動普遍。開源推論架構 vLLM 釋出，推動視訊記憶體管理與排程效率提升。
- 2023 下半年‑2024 年：雲端廠商和推論平台推出帶分位數延遲保障的推論 SLA，競爭白熱化。Fireworks、Together、Anthropic 等均將低延遲承諾作為賣點。2024 年，MoE 模型（Mixtral、DeepSeek‑V2）流行，其動態路由給 SLA 帶來新挑戰（專家負載不均導致尾部延遲）。業界探索自適應路由和專家並行。
- 2025 年展望：離線 / 線上混合推論、基於 LoRA 的多租戶適配、邊緣推論的 SLA 或將標準化。
技術路線對比
| 維度 | 自建推論叢集 (私有化) | 雲端託管推論服務 (Bedrock/Vertex AI) | 專業推論平台 (Together/Fireworks) | 通用 GPU 雲端按需自建 |
|---|---|---|---|---|
| SLA 提供者 | 內部運維團隊 | 雲端廠商 | 平台 | 使用者自己 |
| 典型延遲 P95 TTFT | 難以保證，依賴內部最佳化水平 | 一般 200‑500 ms（根據不同模型） | 追求低於雲端廠商，宣稱 <100 ms | 不可控，需大量工程投入 |
| 可用性 | 取決於自身設施，可高可低 | 公有雲端等級，99.9%‑99.99% | 對標雲端廠商或更高 | 取決於 GPU 穩定性 |
| 成本 | 硬體成本固定，但利用率可能低 | 按 token 計費，溢價但合規簡單 | 通常比雲端更便宜，但冷僻模型少 | 按例項計費，費用最低，但運維開銷大 |
| 靈活性 | 高，可定製裁剪 | 受限於支援模型列表和 schema | 快速上新模型，支援微調後部署 | 高，全棧可控 |
| 適用場景 | 資料敏感，大併發穩定業務 | 企業快速接入，有商業賠付保障 | 追求極致價效比和低延遲的創業公司 | 實驗、非關鍵應用 |
表中數字為定性估算，無確切來源，僅供參考。
上下游
- 上游：GPU 硬體（NVIDIA H100/B200、AMD MI300X）、高速網路（InfiniBand、NVLink）、推論引擎架構（vLLM、SGLang、Triton Inference Server）、模型壓縮工具（TensorRT‑LLM、LM‑Deploy）、監控平台（Prometheus、Datadog）。
- 中游：推論服務提供商（AWS、Azure、GCP、火山引擎、國內阿里雲端、騰訊雲端；獨立平台 Together AI、Fireworks、Anthropic API 服務）。
- 下游：垂直應用：Chatbot、AI 搜尋、程式碼助手、內容生成、遊戲 NPC、智慧客服、金融風控、自動駕駛雲端端模擬。對推論 SLA 敏感度由低到高：客服（秒級可接受）→ 程式碼補全（需 < 200 ms）→ 自動駕駛（毫秒級硬即時）。
關鍵指標
- 可用性 (Availability)：每月成功請求數 / 總請求數，排除客戶端錯誤和配額限制；通常計算“錯誤預算”，可用性 99.9% 意味著每月允許約 43 min 宕機。
- 尾延遲 (Tail Latency)：TTFT/TPOT 的 P95、P99，甚至 P999。
- 服務質量 (SLO vs. SLA)：SLO（服務等級目標）是內部目標，SLA 是外部合同承諾，後者常比 SLO 嚴格。
- 吞吐量 (Throughput)：RPS 或 TPS，需注意與延遲的折中。高吞吐會導致佇列延遲上升，降低延遲 SLO。
- 一致性 (Quality): 定量難，常用代理：輸出長度方差、無意義符號率、重複率，或業務指標（如搜尋任務完成率）。
供需與市場資料
- 推論算力市場增長迅速，據多方報告估算（如 SemiAnalysis、Gartner），2024 年全球 AI 推論晶片及服務市場可達數百億美元，到 2028 年可能超越訓練市場。
- GPU 雲端供不應求，優質推論 SLA 的服務價格較高，例如低延遲優先服務可能比“盡力而為”模式溢價 30‑50%。
- 開源模型（Llama、Mistral、DeepSeek）大幅降低推論門檻，但也促使平台間 SLA 競爭加劇。推論平台通過規模效應和工程最佳化降低每 token 成本，支撐 SLA。
- 國內由於模型備案和資料合規要求，推論 SLA 往往與模型部署區域和資料駐留繫結，催生本地化推論服務機會。
以上為行業判斷，具體產值資料未獲精確來源，屬估算範疇。
代表公司與資本對映
- NVIDIA：提供硬體基石（GPU、TensorRT‑LLM、Triton），其推論微服務（NIM）也包含 SLA 支援。
- 雲端巨頭：AWS Bedrock、Azure AI、Google Vertex AI 均推出一系列模型推論 SLA，資本投入於自研晶片（Trainium/TPU）和伺服器架構以最佳化效能。
- 獨立推論平台：Together AI、Fireworks、RunPod 等，以高效能推論和 SLA 為賣點，獲一線風投青睞。
- 國內：阿里雲端百鍊、火山引擎豆包大型模型平台、騰訊混元、智譜 API 等。部分企業如矽基流動、趨動科技深耕推論最佳化，與算力合作提供 SLA 能力。
- 資本對映：投資者關注“推論即服務”的網路效應：越多開發者使用，推論工作負載越聚集，平台能進一步最佳化批處理效率和成本，抬高對手進入門檻。推論 SLA 是這種網路效應的直接表現。
投資邏輯
- 從訓練到推論的重心遷移：隨著開源模型能力逼近閉源，企業需求從“訓練自己的大型模型”轉向“高效推論外部模型”，推論 SLA 成為平台鎖定客戶的護城河。
- SLA 驅動的溢價與粘性：一旦企業將特定 API 整合進生產（含 SLA 條款），遷移成本高，形成穩定經常性營收。
- 晶片和系統層的受益者：推論需求爆發拉動推論晶片、高速互連、液冷等產業鏈。能提供端到端 SLA 保障的整合方案（如 NVIDIA AI Enterprise + NIM）估值受益。
- 風險：推論 SLA 競爭可能淪為價格戰，各平台承諾過度導致高賠付；此外，SLA 僅覆蓋基礎通訊和可用性，難以解決模型可靠性（幻覺、安全），業務價值存在上限。
- 關鍵觀察點：各平台是否公開 P99 延遲 data 和實際賠付記錄；是否引入“質量 SLA”（如準確率承諾）；是否將推論 SLA 與微調、評估編排捆綁銷售。
常見誤讀糾偏
- 誤讀 1：“推論 SLA 只保證伺服器不宕機，延時高不算違約。”
糾偏：成熟的推論 SLA 明確包括延遲 KPI，如“P95 首 Token 延遲 < 200 ms”，若未達到，即使 HTTP 200 返回也視作違反 SLA。延遲定義需看清是全鏈路還是僅模型處理段。 - 誤讀 2：“月可用性 99.9% 意味著每月 43 分鐘宕機，超過就賠。”
糾偏：失敗請求並非僅以時長計。一臺伺服器宕機 10 秒但所有請求失敗，算作請求失敗納入錯誤預算，可能很快耗盡。錯誤預算為（1‑可用性）× 總請求數，而非連續時間。可用性 99.9% 下，若月請求量 1 億次，可錯 10 萬次。所以小機率長時間宕機不一定是主要風險，持續微小錯誤也會突破 SLA。 - 誤讀 3：“使用 MoE 架構模型，推論 SLA 更難保障，因為專家負載不均。”
糾偏：MoE 的“專家並行”本身不是 SLA 的天然殺手。通過智慧路由（re‑route 過載專家）、層次化 all‑to‑all 最佳化、以及預留容量，已有平台將 MoE 模型的推論延遲做到與稠密模型可比。難點在於工程實現，但並非不可攻克。
學習路徑
- 基礎：理解 Transformer 推論過程（prefill 和 decode），掌握延遲和吞吐指標。
- 系統工程：閱讀 vLLM 論文（“Efficient Memory Management for Large Language Model Serving with PagedAttention”）、Orca 論文（Continuous Batching），理解 KV‑cache 管理和排程。
- 分散式：研讀 Megatron‑LM 推論並行策略，瞭解 Tensor Parallelism 與 Pipeline Parallelism 對延遲的影響。
- SLA 設計：學習 Google SRE 書中的 SLO/SLA 工程方法，結合推論特定場景實踐錯誤預算。
- 案例研究：分析 OpenAI、Anthropic 的狀態頁面與 Postmortem，觀察它們如何描述延遲超限和可用性問題。
- 實驗：部署 vLLM 或 SGLang，壓測，設定 SLO，用 Prometheus + Grafana 監控，切身感受。
一句話總結
推論 SLA 是 AI 應用從 API 呼叫走向企業級業務生命線的契約，它倒逼底層異構計算、排程系統、模型壓縮技術的整體協同進化，也是衡量平台推論工程能力的最直接標尺。
延伸閱讀與來源
- 論文：Kwon et al. “Efficient Memory Management for Large Language Model Serving with PagedAttention” (vLLM) (2023)
- 論文：Yu et al. “Orca: A Distributed Serving System for Transformer‑Based Generative Models” (2022)
- NVIDIA Triton Inference Server 文件：Model Configuration and Scheduling
- Google SRE 書籍：Service Level Objectives
- AWS Bedrock SLA 頁面（公開條款，可檢視具體違約賠付方式）
- Fireworks AI 的技術部落格（如關於 continuous batching 和 speculative decoding 的實踐）
- 行業報告：SemiAnalysis “AI Inference Landscape” 2024‑2025
注：受限於檢索，具體資料均為定性描述或[未充分揭露]，實際專案應查閱最新平台服務協議和第三方基準測試。