- Reka는 깨끗한 상태에서 대규모 언어·멀티모달 모델 훈련 인프라를 만들며, 컴퓨트 확보보다 클러스터 품질 편차와 운영 불안정성이 더 큰 병목이 됨
- 같은 H100 GPU라도 공급자와 클러스터에 따라 노드 장애, 케이블링 문제, GPU 오류, I/O·파일시스템 병목, 체크포인트 삭제, 납기 지연이 겹쳐 하드웨어 복권 같은 상황이 생김
- Google의 TPU·내부 인프라 경험과 달리 외부 GPU 환경에서는 멀티노드 학습, 배선, 지원 품질 차이가 커서 MFU와 다운타임이 클러스터마다 크게 달라짐
- 여러 클러스터와 대용량 데이터 이동, 외부 코드베이스 제약을 감수해야 했고, Reka는 PyTorch 기반으로 옮기며 모니터링, 효율적 체크포인트, 커스텀 파일시스템을 직접 구축함
- 제한된 컴퓨트 때문에 Big Tech식 체계적 스케일링 대신 적은 수의 짧은 절제 실험과 Yolo run에 기대야 했고, 그 결과 21B Reka Flash와 7B edge 모델을 만들 수 있었음
깨끗한 상태에서 훈련 인프라 만들기
- Reka는 강한 멀티모달 언어 모델을 훈련하면서, 대규모 언어·멀티모달 모델을 바닥부터 훈련하는 데 필요한 인프라를 새로 구축함
- 핵심 난점은 TPU와 GPU 중 무엇을 고르는 문제가 아니라, 외부 인프라와 코드 환경에서 실제 훈련을 안정적으로 굴릴 만큼 운영 품질을 확보하는 일이었음
LLM 시대의 하드웨어 복권
- 모델 훈련의 첫 조건은 컴퓨트 확보지만, 실제로는 공급자·클러스터·가속기 연결 품질의 편차가 가장 큰 변수로 작용함
- 같은 H100 GPU라도 전체 클러스터 품질은 크게 달랐고, 여기서 말하는 하드웨어는 칩 자체보다 클러스터 전체 품질에 가까움
- Reka는 여러 컴퓨트 공급자로부터 수백~수천 칩 규모의 클러스터를 임대했으며, 상태는 비교적 해결 가능한 수준부터 몇 시간마다 실패하는 수준까지 다양했음
- 일부 클러스터는 케이블링 문제나 GPU 하드웨어 오류 때문에 노드가 짧은 주기로 실패함
- 같은 공급자의 클러스터끼리도 견고함이 크게 달랐음
- 안정적인 노드가 있더라도 I/O와 파일시스템이 나쁘면 체크포인트 저장이 타임아웃되거나 클러스터 사용률이 크게 떨어짐
- 일부 컴퓨트 소스는 실행을 위해 완전히 다른 소프트웨어 계층을 요구해, 자체 코드베이스를 가져온 팀에는 마이그레이션 비용이 추가됨
- 사전에 어떤 하드웨어를 받게 될지, 얼마나 견고하고 장애 허용적인 경험을 하게 될지 알기 어려웠음
- 공급자가 제때 납품하지 못하면 몇 달씩 지연되고, 다른 공급처에서도 몇 주 또는 몇 달 동안 조달하지 못하는 상황이 생길 수 있음
- 일부 공급자는 체크포인트를 실수로 삭제하기도 했음
MFU와 장애 대응을 위한 내부 도구
- 클러스터마다 Model Flop Utilisation(MFU) 가 달라졌고, 잘못 케이블링된 노드나 공급자 문제를 만나면 무시할 수 없는 컴퓨트가 낭비됨
- 파일시스템이 매우 비효율적인 환경에서는 누군가 클러스터 간 대량 데이터 전송을 시작하는 것만으로 훈련 실행의 MFU가 급락할 수 있음
- 공급자 지원 수준도 크게 갈림
- 정중한 지원부터 무심한 대응까지 다양했음
- “ChatGPT 스타일”의 정형 응답이나 모든 문제를 사용자 탓으로 돌리는 대응도 있었음
- 각 클러스터는 고유한 고충과 실패 모드를 가졌고, 클러스터마다 별도 핫픽스가 필요한 것처럼 느껴졌음
- Reka는 사용 가능한 환경을 만들기 위해 여러 내부 도구를 구축함
- 모니터링 도구
- 효율적 체크포인트
- 여러 최적화
- 확장 가능한 데이터 저장을 위한 커스텀 파일시스템 설치
- 이런 도구 조합은 열악한 하드웨어에서도 다운타임을 줄이고 MFU를 의미 있게 개선함
GPU와 TPU 경험의 차이
- Reka는 대부분 GPU로 모델을 훈련함
- Google에서 대규모 언어 모델 훈련에 TPUs를 주로 사용했던 경험과 비교하면, CUDA와 nccl은 낯선 환경이었음
- GPU 장애율은 Google에서 TPUs를 사용하던 경험과 크게 달랐음
- Google의 UL2 20B는 작업이 실수로 한 달 동안 계속 실행됐지만 실패하지 않았음
- GPU 환경이었다면 처음 며칠 안에 실패했을 것이라고 봄
- 다만 이 차이는 칩 자체보다 가속기를 관리하는 하드웨어 팀의 역량과 공급자 지원 품질에 더 관련될 수 있음
- GPU 환경의 멀티노드 훈련은 TPU pod처럼 분산 훈련을 일급 개념으로 둔 느낌이 아니라, 나중에 붙인 요소처럼 느껴졌음
- 공급자마다 멀티노드 훈련을 가능하게 하는 배선 방식이 달라 보였고, 이 차이가 장소별 편차를 키움
멀티 클러스터 운영의 부담
- Google 내부 인프라는 Borg, Xmanager, Colossus 위에서 어디서든 접근 가능한 환경이었음
- 외부 환경에서는 여러 클러스터에 새 환경을 직접 구성해야 했고, 이는 이전 경험과 크게 달랐음
- 한 장소에 대규모 가속기 풀을 직접 만들지 않는 한, 여러 클러스터의 가속기 풀을 쓰는 상황은 불가피해 보임
- GPU 공급 부족은 조달을 자연스럽게 분산된 클러스터 형태로 만듦
- 대규모 모델 훈련에는 수십 TB급 데이터가 필요해, 데이터를 옮기는 일 자체가 큰 부담이 됨
- 매우 큰 규모에서는 데이터 복제도 간단하지 않고 비용 부담이 큼
- 이상적인 형태는 여러 서버로 작업을 보내는 오케스트레이션 계층이지만, 가볍고 새로운 스타트업이 초기에 이런 정교한 ML 훈련 인프라를 갖추기는 어려움
- Reka는 여러 내부 워크플로로 문제를 완화했고, 세계적 수준의 실험 인프라를 향해 계속 이동 중임
- 이런 스크래피한 구성은 최상위권 또는 대기업이 아닌 곳에서는 대체로 일반적이라고 들었다고 함
외부 코드베이스와 PyTorch 선택
- 선호하던 코드베이스는 T5X와 Mesh Tensorflow였지만, Reka에서는 현실적인 선택지가 아니었음
- Google 밖에서 지원이 많지 않음
- 어느 정도 deprecated 상태임
- 팀 내 Google 출신이 아닌 사람들에게 친화적이지 않음
- Reka는 더 바닐라에 가깝고 안정적으로 보이며 널리 쓰이는 PyTorch를 선택함
- 초반에는 pip, git, docker 같은 외부 개발 환경에 적응해야 했음
- 외부에서 Google 코드베이스를 안정적이고 사용자 친화적으로 쓰기 어려웠을 가능성도 있음
- 외부 코드베이스 품질은 Google에서 익숙했던 코드베이스보다 상당히 뒤처진다고 느꼈음
- Google 내부 코드베이스는 Noam Shazeer, Barret Zoph, Adam Roberts, Hyung Won Chung 등 ML 연구자들이 직접 작성한 경우가 많았다고 봄
- 다른 회사가 만든 코드 중에는 코드 품질이 특히 불만스러운 경우도 있었음
- 일부 코드베이스에서는 모델 병렬화 구성을 바꾸기 위해 별도 변환기를 작성해야 했고, 병렬화 변경이 자동으로 제공되지 않았음
- 대규모 encoder-decoder 훈련이나 prefixLM 훈련 지원도 부족했음
- flash attention은 GitHub 이슈에서 합리적인 수요가 있었음에도 prefixLM 훈련, 즉 커스텀 마스크 지원을 계속 제공하지 않았다고 함
- Jax를 써야 한다는 인식은 있었지만, 스타트업에서 빠르게 움직이기 위해 PyTorch를 선택함
제한된 컴퓨트와 Yolo run
- 체계적인 모델 스케일링은 보통 1B → 8B → 64B → 300B처럼 작은 모델에서 큰 모델로 여러 단계 실험을 실행하고, 승자를 골라 계속 키우는 방식임
- 스타트업에서는 하이퍼파라미터를 확인하기 위한 대규모 스윕을 수행할 컴퓨트가 훨씬 부족했음
- Reka는 많은 Yolo run에 의존했고, 결과적으로 잘 풀렸다고 봄
- 적은 수의 더 작은 규모·짧은 절제 실험만으로 강한 21B Reka Flash, 7B edge 모델, 그리고 예정된 가장 큰 core 모델까지 도달함
- 제한된 실행 횟수로 좋은 레시피를 찾기는 어렵고, 탐색 공간이 매우 커서 한 번에 많은 변수를 바꿔야 했음
- Big Tech식 체계성 대신 Yolo, 감, 직관에 많이 의존해야 했음
- 팀원들이 이전 ML 경력에서 쌓은 직관은 적은 시도 안에 맞추는 데 도움이 됨
- 이전 직장에서 좋은 모델을 훈련한 경험이 있어도, 훈련 인프라, 데이터, 새 아이디어 통합, 환경 이슈 차이가 결과에 작지 않은 차이를 만들 수 있음
- 강한 사전 경험은 탐색 공간을 크게 줄였고, 적은 시행·자원·실험으로 강한 모델을 훈련할 수 있었던 쉬운 설명 중 하나로 볼 수 있음
1년 미만의 결과와 남은 과제
- 컴퓨트 부족과 불안정한 컴퓨트 공급자는 예상보다 훨씬 큰 어려움을 만들었음
- Reka는 회사를 시작해 자금을 조달하고 칩을 구매한 뒤 모든 것을 바닥부터 구축함
- 1년이 안 되는 기간에 Gemini Pro/GPT-3.5와 맞먹고 다수 모델을 능가했다고 함
- 데이터 파이프라인과 인간 평가 등은 아직 더 다룰 주제로 남아 있음