冷热切换机制通过预置热备与冷备资源实现主模型失效时的平滑降级：热备已就绪、切换快（约300ms），冷备按需启动、延迟数秒至十余秒，二者协同提升服务稳定性。
☞☞☞AI 智能聊天, 问答助手, AI 智能搜索, 多模态理解力帮你轻松跨越从0到1的创作门槛☜☜☜
如果您调用某个大模型 API 时遭遇响应超时、5xx 错误或持续性 429 限流，服务可能已陷入不稳定状态。此时若无自动应对机制，用户将直面中断体验。冷热切换机制正是为解决此类故障而设计的分层接管策略，它通过预置热备与冷备资源，在主模型失效时实现平滑降级。以下是具体实施方式：
一、理解冷备与热备的本质差异
热备节点在系统正常运行期间即完成模型加载、端口绑定、数据库连接及心跳监听，处于“待命但已就绪”状态；冷备节点则仅保留在镜像或配置中，未占用 GPU 显存与计算资源，启动需数秒至十余秒。二者共同构成风险概率与资源效率权衡后的工程防线。
1、热备节点已在 CUDA 环境下完成模型权重映射与上下文初始化，实测 Fun-ASR-Nano-2512 热备切换耗时约 300ms。
2、冷备节点不参与日常流量，仅在热备同步失效后被拉起，其启动延迟取决于模型体积与硬件 IO 能力。
3、热备必须与主节点共享 history.db 等状态存储，并通过 Nginx 或自定义调度器检测 三次连续 502 Bad Gateway 后触发接管。
二、基于 OpenAI 兼容路由层的自动 fallback 配置
该方法依赖统一接口抽象，将业务请求中的模型质量等级（如 MODEL_QUALITY=high/normal/cheap）映射至不同平台的具体 model name，主线路失败时自动切至备用线路，无需修改业务代码。
1、在路由层定义主备映射表，例如：high → gpt-4-turbo（OpenAI）、qwen-max（通义千问）；normal → claude-3-haiku、glm-4-flash。
2、对每次请求封装 try-catch 块，主调用设置 connect:2s / read:15s / total:30s 超时约束。
3、捕获 5xx 或 429 错误后，按预设优先级顺序尝试下一档模型，最多执行 2 次降级跳转，避免链式雪崩。
三、利用 OneAPI 的内置降级熔断机制
OneAPI 提供开箱即用的后端模型不可用自动切换能力，其核心是将所有接入模型（含 Azure、Gemini、DeepSeek、文心一言等）统一为标准 OpenAI 格式，并内置健康探针与熔断开关，无需额外开发即可启用降级策略。
1、部署 OneAPI 单可执行文件或 Docker 镜像，确保其配置中已启用 fallback.enabled = true。
2、在 models.yaml 中为每个主模型指定至少一个 fallback_model，例如：qwen-plus 的 fallback_model 设为 zhipu-glm-4v。
3、启动后 OneAPI 自动周期性探测各模型 endpoint 的可用性，当某主模型连续 3 次 probe 失败，立即启用对应 fallback_model 响应后续请求。
四、手动触发冷备激活的应急操作流程
当监控发现热备亦发生异常（如 GPU 显存溢出、CUDA 初始化失败），需人工介入启用冷备，该流程适用于极端故障场景，目标是快速恢复基础服务能力而非零感知。
1、登录部署节点，执行 systemctl stop oneapi-hotstandby.service 停止热备进程。
2、修改环境变量 CONFIG_ENV=standalone，运行 ./oneapi --model cold-llama3-8b-instruct 启动冷备实例。
3、更新 Nginx upstream 配置，将流量指向新启动的冷备监听地址，并执行 nginx -s reload 生效。
