Olmo-core 3: MoE가 커질수록 비싸지는 학습 경로를 다시 설계하다

MoE(Mixture of Experts)는 토큰마다 일부 expert만 선택해 계산한다.[1] 그래서 “전체 파라미터는 크게, 토큰당 연산량은 작게” 만들 수 있다. 그러나 모델 전체를 저장하고 갱신해야 하는 비용, 토큰을 expert가 있는 GPU로 보내는 비용까지 사라지는 것은 아니다. 이 글에서는 활성 연산량과 별개로 늘어나는 저장·통신·상태 관리 비용을 편의상 용량 비용(capacity tax)이라고 부르겠다.

Ai2가 2026년 10월 1일 공개한 Olmo-core 3는 이 병목을 겨냥한 PyTorch 기반 오픈소스 학습 프레임워크다. 새 언어 모델이나 추론 서버가 아니라, 대규모 MoE를 여러 GPU에 배치하고 학습시키는 인프라다. 발표에는 DDP 기반 상주 expert, expert·pipeline parallelism, 분산 optimizer, GPU-resident routing, grouped GEMM, MXFP8가 포함됐다.[1]

이 글의 결론부터 말하면 Olmo-core 3의 가치는 “누구나 trillion-parameter 모델을 바로 학습할 수 있다”는 데 있지 않다. 가중치뿐 아니라 모델을 만드는 병렬화 방식, kernel, 실험 설정, 실패한 최적화까지 검토할 수 있게 했다는 점이 더 중요하다. 반대로 소수 GPU에서 모델을 미세조정하거나 이미 만들어진 모델을 서빙하려는 팀에는 너무 낮은 층의 도구다.

왜 오늘 Olmo-core 3를 골랐나

이번 선정 범위는 2026년 10월 15일 04:05 KST 기준 최근 30일이다. Olmo-core 3 발표는 14일 전이고, v3.0.0 릴리스는 10월 2일 00:17 KST에 게시됐다. 릴리스는 최소 PyTorch를 2.10으로 올렸고, MoE DDP·expert-parallel stack과 기술 보고서용 reference script를 포함한다.[2]

공개 범위도 분명하다. 코드는 Apache License 2.0으로 배포되는 오픈소스 소프트웨어다. 재배포할 때는 라이선스 사본 제공, 수정 파일 고지, 해당되는 저작권·특허·상표·귀속 고지 보존, 원본에 NOTICE가 있을 경우 그 귀속 고지 보존 조건을 확인해야 한다.[3] 다만 Olmo-core 3는 학습 프레임워크 릴리스다. 이번 발표 자체가 새 모델 가중치, 새 학습 데이터 전체, 완성된 trillion-parameter checkpoint를 배포했다는 뜻은 아니다.

인기나 급상승은 총 star 하나로 판정하지 않았다. 2026년 10월 15일 04:05 KST GitHub API 조회 당시 저장소는 1,719 stars, 345 forks였고, API의 마지막 push 시각은 10월 15일 03:57 KST였다.[4] 여기에 10월 2일의 major release가 확인된다.[2] 이는 최근 코드 활동과 외부 관심이 함께 관측된다는 두 신호이지, 대중적 폭발을 증명하는 성장 시계열은 아니다. 과거 star snapshot이나 GitHub Trending 이력을 확보하지 못했으므로 “하루에 몇 star씩 급증했다”는 증가율은 만들지 않았다.

주목받는 이유는 가설로 구분해야 한다. 차세대 Olmo의 MoE 학습 기반이라는 공식 발표, 실제 reference configuration 공개, 대규모 학습에서 반복되는 weight 이동을 줄이는 설계가 연구·인프라 팀의 관심을 끌었을 가능성이 크다.[1] 그러나 이 기능들이 stars나 forks의 증가를 직접 일으켰다는 인과 자료는 없다.

공개된 것과 공개되지 않은 것

