海豚平台是货拉拉自研的一站式云原生AI开发平台，覆盖了从数据处理、镜像构建到模型开发、训练、部署及在线推理的全流程。经过近两年的建设，海豚平台已成为货拉拉AI开发的核心基础平台，显著提升了AI开发人效和算力资源利用率，有力推动了公司AI技术与业务的发展。然而随着大模型技术的快速发展，海豚平台在部署大模型时迎来新的挑战。
海豚平台目前使用K8S的Deployment来部署模型服务，一个Pod部署一个完整的模型实例并运行在一台GPU物理机上。但在部署大模型时，由于物理节点算力资源有限，单台物理机无法独立完成大模型部署，需要引入大模型分布式框架，使用流水线并行（PP）和张量并行（TP）等策略，利用多个Pod将大模型分布式部署在多台物理节点上。然而，基于Deployment托管Pod的模式在实现此方案时存在以下问题：
1.大模型分布式部署框架中，不同节点的启动命令不同，而Deployment托管的Pod启动命令相同，无法满足需求。
2.大模型分布式部署框架要求主节点IP固定，以便其他节点连接并构建节点组。然而，Deployment部署的PodIP地址不固定，模型服务重启后，整个分布式框架无法正常运行。
3.多个Pod构成的Pod组需要整体扩容、滚动更新和故障恢复能力，而Deployment不支持该能力。
对于以上问题，仅靠现有K8S的Deployment能力无法满足大模型分布式部署要求，我们必须寻求其他解决方案。下面将介绍海豚平台如何基于K8S实现大模型多机分布式部署方案和背后的原理。
我们经过调研发现，LeaderWorkerSet(LWS) 可以解决AI/ML多机分布式部署问题。海豚平台通过引入LWS，配合大模型分布式推理框架（如 Vllm、SGLang、LmDeploy 等），将大模型部署在多台物理机上，从而实现了海豚平台基于K8S的大模型分布式部署能力。
LWS是K8S兴趣小组基于K8S的HeadlessService和StatefulSet实现的CRD工作负载，它专注于解决AI/ML多机分布式部署的业务场景。
PodGroup作为一个整体单元：多个Pod组成一个PodGroup，Group中的每个Pod都有一个从0到n-1的唯一索引，且具有相同的生命周期，所有的Pod都有一个全局唯一的网络地址标识。
PodGroup支持多模板:一个PodGroup是由单个LeaderPod和多个WorkerPod组成的组，允许LeaderPod和WorkerPod指定不同的模板（启动命令、资源等）。
PodGroup扩缩容:支持创建上述Group的多个副本，实现快速的扩缩容能力。
PodGroup滚动更新:PodGroup作为一个整体单元进行升级（即Group内的Pod一起更新）。
PodGroup故障恢复:如果Group中的一个Pod运行失败，则会重新创建组中的所有 Pod。
在一个PodGroup中，LeaderPod和WorkerPod分别由对应的LeaderStatefulSet和WorkerStatefulSet创建，并通过label将它们关联起来，LeaderStatefulSet和WorkerStatefulSet可以分别配置不同的template，如启动命令、运行镜像、资源配置等，从而成功实现了在一个PodGroup内，LeaderPod和WorkerPod多模版的能力。
在大模型分布式部署时，LeaderPod必须要有固定的网络标识，才能让WorkerPod进行通信，LWS采用StatefulSet和HeadlessService结合使用，实现Pod节点组内的Pod网络标识固定的能力。
StatefulSet:是Kubernetes用于管理有状态应用的工作负载，它为有状态应用提供了有序的部署、扩展和管理能力，与Deployment和DaemonSet等其他控制器不同，StatefulSet更适合需要稳定网络标识和持久化存储的有状态应用，比如数据库（如 MySQL、MongoDB 等）、分布式缓存（如 Redis 集群）等。 StatefulSet为每个Pod生成稳定的Pod名称，例如，如果你创建了一个名为haitun的StatefulSet，它会生成名为haitun-0、haitun-1的Pod。这些Pod的名称在整个生命周期中保持不变，即使Pod被重新调度或重启，名称也不会改变。
HeadlessService:是一种特殊的Service，不会分配一个集群内部的虚拟IP地址（Cluster IP），不支持负载均衡、服务发现，主要作用是会为对应的Pod增加一条DNS记录，用于固定Pod的网络地址标识，如下：
{pod名称}.{serviceName}.namespace.svc.cluster.local通过StatefulSet实现Pod名称的固定后，HeadlessService将会为每个Pod生成一条固定的DNS记录，从而实现LeaderPod网络标识固定的能力。
LWS的扩缩容机制基于LeaderStatefulSet和WorkerStatefulSet的协同操作实现。当用户修改LWS的spec.replicas字段时，LWS Controller感知到这一变更，随即触发扩缩容流程：
1.对LeaderStatefulSet进行扩缩容操作，K8S会按照序号递增的顺序创建新的LeaderPod，或者删除序号最大的LeaderPod。
2.对于每个新创建的LeaderPod，LWS Controller会自动创建一个与之对应的WorkerStatefulSet，从而确保每个LeaderPod都有其专属的WorkerPod。当某个LeaderPod被删除时，其对应的WorkerStatefulSet也会被同步删除，从而完成PodGroup中WorkerPod的创建和删除操作。
在整个扩缩容流程中，LWS确保整个PodGroup的扩缩容操作的原子性。
VERSION=v0.6.1kubectlapply--server-side-fhttps://github.com/kubernetes-sigs/lws/releases/download/$VERSION/manifests.yaml
通过LWS部署如下的示例:
apiVersion:leaderworkerset.x-k8s.io/v1kind
eaderWorkerSetmetadata:name:sglangspec:replicas:2leaderWorkerTemplate:size:2restartPolicy:RecreateGroupOnPodRestartleaderTemplate:metadata:labels:role:leaderspec:containers:-name:sglang-leaderimage:lmsysorg/sglang:latestenv:-name:HUGGING_FACE_HUB_TOKENvalue:<your-hf-token>command:-python3--m-sglang.launch_server---model-path-meta-llama/Meta-Llama-3.1-8B-Instruct---tp-"2"#SizeofTensorParallelism---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:40000workerTemplate:spec:containers:-name:sglang-workerimage:lmsysorg/sglang:latestenv:-name:HUGGING_FACE_HUB_TOKENvalue:<your-hf-token>command:-python3--m-sglang.launch_server---model-path-meta-llama/Meta-Llama-3.1-8B-Instruct---tp-"2"#SizeofTensorParallelism---dist-init-addr-$(LWS_LEADER_ADDRESS):20000---nnodes-$(LWS_GROUP_SIZE)---node-rank-$(LWS_WORKER_INDEX)---trust-remote-coderesources:limits:nvidia.com/gpu:"1"
curlhttp://localhost:40000/v1/completions\-H"Content-Type:application/json"\-d'{"model":"meta-llama/Meta-Llama-3.1-8B-Instruct","role":"user","prompt":"Whatisthemeaningoflife?"}'通过更新LWS的spec.replicas字段即可实现对应的扩缩容机制。
apiVersion:leaderworkerset.x-k8s.io/v1kindeaderWorkerSetmetadata:name:sglangspec:replicas:2
同Deployment一样，在模型服务更新时，LWS通过配置maxUnavailable和maxSurge字段实现滚动的更新。
spec:rolloutStrategy: type: RollingUpdate rollingUpdateConfiguration: maxUnavailable:2 maxSurge:2replicas:4
maxSurge：表示在更新期间可以部署多少个额外的副本，也就是可以额外创建多少个新的Pod。
maxUnavailable：表示在更新期间允许不可用的副本数，也就是更新期间，旧的Pod可以先退出的个数。
如上yaml文件所示，服务滚动更新的过程如下：
LeaderPod作为整个PodGroup的探针检测点，支持启动探针、存活探针、就绪探针。LeaderPod探针检测失败时，整个PodGroup组将重启。
readinessProbe:tcpSocket:port:40000initialDelaySeconds:15periodSeconds:
同Deployment发布状态检测一样，LWS也提供了类似的判定方法：
期望副本数(spec.replicas)=已经ready的副本数(readyReplicas)=实时副本数(status.replicas)=已更新副本数(updatedReplicas)
目前海豚平台已经支持了AI开发流程的全部核心能力，大模型应用方面也已支持大模型的训练和部署推理，接下来我们将从以下几个方面进一步提升平台能力：
完善大模型应用市场:统一管理海豚平台大模型，提供大模型的快速微调训练、部署、体验及API接入的全方位支持。
大模型分布式训练：引入业界先进的大模型微调训练框架，结合高速网络传输（RDMA）与高性能文件存储技术，完善大模型分布式微调训练体系。
算力资源利用率提升：深度优化算力资源分配与调度机制，聚焦大模型算力资源的高效分配与利用，提升整体算力资源的使用效率。
平台稳定性建设：构建多Region多集群架构，实现算法服务的多泳道（多活）能力，提升平台的稳定性。
