SlideDP가 여러 GPU의 공유 호스트 자원에서 계층 스트리밍 파인튜닝을 겹쳐 돌린다

무엇인가

풀 파라미터 파인튜닝은 mixed-precision Adam 기준으로 파라미터 N개당 약 16N 바이트의 상태(BF16 가중치·그래디언트 각 2N, FP32 마스터 가중치 4N, Adam 모멘트 8N)를 유지해야 한다. 이는 GPU 메모리 용량을 넘기거나, 한 노드 안에서 여러 GPU에 나눠 담아도 활성값(activation) 공간을 남기지 않는다. 호스트 상주 계층 스트리밍은 FP32 마스터 가중치와 옵티마이저 상태를 CPU 메모리에 두고, 작고 재사용 가능한 GPU 윈도로 계층을 하나씩 흘려보내 이 압박을 GPU 메모리에서 호스트 메모리와 CPU-GPU 경로로 옮긴다. 문제는 이걸 한 노드의 여러 GPU로 데이터 병렬 확장할 때다. GPU들이 고정된 호스트 자원 풀(CPU 연산, DRAM 대역폭, PCIe I/O)을 나눠 쓰기 때문에, GPU를 늘려도 호스트 서비스 용량은 비례해 늘지 않는다. 논문은 여기서 두 가지 압력을 지목한다. 첫째는 회피 가능한 증폭으로, 단일 GPU 엔진을 그대로 복제하면 계층 전송이 R개 랭크마다 복제되고 R개의 그래디언트가 호스트 측 리덕션을 위해 돌아온다. SlideFormer의 공개 다중 GPU 구현과 MegaTrain의 다중 GPU 모드가 이 패턴을 따른다고 논문은 밝힌다. 둘째는 잔여 파이프라인 노출로, 복제를 제거한 뒤에도 CPU 업데이트와 필수 전송, 랭크 간·버퍼 의존성이 남는데 강한 스케일링에서는 이를 가릴 계산 창 자체가 줄어든다.

어떻게 동작하나

SlideDP의 핵심 설계는 상태 소유권과 통신 경로를 분리하는 것이다. L개 계층 각각에 대해 호스트가 FP32 파라미터와 Adam 모멘트의 단일 사본을 하나만 유지하고, rank-0 옵티마이저 워커가 이를 반복마다 한 번 갱신한다. GPU 윈도는 임시 복사본만 들고 있으므로 전달 경로를 바꿔도 상태 소유권과 갱신 의미론은 변하지 않는다. 동기 데이터 병렬을 지키는 세 가지 불변식은 모든 랭크가 같은 파라미터 버전으로 계층을 계산할 것, 갱신이 모든 랭크에서 집계된 그래디언트를 소비할 것, 다음 반복의 디스패치가 그 갱신을 기다릴 것이다. 파라미터 전달은 전체 디스패치(각 랭크에 P_l 바이트)와 샤딩 디스패치(각 랭크에 P_l/R, 이후 all-gather로 재구성) 중에서 고르고, 그래디언트 반환은 GPU 리덕션(랭크 0이 평균 낸 그래디언트 하나를 호스트로 반환)과 CPU 리덕션(R개의 G_l 바이트를 D2H 후 호스트에서 집계) 중에서 고른다. 샤딩 디스패치와 GPU 리덕션을 조합하면 파라미터·그래디언트 총 페이로드가 랭크 수 R과 무관해진다.

무엇과 다른가

겹침은 두 스케일에서 일어난다. 완료된 계층이 업데이트를 풀어놓는 동안 앞쪽 계층의 역전파가 계속되고, 한 계층 안에서는 청크가 준비·이동·갱신을 겹친다. 파라미터 준비와 H2D, 활성값 오프로드/재로드, GPU 연산, 그래디언트 리덕션, 그래디언트 D2H, CPU LayerAdam의 여섯 논리 레인이 DRAM과 호스트-디바이스 경로를 공유하며, 런타임은 랭크 준비 상태와 버퍼 완료를 조율한다. 파라미터 전달에서는 CPU가 청크 k+1을 BF16으로 캐스팅하는 동안 DMA가 청크 k를 옮기고, AVX-512 스테이징은 non-temporal store로 DMA가 소비하는 버퍼의 캐시 오염을 줄인다. 그래디언트 반환에서는 계층 전체 리덕션 후 청크 단위 D2H가 이어지고, 완료된 복사본이 자기 Adam 청크를 풀어준다. 버퍼가 차면 배압(backpressure)이 대기 중인 전송이나 갱신 작업을 노출시킨다. 여기에 공유 자원 서비스 수요와 계층 간·랭크 간 의존성(준비 상태, 버퍼 재사용, 파라미터 버전)을 담은 분석적 스텝 타임 모델을 붙여, 호스트 바운드와 GPU 바운드 실행을 구분하고 트래픽을 줄이면 언제 스텝이 짧아지는지, 계산 창이 줄면 언제 호스트 작업이 드러나는지를 설명한다. AutoPolicy는 이 모델과 실측을 바탕으로 통신 경로·청크 크기·활성값 배치를 정하고, Elastic Checkpointing은 계층별로 활성값 유지·오프로드·재계산을 선택한다. 라우트와 청크를 먼저 탐색하고, 후보 활성값 배치를 축소된 파이프라인에서 보정한 뒤 예산 안에서 배정·검증하는 단계적 프로파일링을 쓴다.