Olmo-core 저장소에는 Python library source, 테스트, 문서, 공식 학습 script와 Dockerfile이 있다. PyPI에서는 ai2-olmo-core로 설치할 수 있고, source 개발 설치도 안내한다.[5]

공개 범위를 층별로 나누면 다음과 같다.

따라서 Olmo-core 3를 “open-weight 모델”이나 “source-available 제품”으로 부르는 것은 부정확하다. 이것은 Apache-2.0 오픈소스 소프트웨어다. 그 위에서 만들 모델의 weights·data·recipe는 각 산출물의 별도 라이선스와 공개 범위를 다시 확인해야 한다.

문제의 핵심: sparse compute가 storage와 통신을 없애지는 않는다

MoE에서 토큰이 네 expert만 통과하더라도 전체 expert weight와 optimizer state는 저장돼야 한다.[6] 학습 중에는 gradient를 올바른 replica끼리 합치고, 토큰을 선택된 expert가 있는 rank로 보내고, 출력은 원래 토큰 위치로 돌려놓아야 한다. 총 파라미터가 늘면 활성 연산량과 별개로 storage·optimizer·routing·communication 비용이 증가한다.

기술 보고서는 dense Olmo에 사용하던 full-reshard FSDP 경로가 각 wrapped unit의 forward와 backward 주위에서 weight를 반복해 gather·reshard하는 지점을 비교 기준으로 삼는다. Olmo-core 3의 custom DDP 경로는 각 rank의 model partition을 accumulation window 동안 GPU에 상주시킨 뒤 optimizer step마다 gradient를 동기화하고, FP32 main weight와 optimizer state는 분산 optimizer로 shard한다.[6]

여기서 “DDP가 FSDP보다 항상 빠르다”는 결론을 내리면 안 된다. 보고서의 비교는 full-reshard FSDP endpoint와 Olmo의 DDP+EP stack 사이의 시스템 비교다. 메모리를 더 쓰고 통신을 덜 하는 다른 FSDP retention policy나 HSDP는 서로 다른 지점에 있다.[6] 실제 선택은 GPU memory 여유, expert 수, accumulation 횟수, interconnect, checkpoint 형식에 따라 달라진다.

설계는 네 개의 비용을 따로 줄인다

Expert parallelism: weight 대신 token을 보낸다

Expert parallelism(EP)은 expert 집합을 여러 GPU에 나눈다. 각 GPU가 모든 expert를 들고 있지 않고, router가 선택한 expert가 있는 rank로 token row를 이동시킨다. 메모리는 줄지만 dispatch·combine 통신과 load imbalance가 생긴다.

Olmo-core 3의 rowwise 경로는 peer별 block을 만들고 다시 푸는 전통적인 all-to-all 배치 대신, route-indexed token row를 미리 할당한 symmetric buffer에 직접 배치한다. 이 방식도 공짜는 아니다. route map 생성, 고정 capacity storage, indexed write ordering 비용이 있고, 이 비용이 permutation·temporary buffer·host stall 절약보다 작을 때만 이득이다.[6]

Pipeline parallelism: layer를 나눈다

Pipeline parallelism(PP)은 연속된 layer를 stage로 나눠 GPU group에 배치한다. 한 GPU가 보관할 layer 수는 줄지만 stage 간 activation 이동과 pipeline bubble이 생긴다. EP가 “어느 expert를 보관할지”를 나눈다면 PP는 “어느 layer를 보관할지”를 나눈다. 둘을 함께 쓸 때 topology mapping과 microbatch 수가 성능을 좌우한다.

Distributed optimizer: 학습 상태를 나눈다

Adam 계열 학습은 model parameter 외에도 FP32 main weight와 optimizer state를 유지할 수 있다. Olmo-core 3는 이 상태를 rank에 분산한다. 단, checkpoint 저장·복구와 HF export까지 같은 sharding 계약을 이해해야 한다. 학습은 되지만 resume 뒤 optimizer state가 달라지거나 export가 unsupported routing을 조용히 바꾸는 경로는 허용하면 안 된다. v3.0.0은 여러 비호환 export 조합을 명시적으로 거부하고 normalization·tokenizer 설정 보존을 강화했다.[2]

