효율적인 강화학습 – Rhythm Garg & Linden Li, Applied Compute

채널 아이콘
AI Engineer 구독자 99,800명

요약

Applied Compute 공동 창업자 Rhythm과 Linden이 소개하는 효율적인 강화학습 워크플로우입니다. 동기식 RL의 비효율성을 지적하고, 파이프라인 기반 비동기 RL을 통해 GPU 활용률을 높이며 학습 속도를 끌어올리는 방법을 설명합니다. 이어서 시스템 모델링을 통해 샘플링·훈련 처리량, 지연 곡선을 분석하고, 한정된 GPU 자원을 최적 배분해 약 60% 속도 향상을 달성하는 시뮬레이션 결과를 공유합니다.

주요 키워드

Efficient RL Pipeline RL Staleness Importance Ratio Throughput Latency Curve Roofline Model GPU Utilization KV Cache Batch Size

하이라이트

  • 🔑 Applied Compute는 기업 맞춤형 데이터 플라이휠을 활용해 AI 자동화를 구현하고 정량적 ROI를 제공합니다.
  • 📌 동기식 RL은 모든 샘플 완료를 기다리느라 GPU가 유휴 상태가 되는 긴 꼬리(latency tail) 현상이 발생합니다.
  • ⚡️ 파이프라인 파이프라인 RL은 샘플링과 훈련을 분리해 GPU 활용률을 높이고, 실시간으로 모델 가중치 업데이트를 수행합니다.
  • 🔄 시차(Staleness)가 커질수록 중요도 비율(Importance Ratio)의 분산이 증가해 학습 안정성이 저해됩니다.
  • 🎯 엔터프라이즈용 RL은 빠르고(일 단위), 저렴하며 변동성이 낮은 예측 가능한 학습 시간이 필수입니다.
  • 📊 시스템 모델링을 통해 GPU 수·배치 크기·샘플링 처리량·훈련 처리량을 프록시로 사용해 전체 파이프라인 성능을 추정합니다.
  • 📈 샘플링 지연 곡선(latency curve)은 배치 크기에 따른 메모리 바운드와 연산 바운드 전이를 잘 설명합니다.
  • 🔧 동기식·비동기식 각각을 시뮬레이션해 스테디 스테이트 배치 사이즈, 최대 시차를 제약 조건으로 최적 자원 배분을 찾았습니다.
  • 🚀 최적 구성은 동기식 대비 약 60% 학습 속도 향상을 보여주며, 다양한 시퀀스 길이·GPU 비율 설정을 사전 검증할 수 있습니다.

용어 설명

강화학습 (Reinforcement Learning)

에이전트가 시행착오를 거쳐 보상 신호를 최대화하며 학습하는 기계학습 기법입니다.

동기식 RL (Synchronous RL)

샘플링과 훈련을 순차적으로 진행해 모든 샘플이 완료된 뒤에야 업데이트하는 방식입니다.

비동기식 RL (Asynchronous RL)

샘플링과 훈련을 병렬로 실행해 자원을 효율적으로 사용하는 방식입니다.

파이프라인 RL (Pipeline RL)

샘플링 전용 GPU와 훈련 전용 GPU를 분리하고, 가중치를 in-flight로 실시간 업데이트하는 비동기식 기법입니다.

중요도 비율 (Importance Ratio)

기존 정책과 최신 정책 간 확률 비율로, 시차로 인한 편향을 보정해 무편향(policy gradient) 학습을 보장합니다.

[00:00:20] Applied Compute와 강화학습 소개

공동 창업자 Rhythm과 Lyndon이 Applied Compute 설립 배경과 미션을 소개합니다. 기업별 맞춤형 AI 시스템 구축과 실사용 데이터 플라이휠을 통해 정량적 ROI를 내는 과정을 설명합니다.

Applied Compute 공동창업자들인 Rhythm과 Lyndon이 자기소개를 하며, 이전에 OpenAI에서 연구원으로 일했던 경험을 소개합니다. 현재는 최첨단 AI를 기업 내부로 가져오는 일을 하고 있다고 설명합니다.
Applied Compute의 비즈니스 모델을 설명합니다. 기업이 자체 AI를 구축하여 생산성 향상을 넘어서 실질적인 자동화와 정량적 ROI를 달성할 수 있도록 돕는다고 설명하며, 데이터 플라이휠을 통해 지속적으로 개선되는 시스템을 제공한다고 언급합니다.
강화학습(RL)이 Applied Compute에서 어떻게 활용되는지 설명합니다. 분포 밖 데이터를 분포 내로 가져오는 도구로서 RL을 사용하며, OpenAI에서의 경험을 바탕으로 공공 벤치마크를 넘어서 기업의 프라이빗 벤치마크 문제 해결에 적용하고 있다고 설명합니다.
[00:01:44] RL을 통한 모델 수학 성능 강화 메커니즘

오픈소스 모델에 수학 문제 데이터셋을 RL 학습으로 적용하는 구체적 흐름을 다룹니다. 여러 번 샘플링 후 정답 판정에 따라 가중치를 보강·억제해 추론 성능을 높이는 과정을 예시로 설명합니다.

수학 문제를 예시로 들어 Applied Compute의 RL 작동 방식을 구체적으로 설명합니다. 네 개의 문제를 선택하여 모델이 각 문제를 100번씩 시도하게 하고, 정답일 때는 사고 과정을 강화하고 오답일 때는 억제하는 방식으로 모델을 훈련시킨다고 설명합니다.
실제로는 수학 문제가 아닌 기업이 중요하게 생각하는 작업에 이 메커니즘을 적용한다고 설명하며, Applied Compute에서 하는 RL 작업이 연구소의 작업과는 다르다고 언급합니다.
[00:02:58] 엔터프라이즈 RL 효율성 요건

