模型会继续换， 接入层不该跟着换

首篇不写产品介绍，写不常变的东西——为什么模型不该被硬编码进业务、多模型的成本为什么八成记在账上、稳定性为什么是路由问题，以及智能体时代接入层为什么必须扩到「信任」。

本文要点

1. 模型不是基础设施，接入层才是。业务代码的生命周期以年计，模型的半衰期以月计，这一错位必须由一层稳定的调用方式来吸收。

2. 多模型的成本八成记在账上。凭证、口径、责任三张账对不上，比模型选得对不对更费工程师时间。

3. 稳定性是路由问题。把网关开销与端到端耗时分开看，才知道慢在哪一段。

4. 智能体把接入层的边界推到了信任。网关管怎么调，检测管能不能信。

这是 AionRouter 的第一篇博客。

按理说第一篇该写产品介绍：支持多少个模型、多少钱、怎么接入。但这些内容官网页面上都有，而且每天都在变——价格每周在调，模型每季度在换，写进博客三天就过期。

所以我们更想写不常变的那部分：做这个平台时的判断、判断背后的代价，以及一些我们明确不承诺的事。

因为一个接入层的价值，从来不取决于它此刻接了多少个模型，而取决于你换模型的那一天，业务代码要不要跟着改。

一、模型不是基础设施，接入层才是

先把一件事说清楚：模型不是基础设施。

基础设施的特征是稳定、向后兼容、生命周期以年计。而过去十二个月的实际情况是——主力模型换了三代，价格表改了不止四次，视频模型从「能不能出声」一路卷到「音画同步」。

业务代码的生命周期通常三到五年，提示词资产、评测集、工作流编排往往更长。当你把一个具体型号名硬编码进业务代码、散落在十几个条件分支里，你实际上是把一个半衰期只有几个月的变量，固化进了要活三年的资产。下一次换代，你要改的不是一行配置，是一批分支、一轮回归测试、一个发版窗口。

该稳定的那一层，是调用方式：鉴权怎么带、请求长什么样、错误怎么返回、用量怎么算。这一层如果稳定，上面换什么模型都只是配置变更。

第一条设计原则： 把模型选择从代码里挪出去，变成运行时可变的配置。

具体做法是克制地选择兼容，而不是发明：对外只提供与 OpenAI 一致的接口形态，同时兼容 Anthropic 的 Messages 格式。代价很清楚——我们放弃了为每个上游定制私有参数的自由；收益是，任何写过 OpenAI 接口的团队改两行配置就能进来，也能随时改两行配置离开。

模型名称是部署态的名字，不是能力的名字

这一条常被误解，值得单独说。

同样叫一个名字，在不同渠道可能是不同的量化精度、不同的上下文长度、不同的版本快照。所以平台从不鼓励你去厂商官网、模型榜单或技术博客里抄型号——那些描述的是「世界上存在什么」，而你需要的是「你这个账号、这个令牌，此刻真的能调到什么」。

这两件事的差值，就是线上事故的常见来源。

正确的动作只有一个：调用之前，先向平台查询一次当前账号真正可用的模型清单，用返回结果里的名称去请求。平台反复强调「不要猜测型号」，不是措辞谨慎，是架构决定的——模型清单由渠道、账号分组和令牌权限共同决定，它是动态的，也是账号相关的。任何静态列表，包括这篇文章里的例子，都只是示例。

二、多模型的成本，八成记在账上

把模型接进来只需要半天。让它长期跑在生产上，成本才真正开始。

我们和大量团队聊过，卡住他们的从来不是「哪个模型更强」，而是三张对不上的账。

第一张是凭证账。五个厂商五套密钥，十个项目再乘一遍。密钥散落在配置文件、持续集成变量、某位同事的备忘录和一台没人记得密码的跳板机上。谁在用什么、什么时候该吊销，没人说得清。

