导致 Kubernetes 自动伸缩失效的 AI 冷启动

Source: Dev.to

自动伸缩通常在微服务中表现极佳。

当流量增加时，Kubernetes 会启动新的 pod，并在几秒钟内开始处理请求。但 AI 推理系统的行为截然不同。 最近在探索推理设置时，指标中出现了奇怪的现象。用户遇到响应缓慢和请求队列增长，但自动伸缩器已经创建了更多的 pod。

更令人困惑的是：GPU 节点已就绪——但它们尚未进行有用的工作。

根本原因是 模型冷启动 时间。

为什么自动扩展适用于微服务

典型的自动扩展工作流

大多数服务只需要：

• 启动运行时
• 加载应用代码
• 连接数据库

启动时间通常只有几秒钟。

为什么 AI 推理服务表现不同

AI 容器需要更为繁重的初始化过程。在 pod 能够提供请求之前，它通常必须：

• 加载模型权重
• 分配 GPU 内存
• 将权重移动到 GPU
• 初始化 CUDA 运行时
• 初始化分词器或预处理流水线

对于大型模型，这可能需要数十秒甚至几分钟。

示例模型初始化

from transformers import AutoModelForCausalLM, AutoTokenizer
import torch

model_name = "meta-llama/Llama-7b"

tokenizer = AutoTokenizer.from_pretrained(model_name)

model = AutoModelForCausalLM.from_pretrained(
    model_name,
    torch_dtype=torch.float16
)

# Move the model to GPU memory
model = model.to("cuda")

上述代码将模型移动到 GPU 内存。大致加载时间：

在流量高峰期间，监控仪表盘可能会显示一些令人困惑的内容：

• GPU 节点可用
• 自动伸缩器正在创建 pod
• 资源已分配

但用户仍然会遇到响应缓慢的情况。

原因： GPU 节点在 pod 仍在加载模型时可能处于空闲状态。即使 Kubernetes 已将 pod 调度到 GPU 节点，模型必须完成加载后 pod 才能提供请求服务。系统在技术上拥有计算容量——但此时尚不可用。

在流量激增期间会发生什么

想象一个系统通常运行 2 个推理 pod。突然流量增加。

Kubernetes 会扩展部署：

2 pods → 6 pods

新 pod 必须先加载模型。示例时间线：

在此期间：

Users → API Gateway → Request Queue grows → Latency increases

自动伸缩起作用了——但太慢，未能防止用户受到影响。

Solution Pattern 1 — 预热推理 Pods

保持已经加载模型的预热 Pods。

架构

Users
   ↓
API Gateway
   ↓
Load Balancer
   ↓
Warm Inference Pods (model already loaded)
   ↓
GPU inference

流量高峰期间

Traffic spike
   ↓
Warm pods handle traffic immediately
   ↓
Autoscaler creates additional pods
   ↓
New pods join after model loads

结果：显著降低延迟峰值。

解决方案模式 2 — 事件驱动自动伸缩 (KEDA)

传统的自动伸缩通常使用 CPU 指标。AI 工作负载使用基于队列的指标伸缩效果更好。像 KEDA 这样的工具可以基于以下内容进行伸缩：

• 请求队列
• 消息积压
• 事件触发

架构

Incoming Requests
   ↓
Request Queue
   ↓
KEDA monitors queue
   ↓
Scale inference pods

这使得可以在延迟增加 之前 做出伸缩决策。

参考文献与进一步阅读

• KEDA documentation: https://keda.sh
• Kubernetes Horizontal Pod Autoscaler (HPA): https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/
• Hugging Face model loading guide: https://huggingface.co/docs/transformers/quickstart

方案模式 3 — 模型缓存

模型缓存通过在本地保留模型权重来帮助减少启动时间，而不是每次 pod 启动时都从远程存储下载或加载它们。

常见做法包括：

• 将模型存储在本地节点磁盘上。
• 使用持久卷。

这些方法使得在扩展事件中，新推理 pod 能够更快地加载模型。

Solution Pattern 4 — Dedicated Inference Servers

Specialized inference platforms such as NVIDIA Triton, KServe, or TorchServe are designed for production model serving and provide optimizations like:

• 动态批处理
• 高效的 GPU 利用率
• 模型缓存

…making large‑scale inference systems easier to manage and more performant.

将所有内容整合在一起

• 对流量峰值的快速响应
• 高效的 GPU 利用
• 可预测的扩展行为

关键工程经验

• AI 工作负载的行为与典型微服务截然不同。
• 模型初始化时间可能主导启动延迟。
• 自动扩缩容必须考虑冷启动延迟。
• 热 pod 能显著提升响应速度。
• 可观测性应包括模型加载时间指标。

最终思考

自动扩缩容功能强大——但它假设计算资源可以立即使用。AI 工作负载引入了一个新约束：

计算容量在模型加载之前是无用的。

设计可靠的 AI 基础设施意味着不仅要考虑资源的扩展，还要考虑这些资源多快能够准备好提供请求。