[论文] 在高性能计算基础设施上实现自动化动态 AI 推理伸缩：整合 Kubernetes、Slurm 和 vLLM
发布: (2025年11月26日 GMT+8 22:06)
7 min read
原文: arXiv
Source: arXiv - 2511.21413v1
概览
本文提出了一个原型，使大语言模型（LLM）推理能够在传统的高性能计算（HPC）集群上运行，方法是将三种流行的编排工具结合在一起：vLLM（高速 LLM 服务引擎）、Slurm（超级计算机的事实批处理调度器）和 Kubernetes（开发者熟悉的容器编排平台）。作者展示了该混合栈能够处理数百到一千个并发用户请求，仅增加约 500 ms 的延迟，表明现有的 HPC 资源可以重新用于低延迟、面向用户的 AI 服务。
关键贡献
- 混合编排层 – 将 Slurm 与 Kubernetes 的新颖集成，使 HPC 节点能够像云原生资源池一样被管理，同时仍遵守批处理调度器的分配策略。
- 以 vLLM 为中心的服务 – 将高吞吐量的 vLLM 推理引擎嵌入到 HPC 容器中，实现跨多个节点的张量并行和模型分片。
- 动态伸缩逻辑 – 自动化控制器根据实时请求量启动或关闭 vLLM pod，实现 100、500 和 1 000 并发查询的近线性伸缩。
- 端到端基准测试 – 在 RAMSES 超算上进行的定量评估，测量延迟、吞吐量和开销，显示相较于纯云部署仅多约 0.5 s 的延迟。
- 开源参考实现 – 作者发布了脚本和 Helm chart，帮助其他机构在自己的 Slurm 支持的集群上复现该设置。
方法论
- 环境搭建 – RAMSES HPC 集群（GPU 节点）使用 Slurm 进行资源分配。轻量级的 Kubernetes 控制平面部署在头节点上，每个计算节点运行一个 Kubelet，注册为 Kubernetes 工作节点。
- 容器化 – 将 vLLM 服务器、其依赖以及 LLM 模型文件打包成 Docker 镜像。该镜像存放在集群可访问的私有仓库中。
- 调度桥接 – 自定义的 Slurm‑to‑Kubernetes 桥接程序监视 Slurm 作业队列。当用户通过 REST 接口提交推理请求时，桥接程序创建一个 Slurm 作业以预留所需 GPU，然后启动对应的运行 vLLM 的 Kubernetes pod。
- 动态自动伸缩 – 控制器监控请求延迟和队列深度。如果队列超过阈值，它会请求额外的 Slurm 资源分配，进而启动更多 vLLM pod。当需求下降时，pod 被优雅地终止，GPU 资源释放回 Slurm。
- 基准测试 – 作者生成 100、500 和 1 000 个并发 HTTP 请求的合成工作负载，针对一个 7B 参数的 LLM 进行测试。记录端到端延迟（客户端 → API 网关 → vLLM → GPU），并与在不使用 Slurm 的专用 Kubernetes 集群上运行 vLLM 的基线进行比较。
结果与发现
| 并发请求数 | 平均端到端延迟 | 相较纯 K8s 的额外开销 |
|---|---|---|
| 100 | ~1.2 s | +0.45 s |
| 500 | ~1.4 s | +0.48 s |
| 1 000 | ~1.6 s | +0.52 s |
- 可伸缩性 – 延迟呈亚线性增长；系统能够在不饱和网络或 GPU 内存的情况下支撑千级并发查询。
- 开销 – 额外约 500 ms 主要来源于 Slurm‑Kubernetes 的交接和容器启动；一旦 pod 处于热状态，请求成本与原生云部署相当。
- 资源利用率 – 在峰值负载期间，混合调度器实现了 >85 % 的 GPU 利用率，远高于 HPC 集群常用的静态分配策略。
实际意义
- 利用现有 HPC 投资 – 大学和研究实验室可以在不购买专用推理集群的情况下，将 GPU 丰富的超级计算机暴露为 AI 驱动的 Web 服务。
- 成本效益的 AI SaaS – 通过复用批处理调度资源，组织能够向学生、研究者或内部工具提供低延迟的 LLM API，仅为实际使用付费。
- 开发者友好的运维 – Kubernetes 的外观层意味着开发者可以使用熟悉的
kubectl、Helm chart 和 CI/CD 流程，而 HPC 管理员则通过 Slurm 策略（公平共享、配额、计费）保持控制权。 - 混合云边缘场景 – 当本地 HPC 队列已满时，该模式可以将 AI 工作负载弹性地转向云端，实现本地/云端推理的无缝衔接。
- 标准化路径 – 桥接代码和 Helm chart 有望成为其他 HPC 中心暴露 AI 服务的参考实现，加速 “HPC‑as‑a‑service” 在 AI 领域的落地。
局限性与未来工作
- 模型规模边界 – 本次评估使用的是 7B 参数模型；将规模扩大到 70B 以上的模型可能会受到当前 GPU 节点内存的限制，需要更复杂的张量并行策略。
- 冷启动惩罚 – ~500 ms 的开销主要来自 pod 启动和模型加载；通过缓存热 pod 或使用 “热池” 可以进一步降低此延迟。
- 安全性与多租户隔离 – 当前原型假设内部网络可信；若要面向多租户公共 API，需要更强的隔离措施（如 pod 安全策略、网络沙箱）。
- 调度器复杂度 – 同时维护 Slurm 与 Kubernetes 两套调度系统会增加运维负担；未来工作可探索更紧密的集成或统一的 API 层。
- 更广泛的基准 – 真实工作负载（如检索增强生成、多模态推理）以及异构硬件（TPU、更新的 GPU）仍需进一步测试。