핵심 요약
- Reshard는 학습 GPU의 최신 가중치를 추론 GPU로 옮길 때 각 GPU에 필요한 조각만 직접 전달합니다.
- NVIDIA의 NeMo RL 실험에서 H100과 GB200 시스템의 가중치 갱신(Refit) 구간이 기존 방식보다 약 2.7~5.7배 빨라졌으며, 이 배속은 전체 강화 학습 시간의 개선율과 구분해야 합니다.
- 현재 지원 대상은 Megatron 학습과 vLLM 또는 Megatron 생성을 별도 GPU에 배치한 NeMo RL 구성이며, 정밀도와 병렬 배치 제약을 확인해야 합니다.
Reshard 소개
Reshard는 서로 다른 GPU 배치 사이에서 필요한 텐서 조각을 직접 옮기는 집단 통신(Collective Communication) 연산입니다.
대규모 언어 모델의 강화 학습에서는 학습한 가중치를 응답 생성용 GPU로 반복해서 전달해야 하는데, Reshard는 이때 불필요하게 전송하는 데이터를 줄입니다.
NVIDIA는 2026년 11월 6일 공개한 기술 블로그에서 이 연산의 설계와 NeMo RL 적용 결과를 소개했습니다.
학습 GPU와 추론(Inference) GPU가 서로 다른 수의 GPU를 사용하거나 가중치를 다른 방향으로 나눠 보관해도, 각 목적지에 필요한 부분을 계산해 전달하는 방식입니다.
공개 참조 구현인 NCCL M2N Reshard는 NVIDIA Collective Communications Library(NCCL)를 기반으로 동작합니다.
학습한 가중치를 추론 GPU에 반복해서 전달해야 하는 이유
학습과 응답 생성은 같은 모델을 다른 방식으로 실행합니다
강화 학습(Reinforcement Learning, RL) 기반의 사후 학습(Post-training) 에서는 현재 정책 모델이 생성한 응답을 평가하고, 그 결과로 모델을 업데이트합니다.
응답 생성에 사용한 모델과 학습으로 갱신한 모델의 가중치를 연결하는 절차가 필요합니다.
학습 측의 최신 가중치를 추론 측으로 전달해 갱신하는 작업을 리핏(Refit) 이라고 합니다.
NeMo RL의 리핏 가이드에서는 학습과 생성을 같은 GPU에 배치하는 방식과 별도 GPU에 배치하는 방식을 구분합니다.
별도 자원을 사용하는 분리 배치(Disaggregated Setup) 에서는 학습과 생성이 서로 다른 GPU에 가중치를 보관합니다.
학습으로 갱신한 가중치를 생성 측의 배치에 맞게 전달해야 합니다.
리핏이 오래 걸리면 새로운 정책을 추론 측에 반영하는 데에도 시간이 필요합니다.
대규모 RL 시스템의 구성은 커뮤니티의 Miles 소개 글에서도 함께 살펴볼 수 있습니다.
이번 NVIDIA 글은 그중에서도 학습과 추론 사이의 가중치 이동을 다룹니다.
GPU 수가 같아도 가중치의 배치는 다를 수 있습니다
분산 실행에서 샤드(Shard) 는 전체 텐서를 나눈 조각을 뜻합니다.
어느 GPU가 어떤 조각을 보관하는지는 사용하는 병렬화 방식에 따라 달라집니다.
학습 측은 학습 연산과 메모리 사용량에 맞춰, 추론 측은 응답 생성에 맞춰 배치를 선택합니다.
원문 성능 표에 등장하는 병렬화 약어는 다음과 같습니다.
| 표기 | 이름 | 가중치 배치를 이해할 때의 의미 |
|---|---|---|
| TP | 텐서 병렬화(Tensor Parallelism) | 한 연산의 가중치 텐서를 여러 GPU에 나눕니다. |
| PP | 파이프라인 병렬화(Pipeline Parallelism) | 모델의 층을 여러 실행 단계에 나눕니다. |
| EP | 전문가 병렬화(Expert Parallelism) | 전문가 혼합 모델의 전문가들을 나눠 배치합니다. |
| DP | 데이터 병렬화(Data Parallelism) | 같은 모델 가중치를 사용하는 복제본을 둡니다. |
이처럼 학습 측의 조각 경계가 추론 측에서 필요한 경계와 일치하지 않을 수 있습니다.
한 목적지 GPU가 여러 출발지의 조각을 받아야 하고, 한 출발지의 조각을 여러 목적지에 나눠 보내야 할 수도 있습니다.
같은 가중치의 복제본까지 있으면 전송 경로를 결정하는 문제가 더 복잡해집니다.
리핏과 병렬화 더 알아보기
NeMo RL의 전송 방식 선택 가이드
전체 텐서를 모았다가 보내면 필요 없는 데이터도 이동합니다
기존의 일반적인 리핏은 전체 수집 후 방송(Gather-and-broadcast) 방식입니다.
학습 GPU들이 가진 조각을 모아 완전한 파라미터 텐서를 만든 뒤, 추론 GPU에 전달합니다.
각 추론 GPU는 받은 전체 텐서에서 자신에게 필요한 조각을 남깁니다.
이 방식은 서로 다른 배치를 연결하기 쉽습니다.
중간에 완전한 텐서가 있으므로, 목적지의 분할 방법에 맞춰 다시 나누면 됩니다.
그러나 일부 열만 필요한 GPU에도 전체 텐서를 전달한다면, 그 GPU가 사용하지 않을 데이터까지 이동합니다.
원문에서는 전체 수집(All-gather)과 방송(Broadcast) 두 단계를 합친 논리적 전송량을 모델 가중치 크기의 약 두 배로 추산했습니다.
아래 값은 파라미터당 2바이트인 BF16(BFloat16)을 가정한 원문의 추정치입니다.
TB는 십진 단위이며, 실제 네트워크 인터페이스에서 측정한 총 바이트 수와는 구분해야 합니다.
| 모델 | BF16 가중치 크기 추정 | 두 단계의 논리적 전송량 추정 |
|---|---|---|
| Kimi K3 | 5.6 TB | 약 11.2 TB |
| Qwen 3.8 2.4T A95B | 4.8 TB | 약 9.6 TB |
전송량의 출발점은 모델의 전체 가중치 크기입니다.
모델이 커질수록 사용하지 않을 부분까지 반복 전송하는 비용도 커집니다.
NVIDIA는 이 문제를 해결하기 위해, 출발지와 목적지의 조각이 겹치는 부분만 전달하도록 리핏을 다시 정의했습니다.
기존 집단 통신 더 알아보기
NCCL 집단 통신 연산의 의미
DTensor로 배치를 표현하면 필요한 조각을 계산할 수 있습니다
전체 모양과 GPU 배치를 함께 기술합니다
PyTorch의 분산 텐서(DTensor, Distributed Tensor)는 여러 GPU에 나눠 놓거나 복제한 텐서를 표현하는 추상화입니다.
텐서의 전체 모양과 GPU의 논리적 배열, 메시의 각 차원에서 텐서를 분할하거나 복제하는 방식을 함께 기술합니다.
GPU의 논리적 배열은 디바이스 메시(Device Mesh), 분할과 복제 방식은 배치 명세(Placement) 로 표현합니다.
예를 들어 전체 행렬의 모양만 알아서는 어느 GPU가 어떤 데이터를 보내야 하는지 결정할 수 없습니다.
학습 측이 행을 기준으로 나눴는지, 추론 측이 열을 기준으로 나눴는지까지 알아야 합니다.
DTensor의 배치 정보는 이 두 설명을 같은 형태로 전달하는 데 사용됩니다.
Reshard는 출발지와 목적지의 명세를 받아 각 샤드가 겹치는 영역을 계산합니다.
이렇게 조각의 배치를 바꾸는 작업을 재분할(Resharding) 이라고 합니다.
응용 프로그램이 개별 송수신을 모두 작성하는 대신, 라이브러리에 원하는 재분할을 요청하는 구조입니다.
8×8 행렬을 두 학습 GPU에서 네 추론 GPU로 옮기는 예
원문의 첫 번째 도식에서는 8×8 가중치 행렬을 학습 GPU 두 개가 행 방향으로 나눠 보관합니다.
각 학습 GPU가 가진 조각은 4×8입니다.
반면 추론 GPU 네 개는 열 방향으로 나누므로, 각 GPU에 8×2 조각이 필요합니다.
출처: NVIDIA 원문 Figure 1.
각 추론 GPU는 첫 학습 GPU에서 4×2, 두 번째 학습 GPU에서 4×2를 받으면 됩니다.
두 조각을 합치면 자신에게 필요한 8×2 조각이 완성됩니다.
어느 추론 GPU도 완전한 8×8 행렬을 받을 필요가 없습니다.
복제본이 없는 이 예에서 목적지 네 개가 받는 데이터는 총 64개 원소입니다.
이는 8×8 행렬의 원소 수와 같습니다.
이 계산은 도식의 크기에서 도출한 설명이며, 별도로 측정한 성능 수치는 아닙니다.
추상화와 공개 구현의 지원 범위는 구분해야 합니다
NCCL M2N README는 서로 겹치지 않는 두 GPU 프로세스 그룹 사이의 재분할을 설명합니다.
M은 출발지 GPU 수, N은 목적지 GPU 수를 뜻하며, 두 수가 같을 필요는 없습니다.
두 그룹은 같은 논리적 텐서를 서로 다른 배치로 보관합니다.
원문의 두 번째 도식은 네 GPU에 열 방향으로 나눈 가중치를 네 추론 GPU의 복제본으로 전달하는 예입니다.
출발지와 목적지의 로컬 버퍼, 메시, 배치 명세, 공통 통신 그룹을 인자로 전달합니다.
출처: NVIDIA 원문 Figure 2.
현재 공개 C API 문서는 1~2차원 메시와 1~3차원 텐서, 각 그룹 내부에서 모양이 같고 메모리상 연속적인 로컬 타일을 지원 범위로 명시합니다.
출발지와 목적지의 전체 텐서 모양은 같아야 하지만, 로컬 타일 모양은 두 그룹 사이에서 서로 달라도 됩니다.
따라서 임의의 배치를 표현한다는 개념 설명을, 모든 텐서 모양과 모든 메모리 배치를 즉시 지원한다는 의미로 확대해서는 안 됩니다.
DTensor와 Reshard 더 알아보기
PyTorch DTensor 공식 문서
NCCL M2N 공개 인터페이스와 배치 명세
복제본은 네트워크로 중복 전송하지 않고 NVLink로 완성합니다
필요한 조각을 계산한 뒤에도 복제본에 같은 데이터를 반복해서 보내면 네트워크 트래픽이 늘어납니다.
NCCL M2N Reshard는 NVIDIA NVLink로 연결된 GPU 그룹을 고려해 전송을 배분합니다.
여기서 NVLink 도메인(NVLink Domain) 은 NVLink를 통해 서로 데이터를 교환할 수 있는 GPU 그룹을 가리킵니다.
아래 원문 애니메이션은 학습 측 TP4 배치를 추론 측 TP2×DP2로 바꾸는 예입니다.
추론 측 GPU 네 개는 하나의 NVLink 도메인 안에 있습니다.
같은 TP 조각이 DP 복제본 두 곳에 필요합니다.
출처: NVIDIA 원문 Figure 3. 왼쪽은 직접 전송, 오른쪽은 NCCL M2N Reshard입니다.
단순한 점대점(Point-to-point, P2P) 전송에서는 S0~S3 조각을 각각 두 복제본에 보내므로 도메인 간 전송이 여덟 번 발생합니다.
Reshard는 각 조각을 네트워크로 한 번씩 보내, 네 번의 도메인 간 전송으로 배분합니다.
각 추론 GPU는 자신이 직접 받지 않은 부분을 같은 도메인의 다른 GPU에서 NVLink로 받습니다.
예를 들어 G0는 S0를 학습 측에서 받고, S1은 G2에서 전달받습니다.
G2도 자신이 받은 S1을 공유하고 G0의 S0를 전달받아 같은 조각을 완성합니다.
전체 데이터를 목적지 복제본마다 네트워크로 다시 보내는 대신, 도메인 내부의 빠른 연결을 활용하는 방식입니다.
여러 NVLink 도메인에 복제본이 있으면 도메인 사이로 데이터를 전달하고, 각 도메인 안에서 다시 분배합니다.
네트워크 전송과 NVLink 교환은 겹쳐 실행합니다.
원문은 전송이 네트워크 대역폭을 충분히 사용하는 조건을 가정해 중복 전송을 줄이는 효과를 설명합니다.
따라서 위 예의 전송 횟수가 절반이라는 사실만으로 모든 환경의 실행 시간도 절반이 된다고 계산할 수는 없습니다.
실제 효과는 GPU 연결 구조와 복제 배치, 데이터 크기에 따라 달라집니다.
네트워크 배치를 고려한 전송 더 알아보기
NCCL M2N의 메시와 복제 배치 설명
NeMo RL은 큰 가중치에 Reshard를 적용하는 혼합 방식을 사용합니다
NeMo RL의 구현 문서는 전송 대상을 두 경로로 나눕니다.
큰 비중을 차지하는 순전파 신경망(Feed-forward Network, FFN) 의 투영 가중치는 조각 간 재분할로 보냅니다.
그 밖의 가중치는 기존 전송과 적재 경로를 사용합니다.
NVIDIA는 블로그에서 최근 대규모 언어 모델의 순전파 투영 가중치가 전체 파라미터의 약 95%를 차지한다고 설명했습니다.
이는 모든 모델에 공통으로 적용되는 고정 비율은 아닙니다.
해당 비중이 클수록 Reshard가 처리하는 데이터의 비중도 커집니다.
| 구분 | 대표 대상 | 전송 방식 |
|---|---|---|
| 대용량 경로(Bulk Path) | 지원되는 gate_proj, up_proj, down_proj 가중치 |
필요한 샤드 영역을 직접 재분할합니다. |
| 나머지 경로(Misc Path) | 임베딩, 어텐션 투영, 정규화, 라우터 등 | 기존의 묶음 방송과 백엔드 적재 절차를 사용합니다. |
전문가 혼합(Mixture of Experts, MoE) 모델에서도 큰 전문가 가중치는 대용량 경로의 대상이 됩니다.
다만 이름에 FFN이 포함된 모든 가중치가 같은 경로를 쓰는 것은 아닙니다.
현재 구현의 대상 선정 규칙에는 공유 전문가 등 별도 적재가 필요한 예외가 있습니다.
이 설계는 모든 계층의 특수한 적재 규칙을 한꺼번에 다시 구현하는 부담을 줄입니다.
전송량이 큰 부분부터 최적화하면서, 나머지 가중치는 기존 백엔드의 처리 방식을 유지합니다.
적용 시에는 자신의 모델에서 대용량 경로가 실제로 처리하는 비율을 확인할 필요가 있습니다.
NeMo RL 혼합 경로 더 알아보기
NCCL Reshard Refit 설계 문서
벤치마크의 2.7~5.7배는 가중치 갱신 구간의 측정값입니다
NVIDIA는 NeMo RL에서 기존 전체 수집 후 방송 방식과 Reshard 기반 리핏의 지연 시간을 비교했습니다.
다음 표는 블로그에 제시된 네 가지 측정값입니다.
원문에 명시된 NVLink 도메인 구성은 H100 시스템이 NVL8, GB200 시스템이 NVL72입니다.
배속은 기존 시간을 Reshard 시간으로 나눠 소수점 한 자리로 반올림한 값입니다.
| 플랫폼 | 모델 | 학습 → 추론 배치 | 기존 리핏 | Reshard 리핏 | 약 배속 |
|---|---|---|---|---|---|
| NVIDIA DGX H100, NVL8 | Qwen 3 235B | TP4×PP8×EP16 → TP8×DP16 | 6.4초 | 1.9초 | 3.4배 |
| NVIDIA DGX H100, NVL8 | DeepSeek v3 671B | PP16×EP16 → TP32×DP8 | 14.9초 | 2.6초 | 5.7배 |
| NVIDIA DGX GB200, NVL72 | DeepSeek v3 671B | PP16×EP16 → TP32×DP8 | 6.1초 | 2.3초 | 2.7배 |
| NVIDIA DGX GB200, NVL72 | Nemotron Ultra v3 | TP8×EP32×PP2 → TP8×DP8 | 8.2초 | 2.3초 | 3.6배 |
H100의 DeepSeek v3 671B 실험에서는 리핏 시간이 14.9초에서 2.6초로 줄었습니다.
같은 이름의 모델도 GB200 실험에서는 기존 시간이 6.1초였으므로 개선 배율이 다릅니다.
모델명만으로 전송 성능을 일반화하기보다 플랫폼과 병렬 배치를 함께 봐야 합니다.
원문에는 Qwen3.8 2.4T BF16 모델의 리핏 전용 마이크로벤치마크(Microbenchmark) 에서 4.3초가 걸렸다는 결과도 있습니다.
이 측정에는 같은 조건의 기존 방식 비교값이 함께 제시되지 않았습니다.
따라서 이 값으로 별도의 가속 배율을 계산하거나 전체 학습 처리량을 추정할 수는 없습니다.
또한 생성, 보상 계산, 역전파 등에 걸리는 시간은 위 표에 포함되지 않습니다.
자신의 학습에서 리핏이 차지하는 시간이 작으면, 리핏을 크게 줄여도 전체 시간의 감소 폭은 작을 수 있습니다.
도입 효과를 판단하려면 전체 단계 시간과 리핏 시간을 함께 측정해야 합니다.
성능 결과 더 알아보기
NVIDIA 원문의 리핏 지연 시간 비교
설정은 간단하지만 백엔드와 정밀도 조건을 먼저 확인해야 합니다
블로그에서 제시한 NeMo RL 설정은 다음과 같습니다.
학습과 생성을 별도 GPU에 배치하고, 전송 방식으로 nccl_reshard 를 선택합니다.
policy:
generation:
colocated:
enabled: false
refit_transport: nccl_reshard
이 설정은 이미 구성된 NeMo RL 학습 설정에 적용하는 항목입니다.
위 코드만으로 모델과 GPU 자원이 자동으로 준비되지는 않습니다.
현재 지원 조건을 보면 백엔드와 병렬 배치에 추가 제약이 있습니다.
| 확인 항목 | 현재 공식 문서에 명시된 조건 |
|---|---|
| GPU 배치 | colocated.enabled: false 로 학습과 생성을 별도 GPU에 배치해야 합니다. |
| 학습 백엔드 | Megatron 학습 백엔드를 사용해야 하며, Automodel은 아직 지원하지 않습니다. |
| 생성 백엔드 | vLLM 또는 Megatron을 지원합니다. |
| 생성 측 파이프라인 병렬화 | 이 전송 방식에서는 생성 측 PP가 1보다 큰 구성을 아직 지원하지 않습니다. |
| 학습 측 전문가 텐서 병렬화(Expert Tensor Parallelism, ETP) | vLLM 생성 시 policy.megatron_cfg.expert_tensor_parallel_size: 1 이 필요합니다. |
| ModelOpt의 실제 양자화(Real Quantization) | policy.generation.real_quant: false 가 필요합니다. |
| 정밀도 | BF16과 문서에 명시된 FP8 및 MXFP8 조합을 지원하며, 저장 형식과 백엔드 조합을 확인해야 합니다. |
위 표는 주요 조건이며, 사용자 정의 파이프라인 배치와 정밀도 조합 등 나머지 제약은 연결된 공식 문서에서 함께 확인해야 합니다.
생성 백엔드가 SGLang 또는 TensorRT-LLM인 구성은 현재 nccl_reshard 전송의 지원 대상이 아닙니다.
이는 해당 도구 자체가 리핏을 지원하지 않는다는 뜻이 아니라, 이 전송 방식과의 조합에 대한 제약입니다.
vLLM 내부에서 사용하는 커널 백엔드의 이름과, NeMo RL의 생성 백엔드 이름도 구분해야 합니다.
양자화(Quantization) 는 가중치를 더 낮은 비트 수로 표현하는 기법입니다.
FP8은 8비트 부동소수점 형식이며, MXFP8은 블록 단위 스케일을 함께 사용하는 형식입니다.
양자화된 학습 가중치도 물리적인 저장 바이트를 그대로 옮기는 것으로 단정할 수 없습니다.
양자화 파라미터 지원 문서에 따르면, 대용량 경로의 양자화된 출발지 가중치는 BF16으로 변환해 전송하며 나머지 경로는 기존 처리를 유지합니다.
이 변환 비용까지 포함하므로 BF16 측정값을 다른 정밀도에 그대로 적용해서는 안 됩니다.
네이티브 구현이 실제로 선택됐는지도 확인해야 합니다.
전송 구현 설명에 따르면 nccl.m2n 을 불러올 수 없으면 Python 기반 대체 구현이 자동으로 선택됩니다.
설정 이름만 확인하는 대신 설치된 패키지와 실행 경로를 함께 확인하는 이유입니다.
장애 복구 과정에서 GPU 구성이 달라지면 통신 그룹과 배치 정보도 갱신해야 합니다.
블로그 공개 시점의 NeMo RL은 통신 그룹을 해제한 뒤 다시 생성하는 방식을 사용합니다.
NCCL의 그룹 축소 및 확장 API를 사용하는 복원력 지원은 원문에서 향후 계획으로 제시됐습니다.
적용 조건 더 알아보기
NeMo RL의 백엔드별 전송 제약
정밀도와 병렬 배치의 세부 지원 조건
자신의 환경에서는 무엇을 측정해야 할까요
Reshard 도입을 검토할 때는 현재 리핏의 병목과 지원 범위를 함께 확인할 수 있습니다.
아래 항목은 앞서 설명한 설계와 제약에서 도출한 적용 검토 기준입니다.
- 전체 학습 단계에서 리핏이 차지하는 시간을 측정합니다.
- 학습과 추론의 TP, PP, EP, DP 배치와 NVLink 연결 구조를 확인합니다.
- 모델 가중치 중 Reshard 대용량 경로가 처리하는 비중을 확인합니다.
- 실제 선택된 전송 구현과 정밀도 변환 비용을 확인합니다.
- 같은 모델과 배치에서 리핏 시간, 전체 단계 시간, 갱신된 가중치의 정확성을 비교합니다.
이 방식은 특히 전체 가중치를 자주 전달하는 대규모 분리형 RL 구성에 적용을 검토할 수 있습니다.
GPU를 공유하는 구성은 백엔드별 별도 리핏 경로를 사용하므로, 위 설정의 대상과 다릅니다.
공식 문서는 nightly 문서이므로 실제 도입 시에는 사용하는 NeMo RL 버전의 지원 조건을 다시 확인해야 합니다.
Accelerating Reinforcement Learning Weight Refit with the Reshard Collective 소개 블로그
NCCL Extensions GitHub 저장소
NeMo RL GitHub 저장소
더 읽어보기
이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다. 
이 글은 
파이토치 한국 사용자 모임
이 직접 정리한 글입니다. 새 글을 놓치지 않으시려면 텔레그램(Telegram)이나 Slack/Discord/Teams/Dooray/GoogleChat 등으로 알림을 받으시고, 회원으로 가입하시면 주요 글들을 이메일
로도 보내드립니다! 
아래
쪽에 좋아요
를 눌러주시면 새로운 소식들을 정리하고 공유하는데 힘이 됩니다~ 