GPU-resident routing과 grouped GEMM: 작은 대기를 합친다

Routing metadata를 CPU로 왕복시키면 CPU가 split 정보를 읽을 때 GPU queue가 멈출 수 있다. GPU-resident routing은 rank 간 라우팅 합의 정보와 토큰 이동 metadata를 GPU memory에 유지해 CPU 동기화 지점을 줄인다. Grouped GEMM은 expert별로 잘게 나뉜 matrix multiplication을 한 묶음으로 실행해 작은 kernel launch와 낮은 occupancy 문제를 줄인다.[1][6]

핵심은 각 최적화를 독립 feature처럼 켜는 것이 아니다. 계산이 빨라지면 통신 비중이 커질 수 있고, 통신량을 줄이려는 format conversion이 더 비쌀 수 있다. end-to-end training step에서 병목이 실제로 이동했는지 봐야 한다.

패키지 설치와 공식 예제의 실행 전제

공식 reference script는 v3.0.0 source checkout과 별도 GPU 의존성을 전제한다.[7] 기본 package는 Python 3.10 이상과 torch>=2.10,<2.14를 요구한다.[8] PyTorch는 GPU·driver·CUDA·운영체제 조합에 맞는 공식 설치 명령으로 먼저 설치해야 한다. 아래는 호환되는 PyTorch가 이미 준비된 환경에서 Olmo-core package만 고정하는 예시다.[5]

python -m venv .venv
source .venv/bin/activate
python -m pip install --upgrade pip
python -m pip install 'ai2-olmo-core==3.0.0'

그러나 대규모 MoE 실험은 base package 설치만으로 끝나지 않는다. flash-attn-4, NVSHMEM 기반 rowwise 경로, grouped_gemm, Transformer Engine, DeepEP 등은 선택한 backend와 GPU architecture에 따라 별도 설치나 build가 필요하다.[5][7] 공식 Docker image도 dependency를 담을 뿐 Olmo-core package 자체는 설치하지 않으며, 다른 hardware·driver·CUDA 조합에서는 그대로 동작하지 않을 수 있다고 저장소가 경고한다.[5]

재현성을 우선하면 mutable main 대신 tag를 고정한다.

git clone https://github.com/allenai/OLMo-core.git
cd OLMo-core
git checkout v3.0.0
python -m pip install -e '.[all]'

v3.0.0의 .[all]은 fla 의존성 때문에 torch>=2.13,<2.14를 요구한다. 기본 wheel의 PyTorch 범위와 같지 않으므로 현재 cluster image의 CUDA 조합을 먼저 확인해야 한다.[8]

다음은 일반 사용자를 위한 smoke test가 아니라, v3.0.0 repository root에서 기술 보고서용 reference configuration을 시작하는 generic launch 형태다. PyPI package만 설치한 환경에는 src/examples 경로가 없으며, 공개 데이터만으로 즉시 실행되는 독립 튜토리얼도 아니다.[7]

torchrun --nproc-per-node=8 \
  src/examples/olmo_ddp/moe_8l_ddp.py \
  olmo-core-3-reference

이 명령을 노트북에서 바로 실행할 수 있다고 기대하면 안 된다. reference script는 beaker extra와 FlashAttention 4, 쓰기 가능한 /workspace, Ai2 data mix 읽기 권한을 전제한다. DeepEP v2 경로는 checkout 위치도 필요하다. production configuration은 노드당 GPU 8개를 가정하며, 공개된 headline configuration은 2노드부터 64노드까지 걸쳐 있다.[7]

이하의 도입 순서, 관측 지표, 보안 통제와 upgrade gate는 Ai2가 규정한 필수 절차가 아니라 공개 구현과 일반적인 분산 학습 위험을 바탕으로 정리한 저자의 운영 제안이다. 조직의 인프라와 위협 모델에 맞게 조정해야 한다.

