분산 강화학습의 경험 경로를 런타임 최적화 대상으로 끌어올린 Conduit

무엇인가

이 논문이 다루는 문제는 분산 강화학습에서 actor와 learner 사이를 잇는 Experience Buffer가 더 이상 단순한 replay 큐가 아니라는 점이다. 최신 경험 데이터는 큰 시각·멀티모달·장문 컨텍스트 페이로드를 담고 있어, 매 반복마다 이 무거운 데이터를 옮기고 변환하고 샘플링하고 배치로 묶는 작업이 learner 업데이트 전에 반드시 일어난다. 저자들은 이 반복 작업을 경험 경로 처리(experience-path handling)라고 부르고, 이것이 반복 시간의 50.2%(off-policy DQN)와 26.2%(on-policy PPO)를 차지한다고 측정한다. RLlib 기준으로 한 반복에 DQN은 33개, PPO는 27개의 전송·처리 연산이 실행된다. 문제는 기존 시스템이 이 경로를 프레임워크 제어 흐름 안에 박아 넣거나(RLlib, MSRL, SRL) 요청 기반 버퍼 서비스로 노출한다는 점이다(Reverb, Gear). 두 경우 모두 경험 데이터의 배치 위치가 CPU나 특정 GPU로 고정되고, 경험 경로 작업을 독립적으로 스케줄링할 수 없다.

어떻게 동작하나

제안 시스템 Conduit은 이 경험 경로를 명시적인 시스템 최적화 문제로 끌어낸다. 핵심 추상화는 Experience Data Plane(EDP)으로, 경험 수집(ingestion), 경험 배치(placement), 경험 전달(delivery)을 프레임워크 내부 부수 효과가 아니라 런타임 제어점으로 노출한다. 역할 분담이 분명한데, 프레임워크는 어떤 경험을 저장하고 소비할지를 계속 정의하고, EDP는 그 경험이 어디에 상주하며 언제 수집·전달될지를 결정한다. Conduit은 프레임워크의 버퍼 인터페이스를 가로채는 저침습 계층으로 통합되며, RLlib의 실행 로직을 바꾸지 않고 붙는다. 논문은 RLlib 외에 스트리밍 데이터플로우 실행 모델을 쓰는 SRL과 LLM 사후학습용 Verl에도 통합된다고 밝힌다.

무엇과 다른가

배치 메커니즘은 용량 제약과 대역폭을 함께 고려한다. Conduit은 측정된 실효 대역폭으로 actor에서 버퍼로 들어오는 전송과 버퍼에서 learner GPU로 나가는 전송의 지연을 추정하고, 메모리 제약을 만족하는 후보 중 지연이 가장 낮은 배치를 고른다. 경험 크기가 학습 중 커지면 초기 배치가 불가능해질 수 있는데, 이때는 미리 계산해 둔 배치 맵을 이용한 온라인 마이그레이션으로 런타임 재프로파일링 없이 대응한다. 스케줄링 쪽은 두 개의 손잡이를 쓴다. 수집 granularity g_ing는 한 번의 수집 호출이 처리하는 롤아웃 양, 전달 granularity g_del은 한 번의 전달 호출이 준비하는 학습 데이터 양이다. off-policy에서는 g_ing이 {1,...,g_ing^max} 범위에서 여러 롤아웃을 묶을 수 있고, on-policy에서는 한 롤아웃이 M개의 미니배치 업데이트를 먹이는 경우 {1/M, 2/M, ..., 1}로만 파이프라이닝할 수 있다. 전달도 같은 방식으로 off-policy는 g_del ∈ {1,...,g_del^max}로 여러 배치를 프리페치하고, on-policy는 g_del = 1/M로 신선도를 지킨다. 사용자는 이 값을 직접 튜닝하지 않고, 프레임워크가 이미 노출하는 on/off-policy 여부와 미니배치 수 M만 주면 Conduit이 안전한 범위를 도출한다.

어떻게 쓰나

배치 실험은 합성 환경에서 전이 차원 128부터 20,000까지, 버퍼 용량 10^6, 배치 크기 512로 스윕한다. 차원 128~5,000 구간은 버퍼가 단일 GPU에 들어가는 대역폭 지배 영역으로, 단일 GPU 배치가 CPU-GPU 전송을 없애 가장 빠르며 d=5,000에서 Reverb 대비 최대 130배, Gear 대비 2.9배 낮은 지연을 낸다. 5,000을 넘으면 단일 GPU 메모리를 초과해 Conduit은 공유 GPU 배치로 전환하고, GPU-GPU 링크가 CPU-GPU보다 약 10배 빠르기 때문에 d=20,000에서 Reverb 대비 127배, Gear 대비 4.1배 빠르다. 온라인 마이그레이션 실험에서는 초기 최저 지연 배치를 고르는 Greedy가 d≥10,000에서 GPU 메모리를 소진해 실행을 끝내지 못하고, 처음부터 8개 GPU에 샤딩하는 Conservative는 151~403ms를 계속 지불한다. Conduit은 Greedy와 동일한 성능을 유지하다가 d=10,000과 20,000에서 약 30ms짜리 교체 스파이크 두 번만 흡수하고, 가장 큰 두 구간에서 146ms와 266ms로 Conservative보다 34~46% 낮은 반복 지연을 유지한다. 40회 반복 전체로는 Conservative보다 누적 지연이 1.9배 적다.

