進入 2026 年後，認真考慮遷移離開 OpenAI 的團隊明顯變多了。開放權重模型在日常生產任務上的品質已經很難與頂尖模型區分開來，公開單價更低，而權重本身可以下載這一點，把與廠商的關係從依賴變成了選擇。

但這不代表切換是免費的。API 呼叫本身幾乎一模一樣，真正要做的工作在它周圍的一切。本文說明：哪些東西能原樣搬過去、哪些會悄悄出問題、怎樣設計一次有意義的比較，以及什麼時候留在原地才是正確答案。

先把預期對齊。 換廠商就是換一個基底 URL、一個模型名稱、一份憑證。但要拿回同樣的輸出品質，那是以天為單位計的提示詞工程。給一個範圍明確的功能預留一到三週。任何假設可以即時替換的估算，都是樂觀估算。

哪些東西能原樣搬過去

比你想的多，這也正是值得考慮的原因。

呼叫格式能搬。 認真做開放權重的服務方現在基本都提供相容 OpenAI 慣例的介面，你現有的用戶端函式庫、請求結構與串流處理程式碼通常無需改動即可運作。例如 Kimi K3 同時提供 OpenAI 相容與 Anthropic 相容介面，細節見 Kimi K3 API 指南 。

周邊架構整體能搬。 保管憑證的代理層、佇列、重試邏輯、按使用者計量、日誌，這些都不在意背後是哪個模型。如果這一層做得乾淨，切換真的就是改設定。反過來，如果你把廠商 SDK 直接鋪滿整個程式碼庫，現在就是發現這件事的時刻。

檢索層能搬。 向量化、向量資料庫與分塊策略與生成模型無關，不過如果新模型的脈絡視窗差異很大，分塊大小值得重新檢視。

哪些東西會悄悄出問題

失敗模式夠一致，可以事先規劃。

提示詞無法移植。 這是最大的一項。提示詞往往是在不自覺中針對某個模型的習慣調出來的。原樣搬過去，你會得到技術上正確但風格跑偏的輸出：囉嗦程度不同、格式不同、願不願意說「我不知道」也不同。請做好重寫系統提示詞的準備，這就是遷移工作的主體。

結構化輸出的行為不一樣。 如果你依賴受結構描述約束的回應，要確認新服務方是怎麼強制的。有的在解碼層保證符合，有的只是禮貌地要求、多數時候會遵守。按「有保證」寫出來的程式碼，遲早會碰到一個畸形欄位。

工具呼叫差在細節。 呼叫格式已標準化，但可靠度、連續呼叫多個工具的意願、以及沒有工具符合時的行為都不一樣。在代理式負載裡最痛，因為誤差會跨步驟累積。

推理行為與計費方式不同。 有些模型始終推理，並把推理 token 計為輸出。一個預設開啟推理且預設強度拉滿的模型，即使公開單價更低，單次請求成本也可能高於你剛離開的頂尖模型。在試算節省之前，先把預設值讀一遍。

安全邊界與拒答位置會移動。 每家劃線的位置不同。目前模型能處理的內容可能被拒答，反之亦然。如果你的應用涉及醫療、法律或金融，請明確測試這一點，而不是等客戶來告訴你。

設計一次有意義的比較

廠商的基準測試回答不了你的問題。自己做一個小的評測集來回答。

從生產流量裡收集 30 到 100 筆真實輸入，要涵蓋完整範圍、包含棘手樣例，並為每一筆記錄下你認可的正確輸出。這就是我們在 OpenAI API 整合指南 裡描述的同一套評測體系，如果已經有了，比較只需要半天。

兩個模型都要用各自調好的提示詞跑。拿為 A 模型最佳化的提示詞去跑 B 模型，那不是比較，只是再次證明提示詞無法移植。

測四件事：依你標準判定的輸出品質、含推理 token 的單次請求總成本、使用者真實體驗的分位數延遲（不是平均值）、以及失敗模式。最後一項最重要也最常被漏掉。一個平均品質略低但從不產生畸形輸出的模型，對自動化流程可能是更好的選擇。

接著跑影子部署。把線上流量複製一份發給候選模型但不使用其回應，用一週的真實使用做對比。合成評測會漏掉長尾，生產流量不會。

遷移離開 OpenAI 後，節省在哪裡是真的

先算帳，再動工程，因為答案隨負載差異極大。

大批量常規任務上，節省真實且可觀。 分類、擷取、摘要、路由都屬於這一類。它們幾乎不需要頂尖級能力，又持續不斷地跑，單 token 價差會一路累積。這是最有力的理由，通常僅憑這一條就足以支撐遷移。

