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