使用 Kubeflow Trainer v2 进行微调

本教程演示如何使用 Kubeflow Trainer v2 在 Kubernetes 上运行基于 LlamaFactory 的监督微调(SFT)作业。

概述

Kubeflow Trainer v2 将作业模板TrainingRuntime)与作业运行TrainJob)分离,允许你:

  • 定义一个可复用的 TrainingRuntime,其中包含容器镜像、训练流水线步骤(数据集初始化 → 模型初始化 → 训练器)以及 LlamaFactory 配置。
  • 提交多个引用同一运行时的 TrainJob,只覆盖每个实验中变化的部分——基础模型、数据集 URL、超参数或 GPU 资源。

前提条件

开始之前,请确保以下条件已满足:

要求详情
Kubeflow Trainer v2已在集群中安装(trainer.kubeflow.org API 组可用)
Kueue已在集群中安装,用于作业调度和配额管理(可选但推荐)
共享 PVC一个所有 Pod 都可访问的 PersistentVolumeClaim(例如 team-model-cache-pvc),后端存储可为 NFS、Ceph 或本地存储如 topolvm
Git 凭据一个名为 aml-image-builder-secret 的 Kubernetes Secret,包含访问私有 Git 仓库所需的 MODEL_REPO_GIT_USERMODEL_REPO_GIT_TOKEN 两个密钥
GPU 节点配备 NVIDIA GPU 的节点;示例中使用的是 Tesla-T4 节点,请根据你的集群调整 nodeSelector
kubectl 访问权限配置了权限,可在目标命名空间中创建 TrainingRuntimeTrainJob 资源

RBAC 权限

如果在创建或管理 Kubeflow Trainer v2 资源时遇到 RBAC 权限错误,请先停止操作并联系你的集群管理员。请管理员为你创建一个临时角色,并将其绑定到你的账户或命名空间,使你拥有对 trainjobstrainingruntimes 自定义资源的读写权限。

下面示例展示了集群管理员如何为名为 aml-editor 的工作台所使用的 ServiceAccount 授权:

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: aml-editor-trainer-rw
  namespace: mlops-demo-ai-test
rules:
  - apiGroups:
      - trainer.kubeflow.org
    resources:
      - trainjobs
      - trainingruntimes
    verbs:
      - get
      - list
      - watch
      - create
      - update
      - patch
      - delete
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: aml-editor-trainer-rw
  namespace: mlops-demo-ai-test
subjects:
  - kind: ServiceAccount
    name: aml-editor
    namespace: mlops-demo-ai-test
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: aml-editor-trainer-rw

请将 mlops-demo-ai-test 替换为工作台和 Trainer v2 资源运行的命名空间。

构建 Trainer 镜像或使用预构建镜像

你可以使用我们预构建的镜像 alaudadockerhub/fine_tune_with_llamafactory:v0.1.11,也可以使用 aml-docs 中提供的 Containerfile 自行构建镜像。

下载 notebook 并运行示例

  1. 下载 notebook 到你当前的 Alauda AI 工作台,如果没有工作台请先创建一个,然后打开该 notebook。
  2. 按照 notebook 中的说明创建 TrainingRuntime 并提交 TrainJob,以微调 LLaMA-Factory 模型。notebook 中包含了使用 team-model-cache-pvc 共享 PVC 和 Git 凭据的示例配置。

使用 Kueue 进行调度

Kueue 为 Kubernetes 工作负载提供作业排队、配额管理和公平调度功能。当 Kueue 安装在集群中时,TrainJob 会处于挂起状态,直到 Kueue 根据可用配额批准它们。

工作原理

  1. 集群管理员创建带有资源配额(CPU、内存、GPU)的 ClusterQueue
  2. 命名空间管理员创建指向该 ClusterQueueLocalQueue
  3. 用户在 TrainJob 上添加标签 kueue.x-k8s.io/queue-name,将作业提交到对应的 LocalQueue
  4. Kueue 评估资源请求,在配额可用时批准工作负载并解除挂起。

有关设置 ClusterQueueLocalQueue 的详细信息,请参阅 Kueue 文档

创建 LocalQueue(可选)

在使用 Kueue 提交 TrainJob 之前,请在你的命名空间中创建一个引用已有 ClusterQueueLocalQueue

apiVersion: kueue.x-k8s.io/v1beta2
kind: LocalQueue
metadata:
  name: local-queue
  namespace: mlops-demo-ai-test
spec:
  clusterQueue: cluster-queue
kubectl apply -f kf-local-queue.yaml

使用 Kueue 提交 TrainJob(可选)

要与 Kueue 集成,请在 TrainJob 的 metadata.labels 中添加 kueue.x-k8s.io/queue-name 标签,指定作业所属的 LocalQueue

metadata:
  generateName: trainjob-sft-qwen3-
  namespace: mlops-demo-ai-test
  labels:
    kueue.x-k8s.io/queue-name: local-queue

TrainJob 规范的其他部分保持不变。完整示例请参见 notebook。

NOTE

启用 Kueue 时,集群可能配置了 PodsReady 超时(例如 5 分钟)。如果训练镜像较大且尚未缓存到节点,首次尝试可能因镜像拉取超时而被驱逐。通常重新提交作业会成功,因为镜像已被本地缓存。