多机多卡大模型推理服务：方案对比与Kthena选型实践

背景与痛点

直接痛点：超大模型的张量并行

随着大型语言模型（LLM）参数量的持续增长，以GLM-5 744B为代表的超大规模模型，一个完整的模型权重需要占用数百GB甚至TB级别的显存。以华为昇腾910B3为例，单卡显存约为64GB，8卡节点合计约512GB，远不足以加载GLM-5 744B的完整权重（FP16精度下约需~1.5TB显存）。这意味着：单个节点无法独立承载此类超大模型的推理服务，必须依赖跨节点的多机多卡分布式部署。

多机多卡部署场景下的核心痛点

在Kubernetes体系内实现多机多卡推理部署，工程团队面临以下典型挑战：

资源调度层面

原子性调度缺失：标准Deployment/StatefulSet不支持Gang Scheduling（组调度），容易出现"半部署死锁"——部分节点的推理Pod已启动并占用显存，另一部分因资源不足而Pending，导致两侧均无法对外服务，造成资源浪费。
拓扑感知缺失：多机通信延迟远高于机内通信（RDMA跨交换机 vs NVLink/NVSwitch），若调度器无法感知网络拓扑，可能将强耦合的多个推理Pod分散到通信代价高的节点，严重影响推理吞吐和延迟。
异构资源不兼容：集群可能混合GPU与NPU节点，调度框架需要理解异构硬件的资源语义。

多节点协作层面

节点间启动顺序编排复杂：以vLLM + Ray为例，主节点（Leader）需要先启动Ray Cluster，工作节点（Worker）再通过Ray地址加入集群後才能启动推理服务。如果Pod无法自动感知Leader地址，需要手动维护大量脚本逻辑。
服务发现与DNS耦合：多节点推理服务需要Entry Pod的地址被Worker Pod稳定感知，原生Deployment无稳定主机名，StatefulSet的多角色管理能力非常有限。
故障恢复代价高：单节点重启会导致整个推理组失效（因为分布式推理状态是整体的），需要所有节点协调重建，原生Kubernetes的独立Pod恢复逻辑无法满足此需求。

流量路由层面

模型感知路由缺失：标准Service与Ingress只做L4/L7路由，不理解LLM请求的模型名称、LoRA Adapter、KV Cache状态等信息，无法做到智能的推理请求调度。
PD分离（Prefill-Decode Disaggregation）难以支撑：PD分离需要将Prefill请求路由到算力密集型节点、Decode请求路由到带宽密集型节点，或组成xPyD拓扑灵活组合，标准路由层完全无感知。

运维管理层面

滚动升级破坏性大：标准滚动升级无法以"推理组"为单位进行，容易打散一个正在运行的多节点推理服务。
LoRA动态加载复杂：业务通常需要在不停服的情况下热加载多个LoRA Adapter，原生框架无内置支持。
可观测性不足：标准Kubernetes指标与推理引擎指标（KV Cache占用率、TTFT、TPOT等）之间存在鸿沟。

三种技术方案对比

业界针对上述痛点提出了多种解决方案，当前较为主流的包括：LeaderWorkerSet（LWS）、RoleBasedGroup（RBG） 以及 Kthena。

LeaderWorkerSet（LWS）

LWS（kubernetes-sigs/lws）是Kubernetes SIG-Apps下的子项目，提供了一种以"Leader-Worker 组"为单位进行Pod复制的API，是目前最接近Kubernetes官方标准的多节点推理部署方案。

LeaderWorkerSet（LWS）

核心设计理念

将一个推理服务实例建模为一个Group，包含1个Leader Pod（接受请求、协调Ray Cluster等）和若干Worker Pod（参与分布式计算）。支持创建多个这样的Group（即多副本），每个Group作为一个整体进行滚动更新和拓扑调度。

LeaderWorkerSet
├── Replica 0 (Group)
│   ├── Leader Pod (index=0)
│   └── Worker Pod (index=1..N)
└── Replica 1 (Group)
    ├── Leader Pod (index=0)
    └── Worker Pod (index=1..N)

