Claude Code는 하나의 프롬프트만으로 클라우드 GPU에서 모델을 학습시킬 수 있을까?

Claude Code는 사용자가 결정할 수 있는 다섯 가지 요소만 명시된다면, 단 하나의 프롬프트로도 모델을 학습시킬 수 있습니다. 이 다섯 가지 요소란 정확한 리비전의 베이스 모델, 데이터와 그 컬럼들, 언제 멈출지 시점, 비용 상한선(dollar cap), 그리고 어떤 파일을 되돌려 받을지 여부입니다. Nodus에 MCP를 통해 연결되면, Claude Code는 TrainingJob을 작성하고, 건식 실행 추정치(dry-run estimate)를 보여주며, 사용자의 승인을 기다린 후 어댑터가 디스크에 올라올 때까지 실행 과정을 따라갑니다.

이 다섯 가지 요소 중 하나라도 빠지면 에이전트가 임의로 추측하여 빈틈을 메웁니다. 저희는 Nodus 학습 문서를 검토하며 TrainingJob 건식 실행이 자체적으로 무엇을 결정하고, 무엇을 거부하는지에 주목하여 이 목록을 작성했습니다. TrainingJob은 베타 기능이므로, 복사 붙여넣기 하기 전에 현재 학습 가이드에서 필드 이름을 확인하세요.

Claude Code는 시작하기 전에 무엇을 알아야 할까?

다섯 가지 요소 각각은 TrainingJob의 특정 필드에 해당하며, 에이전트가 이를 추측할 때마다 비용이 발생합니다.

첫 프롬프트 전에 무엇을 설정해야 할까?

CLI를 설치하고, 로그인한 후, 로컬 MCP 서버를 Claude Code에 추가하세요:

pip install nodus-compute
nodus login
nodus mcp install claude

이용하는 것은 호스팅된 서버가 아니라 로컬 서버를 사용하세요. 호스팅된 서버는 노트북에 있는 파일을 읽을 수 없습니다. 로컬 서버는 프로젝트를 업로드하고, 기록된 체크섬과 각 파일을 비교하여 결과를 디스크에 저장할 수 있습니다. 이 두 가지 모두 MCP 가이드에 설명되어 있으며, 각 클라이언트에 대한 호스팅 설정은 저희 MCP 설정 게시물에서 확인할 수 있습니다.

그런 다음 데이터를 직접 Volume에 넣어주세요. 이 과정은 세 개의 명령어로 이루어지며 파일 업로드를 에이전트의 손길에서 제외합니다:

nodus create volume support-chats --size 1Gi
nodus volume put support-chats ./data/chats.jsonl /
nodus get volume support-chats    # Ready 상태가 될 때까지 대기

TrainingJob은 생성될 때 Volume의 가장 최근 커밋된 버전을 고정합니다. 만약 실행 도중에 특정 파일을 업로드하더라도, 해당 실행은 이전 버전으로 계속 훈련됩니다.

하나의 프롬프트는 어떻게 생겼나요?

프로젝트 폴더에서 Claude Code에 다음 내용을 붙여넣고 이름과 숫자를 변경하세요:

Fine-tune a model on Nodus with a TrainingJob.

- Base model: hf://Qwen/Qwen3-0.6B@c1899de289a04d12100db370d81485cdf75e47ca
...

두 줄이 보이는 것보다 더 많은 일을 합니다. TrainingJob 필드를 먼저 설명해 달라는 요청은 종류(kind)가 Beta 버전이며, 메모리에서 작동하는 에이전트는 이미 변경된 필드를 작성할 수 있기 때문에 중요합니다. 중지된 실행의 일반적인 해결책은 상한선(cap)을 높이는 것인데, 이는 에이전트가 아닌 사용자에게 지출 결정이기 때문에 '멈추고 물어봐 달라'는 요청도 중요합니다.

승인하기 전에 매니페스트는 어떻게 보여야 하나요?

거의 이와 비슷해야 합니다. 아래 모든 필드는 훈련 가이드에서 가져온 것입니다:

apiVersion: nodus.dev/v1beta1
kind: TrainingJob
metadata:
...

'예'라고 말하기 전에 네 가지를 확인하세요. 모델은 브랜치 이름이 아니라 전체 커밋 해시(commit hash)를 가지고 있어야 하며, 컬럼 이름은 파일과 일치해야 합니다. maxCostUSD가 포함되어야 합니다. 요청하지 않은 resources 블록은 없어야 합니다.

