1. 多模型接入的麻烦，LiteLLM 能解决什么
如果你手上同时用着 OpenAI、Anthropic、DeepSeek、Qwen 这几家的模型，大概率经历过这种场景：每个厂商的 SDK 不一样，鉴权方式不一样，返回结构也不一样。写业务代码时，光是维护几套调用逻辑就够头疼了，更别说后面还要加新模型、做故障切换。LiteLLM 就是冲着这个痛点来的开源工具，它把上百种大模型的调用方式统一成一套 OpenAI 风格的接口，你只需要改model参数里的前缀，就能在同一个函数里切换不同厂商。
LiteLLM 本身是一个 Python 库，同时也能以代理服务（Proxy）的形式跑起来，对外暴露一个/v1/chat/completions端点。这意味着你的业务代码可以完全不知道底层用的是哪家模型，只跟 LiteLLM 打交道。它适合谁？适合需要统一接入多模型 API 的开发者、做模型对比评测的团队，以及想把模型调用层抽象出来的后端工程师。
但这里有个现实问题：LiteLLM 统一了调用格式，却没有统一「Key 从哪来」。你依然要为每个厂商单独申请 Key、单独配置 base_url、单独管理额度。如果能把多家模型的访问通道收敛到一个统一的入口，config.yaml 会干净很多。这篇就围绕这个思路，给出 LiteLLM 配 TaoToken 的 config.yaml 骨架，以及多模型路由的验证方法。
2. TaoToken 作为统一接入点，前置准备
TaoToken 在这里扮演的角色是「统一 Key + 统一 API 通道」。你不需要为每个模型厂商分别去申请和管理 Key，而是通过一个 TaoToken 的 Key，配合不同的模型名称，就能访问到背后对应的模型。对 LiteLLM 来说，它看到的只是一个 OpenAI 兼容的 API 端点，配置起来非常直接。
先做两件准备工作。第一，拿到你的 TaoToken API Key。登录官网后进入控制台，在 API Keys 页面创建一个新的 Key，复制保存好，后面 config.yaml 里要用。控制台地址是 https://taotoken.net/console?utm_source=taotoken_aicg_blog_end&utm_content=console&utm_campaign=rewrite ，API Keys 页面在 https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。
第二，确认你要用的模型名称。TaoToken 的 API 端点是https://taotoken.net/api，它兼容 OpenAI 的请求格式。你可以在模型对话页面先手动试一下某个模型能不能正常返回，确认模型名拼写无误。模型对话入口：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。
注意：config.yaml 里的
api_key建议用环境变量注入，不要直接写死在文件里。LiteLLM 支持os.environ/VAR_NAME这种写法，后面骨架里会体现。
安装 LiteLLM 用 pip 即可，如果你要用代理模式，还需要带上 proxy 依赖：
pip install "litellm[proxy]"装完之后可以用litellm --version确认一下。接下来进入 config.yaml 的编写。
3. config.yaml 骨架：model_list 与 router_settings
LiteLLM 的 config.yaml 核心是两块：model_list定义有哪些模型可用，router_settings定义路由和回退策略。下面这份骨架可以直接复制修改，重点看api_base和api_key这两处怎么指向 TaoToken。
model_list: # 第一个模型：走 TaoToken 统一通道 - 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 # 第二个模型：同一个通道，不同模型名 - model_name: claude-3-5-sonnet litellm_params: model: openai/claude-3-5-sonnet api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY # 第三个模型：再换一个 - model_name: deepseek-chat litellm_params: model: openai/deepseek-chat api_base: https://taotoken.net/api api_key: os.environ/TAOTOKEN_API_KEY router_settings: # 路由策略：简单轮询，也可以换成 least-busy、usage-based-routing routing_strategy: simple-shuffle # 失败重试次数 num_retries: 2 # 超时设置（秒） timeout: 60 # 回退：当主模型失败时，按顺序尝试后面的模型 fallbacks: - gpt-4o-mini: ["claude-3-5-sonnet", "deepseek-chat"] - claude-3-5-sonnet: ["gpt-4o-mini"] # 允许的失败次数，超过则触发回退 allowed_fails: 1 # 冷却时间，失败的模型在多少秒内不再被选中 cooldown_time: 30 general_settings: master_key: os.environ/LITELLM_MASTER_KEY几个关键点解释一下。model_name是你对外暴露的名字，业务代码里用这个名字来调用；litellm_params.model里的openai/前缀告诉 LiteLLM 用 OpenAI 兼容协议去请求，后面的gpt-4o-mini是 TaoToken 侧识别的模型标识。api_base统一指向https://taotoken.net/api，api_key从环境变量读取。
router_settings里的fallbacks是这份配置的重点。它定义了当某个模型调用失败时，LiteLLM 会自动按列表顺序尝试下一个模型。比如gpt-4o-mini挂了，会先试claude-3-5-sonnet，再试deepseek-chat。cooldown_time让失败的模型在 30 秒内不被再次选中，避免反复撞墙。
设置环境变量后启动代理：
export TAOTOKEN_API_KEY="你的TaoToken Key" export LITELLM_MASTER_KEY="sk-1234" litellm --config config.yaml --port 4000启动成功会看到类似LiteLLM: Proxy initialized with Config的日志，监听在 4000 端口。
4. 验证多模型路由与回退
代理跑起来后，用 curl 验证。先测单个模型是否通：
curl http://localhost:4000/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-1234" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "用一句话说明什么是路由"}] }'预期返回一个标准的 OpenAI 格式 JSON，choices[0].message.content里有模型回复。如果返回 401，检查LITELLM_MASTER_KEY和请求头里的 Bearer 是否一致；如果返回 500 且提示上游错误，检查TAOTOKEN_API_KEY是否有效、api_base是否写对。
再测多模型切换，把model换成claude-3-5-sonnet和deepseek-chat各发一次，确认三个模型都能正常返回。这一步验证的是model_list配置正确。
验证回退逻辑稍微麻烦一点。你可以故意把某个模型的api_base改成一个不存在的地址，然后请求它，观察 LiteLLM 是否自动切到 fallback 列表里的下一个模型。日志里会出现Fallback triggered之类的提示，返回结果里model字段会显示实际生效的模型名。这个测试能确认fallbacks和cooldown_time是否按预期工作。
如果你更习惯用 Python 直接调，也可以绕过代理，用 LiteLLM 库的方式：
import os from litellm import completion os.environ["TAOTOKEN_API_KEY"] = "你的Key" response = completion( model="openai/gpt-4o-mini", api_base="https://taotoken.net/api", api_key=os.environ["TAOTOKEN_API_KEY"], messages=[{"role": "user", "content": "你好"}] ) print(response.choices[0].message.content)这种方式适合快速验证单个模型，不用起代理服务。
5. 常见报错与排查
报错一：AuthenticationError: Invalid API key。先确认TAOTOKEN_API_KEY环境变量在当前 shell 里确实生效了，用echo $TAOTOKEN_API_KEY检查。如果 Key 没问题，检查 config.yaml 里api_key的写法是不是os.environ/TAOTOKEN_API_KEY，注意是斜杠不是冒号。
报错二：model not found。这通常是litellm_params.model里的模型名写错了。TaoToken 侧的模型标识要跟你在模型对话页面看到的一致。另外注意openai/前缀不能丢，丢了 LiteLLM 会按原生 OpenAI 去请求，而不是走你配置的api_base。
报错三：回退不生效。检查fallbacks的写法，它是个列表，每个元素是{主模型: [备选模型列表]}的字典。如果主模型名跟model_name对不上，回退不会触发。另外allowed_fails设成 0 的话，第一次失败就会触发回退，设成 1 则允许失败一次后再回退。
报错四：代理启动报yaml parse error。YAML 对缩进敏感，检查model_list下面每个- model_name的缩进是否一致，冒号后面要有空格。可以用python -c "import yaml; yaml.safe_load(open('config.yaml'))"先验证语法。
报错五：请求超时。router_settings.timeout默认可能偏短，如果模型响应慢，调大到 120 秒试试。另外确认本机到taotoken.net的网络是通的，可以用curl -I https://taotoken.net/api看返回状态码。
6. 接入方式选择与后续
排障和接入相关的细节，可以对照接入文档再核一遍：https://taotoken.net/doc?utm_source=taotoken_aicg_blog_end&utm_content=doc&utm_campaign=rewrite 。如果你主要是想验证不同模型的效果，直接在模型对话页面切换着试最快：https://taotoken.net/models?utm_source=taotoken_aicg_blog_end&utm_content=models&utm_campaign=rewrite 。
如果你打算把 LiteLLM 长期跑在编码工具或 Agent 流程里，建议用 Coding Plan 来管理额度和调用：https://taotoken.net/coding-plan?utm_source=taotoken_aicg_blog_end&utm_content=coding-plan&utm_campaign=rewrite 。Key 的创建和管理都在 API Keys 页面：https://taotoken.net/api-keys?utm_source=taotoken_aicg_blog_end&utm_content=api-keys&utm_campaign=rewrite 。
config.yaml 这份骨架我用了挺久，最实用的其实是fallbacks那段——模型偶尔抽风的时候，业务代码完全无感，请求自动切到备选模型。你可以先把三个模型跑通，再慢慢加router_settings里的策略参数，不用一次配全。
