1. 从一次“账单对不上”说起New-API 渠道配置到底在解决什么如果你正在自建 New-API 聚合网关多半会遇到这样一个场景上游接了好几家模型服务客户端却只想用一个 Base URL 和一把 Key月底对账时发现网关账面消耗和厂商账单差了一截某条渠道突然限流下游请求直接 500。这些问题的根子基本都落在三件事上——渠道配置、模型倍率、负载均衡。New-API 是一个 OpenAI 兼容 API 聚合网关它把 DeepSeek、通义、智谱等各家格式各异的接口统一转换成一套/v1/chat/completions标准接口对外提供服务。客户端Cursor、Dify、LangChain不用改代码换模型只改模型名。它适合谁适合需要统一管理多家上游 Key、做内部成本分摊、又不想让每个使用者直接接触厂商密钥的团队。我这次实操的目标很明确把上游 endpoint 和鉴权集中管理同时用 TaoToken 的统一 Key/API 通道作为其中一条上游渠道接入验证多渠道调度是否真的能按权重分发、故障时能否自动切换。下面把渠道分组、倍率表、权重设置逐项拆开给出可复制的配置片段和一轮请求分发验证。先理清核心链路上游渠道各家官方 Key 或统一通道→ 网关中转 → 用户账号 → 账号下生成 API 密钥 → 客户端调用扣账号钱包余额。理解这条链路后面所有配置都不会迷路。2. TaoToken 前置准备统一 Key 与 API 通道怎么接进 New-API在配置 New-API 渠道之前先把上游侧准备好。TaoToken 提供统一的 API 通道官网入口是 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 基址为 https://taotoken.net/api 这个地址不加 UTM 参数直接用于程序调用。你需要先拿到一把可用的 Key。登录后进入控制台在 API Keys 页面创建密钥https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。创建时建议给密钥起一个能识别用途的备注比如newapi-upstream方便后续在 New-API 渠道里对应。密钥只在创建时完整展示一次复制后妥善保存。拿到 Key 之后先别急着往 New-API 里填用一条 curl 确认通道本身是通的curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoToken密钥 \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: ping}] }如果返回正常的choices结构说明 Key 和通道都没问题。这一步很关键——很多人把上游问题带进 New-API 里排查结果绕了一大圈才发现是 Key 本身失效。先隔离验证能省掉后面一半的排错时间。关于模型 IDTaoToken 的模型对话页可以查看当前可用模型清单https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。记下你要在 New-API 里映射的模型名比如claude-sonnet-4-5、gpt-4o这类后面配置渠道勾选模型时会用到。如果你后续要做长期编码或 Agent 类调用可以了解下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 它更适合高频、稳定的编码场景。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 遇到字段格式问题可以对照查。前置准备清单就三样一把 TaoToken Key、确认通道可用的 curl 结果、要映射的模型 ID。齐了再进 New-API。3. 可复制配置渠道分组、倍率表与权重设置这一节是全文的核心给出可以直接抄的配置。假设你的 New-API 部署在内网http://192.168.1.133:60002下面所有操作都在这个网关的管理后台完成。3.1 渠道配置片段JSON 形式New-API 的渠道本质是一条上游连接记录。以 TaoToken 作为上游为例关键字段如下。不同版本 UI 字段名略有差异但语义一致{ name: taotoken-claude, type: openai, base_url: https://taotoken.net/api, key: sk-你的TaoToken密钥, models: [claude-sonnet-4-5, claude-haiku-4-5], group: default, weight: 3, priority: 10, status: 1 }逐字段说明type选openai是因为 TaoToken 走 OpenAI 兼容协议base_url填https://taotoken.net/api注意不要多加/v1New-API 会自己拼接models是这条渠道对外提供的模型列表必须和你在 New-API 模型管理里启用的模型名一致weight是负载均衡权重数值越大分到的请求越多priority用于故障切换的优先级数值小的优先。如果你要接多家上游做冗余就复制这段改name、base_url、key和weight。比如再配一条官方 DeepSeek 渠道weight设 1TaoToken 设 3那么大约 75% 的请求走 TaoToken25% 走 DeepSeek。3.2 模型倍率表倍率是 New-API 里最容易理解错的概念。它不是“相对官方价格的倍数”而是每 1000 token 的记账单价。填 1 代表 1 元/1000 token。扣费公式消耗金额 (输入 token × 输入倍率 输出 token × 输出倍率) ÷ 1000自用场景下把倍率填成上游官方千 token 单价网关账面就尽量贴近上游账单。对外分发场景可以填大于官方的数值实现加价。默认值只是参考不会自动跟随厂商调价必须手动修正。模型输入倍率输出倍率说明claude-sonnet-4-50.0030.015按上游千 token 单价填写claude-haiku-4-50.00080.004轻量模型适合高频调用gpt-4o0.0050.015多模态场景deepseek-chat0.0010.002成本敏感型任务注意倍率只影响网关本地记账不能改变厂商真实扣费两者之间会存在少量 token 统计偏差这是正常的。对账时以厂商账单为准网关账面用于内部分摊。3.3 权重与故障切换设置负载均衡和故障切换都依赖“同一模型有多条渠道”。只有多条渠道勾选了相同模型网关才会在它们之间分发。权重轮询的逻辑是请求按weight比例分配。故障切换的逻辑是某条渠道出现超时、限流、密钥失效时网关自动把请求转发到其他可用同模型渠道下游无感知。priority决定切换顺序weight决定正常时的流量比例。配置建议主力渠道weight设高、priority设小备用渠道weight设低、priority设大。这样正常时主力扛量主力挂了备用顶上。3.4 账号与 API Key 关联API Key 隶属于用户账号扣费扣所属账号的钱包余额密钥本身没有独立钱包。推荐流程是管理员先创建子账号并分配额度使用者登录自己账号自行生成 API Key。不推荐管理员生成密钥再分发那样密钥管理权在管理员手里既不安全也不方便用户自主管理。同一账号可以创建多个 API Key共享该账号钱包余额每个密钥还能单独设置消费上限。调用日志里可以看到密钥归属的用户 ID方便追责和分摊。4. 验证请求一轮分发测试与失败重试观察配置完不验证等于没配。这一节给出一轮完整的请求分发验证以及故障切换的观察方法。4.1 基础连通测试先用 curl 打一条请求确认网关到上游整条链路是通的curl http://192.168.1.133:60002/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的网关密钥 \ -d { model: claude-sonnet-4-5, messages: [{role: user, content: 做接口测试}] }返回正常choices就说明链路通了。注意这里的sk-是 New-API 生成的网关密钥不是 TaoToken 的 Key两者别搞混。4.2 分发验证连续打 20 条看比例要验证权重是否生效连续发多条请求然后去【使用日志】里看每条请求命中了哪条渠道。写个小循环for i in $(seq 1 20); do curl -s http://192.168.1.133:60002/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的网关密钥 \ -d {model:claude-sonnet-4-5,messages:[{role:user,content:test}]} \ -o /dev/null -w %{http_code}\n done20 条打完进【使用日志】按渠道筛选。如果 TaoToken 权重 3、DeepSeek 权重 1理论上大约 15 条走 TaoToken、5 条走 DeepSeek。实际会有波动但比例大致对得上就说明权重生效了。4.3 故障切换观察想验证自动切换可以临时把主力渠道的 Key 改错或者把status置为禁用然后再打请求。正常情况下请求不会报错而是被转发到备用渠道。日志里会显示命中了备用渠道下游客户端完全无感知。这一步建议在测试环境做别在生产上直接改主力渠道。观察完记得把配置改回来。4.4 对接客户端验证通过后把网关地址填进客户端Base URLhttp://192.168.1.133:60002/v1API Key网关生成的sk-密钥Model已启用的模型名如claude-sonnet-4-5Cursor、Dify、LangChain 都是这套填法。Dify 里选 OpenAI 兼容供应商把 Base URL 换成网关地址即可。5. 本篇常见错排查401、local proxy failed 与 reading choices配置过程中最容易撞上的几类报错逐个拆。401 Unauthorized九成是 Key 填错或没带。检查三处——客户端填的是不是网关sk-密钥New-API 渠道里填的是不是 TaoToken 的 Key请求头Authorization: Bearer有没有漏。如果渠道测试成功但客户端 401问题在客户端侧如果渠道测试就 401问题在上游 Key。local proxy failed / connection refused网关到上游连不通。先确认base_url没写错TaoToken 是https://taotoken.net/api不要多加/v1。再确认网关服务器本身能访问外网。内网部署的网关如果没配好出网所有上游都会连不上。reading choices 报错 / 返回结构异常通常是上游返回了非标准结构或者模型名对不上。检查渠道勾选的模型和请求里的model是否一致。如果用了 TaoToken 的 Claude 模型确认模型 ID 拼写正确去模型对话页核对https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。OAuth / 鉴权格式错误有些上游要求特定的鉴权头格式。TaoToken 走标准 Bearer如果报鉴权格式错检查是不是把 Key 填到了错误的字段或者type选错了。模型不存在渠道没勾选该模型或模型管理页没启用。两处都要确认。账面金额和官方账单对不上核对模型倍率配置。token 统计存在少量偏差属于正常倍率填错才是大问题。外网访问失败192.168.1.133是内网地址只有局域网设备能访问。需要外网访问就做公网部署或内网穿透。排错的核心入口是【使用日志】它会显示每次调用的 token、消耗和上游返回的原始报错。遇到问题先看日志比盲猜快得多。6. 把统一 Key 接入长期用起来CTA 与后续维护渠道配好、倍率填对、权重设好之后这套多渠道路由方案就能稳定跑了。日常维护主要盯三件事上游调价时手动更新倍率、渠道失效时看日志定位、余额不足时及时充值。如果你还没准备好上游 Key可以从 API Keys 页面创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite 。接入过程中遇到字段或格式问题对照接入文档https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite 。想先验证模型效果用模型对话页试跑https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodelsutm_campaignrewrite 。长期做编码或 Agent 调用Coding Plan 更合适https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite 。最后留一个实操习惯每次改完渠道或倍率都打一轮 20 条请求验证分发比例再去日志里核对。配置改动不验证等于给自己埋雷。这套流程跑顺之后多渠道路由的维护成本会低很多。