容错型LiteLLM路由架构：232家推理商成本与吞吐权衡

为什么单供应商硬编码是可靠性与成本的定时炸弹

把某一家 LLM 供应商的 SDK 硬编码进核心业务代码，是很多团队踩过的坑。原文对 232 家推理供应商、470 个模型做了一次横向盘点，归纳出三类结构性风险：

• 旧端点价格陷阱：仍在调用 openai/gpt-4.5-preview（$75/$150 每百万 token）或 openai/gpt-4-32k（$60/$120 每百万 token）的团队，相比 openai/gpt-4o（$2.50/$10.00）或 anthropic/claude-3.7-sonnet（$3.00/$15.00）这类可直接替换的模型，多付了 25 到 60 倍的成本。
• 跨托管方的价格与速度剪刀差：Llama 3.3 70B Instruct、Qwen QwQ-32B 这类开放权重模型，在 DeepInfra 的 FP8 无服务器端点上输入价格低至 $0.12/1M，而在 Groq LPU 与 Cerebras 晶圆级集群上能达到 420 至 2100 tokens/秒的吞吐。
• 429 限流与区域故障：只依赖一个直连 API Key，供应商一次限流高峰就会打断面向用户的 SSE 流式输出。

这三点合起来说明一件事：模型选择不该散落在各个微服务里，而应该收敛到一层可配置、可回退的路由抽象上。LiteLLM 提供的正是这一层。

三层语义路由矩阵：把 80/15/5 的流量分层

原文的核心主张是把请求按语义分成三档，而不是按供应商分。这样业务代码只认 tier-fast、tier-frontier、tier-reasoning 三个名字，底层换模型不影响调用方。

路由层级	请求占比	主模型	零停机回退	目标 SLA 与成本底线
tier-fast	80%	gemini-2.0-flash-001（$0.10/$0.40）	deepinfra/meta-llama/Llama-3.3-70B-Instruct（$0.12/$0.30）	TTFT < 250ms，混合成本 < $0.20/1M
tier-frontier	15%	anthropic/claude-3.7-sonnet（$3.00/$15.00，缓存 $0.30）	openai/gpt-4o（$2.50/$10.00，缓存 $1.25）	高工具调用准确率 + 85% 缓存命中
tier-reasoning	5%	qwen/qwq-32b（$0.12/$0.18）或 o3-mini（$1.10/$4.40）	deepseek广告/deepseek-r1（$0.50/$2.15）	深度 STEM、代码合成与验证

这个分层的思路值得展开。绝大多数应用里，真正需要前沿模型的请求其实只占少数——大量请求是分类、抽取、改写、轻量对话，用 flash 级别模型足够。把 80% 的流量压到低成本层，整体单位经济学就成立；而把 15% 留给前沿模型、5% 留给推理模型，保证了复杂任务的质量底线。

你可能没注意到回退设计：每一层都配了一个价格量级相近的替代模型，而不是随便挂一个更贵的。tier-fast 回退到 DeepInfra 上的 Llama 3.3 70B，tier-frontier 回退到 gpt-4o——两者的定价都在同一档，故障切换不会造成账单突刺。这是很多团队做 fallback 时容易忽略的细节。

LLM 路由器（LLM Router） 是介于应用与模型供应商之间的抽象层，典型职责包括：按策略选择候选模型、管理多供应商密钥、处理重试与回退、统一不同厂商的 API 协议差异、以及聚合用量与成本指标。LiteLLM 是这一层的开源实现之一，它把 OpenAI 格式作为统一入参出参，向下适配 Anthropic、Gemini、OpenRouter、DeepInfra 等不同端点。路由策略通常包括加权随机、成本优先、延迟优先（latency-based）和语义路由。语义路由指依据请求内容或业务标签决定走哪一档模型，而不是按供应商切分，这正是 80/15/5 分层能落地的机制基础。

TTFT（Time To First Token，首 token 延迟） 指从发出请求到收到第一个流式 token 的时间，是流式对话体验的核心指标；与之对应的 TPOT（每输出 token 时间）决定整体生成速度。对 tier-fast 层而言，用户感知几乎完全由 TTFT 决定，因此原文把 TTFT < 250ms 写进 SLA。需要注意，TTFT 受输入长度、并发度和供应商排队策略影响很大，跨供应商比较时应在相同 prompt 长度和并发条件下测量，否则延迟路由可能把流量错误地导向看似更快、实则在高并发下劣化的端点。

生产级 litellm_config.yaml 模板拆解

原文给出了一份可直接改用的配置。核心结构分两块：model_list 定义模型与密钥，router_settings 定义路由行为。

