One API / New API 上游渠道配置:接入 OpenAI 兼容中转

三步配好一条上游渠道

结论先行:kkaiapi 是标准 OpenAI 兼容中转,在 One API 或 New API 里按普通 OpenAI 渠道接入,全程不改一行代码。 第一步,进入后台 渠道 > 添加渠道,类型选 OpenAI。不要因为要调 Claude 或 DeepSeek 就去选专有类型,走 kkaiapi 时所有模型统一用 OpenAI 协议。 第二步,代理(Base URL)填 https://api.kkaiapi.com,注意不带 /v1。网关会自动拼接 /v1/chat/completions,自己多写一层 /v1 会变成重复路径,渠道测试直接 404。密钥填 kkaiapi 控制台生成的 sk- 开头 Key。 第三步,模型列表填入需要的上游模型 ID:deepseek-v4-flash、deepseek-v4-pro、glm-5、kimi-k2.6、claude-sonnet-4-6、claude-opus-4-7、gpt-5.5。保存后点渠道测试,New API 用户记得把测试模型设为 deepseek-v4-flash 这类一定在列表里的 ID,避免默认测试模型不存在导致误判。保存前建议先在服务器上用 curl 直接验证 Key 和网络:

curl https://api.kkaiapi.com/v1/chat/completions \
  -H "Authorization: Bearer sk-你的Key" \
  -H "Content-Type: application/json" \
  -d '{"model":"deepseek-v4-flash","messages":[{"role":"user","content":"ping"}]}'

模型映射:对外名字稳定,上游随时可换

渠道编辑页的模型重定向是一个 JSON,key 是对外暴露的模型名,value 是实际发给上游的模型 ID。两个典型用法:一是兼容存量客户端写死的旧模型名,不用挨个改业务配置;二是给团队定一套内部别名,以后升级换代只改映射,下游无感。 一个高频踩坑点:映射里的对外名必须同时出现在渠道的模型列表中。One API 按请求里的模型名匹配渠道,列表里没有这个名字,请求根本进不了这条渠道,重定向自然不会生效。

{
  "deepseek-chat": "deepseek-v4-flash",
  "deepseek-reasoner": "deepseek-v4-pro",
  "gpt-4o": "gpt-5.5",
  "team-writer": "claude-sonnet-4-6"
}

倍率设置:补全倍率必须跟上游价差对齐

One API 的额度公式:消耗额度 = (输入 tokens + 输出 tokens × 补全倍率) × 模型倍率 × 分组倍率。模型倍率决定这个模型整体记账多贵,默认基准是 1 倍率对应每百万输入 tokens 2 美元;补全倍率决定输出 token 相对输入贵多少;分组倍率用来给不同用户组做折扣。 最容易亏钱的是补全倍率。它应当等于上游真实的输出单价除以输入单价,填低了,长回复、代码生成这类重输出流量的内部记账就会低于真实账单,月底对不上账。按 kkaiapi 当前价目换算,各模型补全倍率参考下表。模型倍率把输入价按你的记账基准换算即可,基准选多少不重要,全站一致就行。

把中转当上游:成本与稳定性怎么权衡

成本侧,自建网关加中转上游的组合把计费收敛到一个入口。kkaiapi 面向中文开发者,支付宝和微信直接充值,按量计费没有订阅费,DeepSeek、GLM、Kimi、Claude、GPT 一个余额全覆盖,省掉多家平台分别开户,也解决了 Claude 和 GPT 没有国内直购渠道的问题。下表是全文唯一价格出处,单位 ¥/1M tokens(输入/输出)。 稳定性侧,任何单一上游都是单点,自建网关的价值恰恰是把单点变成可调度的渠道池。实操上按以下清单落地:

• 主备双渠道:同一模型至少配两条渠道,kkaiapi 设为高优先级主渠道,官方或其它上游做兜底,New API 支持按权重和优先级调度。
• 自动禁用与重试:打开渠道失败自动禁用,上游连续报错时自动摘除,恢复后再启用,避免坏渠道持续吃请求。
• 盯住余额:kkaiapi 按量计费,余额耗尽即报错。在充值页 /topup 保持余额充足,配合网关的渠道告警,比事后翻日志省心。
• 固定测试模型:渠道测试模型统一设为 deepseek-v4-flash,防止默认测试模型不在上游列表引起误禁用。

常见问题