1. 多账号 AI 聊天系统为什么总在 Key 和模型路由上翻车公司内部要搭一个多账号 AI 聊天系统最开始的诉求往往很朴素一个 NextChat 前端配一个 OpenAI Key大家凑合用。用着用着问题就来了——有人要 Claude Sonnet 写长文有人要 DeepSeek-R1 做推理还有人只想用 GPT-4o 处理日常问答。于是 Key 从一个变成五个模型名从gpt-4o变成一堆带前缀的字符串前端配置里塞满了xxxOpenAI这种让人头大的写法。我见过最典型的翻车现场是这样的运维同事把三个厂商的 Key 分别写进 NextChat 的环境变量结果模型切换时前端不知道该用哪个 Key请求直接 401或者 LiteLLM 的config.yaml里模型名和 NextChat 的CUSTOM_MODELS对不上界面上能看到模型但一点就报model not found。更麻烦的是多账号场景——每个同事想要独立的调用额度、独立的模型权限如果共用一套 Key出了问题根本查不到是谁在用。LiteLLM NextChat 这套组合能解决的核心问题就是把「多厂商 Key 管理」和「多账号前端切换」拆成两层LiteLLM 做统一网关对外只暴露一个 Base URL 和一个 Key内部按模型名路由到不同厂商NextChat 做前端通过CUSTOM_MODELS控制每个账号能看到哪些模型。而 TaoToken 在这里扮演的角色是进一步把上游通道收敛成一个统一的 API 入口让你不用在config.yaml里维护一堆厂商的原始 Key而是用一套 TaoToken 的 Key 和 Base URL 就能覆盖 OpenAI、Anthropic、DeepSeek 等主流模型。这篇文章面向的是需要在内网或小团队里部署多账号 AI 聊天系统的开发者。你会看到完整的config.yaml骨架、NextChat 环境变量配置、Docker 网络隔离的坑、以及用 TaoToken 统一 Key 接入后的连通性验证动作。所有配置都可以直接复制改参数使用不需要你从零理解 LiteLLM 的源码。先说清楚这套架构的数据流NextChat3000 端口→ LiteLLM Proxy4000 端口→ TaoToken API 通道 → 各厂商模型。NextChat 只认 OpenAI 格式的接口LiteLLM 负责把 OpenAI 格式的请求翻译成各厂商的原生格式TaoToken 则提供统一的 Base URL 和 Key让 LiteLLM 不用为每个厂商单独配凭证。这样你新增一个模型时只需要在 TaoToken 侧确认通道可用然后在config.yaml里加一段model_list即可。2. TaoToken 统一 Key 接入 LiteLLM 的前置准备在动手写config.yaml之前先把 TaoToken 侧的凭证准备好。这一步的目标是拿到三样东西Base URL、API Key、以及你要用的模型 ID。这三样东西后面会分别填进 LiteLLM 的litellm_params和 NextChat 的环境变量里。先访问 TaoToken 官网 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 注册并登录然后在控制台里创建一个 API Key。创建路径是 console 页面进去之后找到 API Keys 管理点新建复制生成的sk-开头的字符串。这个 Key 就是后面 LiteLLM 用来调用 TaoToken 通道的凭证注意不要泄露到前端。Base URL 固定是https://taotoken.net/api这个地址不加任何 UTM 参数直接写进配置即可。模型 ID 需要你根据实际要用的模型去文档里查比如gpt-4o、claude-3-5-sonnet-20240620、deepseek-r1这些。TaoToken 的文档地址在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 里面有完整的模型列表和对应的调用名称。这里有个容易踩的坑LiteLLM 的model字段格式是provider/model_name比如openai/gpt-4o。但当你用 TaoToken 作为统一通道时provider 部分要写openai因为 TaoToken 对外暴露的是 OpenAI 兼容接口。也就是说即使你实际调用的是 Claude 或 DeepSeek在 LiteLLM 里也统一写成openai/模型ID然后在api_base里指向 TaoToken 的地址。这样 LiteLLM 就会用 OpenAI 的请求格式发出去TaoToken 侧再做转换。如果你需要长期跑编码类任务或者 Agent 工作流建议同时了解一下 Coding Plan地址是 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 它针对高频调用场景做了额度优化。不过对于本文的多账号聊天系统场景普通的 API Key 就够用了。准备好这三样东西后建议先在本地用 curl 验证一下 Key 是否可用避免后面配置写完了才发现是凭证问题。验证命令如下curl https://taotoken.net/api/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的TaoTokenKey \ -d { model: gpt-4o, messages: [{role: user, content: ping}] }如果返回正常的 JSON 响应说明 Key 和通道都没问题。如果返回 401检查 Key 是否复制完整如果返回 404检查模型 ID 是否写对。这一步验证通过后再往下走能省掉很多排查时间。3. LiteLLM config.yaml 与 NextChat 环境变量可复制配置骨架这一节给出完整的配置骨架包括 LiteLLM 的config.yaml、NextChat 的 Docker 启动命令、以及生产环境用的docker-compose.yaml。所有配置都基于 TaoToken 统一 Key 接入你只需要替换 Key 和模型 ID 即可。先看 LiteLLM 的config.yaml。这个文件的核心是model_list每一项定义一个对外暴露的模型名和对应的上游参数。model_name是 NextChat 里看到的名称litellm_params里的model是实际调用的模型 IDapi_base指向 TaoTokenapi_key填你的 TaoToken Key。model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_base: https://taotoken.net/api api_key: sk-你的TaoTokenKey - model_name: sonnet-3-5 litellm_params: model: openai/claude-3-5-sonnet-20240620 api_base: https://taotoken.net/api api_key: sk-你的TaoTokenKey - model_name: deepseek-r1 litellm_params: model: openai/deepseek-r1 api_base: https://taotoken.net/api api_key: sk-你的TaoTokenKey - model_name: o3-mini litellm_params: model: openai/o3-mini api_base: https://taotoken.net/api api_key: sk-你的TaoTokenKey litellm_settings: modify_params: true drop_params: true general_settings: master_key: sk-1234这里有几个关键点。master_key是 LiteLLM 自己的管理 KeyNextChat 用这个 Key 来访问 LiteLLM跟 TaoToken 的 Key 是两回事。modify_params: true和drop_params: true是为了兼容不同厂商的参数差异比如某些模型不支持temperature或top_pLiteLLM 会自动丢弃这些参数而不是报错。接下来是 NextChat 的 Docker 启动命令。这里用CUSTOM_MODELS控制界面上显示的模型列表-all表示先清空默认模型然后逐个添加。注意每个模型后面的OpenAI是告诉 NextChat 用 OpenAI 格式来调用因为 LiteLLM 对外就是 OpenAI 兼容接口。docker run -d -p 3000:3000 \ -e CODE123123 \ -e BASE_URLhttp://host.docker.internal:4000 \ -e OPENAI_API_KEYsk-1234 \ -e CUSTOM_MODELS-all,gpt-4oOpenAI,o3-miniOpenAI,sonnet-3-5OpenAI,deepseek-r1OpenAI \ yidadaa/chatgpt-next-webCODE是 NextChat 的访问码用户打开页面后需要输入这个码才能使用。BASE_URL指向 LiteLLM 的地址这里用host.docker.internal是因为 NextChat 和 LiteLLM 都在 Docker 里需要走宿主机的 DNS 解析。如果你在 Linux 环境下host.docker.internal可能不生效需要换成宿主机的实际 IP比如http://10.30.110.196:4000。生产环境建议用docker-compose.yaml统一管理这样两个容器在同一个网络里可以直接用服务名互相访问避免 IP 变化导致的问题。version: 3.8 services: litellm: image: ghcr.io/berriai/litellm:main-latest container_name: litellm ports: - 4000:4000 volumes: - ./config.yaml:/app/config.yaml command: --config /app/config.yaml restart: unless-stopped chatgpt-web: image: yidadaa/chatgpt-next-web container_name: chatgpt-web ports: - 3000:3000 environment: CODE: 123123 BASE_URL: http://litellm:4000 OPENAI_API_KEY: sk-1234 CUSTOM_MODELS: -all,gpt-4oOpenAI,o3-miniOpenAI,sonnet-3-5OpenAI,deepseek-r1OpenAI depends_on: - litellm restart: unless-stopped注意BASE_URL这里写的是http://litellm:4000用的是 Docker Compose 的服务名这样两个容器在同一个默认网络里可以直接通信不需要关心宿主机 IP。config.yaml和docker-compose.yaml要放在同一个目录下然后执行docker-compose up -d启动。如果你需要给其他同事提供 API 调用能力可以在 LiteLLM 前面加一层 Nginx 反代把https://litellm.yourdomain.com指向localhost:4000然后把 NextChat 的BASE_URL换成这个域名。这样外部调用和前端访问走同一个入口管理起来更清晰。4. 验证请求与多账号切换的连通性检查配置写完之后不要急着让同事用先自己做一轮连通性验证。验证的顺序是先确认 LiteLLM 能通 TaoToken再确认 NextChat 能通 LiteLLM最后确认多账号切换时模型列表和调用都正常。第一步直接请求 LiteLLM 的/v1/chat/completions接口看它能不能正确转发到 TaoToken。命令如下curl http://localhost:4000/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-1234 \ -d { model: gpt-4o, messages: [{role: user, content: 你好请回复ok}] }如果返回的 JSON 里有正常的choices字段和内容说明 LiteLLM 到 TaoToken 的链路是通的。如果报401检查master_key是否和请求头里的 Key 一致如果报model not found检查model_name是否和请求里的model字段匹配。第二步打开 NextChat 页面http://localhost:3000输入访问码123123进入设置页面确认BASE_URL和OPENAI_API_KEY已经正确填入。然后回到对话页面点击模型切换按钮看是否能看到gpt-4o、o3-mini、sonnet-3-5、deepseek-r1这四个模型。如果模型列表为空检查CUSTOM_MODELS的格式是否正确特别是-all前面的减号和每个模型前面的加号。第三步逐个切换模型发一条测试消息。比如切到deepseek-r1问一个推理问题切到sonnet-3-5让它写一段代码切到gpt-4o做日常问答。每个模型都返回正常结果说明多模型路由没问题。多账号场景的验证稍微复杂一点。NextChat 本身不提供账号体系多账号是通过多个访问码或者多个部署实例来实现的。如果你希望不同同事看到不同的模型列表可以部署多个 NextChat 容器每个容器用不同的CODE和CUSTOM_MODELS。比如给研发同事的实例只开放deepseek-r1和sonnet-3-5给产品同事的实例只开放gpt-4o。docker run -d -p 3001:3000 \ -e CODEdev123 \ -e BASE_URLhttp://litellm:4000 \ -e OPENAI_API_KEYsk-1234 \ -e CUSTOM_MODELS-all,deepseek-r1OpenAI,sonnet-3-5OpenAI \ yidadaa/chatgpt-next-web这样研发同事访问 3001 端口输入dev123只能看到两个模型产品同事访问 3000 端口输入123123看到四个模型。LiteLLM 侧不需要改动因为模型路由是在 NextChat 层控制的。如果你需要更细粒度的账号管理比如每个账号独立的调用额度那就要在 LiteLLM 侧配置key级别的权限。LiteLLM 支持在general_settings里定义多个 Key每个 Key 绑定不同的模型列表。不过这个属于进阶用法本文的多账号方案先用多实例 不同CUSTOM_MODELS来满足。验证过程中如果遇到 NextChat 页面一直转圈或者报network error大概率是BASE_URL的地址不对。在 Docker 环境下127.0.0.1和localhost指向的是容器内部不是宿主机所以必须用host.docker.internal或者宿主机的实际 IP。这个问题在下一节会详细展开。5. 本篇常见报错排查401、local proxy failed、reading choices、OAuth部署过程中最容易遇到的报错集中在四类401 鉴权失败、local proxy failed 网络不通、reading choices 响应格式异常、OAuth 相关错误。下面逐个拆解原因和修复动作。401 Unauthorized是最常见的。如果你在 NextChat 里发消息报 401先检查OPENAI_API_KEY是否和 LiteLLM 的master_key一致。NextChat 用这个 Key 访问 LiteLLMLiteLLM 再用 TaoToken 的 Key 访问上游两个 Key 不能混。如果你在 curl 请求 LiteLLM 时报 401检查请求头里的Authorization: Bearer sk-1234是否和config.yaml里的master_key完全一致包括大小写和空格。local proxy failed通常出现在 NextChat 容器无法连接 LiteLLM 容器时。报错信息类似connect ECONNREFUSED 127.0.0.1:4000。原因是 NextChat 容器里的127.0.0.1指向容器自身而不是宿主机。修复方法有两种一是把BASE_URL改成http://host.docker.internal:4000二是用docker-compose让两个容器在同一网络里BASE_URL写http://litellm:4000。如果你在 Linux 上host.docker.internal可能不生效需要在docker run时加--add-hosthost.docker.internal:host-gateway参数。reading choices报错一般是 LiteLLM 返回的响应格式和 NextChat 期望的不一致。完整报错可能是TypeError: Cannot read properties of undefined (reading choices)。这说明 LiteLLM 返回的 JSON 里没有choices字段通常是上游返回了错误信息但 LiteLLM 没有正确包装。检查config.yaml里的model字段是否写成了openai/模型ID的格式如果漏了openai/前缀LiteLLM 可能无法正确识别请求格式。另外检查 TaoToken 的 Key 是否有对应模型的权限如果模型不存在或无权访问上游会返回错误LiteLLM 转发后 NextChat 解析失败。OAuth 相关错误在 LiteLLM 里通常表现为OAuth token not found或authentication failed。如果你在config.yaml里配置了需要 OAuth 的厂商比如某些 Azure 或 Bedrock 场景但用的是 TaoToken 统一通道那就不需要配 OAuth。检查litellm_params里是否有多余的aws_access_key_id、aws_secret_access_key等字段这些在用 TaoToken 时应该全部删掉只保留model、api_base、api_key三个字段。如果你用的是 Claude Code 或者 Cline 这类工具配置里需要写全三件套Base URL、Key、Model ID。Base URL 填https://taotoken.net/apiKey 填 TaoToken 的sk-KeyModel ID 填文档里对应的模型名称。Cline 的 MCP 配置里如果出现local proxy failed检查 MCP server 的启动命令是否在容器内可执行以及网络是否能通到 LiteLLM。排查时建议打开 LiteLLM 的日志启动时加--detailed_debug参数可以看到每个请求的完整转发过程。NextChat 侧可以在浏览器开发者工具的 Network 面板里看请求的响应体通常错误信息会直接显示在响应 JSON 的error字段里。6. 长期运行与扩展从单机部署到团队共用通道单机跑通之后下一步要考虑的是长期运行的稳定性。LiteLLM 和 NextChat 都是无状态服务重启不会丢数据但config.yaml的变更需要重启 LiteLLM 才能生效。如果你经常新增模型建议把config.yaml挂载到宿主机目录改完配置后执行docker restart litellm即可。对于团队共用场景建议把 LiteLLM 的master_key换成更复杂的字符串不要用sk-1234这种默认值。NextChat 的CODE也建议每个实例用不同的值方便区分是谁在用。如果公司有 LDAP 或 SSO可以在 Nginx 层做统一认证NextChat 的CODE作为第二层保护。模型路由方面TaoToken 的统一通道让你不需要在config.yaml里维护多个厂商的原始 Key。新增模型时只需要在 TaoToken 控制台确认通道可用然后在model_list里加一段配置重启 LiteLLM 即可。NextChat 侧只需要在CUSTOM_MODELS里加上新的模型名重启容器后前端就能看到。如果你需要给外部系统提供 API 调用能力可以在 LiteLLM 前面加 Nginx 反代配置 HTTPS 证书然后把域名和 Key 发给调用方。调用方只需要知道 Base URL 和 Key不需要关心底层用的是哪个厂商的模型。这样整个团队的 AI 调用入口就收敛成了一个统一的网关Key 管理和模型路由都在 LiteLLM 侧完成。最后提醒一点config.yaml里包含 TaoToken 的 Key不要把这个文件提交到公开的 Git 仓库。建议用环境变量或者 Docker secret 来注入 Keyconfig.yaml里只写os.environ/TAOTOKEN_API_KEY这样的引用。LiteLLM 支持从环境变量读取api_key这样配置文件就可以安全地版本化管理了。