공개된 학습 사례에서 배우기 — 무엇을 시도했고 무엇이 실패했나

• 들어가며 — 보고서에서 읽어야 할 것은 점수표가 아닙니다
• 고른 사례와 확인 기준
• Llama 3 405B — 장애가 상수인 규모에서 설계하기
• DeepSeek-V3와 Kimi K2 — 스파이크를 없애는 두 층위
• Olmo 계열 — 안정성 수정이 아키텍처에 남긴 흔적
• OPT-175B와 BLOOM — 실패를 기록하는 문화의 원형
• SmolLM3와 Marin — 작은 규모에서 공개된 실험 노트
• 가로질러 읽기 — 반복되는 것과 끝내 안 나오는 것
• 마치며 — 재현할 수 없는 부분을 아는 것이 읽는 기술입니다

들어가며 — 보고서에서 읽어야 할 것은 점수표가 아닙니다

기술 보고서를 벤치마크 표만 보고 닫으면 얻을 것이 거의 없습니다. 점수는 우리 상황에 옮겨지지 않지만, 무엇이 망가졌고 어떻게 고쳤는가는 규모가 달라도 그대로 옮겨집니다.

이 글은 공개 보고서와 로그북에서 그 부분만 뽑았습니다. 손실 스파이크와 그 대응, 하드웨어 고장률과 체크포인트 주기의 관계, 데이터 혼합을 중간에 바꾼 효과, 그리고 스케일링 결정의 근거입니다. 각 사례 끝에는 보고서가 말하지 않은 것을 따로 적었습니다. 재현 가능성을 판단하려면 그쪽이 더 중요합니다.

고른 사례와 확인 기준

전부 2026년 8월 2일에 링크를 확인했습니다. 인용한 수치는 원문이나 원문을 직접 인용한 보도에서 가져왔고, 확인하지 못한 것은 본문에 그렇게 적었습니다.

Llama 3 405B — 장애가 상수인 규모에서 설계하기

가장 인용할 가치가 있는 것은 이 보고서의 중단 통계입니다. 16,384장의 H100 80GB로 54일을 돌리는 동안 예기치 않은 중단이 419건 있었고, 보고서는 그중 78퍼센트를 확인되었거나 의심되는 하드웨어 문제로 분류합니다. 세부 분류는 보고서 표를 인용한 데이터센터 업계 보도에 따르면 다음과 같습니다.

54일에 419건이면 평균 3.1시간에 한 번입니다. 이 규모에서 장애는 예외가 아니라 상수입니다. 그래서 설계가 달라집니다. 사람이 개입해 재시작하는 운영은 성립하지 않고, 장애 감지와 노드 교체, 재개가 자동으로 돌아야 합니다.

여기서 곧바로 나오는 실무 계산이 체크포인트 주기입니다. 평균 장애 간격 3.1시간에 저장이 5분 걸린다면 최적 주기는 43분 안팎이고, 그래도 전체 시간의 20퍼센트 이상이 저장과 재계산으로 사라집니다. 계산 과정은 LLM Ops 글에 넣어 두었습니다.

병렬화는 텐서, 컨텍스트, 파이프라인, 데이터의 4차원 조합을 썼고, BF16 기준 모델 FLOPs 활용률은 38~43퍼센트 구간으로 보고되었습니다. 이 숫자를 기억해 두시면 좋습니다. 잘 튜닝된 대규모 학습도 이론 성능의 절반을 못 씁니다. 자체 클러스터에서 30퍼센트대가 나온다고 해서 반드시 뭔가 잘못된 것은 아닙니다.

보고서가 말하지 않는 것: 학습 데이터의 정확한 구성 비율과 필터링 분류기의 임계값, 실패해서 버린 사전 실험들, 그리고 장애 감지와 자동 복구를 담당한 내부 운영 소프트웨어의 구현입니다. 통계는 공개되었지만 그 통계를 만든 도구는 공개되지 않았습니다.

DeepSeek-V3와 Kimi K2 — 스파이크를 없애는 두 층위

두 보고서를 같이 읽으면 손실 스파이크를 대하는 서로 다른 전략이 보입니다.

DeepSeek-V3는 671B 파라미터 중 토큰당 37B를 활성화하는 MoE를 14.8T 토큰으로 학습했고, 전체 학습에 2.788M H800 GPU 시간이 들었다고 보고합니다. 여기에는 컨텍스트 확장 119K 시간과 사후 학습 5K 시간이 포함됩니다. 그리고 보고서에는 이런 문장이 있습니다. 전체 학습 과정에서 복구 불가능한 손실 스파이크를 겪지 않았고 롤백을 수행하지 않았다는 것입니다.

