vLLM + LWS：Kubernetes 上的多机多卡推理方案

vLLM + LWS：Kubernetes 上的多机多卡推理方案

随着 LLM 推理的工程实践不断深入，现有推理框架在部署能力方面的不足日益显现：例如难以跨节点统一管理多个 Pod 的生命周期、资源调度粒度过粗、缺乏分布式拓扑感知等问题。针对这些挑战，Kubernetes 推出了一种新的控制器原语 —— LeaderWorkerSet（简称 LWS），用于支持“分布式启动”“资源组调度”“拓扑感知”“组级原子恢复”等推理服务中的关键能力，成为包括 vLLM、TensorRT-LLM 在内的新一代大模型推理系统的重要运行支撑。

什么是 LWS？

LeaderWorkerSet（LWS）是 Kubernetes 新引入的一个 CRD（CustomResourceDefinition，自定义资源类型），其设计目标是 支持分布式 AI 作业的原生部署与管理，在部署结构上强调以下特点：

• • 分布式角色结构：LWS 将一组逻辑相关的 Pod 分为一个 Leader Pod 和多个 Worker Pod。Leader 负责初始化任务、构建主控制流，Worker 负责协同工作。
• • 统一生命周期管理：LWS 保证一组 Pod 的创建、销毁、状态检查以“组”为单位统一管理，解决了 Deployment、StatefulSet 等原生控制器在处理多角色任务时的能力不足。
• • 拓扑感知能力：通过对 Node 拓扑结构的感知（如 GPU、NUMA、TPU 拓扑等），LWS 能为推理场景中的“低延迟、强绑定”资源调度提供基础。
• • 状态同步能力：Leader 可通过注解等机制将服务发现、端口号、共享参数等元信息同步给 Worker，降低集群服务编排的复杂性。

简言之，LWS 旨在提供一种 更符合 AI 原生工作负载特点的分布式控制器语义，填补现有原语在推理部署上的能力空白。

与传统控制器的对比

Kubernetes 中已有多种控制器原语，如 Deployment、StatefulSet、Job、ReplicaSet 等，它们在构建无状态服务或状态服务方面表现出色。然而，对于如 vLLM、TensorRT-LLM 这类 异构资源强绑定 + 启动顺序依赖 + 多节点资源协同 的工作负载，传统原语存在如下不足：

相比之下，LeaderWorkerSet 是首个支持 Pod 间主从角色语义的控制器，具有以下差异化能力：

1. 1. 生命周期一致性：Leader 与 Worker 被绑定为一个逻辑部署单元，状态同步、重建过程均由控制器原子管理。
2. 2. 拓扑表达能力：Worker 可感知 Leader 所在节点信息，实现“同 NUMA”、“同 switch”等低延迟协同。
3. 3. 分布式配置能力：通过注解或 Downward API 等方式传递 Leader 地址、端口、分布式参数，简化调度逻辑。

LWS 的核心优势

1. 统一的生命周期管理

LWS 将 Super Pod 作为原子单元进行扩缩容和更新，确保组内状态一致性。例如：

• • 扩缩容时以组为单位增减资源池。
• • 滚动更新采用两阶段机制（预热 + 流量切换）。
• • 故障时优先局部恢复，必要时整组重建。

2. 拓扑感知的调度

通过 Kubernetes 原生的 Pod Topology Spread Constraints 和厂商扩展实现：

# NVIDIA DGX 系统
annotations:
nvidia.com/gpu.topology:"single-node-socket"
# Google TPU 集群  
annotations:
cloud.google.com/gke-tpu-topology:"4x4x4"

支持 NVLink 域内调度、TPU 切片绑定等高级场景，降低跨节点通信延迟。

3. 弹性伸缩与资源优化

与 HPA 深度集成，支持基于多维指标（请求队列、GPU 利用率）的弹性伸缩。资源分配通过 limits/requests 精细化控制，结合 NVIDIA MIG 技术可将单 GPU 划分为多个实例，提升利用率。

4. 安全与可观测性

• • 凭证管理：通过 Secrets 存储敏感信息，避免明文暴露。
• • 网络隔离：使用 NetworkPolicy 限制 Worker 仅允许与 Leader 通信。
• • 监控体系：采集 GPU 利用率、KV Cache 使用率等关键指标。

vLLM 场景下的能力支撑分析

vLLM 是一个专为大语言模型推理优化的高性能引擎，在实际部署中，它往往要求：

• • 横跨多个节点使用 GPU/TPU；
• • Worker 需通过 gRPC 接入 Leader 完成分布式 KV Cache 管理；
• • 推理参数（如 max num tokens）需由 Leader 向 Worker 广播；
• • 启动与恢复需具备原子性，避免部分 Worker 卡死或重连失败。

这些需求中，LWS 提供的组级调度与启动顺序控制能力、拓扑感知能力、配置动态传递能力，恰好能够完整覆盖，如下表所示：

vLLM 与 LWS 的实战部署

配置解析

以下是使用 LeaderWorkerSet（LWS）在 Kubernetes 上部署 vLLM 的配置示例：

