對 LLM API 進行不誤導的負載測試

生產實作指南:對 LLM API 進行不誤導的負載測試。內容包含確定性工件、失敗邊界、上線檢查與有來源的限制。

對 LLM API 進行不誤導的負載測試

生產實作指南:對 LLM API 進行不誤導的負載測試。內容包含確定性工件、失敗邊界、上線檢查與有來源的限制。

先做決策

對 LLM API 進行不誤導的負載測試是一份明確的生產契約,而非孤立的程式修改。移動流量前先定義成功訊號、終止失敗狀態與回復條件。以下工件把證據與假設分開,並讓每次嘗試都可追溯。

先落實 workload,再以確定性案例證明 traffic,並把 ethics 設為上線門檻,而非事後補項。

可重用的技術工件

以下表格是審查記錄。只有證據來自同一請求、測試時窗或設定快照時才算通過。

檢查點 需要保留的證據 通過條件
workload prompt/output_distributions,stream_share,tools,schema 記錄 owner、來源、核驗日期與已知限制。
traffic arrival_model,concurrency,warm-up,duration,region 限制明確,超過時預設拒絕。
routing model_ID,route_version,fallback_and_retry_policy 記錄 owner、來源、核驗日期與已知限制。
measurement eligible_denominator,errors,p50/p95/p99,TTFT_definition 在線路邊界保留並精確比對該值。
saturation queue,admission_rejects,upstream_429,timeout_phase 記錄能連結一個邏輯請求與一次具體嘗試。
ethics owned_endpoint_and_approved_capacity;never_test_third_parties 執行前立即核驗身分、作用域與策略。

演算範例

範例使用合成且確定性的資料。請改用已審查的工作負載參數,勿把生產密鑰或客戶提示放入測試工件。

scenario: steady_mixed
duration: 20m
warmup: 5m
arrival_rate_rps: 2
max_concurrency: 24
requests:
  short: 60%
  long: 25%
  tool: 10%
  structured: 5%
thresholds:
  error_rate: "< 0.01"
  first_output_p95_ms: "< reviewed_target"
report_failures: true

實作流程

  1. 變更前凍結目前請求、回應、設定與可觀測基線。
  2. 執行一個確定性的正向案例並保留客戶端完整結果。
  3. 執行配對的負向或上限案例,以證據確認失敗行為。
  4. 用一個邏輯請求 ID 連結全部嘗試,記錄時間、終態與用量但不保存敏感正文。
  5. 僅對有界流量放量並設定停止條件,不能因 happy path 通過就直接擴大。
  6. 變更後回讀持久狀態與公開行為;任何不變量失敗時執行預備的回復。

常見失敗模式

即使外層 HTTP 看似成功,以下情況仍使結論無效:

  • 公布百分位數卻未揭露負載、並發、失敗、區域與時窗。
  • 多層重試相乘,把短暫 429 放大成過載。
  • 取消未傳到佇列與上游,結果無用後仍消耗容量。
  • 把提示、密鑰或原始正文寫入高基數遙測。

Modelflare 邊界

Modelflare 可集中管理 OpenAI 相容路由、密鑰、群組、用量與失敗處理,但已設定路由不代表上游支援所有選用欄位。必須以原生協定驗證具體模型與渠道;價格以目前來源為準,保留明確零值,最終持久結算才是帳務真相。

更完整的決策邊界見上層指南,目前客戶端設定見接入文件。

發佈前檢查表

  • 先回答核心問題再補背景。
  • 每個欄位、狀態、指標與公式都有唯一 owner。
  • 範例只用合成識別,不含密鑰或客戶資料。
  • 所有語言保留相同結構、程式碼、限制與警告。
  • T-1 日重查易變契約、模型支援與價格;失效時移動日期。
  • 預約時間前,公共 API、本地化路由與 sitemap 均不出現文章。

來源與核驗日期

來源核驗日期:2026-08-07。來源只建立外部契約或原則,不證明未測試的路由已支援。