企业官网建设流程全解析

最近在梳理 AI 基础设施选型时，注意到一个值得关注的变化：Vercel AI Gateway 上的模型调用数据中，开放权重模型的占比已经上升到 62%。这个数字背后不只是“某个平台的数据变动”，而是 AI 应用开发链路中一个正在发生的结构性转变。

过去一提到接入大模型，大家第一反应就是 OpenAI 的 GPT 系列或 Anthropic 的 Claude。而现在，Llama、Mistral、Qwen、DeepSeek 等开放权重模型正在大量进入生产环境。尤其在国内开发者社区，很多人已经开始把基于开源权重模型的自部署服务与云厂商托管 API 混用，再通过网关层统一收敛。本文就来拆解一下 Vercel AI Gateway 是什么、开放权重模型为什么能快速渗透、以及作为开发者我们应该如何调整自己的技术选型与架构思路。

1. 背景与核心概念

1.1 Vercel AI Gateway 是什么

Vercel AI Gateway 并不是一个独立的“模型服务商”，而是一个位于应用与模型之间的网关层。它主要解决的是 AI 应用开发中的一些通用痛点：多个模型供应商的 API 风格不统一、密钥分散管理困难、调用成本难追踪、模型出问题时要手动切换、开发与生产环境的 key 混用等。

简单来说，它是这样工作的：

前端应用 / 后端服务 ↓ AI Gateway（统一入口） ├── OpenAI API ├── Anthropic API ├── 自托管模型（OpenAI 兼容协议） └── 其他兼容端点 ↓ 实际模型服务

开发者只需要把请求发给 Gateway，由 Gateway 负责转发、鉴权、缓存、限流、日志采集和故障切换。这样应用层不需要关心底层模型是哪个厂商的，也方便后续替换模型或切换供应商。

从技术分类上看，AI Gateway 属于典型的“基础设施中间层”，它的价值不在于模型能力本身，而在于对模型调用的治理能力。在单体调用时代，这类网关看起来多余；但当 AI 应用进入多模型、多环境、多团队协作阶段时，它就会成为必需组件。

1.2 什么是开放权重模型

开放权重（Open Weights）指的是模型训练完成后的权重文件是公开的，用户可以自行下载、部署、微调、商用。这里有个容易混淆的概念需要区分：

• 开源模型：不仅权重开放，训练代码、数据、评估方法也完全公开。
• 开放权重模型：权重可获取和使用，但训练代码和数据不一定公开，许可证也有差异。

实践中常说的 Llama、Mistral、Qwen、DeepSeek 等，大多属于开放权重模型。它们与 OpenAI 的 GPT 系列最核心的区别在于：

这也是开放权重模型占比上升的底层驱动力。

1.3 为什么关注 AI Gateway 上的模型占比

Vercel AI Gateway 是一个偏欧美开发者生态的平台，但它对全球 AI 应用开发有一定的风向标意义。它本身不偏袒某个模型厂商，开发者可以自由选择接哪个模型。因此，在同一个网关上观察模型调用分布，可以相对客观地看出开发者群体的真实选择。

当开放权重模型的调用占比达到 62%，说明“自部署开放权重模型 + 网关统一管理”这条路已经被相当多的开发团队验证过了。它不再是小众玩法，而是与闭源 API 并存的主流方案之一。

对于正在做技术选型的团队来说，这就是一个信号：在规划 AI 应用架构时，不能只围绕单一厂商的 API 设计了。要考虑多供应商适配、网关抽象、模型替换成本。

2. 开放权重占比上升的三个核心驱动力

2.1 成本敏感度上升，token 单价不再是唯一指标

在 AI 应用早期，大家优先关注的是模型能力。一个任务能不能完成，比花费多少更重要。但随着应用规模上升，成本结构开始变得复杂。

使用闭源 API 时，成本主要来自 token 用量。对话型应用、Agent 应用、批处理任务，token 消耗量会非常大。一个中等规模的客服机器人，每月 token 费用可能轻松达到数千甚至上万美元。而开放权重模型自部署后，成本模型转变为服务器固定成本。在持续高并发场景下，自部署的边际成本远低于按 token 付费。

这就像“自建机房”和“按量付费云主机”的区别：流量不稳定时按量付费更灵活，流量稳定后自建更便宜。AI 模型调用也是一样的逻辑。

2.2 数据隐私和合规边界越来越明确

企业应用中有大量数据不适合发送到第三方 API。典型的场景包括：

