度量大模型推理效能——解析 2026 年的 Token 生成效率
在生成式 AI 部署中，你透過一系列關鍵指標來衡量大模型推理效能。Time to first token（TTFT，首 Token 延遲）用於追蹤提示處理時延；time per output token（TPOT，單一 Token 生成時間）和 inter-token latency（Token 間延遲）用於衡量輸出生成速度；tokens per second（每秒 Token 數）反映系統吞吐量，而 Goodput 則統計在嚴格服務目標下成功完成的請求數。
在 2026 年的生產環境中，例如部署在日本專用伺服器叢集上的大規模系統，你透過硬體使用率對營運成本的壓縮程度來定義 Token 生成效率。一條清晰的計算邊界將大語言模型的執行劃分為兩個階段：預填充（prefill）階段平行處理輸入 Token，形成以運算為主的瓶頸；解碼（decode）階段依序產生 Token，帶來以記憶體頻寬為主的限制。工程師運用這些效能指標，在大模型推理優化過程中定位系統極限。
關鍵重點總覽
- 大模型處理包含兩個階段：預填充階段快速處理提示詞，解碼階段則相對緩慢地生成文字。
- Goodput 透過只統計符合延遲目標的輸出 Token，來衡量系統真正的成功率。
- 連續批次處理可以消除記憶體浪費，將系統速度提升至原來的大約 3 倍。
- 推測解碼運用小模型加速詞元生成，同時不犧牲輸出品質。
- 現代顯示晶片可以降低營運成本，並高效執行大語言模型。
大模型 Token 生成機制：預填充 vs 解碼
你需要理解大語言模型在處理使用者請求時的兩個不同計算步驟：預填充階段負責處理初始提示詞，解碼階段負責生成回應文字。每個階段在大模型執行期間都會帶來獨特的運行需求。
預填充階段與運算瓶頸
在預填充階段，模型會同時攝取全部輸入 Token。你透過量測這一階段來確定部署中的首 Token 延遲（TTFT）。當大模型收到一個提示詞時，加速器會平行計算所有提示 Token 配對之間的注意力分數。例如，對於 4096 個 Token 的輸入提示，大約會產生 1680 萬次注意力分數計算。
| 運行指標 | 預填充階段 | 解碼階段 |
|---|---|---|
| 主要執行模式 | 平行批次處理 | 序列 Token 生成 |
| 算術強度 | 200-400 ops/byte | 60-80 ops/byte |
| GPU 使用率 | 90-95% | 20-40% |
| 硬體限制 | Tensor Core（運算） | 記憶體匯流排（頻寬） |
這種平行執行在硬體上實現了高度的資料重複使用。例如，在 70B FP16 模型上處理 1024 Token 的預填充時，其算術強度約為 1020 FLOP/byte，遠高於 NVIDIA H100 SXM GPU 的 295 FLOP/byte「山脊點」（ridge point）。高算術強度會將 Tensor Core 使用率推高至 90–95%，使得運算吞吐成為主要瓶頸。
解碼階段與記憶體頻寬限制
解碼階段依序逐一生成輸出 Token。每個生成的 Token 都需要對整個網路執行一次獨立的前向運算，導致在多步輸出中形成較長的 Token 生成時間。例如，對於 1024 個輸出 Token，你的系統必須執行 1024 個連續步驟。
在每一次解碼步驟中，硬體都需要從顯示記憶體中讀取完整的模型權重以及已快取的 KV（鍵值）向量。以批次大小為 1 的 70B FP16 模型為例，每生成一個 Token 大約需要讀取 140 GB 的權重資料。這種持續的資料串流會將算術強度拉低至 60–80 ops/byte，同時讓 GPU 使用率降至 20–40%。
記憶體頻寬會成為系統限制因素，因為 GPU 大部分時脈週期都在等待權重傳輸。透過放大批次大小，可以將這些權重讀取開銷攤提到多個請求上，從而提升總吞吐量。妥善優化記憶體頻寬可以穩定效能，並在生產工作負載下整體提升 Token 生成效率。有效管理這些硬體限制，可以在高併發推理任務中加速大模型推理流程，同時降低整體硬體營運支出。
延遲與回應性的關鍵指標
在生產環境中，你透過追蹤各執行階段的關鍵指標來評估使用者體驗。服務系統採用統一公式計算端到端回應時間：Latency = TTFT + (TPOT * 輸出 Token 數)。此公式將初始提示處理時間與累積 Token 生成時間相加，精準衡量整體系統回應性。
TTFT、TPOT 與 Token 間延遲
模型參數規模與部署硬體會直接決定服務速度。以 LLaMA-2 模型為例，在引擎版本 0.6.1、4 張 NVIDIA A100 GPU、25 個併發使用者的條件下，基準測試凸顯了這些關鍵運行權衡：
| 模型規模 | TTFT p50（秒） | TTFT p95（秒） | TTFT p99（秒） | TPOT p50（秒） | TPOT p95（秒） | TPOT p99（秒） |
|---|---|---|---|---|---|---|
| 7B 模型 | 0.24 | 0.89 | 1.42 | 0.019 | 0.037 | 0.056 |
| 13B 模型 | 0.31 | 1.12 | 1.78 | 0.033 | 0.067 | 0.096 |
| 70B 模型 | 0.87 | 2.34 | 3.67 | 0.122 | 0.231 | 0.343 |
在較低併發、以 NVIDIA H100 GPU 為基礎的情境下，較小的模型變體（如 Llama 3.1 8B）可實現小於 80 ms 的首 Token 延遲，以及 11–21 ms 的 Token 間延遲。模型架構同樣會影響推理執行時的 Token 延遲。Mixture-of-Experts（專家混合）架構每層只啟用部分參數，相較稠密網路可將前饋網路通訊開銷降低約 50%；而較淺的網路深度則能減少序列生成過程中的 Token 間延遲，進而提升整體大模型效能。
尾部延遲與分位數分佈
企業環境會精細監控 Token 使用情況，以在持續擴大的上下文視窗中維持效率。系統提示在數百萬次請求中重複，會產生龐大的指令開銷；動態請求批次處理可以將這類指令開銷最多降低 96.5%，避免嚴重的運算與記憶體浪費。
現代連續批次引擎會優先排程提示預填充，而非正在進行的解碼步驟。這種排程策略會帶來特定的運行瓶頸：
- 插入預填充任務時，會暫時中斷現行的解碼迭代。
- 在尖峰負載下，這類執行停頓會讓輸出 Token 生成延遲數秒。
- 排程延遲會導致 P99 Token 間延遲指標出現嚴重尾部延遲尖峰。
工程師必須以完整的統計分佈來分析效能指標，而非只依賴平均值。平均值會掩蓋資源爭用下的延遲尖峰。透過追蹤高分位數，可以看清佇列瓶頸在高負載時如何影響真實終端使用者。將整體 tokens per second 吞吐量與嚴格的總延遲上限加以平衡，有助於維持服務品質。你需要透過調整引擎參數來穩定大模型推理流程中的排隊延遲；對效能指標進行嚴密監控，可在請求量成長時確保高回應性。
度量大模型推理效能與吞吐量
你透過比較標準系統吞吐量與實際生成速度來評估服務能力。傳統 API 工具在客戶端側以每秒請求數（RPS）和每秒 Token 數（TPS）回報吞吐量。客戶端工具 GenAI-Perf 透過向相容 OpenAI 的服務端點發送工作負載流量，在線上壓力測試中追蹤這些效能指標。
每秒請求數與併發擴展
你必須同時分析每秒請求數與每秒 Token 數，才能充分理解整體批次處理效率。標準 API 端點透過已完成的客戶端請求數來追蹤一般服務能力，而聊天服務則透過輸出 Token 的每秒生成速度來監控即時效能。
- 客戶端側的 Token 生成吞吐反映使用者在串流會話中的主觀傳輸速度。
- 伺服端情境會在固定延遲目標下評估 TTFT 與 TPOT，例如 450 ms 的首 Token 延遲與 40 ms 的單 Token 生成時間。
- 離線情境則在完整資料集運行期間，聚合每秒生成的總輸出 Token 數。
針對批次最佳化的基準測試往往透過固定長度提示、在預熱完成的 GPU 上執行，以掩蓋實際運行中的停頓。混合提示長度在真實環境中會導致 GPU 使用率下降與動態排隊延遲。冷快取未命中也會增加互動使用者的總延遲。你應結合請求量與實際輸出 Token 度量，來最佳化部署硬體的資源配置。
Goodput 與 SLO 達成率
原始吞吐數據並不能保證使用者在企業使用情境中真正滿意。你透過追蹤生產叢集中的 Goodput 來度量有效服務成功率。Goodput 統計的是在單位時間內，完全在服務等級目標（SLO）內完成的成功請求 Token 數。
| 指標 | 定義 | 量測方法 |
|---|---|---|
| 服務等級目標達成率 | 在所有 Token 交付期限內完成的請求占比 | 只統計符合目標時間條件的完整請求 |
| Goodput | 符合服務等級目標的 Token 吞吐 | 以成功輸出的 Token 數除以總服務時間 |
| 平滑 Goodput | 連續化的服務效益計算 | 透過懲罰延遲 Token，而非直接捨棄逾時請求來計算 |
量測 Goodput 有助於將真正的營運交付速度與被浪費的運算步驟區分開來。高負載會增加排隊延遲，進而削弱互動效能。現代推理工具透過扣除基於使用者體驗校準的延遲懲罰來計算平滑 Goodput，此一連續指標有助於在真實流量高峰下評估大語言模型表現。你可以透過調整執行批次策略，在確保所有節點符合嚴格延遲門檻的前提下，維持高水準的大模型效能。對這些關鍵指標的標準化度量，有助於建構可擴展、具成本效益的大模型推理流程；追蹤 Goodput 能確保推理平台在不浪費硬體運算資源的情況下，持續提供穩定回應。
最佳化大模型推理中的系統權衡
最佳化大模型推理需要在處理速度與硬體記憶體使用之間取得平衡。傳統靜態批次處理會導致嚴重的伺服器延遲，因為短輸出必須等待長輸出完成。現代服務框架透過連續批次處理與進階記憶體管理來解決此一問題。
連續批次處理與記憶體管理
連續批次處理在迭代層級運作，以有效處理動態工作負載。系統排程器會在每個迭代步驟後檢查目前活動請求佇列。
- 記憶體引擎將序列快取資料切分為邏輯記憶體區塊。
- 執行階段將這些邏輯區塊對應到實體顯示記憶體區塊。
- 區塊對照表追蹤分散於實體記憶體中的所有邏輯映射。
- 服務引擎會隨著序列產生 Token 動態配置新的記憶體區塊。
- 請求結束後，系統會立即釋放對應的序列記憶體區塊。
- 引擎會將等待中的請求插入空閒的批次槽位，而不拖慢正在執行的序列。
這種動態方式消除了預先配置記憶體的浪費。PagedAttention 在生產流量下可將記憶體浪費壓低至約 4%。
| 工作負載類型 | 固定批次（請求/分鐘） | 連續批次（請求/分鐘） | 吞吐提升 |
|---|---|---|---|
| 混合回應長度（50–800 Token） | 25 | 85 | 3.4x |
| 互動式聊天（輪次可變） | 35 | 110 | 3.1x |
| 穩定短回應（<100 Token） | 60 | 95 | 1.6x |
| 長文本生成（平均 >500 Token） | 12 | 28 | 2.3x |
在多種回應長度下，你都能獲得顯著的吞吐提升。
- 連續批次處理會在既有請求釋放顯示記憶體後，立即接納排隊中的請求。
- 在序列生成步驟中，GPU 批次始終維持高填充度。
- 短序列會提前結束，而其餘序列則在不增加額外延遲的情況下持續生成。
更高的併發會讓 Token 生成步驟變慢，因此你必須將連續批次處理與模型最佳化結合，才能在高使用者量下維持系統效率。
推測解碼與解耦式服務
推測解碼透過在主模型旁邊執行一個較小的草稿模型來加速推理。草稿模型可以快速生成候選 Token，而大型目標模型則以一次平行前向運算驗證這些候選 Token。
| 加速效果 | 條件 |
|---|---|
| 最高 111% 吞吐提升 | 為 LLaMa-65B 設計的新草稿模型，相較既有草稿模型，在維持準確率的前提下提升吞吐。 |
| 超過 60% 吞吐提升 | 在參數總量不變的前提下，以更深且更窄的新草稿模型取代既有模型。 |
| 97%–111% 吞吐提升 | 在溫度取樣對照實驗中，NoFT-Wide-796M 草稿模型相較某已微調模型的表現。 |
這種執行方式在完全維持目標輸出品質的前提下，大幅降低生成延遲。你可以在無需重新訓練大模型的情況下，獲得更快的單一 Token 生成速度。
多節點部署會將運算密集的預填充作業與記憶體密集的解碼步驟拆分到不同的 GPU 叢集上。
| 結論 | 發現 |
|---|---|
| 延遲改善 | PPD（預填充/解碼解耦服務變體）在維持 TPOT 競爭力的同時，將第 2 輪及之後的 TTFT 降低約 68%。 |
| 吞吐與負載行為 | PPD 在高負載情境下可緩解 KV 傳輸壅塞。 |
| 架構原理 | 將預填充與解碼實體拆分到不同 GPU 資源池，可以消除互相干擾，使 P/D 資源能獨立擴縮並支援硬體多樣性。 |
在異質部署中使用 A100 系統，可以至少將單一 Token 延遲降低 2 ms；而在 25 Gbps 乙太網路下，跨節點資料傳輸每個 Token 的額外開銷最多約為 0.21 ms。透過解耦節點，可以在分散式叢集中最佳化大模型推理流程；針對性的硬體最佳化能在生產規模下穩定回應延遲。
2026 年生產基準與決策架構
你必須設定清晰的基準目標，才能在真實生產環境中評估系統效率。生成式 AI 基礎設施需要對延遲目標與運算上限進行嚴格監控，不同使用情境在實際部署中對應不同效能目標。
依工作負載評估 Token 生成效率
互動式應用需要快速的首回應來維持使用者黏著度。GuideLLM 為企業級聊天部署提出了具體服務目標：
- 首 Token 延遲目標須控制在 200 ms 以內；
- 此回應目標需在 99% 的總請求中達成。
你透過在延遲目標與系統硬體成本之間權衡，來衡量 Token 生成效率。即時聊天應用更重視低首延遲，而非最大批次大小；長上下文摘要任務則更重視輸出吞吐，而對首回應速度要求較低。
工程師會分析效能指標，以評估高負載下整體佇列健康度。高使用者流量會在服務節點間增加排隊延遲。你可以透過讓執行階段組態貼合實際工作負載，來保護大模型推理流程；有效的模型最佳化可以在不觸發記憶體溢位的前提下穩定處理速度。
成本效率與硬體選型策略
硬體選型直接決定整體資本支出與營運成本。對於小型團隊而言，在本地硬體上部署大語言模型，可以更好地掌握記憶體資源。例如，一台搭載 M4 Ultra 的 Mac Studio 在 Q8 量化條件下執行 Llama 3 70B 時，可達到約 15–25 Token/秒的速度，而因存在卸載開銷的 RTX 5090 則只有約 3–5 Token/秒。資料中心部署則需要專用加速硬體來承載企業級需求。
| 硬體平台 | 工作負載或基準情境 | 營運 CPM | 關鍵效能指標 |
|---|---|---|---|
| NVIDIA B200 | 企業級服務 | 約 $0.02 / 百萬 Token | 約 60,000 Token/秒 / GPU |
| H100 SXM | Llama 4 Scout 17B 於 vLLM 上 | $0.19 / 百萬 Token | 4,200 Token/秒 吞吐量 |
| H100 SXM | 70B FP8，結合最佳批次設定 | $0.32–$0.54 / 百萬 Token | 1,500–2,500 Token/秒 吞吐量 |
| MI300X | Mixtral 8x7B，批次大小為 1 | $22.22 / 百萬 Token | 買斷與租用的損益兩平點約為 9,045 小時 |
選擇現代資料中心晶片可以大幅降低 Token 成本。Blackwell 架構相較於 Hopper 晶片，Token 成本最高可降低達 10 倍。
你可以透過將硬體平台與實際批次大小分佈對齊來最佳化營運成本。MI300X GPU 在批次大小大於 256 的情境下提供更低的 Token 成本；H100 GPU 則在批次大小 2–128 的中等批次區間具備更佳的單位 Token 成本。最佳化大模型推理，需要將硬體記憶體頻寬與預期批次大小精準匹配；良好的推理架構設計不僅能提供強勁的大模型效能，也能控制硬體支出。透過精準的最佳化，你可以在高生產流量下維持企業部署的穩定性，同時提升整體大模型容量而不超出預算。
在推理過程中，你需要透過管理兩個處理階段來平衡大模型效能：以運算為主的預填充階段需要強大的平行運算能力，而以記憶體為主的解碼階段則仰賴高顯示記憶體頻寬。將這兩個計算階段適度隔離，可以提升整個叢集的 Token 生成效率。
在大模型推理中，唯有將 Goodput 與服務等級目標（SLO）置於原始吞吐量之上，你才能獲得真正的系統價值。單純最大化輸出 Token 數，並不代表使用者滿意度隨之提升。
你可以依據目標應用需求選擇最佳化路徑：
- 對於互動式聊天工作負載，可選擇推測解碼以降低個別回應延遲。
- 對於高併發企業級大模型推理應用，可部署解耦架構，將運算密集的預填充與受記憶體限制的解碼負載拆分至不同 GPU 叢集。
常見問答（FAQ）
如何計算推理中的端到端總延遲？
你可以將首 Token 延遲（TTFT）與單一 Token 時間（TPOT）乘上輸出 Token 數後相加，以計算總延遲。此公式有助於衡量互動式應用中的整體大模型回應性。
預填充與解碼階段在計算上的最大差異是什麼？
預填充階段會同時處理所有輸入 Token，強烈仰賴 GPU 運算能力；解碼階段則依序生成輸出 Token，主要受限於記憶體頻寬。
為什麼企業團隊應優先關注 Goodput，而不是原始吞吐量？
原始吞吐量只統計生成的 Token 數，並不區分是否逾時；Goodput 則只統計符合服務等級目標的成功 Token。因此，監控 Goodput 能在高流量下幫助你維持服務品質。
連續批次處理如何提升生成效率？
連續批次處理在每個迭代步驟上管理請求佇列。此技術藉由 PagedAttention 將記憶體浪費降低到約 4%，因此你可以用它來最佳化大語言模型的整體吞吐量。
推測解碼與解耦式服務如何降低延遲？
推測解碼透過小型草稿模型加速輸出生成；解耦式服務則將預填充與解碼拆分至不同 GPU 叢集。你可以依照目標大模型效能指標，在尖峰需求情境下選擇這些最佳化路徑，以穩定延遲表現。
