⚠️ 표기 관련 참고: 이 영상은 자동 생성 자막(auto-caption)만 존재하며, 회사명·모델명 등 고유명사가 다수 오인식되어 있습니다(예: "poolside" → "Pulsar", 모델명 "Lagoon" → "Laguna", 발표자 "Marah Abdin" → "Mara Abden"). 아래 노트는 문맥과 공식 발표자/컨퍼런스 정보를 바탕으로 가능한 한 정정했으나, 일부 세부 모델명·경쟁 모델명(예: "턴 360", "Deep Chem FP8 커널")은 오인식 가능성이 남아있어 원문 발음을 병기했습니다.
1. 핵심 요약
AI 코딩 파운데이션 모델 스타트업 poolside의 데이터팀(Marah Abdin)과 프리트레이닝팀(Robert McHardy)이 AI Engineer 컨퍼런스에서 발표한 실전 스케일링 노트다. poolside는 최근 엔터프라이즈 전용 배포에서 오픈소스 배포로도 전환했고, 오픈웨이트 모델 **Lagoon M(v0.1)**과 **Lagoon XS(v0.2, 코드명 XGen-2)**를 허깅페이스에 공개했다. 발표는 두 파트로 나뉜다: (1) 합성 데이터를 어떻게 설계·조합했는지(Marah), (2) 수천 개 GPU로 수백억 파라미터 모델을 학습할 때 실제로 무엇이 깨지는지와 그것을 어떻게 잡아냈는지(Robert). 핵심 메시지는 "합성 데이터는 유기 데이터의 대체재가 아니라 보완재"이며, "스케일에서는 신뢰할 수 있는 것이 없다 — 모든 것을 직접 검증해야 한다"는 두 가지다.
2. 상세 내용
2-1. 배경 — poolside의 모델 전환
- 기존에는 모델을 엔터프라이즈向으로만 배포했으나, 최근 일반 공개(오픈웨이트)로도 전환
- 오픈웨이트 모델 2종을 허깅페이스에 공개: Lagoon M(0.1), Lagoon XS(0.2) — 상세 내용을 담은 테크 리포트도 함께 공개
- 두 버전(0.1→0.2) 사이에 데이터·아키텍처·수치 안정성 측면에서 많은 것을 바꿨고, 이 발표는 그 전환 과정을 다룸
- 발표 말미에 Robert가 아직 공개되지 않은 차기 모델(Lagoon S)의 프리뷰 결과도 공유
2-2. 합성 데이터 파트 (Marah Abdin)
스케일링 시 해결한 3가지 데이터 문제
- Auto Mixer 도입: 비싼 실험(대규모 학습)에 들어가기 전, 데이터 클러스터 조합에 대해 저렴하게 스윕(sweep)할 수 있는 체계
- 웹 데이터 샘플링 재설계: 재현율(recall)을 높이는 방향으로 웹 데이터 샘플링 방식을 재검토
- 합성 데이터 비중 확대: 여러 형태의 합성 데이터를 이전보다 훨씬 많이 활용
왜 합성 데이터인가
- poolside의 입장: 합성 데이터는 유기(organic) 데이터의 대체재가 아니라 보완재
- 유기 데이터에는 암묵적으로 숨겨진 신호(implicit rationale, implicit planning, implicit structure)가 많은데, 최적의 형태로 제시되지 않은 경우가 많음
- 합성 데이터는 이런 암묵적 특징을 추출해 다른 형태(plane)로 재투영하는 통로 역할을 함 → 토큰 표현 방식뿐 아니라 모델을 "가르치는 방식" 자체를 규제(regularize)
- Lagoon XS(0.2) 프리트레이닝 믹스에서 합성 데이터 비중은 13% (포스트트레이닝 이전, 프리트레이닝 단계 기준)
- 현재 지속적으로 성장 중인 6조 토큰 코퍼스 보유
0.1→0.2 전환에서 발견한 한계 — 토큰 유니크니스 문제
- 처음에는 작은 스케일에서 quality 대 quantity 중 quality를 과도하게 우선시
- 이후 모델을 스케일업하며 학습 예산(training budget)을 늘리자, 고품질 데이터의 **반복(repetition)**이 모델을 너무 이른 시점에 saturate시키는 문제 발생
해결책 — 리프레이징(Rephrasing)
- 가장 흔한 합성 데이터 기법인 "리프레이징"을 활용 (예: Beyond Web 등에서 최근 트렌드가 된 기법)
- 범용적이고 확장 가능한 멀티모드 리프레이징 파이프라인 + 특화 파이프라인 2종 추가 구축:
- 수학(math) → 코드(code) 변환 파이프라인
- 스캔(scan/OCR) 데이터 특화 파이프라인 (STEM 문서 대상, 시드에 크게 의존하는 저비용 파이프라인이라 시드 품질에 더 투자)
- Ablation 결과: 반복된 시드를 그대로 재사용(orange)하는 것보다, 반복 토큰을 멀티모드 리프레이징으로 대체(green)했을 때 반복 문제가 일관되게 완화됨 (수치는 ablation이라 참고용)
합성 데이터 파이프라인의 모듈화 프레임워크 — 6가지 구성요소
- 시드(Seeds) — primary input
- 메타데이터 — secondary input
- 생성기(Generator) — 툴을 쓰는 에이전트이거나 프롬프트 템플릿 기반
- 보조 함수 — 필터, 검증기(validator) 등 (이 6개 요소의 조합으로 단순한 것부터 매우 복잡한 파이프라인까지 전부 구성 가능)
복잡도 스펙트럼
- 한쪽 끝: 작은 모델로도 돌아가는 저비용·확장 가능 파이프라인 (시드 의존도 높은 단순 리프레이징)
- 다른 쪽 끝: 오케스트레이션이 많이 들어간 복잡한 파이프라인 (교육용 데이터처럼 "투자할 가치가 있는" 것에 한정 사용)
- 핵심 원칙: "티처 모델의 한계에 갇히지 않는다" — 작업을 잘게 쪼개면 teacher 모델의 능력을 넘어서는 합성 데이터도 만들 수 있음
- 룰 오브 텀: 작업이 모델에게 너무 어려우면 모델은 정확성(correctness)과 다양성(diversity)을 잃음 → 그러니 작업을 더 단순하게 분해할 것
합성 데이터의 4가지 "형태(shape)"
- 포뮬러/리프레이징 — 위에서 다룬 방식
- 멀티스테이지 파이프라인/워크플로우 — 생성을 여러 단계로 쪼개 순차적으로 축적. 예: 소설을 한 번에 챕터별로 생성하는 대신, 먼저 배경/캐릭터명/캐릭터 스타일/플롯/반전을 생성한 뒤, 그걸 기반으로 챕터를 하나씩 생성 → 훨씬 나은 결과물 산출
- 크로스 도메인 포팅 — 한 모드에서 다른 모드로 이동. 예: 코드 번역, 수학 문제를 코드로 변환
- 멀티턴 롤/반복(iteration) — 선형적이지 않은 반복 구조. 예: 두 에이전트가 서로 대화하는 멀티턴 챗, 혹은 judge와 evolver가 k번 왕복하는 task evolution 파이프라인
인프라 — Hive
- 합성 데이터 생성을 위한 구성 가능한(configurable) 내부 인프라
- 에이전트 큐(queue)를 정의: 각 에이전트는 자체 프롬프트/파라미터/모델/입출력을 가짐
- 큐 진입/이탈 시점, 진입 빈도까지 설정 가능
- 에이전트 사이에는 오케스트레이터가 존재 — 생성 중인 LLM들 간의 계층 구조를 관리("policing"), 동시에 창의성을 발휘해 다음 에이전트에게 줄 지시를 동적으로 바꾸거나 다음 에이전트를 선택/스킵할 수 있음
- 오케스트레이터 위에는 슈퍼바이저가 있어 오케스트레이터를 감독하고 전역적 시야를 가짐
2-3. 프리트레이닝 파트 (Robert McHardy)
철학
- "데이터 믹스를 스테이지별로 총체적으로 다뤄야 한다"는 Marah의 관점에 더해, 학습 코드베이스의 정확성(correctness)도 총체적으로 다뤄야 한다고 강조
- 데이터가 나쁘면 좋은 모델을 학습할 수 없고, 학습 코드베이스가 나쁘면 그것도 마찬가지
- Robert의 팀은 아키텍처, 분산 학습(distributed training)을 담당
- 팀의 원칙: "아무것도 신뢰하지 않는다(we don't trust anything)" — 수십억~수천억 파라미터 모델을 수천 개 GPU로 학습할 때는 잘못될 수 있는 지점이 너무 많음
검증 기법 — 모델 레플리카 해시 체크
- 분산 데이터 병렬(DDP) 학습 시 동일 모델의 여러 레플리카를 학습하는데, **가중치는 모든 레플리카에서 항상 동일해야 한다는 불변식(invariant)**이 존재
- 가중치에 대한 해시를 계산해 주기적으로 모든 레플리카 간 비교
- 모든 해시가 동일하면 학습 계속, 하나라도 다르면 **심각한 문제가 발생한 것이므로 학습을 즉시 크래시(중단)**시킴
실제 사례 1 — 고장난 GPU (Broken GPU)
- 동일한 모델 설정·학습 데이터·구현으로 실행한 두 학습 run의 loss curve를 비교
- 한쪽은 loss curve가 매우 튀고(spiky) gradient norm이 거대함
- 원인: 해당 run에 우연히 고장난 GPU가 포함되어 있었고, 이것이 **사일런트 데이터 손상(silent data corruption)**을 유발
- 레플리카 해시 체크로 이 문제를 포착할 수 있었던 사례
실제 사례 2 — Exploding Gradients (Lagoon M.1 초기 학습)
- 학습 약 5만(50,000) 스텝 지점에서 loss가 더 이상 수렴하지 않고 평탄해짐(flattening)
- 원인 분석: LM head(unembedding) 직전 activation이 계속 커지는데, tensor parallel 방식으로 unembedding을 처리하려면 누적(accumulation) 연산이 필요했고, 이 누적이 기본적으로 BF16으로 수행되고 있었음
- activation 규모가 커지면서 BF16의 수치 정밀도로는 부족해졌고, 결과적으로 모델이 더 이상 학습되지 않음(전체 모델 트렁크로 역전파되며 치명적으로 확산)
- 해결: 해당 체크포인트에서 누적 연산을 FP32로 전환 → gradient norm이 다시 감소 추세로 전환되며 모델이 재수렴
M.1 → XGen-2로의 전환
- 위의 데이터(리프레이징 등)·수치 안정성(FP32 전환 등) 인사이트를 모두 반영해 M.1을 "새로운 세대"인 **XGen-2(Lagoon XS/0.2)**로 발전
- 개선 사항: 다양성 증가, 데이터 반복 감소, 수치 안정성 수정, 옵저버빌리티/체크 강화, 아키텍처·학습 최적화
- XGen-2: 330억(33B) 파라미터, 오픈웨이트로 무료 다운로드 가능, 사이즈 대비 가장 경쟁력 있는 모델 중 하나 (특히 코딩, 에이전틱 코딩에 집중)
차기 모델 — Lagoon S (프리뷰, 미공개)
- 33B 모델은 "꽤 작은" 편이라 스케일에서만 드러나는 이슈들을 충분히 관찰하기 어려움 → XGen-2를 테스트베드로 삼아 진짜 스케일 테스트 수행
- Lagoon S 스펙: 총 1,180억(118B) 파라미터, 활성 파라미터 80억(8B) (MoE 구조로 추정), 30조 토큰, 4,000개 GPU로 학습
- 목적: 데이터·아키텍처 개선이 스케일에서도 유지되는지, 그리고 수치 이슈가 다시 발생하는지 테스트
실제 사례 3 — Race Condition (FP8 학습)
- Lagoon S에서는 스케일 자체와 무관한 문제 발생: FP8 학습을 도입하며 오픈소스 FP8 커널(자막상 "Deep Chem" — DeepSeek 계열 FP8 커널로 추정, 정확한 명칭 불확실)을 사용
- 증상: illegal memory access, gradient에 NaN 발생 → 디버깅 끝에 해당 커널의 **레이스 컨디션(race condition)**으로 추적
- 더 위험한 점: 관측 불가능한(unobservable) 부작용도 존재 — gradient의 약 0.5%가 조용히 손상되어 랜덤 값으로 대체되는 현상. 알고 찾지 않으면 절대 알 수 없는 문제
- 수정 PR은 준비되어 있으나 아직 오픈소스 레포에 머지되지 않음(발표 중 QR코드로 공개)
- 중요한 통찰: 레이스 컨디션은 해시 체크의 사각지대(blind spot)다. 해시 체크는 "동일 가중치, 동일 데이터"라는 중복성(redundancy)이 있어야 비교가 가능한데, 실제 프로덕션 학습 런에는 forward/backward가 레플리카 간 동일하게 동작하는지 비교할 중복성이 없음 → 레이스 컨디션은 이 방식으로 잡을 수 없음. 팀은 현재 이를 dry-run 형태로라도 잡을 수 있는 별도의 해시 체커를 개발 중
초기 평가 결과 (Lagoon S, 베이스 모델 기준 — 포스트트레이닝 이전이라 참고용)
- 코딩 벤치마크(HumanEval+, BigCodeBench 등): Lagoon S가 이전 소형 모델 XGen-2보다 강하고, 훨씬 큰 모델인 Lagoon M.1보다도 강함. GLM-4.5-Air(다소 구형), 자막상 "턴 360"(정확한 모델명 불확실), 훨씬 큰 최신 모델인 DeepSeek V4 Flash/Max보다도 우수
- BigBenchHard: 최상위권 모델들과 근소한 차이로 경쟁력 있음 (1위는 아님)
- HumanEval+: 최상위권과 근접
- SWE-bench Agentless Multilingual (프리트레이닝 단계에서 에이전틱 성능의 프록시로 활용): 테스트한 모든 다른 모델보다 확실히 우수
- MMLU-Pro(지식 벤치마크): Nemotron, DeepSeek 대비 열세 — 팀이 우선순위를 두지 않은 영역(지식보다 에이전틱 코딩에 집중)이며, 데이터로 메울 수 있는 격차로 인식하고 있음
- 결론: "레시피가 유지됐고, 스케일에도 통했다(the recipe held, it scaled)" — 계속 스케일업 예정. Lagoon S는 가까운 시일 내 오픈웨이트로 공개 예정
3. 핵심 발언/인용
- "합성 데이터는 유기 데이터를 대체하는 게 아니라 보완하는 것이다. 유기 데이터에는 최적으로 표현되지 않은 암묵적 신호가 많이 숨어 있고, 합성 데이터는 그걸 추출해 다른 형태로 재투영하는 통로다." (Marah)
- "작업이 모델에게 너무 어려우면 모델은 정확성과 다양성을 잃는다. 그러니 작업을 쪼개고 더 단순하게 만들어라." (Marah)
- "우리는 아무것도 신뢰하지 않는다. 수천 개 GPU로 수백억 파라미터 모델을 학습할 때는 잘못될 수 있는 지점이 너무 많다." (Robert)
- "고장난 GPU가 사일런트 데이터 손상을 일으켰다. 설정도, 데이터도, 구현도 완전히 동일한 두 런인데 결과가 이렇게 달랐다." (Robert)
- "활성값이 커지면서 BF16 정밀도로는 부족해졌고 모델은 더 이상 학습되지 않았다. FP32로 누적 연산을 바꾸자 다시 수렴하기 시작했다." (Robert)
- "레이스 컨디션은 해시 체크의 사각지대다. 실제 학습 런에는 forward/backward가 레플리카 간 동일한지 비교할 중복성이 없기 때문이다." (Robert)
- "레시피가 유지됐고, 스케일에도 통했다. 우리는 여기서부터 계속 스케일업할 것이다." (Robert)
4. 시사점
- 합성 데이터는 "양"이 아니라 "구조"의 문제다: poolside는 합성 데이터를 유기 데이터의 대체재가 아닌, "암묵적 구조를 명시적으로 드러내는 도구"로 프레이밍한다. 단순히 데이터양을 늘리기 위한 수단이 아니라, 모델이 배우는 방식 자체를 설계하는 수단이라는 관점이 인상적이다.
- 저비용 리프레이징만으로도 반복(repetition) 문제를 상당히 완화 가능: 고품질 데이터가 부족해 반복 학습이 필요할 때, 시드 기반 리프레이징으로 토큰 다양성을 확보하는 방식은 데이터가 제한적인 환경에서 참고할 만한 실용적 해법이다.
- 합성 데이터 파이프라인을 "6개 컴포넌트의 모듈 조합"으로 표준화하면 단순 파이프라인부터 복잡한 오케스트레이션까지 같은 프레임으로 설계·관리할 수 있다 — 사내 합성 데이터 인프라를 설계할 때 참고할 만한 추상화 수준이다.
- "티처 모델의 한계에 갇히지 않는다"는 원칙: 작업을 잘게 분해하면 더 약한 모델로도 티처 모델의 능력 이상을 끌어낼 수 있다는 통찰은, 고비용 프론티어 모델 없이 합성 데이터 파이프라인을 구축해야 하는 팀에 실질적인 전략이 된다.
- 대규모 분산 학습에서 "신뢰하지 않고 검증한다"는 문화가 실제로 장애를 막는다: 레플리카 간 가중치 해시 비교라는 비교적 단순한 기법으로 고장난 GPU로 인한 사일런트 데이터 손상을 실시간으로 잡아낼 수 있었다. 대규모 학습 인프라를 운영한다면 이런 형태의 불변식(invariant) 기반 자동 검증을 도입할 가치가 크다.
- 수치 정밀도(BF16 vs FP32)는 스케일이 커질수록 숨어있던 버그를 드러낸다: activation 값이 커지는 특정 연산(unembedding 누적 등)에서 정밀도 부족이 전체 모델 학습을 망가뜨릴 수 있다는 사례는, 모델을 스케일업할 때 수치 안정성을 재검토해야 할 지점을 구체적으로 짚어준다.
- 레이스 컨디션은 해시 기반 검증으로 잡을 수 없는 사각지대라는 지적은 중요하다 — 커널 최적화(FP8 등)를 도입할 때 "정상 동작하는 것처럼 보이지만 실제로는 gradient 일부가 조용히 손상되는" 상황이 존재할 수 있음을 시사하며, 이런 문제를 잡기 위한 별도의 dry-run 검증 인프라가 필요하다는 방향성은 실무에 바로 적용 가능한 교훈이다.
- 작은 모델(XGen-2, 33B)에서 검증한 개선사항이 훨씬 큰 모델(Lagoon S, 118B)에서도 "레시피가 유지됐다"는 결론은, 신뢰할 수 있는 스케일링 방법론을 구축했다는 강한 신호이며, 모델 사이즈를 늘리기 전에 작은 스케일에서 충분히 검증하는 전략의 유효성을 보여준다.