模型网关的治理设计：计费、密钥与隐私保护

一个模型网关即使能稳定转发请求，如果不知道是谁在调用、费用算到哪里、上游 Key 是否可能泄漏，它依然很难成为可靠的共享基础设施。

这些问题看起来分别属于计费、安全和运维，实际上都围绕同一条请求生命周期：请求进来时要验证身份、检查预算和处理隐私；响应返回后要结算真实用量、记录审计信息。本文从通用架构角度讨论这些治理能力，并用 ai-gateway 作为具体案例。

两类密钥，不要交给同一层管理

业务调用网关需要一种客户端凭据；网关访问模型供应商又需要另一种上游凭据。两者的生命周期和泄漏影响不同，应该分开管理：

text

1

业务服务 ── 虚拟 Key ──→ 网关 ── 上游 Key ──→ 模型供应商

业务侧只拿到网关签发的虚拟 Key。它可以关联应用、模型权限、余额或预算，泄漏后能被吊销，而不直接暴露供应商真实凭据。

虚拟 Key 本身通常应当只在签发时明文展示一次，存储侧保留用于校验的摘要，而不是长期保存明文。上游 Key 则需要由网关在调用时取用；如果必须持久化，可以使用经过管理的加密方式保存，并严格限制读取路径。加密不是密钥管理的全部：主密钥轮换、备份、权限隔离和日志脱敏同样重要。

ai-gateway 将上游密钥加密保存，管理接口只返回掩码，并把生产所需的加密主密钥、虚拟 Key 盐值等配置设为显式必需项。这里的设计重点不是某个具体算法，而是减少明文凭据出现的时间和位置。

计费要拆成预留和结算

模型请求结束前，网关通常不知道最终准确的 token usage。若等到响应完成后才扣费，余额可能已经被并发请求同时花超；若一开始按最坏情况直接扣掉，也会让用户体验很差。

一种常见做法是两阶段处理：

      text
      
1
2
3

请求前：估算成本 → 检查预算 → 预留额度
请求后：读取上游真实 usage → 计算实际成本 → 结算差额
异常结束：按失败语义释放或调整预留额度

这里最难的不是乘单价，而是状态一致性：客户端断开、上游超时、进程重启或结算重复执行时，预留额度不能永久挂住，也不能重复扣款。可以为一次请求建立唯一计费记录，并让结算、退款和释放操作具备幂等性；对于可能并发修改的余额，则需要原子地完成检查和更新。

模型用量也不总是简单的输入 token 与输出 token。有些供应商会单独报告缓存读写 token，若它们有不同价格，就应在归一化 usage 时保留这些维度，而不是提前合并丢失。预扣估算与真实结算的口径也要一致，否则差额会持续偏大或偏小。

限额要明确作用维度与故障语义

“限流”不是一个开关，而是多个维度的策略组合：

Key 或应用的请求数 / 预算；
单模型的 token 速率；
上游渠道的 RPM、TPM 或并发上限；
全局保护阈值。

每个维度解决的问题不同。应用预算用于控制消费，渠道配额用于保护上游，全局限流则用于防止自身资源被打满。实现时还要决定 Redis 或限流服务不可用时是 fail-open（尽量继续服务）还是 fail-closed（拒绝请求保护预算）。没有一种答案适合所有维度：一次营销活动的全局保护与一项严格预算控制，容忍的风险可能完全相反。

多实例限流通常需要共享状态。使用 Redis Lua 等原子操作可以把“检查额度并占用额度”合并成一个操作，避免多个实例同时读到旧值后一起放行。但原子性只解决并发竞态，不会自动解决窗口定义、时钟偏差、超额补偿和故障降级等策略问题。

脱敏应该定义清楚边界

把敏感内容送往外部模型前进行脱敏，可以降低不必要的数据暴露。但“用正则替换一下”并不等于完整的隐私保护：

识别规则可能漏报，也可能误伤普通文本；
替换后的占位符要能否回填，取决于业务语义；
多轮对话和流式输出会让替换范围更复杂；
日志、错误信息和调试追踪也可能意外保存原文。

一个相对清晰的处理流程是：在调用上游前识别敏感值，为需要保留语义的值生成不可预测的占位符映射；映射只在当前请求生命周期内使用；响应是否回填由明确策略决定；日志默认不记录原始敏感值。

该项目实现了手机号、身份证、邮箱、银行卡、IP 和密钥等类别的识别，并将占位符映射限制在内存中。它是一层风险降低措施，不是合规证明，也不能替代访问控制、数据保留策略或组织层面的隐私评估。

可观测性要服务于排障和核算

请求日志、审计事件和指标解决的问题不同：

请求日志帮助排查单次请求，但要避免记录凭据和完整敏感内容；
审计事件回答谁修改了渠道、价格或策略；
指标帮助观察总体趋势，例如延迟、错误率、限流、熔断、token 和成本。

指标标签要控制基数。模型名或渠道名可能是合理维度，但把 request ID、用户输入或 Key 放进标签，会让时序数据库的时间序列数量迅速膨胀。单次请求的细节应由日志或追踪承载，而不是无限加到指标标签里。

异步写日志能避免数据库变慢时阻塞推理热路径，但队列必须有容量上限，并明确满载时的行为：丢弃、采样、阻塞还是降级。对在线推理而言，“日志绝不丢”未必比“模型请求不被日志拖死”更重要；这需要根据审计要求决定。

把治理动作纳入同一条生命周期

一个治理型网关可以把关键状态变化整理成如下流程：

      text
      
    


1
2
3
4
5
6
7
8
9


鉴权与模型权限
    ↓
预算校验 / 额度预留
    ↓
隐私处理与上游调用
    ↓
读取真实 usage，结算或释放额度
    ↓
记录访问日志、审计事件与指标

请求链路中任何位置失败，都要知道此前占用过哪些资源，以及由谁负责释放。把清理和结算逻辑集中在一个幂等的终结路径上，通常比让每个错误分支各自退款更容易维护。

小结

模型网关的成本与安全治理，可以归纳为几条原则：

业务凭据与上游凭据分离，减少明文密钥暴露面；
将费用核算拆成预留和真实用量结算，并让状态变更可重试、可幂等；
按不同维度设计限额，并明确共享状态不可用时的策略；
把脱敏当作风险降低手段，而不是完整的隐私保证；
区分日志、审计和指标，既要能排障，也要保护敏感数据。

这些能力最终都要回答同一个问题：请求无论成功、失败还是中断，网关能不能解释发生了什么，并把占用的预算和资源妥善收尾。

项目地址：liku-yu/ai-gateway。

相关阅读：

AI 模型网关的通用架构：从 API 代理到推理治理层 —— 了解网关的整体职责与请求链路
多模型路由与故障恢复：重试、熔断和降级的边界 —— 了解上游选择与失败恢复的约束