目前不提供发票。适合能以技术服务或预付余额方式入账的团队;采购流程对发票有硬要求的,请在接入前先和财务确认这一点是否可接受,别等到报销环节才发现。

一个账户能建几把 key?该怎么拆?

当前每个账户最多同时持有 10 把,不够时先吊销闲置的再建新的。拆的原则是按「泄漏半径」而不是按人头:生产服务一把、CI/测试一把、每个高频项目或成员各一把,这样任何一把出问题只需吊销它,不影响其他线。

月底怎么把成本分摊到各项目?

前提是逐笔流水带模型名和 token 数(可导出)。做法是导出后按 key 前缀聚合,所以建 key 时就要按「用途-归属」规范命名,比如 proj-alpha、ci-bot。建议再按模型聚合一次,能直接看出哪个项目在拿旗舰型号跑杂活。

迁移要改多少代码?

两个参数:base_url 指到 https://cocodot.co/api/ai/v1(末尾 /v1 必须带,漏了全部 404)、api_key 换成新建的 key,其余不动。各语言官方 SDK 和支持自定义 OpenAI 接口的工具填的都是这一组。但别因为改动小就直接切生产,先在测试环境用真实任务跑一周。

有并发或速率限制吗?

常规团队用量不设额外限制。每分钟数千请求这个量级的需求,建议先联系我们评估容量再上线,别直接把大流量切过来。

怎么确认拿到的是真模型、不是套壳?

不用靠信任,直接测。我们把检测工具开源了(probe.cocodot.co),从能力指纹验证模型真伪,对任何供应商都可用,包括拿来测我们自己。另外标价与实扣是否一致、失败调用扣不扣钱,都可以小额跑十笔逐笔核对。

企业方案更新于 2026-10

企业/团队接入大模型 API 实操:统一余额、分项目 key、逐笔可审计(2026)

国内团队接海外大模型 API 的三个企业级问题:怎么付钱、怎么管多项目用量、月底怎么对账。一个账户最多 10 把命名 key、共享余额、逐笔账本,支付宝充值,一个 OpenAI 兼容接口。

一句话结论:团队用大模型 API,痛点从来不是「能不能调通」,而是三件管理层面的事:付款(海外卡、外汇、采购流程走不通)、隔离(多项目多成员共用一把 key,泄漏范围和用量归属都说不清)、对账(月底财务问这笔钱花哪了,答不上来)。对应的做法是三层:付款上用支付宝充值成统一余额,按 token 后付,不需要海外卡;隔离上建多把命名 key(当前每个账户最多同时持有 10 把),按项目或成员拆开,某一把泄漏只吊销那一把,不影响其他线;对账上账本逐笔可查,每次调用的模型和输入输出 token 都在流水里,导出即审计底稿。接口是 OpenAI 兼容的,现有代码改 `base_url` 和 `api_key` 两个参数即可迁移。先说清楚边界:目前不提供发票,对发票有硬要求的采购流程请先评估。

1. 团队接入真正卡住的三件事

技术上「调通一个大模型 API」是十分钟的事,团队用起来之后卡住的从来是别的:① 付款——官方渠道要求绑一张能过风控的海外卡,国内团队常卡在这里,而且公司采购走对公流程时,一张个人海外卡本身就不合规;② 隔离——最初图省事全团队共用一把 key,等到用量涨起来,你既说不清哪个项目花了多少,也不敢轻易换 key(一换全线中断),某天 key 泄漏更是只能全线停机;③ 对账——月底财务拿到一个总数,问「这笔钱花在哪了」,如果供应商只给你一个余额变化,你答不上来。下面三节分别对应这三个问题。

2. key 怎么拆:按「泄漏半径」而不是按人头

拆 key 的原则不是「一人一把」,而是按泄漏半径拆——出事的时候,吊销这把 key 会中断多大范围的业务?按这个思路,推荐的拆法是:生产服务一把、CI/测试一把、每个高频使用的项目或成员各一把。这样任何一把出问题(泄漏、被滥用、被误提交到仓库),吊销它只影响那一条线,其余照常跑。当前每个账户最多同时持有 10 把 key,对绝大多数团队够用;不够时先吊销闲置的再建新的,而不是让所有人挤一把。特别提醒:生产环境的 key 一定要单独一把,并且不要出现在任何开发者的本机上,这是隔离能否生效的前提。

3. 命名规范:三个月后你会感谢自己