실제 도입을 다음 세 단계로 나누면 실패 원인을 분리하기 쉽다.

1. Configuration build test: CPU에서 script가 model·optimizer·trainer config를 만들고 parameter count를 고정하는지 확인한다.
2. Single-node smoke test: 합성 또는 조직이 소유한 작은 dataset으로 forward, backward, checkpoint, resume까지 검증한다.
3. Multi-node scaling test: 같은 model·batch 조건을 유지한 채 EP·PP degree와 transport만 바꾸고 throughput·memory·network tail을 비교한다.

공식 script를 복사해 production training을 시작하기보다, 먼저 데이터 경로·checkpoint 목적지·실험 추적 callback·optional backend를 조직 환경에 맞춰 제거하거나 고정하는 편이 낫다.

실제 활용 시나리오

1. MoE architecture 연구

Expert 수, top-k, shared expert, load-balancing loss, routing 방식이 quality와 system cost에 미치는 영향을 함께 측정할 때 적합하다. Olmo-core 3는 채택한 기법뿐 아니라 token gerrymandering처럼 balancing score가 좋아져도 실제 workload 균형은 나빠질 수 있는 실패 사례를 공개한다.[1][6]

평가 지표를 router auxiliary loss 하나로 두지 말고 rank별 token count의 분산, expert별 drop·capacity, step time의 p50/p95/p99, validation loss를 함께 기록해야 한다.

2. 새 GPU cluster의 학습 stack 검증

공개된 production-throughput reference는 B300 환경에서 측정됐다.[6][7] 이를 H100·H200 또는 다른 accelerator 환경으로 옮길 때, rowwise EP와 block all-to-all, BF16과 MXFP8, recompute 정책을 비교하는 harness로 쓸 수 있다. 이때 목표는 발표 수치를 재현하는 것이 아니라 자기 topology에서 병목 경계를 찾는 것이다.

3. 기존 FSDP MoE의 migration 평가

현재 full-reshard FSDP가 microbatch마다 weight materialization 비용을 크게 내고 있다면 DDP+EP를 비교할 이유가 있다. 다만 API 하나만 바꾸는 migration이 아니다. 공개 example도 DDP+EP 쪽과 FSDP/HSDP 쪽이 router, optimizer, sparse kernel까지 달라 단일 변수 비교가 아니라고 명시한다.[7]

Migration acceptance는 동일한 parameter count뿐 아니라 checkpoint round-trip, 첫 N step loss trajectory, gradient norm, resume 후 sample order, export 결과를 포함해야 한다.

성능 수치는 무엇을 증명하나

공식 발표의 대표 결과는 세 가지다.[1]

• 예비 시스템 비교에서는 8개 B300 GPU에서 8-layer BF16, 약 3.2B active @ 47B total, top-4 random routing, EP8, pipeline parallelism 없음 조건으로 측정했다. 새 DDP+EP stack은 52.0K tokens/s/GPU, 이전 full-reshard FSDP 기반 stack은 19.4K tokens/s/GPU를 기록했다. Router·optimizer·sparse kernel까지 함께 달라진 composed-stack 결과이므로 DDP와 FSDP API만의 2.7배 차이로 해석하면 안 된다.[6][7]
• 4개 B300 GPU의 controlled benchmark는 8-layer, 3.172B active @ 13.037B total, 32 routed experts와 top-4·shared expert 1개, EP4, uniform routing 조건이었다. Attention projection, MLP, rowwise EP transport에 MXFP8를 함께 적용한 mode는 BF16 기준 54.74K tokens/s/GPU보다 20.6% 높은 throughput을 보였고, peak active memory는 103.4 GiB에서 약 95.0 GiB로 줄었다. 각 mode는 fresh distributed job 3회와 10-step timing window로 측정한 짧은 시스템 benchmark이며 장기 학습 품질 증거는 아니다.[6]
• 512개 B300 GPU에서 측정한 Ultra-128E 구성은 58.36B active @ 1.200T total, 128 routed experts, top-4 random routing, MXFP8, per-layer recompute, EP8·PP8 조건에서 관측된 최고값 858 useful-model TFLOP/s/GPU를 기록했다. 이는 반복 평균이 아니며 보고서에는 원인이 규명되지 않은 더 낮은 throughput의 반복 실행도 기록돼 있다. MFU는 MXFP8 peak가 아니라 B300 dense BF16 peak를 분모로 계산했다. 58.41B active @ 2.380T 구성은 EP32·PP8, MXFP8, per-layer recompute와 DeepEP v2를 사용한 9-step capacity test로, sustained throughput이나 장기 학습 결과가 아니다.[6][7]