이 안정성이 어디서 왔는지는 보고서가 직접 단언하지 않습니다. 다만 함께 기술된 것들이 힌트입니다. FP8 혼합정밀 학습을 도입하면서 정밀도가 민감한 연산은 고정밀로 남겼고, 파이프라인 버블을 줄이는 DualPipe로 계산과 통신을 겹쳤으며, MoE 로드 밸런싱을 보조 손실 없이 처리하는 방식을 썼습니다. 마지막 항목이 특히 중요합니다. 보조 손실로 전문가 사용을 균등화하면 그 손실이 주 목적 함수와 싸우면서 불안정을 만드는데, 그 항을 없앤 것입니다.

후속 회고 논문인 Insights into DeepSeek-V3는 하드웨어 쪽 설계를 다룹니다. 멀티헤드 잠재 어텐션으로 토큰당 KV 캐시를 70.272KB까지 줄였다는 수치가 나오는데, 같은 표에서 Llama-3.1 405B는 516.096KB입니다. 그리고 클러스터 네트워크로 다중 평면 팻트리 토폴로지를 썼다고 적습니다. 모델 구조 결정이 곧 인프라 결정이라는 사례입니다.

Kimi K2는 다른 층위에서 같은 문제를 풉니다. 총 1.04T 파라미터 중 32B를 활성화하는 MoE를 15.5T 토큰으로 학습하면서 손실 스파이크가 관측되지 않았다고 보고하는데, 그 수단이 옵티마이저입니다. Muon 옵티마이저에 QK-Clip을 결합한 MuonClip을 써서, 업데이트 직후 어텐션의 질의와 키를 재조정해 로짓 폭주를 억제했습니다. 학습률 일정은 WSD 계열로, 500스텝 워밍업 뒤 10T 토큰을 상수 학습률로 돌리고 남은 5.5T를 코사인으로 감쇠했다고 기술합니다. 사전학습 컨텍스트는 4,096입니다.

두 접근의 차이를 정리하면 이렇습니다.

보고서가 말하지 않는 것: 두 보고서 모두 성공한 최종 구성만 기술합니다. FP8 도입 과정에서 어떤 레이어가 먼저 터졌는지, MuonClip의 클리핑 임계값을 어떻게 찾았는지, 그 전에 몇 번의 실패한 런이 있었는지는 나오지 않습니다. 그리고 두 곳 모두 데이터 구성은 공개하지 않습니다.

Olmo 계열 — 안정성 수정이 아키텍처에 남긴 흔적

Allen AI의 Olmo 3은 7B와 32B 모델을 내면서 체크포인트와 데이터셋, 의존성까지 전체 개발 파이프라인을 공개했습니다. 이 완전 공개가 중요한 이유는 벤치마크 점수 때문이 아니라, 제3자가 오염 여부와 데이터 출처를 직접 감사할 수 있는 유일한 형태이기 때문입니다.

기술적으로 눈여겨볼 것은 안정성 수정이 하이퍼파라미터가 아니라 아키텍처에 남았다는 점입니다. Olmo 3은 OLMo 2에서 안정성 개선으로 확인된 구성을 유지합니다. RMSNorm을 쓰되 정규화 위치를 후행으로 두고, 어텐션 계산 전에 질의와 키에 정규화를 한 번 더 걸며, 임베딩에는 가중치 감쇠를 적용하지 않습니다.

세 가지 모두 사전학습을 시작한 뒤에는 바꿀 수 없는 결정입니다. 그래서 이 사례가 주는 교훈은 실무적으로 냉정합니다. 불안정 대응의 가장 좋은 시점은 첫 번째 스파이크가 나기 전입니다. 이미 3T 토큰을 돌린 상태에서 정규화 위치를 바꾸는 선택지는 존재하지 않습니다.

보고서가 말하지 않는 것: 데이터와 체크포인트는 공개되었지만, 이 규모를 다시 돌릴 계산 자원이 대부분의 조직에는 없습니다. "완전 공개"는 감사 가능성을 주지만 재현 가능성을 주지는 않습니다. 이 구분은 분명히 해 두는 편이 좋습니다.

OPT-175B와 BLOOM — 실패를 기록하는 문화의 원형

