如何評估 AI API Gateway：生產級檢查清單
以可重現流程評估 Protocol Conformance、故障演練、延遲、用量成本、安全邊界、Control Plane 與 Exit Risk。
評估 AI API Gateway，應把真實 Protocol Contract 跑過候選系統，主動製造在意的 Failure Mode，再檢查它產生的 Request-level Evidence。Feature List 或一次成功的「Hello World」無法證明 Streaming 正確性、Tool 相容性、Fallback 安全、成本準確度、Security Boundary 或可執行的 Exit Path。
最可靠的方法把條件分成兩類：任何一項失敗就淘汰候選者的 Mandatory Gate，以及所有 Gate 通過後才用來比較營運品質的 Evidence Score。
先定義 Workload Contract
不要從 Vendor Comparison Table 開始。先選一個代表性 Workload，寫下不可改變的契約：
- 明確 Endpoint：Responses、Chat Completions、Embeddings、Images 或其他 API；
- 明確 Model ID，以及是否允許 Alias；
- 使用中的 Streaming 與 Non-streaming Mode；
- Structured Outputs、Function Calling、Hosted Tools、Reasoning 等必要欄位；
- 一般與高百分位 Input/Output Length；
- Concurrency、Request Rate、Region 與 User-facing Deadline；
- 必要的 Usage、Cache、Cost 與 Request Correlation Field；
- 允許的 Fallback Route，以及是否禁止 Model Substitution；
- Data Retention、Access、Residency 與 Deletion 要求；
- 可能產生 Side Effect 的應用操作。
同一套 Gateway 可能通過內部 Text Assistant，卻無法承載 Streaming Coding Agent。「OpenAI-compatible」也不是足夠的 Workload Definition；相容性會依 Endpoint、Event Type、Tool、Schema Keyword 與 Provider Route 而不同。
若團隊仍在判斷需要單純 Proxy 還是 Model-aware Control Plane，可先閱讀 LLM Proxy 與 AI Gateway。以下清單假設 Gateway 類別已經合理，目標是驗證某個實作能否承擔必要責任。
先用快速淘汰條件縮小候選範圍
第一輪應直接排除無法滿足硬邊界的候選者。要求可重現的行為證據，不接受 Roadmap 承諾。
| Gate | 立即淘汰條件 | 要求證據 |
|---|---|---|
| Protocol | 必要 Request Field、Output Item 或 Stream Event 被丟棄或錯誤重寫 | 去識別 Request/Response 與 Parser Result |
| Model Identity | Gateway 靜默更換 Requested Model | 同時記錄 Requested/Actual Model 的 Attempt Record |
| Streaming | 緩衝完整回應、遺失 Cancellation 或破壞 Tool Argument Fragment | 帶 Timestamp 的 Event Sequence 與 Cancel Trace |
| Authentication | Browser 或 Workload Client 能取得 Provider Credential | Credential Flow Diagram 與真實 Key Rotation Exercise |
| Tenant Isolation | 某 Project 能使用或查看另一 Project 的 Key、Usage 或 Log | 使用真實隔離帳戶的 Authorization Check |
| Cost Evidence | 最終 Charge 無法連到 Model、Route、Price Basis 與 Usage | 單一 Request 的完整 Reconciled Ledger |
| Failure Safety | Partial Stream 被透明重播，或 Cancel 後又啟動 Attempt | 強制 Partial Stream 與 Cancellation Trace |
| Export and Exit | 無法匯出設定與 Request Contract，退出必須重寫應用 | Export Sample 與 Provider-native Rollback Drill |
Mandatory Gate 失敗，不能用高總分補償。良好 Dashboard 無法抵消 Tenant Isolation 缺陷，低價格也無法抵消錯誤的 Tool Contract。
建立小而完整的 Protocol Conformance Corpus
使用可重現、非敏感輸入，並把預期 Wire Behavior 納入版本控制。Corpus 必須直接呼叫真實 Gateway Endpoint；不能 Mock Provider，也不能複製 Gateway Conversion Logic 當作 Test Oracle。
| Case | Request | 必須觀察的結果 |
|---|---|---|
| Basic Non-streaming Text | 固定 Model 與 Prompt | Status、Model Identity、Text Location、Usage、Request ID 正確 |
| Streaming Text | 同一 Prompt 啟用 Streaming | Event 有序、First Effective Output、Final Event、Cancellation 正確 |
| Structured Output | 必填欄位與 additionalProperties: false 的 Strict Schema |
合法輸出或明確 Unsupported Error，不可 Silent Downgrade |
| Function Calling | 一個 Read-only Function 與回傳 Result | Function Name、JSON Arguments、Call ID Correlation、Final Answer |
| No-tool Path | 宣告相同 Tools 但任務不需要 Tool | 正常文字，不得捏造 Tool Call |
| Invalid Field | 故意送出不支援或 Malformed Request | 穩定 Client Error，不能用 Provider Fallback 掩蓋缺陷 |
| Long Input Boundary | 低於與高於核准 Limit 的輸入 | 依文件接受或明確拒絕，不得 Silent Truncation |
| Usage Detail | 可觸發 Cache 或 Reasoning Usage 的 Request | 欄位穿過 Route，並能與 Billing Record 對帳 |
| Cancellation | 連線後與 First Output 後分別取消 | Upstream Work 停止，沒有新 Fallback Attempt |
| Partial Stream | Effective Output 後連線失敗 | 一次明確 Partial Failure，不得出現隱藏第二份答案 |
每條可能承載 Workload 的 Route 都要跑完整 Corpus；Primary Route 通過不代表 Fallback 合格。Structured Outputs 指南與 Function Calling 比較提供這兩項能力的 Field-level Case。
每次記錄 Gateway Version、Route Configuration Version、Model ID、Provider、Region、Timestamp 與 Sanitized Result Hash。Model 與 Provider 行為會變動，因此 Rollout 前與重大 Route Change 後都應重跑。
測試 Routing 與失敗行為，而非只測成功
Reliability Claim 只有在 Failure Policy 可見時才有意義。Production 前主動製造：
- Primary Route 在 Header 前不可用；
- 有與沒有
Retry-After的 Provider Rate Limit； - Upstream Authentication 或 Account Failure；
- Slow Headers 與 Slow First Effective Output；
- Malformed Provider Response；
- Upstream Pending 時 Caller Cancellation；
- Visible Output 開始後 Connection Loss；
- 所有合格 Route 耗盡。
每個 Case 都要保存 Attempt Order、Selected Route、Status、Timing、Output 是否開始、Terminal Reason、Usage 與 Cost。除非另有顯式 Model-substitution Policy，否則必須確認 Requested Model 與 Protocol 保持不變。
同時量測 SDK、Application、Gateway 與 Provider 之間的 Attempt Amplification。某一層負責即時 Same-contract Fallback，Application 則負責判斷整個 User Action 能否重播。AI API Fallback Strategy提供分階段 Failure Matrix 與 Retry Budget。
Latency 也要使用精確定義：比較 Upstream Headers、First SSE Event、First Effective Output、First Visible Text、Completion 與 Visible Output Speed，並使用真實 Concurrency。不要接受一個無說明的平均「Latency」。詳見 AI API Latency Metrics。
從單一 Request 核對 Usage 與 Cost
挑選多個已完成 Request，沿完整帳務鏈追蹤：
application request ID
→ gateway attempt sequence
→ selected model and route
→ provider or normalized usage
→ applicable price basis
→ final recorded charge
評估必須回答：
- 適用時，Input、Output、Cached、Reasoning 與 Tool-related Unit 是否都存在？
- 哪些值來自 Provider，哪些是 Estimated？
- Model Price 何時選定，是否針對 Request 固定？
- Group、Service Tier、Discount 或 Surcharge 如何改變 User Charge？
- 哪些 Failed Attempt 會產生 Provider Cost，如何記錄？
- 最終成功 Fallback 是否掩蓋前面可計費 Attempt？
- Currency Conversion 與 Rounding Rule 是否明確？
- Finance 能否從 Immutable Request Record 重建 Daily Total？
至少測試 Normal Completion、Same-contract Fallback、Cancelled Request 與 Upstream Error。Dashboard Total 不足以作為證據；Gateway 需要提供可辯護的 Per-request Record。AI API Cost Tracking區分 Provider Usage、Platform Pricing、Customer Charge 與 Supplier Cost。
比較 Vendor 節省幅度前，必須固定同一 Model、Workload、Cache Behavior、Output Length、Failure Rate 與 Provider Price Basis。看似較低的成本可能只是缺少 Usage，或發生 Silent Model Substitution。
驗證 Security 與 Data Boundary
畫出 Client、Gateway 與各 Provider 的真實 Data Flow。每一 Hop 都要標示誰能讀取 Credential、Request Content、Response Content、Metadata 與 Administrative Configuration。
至少驗證：
- Provider Credential 僅存在 Server-side、At-rest Encryption，且不回傳一般 Client；
- Application Key 可按 Project/Workload Scope，且能獨立撤銷；
- 每個 Management 與 Log Endpoint 都在 Server-side 執行 Authorization；
- Log 不包含完整 API Key，Prompt/Response Retention 有顯式控制；
- Support Access 可歸因且有邊界；
- Configuration Change 有 Actor、Time、Before/After 與 Rollback Evidence；
- Exported Trace 去除 Secret、Personal 與 Proprietary Content；
- Deletion 與 Retention 能以實際行為證明；
- Region 與 Subprocessor Claim 符合實際使用 Route；
- Abuse Limit 盡可能在昂貴 Upstream Work 前生效。
詢問 Key Rotation、Operator 離職、Application Key 洩漏與 Provider Key 洩漏時會發生什麼，並使用隔離的真實 Test Credential 進行 Rotation/Revocation Exercise。不要把 Production Secret 複製到評估環境。
Gateway 無法讓不安全的 Application Tool 自動變安全。Tool Authorization、Transactionality、Approval 與 Idempotency 仍屬 Application Responsibility。AI API Key Security and Cost Controls可協助拆分 Credential 與 Workload Limit。
評估 Operational Control Plane
Data Plane 可能正常，Control Plane 卻帶來營運風險。檢查 Operator 如何修改與恢復設定：
| 範圍 | 必須回答的問題 |
|---|---|
| Versioning | 每次 Route、Price、Policy、Key Change 是否有版本或 Actor？ |
| Validation | Invalid Route 或 Incompatible Model 能否在啟用前被拒絕？ |
| Rollout | Change 能否先套用小 Workload 或低比例？ |
| Rollback | 能否快速恢復 Last-known-good Configuration？ |
| Availability | Control Plane 不可用時，Existing/New Request 會如何？ |
| Health | Channel Health 是否基於近期證據，自動停用是否可檢查？ |
| Incidents | 能否不跨多個無關系統就重建單一 Request？ |
| Limits | 高 Concurrency 下 Rate/Quota Decision 是否保持正確？ |
| Change Ownership | Emergency Edit 是否與一般 Product Configuration 分離？ |
實際完成一次 Configuration Rollback 與一次 Unhealthy-route Removal，記錄 Operator Step 並驗證 Data-plane Result。Rollback Button 的截圖不等於完成 Drill。
簽約前測試 Exit Path
Gateway 可能讓應用依賴 Model Alias、Custom Header、Proprietary Route Name、Log API、Normalized Error Shape 或 Hosted Prompt/Tool Configuration。逐項列出並判斷它是刻意採用的價值，還是意外 Lock-in。
可執行的 Exit Drill 應：
- 以文件化格式匯出 Route、Key Policy、Price 與 Audit Configuration；
- 把一個 Workload 切到 Provider-native Test Endpoint；
- 用明確 Application Configuration 取代 Gateway-only Header 或 Alias；
- 切換期間保持 Request Correlation 與 Usage Reconciliation；
- 記錄哪些功能無法在不重新設計下搬移；
- 依實際工作估算 Exit Engineering，而非採用 Sales Claim。
Exit Path 不要求 Gateway 與每家 Provider 完全可互換，而是要求團隊知道自己擁有什麼、Gateway 擁有什麼，以及如何還原底層 Protocol Contract。
Mandatory Gate 全部通過後才評分
Hard Boundary 使用 pass/fail，Operational Quality 使用小範圍 Evidence Score：
| 分數 | 意義 |
|---|---|
| 0 | 不支援或測試結果直接否定 |
| 1 | 僅 Claim 或手動展示一次，Evidence 薄弱 |
| 2 | 可重複展示，並有 Request-level Evidence |
| 3 | 可重複、受監控，且能透過已測 Control 恢復 |
可評分範圍包括 Protocol Coverage、Route Reliability、Attempt Evidence、Latency Diagnostics、Usage Accuracy、Cost Reconciliation、Key Isolation、Auditability、Configuration Rollback、Supportability 與 Exit Effort。依 Workload 加權，但每個分數旁必須保留 Raw Evidence。
若多個欄位仍屬主觀判斷，不要製造 87.4/100 這類虛假精確度。決策紀錄應包括 Mandatory Gate、各範圍分數與證據、已接受缺口與 Owner、Remediation Deadline、Cost/Contract Assumption、候選選擇理由，以及 Production 首月後的 Review Date。
以 Ownership 比較 Build 與 Buy
正確問題不是內建 Gateway 是否沒有 License Fee，而是團隊能否長期承擔責任。
| 責任 | 內部 Build | Purchase 或 Managed |
|---|---|---|
| Protocol Updates | 追蹤 Provider Schema 與 Regression | 驗證 Vendor Update 與 Route Compatibility |
| Routing and Retry | 設計 State Machine 與 Failure Evidence | 設定 Policy 並稽核實際 Attempts |
| Usage and Billing | Normalize Usage 並維護 Pricing Logic | 對帳 Vendor Record 與內部 Finance Truth |
| Security | 保存 Secret、執行 Tenancy、稽核 Access | 驗證 Vendor Boundary 並設定 Least Privilege |
| Reliability | 營運 Data Plane、Control Plane 與 On-call | 監控 Vendor 與 Integration，保留 Exit Path |
| Product Support | 診斷所有 Application/Provider Interaction | 分流 Gateway、Provider 與 Application Fault |
不要套用泛化薪資或「節省工程時間」數字。應依自己的 On-call Load、Protocol Change History、Incident Frequency、Finance Requirement 與 Compliance Work 估算。Managed Product 仍需要內部 Accountable Owner。
正確把清單套用到 Modelflare
Modelflare 的評估邊界應明確。它提供 Workload API Keys、依 Requested Model 在合格 Group/Channel 間路由、一般 Key 的 Ordered Group Fallback、Smart API Key 的 Strategy-based Group Selection、Pre-upstream Group RPM Admission，以及 Request-level Usage、Cost、Status 與 Timing Record。
GPT、Codex 與 OpenAI Traffic 是完整適配的 Compatibility Target。其他 OpenAI-compatible Model Family 應先視為 Raw Chat Completions Pass-through，除非個別能力已驗證。共用 Base URL 不代表 Responses、Hosted Tools、Structured Outputs 或 Function Calling 在每條 Route 都相同。
Modelflare Fallback 應為 Requested Model 搜尋合格路徑，而非靜默選另一個模型；Downstream Output 開始後 Channel Failover 應停止。上述 Claim 都應以 Corpus 與 Failure Drill 驗證，而非當作 Marketing Statement 接受。
使用 Models & Pricing確認目前 Model/Group Surface，並透過 Modelflare Docs設定隔離 Test Key。評估 Request 應保持非敏感、Pin Exact Model，並保留能調查每次 Attempt 的 Request ID。
最終決策必須可重現：另一位工程師能跑同一 Corpus、檢查同類 Evidence，並理解候選者為何通過。這比閱讀比較頁慢，卻遠快於在 Gateway 已承載 Production Traffic 後，才發現 Tool Contract 不相容、帳單無法追溯或 Fallback 不安全。