apiVersion:leaderworkerset.x-k8s.io/v1
kind:LeaderWorkerSet
metadata:
name:vllm
spec:
replicas:2
leaderWorkerTemplate:
size:2
restartPolicy:RecreateGroupOnPodRestart
leaderTemplate:
metadata:
labels:
role:leader
spec:
containers:
-name:vllm-leader
image:docker.io/vllm/vllm-openai:latest
env:
-name:HUGGING_FACE_HUB_TOKEN
value:<your-hf-token>
command:
-sh
--c
-"bash /vllm-workspace/examples/online_serving/multi-node-serving.sh leader --ray_cluster_size=$(LWS_GROUP_SIZE); 
                 python3 -m vllm.entrypoints.openai.api_server --port 8080 --model meta-llama/Meta-Llama-3.1-405B-Instruct --tensor-parallel-size 8 --pipeline_parallel_size 2"
resources:
limits:
nvidia.com/gpu:"8"
memory:1124Gi
ephemeral-storage:800Gi
requests:
ephemeral-storage:800Gi
cpu:125
ports:
-containerPort:8080
readinessProbe:
tcpSocket:
port:8080
initialDelaySeconds:15
periodSeconds:10
volumeMounts:
-mountPath:/dev/shm
name:dshm
volumes:
-name:dshm
emptyDir:
medium:Memory
sizeLimit:15Gi
workerTemplate:
spec:
containers:
-name:vllm-worker
image:docker.io/vllm/vllm-openai:latest
command:
-sh
--c
-"bash /vllm-workspace/examples/online_serving/multi-node-serving.sh worker --ray_address=$(LWS_LEADER_ADDRESS)"
resources:
limits:
nvidia.com/gpu:"8"
memory:1124Gi
ephemeral-storage:800Gi
requests:
ephemeral-storage:800Gi
cpu:125
env:
-name:HUGGING_FACE_HUB_TOKEN
value:<your-hf-token>
volumeMounts:
-mountPath:/dev/shm
name:dshm
volumes:
-name:dshm
emptyDir:
medium:Memory
sizeLimit:15Gi
---
apiVersion:v1
kind:Service
metadata:
name:vllm-leader
spec:
ports:
-name:http
port:8080
protocol:TCP
targetPort:8080
selector:
leaderworkerset.sigs.k8s.io/name:vllm
role:leader
type:ClusterIP

详细配置说明请参见 vLLM 官方文档。

关键配置说明：

• • 动态组规模传递：通过注解机制，$(LWS_GROUP_SIZE) 动态注入组内 Pod 数量，确保资源分配的灵活性。
• • 服务发现机制：Worker Pod 通过注解 leaderworkerset.x-k8s.io/leader-address 自动获取 Leader 的地址，实现高效的服务发现。

性能调优与部署实践

vLLM 对推理性能高度敏感，部署时通常采用多机多卡结构（GPU/TPU），以实现模型并行和吞吐优化。以下是某企业在生产环境中的部署经验总结：

• • 模型规模：使用 Mixtral 模型（12.9B），量化后模型大小约 48GB。
• • 部署结构：1 个 Leader + 3 个 Worker，每个 Worker 节点分配 2 块 GPU，采用张量并行机制。
• • 核心参数调优示例：

  python3 -m vllm.entrypoints.openai.api_server \
    --model /models/mixtral \
    --dtype auto \
    --tensor-parallel-size 4 \
    --max-model-len 8192 \
    --gpu-memory-utilization 0.9 \
    --quantization awq \
    --enforce-eager \
    --max-num-batched-tokens 8192 \
    --max-num-seqs 256 \
    --disable-log-stats \
    --enable-prefetch

• • 调优要点说明：
• • --tensor-parallel-size：结合多卡部署设定张量并行维度。
• • --gpu-memory-utilization：控制每张 GPU 的显存使用上限，避免 OOM。
• • --quantization：使用 awq 量化以减小模型加载体积。
• • --max-num-batched-tokens 与 --max-num-seqs：控制批处理规模，提升吞吐性能。
• • --enable-prefetch 与 --enforce-eager：优化执行计划以降低延迟。

该配置可在保持高吞吐的同时，兼顾大模型的响应延迟需求。

未来趋势与能力展望

LWS 仍处于 Alpha 阶段，但其所提供的分布式调度原语被越来越多模型推理系统采纳。在未来，以下方向可能成为演进重点：

• • 更强的异构资源调度表达能力：引入 GPU 型号、TPU topology-aware 等特征调度；
• • 与 Service Mesh 结合：Worker 动态加入统一负载平衡服务；
• • 与 HPA（水平自动扩展）协同：根据负载自动调整 Worker 数量。

此外，LWS 的控制器机制也可能被扩展用于训练作业、在线增量学习等更广泛的场景中，成为 AI native workload 的基础控制器抽象。

扩展阅读

• • LWS 官方文档
• • Kubernetes 拓扑调度指南
• • vLLM 多节点部署实践

通过整合 Kubernetes 原生能力与分布式推理优化，LWS 正在重新定义云原生 AI 基础设施的构建范式。其设计理念与实现细节为大规模模型部署提供了重要参考，值得开发者深入探索。