#Тонкая настройка LLM с использованием Workbench

#Общие сведения

Тонкая настройка и обучение моделей часто требуют адаптации к различным структурам моделей, аппаратным устройствам и соответствующим методам параллельного обучения. Alauda AI Workbench предоставляет комплексный подход — от разработки модели до отправки задач обучения, управления ими и отслеживания экспериментов, помогая инженерам по моделям и алгоритмам быстро адаптироваться и завершить весь процесс тонкой настройки и обучения модели.

В этом решении приведён пример тонкой настройки модели Qwen3-0.6B с использованием LLaMA-Factory.

Alauda AI Workbench создаёт контейнерную среду Notebook/VSCode (CodeServer) для разработки и отладки в пространстве имён пользователя. В пространстве имён можно создать несколько экземпляров Notebook/VSCode, чтобы сохранить среды для разных пользователей и задач разработки. Ноутбуки могут запрашивать только CPU-ресурсы для разработки и отправки задач в кластер, используя GPU-ресурсы кластера для выполнения задач. Также можно запрашивать GPU-ресурсы для Notebook, что позволяет выполнять задачи, такие как обучение и тонкая настройка, непосредственно в Notebook, независимо от того, требует ли модель распределённого обучения.

Кроме того, вы можете использовать встроенный в платформу MLFlow для записи различных метрик каждой сессии тонкой настройки модели, что облегчает сравнение нескольких экспериментов и выбор итоговой модели.

Для отправки задач кластера из Notebook мы используем VolcanoJob — Kubernetes-нативный менеджер ресурсов. Планировщик Volcano поддерживает очереди, приоритеты и различные политики планирования, что способствует более эффективному планированию задач в кластере и улучшению использования ресурсов.

В этом решении используется LLaMA-Factory для запуска задач тонкой настройки и обучения. Однако для более масштабных сценариев тонкой настройки и обучения моделей, требующих параллельных методов, таких как Tensor Parallelism, Context Parallelism и Expert Parallelism для обучения больших моделей, может потребоваться использование других инструментов, создание собственных runtime-образов для тонкой настройки и изменение скрипта запуска задач для адаптации к разным инструментам и моделям. Для более подробного использования и настройки параметров LLaMA-Factory смотрите: https://llamafactory.readthedocs.io/en/latest/index.html

#Область применения

• Решение применимо к Alauda AI версии 1.3 и выше.
• Тонкая настройка и обучение моделей LLM. Для обучения других типов моделей (например, YOLOv5) потребуется использовать другие образы, скрипты запуска, наборы данных и т.д.
• Решение применимо для сценариев с CPU x86/64 и GPU NVIDIA.
• Для сценариев с NPU требуется построить подходящий runtime-образ на основе данного решения для совместимости.

#Подготовка

• Сначала необходимо развернуть плагин "Alauda AI Workbench" для поддержки Workbench (или развернуть плагин Kubeflow Base для использования Notebook с Kubeflow).
• Установить плагин MLFlow для отслеживания экспериментов.

#Шаги тонкой настройки модели LLM

#Создание экземпляра Notebook/VSCode

Перейдите в Alauda AI - Workbench (или Advanced - Kubeflow - Notebook), затем создайте новый Notebook или используйте существующий. Рекомендуется, чтобы Notebook использовал только CPU-ресурсы. Отправка задачи в кластер из Notebook будет запрашивать GPU-ресурсы в кластере для повышения эффективности использования ресурсов.

Подробные шаги создания экземпляра Notebook/VSCode смотрите в разделе Creating a Workbench.

#Подготовка модели

Скачайте модель Qwen/Qwen3-0.6B с Huggingface или других сайтов с открытым исходным кодом моделей. Затем загрузите модель в репозиторий моделей.

Подробные шаги загрузки файлов модели в репозиторий смотрите в Upload Models Using Notebook.

#Подготовка места вывода модели

Создайте пустую модель в репозитории моделей для хранения выходной модели. При настройке места вывода тонкой настройки укажите URL Git-репозитория модели.

#Подготовка набора данных

Скачайте и загрузите пример набора данных identity в репозиторий наборов данных. Этот набор используется для тонкой настройки LLM, чтобы отвечать на вопросы пользователя, например "Кто ты?"

