这次有一个值得留意的信号Vercel AI Gateway 上的开放权重模型调用占比已经升到 62%。这不是某个模型榜单的评测分数而是来自真实业务流量入口的开发者选型结果。AI Gateway 位于应用与模型之间负责分发请求、缓存、限流、记录用量和做故障回退所以它内部的流量结构基本就是工程师在实际项目里用脚投票的结果。62% 的含义需要先看清楚在通过 Vercel AI Gateway 转发的模型请求里权重公开、可以自行下载和部署的开放权重模型已经超过了闭源 API 模型成为主流。对做 AI 应用的技术团队来说这是一个值得跟进的变化因为它直接影响模型接入方式、成本控制方式、数据隐私边界和部署架构的选型。这篇文章会把几件事讲清楚Vercel AI Gateway 在 AI 应用架构里到底承担什么角色开放权重模型占比上升背后有哪些技术驱动力团队如何把开放权重模型接入网关做统一调度自托管开放权重模型时要观察哪些硬件和稳定性指标不同方案之间的选型边界在哪里以及生产落地时常见的坑和排查方法。无论你在做 RAG 应用、Agent 应用、内容生成工具还是企业知识库这篇文章都能提供一套可执行的判断框架。1. 核心信息速览先把这次事件的关键信息整理成一张表方便快速判断话题的定位和影响范围。信息项说明事件来源Vercel AI Gateway 流量数据核心数据开放权重模型调用占比升至 62%观察对象通过 AI Gateway 转发的模型 API 请求数据含义开放权重模型的实际业务调用量超过闭源 API 模型对比对象闭源模型 API如各厂商独占模型服务涉及模型类型Llama、Qwen、Mistral、DeepSeek、Phi、Gemma 等开放权重模型家族涉及接入方式托管推理服务接入、自托管推理服务接入、统一网关转发重点关注人群AI 应用开发者、平台架构师、算法工程师、运维工程师主要受益能力统一接口、缓存、降级回退、成本追踪、多模型路由补充说明一点这里讨论的“开放权重”和通常说的“开源模型”不完全是一回事。开放权重指模型权重文件可以公开获取、下载和部署但模型的许可证可能附带限制比如禁止商用、要求保留版权声明、超过一定规模需要单独授权。所以后面讲到选型时许可证检查会是很重要的一环。2. Vercel AI Gateway 在 AI 应用架构中的位置2.1 AI Gateway 解决什么问题AI 应用开发早期最常见的集成方式是直接调用某个模型服务商提供的 SDK。这种方式的优点是链路短缺点是问题很多每家服务商的接口格式不同切换模型时要改代码。单个服务商故障时应用没有自动容错能力。请求日志和费用分散在各个控制台难以统一审计。加缓存、限流、重试、密钥管理全都要自己写。多模型对比测试时每接一个模型就要改一遍配置。AI Gateway 就是解决这个问题的中间层。它把模型调用统一成一个标准接口后面再对接不同模型服务商。对上一层应用来说只需要认识网关一个接口对下层模型来说网关负责把请求翻译成各家能识别的格式。Vercel AI Gateway 是其中比较有代表性的一类服务从公开产品定位看它提供了统一接入、请求缓存、模型故障回退、速率限制、日志与成本追踪等能力。对 Next.js 生态的开发者来说它可以和 Vercel Functions、Vercel KV、Vercel Postgres 等组件一起构成完整的 AI 应用基础设施。2.2 为什么网关流量能反映模型选型趋势模型选择最终发生在应用代码里但应用大多通过网关转发请求所以网关的流量数据能相当客观地反映真实生产环境里的模型使用情况。模型评测榜单反映的是“某个任务上谁更强”而网关流量反映的是“真实业务里谁在被调用”。后者更贴近落地现状。Vercel AI Gateway 的流量结构里开放权重模型从次要位置提升到 62% 的调用占比意味着开发者在生产环境中的模型选型偏好已经发生结构性变化。这种变化不是某一篇论文或某一次发布会推动的而是成本、可控性、数据合规、模型能力等多个因素共同作用的结果。2.3 网关层还能提供哪些附加价值除了路由请求网关还可以做几件对生产特别有价值的事统一鉴权把不同服务商的 API Key 统一管理避免密钥散落在前端代码里。格式标准化把不同模型服务的请求、响应格式转成统一结构减少业务代码适配成本。灰度切换新模型先在少量流量上验证再逐步放大比例。细粒度限流按用户、团队、应用维度分别设置调用额度。审计日志记录每一次请求的模型、Tokens、耗时、费用和响应状态。多活容灾某个模型服务不可用时自动把请求切换到备用模型。这些能力叠加在一起让 AI Gateway 成为 AI 应用架构里很关键的一层。即使团队现在只用一个模型引入网关之后后续增加模型、替换模型、做成本治理都会方便很多。3. 开放权重模型占比为什么上升3.1 模型能力与闭源 API 的差距在缩小过去很长一段时间开放权重模型给人的印象是可以部署但效果和闭源 API 有明显差距。这种差距体现在复杂指令跟随、长文本推理稳定性、代码生成准确率等维度上。但近两代的开放权重模型在很多常见任务上的表现已经逼近同代闭源模型某些特定任务甚至反超。对大多数应用场景来说模型能力已经不再是选择闭源 API 的充分理由。当能力差距缩小到一定程度成本和可控性就会成为主导因素。这就是开放权重模型占比上升的技术前提。3.2 成本结构更符合规模化诉求闭源 API 的成本是“按量计费”随着调用量线性增长。用户量大了以后每月的模型费用会成为一笔不小的开支。开放权重模型则不同权重获取成本为 0主要成本是部署和运维推理服务的机器费用。如果你的流量足够稳定自托管或者使用按实例计费的托管推理服务长期成本通常会低于按 Tokens 计费的闭源 API。更关键的是开放权重模型可以私有化部署到自己的 VPC 或内网这在大模型应用走向企业服务时是最现实的约束之一。3.3 数据隐私和合规需求推动本地部署很多企业应用涉及内部文档、用户隐私、金融数据或医疗数据不允许把原始内容直接发送给第三方模型服务。即使服务商承诺“数据不用于训练”合规团队仍然会提出质疑。开放权重模型配合私有化部署可以让数据在本地完成推理不离开企业的网络边界。这一条在金融、政务、医疗、法务等对数据敏感度要求高的行业里往往是决定性的。从 Vercel AI Gateway 的流量结构变化看这类需求已经不只是大型企业的诉求越来越多的中小型团队也开始把数据控制权放在模型选型的第一优先级。3.4 避免被单一模型供应商锁定只依赖一家闭源模型 API 存在三类风险价格调整、能力限制、服务中断。由于模型服务商的定价策略不在你的控制范围内一旦涨价或调整配额应用成本就会受到直接影响。如果模型服务商的服务出现稳定性问题整个应用可能跟着不可用。开放权重模型目录下可以从多个供应商或者自建服务里选也可以随时切换。网关层让这种切换成本进一步降低业务代码不变只需要在网关配置里更新模型路由。3.5 网关降低了多模型接入的工程成本即使开放权重模型有成本和合规优势如果接入成本很高团队仍然不愿意迁移。AI Gateway 在这里起到了关键的工程缓冲作用统一接口 配置化路由让团队可以在几分钟内把同一个应用从闭源 API 切到开放权重模型托管服务上需要改的只是配置不是业务代码。这一点很重要。开放权重模型占比上升并不意味着闭源 API 会被淘汰而是“多模型共存”成了常态。网关让这种共存变得可维护。4. 开放权重模型接入 AI Gateway 的典型方案开放权重模型接入网关常见有两种路径使用第三方托管推理服务或者自己部署推理服务。两种路径各有优劣需要结合团队的情况选择。4.1 方案一通过托管推理服务接入托管推理服务的定位是免去自建 GPU 集群的运维成本模型已经部署好你只需要传入密钥按调用量或实例时长付费。对没有专业运维团队的中小型团队来说这是成本最低的接入方式。这类服务的特点通常提供 OpenAI 兼容的接口格式接入网关的改造量小。支持多种开放权重模型可以按需切换。不需要自己准备 GPU 服务器。按量付费或按实例付费适合流量波动较大的场景。服务稳定性由服务商负责但需要关注服务商自身的可用性。接入网关后配置模型供应商时只需要把托管服务的 Base URL 和 API Key 填到网关配置里然后为这个供应商绑定一个模型标识。后续通过网关发请求时网关会通过这个模型标识找到对应的供应商配置。4.2 方案二自托管推理服务接入自托管适合对数据隐私、模型版本、推理性能有更强控制要求的团队。部署开放权重模型的主流方式之一是使用推理框架加载模型权重暴露一个兼容 OpenAI 的 HTTP 接口然后把这个接口注册到网关的模型供应商列表里。自托管的基本链路如下准备 GPU 服务器或 GPU 云实例。选择推理框架如 vLLM、SGLang、Ollama、llama.cpp、TensorRT-LLM。下载对应模型的开放权重文件加载到推理框架。启动推理服务确认本地接口可访问。把本地推理服务作为网关的模型供应商之一接入。自托管的优势是数据完全留在内部网络推理成本只和硬件相关模型版本可以长期固定。代价是需要承担运维工作比如版本升级、性能调优、GPU 故障处理、并发扩容。团队至少需要有人能看懂推理日志、关注显存占用和服务吞吐。4.3 统一 API 格式与兼容层无论选择哪种接入方式最后一步都是“让网关能认识这个模型服务”。目前多数推理框架和托管服务都支持 OpenAI 兼容接口所以兼容层的工作量通常不大把网关作为统一入口网关与具体模型服务之间按 OpenAI 兼容协议通信即可。这里给出一个概念性的网关配置示例实际字段名需要按你所用的网关平台文档调整。重点是理解结构模型逻辑名、供应商 Base URL、密钥、能力参数。# 概念性配置示例实际字段需要按网关平台文档调整 models: - name: llama-3-70b-prod provider: together base_url: https://api.together.xyz/v1 api_key_env: TOGETHER_API_KEY capabilities: chat: true max_context_length: 8192 - name: qwen2.5-72b-selfhost provider: vllm base_url: http://10.0.0.12:8000/v1 api_key_env: INTERNAL_GATEWAY_KEY capabilities: chat: true max_context_length: 16384在这个示例里应用代码只需要调用一个统一的模型名网关负责把请求路由到对应的供应商。如果后续要切换供应商改动只发生在网关配置里业务代码不需要变。5. 从网关视角看流量路由、缓存与回退5.1 多模型路由策略网关联到多个模型服务之后路由策略是关键。常见路由方式有三种固定路由请求都发给同一个模型适合稳定生产的环境。权重路由按比例把流量分发给不同模型适合灰度上线和 A/B 对比。条件路由按请求特征选择模型比如短文本走低成本模型、长文本走更强模型。网关的配置里一般可以指定一个模型对应多个供应商并为每个供应商设置权重。这样在不改业务代码的前提下可以让新模型先承担 5% 的流量观察效果后再逐步上调。5.2 缓存降低重复请求的成本和延迟网关缓存是成本治理最直接的杠杆。AI 应用里有很多“相同或相似请求”的场景比如同一个知识库问题被频繁询问、同一段提示词被多次实验、多个用户问同一份文档。如果不加缓存这些重复请求每次都会产生模型费用。网关缓存的核心逻辑是以请求内容、提示词、模型名、参数组合作为缓存键。命中缓存时直接返回上次结果不再调用模型。未命中时调用模型并把结果写入缓存。可以设置缓存过期时间避免结果长期过期。需要注意缓存不可盲目开启。涉及用户个性化数据、动态时间信息、实时状态的请求不适合缓存。适合缓存的场景包括固定知识库问答、文档摘要、稳定的分类任务、内容改写等。5.3 故障回退可用性兜底单个模型服务商出现故障时网关的 fallback 机制可以在业务无感知的情况下把请求切换到备用模型。回退策略一般有两种同质回退主模型挂了切到另一个能力接近的模型保证任务效果差异不大。低成本回退主模型超时或限流切到更轻量、更快的模型先把用户体验保住。配置回退时需要注意备用模型的能力、上下文长度、返回格式必须兼容主模型否则下游解析可能会失败。比如主模型支持工具调用备用模型不支持那回退后就可能直接报错。5.4 用量与成本追踪网关的另一个价值是统一记录费用。不同供应商的计费方式不同有的按 TPM/RPM 计费有的按 Tokens 计费有的按实例时长计费。网关注册多个供应商后可以通过网关日志统一统计每次请求的模型、输入 Tokens、输出 Tokens、响应时间、状态码和预估费用。这样就能回答几个常见问题哪个模型贡献了最多的调用量哪个业务线消耗了多少 Tokens缓存命中率是多少缓存省了多少钱哪个供应商的失败率最高成本增长主要来自哪些应用没有网关时这些数据分散在各家控制台里很难合并。有了网关成本分析就变成一次 SQL 或一张报表的事。6. 自托管开放权重模型的硬件与部署观察在这部分之前先说明一点具体的显存占用和推理速度和模型参数量、量化精度、上下文长度、并发数、推理框架直接相关不能用一个数字笼统概括。实际操作时要按自己的模型版本和压力测试数据来评估。下面给的是通用的观察方法和估算思路不是固定结论。6.1 推理框架怎么选不同的推理框架侧重点不同按场景选框架特点适合场景vLLM高吞吐、支持 PagedAttention适合服务化部署高并发生产环境SGLang结构化生成更高效适配复杂 Agent 场景Agent 应用、结构化输出Ollama安装简单适合本地快速实验小团队实验、个人开发、端侧测试llama.cppCPU 和消费级显卡优化好量化支持丰富资源受限环境、边缘部署TensorRT-LLM针对 NVIDIA GPU 深度优化GPU 资源固定的生产集群建议第一款自托管模型用来做 PoC 时先用 Ollama 或 vLLM 跑通全链路确认业务效果符合预期后再决定是否需要换成更高吞吐的框架。6.2 显存与内存估算注意事项推理时的显存占用主要由这几个因素决定模型权重体积、KV Cache 大小、批处理大小、输入输出长度、推理框架自身的显存开销。估算权重大小的通用参考FP16/BF16 精度下权重显存约等于参数量乘以 2 字节。INT8 量化后约等于参数量乘以 1 字节。INT4 量化后约等于参数量乘以 0.5 字节。实际加载时还要加 KV Cache长上下文场景下 KV Cache 的显存开销可能超过权重本身。所以更稳妥的做法是部署后在无请求状态下看一次空闲显存再打一个基准请求观察显存峰值变化。这里给一个可以用 nvidia-smi 观察显存占用示例# 每 2 秒刷新一次 GPU 使用情况 watch -n 2 nvidia-smi部署服务时还可以通过推理框架自带的 metrics 接口观察吞吐和延迟比如 vLLM 默认会暴露 /metrics 接口可以用 Prometheus 采集。6.3 CPU 推理和 GPU 推理的取舍如果只是验证功能可以用 CPU 跑一个量化过的中小规模模型跑通之后不着急上 GPU。但生产环境一般不建议 CPU 推理原因是 CPU 推理的 Token 生成速度远低于 GPU用户体感差异明显并发能力也很有限。CPU 推理更合适的场景是后台离线任务、文本分类、短文本生成、边缘设备上的轻量模型以及预算有限时的功能验证。如果团队有条件优先用 GPU 实例做推理服务化。GPU 型号选择不只看显存还要考虑算力、显存带宽和会不会被多个并发任务打满。6.4 并发与吞吐观察方式生产环境里模型服务的吞吐通常用以下几个指标衡量Tokens/s每秒生成的 Token 数量。请求并发数同时处理的请求数量。首 Token 延迟从发送请求到收到第一个 Token 的时间。总请求延迟从发送请求到完整响应的时间。做性能压测时可以先从小并发开始逐步增加并发观察显存占用和延迟的拐点。如果并发增加后延迟大幅上升同时吞吐不再增长说明服务已经接近瓶颈需要扩容或调整批处理参数。6.5 降低显存占用的通用手段使用量化版本比如 AWQ、GPTQ、GGUF 量化。限制最大输入输出 Tokens。减小最大并发数。关闭多余特性比如某些框架默认开启的额外缓存。使用更小的模型变体比如 7B 换成 3B70B 换成 32B。量化后模型效果可能会有少量下降所以必须用实际业务样本做对比验证不能只看指标。7. 开放权重模型 vs 闭源 API 选型参考选择哪个方案取决于业务要求和团队资源。下面通过一个对比表来说明各自的适用情况。维度开放权重模型自托管开放权重模型托管推理闭源模型 API权重可见性权重可下载许可证需检查服务商提供权重不直接交付仅提供接口权重不可见数据流向完全留在自己网络数据进入第三方推理服务数据发送给模型服务商初始成本需要准备服务器和模型文件低绑定密钥即可低绑定密钥即可可变成本主要是硬件和运维按 Tokens 或实例时长计费按 Tokens 计费运维复杂度高中低最低模型选择范围取决于团队实测服务商支持列表仅该厂商提供的模型定制微调支持部分支持基本不支持供应商锁定无中等高上线速度慢快最快从表里可以看出一条清晰的选型逻辑如果希望数据不出内网、模型要长期固定、成本随规模增长可控优先考虑自托管开放权重模型。如果希望快速验证多个开放权重模型、不投入运维团队可以选择托管推理服务。如果对生成能力的要求很极致且数据脱敏和合规都能满足闭源 API 仍然是可以考虑的方案。大多数团队更适合混合策略核心敏感场景走开放权重模型高难任务走闭源 API中间用网关统一调度。这样既控制了成本又不牺牲关键任务的效果。8. 接入与验证一个最小实验如果看完前面的分析想验证“统一网关接入开放权重模型”这个思路可以做一个最小实验。下面是一个通用示例假设你有一个兼容 OpenAI 协议的自托管模型服务运行在本地 8000 端口然后用一个类似网关的中间层转发请求。先在本地启动一个自托管模型服务比如用 vLLM 或 Ollama 启动一个模型确认本地的模型接口能正常响应。这里以通用命令为例# 用 vLLM 启动模型服务示例 python -m vllm.entrypoints.openai.api_server \ --model /path/to/model \ --served-model-name my-model \ --port 8000确认服务启动后用下面的 Python 脚本通过统一接口格式调用这个模型观察返回内容。这里模拟的是“网关只暴露一条标准接口后端模型可替换”的场景import requests import json # 使用 OpenAI 兼容接口调用本地模型服务 url http://127.0.0.1:8000/v1/chat/completions payload { model: my-model, messages: [ {role: system, content: 你是一个技术助手回答要简洁。}, {role: user, content: 请用一句话解释什么是开放权重模型。} ], temperature: 0.3, max_tokens: 256 } response requests.post( url, headers{Content-Type: application/json}, datajson.dumps(payload), timeout120 ) if response.status_code 200: result response.json() print(result[choices][0][message][content]) else: print(fRequest failed: {response.status_code}) print(response.text)这个实验的目的是验证同一个 OpenAI 兼容接口换成自托管开放权重模型后业务代码只需要改一下 Base URL 和模型名就能继续工作。如果你把上面这个接口地址换成某个网关的转发地址就能体会到“应用只认网关、不认具体模型”的迁移便利性。验证过程中建议观察三件事请求是否成功返回完整内容。模型输出的中文质量和一致性。响应延迟在可接受范围内。如果返回失败优先检查模型服务是否启动、端口是否正确、模型名是否一致。这一步通过之后再开始接入更完整的网关能力比如缓存、回退和多路路由。9. 自托管与多模型接入常见问题排查在把开放权重模型接入网关的过程中很多问题不是模型效果问题而是工程链路问题。下面按现象给出排查方向。问题现象可能原因排查方式解决方案新模型接口一直连接失败模型服务未启动、端口错误或防火墙拦截检查进程、端口监听和防火墙规则确认模型服务正常监听端口与网关配置一致模型返回格式不兼容模型服务协议不是 OpenAI 兼容接口查看服务文档、查看原始响应结构使用兼容层转换为统一格式或更换推理框架提示词长度超限模型的上下文窗口小于输入 Tokens在日志中查看 max context length 报错缩短输入、按块处理或换用上下文更大的模型显存不足导致服务崩溃模型权重 KV Cache 超过 GPU 显存nvidia-smi 查看显存占用换量化模型、缩短上下文、减少批处理大小首次请求特别慢模型加载尚未完成或需预热观察服务日志和 GPU 利用率先发一次预热请求再接入正式流量网关启用缓存后结果过期缓存过期时间设置不合理检查缓存策略和时长按业务要求设置 TTL或关闭动态内容缓存主模型故障后回退失败备用模型不支持主模型的工具调用或字段查看回退日志中的格式错误选用能力匹配的备用模型或做格式兼容模型响应不稳定时好时坏并发过高、服务过载或量化损失观察延迟、吞吐和 GPU 利用率压测定上限、扩容、换更高吞吐框架Tokens 用量统计异常偏高输入长度重复统计或缓存未生效对比网关日志和供应商账单检查缓存命中率优化提示词长度和调用策略许可证要求与使用场景冲突模型许可证限制商用或特定部署方式查看模型卡和许可证原文更换模型或与法务确认合规边界排查时最好养成两个习惯一是所有请求都加 request_id方便把网关日志、模型服务日志和应用日志关联起来二是模型服务启动后先手动测试一次接口再接入网关避免把问题混在一起。10. 最佳实践与合规建议10.1 模型选型先做效果测试不要只看模型榜单就决定生产选型。正确顺序是找一批与业务场景高度接近的测试样本用同等提示词格式对比多个模型的输出从准确性、格式稳定性、中文表达、失败率几个维度评分。开放权重模型的优势要在真实数据上验证不能凭印象判断。10.2 网关配置要先小流量灰度把新模型接入网关时不要一上来就全量切换。先用较低权重分发小比例流量观察一段时间内的延迟、输出效果和错误率后再逐步放量。如果模型回退策略复杂先在测试环境模拟主模型故障验证回退链路真的能跑通。10.3 模型文件与配置要版本化管理自托管模型时模型权重文件、量化格式、推理框架版本、网关路由配置都要有版本记录。某个模型效果变化往往不是权重变了就是推理框架版本升级导致的精度变化。可复现性在模型服务化里非常重要。10.4 成本监控要做到接口级不要只看总账单。通过网关日志按模型、业务线、应用维度统计 Tokens 消耗和费用设置月度或日度预算告警。如果某个业务线的成本突然上涨要能快速定位到具体模型和调用场景而不是月末收到账单才发现异常。10.5 数据安全与访问控制自托管模型最核心的理由是数据不外传但如果服务部署到公网反而可能造成数据泄露。自托管推理服务必须限制访问范围建议只允许内网或网关所在网段访问不要直接暴露公网。网关的 API Key 要使用环境变量或密钥管理服务不要硬编码到代码仓库里。10.6 许可证、肖像与版权合规使用开放权重模型前要检查模型许可证确认是否允许商用、是否要求公开衍生品、是否有用户规模限制。涉及人脸、声音、版权素材的生成场景必须确认素材来源合法并获得必要的授权。涉及企业业务数据要与法务确认数据处理协议是否满足合规要求。开放权重不等于无限制使用这一点需要特别强调。11. 总结与下一步这次 Vercel AI Gateway 的流量数据显示开放权重模型调用占比已经占到 62%给技术团队的一个重要提醒是把开放权重模型放在可选列表里现在不再是为了省成本而做的妥协而是为了数据控制、供应商弹性和长期成本结构优化而做的主动选择。最值得先验证的功能不是“哪个模型最强”而是同一个应用能不能通过网关在不同模型之间平滑切换缓存节省了多少重复请求故障时能不能自动切到备用模型。这三件事跑通之后你的 AI 应用就已经不是绑定单一模型商家的应用了。最容易踩的坑集中在三个地方一是许可证没检查清楚就开始商用二是自托管服务暴露到公网导致数据安全风险三是缓存策略设置不当导致业务数据过期或用户看到别人的结果。这三块都适合在正式上线前做一次专项检查。接下来可以继续做的事包括对比不同开放权重模型在你真实业务数据上的效果测试 vLLM、SGLang、Ollama 等推理框架在不同并发下的表现给网关配置缓存和回退策略并压测验证把模型服务纳入监控告警体系观察显存、延迟和错误率。把这一整套链路跑通之后你的 AI 应用就具备了灵活切换模型、控制成本和保障可用性的基础这正是开放权重模型占比上升趋势背后真正的工程价值。