3. 自动扩缩容概念：什么是自动扩缩容、为什么需要、扩缩容的粒度

3.1 什么是自动扩缩容

自动扩缩容（Auto Scaling）是指系统根据实时负载、队列深度、GPU 利用率等指标，自动调整推理服务占用的计算资源数量，而无需人工干预。与传统的“峰值预留”模式不同，自动扩缩容追求的是资源供给与请求压力之间的动态匹配：请求增多时自动增加副本或设备，请求减少时自动回收空闲资源。

在分布式 AI 推理场景中，自动扩缩容并非简单地“加机器”，而是围绕推理时延目标（SLO）和资源成本两个约束进行闭环调节。一个完整的自动扩缩容系统通常包含四个环节：指标采集、决策引擎、执行动作、反馈修正。其中，决策引擎根据当前指标与目标指标的偏差，决定扩容或缩容的步长与速率。

核心理解：自动扩缩容的本质是“以指标为输入、以动作为输出”的反馈控制系统。它的目标不是让资源利用率永远保持高位，而是在满足延迟 SLO 的前提下，尽可能降低空闲资源的浪费。

3.2 为什么需要自动扩缩容

AI 推理服务的负载具有明显的波动性和突发性。以线上电商场景为例，白天峰值 QPS 可能是夜间低谷的 10 倍以上；大促活动期间流量可能在几分钟内翻倍。如果按照峰值流量长期预留 GPU 资源，会导致大量算力在非高峰时段闲置，造成严重的成本浪费。反之，如果资源预留不足，则会出现请求排队、超时甚至服务不可用。

具体而言，自动扩缩容解决以下三类核心问题：

成本控制：GPU 是昂贵的稀缺资源，按需扩缩容可避免为低峰期的空闲算力付费。例如，一个 8 卡 A100 的推理集群，若长期利用率仅 20%，每年浪费的成本可达数十万元。
SLO 保障：通过快速扩容吸收突发流量，避免 P99 延迟超出业务容忍阈值（如 50ms）。缩容时则通过平滑策略避免因资源骤减导致延迟抖动。
运维效率：人工扩缩容响应慢、易出错，尤其在凌晨或节假日流量异常时，自动扩缩容能实现分钟级甚至秒级响应。

常见误区：自动扩缩容不是“越快越好”。过于激进的扩容可能导致资源抖动和成本飙升；过于保守的缩容则可能在流量回升时来不及反应。合理的扩缩容策略需要结合业务流量特征、模型加载时间和 GPU 显存大小综合设计。

3.3 扩缩容的粒度

扩缩容的粒度决定了系统调整资源时的最小操作单元。不同粒度适用于不同的部署架构和业务需求，三者可以组合使用，但需要明确各自的适用边界。

3.3.1 实例级扩缩容

实例级扩缩容是最常见的粒度，以容器副本（Pod）或虚拟机实例为基本单位。每个实例运行一个完整的推理服务进程，包含模型加载、预处理、后处理等全部逻辑。扩容时增加副本数，通过负载均衡将请求分发到新副本；缩容时下线空闲副本。

实例级扩缩容的优点是实现简单、隔离性好，适合无状态或轻状态推理服务。缺点是每个实例都需要加载模型，当模型较大（如 7B 参数）时，实例启动和模型加载时间可能长达数十秒，无法应对秒级突发流量。

3.3.2 GPU 级扩缩容

GPU 级扩缩容针对显存和算力资源进行精细调整，常见于单机多卡或 GPU 虚拟化场景。具体实现方式包括：

MIG（Multi-Instance GPU）：将物理 GPU 切分为多个独立实例，每个实例拥有独立的显存和计算单元。例如，A100 40GB 可切分为 7 个 5GB 的 MIG 实例，按需分配给不同推理任务。
显存动态分配：通过 CUDA MPS 或 vGPU 技术，在多个推理进程之间动态共享 GPU 显存和算力。
整卡调度：在 GPU 集群中，将整张 GPU 卡作为调度单元，通过 Kubernetes 设备插件实现 GPU 卡的挂载与释放。

