GPU 서버, SLURM 클러스터, NAT 뒤의 컴퓨터에서 학습하기

v2.14.0의 새 기능

이 튜토리얼은 Potato의 모델 학습을 어노테이션 서버에서 GPU가 있는 컴퓨터로 옮깁니다. 이 튜토리얼은 어노테이션 서버가 작은 클라우드 VM이나 노트북이고, GPU는 연구실 서버, 대학 클러스터, 서버가 연결할 수 없는 워크스테이션에 있는 연구 관리자를 위한 것입니다. 이 페이지는 원격 백엔드 세 가지 각각에 대해 그 백엔드를 고르는 때, 원격 컴퓨터에 설치해야 할 것, 설정, 점검 명령, 실행 중에 일어나는 일, 실행을 취소하는 방법, 가장 흔히 보게 될 실패를 다룹니다. 이 튜토리얼은 첫 모델 학습하기의 리뷰 프로젝트처럼 어노테이션 서버에서 이미 학습이 되는 프로젝트를 전제로 합니다.

실행이 돌 수 있는 네 곳

백엔드는 학습 실행이 돌아가는 곳입니다. Potato에는 어노테이션 서버의 하위 프로세스인 local 백엔드가 항상 있습니다. 다른 백엔드는 model_training.backends 아래에 이름을 붙여 지정합니다.

어노테이션 서버가 ssh 키로 GPU 컴퓨터에 로그인할 수 있으면 ssh를 고르십시오. GPU가 SLURM 스케줄러 뒤에 있고 로그인할 수 있는 컴퓨터가 로그인 노드이면 slurm을 고르십시오. 서버에서 GPU 컴퓨터로 연결을 열 수 없으면 agent를 고르십시오. 에이전트가 모든 연결을 직접 열기 때문입니다. 가정용 공유기나 캠퍼스 방화벽 뒤의 워크스테이션이 에이전트의 전형적인 경우입니다. 예측과 실행 결과는 어떤 백엔드에서든 서버에 도착하므로, 되쓰기와 홀드아웃 점수는 트레이너가 어디서 돌았든 똑같이 동작합니다. decision-calibrate를 뺀 모든 트레이너는 어느 백엔드에서든 실행됩니다.

프로젝트 설정

아래 설정은 첫 튜토리얼의 리뷰 프로젝트에 원격 백엔드 세 가지를 모두 더한 것입니다. 실제 프로젝트에는 쓰는 백엔드만 있으면 되며, 각 백엔드는 아래에 자기 절이 있습니다. max_wall_seconds: 3600은 한 시간 안에 끝나지 않은 실행을 멈춥니다. ssh나 agent 백엔드에서는 서버가 1초마다 이 한도를 확인하므로, 원격 컴퓨터에서 멈춘 실행이 한도보다 오래 실행 대기열을 붙잡지 않습니다.

annotation_task_name: "Review Sentiment"
task_dir: "."
data_files:
  - "data/reviews.json"
item_properties:
  id_key: "id"
  text_key: "text"
output_annotation_dir: "annotation_output"
admin_api_key: "change-me"
 
annotation_schemes:
  - annotation_type: "radio"
    name: "sentiment"
    description: "Is this review positive or negative?"
    labels: ["positive", "negative"]
 
model_training:
  enabled: true
  backend: gpu-server        # the default for runs; leave out to keep runs local
  max_wall_seconds: 3600
  writeback:
    schemas: ["sentiment"]
    include_unlabeled: true
    min_confidence: 0.6
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      gpus: auto
      min_free_gpu_mb: 4000
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3
      job_python: /shared/envs/train/bin/python
      remote_dir: /shared/projects/me/potato-training
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

서버를 시작하기 전에 설정을 검증하십시오.

potato validate config.yaml --strict

검증기는 백엔드 유형이 받지 않는 키, host가 없는 ssh나 slurm 백엔드, /tmp 아래에 있는 SLURM remote_dir, 어떤 백엔드도 가리키지 않는 model_training.backend를 보고합니다. 서버도 같은 오류에서 시작되지 않으므로, pyhton처럼 잘못 쓴 키는 실행을 기본 python3로 보내는 대신 시작할 때 서버를 멈춥니다.

Runs on 메뉴와 API

