云端AI部署基础：云服务模型与AI部署形态
在深入监控与告警体系之前，必须先厘清云端AI应用到底“跑在什么上面”。云服务模型决定了资源的边界与责任归属，AI部署形态决定了请求的流量模式与生命周期，而部署架构则决定了故障传播的路径。这三者共同构成了监控指标选取、告警阈值设计以及故障定位逻辑的底层依据。
2.1 云服务模型：IaaS / PaaS / SaaS
云服务模型本质上是“你管到什么层、云厂商管到什么层”的契约划分。对于AI部署而言，三种模型对应着截然不同的运维自由度与监控深度。
| 维度 | IaaS（基础设施即服务） | PaaS（平台即服务） | SaaS（软件即服务） |
|---|---|---|---|
| 典型云产品 | EC2、CVM、GPU裸金属 | SageMaker、AI Platform、Kubernetes | 云端API、预训练模型服务 |
| AI部署方式 | 自建推理容器、自定义训练集群 | 托管推理端点、AutoML流水线 | 直接调用模型API，无基础设施感知 |
| 监控责任 | 基础设施层（CPU/GPU/内存/网络）全部自管 | 平台层由云厂商负责，应用层自管 | 仅能监控业务指标（调用量、延迟、错误率） |
| 告警深度 | 可采集到GPU温度、显存ECC错误、PCIe带宽 | 可获取容器重启、模型加载失败、自动扩缩容事件 | 只能看到黑盒API返回码与SLA偏差 |
核心判断：选择IaaS意味着你需要自己构建从“物理硬件”到“模型进程”的全栈监控；选择PaaS意味着你放弃了对底层硬件的可见性，但获得了平台级的健康检查与自动恢复能力；选择SaaS则几乎完全依赖服务商的SLA承诺，你的监控重心应放在“业务影响面”而非“技术根因”。
在AI部署场景中，IaaS常用于对GPU型号、驱动版本、推理延迟有极致要求的自研场景；PaaS适合需要快速迭代、弹性扩缩容的标准化推理服务；SaaS则适合直接嵌入业务流的即用型AI能力（如OCR、语音识别）。监控策略必须与所选模型匹配，否则会出现“告警了却无权处理”或“故障发生了却无指标可查”的尴尬局面。
2.2 AI部署形态：在线推理与批量处理
AI模型部署后的工作负载模式，直接决定了监控指标的选择与告警触发逻辑。两种典型形态——在线推理与批量处理——在延迟敏感度、流量特征、故障影响面方面存在本质差异。
在线推理（Online Inference）
- 请求模式：单条或小批量同步请求，用户或上游服务等待实时响应。
- 核心指标：P99/P95延迟、超时率、错误率、GPU利用率峰值、队列积压。
- 故障特征：流量突增导致GPU显存溢出（OOM）、模型推理线程阻塞、冷启动延迟飙升。
- 告警重点：延迟超过SLA阈值（如P99 > 300ms）、错误率超过1%、GPU显存使用率持续高于90%。
批量处理（Batch Processing）
- 请求模式：大规模数据分片异步处理，通常由任务调度器触发，无实时交互。
- 核心指标：任务吞吐量（样本/秒）、任务失败率、重试次数、队列深度、单批次完成时间。
- 故障特征：数据倾斜导致部分Worker过载、检查点失败引发任务回滚、GPU利用率低但任务卡死。
- 告警重点：任务卡顿超过预期时长、失败率超过阈值、队列积压持续增长、自动重试超过最大次数。
监控视角差异：在线推理的告警必须“秒级响应”，因为用户直接感受到延迟；批量处理的告警可以“分钟级响应”，因为任务有重试机制和缓冲队列。但批量任务一旦失败，影响的是数据产出时效，可能引发下游链路连锁延迟。
2.3 部署架构概述：从单体到微服务
AI部署架构的演进直接影响故障域的大小。早期常见的单体推理服务将所有功能打包在一个进程中，而现代云原生架构则拆分为多个可独立扩展的组件。
一个典型的云端AI推理架构通常包含以下层次：
- 接入层：负载均衡器（如ALB/NLB）或API网关，负责流量分发、鉴权、限流。
- 推理引擎层：运行模型的容器组（Pod/ECS），可能是无状态多副本，也可能是有状态的GPU节点池。
- 中间件层：消息队列（用于异步解耦）、缓存（Redis用于特征缓存）、对象存储（用于模型文件与中间结果）。
- 数据层：特征数据库、向量数据库（用于检索增强生成）或传统的关系型数据库。
监控告警必须覆盖从“用户请求进入负载均衡”到“推理结果返回”的全链路。任何一个环节的故障都会表现为上游的超时或下游的数据异常。例如，当GPU节点因显存耗尽而重启时，负载均衡会将流量转移到剩余节点，可能导致剩余节点延迟飙升——此时监控系统需要同时捕捉“节点重启事件”和“延迟飙升告警”，才能快速定位根因。
常见误区：只监控模型推理延迟，却忽略了负载均衡层的健康检查频率、队列积压情况以及下游特征服务的可用性。在微服务架构中，80%的AI服务故障并非模型本身的问题，而是依赖的周边组件（如特征服务、模型存储、鉴权服务）出现异常。
2.4 案例复盘：一次典型的在线推理故障
某电商推荐系统采用PaaS托管推理端点，模型部署在GPU节点池上。某日大促流量突增，监控告警显示：
2025-03-15 14:23:17 [CRITICAL] inference-endpoint: P99 latency 850ms (threshold: 300ms)
2025-03-15 14:23:20 [WARNING] inference-endpoint: GPU memory utilization 97% on node-3
2025-03-15 14:23:25 [ERROR] inference-endpoint: 5% requests returning 503 Service Unavailable
2025-03-15 14:23:30 [INFO] autoscaler: scaling out 2 replicas (current: 4, target: 6)故障分析过程：
- 首先看到P99延迟飙升，初步怀疑模型推理变慢。
- 进一步检查GPU显存，发现node-3显存占用97%，接近OOM阈值。
- 503错误率上升，说明部分请求因节点过载被拒绝。
- 自动扩缩容已触发，但新副本冷启动需要约2分钟，期间延迟仍会持续偏高。
根因定位：大促流量超出预期，原有4个GPU副本的显存总量不足以承载并发请求，导致推理请求在GPU上排队，延迟飙升。同时，部分请求因排队超时被网关主动断开，表现为503错误。
改进措施：
- 将自动扩缩容的触发阈值从“CPU利用率70%”改为“GPU显存利用率80%”，提前扩容。
- 增加队列深度监控，当推理请求排队数超过50时提前告警。
- 为关键模型配置预留实例（Warm Pool），避免冷启动延迟。
复盘要点：监控告警的价值不在于“发现问题”，而在于“压缩故障定位时间”。如果只设置了延迟告警而没有GPU显存监控，工程师可能需要花费10分钟才能定位到资源瓶颈；而完善的层级化监控（延迟→资源→事件）可以在1分钟内完成根因判断。