지금의 기술 보고서들이 매끄러운 최종본이라면, 2022년의 두 사례는 날것의 기록입니다.

OPT-175B의 chronicles 디렉터리에는 전체 로그북 PDF와 함께 진행률 10퍼센트, 27퍼센트, 56퍼센트, 그리고 최종 시점의 업데이트 노트가 들어 있습니다. 저장소 설명은 이것을 "OPT-175B 학습에 사용한 전체 로그북과, 과정에서 마주친 어려움을 정리한 노트들"이라고 소개합니다. 로그북에는 반복된 재시작, 손실 발산, 학습 도중의 하이퍼파라미터 변경, 하드웨어 교체가 날짜와 함께 남아 있습니다.

여기서 배울 것은 특정 기술이 아니라 기록 자체가 산출물이라는 태도입니다. 학습 중 어떤 결정을 왜 내렸는지가 그 시점에 기록되지 않으면, 두 달 뒤에는 아무도 재구성하지 못합니다.

BLOOM은 프랑스 Jean Zay 슈퍼컴퓨터에서 48개 노드, 노드당 A100 80GB 8장, 총 384장으로 약 3.5개월간 학습했고 1,082,990 계산 시간을 썼습니다. 자원 계획에서 눈에 띄는 것은 하드웨어 장애 가능성 때문에 예비 노드 4개를 따로 확보해 두었다는 점입니다. 노드 간 연결은 노드당 100Gbps Omni-Path 링크 4개였고, 공용 슈퍼컴이라 파일 시스템을 다른 사용자와 공유했습니다.

384장 규모에서 예비 노드를 8퍼센트 남짓 확보한 이 결정은 그대로 옮겨 쓸 수 있는 실무 규칙입니다. 자원 신청서에 예비 노드를 쓰지 않으면, 노드 하나가 죽는 순간 전체 학습이 대기열 맨 뒤로 갑니다.

보고서가 말하지 않는 것: 두 사례 모두 당시의 소프트웨어 스택(구버전 Megatron-DeepSpeed, 구버전 PyTorch) 위에 있어 코드를 그대로 돌릴 수 없습니다. 그리고 로그북의 판단들은 당시 하드웨어와 프레임워크 제약에 묶여 있으므로, 결론이 아니라 사고 과정만 가져와야 합니다.

SmolLM3와 Marin — 작은 규모에서 공개된 실험 노트

앞의 사례들은 대부분의 조직이 흉내 낼 수 없는 규모입니다. 그래서 더 실용적인 두 사례를 덧붙입니다.

SmolLM3는 3B 모델을 11.2T 토큰으로 학습하면서 데이터 혼합을 어떻게 결정했는지를 공개했습니다. 3단계 사전학습으로 웹, 코드, 수학의 비율을 단계마다 바꾸고, 그 비율은 3B 모델을 50B에서 100B 토큰 규모로 돌리는 소규모 실험으로 정했다고 기술합니다. 1단계 구성은 웹 85퍼센트(그중 다국어 12퍼센트), 코드 12퍼센트 같은 식으로 숫자까지 나와 있습니다.

이 방법론이 핵심입니다. 11.2T 토큰짜리 결정을 100B 토큰짜리 실험으로 내린 것입니다. 혼합 비율 후보를 몇 개 잡고 작은 규모에서 돌려 비교한 다음 본 학습에 적용하는 절차는 3B에서도 30B에서도 똑같이 씁니다. 함께 공개된 Smol Training Playbook은 384장 규모 작업에서 손실 스파이크를 디버깅한 과정처럼 논문에 안 들어가는 부분을 다룹니다. 384장은 많은 조직이 실제로 만질 수 있는 규모입니다.

Marin은 스탠퍼드 쪽에서 시작한 공개 실험실로, 모든 연구 시도를 GitHub 이슈로 먼저 등록하고 그 이슈가 일종의 사전 등록 역할을 하게 합니다. 8B 모델을 12T 토큰 이상으로 학습하는 과정에서 데이터 혼합을 계속 다듬었고, 후반 냉각 단계에서 학습률을 낮추면서 데이터를 고품질 쪽으로 바꾸는 방식을 회고 문서로 남겼습니다.

사전 등록이라는 관행이 특히 가져갈 만합니다. 실험 결과를 보고 나서 가설을 쓰면 거의 모든 결과가 성공으로 보입니다. 돌리기 전에 무엇을 기대하는지 적어 두는 것만으로 이 편향이 크게 줄어듭니다.

