企业级AI大模型中转平台架构设计：高可用分发、流控与计费系统搭建

团队从几个人试水走到几十号人共用一套模型调用，原来那套「一把 Key 加一个脚本」就开始出问题：某家上游抖一下全员卡住，有人写循环把额度烧穿，月底对账对不上部门。这篇不讲怎么拿 Key 跑通第一个请求，而是给做方案评审的人一套分层设计思路：接入层怎么分流和降级、流控放在哪一层、计费按什么口径记，以及上线前该拿哪些指标验收。

团队从几个人试水走到几十号人共用一套模型调用，原来那套「一把 Key 加一个脚本」就开始出问题：某家上游抖一下全员卡住，有人写循环把额度烧穿，月底对账对不上部门。这篇不讲怎么拿 Key 跑通第一个请求，而是给做方案评审的人一套分层设计思路。

核心是把中转平台拆成接入路由、流控、计费三块，各自有独立的验收口径。评审时最容易被跳过的不是功能，而是「出事后能不能定位到是哪一层的问题」。下面按节给判断标准和检查项，具体数字一律去站内对应页面核对当时的数值，别拿本文当报价单用。

先判断要不要自建中转：规模与职责分界

自建不是技术能力的证明，是一笔投入产出账。判断线有三条：同时使用的人数、日均请求量的量级、是否需要按部门或项目分摊费用。三条都低的时候，直接接平台更省事，自建带来的运维、对账、故障排查成本会超过它省下的钱。反过来，只要出现「不同部门要分账」或「某个调用方跑飞影响全员」这类诉求，中转层就有了存在必要。

• 中转层必须自己扛的职责：统一鉴权、模型名称映射、失败重试、用量记录、配额控制，这五项外包不出去
• 可以交给上游或第三方处理的：模型本身的推理能力、部分内容安全过滤、上游侧的基础可用性保障
• 不该自己造的部分：模型权重、推理算力，除非合规强制要求数据不出内网且已有算力资源

接入层与路由：把上游故障挡在用户之外

接入层的第一原则是收口：客户端只认你的一套域名和协议，上游换谁、换几家都不动客户端代码。协议兼容的差异处理可以对照站内 base-url 相关的那篇做法，把不同上游的路径和鉴权差异在网关里抹平。评审时要问的一个问题是：如果明天新增一家上游，需要改客户端吗？答案是「不需要」才算合格。

路由策略按维度拆开，不要揉成一个权重表。至少区分按模型能力路由、按成本路由、按可用性路由三类。关键要求是每个请求命中的线路要在日志里可还原，否则出故障时只能靠猜。健康检查要明确三件事：探针间隔、连续失败几次摘除、恢复后立刻放量还是灰度恢复。摘除太快会误伤抖动线路，太慢会让用户持续踩坑，这两头的取舍要写进方案而不是留给运维临场判断。

1. 定义降级链主线路不可用时切备线；备线也不可用时，交互式请求直接返回明确错误，批处理请求进队列等待；不建议无声降级到能力差距过大的模型，用户拿到质量骤降的结果比拿到报错更麻烦。
2. 设定摘除与恢复规则明确连续失败阈值触发摘除，恢复采用逐步放量而不是一次性回满；规则写进配置并在监控面板上可视，避免只有一个人知道怎么改。
3. 验证线路可追溯随便挑一条历史请求，能查出它走了哪家上游、哪条路由规则、是否有重试，做不到就补日志字段。

流控与并发：分层的闸门比一个总上限管用

只设一个全局总并发是最常见的偷懒做法，结果是一个调用方打满以后所有人一起等。限制至少要拆三层：全局总并发、按 Key 或按用户的配额、按上游线路的池子大小。三层各管一件事——全局防雪崩、单用户防独占、线路池防把某家上游打爆。任何一层单独设置都会漏掉一类事故。

排队和快速失败不是二选一，而是按任务类型分流。交互式任务用户就在屏幕前等，宁可立刻报错让他重试，也不要让他挂在那等几十秒；批处理任务适合进队列慢慢跑，甚至可以在低峰时段调度。两条通道要有不同的入口和不同的限流参数，用同一套阈值会两头不讨好。

重试的边界要写死。超时和上游 5xx 值得重试，参数错误、额度不足、内容被拒这些绝不能重试——重试只会放大问题并污染用量统计。同时要设重试次数上限和单请求总耗时上限，否则一个卡住的请求会一直占着并发。重试的责任归属也要在计费口径里说清，这部分下一节展开。

