1. 多模型接入的混乱现场：为什么需要一个统一代理层
如果你正在做 AI 应用，大概率遇到过这种局面：产品要接 OpenAI 做主力，DeepSeek 做性价比兜底，偶尔还要试试通义千问的效果。每个厂商一套 SDK、一套鉴权、一套返回格式，代码里到处是 if-else 判断走哪家。更麻烦的是，某家 API 突然超时或限流，整个请求就挂了，用户看到的是 500 错误。
我试过最原始的做法——在每个业务函数里写 try-except 逐个切换模型，结果代码膨胀到没法维护，成本统计更是无从下手。后来把代理层单独抽出来，用 FastAPI 做网关、litellm 做格式统一，才把这件事理顺。
这套方案解决三个核心问题。第一是接口统一，上游应用只发一种请求格式，代理层负责翻译成各家 API 的格式。第二是故障降级，主模型失败时自动切到备用模型，用户无感知。第三是成本可观测，每次调用的 token 消耗和费用都记录下来，月底对账不再抓瞎。
适合谁看？如果你正在搭建 AI 中台、做多模型路由、或者单纯想给自己的 side project 加一层成本监控，这篇可以直接照着搭。技术栈是 Python + FastAPI + litellm，不需要额外的基础设施，本地跑起来就能验证。
整个代理层的核心思路可以用一句话概括：对外暴露一个/chat接口，内部按优先级依次尝试模型列表，成功即返回，同时记录成本。听起来简单，但要做到优雅、可扩展、好排障，有几个关键点需要处理好。下面从环境准备开始，一步步把可运行的代码搭出来。
2. TaoToken 统一 Key 通道：一个 Key 打通多模型调用
在写代码之前，先解决一个前置问题：多模型意味着多套 API Key，管理起来很烦。OpenAI 一个 Key、DeepSeek 一个 Key、通义千问又一个 Key，环境变量越堆越多，团队协作时还要同步密钥。
TaoToken 提供的是统一 Key 通道，你只需要一个 API Key，就能通过兼容 OpenAI 的接口调用多家模型。这对代理层来说非常友好——litellm 本身就支持自定义api_base，把请求指向 TaoToken 的 API 地址，模型名称按规范传入即可。
具体来说，TaoToken 的 API 地址是https://taotoken.net/api，兼容 OpenAI 的/v1/chat/completions路径。你在代码里配置api_base和api_key，litellm 就会把请求发到这里，由 TaoToken 路由到对应的底层模型。这样代理层不需要为每家厂商单独配置密钥，一个 Key 搞定。
对于成本监控来说，统一通道还有个额外好处：所有调用的计费口径一致，不用去各家后台分别拉账单。你可以在代理层统一记录 token 用量，结合价格表算出费用，数据来源单一，对账清晰。
如果你还没有 Key，可以去 TaoToken 控制台创建一个。拿到 Key 之后，先别急着写完整代理，用最简单的 curl 验证一下通道是否通畅：
curl https://taotoken.net/api/v1/chat/completions \ -H "Content-Type: application/json" \ -H "Authorization: Bearer sk-你的Key" \ -d '{ "model": "gpt-4o-mini", "messages": [{"role": "user", "content": "说一句你好"}] }'如果返回正常的 JSON 结构，说明 Key 和通道都没问题。这一步很重要，因为后面代理层排障时，需要先排除是通道问题还是代码问题。确认通道可用后，再进入 FastAPI + litellm 的搭建环节。
3. 可复制的 FastAPI + litellm 代理配置：路由、Fallback 与成本中间件
这一节是全文的核心，给出可以直接复制运行的完整配置。我会把代码拆成几个文件，方便你按模块理解。整体结构是：main.py放 FastAPI 应用和路由，config.py放模型列表和价格表，cost.py放成本记录服务。
先安装依赖：
pip install fastapi uvicorn litellm pydantic然后创建config.py，定义模型优先级和价格表。价格表用每千 token 的美元单价，你可以根据实际采购价格调整：
# config.py MODEL_PRIORITY = [ "gpt-4o-mini", "deepseek-chat", "qwen-turbo", ] PRICE_TABLE = { "gpt-4o-mini": {"input": 0.00015, "output": 0.0006}, "deepseek-chat": {"input": 0.00014, "output": 0.00028}, "qwen-turbo": {"input": 0.00005, "output": 0.0001}, } TAOTOKEN_API_BASE = "https://taotoken.net/api" TAOTOKEN_API_KEY = "sk-你的Key"接着写cost.py，用一个简单的内存列表记录成本。生产环境可以换成 Redis 或数据库，但接口设计保持一致：
# cost.py import time from config import PRICE_TABLE class CostService: def __init__(self): self.records = [] def add(self, model: str, prompt_tokens: int, completion_tokens: int): prices = PRICE_TABLE.get(model, {"input": 0, "output": 0}) cost = (prompt_tokens / 1000) * prices["input"] + \ (completion_tokens / 1000) * prices["output"] self.records.append({ "model": model, "prompt_tokens": prompt_tokens, "completion_tokens": completion_tokens, "cost": cost, "timestamp": time.time(), }) return cost def stats(self): if not self.records: return {"total_cost": 0, "count": 0, "by_model": {}} total = sum(r["cost"] for r in self.records) by_model = {} for r in self.records: by_model.setdefault(r["model"], {"cost": 0, "count": 0}) by_model[r["model"]]["cost"] += r["cost"] by_model[r["model"]]["count"] += 1 return {"total_cost": round(total, 6), "count": len(self.records), "by_model": by_model}核心的main.py来了。这里用 litellm 的acompletion做异步调用，配合 FastAPI 的异步路由。Fallback 逻辑是遍历模型列表，捕获异常后继续尝试下一个：
# main.py import litellm from fastapi import FastAPI, HTTPException, Depends from pydantic import BaseModel from typing import List, Optional from config import MODEL_PRIORITY, TAOTOKEN_API_BASE, TAOTOKEN_API_KEY from cost import CostService app = FastAPI(title="LLM Proxy") cost_service = CostService() class ChatRequest(BaseModel): prompt: str models: Optional[List[str]] = None temperature: Optional[float] = 0.7 class ChatResponse(BaseModel): text: str model_used: str cost: float async def call_with_fallback(models: List[str], prompt: str, temperature: float): last_error = None for model in models: try: response = await litellm.acompletion( model=f"openai/{model}", messages=[{"role": "user", "content": prompt}], temperature=temperature, api_base=TAOTOKEN_API_BASE, api_key=TAOTOKEN_API_KEY, ) content = response.choices[0].message.content usage = response.usage cost = cost_service.add( model, usage.prompt_tokens, usage.completion_tokens, ) return content, model, cost except Exception as e: last_error = e continue raise HTTPException(status_code=503, detail=f"All models failed: {last_error}") @app.post("/chat", response_model=ChatResponse) async def chat_endpoint(request: ChatRequest): models = request.models or MODEL_PRIORITY content, model_used, cost = await call_with_fallback( models, request.prompt, request.temperature ) return ChatResponse(text=content, model_used=model_used, cost=cost) @app.get("/cost/stats") async def get_cost_stats(): return cost_service.stats()注意model参数传的是openai/{model}格式，这是 litellm 的约定——告诉它用 OpenAI 兼容协议发送请求，实际地址由api_base决定。这样所有模型都走 TaoToken 通道，不需要为每家单独配置。
启动服务：
uvicorn main:app --reload --port 8000到这里，一个带 Fallback 和成本监控的代理层就跑起来了。下一节验证实际请求效果。
4. 验证请求与成功结果：从单次调用到成本统计
服务启动后，先用一个简单请求验证主流程。打开另一个终端，发一个 POST 请求：
curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{ "prompt": "用一句话解释什么是向量数据库", "temperature": 0.7 }'预期返回类似这样的 JSON：
{ "text": "向量数据库是一种专门存储和检索高维向量数据的数据库，常用于相似度搜索和推荐系统。", "model_used": "gpt-4o-mini", "cost": 0.000042 }model_used显示实际命中的模型，cost是这次调用的估算费用。如果主模型正常，应该命中MODEL_PRIORITY里的第一个。
接下来验证 Fallback。手动把第一个模型改成一个不存在的名称，比如gpt-4o-mini-typo，再发请求：
curl -X POST http://localhost:8000/chat \ -H "Content-Type: application/json" \ -d '{ "prompt": "测试降级", "models": ["gpt-4o-mini-typo", "deepseek-chat"] }'这次第一个模型会报错，代理层自动切到deepseek-chat，返回的model_used应该是deepseek-chat。这说明 Fallback 生效了。
最后查看成本统计：
curl http://localhost:8000/cost/stats返回结果会按模型聚合，类似：
{ "total_cost": 0.000078, "count": 2, "by_model": { "gpt-4o-mini": {"cost": 0.000042, "count": 1}, "deepseek-chat": {"cost": 0.000036, "count": 1} } }到这里，统一代理、故障降级、成本监控三个目标都验证通过了。你可以把这个/cost/stats接口接到 Grafana 或前端面板，实时看调用量和费用趋势。
有个细节值得注意：litellm 返回的usage字段在不同模型下可能略有差异，但走 TaoToken 统一通道后，格式是一致的，所以成本计算逻辑不需要为每个模型写分支。这也是统一通道带来的便利。
5. 常见报错排查：401、local proxy failed、reading choices 与 OAuth
实际跑起来后，大概率会遇到几个典型报错。这一节按报错信息对照排查，都是真实踩过的坑。
401 Authentication Error：最常见的原因是 Key 没传对。检查TAOTOKEN_API_KEY是否以sk-开头，有没有多余空格。另外注意 litellm 的api_key参数优先级高于环境变量，如果你同时设置了OPENAI_API_KEY环境变量，可能会被覆盖。建议在代码里显式传参，避免混淆。
local proxy failed / Connection error：这个报错通常出现在api_base配置错误时。确认地址是https://taotoken.net/api，不要漏掉/api路径，也不要多加/v1——litellm 会自动拼接/v1/chat/completions。如果你在本地开了其他代理工具，可能会干扰请求，先关掉再试。
reading choices / KeyError 'choices'：说明返回的 JSON 结构不符合预期。可能是模型名称写错了，TaoToken 返回了错误信息而不是正常的 completion 结构。打印完整的response对象看看，通常能看到具体的错误原因。另外确认model参数传的是openai/{model}格式，少了openai/前缀 litellm 可能走错协议。
OAuth / token expired：如果你用的是某些需要 OAuth 的模型，可能会遇到 token 过期。走 TaoToken 统一通道的话，鉴权由通道处理，你只需要保证自己的 API Key 有效。如果 Key 被禁用或额度耗尽，也会返回类似鉴权失败的提示，去控制台检查一下 Key 状态和余额。
Fallback 不生效：检查异常捕获的范围。litellm 抛出的异常类型比较多，用except Exception能兜住大部分情况。另外确认模型列表里至少有一个可用模型，如果全部失败，会返回 503。
排障时有个通用技巧：先把litellm.acompletion单独拿出来在 Python 交互环境里跑一次，确认通道和参数没问题，再放回 FastAPI 里。这样能快速定位是通道问题还是框架问题。
6. 从代理层到生产：接入文档与 Coding Plan 的衔接
代理层跑通之后，下一步通常是接入实际业务。如果你用的是 Claude Code 做编码辅助，或者想把代理层接到 Cline、Codex 这类工具里，需要配置三件套：Base URL、API Key、Model ID。
Base URL 填https://taotoken.net/api，API Key 用你在控制台创建的那个，Model ID 按工具要求填对应模型名称。以 Claude Code 为例，在配置文件里指定ANTHROPIC_BASE_URL和ANTHROPIC_API_KEY，就能把请求导向统一通道。Cline 的 MCP 配置类似，在 settings 里填好这三项即可。
如果你需要长期跑编码任务或 Agent 工作流，可以了解一下 Coding Plan，它针对高频调用场景做了额度优化。接入文档里有各工具的详细配置步骤，包括 Claude Code、Cline、Codex 的 auth.json 写法，照着填就行。
验证模型是否正常响应，可以用模型对话页面快速测一下，不用写代码就能确认通道通畅。API Keys 管理页面可以创建和轮换 Key，建议给不同环境分配不同的 Key，方便追踪用量。
整套方案的核心价值在于：用一层薄薄的代理，把多模型接入的复杂度收敛到一个地方。业务代码只关心 prompt，模型切换、故障降级、成本统计都在代理层完成。后续要加新模型，只需要在MODEL_PRIORITY和PRICE_TABLE里加一行配置，不用改业务逻辑。这种架构在模型快速迭代的当下，能省下不少重构时间。
