自架模型接 Codex／OpenCode：相容 API、延遲與成本怎麼驗收
自架模型的 /chat/completions 能回覆，接上 coding agent 卻卡在工具呼叫，第一步是核對 client 使用的協定與完整工具回合。驗收 OpenAI-compatible 服務時，需逐一核對實際需要的 endpoint、串流事件和工具結果格式。
Revolut 在 AI Engineer NYC 的第一方分享談到該團隊的自架模型與服務調校經驗。估算自己的預算時，需依實際硬體利用率、請求大小與併發重新計算。導入決策應從下面三層驗收開始。
先通過 client 的協定門檻
依 2026-11-03 的 Codex 設定參考，自訂 provider 的 wire_api 只支援 responses。如果你的服務只實作 Chat Completions，先確認是否有適用的相容層；只改 base URL 不會把兩種 API 自動轉換。
OpenCode provider 文件則提供以 @ai-sdk/openai-compatible 接自訂服務的路徑。兩個 client 的設定不能共用同一份 JSON／TOML，模型 ID 也必須是服務實際提供的名稱。
| 要確認的項目 | 能避免的誤判 |
|---|---|
| API base URL 與實際 endpoint | 把完整方法路徑當成 base URL |
| 模型 ID、chat template 與工具格式 | 一般聊天成功，就推論工具可用 |
| 認證來源與接收主機 | 把既有雲端 Key 送往新服務 |
| 串流事件、結束訊號與錯誤格式 | 收到文字片段，就判定整個回合成功 |
Codex 自訂 provider 可使用獨立 ID 與 env_key，詳見 官方進階設定。測試時保留原本的登入檔與 agent 權限限制，分開驗收模型接入與工具授權。
用同一份小 repository 比較完整任務
先固定測試 repository、起始 commit、client 版本、模型版本及工具權限。資料必須可公開或已獲准送到該服務；自架在另一個雲端帳號時，資料仍會送往該雲端環境。
以下是依文件檢閱整理的驗收設計，實際部署、模型、GPU、特定 provider 與負載效能仍待測試：
- 讀取回合：放入一個已知值的檔案，要求 agent 透過工具讀取。記錄工具名稱、參數是否有效，以及結果能否進入下一輪。
- 修改回合：提供一個已知失敗的測試，要求只改指定函式。用獨立測試判定輸出，並檢查有沒有超出允許檔案範圍。
- 多回合與上下文：加入必要規則和較長的真實程式碼片段，確認後續修改仍遵守規則。以真實程式碼與任務規則驗收 repository 理解能力。
- 中止與恢復：取消一個測試任務，從服務端確認請求是否停止；重新啟動時確認沒有重送已完成的有副作用工具。GPU 是否停止生成，以服務端狀態為準。
- 代表性併發：依預期使用人數逐步加壓，記錄失敗、排隊與完成時間，以符合團隊使用情境的負載確認承載能力。
每項保留成功與失敗紀錄。若工具參數常不符合 schema，維持檔案權限，先檢查服務與模型的工具格式，釐清協定或品質問題。
延遲和成本都以「驗收成功的任務」計算
首個 token 到達時間可以反映互動等待，但 agent 需要多次推論、工具及重試。另記下端到端完成時間、人工介入時間、驗收通過率；快出字、最後卻需要重寫的任務，要和一次通過的任務分開計算。
可先用以下自訂口徑做內部試算：
每個成功任務成本 =（同一測量期間的 GPU／主機費 + 儲存／網路費 + 維運人力估算）÷ 通過事先定義驗收條件的任務數失敗任務、重試與閒置主機仍計入分子。維運工時可以先用區間估算，但要公開假設；成功數為零時就回報沒有可用的單位成本，分母維持為驗收成功的任務數。
Revolut 的分享也強調服務調校、context 與 cache 的關係。實務比較時應分開記錄冷啟動、暖機、cache 命中與未命中，以及小任務和長上下文任務。先以小規模試用取得自己工作負載的數據，再評估採購效益。
切回原服務也是上線條件
保存原 provider 設定與測試前 commit，保留可明確選回原模型的方式。切回後建立新工作階段，重跑讀取及修改驗收，確認驗收使用新對話的狀態。外部工具已造成的變更，要依 diff 和執行紀錄逐項回復。
若你要設定的是 OpenCode Go 的帳號和模型入口，可先看 OpenCode Go 接入流程；自有推論服務的接入決策則依本文流程驗收。服務已連通但發生 timeout，則再區分 總請求、response header 與串流等待。
要擴大使用，至少先拿到一份能重跑的任務紀錄與回復結果。
參考資料：