从模型管理到 AI 网关：把资产、流量与成本串成闭环
这套系统有两条主线：一条是模型管理与模型资产，回答”谁能用什么、能用多少”；一条是 AI 网关，把这些决定落实到每一次请求。本文分别沿”一个模型的一生”和”一次请求的一生”拆解，最后看两条线在哪里咬合。
一、资产与流量
传统 API 管理的核心对象是接口，AI 平台管理的核心对象是模型。两者看起来都在处理 HTTP 请求，关心的东西却不一样：
| 接口管理关心什么 | 模型管理还要关心什么 |
|---|---|
| 地址、协议、认证、路由 | 模型上架、选型、权限、配额、单价与下线 |
| 请求是否成功 | 输入与输出分别消耗了多少 Token |
| 上游是否健康 | 实例是否健康、是否还有额度、是否需要切换供应商 |
| 调用者是谁 | 调用属于哪个应用、用户和成本中心 |
左列是流量侧关心的问题，右列是资产侧多出来的关切；实例健康、剩余额度这类事最终仍由数据面执行，资产侧只定规则、看结果。如果管资产的和管流量的是两套系统、各管一半，就会出现脱节：审批、权限和配额停留在资产系统里，约束不到真实请求；网关能转发流量，却不知道模型为什么上架、谁获准使用、成本算给谁。
两者真正的关系是一个环：
1 | 模型上架 → 选型与申请 → 授权和配额生成 |
环上有两个方向：决策向下，模型、权限、配额和路由规则经配置面进入网关；结果向上，Token 用量、调用者和调用结果从网关回到资产侧。
这个环靠三个平面转起来：业务面做决定，管模型资产与使用规则；配置面翻译并交付决定，把业务规则变成网关能执行的路由、实例和插件配置；数据面执行决定并回传结果，以 AI 网关为底座，只管请求链路里的鉴权、限流、选路、改写、转发和记录。三个平面各守边界，业务面不碰推理流量，数据面不制定也不保存资产规则，配置面只做翻译和交付。
后文统一用两个词：管规则的一侧叫资产侧，对应三平面里的业务面；发请求的一侧叫调用方，既包括低代码智能体平台、微服务这类应用，也包括个人办公的直接调用。
难点也在这里：同一个模型、令牌和调用方，在资产系统和流量系统里必须指向同一份东西。先看资产侧的一个模型怎么走完一生，再看流量侧的一次请求。
二、模型管理与模型资产：一个模型的一生
用一个贯穿的例子：客服团队要给低代码智能体平台接一个新的推理模型。这个模型从进来到退出，要过六道关：
2.1 选型
他们先在模型市场里并排试了几个候选：同一个模型，逐个调 Temperature、Top_p、Max_tokens，看参数怎么影响输出；参数定下来后固定住，换模型重跑同一组提示词，只留模型一个变量，比较效果差异。
选型不只是挑一个模型名，还要判断要不要推理能力、效果要求多高、有没有安全风险。安全风险尤其关键，它直接决定走私有化实例还是云服务，后面的申请和路由方式都跟着变。
2.2 申请
申请单要填使用方式（低代码智能体平台、微服务调用，还是个人办公）和环境（测试还是生产）。
生产权限必须绑定明确场景。没有场景，调用就只能停在令牌这一层，归不到应用与成本中心，审计追查和问题定位也跟着受限。所以申请这一步真正建立的，是模型、调用方、成本归属三者的关系。
2.3 令牌：权限的载体，不是孤立的 Key
一个令牌可以挂多个模型权限，不用一个模型申请一把 Key。删除令牌的条件卡得很严：删掉最后一个模型权限，令牌随之失效；如果还被智能体引用着，就拒绝删除。系统里不能存在”仍然有效，但不知道由谁使用”的令牌。
申请通过后，授权还要继续向下落到网关。企业 / 应用路径要签发令牌、创建 Consumer（网关侧代表调用方的消费者对象，凭证和插件配置都挂在它下面）、写入模型权限与配额、加入允许调用的路由清单。
个人路径只签发令牌，不建 Consumer，因此鉴权和额度判断留到请求进来时，由资产侧实时判定。
这一步没走完，资产系统里的”已授权”变不成请求链路里的”可以调用”。
2.4 调用约定
真正开始调用后，SDK 说明只是表皮，底下是模型管理规则在请求侧的表达，也是会话、用户与成本归属进入数据面的载体：
- RPM / TPM 任一超限就拒绝，约束的是请求频率、模型吞吐和成本预算；
- 同一对话保持
X-Session-ID不变，通过一致性哈希尽量落到同一实例，复用 KV Cache； - 通过
baggage: sentry-user传用户信息（baggage是 OpenTelemetry 随链路传播键值上下文的标准请求头），日志里就能拿到caller_user，从一次调用一路追到具体用户。
2.5 计费
一次用户交互可能触发多次模型调用，只按交互次数或请求数说不清真实消耗，容量和成本还得看 Token 口径。
按 Token 口径统计，能支撑三件事：
- 容量测算：线上统计出单次交互的平均 Token 消耗（另看 P95，均值会掩盖多轮循环的长尾），拿它去压测，验证 RPM / TPM、并发与延迟的上限，业务量才能换算成资源需求；
- 分账：用量按令牌归集到应用或子产品，需要时再细看到单个用户；
- 成本估算：
DAU（日活跃用户数） × 单人日均交互次数 × 单次平均 Token 消耗 × 单价推日成本。公式的前两项（DAU 与交互次数）来自业务埋点，网关只提供 Token 与单价，单价还要按输入、输出分开计。
网关在这里是反馈入口：解析上游 usage，记下输入输出 Token、模型实例、调用者和链路信息，交给配额结算、明细查询和成本分账使用。
2.6 下线：先解除引用，再删资产
模型下线不能从列表里一删了事。挂在旧模型上的东西都得同步收尾：已发布的路由、已签发的令牌、智能体里的引用、在途的迁移。系统还留了两道校验，都发生在创建路由时：已经写进下线清单的模型不许再建新路由；服务模板不兼容，同样建不成。
完整顺序是：先切换调用关系，再回收令牌和路由，最后才下架模型资产。反过来做不行：先删资产、后切流量，资产关系就和真实流量脱节了。
六个阶段到这里并没有真正结束。图 2 的三条虚线就是回流：用量、质量与成本反馈支撑扩容计划与供应商取舍，权限与配额的调整回到申请环节，下线腾出的位置由替代模型补上，重新进入选型评估。
三、AI 网关：一次请求的一生
第二章建立的资产关系，最终要在一次次真实请求里生效——短则毫秒，长则数分钟。
低代码智能体平台正式接入后，企业路径的每个请求进网关，网关都要依次回答五个问题：
- 你是谁：校验企业凭证。
- 你能否调用这个模型：检查模型权限，以及这条路由在不在允许调用的清单里。
- 这次请求能否放行：安全校验，再看 RPM、并发和输入 Token 预算够不够，决定这个请求让不让进来。
- 这次请求发到哪里：过滤不健康或额度耗尽的候选实例完成选路，再过一遍实例级额度。
- 最终用了多少：解析响应 usage，写日志并回传资产侧。
图 3 把这五问展开为八个阶段，多出来的请求改写和转发属于执行细节。身份和权限要先确认，放行判断在选路之前，真实用量只能在响应后结算——实现可以变，这个先后不能乱。
这五个问题背后都是第二章的决定：你是谁，来自申请建立的归属；能否调用，来自令牌权限；能否放行，来自配额结论；发到哪里，来自选型与下线确定的实例清单；用了多少，回到计费口径。两条线就在这里咬合。
3.1 两类调用方，两条链路
低代码智能体平台走企业路径，个人办公走个人路径。两类调用方的数据来源不同，塞不进同一套鉴权模型：
- 企业 / 应用路径：令牌绑定固定调用方，网关本地完成身份、模型权限和配额检查。
- 个人路径：不创建固定消费者对象，由资产侧实时校验令牌与额度，请求结束后回收实际用量。
两类调用走不同的场景域名。请求到达网关时，域名已经决定它命中企业路由还是个人路由，不用进门后再靠路由上的标签临时分流。
3.2 用量只解析一次
网关只解析一次上游响应里的 usage，同一份结果同时交给 Token 配额结算、个人用量上报、日志和指标，避免各算一遍导致口径不一致。
这一步把”请求成功”变成了可运营信息：不光知道调用完没完成，还知道用了哪个实例、烧了多少 Token、算在谁头上。
请求体和响应体可能带着提示词、业务数据甚至个人信息，”能记录”不等于”默认全量留存”。生产环境还要按场景决定是否采样，并配套相应的脱敏、访问控制和保留周期。
3.3 实例池
一个模型可能同时对应自建实例、云服务和备用供应商。转发前，健康状态、剩余额度、告警降权（把实例优先级调低）共同决定实例能不能进候选；转发后，上游返回 429 / 5xx 就按重试条件切换候选。这些条件必须走同一套选路和重试逻辑，不能各搞一套——否则健康检查刚摘掉的实例可能被另一套逻辑重新选中，配额耗尽的高优先级实例也可能继续收到流量。
3.4 一次真实的请求
图里标红的”不可用”实例因为主动健康检查失败，已经移出候选。这次请求先到首选实例，它返回 429——只在本次请求中被排除，图中标为”本轮已试”，不写进健康检查状态。故障转移（Fallback）开着、距上次失败还没超过重试冷却时间、重试次数也没用完，选路器接着改投备用一。低代码智能体平台全程无感：不用自己重试，也不用换地址换凭证。
请求级排除、健康检查摘除、额度过滤、告警降权，四种机制互不干扰，作用的却是同一个候选池。首选实例持续异常达到阈值后，才被告警联动挂上”降权”，等探测恢复再按策略重新接入候选。
四、咬合点与边界
资产侧做决定，流量侧执行决定，中间靠配额和配置衔接；能力图谱则把两边的边界固定下来。
4.1 配额：资产侧计算，数据面执行
资产侧掌握模型权限、套餐和成本规则，适合回答”应该给多少”；数据面看到每一次真实请求，适合回答”已经用了多少”。两者不能互换。
企业 / 应用路径用五步链路把它们接起来（图中”业务侧”即本文的资产侧）：
边界很清楚：企业路径下，网关不持有配额规则，只持有计算后的结论。 个人路径更彻底，鉴权和额度判断都由资产侧实时给出。
Token 限流分两段：转发前看还有没有余量，响应后按真实 usage 入账。这样调用前能拒绝、调用后能按实际结算；代价是已经发出去、还没返回的请求不会提前占额度，实际用量可能短时超过阈值。
对用户来说，这套实现最终只表现为限流维度 RPM / TPM，具体数值以模型市场详情为准；性能档位（标准模式 / 高性能模式等）是模型市场详情页另行标注的信息。
时段限流也是同一套逻辑：时段是请求进来时才读的，忙闲额度在运行时自动切换，不用每天定时改线上配置。
4.2 配置下发
模型权限、配额和实例状态都会变，但变化不能靠全量覆盖网关配置来完成，一次业务下发就可能冲掉运维的手工调整。
所以配置环节只守两条边界。网关插件分两类，配置面负责下发的叫受管，运维直接在数据面上配的叫非受管。归属边界：受管插件只认数据库，不在库里的变更不算数；非受管插件只认数据面现状，配置面不去碰它。失败边界：调网关这一步不放进数据库事务里，事务提交后再下发；下发失败不回滚，只记状态、告警、重试——回滚撤不回已发出的调用，”未送达”反倒没了记录；真要回滚，先恢复网关、再回滚数据库。
配置面只改目标字段，下发后回读确认。我们不追求某次下发绝不失败；只要失败后仍知道该以谁为准、数据面能重新收敛就行。
4.3 能力图谱
资产侧和流量侧各管一段，边界在哪？起点是一份 13 类能力清单：
1 | 管理能力 · 流量治理 · 连接与超时 · 路由与负载均衡 · 请求改写 · 可观测性 |
拿这 13 类逐项对照传统 API 网关，差异集中在治理与运营，不在转发本身；13 类里条目最密的是可观测性和请求改写。按”能力最终在哪里执行”，它们可以归入 8 个域：
这张图要交代的是边界：A–G 决定请求如何执行，H 决定为什么这样执行。传统 API 网关主要覆盖前者；要让模型成为一等公民，后者必须由模型管理与业务控制面补齐。
五、反馈如何变成决定
运行结果会从三个地方往回走，把流量侧的执行结果送回资产侧：
| 回流的触发 | 谁接住 | 改变什么决定 |
|---|---|---|
| 上游 429 / 5xx 持续出现并触发告警 | 数据面告警联动降权 | 实例的选路优先级，直接影响后续每一次选路 |
| Token 用量与调用明细 | 配额与分析层 | 分账归集到应用或子产品，需要时细看到单个用户，并支撑容量与成本口径（2.5） |
| 实例健康状态与用量增长趋势 | 运维与模型运营 | 扩容实例、降级或补充供应商，直至进入 2.6 的下线与迁移 |
第一行不需要人参与：状态一变，选路优先级跟着变。后两行要人拍板：数据先变成账单和看板，再决定扩容、换供应商或下线。
结语
模型管理决定”谁能用什么、能用多少”，AI 网关负责把这些决定落实到每一次请求；请求结束后，用量、调用者和调用结果再回到模型管理，支撑分账、扩容、迁移与下线。
这也是两条主线的交点：一个模型的一生负责建立和改变资产关系，一次请求的一生负责执行并验证这些关系。少了前者，网关不知道为什么这样转；少了后者，模型管理里的权限和配额只是纸面规则。
这几件事连起来，模型资产、流量治理与成本管理才构成真正的闭环。
作者的话
这套系统从能力盘点、三平面架构设计，到自研插件、模型全生命周期、限流迁移与运维台，都由我负责推进落地。
如果你也在做模型平台、AI 网关或 LLMOps，欢迎交流。
延伸阅读