模型名不用再写进代码里：Vercel AI Gateway 的虚拟模型来了

一句话先说清楚

Vercel 在 2026 年 10 月 28 日上线了 AI Gateway 的虚拟模型（Virtual Models）。做法很简单：给一个任务起一个固定的模型 ID，比如 vmc/coding-agent，应用和 agent 调用时只写这个 ID，真正用哪个模型、用哪些配置、走哪些兜底，全部在 AI Gateway 里集中改。换模型不再需要改代码、不用重新部署，几分钟内所有调用方自动跟上。

这件事听起来像又一个配置层面的小优化，但它踩中的是一个正在变贵的问题。Vercel 在官方博客里给了一个数字：过去 90 天里，AI Gateway 上线了 125 个来自 10 多个实验室的新模型，平均每周大约 10 个。模型换代的速度已经超过了大多数团队改代码、走发布流程的速度。当“换一个更好的模型”从一次发布降级为一次配置修改，团队的模型策略才有可能跟上模型发布的节奏。

需要先划清两个边界。第一，虚拟模型不是新模型，它只是一个指向模型与配置的别名，本身不产生任何推理能力；真正干活的还是底下那个来自 Anthropic、OpenAI 或其他厂商的模型。第二，它和站内之前报道过的 Vercel AI Gateway 隐身推理模型 Glyph Cluster 不是一回事：那篇讲的是某一个新模型上线且限时免费，本篇讲的是管理所有模型的通用机制。两篇可以互为背景，但不要混为一谈。

虚拟模型到底是什么：一个 ID 背后的一整套配置

用 Vercel 自己的例子最容易讲明白。团队先创建一个虚拟模型：vercel ai-gateway virtual-models create coding-agent，指定底层模型为 anthropic/claude-opus-5.5，配置里写上速度优先与零数据保留（Zero Data Retention）。创建完成后，应用代码里不再写 claude-opus-5.5 这样的厂商模型名，只写 vmc/coding-agent。AI SDK 的调用长这样：streamText 里 model 一栏填 vmc/coding-agent，其余代码一字不用动。

之后某天团队想换模型，执行的命令是：vercel ai-gateway virtual-models edit coding-agent --model openai/gpt-6.1-sol。所有调用 vmc/coding-agent 的应用与 agent 会在几分钟内自动拾取新配置，不需要改代码、不需要重新部署。对于已经接进 AI Gateway 的编码 agent，比如 Claude Code、Codex 等，先用 vercel ai-gateway setup 接好，再在各自的模型选择器或配置里选这个虚拟模型即可。

一个虚拟模型 ID 背后装的不只是模型名。它还包括：推理速度、提示缓存、兜底模型与优先级、零数据保留等合规要求、用于成本归属的自定义上报标签。换句话说，虚拟模型把“某个任务应该用什么模型、以什么方式调用”这个决策，从散落在各处代码里的字符串，收敛成平台上一个可以命名、可以审计、可以回滚的实体。任务变了改任务配置，模型变了改模型指向，两者不再绑在一次代码发布里。

为什么这对 agent 团队尤其重要

官方博客举了两个对比鲜明的任务。工单分类这样的任务一小时可能跑几百次，首要诉求是便宜；法律合同审阅一天可能只跑几次，但需要最强的推理能力。如果所有任务共用同一个模型名，要么是便宜任务烧了冤枉钱，要么是关键任务拿不到应有的能力。虚拟模型的做法是按任务各建一个：vmc/support-triage、vmc/contract-review，各自绑定不同的模型与配置，各自独立演进。

对 agent 团队来说，还有一层更实际的意义：agent 的模型选择往往藏在 agent 框架、提示词模板、各种客户端配置里，改起来牵一发而动全身。虚拟模型把选择权收到了网关层，平台团队可以在不碰 agent 代码的情况下做几件事：统一升级某个任务的模型，统一收紧某个任务的数据保留策略，统一给某个任务加上兜底模型。agent 的行为变了，但 agent 的代码没动——这正是平台团队想要的控制点。

成本归属是另一个被低估的收益。虚拟模型上的标签会替换请求里自带的标签，所以无论各个应用怎么给自己的调用打标签，花费最终都会落到任务名下。Virtual Models 页面还会按任务展示请求量、花费与成功率。对跑着几十个 agent 任务的团队来说，这意味着月底对账时不用再靠猜：哪个任务烧了多少钱、成功率如何，都有任务粒度的账本。

三条硬规则：虚拟模型说了算，请求说了不算

虚拟模型的设计里有三条“平台说了算”的规则，理解它们才能正确使用。第一，虚拟模型上的设置优先于请求里的同类设置。调用方不能通过在请求里写不同的兜底顺序、服务等级来绕过平台配置——平台定好的 failover 配置，所有调用方都得用同一套。