이 수치는 모두 공급자 보고 결과다. 2.7배는 8×B300의 특정 47B MoE와 이전 full-reshard 구현 비교다. MXFP8 결과는 work가 expert에 균등 분배된 조건이다. 1.2T 시험은 model quality가 아니라 system performance를 보기 위해 random routing을 썼고, 2.38T는 full training이 아닌 짧은 capacity test다.[1]

그러므로 이 결과를 “1.2T 모델의 장기 학습 안정성과 품질까지 검증했다”거나 “MXFP8는 언제나 21% 빠르다”고 일반화하면 안 된다. 독립 검증 자료도 아직 충분하지 않다. 도입 판단에는 동일한 hardware generation, driver·CUDA, precision, sequence length, global batch, active·total parameter, EP·PP degree, routing distribution, recompute, warm-up과 측정 window를 보존한 자체 benchmark가 필요하다.

운영 비용은 GPU 시간만이 아니다

다음은 수학적 공식이 아니라 총비용에서 빠뜨리기 쉬운 항목을 분해한 개념도다.

training_cost = gpu_time
              + interconnect_time
              + checkpoint_storage_and_io
              + failed_run_recovery
              + kernel_and_driver_maintenance
              + engineer_oncall_time

측정 단위도 throughput 하나로 끝내면 안 된다.

• 진행률: useful tokens/s/GPU, step time p50/p95/p99, 재시작을 제외한 completed token
• 연산: SM utilization, GEMM shape별 duration, MFU를 계산한 peak 기준
• 메모리: allocated·reserved·peak active, fragmentation, optimizer·activation·expert weight 비중
• 통신: dispatch/combine bytes, rank별 duration, straggler, NVLink·fabric utilization
• routing: expert별 token 분포, capacity overflow, auxiliary metric과 실제 imbalance의 차이
• 신뢰성: checkpoint 시간, resume 성공률, lost work, NaN·OOM·collective timeout 빈도

특히 cost per token은 실패한 run까지 포함해야 한다. 평균 step이 빨라도 10시간마다 collective hang으로 재시작한다면 유효 비용은 더 높다. Benchmark에는 성공한 best run뿐 아니라 run 수, 제외 기준, 분산을 남긴다.

보안, 데이터 무결성, 체크포인트 신뢰 경계

학습 framework는 source를 공개했다고 자동으로 안전해지지 않는다.

첫째, optional CUDA extension과 third-party kernel은 build 때 임의 코드를 실행한다. Package name만 고정하지 말고 wheel·container digest, compiler, CUDA toolkit, GPU driver, source commit을 provenance에 남긴다. 공식 image도 자기 cluster와 호환된다는 보증이 아니다.[5]

둘째, training script에는 object storage credential, experiment tracker token, checkpoint upload 권한이 연결되기 쉽다. Worker container에 장기 credential을 bake하지 않고, 플랫폼이 지원한다면 짧은 수명의 workload identity와 최소 권한을 우선 검토한다. Checkpoint callback의 upload·delete 권한도 분리해 검토한다. v3.0.0의 checkpoint-ready callback은 자체적으로 upload나 delete를 수행하지 않는다고 명시한다.[2]