그런 다음 추정치를 읽어보세요. MCP의 경우, 첫 번째 apply 호출은 아무것도 생성하지 않는 건식 실행(dry run)과 etag를 반환합니다. CLI에서는 nodus apply -f sft.yaml --dry-run -o yaml이 동일한 검사를 수행하며, 그 status.estimate는 완료까지의 비용, 첫 번째 홀드 시간, 그리고 시작 시간을 알려줍니다.

수동으로 숫자를 확인해 볼 수 있는데, 추정치는 가장 느린 GPU 유형에서 단계(steps)에 실행 시간당 측정된 초를 곱한 값에 평가(evaluation)가 더해진 것입니다. 예를 들어 설명하자면, NVIDIA L4에서 40분으로 나옵니다. L4는 Nodus 가격 페이지에서 $0.43/hr로 책정되어 있으므로 (가격 확인일: 2026년 10월 15일), 이는 0.67시간 곱하기 $0.43, 즉 약 $0.29의 GPU 시간입니다.

$5 상한선은 재시작할 여유를 남기면서도 심각하게 잘못 진행되는 실행을 중단시킬 수 있습니다. 만약 추정치가 이 산술적 계산이 제시하는 것보다 훨씬 높다면, 승인하기 전에 에이전트에게 그 이유를 물어보세요.

'예'와 디스크의 가중치 사이에는 무엇이 일어나나요?

에이전트는 confirmed: true와 건식 실행에서 얻은 동일한 etag로 다시 apply를 호출합니다. 만약 중간에 추정치가 변경되었다면, 생성(create)은 실패하고 에이전트는 재시도하는 대신 추정치를 다시 실행하여 새로운 숫자를 보여주어야 합니다.

실행이 진행되는 동안, 에이전트는 폴링(polls)을 수행합니다. 각 wait 호출은 최대 60초 동안 차단되며, logs는 최대 2,000줄만 반환하므로, 하나의 긴 연결을 유지하기보다는 확인하는 방식으로 작동할 것으로 예상해야 합니다. get과 describe 도구가 유용합니다. 이들 사이에 진행 단계(CachingModel은 모델 가져오는 중, 그다음 Baseline, Training, 그리고 Evaluating), 단계(step), 손실(loss), 초당 토큰 수(tokens per second), 그리고 지금까지의 비용을 보여줍니다.

이 실행은 Nodus에 존재하며, 채팅창 안에 있는 것이 아닙니다. 노트북을 닫고 나중에 Claude Code를 다시 열어 상태를 문의하거나, 직접 nodus get tj -w를 실행하세요.

성공할 경우, 출력물은 최종 메트릭이 담긴 results.json, 출처(provenance)가 담긴 provenance.json, 파일별 SHA-256을 포함하는 manifest.json, 그리고 토크나이저와 함께 adapter/ 아래에 LoRA 가중치로 저장됩니다. 로컬 서버의 download_output 도구는 각 파일을 저장하고 해당 해시값과 비교합니다. CLI(Command Line Interface)와 동일한 명령어는 nodus cp tj/support-sft:outputs/results.json ./runs/support-sft/results.json입니다.

생성된 실행(run)이 완료된 것은 아닙니다. 에이전트가 출력물을 나열하기 전에 성공했다고 보고하면, results.json을 보여달라고 요청하세요.

무엇이 잘못될 수 있으며, 에이전트는 어떻게 해야 할까요?

매개변수 오류는 비용을 지불하기 전에 포착됩니다. 매개변수는 드라이 런(dry run) 시점에 런타임의 스키마와 비교되므로, learning_rate 같은 필드는 경로와 함께 거부됩니다. 올바른 대응은 새로운 이름을 만들어내는 것이 아니라 explain을 실행하여 이름을 수정하는 것입니다.

용량 제한에 도달하면 실패하는 대신 실행이 일시 중지됩니다. 용량을 높임으로써 체크포인트에서 재개할 수 있으며, 이는 오직 증가만 가능합니다:

nodus patch tj/support-sft --type merge -p '{"spec":{"maxCostUSD":"10"}}'

실패한 검증 게이트는 인프라가 아닌 데이터나 레시피를 가리킵니다. 기본값인 requireImprovement: true의 경우, 최적 체크포인트가 시작 모델의 검증 손실(validation loss)보다 minImprovement 이상 개선되지 않으면 실행은 평가에 실패합니다. 하지만 가중치는 여전히 다운로드할 수 있습니다. 에이전트가 습관적으로 더 많은 단계로 재실행하도록 내버려 두지 마세요. 먼저 데이터를 확인해야 합니다.

