快速扩缩容

在生产环境中运行 LLM 推理，与训练模型完全是两回事。训练通常是批处理式、 可预测的，而推理则由实时用户需求驱动。这种需求往往呈现突发性、 难以预测，并且对延迟和停机几乎没有容忍度。

这意味着系统必须在流量高峰期快速扩容，并在空闲时缩容至零以节省成本。 这种弹性是实现效率的基础。

然而，许多组织把推理当作训练来对待：它们通过长期承诺预先分配固定的 GPU 容量。这通常会导致：

• 过度配置：GPU 容量被浪费，空闲成本高。
• 配置不足：请求被丢弃，延迟飙升，用户体验变差。
• 预算僵化：支出无法随真实使用模式灵活变化。

为什么 serverless 不是银弹

扩缩容问题看起来并不陌生，serverless 计算在多年前就解决了类似问题。 像 AWS Lambda 这样的平台让按需扩展变得容易，但 serverless 并不适合 AI 工作负载。原因如下：

• 不支持 GPU：大多数 serverless 平台都不支持 GPU。这不仅仅是技术疏漏， 其背后还有架构与实践层面的原因。
• GPU 难以被轻松切分：GPU 性能强大且并行度高，但在同时处理跨不同模型的 大量推理任务时，它们不像 CPU 那样灵活。
• 空闲 GPU 成本高：GPU 就像计算世界里的高性能跑车，在特定任务上表现出色， 但维护成本也高，尤其是在无法持续利用时。

冷启动问题

推理工作负载需要能够快速扩缩容、控制成本并保持高性能的基础设施。 而扩缩容中的一个基础性挑战就是冷启动。

在以容器方式部署 LLM 的场景中，如果某个 Kubernetes 节点此前从未运行过某个 部署，就会发生冷启动。结果是该节点本地没有缓存容器镜像， 所有镜像层都必须从头拉取并初始化。

这个问题会出现在三个不同阶段：

1. 云资源配置（cloud provisioning）：这一步是云提供商分配新实例并将其 加入 Kubernetes 集群所需的时间。具体耗时取决于实例类型和可用性， 可能从 30 秒到几分钟不等；对于 NVIDIA A100 和 H100 这类高需求 GPU， 甚至可能需要数小时。

2. 容器镜像拉取：由于包含大量依赖和自定义库，LLM 镜像比典型的 Python 作业镜像大得多，也复杂得多。尽管云提供商宣称带宽可达数 Gbps， 实际镜像下载速度通常慢得多。因此，拉取镜像往往需要三到五分钟。

3. 模型加载。加载模型所需的时间高度依赖模型大小。由于 LLM 拥有数十亿参数，这一阶段往往会引入明显延迟。关键瓶颈包括：

   • 从模型仓库下载缓慢：像 Hugging Face 这样的平台并未针对高吞吐、 多分片下载进行优化，因此获取大型模型文件会很耗时。
   • 串行数据流：模型文件会经过多次中转： remote storage → local disk → memory → GPU。 这些步骤之间几乎没有并行化，甚至完全没有。每一步都会增加延迟， 对于难以缓存或流式传输的大文件尤其如此。
   • 缺乏按需流式加载：在推理开始前，模型文件必须完整下载并写入磁盘。 这会引入额外 I/O 操作并延长启动时间。

冷启动问题的每个阶段都需要有针对性的策略来尽量减少延迟。

扩缩容指标

为 LLM 推理扩展基础设施，不能只靠对系统负载做被动响应。 要实现响应迅速、高效且具成本效益的扩缩容，选对指标至关重要。

• CPU utilization。它简单且阈值清晰，但对基于 Python 的工作负载而言， 它并不能反映真实负载。Global Interpreter Lock（GIL）会限制 CPU 并行性， 尤其是在多核机器上，因此这个指标会误导扩缩容决策。
• GPU utilization。理论上它更相关，但在实践中并不准确。像 nvml 这样的工具只要在采样窗口内检测到任意 kernel 运行过一次，即便非常短暂， 就会把 GPU 记录为“utilized”。这并未考虑 batching 或真实吞吐量， 因而会导致过早扩容，或让人对容量产生虚假的信心。
• QPS (queries per second)。它在传统 Web 服务中很常见， 但对 LLM 推理帮助较小。生成式请求在规模和计算成本上差异很大， 取决于输入长度和生成 token 数量。因此，QPS 缺乏一致性， 也难以作为自动扩缩容参数进行调优。
• Concurrency。该指标表示当前活跃请求数，无论这些请求是在排队还是正在处理， 因而是反映系统负载的理想度量。Concurrency 可以根据 batch size 轻松配置， 并且与真实系统需求直接相关，因此能支持精确扩缩容。不过，要让 concurrency 真正发挥作用，你需要服务框架提供支持，将 concurrency 自动埋点为指标， 并把它作为部署平台的扩缩容信号。