维度	说明
社区归属	`kubernetes-sigs`官方
`Gang Scheduling`	`Alpha`级别，需配合`Volcano`/`Coscheduling`插件
角色类型	仅支持`Leader`+`Worker`两种角色
`PD`分离支持	正在孵化`DisaggregatedSet`（`KEP-766`），尚未`GA`
路由能力	无内置路由层，需配合网关
`Volcano`集成	需要额外配置`PodGroup`
多调度器支持	支持`Volcano`/`Coscheduling`/`YuniKorn`

优点

社区背书强，kubernetes-sigs官方项目，版本稳定性有保障
API设计简洁，学习曲线低，与原生Kubernetes概念契合
与多种调度器兼容性好（Volcano、scheduler-plugins、YuniKorn等）
已经被vLLM、SGLang等主流推理框架官方文档引用为多节点部署参考方案

缺点

角色模型简单，仅支持Leader/Worker两类，无法原生表达PD分离中的Prefill/Decode多角色拓扑
无内置流量路由层，推理请求的智能调度需要额外引入网关或Inference Extension
Gang Scheduling尚处于Alpha阶段，API可能变更
PD分离的上层封装DisaggregatedSet仍在提案阶段（KEP-766），生产可用性有限
不具备自动扩缩容、LoRA热加载、模型生命周期管理等高层能力

RoleBasedGroup（RBG）

RBG（sgl-project/rbg）由SGLang项目团队维护，在LWS设计基础上进行了扩展，将推理服务建模为"基于角色的协作有机体"（Role-Based Organism），以支持更复杂的生产部署场景，尤其是PD分离架构。

RoleBasedGroup（RBG）

核心设计理念

以RoleBasedGroup（RBG）为顶层资源，管理一组具有明确角色（Role）和协作关系的Pod集合。每个Role（如gateway、prefill、decode）拥有独立的Spec、生命周期策略和调度约束，RBG确保跨角色的联动升级、故障恢复和扩缩容。

RoleBasedGroup
├── Role: gateway
├── Role: prefill  (entry + workers)
└── Role: decode   (entry + workers)

维度	说明
社区归属	`SGLang`社区维护，非官方K8s项目
`Gang Scheduling`	支持`Volcano`和`Coscheduling`双模式
角色类型	任意多角色，支持`Prefill/Decode/Gateway`等
`PD`分离支持	原生支持`PD`分离部署模式
路由能力	无内置路由层
`Volcano`集成	支持（可选）
依赖关系	底层依赖`LWS`作为工作负载原语

优点

多角色模型设计优秀，能够原生表达PD分离等复杂拓扑（xPyD等模式）
基于SCOPE设计哲学（Stable/Coordination/Orchestration/Performance/Extensible）
支持角色间的协调升级、联动故障恢复和启动顺序编排
拓扑自感知服务发现，消除对外部服务依赖
对SGLang推理框架的集成最为深入，样例丰富

缺点

项目由SGLang团队维护，社区相对较小，版本稳定性和长期支持存在风险
底层依赖LWS，版本兼容矩阵存在一定维护复杂度
无内置路由层和模型生命周期管理，缺乏完整的推理服务治理体系
与Volcano的集成深度不如Kthena，subGroupPolicy等高级功能未完全利用
不具备自动扩缩容、模型下载管理等运维自动化能力

Kthena

Kthena（volcano-sh/kthena）是由Volcano社区（华为）发起的企业级LLM推理平台，定位为一站式Kubernetes原生推理服务治理方案，覆盖从模型部署、流量路由到自动扩缩容的完整生命周期。

Kthena

核心设计理念

将LLM推理服务的控制平面（模型生命周期、策略管理）与数据平面（请求路由、负载均衡）分离，通过一套CRD体系对外提供声明式的推理服务管理接口，并深度集成Volcano调度器的高级特性（Gang Scheduling、拓扑感知、subGroupPolicy等）。

