3. AI服务特点与扩缩容挑战：GPU资源、模型加载、推理延迟、成本控制
3.1 AI推理服务的本质特征
与传统的无状态Web服务或微服务不同，Kubernetes中运行的AI推理服务具有鲜明的有状态、高资源密度、延迟敏感三大特征。理解这些特征是设计扩缩容策略的前提。
- GPU资源独占性：GPU显存无法像CPU内存那样被多个Pod以细粒度共享（除非使用MIG或vGPU方案），一个Pod通常需要独占整张GPU卡或至少一个MIG切片。扩缩容的粒度因此被“卡”的数量所约束。
- 模型加载的冷启动代价：从镜像启动到模型权重加载至显存，再到完成预热（如TensorRT的engine构建或ONNX Runtime的session创建），往往需要数十秒甚至数分钟。这期间GPU利用率低，但Pod已占用资源。
- 推理延迟的敏感性：在线推理服务（如智能客服、实时推荐）对P99延迟有严格SLA。盲目扩容可能导致GPU资源碎片化，而盲目缩容则可能引发“雪崩式”超时。
- 成本与吞吐的博弈：GPU实例价格昂贵，空闲即浪费。但为了应对突发流量而长期预留大量GPU，又会造成巨大的财务开销。
核心矛盾：传统HPA基于CPU/内存利用率进行扩缩容，对AI服务几乎无效。因为GPU利用率高并不代表服务健康，模型加载期间的GPU利用率可能很低，而推理时的瓶颈往往在显存带宽或批处理大小（batch size）上。
3.2 扩缩容面临的核心挑战
将上述特征映射到Kubernetes的调度与资源模型中，我们归纳出以下四大挑战，它们相互关联，需要系统性解法。
| 挑战维度 | 具体表现 | 对扩缩容的影响 |
|---|---|---|
| GPU资源碎片化 | 不同模型需要不同显存（如2GB的BERT vs 40GB的GPT），单卡无法塞下多个大模型 | 扩容时找不到“整卡”可用，缩容后留下的碎片无法被新Pod利用 |
| 模型加载时长 | 从镜像拉取到模型权重加载完毕，耗时约30s~5min | HPA的默认扩容周期（30s）远小于加载时间，导致扩容“来不及” |
| 延迟与批处理耦合 | 提高吞吐需增大batch size，但会增加单请求排队延迟 | 单纯按QPS扩缩容会破坏动态批处理（continuous batching）的效率 |
| 成本控制粒度 | GPU按秒计费，但K8s调度最小单位是Pod | 缩容决策必须精准，避免因误缩导致重新拉起的高昂代价 |
3.3 可视化：AI服务扩缩容的决策压力模型
下图展示了AI推理服务在Kubernetes中扩缩容时，各要素之间的动态制约关系。左侧是流量与资源输入，中间是核心决策点，右侧是扩缩容动作带来的反馈回路。
3.4 典型场景复盘：为什么“抢跑”扩容比“精确”扩容更重要
假设一个基于GPT类模型的文档摘要服务，部署在3张A100（80GB）GPU上，每个Pod占用1张卡。某天上午10:00流量突增，QPS从50涨到200。
错误做法（传统HPA逻辑）：
# 假设HPA配置如下
# 当GPU利用率 > 70% 时扩容
# 当GPU利用率 < 30% 时缩容
# 指标类型：Pods 自定义指标（GPU利用率）
10:00 流量突增，GPU利用率从40%升至85%
10:01 HPA触发扩容，创建新Pod
10:01 新Pod调度成功，开始拉取镜像（镜像5GB，耗时约40s）
10:02 镜像拉取完成，容器启动，开始加载模型权重（约90s）
10:03 模型加载至80%，GPU利用率开始上升
10:04 新Pod就绪，加入服务
—— 总计耗时约4分钟，期间大量请求超时（P99 > 2s）这个案例暴露了三个关键问题：
- 扩容信号滞后：GPU利用率是“结果指标”而非“先行指标”。当利用率达到85%时，排队请求数可能已经超过GPU的批处理能力。
- 冷启动时间被低估：4分钟的扩容延迟中，真正调度只用了1秒，其余时间全部消耗在镜像拉取和模型加载上。
- 缩容同样危险：如果流量在10:10回落，HPA触发缩容，但若缩掉一个刚完成加载的Pod，那么下一次流量高峰将再次经历4分钟的“空窗期”。
关键教训：对于AI服务，扩缩容的决策必须基于预测而非反应。建议采用“提前扩容、延迟缩容”的策略——例如，当排队请求数超过GPU可承载batch size的1.5倍时立即扩容，而缩容则需要等待至少15分钟的稳定低负载窗口。
3.5 成本控制视角下的扩缩容粒度
GPU成本通常占AI服务总成本的70%以上。下表对比了不同扩缩容策略的成本效率与风险，帮助你在实际架构中做出权衡。
| 策略 | 资源粒度 | 成本效率 | 延迟风险 | 适用场景 |
|---|---|---|---|---|
| 整卡扩缩容 | 1 GPU / Pod | 中（可能浪费显存） | 低（模型独占） | 大模型（>20GB显存） |
| MIG/vGPU切片 | 1/8 GPU ~ 1/2 GPU | 高（充分利用碎片） | 中（需隔离配置） | 中小模型（<10GB） |
| 模型副本池 | 多Pod共享GPU（需调度器支持） | 最高（按需加载） | 高（模型切换耗时） | 低频但多样的模型 |
| Serverless GPU | 按请求计费 | 极高（零闲置） | 极高（冷启动不可控） | 实验性/开发环境 |
在实际的Kubernetes部署中，我们通常采用混合策略：为流量稳定的核心模型使用“整卡+副本数固定”的Deployment，为流量波动大的辅助模型使用“MIG切片+自定义指标HPA”，同时利用KEDA（Kubernetes Event-driven Autoscaling）监听Prometheus中的排队请求数指标，实现提前扩容。
成本控制实操建议：为每个GPU Pod设置
resources.requests.nvidia.com/gpu: 1，但不要设置limits（或与requests一致）。同时，在缩容时使用preStop钩子优雅排空当前正在处理的推理请求，避免强制杀死导致客户端重试风暴。