AI Gateway推出虚拟模型：集中管理模型配置，无需重新部署

AI Gateway 上线了「虚拟模型」（Virtual Models）功能。简单说，它把「用哪个模型、带什么参数」这件事从应用代码里抽出来，变成一份保存在网关侧的配置。应用和 Agent 只需调用一个自定义模型 ID，比如 vmc/coding-agent，背后的模型和设置可以在 AI Gateway 里集中修改，不必重新部署应用或重新配置 Agent。

虚拟模型解决的是什么问题

模型选型和参数配置长期散落在各个应用、各个 Agent 的代码或配置文件里。换一个模型、调一次推理强度，往往意味着改代码、走一遍发布流程。虚拟模型把这个映射关系上移一层：调用方只认一个自定的 slug，真实模型和参数由网关侧决定。

这对多应用、多 Agent 共用同一套模型策略的团队尤其有意义——策略变更从「逐个改代码」变成「改一处配置」。

AI Gateway 是位于应用与模型供应商之间的统一接入层：应用只需面向网关的一套 API 与凭证，由网关负责转发到 Anthropic、OpenAI、Google 等不同供应商，并统一处理鉴权、用量计量、配额、可观测性和故障转移。正因为它处在调用链的中间位置，才有能力在不改动调用方代码的前提下替换真实模型、调整参数或改变路由策略。虚拟模型本质上就是复用这一中间层的位置优势，把「模型标识」也变成网关可以解释和改写的信息，而不是直接透传给上游供应商的字符串。

三个典型使用场景

配置编程 Agent

官方给出的场景之一是编码 Agent。很多 Agent 本身不暴露推理强度（reasoning effort）、快速模式（fast mode）、提示缓存（prompt caching）等选项，通过虚拟模型可以强制注入这些设置，不必等 Agent 端支持。

控制路由与合规

虚拟模型可以指定使用哪些供应商、配置回退模型（fallback），并强制执行零数据保留（Zero Data Retention）等要求。合规策略因此可以落在网关层统一执行，而不是依赖每个调用方自觉遵守。

零数据保留（Zero Data Retention，ZDR） 是指模型供应商承诺不持久化保存请求与响应内容，仅在内存中完成推理后即丢弃，通常用于满足对数据留存有严格限制的行业合规或内部安全要求。不同供应商对 ZDR 的支持范围与开启方式并不一致，有的通过账号级协议约定，有的通过请求头或参数按次生效。把 ZDR 声明放在虚拟模型配置里，意味着凡是经由该 slug 发出的请求都会自动携带相应要求，调用方即便遗漏也不会破坏合规基线；同时也可配合回退模型设置，让不支持 ZDR 的供应商在合规场景下被排除在路由之外。

归属花费

每个使用虚拟模型的请求都可以附加自定义报告标签，便于把花费归到具体项目或团队。

推理强度（reasoning effort） 是新一代推理模型提供的可控参数，用低、中、高等档位调节模型在给出答案前进行内部思考的深度：档位越高，通常质量越好但延迟与 token 消耗也越大。快速模式（fast mode） 一般指优先选择低延迟的模型变体或推理路径，牺牲部分质量换取响应速度。提示缓存（prompt caching） 则允许供应商复用此前已处理的相同前缀内容（如长系统提示、代码库上下文），命中缓存的部分按更低价格计费并显著缩短首 token 延迟，对反复携带同一大段上下文的编码 Agent 收益尤为明显。这三类参数往往只在部分 SDK 或供应商接口中暴露，虚拟模型提供了绕过调用方限制统一注入的途径。

如何创建和使用

在 Virtual Models 页面点击 Create Virtual Model，填入 slug、选择底层模型、配置所需设置后保存即可。也可以通过 Vercel CLI 创建，例如：

vercel ai-gateway virtual-models create coding-agent \
  --model anthropic/claude-opus-5.5 \
  --config '{"speed":"fast","zeroDataRetention":true}'

这条命令创建了一个可复用的编码 Agent 配置，带快速模式和零数据保留。

使用方式很直接：在 AI SDK 或兼容 API 请求里，把原来的供应商模型 ID 换成 vmc/<slug>，例如 vmc/coding-agent。如果用的是编码 Agent，先通过 vercel ai-gateway setup 连接 AI Gateway，再在 Agent 的模型选择器或配置里选中虚拟模型。

官方说明虚拟模型适用于 AI Gateway 上的所有模型类型。

AI SDK 是面向 JavaScript/TypeScript 的模型调用抽象库，用统一的接口描述不同供应商的模型，并支持流式输出、工具调用、结构化输出等能力。在 AI SDK 中，模型通常以一个字符串 ID 或 provider 实例的形式传入；vmc/<slug> 这类 ID 能够被直接识别，前提是请求经由已连接的 AI Gateway 发出，因此需要先完成网关的鉴权与项目绑定。对编码 Agent 而言，vercel ai-gateway setup 的作用正是写入本地凭证与网关地址，让 Agent 后续的模型选择器能够列出并解析虚拟模型，从而在不修改 Agent 源码的情况下切换底层模型。

一个值得留意的设计取向

把模型配置做成网关侧的「间接层」，本质上是把模型调用当成可集中治理的基础设施来对待。代价是多了一跳间接寻址，收益是配置变更与代码发布解耦、合规策略可以强制执行、花费归属更清晰。对已经在用 AI Gateway 的团队，这是低成本的增量能力；对尚在评估的团队，虚拟模型的价值取决于你是否真的存在「多处调用、需要统一策略」的场景——如果只是单一应用调用单一模型，这层抽象带来的收益有限。

更多示例可参考官方发布文章，细节见虚拟模型文档。