• Русский
  • Тонкая настройка с Kubeflow Trainer v2

    В этом руководстве показано, как использовать Kubeflow Trainer v2 для запуска задач контролируемой тонкой настройки (SFT) с помощью LlamaFactory на Kubernetes.

    Обзор

    Kubeflow Trainer v2 разделяет шаблоны заданий (TrainingRuntime) и запуски заданий (TrainJob), что позволяет:

    • Определять переиспользуемый TrainingRuntime, который содержит образ контейнера, шаги тренировочного пайплайна (инициализация датасета → инициализация модели → тренер) и конфигурацию LlamaFactory.
    • Отправлять множество запусков TrainJob, ссылающихся на один и тот же runtime, переопределяя только изменяющиеся параметры для каждого эксперимента — базовую модель, URL датасета, гиперпараметры или ресурсы GPU.

    Требования

    Перед началом убедитесь, что выполнены следующие условия:

    ТребованиеПодробности
    Kubeflow Trainer v2Установлен в вашем кластере (доступна группа API trainer.kubeflow.org)
    KueueУстановлен в вашем кластере для планирования заданий и управления квотами (необязательно, но рекомендуется)
    Общий PVCPersistentVolumeClaim, доступный для всех подов (например, team-model-cache-pvc), с поддержкой NFS, Ceph или локального хранилища, например topolvm
    Git-учётные данныеKubernetes Secret с именем aml-image-builder-secret, содержащий ключи MODEL_REPO_GIT_USER и MODEL_REPO_GIT_TOKEN для доступа к приватным Git-репозиториям
    Узлы с GPUУзлы с NVIDIA GPU; в примерах используются узлы Tesla-T4 — настройте nodeSelector под ваш кластер
    Доступ к kubectlkubectl, настроенный с правами на создание ресурсов TrainingRuntime и TrainJob в целевом namespace

    Права RBAC

    Если при создании или управлении ресурсами Kubeflow Trainer v2 возникают ошибки прав RBAC, остановитесь и обратитесь к администратору кластера. Попросите администратора создать временную роль и привязать её к вашей учётной записи или namespace, чтобы у вас были права чтения и записи для кастомных ресурсов trainjobs и trainingruntimes.

    Пример, как администратор кластера может предоставить такие права ServiceAccount, используемому рабочей средой с именем aml-editor:

    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 на namespace, в котором работают рабочая среда и ресурсы Trainer v2.

    Сборка образа Trainer или использование предсобранного образа

    Используйте наш предсобранный образ alaudadockerhub/fine_tune_with_llamafactory:v0.1.11 или соберите собственный образ с помощью предоставленного Containerfile в aml-docs.

    Скачайте ноутбук и запустите пример

    1. Скачайте ноутбук в текущую рабочую среду в Alauda AI, создайте новую рабочую среду, если у вас её нет, и откройте ноутбук.
    2. Следуйте инструкциям в ноутбуке для создания TrainingRuntime и отправки TrainJob для тонкой настройки модели LLaMA-Factory. В ноутбуке приведены примеры конфигураций с использованием общего PVC team-model-cache-pvc и Git-учётных данных.

    Планирование с Kueue

    Kueue обеспечивает очередь заданий, управление квотами и справедливое планирование для рабочих нагрузок Kubernetes. При установке Kueue в вашем кластере TrainJobs удерживаются в состоянии suspended до тех пор, пока Kueue не допустит их на основе доступных квот.

    Как это работает

    1. Администратор кластера создаёт ClusterQueue с квотами ресурсов (CPU, память, GPU).
    2. Администратор namespace создаёт LocalQueue, ссылающийся на ClusterQueue.
    3. Пользователи маркируют свои TrainJob меткой kueue.x-k8s.io/queue-name, чтобы отправить их в LocalQueue.
    4. Kueue оценивает запрос ресурсов, допускает нагрузку при наличии квоты и снимает приостановку с задания.

    Подробности по настройке ClusterQueue и LocalQueue смотрите в документации Kueue.

    Создание LocalQueue (необязательно)

    Перед отправкой TrainJobs с Kueue создайте LocalQueue в вашем namespace, ссылающийся на существующий ClusterQueue:

    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

    Отправка TrainJob с Kueue (необязательно)

    Для интеграции с Kueue добавьте метку kueue.x-k8s.io/queue-name в metadata.labels вашего TrainJob. Это укажет Kueue, к какому LocalQueue относится задание:

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

    Остальная часть спецификации TrainJob остаётся без изменений. Полный пример смотрите в ноутбуке.

    NOTE

    При включённом Kueue в кластере может быть настроено ограничение по времени ожидания PodsReady (например, 5 минут). Если ваш тренировочный образ большой и ещё не закеширован на узле, первая попытка может быть отменена из-за таймаута загрузки образа. Повторная отправка задания обычно успешна, так как образ уже будет закеширован локально.