维度	说明
社区归属	`Volcano`社区（华为），与`Volcano`调度器同一生态
`Gang Scheduling`	深度集成`Volcano`，支持`subGroupPolicy`多维Gang调度
角色类型	任意多角色，支持`Entry+Worker`双模板
`PD`分离支持	原生支持，提供端到端的`xPyD`管理能力
路由能力	内置`Kthena Router`，支持模型感知、`KV Cache`感知等高级调度
`Volcano`集成	深度集成，`ModelServing`自动创建`PodGroup`
模型生命周期	完整支持（下载、部署、扩缩、滚动升级、`LoRA`热加载）
自动扩缩容	内置`AutoScalingPolicy`，支持异构实例优化

优点

方案完整度最高，覆盖推理服务的完整生命周期，真正的一站式平台
与Volcano调度器深度集成，充分利用Gang Scheduling、HyperNode网络拓扑感知等企业级调度能力
内置智能路由层（Kthena Router），支持KV Cache感知、LoRA亲和性、前缀缓存感知等推理特有的调度策略
ModelServing的ServingGroup + Role + Entry/Worker三层抽象，能精确描述xPyD等复杂PD分离场景
支持ModelBooster一键部署，极大降低使用门槛
内置Downloader和RuntimeAgent Sidecar，解决模型下载和引擎指标标准化问题

缺点

项目相对年轻（2025年孵化），社区规模较LWS小，版本迭代快，API可能变化
对Volcano调度器有强依赖，不适合使用其他调度器（如Kueue、默认调度器）的集群
架构复杂度较高，初次安装和学习曲线比LWS陡峭
国际社区影响力尚处于建立阶段，中文文档相对更丰富

方案选型对比总结

对比维度	LWS	RBG	Kthena
社区成熟度	⭐⭐⭐⭐⭐	⭐⭐⭐	⭐⭐⭐⭐
多角色支持	❌ 仅`Leader/Worker`	✅ 任意多角色	✅ 任意多角色
`Gang Scheduling`	⚠️ `Alpha`	✅	✅（深度集成`Volcano`）
网络拓扑感知	⚠️ 有限	✅	✅（`HyperNode`）
`PD`分离原生支持	⚠️ `KEP`阶段	✅	✅
内置路由层	❌	❌	✅
模型生命周期管理	❌	❌	✅
自动扩缩容	❌	⚠️ 有限	✅
`Volcano`深度集成	⚠️ 可选	⚠️ 可选	✅ 原生
方案完整性	基础工作负载	工作负载+协调	完整推理平台

为何选择 Kthena

结合公司当前的技术栈和业务诉求，我们选择Kthena作为多机多卡推理服务的部署方案，主要基于以下几点考量：

与 Volcano 生态完全契合

公司Kubernetes集群已全面采用Volcano作为调度器，且已在AI训练任务中积累了Gang Scheduling、队列管理等实践经验。Kthena由Volcano社区孵化，与Volcano调度器存在深度集成关系：ModelServing控制器会自动为每个ServingGroup创建PodGroup，并利用Volcano 1.14+新增的subGroupPolicy实现Role级别的细粒度Gang Scheduling（确保Prefill Pod和Decode Pod同时调度，防止资源死锁）。这意味着我们可以在不改变调度器的前提下，直接受益于Kthena的全部调度能力。

解决当前多机多卡的直接痛点

ModelServing的三层抽象（ServingGroup > Role > Entry/Worker Pod）完美契合GLM-5 744B双节点部署的需求：每个ServingGroup对应一个完整的推理实例，Role内的Entry Pod（Leader节点）与Worker Pod（Follower节点）通过环境变量ENTRY_ADDRESS自动完成服务发现，无需手动维护Ray集群地址配置。

面向未来的PD分离扩展能力

虽然当前阶段主要解决张量并行的多机多卡部署，但未来随着流量压力增大，PD分离（将Prefill与Decode分别部署到不同节点实例）是必然趋势。Kthena的ModelServing原生支持任意角色组合，Kthena Router支持PD感知的请求路由，届时只需修改YAML配置即可平滑过渡到PD分离架构，不需要更换底层平台。

完整的运维治理能力

内置的Downloader Sidecar支持从S3、OBS、HuggingFace等多种来源下载模型权重，RuntimeAgent Sidecar标准化了vLLM/SGLang等多种引擎的指标接口，Kthena Router基于实时指标（KV Cache占用率、队列长度、TTFT/TPOT等）做智能路由，这些能力已经覆盖了现阶段运维最核心的痛点。

