Lessons from Generating 12 Trillion Synthetic Tokens — Bogdan Gaza, DatologyAI

한 줄 핵심

12조 개 규모의 synthetic token을 만들며 겪은 병목과 해결책을 통해, 대규모 합성 데이터 생성은 데이터 품질보다도 스토리지 메타데이터, 체크포인팅, 크로스 인프라 스케줄링, 추론 튜닝 같은 인프라 설계가 성패를 좌우한다는 점을 보여주는 영상이다.

시간별 요약

1. 0:00
   소개 오늘 발표의 주제는 trillion token 규모의 pre-training을 위해 synthetic data를 확장하면서 얻은 엔지니어링 교훈이다. 대규모 학습에서 웹 데이터만으로는 한계가 있어 합성 데이터가 필요한 이유와, 이를 어떻게 대규모로 운영했는지를 다룬다.
2. 0:12
   12조 토큰 규모의 synthetic data 12조 토큰 규모의 synthetic data 생성 경험을 바탕으로, web·math·code 전반에서 대규모 합성 데이터를 만드는 과정과 그로부터 얻은 교훈을 공유한다. 단순한 실험 수준이 아니라 실제 운영 가능한 규모의 파이프라인이 핵심이다.
3. 0:27
   합성 데이터가 필요한 이유: 데이터 벽 스케일링 법칙 때문에 더 나은 모델을 만들려면 계산량과 데이터량이 모두 급격히 늘어나지만, 웹에는 사용할 수 있는 고품질 데이터가 유한하다. 그래서 인터넷 데이터의 한계를 보완하는 고품질 synthetic data가 필요하다.
4. 1:47
   DatologyAI가 하는 일 DatologyAI는 pre-training과 mid-training 데이터를 정제하는 데이터 정제 서비스로, 고객 데이터에서 고품질 샘플을 골라낸 뒤 합성 데이터 레시피를 적용해 더 큰 데이터셋으로 확장한다. 핵심 역할은 좋은 원천 데이터를 찾아내고 이를 대규모 학습용 데이터로 바꾸는 것이다.
5. 2:22
   BeyondWeb 결과 BeyondWeb은 synthetic data 레시피로, 같은 성능을 더 작은 모델이나 더 적은 토큰으로 달성할 수 있음을 여러 benchmark로 보여준다. 일부 경우에는 3B 모델이 8B 모델과 비슷한 성능을 내고, 기존 방식 대비 2.7x~5.3x 적은 토큰으로 같은 평균 정확도를 달성한다.
6. 4:11
   rephrasing이 동작하는 방식 synthetic data는 무작정 생성하는 것이 아니라, 고객 데이터셋에서 고품질 문서를 골라 rephrasing·reframing하는 방식으로 만든다. 원본 문서를 씨앗으로 삼아야 데이터 분포의 모드를 그대로 복제하는 문제를 줄이고, 실제로 쓸 만한 다양성과 품질을 확보할 수 있다.
7. 5:51
   출발점: Slurm과 Kubernetes 초기에는 synthetic data가 제품 파이프라인과 분리된 연구용 Slurm 클러스터에서 돌아가고, 핵심 시스템은 Kubernetes 기반이라 코드와 운영이 이원화되어 있었다. 이 구조는 느리고 오류가 많았으며 GPU 활용률도 낮아, 학습과 합성 데이터를 하나의 흐름으로 묶는 방향이 필요했다.
8. 6:31
   기술 스택: Ray, KubeRay, vLLM 현재 파이프라인은 Kubernetes를 중심으로 Ray, Spark, vLLM을 조합해 동작하며, 데이터는 S3 호환 스토리지에 저장한다. 서로 다른 환경(AWS, GCP, on-prem)에서도 돌아가야 하므로, 배포와 오케스트레이션을 Kubernetes 기반으로 표준화하는 것이 중요하다.
9. 7:41
   현재 구성: HyperPod AWS HyperPod 위에서 H100 클러스터를 Kubernetes로 운영하면서, Spark와 Ray 작업을 on-demand CPU/GPU 자원에 맞춰 분리해 실행한다. 내부 job scheduler가 여러 클러스터를 조율해, 필요한 작업을 적절한 자원군으로 보내는 구조를 갖췄다.
