Vercel Virtual Models 教學：同一個模型名稱，如何管理團隊 AI 設定？

Vercel Virtual Models 想解決一個團隊常見的問題：如果有三個 AI 應用，又各自使用程式代理，換一個模型往往不只改一次名稱。不同地方還可能留著不同備援、費用與資料處理設定。

這些差異平常不一定看得見，直到有人切換供應商，才發現某個應用沒有跟著更新，或原本要求的限制沒有寫進那次請求。

Vercel 於 2026 年 10 月 28 日推出 AI Gateway Virtual Models，讓團隊把模型與相關設定存成一個可重複呼叫的名稱。

應用或代理使用 vmc/ 開頭的名稱，背後對應的模型與路由則由管理者調整。官方表示，變更會在幾分鐘內套用到新的請求。

因此，這次更新的重點是集中管理呼叫設定。換了底層模型以後，回答品質、工具操作與原有輸入是否相容，仍要另外確認。

要把分散的設定收攏，第一步是讓每個呼叫者使用同一個任務名稱，再清楚區分名稱和背後實際工作的模型。

Vercel Virtual Models：固定任務名稱，集中調整設定

Virtual Model 可以理解成一份有名稱的呼叫設定。以 vmc/customer-summary 為例，應用程式記住這個名稱，AI Gateway 則負責找到設定指定的模型與處理方式。

這裡的「虛擬」不代表另外訓練出一套模型。真正產生摘要的仍是背後的底層模型。新增的能力，是讓模型選擇與周邊設定有一個共用入口。

當底層模型換了，呼叫者不必每個都重新填名稱。官方文件說明，新設定會在幾分鐘內影響新的請求，因此也不應把按下儲存的瞬間，當成所有流量已經完成切換。

除了文字模型，這個概念也適用於 AI Gateway 目錄中的圖片、影片、語音、轉錄、嵌入與重排等類型。不過，名稱能共用管理方式，並沒有消除不同模型類型的介面差異。

例如，圖片模型的虛擬名稱仍要送進圖片生成介面。把它當成文字聊天模型呼叫，文件指出會得到錯誤。語音、尺寸與影片長度等參數，也要符合底層模型接受的值。

這項限制很實際：中央可以替換模型，但不能替應用自動理解每種模型的輸入要求。因此，適合固定的是「這個任務要呼叫哪份設定」，而非假設所有模型都能接受完全一樣的請求。

對只有一個小程式的人而言，直接填模型名稱可能已經足夠。當同一任務同時出現在後台、排程與不同代理裡，共用設定才開始省掉反覆核對的工作。判斷是否需要它，可以先數清楚真正要一起變更的地方。

集中之後，先釐清哪一層規則優先

AI Gateway 本身是請求進入模型供應商前的共同入口。Virtual Models 再把某個任務的路由、備援、資料限制與追蹤標籤存下來，讓原本難以逐次附上選項的工具也能使用。

但請求最後的設定，還會受到團隊規則影響。官方文件明列，模型與供應商允許名單、預算，以及團隊開啟的零資料保留限制，仍然適用。虛擬模型不能替自己放寬團隊限制。

在虛擬模型和單次請求之間，許多已明確設定的欄位則以虛擬模型為準。例如，管理者指定了供應商順序，呼叫者自己送來另一份順序，後者不會蓋掉前者。

未設定的欄位並不是一律被清空。它們仍可能沿用單次請求的值，或交給系統預設處理。這代表「使用同一個名稱」不一定等於「所有選項都完全一致」，要看這份設定實際存了哪些內容。

零資料保留與禁止供應商用提示訓練，採取的是更嚴格的合併方式：任一方啟用，就不能由另一方關閉。這能保留特定資料處理要求，但不能進一步推成整個應用已符合所有合規義務。

區域設定也有條件。文件說明，虛擬模型指定的推論區域只作用在 AI Gateway 系統憑證的嘗試，不作用在團隊自帶供應商憑證的嘗試。使用自己的金鑰時，不能直接沿用前一種保證。

