大模型技术的发展速度之快，已成为业界有目共睹的事实。然而，技术落地的“最后一公里”往往是最具挑战性的环节。货拉拉自研的云原生AI平台“海豚”，在近两年的快速发展中，已有效贯通了数据处理、模型训练、部署推理等多个环节，显著提升了AI开发的整体效率。然而，大模型的到来带来了新的变局——单台GPU物理机难以支撑其庞大的算力需求，必须依赖分布式部署方案。传统K8S Deployment组件在面对这种多机协同场景时，其架构局限性日益凸显，显得有些力不从心。

1. 前言

海豚平台全面覆盖了从数据处理、镜像构建，到模型开发、训练、部署及在线推理的完整工作流。经过近两年的持续建设，该平台已成为货拉拉AI开发的核心基础设施，显著提高了团队工作效率与算力资源利用率。然而，随着大模型技术的快速迭代，部署环节暴露出新的技术痛点，亟需更优的解决方案。

2. 海豚平台大模型部署的挑战

目前，海豚平台主要采用K8S的Deployment组件来部署模型服务，其模式为一个Pod部署一个完整模型实例，并运行于单台GPU物理机上。但在大模型面前，物理节点的算力瓶颈日益凸显：单台机器难以承载完整的模型计算。因此，引入分布式推理框架（如流水线并行PP与张量并行TP）成为必然，它要求将一个大模型合理拆分至多台物理机。然而，传统的Deployment组件在应对这种分布式场景时，面临三大难题：

• 启动命令差异化：在分布式框架中，不同节点的启动参数各不相同，但Deployment管理的Pod启动命令完全一致，无法满足多节点异构配置的需求。
• 主节点IP不固定：分布式推理框架通常要求主节点拥有固定IP，以便其他节点组建通信集群。而Deployment的Pod在重启后IP会发生变化，直接导致框架连接失败或崩溃。
• Pod组整体管控缺失：在多机部署中，多个Pod需作为一个完整的逻辑单元进行统一扩缩容、滚动更新及故障恢复，但Deployment缺乏对这种“团队协作”模式的原生支持。

显然，单纯依靠Deployment已无法解决大模型分布式部署的核心问题。接下来，我们将探讨海豚平台如何突破这一瓶颈。

3. 海豚平台的解决方案

经过深入的技术调研，团队最终选定了合适的方案——LeaderWorkerSet（LWS）。海豚平台通过引入LWS工作负载，并配合Vllm、SGLang、LmDeploy等先进的分布式推理框架，成功将大模型部署至多台物理机，实现了基于K8S的分布式部署能力。

3.1 LWS是什么

LWS是Kubernetes社区基于Headless Service与StatefulSet实现的一个CRD（自定义资源定义）工作负载，专为解决AI/ML领域的多机分布式部署场景而设计。简而言之，它正是为大模型这种需要“组团协作”的运行模式量身打造的通用方案。

3.2 LWS的主要特性

• PodGroup作为整体单元：多个Pod被组成一个PodGroup，每个Pod都拥有从0到n-1的唯一索引，生命周期完全一致，并具备全局唯一的网络地址标识。
• PodGroup支持多模板配置：在同一个PodGroup中，LeaderPod与WorkerPod可分别配置不同的模板（如启动命令、资源需求等），完美解决了各节点启动命令不一致的问题。
• PodGroup弹性扩缩容：支持创建多个Group副本，从而实现快速、灵活的扩缩容操作。
• PodGroup滚动更新：整个PodGroup作为整体进行升级更新，所有Pod协同完成，避免了分批更新可能带来的一致性问题。
• PodGroup故障恢复：组内任意Pod出现异常，整个Group都会被重建，以维护状态的一致性与完整性。

下面我们将简要介绍这些特性背后的核心实现原理。

3.3 LWS的实现原理

3.3.1 一个副本内多个Pod支持多模板

在PodGroup中，LeaderPod与WorkerPod分别由LeaderStatefulSet和WorkerStatefulSet创建，并通过label进行关联。这两个StatefulSet可配置不同的template，包括启动命令、镜像版本以及资源分配，从而灵活实现了多模板能力。

3.3.2 LeaderPod网络标识固定

在大模型分布式部署时，LeaderPod必须具备一个固定且可解析的网络地址，以便WorkerPod顺利连接。LWS的解决方案是采用 StatefulSet + HeadlessService 的组合策略。

• StatefulSet：为每个Pod生成一个稳定不变的名称（如haitun-0、haitun-1）。即便Pod被重启或调度至其他节点，该名称也不会发生变化。
• HeadlessService：不分配虚拟IP地址，而是为每个Pod创建一条独立的DNS记录，格式为 {pod名称}.{serviceName}.namespace.svc.cluster.local。

通过这一组合，StatefulSet固定了Pod名称，HeadlessService固定了DNS解析路径，从而确保了LeaderPod网络标识的稳定可靠。

3.3.3 PodGroup扩缩容

扩缩容机制基于LeaderStatefulSet与WorkerStatefulSet的协同操作实现。当修改LWS的 spec.replicas 参数时，LWS Controller会触发如下流程：