Kthena 技术架构详解

整体架构

Kthena采用两平面架构，将控制面与数据面分离部署，互不耦合：

核心组件

ModelServing Controller（控制平面）

ModelServing Controller是Kthena的工作负载管理核心，主要职责包括：

工作负载协调：将ModelServing CR转化为Entry Pod、Worker Pod集合和对应的Headless Service。
- Entry Pod（主节点）：每个ServingGroup有且仅有一个Entry Pod，承担两类职责：其一作为分布式推理的协调者——以SGLang为例，Entry Pod启动时以--node-rank=0身份初始化分布式通信后端，并对外暴露HTTP推理接口；其二作为Worker Pod的服务发现锚点——Entry Pod的稳定地址（ENTRY_ADDRESS）会被Kthena自动注入到同Group所有Worker Pod的环境变量中，Worker启动时通过ENTRY_ADDRESS加入分布式集群，无需任何外部注册中心。
- Worker Pod（工作节点）：一个ServingGroup可包含一到多个Worker Pod，每个Worker以WORKER_INDEX（1, 2, …）标识自己在Group中的序号，以GROUP_SIZE感知总节点数，启动后通过dist-init-addr连接Entry Pod，协同完成跨节点的张量并行推理计算。Entry + Worker的数量之和即为一次推理实例所占用的总节点数。
- Headless Service（无头服务）：Kthena为每个ServingGroup创建一个Headless Service（clusterIP: None），为Entry Pod提供稳定的DNS名称（<pod-name>.<svc-name>.<namespace>.svc.cluster.local）。之所以选用Headless Service而非普通ClusterIP Service，是因为分布式推理框架（SGLang/vLLM）需要直接与特定节点（Entry Pod）建立点对点通信（NCCL/HCCL），而普通Service会对流量做负载均衡，掩盖真实Pod IP，导致通信后端无法正确握手；Headless Service的DNS直接解析到Pod IP，满足分布式通信对直连寻址的严格要求。
Gang Scheduling 集成：为每个ServingGroup自动创建Volcano PodGroup，并根据MinRoleReplicas配置生成subGroupPolicy，实现Role级别的细粒度Gang调度
网络拓扑调度：读取networkTopology配置，将HyperNode约束注入PodGroup的networkTopology字段
服务发现注入：通过环境变量ENTRY_ADDRESS、WORKER_INDEX、GROUP_SIZE在Pod启动时注入集群拓扑信息，Worker Pod无需外部注册即可找到Leader
故障恢复：支持restartGracePeriodSeconds宽限期，在Pod失败后等待一段时间再触发整组重建
滚动升级：以ServingGroup为单位进行顺序滚动升级，保证升级过程中服务连续性

Kthena Router（数据平面）

Kthena Router是请求数据平面的统一入口，处理流程如下：

Router通过Metrics Fetcher持续采集推理引擎（vLLM/SGLang）暴露的实时指标（KV Cache占用率、LoRA加载状态、请求队列长度、TTFT/TPOT等），并存储到Datastore，供调度插件在选取后端Pod时参考。

Downloader Sidecar

Downloader以Init Container形式注入到推理Pod中，负责在服务启动前从存储介质（HuggingFace Hub、S3/OBS对象存储、PVC）下载模型权重文件，支持并发下载和文件锁保证幂等性。

RuntimeAgent Sidecar

RuntimeAgent以Sidecar形式运行在推理Pod中，提供：

指标标准化代理：统一vLLM/SGLang等不同引擎的指标接口，向Router的Metrics Fetcher提供标准化指标
LoRA生命周期管理：提供LoRA Adapter的下载/加载/卸载API，支持不停服热切换

组件部署交互流程

以两节点部署GLM-5 744B（Entry Pod在节点1，Worker Pod在节点2）为例，完整流程分为两个阶段。

阶段一：资源提交与调度（步骤 1-7）

阶段二：服务启动与就绪（步骤 8-15）

核心 CRD 资源

Kthena通过以下CRD资源体系对外提供声明式配置接口：

ModelServing

ModelServing是多机多卡推理部署的核心资源，管理ServingGroup集合的生命周期。