• 含用户个人信息（PII）的自动回复系统。
• 企业内部文档问答，涉及商业机密。
• 金融、医疗等强监管行业的业务数据调用。

这些数据如果经过闭源 API，会面临数据出境、数据留存、合规审计等多重问题。开放权重模型支持私有化部署，数据只在公司内部网络上流转。配合合规网关做审计，就能很好满足监管要求。

这是 Vercel AI Gateway 这类网关能发挥价值的重要场景：对内可以接自部署的开放权重模型，对外可以接闭源 API，通过路由规则把不同敏感级别的流量分发到不同的模型服务上。

2.3 避免供应商锁定，架构上留退路

闭源 API 生态存在供应商锁定风险。如果应用深度依赖某个厂商的 SDK、工具链和特殊能力，后续想切换会非常痛苦。而开放权重模型天然没有锁定问题：权重在自己手里，部署在自己环境里，随时可以从 Llama 切换到 Qwen。

开发团队越来越意识到，在架构设计阶段就通过 AI Gateway 抽象模型调用，配合开放权重模型的可替换性，能最大程度保留未来的选择权。

3. 从“单模型调用”到“网关治理”的架构演进

3.1 早期阶段：直连模型 API

最开始，很多项目是直接从后端 or 前端调用大模型 API：

// 直连模型 API，不经过网关 const response = await fetch('https://api.openai.com/v1/chat/completions', { method: 'POST', headers: { 'Content-Type': 'application/json', 'Authorization': `Bearer ${process.env.OPENAI_API_KEY}` }, body: JSON.stringify({ model: 'gpt-4o', messages: [ { role: 'user', content: '你好' } ] }) });

这种方式简单直接，但很快会遇到问题：

• 密钥直接暴露在服务端代码里，管理混乱。
• 换模型要改代码。
• 无法统一采集日志和监控指标。
• 团队多人共用同一个 key，无法按项目、按功能细分计费。

3.2 演进阶段：接入 AI Gateway

引入 AI Gateway 后，应用代码不再关心模型厂商是谁，只需要向统一的端点发送请求：

// 通过 AI Gateway 调用模型 import OpenAI from 'openai'; const client = new OpenAI({ baseURL: 'https://your-ai-gateway.example.com/v1', // 网关统一端点 apiKey: process.env.GATEWAY_API_KEY // 网关密钥，不是模型厂商密钥 }); const response = await client.chat.completions.create({ model: 'llama-3.3-70b', // 由网关解析并路由到对应模型服务 messages: [ { role: 'user', content: '总结一下这段内容：...' } ] });

这里面的关键变化在于：

• 应用层只与网关交互，不会感知底层模型到底是 GPT、Claude 还是自部署的 Qwen。
• 密钥被收敛到网关层，应用环境只存网关密钥。
• 网关可以按路由规则做 fallback：主模型挂了自动切到备用模型。
• 流量进入网关后可以统一做日志采集、缓存、限流。

这种架构的思路与现代微服务网关（如 Spring Cloud Gateway、Kong、APISIX）是相通的，只是治理对象从“微服务”换成了“大模型调用”。

3.3 成熟阶段：多策略路由与分级治理

更成熟的架构会按业务场景配置多条路由策略：

这个阶段的架构已经不再是“接一个模型”，而是围绕模型调用构建了一套策略治理体系。

4. 社区方案与自建网关的落地路径

在正式实践之前，先梳理一下接入 AI 网关的几条路径。这样你能更清楚地判断企业项目适合用哪条路线：

4.1 使用云厂商或平台托管网关

如果项目已经在使用 Vercel、Cloudflare 等平台，可以直接使用它们提供的 AI Gateway 能力，减少自运维成本。这类服务通常开箱即用，支持多种模型供应商，并内置缓存、限流、日志等能力。

4.2 使用开源中间件自建

如果不希望绑定特定平台，可以用开源方案自建 AI 网关。业界常见的做法包括：

• 使用LiteLLM：一个 Python 编写的统一模型网关，兼容 OpenAI 格式，支持上百种模型。
• 使用One API：国内社区常用的开源模型网关，支持多种大模型接口的聚合和分发。
• 使用Apache APISIX等通用 API 网关：通过自定义插件对接模型服务。

自建网关的好处是数据完全在自己手里，可深度定制；代价是需要自己维护、扩容、和监控。

4.3 使用 AI 框架内置网关