第二张是口径账。每家一个后台，一套计费单位：有人按千词元，有人按百万词元，有人按张、按秒、按次。月底要把这些表格拼成一张给管理者看的成本报表，本身就是一个人的工作量。

第三张是责任账。某家上游开始抖动，你既不知道影响面有多大，也没有第二条链路可切。唯一的办法是改代码、发版、等窗口。

这三件事没有一件和模型能力有关，却消耗掉比调提示词更多的工程师时间。

为什么我们用「配额」而不是直接搬价格

一个容易被跳过的设计决定：我们不直接把上游的报价搬进账单，而是用配额做统一记账，单次消耗等于实际词元数乘以该模型的倍率。

这么做有三层考虑。

一是价格是运营参数，不是代码常量。上游调价、限时折扣、渠道差异，全部在倍率这一层消化，不需要改任何调用方代码，也不需要你重算预算表。

二是折扣和分组能在同一层表达。企业协议价、特定渠道优惠，最终都落到倍率上，账单口径始终一致——不会出现「这个人走的是特殊价、报表算不清」的情况。

三是可追溯。每次调用的词元用量、命中情况、扣减金额都能落到具体请求上，月底那张报表是查出来的，不是拼出来的。

三类计费，和唯一值得花时间优化的那一类

模型多了以后，计费口径必然分化。我们把它们收敛成三类：

按量计费，最常见。按输入与输出消耗的词元计费，价格以每百万词元展示，也支持换算成每千词元。

按次计费，用于部分多模态和特殊模型——不论输入输出多少，单次调用扣固定金额。

按秒计费，视频模型的通行做法，按生成时长结算。

三类里，只有按量计费存在真正值得优化的空间，而空间几乎全部来自上下文缓存。

对支持缓存的模型，价格被拆成三档：正常输入、缓存读取、缓存写入。缓存命中价通常只有正常输入价的十分之一左右，部分模型更低。

以站点当前公示的限时价为例，某主力快速模型输入为每百万词元 0.7 元，输出 2.8 元，缓存命中 0.014 元——命中价只有输入价的 2%。

假设每天五百次调用，每次输入两万词元、输出八百词元，其中九成的输入命中缓存：

项目	词元量	单价（元／百万词元）	当日费用（元）
未命中输入	1.0 M	0.70	0.70
缓存命中	9.0 M	0.014	0.13
输出	0.4 M	2.80	1.12
合计	—	—	1.95

同样的调用量，完全不走缓存，输入就是 7.00 元，加上输出共 8.12 元。

一天差 76%，一个月是从 240 多元变成 58 元，一年差 2200 元。而这笔钱不需要换模型、不需要降质量，只取决于你的提示词长什么样。

让缓存生效的办法并不神秘：把稳定不变的部分放前面，把变化的部分放后面。系统指令、代码库定义、参考资料在前，用户输入和临时上下文在后，结构越稳定，命中率越高。在长上下文编程工具里，这一条的效果尤其明显——它们每次调用都带着几乎相同的系统提示和大段代码定义，这正是缓存最理想的形状。

给每个密钥设额度，是组织问题不是技术问题

最后一条容易被当成安全建议忽略：给每个密钥设独立额度。

它的真正作用不是防黑客，是防自己。开发密钥、测试密钥、生产密钥各自限额，代码里一个没写出口的循环最多烧掉设定上限，而不是账户余额。账户余额是上限，令牌额度是闸门，两个都要设。

创建密钥时可以配置的能力，本质上就是这套治理的最小集合：有效期、额度、模型限制、来源地址白名单、渠道分组。团队规模一大，这几项从可选变成必需。

关于价格：上文数值取自站点当前公示的限时折扣价，会随时间调整。实际可用模型与扣费，以控制台模型广场和账号账单为准。

三、稳定性是路由问题，不是模型问题

用户感知到的「这个模型今天很慢」，实际可能来自四个完全不同的地方：上游推理排队、区域网络抖动、渠道配额耗尽、或者我们自己的转发层。把它们混为一谈，就永远修不好。