字段路径	类型	说明
`spec.schedulerName`	`string`	调度器名称，使用`Volcano`时填写`volcano`
`spec.replicas`	`int`	`ServingGroup`副本数
`spec.template.gangPolicy.minRoleReplicas`	`map`	各角色`Gang`调度的最小副本数
`spec.template.networkTopology.rolePolicy`	`object`	`Role`级别的网络拓扑约束
`spec.template.networkTopology.groupPolicy`	`object`	`Group`级别的网络拓扑约束
`spec.template.roles[].name`	`string`	角色名称（如`prefill`、`decode`）
`spec.template.roles[].replicas`	`int`	该角色的副本数
`spec.template.roles[].entryTemplate`	`PodTemplate`	`Entry Pod`（主节点）模板
`spec.template.roles[].workerReplicas`	`int`	`Worker Pod`数量
`spec.template.roles[].workerTemplate`	`PodTemplate`	`Worker Pod`（从节点）模板
`spec.template.restartGracePeriodSeconds`	`int`	故障恢复宽限时间（秒）

ModelRoute

ModelRoute定义请求路由规则，按模型名称、HTTP属性将请求匹配到对应的ModelServer。

字段路径	类型	说明
`spec.modelName`	`string`	按模型名称匹配请求
`spec.loraAdapters`	`[]string`	按`LoRA Adapter`名称匹配
`spec.rules[].matches`	`[]object`	`HTTP`路径/头部匹配规则
`spec.rules[].backendRefs`	`[]object`	目标`ModelServer`引用
`spec.rules[].weight`	`int`	流量权重（支持灰度发布）
`spec.rateLimit`	`object`	基于`token`数的限流配置

ModelServer

ModelServer定义后端推理服务实例的暴露策略和流量访问策略。

字段路径	类型	说明
`spec.workloadSelector`	`LabelSelector`	选择后端推理`Pod`
`spec.inferenceFramework`	`string`	推理框架（`vllm`/`sglang`等）
`spec.modelName`	`string`	模型名称
`spec.trafficPolicy.retries`	`object`	重试策略
`spec.trafficPolicy.timeout`	`duration`	请求超时

ModelBooster

ModelBooster是高层API，通过单个资源声明自动创建并级联管理ModelRoute、ModelServer、ModelServing和AutoScalingPolicy等所有下层资源，适合快速上手或配置需求标准化的场景。

AutoScalingPolicy / AutoScalingPolicyBinding

AutoScalingPolicy定义扩缩容规则（基于CPU、GPU、内存或自定义指标），AutoScalingPolicyBinding将策略绑定到具体的ModelServing实例，支持同构扩缩和异构实例优化两种模式。

使用示例：kind 本地集群运行

下面通过一个完整示例演示如何在本地kind集群中部署Kthena并运行模拟推理服务（无需真实GPU/NPU卡）。

环境准备

依赖工具

Docker（>=20.10）
kind（>=0.20.0）
kubectl（>=1.28）
Helm（>=3.0）

验证工具：

docker --version
kind --version
kubectl version --client
helm version

步骤一：创建 kind 集群

Kthena 推荐使用两个节点的kind集群模拟多节点场景（一个Control Plane + 两个Worker节点）：

# kind-cluster-config.yaml
kind: Cluster
apiVersion: kind.x-k8s.io/v1alpha4
name: kthena
nodes:
  - role: control-plane
  - role: worker
    labels:
      node-role: inference-node1
  - role: worker
    labels:
      node-role: inference-node2

kind create cluster --config kind-cluster-config.yaml
kubectl get nodes

预期输出：

NAME                   STATUS   ROLES           AGE   VERSION
kthena-control-plane   Ready    control-plane   2m    v1.31.x
kthena-worker          Ready    <none>          2m    v1.31.x
kthena-worker2         Ready    <none>          2m    v1.31.x

步骤二：安装 Volcano

kubectl apply -f https://raw.githubusercontent.com/volcano-sh/volcano/master/installer/volcano-development.yaml
kubectl wait deploy/volcano-scheduler -n volcano-system --for=condition=available --timeout=5m
kubectl wait deploy/volcano-controller-manager -n volcano-system --for=condition=available --timeout=5m

