大模型服务故障时，进程还在运行，不代表用户仍能正常获得回答。模型可能加载失败、推理队列堵塞，或请求持续超时。要缩短中断时间，大模型服务器高可用与故障切换架构需要同时检查服务是否可用、及时停止向故障实例发流量，并验证备用实例确实能接住请求。
探测“活着”与“能服务”是两回事
Kubernetes 常用三类探针处理容器状态。存活探针（liveness）判断进程是否需要重启；就绪探针（readiness）决定实例是否接收新请求；启动探针（startup）则为模型加载预留时间，避免启动较慢时被存活检查误判。三者不能互相替代：模型仍在下载或载入权重时，应暂缓就绪检查，而不是不断重启进程。
探针也不宜只访问一个返回 HTTP 200 的健康接口。接口可以报告模型是否已加载、推理后端是否可调用，以及关键依赖是否异常。更深的检查可定期发送短输入并确认返回结构正确，但应控制频率和输入长度，避免探测本身占用过多推理资源。探测答案是否“聪明”属于质量评估，不适合作为每几秒执行一次的健康判断。
把故障探测接到流量切换上
先摘除，再恢复
实际链路通常由 Kubernetes Service、入口负载均衡器或 Envoy 等代理把请求分配到可用实例。readiness 失败后，控制面会更新可接收流量的实例集合；若入口还有独立健康检查，也要确认它与实例状态同步。否则，编排系统认为实例已下线，代理却仍可能把请求转发过去。
切换策略应区分新请求和进行中的请求。实例被摘除后，停止接收新请求；已经开始生成的流式响应通常无法无缝迁移到另一台服务器。客户端可在连接中断后重新发起请求，但要评估重复生成的成本，并设置合理的超时、退避和重试上限。不要对所有失败无条件重试，否则故障期间的重试风暴会进一步压垮剩余实例。
确保备用容量可接管
自动切换只有在备用实例已具备接单条件时才有意义。确认其模型版本、推理配置和依赖一致，并通过真实的短请求验证推理路径；还要留出足够并发余量。若所有实例平时都接近满载，故障后流量集中到少数节点，排队时间可能迅速上升。可通过限流、排队上限或降低非关键请求优先级，防止系统整体失去响应。
一套可执行的检查顺序
- 划分检查目标：用启动探针覆盖模型初始化，用存活探针处理进程卡死，用就绪探针控制是否接收流量。
- 设置保守阈值：先依据模型加载时间、推理时延和业务超时确定检查周期。在线服务可从数秒一次、连续失败两至三次后摘除开始评估；具体取值应在目标环境压测，避免短暂抖动触发频繁切换。
- 验证流量路径：在测试环境让一个实例停止就绪，检查入口是否停止向它分配新请求，并确认其他实例能正常返回结果。
- 演练恢复过程：恢复实例后，观察它是否先通过健康检查再重新接流量；同时查看错误率、排队长度、请求时延和探针失败原因。
- 设置安全边界：限制重试次数与并发，保护剩余实例；为流式请求说明断线后的处理方式，避免客户端误以为输出会自动续接。
阈值与方案如何取舍
检查越频繁，故障通常越早被发现，但探测开销和误判风险也会增加。以几秒为间隔、连续失败数次作为摘除条件，是可用于起步验证的范围，不是通用标准；模型启动时间、网络抖动、服务时延和集群规模都会改变合适阈值。Prometheus 可用于观察时延、错误率和队列指标，帮助判断探针是否过于敏感，但监控告警本身不能替代流量切换。
对短请求服务，可采用实例级健康检查并让负载均衡自动避开异常节点；对长时间流式生成，则需要额外设计客户端断线提示、有限重试和请求去重策略。选择大模型服务器高可用与故障切换架构时，应把检测、摘流、备用容量和请求重试作为一条完整链路验证，而非只检查某个容器是否存活。
常见问题
探针失败后要立即重启模型吗？
不一定。就绪检查失败通常只应让实例暂时停止接收新请求；只有存活检查确认进程无法恢复时，才考虑重启。
能否用一次生成结果判断模型健康？
可以用短请求检查推理链路是否工作，但不宜频繁执行，也不应把回答质量判断混入基础可用性探测。
自动切换能接续中断的流式回答吗？
通常不能直接接续。切换可以保护后续新请求，已经断开的生成请求需要由客户端按约定提示、重试或结束。
怎样确认切换真正有效？
在测试环境模拟实例失去就绪状态，核对新请求是否绕开该实例、剩余实例是否有容量，以及实例恢复后是否经过检查才重新接流量。