这也是我们坚持把网关自身开销和端到端耗时分开公示的原因：企业页给的是网关平均延迟低于 50 毫秒，首页给的是平均响应 320 毫秒。前者是转发层的成本，后者包含上游推理时间。两个数字放在一起看，才知道慢在哪一段。

三种失效，三种对策

上游抖动。表现是间歇性服务端错误和长尾超时。对策是多渠道冗余加自动故障转移——请求不必由你手动改指向，网关按当前健康度选路。

配额耗尽。表现是突然大面积失败，而且往往发生在业务高峰期。对策是账号分组与令牌额度前置约束，让它在设计上就有上限，而不是在告警里被发现。

区域性故障。表现是某一整条链路同时异常。对策是渠道分布本身要跨源，不能所有备用路径都挂在同一个上游。

首页的实时面板显示，过去七天全部渠道可用性 99.94%，平均响应 320 毫秒；官方公示的服务等级承诺为 99.9%。这些数字的意义不是「我们比谁快」，而是它可以被写进你的技术方案，作为一个可以复核的前提。

一条给调用方的建议：把模型名当能力，别当实体

这是本文最实用的一条工程建议。

不要在代码里写「如果主模型是甲，就调用甲；否则调用乙」。正确做法是维护一张能力档位表：

能力档位	典型用途	候选模型
极速档	分类、抽取、路由决策	小参数快模型
主力档	对话、写作、代码	当前主推旗舰
长文档档	合同、代码库、报告解析	长上下文模型
多模态档	图文理解、视频生成	视觉与视频模型

业务代码只声明「我需要主力档」，具体映射到哪个模型，放在配置里，可以热更新。这样换模型是改配置，降级是切换档位，而不是一次发版。

成本优化也是同一张表：把能降档的任务降下来，往往比换一个更便宜的模型更有效——分类任务用旗舰模型，是最常见的浪费。

四、智能体让接入层的边界，扩到了信任

今年另一个明显的变化：越来越多团队开始跑智能体，而智能体的能力边界由第三方技能包决定。

这带来一个此前不存在的问题——调用链上多了一个你无法审计的环节。一个技能包里可以写什么，通常没人看；它读什么文件、发什么请求、往记忆里写什么，往往在出事之后才被翻出来。

所以我们在网关之外做了一个独立的检测入口：上传技能安装包（zip 压缩包，单文件不超过 10MB）或粘贴公开链接，系统做全链路分析，重点看三类风险。

指令劫持。提示注入、权限越界、隐藏的控制指令——表面上是一个正常工具，实际在改写智能体的行为目标。

记忆投毒。持久化记忆和依赖内容里被植入的恶意信息。它不会立刻发作，而是持续污染后续决策，等到发现时，源头已经很难回溯。

组合攻击链。单看每一步都正常，串起来才危险。这类风险靠逐条审查永远发现不了，只能靠跨指令、跨依赖、跨工具调用的关联分析。

它和网关严格来说不是一回事：网关管怎么调，检测管能不能信。但两者解决的是同一类问题——把不可见的风险，变成可查的记录。

五、四个常见误解

做平台久了，有些问题会被反复问到。与其在客服里一遍遍解释，不如写在这里。

常见说法	事实
加了网关，一定更慢	网关平均延迟低于 50 毫秒，相对于上游推理的数百毫秒，转发层不是瓶颈。真正决定体感的是你选的模型和是否流式输出。
聚合平台给的模型是降级版	可用模型由渠道、账号分组、令牌权限决定，能力以带鉴权的实时查询结果为准。我们不做「名单上写着、实际调不到」的承诺。
用了接入层就被锁定了	协议层不锁定：兼容主流两家接口形态，改两行配置进来，也改两行配置出去。锁定你的是私有协议，我们没有发明私有协议。
便宜一定意味着不稳定	成本主要来自路由和缓存，不是牺牲冗余换来的。缓存省下的是重复计算，路由省下的是空转，两者都不降低服务质量。

