多 LLM 编排：模型切换、对比与 fallback

单模型部署是一个你终将越过的决定

团队不会忠于单一的 LLM，也不该如此。快速回答支持问题的本地模型，在细微的法律分析上会失手。能处理推理的前沿模型，用来回答「这份文档里写了什么」又太贵。某个 provider 调价、下线模型或发生故障--突然间整个产品就停摆或需要重新议价。因此，严肃的 AI 平台把「用哪个模型」当作运行时决定，而不是安装决定。

Simmetric Chat 从头到尾都是这样处理的：每个 provider 边界都是一个策略，模型可按聊天选择，评估内建在界面中，故障时优雅降级而不是报错。本文走遍编排层--provider、切换体验、对比模式和 fallback 链。

五个一等 provider，二十个 preset

开箱即用时，平台与五个一等 provider 对话：Ollama（本地，privacy-first 默认值）、OpenAI、Anthropic、OpenRouter 和 Gemini。每一个都有专门的流式解析器--网络格式差异足够大，把流式当通用问题处理会产生细微 bug--因此 token 流、引用和终止事件都按 provider 解析，而不是近似处理。

在一等五家之外，二十个 provider preset 覆盖 OpenAI 兼容生态：DeepSeek、Mistral、Kimi/Moonshot、NVIDIA NIM、Qwen、xAI、Z.AI/GLM、MiniMax、LM Studio、GitHub Copilot 等等。由于这些服务实现 OpenAI 网络协议，新增一个只是一行配置--base URL、key、模型列表--而不是代码改动。因此一个部署可以混用本地 Ollama 处理敏感工作、云端前沿模型做深度分析、廉价的 OpenAI 兼容 provider 做批量总结，全都在一个 workspace 里。

配置遵循平台的优先级规则：环境变量设定基础设施级默认值，管理面板的改动立即生效，设置的解析顺序是数据库高于环境高于默认值。全局默认 provider 就只是一个默认值--可按 workspace 和按聊天覆盖。

不离开对话就切换模型

模型选择就住在对话所在之处。聊天输入框带一个模型徽章，显示下一条消息将由什么回答；点击它--或按 Cmd+K（Windows/Linux 上为 Ctrl+K）--打开快速切换面板。面板按 provider 分组模型，并用来自模型元数据的能力徽章标注它们：

• local-only--on-premise 运行，无数据外流
• fastest--当前 provider 集合中延迟最低
• smartest--可获得的最高质量
• reasoning--具备 chain-of-thought 能力

在输入框键入 /model <名称> 会立即切换到匹配的模型，当名称不是精确匹配时则以过滤后的面板作为回退。命令文本在发送前从消息中移除，因此 slash command 永远不会污染聊天历史。

两个细节让这件事从「可行」变成「顺手」。第一：切换发生在对话中途--同一个聊天可以从本地模型移到前沿模型再回来，每条消息都持久记录实际服务它的模型--模型使用的审计轨迹在切换中存活。第二：面板是 keyboard-first 表面--Cmd+K 模式让选择模型只需一次按键，而不是一趟设置页之旅，这是一项功能被人使用与被人配置一次就遗忘之间的区别。

并排对比

凭描述选模型是盲猜；看着两个模型对你真实 prompt 的回答来选，才是工程。按 Cmd+Shift+M（Ctrl+Shift+M）打开模型并排对比：两个面板同时流式输出不同模型对同一 prompt 的回答，逐 token 呈现。

它启用的流程正是评估 harness 形式化的流程，只是保留在日常界面里：

• 问一次，观察两个模型推理--延迟、措辞和 grounding 差异立刻可见
• 保留一条回答，用该模型继续对话
• 发送到单面板，把输出合并进一个线程
• 关闭对比，用其中任一模型继续

由于对比使用与普通聊天相同的流式和引用基础设施，对比的回答带着完整的 RAG 引用到达--你可以评估模型不仅如何表述回答，还评估它是否把回答建立在正确来源上。在 retrieval 平台上这一区别很重要：一个写得漂亮但引用错文档的模型，比一个写得朴素但引用正确的模型更糟。

fallback 链

模型会变得不可用：provider 故障、模型名下线、对话中途配额耗尽。Simmetric Chat 的答案是确定性的 fallback 链--如果所选模型不可用，系统自动回退到 workspace 默认值，再回退到全局默认值，再回退到任何可用模型。一个 toast 会通知你发生了切换，并提供撤销选项。

该链在周期性轮询（每三十秒）和流式过程中的 SSE 错误时都会触发，因此 provider 在回答中途故障时会被改道而不丢失对话。设计目标很具体：模型故障应当把平台降级到它的下一个模型，而不是降级到错误页。用户看到通知而不是 stack trace，运维看到的是仍在服务的平台。

对多实例部署，同样的设计哲学向外延伸--让聊天在负载下保持响应的流式 fan-out 和 job 队列是外置状态，在扩展文章中单独讨论。

编排层给你买到了什么

把线索汇总，编排层就是把 provider 选择从采购决定变成一组运行时杠杆的东西：

• 成本控制。 把批量工作路由到廉价的 OpenAI 兼容 provider，把前沿模型留给真正需要的 prompt，按聊天而非按部署。
• 隐私区。 让敏感 workspace 锚定在 local-only 模型上，同时让一般 workspace 使用云端 provider--能力徽章让隐私区在选择时可见。
• 韧性。 provider 故障变成模型切换而不是停机，靠 fallback 链和流式改道。
• 把评估变成习惯。 并排对比让「该标准化到哪个模型」从季度研究项目变成每周两分钟的检查。

一切都建立在平台其余部分使用的同一套策略模式 provider 边界上，因此新增 provider--一等或 OpenAI 兼容 preset--永远不会触及聊天、RAG 或 agent 循环。

在文档中阅读完整指南 →