장비 손실(lost machine)은 시스템에서 처리해 줍니다. 복구는 옵티마이저, 스케줄러 및 RNG 상태를 포함한 전체 체크포인트를 사용하며, 단일 노드 실행은 최신 스냅샷을 복원합니다. 로그는 신뢰할 수 없는 것으로 표시되어 에이전트에게 돌아오며, Nodus는 로그 라인이 요청하더라도 에이전트의 권한을 넘어서는 도구 호출은 거부합니다. 용량 제한(caps), 예산 및 승인 설정에 대해서는 AI 에이전트가 GPU를 과다 지출하는 것을 막는 방법을 참조하세요.

이것은 Hugging Face skills나 Modal과 어떻게 다릅니까?

Hugging Face는 huggingface/skills 저장소에 huggingface-llm-trainer 스킬을 배포했습니다. 이 스킬은 에이전트에게 TRL(Transformer Reinforcement Learning) 학습 스크립트를 작성하고, 이를 Hugging Face Jobs 실행으로 제출하며, 작업 ID, 모니터링 링크 및 예상 시간을 보고하도록 가르칩니다. 해당 워크스루에서는 0.6B 모델에 대해 t4-small을 선택하고 완성된 모델을 Hub로 푸시합니다.

스킬 자체 설명서는 단일 프롬프트 실행 시 두 가지 함정을 지적합니다. 첫째, 대부분의 학습에 너무 짧은 30분 기본 시간 초과가 발생하며, 둘째, 작업 환경이 임시적이므로 Hub로 푸시하지 않는 실행 결과는 손실됩니다.

Modal 역시 스킬 방식을 채택했습니다. modal skills install을 사용하면 Modal의 스킬과 문서를 .agents/ 또는 .claude/에 복사하고, 에이전트가 Modal SDK와 CLI를 구동하게 합니다. Modal Functions는 기본적으로 300초 후에 시간 초과하며, 최대 24시간까지 설정할 수 있습니다.

Nodus에서는 에이전트가 학습 스크립트 대신 관리형 트레이너를 위한 짧은 매니페스트(manifest)를 작성합니다. 예상치는 플랫폼의 드라이 런(dry run)에서 나오며, 제한은 에이전트가 기억하는 것이 아니라 Nodus에 의해 강제됩니다.

Hugging Face 스킬은 데이터와 모델이 이미 Hub에 존재하고 Trackio 대시보드와 함께 그 결과를 다시 푸시받고 싶을 때 더 좋은 선택입니다. 만약 에이전트가 자체 학습 루프를 작성하기를 원한다면, Modal 스킬이나 순수한 Nodus Job이 어떤 관리형 런타임보다 더 적합합니다.

FAQ

에이전트가 사용할 수 있는 GPU를 제한하려면 어떻게 해야 하나요?

매니페스트의 resources.gpu.type 아래에 허용되는 유형을 나열하면 됩니다. 예를 들어 [rtx4090-24g]와 같습니다. 그러면 가장 느리게 허용한 유형을 기준으로 비용이 책정되므로, 목록을 좁게 지정할수록 더 정확한 예상치를 얻을 수 있습니다.

동일한 프롬프트가 Codex나 Cursor에서도 작동하나요?

네. 이들은 nodus mcp install codex 또는 nodus mcp install cursor로 설정된 동일한 MCP 서버를 사용합니다. 클라이언트 자체의 승인 설정만 다르고, Nodus 측(드라이 런, etag, cap)은 동일합니다.

하나의 프롬프트로 강화학습을 수행할 수 있나요?

네, Beta 버전에서 가능합니다. nodus/grpo-lora 런타임은 데이터셋 대신 nodus/[email protected]과 같은 환경(Environment)에 대해 학습합니다. Nodus는 각 완료본을 격리된 컨테이너 내에서 평가하므로, 프롬프트가 환경 이름과 학습 및 비보유 작업(held-out tasks)의 개수를 지정합니다.

이전 실행의 모델 사본으로 학습할 수 있나요?

네. TrainingJob은 고정된 리비전(revision)에 있는 볼륨(Volume) 중 하나에서 모델을 가져올 수 있으며, 이는 model: {volume: {name: my-sft-model, revision: 3}}와 같이 작성합니다. 이것이 DPO 실행이 SFT 실행의 출력물로부터 시작하는 방식입니다.

이와 유사한 가이드는 Nodus Compute 블로그에서 확인할 수 있습니다.