因此，團隊需要先說清楚，哪些要求必須成為共用設定，哪些可以交給呼叫者選擇。否則，介面上看似只有一個模型名稱，背後仍可能存在不同的處理條件。

預設值也有差別。文件把部分欄位區分為未設定、指定值與系統預設：未設定時允許請求帶自己的值。選擇系統預設，則會移除請求的選擇。管理者若想取消各人自行指定的服務等級，就要分清這兩種操作。

備援接住失敗，也可能帶來不同結果

模型服務可能因供應商狀態、額度或其他原因失敗。Virtual Models 能保存供應商與模型備援策略，但「換一條路繼續回應」仍需要理解它會換到哪裡。

文件中的 Provider Order 是優先順序，沒有列入的供應商仍可能在後面接手。Provider Only 才是限制名單：名單內都不能服務時，請求就失敗，不再找名單以外的供應商。

這兩者適合回答不同問題。若只想優先使用某一家，排序可能足夠。若資料只能交給特定對象，就不能只靠排序表達限制。把名稱放在第一順位，並不等於排除了其他選項。

模型備援則更進一步：主要模型的供應商都失敗後，可以改用另一個模型。然而，第二個模型能完成回應，不代表它和第一個模型在語意、工具使用或輸出格式上完全相同。

供應商專屬選項也需要重看。某家模型支援的推理強度設定，不會因為放進共用設定，就自動成為另一家的通用功能。底層供應商改變後，相關選項可能不再適用。

官方文件另提醒，把虛擬模型放進單次請求的模型備援陣列時，每一次嘗試分開解析。該虛擬模型的路由與設定只作用在自己的那次嘗試，不會自動一路帶到下一個模型。

這使備援的檢查對象從單一模型，變成一整條可能發生的路徑。若任務要求固定格式或敏感資料限制，每個實際接手的嘗試都需要符合要求，不能只驗證第一順位。

從使用者角度看，備援發生時最好仍交出能接手的結果。如果第二個模型只能回傳一般文字，原本必須解析固定欄位的應用就可能失敗。這不是增加一個模型名稱能補上的能力差距，需要在任務輸出要求中先說清楚。

以客服摘要為例，先測候選設定再換共用入口

假設一個團隊有客服工單摘要功能，主管希望改用另一個模型。以下是導入思路的示例，並非本站已經對 Virtual Models 做過的實測。

團隊可以保留原本供正式應用呼叫的名稱，再建立一個候選名稱，讓兩者處理同一批經過適當整理的工單。這樣比較的單位，就是相同輸入與相同交付要求。

摘要是否更短並不是唯一判斷。若原任務要求保留退款原因、承諾日期與仍待客戶回覆的問題，就應逐一對照這些資訊有沒有留下。否則，文字看起來整齊，下一位客服卻可能接錯工作。

接著再看成本、失敗和工具行為。便宜的單位價格，可能被重試或較長輸出抵銷。主要模型可用時的結果，也不能替備援發生後的結果背書。

追蹤標籤能幫助觀察請求與用量，但文件指出，虛擬模型的標籤會取代單次請求自己送來的標籤。若原來靠請求標籤區分活動或功能，集中設定後需要重新安排追蹤方法。

這不是把所有標籤都搬進同一份清單就能解決。團隊應先決定要觀察共用任務的總用量，還是每個應用各自的用量，避免改完後反而無法回答費用來自哪裡。

當候選設定符合交付要求，才調整正式共用名稱背後的模型，並保留原設定以便回復。集中入口能減少部署次數，但一次影響多個呼叫者，也讓變更前的比較更有必要。

比較紀錄還應保留當時實際指向的模型與設定。只記下共用名稱，過一週再回頭看，名稱可能相同，背後內容卻已經改變。對需要查明某次摘要為何不同的團隊而言，這份變更紀錄能讓問題回到具體版本。