어떻게 쓰나

실험은 PyTorch Distributed 구현으로 RTX 4090, A800, H100에서 이뤄졌다. 매칭 배치 스윕에서 SlideFormer, MegaTrain, ZeRO-Offload 대비 기하평균 처리량이 1.46~2.64배다. RTX 4090 4장에서는 배치 4~32 구간에서 ZeRO-Offload 대비 1.83배, MegaTrain 대비 1.48배였고 배치 64에서 9.81K tokens/s를 내며 베이스라인들과 RoundPipe는 메모리 부족으로 실패했다. H100 4장에서는 배치 16~64에서 ZeRO-Offload 대비 1.46배, 배치 16~128에서 MegaTrain 대비 1.59배였고, 배치 256에서 그래디언트 누적 없이 스텝당 1,048,576 토큰, 23.2K tokens/s를 기록해 두 베이스라인 피크의 각각 1.41배, 1.47배였다. 모델 크기 스케일링에서 RTX 4090은 1.7B~32B 구간에서 429~470 TFLOPS, Qwen3-32B는 ZeRO-Offload의 4.24배, Qwen2.5-72B는 240 TFLOPS로 SlideFormer의 1.56배(나머지 세 오프로딩 베이스라인은 OOM)를 냈다. H100에서는 4B~72B에서 1.8~2.0 PFLOPS, 72B에서 ZeRO-Offload의 1.88배였고, 4B와 8B에서 FSDP2와 1% 이내로 맞서고 14B에서는 11.2% 앞섰다. 긴 시퀀스에서는 Qwen3-14B로 64K에서 2.13 PFLOPS(ZeRO-Offload 1.64, MegaTrain 1.34), 128K에서 1.95 PFLOPS(MegaTrain 1.41), 256K도 1.86 PFLOPS로 완주했으며 이 구간에서 FSDP2와 TP4는 실행 불가로 표시됐다.

전제와 한계

메모리 효율도 주요 결과다. 전체 계층 체크포인팅과 활성값 오프로드 조합에서 Qwen3-14B의 피크 예약 메모리를 ZeRO-Offload 대비 51~59%, MegaTrain 대비 29~42% 줄였고, 배치 256은 72.4 GiB를 쓴다. 호스트 PSS는 RTX 4090의 Qwen3-8B 배치 4~32에서 SlideDP 106~109 GiB, ZeRO-Offload 183 GiB, MegaTrain 211~212 GiB였고, H100의 Qwen3-14B 배치 16~64에서는 약 202 GiB 대 342 GiB였다. 32B까지의 호스트 풋프린트 기울기는 파라미터 10억 개당 14.2 GiB로 다른 시스템의 19.8~22.9 GiB보다 낮다. 확장성 측면에서 Qwen3-32B를 GPU당 64 시퀀스로 돌릴 때 A800 2·4·8장에서 95~98% 약한 스케일링 효율을 보였고(8장에서 7,963 tokens/s 대 ZeRO-Offload 5,478, MegaTrain 5,396), Qwen3-14B 전역 배치 256에서는 4장에서 8장으로 갈 때 1.94배(8.84K→17.18K tokens/s)로 늘어난 반면 SlideFormer는 1.04배에 그쳤다. 같은 조건에서 매칭 계산 기준 대비 초과 스텝 시간은 SlideDP 0.90초, SlideFormer 28.57초, MegaTrain 9.77초였다. 통신 경로 민감도도 실측됐는데, NVLink 브리지가 있는 A800 4장의 호스트 바운드 워크로드에서는 샤딩 전달이 16.8~32.7% 빠르지만 브리지를 제거하면 복제 전달이 19.2~26.0% 빨라지고, GPU 바운드 8장 워크로드에서는 모든 조합이 2.5% 이내로 붙는다. 청킹 효과는 단일 계층 64 MiB 청크 실험에서 변환+H2D가 127.8ms에서 50.8ms로, D2H+CPU 업데이트가 135.9ms에서 91.7ms로 줄었고, Qwen3-8B 배치 8에서 4장 기준 3,218→3,465 tokens/s(+7.7%), 1장 기준 1,386→1,852 tokens/s(+33.6%)였다. 정책 선택은 H100 Qwen3-14B 배치 16에서 10,231→12,832 tokens/s(+25.4%)를 냈고, 선택 비용은 1,218초(20.3분)로 스텝당 0.970초 절감 기준 손익분기 1,257 스텝(2.72시간), 24시간 학습 예산의 1.4%로 추정된다. MoE 계층도 지원해 Qwen3.6-35B-A3B 44.7K tokens/s, Gemma4-26B-A4B 27.3K tokens/s로 ZeRO-Offload 대비 1.98~3.21배, MegaTrain 대비 1.44~1.71배를 냈다. 정확성은 H100 4장에서 Qwen3-14B를 GPU당 배치 16, 시퀀스 길이 1024, C4 샘플로 200 스텝 돌려 FSDP2와 비교했고 전역 배치 평균 손실의 최대 절대 차이가 F-r1에서 5.2×10⁻⁴, 선택 레이아웃에서 6.3×10⁻⁴였다.

