追蹤 AI API 請求的每一次嘗試
生產實作指南:追蹤 AI API 請求的每一次嘗試。內容包含確定性工件、失敗邊界、上線檢查與有來源的限制。

生產實作指南:追蹤 AI API 請求的每一次嘗試。內容包含確定性工件、失敗邊界、上線檢查與有來源的限制。
先做決策
追蹤 AI API 請求的每一次嘗試是一份明確的生產契約,而非孤立的程式修改。移動流量前先定義成功訊號、終止失敗狀態與回復條件。以下工件把證據與假設分開,並讓每次嘗試都可追溯。
先落實 request,再以確定性案例證明 attempt,並把 privacy 設為上線門檻,而非事後補項。
可重用的技術工件
以下表格是審查記錄。只有證據來自同一請求、測試時窗或設定快照時才算通過。
| 檢查點 | 需要保留的證據 | 通過條件 |
|---|---|---|
request |
request_id,tenant_pseudonym,operation,accepted_at |
記錄能連結一個邏輯請求與一次具體嘗試。 |
attempt |
attempt_number,route_version,model,channel_pseudonym |
記錄能連結一個邏輯請求與一次具體嘗試。 |
timing |
connect,headers,first_event,first_output,idle,total |
在線路邊界保留並精確比對該值。 |
terminal |
HTTP,provider_class,cancellation_source,retry_decision |
記錄 owner、來源、核驗日期與已知限制。 |
usage |
normalized_input/output/cache_categories_and_provenance |
預留、觀測與最終值能在同一持久帳本對帳。 |
privacy |
allowlisted_attributes_only;no_prompt,secret,or_raw_arguments |
限制明確,超過時預設拒絕。 |
演算範例
範例使用合成且確定性的資料。請改用已審查的工作負載參數,勿把生產密鑰或客戶提示放入測試工件。
trace_id: 7f3a...synthetic
request_id: req_demo_001
operation: responses
attempts:
- attempt: 1
route_version: rv_42
model: model_alias
timings_ms: { headers: 812, first_output: 1240, total: 3100 }
terminal: upstream_503
- attempt: 2
timings_ms: { headers: 620, first_output: 980, total: 2400 }
terminal: success
usage: { input: 1800, output: 220, source: provider_normalized }
實作流程
- 變更前凍結目前請求、回應、設定與可觀測基線。
- 執行一個確定性的正向案例並保留客戶端完整結果。
- 執行配對的負向或上限案例,以證據確認失敗行為。
- 用一個邏輯請求 ID 連結全部嘗試,記錄時間、終態與用量但不保存敏感正文。
- 僅對有界流量放量並設定停止條件,不能因 happy path 通過就直接擴大。
- 變更後回讀持久狀態與公開行為;任何不變量失敗時執行預備的回復。
常見失敗模式
即使外層 HTTP 看似成功,以下情況仍使結論無效:
- 把提示、密鑰或原始正文寫入高基數遙測。
- 依陣列位置而非穩定 call ID 連結分片。
- 只讀取便利欄位而遺漏輸出項、工具呼叫、拒絕或部分結果。
- 公布百分位數卻未揭露負載、並發、失敗、區域與時窗。
Modelflare 邊界
Modelflare 可集中管理 OpenAI 相容路由、密鑰、群組、用量與失敗處理,但已設定路由不代表上游支援所有選用欄位。必須以原生協定驗證具體模型與渠道;價格以目前來源為準,保留明確零值,最終持久結算才是帳務真相。
發佈前檢查表
- 先回答核心問題再補背景。
- 每個欄位、狀態、指標與公式都有唯一 owner。
- 範例只用合成識別,不含密鑰或客戶資料。
- 所有語言保留相同結構、程式碼、限制與警告。
- T-1 日重查易變契約、模型支援與價格;失效時移動日期。
- 預約時間前,公共 API、本地化路由與 sitemap 均不出現文章。
來源與核驗日期
來源核驗日期:2026-08-07。來源只建立外部契約或原則,不證明未測試的路由已支援。