10. 8:40
    하나의 워크플로: 정제, 합성, 학습, 평가 정제(curate)부터 synthetic 생성, training, eval까지를 하나의 workflow로 엮으면 연구와 엔지니어링이 같은 인프라와 코드 경로를 공유할 수 있다. 그 결과 실험 속도와 신뢰성이 올라가고, 대규모 반복 실험을 운영하기 쉬워진다.
11. 9:30
    대규모 운영에서 얻은 엔지니어링 교훈 trillion token 규모에서는 데이터 품질 외에도 시스템 병목이 실질적인 한계가 된다. 특히 스토리지, GPU 안정성, 크로스 인프라 스케줄링, 추론 설정이 전체 처리량과 비용을 좌우한다.
12. 9:40
    병목 1: S3 메타데이터 수백만 개의 파티션에서 S3 메타데이터를 하나씩 가져오면 rate limit과 느린 metadata store 때문에 9~11일이 걸릴 수 있다. 이를 batch list request로 바꾸고 page size를 키우면 약 2시간으로 줄일 수 있어, idle GPU를 크게 줄일 수 있다.
13. 12:29
    병목 2: GPU 불안정성과 체크포인팅 대규모 GPU 작업에서는 머신 다운이나 GPU 불량이 반드시 발생하므로, 중간 결과를 잃지 않도록 checkpointing과 resumable execution이 필요하다. 파티션 크기를 적절히 줄이고 진행 상태를 S3에 주기적으로 저장하면, 실패해도 재시도로 복구 가능한 구조를 만들 수 있다.
14. 14:59
    병목 3: 크로스 인프라 오케스트레이션 synthetic data 작업은 하나의 GPU 클러스터가 아니라 여러 클러스터와 클라우드에 분산되어 돌아가므로, CPU와 GPU 자원을 함께 고려한 스케줄링이 필요하다. 계산 자원 유형별 전용 pool을 두고 atomic하게 배치하면, 자원 단절 없이 더 안정적으로 확장할 수 있다.
15. 17:53
    병목 4: 추론 튜닝 vLLM이나 SGLang 같은 추론 스택은 batch size, speculative decoding 같은 하이퍼파라미터를 체계적으로 튜닝해야 한다. 이런 파라미터를 grid search로 최적화하면 throughput을 약 40%까지 끌어올릴 수 있다.
16. 18:53
    정리 대규모 synthetic data 운영에서는 스케일에 맞는 메타데이터 처리, 자동 복구, CPU/GPU의 원자적 스케줄링, 추론 파라미터 탐색이 핵심이다. 이 네 가지가 갖춰져야 trillions 규모의 작업을 안정적으로 돌릴 수 있다.
17. 19:13
    30B에서 12T synthetic tokens로 2024년 말에는 Slurm 클러스터에서 30B 수준의 synthetic tokens만 만들 수 있었지만, 이후에는 web에서 7T, math와 code에서 5T를 추가로 생성하며 총 12T 규모까지 확장했다. 앞으로도 더 나은 synthetic recipe를 찾기 위한 개선과 실험이 계속된다.
18. 20:02
    채용 data infrastructure, cloud infrastructure, 일반 인프라, program manager 등 다양한 역할을 채용 중이다. 대규모 데이터·인프라 문제를 함께 푸는 팀에 관심이 있으면 직접 संपर्क하라는 메시지로 마무리된다.

실무 인사이트

• 대규모 synthetic data의 성패는 생성 모델 자체보다 S3 메타데이터, 체크포인팅, 스케줄링 같은 운영 병목을 얼마나 빨리 제거하느냐에 달려 있다.
• 정제된 원본 문서를 씨앗으로 삼아 rephrasing하는 방식은, 무작위 합성보다 품질과 다양성을 함께 확보하는 실전적 접근이다.
• 학습·합성·평가를 하나의 워크플로로 묶으면 연구 속도가 빨라질 뿐 아니라 GPU 유휴 시간을 줄여 비용 효율도 개선된다.