一句话定义
自动扩缩容（Autoscaling）就是系统根据实时负载，自动增加或减少计算实例：忙时加机器，闲时退掉，让容量跟着需求走，同时兼顾体验和成本。
原理：像餐厅按排队人数加窗口
传统 Web 服务跑在 Kubernetes（K8s）上，常用 Horizontal Pod Autoscaler（HPA）做自动扩缩容。它盯着 CPU、内存或每秒请求数，超过阈值就多开几个 Pod，低于阈值就关掉几个。这就像餐厅看到排队变长，立刻多开一个点餐窗口。普通服务加一个 Pod 通常几秒到几十秒：拉镜像、启动进程、挂上配置，就能接客。
为什么 GPU 推理常常来不及
GPU 推理的冷启动（Cold Start）完全是另一回事。从“决定扩容”到“真正能接请求”，中间要调度 GPU 节点、拉取镜像、把几十 GB 的模型权重加载进显存、初始化推理引擎，还要跑几轮预热（Warmup）。这一套走完，常常是分钟级，而不是秒级。
如果还按 CPU 利用率触发扩容，问题更大：CPU 指标本身有采集和判断滞后，等它涨上去，请求早已在队列里排队甚至超时。GPU 推理的瓶颈也可能不在 CPU，而在显存、批处理队列或带宽。用 CPU 当信号，就像用餐厅门口的停车数量判断后厨忙不忙，常常不准。
和相邻概念的区别
| 概念 | 管什么 | 典型信号 | 搬到 GPU 推理的坑 |
|---|---|---|---|
| HPA | Pod 数量 | CPU、内存、自定义指标 | CPU 不敏感，扩容太慢 |
| VPA | Pod 资源规格 | 历史用量 | 调整常要重启，不适合频繁变 |
| Cluster Autoscaler | 节点数量 | 调度失败、资源不足 | 加节点加冷启动，更慢 |
| 事件驱动扩缩容 | 按队列/事件 | 队列长度、消息数 | 更贴近推理，但仍需预热 |
对从业者意味着什么
推理服务的扩容信号要从 CPU 换成更贴近用户体验的指标：排队请求数、首 AI 词典：Token">Token 延迟（TTFT）、GPU 利用率和显存占用。同时保留最小副本，做模型预热、镜像预拉取、节点池预留；扩容要快，缩容要慢，避免来回抖动。具体工具能力和阈值以官方页面为准。
对普通人意味着什么
高峰期 AI 应用排队、回答变慢，或者某些时段更便宜，背后往往就是自动扩缩容在权衡。做得好，你几乎无感；做得差，要么卡住，要么账单飙升。