셋째, dataset boundary 오류는 조용한 품질 손실로 이어질 수 있다. 이번 릴리스는 EOS가 없는 truncated document를 다음 문서와 합쳐 일부 token이 학습에 도달하지 못할 수 있던 경로를 수정하고 metadata boundary 사용 옵션과 cache fingerprint 강화를 추가했다.[2] 이는 직접적인 보안 취약점이라기보다 데이터 무결성과 재현성 문제다. 다만 외부 데이터와 cache 산출물의 출처·변환 과정을 통제하는 조직에서는 학습 데이터 공급망 관리 항목에 포함할 수 있다.

넷째, checkpoint와 HF export를 신뢰 경계로 다룬다. 외부 checkpoint의 pickle 계열 payload를 무검증으로 읽지 말고, 가능한 안전한 tensor format과 허용 목록을 사용한다. Export 후에는 tensor name·shape·dtype뿐 아니라 tokenizer special ID, normalization, router 설정이 원본과 같은지 round-trip test한다.

실패 모드와 도입·업그레이드 gate

Token gerrymandering

Load-balancing score가 좋아져도 token이 실제로 고르게 분산되지 않을 수 있다. 평균 metric 하나 대신 expert·rank별 histogram과 tail을 함께 본다.[1]

값에 따라 달라지는 kernel 시간

같은 matrix shape라도 operand 값이 달라지면 GEMM 시간이 달라질 수 있다고 보고서는 지적한다.[6] 두 kernel을 비교할 때 shape만 맞추고 서로 다른 initialization이나 activation distribution을 쓰면 결과가 왜곡된다.

통신·계산 overlap의 역효과

별도 GPU stream에서 communication과 computation을 겹친다고 항상 빨라지지 않는다. resource contention과 synchronization 비용 때문에 end-to-end 시간이 늘 수 있다.[1] Timeline에서 overlap 비율보다 최종 step time과 jitter를 본다.

OOM이 아닌 partial degradation

한 rank의 routing imbalance, NVLink error, 느린 storage flush는 job을 죽이지 않고 모든 rank를 기다리게 할 수 있다. Health check는 process 생존이 아니라 step progress와 rank별 tail을 기준으로 한다.

Resume는 되지만 동일하지 않은 학습

Attention backend나 RoPE 구현 변경은 checkpoint shape가 같아도 부동소수점 결과를 바꿀 수 있다. v3.0.0도 legacy fused attention을 새 구현으로 옮길 때 저정밀도 gradient를 포함한 결과가 numerically identical하지 않다고 경고한다.[2] Upgrade gate에 짧은 shadow resume와 loss·gradient drift 허용 범위를 둔다.

저자가 제안하는 upgrade 검증 순서는 다음과 같다.

1. Dependency lock과 container digest를 고정한다.
2. Config build test로 parameter count와 parallel degree를 검증한다.
3. Synthetic data로 forward/backward/checkpoint/resume/export를 실행한다.
4. 실제 분포를 닮은 작은 dataset에서 old/new stack을 같은 초기값으로 비교한다.
5. Rank 하나 지연, storage throttle, network degradation을 주입해 timeout과 복구를 확인한다.
6. Throughput뿐 아니라 quality proxy, memory, communication tail, failed-run cost를 승인 기준에 넣는다.
7. Upgrade rollback이 checkpoint format과 dataset cursor를 실제로 되돌릴 수 있는지 시험한다.

어떤 팀에 맞고, 어떤 팀에는 맞지 않나

적합한 경우

• 여러 노드의 NVIDIA GPU cluster에서 MoE pretraining을 직접 수행한다.
• Router·expert architecture와 distributed training system을 함께 연구한다.
• 기존 FSDP MoE에서 weight materialization과 optimizer memory가 병목이다.
• Kernel과 collective를 profile하고 CUDA dependency를 유지할 인력이 있다.
• Open model을 weights뿐 아니라 training decision과 실패 기록까지 감사하려 한다.