这一步只花五分钟,但决定了后面对账做不做得动。建 key 的时候就按规范命名,别想着以后再整理——事后你根本认不出哪把是哪把。推荐格式是「用途-归属」,比如 `prod-api`、`ci-bot`、`proj-alpha`、`dev-alice`。这样做的直接好处有两个:① 成本归集时可以按前缀聚合,`proj-` 开头的加起来就是各项目成本;② 排查异常时能立刻定位,看到某把 key 用量突增,名字直接告诉你该找谁。反过来,如果你的 key 叫「key1、key2、新建的key」,三个月后做成本分摊就只能靠猜。这是那种「现在花五分钟、以后省半天」的事,值得在接入的第一天就定下来。

4. 成本怎么归集到项目

所有调用落在同一本流水里,每笔带模型名和 token 数,这是能做成本归集的前提——如果供应商只给你一个总额、没有逐笔明细,那么无论用什么方法都对不出各项目花了多少。有了逐笔数据,月底的动作就很机械:导出流水 → 按 key 前缀聚合 → 得到各项目成本表。建议同时按模型再聚合一次,因为这一维度会直接暴露优化空间:如果某个项目大量调用旗舰型号跑的却是分类、抽字段这类杂活,那就是明确的降本机会。关于怎么按任务难度分配模型,可以参考 /hub/llm-cost-optimization-2026,那套三层路由方法通常是团队降本里 ROI 最高的一步。

5. 迁移成本接近于零,但要先小额验证

接口是 OpenAI 兼容的,迁移只改两个参数:`base_url` 指到 `https://cocodot.co/api/ai/v1`(末尾这个 `/v1` 必须带,漏了会全部 404,这是最高频的配置错误)、`api_key` 填你新建的 key,其余代码不动。各语言的官方 SDK、以及支持自定义 OpenAI 接口的编辑器和客户端,填的都是这同一组参数。但别因为迁移简单就直接切生产:企业采购最贵的从来不是单价,是切换成本和踩坑成本。推荐的节奏是——先小额充值,在测试环境用你自己的真实任务跑一周,观察延迟、成功率、返回质量和计费是否与标价一致,确认没问题再灰度切生产流量。

6. 别信宣传,自己实测

这个行业最大的信任问题是「降智」——你付了旗舰模型的钱,拿到的可能是更便宜的替代品。这件事不需要靠信任,可以直接测:我们把检测工具开源了(probe.cocodot.co),从能力指纹上验证返回的到底是不是你点的那个模型,而且它对任何供应商都可用,包括拿来测我们自己。企业采购时把它放进 checklist,一小时就能消除最大的那块不确定性。除此之外还有几项也都能自己验:标价与实际扣费是否一致(小额跑十笔逐笔核对)、失败的调用扣不扣钱、逐笔明细是否可导出。完整的验证方法见 /hub/how-to-choose-api-relay-vendor。

7. 能力边界:先说不支持什么

按我们自己那份清单的第六条,这里如实写明边界,免得你接完才发现:① 目前不提供发票——适合能以技术服务或预付余额方式入账的团队,采购流程对发票有硬要求的请先评估,这一条我们写在最前面而不是藏在条款里;② 超大并发需要提前评估——常规团队用量不设额外限制,但每分钟数千请求这个量级的需求,建议先联系我们确认容量再上线;③ 不同型号的能力和计价方式有差异,包括是否有长上下文阶梯价、是否属于会先生成推理过程的型号,接入前按你要用的型号逐个确认;④ 数据方面我们是转发通道,不存储调用内容,敏感场景仍建议脱敏后调用,与直连官方 API 的数据实践一致。

8. 上线前的自检清单

把上面的内容压成一份可以直接过的清单:① key 已按泄漏半径拆开,生产环境单独一把且不在任何开发者本机;② key 命名符合规范,能按前缀聚合;③ key 走环境变量,不在前端代码里,也确认过没有被提交进代码仓库(记得搜历史提交,删掉了也还留着);④ `base_url` 末尾带 `/v1`;⑤ 已在测试环境用真实任务跑过一周,延迟、成功率、计费都核对过;⑥ 已确认所用型号的计价细节(阶梯价、是否推理型号);⑦ 调用侧加了超时和重试,长回答走流式输出;⑧ 余额告警已配置,避免余额耗尽导致业务中断;⑨ 发票这一条已和财务确认过,不要等到报销时才发现问题。

企业接入的三个层次

层次	做法	解决什么	注意
付款	支付宝充值成 USD 余额,按 token 后付	不需要海外卡和外汇流程	目前不提供发票
隔离	按项目/成员建命名 key(最多同时 10 把)	泄漏只需吊销一把;用量按 key 可拆	建时就规范命名,别事后补
审计	逐笔流水记录模型与 token 数	财务对账、成本归集有底稿	导出后按 key 前缀聚合
迁移	改 base_url 与 api_key 两个参数	现有 SDK 和工具链不用动	base_url 末尾必须带 /v1
验证	小额充值在测试环境跑一周	切换成本前置到验证阶段	别一上来就切生产