验证Volcano安装：

kubectl get pods -n volcano-system

步骤三：安装 Kthena

使用Helm从GitHub Container Registry安装Kthena：

# 创建命名空间
kubectl create namespace kthena-system

# 安装 Kthena（最新版本）
helm install kthena oci://ghcr.io/volcano-sh/charts/kthena \
  --version v0.2.0 \
  --namespace kthena-system \
  --create-namespace

# 等待所有组件就绪
kubectl wait deploy/kthena-controller-manager -n kthena-system \
  --for=condition=available --timeout=5m
kubectl wait deploy/kthena-router -n kthena-system \
  --for=condition=available --timeout=5m

验证安装：

kubectl get pods -n kthena-system

预期输出：

NAME                                      READY   STATUS    AGE
kthena-controller-manager-xxxx-xxxx       1/1     Running   1m
kthena-router-xxxx-xxxx                   1/1     Running   1m

也可以使用Kthena内置的hack脚本一键完成上述所有步骤：

git clone https://github.com/volcano-sh/kthena.git
cd kthena
./hack/local-up-kthena.sh

步骤四：部署模拟多节点推理服务

在本地kind集群中没有真实GPU，我们使用nginx模拟一个简单的推理服务端点（仅用于验证Kthena的调度和路由流程）。

创建模拟推理服务的 ModelServing：

# mock-inference-modelserving.yaml
apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: mock-llm
  namespace: default
spec:
  schedulerName: volcano
  replicas: 1
  template:
    restartGracePeriodSeconds: 30
    gangPolicy:
      minRoleReplicas:
        llm-node: 1
    roles:
      - name: llm-node
        replicas: 2     # 2个节点（Entry + Worker）
        entryTemplate:
          spec:
            containers:
              - name: mock-inference
                image: nginx:alpine
                ports:
                  - containerPort: 80
                readinessProbe:
                  httpGet:
                    path: /
                    port: 80
                  initialDelaySeconds: 5
                  periodSeconds: 5
                env:
                  - name: ROLE
                    value: "entry"
        workerReplicas: 1
        workerTemplate:
          spec:
            containers:
              - name: mock-worker
                image: nginx:alpine
                env:
                  - name: ROLE
                    value: "worker"
                  - name: ENTRY_ADDRESS
                    value: "$(ENTRY_ADDRESS)"

kubectl apply -f mock-inference-modelserving.yaml

查看创建的Pod和PodGroup：

kubectl get pods -o wide
kubectl get podgroup

预期输出（Kthena自动为ModelServing创建了命名规则清晰的Pod）：

NAME                      READY   STATUS    NODE
mock-llm-0-llmnode-0-0    1/1     Running   kthena-worker
mock-llm-0-llmnode-0-1    1/1     Running   kthena-worker2

NAME         STATUS    MINMEMBER   RUNNINGS
mock-llm-0   Running   2           2

创建 ModelServer 和 ModelRoute：

# mock-inference-routing.yaml
---
apiVersion: networking.serving.volcano.sh/v1alpha1
kind: ModelServer
metadata:
  name: mock-llm-server
  namespace: default
spec:
  inferenceFramework: vllm   # 框架标识
  modelName: mock-model
  workloadSelector:
    matchLabels:
      modelserving.volcano.sh/name: mock-llm
      modelserving.volcano.sh/entry: "true"
  trafficPolicy:
    timeout: 60s
---
apiVersion: networking.serving.volcano.sh/v1alpha1
kind: ModelRoute
metadata:
  name: mock-llm-route
  namespace: default
spec:
  modelName: mock-model
  rules:
    - backendRefs:
        - name: mock-llm-server
          weight: 100

kubectl apply -f mock-inference-routing.yaml

验证路由：

# 获取 Kthena Router 的 ClusterIP
ROUTER_IP=$(kubectl get svc kthena-router -n kthena-system \
  -o jsonpath='{.spec.clusterIP}')

# 在集群内发送模拟请求（使用 busybox pod）
kubectl run test-client --image=busybox --restart=Never --rm -it \
  -- wget -qO- http://${ROUTER_IP}:8080/v1/models