전제와 한계

스케줄링 실험은 granularity와 타이밍을 분리해 측정한다. 순차 실행에서 배치 크기 1,024일 때 g=2의 노출 지연 1.87ms가 g=8에서 0.57ms로 줄어 호출당 오버헤드 상각 효과를 보이지만, 전이 차원 10,000에서는 최적이 g=4(2.33ms)로 돌아서고 g=8은 3.67ms로 역전된다. 청크가 커지면 관리 비용이 상각 이득을 넘어선다는 뜻이다. 타이밍만 분리하면 차원이 128에서 10,000으로 커질 때 Reverb와 Gear는 경험 경로 지연이 각각 27배, 4.4배 늘지만, Conduit의 배치 전용 모드는 2.5배(3.12ms에서 7.83ms)만 늘고 여기에 오버랩을 켜면 잔여 지연 대부분이 롤아웃과 업데이트 뒤로 숨는다. 32개 수동 구성(배치 4 × 오버랩 2 × granularity 4)을 차원 128~10,000에서 스윕하면 구성 간 지연 격차가 82.9ms에서 888.5ms로 벌어지고, 차원마다 최적 구성이 달라지는데 Conduit의 자동 선택은 매 지점에서 하위 포락선에 놓인다. 확장성은 A100 클러스터에서 1~16 GPU, 총 배치 2,048로 95ms에서 15ms로 84% 줄고, 16 GPU에서 Gear보다 57%(15 대 35ms), Reverb보다 65%(15 대 43ms) 낮다. MI250X 슈퍼컴퓨터에서는 8~1,024 GPU, 워크로드 32,768로 614ms에서 50ms로 92% 줄고, 적응형 배치를 끈 버전보다 모든 규모에서 9~21% 우수하다(64 GPU에서 110 대 140ms, 1,024 GPU에서 50 대 55ms). 이는 MI250X 노드 내 링크가 100~400GB/s로 균일하지 않아 Conduit이 느린 랭크(1/3/5/7) 대신 빠른 랭크(0/2/4/6)를 선호한 결과다. Reverb와 Gear는 AMD를 지원하지 않아 이 실험에서 제외됐다. 수렴성은 DQN/MountainCar와 PPO/Meta-World에서 actor 8개, learner 8개로 확인했고, 보상 곡선은 기준선과 일치하며 wall-clock 기준으로는 더 빨리 같은 수준에 도달한다.

개발자 관점에서 이 논문의 실용적 의미는 버퍼 계층이 학습 처리량의 병목이 될 때 선택지가 하나 늘어난다는 것이다. 프레임워크 실행 로직을 건드리지 않고 버퍼 인터페이스만 가로채므로, 기존 RLlib 파이프라인에 얹어 경험 경로 지연을 줄일 수 있다. 다만 도입 전에 확인할 것은 세 가지다. 첫째, 자신의 워크로드에서 경험 경로가 반복 시간에서 차지하는 비중이다. 논문이 밝히듯 이 비중이 클수록 EDP의 배치·스케줄링 이득이 커진다. 둘째, 노드 내 인터커넥트가 균일한지다. GPU 쌍별 대역폭이 100~400GB/s로 갈리는 패브릭에서는 배치 선택이 성능을 좌우한다. 셋째, on-policy 학습에서는 신선도 제약 때문에 배칭 폭이 제한되어 end-to-end 이득이 rollout/update 시간에 묶인다는 점이다.

저자들이 명시한 전제와 한계도 분명하다. Conduit의 최적화는 on-policy 신선도와 off-policy replay 의미론을 보존하는 범위 안에서만 움직이며, EDP는 경험 경로 처리가 언제 어디서 실행되는지를 바꿀 뿐 어떤 데이터를 만드는지는 바꾸지 않는다. PPO에서는 경험 경로 지연을 크게 줄였지만 end-to-end 개선은 제한적인데, 신선도가 배칭을 막고 남은 rollout/update 시간이 임계 경로를 지배하기 때문이다. 또한 사용자가 staleness나 메모리 오버헤드를 제한하려면 배칭 상한을 직접 지정할 수 있지만, 논문은 합리적 기본값이면 충분하다고 주장한다. 마지막으로 대규모 슈퍼컴퓨터 실험에서 Reverb와 Gear는 AMD를 지원하지 않아 정면 비교가 아니라 하드웨어 일반성과 적응형 배치 효과를 보여주는 실험이라는 점을 저자들 스스로 밝히고 있다.