课程导入：学习目标、课程大纲、适用人群、前置知识
欢迎来到《分布式AI推理服务自动扩缩容调优》课程。在正式开始之前，我们需要先明确这门课程将带你走向哪里、需要你具备什么基础，以及整个学习路径如何展开。自动扩缩容（Auto Scaling）是分布式AI推理系统在生产环境中稳定运行、控制成本的核心能力，但它的调优涉及多个层面：从底层指标采集、负载预测，到弹性策略设计、冷启动优化，再到压测验证与成本治理。本章作为全课程的起点，将为你绘制一张完整的学习地图。
1.1 学习目标
完成本课程后，你将能够独立完成一个分布式AI推理服务的自动扩缩容方案设计、部署与调优。具体而言，你将掌握以下核心能力：
- 理解推理服务的负载特征：区分CPU密集型、GPU显存密集型、I/O密集型等不同推理负载，并识别其QPS（每秒查询数）、延迟、显存占用等关键指标的变化规律。
- 掌握主流扩缩容技术栈：包括Kubernetes HPA（水平Pod自动扩缩）、KEDA（基于事件驱动的自动扩缩）、自定义指标适配器（如Prometheus Adapter），以及GPU共享调度等进阶方案。
- 设计弹性策略：能够根据业务SLA（服务等级协议）和成本约束，选择合适的扩缩容触发指标、阈值、冷却时间与最大/最小副本数。
- 解决冷启动与流量突刺问题：掌握模型加载优化、预热缓存、预测性扩缩容等技巧，避免因扩容延迟导致请求超时。
- 建立压测与观测体系：使用wrk、ghz、Locust等工具模拟推理流量，结合Prometheus、Grafana构建可观测性看板，验证扩缩容效果。
- 进行成本与性能的权衡：通过缩容策略、Spot实例（抢占式实例）使用、模型分片等手段，在保证SLA的前提下降低推理成本。
1.2 课程大纲
本课程共30章，分为五个模块，从基础概念逐步深入到生产环境实战。下表展示了各模块的核心主题与章节分布：
| 模块 | 章节范围 | 核心主题 |
|---|---|---|
| 基础与原理 | 第1-5章 | 课程导入、推理服务架构、扩缩容基础概念、Kubernetes弹性原语、负载特征分析 |
| 指标与观测 | 第6-10章 | Prometheus指标采集、自定义指标开发、GPU监控、延迟与吞吐指标建模、Grafana看板设计 |
| 策略与算法 | 第11-18章 | HPA进阶、KEDA事件驱动扩缩容、预测性扩缩容、基于队列长度的扩缩容、多指标协同策略 |
| 工程实践 | 第19-25章 | 模型冷启动优化、预热与缓存、压测方法论、混沌工程与故障注入、扩缩容安全与限流 |
| 成本与进阶 | 第26-30章 | 成本建模、Spot实例管理、GPU共享与分片、混合云弹性、全链路调优案例复盘 |
每个章节都包含理论讲解、可运行的配置示例、故障排查思路以及课后练习。第30章将综合运用全部知识，完成一个端到端的调优项目。
1.3 适用人群
这门课程适合以下三类人群：
- AI平台工程师 / MLOps工程师：你负责搭建和维护推理服务的基础设施，需要解决服务在流量波动下的稳定性问题，并降低GPU资源成本。
- 后端开发工程师：你正在将训练好的模型部署为在线服务，希望了解如何配置自动扩缩容，避免因突发流量导致服务雪崩。
- 运维工程师 / SRE：你关注服务的SLA与资源利用率，需要掌握Kubernetes生态下的弹性伸缩工具链，并建立有效的监控告警体系。
如果你是一名学生或研究人员，对分布式系统和AI服务化感兴趣，这门课程同样能帮助你建立从理论到实践的完整认知。
1.4 前置知识
为了确保学习效果，建议你具备以下基础。如果某些部分尚不熟悉，可以在学习过程中随时查阅相关资料补齐。
- Docker与Kubernetes基础：了解容器镜像的构建与运行，熟悉Pod、Deployment、Service、Namespace等核心资源对象。能够使用
kubectl命令进行基本的部署和排查。 - Linux命令行与Shell脚本：能够编写简单的Shell脚本，理解进程、端口、文件系统等基本概念。
- Python或Go基础：本课程中的自定义指标、Operator开发等章节会涉及代码示例，需要能够阅读和修改简单的Python或Go代码。
- HTTP与RESTful API基础：理解请求/响应模型、状态码、超时设置等概念，因为推理服务通常以HTTP接口对外提供。
- 基础统计学概念：了解均值、百分位数（如P99）、标准差等概念，这对于理解延迟指标和扩缩容阈值至关重要。
1.5 核心原理：为什么自动扩缩容如此重要？
在深入技术细节之前，我们先从原理层面理解自动扩缩容在AI推理系统中的位置。一个典型的分布式推理服务架构如下图所示：
上图展示了自动扩缩容在推理系统中的核心位置。客户端请求经过负载均衡分发到一组推理Pod，Prometheus持续采集每个Pod的QPS、延迟、GPU利用率等指标。扩缩容控制器（HPA或KEDA）根据预设策略（如“当P99延迟超过200ms且持续3分钟时扩容”）计算出期望副本数，并调用Kubernetes API调整Deployment的副本数。这个闭环系统直接决定了服务的两个关键属性：稳定性（能否扛住流量高峰）和经济性（是否在低谷期浪费资源）。
1.6 常见误区与学习建议
根据我们过往的教学和工程实践经验，初学者在学习自动扩缩容时容易陷入以下几个误区：
- 误区一：只关注CPU指标。对于AI推理服务，GPU显存利用率、推理队列深度、P99延迟往往比CPU更重要。仅依赖CPU会导致扩容滞后。
- 误区二：忽略冷启动时间。如果你的模型加载需要30秒，而HPA的扩容响应时间是1分钟，那么即使扩容成功，流量高峰可能已经过去。必须将冷启动时间纳入策略设计。
- 误区三：阈值设置过于激进。将阈值设得过低会导致频繁扩缩容（抖动），不仅增加API Server压力，还可能造成成本失控。
- 误区四：没有压测验证。直接在生产环境调整参数风险极高。建议在预发环境使用录制流量或工具压测，验证策略的鲁棒性。