TechMoon 科技月球
WordPress、SEO 與 AI 工具實測指南
Vercel AI Gateway Virtual Models：換模型不必再改程式碼
Vercel 於 10 月 28 日正式介紹 AI Gateway 的 Virtual Models，把模型名稱連同路由、備援與資料處理限制存成 vmc/ 共用代稱，官方稱編輯後幾分鐘內對新請求生效、不必重新部署。設定衝突時虛擬模型的值壓過請求端，控制權隨之移到團隊設定端，換模型的相容性與品質仍要自行驗證。
用 AI 摘要這篇文章：
Vercel 在 10 月 28 日（台北時間下午 3 時 25 分）的官方部落格文章中，正式介紹了 AI Gateway 的 Virtual Models，官方 X 帳號在 15 小時後（台北時間 10 月 29 日上午 6 時 27 分）跟著發布公告，把賣點列為集中管理模型字串與設定、即時換上新模型、強制零資料保留。它的作用可以用一句話講完：把模型名稱連同供應商路由、備援、推論區域與資料處理限制，一起存成一個 vmc/ 開頭的共用 ID，之後要換模型只改這份設定，不必再動應用程式碼。這次更新值得記住的取捨在於：換模型脫離了部署流程，而路由與合規設定的最終決定權，也從發出請求的那一端，移到管理這份設定的團隊手上。
模型字串變成一份有名稱的設定
Virtual Model 本身並不是新模型，而是儲存在 AI Gateway 的一份呼叫設定。團隊用 CLI 建立一個代稱，例如：
vercel ai-gateway virtual-models create coding-agent --model anthropic/claude-opus-5.5 --config '{"speed":"fast","zeroDataRetention":true}'應用程式之後就把 vmc/coding-agent 當成模型名稱來呼叫。想換模型時，管理端下一行指令：
vercel ai-gateway virtual-models edit coding-agent --model openai/gpt-6.1-sol官方部落格寫明，所有使用這個代稱的應用與代理，會在幾分鐘內對新的請求套用新設定，過程不需要改程式碼，也不需要重新部署。這幾分鐘的傳播時間是官方說法，實際延遲未必相同，把按下儲存的瞬間當成全部流量已完成切換，並不安全。
名稱背後可以掛的設定相當完整：供應商順序與限定名單、模型備援鏈、快速模式、服務等級、提示詞快取、推論區域、零資料保留（Zero Data Retention）、禁止供應商以請求資料訓練，以及逐家供應商的專屬選項。代稱也不限文字模型，官方文件列出嵌入、圖片、影片、語音合成、語音轉錄、重排與決策模型都適用同一套機制。
官方在文章裡也把「為什麼現在要做這件事」講得很直白：AI Gateway 過去 90 天上了 125 個新模型，換模型本來就是改一行字串的事，但那一行字串活在程式碼裡，改它通常意味著一次重新部署。Virtual Models 把那一行字串搬出程式碼，換模型的動作就從部署流程裡解開了。部落格同時給了按任務分流的例子：客服工單分類每小時可能跑數百次、要的是便宜；法律合約審查一天只跑幾次、要的是推理深度。兩種任務各自配一個代稱，各自的模型與設定可以獨立演化，互不牽動。
時間線上有一點值得先說清楚：這項功能的文件頁，較早版本至少在 9 月下旬就已上線（網際網路檔案館留有 9 月 23 日的快照，頁面標題當時就叫做 Virtual Models），10 月 28 日的部落格文章是正式的對外介紹。換句話說，它已經跑了一段時間，不是發文當天誕生的新東西，文件在此前已大幅擴寫，把設定互動、模型類型與代理整合的細節補齊。
誰說了算：設定撞在一起時的優先規則
共用名稱真正的治理意涵，藏在虛擬模型設定與單次請求選項的互動規則裡。依 Vercel 官方文件的互動表，原則可以整理成三層：
| 情境 | 官方規則 |
|---|---|
| 虛擬模型已設定的欄位（供應商順序、備援、快速模式、排序、服務等級、快取、標籤等） | 虛擬模型的值生效，請求送來的同欄位值被忽略 |
| 虛擬模型未設定的欄位 | 請求自己的值照常生效，沒有設定的話才用系統預設 |
| 供應商專屬選項 | 兩邊逐項合併，虛擬模型設定過的項目贏，其餘留給請求 |
這代表「大家用同一個名稱」不等於「所有選項都一致」。哪一段設定被收歸管理端，取決於這份虛擬模型實際存了哪些欄位。文件給了一個完整的解析範例：某個代稱設了歐盟推論區域、供應商順序 bedrock 與 vertex、Anthropic 推理強度 high、觀測標籤 coding-agents，快取留空。此時若有呼叫者照樣送出自己的選項，結果是供應商順序仍照代稱的設定走歐盟、標籤記成 coding-agents（請求的標籤被忽略）、快取採用請求端的 auto（因為代稱沒設）、推理強度維持 high（逐項合併時代稱贏）。一個欄位一個結果，沒有全有全無。
文件裡還有一個更主動的狀態：把欄位設成系統預設（@default），會直接丟棄請求端送來的值，套用系統預設行為，官方舉的例子是防止呼叫者透過共用名稱固定使用優先服務等級。這個狀態只存在於排序、服務等級、快取與供應商逾時四個欄位。
合規設定走更嚴格的規則：零資料保留與禁止訓練，只要任何一方開啟就生效，虛擬模型關不掉請求端的限制，請求端也覆蓋不了虛擬模型的限制。對把資料處理條件寫進合約的團隊來說，這是雙向的保險。
往上還有一層團隊設定。官方文件明列，虛擬模型可以為自己的流量加限制，但不能放寬團隊既有的規則：模型允許名單檢查的是代稱背後的實際模型，不是 vmc/ 名稱本身；團隊停用的供應商，即使被寫進代稱的供應商順序也不能服務；全團隊的零資料保留設定關不掉；流量照常計入各種預算。換句話說，共有三層權威：團隊設定、虛擬模型設定、請求選項，衝突時一律從最上層往下壓。
觀測歸因也跟著換了位置。代稱的標籤會取代請求自行送來的標籤，官方控制台的 Virtual Models 頁面按任務顯示請求量、花費與成功率。原本靠請求標籤區分活動或功能的團隊，集中之後要重新安排標籤策略，先想清楚要看的是任務總用量還是各應用各自的用量，否則改完反而答不出費用來自哪裡。
兩個容易漏看的細節：推論區域只作用於 AI Gateway 系統憑證處理的請求，團隊自帶供應商金鑰（BYOK）的嘗試不在保障範圍；必要能力清單是整組替換而非疊加，請求原本用 has: ['free'] 讓流量留在免費供應商，一旦代稱自帶能力清單，這層保護就消失了。
編程代理最先吃到好處
這個設計最直接的受益場景是編程代理。Claude Code、Codex 這類工具每次請求只送出一個模型 ID，通常無法逐請求附上供應商順序、備援或資料處理選項，Virtual Models 等於讓設定跟著任務走，而不是跟著客戶端走。想在模型之間手動切換的讀者，先前也有 Free Claude Code 這類開源路由器可選，兩者解決的是同一個痛點的不同側面：路由器把選擇權留給開發者，虛擬模型把它交給團隊設定端。
官方文件的整合細節頗具體：先以 vercel ai-gateway setup 把代理接上 AI Gateway，之後 Claude Code 的模型選單會列出 claude-code/vmc/<代稱>，底層模型支援百萬 token 以上上下文時再加註 [1m] 後綴；Codex 可以用 codex --model vmc/<代稱> 指定，或寫進設定檔。代理端只儲存代稱，所以管理端編輯設定，全團隊的新請求一起跟進，不需要逐一改每個開發者的環境，官方文件對這個場景的描述很直白：模型的設定可以之後再改，不必碰每個開發者的設定檔。清單裡只會出現指向語言模型的代稱，剛建立的代稱沒有顯示時，重啟代理讓它重新載入模型清單即可。
費用方面官方也表示，AI Gateway 反映供應商定價、推論不加價，自帶金鑰的請求同樣不收平台費。對把代理工作交給不同模型的團隊來說，計費透明度是選閘道時的實際考量，這點至少在官方的定價宣稱上站得住。
換模型時它不會替你把關的部分
集中管理解決的是設定的散落問題，模型本身的差異要另外驗證，官方文件在好幾處都把界線畫得很清楚。
供應商專屬選項只對該供應商有效。部落格舉例，Anthropic 的推理強度設定，在代稱改指向 OpenAI 模型後就不再適用，官方建議每次切換供應商都重看一遍供應商選項。介面差異也還在：代稱只服務自己那種模型類型，把圖片代稱丟給文字聊天介面會收到 400 錯誤，語音、尺寸、影片長度這類參數仍要符合底層模型接受的值。
備援行為值得單獨理解。代稱可以放進請求自己的備援陣列，但每次嘗試是分開解析的：虛擬模型的路由與設定只作用於它自己那次嘗試，不會延伸到鏈上的下一個模型。如果任務要求固定輸出格式或資料限制，每個可能接手的環節都要分別檢查。
至於任務品質，官方部落格給的做法很樸素：正式流量切換前，另建一個候選代稱（例如 vmc/coding-agent-candidate）指向新模型，對著它跑評測，品質掉下來就把原本的代稱指回舊模型。共用入口讓切換變便宜，也讓一次切換影響所有呼叫者，事前比較因此更必要，而非更省略。
維運上有幾個硬規則。代稱的 slug 建立後不能改，命名按任務用途（客服摘要、程式代理）比塞進模型版本名更能活得久；封存後使用該名稱的請求會直接回 404，還原才恢復服務；CLI 的移除指令不跳確認，但設定會保留，還原指令可以救回。權限矩陣是：任何成員都能使用代稱，擁有者（Owner）與一般成員（Member）都能建立，而編輯、封存、移除與還原，只有建立者本人或團隊 Owner 可以做。多個應用依賴同一個名稱時，建立當下就該記錄誰擁有它。
什麼時候該把模型字串交出去
判斷標準其實只有一條：同一個任務的模型字串，同時活在幾個地方。當它出現在正式應用、排程工作、後台腳本與多個代理的設定檔裡，換一次模型要逐一核對的成本，會很快超過建立一個共用代稱的成本。只有單支小程式時，直接寫模型字串仍然單純，先數清楚要一起變更的位置，再決定要不要收攏。
模型閘道的市場位置可以順著看：OpenRouter 讓呼叫端在數百個模型之間自由切換，用量版圖的變化也一直是觀察重點，Opus 5.5 近期重回支出冠軍就是一例；Vercel 這次選的路線不同，它把切換權留給平台設定端的團隊，而不是每個呼叫者。兩者回答的問題不一樣，前者問「能叫到哪些模型」，後者問「這個任務該由誰決定用哪個模型」。想讓多個代理分工吃不同模型的團隊，也可以把這套共用代稱與 HarnessRouter 這類代理交換層放在同一張圖上思考，一邊管模型設定，一邊管任務派工。
對已經在 Vercel 生態裡的團隊，這次更新與平台近期的治理動作方向一致：市集的存取憑證正在收緊長效金鑰，AI Gateway 這端則把模型設定的控制權往上收。兩件事放在一起看，Vercel 想把代理流量的治理留在自家控制台裡的意圖相當清楚。入門途徑有兩個：團隊控制台的 Virtual Models 頁面，或最新版 Vercel CLI，先拿一個低風險任務試水位，把候選代稱的評測流程跑順，再考慮把正式流量交給它。