/admin/training의 Training 페이지에는 모든 백엔드를 유형과 호스트와 함께 나열하는 Runs on 메뉴가 있으며, 예를 들어 gpu-server (ssh to gpu.example.org)처럼 나옵니다. model_training.backend는 메뉴가 처음 선택하는 항목을 정하고, 실행 표는 Ran on 열에 각 실행이 어디서 돌았는지 기록합니다. API로 시작한 실행은 요청 본문의 backend 필드에 백엔드 이름을 적습니다.

curl -X POST -H "X-API-Key: $KEY" -H "Content-Type: application/json" \
  http://localhost:8000/admin/training/api/runs \
  -d '{"trainer": "hf-text-classification", "schemas": ["sentiment"], "backend": "cluster"}'

설정에 없는 백엔드 이름은 409로 거부됩니다. 자동 재학습은 auto_retrain.backend가 다른 백엔드를 지정하지 않으면 model_training.backend를 쓰며, auto_retrain은 루프 안의 모델에서 전부 다룹니다. 백엔드와 관계없이 실행은 한 번에 하나만 돌고, 다른 실행이 진행 중일 때 시작한 실행은 대기열에서 기다립니다.

이 컴퓨터에서 학습하기

실행을 다른 곳으로 옮기기 전에 로컬 실행이 어떤 장치를 쓰는지 확인하십시오. 기본값 device: auto에서 로컬 실행은 CUDA를 먼저, 그다음 Apple의 Metal(mps), 그다음 CPU를 쓰며, device: cuda:1은 GPU 하나를 지정합니다. 점검 명령은 로컬 실행이 쓸 장치를 출력합니다.

potato training check local config.yaml

Apple 실리콘 Mac에서 이 명령은 local: this machine, Apple Metal (mps)를 출력합니다. 요청한 장치가 없으면 CPU나 다른 가속기로 대체되며 실행 로그에 경고가 남습니다. 답이 CPU이고 트레이너가 트랜스포머를 파인튜닝한다면, 실행을 아래의 원격 백엔드로 옮기십시오. 로컬 실행의 device, num_threads, max_ram_mb는 설정에 나열되어 있습니다.

ssh로 연결한 GPU 서버

ssh 백엔드는 어노테이션 서버가 ssh로 닿을 수 있는 컴퓨터, 보통 연구실 GPU 서버에서 트레이너를 실행합니다. Potato가 원격 쪽의 모든 것을 직접 시작하므로, Python과 트레이너의 패키지 외에는 그곳에 직접 설치하거나 시작할 것이 없습니다. Potato는 첫 실행 때 자신의 Python 소스를 호스트에 복사하고 소스가 바뀔 때까지 그 복사본을 다시 쓰므로, GPU 호스트에는 Potato를 설치하지 않아도 됩니다.

ssh 백엔드의 요구 사항

어노테이션 서버가 실행되는 계정에는 프롬프트 없이 GPU 호스트에 로그인되는 ssh 키가 필요합니다. Potato는 BatchMode=yes로 ssh를 실행하므로, 비밀번호 프롬프트가 뜨면 실행이 멈추지 않고 곧바로 실패합니다. 그 계정으로 ssh gpu.example.org true가 성공해야 하며, 암호가 걸린 키도 ssh-agent가 키를 갖고 있으면 동작합니다. host 값은 ssh가 받아들이는 어떤 이름이든 되며, ~/.ssh/config의 별칭도 동작합니다. user, port, identity_file 키는 ssh에 각각 -l, -p, -i로 전달됩니다.

GPU 호스트에는 Python 3.8 이상과 실행하는 트레이너의 패키지가 필요합니다. hf-text-classification의 패키지는 torch, transformers, peft이며, potato-annotation[train-text] 엑스트라의 내용입니다. 모든 트레이너의 설치 방법은 트레이너 페이지에 있습니다. 호스트의 인터프리터에 패키지가 없으면 python이 패키지가 있는 인터프리터를 가리키게 하거나, 패키지를 packages 아래에 나열하십시오. packages를 지정하면 Potato는 remote_dir 아래에 --system-site-packages로 가상 환경을 만들고 나열된 패키지를 한 번 설치합니다. 호스트 자체의 CUDA용 torch 빌드는 가상 환경 안에서도 그대로 보입니다.