1. Сначала создайте пустой репозиторий набора данных в разделе "Datasets" - "Dataset Repository".
2. Загрузите zip-файл в Notebook, распакуйте его, затем перейдите в каталог набора данных. Используйте git lfs для загрузки набора данных в Git URL репозитория набора данных. Шаги аналогичны загрузке модели.
3. После завершения загрузки обновите страницу набора данных — в вкладке "File Management" вы увидите успешно загруженный файл.

Примечание: Формат набора данных должен быть корректно распознан фреймворком тонкой настройки для использования в последующих задачах тонкой настройки. Ниже приведены два распространённых формата наборов данных для тонкой настройки LLM:

#Формат набора данных Huggingface

Вы можете использовать следующий код, чтобы проверить, корректно ли загружается формат каталога набора данных с помощью datasets:

import datasets

ds_infos = datasets.get_dataset_infos(<dataset directory>)
ds = datasets.load_dataset(<dataset directory>)
print(ds_infos)
print(ds)

#Формат LLaMA-Factory

Если вы используете инструмент LLaMA-Factory из примеров для обучения, формат набора данных должен соответствовать формату LLaMA-Factory. Справка: data_preparation

#Подготовка runtime-образа

Используйте следующий Containerfile для сборки runtime-образа обучения или используйте предсобранный образ: alaudadockerhub/fine_tune_with_llamafactory:v0.1.1. Если вы хотите использовать другой фреймворк обучения, например YOLOv5, возможно, потребуется кастомизировать образ и установить необходимые зависимости.

После сборки образа загрузите его в реестр образов кластера платформы Alauda AI и настройте в последующих задачах.

Примечание: В образе должна быть доступна команда git lfs для загрузки и выгрузки файлов модели и набора данных.

ARG LLAMA_FACTORY_VERSION="v0.9.4"
FROM python:3.13-trixie

