AI 功能的自带密钥 (BYOK):没人预估过成本的销售驱动型架构重构
你正在对接的采购团队最终会提出一个重置你架构的问题:“我们可以自带模型 API 密钥吗?”回答“可以”能赢得订单。但回答“可以”同时也意味着你的信任边界、成本边界和运营边界发生了转移 —— 而大多数产品团队只有在合同签署、第一个月的使用产生了一个没人知道如何回答的服务工单后,才会发现这一点。
BYOK 在公司内部推销时被视为一个开关。客户粘贴一个密钥,你的代码从保险库(Vault)读取它而不是从你自己的账户读取,然后推理流程照常进行。但这并不是一个开关。这是一场由销售驱动的架构重构,它会波及成本分摊、安全事件响应、可观测性、速率限制、模型版本锁定以及值班问责。那些在没有意识到这一点的情况下就交付产品的团队,最终会在一年后为了修复这些问题而重构整个平台层,而付费企业客户则在焦急等待。
这是一个设计空间,而非单一设计
第一反应是将 BYOK 视为一个功能。它至少包含两个功能,且它们之间几乎没有任何关系。
供应商 API 密钥 BYOK 是企业采购部门实际要求的。客户希望他们的 OpenAI、Anthropic 或 Bedrock 账户能为你产品生成的 Token 负责,这既是为了成本核算,也是为了纳入他们自己与供应商的合同关系中。Token 账单流向他们。供应商的日志流向他们。他们安全团队的数据外泄监控覆盖的是他们的密钥,而不是你的。
加密密钥 BYOK 是如果你的产品处理的数据涉及 PII、PHI 或财务记录时,他们的合规团队会要求的。他们的 HSM 持有封装你平台存储的关于他们数据的密钥。他们可以撤销。没有他们的配合,你无法解密。这个版本能让他们在 HIPAA 的加密安全港条款下,于数据泄露通知中幸免于难,因为云供应商持有的只是你无法解密的密文。
这两者在路线图讨论中经常被混为一谈,因为缩写相同。但实现工作却大相径庭。在工程团队评估范围之前,销售应该弄清楚客户到底在问哪一个。
在供应商密钥 BYOK 内部,还存在第二个比营销材料中描述的更为重要的设计选择:透传(Pass-through)对比带有保险库的代理(Proxy-with-vault)。在透传架构中,客户的 API 密钥在每次调用时直接呈现给供应商。客户可以在他们自己的供应商仪表盘中看到每一次请求。在带有保险库的代理架构中,你将密钥保存在自己的 KMS 中,在网关处按客户划分范围,并代表他们调用供应商。客户的仪表盘看到的是聚合数据,而你的网关能看到细节。
透传对于信任来说更纯粹(“我们在摄取后从 未看到过你的明文密钥”),但对于可观测性来说更难 —— 你无法在追踪(Traces)中丰富那些你无法访问的供应商侧延迟或 Token 计数。代理对于产品功能(缓存、后备路由、判定校准)更纯粹,但这意味着你的安全审查必须证明网关作为一个凭据保险库的安全性。
第三个选项是虚拟密钥,这是成熟的网关平台最终会趋同的方向:客户真实的供应商凭据存在你的保险库中,而你的应用程序代码永远看不到它。应用程序代码引用一个工作区范围(Workspace-scoped)的 Token,网关在调用时对其进行解析。这是唯一能让你实现按客户速率限制、按客户预算执行以及通过配置更改切换供应商的设计。它也是构建成本最高的设计。
成本分摊:你无法发现的 Bug
一旦 BYOK 落地,单位经济效益就会发生变化。客户支付推理费用。你仍然支付其他一切费用 —— 工程、可观测性、支持、网关、评估集、评测模型、缓存基础设施。你的定价模型必须反映这一点,否则你就是在免费提供平台。
定价方案已基本趋同。可预测的平台费(按席位、按工作区或按活跃用户)覆盖运营成本。使用费组件(按 API 调用、按 Agent 运行、按结果)覆盖你仍在运行的部分的可变成本。推理账单则由他们支付。2026 年成熟的 AI SaaS 定价通常是这种混合模式的某种形式。那些将 BYOK 定价为单纯节省推理费用的公司,现在正计划在下一个合同周期增加平台费,并向客户解释其中的差异。
架构成本则更为隐蔽。成本分摊的可观 测性必须重建。在托管密钥下,你可以看到每一个 Token,将其归属于某个客户,并能回答“账单激增是 Bug 还是功能”。在 BYOK 下,客户在他们自己的供应商仪表盘上看到账单激增,并问你为什么。你不再拥有每个客户 Token 消耗的完整视图,因为透传追踪不包含他们的成本细节,而带有保险库的代理追踪包含你的成本细节,但不包含供应商侧的账务。
这种失败模式通常在发布六个月后显现。客户的 CFO 打来电话,账单翻了三倍。是使用量增长了吗?还是你的代码出了 Bug,正在用他们的钱产生长路径的重试循环?或者是 Prompt 回归导致补全长度增加了 40%?你无从得知,因为你构建的遥测系统锚定在自己的成本核算上,而成本核算已经移出了你的系统。那些在没有重建每个客户成本遥测原语(Token 计数、Prompt 大小、补全大小、重试率、工具调用次数、Agent 循环深度)的情况下就交付 BYOK 的团队,会发现他们已经失去了调试自己产品经济模型的能力。
- https://www.augmentcode.com/guides/byok-enterprise-agent-rollouts
- https://developers.cloudflare.com/ai-gateway/configuration/bring-your-own-keys/
- https://vercel.com/docs/ai-gateway/authentication-and-byok/byok
- https://github.blog/changelog/2026-01-15-github-copilot-bring-your-own-key-byok-enhancements/
- https://openrouter.ai/docs/guides/overview/auth/byok
- https://www.lockllm.com/blog/BYOK-vs-managed-keys
- https://www.command.ai/blog/ai-saas-pricing/
- https://www.requesty.ai/blog/security-compliance-checklist-soc-2-hipaa-gdpr-for-llm-gateways-1751655071
- https://www.trendmicro.com/en_us/research/26/c/inside-litellm-supply-chain-compromise.html
- https://futureagi.com/blog/litellm-compromised-incident-response-migration-guide/
- https://www.getmonetizely.com/blogs/the-2026-guide-to-saas-ai-and-agentic-pricing-models