六、一份接入清单：七条硬规则

如果你准备把 AionRouter 放进生产，这七条能避开绝大多数坑。

1. 密钥分层。 生产、测试、本地各一个，额度独立。生产密钥开来源地址白名单，测试密钥做模型限制。密钥只在创建时完整展示一次，存进密钥管理服务，不进代码仓库、不进聊天记录。

2. 模型靠发现，不靠硬编码。 服务启动时查询一次可用模型清单，缓存结果并按需刷新。写死型号的代码，会在某次上游调整后集体失效。

3. 能力档位替代模型名。 业务只认档位，配置决定映射，见上一节的能力表。

4. 异步任务要持久化任务标识。 视频、图像这类接口会真实产生费用。创建任务后立刻把任务标识落库，之后靠查询任务状态取回内容。恢复靠查询，不靠重建。

5. 错误要分类，不要统一重试。 这是最容易写错的一处：

错误类别	是否重试	正确动作
鉴权失败	否	检查密钥、有效期、模型限制、来源地址白名单
模型不可用	否	重新查询可用模型清单，不要按名字猜
参数错误	否	改参数。退避重试只会放大错误
额度不足	否	充值或调整令牌额度，同时告警
限流	是	指数退避并设上限，或降并发、换分组
上游异常或超时	是	有上限退避；计费类任务先查任务再决定是否重建

1. 提示词结构为缓存设计。 稳定的在前，变化的在后。这一条没有代码成本，只有习惯成本，但它决定了你每月账单的位数。

2. 预留降级路径。 主力档不可用时的备选档，应该在你写第一行业务代码时就确定，而不是在故障当晚讨论。

七、我们明确不承诺的事

首篇博客如果只讲能做什么，就不值得读。以下几条是边界，写清楚对双方都好。

不承诺固定价格与免费额度。上游在调价，平台价格随之变化。所有报价以控制台模型广场的实时公示为准，本文出现的数字都是某一时刻的记录。

不承诺上游有什么、你就能调什么。模型清单是账号、令牌、渠道三者共同决定的结果。任何脱离实时查询的模型列表，都不构成可用性承诺。

不承诺单一模型的可用性与性能。我们承诺的是链路层面的服务等级，不是某个具体模型在某个时刻的响应速度。模型是别人的，路由和兜底是我们的。

不做无鉴权的公开转发。所有接口请求必须携带令牌，没有例外。这不只是计费需要，也是责任边界。

不存储你的密码。登录走手机验证码与微信授权，全程第三方授权协议，平台侧不落密码。

不把「我们支持」当营销词。文档里能查到路由的接口，才是真的实现了的接口；查不到的，就是还没做。

不隐藏失败。出错时优先返回明确的状态码和可读的错误内容，而不是一个成功状态加一段空响应。

八、写给第一个密钥

模型还会继续换。下个季度会有新的版本、新的旗舰、新的视频模型，能力表会再刷一遍，价格表也会再改一遍。

这件事不会停，也没必要停。

但接入层不该跟着换。一个密钥、一个地址、一份账单、一套权限——把变化挡在网关后面，业务代码才不用每两个月重写一次。

如果你现在手上正好有三个以上的模型密钥散落在不同地方，欢迎从五分钟接入试一次。第一个请求跑通之后，剩下的就是把这套结构慢慢搬进生产。

下一篇我们会写更具体的东西：一份真实项目从零接入的完整记录，包括迁移成本、遇到的问题和最后省下的钱。如果你有想看的场景，可以写信给我们。

—— AionRouter 团队

---

AionRouter 是杭州趣猿人工智能有限公司旗下的一站式大模型 API 平台，提供文本、图像、音频、视频模型的统一接入、路由、用量统计与计费管理。技术接入支持与商务咨询：support@aionclaw.com