先给结论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% 这个数字以后很可能会更高。但对具体团队来说更重要的不是追赶这个比例而是判断自己的业务是否适合把更多流量切到开放权重模型上。如果适合优先把网关路由、观测指标、成本统计和失败重试配置好如果不适合也不需要因为一个行业数据而强迫自己迁移。把网关这一层搭稳后续无论哪个模型表现更好切换成本都低。这比单纯追求某一个占比数字更有实际价值。
开放权重模型调用占比62%，AI网关如何引领模型选型新趋势？
先给结论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% 这个数字以后很可能会更高。但对具体团队来说更重要的不是追赶这个比例而是判断自己的业务是否适合把更多流量切到开放权重模型上。如果适合优先把网关路由、观测指标、成本统计和失败重试配置好如果不适合也不需要因为一个行业数据而强迫自己迁移。把网关这一层搭稳后续无论哪个模型表现更好切换成本都低。这比单纯追求某一个占比数字更有实际价值。
算法精解与面试技巧)