model_training:
  enabled: true
  backends:
    gpu-server:
      type: ssh
      host: gpu.example.org
      python: /opt/conda/bin/python3
      packages: ["transformers>=4.46.0", "peft>=0.13.0"]
      gpus: auto
      min_free_gpu_mb: 4000
      num_threads: 8

gpus: auto에서 각 실행은 여유 메모리가 가장 많은 GPU를 잡고, min_free_gpu_mb(기본값 2000)만큼 여유가 있는 GPU가 없으면 시작을 거부합니다. 공유 서버에서는 사용률이 낮은 카드도 여유 메모리가 적을 수 있으므로 Potato는 사용률이 아니라 여유 메모리를 비교합니다. min_free_gpu_mb는 트레이너에 필요한 메모리에 가깝게 지정하십시오. gpus: "1"은 GPU 1을 고정하고, "0,1"은 GPU 두 개를 고정하며, gpus: none은 CPU에서 학습합니다. GPU가 전혀 없는 호스트도 auto에서는 CPU로 학습합니다. num_threads는 실행의 OMP_NUM_THREADS, MKL_NUM_THREADS, OPENBLAS_NUM_THREADS를 설정합니다. 일부 공유 서버는 로그인 셸에서 OMP_NUM_THREADS=1을 설정하는데, num_threads가 로그인 셸의 값을 덮어씁니다.

ssh 백엔드의 점검 명령

점검은 어노테이션 서버에서, 서버가 실행되는 계정으로 실행하십시오.

potato training check gpu-server config.yaml

이 명령은 연결한 뒤 원격 Python 버전, 여유 메모리와 사용률이 포함된 모든 GPU, 실행이 잡을 GPU, 원격 인터프리터에 없는 학습 패키지를 보고합니다. 설치된 torch에 커널이 없는 GPU에는 (torch there has no kernels for it)가 표시되며, gpus: auto는 그런 GPU를 건너뜁니다. --json은 같은 보고서를 JSON으로 출력합니다. 명령은 실행을 시작할 수 있으면 0으로, 아니면 1로 종료합니다. Runs on 메뉴 옆의 Check 버튼은 Training 페이지에서 같은 점검을 실행합니다.

ssh 실행의 단계

각 실행마다 Potato는 다음 단계를 수행합니다.

1. ssh로 연결하고, 원격 /tmp의 유닉스 소켓에서 어노테이션 서버로 되돌아가는 역방향 포워드를 엽니다.
2. 인터프리터를 확인하고 nvidia-smi를 읽어 GPU를 고릅니다.
3. 호스트에 해당 버전이 없으면 Potato의 소스를 remote_dir/code/<hash>로 복사하고, packages가 설정되어 있는데 가상 환경이 없으면 가상 환경을 만듭니다. remote_dir의 기본값은 ~/.cache/potato-training입니다.
4. 실행을 위해 python -m potato.training.agent를 시작합니다. 실행의 토큰은 stdin으로 에이전트에 전달되며 명령줄에는 나타나지 않습니다. 공유 서버에서는 모든 계정이 명령줄을 볼 수 있기 때문입니다.
5. 에이전트는 실행의 항목, 레이블, 미디어 번들을 내려받습니다. 에이전트는 로컬 백엔드가 실행하는 것과 같은 학습 워커를 실행하고, 진행 상황, 예측, 결과를 소켓으로 돌려보냅니다.
6. 실행이 성공하면 Potato는 아티팩트 디렉터리를 실행의 artifacts/로 복사해 오고, 원격 작업 디렉터리를 삭제하고, 연결을 닫습니다.

Training 페이지의 단계 줄은 이 단계를 따라가며, 예를 들어 copying Potato's code to gpu.example.org와 waiting for the agent on gpu.example.org가 나옵니다. 실행 로그에는 호스트의 Python과 실행이 잡은 GPU가 적힙니다.

전체 파인튜닝은 모델 전체를 복사해 오며, 느린 연결에서 330 MB 모델은 몇 분이 걸립니다. 단계 줄은 모델이 얼마나 도착했는지 보여 줍니다. max_artifact_mb(기본값 2048)보다 큰 파일은 GPU 호스트에 남으며 실행 로그에 이름이 적힙니다. fetch_artifacts: false는 모든 모델 파일을 GPU 호스트에 남기고, keep_remote: true는 원격 작업 디렉터리를 점검용으로 남깁니다. 실행 페이지의 Hugging Face Hub 게시에는 어노테이션 서버에 모델 파일이 있어야 하므로, GPU 호스트에 남은 모델은 실행 페이지에서 게시되지 않습니다.

