最佳多供應商 LLM 服務：如何降低成本並提高正常運行時間？

對多供應商 LLM 服務而言，「更高的正常運行時間」意味著什麼
多供應商 LLM 服務的 SLO 設計
供應商健康監控標準
供應商服務降級的警示架構
多供應商 LLM 服務的事件劇本
備援政策治理
Novita AI 如何支援多供應商正常運行時間運作
上線前的運作準備清單
常見問題
推薦文章

最佳的多供應商 LLM 服務能夠在降低成本並提高正常運行時間的同時，將穩固的路由架構與明確的運作實務相結合：定義明確的 SLO、持續監控供應商健康狀態、經過測試的事件劇本，以及受治理的備援政策。路由架構決定了哪些模型可用，而運作實務則決定了路由就位後，服務是否能真正滿足正常運行時間的承諾。

本文將重點放在運作層面。至於路由架構本身 —— 包括備援政策、成本層級模型選擇、斷路器與重試預算 —— 請參閱最佳多供應商 LLM 平台：降低成本與停機時間。

對多供應商 LLM 服務而言，「更高的正常運行時間」意味著什麼

LLM 服務的正常運行時間並不等同於伺服器可用性。供應商的狀態頁面可能顯示為綠燈，但您的使用者卻經歷著更高的延遲、輸出品質下降，或是在代理工作流程中出現靜默的部分故障。

一個實用的多供應商 LLM 服務正常運行時間 SLO 應涵蓋：

成功完成率：在延遲預算內回傳有效、可用回應的 LLM 請求比例
第一個 token 的時間（P95）：互動式使用者感受到的延遲，而不僅僅是平均延遲
代理工作流程完成率：對於代理型工作負載，達到成功終止狀態的多步驟工作比例
每項成功任務的成本：一個效率訊號，當重試、備援或更長的輸出在不增加成功完成次數的情況下推高花費時，這個訊號會上升

即使伺服器可用性達到 99.9%，如果模型品質下降、速率限制耗盡或沙箱故障導致靜默錯誤，服務仍可能無法滿足使用者可見的正常運行時間 SLO。

多供應商 LLM 服務的 SLO 設計

按工作負載類別定義 SLO，而非按供應商

供應商的可靠性因模型、地區和服務層級而異。請在工作負載類別層級 —— 即使用者面向的操作 —— 定義您的 SLO 目標，而非在供應商層級。

工作負載類別	SLO 目標範例	錯誤預算（30 天）
互動式聊天（P95 延遲 ≤ 2 秒）	99.5% 成功完成率	3.6 小時
代理工作流程完成	99.0% 工作達到終止狀態	7.2 小時
批次提取 / 分類	99.9% 在 SLA 時間內完成	43 分鐘
串流生成（P95 TTFT ≤ 1 秒）	99.0% 請求滿足 TTFT 預算	7.2 小時

工作負載類別 SLO 讓您能準確分配錯誤預算。如果某個事件耗盡了互動式聊天的預算但未影響批次預算，您就知道該將可靠性工作重點放在哪裡。

將可用性 SLO 與品質 SLO 分開

一個多供應商系統可以維持高可用性（請求獲得回應），但同時品質卻下降（備援模型產生較弱的答案）。兩者都應追蹤：

可用性 SLO：在延遲預算內的非錯誤回應率
品質 SLO：符合最低品質門檻（人工標籤、自動評估、使用者不喜歡率）的回應比例

當事件期間啟動備援路由時，品質 SLO 燃燒率就是一個訊號，告訴您降級模式是否可以接受，或者系統是否應該進入佇列或暫停。

供應商健康監控標準

有效的多供應商監控不僅僅是查看供應商狀態頁面。從觀察到的流量中建立您自己的健康訊號。

