多模型接入的凭证治理：虚拟 Key 架构与云上实践

团队接入多个大模型之后，最先失控的往往不是模型效果，而是凭证。

每个人的 IDE 配置里存着一份 API Key，每个项目组各自买订阅、各自记额度、月底对着几张账单对账；有人离职了，那把 Key 还在各个环境变量里生效；某个 Key 被泄露了，只能整把作废重发。这些问题的根源是同一个：凭证的治理粒度太粗。

这篇文章从凭证架构的角度拆解这个问题，并给出一种可行的解法——虚拟 Key 架构，以及它与云上基础设施的配合方式。

一、账号级凭证的结构性缺陷

大多数团队目前在用的凭证，本质上是"账号级凭证"：订阅账号或原始 API Key。这类凭证有两个结构性缺陷：

全有或全无。 一份凭证要么拥有全部权限，要么没有。你没法给测试环境签发一把"只能调用轻量模型、单日限额 100 万 Token"的 Key，只能把完整的 Key 复制出去，然后祈祷它不被滥用。

不可拆分、不可追溯。 一个 Key 被三个项目、五个人共用，出问题（超支、违规调用、泄露）时只能对着一个 Key 发问：是谁干的？查不到，因为凭证没有携带身份信息。

这和云账号体系早期的"主账号密钥满天飞"是同一个问题。云厂商的解法大家已经很熟悉：用 RAM 子账号 + 细粒度策略代替主账号密钥，用 KMS 托管密钥、定期轮换。AI 凭证治理，本质上是要把同样的治理粒度下沉到模型调用层。

二、从身份中解耦：策略级凭证

虚拟 Key 的核心，是把"凭证"从"身份"里解耦出来。

账号级凭证绑定的是"一个自然人/一个账号"；策略级凭证（虚拟 Key / Scoped Token）绑定的是一组策略——能用哪些模型、单日多少额度、在哪个环境生效、有效期多久。它不直接对应某个真实账号，而是对应一套授权规则。

账号级凭证：  Key_A  →  身份（某账号）  →  全部权限
策略级凭证：  Key_A  →  策略（模型白名单 + 配额 + 有效期 + 环境）

粒度细化之后，治理能力随之解锁：

• 按需签发：按项目、按成员、按环境签发不同策略的虚拟 Key
• 分钟级撤销：发现异常立即吊销单把 Key，不影响其他使用者
• 成本可归因：每次调用都携带凭证身份，谁用了哪个模型、花了多少 Token 一清二楚
• 风控前置：配额、白名单、异常调用拦截在请求发出前执行，而不是月底看账单

三、工程实现要点

虚拟 Key 架构在工程上由两部分组成：

控制面负责"定义"：签发与撤销凭证、配置策略、沉淀审计日志。它是凭证的权威来源，真实密钥集中托管在这里，不下发到任何终端。

执行面负责"执行"：在请求真正发出前完成身份校验、策略评估、路由与审计。它通常以本地代理、Sidecar 或网关形态存在，业务代码无需改动。

一次请求的完整链路如下：

# 执行面核心流程（伪代码）
def handle_request(virtual_key, target_model, payload):
    # 1. 身份校验：解析虚拟 Key，定位其绑定的策略
    policy = control_plane.resolve_policy(virtual_key)

    # 2. 策略评估：模型白名单 + 配额检查
    if target_model not in policy.allowed_models:
        raise PermissionError("model not allowed")
    if policy.quota.exceeded():
        raise QuotaExceededError("daily quota exceeded")

    # 3. 路由与转发：从凭证池选取真实凭证，调用上游
    upstream_cred = credential_pool.acquire(policy.provider)
    response = call_upstream(upstream_cred, target_model, payload)

    # 4. 审计：记录调用方、模型、Token、费用
    audit_log.write(virtual_key, target_model, response.usage)
    return response

对上层工具来说，虚拟 Key 与普通 API Key 的用法完全一致：填进 API_BASE 和 API_KEY 即可，IDE 插件、CLI、SDK 无需改造。区别只在 Key 背后——它是一份可管理、可撤销、可审计的策略，而不是一个裸账号。

四、与云上基础设施的协同

这套架构与云上已有的治理能力天然互补，而不是重复造轮子：

以阿里云为例：团队可以用百炼等模型服务平台承接统一模型接入，用 RAM 控制云资源访问，用 KMS 托管敏感密钥；而在模型调用这一层，虚拟 Key 架构补上了"凭证级"的治理粒度——这也是云上 IAM 和 API 网关没有覆盖到的最后一公里。

五、落地路径建议

如果团队正被多模型凭证管理困扰，不必一步到位，可以按这个顺序演进：

1. 先收敛：把散落在个人环境变量里的 Key 收拢到统一接入点，凭证池化
2. 再细化：按项目/成员签发虚拟 Key，配额和模型白名单生效
3. 后闭环：接入审计与成本归因，撤销流程常态化

值得提醒的是，接入点务必部署在自己的环境里、流量直连模型官方接口，避免经过任何第三方中转——"请求过一道手"带来的数据风险，比凭证管理问题本身更值得警惕。