유닉스 소켓은 모드 0600으로 만들어지므로, Potato가 로그인한 계정만 소켓으로 연결할 수 있습니다. 소켓을 거친 요청은 어노테이션 서버에 루프백 요청으로 도착합니다. debug: true로 시작한 서버는 루프백 요청에 관리자 권한을 줍니다. 그러면 실행이 진행되는 동안 GPU 호스트에서 그 계정을 쓸 수 있는 누구나 디버그 서버의 관리자 권한을 갖게 됩니다. ssh로 학습하는 서버에서는 debug를 꺼 두십시오.

취소와 하트비트 타임아웃

Training 페이지의 Cancel run은 에이전트의 다음 진행 보고에 대한 응답으로 소켓을 통해 에이전트에 전달됩니다. 에이전트는 워커에 SIGTERM을 보내고, 서버가 작업과 함께 보내는 model_training.grace_seconds(기본값 20)가 지난 뒤에도 워커가 돌고 있으면 SIGKILL을 보냅니다. 이전 Potato 서버의 작업에는 grace_seconds가 없으며, 그러면 에이전트는 20초를 기다립니다. 서버에서는 grace_seconds가 지나면 실행이 취소됨으로 끝나고, 서버는 에이전트의 ssh 세션을 닫습니다. 에이전트가 heartbeat_timeout_s(기본값 120) 동안 아무것도 보내지 않은 실행은 실패하며, 실행 디렉터리의 agent.log에 에이전트의 마지막 출력이 들어 있습니다.

SLURM 클러스터

slurm 백엔드는 GPU가 SLURM 스케줄러 뒤에 있는 클러스터용입니다. 그런 클러스터에서 Potato가 ssh로 닿을 수 있는 컴퓨터는 GPU가 없는 로그인 노드이고, 컴퓨트 노드는 Potato에 아예 닿을 수 없습니다. 그래서 Potato는 ssh 백엔드처럼 로그인 노드에서 에이전트를 시작하고, 에이전트는 학습 워커만 sbatch로 컴퓨트 노드에 제출합니다. 진행 상황은 로그인 노드와 컴퓨트 노드가 공유하는 저장소의 파일을 통해 돌아옵니다.

SLURM 백엔드의 요구 사항

로그인 노드에는 ssh 백엔드의 호스트와 마찬가지로 프롬프트 없는 ssh 키와 에이전트를 위한 Python 3.8 이상이 필요합니다. 로그인 노드에는 PATH에 sbatch, squeue, scancel도 있어야 합니다. 에이전트는 클러스터에 그 명령이 있으면 scontrol도 호출합니다. Potato는 srun이나 sacct를 호출하지 않으므로, srun이 비활성화되어 있고 회계 데이터베이스가 없는 클러스터에서도 동작합니다. remote_dir은 필수이며, 작업이 그곳에서 번들을 읽고 모델을 쓰므로 컴퓨트 노드가 공유하는 저장소에 있어야 합니다. /tmp나 /var/tmp는 각 노드의 로컬 디렉터리이므로, remote_dir이 그 아래에 있으면 검증기가 오류를 보고합니다.

컴퓨트 노드에는 job_python이 가리키는, 트레이너의 패키지가 있는 인터프리터가 필요합니다. 로그인 노드에서 만든 가상 환경이 컴퓨트 노드에서 실행되지 않을 수 있으므로 SLURM 백엔드는 packages를 지원하지 않습니다. job_python은 컴퓨트 노드에 있는 환경을 가리키게 하고, 모듈 로드나 환경 활성화는 prelude에 넣으십시오.

model_training:
  enabled: true
  backends:
    cluster:
      type: slurm
      host: login.cluster.example.org
      python: /opt/conda/bin/python3                    # on the login node, for the agent
      job_python: /shared/envs/train/bin/python         # on the compute nodes, for the worker
      remote_dir: /shared/projects/me/potato-training   # storage the compute nodes share
      partition: gpu
      gres: gpu:1
      time: "04:00:00"
      prelude: ["module load cuda/12.4"]