GPU 级扩缩容的粒度比实例级更细，适合多模型共享 GPU 或单模型显存占用较小的场景。例如，一个 7B 模型量化后显存占用约 6GB，可以在 40GB 的 A100 上同时部署多个模型副本，根据各模型的实时流量动态调整 GPU 资源分配。

3.3.3 模型级扩缩容

模型级扩缩容针对模型副本数量或模型分片方式进行调整，适用于超大模型或需要分布式推理的场景。具体包括：

模型副本增减：在多个 GPU 上分别加载同一模型的完整副本，通过请求路由将流量分发到不同副本。这与实例级扩缩容类似，但更强调模型层面的管理。
模型并行度调整：对于无法单卡加载的大模型（如 70B 参数），通过调整张量并行（Tensor Parallel）或流水线并行（Pipeline Parallel）的维度来改变 GPU 占用。例如，将张量并行度从 2 提升到 4，意味着模型分布在更多 GPU 上，单卡显存压力降低，但通信开销增加。
模型分片迁移：在推理过程中，根据各 GPU 的负载情况，动态迁移模型分片以平衡算力。

粒度	最小操作单元	适用场景	响应速度	典型工具
实例级	容器 / 虚拟机	无状态服务、轻量模型	秒级 ~ 分钟级	K8s HPA、KEDA
GPU 级	GPU 卡 / MIG 实例	多模型共享 GPU、显存优化	秒级	K8s Device Plugin、MIG
模型级	模型副本 / 分片	大模型、分布式推理	分钟级	vLLM、Ray Serve

3.4 案例：多粒度组合扩缩容实践

某在线翻译平台部署了一个基于 7B 参数模型的翻译服务，使用 4 台 A100 服务器（每台 8 卡）。业务流量呈现明显的“早晚高峰、午间低谷”特征，且大促期间流量会突增 5 倍。该平台采用了三级组合扩缩容策略：

实例级：每个 GPU 上部署 2 个推理容器实例，通过 KEDA 监控 RabbitMQ 队列深度，当队列积压超过 500 条时自动扩容实例。
GPU 级：使用 MIG 将每张 A100 切分为 4 个实例，每个实例分配 10GB 显存。根据各实例的利用率动态调整 MIG 分配比例，利用率超过 85% 的实例自动获得更多算力份额。
模型级：当单实例 QPS 超过 200 时，触发模型副本扩容，在空闲 GPU 上加载新的模型副本，并通过一致性哈希将流量路由到新副本。

通过三级联动，该平台在流量高峰时资源利用率保持在 75% 左右，P99 延迟稳定在 45ms 以内；低谷时自动缩容至 2 台服务器，每月节省 GPU 成本约 40%。

3.5 误区与复盘

误区一：只关注实例级扩缩容。很多团队仅依赖 Kubernetes HPA 进行副本扩缩，忽略了 GPU 显存和模型加载时间的影响。当模型加载需要 30 秒时，HPA 扩容的副本在 30 秒内无法提供服务，导致扩容期间请求仍然超时。复盘建议：将模型预热纳入扩容流程，或采用 GPU 级 MIG 切片实现秒级资源调整。

误区二：缩容过于激进。当流量下降时，系统快速缩容大量实例，但模型副本的销毁会导致已建立的连接中断，且如果流量在短时间内回升，重新加载模型的时间会造成服务空窗。复盘建议：设置缩容冷却时间（Cooldown），并采用“先扩容后缩容”的平滑策略。

误区三：忽略指标选择的合理性。仅使用 CPU 利用率作为扩缩容指标，在 GPU 推理场景中完全不适用。GPU 利用率、显存占用、请求队列深度、P99 延迟才是更直接的信号。复盘建议：建立多维指标联合判断机制，避免单一指标误触发。

3.6 小结

自动扩缩容是分布式 AI 推理服务降本增效的核心机制。理解三种粒度的差异与适用场景，是设计合理扩缩容策略的前提。实例级适合快速水平扩展，GPU 级适合精细资源调配，模型级适合大模型分布式推理。实际生产中，往往需要组合使用多种粒度，并配合合理的指标采集和反馈修正机制，才能实现既保障 SLO 又控制成本的目标。