訊號	衡量內容	警示門檻範例
按供應商 + 模型的錯誤率	每分鐘 4xx/5xx 回應數	在 5 分鐘視窗內 > 5%
按供應商 + 模型的 P95 延遲	第一個 token 的時間、總完成時間	連續 3 分鐘 > 2 倍基線
速率限制命中率	429 回應佔請求的比例	在 2 分鐘視窗內 > 2%
備援啟動率	路由到次要模型的請求	持續 5 分鐘 > 10%（可能表示主要服務降級）
代理工作流程失敗率	未達到終止狀態的多步驟工作	在 10 分鐘視窗內 > 1%
每項成功任務的成本	（輸入 token + 輸出 token）× 價格 / 成功完成次數	高於 7 天基線 20%
品質評分漂移	自動評估通過率或使用者負面回饋率	與 7 天基線相比相對下降 > 15%

對於使用 Novita AI LLM API 的團隊，與 OpenAI 相容的聊天補全端點會回傳標準的 HTTP 狀態碼和延遲標頭，可直接輸入到這些訊號中。記錄每個請求的模型 ID、供應商路徑和重試次數，以便您的監控是針對特定模型，而不僅僅是端點層級。

每個 LLM 請求日誌中應發出的內容

{
  "request_id": "req_abc123",
  "workload_class": "interactive_chat",
  "primary_model": "meta-llama/llama-3.1-70b-instruct",
  "routed_model": "meta-llama/llama-3.1-8b-instruct",
  "route_reason": "primary_rate_limited",
  "provider": "novita",
  "latency_ms": 1240,
  "ttft_ms": 380,
  "input_tokens": 512,
  "output_tokens": 148,
  "retry_count": 1,
  "status": "success",
  "quality_eval": "pass",
  "cost_usd": 0.00031
}

route_reason 是大多數團隊會遺漏的欄位。少了它，您將無法在儀表板中區分健康的備援（預期行為）與降級的備援（供應商事件）。

供應商服務降級的警示架構

警示應在兩個層級觸發：戰術層級（值班工程師立即採取行動）和策略層級（需要變更路由政策的趨勢）。

戰術警示（傳呼值班工程師）

生產工作負載類別的供應商錯誤率在 5 分鐘內超過 5%
互動式聊天的 P95 延遲連續 3 分鐘超過 2 倍基線
代理工作流程失敗率在 10 分鐘內超過 1%
品質 SLO 燃燒率在 1 小時內超過月度錯誤預算的 5%

策略警示（Slack 頻道，不傳呼）

備援啟動率持續 30 分鐘高於 10%（可能需要調整路由政策）
每項成功任務的成本在 2 小時內高於 7 天基線 20%
主要模型的速率限制命中率在 24 小時內呈上升趨勢（容量規劃訊號）
品質評分漂移警示：備份模型品質在 7 天視窗內下降

按工作負載類別路由警示

不要將每個警示都傳送到同一個頻道。按工作負載類別路由戰術警示，以便正確的團隊採取行動。內部 copilot 上的 429 突發事件，其優先級低於客戶面向的代理工作流程上出現的相同突發事件。

多供應商 LLM 服務的事件劇本

路由政策決定了自動處理的方式。事件劇本則指引值班工程師在自動行為不足或事件不明確時該如何應對。

劇本：主要供應商錯誤率升高

觸發條件：生產工作負載類別的主要模型錯誤率在 5 分鐘內 > 5%。

驗證：檢查供應商狀態頁面和您自己的錯誤日誌。區分短暫突發與持續降級。
評估影響：有多少工作負載類別受到影響？備援模型是否已啟動且品質 SLO 是否達標？
如果備援已啟動且品質 SLO 達標：監控恢復情況。設定 30 分鐘的審查檢查點。
如果備援已啟動但品質 SLO 正在燃燒：將高風險工作負載（法律、金融、安全敏感）移至佇列或人工保留。通知利害關係人。
如果沒有可用的備援：啟動降級模式（使用者可見的通知、將非緊急請求加入佇列）。升級給事件指揮官。
恢復：一旦主要錯誤率在 10 分鐘內回到 1% 以下，逐漸將流量切回。不要一次切換所有流量。
事件後：記錄事件持續時間、受影響的工作負載類別、品質 SLO 燃燒、成本影響，以及任何發現的備援政策缺口。

劇本：速率限制耗盡

觸發條件：主要模型的 429 速率在 2 分鐘內 > 2%。