如果项目使用 LangChain、LlamaIndex 等 AI 框架，框架本身也提供了统一的模型调用抽象。虽然这不是完整的网关，但能满足部分场景的路由和降级需求。适合快速原型验证。

5. 完整实战：基于 OpenAI 兼容协议接入开放权重模型

这一节我以一个实际的示例来说明：假设你的团队已经在公司内网用 vLLM 或 Ollama 部署了 Qwen 模型，现在要通过 AI Gateway 把它与 OpenAI API 对齐，让业务方通过统一端点调用。

5.1 准备一个本地开放权重模型服务

最简单的方式是使用 Ollama 运行一个开放权重模型。先在本地安装 Ollama，然后拉取模型：

ollama pull qwen2.5:7b ollama serve

验证模型服务是否正常：

curl http://localhost:11434/v1/chat/completions \ -H "Content-Type: application/json" \ -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "你好，介绍一下你自己"} ] }'

Ollama 提供了 OpenAI 兼容的/v1接口，所以下面的 AI Gateway 可以直接把它当成一个标准 provider 接入。

5.2 配置 AI Gateway 路由

在网关上配置一个模型别名，比如把内部模型统一命名为internal-llm，业务方不需要关心它实际是 Qwen 还是 Llama。

以下是基于通用 AI 网关的配置思路：

# gateway-config.yaml models: - name: internal-llm provider: openai-compatible base_url: http://internal-llm-service.example.com/v1 api_key_env: INTERNAL_LLM_API_KEY models: - qwen2.5:7b - name: external-gpt provider: openai api_key_env: OPENAI_API_KEY models: - gpt-4o

路由规则示例：

routes: - name: internal-doc-qa match: app_id: doc-qa model: internal-llm fallback_model: external-gpt - name: default match: all: true model: external-gpt

这样配置后，内部文档问答流量统一走内网模型；如果内网模型服务抖动，网关自动降级到外部 GPT 接口。

5.3 业务方代码接入

业务方代码只需要知道网关地址和网关 key，不需要关心底层模型是开放权重还是闭源 API：

# app.py from openai import OpenAI client = OpenAI( base_url="https://ai-gateway.example.com/v1", api_key="your-gateway-key", ) def answer(question: str) -> str: response = client.chat.completions.create( model="internal-llm", # 网关别名 messages=[ {"role": "system", "content": "你是一个专业的文档问答助手。"}, {"role": "user", "content": question}, ], temperature=0.3, ) return response.choices[0].message.content if __name__ == "__main__": print(answer("请总结这份合同中的违约责任条款"))

注意，这里的model字段填的是网关上配置的模型别名，不是模型厂商的实际模型名。以后底层换模型，只需要在网关配置上修改，不需要改业务代码。

5.4 添加缓存与限流策略

为了降低成本，可以在网关上配置语义缓存和访问限流：

cache: enabled: true strategy: semantic provider: redis ttl: 3600 similarity_threshold: 0.95 rate_limit: enabled: true strategy: per_app default: rpm: 60 tpm: 100000

语义缓存的使用要谨慎，只对幂等性强的请求生效；对话类请求如果对新鲜度有要求，建议关闭缓存或缩短 TTL。

5.5 运行与验证

启动网关服务后，业务方调用统一端点：

curl https://ai-gateway.example.com/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer your-gateway-key" \ -d '{ "model": "internal-llm", "messages": [ {"role": "user", "content": "你好"} ] }'

如果网关和模型服务都正常工作，会返回类似 OpenAI 格式的响应：

{ "id": "chatcmpl-107", "object": "chat.completion", "model": "internal-llm", "choices": [ { "index": 0, "message": { "role": "assistant", "content": "你好！我是由 Qwen 2.5 模型驱动的 AI 助手。" }, "finish_reason": "stop" } ] }

这个示例说明了一个关键事实：开放权重模型通过 OpenAI 兼容协议接入 AI Gateway 后，调用方式与闭源 API 完全一致，应用层零感知。

6. 常见问题与排查思路

在接入 AI 网关、转向开放权重模型的过程中，团队常遇到下面几类问题。

以下对三个高频问题进行展开说明。

6.1 开放权重模型部署多久后适合接网关

如果只是本地开发调试，不需要立刻引入网关。但当出现以下特征时，就应该把网关纳入架构：

• 同时使用两个以上模型服务。
• 有多个应用共用同一套模型凭证。
• 需要按业务线拆分模型调用成本。
• 有生产环境与测试环境隔离的需求。

6.2 自部署模型与闭源 API 如何分配流量

