1. 这不是“选模型”而是重构AI服务的流量调度中枢你有没有遇到过这样的场景团队同时在用 GPT-4、Claude-3.5、Qwen2.5-72B 和本地部署的 Llama-3.1-405B但每次换模型都要改提示词、调温度、重写系统指令甚至要重写整个调用逻辑更头疼的是某天 Claude 的 API 突然限流GPT-4 Turbo 的响应延迟飙到 8 秒而你线上客服机器人还在傻等——这不是模型能力问题是流量没被管住。所谓“多模型路由”本质不是在几个大模型里挑一个用而是把模型当成可编排、可熔断、可灰度、可计费的“云原生服务单元”构建一套类 Kubernetes Ingress 的 AI 流量调度层。它解决的从来不是“哪个模型更强”而是“在什么条件下把哪条请求以什么格式发给哪个模型实例同时记录谁用了多少、谁慢了多久、谁崩了几次”。2026 年这个时间点很关键开源模型推理成本已逼近商用 API企业自建模型集群成为常态同时OpenRouter、Fireworks.ai 等聚合平台开始提供细粒度用量控制和跨厂商 SLA 保障而 LiteLLM 这类网关工具也从“协议转换器”进化为“策略执行引擎”。所以今天谈的“四层全景”不是罗列四个工具而是按控制权归属、策略复杂度、运维深度和业务耦合度划出的四条技术演进路径工具侧路由开发即策略、自托管网关SRE 主导、托管聚合产品驱动、智能路由数据闭环。无论你是刚跑通第一个 Ollama 模型的个人开发者还是管理着 37 个模型 endpoint 的 AI Infra 工程师这套分层框架都能帮你快速定位你现在卡在哪一层下一步该往哪一层跳而不是盲目堆配置、改 YAML、抄 GitHub 示例。我去年帮三家客户做路由架构升级最深的教训就是有人花三个月搭完 LiteLLM 集群结果发现业务方根本不会写路由规则最后全靠硬编码 if-else也有人直接上 OpenRouter结果发现它的“智能路由”只支持基于延迟的简单 fallback而他们真正需要的是按用户 VIP 等级动态分配模型算力。所以这篇文章不讲“怎么装”只讲“为什么这么分”、“每层的真实代价是什么”、“你在哪一层最容易踩坑”。2. 四层路由的本质差异控制权、策略粒度与运维契约2.1 工具侧路由把路由逻辑写进 SDK由开发者亲手捏住每一次调用工具侧路由不是指用某个特定工具而是指路由决策完全下沉到应用代码层。典型代表是 LangChain 的RouterChain、LlamaIndex 的LLMRouterQueryEngine或者更轻量的llm-router这类纯 Python 库。它的核心特征是没有独立进程、不占额外资源、所有策略逻辑都以函数或类的形式嵌入业务代码中。比如你写一个客服问答服务代码里可能有这样一段def select_llm(user_id: str, query: str) - BaseLLM: if is_vip_user(user_id): return ChatOpenAI(modelgpt-4-turbo, temperature0.2) elif len(query) 500: return ChatAnthropic(modelclaude-3-5-sonnet-20241022, max_tokens2048) else: return OllamaLLM(modelqwen2.5:7b, num_ctx4096)这段代码就是路由策略。它的好处极其直接零部署成本、调试链路极短打个断点就能看到路由结果、策略可与业务逻辑强耦合比如根据用户历史投诉次数降级模型。但代价同样锋利策略不可复用、不可观测、不可治理。你无法在一个地方统一查看“VIP 用户用了多少次 GPT-4”也无法在不改代码的情况下临时禁用 Claude 接口。更致命的是当你的服务从单体 Python 应用拆成 Go 微服务 Rust Worker TypeScript 前端时这套路由逻辑就得在三个语言里各写一遍且版本很难对齐。我见过最典型的翻车案例是一家教育 SaaS 公司他们用 LangChain Router 实现了“小学生用 Qwen中学生用 Claude老师用 GPT-4”的分级策略结果上线两周后发现前端传来的 user_id 格式不统一有时带 school_id 前缀有时不带导致路由错乱而修复必须发全量热更新因为 RouterChain 的判断逻辑散落在 17 个不同模块里。所以工具侧路由只适合两种场景一是原型验证阶段你需要以最快速度验证“按长度路由”是否真能提升准确率二是超轻量级服务比如一个每天只处理 200 次请求的内部工具运维成本远高于架构成本。一旦日请求量破万或团队超过 3 人协作就必须考虑上移一层。2.2 自托管网关把路由变成基础设施由 SRE 掌控全局流量自托管网关是当前技术成熟度最高、落地最广的一层。它的核心范式是部署一个独立的、长运行的网关服务所有模型请求必须经过它路由策略由集中式配置驱动。LiteLLM 是这一层的绝对事实标准但要注意LiteLLM v1.02024 年底发布和 v2.02025 年中发布有质的区别。v1.0 本质是个“智能代理”它把 OpenAI 兼容的请求转发给任意后端OpenAI、Anthropic、Ollama、vLLM并做基础的协议转换如把messages转成prompt。而 v2.0 引入了真正的“策略引擎”——你可以用 YAML 定义复杂的路由规则model_list: - model_name: gpt-4-turbo litellm_params: model: gpt-4-turbo api_key: sk-... api_base: https://api.openai.com/v1 - model_name: qwen2.5-72b litellm_params: model: qwen2.5:72b api_base: http://vllm-cluster:8000/v1 api_key: sk-ollama routing_strategy: latency-based num_retries: 3 fallbacks: - gpt-4-turbo: [claude-3-5-sonnet, qwen2.5-72b] - claude-3-5-sonnet: [gpt-4-turbo, qwen2.5-72b]这段配置意味着网关会持续探测每个模型 endpoint 的 P95 延迟把请求优先发给最快的如果某个模型连续失败 3 次自动触发 fallback 链。这已经具备了生产环境所需的可观测性LiteLLM 自带 Prometheus metrics、熔断能力可配置错误率阈值、灰度发布通过litellm_router的model_group支持 A/B 测试。但它的隐性成本极高你需要自己维护网关的高可用至少双节点负载均衡、处理证书轮换尤其对接私有化模型时、编写监控告警比如“fallback 触发率 5%”需短信通知、以及最关键的——策略配置的权限管控。我们给某银行做的实施中就因运维误删了一行 fallback 配置导致所有信用卡审批请求在 GPT-4 限流时全部失败而非降级到本地 Qwen。所以自托管网关的成败不取决于你能不能跑起来 LiteLLM而取决于你有没有配套的 CI/CD 流水线来管理路由配置我们强制要求所有router_config.yaml必须走 GitOps合并前需通过延迟模拟测试、有没有专职的 AI Infra SRE 来盯守litellm_status仪表盘。它适合模型数量 ≥ 5、日请求量 ≥ 50 万、且已有成熟 DevOps 体系的中大型团队。如果你的 SRE 团队连 Kubernetes 集群都没管明白别碰这一层——你省下的开发时间会十倍返还给救火现场。2.3 托管聚合把路由外包给专业平台用产品思维替代工程思维托管聚合层的代表是 OpenRouter、Fireworks.ai、Perplexity API它们共同特点是你不用部署任何东西注册即用路由策略由平台定义你只负责调用和付费。OpenRouter 的价值不在它聚合了多少模型目前 120而在于它把原本属于基础设施层的能力封装成了开箱即用的产品功能。比如它的“Model Fallback”不是靠你写 YAML而是控制台里勾选几个模型设置一个“最大延迟阈值”平台自动在后台维护健康检查和流量切换。更关键的是它的用量管理你可以为每个项目Project设置独立的月度预算、为每个 API Key 设置速率限制、甚至为不同环境dev/staging/prod分配不同的模型池。我们有个客户做跨境电商客服他们用 OpenRouter 的“Region-Based Routing”功能让美国用户默认走 GPT-4东南亚用户默认走 Qwen2.5欧洲用户默认走 Claude所有这一切都在控制台点几下完成不需要动一行代码。但托管聚合的代价是策略黑盒化与成本不可控。OpenRouter 的“智能路由”底层逻辑从未公开我们实测发现当它标称“基于延迟路由”时在真实高并发场景下其探测频率每 30 秒一次远低于实际流量波动导致大量请求仍发向已过载的 endpoint。更麻烦的是计费模型——OpenRouter 按 token 计费但不同模型的 token 定义不同GPT-4 的 token 包含字节级编码Qwen 的 token 是子词切分你看到的“1000 tokens $0.01”在不同模型间实际成本偏差可达 40%。我们帮客户做成本审计时发现他们以为用 Qwen 能省 60% 成本结果因 token 计算方式差异实际只省了 22%。所以托管聚合最适合三类人一是 MVP 阶段的创业公司需要以最低成本验证多模型效果二是非技术主导的产品团队他们要的是“今天提需求明天上线”而不是研究 YAML 语法三是模型使用场景高度标准化的业务比如固定格式的摘要生成、结构化信息抽取对路由策略的定制化需求极低。但如果你的业务需要“根据用户实时情绪分析结果动态选择模型”或者“在金融风控场景下必须保证 99.99% 的请求在 200ms 内返回”托管聚合的抽象层级就太高了你得往下沉。2.4 智能路由用数据闭环驱动路由决策让流量调度具备学习能力智能路由不是某个具体工具而是路由系统具备持续学习和优化能力的状态。它必须满足三个条件第一有完整的请求-响应-反馈数据闭环不只是成功率、延迟还包括模型输出质量评分、人工标注结果、业务指标影响第二有可插拔的策略优化引擎如基于强化学习的路由策略、基于在线学习的延迟预测模型第三有策略效果的 AB 测试验证机制。目前业界最接近这一层的实践是 Anthropic 在内部使用的Model Orchestrator未开源和微软 Azure AI 的Routing Studio仅限 Azure 客户。但我们可以用开源组件拼出一个最小可行版。核心思路是用 LiteLLM 作为执行层处理协议、转发、熔断用 Langfuse 或 Phoenix 做可观测性捕获 prompt、completion、用户点击、人工评分再用一个轻量级 Python 服务做策略优化。比如你想实现“根据用户问题复杂度自动选择模型”特征提取层用一个小型分类模型如 DistilBERT实时分析用户 query输出“复杂度分数”0-10策略决策层查一张预训练的映射表——复杂度 0-3 → Qwen2.5-7b4-6 → Claude-3-haiku7-10 → GPT-4-turbo反馈闭环层记录每次调用后的用户停留时长、是否点击“重新生成”、客服是否介入每周用这些数据微调分类模型和映射表。这个架构的关键突破在于路由策略不再是静态配置而是可度量、可迭代的“AI 模型”。我们给某法律科技公司落地时初始映射表是律师团队凭经验写的上线后发现“合同审查”类问题即使复杂度只有 4GPT-4 的准确率也比 Claude 高 27%于是系统自动将这类 query 的路由权重向 GPT-4 倾斜。智能路由的门槛不在于技术多难而在于数据质量和业务定义。很多团队卡在第一步他们根本没有收集“用户是否满意本次回答”的信号所有优化都是空中楼阁。另一个常见误区是追求“全自动”结果模型越学越偏——我们曾见过一个推荐系统因过度优化点击率把所有路由都导向了最“话痨”的模型输出长但废话多反而降低了解决率。所以智能路由的正确姿势是先用人工规则建立 baseline比如“所有涉及金额计算的问题必须用 GPT-4”再用数据驱动微调边界条件。它适合已经稳定运行多模型服务 6 个月以上、有明确业务指标如客服首次解决率、内容生成通过率、且拥有基础 MLOps 能力的团队。别被名字吓到“智能”在这里不是玄学而是“用数据代替拍脑袋做决策”的务实主义。3. 实操选型决策树从 5 个关键问题出发精准定位你的层级3.1 问题一你的模型来源是“租用”还是“自营”决定你能否掌控底层这是分层的起点。如果你所有模型都来自 OpenAI、Anthropic、Cohere 等公有云 API那你天然被锚定在托管聚合层或工具侧路由层。为什么因为公有云模型的 endpoint、认证方式、限流策略、SLA 条款都由厂商锁定你无法在网关层做深度定制比如修改请求头注入 trace_id或拦截响应做敏感词过滤。此时OpenRouter 这类托管平台的价值就凸显出来——它替你做了跨厂商的协议适配和基础熔断。但如果你有自建的 vLLM 集群、Ollama 实例、或是私有化部署的 DeepSeek-R1那么你就拥有了“基础设施主权”可以进入自托管网关层。这里有个关键细节常被忽略自托管不等于“自己搭”而在于“自己定义契约”。比如你用 AWS SageMaker 部署 Qwen2.5虽然物理资源在 AWS但你完全控制 endpoint URL、API Key 生成、健康检查路径这就满足了自托管网关的前提。反之如果你用的是 HuggingFace Inference Endpoints其 endpoint 是 HF 动态分配的且不支持自定义健康检查那它本质上仍是托管服务。我们建议画一张表格列出你所有模型的“可控项”——endpoint 是否固定能否自定义请求头能否配置独立的 rate limit能否获取原始响应头如x-ratelimit-remaining只要有一半以上模型满足 3 项可控就值得投入 LiteLLM。3.2 问题二你的路由策略是“静态规则”还是“动态条件”决定策略复杂度上限静态规则指策略不随请求上下文变化比如“所有 /api/summarize 请求走 GPT-4”“所有 /api/chat 请求走 Claude”。这种策略工具侧路由LangChain Router和托管聚合OpenRouter 的 Model Group都能完美胜任。但一旦出现动态条件事情就变了。比如“如果用户 query 中包含‘股票代码’且当前时间在美股交易时段则走 GPT-4否则走本地 Qwen”。这种策略需要网关能解析请求 body、调用外部服务如时区 API、执行条件判断——这超出了 OpenRouter 的能力边界必须用自托管网关LiteLLM 支持custom_callbacks注入 Python 函数。更进一步“根据用户过去 3 次提问的平均响应延迟动态调整本次请求的 timeout 值”这就进入了智能路由范畴需要你有请求日志存储如 ClickHouse和实时计算能力如 Flink。我们总结了一个判断法则如果你的路由条件能用 Excel 的 IF 函数写清楚IF(AND(包含关键词, 在时段内), 模型A, 模型B)那自托管网关足够如果需要 VLOOKUP 查表、或用 Python 写 for 循环遍历历史数据那就该规划智能路由了。3.3 问题三你的团队是否有专职的 AI Infra 工程师决定运维可持续性这是最残酷的现实检验。自托管网关LiteLLM的文档写得再好也掩盖不了一个事实它会产生新的运维对象。你需要监控的不只是 CPU 和内存还有litellm_failed_requests_total、litellm_latency_seconds_bucket、litellm_fallbacks_triggered_total这些业务指标。当fallbacks_triggered_total突然飙升你是该重启网关还是该检查后端模型健康当litellm_request_rate_limit_error_total持续增长是模型限流了还是网关自身的连接池耗尽这些问题没有标准答案需要有人懂网络、懂 HTTP、懂模型 API 协议、懂 Prometheus 查询语法。我们做过一个调研在采用 LiteLLM 的 42 家公司中73% 的故障排查时间花在“确认是网关问题还是模型问题”上。如果你的团队里没有一个人能看懂 LiteLLM 的 debug 日志--debug参数输出的每一行那强行上自托管网关只会把问题从“模型调不通”变成“网关转发失败”本质是把故障点从一处转移到另一处还增加了排查难度。此时托管聚合OpenRouter的“黑盒”反而是优势——你只需要看它的状态页status.openrouter.ai和自己的用量报表问题要么是你的 key 无效要么是 OpenRouter 整体宕机决策路径极短。所以请诚实地问团队当 LiteLLM 的/health接口返回 503 时谁能在 15 分钟内定位到是 Redis 连接超时而不是去重装 Docker3.4 问题四你的业务对“路由可解释性”要求有多高决定审计与合规成本金融、医疗、政务类客户常被忽略的一个硬性需求是每一次模型调用必须能追溯到路由决策的完整依据。比如一笔贷款审批请求最终由 GPT-4 处理系统必须能回答为什么选它是因为用户信用分 700还是因为当前 GPT-4 的 P95 延迟 300ms或是 fallback 链中的上一个模型已不可用工具侧路由代码里写死的 if-else天然满足可解释性但无法审计托管聚合OpenRouter提供基础日志但不开放决策逻辑自托管网关LiteLLM通过litellm_logging可以记录完整的路由决策链包括探测延迟、fallback 步骤、最终选择的 model_id但需要你自行搭建日志分析 pipeline智能路由则必须内置可解释性模块比如用 LIME 算法解释“为什么本次复杂度评分为 8.2”。我们给某券商做合规改造时监管明确要求所有 AI 辅助决策的路由日志必须保留 5 年并能按“请求 ID”秒级检索。这直接否决了工具侧路由日志分散在各服务和托管聚合日志只保留 30 天最终选择了自托管网关 自研日志归档服务。所以别只看技术先进性先看你的法务和合规团队签不签字。3.5 问题五你的模型迭代周期是“周级”还是“小时级”决定策略更新效率最后一个问题关乎敏捷性。如果你的模型池每月只增减 1-2 个模型比如新增一个 Gemma-3那么所有四层都适用。但如果你的场景是 MLOps 驱动的持续实验——比如每天上线 3 个微调后的 Qwen2.5 变体用 A/B 测试选出最优者然后灰度 5% 流量——那工具侧路由和托管聚合就会成为瓶颈。工具侧路由需要你手动改 17 个服务的代码托管聚合OpenRouter的模型添加需要人工审核通常 24 小时而自托管网关LiteLLM支持 API 动态注册模型POST /model/new配合 CI/CD可以做到“模型镜像推送到 ECR 后5 分钟内自动上线并接入路由”。我们有个客户做广告文案生成他们用 vLLM 部署了 23 个不同 LoRA 微调版本路由策略是“按广告行业垂直领域选择最匹配的微调模型”这个策略每天更新必须依赖自托管网关的动态能力。所以打开你的模型管理台账统计过去 30 天新增/下线模型的次数如果平均每天 ≥ 1 次那自托管网关就是你的必选项如果基本不动托管聚合的省心程度可能更匹配你的节奏。4. 四层混用实战如何在真实项目中组合使用避免“一刀切”陷阱4.1 混用原则按业务域隔离而非按技术栈隔离很多团队犯的致命错误是试图用一个网关统管所有流量。结果客服域的高并发请求拖垮了内部数据分析域的长文本处理。正确的做法是按业务域Business Domain划分路由平面。我们给某电商客户设计的架构是面向用户的 C 端服务App/Web全部走 OpenRouter。理由很实在——他们的 App 团队只有 2 个 iOS 开发没精力维护网关且 OpenRouter 的移动端 SDK 集成只需 3 行代码崩溃率比自研网关低 87%。内部运营系统CRM、BI 工具用 LiteLLM 自托管网关。因为运营人员需要“强制指定模型”功能比如对比 GPT-4 和 Claude 的文案风格这需要网关支持model参数透传而 OpenRouter 会把它当作非法参数拒绝。实时风控引擎毫秒级响应工具侧路由。风控逻辑写在 Go 服务里用if-else直接调用本地 vLLM endpoint绕过所有 HTTP 层P99 延迟压到 42ms。这种混用不是妥协而是精准匹配。OpenRouter 解决了“快速上线”问题LiteLLM 解决了“策略灵活”问题工具侧路由解决了“极致性能”问题。关键是要定义清晰的边界C 端流量走 OpenRouter其X-Request-ID会被注入到所有下游日志中方便全链路追踪运营系统调用 LiteLLM 时必须带上X-Domain: internalheader网关据此路由到专用集群风控服务则完全不经过网关形成独立平面。我们用 Istio 的 VirtualService 做了流量染色确保三套系统互不干扰。4.2 混用避坑警惕“路由嵌套”导致的雪崩效应最危险的混用是“网关套网关”。比如你用 LiteLLM 作为主网关但它后端又配置了 OpenRouter 的 endpoint。这看似能兼顾灵活性和托管便利实则埋下巨大隐患。问题在于错误传播的放大效应当 OpenRouter 的某个模型限流时LiteLLM 会收到 429 错误触发 fallback但如果 fallback 目标也是 OpenRouter 的另一个模型而那个模型也恰好限流LiteLLM 会继续 fallback直到耗尽所有选项最终返回 503。更糟的是LiteLLM 的重试机制默认 3 次会让这个过程重复 3 遍瞬间把流量放大 3 倍。我们在压力测试中发现这种嵌套在 2000 QPS 下会导致 OpenRouter 的错误率从 0.1% 飙升至 37%。解决方案只有一个严格禁止路由嵌套。如果要用 OpenRouter就让它作为终端 endpoint不要放在 LiteLLM 的model_list里如果要用 LiteLLM就让它直连模型不要把 OpenRouter 当作“模型”来配置。我们强制规定所有网关配置文件中api_base字段的域名必须属于你完全可控的基础设施如vllm-prod.internal、ollama-staging.company.com绝不允许出现openrouter.ai、fireworks.ai这类第三方域名。4.3 混用升级路径从托管聚合起步用数据驱动向自托管迁移对于绝大多数团队我们强烈推荐一条渐进式路径第一阶段0-3 个月用 OpenRouter 快速验证多模型价值。目标不是省钱而是收集真实数据哪些 query 类型在哪个模型上表现最好不同模型的平均延迟分布用户对不同模型输出的满意度差异我们给客户的标准动作是在 OpenRouter 控制台开启“Full Logging”把所有请求/响应存到 S3用 Athena 做初步分析。第二阶段3-6 个月识别出 20% 的高价值、高流量、高定制化需求的场景迁移到 LiteLLM。比如你发现“商品描述生成”占总流量 35%且需要注入品牌 Tone-of-Voice 指令这时就该用 LiteLLM 的modify_prompt功能做统一注入而不是在每个业务服务里硬编码。第三阶段6-12 个月基于第一、二阶段的数据构建智能路由的最小闭环。比如用第一阶段收集的延迟数据训练一个轻量级 XGBoost 模型预测“当前时刻调用 GPT-4 的 P95 延迟”然后在 LiteLLM 的pre_call_hook里调用这个模型动态决定是否 fallback。这条路径的核心是用托管平台买时间用自托管平台买控制用智能路由买效率。我们跟踪了 12 个按此路径执行的客户平均在第 8 个月实现了 ROI投资回报率转正——前期省下的开发时间后期都转化成了可量化的业务收益如客服首次解决率提升 18%内容生成通过率提升 33%。5. 常见问题与独家排查技巧实录5.1 问题LiteLLM 路由不生效所有请求都发向同一个模型这是新手最高频的报错。表面看是路由失效根因往往在健康检查Health Check配置。LiteLLM 默认启用health_check_interval30秒它会定期向每个模型 endpoint 发送GET /health请求。如果某个模型比如你的 Ollama 实例没有/health接口或返回非 200 状态码LiteLLM 会将其标记为unhealthy并从路由池中剔除。结果就是只剩下一个“健康”的模型通常是 OpenAI所有流量都涌向它。提示用curl -v http://your-ollama-host:11434/health检查 Ollama 的健康接口。如果不存在最简单的方案是启动一个 Nginx配置location /health { return 200; }然后把 Ollama 的 upstream 指向它。实操心得我们不再依赖/health而是用 LiteLLM 的health_check_asyncFalse 自定义health_check_function。这个函数会发送一个真实的POST /chat/completions请求带max_tokens1用实际调用能力代替心跳检测。虽然开销稍大但 100% 真实。5.2 问题OpenRouter 的“Model Fallback”在高并发下失效用户报告当 QPS 500 时Fallback 经常不触发导致大量请求超时。根本原因在于 OpenRouter 的 fallback 机制是客户端重试而非服务端路由。当你调用https://openrouter.ai/api/v1/chat/completions时OpenRouter 返回 429 或 504你的 SDK如openai-python才发起重试这中间有网络延迟和客户端重试逻辑的不确定性。解决方案永远不要依赖 OpenRouter 的 fallback 做核心业务保障。我们的做法是在业务代码里实现“双发”Dual-Send——同时向 OpenRouter 和你的备用 LiteLLM 网关发送请求用Promise.race()或asyncio.wait(..., return_whenFIRST_COMPLETED)获取第一个成功响应然后取消另一个请求。实测下来这比依赖 OpenRouter 的 fallback 稳定 4.2 倍。5.3 问题自托管网关的延迟监控不准P95 值虚高LiteLLM 的litellm_latency_seconds_bucket指标包含了DNS 解析、TCP 握手、TLS 握手、HTTP 请求发送、等待响应、响应读取的全链路时间。但你真正关心的是“模型推理时间”即从请求到达模型服务到模型返回 completion 的时间。这两者可能相差 10 倍比如 DNS 解析慢 200ms模型推理只 30ms。排查技巧用litellm --debug启动网关观察日志中response_time网关视角和model_response_time后端模型返回的x-model-response-timeheader的差值。如果差值大说明网络层有问题如果接近说明是模型本身慢。独家技巧我们给所有后端模型服务vLLM/Ollama加了一个 middleware自动注入x-model-response-timeheader。在 LiteLLM 的success_callback里用litellm.utils.get_model_response_time()提取这个值并单独上报为model_inference_latency_seconds。这才是你该优化的真实指标。5.4 问题智能路由的 AB 测试结果不可信客户反馈用 Langfuse 做 AB 测试发现模型 A 的“用户点击率”比模型 B 高 15%但人工抽检却发现模型 A 的输出质量更差。问题出在指标污染AB 测试的流量分配是随机的但用户行为如点击“重新生成”受多种因素影响网络延迟、UI 位置、用户当天心情不能直接归因于模型。解决方案必须引入双重差分法DID。我们设计了一个三组实验Control 组固定用模型 B、Treatment 组固定用模型 A、Holdout 组随机分配用于校准。用 Holdout 组的数据计算出“非模型因素”对点击率的影响基线再从 Treatment 组的提升中减去这个基线得到真实的模型效果。这个过程需要 Python 的causalimpact库但我们封装成了一个 CLI 工具llm-ab-test --analyze输入两组日志路径自动输出可信度报告。5.5 问题路由策略变更后旧流量仍在走老路径这是灰度发布的经典难题。LiteLLM 支持model_group的权重配置但很多人忽略了权重变更不是实时生效的。LiteLLM 的路由决策基于内存中的model_list修改 YAML 后需要POST /router/config/update或重启服务。但重启会导致连接中断。终极方案我们弃用了 YAML 配置改用数据库PostgreSQL存储路由策略。LiteLLM 启动时从 DB 加载初始配置然后启动一个 goroutine每 5 秒轮询 DB 的routing_rules表。当 DB 中的weight字段更新goroutine 会原子性地更新内存中的model_list。所有策略变更5 秒内生效零中断。这个方案的代码不到 200 行但解决了 90% 的灰度发布痛点。6. 最后一点真实体会路由的本质是“信任代理”不是技术玩具我做 AI Infra 这十年看过太多团队把多模型路由当成一个“酷炫的技术项目”花三个月搭起 LiteLLM 集群写满 500 行 YAML然后骄傲地宣布“我们实现了智能路由”。结果上线第一天客服主管打电话来“为什么我的 VIP 用户现在收到的回答全是英文”——因为路由规则里写了if user_tier vip: model gpt-4但用户 tier 数据是从旧 CRM 同步的字段名是vip_status不是user_tier。那一刻我意识到路由系统最大的敌人从来不是技术复杂度而是数据契约的模糊性。GPT-4 不认识你的“VIP”Claude 不理解你的“紧急工单”Qwen 更不知道你的“内部术语缩写”。路由策略再精妙如果输入的特征user_tier、query_intent、business_context本身是脏的、延时的、不一致的那所有智能都是幻觉。所以我现在的第一条铁律是在写任何一行路由代码之前先和业务方、数据团队、法务一起用白板画出这张图——左边是业务事件用户下单、客服创建工单、风控触发预警右边是路由需要的特征