model_list:
  - model_name: tier-fast
    litellm_params:
      model: openrouter/google/gemini-2.0-flash-001
      api_key: os.environ/OPENROUTER_API_KEY
      rpm: 2000
  - model_name: tier-fast-fallback
    litellm_params:
      model: deepinfra/meta-llama/Llama-3.3-70B-Instruct-Turbo
      api_key: os.environ/DEEPINFRA_API_KEY

  - model_name: tier-frontier
    litellm_params:
      model: anthropic/claude-3-7-sonnet-latest
      api_key: os.environ/ANTHROPIC_API_KEY
      extra_headers:
        anthropic-beta: "prompt-caching-2024-07-31"
  - model_name: tier-frontier-fallback
    litellm_params:
      model: openai/gpt-4o
      api_key: os.environ/OPENAI_API_KEY

  - model_name: tier-reasoning
    litellm_params:
      model: openrouter/deepseek/deepseek-r1
      api_key: os.environ/OPENROUTER_API_KEY

router_settings:
  routing_strategy: latency-based-routing
  num_retries: 2
  timeout: 45
  fallbacks:
    - {"tier-fast": ["tier-fast-fallback"]}
    - {"tier-frontier": ["tier-frontier-fallback"]}

几个参数值得单独说。routing_strategy: latency-based-routing 让路由器在同类候选中挑响应最快的，这对 tier-fast 层尤其关键，因为 TTFT 直接决定用户感知。num_retries: 2 加上 fallbacks 构成双层容错：先重试，再切换供应商，两者结合才能扛住 429 和区域抖动。timeout: 45 是兜底上限，防止某个供应商挂起后把整个请求链路拖死。

tier-frontier 里的 anthropic-beta: prompt-caching-2024-07-31 头也值得一提。前沿模型层的每次调用都贵，缓存命中率直接影响这 15% 流量的实际成本，把缓存作为配置的一部分而不是事后优化，是更务实的做法。

Prompt Caching（提示缓存） 是 Anthropic、OpenAI 等供应商提供的能力：当请求前缀（system prompt、工具定义、长文档）与之前请求一致时，命中缓存的输入 token 按折扣价计费，Anthropic 的缓存读取价约为标准输入价的 10%，OpenAI 约为 50%。原文在 tier-frontier 中通过 anthropic-beta 请求头显式开启该特性，原因在于缓存并非默认全量生效，需要按供应商的 beta 头或参数声明。要拿到 85% 的缓存命中率，实践上要求把稳定内容（系统提示、few-shot 示例、检索到的长上下文）放在 prompt 前部，易变内容放在末尾，并保持请求前缀逐字节一致——任何微小的前缀变动都会导致缓存未命中，使这 15% 流量的实际成本回到原价。

自建 GPU 与无服务器 Token API 的临界点

原文提出了一个经验阈值：当团队持续吞吐跨过约 4000 万到 5000 万 tokens/天，租用专用 vLLM/SGLang GPU 实例通常比按 token 计费的无服务器方案再省 45% 到 60%。

这个数字的意义在于给团队一个判断坐标。低于这个量级，无服务器端点省去了运维、扩缩容和模型部署的复杂度，综合成本更低；高于这个量级，固定成本的 GPU 摊销开始占优。原文列举的选项包括 Vultr 的 H100/A100/L40S 裸金属与云集群、RunPod 的按秒计费 vLLM 模板（$0.20/hr 至 $2.69/hr），可用于部署 Llama 3.3 70B、DeepSeek R1 Distill、Qwen 2.5 Coder 32B 等模型。

需要说明的是，这些报价与折扣属于原文引用的供应商信息，实际成本会随 GPU 型号、地域与合约期限波动，落地前应自行核算。

vLLM 与 SGLang 是两个主流的高吞吐开源推理引擎。vLLM 的核心是 PagedAttention，把 KV Cache 按页管理，显著降低显存碎片、提升批量并发；SGLang 则通过 RadixAttention 在前缀共享场景（多轮对话、同一 system prompt 的大量请求）中复用 KV Cache，并用结构化生成加速约束解码。二者都支持连续批处理（continuous batching），这是专用 GPU 实例能跑出高吞吐的关键。选择自建时，实际有效吞吐取决于模型参数量、量化精度（FP8/INT8）、上下文长度分布与并发形态，不能直接套用厂商标称的 tokens/秒；同时需要把 GPU 利用率、冷启动、模型加载时间和运维人力一并计入总成本，再与无服务器方案的按 token 单价对比。

这套架构适合谁

三层路由的价值在不同阶段的团队里差别很大。日请求量很小的项目，直接调一家 API 更省心，路由层的收益抵不过配置成本。但只要满足下面任一条件，这层抽象就值得建：

• 面向用户的产品依赖流式输出，一次限流就是可见的体验故障；
• 月度 token 账单已经需要专人盯，旧端点遗留调用开始显形；
• 业务里既有轻量任务又有复杂推理，用同一个模型会要么浪费要么不够用。

真正的收益不在配置本身，而在于把「用哪个模型」从代码里挪到配置里。这样换模型、调比例、加回退都变成改 YAML 而不是发版，FinOps 的讨论也才有落点。