Applied Compute가 추구하는 학습의 세 가지 조건(빠른 수행, 저비용, 낮은 분산)을 제시합니다. 기업 환경에서 예측 가능한 학습 시간을 확보하는 중요성을 강조합니다.

Applied Compute는 연구소와 다른 방식으로 운영되며, 몇 주에 걸친 대규모 훈련 대신 더 특화된 훈련을 수행합니다.
RL 훈련에서 중요한 요소는 빠른 속도(며칠 내 고객 전달), 비용 효율성, 그리고 훈련 시간 추정의 낮은 분산입니다.
비즈니스 핵심 연구 과제는 에이전트 구축 플랫폼과 결합하여 사용 사례별 훈련을 확장할 수 있는 매우 효율적인 RL 스택을 구축하는 것입니다.
동기식 RL의 문제점을 설명합니다. 8개 샘플을 배치로 훈련할 때 모든 샘플이 완료될 때까지 기다려야 하므로 많은 GPU가 유휴 상태가 됩니다.
[00:04:08] 동기식 RL의 비효율성

샘플링 완료 후 훈련을 시작하는 동기식 RL의 병목 현상을 분석합니다. 느린 꼬리(straggler) 샘플 때문에 GPU가 대기 상태에 빠져 처리량이 급감하는 문제를 실측 데이터를 통해 보여줍니다.

동기식 RL에서는 가장 느린 샘플이 전체 스텝 시간을 좌우하는 문제가 있습니다.
실험 결과 40개 산술 문제로 Qwen 30B 테스트 시 99% 샘플은 40초 내 완료되지만, 나머지 1%가 추가 80초 소요되는 긴 꼬리 현상을 보여줍니다.
처리량 차트에서 GPU들이 초기에는 많이 작업하지만 마지막 샘플 대기로 매우 비효율적으로 사용되며, 이를 'GPU가 빈둥거리고 있다'고 표현합니다.
문제 해결을 위해 샘플링과 훈련의 동기화 조건을 깨뜨려 샘플링 중에도 훈련이 가능한 비동기식 RL 접근법이 필요합니다.
[00:05:35] 비동기식 파이프라인 RL 개념

샘플링 전용·훈련 전용 GPU를 분리해 작업을 계속 수행하는 파이프라인 RL을 소개합니다. in-flight weight update로 샘플 중에도 최신 가중치를 반영하는 방식이 특징입니다.

비동기 파이프라인 RL 시스템에서는 GPU를 샘플링과 훈련 작업으로 나누어 할당합니다. 샘플링 워커는 지속적으로 높은 배치 크기로 추론을 수행하고, 완료된 샘플들은 훈련 큐에 추가되어 훈련 워커들이 처리합니다.
파이프라인 RL의 핵심 특징인 인플라이트 가중치 업데이트에 대해 설명합니다. 훈련 스텝이 완료되면 샘플링이 진행 중이어도 새로운 모델 가중치를 모든 샘플링 워커에 즉시 전파합니다.
이러한 방식으로 인해 하나의 샘플 생성에 여러 버전의 정책이 기여하게 되어 스테일 토큰이 포함된 샘플들이 생성됩니다. 실제 예시를 통해 t, t+1, t+2 시점의 정책들이 하나의 샘플을 만드는 과정을 보여줍니다.
[00:06:39] 시차(Staleness)와 학습 안정성

샘플 생성 중 발생하는 여러 버전의 정책 토큰(stale tokens)이 학습에 미치는 영향을 설명합니다. 허용 시차를 높일수록 GPU 유휴는 줄지만 중요도 비율 분산이 커져 학습 불안정성이 증가합니다.

스테일니스 허용 수준에 따른 시스템의 동작 변화를 설명합니다. 최대 2까지의 지연만 허용할 경우, 훈련 워커들이 샘플 완료를 대기해야 하며, 1까지만 허용하면 더 긴 대기 시간이 필요합니다.
스테일니스 허용 수준과 GPU 효율성 간의 트레이드오프를 설명합니다. 더 높은 지연 허용은 유휴 GPU를 줄이지만, 중요도 비율의 분산이 증가하여 학습 불안정성과 발산 위험을 야기할 수 있습니다.
많은 staleness가 학습 불안정을 야기하며, 이를 해결하기 위해서는 알고리즘과 과학적 혁신이 필요하다. 이는 Applied Compute의 핵심 연구 문제이자 비즈니스와 직결되는 영역이다.
본 발표에서는 단순한 하위 문제에 집중한다. 좋은 과학기법과 알고리즘으로 일정 임계값까지 staleness를 허용할 수 있고, 고정된 컴퓨팅 예산이 있다는 가정 하에 가장 효율적인 RL 수행 방법을 찾는다.
[00:09:00] RL 시스템 모델링: 주요 요소

Linden이 시스템 모델링을 위해 정의한 프록시 요소를 소개합니다. 전체 GPU 수, 훈련 배치 크기, 샘플링 처리량, 훈련 처리량 등 워크로드 구성 변수를 도식화합니다.

이를 엔드투엔드 시스템의 모델링 문제로 접근했다. 복잡해 보이지만 원칙 기반 시스템 모델링을 통해 놀라운 성과를 얻을 수 있었다. 시스템을 설명하는 주요 구성 요소들을 파악하고 이들의 결합 방식을 분석한다.
첫 번째 요소는 컴퓨팅 예산의 지표인 GPU 개수다. 동기식 설정에서는 모든 GPU가 훈련과 샘플링에 순차적으로 사용되지만, 비동기 설정에서는 GPU 풀을 훈련용과 샘플링용으로 자유롭게 할당할 수 있어 설계 결정이 필요하다.
두 번째는 훈련 배치 크기로 전체 시스템의 워크로드 지표다. 데이터셋의 부분집합인 문제 배치를 다루며, 문제 난이도에 따라 샘플링 수를 조정하여 모델이 다양한 전략을 학습하도록 장려한다.
세 번째는 샘플링 처리량의 지표다. 현대 추론 엔진의 작동 방식을 살펴보면, GPU 메모리에는 모델 가중치, 활성화, KV 캐시가 있고, 각 순방향 패스가 다음 토큰을 샘플링한 후 KV 캐시에 기록한다. 따라서 순방향 패스의 GPU당 지연 시간을 측정하는 것이 핵심이며, 이는 시스템 관점에서 추론 처리량을 결정하는 주요 요소다.
[00:10:21] 샘플링 처리량과 지연 모델

