多模型路由设计：企业后端不要把模型供应商写死

企业应用接入大模型时，第一版常常直接在业务代码里调用某个模型 API。上线初期很快，后面就痛苦：价格变化、限流变化、模型效果波动、合规要求变化，每一次都要改业务代码。模型供应商不应该被写死在业务服务里。

更稳的方式，是在 Java 后端中引入模型路由层，把业务意图、模型选择、限流、降级和审计分开。

一、业务服务只声明意图

flowchart TD A[Business Service] --> B[Model Router] B --> C[Policy Engine] C --> D[Provider A] C --> E[Provider B] C --> F[Local Model] B --> G[Audit And Metrics]

业务服务不要关心具体 provider，只传入任务类型、延迟要求、成本等级、数据敏感度。

ModelRequest request = ModelRequest.builder() .taskType("contract_summary") .latencyClass("normal") .dataLevel("internal") .maxCostCents(20) .prompt(prompt) .build();

这样模型切换由路由层处理，业务代码保持稳定。

意图设计要具体。不要只传"AI任务"，而要说明任务类型、输出格式要求、延迟容忍度、成本上限和数据隐私等级。这些信息能帮助路由层做出更合适的选择。例如，同样是高优先级任务，客服对话要求低延迟，而合同摘要可以接受较长等待但要求高质量。意图越清晰，路由策略越精准。

enum TaskPriority { REAL_TIME, // 用户等待 INTERACTIVE, // 用户在线但可接受短暂延迟 BACKGROUND, // 批量任务 OFFLINE // 可排队 }

二、路由策略要可配置

模型选择不能全写死在 if else 里。不同任务对准确率、成本、延迟和合规要求不同。

routes: contract_summary: primary: provider_a.large fallback: provider_b.medium data_policy: no_public_provider chat_assistant: primary: provider_b.fast fallback: local.small max_latency_ms: 3000

配置不是为了炫技，而是让架构能跟着业务策略调整。财务、法务、客服、研发助手，可能需要完全不同的模型路线。

三、降级要有产品语义

模型降级不能只是换一个便宜模型。要告诉业务：降级后能力有什么变化，比如摘要更短、结构化字段减少、回答需要人工确认。

{ "model": "local.small", "degraded": true, "capability": { "max_context": "8k", "structured_output": false, "requires_review": true } }

业务层拿到降级标记后，可以调整提示、隐藏某些功能，或者给用户明确反馈。静默降级最容易制造信任问题。

四、审计和成本要按路由维度统计

模型路由层天然适合做指标：不同任务调用了哪个模型，成功率多少，平均成本多少，fallback 触发多少。

router_metrics ├── request_count by task_type and provider ├── latency_p95 by model ├── cost_cents by department ├── fallback_rate └── policy_reject_count

没有这些指标，企业 AI 应用很快会变成黑箱：钱花在哪里不知道，效果为什么波动不知道，供应商切换风险也不知道。

成本优化是模型路由的重要目标。通过聚合各部门的模型调用，可以在供应商处争取更优惠的价格。路由层还能实现成本分摊，把 AI 成本按部门或项目拆分，让各业务线对自己的 AI 用量负责。当成本可视化后，很多团队会自发优化 prompt、减少冗余调用或选择更经济的模型，这种自下而上的优化往往比自上而下推行更有效。

模型路由层在实际落地中还需要处理一个棘手的问题：模型的等效性判断。当系统从 GPT-4 切换到 Claude Sonnet，或从 Qwen-Max 切换到 DeepSeek-V3 时，即使输出内容相似，不同的输出格式、不同的 reasoning 风格、不同的 tool call 行为，都可能让下游业务代码出现轻微异常。我们的做法是在路由层增加"模型适配器"（Adapter）——每个模型对应一个 Adapter，负责将异构的响应统一为业务代码约定的格式。同时建立模型效果的回归测试集：保留 500 条历史请求及其期望输出，每次模型切换前自动跑一遍，对比准确率和格式一致性。这个测试集每周更新，确保覆盖最新业务场景的典型请求。通过 Adapter + 回归测试的双保险，我们将模型切换引起的业务故障率从 2.3% 降至 0.1% 以下。

五、总结

企业后端不要把模型供应商写死。模型路由层应承接业务意图、策略配置、provider 选择、降级语义、审计和成本统计。

业务代码越少感知具体模型，系统越容易长期演进。模型会变，供应商会变，但企业应用的服务边界应该稳定。