개발자 관점에서 이 논문의 실용적 메시지는 두 가지다. 첫째, 호스트 상주 스트리밍을 여러 GPU로 늘릴 때 가장 먼저 손봐야 할 것은 알고리즘이 아니라 데이터 이동 경로다. 랭크마다 계층을 복제해 내려보내고 그래디언트를 전부 호스트로 끌어올리는 순진한 확장은 호스트 DRAM과 PCIe에서 병목을 만든다. 논문의 실측에 따르면 A800에서 800M 파라미터 계층의 cast-and-copy는 GPU 한 장이 복사할 때 15.6 GB/s지만 두 장이 동시에 복사하면 GPU당 8.7 GB/s로 떨어지고, CPU Adam은 16 물리 코어에서 182~184 GB/s로 포화돼 32 코어로 늘려도 8.5~10.0%밖에 개선되지 않는다. 둘째, 통신 경로와 GPU 메모리 배치는 하드웨어 토폴로지와 워크로드에 따라 최적값이 뒤집히므로 고정 정책을 쓰면 손해다. NVLink 유무에 따라 선호 경로가 바뀌고, 남는 HBM을 활성값 유지에 쓸지 재계산 억제에 쓸지도 현재 노출된 병목에 따라 달라진다. 실제로 H100 배치 32에서 31개 F-r0 계층과 9개 무체크포인트 계층을 섞은 설정은 76.6 GiB를 쓰며 고정 정책(15.0 GiB)보다 처리량이 12.4% 높았다. 다만 정책 선택에는 20분 안팎의 프로파일링 비용이 들고, 그 이득은 최소 1,257 스텝 이상 학습해야 회수된다는 점을 감안해야 한다.

논문이 명시한 전제와 한계도 분명하다. 대상은 한 노드 안에서 호스트 자원을 공유하는 다중 GPU 시스템이며, 동기 데이터 병렬 의미론을 유지하는 것을 전제로 한다. 텐서 병렬은 계층 내 연산자를 분할해 GPU 간 통신을 만들고 호스트-디바이스 겹침을 복잡하게 만들기 때문에 선택지에서 제외했고, 파이프라인 병렬 기반의 RoundPipe 같은 접근은 비동기 옵티마이저 갱신과 지연된 파라미터 버전에 의존해 동기 파인튜닝에서는 갱신 의존성이 되살아나 정지가 생길 수 있다고 지적한다. 또한 통신 경로 선택은 토폴로지와 워크로드에 모두 의존하므로 단일 최적 경로가 존재하지 않는다고 못박고, 정책 선택 오버헤드와 상각에 필요한 스텝 수를 별도로 보고한다. 제시된 스텝 타임 모델은 분석적 모델이며, 실측으로 보정해 정책을 고르는 데 쓰인다. 원문에는 별도의 한계 절이 따로 있지는 않지만, 이상의 전제들이 이 결과를 적용할 수 있는 범위를 규정한다.