采购 AI API 额度批发服务时，不能只比较 Token 单价。多个项目共用一把 API key，容易让测试流量挤占生产额度，也会增加泄露后的损失与排障难度。接入 OpenAI、Claude、Gemini 等模型前，应把密钥分配、权限、预算和轮换流程纳入采购验收，而不是等调用失败后再补救。
采购前：先确认额度与密钥的边界
通过中转接口调用模型时，要区分平台余额、项目预算、速率限制和模型访问权限。余额充足不代表并发足够，也不代表所有模型均可调用。询价时应确认计费单位、输入与输出计费口径、失败请求处理方式，以及用量记录能否按项目核对；具体规则以服务协议和实际账单为准。
- 确认能否创建独立子密钥，以及是否支持停用、到期和权限限制。
- 确认预算是告警阈值还是强制限额，是否存在统计延迟。
- 确认请求速率、Token 速率和并发限制分别如何计算。
- 确认用量日志是否包含请求标识、模型、时间和计费明细，同时避免记录密钥。
接入时：按项目和环境拆分 API key
建议至少按生产、测试和开发环境隔离密钥；涉及多个客户或业务时，再按责任边界拆分。不要让所有应用共享管理员凭据。若平台不支持细粒度权限，可在自建网关增加模型白名单、调用鉴权和预算控制，但要验证这些限制是否真正生效。
API key 应保存在服务端密钥管理系统或受控配置中，不要写进浏览器代码、移动端安装包、公开仓库或工单截图。应用日志应脱敏请求头和配置内容。为每把密钥记录负责人、用途、所属环境、创建时间及依赖服务，才能在轮换时找到完整影响范围。
轮换时：先验证新 Key，再撤销旧 Key
常规轮换宜采用分阶段替换，而不是直接删除旧密钥。是否允许两把密钥短暂并存、是否支持即时撤销，需要事先确认，不能假设所有中转服务行为一致。
- 盘点旧密钥的调用方，包括定时任务、队列消费者、备用实例和部署流水线。
- 创建新密钥并配置必要权限、预算与模型范围，先以少量请求验证鉴权、流式响应和用量记录。
- 将新密钥灰度部署到部分实例，观察错误率、延迟和消费变化，再逐步扩大范围。
- 确认旧密钥不再承载正常流量后撤销，并检查后台任务是否出现失败。
出现异常时，可暂停发布并核查配置版本、接口地址及权限差异。若轮换原因是疑似泄露，应优先撤销受影响密钥，不能为了无感切换继续保留风险凭据；必要时暂时降级业务，并审计异常消费。
验收后：把错误处理与成本核对做成例行项
遇到 401 或 403，应结合响应体排查密钥、权限和模型授权；遇到 429，应检查速率、并发或额度限制，具体含义以接口文档为准。重试需设置退避、次数上限和超时，避免失败循环扩大费用。定期核对项目用量与账单，并测试停用密钥是否仍能调用。
在 openmagic.ai 规划 AI API 额度批发接入时，可用上述清单明确采购需求与验收标准。可追踪、可撤销、可核账的密钥管理，比单纯压低报价更有助于控制长期调用风险。