一个常见误区是“用了开放权重模型就把闭源 API 全部替换掉”。实际工程中，两者往往共存。

推荐使用优先级策略：默认走自部署模型；当自部署服务出现故障或超时，网关自动降级到闭源 API。这个策略能最大化利用开放权重模型的成本优势，同时保留闭源模型作为兜底，避免业务中断。

6.3 开放权重模型效果不稳怎么处理

不同基座模型的效果差异较大。建议在接入前先基于自己的业务数据做离线评测，构建一个小型评估集，包含典型问题和边界情况。然后对比多个候选模型的表现，再决定生产模型。

对于中文场景，建议优先评估 Qwen 系列和 DeepSeek 系列；对于代码生成场景，可以评估 DeepSeek-Coder、CodeLlama 等专门模型；对于英文通用场景，可以评估 Llama 系列。

7. 最佳实践与工程建议

7.1 模型层抽象要早做

最怕的是业务代码里到处都是对某个模型 API 的直接调用。这项工作一定要在早期就做抽象。无论你使用 AI Gateway 还是框架自带的 model 接口，核心原则都一样：业务代码只依赖模型名或别名，不依赖具体供应商。

7.2 密钥管理要收敛到网关层

模型厂商的 API key 永远不要下发到应用层。应用只需要持有网关 key。网关负责把请求转发到正确的模型服务，并填充对应的上游密钥。这样即使某个业务模块的 key 泄漏，影响范围也只会限制在网关层，可以快速隔离和轮换。

7.3 建立模型监控与成本报表

大模型调用有很强的不确定性，必须建立可观测性体系。建议从以下维度监控：

• 请求量、错误率、延迟分位数。
• 按模型、按应用、按团队维度的 token 消耗。
• 缓存命中率和节约金额。
• fallback 触发次数和原因。

这些指标不仅能帮助排查故障，还能为后续模型选型提供决策依据。

7.4 灰度发布与模型替换

替换模型时不要直接全量切换。可以先在网关上配置按流量比例的灰度路由：

v1 路由：30% 流量走新模型 v2 路由：70% 流量走旧模型

观察一段时间，如果新模型的效果和稳定性达标，再逐步放大比例。这种方式在开放权重模型迭代频繁的当下尤其重要。

7.5 关注许可证合规

开放权重不等于可以随意使用。各模型的许可证差异很大，有些允许免费商用，有些要求超过一定规模后获得额外授权。落地前必须仔细阅读模型许可证，并咨询公司法务。常见的风险点包括：

• 是否允许商用。
• 是否要求保持同样的许可证开放。
• 是否有月度活跃用户数量限制。
• 是否禁止用于特定领域。

7.6 生产环境的变更规范

不论是更换模型、修改网关路由还是更新部署脚本，都要走规范的变更流程：

1. 先在测试环境或 staging 环境验证。
2. 备份当前网关配置。
3. 发布后观察关键指标是否异常。
4. 准备快速回滚方案。
5. 记录变更人和变更时间。

大模型应用的变更往往影响面很大，不建议直接在生产环境做没有回滚预案的操作。

8. 总结与后续学习方向

Vercel AI Gateway 上开放权重模型占比上升到 62%，说明 AI 应用开发正在进入“多模型共存”的新阶段。闭源 API 不再是唯一选择，企业可以基于开放权重模型建立私有化的模型服务体系，并通过 AI Gateway 统一管理所有模型调用。

如果你正准备在自己的项目中引入这套体系，可以按以下顺序推进：

1. 先梳理业务请求的模型使用场景，确定哪些数据可以走外网 API、哪些必须内网自部署。
2. 选 1-2 个开放权重模型做离线评测，确定候选方案。
3. 用 vLLM 或 Ollama 部署候选模型，验证服务稳定性。
4. 引入 AI Gateway 或自建网关，把模型调用统一收口。
5. 配置路由、缓存、限流、日志、监控指标。
6. 逐步把流量从闭源 API 切换到自部署模型，观察成本与效果变化。

下一步可以重点关注：vLLM 与 SGLang 等推理引擎的部署优化、RAG 与 Agent 架构下的模型调用模式、多模态模型网关治理、以及开放权重模型的微调与蒸馏实践。

整个领域还在快速演进，具体工具链和模型版本会不断变化，但“应用层与模型解耦、通过网关统一治理”这个底层方向是明确的。尽早把架构建立在抽象层上，后面换模型、换厂商、做成本优化都会从容很多。