gpus와 packages를 뺀 모든 ssh 키가 SLURM 백엔드에도 적용됩니다. GPU는 gres로 받으며, 스케줄러가 배정한 GPU에 대해 CUDA_VISIBLE_DEVICES를 설정합니다. gres가 없는 작업은 GPU를 받지 못합니다. SLURM 설정은 sbatch 플래그에 대응합니다.

time이 6시간을 넘으면 potato validate와 서버 시작이 model_training.backends.cluster.time is 12:00:00. A job that holds a GPU for more than 6 hours is long on a shared cluster; check its policy를 보고하며, potato validate --strict는 이 경고에서 실패합니다. 클러스터 정책이 더 긴 작업을 허용하면, potato validate만 읽는 최상위 validation 블록에서 그 백엔드 하나에 대해 경고를 확인 처리하십시오.

validation:
  acknowledge:
    - "model_training.backends.cluster.time is"

각 항목은 경고 문구와 대소문자를 구분하는 12자 이상의 부분 문자열로 대조되며, 일치한 경고는 확인된 목록으로 옮겨지고 더는 --strict를 실패시키지 않습니다. 백엔드 이름이 들어간 항목은 그 백엔드의 경고만 확인 처리합니다. 너무 짧거나 어떤 경고와도 일치하지 않는 항목은 그 자체로 경고가 됩니다.

SLURM 백엔드의 점검 명령

potato training check cluster config.yaml

점검은 로그인 노드에 로그인해 sbatch, squeue, scancel이 PATH에 있는지와 remote_dir이 /tmp 아래에 있지 않은지 확인합니다. 보고서에는 로그인 노드의 Python 버전과 작업이 실행할 job_python이 나옵니다. 점검은 컴퓨트 노드에 어떤 패키지가 있는지 볼 수 없으므로, 컴퓨트 노드에 패키지가 없으면 실행 로그에 import 오류가 담긴 실패한 실행으로 나타납니다. 이런 문제를 일찍 찾으려면 작은 time으로 짧은 첫 작업을 돌려 보십시오.

SLURM 실행의 단계

Potato는 ssh 백엔드와 마찬가지로 로그인 노드에 연결해 코드를 복사합니다. 그다음 에이전트가 다음 단계를 수행합니다.

1. 번들을 remote_dir/jobs/<run>/으로 내려받습니다.
2. job.sh를 쓰고 sbatch --parsable로 스크립트를 제출합니다. 실행 로그에는 작업 ID와 플래그가 담긴 Submitted SLURM job이 기록됩니다.
3. 작업 디렉터리에서 컴퓨트 노드의 워커는 이벤트를 events.jsonl에, 오류를 stderr.log에, 종료 코드를 exit_code에 씁니다. SLURM 자체의 출력은 slurm.out으로 갑니다.
4. 에이전트는 events.jsonl이 커지는 대로 읽어 진행 상황을 서버로 중계합니다. 에이전트는 poll_interval_s마다 한 번 squeue를 실행하며, 실행 로그에는 작업의 대기열 상태가 바뀔 때마다 기록됩니다. 예를 들어 SLURM job 4242: PENDING (Priority)에 이어 RUNNING on node07이 나옵니다.
5. 작업이 끝나면 에이전트는 예측을 업로드하고 결과를 보고합니다. ssh 백엔드와 마찬가지로 아티팩트는 서버로 돌아오고 작업 디렉터리는 삭제됩니다.

Cancel run은 작업에 scancel --full --signal=TERM을 보내고, 워커가 멈추지 않았으면 일반 scancel을 보냅니다. 로그인 노드로의 ssh 세션이 끊어지면 에이전트는 자기 작업을 취소하고 GPU 할당이 풀립니다. 스케줄러가 직접 작업을 끝내면, 실행은 scontrol show job이나 slurm.out에서 읽은 스케줄러의 이유와 함께 실패합니다. Potato가 보고하는 이유에는 시간 제한, 노드 장애, 선점, 메모리 부족, Potato 밖에서 온 scancel이 있습니다.

Potato의 테스트 스위트는 sbatch, squeue, scancel의 대역을 상대로 SLURM 절차를 실행하며, 작업 제출, 대기열 상태, 진행 상황 중계, 취소를 다룹니다. 파티션 제한과 선점 정책은 클러스터마다 다르므로, 새 클러스터에서의 첫 작업은 실행 로그를 지켜보십시오.