GPU 메모리·연산 바운드 전이를 보여주는 지연 곡선(latency curve)을 설명합니다. 배치 크기에 따른 forward pass 지연 변화를 roofline 모델 기반 수식으로 정량화합니다.

GPU 추론 처리량은 샘플링 배치 크기에 의해 결정되며, 동시에 전달되는 토큰 배치가 메모리 제약 하에서 GPU를 최대한 효율적으로 활용해야 한다고 설명합니다.
배치 크기에 따른 지연 시간 곡선을 피팅할 수 있으며, 이 곡선은 메모리 바운드에서 컴퓨트 바운드로 전환되는 특성을 보입니다.
시스템의 루프라인 모델을 기반으로 한 방정식을 통해 낮은 배치 크기에서는 메모리 바운드되고, 배치 크기가 커질수록 프로세서가 병목이 되는 현상을 설명합니다.
[00:12:28] 훈련 처리량 프로파일링

GPU당 tokens/sec 단위로 훈련 처리량을 측정하는 방법을 설명합니다. 순전파, 역전파, 옵티마이저 단계를 포함한 전체 학습 단계의 처리량을 모델링합니다.

학습 처리량의 프록시로 GPU별 토큰 처리 속도를 측정하며, 이는 순방향, 역방향 및 옵티마이저 단계를 포함한 초당 토큰 수로 표현됩니다.
동기 설정을 사용한 시스템 모델링 접근법을 제안하며, 이는 스탈니스 제약을 만족하고 전체 GPU 플리트를 효율적으로 활용할 수 있지만, 생성 배치 크기와 응답 길이 분포를 알아야 합니다.
[00:13:20] 동기식 RL 워크로드 시뮬레이션

동기식 구성에서 배치 크기 변화를 시각화한 시뮬레이션을 보여 줍니다. GPU 대기 구간이 발생하며, 최대 토큰 추론 단계와 응답 길이 분포를 반영해 전체 지연을 계산합니다.

샘플링 작업 시간 예측과 시스템 구성을 위한 시뮬레이션 과정을 설명합니다. 각 요청의 처리 과정을 시각화하고 배치 크기 변화를 모니터링하는 방법을 보여줍니다.
최적화 단계 실행과 반복적인 샘플링 절차를 설명합니다. 최대 토큰 추론 패스와 지연 시간 추정기를 활용한 응답 길이 분포 계산 방법을 다룹니다.
[00:14:00] 비동기식 RL 자원 배분 최적화

샘플링·훈련 GPU 비율에 따른 극단적 사례를 분석합니다. 생산 속도와 소비 속도를 균형 있게 맞춰야 GPU 유휴·시차 문제를 동시에 해결할 수 있음을 보여 줍니다.

훈련 시 토큰 수 계산과 처리량 분석을 통한 지연 시간 곡선 시뮬레이션을 설명합니다. GPU 수 증가가 단계별 지연 시간 감소에 미치는 영향을 보여줍니다.
[00:15:00] 최적 GPU 구성 시뮬레이션 결과

시차 상한, 처리량 균형 제약 하에 GPU 레이아웃을 탐색한 결과 동기식 대비 약 60% 학습 속도 향상을 달성합니다. 다양한 시퀀스 길이·GPU 분할 시나리오를 사전 검증 가능합니다.