计费与用量记录：先定义口径，再谈对账

很多团队上来就开始写对账脚本，结果发现两边永远对不上，根因是口径没定义。评审时先把两个口径摆上台面：上游账单口径（上游怎么算你的钱）和内部分摊口径（你怎么跟部门收钱）。两者不一致是常态，关键是明确以哪个为准、差异归集到哪个科目，而不是假装它们应该相等。

• 记录字段至少覆盖：请求时间、调用方标识、模型与分组、输入输出量、缓存命中情况、是否重试、耗时、结果状态
• 失败请求不应计入费用，但要在用量记录里保留，用于区分「上游故障」和「我方被拒」
• 重试产生的额外用量要能追溯到责任方：我方路由问题还是上游抖动，处理方式不同
• 缓存命中的折扣必须落到具体调用方名下，否则缓存省下的钱进了平台账，部门看到的还是全额

按月对账要有固定动作，不能临时抓数据。拉上游账单、拉内部用量、按调用方聚合，三者对不上时归到三类原因里去查：漏记（我方日志缺失）、口径不同（计费单位或分组不一致）、上游多算（需要发起争议）。三类原因的处理路径不同，混在一起查会浪费大量时间。上游侧的计费规则和单位换算，到站内价格与计费相关页面核对当时的说明，别凭印象。

数据边界、日志与审计留痕

提示词和返回内容要不要落库，是评审桌上争议最大的问题之一。落库方便排查但风险大，尤其是涉及业务数据和客户信息的时候。常见做法是元数据（谁、何时、哪个模型、多少量、结果状态）长期保留，正文内容按需脱敏后短期保留，或者只在报障时按工单临时开启留存。这条策略要写进方案，并在脱敏与留存相关规则页确认具体执行标准。

日志里有几类字段不该出现：完整的鉴权凭据、未经脱敏的用户输入原文、内部密钥或上游账号信息。留存周期也要明确，太短排不了障，太长合规压力大。判断标准是：出了问题需要回溯多长时间，就留至少那么久，多出来的部分评估风险。

1. 确认身份可追溯任何一个请求都能回答「谁在什么时候用了哪个模型、花了多少」，查不到说明 Key 分发环节缺了绑定关系。
2. 演练一次审计问答挑一段内容，回答它发给过哪些上游、经过哪些节点、保留多久；答不上来的环节就是要补的日志。
3. 划定字段黑名单把不该落库的字段列成清单，在写入层做拦截，不靠开发自觉。

成本控制与配额分配：把预算变成硬约束

预算如果不落成系统里的硬约束，就只是一份愿望清单。三种约束方式各有取舍：硬额度到点即停，控制力最强但可能中断业务；软额度加多级告警，灵活但依赖人响应；审批后临时提额，适合可预期的大任务。实际方案里通常是组合使用——日常走软额度加告警，关键项目配硬上限，突发需求走审批通道。

给调用方一个自助视图能显著降低沟通成本：剩余额度、近期消耗曲线、异常峰值提示。很多人不是故意超支，只是不知道自己在超支。跑飞防护要有兜底：单次请求的最大用量上限、单日环比突增的自动熔断、可疑循环调用的识别信号（同一调用方短时间高频重复相似请求）。这些规则的阈值需要根据实际流量分布调，具体参考值到站内用量与配额相关页面看当时的数字。

灰度上线与验收清单

上线不是切流量那一刻，而是能回答「出问题怎么退」的那一刻。建议先内部小流量接一条非关键业务，跑通后再按部门逐个接入，避免一次全量切换。每接一个部门前，确认他们的用量能被单独统计、配额能被单独设置、故障时能单独通知到人。

1. 确认四类观测指标成功率、延迟分布、上游切换次数、单位请求成本，四项缺一项都会在出事后说不清问题在哪一层。
2. 明确回滚路径与决策人出问题是切回直连、切到备份平台还是临时关停，谁有权决定，这个答案要在上线前就写下来而不是现场讨论。
3. 落到书面约定与上游确认可用性口径、故障通知时限、账单争议处理方式，口头约定在争议时没有效力。
4. 跑一次故障演练人为断开主线路，观察摘除、切换、告警、恢复放量是否按设计动作，演练结果作为验收依据。

最后提醒一点：这套分层架构的成本主要在运维和排障能力上，不在搭建本身。如果团队没有稳定的人能看日志、能值班、能处理对账争议，分层带来的复杂度会反噬。评估时把人力投入算进去，再和直接接平台做对比。