서버에 닿을 수 있는 로그인 노드에서 직접 시작한 에이전트도 potato training agent --server ... --backend <name> --workdir <shared dir> --slurm-config slurm.json으로 SLURM에 제출할 수 있습니다. slurm.json 파일에는 위 표의 설정이 JSON 객체로 들어 있으며, --workdir은 컴퓨트 노드가 공유하는 저장소에 있어야 합니다.

Potato가 닿을 수 없는 컴퓨터

agent 백엔드는 NAT 뒤의 워크스테이션처럼 어노테이션 서버가 연결할 수 없는 컴퓨터용입니다. 누군가 그 컴퓨터에서 potato training agent를 시작하면 에이전트가 서버에 작업이 있는지 폴링합니다. 에이전트가 모든 연결을 직접 열기 때문에 인바운드 포트는 필요 없습니다. 취소는 에이전트의 다음 진행 보고에 대한 서버의 응답으로 에이전트에 전달됩니다. 모델 파일은 학습 컴퓨터에 남고, 예측과 결과만 돌아옵니다.

agent 백엔드의 요구 사항

학습 컴퓨터에는 Potato, 실행하는 트레이너의 패키지, 어노테이션 서버 URL로 가는 네트워크 경로가 필요합니다. hf-text-classification에서는 설치 한 번으로 Potato와 트레이너의 패키지가 모두 갖춰집니다.

pip install "potato-annotation[train-text]"

서버에는 백엔드 항목만 있으면 됩니다. agent 백엔드는 type, description, heartbeat_timeout_s(기본값 120), queue_timeout_s만 받으며 다른 키는 받지 않습니다.

model_training:
  enabled: true
  backends:
    lab-workstation:
      type: agent
      queue_timeout_s: 3600

에이전트 등록과 시작

어노테이션 서버에서 백엔드용 토큰을 발급합니다.

potato training register lab-workstation config.yaml

이 명령은 토큰을 한 번만 출력하며, 학습 컴퓨터에서 실행할 명령도 함께 보여 줍니다.

Token for backend 'lab-workstation' (shown once; registering again replaces it):
 
  <token>
 
On the training machine:
 
  export POTATO_TRAINING_TOKEN=<token>
  potato training agent --server http://<this-server>:8000 --backend lab-workstation

학습 컴퓨터에서 서버의 실제 URL로 에이전트를 시작합니다.

export POTATO_TRAINING_TOKEN=<the token>
potato training agent --server https://annotate.example.org --backend lab-workstation

에이전트는 사용자가 멈출 때까지 자기 백엔드의 작업을 실행합니다. --token-file은 POTATO_TRAINING_TOKEN 대신 파일에서 토큰을 읽고, --python은 학습 워커가 실행되는 인터프리터를 지정하며 기본값은 에이전트 자신의 인터프리터입니다. --once는 작업 하나를 마치고 종료하고, --workdir은 에이전트의 파일을 ~/.cache/potato-training에서 옮기며, --keep은 각 작업의 번들을 남깁니다. 같은 이름을 다시 등록하면 새 토큰이 발급되고 이전 토큰은 무효가 됩니다.

potato training check lab-workstation config.yaml은 백엔드의 토큰 기록을 출력하며, 에이전트가 한 번 연결하면 last_seen이 설정됩니다. 등록 전에는 이 명령이 no token issued yet와 실행할 register 명령을 출력합니다.

agent 실행의 단계

agent 백엔드의 실행은 에이전트가 작업을 요청할 때까지 queued 상태로 기다립니다. queue_timeout_s: 3600이면 에이전트가 없는 채로 한 시간이 지나 실행이 실패하고, queue_timeout_s가 없으면 실행은 사용자가 취소할 때까지 기다립니다. 에이전트는 번들을 tar.gz 파일로 내려받고, 끊긴 다운로드는 멈춘 지점에서 최대 다섯 번까지 이어받습니다. 그다음 에이전트는 워커를 실행하고, 진행 상황을 게시하고, predictions.jsonl을 업로드하고, 종료 코드를 보고합니다. 서버는 max_predictions_mb(기본값 512)보다 큰 예측 파일에 413으로 응답합니다.

