學習如何針對需要高吞吐量、低延遲及可靠效能的生產工作負載，優化模型服務端點。
優化策略可分為三類：
何時優化你的端點
當您遇到以下任一情境時，請考慮優化您的模型服務端點：
- 高查詢量：你的應用程式每秒向單一端點發送超過 5 萬筆查詢（QPS）
- 延遲需求：你的應用程式需要低於 100 毫秒的回應時間
- 擴展瓶頸：端點在流量高峰時出現排隊或回傳 HTTP 429 錯誤
- 成本優化：你希望在維持績效目標的同時降低服務成本
- 生產準備：你正準備從開發工作轉到生產工作負載
基礎建設優化
基礎建設優化能改善網路路由、擴展行為及運算能力。
路線優化
路由優化 是高吞吐量工作負載中基礎設施最顯著的改善。 當你在端點啟用路由優化時，Databricks 模型服務會改善推論請求的網路路徑，從而促進客戶端與模型間更快速、更直接的通訊。
效能提升：
| 特徵 / 功能 | 標準終點限制 | 路由優化端點限制 |
|---|---|---|
| 每個工作區的每秒查詢率（QPS） | 200 | 50,000+（如需更高限額，請聯絡 Databricks） |
| 每個工作空間的用戶端並行性 | 192-1024（依地區而異） | 無明確限制（受限於已配置的並行數） |
| 端點為每個服務實體提供預設並行數 | 1,024 | 1,024（如需更高限額，請聯絡Databricks） |
何時使用路線優化：
- 需要超過 200 QPS 的工作負載
- 嚴格延遲需求的應用程式（延遲低於 50 毫秒）
- 服務多個同時使用者的生產部署
這很重要
路由優化僅適用於自訂模型服務端點。 基礎模型 API 及外部模型不支援路線優化。 驗證需要 OAuth 代幣;不支援個人存取權杖。
請參閱「 服務端點的路由優化 」以獲得設定說明，查詢細節請參見「 查詢路由優化的服務端點 」。
佈建的預置平行處理
配置並行性控制終端能同時處理多少請求。 根據您預期的 QPS 和延遲需求來配置預配置併發性。
配置指引：
- 最小並發數：設定為足夠高，以便在不造成排隊的情況下處理基線流量負載
- 最大並行：設定足夠高以容納流量激增，同時控制成本
- 自動擴展：啟用自動擴展功能，根據需求動態調整容量
計算所需的並行性：
Required Concurrency = Target QPS × Average Latency (seconds)
舉例來說，如果你的目標是 100 QPS，平均延遲 200ms：
Required Concurrency = 100 × 0.2 = 20
利用 負載測試 來測量實際延遲並決定最佳的並行設定。
實例類型
根據你模型的計算需求選擇實例類型：
| 實例類型 | 適用對象 | 權衡取捨 |
|---|---|---|
| CPU（小型、中型、大型） | 輕量級模型，簡單推論邏輯 | 成本較低，但對於運算密集型模型來說速度較慢 |
| GPU（小型、中型、大型） | 大型模型、複雜計算、影像/影片處理 | 成本較高，深度學習效能最佳 |
小提示
從 CPU 實例開始進行開發和測試。 只有當你發現推理延遲高或模型需要專門運算（例如深度學習操作）時，才建議切換到 GPU 實例。
模型優化
模型優化提升推論速度與資源效率。
模型大小和複雜度
模型規模與複雜度：較小且較簡單的模型通常能帶來更快的推論時間與較高的 QPS。 如果你的模型很大，可以考慮像是模型量子化或修剪等技術。
批次處理
如果你的應用程式能在一次呼叫中發送多個請求，請在用戶端啟用批次處理。 這能大幅降低每次預測的負擔。
前處理與後處理優化
將複雜的前處理與後處理從服務端點卸下，以減輕推論基礎設施的負擔。
用戶端優化
用戶端優化改善應用程式與服務端點的互動方式。
連線池化
連線池會重複使用現有連線，而不是為每個請求建立新連線，大幅降低開銷。
- 使用 Databricks SDK，自動化實作連線池管理的最佳實務
- 如果使用自訂客戶端，需自行實作連線池。
錯誤處理與重試策略
實施穩健的錯誤處理機制，以優雅地處理臨時故障，尤其是在自動擴展事件或網路中斷時。
有效載荷大小優化
盡量減少請求與回應的有效載荷大小，以縮短網路傳輸時間並提升吞吐量。
衡量並提升績效
效能監控
使用 Mosaic AI 模型服務提供的工具監控端點效能：
| 計量 | 它衡量的是什麼 | 標的 | 超出時採取的措施 |
|---|---|---|---|
| 延遲（P50、P90、P99） | 請求回應時間 | 依應用程式而定（通常 <100-500毫秒） | 檢查是否有排隊，優化模型或客戶端 |
| 吞吐量（QPS） | 每秒完成的請求數 | 依工作負載而定 | 啟用路由優化，增加配置並行性 |
| 錯誤率 | 申請失敗的百分比 | <1% | 檢查服務紀錄，檢查容量問題 |
| 佇列深度 | 等待處理的請求 | 0（無排隊） | 增加配置並行性或啟用自動擴展 |
| CPU/記憶體使用量 | 資源使用率 | <80% | 擴大實例類型或增加並行性 |
請參閱 「監控模型品質與端點健康 」以獲得詳細監控指引，並「 追蹤並匯出服務端點健康指標至Prometheus與Datadog ，以匯出指標至可觀察工具」。
負載測試
負載測試在真實交通狀況下衡量端點效能，並協助你：
- 評估最佳的預配置並行性設定
- 識別效能瓶頸
- 驗證延遲與吞吐量需求
- 了解用戶端並行與伺服器並行之間的關係
請參閱 負載測試以服務端點。
排解常見效能問題
Queuing
模型服務支援自動縮放，根據流量模式調整容量。 然而，突發流量激增可能導致排隊，因為自動擴展需要時間偵測負載增加並預留額外容量。 在此期間，要求可能暫時超過可用容量，導致排隊。
當請求速率或並行性超過端點目前的處理能力時，會發生排隊。 這通常發生在流量急劇激增、工作負載突發，或端點配置並行不足時。 模型服務端點允許暫時排隊以處理突發，但超過定義閾值後，端點會回傳 HTTP 429（請求過多）錯誤以保護系統穩定性。
排隊會增加延遲，因為排隊請求會等待處理。 為了減少排隊時間：
- 設定最低預配置併發度足夠高，以應對基線流量以及常見的流量突發。
- 啟用路由優化以提升容量上限
- 在客戶端應用程式中實作帶有指數退縮的重試邏輯
外部 API 瓶頸
模型在推論過程中常會呼叫外部 API，以進行資料豐富、特徵檢索或其他任務。 這些外部相依性可能成為效能瓶頸：
- 延遲：測量每次外部 API 呼叫的回應時間。 這些通話中的高延遲直接增加整體服務延遲並降低吞吐量。
- 吞吐量限制：外部 API 可能會施加速率限制或容量限制。 超過這些限制可能會導致降頻、錯誤及效能下降。
- 錯誤率：外部 API 頻繁錯誤可能觸發重試並增加服務端點的負載。
- 快取：對外部 API 頻繁存取的資料實施快取，以減少呼叫次數並改善回應時間。
監控這些因素，找出瓶頸，並針對高吞吐量工作負載實施針對性的優化。