步骤五：查看 Kthena 自动注入的环境变量

验证Kthena的服务发现注入是否正常（Worker Pod通过ENTRY_ADDRESS无需手动配置即可找到Leader）：

# 查看 Entry Pod 的环境变量
kubectl exec mock-llm-0-llmnode-0-0 -- env | grep -E "ENTRY_ADDRESS|WORKER_INDEX|GROUP_SIZE"

# 查看 Worker Pod 的环境变量
kubectl exec mock-llm-0-llmnode-0-1 -- env | grep -E "ENTRY_ADDRESS|WORKER_INDEX|GROUP_SIZE"

预期输出（Worker Pod能自动感知Entry Pod地址）：

# Worker Pod 输出
ENTRY_ADDRESS=mock-llm-0-llmnode-0-0.mock-llm-0-llmnode-0-0.default.svc.cluster.local
WORKER_INDEX=1
GROUP_SIZE=2

步骤六：清理环境

kubectl delete -f mock-inference-routing.yaml
kubectl delete -f mock-inference-modelserving.yaml
./hack/local-up-kthena.sh -q   # 清理 Kthena 和 Kind 集群

生产环境配置参考

在实际部署GLM-5 744B（2节点 × 8卡昇腾910B3）时，以SGLang引擎为例，ModelServing配置参考如下：

apiVersion: workload.serving.volcano.sh/v1alpha1
kind: ModelServing
metadata:
  name: glm5-744b
  namespace: ai-serving
spec:
  schedulerName: volcano
  replicas: 1
  template:
    restartGracePeriodSeconds: 120
    gangPolicy:
      minRoleReplicas:
        glm5: 1         # 至少1个完整的Entry+Worker组才能启动
    networkTopology:
      rolePolicy:
        mode: hard
        highestTierAllowed: 1     # Entry和Worker必须在同一HyperNode下
      groupPolicy:
        mode: soft
        highestTierAllowed: 2
    roles:
      - name: glm5
        replicas: 2               # Entry(Leader) + Worker(Follower)
        entryTemplate:
          spec:
            initContainers:
              - name: model-downloader
                image: ghcr.io/volcano-sh/downloader:latest
                env:
                  - name: MODEL_SOURCE
                    value: "obs://your-bucket/glm-5-744b"
                  - name: MODEL_TARGET
                    value: "/models/glm-5-744b"
                volumeMounts:
                  - name: model-storage
                    mountPath: /models
            containers:
              - name: sglang-leader
                image: lmsysorg/sglang:latest
                command:
                  - sh
                  - -c
                  - |
                    python3 -m sglang.launch_server \
                      --model-path /models/glm-5-744b \
                      --tp $(GROUP_SIZE * 8) \
                      --dist-init-addr ${ENTRY_ADDRESS}:20000 \
                      --nccl-port 20001 \
                      --nnodes ${GROUP_SIZE} \
                      --node-rank ${WORKER_INDEX} \
                      --host 0.0.0.0 \
                      --port 30000 \
                      --trust-remote-code
                resources:
                  limits:
                    huawei.com/Ascend910B: "8"
                    memory: 1200Gi
                ports:
                  - containerPort: 30000
                readinessProbe:
                  tcpSocket:
                    port: 30000
                  initialDelaySeconds: 600
                  periodSeconds: 30
                volumeMounts:
                  - name: model-storage
                    mountPath: /models
            volumes:
              - name: model-storage
                persistentVolumeClaim:
                  claimName: glm5-model-pvc
        workerReplicas: 1
        workerTemplate:
          spec:
            initContainers:
              - name: model-downloader
                image: ghcr.io/volcano-sh/downloader:latest
                env:
                  - name: MODEL_SOURCE
                    value: "obs://your-bucket/glm-5-744b"
                  - name: MODEL_TARGET
                    value: "/models/glm-5-744b"
                volumeMounts:
                  - name: model-storage
                    mountPath: /models
            containers:
              - name: sglang-worker
                image: lmsysorg/sglang:latest
                command:
                  - sh
                  - -c
                  - |
                    python3 -m sglang.launch_server \
                      --model-path /models/glm-5-744b \
                      --tp $(GROUP_SIZE * 8) \
                      --dist-init-addr ${ENTRY_ADDRESS}:20000 \
                      --nccl-port 20001 \
                      --nnodes ${GROUP_SIZE} \
                      --node-rank ${WORKER_INDEX} \
                      --trust-remote-code
                resources:
                  limits:
                    huawei.com/Ascend910B: "8"
                    memory: 1200Gi
                env:
                  - name: ENTRY_ADDRESS
                    value: "$(ENTRY_ADDRESS)"   # Kthena 自动注入
                  - name: WORKER_INDEX
                    value: "$(WORKER_INDEX)"    # Kthena 自动注入
                  - name: GROUP_SIZE
                    value: "$(GROUP_SIZE)"      # Kthena 自动注入
                volumeMounts:
                  - name: model-storage
                    mountPath: /models
            volumes:
              - name: model-storage
                persistentVolumeClaim:
                  claimName: glm5-model-pvc

