Multi-LLM 架构：显式表达差异
用明确的工作负载契约、类型化适配器和证据管理多个模型，而不是假装它们完全相同。
速览
声明意图、所需能力、质量、延迟、安全、数据与故障行为。
版本化每个模型与端点的能力、运行位置与行为。
使用类型化供应商适配器，同时保留原生字段与出口。
连接路由决策、输出、工具使用、安全事件与评估结果。
四种 Multi-LLM 架构模式
主动—被动故障切换为可用性事故保留已验证备用项；能力路由选择支持必需模态、工具或上下文的模型；成本或延迟分层把常规任务交给高效路由，只有验证器判断能力不足时才升级；Ensemble则调用多个模型，再合并、排序或讨论结果。
系统可以按工作负载使用多种模式，但每种模式都会引入不同风险：故障切换可能带来语义漂移，分层可能误判困难请求，能力路由依赖准确目录，Ensemble 会放大延迟与成本，而且仍需要可信聚合规则。应从要解决的故障或质量问题出发选择模式，而不是看手里有多少供应商。
稳定抽象应是版本化工作负载契约，而不是万能模型。契约描述所需结果、Schema、工具、区域、安全规则、截止时间、质量下限与成本上限；能力目录和策略路由器把契约映射到合格端点，窄 Provider Adapter 容纳不可避免的协议差异，不让其渗入应用代码。
Multi-LLM 模式与取舍
| 模式 | 最适合 | 选择前验证 |
|---|---|---|
| 主动-被动 | 已验证备用项能够保留契约时提升可靠性。 | 冷路径、语义漂移、额外凭证与未测试恢复。 |
| 能力路由 | 工具、模态、上下文或领域能力因负载而异。 | 目录准确性与预检拒绝变得关键。 |
| 成本或延迟分层 | 大批量负载接受有边界的质量与功能取舍。 | 节省可能隐藏重试、审核成本或较低可接受输出率。 |
| Ensemble | 高价值任务受益于多样性、批判或共识。 | 更高成本、延迟、聚合复杂度与相关故障。 |
| 供应商可移植性 | 监管、商业或连续性要求需要多种选择。 | 共同分母可能抹去有价值的供应商特定功能。 |
围绕版本化契约构建
明确所需输入、输出、工具、上下文、安全、数据、SLO 与预算。
为模型、端点、策略、价格与生命周期事实标注来源、验证并设置过期。
只转换受支持语义，并显式暴露供应商特定扩展。
按工作负载与路由版本测量质量、安全、延迟、成本与故障。
验证多模型生产路径
应在工作流层测试每种模式。模型可能通过单次 Benchmark，却因工具 Schema 不同、取消处理不佳，或故障切换后产生无效结构化输出而失败。需要使用真实工作负载分布，以及能够代表业务结果的验证器。
- 建立包含能力、策略约束与可量化验收标准的 Golden 工作负载集。
- 每个合格端点与 Adapter 通过契约测试后，才能加入版本化目录。
- 在供应商宕机、配额压力、慢流、目录过期与验证器失败时回放路由。
- 测量语义有效性、工具完成情况、尾延迟与每个可接受结果的总成本，而非孤立 Token 价格。
- 测试 Ensemble 的分歧与聚合规则，包括没有任何答案应被接受的情况。
- 按工作负载灰度策略变更，设置评测门禁，并可立即回滚到旧版本。
连接契约、目录与证据
应用提交工作负载别名与版本化契约。路由器将其与可审计能力目录、租户策略和当前运营状态关联，生成包含端点、Adapter、故障切换上限与验证规则的 Route Plan。硬过滤必须先于成本或延迟优化执行，确保不合格模型不会因为分数高而胜出。
Gateway 在同一父截止时间下执行计划，并为每次 Attempt 写入标准化与供应商原生证据。应保存契约、目录与策略版本、候选排除原因、所选路由、验证结果和用量。离线评测可以更新目录可信度并建议后续策略，但不应修改正在执行的决策。
生产规则：模型只有通过所需工作负载契约且回滚路径仍可用后，才能进入生产路由。
在模型层上增加外部能力层
多个模型扩展推理选择，但不会自动可靠访问外部 API、工具、服务与实时数据。QVeris 通过 Discover → Inspect → Call 提供互补能力层；能力 Schema、权限与供应商证据应独立于路由器选择的模型进行检查。
一个 Workflow Trace 可贯穿模型选择与能力执行，但凭证、Action ID、重试预算和可用性策略应分别维护。如果工具结果已经验证后才发生模型故障切换，应把结果传给下一个模型，而不是重复外部动作；只有新鲜度契约明确要求时才重新调用。
FAQ
为了可靠性、能力匹配、商业灵活性、区域需求、延迟或成本，但必须有显式契约。
不应。稳定的高风险负载可能更适合固定模型与已验证故障切换。
在模型与端点变化时维护真实能力数据与工作负载特定证据。