1. 首先对LeaderStatefulSet进行扩缩容，K8S按序号递增创建或删除LeaderPod。
2. 每个新创建的LeaderPod，会自动生成一个对应的WorkerStatefulSet；而LeaderPod被删除时，其对应的WorkerStatefulSet也会同步注销。

整个流程确保了PodGroup扩缩容的原子性与一致性。

4. 海豚平台LWS内部实践

4.1 安装LWS插件

VERSION=v0.6.1
kubectl apply --server-side -f https://github.com/kubernetes-sigs/lws/releases/download/$VERSION/manifests.yaml

4.2 SGLang部署示例

下面是一个使用LWS部署SGLang服务的YAML示例，它展示了如何分别配置LeaderPod与WorkerPod的不同模板属性：

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: sglang
spec:
  replicas: 2
  leaderWorkerTemplate:
    size: 2
    restartPolicy: RecreateGroupOnPodRestart
    leaderTemplate:
      metadata:
        labels:
          role: leader
      spec:
        containers:
          - name: sglang-leader
            image: lmsysorg/sglang:latest
            env:
              - name: HUGGING_FACE_HUB_TOKEN
                value: 
            command:
              - python3
              - -m
              - sglang.launch_server
              - --model-path
              - meta-llama/Meta-Llama-3.1-8B-Instruct
              - --tp
              - "2"
              - --dist-init-addr
              - $(LWS_LEADER_ADDRESS):20000
              - --nnodes
              - $(LWS_GROUP_SIZE)
              - --node-rank
              - $(LWS_WORKER_INDEX)
              - --trust-remote-code
              - --host
              - "0.0.0.0"
              - --port
              - "40000"
            resources:
              limits:
                nvidia.com/gpu: "1"
            ports:
              - containerPort: 40000
    workerTemplate:
      spec:
        containers:
          - name: sglang-worker
            image: lmsysorg/sglang:latest
            env:
            - name: HUGGING_FACE_HUB_TOKEN
              value: 
            command:
              - python3
              - -m
              - sglang.launch_server
              - --model-path
              - meta-llama/Meta-Llama-3.1-8B-Instruct
              - --tp
              - "2"
              - --dist-init-addr
              - $(LWS_LEADER_ADDRESS):20000
              - --nnodes
              - $(LWS_GROUP_SIZE)
              - --node-rank
              - $(LWS_WORKER_INDEX)
              - --trust-remote-code
            resources:
              limits:
                nvidia.com/gpu: "1"

4.3 推理测试

部署完成后，可直接使用curl命令对接口进行测试验证：

curl http://localhost:40000/v1/completions -H "Content-Type: application/json" -d '{
    "model": "meta-llama/Meta-Llama-3.1-8B-Instruct",
    "role": "user",
    "prompt": "What is the meaning of life?"
}'

4.4 扩缩容

只需修改LWS配置中的 spec.replicas 字段即可触发弹性扩缩容操作，例如：

apiVersion: leaderworkerset.x-k8s.io/v1
kind: LeaderWorkerSet
metadata:
  name: sglang
spec:
  replicas: 2

4.5 滚动更新

与Deployment类似，LWS通过配置 maxUna vailable 和 maxSurge 参数来实现滚动更新策略：

spec:
  rolloutStrategy:
    type: RollingUpdate
    rollingUpdateConfiguration:
      maxUna vailable: 2
      maxSurge: 2
  replicas: 4

• maxSurge：在更新期间允许额外创建的Pod数量上限。
• maxUna vailable：在更新期间允许处于不可用状态的Pod数量上限。

更新过程会先创建新的Pod组（不超过maxSurge的限制），待新组就绪后，再逐步删除旧的Pod组（确保不可用Pod数不超过maxUna vailable），两者交替进行，直至全部更新完成。

4.6 故障恢复

LeaderPod作为整个PodGroup的健康检查探针检测点，支持配置启动探针、存活探针与就绪探针。如果LeaderPod的探针检测失败，整个PodGroup将被触发重启。例如，配置一个就绪探针的示例如下：

readinessProbe:
  tcpSocket:
    port: 40000
  initialDelaySeconds: 15
  periodSeconds: 5

4.7 发布状态检测

LWS还提供了清晰的发布状态判定逻辑，其思路与Deployment保持一致：

期望副本数(spec.replicas) = 已经ready的副本数(readyReplicas) = 实时副本数(status.replicas) = 已更新副本数(updatedReplicas)

5. 海豚平台未来规划

目前，海豚平台已全面覆盖AI开发的全生命周期，并在大模型方面支持了训练、部署及推理等关键环节。接下来，平台计划从以下几个方向持续提升：

• 完善大模型应用市场：统一管理和运营平台上的各类大模型，提供从快速微调训练、部署上线、模型体验到API接入的一站式支持。
• 大模型分布式训练：引入业界先进的微调训练框架，结合高速网络传输（RDMA）与高性能文件存储，打造完善的分布式微调训练体系。
• 算力资源利用率提升：深度优化资源分配与调度策略，聚焦大模型算力的高效分配与动态管理，进一步提升整体使用效率。
• 平台稳定性建设：构建多Region、多集群架构，实现算法服务的多泳道（多活）能力，全面增强平台的服务韧性与可用性。