보고서가 말하지 않는 것: SmolLM3의 소규모 대리 실험이 본 규모에서 얼마나 잘 예측했는지는 정량적으로 검증되지 않았습니다. 작은 규모 실험이 큰 규모로 옮겨가지 않는 경우가 실제로 존재하므로, 이 방법론은 "완벽한 예측"이 아니라 "근거 없는 추측보다 나은 절차"로 받아들이는 것이 맞습니다.

가로질러 읽기 — 반복되는 것과 끝내 안 나오는 것

일곱 사례를 겹쳐 놓으면 반복되는 패턴이 다섯 개 보입니다.

1. 손실 스파이크 대응에는 네 층위가 있고, 아래로 갈수록 싸고 위로 갈수록 늦습니다. 목적 함수 설계, 아키텍처, 옵티마이저, 운영 순으로 개입 비용이 커집니다. 그런데 대부분의 팀은 가장 비싼 운영 층위에서만 대응합니다.
2. 장애율은 GPU 수에 비례하고, 체크포인트 주기와 자동화 수준을 결정합니다. 384장에서는 예비 노드로 충분하고, 16,384장에서는 자동 감지와 교체가 필수입니다. 규모가 열 배가 되면 운영 방식이 달라져야 합니다.
3. 데이터 혼합은 처음부터 끝까지 고정되지 않습니다. 여러 사례가 단계별 혼합과 후반 냉각 구간의 고품질 데이터 전환을 기술합니다. "데이터셋을 정하고 학습을 시작한다"는 모델은 현실과 다릅니다.
4. 스케일링 결정은 소규모 대리 실험에서 나옵니다. 큰 결정일수록 작은 실험이 근거가 됩니다. 실험 설계 능력이 GPU 수보다 중요해지는 지점입니다.
5. 모델 구조 결정은 인프라 결정입니다. KV 캐시 크기를 줄이는 어텐션 설계가 서빙 비용을 바꾸고, MoE 선택이 네트워크 토폴로지 요구를 바꿉니다.

반대로, 거의 모든 보고서에서 끝내 나오지 않는 것도 정리해 둡니다. 이 목록을 알고 있어야 보고서를 과신하지 않습니다.

• 실패한 런의 수와 비용. 최종 런의 GPU 시간은 나오지만, 거기 도달하기까지 태운 자원은 거의 공개되지 않습니다. 공개된 GPU 시간을 그대로 예산 근거로 쓰면 크게 모자랍니다.
• 데이터의 정확한 구성과 필터 임계값. 비율은 나와도 원본 출처와 중복 제거 파라미터, 품질 분류기의 컷오프는 대개 빠집니다.
• 하이퍼파라미터 탐색 과정. 최종 값만 나오고, 그 값을 어떻게 찾았는지는 나오지 않습니다.
• 운영 인력과 도구. 몇 명이 몇 교대로 붙었는지, 어떤 내부 도구가 장애를 감지했는지가 빠집니다. 이것이 실제로는 가장 큰 진입 장벽입니다.
• 평가 세트 오염 검사의 상세. 검사했다는 서술은 있어도 방법과 임계값, 발견된 겹침의 규모까지 적는 경우는 드뭅니다.

마치며 — 재현할 수 없는 부분을 아는 것이 읽는 기술입니다

공개 보고서는 성공의 설계도가 아니라 한 팀이 특정 제약 아래 내린 결정의 기록입니다. 16,384장에서 유효했던 자동 복구 설계가 8장짜리 노드에서는 과잉이고, 384장에서 통했던 수동 대응이 16,384장에서는 성립하지 않습니다.

그래서 읽는 방법은 이렇게 정리됩니다. 숫자는 그 팀의 규모에 묶여 있으니 가져오지 말고, 결정의 근거를 가져오십시오. 왜 이 시점에 체크포인트 주기를 정했는가, 왜 이 층위에서 불안정을 막기로 했는가, 왜 이 실험으로 저 결정을 내렸는가. 그리고 보고서에 없는 항목의 목록을 항상 함께 들고 다니십시오. 없는 것이 무엇인지 아는 사람만이 그 보고서를 근거로 계획을 세울 수 있습니다.

병렬화의 기본기는 멀티 GPU 학습의 네 가지 병렬화에, 이 결정들을 실행할 도구는 LLM 학습 스택 지도와 Slurm 실무 가이드에 정리해 두었습니다.