中等規模的互動功能上，節省真實但有限。 每月處理幾千次對話的客服助理，用哪家花的錢都不多，工程時間可能超過一整年的節省額。

如果推理 token 計為輸出且新模型每次呼叫都推理，節省可能是幻覺。 請用你真實的提示詞長度建模，而不是公開單價。

還有一類節省與錢無關。 可下載的權重是一個退出選項。當服務方停掉你依賴的模型、在合約中途改價、或施加不合適的速率限制時，「有地方可去」本身是有價值的。真正行使這個選項要花多少錢，見自建 Kimi K3 指南 ，它比多數團隊預想的要高。

答案通常是「兩個都要」

把這件事框定為一次切換，本身就是錯的。回報最好的團隊會在同一個介面後面同時跑多個模型。

按任務路由。把大批量常規工作發給能通過評測的最便宜模型；把長脈絡與代理式工作發給最擅長它的模型；再保留一個頂尖模型，用於那一小部分你想要最強答案、價格不是決定因素的請求。

也可以按資料分級路由。含有不得離開轄區資料的請求走自建模型，其餘走託管 API。因為介面相同，應用層根本不需要知道請求走了哪條路。

這要求抽象層在你需要它之前就已經存在。先建好這道邊界，廠商選擇就變成設定項而不是專案，未來的切換也會因此變便宜。預算全貌可參考 AI 整合成本指南 ，它把建置成本與營運成本分開算。

什麼時候應該留在原地

比遷移類文章暗示的要多得多。

如果量小，就留下。工程成本收不回來，那些時間花在功能本身更值。

如果你確實依賴某個廠商特有能力，並且已經驗證（而不是假設）替代方案沒有它，就留下。下結論之前先測試。

如果這是安全敏感的應用，而目前服務方的邊界經過真實測試確實符合需求，就留下。重建這份信任也是有成本的。

如果你還沒有評測體系，現在就留下。沒有評測的切換意味著，直到客戶告訴你，你才知道品質掉了。先把體系建起來，無論最後怎麼決定它都有用。

讓比較被正確地跑一遍

Mecanik 在人工智慧整合服務 中承接多廠商大模型工作：路由層、評測體系、針對目標模型重寫提示詞，以及告訴你生產環境真實表現的影子部署。

在你做出承諾之前，我們會把你自己的流量跑過多個服務方，把品質、成本與延遲並排擺出來，包括那些誠實建議就是「別動」的情況。如果你現有的整合把某一家廠商硬編碼在整個程式碼庫裡，我們的 OpenAI API 整合指南 講了那一層代理，它能讓這次以及今後每一次切換都便宜下來。

告訴我們目前的月度支出規模與這個功能在做什麼，我們會告訴你這次遷移值不值這份工程投入。

相關文章: 微調 vs RAG vs 提示詞：各自的真實成本 、打造 OpenAI API 聊天機器人：2026 指南 。

常見問題

從 OpenAI 遷到開放權重模型難嗎？ API 呼叫本身很簡單，多數服務方提供 OpenAI 相容介面，改一個基底 URL、模型名稱與憑證即可。真正的工作是重寫那些針對單一模型習慣調校過的提示詞，並重新驗證結構化輸出與工具呼叫。給一個範圍明確的功能預留一到三週。

換成開放權重模型能省錢嗎？ 取決於負載。分類、擷取、摘要這類大批量常規任務通常節省顯著；而小規模互動功能往往收不回工程成本。要留意那些始終推理並把推理 token 計為輸出的模型，它們可能抵銷掉更低的公開單價。

我現有的提示詞在別的模型上還能用嗎？ 不重寫通常不行。提示詞是針對某個模型的囉嗦程度、格式與拒答傾向調出來的，同一段提示詞換個模型會得到技術上正確但風格跑偏的輸出。比較之前請按模型分別調校。

怎樣公平地比較兩個大模型？ 用 30 到 100 筆已知正確輸出的真實輸入建評測集，為每個模型單獨調校提示詞，然後比較品質、含推理 token 的單次請求成本、真實分位數延遲以及失敗模式，再用線上流量跑一次影子部署。

該用一家服務方還是多家？ 在同一個介面後面用多家。大批量常規工作走能通過評測的最便宜模型，長脈絡與代理式工作走最擅長的模型，再保留一個頂尖模型給需要最強答案的少數請求。這樣未來切換也更便宜。