부적합한 경우

• 완성된 모델을 내려받아 inference만 하려 한다.
• 단일 GPU 또는 소수 GPU에서 LoRA·SFT를 수행한다.
• Managed training service 밖의 driver·CUDA·collective 운영을 맡을 인력이 없다.
• B300 공급자 benchmark를 자기 H100 cluster의 비용표로 바로 쓰려 한다.
• 모든 dataset과 완성 checkpoint까지 이번 릴리스에 포함됐다고 기대한다.

대안도 명확하다. 추론이 목표라면 vLLM 같은 inference runtime이 맞고, 소규모 fine-tuning은 Transformers·PEFT처럼 abstraction이 높은 도구가 단순하다. 대규모 MoE 학습이 필요하지만 이미 Megatron-Core 운영 경험이 있다면 새 stack 도입 비용과 기존 checkpoint·monitoring 통합 비용을 비교해야 한다. Olmo-core 3의 장점은 보편적 우월성이 아니라 Olmo 생태계의 실험과 설계 근거가 공개된 통합 경로에 있다.[1][6]

다만 보고서의 모든 실험 경로가 v3.0.0 release에서 재현되는 것은 아니다. 특히 two-batch overlap 결과는 pre-merge branch에서 측정됐으며, v3.0.0의 ExpertParallelConfig와 reference script는 해당 schedule을 지원하지 않는다.[7] 보고서에 기록된 실험 결과와 release tag에서 실행 가능한 기능을 구분해야 한다.

결론: Open weights 다음에는 open training decisions가 필요하다

Olmo-core 3는 MoE의 “적은 활성 파라미터” 뒤에 숨은 비용을 드러낸다. Expert 전체 저장, optimizer state, token routing, grouped compute, pipeline stage, checkpoint와 export가 하나의 training step에서 서로 영향을 준다. 한 부분의 microbenchmark를 빠르게 만드는 것보다 end-to-end 비용과 실패 경계를 함께 공개한 점이 중요하다.

다만 공개된 수치의 경계는 엄격히 지켜야 한다. 2.7배는 특정 B300·47B 비교이고, MXFP8 21%는 controlled configuration이며, 1.2T는 random routing system test, 2.38T는 짧은 capacity test다.[1] 이것은 차세대 Olmo의 품질이나 장시간 학습 안정성을 아직 증명하지 않는다.

오픈 모델 생태계의 다음 기준은 가중치를 다운로드할 수 있는가만이 아니다. 어떤 병렬화와 precision을 골랐는지, 어떤 최적화가 실패했는지, checkpoint와 data boundary가 어떻게 검증되는지, benchmark가 무엇을 증명하지 않는지까지 살펴야 한다. Olmo-core 3는 그 기준을 실제 코드와 실험 설정으로 검토할 수 있게 한다. 대규모 MoE를 직접 만드는 팀이라면 성능 숫자보다 이 감사 가능성에서 도입 가치를 찾는 편이 정확하다.

Sources

[1] https://huggingface.co/blog/allenai/olmocore3 — Introducing Olmo-core 3 [2] https://github.com/allenai/OLMo-core/releases/tag/v3.0.0 — Olmo-core v3.0.0 release [3] https://github.com/allenai/OLMo-core/blob/v3.0.0/LICENSE — Olmo-core v3.0.0 LICENSE [4] https://api.github.com/repos/allenai/OLMo-core — GitHub repository API [5] https://github.com/allenai/OLMo-core/blob/v3.0.0/README.md — Olmo-core v3.0.0 README [6] https://allenai.org/papers/olmocore3 — Olmo-core 3 technical report [7] https://github.com/allenai/OLMo-core/blob/v3.0.0/src/examples/olmo_ddp/README.md — Olmo-core 3 DDP examples [8] https://github.com/allenai/OLMo-core/blob/v3.0.0/pyproject.toml — Olmo-core 3 package metadata