檢查配額儀表板：這是持續的容量問題還是流量突發？
如果是突發：啟動退避和重試預算。將超額流量路由到符合資格的次要模型層級。
如果是持續性的：對較低優先級的工作負載實施請求佇列。考慮將可預測的高流量遷移到專用端點 —— Novita AI GPU Cloud 或專用 LLM 端點可以為已超出共享 API 速率限制的工作負載提供更可預測的容量。
不要無限期重試：強制執行重試預算。記錄每個 429 及其工作負載類別和模型，以便找出哪些呼叫模式受到最大影響。

劇本：代理工作流程失敗突發

觸發條件：代理工作流程失敗率在 10 分鐘內 > 1%。

區分失敗類型：失敗是在 LLM 呼叫（模型錯誤、速率限制、上下文溢出）還是在執行層（沙箱超時、工具呼叫輸出格式錯誤、檔案操作錯誤）？
對於 LLM 層的失敗：遵循上述主要供應商錯誤率劇本。
對於沙箱或執行失敗：檢查 Novita Agent Sandbox 日誌。識別問題是系統性的（不良的提示模板導致格式錯誤的工具呼叫）還是環境性的（沙箱容量、網路超時）。
隔離受影響的工作流程類型：如果瀏覽器自動化失敗，不應導致程式碼執行工作流程暫停，除非它們是相互依賴的。
恢復閘道：在恢復全部流量之前，透過受影響的工作流程運行一組代表性的黃金提示，並確認失敗率回到基線。

劇本：備援期間品質 SLO 降級

觸發條件：當備援模型啟動時，品質評分從 7 天基線下降 > 15%。

識別哪些工作負載類別受影響：品質降級通常因工作負載而異。備援模型可能能很好地處理簡單的分類，但在長篇推理上表現不佳。
應用工作負載類別特定的備援限制：將降級的備援限制在品質下降可接受的工作負載。將高風險任務加入佇列或暫停。
通知利害關係人 有關客戶面向的影響。
事件後：更新備援核准矩陣，以反映觀察到的備份模型品質限制。

備援政策治理

路由政策決定了哪些備援模型可用。治理則決定了哪些備援已獲核准用於每個工作負載類別 —— 以及何時根本不應進行自動備援。

備援核准矩陣

按工作負載類別維護一份文件化的備援核准矩陣：

工作負載類別	主要模型	已核准的備援	條件	禁止的備援
客戶聊天	模型 A（大型）	模型 B（中型）	在黃金測試集上通過品質評估	任何不在核准清單上的模型
內部 copilot	模型 A（大型）	模型 B（中型），模型 C（小型）	通過品質評估	無
法律 / 合規草稿	模型 A（大型）	僅佇列	無自動備援	任何較小的模型
批次分類	模型 C（小型）	模型 D（替代供應商）	通過品質評估	大型模型（成本控制）
瀏覽器代理	模型 A（大型）+ 沙箱	佇列	必須確認沙箱執行	不支援工具的純文字模型

每月審查此矩陣，並在每次備援行為出乎意料或不充分的事件之後進行審查。

誰擁有備援政策變更的權限？

備援政策變更需要工程團隊（系統能否支援此變更？）和產品或風險團隊（品質權衡是否可接受？）的簽核。一個自動路由系統在沒有人類簽核品質標準的情況下，就切換到更便宜的模型，會造成無聲的產品風險。

記錄每次變更：哪個模型、哪個工作負載類別、進行了什麼品質評估、誰核准的，以及哪些條件會觸發政策審查。

Novita AI 如何支援多供應商正常運行時間運作

Novita AI 作為一個 AI 與代理雲端 —— LLM API、Agent Sandbox 和 GPU Cloud —— 運作，團隊可以將其用於此處所述的運作實務。

LLM API 會回傳標準 HTTP 狀態碼、延遲標頭和每個請求的 token 計數，為您提供供應商健康監控和 SLO 追蹤的原始訊號。模型庫列出了目前的模型可用性，以便您能夠針對實際支援的模型建立路由政策。與 OpenAI 相容的聊天補全 API 意味著現有的可觀測性工具（請求日誌、延遲追蹤、錯誤率儀表板）無需自訂儀器即可運作。