总结

本文从公司使用昇腾NPU部署GLM-5 744B超大规模模型的真实背景出发，系统梳理了多机多卡LLM推理部署的核心痛点，并对LWS、RBG、Kthena三种业界主流方案进行了深入对比分析。

Kthena作为Volcano生态下的企业级推理平台，凭借与Volcano调度器的深度集成、完整的PD分离支持、内置的智能路由层以及端到端的模型生命周期管理，成为当前技术栈下最适合的选择。其ModelServing的三层抽象（ServingGroup > Role > Entry/Worker）精确描述了多节点协作推理的拓扑需求，Gang Scheduling + HyperNode网络拓扑感知调度从根本上解决了多机多卡部署的资源死锁和通信效率问题。

随着GLM-5等更大规模模型的持续演进，Kthena的PD分离能力将为未来架构演进提供平滑路径，不需要替换底层平台即可支持更高级的推理优化策略。

背景与痛点​

直接痛点：超大模型的张量并行​

多机多卡部署场景下的核心痛点​

三种技术方案对比​

LeaderWorkerSet（LWS）​

RoleBasedGroup（RBG）​

Kthena​

方案选型对比总结​

为何选择 Kthena​

与 Volcano 生态完全契合​

解决当前多机多卡的直接痛点​

面向未来的PD分离扩展能力​

完整的运维治理能力​

Kthena 技术架构详解​

整体架构​

核心组件​

ModelServing Controller（控制平面）​

Kthena Router（数据平面）​

Downloader Sidecar​

RuntimeAgent Sidecar​

组件部署交互流程​

核心 CRD 资源​

ModelServing​

ModelRoute​

ModelServer​

ModelBooster​

AutoScalingPolicy / AutoScalingPolicyBinding​

使用示例：kind 本地集群运行​

环境准备​

步骤一：创建 kind 集群​

步骤二：安装 Volcano​

步骤三：安装 Kthena​

步骤四：部署模拟多节点推理服务​

步骤五：查看 Kthena 自动注入的环境变量​

步骤六：清理环境​

生产环境配置参考​

总结​

背景与痛点

直接痛点：超大模型的张量并行

多机多卡部署场景下的核心痛点

三种技术方案对比

LeaderWorkerSet（LWS）

RoleBasedGroup（RBG）

Kthena

方案选型对比总结

为何选择 Kthena

与 Volcano 生态完全契合

解决当前多机多卡的直接痛点

面向未来的PD分离扩展能力

完整的运维治理能力

Kthena 技术架构详解

整体架构

核心组件

ModelServing Controller（控制平面）

Kthena Router（数据平面）

Downloader Sidecar

RuntimeAgent Sidecar

组件部署交互流程

核心 CRD 资源

ModelServing

ModelRoute

ModelServer

ModelBooster

AutoScalingPolicy / AutoScalingPolicyBinding

使用示例：kind 本地集群运行

环境准备

步骤一：创建 kind 集群

步骤二：安装 Volcano

步骤三：安装 Kthena

步骤四：部署模拟多节点推理服务

步骤五：查看 Kthena 自动注入的环境变量

步骤六：清理环境

生产环境配置参考

总结