Marin 535B 공개 학습, 실시간으로 무엇을 볼 수 있나?
Marin 535B 공개 학습은 완성된 모델 가중치만 배포하는 프로젝트가 아니라, 2026년 8월 시작된 대규모 MoE 사전학습의 설정·실험·손실 곡선·실패 가능성까지 진행 중에 공개하는 시도입니다. 기준일인 2026년 8월 23일 현재 GitHub의 Hero Run 이슈는 열려 있으며, 535B 전체 파라미터와 토큰당 활성 23B 규모의 모델을 약 18조 토큰으로 학습하는 과정이 추적되고 있습니다. 모델 성능은 아직 확정된 결과가 아니므로 현재 공개 자료에서 읽어야 할 핵심은 벤치마크 순위가 아니라 대규모 학습을 검증하는 방법입니다.
Marin은 스탠퍼드 CRFM에서 출발한 오픈 랩입니다. 일반적인 오픈웨이트 공개가 학습이 끝난 산출물을 보여 준다면, Marin은 실험 목적을 GitHub 이슈에 먼저 적고 실행 코드와 데이터 구성, Weights & Biases 로그, 잘못된 실험까지 연결합니다. 이번 Hero Run은 그 철학을 수천억 파라미터 규모로 확장한다는 점에서 관심을 끕니다. 아래에서는 숫자의 의미, 스케일링 래더가 필요한 이유, MoE의 토큰 드롭과 긴 문맥 문제, 연구자와 개발자가 실제로 확인할 항목을 구분해 설명합니다.
Marin 535B 공개 학습에서 확인된 사양은 무엇인가?
공식 GitHub 이슈의 제목은 ‘535B-A23B on 18T tokens’입니다. 535B는 모델이 가진 전체 파라미터 규모를, A23B는 한 토큰을 처리할 때 활성화되는 파라미터가 약 23B라는 뜻입니다. 모든 파라미터를 매번 계산하는 밀집 모델과 달리 Mixture-of-Experts, 즉 MoE는 라우터가 토큰마다 일부 전문가를 선택합니다. 따라서 저장해야 하는 전체 지식 용량은 크게 가져가면서도 토큰당 연산량은 상대적으로 낮추는 설계를 노립니다.
Threads의 choi.openai 게시물은 이번 실행이 11대의 GB200 NVL72에서 약 18.75조 토큰, 약 3개월 일정으로 진행된다고 소개했습니다. 이 수치는 화제성을 파악하는 참고로만 사용했고, 프로젝트의 공식 GitHub 이슈에서 18T 토큰 Hero Run과 약 100일 실행, W&B 추적 링크가 실제로 공개된 것을 확인했습니다. 하드웨어 대수와 세부 데이터 배합은 실행 중 변경될 수 있으므로 최종 모델 카드와 회고가 나오기 전에는 고정된 완성 사양으로 단정하면 안 됩니다.
이슈는 2026년 8월 18일 열렸고 ‘August milestone: launch 535B-A23B MoE’ 마일스톤에 연결돼 있습니다. 설명에는 스케일링 래더, 설정, 실행 성능을 한곳에서 추적한다고 적혀 있습니다. 또한 약 100일 동안 실제 곡선이 사전 예측과 맞는지 관찰하며, 예측에서 벗어나면 학습 동역학을 조기에 조사한다는 계획이 제시돼 있습니다. 공개된 것은 결과 발표가 아니라 진행 중인 실험 기록이라는 점이 중요합니다.
535B와 활성 23B는 어떻게 함께 성립하나?
MoE 층에는 여러 전문가 신경망이 있고 라우터가 입력 토큰을 일부 전문가에게 보냅니다. 전체 전문가의 파라미터를 합치면 535B가 되지만, 특정 토큰이 통과하는 경로는 그중 일부와 공통 계층만 포함하므로 활성 규모가 23B 수준이 됩니다. 이 표기는 모델 파일 크기와 실제 추론 연산량이 같지 않음을 알려 줍니다. ‘535B 모델이니 밀집 535B와 비용이 같다’고 읽어도 틀리고, ‘활성 23B이니 일반 23B 모델과 완전히 같다’고 읽어도 틀립니다.
MoE의 장점은 같은 토큰당 계산 예산에서 더 많은 전문가 용량을 둘 수 있다는 것입니다. 서로 다른 데이터 유형이나 패턴을 전문가가 나눠 학습할 가능성이 생깁니다. 반면 라우팅의 균형, 장치 간 통신, 일부 전문가로 토큰이 몰리는 현상, 전문가가 처리하지 못한 토큰을 버리는 토큰 드롭이 새로운 실패 원인이 됩니다. 파라미터 수가 커졌다는 사실만으로 품질 향상을 보장할 수 없는 이유입니다.
Marin 이슈는 두 개의 공유 전문가와 여러 활성 전문가를 조합하는 설계를 설명합니다. 공유 전문가는 모든 토큰이 통과하는 안정적인 바탕을 제공하고, 라우팅된 전문가는 추가 용량을 담당합니다. 프로젝트 팀은 토큰 드롭이 높아지는 상황에서도 학습이 완전히 멈추지 않도록 공유 경로를 강화했다고 설명합니다. 다만 이것은 설계 의도이며, 긴 실행 동안 실제 손실과 평가가 얼마나 안정적인지는 공개 로그와 후속 회고로 검증해야 합니다.
Marin 535B 스케일링 래더는 왜 먼저 필요한가?
535B 모델을 곧바로 전체 토큰 예산으로 실행하면 설정 오류 하나가 막대한 계산 자원을 낭비할 수 있습니다. 스케일링 래더는 작은 모델과 짧은 실행에서 같은 학습법을 시험한 뒤, 크기가 커질 때 손실과 기울기, 라우팅이 어떻게 변할지 예측하는 절차입니다. Marin은 이 단계의 비용을 전체 연산량의 약 1%로 설명합니다. 작은 추가 비용으로 대형 실행의 중단 위험을 줄이는 보험에 가깝습니다.
공식 이슈에는 스케일링 래더가 잡아낸 구체적 사례도 적혀 있습니다. 과거 실행에서 토큰 구간을 늘릴수록 gradient norm이 4 이상으로 커지는 현상을 발견했고, logit z-loss를 적용하는 수정으로 이어졌습니다. 이후 절제 실험에서는 이 수정이 없을 때 큰 배치 같은 특정 조건에서 학습이 중간에 폭주할 수 있음을 확인했다고 합니다. 작은 실행이 단순한 축소판이 아니라 실패 모드를 드러내는 진단 도구였던 셈입니다.
래더는 최종 손실 숫자 하나만 예측하지 않습니다. 학습 진행률에 따른 기울기 변화, 전문가별 토큰 분배, 토큰 드롭률, 평가 점수의 궤적을 비교할 기준선을 만듭니다. 예를 들어 기울기가 초반 40% 동안 증가하다가 학습률이 줄면서 내려오는 패턴을 작은 실행에서도 보았다면, 대형 실행의 같은 현상을 즉시 장애로 오판하지 않을 수 있습니다. 반대로 예측 범위를 벗어나면 수십 일 뒤가 아니라 그 시점에 원인을 조사할 수 있습니다.
대규모 학습에서 이 접근이 중요한 이유는 재현성의 단위가 최종 체크포인트보다 넓기 때문입니다. 동일한 코드라도 하드웨어 토폴로지, 통신 구현, 데이터 순서, 배치 크기, 장애 복구 시점이 달라지면 결과가 변할 수 있습니다. 사전에 가설과 예측을 기록하면 결과가 나온 뒤 설명을 끼워 맞추는 선택적 해석도 줄일 수 있습니다.
공개 로그에서는 무엇을 봐야 하나?
가장 먼저 볼 값은 training loss입니다. 손실이 전반적으로 내려가더라도 작은 모델에서 예측한 곡선과의 차이가 커지는지 확인해야 합니다. 순간적인 스파이크 하나보다 추세와 복구 여부가 중요합니다. 데이터 배합이 바뀌는 구간이나 학습률 전환점에서는 곡선의 형태가 달라질 수 있으므로, 실행 설정과 함께 읽어야 합니다.
두 번째는 gradient norm입니다. 지나치게 커지면 불안정성의 신호가 될 수 있고, 갑자기 작아지면 학습이 제대로 진행되지 않는 상황을 의심할 수 있습니다. 그러나 정상 범위는 모델과 학습 단계마다 다릅니다. Marin이 작은 규모의 래더를 비교 기준으로 삼는 이유도 절대 임계값 하나로 대형 모델을 판단하기 어렵기 때문입니다.
세 번째는 MoE 고유 지표입니다. 전문가별 토큰 수가 한쪽으로 몰리는지, 라우터가 균형을 유지하는지, 용량을 넘겨 버려지는 토큰 비율이 커지는지 확인해야 합니다. 평균 손실이 좋아 보여도 일부 전문가만 과도하게 사용되면 전체 용량을 효율적으로 활용하지 못할 수 있습니다. 장치 간 all-to-all 통신 시간이 늘어나면 계산 유닛이 기다리는 시간도 커져 실제 학습 속도가 떨어집니다.
네 번째는 처리량과 하드웨어 상태입니다. tokens per second, model FLOPs utilization, 통신 시간, 재시작과 장애 기록을 함께 보면 이론적 모델 설계가 실제 클러스터에서 얼마나 효율적인지 알 수 있습니다. 대규모 학습은 모델 연구와 분산 시스템 운영이 결합된 작업이므로, 손실이 안정적이어도 처리량이 예상보다 낮으면 일정과 토큰 예산이 흔들립니다.
다섯 번째는 평가 궤적입니다. 완성 시점의 벤치마크만 보면 중간에 어떤 능력이 먼저 생기고 정체됐는지 알 수 없습니다. 다만 진행 중 체크포인트의 점수는 데이터 오염, 평가 설정, 작은 표본 변동의 영향을 받을 수 있습니다. 한 번의 순위보다 동일한 평가 파이프라인에서 예상 궤적과 일관되게 움직이는지를 보는 편이 안전합니다.
토큰 드롭은 왜 긴 문맥에서 더 어려워지나?
각 전문가는 한 배치에서 처리할 수 있는 토큰 용량이 제한됩니다. 라우터가 특정 전문가에게 너무 많은 토큰을 보내면 용량을 초과한 토큰을 다른 경로로 돌리거나 버려야 합니다. Marin 이슈는 이전 시험에서 문맥 길이를 4K에서 65K로 늘릴 때 토큰 드롭이 약 7%에서 40%까지 증가한 사례를 언급합니다. 이번 구현에서는 4K 구간의 드롭을 약 3% 수준으로 줄였지만, 긴 문맥 확장에서는 다시 높아질 가능성을 명시했습니다.
문맥이 길어지면 한 시퀀스 안의 토큰이 비슷한 전문가를 선호할 수 있고, 배치 안 시퀀스 수가 줄어 라우팅 다양성이 낮아질 수 있습니다. Marin이 사전학습을 4K 길이에서 시작하려는 이유는 같은 토큰 배치에서도 더 많은 독립 시퀀스를 섞어 전문가 균형을 개선하기 위해서입니다. 이후 8K, 65K, 최종적으로 더 긴 문맥을 단계적으로 시험하는 계획이 제시돼 있습니다.
팀은 드롭 없는 ragged all-to-all 구현을 도입하거나, 전문가 용량 계수를 높이거나, 시퀀스 수준 균형을 적용하는 선택지를 검토합니다. 각각 대가가 있습니다. 드롭을 없애면 통신과 구현 복잡성이 커질 수 있고, 용량을 늘리면 메모리와 계산 여유가 줄어듭니다. 중간에 균형 방식을 바꾸면 이미 전문화된 전문가가 다시 적응해야 할 수 있습니다. 따라서 긴 문맥 숫자만 크게 만드는 것보다 전환 구간의 손실과 라우팅 안정성을 공개하는 것이 더 유용합니다.
Marin의 오픈 개발은 오픈웨이트와 무엇이 다른가?
오픈웨이트 모델은 학습이 끝난 가중치를 내려받아 추론하거나 파인튜닝할 수 있게 합니다. 그러나 어떤 원시 데이터에서 어떤 필터를 거쳤는지, 실패한 실행은 무엇이었는지, 하이퍼파라미터를 왜 바꿨는지 알기 어려운 경우가 많습니다. Marin은 실험을 GitHub 이슈로 사전 등록하고, 코드 변경을 리뷰하며, 실행 로그와 분석을 다시 이슈에 연결하는 ‘오픈 개발’을 지향합니다.
이 방식은 세 가지 검증 가능성을 높입니다. 첫째, 결과가 나온 뒤 성공한 실험만 골라 공개하는 문제를 줄입니다. 둘째, 다른 연구자가 논문의 짧은 방법 절만 보고 구현을 추측하는 대신 실제 설정과 변경 내역을 확인할 수 있습니다. 셋째, 모델 가중치가 나오기 전에도 데이터 처리와 분산 학습, 평가 방법에 기여할 수 있습니다.
그렇다고 완전한 재현이 자동으로 보장되는 것은 아닙니다. 수백억에서 수천억 파라미터 학습은 같은 하드웨어와 예산을 구하기 어렵고, 공개 데이터라도 이용 조건과 저장 비용이 장벽이 됩니다. 실시간 로그가 많을수록 어떤 지표가 결정에 영향을 줬는지 해설이 필요합니다. 공개된 실행을 누구나 동일하게 반복할 수 있다는 의미보다, 의사결정과 증거를 감시하고 부분적으로 재현할 수 있는 범위가 넓어진다는 의미로 이해하는 편이 정확합니다.
Marin의 기존 8B 모델은 코드, 데이터 구성, 여러 체크포인트, 평가 결과를 모델 카드로 연결했습니다. 프로젝트 공식 소개는 성공과 실패를 모두 프로그램적으로 기록하는 것을 핵심으로 내세웁니다. 이번 535B 실행이 끝난 뒤에도 최종 모델 카드가 데이터 계보, 라이선스, 평가, 한계, 중간 체크포인트를 얼마나 충실히 묶는지가 오픈 개발의 실제 완성도를 판단하는 기준이 됩니다.
연구자와 개발자는 Marin 535B를 어떻게 활용할 수 있나?
첫째, 대형 모델을 직접 훈련하지 않더라도 스케일링 실험 설계를 배울 수 있습니다. 모델 크기별 손실을 맞추는 방법, 전체 예산의 일부를 위험 제거에 배분하는 법, 중단 조건을 사전에 정의하는 법은 더 작은 사내 모델에도 적용할 수 있습니다. 특히 한 번의 장기 실행보다 작은 파일럿 여러 개에서 실패 조건을 찾는 운영 방식이 중요합니다.
둘째, MoE 인프라 지표를 관찰할 수 있습니다. 모델 논문은 정확도와 파라미터 수를 강조하지만 실제 배포 비용은 전문가 라우팅, 통신, 메모리 배치, 체크포인트 저장과 복구에 좌우됩니다. 공개 이슈에 연결된 구현 설명과 로그를 함께 보면 알고리즘과 시스템 병목이 어디서 만나는지 파악할 수 있습니다.
셋째, 평가의 시간축을 분석할 수 있습니다. 특정 벤치마크가 토큰 수에 따라 언제 개선되는지, 데이터 배합 전환 뒤 어떤 능력이 변하는지, 작은 모델의 예측이 큰 모델에서도 유지되는지 연구할 수 있습니다. 단, 진행 중 로그를 독립된 공식 성과처럼 홍보해서는 안 됩니다. 체크포인트와 평가 코드, 데이터 오염 검사를 확인하고 프로젝트의 후속 분석과 함께 해석해야 합니다.
넷째, 공개 연구에 기여할 수 있습니다. GitHub 이슈는 질문과 설계 토론을 남길 수 있고 코드 저장소는 재현 예제와 수정 제안을 받습니다. 의미 있는 기여는 단순히 손실 그래프를 중계하는 것보다, 특정 이상 구간을 재현하거나 평가 코드의 오류를 찾고, 더 작은 설정에서 대안을 시험해 근거를 제시하는 형태에 가깝습니다.
Marin 535B 결과를 평가할 때 피해야 할 오해
첫 번째 오해는 전체 파라미터 수를 성능 순위로 보는 것입니다. 535B라는 숫자는 아키텍처 용량을 나타낼 뿐 데이터 품질, 활성 계산량, 학습 안정성, 사후학습, 평가 공정성을 대신하지 않습니다. MoE 모델은 활성 파라미터와 메모리·통신 비용을 함께 비교해야 합니다.
두 번째 오해는 손실이 내려가면 성공이 확정됐다고 보는 것입니다. 학습 손실은 데이터 예측 능력을 보여 주지만 실제 지시 수행, 사실성, 코딩, 긴 문맥, 안전성은 별도 평가가 필요합니다. 사전학습 모델과 대화형 모델의 용도도 다릅니다. Hero Run이 끝나도 후속 정렬과 제품화 없이 일반 챗봇과 직접 비교하기 어렵습니다.
세 번째 오해는 실시간 공개가 곧 무결성을 보장한다는 생각입니다. 로그가 공개돼도 지표 이름과 집계 방식, 누락 구간, 재시작 정책을 알아야 제대로 해석할 수 있습니다. 공개성은 검증의 재료를 제공하지만 검증 자체를 대신하지 않습니다. 중요한 주장에는 실행 ID, 설정 커밋, 평가 코드와 원시 결과를 연결해야 합니다.
네 번째 오해는 예정된 토큰 수와 문맥 길이를 이미 달성한 결과로 표현하는 것입니다. 18T 토큰과 약 100일은 실행 계획이며 하드웨어 장애, 처리량 저하, 실험 판단에 따라 토큰 지평이 조정될 수 있습니다. 공식 이슈도 일정이 지연되면 전체 토큰 예산의 약 25% 지점까지는 학습률 감쇠와 데이터 혼합을 조정해 새 종료 지점에 맞출 수 있다고 설명합니다.
다섯 번째 오해는 Threads 요약을 1차 출처로 사용하는 것입니다. 소셜 게시물은 새 소재를 빠르게 발견하는 데 유용하지만 숫자와 상태가 압축되고 맥락이 생략됩니다. 이번 글은 choi.openai의 최신 게시물을 발견 경로로만 사용하고, 모델 표기·실행 상태·스케일링 이유·긴 문맥 계획은 Marin GitHub 이슈와 프로젝트 공식 문서에서 다시 확인했습니다.
실시간 학습을 볼 때 사용할 체크리스트
- GitHub Hero Run 이슈가 열려 있는지, 최근 설정 변경과 실행 ID가 무엇인지 확인합니다.
- 전체 파라미터 535B와 활성 파라미터 23B를 구분해 기록합니다.
- 누적 토큰 수와 목표 토큰 수를 분리하고 예정치를 달성치처럼 쓰지 않습니다.
- 손실뿐 아니라 gradient norm, 토큰 드롭, 전문가 균형, 처리량을 함께 봅니다.
- 작은 스케일링 래더의 예측 범위와 Hero Run의 실제 궤적을 비교합니다.
- 데이터 배합, 학습률, 문맥 길이가 바뀐 지점을 그래프에 표시합니다.
- 평가 점수에는 체크포인트, 평가 코드, 표본 수, 오염 검사 정보를 붙입니다.
- 장애와 재시작, 설정 변경이 최종 토큰 예산에 미친 영향을 확인합니다.
- 최종 모델 카드가 데이터 계보, 라이선스, 위험과 한계를 포함하는지 검토합니다.
개인 개발자가 직접 로그를 저장해 분석하려면 먼저 공개 대시보드의 이용 조건과 API 제한을 확인해야 합니다. 화면을 과도하게 스크래핑하기보다 프로젝트가 제공하는 리포트와 내보내기 기능을 이용하고, 그래프를 재게시할 때는 실행 링크와 확인 시각을 남기는 편이 좋습니다. 진행 중 값은 바뀔 수 있으므로 캡처만으로 장기 결론을 내리지 않습니다.
Marin 535B 공개 학습의 의미와 남은 질문
이번 실행의 가장 큰 의미는 ‘큰 오픈 모델 하나가 더 나온다’는 데만 있지 않습니다. 프런티어 규모의 학습에서 어떤 위험을 먼저 줄이고, 어떤 지표로 계속할지 중단할지 판단하며, 실패와 수정 과정을 어떻게 공개 연구 자산으로 바꾸는지를 관찰할 수 있다는 데 있습니다. 완성된 가중치보다 학습 방법 자체가 공동의 연구 대상이 됩니다.
남은 질문도 많습니다. 스케일링 래더가 535B 실행의 손실과 평가를 얼마나 정확히 예측하는지, 긴 문맥 확장에서 토큰 드롭을 어느 수준으로 통제하는지, 통신 구현이 안정적인 처리량을 유지하는지 확인해야 합니다. 데이터 배합과 라이선스, 중복 제거, 오염 검사도 최종 평가의 신뢰성을 좌우합니다. 사전학습 뒤 어떤 후속학습과 안전 평가를 적용할지도 아직 결과가 아닙니다.
따라서 2026년 8월 23일 시점의 결론은 신중해야 합니다. Marin 535B-A23B는 성능 우승이 확정된 모델이 아니라, 약 18조 토큰 규모의 대형 MoE 훈련을 공개 검증 가능한 연구 과정으로 만들려는 진행 중 실험입니다. 앞으로 볼 것은 파라미터 숫자보다 예측과 실제의 차이, 문제를 발견한 뒤 수정한 근거, 최종 산출물까지 이어지는 데이터와 코드의 연결성입니다.
기업의 사내 LLM 학습에도 적용할 수 있는 운영 원칙
Marin과 같은 규모의 클러스터가 없어도 운영 원칙은 축소해 적용할 수 있습니다. 먼저 본 실행 전에 전체 예산의 작은 비율을 파일럿에 배정하고, 파일럿이 통과해야 할 손실 범위와 처리량, 메모리 사용량, 평가 점수를 문서로 고정합니다. 결과가 나온 뒤 기준을 바꾸면 실패한 설정을 성공처럼 해석하기 쉬워집니다. 파일럿과 본 실행은 가능한 한 같은 데이터 파이프라인과 평가 코드를 사용해야 규모 차이 외의 변수를 줄일 수 있습니다.
둘째, 모델 지표와 시스템 지표를 같은 타임라인에 기록합니다. 손실 스파이크가 데이터 배치 전환 때문인지, 특정 장치 장애와 재시작 때문인지, 통신 지연 때문에 유효 배치가 달라졌기 때문인지 한 화면에서 연결할 수 있어야 합니다. 코드 커밋, 설정 파일 해시, 데이터 스냅샷, 컨테이너 이미지, 체크포인트 식별자를 실행 ID에 묶으면 며칠 뒤에도 원인을 재구성하기 쉽습니다.
셋째, 중단과 복구 정책을 사전에 정합니다. 손실이 예측 범위를 몇 단계 연속 벗어날 때 멈출지, 처리량이 목표 아래로 떨어지면 토큰 예산과 학습률을 어떻게 조정할지, 체크포인트 손상 시 어느 시점으로 돌아갈지를 정합니다. 장기 실행에서 무조건 계속하는 것과 순간 이상에 과민하게 중단하는 것 모두 비용을 키웁니다. 비교 가능한 작은 실행이 있으면 정상적인 변동과 실제 장애를 구분하는 근거가 됩니다.
넷째, 최종 보고서에는 성공한 설정만 남기지 않습니다. 폐기한 데이터 혼합, 불안정했던 학습률, 느렸던 통신 구현과 제외 이유를 기록하면 다음 팀이 같은 실패를 반복하지 않습니다. 보안이나 라이선스 때문에 원시 데이터를 공개할 수 없는 기업이라도 데이터 계보, 필터 규칙, 평가 절차, 변경 이력을 내부 감사자가 확인할 수 있게 만들 수 있습니다. 공개성의 수준은 달라도 검증 가능한 의사결정이라는 핵심은 유지할 수 있습니다.
참고 자료
'LLM' 카테고리의 다른 글
| Qwen3.8-27B 비검열 모델, 안전장치 제거 원리와 검증법 (0) | 2026.08.23 |
|---|---|
| OpenAI o3 종료 8월 26일, 무엇을 바꿔야 할까? (0) | 2026.08.23 |
| Claude Mythos 5 보안 스캔, 누가 어떻게 쓸 수 있나? (0) | 2026.08.22 |
| Hugging Face 오픈 모델 2026 보고서, 무엇이 달라졌나? (0) | 2026.08.22 |
| Gemini 3.7 Flash API 가격·마이그레이션 총정리 (0) | 2026.08.21 |