동기식 설정의 한계점을 인식하고 비동기식 설정의 필요성을 제시합니다. 하지만 단순한 컴퓨팅 프로비저닝만으로는 유휴 GPU 문제를 해결할 수 없음을 경고합니다.
할당 문제의 극단적 사례를 분석합니다. 추론 GPU를 과도하게 프로비저닝하고 샘플러를 적게 설정했을 때 발생하는 문제점을 설명하며, 큐 소비 속도와 생산 속도 불균형으로 인한 GPU 유휴 상태 문제를 보여줍니다.
극단적인 반대편에서는 샘플링 GPU를 너무 많이 프로비저닝하여 생산 속도가 소비 속도보다 훨씬 빨라지는 경우가 있습니다. 샘플링 GPU를 두 배로 늘리고 훈련 GPU를 절반으로 줄이면, 샘플 생산 속도는 빨라지지만 각 샘플의 staleness가 계속 증가하게 됩니다.
시간이 지나면서 샘플들이 점점 더 stale해지고 투명해져서, 개별 샘플에서 배우는 것이 줄어듭니다. 따라서 이런 워크로드를 어떻게 모델링하여 최적의 비동기 워크로드를 결정할지 생각해봐야 합니다.
이 경우 그림이 조금 다른데, steady state에서 배치 크기가 시간에 따라 감소하는 동기 설정과 달리 상대적으로 일관적입니다. 노란색 사각형이 항상 가득 차 있고, 샘플을 완료할 때마다 새로운 샘플이 들어가므로 배치 크기가 실행 과정에서 꽤 일관적입니다.
물론 응답 길이가 늘어날수록 KV 캐시 부족으로 배치 크기가 감소하지만, 우리 모델은 응답 길이 분포를 수용합니다. 생성 배치 크기가 실행 과정에서 대략 일관적이라는 것을 알았으니, 최적 레이아웃을 알아낼 수 있습니다.
만족해야 할 두 가지 제약조건이 있습니다. 첫 번째는 생산 소비 속도가 대략 같아야 한다는 것으로, 훈련 처리량(훈련 GPU 수 × GPU당 처리량)과 샘플링 처리량(샘플링 GPU 수 × 배치 크기 × forward pass 지연시간)이 같아야 합니다.
두 번째로, 너무 많은 staleness가 ML 관점에서 나쁠 수 있으므로, 최대 이론적 staleness나 시뮬레이션된 staleness가 우리 ML이 처리할 수 있는 수준을 초과하지 않도록 해야 합니다. 최대 staleness는 배치에서 가장 긴 요청이 걸린 시간(최대 토큰 수 × 토큰당 forward pass 시간)과 관련이 있습니다.
강화학습 시스템에서 훈련 스텝의 길이는 훈련 배치 크기와 평균 시퀀스 길이의 곱으로 계산됩니다.
시뮬레이션은 다양한 훈련 GPU 수를 확인하며, 고정된 연산 자원 풀에서 샘플링에 사용될 GPU 수를 결정합니다.
샘플링 GPU 수에 대해 KV 캐시 메모리 제약 조건 하에서 메모리 초과를 방지하고 최대 처리량을 달성하는 최소 정상상태 생성 배치 크기를 계산합니다.
샘플링 처리량이 최대 허용 스탈네스를 초과하는 모든 시뮬레이션을 제거하여 시스템을 최적화합니다.
응답 길이로 매개화된 end-to-end 시뮬레이션 결과, GPU 연산이 훈련과 샘플링 간에 최적 할당될 때 동기식 기준선 대비 약 60%의 속도 향상을 달성했습니다.
제약 조건 내에서 레이아웃 스윕을 통해 스탈네스를 제한하면서도 실제 실행 없이 최대 처리량을 보장할 수 있습니다.
비용이 많이 드는 GPU 실행 전에 다양한 워크로드를 시뮬레이션할 수 있는 통찰력을 제공하여, 응답 길이가 길어질 때의 최적 GPU 구성 등 과학적 질문에 답할 수 있습니다.
[음악]
안녕하세요 여러분, 만나서 정말 반갑습니다.
오늘 이 자리에 함께할 수 있어 정말 기쁩니다. 제 이름은 Rhythm이고,
이쪽은 제 공동창업자 Lyndon입니다.
저희의 세 번째 공동창업자인 Yash는
오늘 참석하지 못했지만, 저희 모두
이 자리에 오게 되어 매우 기쁩니다. 저희 세 명은
이전에 OpenAI에서 연구원으로 일했고,
현재는 Applied Compute에서 최첨단 AI를
기업 내부로 가져오는 일을 하고 있습니다.
오늘은 효율적인 강화학습에 대해
이야기해보겠습니다.
Applied Compute에 대해 간단히 설명드리자면, 저희는
기업이 자체 인공지능을 구축하여
회사 내에서 실질적인 업무를 처리할 수 있도록
도움을 드립니다. 저희는 AI를 생산성 향상을 넘어서
실제 자동화 솔루션으로 발전시켜
정량적인 ROI를 제공하는 방법에 대해 많이 고민합니다.
회사를 위한 것입니다. 저희가
특정 사용 사례에 맞게 회사의
운영 방식에 특화된 시스템을 구축한 후,
데이터 플라이휠과 함께 배포하여
사용하면 할수록 더 나아지도록
시간이 지남에 따라 발전하게 만듭니다.
회사 내 전문가가 항상
해당 분야의 최전선에 있는 것처럼 상상해보세요.
해당 분야의 최전선에 있는 것처럼요.
강화학습은 기계적으로 저희가
이러한 분포 밖 데이터셋을
오늘날 모델들을 위한 분포 내로
가져오기 위해 사용하는 도구입니다. Yash, Lyndon과 저는
모두 OpenAI 초기의 RL 프로젝트에서 일했고
강화학습이 공공 벤치마크를
최대화하는 데 있어서의 강력한 힘을 직접 목격했습니다.
이제 저희는 한 걸음 더 나아가서
기업들이 가장 중요하게 생각하는
문제들을 해결할 수 있도록 돕고 있습니다.
일종의 그들만의
프라이빗 벤치마크라고 할 수 있죠.
여기 Applied Compute의 RL이 어떻게
언어모델이 이러한 추론과
지능 능력을 습득하도록 돕는지에 대한 매우 높은 수준의 개요입니다.
수학 문제 데이터셋이 있다고 가정해보고
그 중에서 네 개를 선택해서
RL 훈련 단계를 진행한다고 해봅시다.
그다음 오픈소스 모델을 가져옵니다.
GPT-O 모델 중 하나나
Llama 모델 중 하나를 사용해서, 모델이
네 개 문제 각각을 100번씩
시도하도록 합니다. 이 100번의 시도 각각은
모델이 최종 답에 어떻게 도달할지 생각하고
최종 답 자체로
마무리하는 과정입니다.
그리고 이것들은 모델의 사고 궤적에서 나오는
수많은 추론 토큰들입니다.
저희는 이 모든 답안들을 채점할 수 있고
모델이 정답을 맞혔을 때는
해당 시도에서의 사고 과정을 강화하도록
모델의 가중치를 조정할 수 있습니다.
틀렸을 때는 모델이 그런 종류의 행동을
다시 하지 않도록
억제할 수 있습니다. 이런 방식으로 네 개 문제에 각각 100번씩 시도하는
배치로 더 많은 훈련 단계를
진행할수록, 모델은 추론하고
수학 문제를 해결하는 법을 배우고
수학을 정말, 정말 잘하게 됩니다.
물론 Applied Compute에서는
실제로 기업의 수학 문제 해결을 돕는 것이 아니라,
이것이 저희가 모델들을
기업이 중요하게 생각하는 작업에서
정말, 정말 뛰어나게 만드는
메커니즘의 한 종류입니다.
말씀드린 바와 같이, Applied Compute에서 저희가 하는
RL 작업의 유형은
실제로 연구소에서 하는 것과는 상당히 다릅니다.
이것들은 실제 생활에서 찍은 사진들로
연구소에서 찍은 사진과 며칠 전에 Applied Compute 사무실에서 찍은 사진입니다.
연구소는 몇 주에 걸쳐
대규모 훈련을 진행하죠.
저희는 더 특화된 훈련을 합니다.
그리고 저희에게 특히 중요한
RL 훈련의 몇 가지
측면들이 있습니다.
저희 훈련은 빨라야 합니다. 모델을 훈련시켜서
며칠 안에 고객에게
매우 빠르게 전달할 수 있어야 해요.
단위 비용이 맞아야 하고
비용 효율적이어야 합니다.
사업을 지속 가능하게
확장할 수 있도록 말이죠.
그리고 중요한 점은 - 놓치기 쉬운 부분인데 -
이 훈련 작업이 얼마나
오래 걸릴지에 대한 추정이
매우 낮은 분산을 가져야 한다는 겁니다.
단순히 일반적으로 빠른 게 아니라
고객과 작업할 때
안정적으로 빨라야 합니다.
그래서 저희에게
비즈니스적으로 매우 중요한
연구 문제는 RL 스택을
매우 효율적으로 구축할 수 있는가
입니다. 에이전트 구축 플랫폼과 결합하여
이 사용 사례별 훈련
방식을 실제로 확장할 수 있도록
말이죠.
비효율적인 RL 형태인
동기식 RL부터 시작해보겠습니다.
동기식 RL에서는 샘플링과 훈련이
동기화되어 일어납니다.
여기서 몇 가지 단순화를 했지만
8개 샘플의 배치로
훈련하고 싶다고 하면
8개 샘플이 모두 완료될 때까지
기다린 다음 훈련을 시작합니다.
그리고 이 과정을
반복하게 됩니다.
결과적으로 많은 GPU들이
세 번째 느린 샘플이
완료되기를 기다리며
유휴 상태에 있게 됩니다.
즉, 동기식 RL에서는
스텝 시간이 가장 오래 걸리는
샘플에 의해
좌우됩니다.
이것이 왜 나쁜지 설명하기 위해
40개의 산술 문제를 가져와서
각각에 대해 Qwen 30B로 32개씩
샘플을 요청하고 이 샘플들이
완료되는 데 얼마나
걸리는지 측정했습니다.
결과적으로 99%의 샘플이
약 40초 내에 완료되었습니다.
나머지 1%가 완료되는 데
추가로 80초가 걸렸습니다.
정말 긴 꼬리를 갖고 있습니다.
예상대로 처리량 차트를 보면
GPU들이 처음에는
모든 샘플링 요청이 시작될 때
많은 작업을 하지만
마지막에는
마지막 샘플들이 완료되기를
기다리느라 매우 매우
비효율적으로 사용됩니다.
Applied Compute에서 사용하는
기술 용어로는 GPU들이
'빈둥거리고 있다'고 합니다.
그래서 동기식 RL은
이런 GPU들을 사용하는
효율적인 방법이 아닙니다.
이 문제를 해결하기 위해서는
샘플링과 훈련이
동기화되어야 한다는
조건을 깨뜨려야 합니다.
즉, 샘플링하는 동안
훈련을 허용해야 합니다.
여기서 몇 가지 단순화를
하겠지만, 비동기
파이프라인 RL에서는 일부 GPU를
샘플링에, 일부 GPU를 훈련에
할당합니다. 샘플링 워커들은
멈추지 않습니다. 높은 배치
크기로 지속적으로 추론을
수행합니다. 샘플들이 완료되면
훈련을 위한 큐에 추가되고,
훈련 워커들은 큐에서 배치를
가져와 훈련합니다. 배치가
훈련 완료되면, 훈련 워커들이
새로운 모델 가중치를 모든
샘플링 워커에 전파하는데,
이를 인플라이트 가중치
업데이트라고 합니다. 이것이 바로
파이프라인 RL을 차별화하는
요소입니다. 샘플링 워커들이
샘플 생성 중이어도 훈련 스텝이
완료되면 가중치가 업데이트됩니다.
결과적으로 샘플을 생성하기 위해
여러 버전의 정책이 기여한
샘플들이 생성됩니다. 다시 말해,
일부 샘플에는 오래된 토큰들이
포함됩니다. 이를 더 명확히
하기 위해 한 샘플을 살펴보겠습니다.
보시다시피, 시간 단계 t, t+1,
t+2에서 세 가지 버전의
정책이 이 샘플을 생성하는데
사용되었습니다. 이는 이 샘플이
생성되는 동안 두 번의 훈련
스텝이 완료되고, 두 번의
인플라이트 가중치 업데이트가
있었기 때문입니다.
따라서 이 샘플이 T+3에서
T+4 훈련 배치에서 훈련될 때,
세 스텝 이전 정책에서 나온
토큰들과 두 스텝 이전
정책에서 나온 토큰들, 그리고
한 스텝 이전 정책에서 나온
마지막 두 토큰들이 혼재합니다.
이제 우리가 최대 2까지의
지연만을 허용한다고 가정해봅시다.
그러면 T+1에서 T+2 훈련 배치
완료 후 인플라이트 가중치
업데이트를 허용하지 않습니다.
즉, 훈련 워커들이 이 샘플이
완료될 때까지 대기하며
인플라이트 가중치 업데이트를
전파하고 다음 배치 훈련을
시작하게 됩니다. 만약 인플라이트
가중치 업데이트를 한다면,
이 샘플의 지연이 3이 되어
방금 본 것과 같습니다.
만약 지연을 1까지만 허용한다면,
훈련 워커들이 훨씬 더 오래
대기하게 될 것입니다.
이는 좋지 않습니다. 따라서 허용하는
지연이 늘어날수록 일반적으로
유휴 GPU가 줄어듭니다. 하지만
알다시피, 공짜는 없습니다.
이것은 표준 정책 기울기에
중요도 비율을 조정한 것으로,
시간 단계 t의 정책에서 샘플링하고
k 지연이 있는 시간 단계 t+k의
정책으로 훈련하는 사실을
조정합니다. 중요도 비율이 이
정책 기울기를 편향되지 않게
만듭니다. 하지만 그 비율의
분산이 지연이 증가할수록
증가합니다. 이것이 여기서
큰 문제인데, 높은 분산의
중요도 비율로 인해 학습이
불안정해지고 발산할 수 있습니다.
구체적인 트레이드오프는
빠른 RL 실행을 위해서는 높은
많은 staleness는 학습을 불안정하게 만들고,
이는 알고리즘과 과학적 혁신이 필요하다는 것을 의미합니다.
이것이 Applied Compute에서 우리가 집중하는
주요 연구 문제 중 하나입니다.
Applied Compute에서 우리가 집중하는
주요 연구 문제입니다. 그리고 앞서 말했듯이,
이는 직접적으로 우리 핵심 비즈니스와 연결됩니다.
직접적으로 우리 핵심 비즈니스와 연결됩니다.
이번 발표에서는
좀 더 단순한 하위 문제에 집중하겠습니다.
좋은 과학적 기법과 알고리즘 혁신이 있어서
일정한 임계값까지 staleness를 허용할 수 있고,
어떤 고정된 임계값까지 staleness를 허용할 수 있고,
실제 세계에서 일반적으로 존재하는
고정된 컴퓨팅 예산이 있다고 가정해 봅시다.
이런 상황에서 RL을 수행하는
가장 효율적인 방법은 무엇일까요?
좋습니다. Rhythm, 감사합니다.
우리는 이를 엔드투엔드 시스템의
모델링 문제로 접근했습니다.
처음에는 조금 복잡해 보일 수 있지만,
원칙에 기반한 시스템 모델링을 통해
놀라울 정도로 많은 것을 얻을 수 있다는 것을
발견했습니다. 모든 모델링 문제와 마찬가지로
시스템을 설명하는 주요 요소들을 파악하고,
시스템을 설명하는 주요 요소들을 파악하고,
이들이 어떻게 결합되어
모델을 구성하는지 생각해 보겠습니다.
첫 번째 주요 요소는 컴퓨팅 예산의 지표로,
여기서는 GPU 개수를 사용합니다.
Rhythm이 방금 설명한 동기식 설정에서는
모든 GPU가 훈련 또는 샘플링에
순차적으로 사용됩니다.
하나씩 차례로 발생하기 때문입니다.
하지만 비동기 설정에서는 조금 더 복잡합니다.
GPU 컴퓨팅 풀을
훈련용으로 원하는 만큼 할당하거나
샘플링용으로 원하는 만큼 할당할 수 있어서
설계 결정이 필요합니다.
샘플링용으로 원하는 만큼 할당할 수 있어서
설계 결정이 필요합니다.
다음은 훈련 배치 크기로,
전체 시스템에서 워크로드의 지표입니다.
전체 시스템에서 워크로드의 지표입니다.
이는 ML 결정이지만,
간단히 말해 데이터셋의 일부인
문제 배치가 있습니다.
예를 들어 훈련하고 싶은 n개의 수학 문제가 있고,
각 문제에 대해 병렬로
n개의 문제를 샘플링할 것입니다.
문제가 정말 어렵다면,
샘플의 다양성을 장려하기 위해
더 많이 샘플링할 수 있습니다.
모델이 잠재적으로 다양한
전략을 학습하도록 장려하기 위해
전략을 학습하도록 장려하기 위해서입니다.
다음으로 필요한 것은
샘플링 처리량의 지표입니다.
모델링 결정으로 무엇을 선택해야 할지
직관을 얻기 위해,
현대적인 추론 엔진이 어떻게
요청을 처리하는지 살펴봅시다.
GPU 메모리에는 모델 가중치, 활성화,
그리고 KV 캐시라고 불리는
런타임 상태가 메모리에 있습니다.
이 훈련된 모델이 주어지면,
각 순방향 패스가 다음 토큰을 샘플링하는
순방향 패스를 여러 번 실행하고,
그 다음 KV 캐시에 기록합니다.
이 모델이 보여주는 것은
우리가 해야 할 주요 추정치는
순방향 패스의 GPU당 지연 시간을
측정하는 방법을 찾는 것입니다.
이것은 실제로 꽤 좋은 선택인데,
시스템 관점에서 우리가 선택하는
추론 처리량은 주로
샘플링을 수행하는 배치 크기에 따라 결정됩니다.
여기 빨간 사각형에서 보여드린 것은
동시에 전달되는 토큰들의 배치입니다.
이 샘플링 순방향 패스는
GPU를 효율적으로 활용하기 위해
가능한 한 크게 만들어야 합니다.
단, KV 캐시에서 메모리 부족이
발생하지 않는 런타임 제약 조건 하에서 말이죠.
KV 캐시에서요.
그래서 우리가 할 수 있는 것은
배치 크기의 함수로
지연 시간 곡선을 맞추는 것이고
그 지연 시간 곡선은 이런 모습이 될 것입니다.
메모리 바운드 영역이 있고
증가하면 컴퓨트 바운드가 되며
아래에는 어떤 함수적 형태가 있습니다.
왜 이런 결정을 내렸는지
세부사항을 설명하기 위해
여기 있는 방정식은
시스템의 루프라인 모델을 기반으로 합니다.
낮은 배치 크기에서는
노란색으로 강조표시한 부분인데
처리할 작업이 그리 많지 않습니다.
프로세서에서 할 컴퓨팅이 많지 않고
동시에 로드해야 할 매개변수가 너무 많기 때문입니다.
결과적으로 증분 작업을 추가할 때
전체 시스템의 지연 시간에는
그리 큰 영향을 주지 않습니다.
프로세서가 수학 연산을 매우 빠르게 처리하기 때문에
우리는 단지 메모리에서 매개변수가
프로세서로 스트리밍되기를 기다릴 뿐입니다.
메모리에서 프로세서로 말이죠.
하지만 배치 크기가 커지기 시작하면
프로세서가 병목이 됩니다.
배치에 더 많이 추가할수록
순방향 패스가 더 느려집니다.
그리고 추가로 설명하자면
여기에 시그모이드가 있어서
이 힌지 포인트에서
부드러운 전환을 조정해서
메모리 바운드 연산에서
더 컴퓨트 바운드되고
프로세서가 병목이 되는
연산으로의 미묘한 전환이
있음을 보여줍니다.
마지막 구성요소는 학습 처리량의 일종의 프록시이고
우리는 이것을 GPU별로 측정하기로 했습니다.
이 경우 모델은 학습 배치 크기를 입력으로 받습니다.
앞서 본 매개변수죠.
일반적으로 우리는 실제 워크로드의
프록시를 피팅해서 이를 수행합니다.
여기서 단위는
각 학습 GPU가 초당 처리하는
토큰 수입니다.
따라서 순방향, 역방향 및
일부 옵티마이저 단계를
수행해야 합니다.
이러한 예측 구성요소들이 주어지면
시스템 모델링을 시작할 수 있습니다.
첫 번째 아이디어는 비록 Rhythm이
이것이 좋은 아이디어가 아닐 수 있다고
제안했지만, 동기 설정을
사용하는 방법에 대해 생각할 수 있습니다.
이것은 첫 번째 원칙에서
좋은 아이디어일 수 있는데
확실히 스탈니스 제약을 만족하기 때문입니다.
오래된 데이터로 학습하지 않고
항상 전체 GPU 플리트를
학습이나 샘플링에 사용해서
하드웨어를 효율적으로 사용하도록 합니다.
실제로 이것을 어떻게 모델링하는지
생각해봅시다. 알아야 할 두 가지가 있습니다.
생성이 실행되는 배치 크기를 알아야 하고
또한 학습 워크로드가 어떻게 진행되는지
파악하기 위해 응답 길이 분포를
알아야 합니다.
작동할지와 샘플링이 얼마나 걸릴지도
알아야 합니다. 여기서 보여드리는
시뮬레이션은 여러 엔진들을
나타냅니다. 각 사각형은 처리되는
요청을 나타내고, 배치 처리가
진행될수록 점점 더 어두워집니다.
샘플들이 완료되면 큐에 써집니다.
오른쪽에는 시계열 메트릭이
있는데, 프로덕션 메트릭을
모니터링한다면 Grafana에서
볼 수 있는 것과 같습니다.
보시면 배치 크기가 처음에는
매우 높지만 시간이 지나면서
서서히 감소하다가 결국 0이 되고
모든 샘플이 완료됩니다.
그러면 드디어 최적화 단계를
실행할 수 있습니다. 단계가
완료되면 이를 반복해서
다음 단계로 넘어갑니다.
결과적으로 다음과 같은
샘플링 절차를 가질 수 있습니다.
최대 토큰 추론 순방향 패스를
수행하는데, 여기서 최대 토큰은
가장 긴 요청에 대해 수행하는
총 순방향 패스 수입니다.
학습된 지연 시간 추정기를 사용해
순방향 패스가 얼마나 걸릴지
파악합니다. 그리고 응답 길이
분포가 몇 개의 응답을
삭제할지 알려줍니다.
여기서 보여드리는 비디오는
지연 시간 추정기에 입력하는
응답 길이 분포의 전체 과정입니다.
훈련 시에는 배치에서
방금 샘플링한 총 토큰 수를
계산하고 총 훈련 처리량으로
나눕니다. 이는 GPU 수에
GPU당 훈련 처리량을
곱한 값입니다. 여기서
지연 시간 곡선이 어떻게
보이는지 시뮬레이션한
것이 있습니다. 왼쪽에는
응답 길이 분포의 CDF가 있어
몇 개의 응답을 삭제해야 하는지
알려주고, 오른쪽에는 지연 시간
곡선이 있습니다. 이는 대략
추적됩니다. GPU를 더 추가하면
단계별 지연 시간이 감소할 것으로
예상되기 때문입니다.
다음 아이디어는, Rhythm이 보여준
것처럼 동기식 설정이 가장
원칙적인 선택이 아닐 수도 있으니
비동기식 설정입니다. 하지만
단순히 훈련과 추론 사이에
컴퓨팅을 프로비저닝하는 것만으로는
충분하지 않습니다. 주의깊게 하지
않으면 다시 유휴 GPU
문제에 부딪힐 수 있습니다.
이를 보여주기 위해 이 할당
문제의 두 극단을 살펴보겠습니다.
먼저 스펙트럼의 한쪽 끝을
살펴보겠습니다. 추론 GPU는
너무 많이 프로비저닝하고 샘플러는
많지 않게 한 경우입니다. 이 경우
큐에서 소비하는 속도가 생산하는
속도보다 훨씬 빠릅니다. 샘플링
워커들이 우리가 실제로 소비할 수
있는 속도보다 훨씬 느리게
작업을 생산하기 때문입니다.
빨간 사각형이 회색이 되면
유휴 상태임을 나타냅니다.
이 다이어그램이 보여주고자 하는
것은 대부분의 시간 동안 우리가
실제로 이를 사용하지 않고 있다는
것이며, 이는 앞서 보여준 동기식
극단적인 반대편에서는 샘플링 GPU를
너무 많이 프로비저닝할 수 있습니다.
이 경우 생산 속도가 실제로
소비하는 속도보다 훨씬 빨라집니다.
여기서는 전체 샘플링 GPU 수를 두 배로 늘리고
훈련 GPU 수는 절반으로 줄였습니다.
보시다시피, 훨씬 빠른 속도로
샘플을 생산합니다.
하지만 각 노란색 사각형의 이 인덱스는
각 샘플의 staleness 카운트로,
계속 증가합니다.
시간이 지나면서 점점 더
stale 해집니다.
따라서 샘플들이 점점 더
투명해지고,
개별 샘플에서 배우는 것이 줄어듭니다.
그럼 실제로
이 워크로드를 어떻게 모델링하여
최적의 async 워크로드를 결정할지 생각해봅시다.
이 경우 그림이 조금 다른데,
steady state에서 배치 크기가
시간에 따라 감소하는 synchronous 설정과 비교해
상대적으로 일관적이기 때문입니다.
오른쪽에는
동일한 시계열 메트릭이 있습니다.
하지만 이 경우는 조금 다른데,
노란색 사각형이 항상 가득 차 있습니다.
샘플을 완료할 때마다
새로운 샘플이 들어가고
큐에 계속 쓸 수 있기 때문입니다.
따라서 약간의 변동이 있더라도
배치 크기는
실행 과정에서 꽤 일관적입니다.
물론 여기서 주의할 점은
이 배치 크기가
응답 길이가 늘어날수록
확실히 감소할 것인데,
KV 캐시가 부족해지기 때문입니다.
하지만 이는 별개의 이야기이고
실제로 우리 모델이 이를 수용합니다.
왜냐하면 실제로
응답 길이 분포를 수용하고 있기 때문입니다.
그러면 최적 레이아웃을
알아낼 수 있고,
지금 만족해야 할 두 가지 제약조건이 있습니다.
생성 배치 크기가
실행 과정에서
대략 일관적이라는 것을 알게 되었으니까요.
필요한 첫 번째 불변량은
생산 소비 속도가
대략 같아야 한다는 것입니다.
이 등식의 왼쪽에는
훈련 GPU 수에
GPU당 처리량을 곱한 훈련 처리량이 있고
또한 샘플링 GPU 수에
샘플링 처리량을 곱한 것이 있습니다.
이는 단순히 배치 크기에
해당 배치 크기에서 실제로
forward pass를 수행하는 지연시간을 곱한 것입니다.
다음으로, Rhythm이
너무 많은 staleness가
ML 관점에서 나쁠 수 있다고 언급했으므로,
최대 이론적 staleness나
시뮬레이션된 staleness가
우리 ML이 처리할 수 있는 수준을
초과하지 않도록 해야 합니다.
왼쪽의 최대 staleness는
위쪽의 배치에서 가장 긴 요청이 걸린 시간과 같은데,
이는 단순히 최대 토큰 수에
각 토큰 forward pass가
걸리는 시간을 곱한 것입니다.
그리고 아래쪽에는
훈련 단계의 길이가 있습니다.
훈련 스텝의 길이는
훈련 배치 크기에
평균 시퀀스 길이를
곱한 값입니다.
그래서 여기서 시뮬레이션은
훈련 GPU 수의 다양한 값들을
확인해보게 됩니다. 그리고 우리는
고정된 연산 자원 풀을 가지고 있기 때문에
샘플링에 사용되는 특정 수의 GPU가
암시됩니다. 그리고 이 샘플링 GPU 수에 대해
우리는 최소 정상상태 생성 배치
크기를 계산할 수 있어서 KV 캐시
메모리 제약 조건 하에서
메모리를 초과하지 않도록 보장하고
동시에 샘플링 측면에서
최대 처리량을 달성할 수 있습니다.
그리고 마지막으로 우리는
샘플링 처리량이 최대 허용
스탈네스를 초과하는 모든 시뮬레이션을
제거하고 싶습니다.
이 시뮬레이션을 살펴보면
응답 길이로 매개화된
end-to-end 시뮬레이션을 실행할 수 있습니다.
이것이 동기식 기준선 대비
약 60%의 속도 향상을
시뮬레이션한다는 것을 볼 수 있습니다.
GPU 연산이 훈련과 샘플링 간에
최적으로 할당된다고 가정할 때 말입니다.
결과적으로, 이러한 제약 조건 내에서
레이아웃을 스윕할 때, 이는 우리가
스탈네스를 제한할 수 있게 해주지만
실제 실행 없이도 최대 처리량으로
실행이 진행되도록 보장합니다.
따라서 이것은 GPU에서 실제로
실행하기 전에 다른 워크로드들을
시뮬레이션할 수 있는 통찰력을 제공합니다.
이러한 실행들이 실제로는
꽤 비쌀 수 있기 때문입니다.
따라서 이것을 통해 우리는 제1원리로부터
과학적 질문에 답할 수 있습니다.
예를 들어, 응답 길이를 매우 길게 만들 때
GPU 연산의 최적 구성은 무엇인가?
왜냐하면 모델이 강화학습을 통해
학습할 때 종종
훨씬 더 오랜 시간 동안 사고하기 시작하기
때문입니다. 그리고 또한 성능 최적화 동안
목표로 해야 할 경험적 처리량이
무엇인지도 알 수 있습니다.
따라서 이것은 정말 유용한
기술 조각이었고, 시뮬레이션은
우리가 만드는 많은 시스템과
연구 설계 결정에 정보를 제공했습니다.
좋습니다. 시간을 내주셔서 감사하고
나중에 더 많은 강화학습
연구 엔지니어링을 함께 논의하기 위해 저희를 찾아주세요. 감사합니다.
[음악]