RUN sed -i 's/deb.debian.org/mirrors.ustc.edu.cn/g' /etc/apt/sources.list.d/debian.sources && \
apt-get update && \
export DEBIAN_FRONTEND=noninteractive && \
apt-get install -yq --no-install-recommends git git-lfs unzip curl ffmpeg default-libmysqlclient-dev build-essential pkg-config && \
apt clean && rm -rf /var/lib/apt/lists/*

RUN pip install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple -U pip setuptools && \
cd /opt && \
git clone --depth 1 https://github.com/hiyouga/LLaMA-Factory.git && \
cd LLaMA-Factory && git checkout ${LLAMA_FACTORY_VERSION} && \
pip install --no-cache-dir -e ".[torch,metrics,deepspeed,awq,modelscope]" -i https://pypi.tuna.tsinghua.edu.cn/simple

RUN pip install --no-cache-dir -i https://pypi.tuna.tsinghua.edu.cn/simple \
"transformers>=4.51.1,<5" \
"tokenizers>=0.21.1" \
"sqlalchemy~=2.0.30" \
"pymysql~=1.1.1" \
"loguru~=0.7.2" \
"mysqlclient~=2.2.7" \
"mlflow>=3.1"
WORKDIR /opt

#Создание задачи VolcanoJob для тонкой настройки

В Notebook создайте YAML-файл для отправки задачи. Пример приведён ниже:

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  generateName: vcjob-sft-qwen3-
spec:
  minAvailable: 1
  schedulerName: volcano
  maxRetry: 1
  queue: default
  volumes:
    # PVC рабочего пространства, где выполняется задача (временный PVC)
    - mountPath: "/mnt/workspace"
      volumeClaim:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "sc-topolvm"
        resources:
          requests:
            storage: 5Gi
  tasks:
    - name: "train"
      # Количество параллельных реплик. Для распределённых задач обучения можно указать replicas > 2
      replicas: 1
      template:
        metadata:
          name: train
        spec:
          restartPolicy: Never
          securityContext:
            runAsNonRoot: true
            runAsUser: 65534
            runAsGroup: 65534
            fsGroup: 65534
          # Монтирование shm устройства для предоставления разделяемой памяти, необходимой для коммуникации между несколькими картами.
          volumes:
            - emptyDir:
                medium: Memory
                # Здесь можно настроить размер используемой разделяемой памяти
                sizeLimit: 2Gi
              name: dshm
            # PVC для хранения моделей и наборов данных.
            # В распределённых задачах обучения (с >= 2 репликами) убедитесь, что используете подходящий тип хранилища для кэширования больших моделей:
            # 1. Сетевое хранилище, например NFS или Ceph: просто монтируйте сетевое хранилище. Обратите внимание, что несколько контейнеров могут одновременно обращаться к этому хранилищу, что приводит к высокой нагрузке. Кроме того, чтение больших файлов модели может быть медленнее, чем локальное чтение (в зависимости от производительности сетевого хранилища).
            # 2. Локальное хранилище, например topolvm или local-storage: используйте `kserve local model cache` для предварительного кэширования файла модели на каждом узле перед монтированием этого PVC. Задачи обучения не могут кэшировать каждый локальный PVC.
            - name: models-cache
              persistentVolumeClaim:
                claimName: wy-model-cache
          initContainers:
            - name: prepare
              image: alaudadockerhub/fine_tune_with_llamafactory:v0.1.1
              imagePullPolicy: IfNotPresent
              env:
              # Измените BASE_MODEL_URL на адрес базовой модели, DATASET_URL на адрес набора данных
              - name: BASE_MODEL_URL
                value: "https://<your-model-registry-git-address>/mlops-demo-ai-test/amlmodels/qwen3-0.6b"
              - name: DATASET_URL
                value: "https://<your-model-registry-git-address>/mlops-demo-ai-test/amldatasets/identity-alauda"
              - name: GIT_USER
                valueFrom:
                  secretKeyRef:
                    name: aml-image-builder-secret
                    key: MODEL_REPO_GIT_USER
              - name: GIT_TOKEN
                valueFrom:
                  secretKeyRef:
                    name: aml-image-builder-secret
                    key: MODEL_REPO_GIT_TOKEN
              resources:
                requests:
                  cpu: 100m
                  memory: 128Mi
                limits:
                  cpu: 2
                  memory: 4Gi
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - ALL
                runAsNonRoot: true
                seccompProfile:
                  type: RuntimeDefault
              volumeMounts:
                - name: models-cache
                  mountPath: /mnt/models
              command:
              - /bin/bash
              - -c
              - |
                set -ex
                cd /mnt/models
                BASE_MODEL_NAME=$(basename ${BASE_MODEL_URL})
                # Загрузка базовой модели
                gitauth="${GIT_USER}:${GIT_TOKEN}"
                BASE_MODEL_URL_NO_HTTPS="${BASE_MODEL_URL//https:\/\/}"
                if [ -d ${BASE_MODEL_NAME} ]; then
                    echo "${BASE_MODEL_NAME} dir already exists, skip downloading"
                else
                    GIT_LFS_SKIP_SMUDGE=1 git -c http.sslVerify=false -c lfs.activitytimeout=36000 clone "https://${gitauth}@${BASE_MODEL_URL_NO_HTTPS}"
                    (cd ${BASE_MODEL_NAME} && git -c http.sslVerify=false -c lfs.activitytimeout=36000 lfs pull)
                fi
                # Загрузка набора данных
                DATASET_NAME=$(basename ${DATASET_URL})
                DATASET_URL_NO_HTTPS="${DATASET_URL//https:\/\/}"

                rm -rf ${DATASET_NAME}
                rm -rf data

                if [ -d ${DATASET_NAME} ]; then
                    echo "dataset ${DATASET_NAME} already exists skipping download"
                else
                    git -c http.sslVerify=false -c lfs.activitytimeout=36000 clone "https://${gitauth}@${DATASET_URL_NO_HTTPS}"
                fi
                echo "listing files under /mnt/models ..."
                ls /mnt/models
                echo "listing model files ..."
                ls ${BASE_MODEL_NAME}
                echo "listing dataset files ..."
                ls ${DATASET_NAME}
          containers:
            # Образ runtime-среды. Можно использовать src/llm/Containerfile для сборки подобного образа. Обычно включает cuda, transformers, pytorch, datasets, evaluate и git lfs.
            - name: train
              image: alaudadockerhub/fine_tune_with_llamafactory:v0.1.1
              imagePullPolicy: IfNotPresent
              volumeMounts:
                - mountPath: /dev/shm
                  name: dshm
                - name: models-cache
                  mountPath: /mnt/models
              env:
                # Измените BASE_MODEL_URL на адрес базовой модели, DATASET_URL на адрес набора данных, OUTPUT_MODEL_URL на адрес выходной модели
                - name: BASE_MODEL_URL
                  value: "https://<your-model-registry-git-address>/mlops-demo-ai-test/amlmodels/qwen3-0.6b"
                - name: DATASET_URL
                  value: "https://<your-model-registry-git-address>/mlops-demo-ai-test/amldatasets/identity-alauda"
                - name: OUTPUT_MODEL_URL
                  value: "https://<your-model-registry-git-address>/mlops-demo-ai-test/amlmodels/wy-sft-output"
                # Каталог кэша, используемый библиотеками huggingface, такими как datasets, transformers и др.
                - name: HF_HOME
                  value: /mnt/workspace/hf_cache
                - name: DO_MERGE
                  value: "true"
                - name: GIT_USER
                  valueFrom:
                    secretKeyRef:
                      name: aml-image-builder-secret
                      key: MODEL_REPO_GIT_USER
                - name: GIT_TOKEN
                  valueFrom:
                    secretKeyRef:
                      name: aml-image-builder-secret
                      key: MODEL_REPO_GIT_TOKEN
                # Измените MLFLOW_TRACKING_URI на фактический адрес сервера mlflow
                - name: MLFLOW_TRACKING_URI
                  value: "http://mlflow-tracking-server.kubeflow:5000"
                # Установите MLFLOW_EXPERIMENT_NAME в имя вашего namespace или собственного эксперимента
                - name: MLFLOW_EXPERIMENT_NAME
                  value: mlops-demo-ai-test
              command:
              - bash
              - -c
              - |
                set -ex
                echo "job workers list: ${VC_WORKER_HOSTS}"
                if [ "${VC_WORKER_HOSTS}" != "" ]; then
                    export N_RANKS=$(echo "${VC_WORKER_HOSTS}" |awk -F',' '{print NF}')
                    export RANK=$VC_TASK_INDEX
                    export MASTER_HOST=$(echo "${VC_WORKER_HOSTS}" |awk -F',' '{print $1}')
                    export RANK=$RANK
                    export WORLD_SIZE=$N_RANKS
                    export NNODES=$N_RANKS
                    export NODE_RANK=$RANK
                    export MASTER_ADDR=${MASTER_HOST}
                    export MASTER_PORT="8888"
                else
                    export N_RANKS=1
                    export RANK=0
                    export NNODES=1
                    export MASTER_HOST=""
                fi

                cd /mnt/workspace
                BASE_MODEL_NAME=$(basename ${BASE_MODEL_URL})
                DATASET_NAME=$(basename ${DATASET_URL})

                cat >lf-sft.yaml <<EOL
                model_name_or_path: /mnt/models/${BASE_MODEL_NAME}

                stage: sft
                do_train: true
                finetuning_type: lora
                lora_target: all
                lora_rank: 8
                lora_alpha: 16
                lora_dropout: 0.1

                dataset: identity_alauda
                dataset_dir: /mnt/models/${DATASET_NAME}
                template: qwen
                cutoff_len: 1024
                max_samples: 1000
                overwrite_cache: true
                preprocessing_num_workers: 8

                output_dir: output_models
                logging_steps: 10
                save_steps: 500
                plot_loss: true
                overwrite_output_dir: true

                # global batch size: 8
                per_device_train_batch_size: 2
                gradient_accumulation_steps: 2
                learning_rate: 2.0e-4
                num_train_epochs: 4.0
                bf16: false
                fp16: true
                ddp_timeout: 180000000

                val_size: 0.1
                per_device_eval_batch_size: 1
                eval_strategy: steps
                eval_steps: 500
                report_to: mlflow
                EOL

                # Запуск обучения
                if [ ${NNODES} -gt 1 ]; then
                    echo "deepspeed: ds-z3-config.json" >> lf-sft.yaml
                    FORCE_TORCHRUN=1 llamafactory-cli train lf-sft.yaml
                else
                    unset NNODES
                    unset NODE_RANK
                    unset MASTER_ADDR
                    unset MASTER_PORT
                    llamafactory-cli train lf-sft.yaml
                fi

                if [ "${DO_MERGE}" == "true" ]; then
                  # Объединение адаптеров LoRA
                  cat >lf-merge-config.yaml <<EOL
                model_name_or_path: /mnt/models/${BASE_MODEL_NAME}
                adapter_name_or_path: output_models
                template: qwen
                finetuning_type: lora

                ### export
                export_dir: output_models_merged
                export_size: 4
                export_device: cpu
                export_legacy_format: false
                EOL

                  llamafactory-cli export lf-merge-config.yaml
                else
                  # переместить выходной адаптер для push
                  mv output_models output_models_merged
                fi
                # отправка объединённой модели в репозиторий моделей
                gitauth="${GIT_USER}:${GIT_TOKEN}"
                cd /mnt/workspace/output_models_merged
                touch README.md
                OUTPUT_MODEL_NO_HTTPS="${OUTPUT_MODEL_URL//https:\/\/}"
                PUSH_URL="https://${gitauth}@${OUTPUT_MODEL_NO_HTTPS}"
                push_branch=$(date +'%Y%m%d-%H%M%S')

                git init
                git checkout -b sft-${push_branch}
                git lfs track *.safetensors
                git add .
                git -c user.name='AMLSystemUser' -c user.email='aml_admin@cpaas.io' commit -am "fine tune push auto commit"
                git -c http.sslVerify=false -c lfs.activitytimeout=36000 push -u ${PUSH_URL} sft-${push_branch}
              resources:
                # Убедитесь, что ресурсов достаточно для выполнения тонкой настройки. Если требуется GPU, запросите соответствующие ресурсы GPU/vGPU.
                requests:
                  cpu: "1"
                  memory: "2Gi"
                limits:
                  cpu: "8"
                  memory: "16Gi"
                  nvidia.com/gpu: 1
              securityContext:
                allowPrivilegeEscalation: false
                capabilities:
                  drop:
                    - ALL
                runAsNonRoot: true
                seccompProfile:
                  type: RuntimeDefault

В приведённом YAML-файле перед отправкой задачи измените следующие настройки.

1. Образ: содержит зависимости, необходимые для выполнения задачи.
2. Переменные окружения: адреса исходной модели, набора данных и выходной модели для задачи:

• BASE_MODEL_URL: измените на Git URL подготовленной модели.
• DATASET_URL: измените на Git URL подготовленного набора данных identity-alauda.
• OUTPUT_MODEL_URL: создайте пустую модель в репозитории моделей для хранения выходной модели, затем укажите Git URL этой модели.

3. Необходимые ресурсы для задачи, включая:

• PVC кэша модели (опционально): PVC для хранения базовой модели (при запуске предварительного обучения можно пропустить шаг загрузки базовой модели) и набора данных. Необходимо вручную создать и указать PVC в YAML-файле выше. Используйте этот "PVC кэша модели" для ускорения нескольких экспериментов тонкой настройки на разных моделях.
• PVC рабочего пространства (обязательно): PVC и рабочий каталог, где выполняется задача. Здесь будут храниться контрольные точки и выходные файлы модели. В приведённом примере используется временный PVC, который удаляется после завершения задачи, так как выходная модель уже загружена в репозиторий моделей.
• Разделяемая память: для многокартных/распределённых задач обучения рекомендуется выделять не менее 4 Gi разделяемой памяти.
• CPU, память и GPU ресурсы, необходимые для задачи (на основе плагина GPU-устройств, развернутого в кластере).

4. Скрипт выполнения задачи:
5. Пример скрипта выше включает кэширование модели из репозитория моделей в PVC, кэширование обучающего набора данных в PVC и отправку модели в новый репозиторий моделей после тонкой настройки. Вы можете кастомизировать скрипт под свои задачи.
6. Пример скрипта использует LLaMA-Factory для запуска задачи тонкой настройки, который подходит для большинства сценариев тонкой настройки LLM.
7. Гиперпараметры: в примере гиперпараметры определены непосредственно в скрипте запуска. Вы также можете использовать переменные окружения для чтения гиперпараметров, которые могут часто изменяться, что облегчает многократный запуск и настройку.

#Примечание по использованию PVC на основе NFS

При использовании NFS в качестве PVC рабочего пространства или кэша модели необходимо выполнить следующие действия, чтобы обеспечить корректные права доступа к файловой системе на смонтированном NFS-томе:

• На всех узлах Kubernetes, которые могут использовать PVC NFS, должен быть установлен пакет nfs-utils, например, yum install -y nfs-utils.

• При создании класса хранилища NFS добавьте параметр mountPermissions: "0757", например:

  apiVersion: storage.k8s.io/v1
  kind: StorageClass
  metadata:
    name: ai-nfs
    labels:
      project.cpaas.io/name: null
      project.cpaas.io/ALL_ALL: "true"
    annotations:
      cpaas.io/display-name: ""
      cpaas.io/access-mode: ReadWriteOnce,ReadWriteMany
      cpaas.io/features: ""
  provisioner: nfs.csi.k8s.io
  parameters:
    mountPermissions: "0757"
    server: 192.168.17.28
    share: /nfs_data/int/ai
  reclaimPolicy: Delete
  volumeBindingMode: Immediate
  mountOptions:
    - hard
    - nfsvers=4.1
  driverName: ""

После завершения всех настроек откройте терминал в Notebook и выполните команду: kubectl create -f vcjob_sft.yaml для отправки VolcanoJob в кластер.

#Управление задачей

В терминале Notebook:

1. Выполните kubectl get vcjob для просмотра списка задач, затем kubectl get vcjob <имя задачи> для просмотра статуса задачи VolcanoJob.
2. Выполните kubectl get pod для просмотра статуса pod, и kubectl logs <имя pod> для просмотра логов задачи. Обратите внимание, что для распределённых задач может быть несколько pod.
3. Если pod не создаётся, выполните kubectl describe vcjob <имя задачи> или kubectl get podgroups для просмотра podgroup Volcano. Также можно проверить логи планировщика Volcano, чтобы определить, связана ли проблема с недостатком ресурсов, невозможностью монтирования PVC или другими проблемами планирования.
4. После успешного выполнения задачи тонко настроенная модель автоматически будет отправлена в репозиторий моделей. Обратите внимание, что задача автоматически создаёт ветку репозитория для push на основе времени. При использовании выходной модели обязательно выбирайте правильную версию.

Для удаления задачи выполните kubectl delete vcjob <имя задачи>.

#Отслеживание экспериментов

В приведённом примере задачи тонкой настройки мы используем LLaMA-Factory для запуска задачи и устанавливаем report_to: mlflow в конфигурации задачи. Это автоматически отправляет метрики обучения на сервер mlflow. После запуска задачи записи отслеживания экспериментов можно найти в разделе Alauda AI - Advanced - MLFlow и сравнить несколько запусков. Например, можно сравнить потери (loss) нескольких экспериментов.

#Запуск сервиса вывода с использованием тонко настроенной модели

После завершения задачи тонкой настройки модель автоматически отправляется в репозиторий моделей. Вы можете использовать тонко настроенную модель для запуска сервиса вывода и доступа к нему.

Примечание: В приведённом примере используется метод тонкой настройки LoRA. Перед загрузкой модели адаптер LoRA был объединён с исходной моделью. Это позволяет напрямую публиковать выходную модель в сервис вывода. Запуск сервиса вывода с использованием базовой модели и адаптеров НЕ поддерживается в текущей версии.

Шаги:

1. Перейдите в Alauda AI - Model Repository, найдите тонко настроенную выходную модель, перейдите в Model Info - File Management - Edit Metadata, выберите "Task Type": "Text Classification" и "Framework": "Transformers".
2. Нажмите кнопку Publish Inference API, затем выберите Custom Publishing.
3. На странице публикации сервиса вывода выберите runtime вывода vLLM (выберите vLLM с версией CUDA, поддерживаемой GPU-узлами кластера), заполните настройки хранилища, ресурсов, GPU и нажмите Publish.
4. Дождитесь полного запуска сервиса вывода, нажмите кнопку Experience в правом верхнем углу, чтобы начать диалог с моделью. (Примечание: модели с конфигурацией chat_template имеют только возможности чата.)

#Запуск на GPU, не относящихся к Nvidia

При использовании среды с GPU, не относящимся к Nvidia (например, NPU, Intel Gaudi, AMD и др.), вы можете следовать общим шагам ниже для тонкой настройки моделей, запуска задач обучения и управления ими в AML Notebook.

Примечание: Следующие шаги также применимы к предобучению LLM и традиционным сценариям ML. Это общие шаги для адаптации решения вендора под запуск на Alauda AI с использованием Notebook и VolcanoJob.

#Подготовка

1. Предварительно: драйвер GPU вендора и плагин устройства Kubernetes должны быть развернуты в кластере. Устройства должны быть доступны внутри pod, созданного Kubernetes. Примечание: необходимо знать имя ресурса GPU вендора и общее количество устройств в кластере для удобства последующей отправки задач. Например, для Huawei NPU можно запросить карту NPU с помощью: huawei.com/Ascend910:1.
2. Получите документацию и материалы решения вендора для тонкой настройки на GPU данного вендора. Обычно это включает:
3. Документацию и шаги решения. Это можно выполнить в Kubernetes или в контейнере с помощью nerdctl run.
4. Образ для запуска тонкой настройки. Например, вендор предоставляет решение тонкой настройки с использованием LLaMA-Factory и соответствующий образ LLaMA-Factory (который может быть включён в образ).
5. Модель для тонкой настройки. Обычно устройства вендора поддерживают ряд моделей. Используйте поддерживаемые модели или модели из решения вендора.
6. Данные для обучения. Используйте пример данных из документации решения вендора или создайте собственный набор данных в том же формате.
7. Команда запуска задачи и параметры. Например, решение тонкой настройки на базе LLaMA-Factory использует команду llamafactory-cli для запуска задачи и настройки параметров, включая гиперпараметры задачи, в YAML-файле.

#Проверка исходного решения вендора (опционально)

Для гарантии корректного выполнения решения вендора и уменьшения последующих проблем можно сначала полностью запустить его согласно документации вендора и убедиться, что оно работает корректно.

Этот шаг можно пропустить. Однако если позже возникнут проблемы с выполнением задачи, можно вернуться к этому шагу для проверки исходного решения.

#Преобразование решения вендора для запуска как Kubernetes Job/Deployment (опционально)

Если решение вендора уже работает как Kubernetes job/deployment/pod, этот шаг можно пропустить.

Если решение вендора использует метод запуска контейнера, например nerdctl run, можно сначала использовать простой Kubernetes job, чтобы проверить, что решение корректно работает в Kubernetes-среде с развернутым плагином устройства вендора.

Примечание: этот шаг позволяет исключить проблемы с невозможностью планирования устройств GPU вендора в volcano job, поэтому его можно проверить отдельно.

Пример:

apiVersion: batch/v1
kind: Job
metadata:
  name: custom-gpu-ft-job
spec:
  template:
    spec:
      containers:
      - name: train
        image: <Image used by the vendor to fine-tune training solutions>
        command: ["Task start command", "Parameter 1", "Parameter 2"]
      restartPolicy: Never
  # Примечание: для распределённых задач можно указать параллелизм через parallelism, completions.
  completions: 1
  parallelism: 1

#Модификация решения вендора для запуска как volcano job

Смотрите пример определения YAML ниже.

apiVersion: batch.volcano.sh/v1alpha1
kind: Job
metadata:
  generateName: vcjob-sft-
spec:
  minAvailable: 1
  schedulerName: volcano
  maxRetry: 1
  queue: default
  volumes:
    # PVC рабочего пространства, где выполняется задача (временный PVC)
    - mountPath: "/mnt/workspace"
      volumeClaim:
        accessModes: [ "ReadWriteOnce" ]
        storageClassName: "sc-topolvm"
        resources:
          requests:
            storage: 5Gi
  tasks:
    - name: "train"
      # Количество параллельных реплик. Для распределённых задач обучения можно указать replicas >= 2
      replicas: 1
      template:
        metadata:
          name: train
        spec:
          restartPolicy: Never
          # Монтирование shm устройства для предоставления разделяемой памяти, необходимой для коммуникации между несколькими картами.
          volumes:
            - emptyDir:
                medium: Memory
                # Здесь можно настроить размер используемой разделяемой памяти
                sizeLimit: 2Gi
              name: dshm
            # PVC для хранения моделей и наборов данных.
            # В распределённых задачах обучения (с >= 2 репликами) убедитесь, что используете подходящий тип хранилища для кэширования больших моделей:
            # 1. Сетевое хранилище, например NFS или Ceph: просто монтируйте сетевое хранилище. Обратите внимание, что несколько контейнеров могут одновременно обращаться к этому хранилищу, что приводит к высокой нагрузке. Кроме того, чтение больших файлов модели может быть медленнее, чем локальное чтение (в зависимости от производительности сетевого хранилища).
            # 2. Локальное хранилище, например topolvm или local-storage: используйте `kserve local model cache` для предварительного кэширования файла модели на каждом узле перед монтированием этого PVC. Задачи обучения не могут кэшировать каждый локальный PVC.
            - name: models-cache
              persistentVolumeClaim:
                claimName: sft-qwen3-volume
          containers:
            # Образ среды выполнения.
            - image: <Укажите образ, используемый решением вендора, или кастомизируйте образ на месте>
              imagePullPolicy: IfNotPresent
              name: train
              volumeMounts:
                - mountPath: /dev/shm
                  name: dshm
                - name: models-cache
                  mountPath: /mnt/models
              env:
                - name: MLFLOW_TRACKING_URI
                  value: "http://mlflow-tracking-server.aml-system.svc.cluster.local:5000"
                - name: MLFLOW_EXPERIMENT_NAME
                  value: kubeflow-admin-cpaas-io
              command:
              - bash
              - -c
              - |
                set -ex
                echo "job workers list: ${VC_WORKER_HOSTS}"
                # добавьте команды запуска задачи ниже
                # ...
              resources:
                # Убедитесь, что ресурсов достаточно для выполнения тонкой настройки. Если требуется GPU, запросите соответствующие ресурсы GPU/vGPU.
                requests:
                  cpu: "1"
                  memory: "8Gi"
                limits:
                  cpu: "8"
                  memory: "16Gi"
                  nvidia.com/gpualloc: "1"
                  nvidia.com/gpucores: "50"
                  nvidia.com/gpumem: "8192"

#Отслеживание экспериментов

Некоторые фреймворки тонкой настройки/обучения автоматически записывают прогресс эксперимента в различные сервисы отслеживания экспериментов. Например, фреймворки LLaMA-Factory и Transformers могут указывать запись прогресса в сервисы, такие как mlflow и wandb. В зависимости от вашей инфраструктуры можно настроить следующие переменные окружения:

• MLFLOW_TRACKING_URI: URL сервера отслеживания mlflow.
• MLFLOW_EXPERIMENT_NAME: имя эксперимента, обычно используется имя пространства имён. Это позволяет группировать задачи.

Фреймворк также указывает место записи. Например, LLaMA-Factory требует указания report_to: mlflow в YAML-конфигурации параметров задачи.

После начала задачи обучения соответствующую задачу можно найти в интерфейсе Alauda AI - "Advanced" - MLFlow и просмотреть кривые каждой записанной метрики в разделе "Metrics" или параметры конфигурации каждого запуска. Также можно сравнивать несколько экспериментов.

#Итог

Используя среду разработки Alauda AI Notebook, вы можете быстро отправлять задачи тонкой настройки и обучения в кластер с помощью YAML и командной строки, а также управлять статусом выполнения этих задач. Такой подход позволяет быстро разрабатывать и настраивать шаги тонкой настройки и обучения моделей, обеспечивая выполнение операций, таких как LLM SFT, выравнивание предпочтений, традиционное обучение моделей и сравнение нескольких экспериментов.