Novita Agent Sandbox 為代理型工作流程增加了受管理的執行環境。在同一個工作流程日誌中同時觀察 LLM 呼叫結果和沙箱執行結果的能力，與代理工作流程失敗劇本直接相關：如果沒有來自兩個層級的日誌，就無法區分模型失敗與沙箱執行失敗。

Novita AI GPU Cloud 和專用端點為團隊提供了一條運作路徑，當共享 API 速率限制成為可靠性限制時可以使用。對於 429 是反覆出現的事件觸發條件的工作負載，遷移到專用容量可以從共享 API 運作模型中移除一類事件。

上線前的運作準備清單

在評估您的多供應商 LLM 服務是否已準備好進行運作時，請使用此清單：

SLO 定義

[ ] 為每個生產工作負載類別定義了 SLO 目標（可用性 + 品質）
[ ] 計算並記錄了錯誤預算
[ ] 為每個 SLO 配置了燃燒率警示

監控

[ ] 每個 LLM 請求記錄：模型、供應商、路由原因、延遲、token、重試次數、狀態、品質評估結果
[ ] 儀表板顯示錯誤率、P95 延遲、備援啟動率、每項成功任務的成本 —— 按工作負載類別分類
[ ] 供應商健康訊號來自觀察到的流量，而不僅僅是狀態頁面

警示

[ ] 為生產工作負載類別配置了戰術警示（傳呼）
[ ] 為成本漂移和備援率趨勢配置了策略警示（Slack）
[ ] 警示路由將工作負載類別對應到所屬團隊

事件劇本

[ ] 已撰寫並可存取的事件劇本：主要供應商錯誤突發、速率限制耗盡、代理工作流程失敗、品質 SLO 降級
[ ] 為每個劇本定義了恢復閘道（在恢復全部流量之前必須滿足什麼條件）
[ ] 記錄了事件後檢討流程

備援治理

[ ] 備援核准矩陣存在且為最新
[ ] 為高風險工作負載類別記錄了禁止的備援條件
[ ] 定義了政策變更簽核流程（工程 + 產品/風險）
[ ] 安排了每月審查

基礎設施應急方案

[ ] 為共享 API 速率限制是反覆出現的限制的工作負載，確定了專用端點或 GPU Cloud 路徑

常見問題

多供應商路由設計與多供應商運作之間有何區別？

路由設計決定了政策：哪些模型是主要的和備援的、何時重試，以及如何處理特定錯誤類型。運作則是持續驗證政策是否有效的實務：監控 SLO 燃燒、在政策無效時執行事件劇本，以及治理政策的變更。兩者都是服務可靠滿足正常運行時間承諾所必需的。

如何為多供應商 LLM 服務設定一個實際的正常運行時間 SLO？

首先，在一個代表性的流量視窗內衡量您當前的成功完成率和 P95 延遲。將您的 SLO 目標設定在您的路由政策在可用錯誤預算下能夠實際支援的水平。對於新服務，99.0%–99.5% 的成功完成率是一個合理的起點。在觀察了前幾個錯誤預算視窗後進行調整。

備援核准矩陣應該多久審查一次？

每月至少一次，並且在備援行為出乎意料或備援期間品質下降的任何事件之後。模型能力和價格變動頻繁，以至於第一季度有效的矩陣在第三季度可能不再有效。

何時不應自動進行多供應商備援？

當工作負載類別具有安全、法律、財務或合規敏感性，且備援模型尚未針對該特定任務類型進行評估時。在這些情況下，將請求加入佇列或顯示使用者可見的不可用狀態，比提供品質較低的自動回應更安全。

Novita AI 如何融入此運作模型？

Novita AI 提供了基礎設施層 —— 用於推論的 LLM API、用於代理執行的 Agent Sandbox、用於專用容量的 GPU Cloud —— 您可以使用上述實務對其進行儀器和運作。它不會取代使服務可靠的 SLO 定義、監控配置、劇本或治理決策。這些來自您團隊的運作實務。

最佳多供應商 LLM 服務：如何降低成本並提高正常運行時間？

對多供應商 LLM 服務而言，「更高的正常運行時間」意味著什麼