多模型路由实战：GLM-5.3 负责推理、本地 Qwen3.8-27B 兜底日常

为什么需要一层路由

把 AI 接进业务之后，很快会遇到选择困难：GLM-5.3 编程和推理很强，但强制思考、定价还没正式公布；DeepSeek V4 Pro 便宜好用，8 月 16 日却上了峰谷计费；本地 Qwen3.8-27B 免费还能离线，就是慢。与其在代码里硬编码模型，不如加一层 LiteLLM 路由，让请求自己「挑便宜又够用」的路走。

第一步：安装并配置 LiteLLM

pip install litellm[proxy]

LiteLLM Proxy 用 config.yaml 统一管理模型路由，把本地 Ollama 和云端 API 放在一张表里：

model_list:
  - model_name: local-code
    litellm_params:
      model: ollama/qwen3.8-27b
      api_base: http://localhost:11434
  - model_name: glm53
    litellm_params:
      model: zhipu/glm-5.3
      api_key: os.environ/ZHIPU_API_KEY

第二步：启动代理

litellm --config config.yaml --port 4000

启动后所有业务只认一个地址 http://localhost:4000。模型名 local-code 和 glm53 对调用方透明，切换后端时不用改业务代码。

第三步：按任务难度分派

路由的核心是「把难活给强模型、把重复活给便宜模型」。参考策略：

• 日常对话 / 文档摘要 → local-code（本地免费，慢一点无所谓）
• 代码审查 / 复杂重构 → glm53（reasoning_effort 用 high）
• 批量任务 → 排到 DeepSeek 谷时段（输出 $1.98/1M，约为峰值一半）
• 离线 / 内网场景 → 只走 local-code，数据不出内网

第四步：加一层成本熔断

LiteLLM Proxy 支持按模型设置 budget（额度）和 tpm/rpm 限流。给 glm53 设月度上限，超了就自动降级到 local-code，防止账单失控。DeepSeek 峰谷计费生效后，这类按时间调价的策略价值更明显。

多模型路由不是炫技，是 2026 年下半年控制 AI 成本的基本功：能力、价格、时段三个维度一起优化。