第二，合规要求会被强制执行，哪怕请求明确要求反着来。如果虚拟模型要求零数据保留，或者要求只用不拿请求数据训练的厂商，那么即使某个请求显式把 zeroDataRetention 或 disallowPromptTraining 设为 false，也会被压住。这个设计的目标很明确：合规红线不能靠调用方的自觉来守，必须由平台层硬性兜底。

第三，标签会被替换。请求里自带的标签会被虚拟模型上的标签覆盖，确保成本永远归属到任务。这三条规则合起来传达了一个立场：虚拟模型不是给调用方提供方便的别名，而是给平台团队提供治理手段。方便是结果，治理才是目的。

换模型之前，先建一个候选：官方推荐的切换流程

官方博客给出的切换流程值得单独拿出来，因为它暴露了虚拟模型真正的使用姿势。不要直接把生产流量的虚拟模型指向新模型，而是先建第二个虚拟模型，比如 vmc/coding-agent-candidate，指向新模型，拿它去跑评估；评估通过后再把正式的虚拟模型切过去；如果切换后质量下滑，再把正式模型指回旧模型。

这个流程里有三个值得注意的点。首先，评估是切换的前置条件，不是事后补救——虚拟模型让切换变便宜了，但便宜不等于可以不评估，恰恰因为切换变便宜了，不经评估就切换的诱惑才更大。其次，回滚和切换用的是同一个机制：改一次配置指向，几分钟生效，回滚不需要重新发布旧版本代码。最后，候选模型与正式模型是两个独立实体，评估流量与生产流量的成本归属天然分开，不会在对账时混在一起。

还有一处细节容易踩坑：厂商专属配置在换厂商时会失效。官方博客明确提醒，Anthropic 专属的设置在把虚拟模型指向 OpenAI 模型后就不再适用，换厂商时必须逐项复核配置。这个提醒的潜台词是：虚拟模型抽象的是“任务的模型选择”，而不是“所有厂商行为的通用语义”。跨厂商切换时，配置项的语义差异仍然需要人工过一遍，不能指望平台自动翻译。

虚拟模型没有解决的问题

把模型名抽离出代码是有代价的。第一，配置层本身成了新的关键依赖：网关的配置改错一次，所有调用方会同时中招，而不像过去那样只有改了代码的服务受影响。配置变更同样需要评审、灰度与回滚纪律，只不过评审的对象从代码变成了配置。第二，配置漂移并没有消失，只是换了地方：虚拟模型里的模型、兜底、标签、合规项会随着时间各自演进，久而久之，某个任务的虚拟模型到底指向什么、为什么这样配，可能只有最初创建它的人说得清。定期审计虚拟模型清单，应该成为平台团队的例行工作。

第三，虚拟模型不解决评估问题本身。它让“换模型”变便宜，但没有告诉你“新模型是不是更好”。评估集、回归测试、线上质量监控，仍然要团队自己建。第四，它不改变计价本质：AI Gateway 本身按厂商价收费、不加价、不收平台推理费（包括自带密钥的请求），虚拟模型只是换了一种组织计价的方式，模型本身的成本曲线并不会因为加了一层抽象就变平。

最后还有一个适用边界：虚拟模型覆盖 AI Gateway 上的全部模型类型，包括图像、视频、语音、嵌入与实时模型，也兼容 AI SDK 以及 OpenAI 与 Anthropic 兼容接口。但它终究是 Vercel 生态内的抽象——如果你的 agent 同时跑在多个网关、多个云厂商之间，虚拟模型只能管住 Vercel 这一段，跨平台的模型治理还需要更高一层的约定。

给 vibe 开发者的判断

如果你是一个人或小团队在 vibe 开发，虚拟模型最值得抄走的不是 Vercel 这个具体产品，而是一种习惯：不要把模型名硬编码进业务代码。哪怕你现在不用 AI Gateway，也可以给每个 agent 任务起一个任务级的名字，用环境变量或一份集中配置来承载模型选择。这样做的好处在模型换代时会立刻显现：评估一个新模型时，你只需要改一处配置，而不是全文搜索模型名字符串。

具体到是否采用 Vercel 的虚拟模型，可以按团队规模分三档判断。单人小项目、任务不超过两三个时，环境变量已经够用，引入网关层反而多一套要管的东西；任务开始变多、或者已经在用 AI Gateway 做统一调用与成本统计时，虚拟模型是顺手的一步；到了需要平台团队统一管模型、管合规、管成本归属的阶段，虚拟模型的三条硬规则——设置优先、合规强制、标签替换——才真正开始值钱。

