GRPO(Group Relative Policy Optimization)는 동일한 프롬프트에 대한 여러 답변의 점수를 매기고 모델을 그룹 평균보다 우수한 쪽으로 이동시키는 강화학습 (reinforcement learning) 방법론입니다. 따라서 별도의 비평가 모델(critic model)이 필요하지 않습니다. Nodus는 이를 관리형 런타임인 nodus/grpo-lora로 실행하여 LoRA 어댑터를 훈련하며, 기본적으로 하나의 GPU에서 작동하고 플랫폼의 모든 답변을 평가하며 사용자가 설정한 달러 한도 내에서 실행됩니다. QLoRA를 사용할 경우, 8B 모델은 가중치와 학습 가능한 상태에 약 4.5 GB만 필요하며, Nodus 프리셋은 48 GB 이상의 단일 GPU에서 이를 실행할 수 있습니다.
GRPO는 어디서 왔을까요?
GRPO는 DeepSeekMath paper에서 "Proximal Policy Optimization (PPO)의 변형"으로 소개되었으며, PPO의 메모리 사용량을 줄이는 특징도 가지고 있습니다. 해당 논문에서는 DeepSeekMath-Instruct 7B 모델을 GSM8K에서 82.9%에서 88.2%로, MATH에서 46.8%에서 51.7%로 향상시켰습니다.
이 기술은 1년 후 광범위하게 알려졌습니다. DeepSeek-R1 paper에서는 GRPO를 DeepSeek-R1-Zero와 DeepSeek-R1을 모두 훈련하는 데 사용된 강화학습 알고리즘으로 명시했으며, 보상은 최종 답변의 정확도에 기반합니다.
GRPO 훈련은 어떻게 작동하나요?
GRPO는 학습된 값 모델(learned value model)을 그룹 내 답변 간의 단순 비교로 대체합니다. 각 훈련 단계는 네 가지 작업을 수행합니다.
- 그룹 샘플링(Sample a group). 각 프롬프트에 대해 현재 모델은 G개의 완성본을 생성합니다. DeepSeekMath는 질문당 64개를 사용했으며, Hugging Face TRL의 GRPOTrainer는 기본값으로 8개, Nodus 런타임은 기본값으로 4개를 사용합니다.
- 보상 함수(reward function) 또는 보상 모델(reward model)로 각 완성본을 점수화합니다. 검증 가능한 작업의 경우 이는 일반적인 코드입니다: 최종 답변이 일치하는지, 단위 테스트가 통과하는지, 형식이 올바른지 등을 확인합니다.
- 점수를 장점(advantages)으로 변환합니다. 각 보상에서 그룹 평균을 빼고 그룹 표준 편차로 나눕니다. 해당 완성본의 모든 토큰은 동일한 장점을 얻습니다.
- PPO의 클리핑된 목적 함수(clipped objective)를 사용하여 정책(policy)을 업데이트하며, 선택적으로 모델이 고정된 참조 복사본(frozen reference copy)에 가깝게 유지되도록 하는 KL 발산 페널티(KL divergence penalty)를 추가합니다.
다음은 3단계를 구체화한 작은 예시입니다. 예를 들어 수학 프롬프트가 8개의 완성본을 얻었고 그중 3개가 정확했다면, 보상은 1, 0, 0, 1, 1, 0, 0, 0이 됩니다.
| 값 |
|---|
| 그룹 평균 | 3 / 8 = 0.375 |
| ... | |
| 라이브러리에서 표본 표준 편차(sample standard deviation)를 사용하면 약간 더 작은 숫자(0.518, 따라서 +1.21 및 −0.72)가 나옵니다. 중요한 것은 방향입니다: 정답은 강화되고, 오답은 억제되며, 크기는 각 답변이 자체 그룹 내에서 얼마나 이례적이었는지에 따라 달라집니다. | |
엣지 케이스(edge case)가 중요합니다. 만약 8개의 답변 모두가 맞거나, 8개 모두 틀렸다면, 모든 장점은 0이 되고 해당 단계는 아무것도 가르쳐주지 못합니다. 이것이 GRPO가 때때로 작업을 해결하는 기본 모델(base model)을 필요로 하는 이유입니다.
PPO 대비 GRPO의 이점은 무엇인가요?
GRPO의 주요 장점은 PPO의 값 모델(value model)을 제거한다는 점이며, 이는 대략 모델 하나 분량의 메모리와 컴퓨팅 자원을 절약해 줍니다. DeepSeekMath 저자들은 PPO의 값 함수가 “일반적으로 정책 모델과 비교할 만한 크기의 또 다른 모델”이며, 마지막 토큰만 보상을 받을 때 잘 훈련시키기 어렵다고 언급합니다. GRPO는 대신 그룹 평균을 기준선(baseline)으로 사용합니다.
두 가지 작은 차이점이 뒤따릅니다. GRPO는 KL 페널티를 보상(reward)에 통합하는 대신 손실(loss)에 직접 추가하여 어드밴티지 계산을 깔끔하게 유지합니다. 이 KL 항은 이제 종종 비활성화됩니다. TRL은 beta를 0.0으로 기본 설정하며, 0일 경우 "참조 모델(reference model)이 로드되지 않아 메모리 사용량을 줄이고 학습 속도를 향상시킵니다." DeepSeekMath는 KL 계수로 0.04를 사용했으며, TRL 문서는 DeepSeek-R1의 경우 0.001을 언급합니다.
8B 모델에 GRPO는 얼마나 많은 GPU 메모리가 필요한가요?
Qwen3-8B의 경우, LoRA를 사용한 GRPO는 활성화(activations) 및 생성 캐시(generation cache)를 제외하고 가중치와 학습 가능한 상태에 약 16.8 GB가 필요하며, QLoRA는 약 4.5 GB가 필요합니다. 이 수치는 Qwen3-8B 모델 카드 및 설정을 기반으로 계산되었습니다: 8.2B 파라미터, 36 레이어, 히든 사이즈 4,096, 차원 128의 8개 KV 헤드. 학습된 파라미터에는 혼합 정밀도 Adam(mixed-precision Adam)을 위해 ZeRO 논문에서 제시한 각 16바이트를 사용합니다.
- 고정된 16비트 기본 모델: 8.2B × 2 바이트 = 16.4 GB.
- QLoRA용 고정된 4비트 (NF4) 기본 모델: 8.2B × 0.5 바이트 = 4.1 GB, 여기에 작은 양자화 상수(quantization constants)가 추가됩니다.
- 모든 선형 레이어에 대한 Rank-8 LoRA: 레이어당, q, k, v, o, gate, up 및 down 투영을 통해 계산된 (입력 + 출력)의 합은 606,208 파라미터입니다. 이를 36개 레이어에 곱하면 21.8M 파라미터가 되며, 각 16바이트를 사용하면 0.35 GB입니다.
- 정책(policy)의 전체 미세 조정: 8.2B × 16 바이트 = 131.2 GB. KL 항을 위한 16비트 참조 모델은 16.4 GB가 추가되어 총 147.6 GB가 됩니다.
- PPO 스타일의 전체 학습 (학습된 값 모델(value model)이 정책과 동일한 크기이며 고정된 참조 및 보상 모델 포함): 131.2 × 2 + 16.4 × 2 = 295.2 GB.
생성 과정에서도 공간이 필요합니다. Qwen3-8B의 KV 캐시는 2 × 36 레이어 × 8 헤드 × 128 × 2 바이트 = 토큰당 147,456바이트입니다. 각각 1,024개의 토큰으로 구성된 8개 완료(completions) 그룹은 8,192개의 토큰을 담고 있으며, 캐시로 약 1.2 GB에 해당합니다. 활성화는 배치 크기(batch size)와 시퀀스 길이(sequence length)에 따라 달라지며, Nodus 런타임에서 기본으로 활성화되는 그래디언트 체크포인팅(gradient checkpointing)은 이를 작게 유지해 줍니다.
Memory for weights and trainable state on Qwen3-8B: PPO-style full training 295.2 GB, GRPO full with a reference model 147.6 GB, GRPO full without one 131.2 GB, GRPO with LoRA 16.8 GB, and GRPO with QLoRA 4.5 GB.
Critic을 제거하면 전체 학습(full-training)의 메모리 사용량이 절반으로 줄어듭니다. LoRA와 QLoRA를 사용하면 GRPO를 단일 GPU 카드로 구현할 수 있습니다.
이러한 추정치는 [grpo-lora runtime reference]의 프리셋과 일치합니다: Qwen3-8B 모델에 QLoRA를 적용하면 L40S, RTX A6000 또는 A100 80 GB 중 하나가 필요하며, 모두 48GB 이상이어야 합니다. 70B 모델의 경우, 동일한 계산은 [70B 모델용 VRAM 가이드]에 나와 있습니다.
GRPO 실행 과정에서 시간이 소요되는 부분은 무엇인가요?
일반적으로 생성(Generation) 단계가 가장 많은 시간을 차지합니다. 왜냐하면 그래디언트(gradient)를 계산하기 전에 매 단계마다 G개의 전체 완료본을 샘플링하기 때문입니다. 보상(reward)이 Python 검사라면 스코어링은 저렴하며, 업데이트 자체는 정책(policy) 또는 그 어댑터에 대한 일반적인 역전파(backward pass) 과정입니다.
대부분의 GRPO 스택은 전용 추론 엔진(inference engine)을 사용하여 샘플링 단계를 가속화합니다. TRL은 [두 가지 모드의 vLLM]을 지원합니다: 기본값인 colocate 모드는 vLLM이 트레이너와 GPU 메모리를 공유하며, server 모드는 vLLM이 별도의 GPU에서 실행됩니다. Colocate는 하드웨어를 절약하지만 "훈련용 GPU의 메모리 경합(memory contention)을 유발할 수 있으므로" 여유 공간을 확보해야 합니다.
DPO나 SFT 대신 GRPO를 언제 사용해야 하나요?
답변을 자동으로 스코어링할 수 있고, 기본 모델(base model)이 어느 정도의 확률로 정답을 맞힐 때 GRPO를 사용하십시오. 저희가 사용하는 규칙은 다음과 같습니다.
- 좋은 예시 출력을 가지고 있고 모델이 이를 모방하기를 원할 때 SFT(Supervised Fine-Tuning)를 사용하세요.
- 자동 검사기가 없지만 선호되는 답변과 거부된 답변 쌍을 가지고 있을 때 DPO(Direct Preference Optimization)를 사용하세요. DPO는 이러한 고정된 쌍으로부터 학습하며, DPO 논문에 따르면 미세 조정 중 모델에서 샘플링할 필요성을 제거하여 예시당 비용을 절감합니다.
- 정확성을 코드로 확인할 수 있을 때 (수학 답변, 단위 테스트, 구조화된 출력, 게임 등) GRPO를 사용하세요. 먼저 기준선(baseline)을 실행하세요. 모델이 작업에서 0% 또는 100% 점수를 받으면 모든 그룹 보상이 동일하므로 GRPO가 학습할 것이 없습니다. 대신 SFT를 먼저 수행하거나 더 어려운 작업을 선택하세요.
- 학습된 가치 함수(learned value function)가 필요할 이유가 있을 때만 전체 PPO를 사용하세요. 검증 가능한 보상의 경우, GRPO는 모델 하나 적은 것으로 동일한 정책 경사 하강법(policy-gradient training)을 제공합니다.
Nodus에서 GRPO 훈련은 어떻게 실행하나요?
Nodus에서는 실행을 nodus/grpo-lora 런타임, 모델, 환경(Environment)을 지정하는 TrainingJob으로 설명하며, Nodus는 동일한 별도 작업(held-out tasks)에 대해 기준선 평가, 훈련 및 최종 평가를 수행합니다. 트레이너가 스스로 채점하지 않습니다. 훈련 가이드에 따르면, 완료된 결과는 네트워크 접근 권한이 없는 격리된 컨테이너의 그레이더(grader)로 전송되며, 그레이더 충돌은 0점 점수가 아닌 인프라 실패로 간주됩니다.
CLI를 설치하고 로그인하세요:
$ pip install nodus-compute
$ nodus login
이것은 런타임 레퍼런스에 있는 예시 TrainingJob입니다. 이 작업은 Qwen3-0.6B 모델에 대해 그래프 색칠(graph-coloring) 환경을 사용하고 $5의 제한액으로 LoRA 어댑터를 훈련합니다:
aviapi
kind: TrainingJob
metadata: {name: my-grpo-lora}
...
이를 my-grpo-lora.yaml로 저장하세요. 드라이런(dry run)으로 가격을 책정한 다음, 실행하고, 모니터링하며, 결과를 다운로드하세요. 이 명령어들은 파일 이름만 변경된 훈련 가이드의 명령어들입니다.
$ nodus apply -f my-grpo-lora.yaml --dry-run -o yaml # status.estimate: cost to completion, first hold, start time
$ nodus apply -f my-grpo-lora.yaml
$ nodus get tj -w
...
런타임의 GRPO 설정값(knobs)은 spec.parameters 아래에 위치합니다: numGenerations (그룹 크기, 기본값 4), beta (기본값 0으로, 레퍼런스 모델을 비활성화함), maxCompletionLength (기본값 64 토큰), lora.r (기본값 8), method (LoRA, QLoRA 또는 Full), 그리고 saveSteps (기본값 25). 실행 후, status.diagnostics.rewardSignal은 모든 학습 보상이 동일했다면 경고합니다. 이는 위에서 언급된 '모두 괜찮거나(all-right)' 혹은 '모두 잘못된(all-wrong)' 경우입니다. 카탈로그 환경을 선택하는 것보다 Python으로 보상 함수를 직접 작성하고 싶다면, nodus.recipes.rl SDK 레퍼런스에 있는 rl.train이 사용자의 보상을 환경(Environment)으로 패키징하여 보여줍니다.
복구 기능은 내장되어 있습니다. 실행은 매 saveSteps마다 체크포인트를 생성하며, 중단된 후에는 상태에 저장된 기준선(baseline)을 재사용하여 기준선 평가를 반복하지 않습니다. 일반적인 패턴은 스팟 GPU 트레이닝이 선점(preemption)을 견디는 방법에서 확인할 수 있습니다.
Nodus에서 GRPO 실행 비용은 얼마인가요?
학습 단계 자체는 저렴하며, 청구서의 대부분은 몇 개의 단계와 완료(completions)가 얼마나 길지에 달려 있습니다. 런타임 레퍼런스는 건너뛰기 실행 추정치에 사용되는 단계당 초를 매일 재측정하여 게시합니다. 이 수치는 H100에서 0.45초, A100 80 GB에서 0.7초, L40S에서 1초, RTX 4090에서 1.2초, 그리고 RTX A6000에서 1.3초입니다.
Nodus 가격 책정 페이지의 GPU 요율을 곱하면 1,000개 학습 단계의 비용이 산출됩니다:
| GPU | Listed rate | 1,000 steps | Cost of 1,000 steps |
|---|
| H100 SXM 80 GB | $2.600/hr | 450 s (0.125 h) | $0.33 |
| ... | | | |
가격은 2026년 10월 26일에 확인된 것으로, Nodus 가격 책정 페이지에 시간당 공급 가격으로 기재되어 있습니다.
Cost of 1,000 GRPO training steps at the runtime's published step times: RTX 4090 $0.10, RTX A6000 $0.12, A100 80 GB $0.21, L40S $0.22, H100 $0.33.
가장 빠른 GPU가 step당 가장 저렴한 것은 아닙니다: H100은 RTX 4090보다 2.7배 빠르지만, step당 비용은 3.4배 더 많이 듭니다.
이것들을 전체 청구 금액이 아닌 학습 단계(training-step)의 기준점으로 간주하세요. 단계 시간은 사용자의 모델이나 완성 길이에서 오는 것이 아니라 런타임 자체 측정 실행 결과에서 나옵니다. 평가 과정은 GPU 시간을 추가하며, 8B QLoRA 실행에는 24 GB RTX 4090이 아닌 48 GB 프리셋 카드가 필요합니다.
드라이 런(dry run)은 어떤 비용도 청구되기 전에 실제 구성을 가격 책정하며, maxCostUSD는 설정된 한도에서 실행을 중지시킵니다. 시작 시간, 유휴 시간, 재작업 등이 더 큰 GPU의 작업당 가격에 어떻게 영향을 미치는지 알아보려면 H100 또는 B200 시간당 완료된 작업 비용을 참조하세요.
자주 묻는 질문 (FAQ)
GRPO는 보상 모델(reward model)이 필요한가요?
아니요. 각 완성 결과에 대한 점수가 필요하며, 검증 가능한 작업의 경우 답을 확인하는 간단한 함수만으로 충분합니다. DeepSeekMath는 훈련된 보상 모델을 사용했고, DeepSeek-R1은 최종 답변이 올바른지 여부를 보상했습니다.
GRPO에 어떤 그룹 크기(group size)를 사용해야 하나요?
