TTFT
TTFT 越低越好
量測 streaming 使用者等待第一份輸出的時間，主要反映運算密集的 prefill。
1
先備知識
在調校模型伺服器之前，先界定應用、證明模型品質、選擇服務模式，並決定哪些延遲與吞吐量量測能代表成功。
9 分鐘閱讀
印刷頁: 23–38
一口氣讀懂
最佳化是在可行方案中尋找最合適的平衡，不是只把某個數字推到最大。先釐清應用所需模型、輸入與輸出介面、端到端延遲預算、單位經濟、流量形態與合規界線。這些限制會決定共享推論是否仍然合適、哪些模型值得評估，以及延遲或吞吐量何者應優先。對 streaming 語言模型輸出而言，time to first token（TTFT）描述輸出開始前的等待，tokens per second（TPS）則描述開始後的傳送速度。必須報告兩者的百分位數，區分每位使用者感受到的速度與全服務吞吐量，並比較純推論時間和客戶端真正經歷的時間。技術上更快的模型若無法符合產品品質、成本或可靠度契約，就不算改善。
應用類別先收斂為工作負載契約，再導向模型與評估以及服務模式；生產環境的使用者可見指標最後從結果回饋至原始契約。
- 應用類別互動方式與受眾決定使用者在意什麼，也決定流量形態。
- 工作負載契約明確列出模型、介面、延遲、經濟性、使用情形與合規限制。
- 模型與評估選擇能通過產品專屬品質測試，且受到工具良好支援的最小候選模型。
- 服務模式依流量、控制與編排需求，在共享或專用推論之間選擇。
- 使用者可見指標一起量測 streaming 速度、尾端延遲、總回應時間、吞吐量與品質。
- 應用類別工作負載契約: 加入限制
- 工作負載契約模型與評估: 定義通過標準
- 模型與評估服務模式: 設定部署需求
- 服務模式使用者可見指標: 產生證據
- 使用者可見指標工作負載契約: 修訂預算
為何重要
推論改善會交換延遲、吞吐量、品質與成本。沒有產品定義，團隊便無法判斷哪一種交換可以接受。高度 batch 化的部署也許能有效率地處理離線語料庫，放進聊天介面卻可能慢得無法使用；高價低延遲服務也許很適合商業工作流程，卻可能摧毀用量波動劇烈的消費產品毛利。限制能縮小搜尋空間，讓吸引人的 benchmark 數字變成可依使用者、流量與經濟條件評估的決策。
處理順序同樣重要。選擇一個能力足夠的小模型，對成本與延遲的影響可能遠超過之後的 inference engine 調校。產品專屬評估能避免工程師加速一個根本不夠好的模型，也提供品質 benchmark，用來檢查可能降低品質的最佳化。這些決策有證據支持後，團隊才應承擔專用推論及其更大的營運責任面。
限制之間也需要排序。品質先決定功能究竟能不能用；互動方式決定使用者看得見延遲的哪一部分；流量和經濟條件決定產品負擔得起多少容量；可用性與合規則決定服務可以在哪裡、以什麼方式執行。當兩個目標衝突時，這套階層能避免某個漂亮 benchmark 數字悄悄重新定義產品。它也讓最佳化提案可以被否證：團隊必須說明哪個限制預期改善、哪個限制可以變差、可接受幅度是多少，以及最後由哪一項評估或生產量測做決定。舉例來說，聊天產品也許願意以稍低總吞吐量換取更快的第一份輸出；離線文件處理則可能接受單件工作較慢，只要每小時完成量提高。這不是一套放諸四海皆準的優先表，而是要求每個產品明確寫出自己的排序。如此一來，效能工作就從無限搜尋轉為有界線、可重複、能判斷成功與失敗的工程實驗。
心智模型
- 產品形態最先決定方向。代理會把一次使用者動作放大成許多次推論呼叫；聊天會凸顯開頭的停頓；語音受對話往返延遲支配；媒體明顯交換速度和品質；搜尋同時包含離線語料準備與線上查詢；內容審核則常偏重經濟的高吞吐量。應用類別預示等待的代價，以及平行工作的價值。
- 工作負載契約應點名確切模型、請求格式、輸出行為、延遲預算、計費單位、並行形態、尖峰，以及地理或隱私限制。這些不是設計完成後才補上的文件，而是模型、部署與量測選擇的直接輸入。
- 品質是一道閘門，不是預設。一般 benchmark 可用來篩選候選模型，但產品中最困難的真實案例才決定模型能力是否足夠。同一套評估資料也會成為基線，用來檢查微調、蒸餾、quantization 或其他可能改變行為的處理。
- 服務模式是經濟與控制選擇。共享端點免除營運負擔，也適合需求仍不確定的早期階段。專用部署增加最低支出與工程責任，卻可能在流量、客製模型、嚴格效能、可用性或多模型編排形成明確商業需求時勝出。
- 量測讓迴路閉合。以推論指標隔離模型服務效能，以端到端指標代表產品體驗。檢視分布而不只看平均值，並把線上與離線工作負載分開切片，避免單一彙總數字掩蓋彼此衝突的目標。
評估是產品語言與服務語言之間的橋梁。產品負責人可以描述不可接受的失敗，以及最困難但必須成功的案例；評估集則把這些描述轉成可重複的證據。推論工程師因此能比較較小模型、微調變體，或可能影響品質的最佳化，而不必猜測行為改變是否重要。這座橋還必須和工作負載切片保持連結。模型也許在短請求上通過，遇到長上下文卻失敗；服務也許在平均流量下看似經濟，到了高並行尖峰卻超過延遲預算。若評估只測能力、效能測試只用合成輸入、成本估算又依另一套流量假設，三組數字就無法共同回答產品問題。因此契約、評估和服務量測應使用相符的情境、輸入分布與識別方式，讓每次比較都能追溯到同一個使用案例。
核心概念
- 線上工作每個請求背後都有正在等待的使用者，因此應強調延遲；離線工作可以接受單一請求較慢，換取單位時間完成更多工作。同一模型若在兩種模式都有足夠用量，應考慮分開部署，因為折衷設定可能讓兩邊都付出不必要成本。
- 消費市場的需求通常波動更大，也更敏感於毛利，因此偏向彈性與低邊際成本。企業軟體可能用量較穩定、毛利較佳，卻要求更高可用性與一致延遲。不論市場為何，資料主權、隱私和法規都可能排除原本很吸引人的基礎設施選項。
- 其他條件相同時，參數較少就代表推論較快且較便宜。因此，最佳候選者是能通過任務品質門檻，而且架構受到 inference engine 成熟支援的最小模型。若小模型失敗，大型前沿模型仍可能合理，但必須用證據證明確有必要，而不能視為預設。
- 公開能力 benchmark 適合發現候選者，卻可能已飽和，或因成為競爭目標而遭過度調校。高可信度評估要使用具代表性的產品資料、聚焦真正重要的最難任務，並以領域判斷檢查結果。效能工作開始前，它必須回答兩件事：這個模型是否有用，以及後續最佳化可以花掉多少品質預算。
- 微調以特定領域資料改變預訓練模型，小型微調模型有時能在狹窄任務上追平大型通用模型。蒸餾則教導較小的學生模型模仿大型教師模型的機率行為，既可能轉移有用能力，也可能繼承限制；原書指出，它在真實生產中的使用仍少於微調。
運作機制
- 先分類互動。記錄工作是線上或離線、streaming 或完整回傳、單一模型或多步驟，以及面向消費者或企業。在考慮區域與供應商之前，就要納入合規限制。
- 把期待轉成預算。具體寫出可接受的端到端等待、每次請求或每位使用者的經濟條件、可能並行量、每日形態、突發流量、可用性、輸入形式與輸出形式。分開標示不可妥協的限制和偏好，讓後續取捨有明確順序。
- 建立產品專屬評估集，只把廣泛 benchmark 用於縮小範圍。檢視真實案例、集中測試困難情境，並保存分數和具代表性的失敗，作為品質基線。
- 從小到大比較候選模型，直到找到通過者。檢查預定 inference engine 對架構的支援，因為廣泛採用且支援成熟的模型家族，能讓不同尺寸、變體和微調版本共享既有的效能成果。
- 當不確定性和低用量使按用量計費與最低工程投入更有吸引力時，繼續使用共享推論。只有當眼前的經濟性、專門化或編排需求足以證明容量承諾和營運責任合理時，才核准專用部署。
- 同時對推論路徑與客戶端路徑埋設量測。streaming 輸出要記錄第一個可見 token 和後續傳送節奏；非 streaming 工具呼叫則記錄總回應時間。依契約使用相同工作負載切片，並列呈現百分位數、吞吐量、品質和成本。
端到端延遲 = 排隊時間 + 網路時間 + 推論時間 + 應用程式周邊工作關鍵指標
感受 TPS
TPS 越高越好
量測第一個 token 之後每位使用者收到 token 的速度，主要反映頻寬密集的 decode。
inter-token latency（ITL）
ITL 越低越好
量測連續 token 之間的時間；十毫秒相當於每秒一百個 token。
全服務吞吐量
總 TPS
計算整個服務每秒產生的所有 token，不能和單一使用者感受到的速度混為一談。
尾端百分位數
P90、P95 與 P99
揭露右偏回應時間分布中，平均值或中位數可能遮蔽的慢速 outlier 請求。
總回應時間
從請求開始到有用結果完成
適合非 streaming 的代理工具呼叫，以及個別 token 對呼叫端沒有用途的其他輸出。
一個指標需要完整量測規約，不能只有名稱。記錄計時器從哪裡開始、在哪裡結束、輸出是否 streaming、提示與輸出長度、並行量、服務模式，以及報告的是哪個百分位數。對 TPS 而言，還要說明分子涵蓋單一回應或整個服務。延遲必須和同一工作負載的評估結果與成本並列，因為答案品質下降，或請求組成已經不同的快速執行，根本不能公平比較。最後，依請求把純推論追蹤和端到端追蹤對齊。若模型時間保持不變而客戶端時間上升，證據就會指向排隊、網路距離或應用工作，而不是再做一輪模型最佳化。規約也要固定負載產生方式與暖機狀態，避免把 cold start、突發排隊和穩態執行混成一個平均值。報告除了中心趨勢，也應保留 P90、P95 或 P99 等尾端結果，並標示樣本時間窗口。只有這樣，不同模型、部署或版本的數字才具有可比性，也才能把使用者抱怨對應回具體服務階段。
取捨
延遲與吞吐量
線上互動獎勵快速的個別回應；離線工作獎勵單位時間完成更多工作。同一模型若兩邊都有可觀用量，應設計不同部署，而不是迫使單一設定同時滿足方向相反的目標。
共享與專用
共享服務具備低營運負擔、按用量計費和無部署 cold start 等優點，但控制受限且依賴供應商。專用服務提供控制力與規模經濟機會，卻增加最低支出、容量風險和工程責任。
模型大小與任務品質
小模型比較容易服務，但必須通過產品評估才有用。微調可能在狹窄領域推進這條界線；若任務確實需要大型通用模型的能力，選擇較大模型仍然正確。
平均與尾端
改善平均值有利整體速度；降低高百分位數則能保護使用者，避免罕見但破壞信任的漫長等待。推論延遲通常右偏，因此服務需要同時觀察兩種視角。
推論時間與產品時間
GPU 上的時間適合評估模型效能工作；端到端時間適合評估使用者體驗。兩者之間的落差會把 attention 轉向排隊、網路或其他基礎設施問題。
工程檢查表
- 點名應用類別、互動模式、受眾，以及工作負載屬於線上、離線或兩者兼具。
- 記錄模型、介面、延遲、單位經濟、並行量、使用形態、可用性、隱私、資料主權與合規限制。
- 在效能最佳化之前，用具代表性且困難的產品案例建立任務專屬評估。
- 測試可能通過品質閘門，且工具支援成熟的最小模型家族。
- 從共享推論轉到專用推論前，記錄當下具體的經濟或控制理由。
- TPS 可能產生歧義時，明確標示它代表單一使用者感受速度或全服務吞吐量。
- 每個延遲結果都要報告百分位數與工作負載切片，不能只依賴平均值。
- 同時量測純推論與端到端時間，讓緩慢產品能追查到正確層次。
術語
原書索引
印刷頁 25–26
定義讓最佳化具有具體目標的產品限制。
印刷頁 26–27
比較共享與專用推論，並列出轉換服務模式的主要原因。
印刷頁 27–30
區分應用類別、工作時效、市場與合規需求。
印刷頁 31
把模型大小與架構支援視為一級推論決策。
印刷頁 31–32
說明產品專屬評估及其作為品質基線的功能。
印刷頁 32–35
對照領域微調與教師學生蒸餾。
印刷頁 35–36
定義 streaming token 指標，以及每位使用者 TPS 和總 TPS 的歧義。
印刷頁 36–37
說明右偏回應時間為何需要百分位數報告。
印刷頁 37–38
把 GPU 上的推論時間和完整使用者可見路徑分開。
- Product-specific optimization, model requirements, interfaces, budgets, and usage patterns
- 印刷頁: 25–26; PDF 頁: 27–28
- Shared inference, dedicated deployments, and the scale, specialization, and orchestration threshold
- 印刷頁: 26–27; PDF 頁: 28–29
- Application categories, online versus offline work, consumer versus business products, and compliance
- 印刷頁: 27–30; PDF 頁: 29–32
- Selecting the smallest capable model and preferring well-supported architectures
- 印刷頁: 31–31; PDF 頁: 33–33
- Product-specific model evaluation, baselines, and limits of general benchmarks
- 印刷頁: 31–32; PDF 頁: 33–34
- Fine-tuning, distillation, domain specialization, and architecture support
- 印刷頁: 32–35; PDF 頁: 34–37
- Time to first token, tokens per second, inter-token latency, and total response time
- 印刷頁: 35–36; PDF 頁: 37–38
- Right-skewed latency, percentile reporting, and tail experience
- 印刷頁: 36–37; PDF 頁: 38–39
- Inference-only versus end-to-end measurement and bottleneck localization
- 印刷頁: 37–38; PDF 頁: 39–40