★ FEATURED ARTICLE 1. 源码部署 LiteLLM 后 Base URL 指向 TaoToken 的完整接入思路源码部署 LiteLLM 之后很多人会卡在同一个地方Proxy 本身跑起来了/health也返回正常但真正发一条 chat 请求时日志里看到的还是默认的 OpenAI 上游或者干脆报AuthenticationError。原因通常不是 LiteLLM 装错了而是上游通道没换。LiteLLM 作为统一网关它的价值在于把不同厂商的模型收敛到一个入口而入口背后指向谁完全由model_list里的api_base和api_key决定。把这两个字段改到 TaoToken 的统一通道就能让自部署的 LiteLLM 用一套 Key 调度多个模型省去在.env里堆一堆厂商密钥的麻烦。这篇内容面向已经完成 LiteLLM 源码部署、正在做上游接入的自部署用户。我会把两种写法都写清楚一种是纯环境变量方式适合快速验证另一种是config.yaml的model_list写法适合长期维护。两种方式都会给出可直接复制的 Base URL、API Key 片段以及用curl和 LiteLLM 自带日志确认请求确实走通 TaoToken 的步骤。TaoToken 在这里扮演的是统一 Key/API 通道的角色LiteLLM 负责路由、限流、缓存和日志两者职责不重叠。需要先明确一个概念LiteLLM 的api_base是「上游 OpenAI 兼容端点」不是 LiteLLM 自己的监听地址。很多人把--port 18001和api_base搞混结果请求打回自己形成环回。TaoToken 的 API 端点是https://taotoken.net/api在 LiteLLM 里要写成https://taotoken.net/api作为api_base模型名按 TaoToken 支持的名称填。下面从环境准备开始一步步把配置落到文件里。2. TaoToken 前置准备与 LiteLLM 环境变量接入方式在改 LiteLLM 之前先把 TaoToken 这边的 Key 拿到。登录官网https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content进入控制台的 API Keys 页面创建一个 Key。这个 Key 就是后面 LiteLLM 里要填的api_key格式通常以sk-开头。创建时建议给它起一个能识别用途的名字比如litellm-proxy-prod方便以后在控制台按项目排查用量。拿到 Key 之后不要直接写进config.yaml提交到 Git先放在.env里用os.environ/引用。TaoToken 的接入文档在https://taotoken.net/doc里面会列出当前支持的模型 ID 和对应的调用方式。LiteLLM 走的是 OpenAI 兼容协议所以模型名直接填 TaoToken 文档里的名称即可不需要加openai/前缀以外的额外转换。如果你之前用的是openai/gpt-4o这种写法把api_base换成 TaoToken 之后model字段保持openai/前缀LiteLLM 会按 OpenAI 协议发请求TaoToken 侧按模型名路由。环境变量方式适合先跑通链路。编辑/data/litellm/.env在原有内容基础上追加 TaoToken 相关变量。注意.env里不要出现明文密码提交到仓库权限收紧到600。下面这段可以直接复制把your-taotoken-key换成你刚创建的 Key# TaoToken 统一通道 TAOTOKEN_API_BASEhttps://taotoken.net/api TAOTOKEN_API_KEYyour-taotoken-key # 让 LiteLLM 默认走 TaoToken可选用于快速验证 OPENAI_API_BASEhttps://taotoken.net/api OPENAI_API_KEYyour-taotoken-key这里有个细节LiteLLM 在model_list没显式指定api_base时会回退到OPENAI_API_BASE。所以如果你只是想快速验证把OPENAI_API_BASE指向 TaoToken 就能让默认的 OpenAI 模型走 TaoToken。但生产环境不建议依赖这个回退因为一旦你同时接了别的厂商默认值会互相干扰。更稳妥的做法是在config.yaml的每个model_list条目里显式写api_base。改完.env后重新加载环境变量确认变量生效cd /data/litellm set -a; source .env; set a echo $TAOTOKEN_API_BASE echo $TAOTOKEN_API_KEY | head -c 8第二条命令只打印 Key 的前 8 位避免完整 Key 出现在终端历史里。如果输出是https://taotoken.net/api和sk-xxxxx说明环境变量已经就位。接下来进入config.yaml的写法这是长期维护推荐的方式。3. config.yaml 中 model_list 指向 TaoToken 的可复制配置LiteLLM 的config.yaml里真正决定上游的是model_list下的litellm_params。model_name是调用方看到的名字litellm_params.model是实际发给上游的模型标识api_base和api_key决定请求发到哪里。把这三个字段配好LiteLLM 就会把请求转发到 TaoToken。下面是一段可以直接放进config.yaml的model_list覆盖了 chat 和 embedding 两类常用模型路径与 LiteLLM 源码部署时的config.yaml一致model_list: - model_name: gpt-4o litellm_params: model: openai/gpt-4o api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY rpm: 1000 tpm: 200000 model_info: max_input_tokens: 128000 base_model: openai/gpt-4o - model_name: gpt-4o-mini litellm_params: model: openai/gpt-4o-mini api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY rpm: 2000 tpm: 400000 model_info: max_input_tokens: 128000 base_model: openai/gpt-4o-mini - model_name: text-embedding-3-small litellm_params: model: openai/text-embedding-3-small api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY model_info: base_model: openai/text-embedding-3-small注意api_key写的是os.environ/TAOTOKEN_API_KEY不是明文。LiteLLM 启动时会去读环境变量所以.env里必须有TAOTOKEN_API_KEY。如果你在.env里用的是OPENAI_API_KEY这里就改成os.environ/OPENAI_API_KEY两者保持一致即可。api_base统一写https://taotoken.net/api不要带尾部斜杠LiteLLM 拼接路径时自己会处理。如果你想让 LiteLLM 的 Router 在多个 TaoToken 部署之间做负载均衡可以在model_list里对同一个model_name写多条用weight区分权重。比如两条gpt-4o一条weight: 9一条weight: 1Router 会按权重分发。但要注意TaoToken 侧本身已经做了通道调度除非你有明确的灰度需求否则单条配置更简单排障时也少一层变量。config.yaml里还有几个和上游相关的设置值得一起改。litellm_settings.drop_params: true建议保持开启因为不同模型对参数支持不一致TaoToken 侧如果遇到不支持的参数会直接报错开启后 LiteLLM 会自动丢弃。router_settings.num_retries可以设成 2 到 3配合cooldown_time当某个上游短暂抖动时自动重试。这些设置不改变 Base URL但会影响接入后的稳定性建议一并检查。改完config.yaml后用 LiteLLM 自带的配置校验命令先过一遍避免 YAML 缩进错误导致启动失败cd /data/litellm conda activate litellm litellm --config config.yaml --detailed_debug --port 18001--detailed_debug会打印每个请求实际使用的api_base这是后面验证链路的关键。如果配置有语法错误启动阶段就会报yaml.scanner.ScannerError或ValidationError按提示改缩进即可。确认能启动后用CtrlC停掉再用start.sh后台运行。4. 用 curl 与 LiteLLM 日志验证请求确实走通 TaoToken配置改完不等于链路通了必须用实际请求验证。验证分两层第一层是直接打 LiteLLM 的 Proxy 端点看它是否返回正常响应第二层是看 LiteLLM 日志里api_base是不是https://taotoken.net/api。两层都过才能确认请求确实走通 TaoToken而不是被回退到别的上游。先确认 LiteLLM 在监听。假设你按start.sh用--port 18001启动LITELLM_MASTER_KEY是sk-your-master-key。用 curl 发一条 chat 请求模型名用config.yaml里定义的gpt-4ocurl -s http://127.0.0.1:18001/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-master-key \ -d { model: gpt-4o, messages: [{role: user, content: 只回复两个字通了}], max_tokens: 16 } | python3 -m json.tool如果返回体里有choices[0].message.content且内容是「通了」说明 LiteLLM 到 TaoToken 的链路已经打通。如果返回401先检查Authorization头里的 Key 是不是LITELLM_MASTER_KEY不是 TaoToken 的 Key。LiteLLM 的 Proxy 认证和上游认证是两套调用方用 master key 或虚拟 keyLiteLLM 再用config.yaml里的api_key去访问 TaoToken。接着看日志。LiteLLM 启动时如果带了--detailed_debug日志里会有一行类似POST Request Sent from LiteLLM: curl -X POST https://taotoken.net/api/chat/completions。这行就是证据说明请求发往 TaoToken 而不是别的地址。如果你用start.sh后台运行日志在/data/litellm/litellm.log用下面命令过滤grep -n taotoken.net /data/litellm/litellm.log | tail -20正常应该能看到api_base或完整 URL 里包含taotoken.net。如果 grep 不到说明config.yaml里的api_base没生效检查是不是被.env里的OPENAI_API_BASE覆盖了或者model_name和请求里的model对不上导致走了默认路由。再验证一次 embedding确认非 chat 类请求也走 TaoTokencurl -s http://127.0.0.1:18001/v1/embeddings \ -H Content-Type: application/json \ -H Authorization: Bearer sk-your-master-key \ -d { model: text-embedding-3-small, input: litellm taotoken 链路验证 } | python3 -m json.tool返回里data[0].embedding是一个浮点数组长度符合模型维度就说明 embedding 通道也通了。这一步很多人会漏结果 chat 通了但 embedding 报model not found原因是model_list里没加 embedding 条目或者model字段写成了openai/text-embedding-3-small但 TaoToken 侧名称不同。以接入文档https://taotoken.net/doc里的模型 ID 为准。最后用 LiteLLM 的/model/info端点确认当前加载的模型和上游curl -s http://127.0.0.1:18001/model/info \ -H Authorization: Bearer sk-your-master-key | python3 -m json.tool返回里每个模型的litellm_params.api_base应该都是https://taotoken.net/api。如果这里显示的是https://api.openai.com/v1说明config.yaml没被正确加载检查启动命令里的--config路径是不是绝对路径以及start.sh里cd的目录对不对。5. 接入 TaoToken 后 LiteLLM 常见报错排查接入过程中遇到的报错大多集中在认证、地址和模型名三类。下面按真实报错逐条对照给出定位方法。AuthenticationError: No API key passed in或401 Invalid API Key。这个报错有两种可能一是调用 LiteLLM 时没带Authorization头二是 LiteLLM 访问 TaoToken 时api_key没读到。先确认 curl 请求头里有Bearer sk-your-master-key再确认.env里TAOTOKEN_API_KEY有值且config.yaml里写的是os.environ/TAOTOKEN_API_KEY。如果.env改了但没重新sourceLiteLLM 进程读到的还是旧值重启服务即可。litellm.APIConnectionError: OpenAIException - Connection error或日志里出现local proxy failed。这类报错通常是api_base写错比如写成了https://taotoken.net少了/api或者写成了http://而不是https://。TaoToken 的 API 端点是https://taotoken.net/api路径要完整。另外检查服务器出网是否正常curl -I https://taotoken.net/api能返回状态码就说明网络可达。KeyError: choices或reading choices相关报错。这通常不是 LiteLLM 的问题而是上游返回了非预期结构常见于模型名写错导致 TaoToken 侧返回错误 JSON。检查config.yaml里litellm_params.model的模型 ID 是否和 TaoToken 文档一致openai/前缀保留后面的模型名不要自己拼。如果模型名对但还报这个错打开--detailed_debug看上游返回的原始 body里面会有具体错误信息。OAuth或token refresh failed类报错。LiteLLM 本身不涉及 OAuth出现这类报错一般是某个 callback 或 hook 在尝试走别的认证流程。检查litellm_settings.callbacks里有没有引入需要额外认证的钩子临时注释掉再启动确认是不是钩子引起的。如果用的是 Claude Code 或 Cline 这类客户端通过 LiteLLM 转发客户端侧的 OAuth 配置和 LiteLLM 无关不要在 LiteLLM 里找 OAuth 配置。model not found或No deployments available。请求里的model字段和config.yaml里model_name不一致。LiteLLM 的model_name是调用方用的名字可以自定义但必须和请求里的model完全一致。如果你在config.yaml里写model_name: gpt-4o请求里写gpt-4o-2024就会报这个错。用/model/info确认当前加载的model_name列表。database unavailable但请求仍想通过。如果你在general_settings里设了allow_requests_on_db_unavailable: true数据库抖动时请求仍会放行但虚拟 Key 校验会跳过。生产环境建议保持true同时监控数据库连接。如果报错是prisma migrate相关说明数据库迁移没执行回到源码目录执行prisma migrate deploy --schema./schema.prisma。排查时有一个通用技巧把LITELLM_LOG设成DEBUG重启后日志会打印每个请求的完整上游 URL 和请求头Key 会脱敏。对照日志里的api_base是不是https://taotoken.net/api基本能定位大部分接入问题。如果日志里 URL 对但请求仍失败问题就在 TaoToken 侧的 Key 或模型权限去控制台检查 Key 是否启用、额度是否充足。6. 长期编码与 Agent 场景下的接入建议LiteLLM 接上 TaoToken 之后日常使用还有几个值得注意的点。如果你是用 Claude Code、Cline 或 Codex 这类编码工具它们通常要求填 Base URL、API Key 和 Model ID 三件套。Base URL 填 LiteLLM 的 Proxy 地址http://127.0.0.1:18001/v1API Key 填 LiteLLM 的虚拟 Key 或 master keyModel ID 填config.yaml里的model_name。这样客户端只认 LiteLLMLiteLLM 再去调度 TaoToken换模型时只改config.yaml客户端不用动。对于长期跑 Agent 的场景建议在 TaoToken 控制台创建独立的 Key按项目区分。LiteLLM 侧可以用虚拟 Key 做二次分发把不同团队的调用隔离到不同虚拟 Key 上配合rpm和tpm限制防止单个项目打满额度。虚拟 Key 的创建在 LiteLLM 的/key/generate端点用 master key 调用即可。这样即使某个虚拟 Key 泄露吊销它不影响其他项目。如果你需要看每个模型的消耗TaoToken 控制台有用量统计LiteLLM 侧也有spend日志。两边对账时注意时区和统计口径LiteLLM 的proxy_batch_write_at默认 60 秒批量写一次刚发完请求可能还没落库等一分钟再查。需要更细的调用链路时把litellm_settings.set_verbose临时打开排查完再关掉避免日志膨胀。最后提醒一点config.yaml里的api_base和.env里的OPENAI_API_BASE不要同时指向不同地址否则容易出现「以为走了 TaoToken 实际走了默认上游」的情况。统一用config.yaml的model_list显式声明.env只放 Key职责清晰排障时也少一层猜测。接入完成后用第 4 节的 curl 和日志验证跑一遍确认api_base是https://taotoken.net/api就可以把 LiteLLM 作为统一入口长期使用了。
阅读完成 · 觉得有帮助？
