答案摘要：本地大模型推理服务的高可用不能只靠增加 GPU 数量，需要同时设计统一入口、实例健康检查、请求队列、超时重试、会话与缓存、模型版本、故障切换和容量降级。聚匠科技会依据真实并发与允许停机时间，验证单实例故障、节点重启和回滚，而不是默认自购多台服务器就已具备高可用。
先定义高可用目标而不是先买第二台服务器
企业要先回答允许中断多久、最多丢失哪些请求、故障后是否可以降级，以及谁负责恢复。内部低频知识问答可能允许短时维护，而面向客户的客服智能体需要更快切换；批量摘要任务可以排队重试，正在执行业务写入的智能体则必须避免重复操作。
自购 GPU 的数量不直接等于高可用。两台服务器如果共用同一电源、交换机、存储或推理网关，公共组件故障时仍会同时不可用；两台实例加载不同模型或提示词版本，也会导致切换后答案口径变化。
方案中可用恢复时间目标、允许的数据与任务损失、降级能力和维护窗口描述要求。没有业务目标时，一味堆叠节点会增加采购、能耗、同步和运维成本。
把推理链路拆成五个可观察环节
| 环节 | 高可用职责 | 常见故障 |
|---|---|---|
| 统一入口 | 鉴权、限流、路由和请求 ID | 网关不可用或路由到错误版本 |
| 任务队列 | 排队、超时、取消和背压 | 请求堆积或重试放大流量 |
| 推理实例 | 模型加载、健康检查和容量上报 | 显存不足、进程退出或响应卡住 |
| 状态服务 | 会话、缓存、工具结果和幂等记录 | 切换后上下文丢失或重复执行 |
| 监控告警 | 资源、延迟、失败与业务成功率 | 硬件正常但回答链路已经失败 |
健康检查不能只判断端口是否开放。至少要区分进程存活、模型是否加载、能否完成最小推理、队列是否超限和依赖服务是否可达。发现故障后，入口应停止分配新请求，正在执行的任务按是否可重试、是否涉及写入分别处理。
容量、版本与降级清单要一起设计
- 单个节点退出后，剩余容量是否能承接关键请求。
- 新旧模型、量化方式、推理框架和提示词是否可以并行运行。
- 队列长度、首字时间、总耗时和错误率达到什么条件触发告警。
- 高峰时是否暂停长文生成、多模态或低优先级批处理。
- 本地模型不可用时，是否允许切换备用本地模型或受控云 API。
- 知识索引、配置、日志和幂等记录如何备份与恢复。
混合私有化可以在规则允许时使用外部模型作为降级，但敏感任务不能因本地故障自动发送到公网。全本地环境则要准备备用本地实例或明确人工接管。降级规则应按数据级别和任务风险设置，不能只按响应速度选择模型。
故障演练要覆盖模型之外的服务
验收时可在受控窗口停止一个推理实例，观察入口摘除、队列、用户提示、告警和恢复；再模拟网关、知识库、身份认证和业务接口异常，确认智能体不会在缺少依据时继续生成确定性回答。涉及工单或订单写入时，还要验证超时重试不会重复创建数据。
升级演练要保留旧模型、镜像、配置和知识版本，确认新版本异常时可以回滚。企业可通过 大模型私有化部署 确定基础设施，在 企业知识库 RAG 验证索引恢复，并对 AI 智能体 的工具调用单独测试幂等和补偿。
哪些企业先不要建设复杂集群
业务仍处于 PoC、请求量很低、模型频繁变化、没有专职运维或允许计划维护时，不适合直接建设复杂多机集群。可以先做好单机监控、自动拉起、备份和明确维护窗口，再依据真实故障与并发数据决定是否扩展。
高可用的目标是让关键业务按约定恢复，不是消除所有故障。采购前应先完成链路和风险分析，再决定双机、多机、冷备、热备或混合降级，避免把未使用的 GPU 资源误当成可靠性。
