01

60 秒回答模板

保障 AI 服务全天稳定运行，我会先定义 SLO，例如可用性、P95/P99 延迟、超时率、错误率、队列等待和质量抽检通过率。资源层要做好 GPU/CPU/显存容量评估、模型预热、实例隔离、自动扩缩容、OOM 保护和健康检查。流量层要有限流、排队上限、优先级、熔断、重试退避和防雪崩，不能让突刺流量把模型实例全部拖死。降级层要准备缓存结果、小模型、规则兜底、异步处理、关闭非核心能力和友好的失败返回。依赖治理上要管理模型版本、prompt/schema 版本、外部 API、向量库和特征服务。监控要覆盖请求链路、GPU、模型输出、依赖、成本和业务指标，并配合灰度发布、回滚、压测和故障演练。

考点 SLO 先行
难度 真实面经题
回答目标 说明全天稳定运行依赖容量、隔离、降级、观测和发布治理，而不是单点优化。
02

深入解析

01

用 SLO 定义稳定

AI 服务的稳定性要同时看可用性、延迟、吞吐、错误率和输出质量。实时推荐或问答服务要关注 P95/P99 延迟、队列等待、超时率、模型错误率、GPU OOM、降级比例和用户成功率；离线或异步任务则更关注任务完成率、积压时长和重试成功率。只有先定义 SLO 和错误预算，才能判断什么时候扩容、限流、降级或回滚。

02

资源治理覆盖 GPU、模型实例和冷启动

AI 服务常见故障不是普通 CPU 打满，而是显存碎片、模型加载失败、GPU OOM、batch 抖动、实例冷启动慢和模型版本切换不一致。生产中应做模型预热、实例池化、显存水位监控、并发上限、负载均衡、进程自恢复和资源隔离。多模型服务还要避免一个大模型占满资源影响小模型，必要时按模型、租户或优先级拆池。

03

限流和降级要在故障前生效

流量突刺时，如果所有请求都排队等待大模型，P99 会恶化并引发级联超时。更稳的方式是入口限流、队列长度上限、优先级调度、超时取消、熔断下游、指数退避重试和请求去重。降级策略要提前设计，例如命中缓存、使用小模型、规则兜底、返回部分结果、转异步任务或暂时关闭高成本能力。

04

监控、发布和依赖治理形成闭环

AI 服务依赖模型文件、prompt、schema、向量库、特征服务、外部模型 API 和业务数据，每一层都可能导致全天运行中断。监控要包含 trace、结构化日志、模型版本、prompt 版本、依赖成功率、输出空值率、异常标签分布和成本。发布时应灰度、金丝雀、双版本对比和一键回滚；日常要做压测、故障注入和容量复盘，证明服务在依赖慢、GPU OOM、模型加载失败和流量翻倍时能恢复。

03

易错点

  • 把稳定性理解成“多加机器”，忽略队列、限流、降级和依赖治理。
  • 健康检查只测进程存活，不测模型加载和真实推理。
  • 没有队列上限和超时取消，流量突刺时请求越积越多。
  • 只监控系统资源，不监控模型输出质量、空结果率和版本变化。
  • 灰度和回滚缺失，模型或 prompt 小改动直接影响全量用户。
04

面试官追问

GPU OOM 怎么处理？

先做显存水位和 batch 大小监控，限制单实例并发、最大输入长度和动态 batch 上限，必要时拆分模型池。发生 OOM 后要自动摘除实例、清理上下文、重启预热，并通过降级或排队上限保护入口，避免所有实例同时崩溃。

外部模型 API 不稳定怎么办？

要有超时、熔断、重试退避和供应商隔离。核心路径可以准备备用模型、本地小模型或缓存结果；非核心路径可以异步化。重试必须有上限，否则外部慢会被内部重试放大成雪崩。

健康检查只返回 200 够吗？

不够。AI 服务需要检查模型是否加载完成、GPU 是否可用、关键依赖是否可连、队列是否过载、版本是否一致。浅层 ping 只能说明进程活着，不能证明服务真的能推理成功。

如何验证服务能稳定跑一整天？

除了单元测试，要做长时间压测、峰值压测、故障注入、灰度观察和回滚演练。验收指标包括内存和显存无持续泄漏、错误率稳定、P99 不漂移、队列不无限增长、降级可控、重启后能自动恢复。