모델 파일은 --workdir 아래의 학습 컴퓨터에 남고, 실행 기록의 artifact_uri가 호스트와 디렉터리를 가리킵니다. 실행 중에 에이전트가 300초 동안 서버에 닿지 못하면 에이전트는 실행을 직접 취소합니다. 에이전트가 heartbeat_timeout_s 동안 아무것도 보내지 않은 실행은 서버에서 No word from the agent on lab-workstation for 120 seconds와 함께 실패합니다.

흔한 실패

각 항목은 실행 로그나 점검 보고서의 메시지를 먼저 적고 해결 방법을 적습니다. 모든 백엔드와 트레이너의 전체 목록은 업스트림 문제 해결 섹션에 있습니다.

• ssh to gpu.example.org failed: Permission denied. Potato에는 프롬프트 없이 동작하는 키가 필요합니다. 서버의 계정에서 ssh gpu.example.org true가 성공해야 합니다.
• /opt/conda/bin/python3 was not found on gpu.example.org. 백엔드의 python을 호스트에 있는 인터프리터로 지정하십시오.
• No GPU has 4000 MB free. 호스트의 모든 GPU가 min_free_gpu_mb가 허용하는 것보다 바쁩니다. potato training check gpu-server config.yaml이 GPU를 나열합니다. 기다리거나, 임계값을 낮추거나, gpus: "1"로 GPU를 고정하십시오.
• Trainer 'hf-text-classification' could not be imported. 원격 인터프리터에 트레이너에 필요한 패키지가 없습니다. python이 패키지가 있는 인터프리터를 가리키게 하거나 패키지를 packages 아래에 나열하십시오. SLURM 백엔드에서는 job_python이 가리키는 환경을 고치십시오.
• This host's torch has no kernels for any of its GPUs. 원격 torch가 호스트에 있는 것보다 새로운 GPU용으로 빌드되었습니다. 그 GPU용 torch 빌드를 설치하거나 다른 호스트를 쓰십시오.
• No word from the agent on gpu-server for 120 seconds. 원격 컴퓨터나 네트워크가 사라졌습니다. ssh 백엔드에서는 실행 디렉터리의 agent.log에 에이전트의 마지막 출력이 있습니다.
• The copy from gpu.example.org sent nothing for 180 s. 모델을 복사해 오는 동안 호스트로의 네트워크가 멈췄습니다. 실행의 예측은 이미 저장되어 있으며, artifacts/에는 모델 파일만 빠져 있습니다.
• login.cluster.example.org has no sbatch on PATH, so it cannot submit jobs. host가 클러스터의 로그인 노드가 아니거나, 명령이 로그인 셸만 설정하는 PATH에 있습니다. 백엔드의 env 아래에 PATH를 설정하십시오.
• SLURM job 4242 ended before the worker finished: it reached its time limit. 백엔드의 time을 늘리거나 더 적은 항목으로 학습하십시오. 다른 스케줄러 실패 후에 slurm.out을 읽으려면 keep_remote: true를 설정해 보존하십시오.
• agent 백엔드의 실행이 대기열에 머뭅니다. 그 백엔드 이름으로 폴링하는 에이전트가 없습니다. potato training agent --backend lab-workstation으로 에이전트를 시작하고, Training 페이지의 Check로 토큰을 확인하십시오.
• nvrtc: error: failed to open libnvrtc-builtins.so.13.0. 호스트의 torch와 nvidia-cuda-nvrtc 패키지가 서로 다른 CUDA 버전용입니다. torch 빌드와 일치하는 nvidia-cuda-nvrtc를 설치하거나 python이 다른 인터프리터를 가리키게 하십시오.

더 읽어보기

• 모델 학습 개요는 Training 페이지, 학습 루프, Hugging Face Hub에 모델 게시하기를 다룹니다.
• 설정에는 모든 model_training 키, 홀드아웃 점수, 실행이 저장되는 위치가 나열되어 있습니다.
• LLM 파인튜닝은 원격 GPU가 가장 자주 필요한 트레이너를 LoRA와 4비트 기반 가중치와 함께 다룹니다.
• 실행이 돌아가는 곳에 대한 업스트림 레퍼런스에는 백엔드별 전체 키 표가 있고, 에이전트 프로토콜 섹션은 직접 에이전트를 만드는 사람을 위해 경로를 문서화합니다.