Provisioned Throughput
3 秒看懂
一句話:Provisioned Throughput(PT)是一種 “包場制”算力消費模式——客戶提前鎖定/預留一整塊確定性的計算吞吐能力(如 LLM 推論的 token/s、儲存的 IOPS、網路頻寬),按時間計費,換取可預測的延遲與吞吐 SLA,而非按實際使用量(on-demand)逐次付費。
類比:On-demand 像打出租車按公里計費,Provisioned Throughput 像包一輛車一整天——車隨時等你,費用固定,確定性拉滿。
3 分鐘產業解釋
為什麼這個概念在 AI 產業鏈中突然變重要?
過去三年,AI 推論服務的計費模型經歷了從”按 token 計量”(pay-per-token)到”按吞吐包月”(provisioned throughput)的結構性遷移。這不是一個純粹的定價花樣,而是整個 AI 基礎設施從”水電煤”向”專線專網”演進的縮影。
驅動力鏈條如下:
- 大型模型推論成為生產環節:當 LLM 從 demo 走進客服、程式碼生成、搜尋增強等生產流水線,企業不能再容忍”高峰期排隊、延遲抖動”的不確定性。
- GPU 資源的物理稀缺性:頂級 AI 加速器(H100/H200/B200 等)供應仍然緊張,雲端廠商無法無限擴 on-demand 池,必須通過預置承諾來管理供需平衡。
- 客戶願意為確定性溢價付費:對於 SLA 敏感的金融、醫療、客服等場景,“貴一點但保證 100ms 以內響應”遠勝於”便宜但看天吃飯”。
產業含義:Provisioned Throughput 模式讓雲端廠商可以把未來的 GPU 算力提前”賣期票”,鎖定營收(提升 ARR 質量),同時也把風險轉嫁為客戶的承諾期限。這與半導體行業的 wafer agreement(晶圓長期協議)在商業邏輯上高度同構。
15 分鐘專家深入
一、PT 模式在 AI 推論中的運作機制
以主流雲端平台的 LLM 推論 Provisioned Throughput 為基準描述(具體定價和規格因廠商、模型、區域而異,以下為定性機制描述):
核心邏輯:模型副本 × 並行配置 → 確定性吞吐上界
┌──────────────────────────────────────────────────────┐
│ Provisioned Throughput 單元 │
│ │
│ ┌─────────────┐ ┌─────────────┐ ┌─────────────┐ │
│ │ Model Copy 1│ │ Model Copy 2│ │ Model Copy N│ │
│ │ (GPU Group) │ │ (GPU Group) │ │ (GPU Group) │ │
│ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │
│ │ │ │ │
│ └────────┬───────┘────────┬───────┘ │
│ │ │ │
│ Load Balancer / Router │
│ │
│ ◆ Model Units = 副本數 = f(模型大小, 精度, 並行策略) │
│ ◆ 總吞吐 ≈ 單副本吞吐 × 副本數(理想線性擴充套件) │
│ ◆ 客戶鎖定 Model Units 數量,按小時/月計費 │
└──────────────────────────────────────────────────────┘
關鍵引數維度(定性):
| 維度 | 說明 |
|---|---|
| Model Units | 代表執行該模型所需的最小 GPU 複製單元數,模型越大、精度越高,單 unit 需要的物理 GPU 越多 |
| 副本倍數 | 客戶購買的 unit 越多,併發吞吐線性擴充套件(在 GPU 供應允許的範圍內) |
| 承諾期限 | 通常有月度/年度合同選項,期限越長折扣越深 |
| 彈性層級 | 部分平台支援”基礎 provisioned + on-demand burst”混合模式 |
二、與其他計費/排程模式的結構性差異
價格 ↑
│ Provisioned ─── 固定價格/固定吞吐
│ (確定性溢價)
│ ╲
│ ╲
│ ╲ On-demand ─── 按量浮動
│ ╲
│ ╲
│ ╲ Spot/Preemptible ─── 競價
│ ╲
└──────────────────────────────── 吞吐確定性 →
三、為什麼這個模式改變了算力經濟學
對雲端廠商(供給端):
- 將零散的 on-demand 碎片流量聚合為大塊可預測負載,提升 GPU 利用率規劃精度。
- 預收款模式改善現金流量和營收可見性(類似 SaaS 的 ARR 邏輯)。
- 但風險在於:如果客戶買的 provisioned 吞吐長期閒置,GPU 實際利用率下降,單位經濟變差。
對客戶(需求端):
- 確定性 = 可靠的產品體驗:對話延遲 P99 可控,不會因鄰居租戶突發流量被擠壓。
- 成本可預測:月度固定賬單,財務規劃友好。
- 鎖定期是雙刃劍:如果模型升級需要切換(如從 GPT-4 遷移到 GPT-4o),已有 provisioned 承諾可能成為遷移摩擦。
技術原理
4.1 AI 推論層 Provisioned Throughput 的技術實現
Provisioned Throughput 的本質是資源隔離 + 預分配。實現路徑因平台而異,但底層機制可歸納為三層:
第一層:物理資源預留(Resource Reservation)
┌──────────────────────────────────────────────┐
│ GPU 叢集物理層 │
│ │
│ ┌──── Provisioned Pool ────┐ ┌─ On-demand ┐│
│ │ GPU 0-7 → Customer A │ │ GPU 16-23 ││
│ │ GPU 8-15 → Customer B │ │ (共享池) ││
│ │ (硬隔離 / 軟隔離) │ │ ││
│ └──────────────────────────┘ └─────────────┘│
└──────────────────────────────────────────────┘
- 硬隔離:Provisioned 客戶的 GPU 被物理或 VM 級別獨佔,完全不受其他租戶影響。NVIDIA MIG(Multi-Instance GPU)可將單 GPU 硬體切分為多個獨立例項,提供強隔離保證,屬於此類別。代價是資源碎片化。
- 軟隔離:通過 Kubernetes Resource Quota、GPU 時間片排程(如 NVIDIA MPS)實現邏輯隔離,靈活性更高但隔離度略低。
- 大多數生產級 PT 服務傾向於硬隔離或接近硬隔離(MIG 級分割槽),因為 SLA 承諾需要可證明的隔離保證。
第二層:模型排程與並行策略
Provisioned 的 “吞吐量” 最終由以下技術棧決定:
| 技術棧層 | 關鍵引數 | 對吞吐的影響 |
|---|---|---|
| 模型精度 | FP16/BF16/FP8/INT4 等 | 精度越低,單 GPU 吞吐越高,但需驗證質量 |
| 張量並行度(TP) | 模型層內切分到幾張卡 | TP 越大,單請求延遲越低但通訊開銷增大 |
| 流水線並行度(PP) | 模型層間切分 | 影響單請求延遲和 batch 效率 |
| 批處理策略 | Continuous batching / Dynamic batching | 批越大吞吐越高,但單請求延遲可能增大 |
| KV Cache 管理 | PagedAttention 等 | 影響併發請求數的上界 |
注意:並行訓練中的通訊模式(AllReduce、All-to-All)與推論服務的排程模式是不同層面的問題。Provisioned Throughput 關注的是推論服務的吞吐 SLA,其底層使用的是推論引擎(如 vLLM、TensorRT-LLM、Triton)的排程能力,而非 Megatron 式訓練並行。
第三層:SLA 監控與保障
請求 → API Gateway → Load Balancer → PT 專屬推論副本池
│
├── Latency Monitor
├── Throughput Meter (tokens/s)
└── SLA Breach Alert → 自動擴容
(如果配置了 burst)
4.2 儲存層 Provisioned Throughput 的技術實現
在 AI 培訓/推論的全棧中,儲存層也有 provisioned throughput 概念:
- 塊儲存(如 AWS EBS io2 Block Express、Azure Ultra Disk):預置 IOPS 和吞吐 MB/s,確保資料載入不成為 GPU 的瓶頸。
- 檔案儲存(如 AWS FSx for Lustre):Provisioned 吞吐模式下,訓練資料讀取頻寬與 GPU 算力匹配。
- 物件儲存:通常不支援 provisioned throughput,而是通過 Transfer Acceleration 或字首分散策略解決熱點。
4.3 網路層 Provisioned Throughput
- 跨節點 GPU 通訊(如 NCCL over RoCE/InfiniBand):頻寬由物理拓撲決定,非”provisioned”但需要網路工程保障。
- CDN / API 出口頻寬:部分雲端廠商提供 Provisioned Bandwidth 選項,確保推論結果回傳不受網際網路擁塞影響。
技術演進史
| 時期 | 階段 | 關鍵事件 |
|---|---|---|
| 2006-2015 | 儲存 Provisioning 起步 | AWS 推出 EBS Provisioned IOPS SSD(io1),首次在雲端儲存中引入”預置 IOPS”概念。傳統 on-prem SAN 儲存早已有類似 QoS 機制,但雲端化後成為標準化產品。 |
| 2016-2019 | 網路與計算 Provisioning 擴充套件 | 雲端廠商開始提供 Provisioned IOPS v2/v3 級儲存(如 io2 Block Express)、Provisioned 頻寬選項。計算層的 Reserved Instances 是另一種”provisioned”形式,但粒度粗(整機預留,非細粒度吞吐預留)。 |
| 2020-2022 | AI 推論 Provisioned 模式萌芽 | Azure OpenAI Service 引入 Provisioned Throughput Units(PTU)概念,讓客戶可以為 GPT 系列模型預購推論吞吐。AWS Bedrock 也推出類似 Provisioned Throughput 產品。這是 PT 概念從基礎設施層向 AI 模型服務層躍遷的標誌性時刻。 |
| 2023-2024 | PT 成為 AI 推論主流商業模型 | 幾乎所有主流模型服務提供商(雲端廠商自研 + 第三方如 Anthropic、Cohere 等通過雲端平台分發)都提供 PT 選項。PT 單位的定價成為衡量模型商業化成熟度的重要指標。 |
| 2025+ | 演進方向 | 推測方向:① PT + 彈性 burst 的混合模式標準化;② 跨模型 PT 的可遷移性(類似”算力通證”);③ 推論叢集級別的 PT 排程(而非單模型級別)。 |
技術路線對比
AI 推論計費/排程模式量化對比
| 維度 | On-Demand / Pay-per-Token | Provisioned Throughput | Spot / Preemptible 推論 |
|---|---|---|---|
| 計費單位 | 按輸入/輸出 token 數 | 按 Model Units × 時間 | 按實際使用時間(大幅折扣) |
| 吞吐確定性 | 低(共享資源池,峰值可能排隊) | 高(獨佔/預留資源) | 極低(隨時可能被驅逐) |
| 延遲 SLA | 通常無硬 SLA | 有 P95/P99 承諾 | 無 |
| 成本效率(穩態) | 中等 | 長期看最優(深度折扣) | 最低單價,但不穩定 |
| 適合場景 | 原型開發、低頻呼叫 | 生產級服務、SLA 敏感應用 | 批處理、非即時任務 |
| 客戶鎖定程度 | 無 | 中-高(承諾期限) | 無 |
| 資源利用率風險 | 由雲端廠商承擔 | 由客戶承擔(買多了閒置) | 由雲端廠商承擔 |
| 典型價格敏感度 | 單價高但無浪費 | 總價可預測,單價低於 on-demand | 單價最低 |
儲存層 Provisioned vs. 通用對比
| 維度 | 通用 SSD (gp3 等) | Provisioned IOPS SSD (io2 等) |
|---|---|---|
| 基線 IOPS | 免費含基礎 IOPS,超出按量付費 | 全量 IOPS 需預購 |
| 吞吐上界 | 有預設上限,可加購 | 按預購值保證 |
| 適用性 | 一般 AI 工作負載 | 大規模訓練檢查點寫入、高併發推論快取 |
注意:上表中的具體定價、IOPS 上限等因廠商、區域、世代而異,此處為定性對比架構,具體數值請參見各廠商官方定價頁。
上下游
上游(決定 PT 的能力邊界)
┌─────────────────────────────────────────────────────┐
│ 上 遊 供 應 鏈 │
├─────────────┬───────────────┬───────────────────────┤
│ AI 加速器 │ 伺服器/OEM │ 雲端基礎設施 │
│ │ │ │
│ GPU/TPU/ │ DGX/HGX 系列 │ 資料中心 + 網路 │
│ NPU 供應量 │ 及定製伺服器 │ (InfiniBand/RoCE) │
│ │ │ │
│ → 決定 PT │ → 決定單 PT │ → 決定叢集級 │
│ 總產能上限 │ Unit 的物理 │ PT 的擴充套件上界 │
│ │ GPU 格式 │ │
└─────────────┴───────────────┴───────────────────────┘
- AI 加速器供應:PT 的總可用容量直接取決於 GPU/加速器的物理供應量。當 H100/H200 供不應求時,雲端廠商的 PT 售罄速度極快,形成”一 unit 難求”的局面。
- 推論引擎:vLLM、TensorRT-LLM、SGLang 等開源推論引擎的效率直接影響”每 GPU 可售出的 PT 量”。引擎最佳化 20% 可能意味著同樣 GPU 數量下可多賣 20% 的 PT。
- 模型最佳化:量化(INT4/FP8)、蒸餾、剪枝等技術可在不顯著降低質量的前提下提升單 GPU 推論吞吐,間接提升 PT 的價效比。
下游(PT 的消費者)
┌─────────────────────────────────────────────────────┐
│ 下 遊 應 用 層 │
├─────────────┬───────────────┬───────────────────────┤
│ 企業 SaaS │ AI-Native │ 垂直行業 │
│ │ 應用 │ │
│ CRM/客服/ │ 程式碼助手/ │ 金融風控推論/ │
│ 文件處理 │ 寫作工具/ │ 醫療影像分析/ │
│ │ 搜尋增強 │ 自動駕駛推論 │
│ │ │ │
│ → SLA 敏感 │ → 成本敏感 │ → 合規+SLA 雙敏感 │
│ → PT 大客戶 │ → PT+On-demand │ → 長期 PT 合同 │
│ │ 混合使用 │ │
└─────────────┴───────────────┴───────────────────────┘
關鍵指標
| 指標 | 定義 | 重要性 |
|---|---|---|
| Provisioned Throughput (tokens/s) | 客戶鎖定的每秒處理 token 數上界 | 核心業務指標,直接決定使用者體驗上限 |
| Model Units | 平台定義的最小 PT 購買單位 | 不同模型的 Unit 含義不同,跨模型不可直接比較 |
| GPU Utilization Rate | PT 內 GPU 實際計算利用率 | 客戶成本效率的關鍵;長期低於 50% 說明買多了 |
| Time-to-First-Token (TTFT) | 首 token 響應延遲 | PT 模式下通常有 SLA 承諾 |
| Inter-Token Latency (ITL) | token 間生成間隔 | 影響使用者體感流式輸出速度 |
| P99 Latency | 第 99 百分位延遲 | SLA 的硬約束線,PT 模式的核心賣點 |
| Commitment Discount % | 相對 on-demand 的折扣幅度 | 期限越長折扣越大,具體比例因廠商和合同而異 |
| Burst Headroom | 超出 provisioned 基線的彈性擴充套件能力 | 部分平台支援,是 PT 靈活性的重要補充 |
供需與市場資料
市場格局(定性判斷)
- 供給側高度集中:全球 AI 推論 PT 市場主要由三家超大規模雲端廠商(AWS、Azure、GCP)主導,合計估計佔據 [未充分揭露] 以上份額。其次是國內雲端廠商(阿里雲端、華為雲端、騰訊雲端)和專業推論服務商(如 CoreWeave、Lambda 等)。
- 需求側快速增長:隨著企業 AI 應用從 POC 進入生產,Provisioned Throughput 需求預計以 [行業估算] 年化 60-80% 的速度增長(2024-2026E),遠快於整體雲端運算增速。
- 供需缺口仍然存在:頂級 AI 加速器的供應緊張是 PT 容量的最大瓶頸。PT 售罄(waitlist)現象在 H100/H200 代際上普遍存在。
定價結構(定性架構)
PT 月度成本 = Model Units × 每 Unit 小時單價 × 承諾小時數 × (1 - 期限折扣)
其中:
- Model Units = f(模型大小, 精度, 並行配置)
- 每 Unit 小時單價 = 由廠商定價,受 GPU 成本 + 獲利率驅動
- 期限折扣:月度 < 年度 < 多年(年度合同折扣通常在 15-40% 區間 [行業估算])
重要提示:具體 Model Unit 定價因廠商、模型、區域、合同談判差異極大,此處不給出具體數字,避免誤導。建議查閱各廠商官方定價頁面獲取最新資料。
代表公司與資本對映
| 公司 | 角色 | PT 相關產品/服務 | 資本對映邏輯 |
|---|---|---|---|
| AWS (Amazon) | 雲端廠商 + PT 平台 | Bedrock Provisioned Throughput | AMZN — AI 推論營收的 ARR 質量提升 |
| Azure (Microsoft) | 雲端廠商 + PT 平台 | Azure OpenAI Provisioned Throughput Units (PTU) | MSFT — 繫結 OpenAI 模型的 PT 是獨佔性壁壘 |
| Google Cloud | 雲端廠商 + PT 平台 | Vertex AI 預留吞吐選項 | GOOG — TPU 自研優勢轉化為 PT 成本優勢 |
| NVIDIA | 上游算力供給 | GPU 是 PT 的物理基礎,NIM 微服務最佳化推論吞吐 | NVDA — PT 需求直接拉動高階 GPU 需求 |
| CoreWeave | 專業 GPU 雲端 | GPU 基礎設施即服務,PT 模式的底層供應商 | 已 IPO (2025) — GPU 雲端需求外溢的直接受益者 |
| Lambda / Together AI 等 | 推論服務商 | 推論 API + PT 選項 | 一級市場 — AI 推論中間層的新興玩家 |
| vLLM / SGLang (開源) | 推論引擎 | 開源推論引擎提升 PT 效率 | 非直接可投,但影響所有 PT 服務商的單位經濟 |
| Alibaba Cloud / Huawei Cloud | 國內雲端廠商 | 百鍊/ModelArts 平台的 PT 產品 | BABA / 未上市 — 國內 AI 推論基礎設施 |
投資邏輯
核心投資主題
1. PT 模式 = AI 推論營收的”SaaS 化”
- On-demand token 計費類似”按使用量付費”的低質量營收,波動大、可預測性差。
- PT 模式下客戶簽訂月度/年度合同,營收更穩定、可預測,ARR 質量提升直接改善雲端廠商的估值倍數。
- 類比:傳統軟體從 license 到 SaaS 轉型的估值重構。
2. PT 容量 = GPU 稀缺性的定價權體現
- 誰控制了更多 GPU 物理資源,誰就能賣出更多 PT Unit,形成**“PT 容量即市場份額”**的格局。
- 雲端廠商提前囤積 GPU 的戰略決策(如 2023-2024 年的大規模採購)通過 PT 銷售變現為未來營收流。
3. 推論引擎效率 = PT 的隱性獲利率槓桿
- vLLM、TensorRT-LLM 等推論引擎每最佳化 10% 的吞吐效率,雲端廠商在同等 GPU 投入下可多賣出 10% 的 PT,或同等 PT 量下降低 10% 的 GPU 成本。
- 這意味著推論引擎層的技術進步是 PT 毛利率提升的隱性驅動力。
風險因素
| 風險 | 說明 |
|---|---|
| GPU 供應過剩 | 如果 AI 加速器供應大幅改善,PT 溢價可能收窄,on-demand 模式的確定性改善可能侵蝕 PT 的賣點 |
| 模型快速迭代 | 客戶鎖定了某模型版本的 PT,但新模型釋出後舊 PT 變成沉沒成本,可能導致客戶縮短 PT 合同期限 |
| 開源模型衝擊 | 越來越多企業自部署開源模型,繞過雲端 PT 模式,直接自建推論叢集 |
| 監管與資料主權 | 部分行業/地區可能要求推論必須在本地進行,削弱雲端 PT 模式 |
常見誤讀糾偏
❌ 誤讀 1:Provisioned Throughput = Reserved Instances
糾正:Reserved Instances(RIs)是整機虛擬機器的長期預留折扣,粒度是”一臺 VM”,與具體執行什麼工作負載無關。Provisioned Throughput 是模型級推論吞吐的預留,粒度是”一個模型在一定吞吐水平上的專用推論資源”。兩者的粒度、計費邏輯、技術實現完全不同。PT 可以理解為”RI 思想在 AI 推論服務層的精細化落地”,但不能等同。
❌ 誤讀 2:買 Provisioned Throughput 一定比 On-demand 便宜
糾正:不一定。PT 的價效比取決於實際利用率。如果客戶買了 1000 tokens/s 的 PT 但平均只用了 300 tokens/s,單位實際使用的成本可能遠高於 on-demand。PT 的經濟性成立的前提是利用率足夠高(通常在 70%+ 以上才開始體現出明確的成本優勢,具體閾值因定價而異)。PT 買的主要是確定性,而非單純的價格折扣。
❌ 誤讀 3:Provisioned Throughput 只適用於大型模型推論
糾正:PT 概念起源於雲端儲存(Provisioned IOPS)和網路頻寬領域,早於 AI 推論應用多年。在 AI 產業鏈中,PT 模式同樣適用於:
- 嵌入模型推論(向量生成吞吐)
- 語音/TTS 推論
- 影像生成推論
- 甚至訓練資料預處理管道的計算吞吐 只是 LLM 推論因其高價值、高成本、強 SLA 需求,成為 PT 模式最顯眼的載體。
❌ 誤讀 4:PT 單位(Model Unit)在不同模型間可以等價換算
糾正:不可以直接換算。一個 Model Unit 對於 7B 模型和 70B 模型的物理 GPU 需求、吞吐能力完全不同。不同平台對 Unit 的定義也可能不同。跨模型比較 PT 價效比時,需要換算到相同吞吐(tokens/s)下的實際單價,而非直接比較 Unit 價格。
學習路徑
入門(0-2 小時)
- 閱讀各主流雲端廠商的 Provisioned Throughput 產品文件概述頁(不求深入,理解產品形態)。
- 對比自己使用 On-demand API(如直接呼叫 OpenAI API 按 token 計費)與 PT 模式的區別,建立直覺。
進階(2-10 小時)
- 深入閱讀 AWS Bedrock / Azure OpenAI 的 PT 定價與配置文件,理解 Model Units 的實際含義。
- 學習推論引擎基礎(vLLM 連續批處理、PagedAttention 等),理解為什麼推論引擎效率直接影響 PT 單位經濟。
- 閱讀至少一份雲端廠商財報中關於”AI 推論營收增長”的管理層討論,理解 PT 模式在財報中的體現。
專家(10+ 小時)
- 研究 GPU 叢集排程系統(如 Kubernetes + GPU Operator + MIG 配置),理解 PT 的底層資源隔離實現。
- 對比自建推論叢集 vs. 購買雲端 PT 的 TCO 模型,建立量化決策架構。
- 追蹤推論引擎開源社群(vLLM、SGLang、TensorRT-LLM 的 GitHub),理解吞吐最佳化的技術前沿如何影響 PT 定價能力。
一句話總結
Provisioned Throughput 是 AI 推論從”按量消費”走向”按需預定”的商業模式躍遷,其本質是用確定性溢價交換可預測的 SLA 和成本,底層由 GPU 資源隔離、推論引擎效率和雲端排程系統共同支撐,是理解 AI 基礎設施商業化演進的關鍵概念之一。
延伸閱讀與來源
| 來源型別 | 推薦內容 | 說明 |
|---|---|---|
| 官方文件 | AWS Bedrock Provisioned Throughput 文件 | 理解具體產品形態和配置方式 |
| 官方文件 | Azure OpenAI Provisioned Throughput Units 文件 | PTU 概念的官方定義和使用指南 |
| 財報/投資者材料 | 各雲端廠商季度財報中 “AI revenue” / “AI infrastructure” 相關章節 | 理解 PT 模式在商業層面的實際影響 |
| 技術論文 | vLLM: Efficient Memory Management for Large Language Model Serving (Kwon et al., 2023) | 理解推論引擎最佳化如何影響 PT 單位經濟 |
| 技術論文 | Orca: A Distributed Serving System for Transformer-Based Generative Models (Yu et al., 2022) | Continuous batching 的技術基礎 |
| 行業報告 | 各券商/研究機構 AI Infrastructure 報告 | 定量市場資料和預測 |
| 開源社群 | vLLM GitHub / SGLang GitHub / TensorRT-LLM 文件 | 推論引擎技術前沿 |
資料口徑宣告:本文中未標註具體來源的市場資料和定價資訊為定性描述或行業估算,具體數字請以各廠商官方揭露為準。標註 [未充分揭露] 的部分表示公開資訊不足以給出精確資料。