企业官网建设流程全解析

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(model="gpt-4-turbo", temperature=0.2) elif len(query) > 500: return ChatAnthropic(model="claude-3-5-sonnet-20241022", max_tokens=2048) else: return OllamaLLM(model="qwen2.5:7b", num_ctx=4096)

这段代码就是路由策略。它的好处极其直接：零部署成本、调试链路极短（打个断点就能看到路由结果）、策略可与业务逻辑强耦合（比如根据用户历史投诉次数降级模型）。但代价同样锋利：策略不可复用、不可观测、不可治理。你无法在一个地方统一查看“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.0（2024 年底发布）和 v2.0（2025 年中发布）有质的区别。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 服务做策略优化。比如，你想实现“根据用户问题复杂度自动选择模型”：

1. 特征提取层：用一个小型分类模型（如 DistilBERT）实时分析用户 query，输出“复杂度分数”（0-10）；
2. 策略决策层：查一张预训练的映射表——复杂度 0-3 → Qwen2.5-7b，4-6 → Claude-3-haiku，7-10 → GPT-4-turbo；
3. 反馈闭环层：记录每次调用后的用户停留时长、是否点击“重新生成”、客服是否介入，每周用这些数据微调分类模型和映射表。

这个架构的关键突破在于：路由策略不再是静态配置，而是可度量、可迭代的“AI 模型”。我们给某法律科技公司落地时，初始映射表是律师团队凭经验写的，上线后发现“合同审查”类问题，即使复杂度只有 4，GPT-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 连接超时，而不是去重装 Docker？

3.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_interval=30（秒），它会定期向每个模型 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_async=False+ 自定义health_check_function。这个函数会发送一个真实的POST /chat/completions请求（带max_tokens=1），用实际调用能力代替心跳检测。虽然开销稍大，但 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_when=FIRST_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）本身是脏的、延时的、不一致的，那所有智能都是幻觉。所以，我现在的第一条铁律是：在写任何一行路由代码之前，先和业务方、数据团队、法务一起，用白板画出这张图——左边是业务事件（用户下单、客服创建工单、风控触发预警），右边是路由需要的特征（