公司已经买了 OpenAI 的企业合同，又申请了 Anthropic 的 API 访问，Claude、GPT 的 Key 各自散落在不同项目里——技术总监问"上个月 AI 花了多少钱"，没人能回答出来。这是 BYOK 网关要解决的问题。
什么是 BYOK？
BYOK 是 Bring Your Own Key 的缩写——你把自己的 API Key（OpenAI Key、Anthropic Key 等）交给网关，网关用你的 Key 去调用模型，你不用再让团队成员直接接触原始 Key。
和"共享模式"的区别在于：
- 共享模式：你充值给平台，平台用平台的 Key 调模型，你消耗平台的额度
- BYOK 模式：你把自己的 Key 交给平台，平台用你的 Key 调模型，费用直接从你的原始账单扣，平台只收一个通道费
如果你的公司已经和 OpenAI、Anthropic 签了企业合同，有批量折扣，那 BYOK 模式意味着你能拿到折扣价的同时，还能享受统一网关带来的管理能力——两头都不亏。
哪些场景适合 BYOK？
场景一：企业已有多家厂商的 Key
公司同时持有 OpenAI 企业 Key、Anthropic API Key、Google Vertex AI 凭证。这些 Key 分别由不同团队申请，格式各异，调用方式不同。直接分发给各业务组，每个组要自己维护 SDK 版本、错误处理逻辑、重试代码——重复劳动，而且一旦需要切换模型，改动面很大。
场景二：合规要求不能经过第三方
某些行业（金融、医疗）对数据流向有严格要求，不允许对话数据经过不受控的第三方服务。BYOK 模式下，网关可以部署在客户自己的私有云里，Key 和数据都不出内网。
场景三：成本归集和部门核算
AI 投入越来越大，财务部门开始要求按部门拆分成本。但 OpenAI 的账单只有一个总数，不知道哪个团队花了多少。BYOK 网关在中间加一层，天然适合做成本拆分和打标。
场景四：团队 Key 管理混乱
Key 直接写在.env文件里，提交到了 Git 仓库，或者员工离职时不知道哪些 Key 要轮换——这是很多中小团队的现状。统一走网关，所有人只拿到网关的 Key，原始厂商 Key 只在网关里存，权限清晰。
BYOK 的优势：统一格式、集中审计、用量监控
统一 API 格式
Anthropic 的/v1/messages和 OpenAI 的/v1/chat/completions格式完全不同。如果业务代码直接调原始 API，换一个模型等于改代码。
通过 BYOK 网关，所有模型都走同一个 OpenAI 兼容格式：
# 同一套代码，换模型只改 model 字段client=OpenAI(base_url="https://api.therouter.ai/v1",api_key="你的网关 Key",)# 调 Clauderesponse=client.chat.completions.create(model="anthropic/claude-sonnet-4",messages=[...])# 调 GPT，一行不用改response=client.chat.completions.create(model="openai/gpt-4o",messages=[...])集中审计日志
每一次 API 调用都在网关留下记录：调用时间、调用方（哪个 Key / 哪个应用）、使用的模型、Token 用量、耗时、是否报错。这些数据原始厂商的控制台不一定有，即使有也是各家分散的。
用这些日志你能回答：
- 某个业务线昨天调了多少次，花了多少钱？
- 生产环境哪个接口调用频率最高？
- 某次报警时间段，是哪个模型在报错？
用量监控和告警
给每个部门的 Key 设一个月度用量上限，超过 80% 时发告警，超过 100% 时自动拒绝请求——这类策略在各家原始 API 里几乎没有，需要自己造轮子。通过网关，这些变成配置项。
TheRouter BYOK 模式的工作原理
工作流程如下：
你的应用 | | (使用网关 Key) ↓ TheRouter 网关 |-- 鉴权：验证你的网关 Key |-- 路由：根据 model 字段选择上游 |-- 注入：替换成你绑定的厂商 Key ↓ OpenAI API / Anthropic API / ... | ↓ 响应原路返回关键步骤是"注入"：你的应用代码里只有网关的 Key，原始厂商 Key 只存在网关配置里。网关在转发请求时，把Authorization头换成你绑定的厂商 Key，你的应用和开发者从来不接触真实 Key。
配置方式：在 TheRouter 中绑定你的 Key
第一步：在控制台创建 Integration
进入 therouter.ai 控制台，找到Integrations（集成）页面，选择要绑定的厂商：
- OpenAI
- Anthropic
- Google Gemini
- 其他支持的厂商
输入你的厂商 API Key，保存。Key 会加密存储，控制台不会再以明文展示。
第二步：创建专用的网关 Key
为每个业务组或应用创建独立的网关 Key，并在创建时选择：
- 允许使用的模型范围（可以限制只能用某几个模型）
- 月度 Token 配额
- 绑定到哪个 Integration（决定用谁的厂商 Key）
第三步：业务代码接入
fromopenaiimportOpenAI# 这是你的网关 Key，不是厂商 Keyclient=OpenAI(base_url="https://api.therouter.ai/v1",api_key="tr-prod-xxxxxxxx",# 网关 Key 前缀为 tr-)response=client.chat.completions.create(model="anthropic/claude-sonnet-4",messages=[{"role":"user","content":"..."}],)就这三步。之后的用量、日志、费用统计，在控制台一目了然。
安全考虑
Key 加密存储
厂商 API Key 存储时使用 AES-256 加密，加密 Key 和数据 Key 分离存储。数据库泄露不会导致 API Key 明文泄露。
传输安全
所有请求走 TLS 1.3，网关到厂商 API 也是全程 HTTPS。Key 在传输过程中不以明文出现在任何日志里（日志记录 Key 的前 8 位用于追踪，不记录完整 Key）。
最小权限
给业务应用的网关 Key 只赋予它需要的权限：
业务应用 Key： - 只允许调用 anthropic/claude-sonnet-4 - 月度上限：50 万 tokens - 禁止访问管理类 API（Key 管理、账单查看）团队的管理员 Key 才有完整权限。这样即使业务 Key 泄露，攻击者也只能在配额内调模型，无法操作账户本身。
Key 轮换
厂商 Key 需要定期轮换（大多数安全规范要求 90 天一轮换）。BYOK 模式下，轮换操作只需要在网关控制台更新一次，所有使用该 Integration 的业务 Key 自动生效，不需要通知各业务组去改代码。
与共享模式的对比：成本结构差异
| 共享模式 | BYOK 模式 | |
|---|---|---|
| 定价 | 基础成本 + 平台溢价（通常 10-30%） | 你自己的厂商成本 + 平台通道费（固定费率，按用量或包月） |
| 适合场景 | 个人开发者、小团队、不想维护厂商账号 | 企业已有厂商合同、用量大、有折扣协议 |
| 账单 | 只需充值到平台，一张账单 | 厂商账单 + 平台账单分开，两笔费用 |
| 启动成本 | 低（注册即用） | 高（需要先申请各家厂商 API 访问权限） |
| 折扣 | 依赖平台的批量协议 | 直接享受你自己的企业折扣 |
什么时候 BYOK 比共享模式更划算？
简单算一笔账：假设你的月用量是 100 美元的模型费用（按原价计算），平台溢价是 20%，那么共享模式你要付 120 美元。如果 BYOK 平台通道费是每月 20 美元（固定），你实际付 100 + 20 = 120 美元，打平。
但如果你有企业折扣，原价 100 美元的用量你只需付 70 美元，那么 BYOK 总费用是 70 + 20 = 90 美元，省了 25%。用量越大、折扣越深，BYOK 的优势越明显。一般来说，月用量超过 500 美元时，BYOK 开始明显合算。
团队管理：多部门 Key 隔离和用量配额
实际落地时，一个典型的企业配置是这样的：
公司账户 ├── Integration: OpenAI 企业 Key ├── Integration: Anthropic API Key │ ├── Key: 产品团队-GPT4o │ ├── 绑定 Integration: OpenAI 企业 Key │ ├── 允许模型: openai/gpt-4o, openai/gpt-4o-mini │ └── 月度配额: 200 万 tokens │ ├── Key: 研发团队-Claude │ ├── 绑定 Integration: Anthropic API Key │ ├── 允许模型: anthropic/claude-sonnet-4, anthropic/claude-haiku-4 │ └── 月度配额: 500 万 tokens │ └── Key: 测试环境 ├── 绑定 Integration: OpenAI 企业 Key ├── 允许模型: openai/gpt-4o-mini （只用便宜模型） └── 月度配额: 50 万 tokens每个 Key 的用量在控制台可以独立查看，月底直接导出数据交给财务做内部核算。
如果某个 Key 的用量异常飙升（可能是 Bug 导致的循环调用），配额到了上限会自动返回429 Quota Exceeded，不会让费用无限增长。
一个容易忽视的问题：模型响应里的model字段
很多团队接入后会发现，调用anthropic/claude-sonnet-4，响应里的model字段返回的是原始模型名（比如claude-sonnet-4-20250514），和请求时的格式不一样。
这会影响日志聚合和成本归因。好的网关会把响应里的model字段标准化为你请求时用的模型 ID（anthropic/claude-sonnet-4），让你的日志和监控系统能正常工作。TheRouter 默认就是这个行为——响应里的model字段始终回显你请求的标准模型名，不管底层实际路由到了哪个版本。
小结
BYOK 不是一个复杂的概念，本质上就是"我有自己的 Key，但我想要一个更好的管理层"。它解决的核心问题是：
- 格式统一：不同厂商 API 格式差异对业务代码透明
- 集中管控：Key 不散落在各个代码库，统一在网关配置
- 可观测性：用量、成本、错误率一目了然
- 成本优化：有折扣协议的企业，BYOK 比共享模式更划算
如果你的团队现在还在各个项目里维护不同厂商的 SDK 和 Key，这是一个值得认真考虑的架构升级。
TheRouter 的 BYOK 接入：therouter.ai → 控制台 → Integrations → 添加你的厂商 Key。