还有一个时间点上的提醒。官方博客提到，过去 90 天有 125 个新模型上线，平均每周 10 个。这个速度意味着“选一个模型然后几年不动”已经不再是现实策略。模型选择正在从一次性决策变成持续运营：定期评估、定期切换、定期回滚。虚拟模型这类工具的价值，不在于它让某一次切换变容易，而在于它让“持续切换”这件事本身变得可管理。

从环境变量到虚拟模型：模型配置的四档演进

虚拟模型在配置演进里处在第几档，理解这一点有助于判断自己现在该不该上。第一档是环境变量：模型名写在 env 里，换模型改变量、重启服务。优点是简单，缺点是改一次影响整个服务，而且没有任务粒度的区分——所有调用同一个变量的任务只能共用一个模型。第二档是集中配置文件：一份配置按任务分键，模型选择从代码里抽出来，但改配置仍然要走发布流程，或者至少要重启、热加载，配置的生效范围与回滚方式都依赖团队自己的实现。

第三档是网关路由：所有调用先经过统一网关，网关负责按规则路由到不同厂商、做重试与兜底。这一档已经解决了“调用入口统一”与“失败转移”，但模型选择本身仍然散落在各处的请求参数里——每个调用方在请求里写自己要的模型，网关只是忠实转发。第四档才是虚拟模型：模型选择本身也被收进网关，成为以任务命名的实体，配置、兜底、合规、成本归属都跟着任务走。演进的方向始终是一致的：把决策点从离业务最近的地方，一步步挪到离平台最近的地方。每挪一步，灵活性就少一点，可治理性就多一点。小团队停在第一档或第二档往往是正确的，因为治理需求还没长出来；硬上第四档，只会多一套需要维护的抽象。

给平台团队的命名与审计规范

如果决定采用虚拟模型，有两件配套工作应该和创建第一个虚拟模型同步做。第一件是命名规范。虚拟模型 ID 应该按任务命名，而不是按模型命名：vmc/coding-agent 是好名字，vmc/claude-opus 是坏名字——后者在换模型那天就会名不副实，逼着你改 ID 或者忍受一个误导性的名字。建议的命名结构是“用途 + 可选的环境后缀”，比如 vmc/support-triage、vmc/contract-review-prod，环境后缀只在确实需要区分生产与评估流量时才加，不要为了整齐而给每个任务都加后缀。

第二件是定期审计。虚拟模型清单应该每季度过一遍：哪些虚拟模型还在被调用，调用量是多少，指向的模型是否还是当前最优，兜底配置是否还合理，标签归属是否还对应真实的团队结构。长期没人调用的虚拟模型要归档或删除，避免清单膨胀成没人敢动的遗产。同时，每次修改虚拟模型都应该留记录：谁改的、改了什么、为什么改、评估结果在哪里。配置变更的审计记录和代码提交记录一样重要，区别只在于它存在网关的控制台里，而不是代码仓库里——如果你的团队只审计代码，那么配置变更就会成为审计盲区。

虚拟模型和功能开关（feature flag）经常被拿来比较，两者确实有相似之处：都是把决策从代码里抽出来，放到运行时可以改的地方。但它们的分工不同：功能开关控制的是“某个功能开不开”，虚拟模型控制的是“某个任务用什么模型、以什么配置跑”。一个常见的组合用法是：功能开关决定新流程是否上线，虚拟模型决定新流程里的 agent 用哪个模型。两者叠加时，变更的组合数会翻倍——功能开了、模型也换了，出了问题很难定位是流程的锅还是模型的锅。所以同时改动两者时，建议分开发布：先开功能、模型不动，观察一阵；再换模型、功能不动，对比效果。一次只动一个变量，是所有线上变更都适用的老规矩，在模型切换这件事上尤其值得遵守，因为模型行为的变化往往比代码变化更难察觉、更难回滚到“上一个行为”。

划界与来源说明

本文的一手来源是 Vercel 官方博客《Introducing Virtual Models on AI Gateway》与官方更新日志《Virtual models now available on AI Gateway》，两篇全文均经 browser.open 亲核。发布日期取 2026 年 10 月 28 日：第三方部署日志 deployedbyai 标注该发布“发表于 2026 年 10 月 28 日星期三”，独立报道 techseen 的故事线亦记录首次打开时间为 10 月 28 日 16:05（太平洋时间）；Vercel 页面本身在文本抓取中不渲染日期，正文日期表述以第三方同日记录交叉印证，主代理发布前可再核对一次页面元数据。文中所有功能描述、命令、示例模型名与 125 个模型、10 余实验室、90 天等数字均以 Vercel 官方博客为准；“几分钟内生效”为官方博客原文表述。站内旧文 Vercel AI Gateway Glyph Cluster 篇讲的是单个隐身推理模型上线，本篇讲的是管理全部模型的通用机制，已划界。