先给结论：Vercel AI Gateway 开放权重模型调用占比上升到 62%，这并不是某个宣传话术，而是开发者实际请求流量里一个很直观的结构变化。简单说，现在通过 AI Gateway 转发出去的模型请求，超过六成最终落在开放权重模型上，而不是封闭的商用 API 模型。这个数字对正在做模型选型、网关搭建和成本控制的人来说，比单纯看模型榜单更有参考价值。
我建议先理解一件事：开放权重模型并不等于“免费模型”，它只是把模型权重公开，你可以自己部署、自己托管、自己控制调用链路。62% 这个占比说明，越来越多团队已经不只是拿开源模型做实验，而是把它放进了生产链路的关键路径。下面按实际落地顺序拆开讲，包括为什么会有这种变化、网关里怎么配置、怎么理解统计指标，以及容易踩的坑。
1. 62% 这个数字，先要搞懂它指的是哪部分流量
1.1 开放权重模型一直在静悄悄吃掉调用份额
过去两年，很多团队处理 AI 需求的第一反应是直接找头部商用 API，因为接入简单、效果稳定、不需要关心部署细节。但最近趋势发生了变化：那些权重可下载、可私有部署的模型，比如 Llama 系列、Mistral 系列、Qwen 系列等，开始大量出现在生产环境里。
Vercel AI Gateway 的 62% 占比可以看作一个行业切片。它说明在通过网关统一转发的外部模型调用里，开放权重模型已经成了主流。这个趋势不是突然发生的。背后的推动因素很直接：开放权重的性能在快速接近商用模型，同时使用成本、数据隐私、定制空间这些维度都更有优势。很多团队开始把简单任务、高频任务、数据敏感任务迁移到开放权重模型，只把最复杂、最需要强能力的任务留给商用闭源模型。
1.2 AI Gateway 在其中扮演什么角色
AI Gateway 不是一个模型，而是一个代理层。它的作用是让业务代码不直接连接某个具体模型服务商，而是统一通过网关转发。你可以把网关理解成模型的“接入交换机”：业务侧只发一个请求，网关负责决定这个请求应该走到哪个模型，哪个提供方，失败以后怎么办。
实用价值体现在几个方面：
- 模型切换不需要改业务代码
- 可以统一配置超时、重试、限流和缓存
- 可以集中查看调用日志和成本消耗
- 可以在多个模型之间做 fallback
所以 62% 这个数字不是某个模型的榜单，而是网关里真实请求流量的分布。它更接近“真实生产环境里大家在用什么”的统计。如果你想复现类似效果，并不是必须用 Vercel 自身的平台，用其他自建网关也能达到同样目的。重点在于，你的网关设计里，是否把开放权重模型的位置放到了足够高。
这里我多说一句：不要因为看到 62% 就马上把所有流量切到开放权重模型。这个数字是宏观趋势，具体到你自己的项目，还是要按任务类型、延迟要求、数据隐私和团队运维能力分开选。
2. 什么场景下应该认真对待开放权重模型的接入
2.1 按成本敏感度划分
如果你的项目每天调用量在几千次以下，商用 API 的成本差异可能不明显。但一旦到日均几万、几十万次，单价差距就会被放大。开放权重模型如果是自行部署，通常成本结构主要是 GPU 资源和运维成本，单次调用的边际成本会低很多。
我一般会建议先算一笔账：
- 商用 API 单次调用价格乘以预估日调用量
- 自建开放权重模型的 GPU 月租成本、带宽成本、存储成本
- 以及人工运维成本
前两项如果差距超过 30% 到 50%，就值得认真评估迁移。但要注意，自建不等于一定便宜。如果调用量太低，空闲 GPU 反而是浪费。
2.2 按数据要求划分
数据隐私是另一个关键判断维度。如果业务数据属于用户隐私、企业机密或者合规敏感数据，把它们发送给外部 API 本身就是一个风险点。开放权重模型配合私有化部署，可以把数据完全留在自己的环境里。
这个场景很适合接 AI Gateway 的私有端点。网关仍然做统一路由，但请求不会离开你的安全域。实际项目中，我看到不少团队是因为合规要求才认真开始研究开放权重模型的。这类场景里的 62% 不是舒适区，而是刚需。
2.3 按部署形态划分
还要看你的应用部署在哪里。如果你的业务已经跑在 Serverless 平台上，那接入外部 API 模型是最顺手的。如果想用开放权重模型，就要解决一个核心问题：模型放在哪里，怎么提供稳定推理服务。
常见方案有三种：
- 使用带 GPU 的容器服务或函数计算
- 使用模型托管服务，把开放权重模型部署成私有 API
- 在本地或私有云启动推理服务，再通过网关接入
这三种方式都可以配合 AI Gateway 使用。区别只在模型服务层，网关层不需要大改。所以架构上更建议先把网关搭好，再把模型源从商用 API 切换成自建开放权重模型，业务侧几乎没有感知。
3. AI Gateway 的配置核心：供应商路由与模型映射
3.1 第一件事是建路由，而不是写大量业务代码
很多新手第一次接触网关时，容易按业务系统的方式去理解，想给每种调用写一套代码。这个方向不对。AI Gateway 的核心工作方式是路由规则，你只需要声明式地配置一个模型列表和 fallback 顺序。
我习惯先把最稳定的模型放在第一路由，把备用模型放在后面。比如：
{ "provider": "gateway", "model": "primary-model", "routes": [ { "name": "self-hosted-open-weights", "type": "openai-compatible", "base_url": "http://192.168.1.10:8080/v1", "model": "qwen2.5-14b", "weight": 1 }, { "name": "fallback-commercial", "type": "openai-compatible", "base_url": "https://api.xxx.com/v1", "model": "gpt-xxx", "weight": 0 } ], "timeout_seconds": 30, "retries": 2 }这里有一个很关键的设计：第一个路由是自建的开放权重模型，第二个才是商用 API 作为兜底。这个顺序不是随便写的。它代表一种策略：正常情况下优先走成本低、可控性强的模型，只有它在超时或报错时才切到备用模型。
3.2 提供方配置的坑：模型名、端点与密钥
配置路由时最容易出问题的，不是网关本身，而是模型提供方的参数。常见的坑有三个：
- 模型名不对。不同提供方对同一个模型的命名可能完全不同，比如本地推理服务里叫
qwen2.5:14b，在某个托管平台里可能叫qwen2.5-14b-instruct。 - 端点路径不一致。有的服务是
/v1/chat/completions，有的只支持/v1/completions，还有的用/generate。 - 密钥权限不对。即使环境变量配好了，也要确认网关运行环境能读到那个密钥，尤其是部署到 Serverless 环境时，密钥可能在构建阶段没有注入。
我建议先把每个模型提供方单独写一个最小的测试脚本，确认可以直接调用成功之后，再把它接进网关。听起来是额外一步，但能减少大量排错时间。
3.3 回退链：当开放权重模型不可用时的兜底逻辑
开放权重模型自建服务的短板是稳定性。GPU 节点重启、显存被打满、模型加载时间过长，这些都会造成请求失败。所以回退链不能省。
配置回退链时，我通常保留一个商用 API 模型作为最终兜底，并设置以下参数：
fallback: enabled: true max_attempts: 3 retry_delay_seconds: 1 on_status_codes: [429, 500, 502, 503, 504]这里只对 429 限流和 5xx 服务端错误做重试。如果底层模型因为输入内容触发了内容审核，返回 400，重试没有意义。不要把 4xx 错误也加进重试列表，否则会出现很多无效请求。
4. 让网关真正产生 62% 这类统计：观测优先于调参
4.1 用量分布应该看哪些指标
如果你也希望知道你用的 AI 网关流量中开放权重的占比，就需要先确保日志和统计是准确的。核心指标有三个：
- 请求总数
- 按模型分组的请求数
- 按提供方分组的请求数
这三个指标加在一起，才能计算出类似 62% 的比例。如果只有日志没有分组，或者只记录成功请求不记录失败请求，统计口径就会有偏差。
在配置网关时，我建议把请求的model、provider、status、latency_ms、cost五个字段都打进结构化日志。这样后续不管是看占比、看成本还是看性能，都有原始数据可查。
4.2 成本与延迟的交叉验证
占比高只是第一层信息。更值得关注的是，这 62% 的流量带来了多少成本，平均延迟是多少。我见过一些团队，开放权重流量占比很高，但延迟不稳定，最终用户体验反而变差。
所以不能只看占比，还要交叉看指标：
| 指标 | 判断标准 |
|---|---|
| 开放权重模型请求占比 | 是否和预期策略一致 |
| 平均延迟与 P95 延迟 | 是否在可接受范围内 |
| 单次请求平均成本 | 是否比纯商用 API 方案低 |
| 失败率和重试率 | 是否出现长时间不可用 |
如果占比很高，但失败率也高，说明路由策略需要调整。比如可以考虑给自建模型增加自动扩容，或者在超时参数上做更精细的配置。
4.3 基于统计做容量和预算调整
统计的价值不只在于汇报，更在于指导资源调整。当你看到开放权重模型占比持续上升，就可以提前准备 GPU 资源，而不是等模型服务被打爆后再扩容。
我一般会按月维度观察趋势，重点关注两个拐点：
- 开放权重模型占比突然上升，但成本没有明显下降
- 占比持平，但失败率开始升高
两个拐点都说明容量或配置需要调整。前一个可能是路由配置错误，大量请求被错误路由到高成本模型；后一个则更可能是自建推理服务承载能力到了瓶颈。
5. 本地落地时的环境检查与参数边界
5.1 硬件与部署方式
如果你打算在网关后面接入自建的开放权重模型，首先要确认推理服务部署在哪里。这个决定会直接影响后续所有性能指标。
不同规模模型的资源需求差别很大。7B 到 14B 级别的模型，单卡 A100 或者多卡 3090/4090 基本可以满足一般在线推理需求。70B 以上就需要多卡并行，对显存和带宽要求更高。如果只是个人学习或低并发场景，也可以用量化版本在消费级显卡上跑，但要牺牲一部分输出质量。
如果你的环境条件不明确，最稳妥的方式是先跑一个最小可用模型验证结论，再逐步放大。不要一上来就部署最大参数模型，否则后面排查问题时，资源和参数混合在一起，很难定位。
5.2 并发、超时与重试
网关的参数配置里，最影响体验的是并发和超时。
自建开放权重模型服务通常有并发上限。超过上限后，请求会排队或者直接报错。网关上如果不能设置合理的并发控制，大量请求同时涌向推理服务，反而会让整体吞吐下降。
我个人会先按以下顺序调整：
- 把超时时间设短一点，比如 30 秒
- 把重试次数设为 2 到 3 次
- 观察失败率
- 如果失败率高，优先扩容或优化推理服务，而不是继续加大重试
这里要特别提醒：重试次数不是越多越好。如果推理服务已经过载，重试只会加重负载。正确的做法是，在网关层设置熔断或限流，而不是让请求无限重试。
5.3 免费层、限额与升级策略
如果你使用的是托管网关服务，比如 Vercel AI Gateway，免费层通常有请求量和次数限制。即使你把开放权重模型接入进去，流量仍然会经过平台转发，平台层面的额度限制依旧存在。
在生产环境接入前，建议先确认三件事：
- 免费层每月可用请求次数
- 超出免费额度后的计费规则
- 是否支持自定义域名和内部网络访问
确认之后，再决定是直接用托管服务，还是自建网关。如果只是中小型项目，托管网关更省心；如果日调用量很大、对延迟和隐私要求高，自建网关会更可控。
6. 常见问题排查链路
6.1 报错时，先看网关日志，而不是模型端
很多接入方在发现问题时，第一反应是去看模型服务日志。但如果你想排查的是网关里的调用链路问题，最有效的路径是先看网关日志。
网关日志里通常包含：
- 请求路由到了哪个 provider
- 模型实际返回的状态码
- 重试发生了几次
- 最终耗时是多少
比如一个请求报 404，很可能是网关里的模型映射名写错了，而不是模型服务本身挂了。这时候如果只去看模型服务，根本发现不了问题。
6.2 超时与速率限制
开放权重模型部署初期，最常见的问题是超时。原因往往是模型首次加载慢，或者显存不足导致推理时间长。
遇到超时，建议先看两份数据：网关的超时设置和模型服务的响应时间。如果模型服务本身就需要 50 秒才能返回，而网关只允许 30 秒，问题就出在参数不匹配。这时候不要盲目把网关超时调到 120 秒，应该先优化推理服务的响应时间，再回调超时。
限流方面，要区分两种限流：
- 模型服务自身的并发限制
- 网关对每个模型设置的最大并发
两层都要检查。我见过一种情况：网关显示 429，很多人以为是平台限流，实际是自建模型服务因为并发过高返回了 429，被网关原样透传回来。
6.3 模型名不要硬编码
网关配置完成后，最容易被忽视的问题是模型名硬编码在业务代码里。这会让网关的灵活路由失去意义。
正确做法是业务侧只使用一个逻辑模型名，比如main-model，真正的底层模型由网关映射。这样你调整开放权重的具体型号时，不需要改业务代码，只要改网关配置。
还有一点：不同环境的模型映射可能不同。开发环境用小型开放权重模型，生产环境用更强参数模型，或者切换不同提供方。模型名硬编码会让这套灵活性完全失效。
6.4 统计口径与日志保留
如果之后你也要输出类似“开放权重占比 62%”的统计，要留意统计口径。常见口径有两种：
- 按请求次数计算
- 按 token 数量计算
同一批流量，两种口径算出来的占比可能差别很大。因为开放权重模型通常 token 单价低，业务方可能会在上面跑更长文本，导致 token 占比高于请求占比。在汇报和对比时，最好明确标注口径。
日志保留时间也很重要。如果只保留最近一天日志，月初和月末的对比就做不出来。建议至少保留 30 天结构化日志。如果成本允许，保留 90 天更好。这个周期足以覆盖一次模型调整前后的对比。
我个人的立场是，开放权重模型占比上升是长期趋势，62% 这个数字以后很可能会更高。但对具体团队来说，更重要的不是追赶这个比例，而是判断自己的业务是否适合把更多流量切到开放权重模型上。如果适合，优先把网关路由、观测指标、成本统计和失败重试配置好；如果不适合，也不需要因为一个行业数据而强迫自己迁移。把网关这一层搭稳，后续无论哪个模型表现更好，切换成本都低。这比单纯追求某一个占比数字更有实际价值。