誰能修改，決定一次變更影響多少人

官方將使用與管理權限分開。團隊成員可以在應用中使用虛擬模型。團隊擁有者（Owner）與一般成員（Member）可以建立，而編輯、封存、移除與還原，限建立者或團隊 Owner 執行。

這讓團隊能共用一份設定，也表示建立時應記錄負責人。若多個應用都依賴同一個名稱，某次調整不再只影響提出變更的人，還會影響其他使用者的新請求。

名稱中的 slug，也就是用來辨識這份設定的字串，建立後不能更改，也值得在一開始想清楚。用任務用途命名，比把目前模型版本直接塞進名稱更容易延續。但任務用途太廣，又可能讓不適合共用的工作被綁在一起。

例如，客服摘要與需要嚴格程式格式的資料抽取，即使今天使用同款模型，也未必應該共用同一份設定。兩者對輸出與備援的要求不同，之後調整時就可能互相牽動。

封存也不是單純藏起來。文件指出，封存後使用該名稱的請求會回傳找不到的錯誤，還原後才恢復服務。因此，整理清單前要先確認還有哪些程式或代理在呼叫它。

費用則仍要回到實際使用的模型與服務條件。共用設定可以讓用量更容易被觀察，卻不會自動讓每件工作變便宜。資料限制或供應商範圍縮小，也可能改變可選路徑。

共同入口也不適合用來掩蓋暫時不知道的選擇。如果團隊還沒定義哪些資料能交給哪家供應商，先建一個名稱並不會替這個問題拍板。設定的好處在於執行已經清楚的規則，而不是讓尚未確認的要求看起來已經處理。

另一個實用分界是誰負責回復。當切換後發現某個工具呼叫不相容，應由可管理該設定的人回到原模型，而不是讓每位使用者各自繞過共用入口。否則，集中管理很快又會變回互不一致的個人設定。

如果只有某個呼叫者需要額外選項，也應先確認共用設定是否留空讓它傳入。能否個別調整取決於欄位，而不是取決於誰最後送出請求。把這個分界寫清楚，可以減少團隊日後反覆排查同一種覆蓋問題。

常見問題

Vercel Virtual Models 是新的 AI 模型嗎？

它是可重複使用的模型呼叫設定。底層模型仍負責產生內容，虛擬名稱負責讓呼叫者共用模型選擇與相關規則，不會因此多出一套新權重。

換模型後，所有應用會立刻同步嗎？

官方說明是幾分鐘內套用到新的請求。既有請求、代理是否已重新載入模型目錄，以及新設定是否符合任務要求，仍應分開確認，不能以管理頁儲存成功代替全部完成。

能用同一名稱避免更改每位工程師的設定嗎？

這是官方列出的用途之一。代理一旦使用這個虛擬名稱，後續可由中央調整背後設定。但如果代理尚未使用 AI Gateway 或不接受該名稱，仍要先完成對應的連接安排。

開了零資料保留，就能省略其他資料檢查嗎？

不能把單一供應商路由選項推成完整資料治理。應用本身的記錄、其他工具、憑證類型與資料流向，仍有各自需要確認的範圍。本文也未獨立驗證每個供應商的處理方式。

當多個應用與代理需要共用同一份經驗證設定，Virtual Models 能減少到處修改的負擔。真正值得保留的做法，是讓共同入口、清楚權限與任務比較一起建立，讓下一次換模型仍有可追查的依據。

延伸閱讀

• 2026 Claude Code 做影片 Skills 推薦：HyperFrames、Remotion 到剪輯工具怎麼選？
• Exa 3.0 是什麼？Lite、Auto 價格與基準測試條件，AI 搜尋 API 怎麼選

原始資料來源

• Vercel：AI Gateway Virtual Models
• Vercel Virtual Models 官方文件
• Vercel 官方發布貼文

免費訂閱 AI 郵報，持續掌握 AI 開發工具的新功能與實際使用條件。