NVIDIA Neotron Elastic AI 모델: 6B·9B·12B 한 번에 얻는 이유는?

Generated image

NVIDIA가 흥미로운 대형 언어 모델 아키텍처를 내놓았습니다. 이름은 Neotron Elastic. 표면적으로는 12B(120억) 파라미터 모델이지만, 그 안에서 6B·9B 모델을 그대로 뽑아 쓸 수 있는 구조를 갖습니다.

추가 학습이나 별도 체크포인트 없이, 한 번 학습한 모델에서 여러 크기를 즉시 추출해 여러 종류의 GPU·VRAM 환경에 맞춰 유연하게 배포하는 것이 핵심입니다.

아래에서는

기존 mixture-of-experts 접근과 무엇이 다른지
6B·9B·12B가 한 번의 학습으로 어떻게 함께 최적화되는지
수학·과학 추론용 모델로서 어느 정도 성능을 내는지
실사용 관점에서 기대할 점과 현실적인 제약

을 차례로 정리합니다.

NVIDIA Neotron Elastic AI가 풀고자 한 문제

대형 언어 모델을 실제 환경에 올릴 때 가장 먼저 마주치는 제약은 VRAM입니다.

12B급 모델을 FP32(4바이트/파라미터)로 올리면 대략 48GB VRAM이 필요합니다.
일부 고급 GPU는 가능하지만, 일반적인 24GB·32GB 카드에서는 현실적이지 않은 규모입니다.

그래서 지금까지는

프루닝(pruning) 후 재학습으로 손상 보정
교사-학생(distillation) 구조로 작은 모델을 따로 학습

같은 방식으로 모델 크기를 줄이는 대신 다시 비용을 지불하는 구조가 일반적이었습니다.

Neotron Elastic은 이 흐름을 바꾸려고 합니다. 하나의 12B 모델 안에 6B, 9B를 "내장"해 두고, 필요할 때 마치 러시아 인형처럼 안쪽 모델만 꺼내 쓰는 발상을 채택합니다.

즉,

6B 모델을 쓰려고 12B 전체를 내려받을 필요가 없고
각각을 따로 학습·관리할 필요도 없도록 설계되어 있습니다.

mixture-of-experts와 무엇이 다를까?

많이 사용되는 Mixture-of-Experts(MoE) 모델은, 여러 전문가 블록을 두고 질문에 따라 일부 전문가만 활성화합니다.

총 파라미터는 예를 들어 47B 정도지만
한 번의 추론에서 실제로 활성화되는 파라미터는 6B → 24B → 42B처럼 일부에 불과합니다.
VRAM에는 전문가 블록 전체가 올라가기 때문에, 활성 파라미터와 상관없이 48GB 수준을 계속 요구하는 구조입니다.

NVIDIA의 Neotron Elastic은 방향이 다릅니다.

필요한 모델 크기만 물리적으로 로딩합니다.
6B 모델을 사용하면 총 파라미터도 6B, VRAM도 약 12GB 수준으로 끝입니다.
9B 모델이면 약 18GB, 12B 모델이면 약 24GB 정도로 올라갑니다.

즉, MoE가 "많이 갖고 와서 일부만 쓰는 구조"라면, Neotron Elastic은 "필요한 만큼만 가져오는 구조"에 더 가깝습니다.

이 때문에 같은 6B 활성 파라미터라도

MoE: 48GB를 로딩한 뒤 일부만 사용
Elastic: 실제 6B짜리 모델만 로딩, 약 12GB로 동작

이라는 차이가 생깁니다. GPU 자원이 한정된 환경일수록 이 차이는 직접적인 비용 절감으로 이어집니다.

6B·9B·12B가 하나의 학습에서 동시에 탄생하는 방식

Neotron Elastic의 독특한 지점은 6B·9B·12B가 별도 학습이 아니라, 하나의 12B 학습 과정에서 함께 최적화된다는 점입니다.

핵심은 텐서 안에 "중요도 순서"로 뉴런을 재배열하는 설계입니다.

어떤 레이어의 가중치 행렬이 4K × 4K라면
가장 중요한 뉴런들이 좌상단 3K × 3K 서브매트릭스에 모이도록 훈련합니다.
이 영역이 결국 6B 모델의 핵심 파라미터가 됩니다.

그 위에

6B 코어를 포함하되, 추론을 정교하게 만드는 추가 파라미터를 더한 부분이 9B
9B 전체 위에 세부적인 디테일·꼬리 파라미터까지 포함한 것이 12B

가 됩니다.

따라서 9B 모델은 6B와 다른 가중치를 쓰는 것이 아니라, 6B 가중치에 더해 "더 많은 가중치 영역"을 함께 사용하는 구조가 됩니다.

레이어를 삭제해도 모델이 붕괴되지 않는 이유

보통 레이어를 통째로 삭제하면, 그 다음 레이어는 전혀 다른 분포의 입력을 받게 되어 성능이 크게 망가집니다. 그래서 프루닝 후 추가 파인튜닝이 필수였습니다.

Neotron Elastic은 이 문제를 "사전에 대비된 학습 과정"으로 해결합니다.

잔차(residual) 경로를 슈퍼하이웨이처럼 강화

입력 X를 레이어를 통과시키는 대신, X + f(X) 형태로 계속 더해 나가는 구조를 적극 활용합니다.
특정 레이어를 "0"으로 만들면, 해당 레이어는 사실상 항등함수(Identity)가 되고, 데이터는 잔차 경로를 타고 그대로 다음 레이어로 전달됩니다.

확률적 탄력성(Stochastic Elasticity)

학습 중에 라우터가 레이어 on/off를 무작위로 토글합니다.
예:
- 스텝 1에서는 레이어 5가 활성 → 레이어 6은 "레이어 5를 거친 특징"을 학습
- 스텝 2에서는 레이어 5를 스킵 → 레이어 6은 "레이어 4 출력"을 직접 받는 상황도 함께 학습

이 과정을 수천 번 반복하면서, 레이어 6 같은 상위 레이어는

입력이 어느 레벨(4→6 / 5→6)이든 견디는 가중치 구조를 갖게 됩니다.

즉, 추론 시에

레이어 5를 아예 제거해도
레이어 6이 "레이어 4 수준의 추상도"를 입력으로 받아 처리할 수 있도록 사전에 학습된 상태가 됩니다.

이 덕분에 특정 레이어를 제거하거나 비활성화해도 추가 파인튜닝 없이 곧바로 작동하는 탄력성이 확보됩니다.

한 번의 학습으로 6B·9B·12B를 함께 최적화하는 커리큘럼

이제 문제는 학습 스케줄입니다.

6B·9B·12B를 모두 동일한 빈도로 샘플링해 학습하면, 작은 모델에서 발생하는 "낮은 수준의 그라디언트"가 큰 모델의 학습을 방해하는 현상이 발생할 수 있습니다. 실제로

균등 샘플링을 하면 12B 모델의 추론력이 오히려 떨어지는 문제가 관찰됩니다.

NVIDIA는 이를 위해 2단계 커리큘럼 학습을 설계했습니다.

1단계: 짧은 컨텍스트 안정화

시퀀스 길이 8K
6B·9B·12B를 균등 샘플링
목적: 라우터와 전체 아키텍처의 기본 동작을 안정화

2단계: 긴 컨텍스트에서 추론 강화

시퀀스 길이 49K
샘플링 비율을 12B: 50%, 9B: 33%, 6B: 20%로 조정

중요한 지점은, 세 모델이 모두 같은 텐서 코어를 공유한다는 점입니다.

12B 모델이 복잡한 수학·과학 데이터로 학습될 때
- 고품질 그라디언트가 공유 코어(6B 영역)에도 그대로 반영됩니다.
6B 구성은 해당 스텝에서 활성화되지 않았더라도
- 12B의 역전파(update)에 의해 공유 가중치가 함께 개선됩니다.

결과적으로

12B 모델은 긴 컨텍스트·고난도 추론에서 높은 수준을 유지하면서
6B 모델도 "12B가 학습한 논리 구조의 혜택"을 받게 됩니다.

NVIDIA는 이 커리큘럼이 6B 모델이 꽤 복잡한 수학 추론을 수행할 수 있게 되는 핵심 요인이라고 설명합니다.

Mamba2·MLP·Transformer가 섞인 하이브리드 구조

Neotron Elastic 12B 모델은 Mamba2 + MLP + Transformer 어텐션이 섞인 하이브리드 구조를 선택했습니다.

기본 베이스는 Neotron Nano 12B v2
수학·과학 중심 고난도 추론 작업에 맞춰 설계
Transformer 어텐션 레이어는 단 4개만 사용해 구조를 단순화

여기서 눈에 띄는 부분은 Mamba2 블록 처리 방식입니다.

Mamba 계열은 state-space model 기반 구조로, 그룹 정렬이 깨지면 CUDA 커널 효율이 크게 떨어집니다.
무작정 뉴런을 삭제하면 계산 커널이 깨지므로, NVIDIA는 그룹 단위로 끊어내는 "group-aware masking"을 적용합니다.
라우터는 머리(head) 단위 또는 채널 단위로 전체 그룹을 한 번에 끄거나 켜는 식으로 제어합니다.

Transformers 쪽에서는

정규화된 MSE 기반 레이어 중요도 측정
중요도가 낮은 레이어를 우선적으로 제거하거나 비활성화

같은 방식을 통해 깊이(depth)를 줄여도 최소한의 손실만 발생하도록 설계합니다.

수치로 보는 성능: 6B·9B·12B 추론 정확도

NVIDIA가 공개한 수치 기준으로, Neotron Elastic 계열의 추론 정확도(여러 벤치마크 평균)는 대략 다음과 같습니다.

6B 활성 파라미터 모델: 약 70%
9B 모델: 약 76%
12B 모델: 약 77.4%

12B로 올라가면 확실히 좋아지지만, 9B 대비 추가 향상 폭은 제한적입니다. 이 지점은 VRAM과 성능 사이에서 선택 기준이 될 수 있습니다.

또 하나 중요한 포인트는 토큰·메모리 효율입니다. Neotron Elastic 구조는

기존 압축 기법 대비 학습 토큰 수를 약 7.22배 줄였다고 주장하며
동일 9B·12B 체크포인트 대비 메모리 사용량을 약 42% 감소시켰다고 밝힙니다.

즉,

12B 모델을 학습하면서
6B·9B 모델을 별도 학습하지 않아도 되기 때문에
전체적으로 학습 리소스와 저장 공간에서 상당한 이득을 얻는 구조입니다.

왜 8bit가 아니라 16bit(bfloat16)를 고수했을까?

Neotron Elastic 연구에서는 bfloat16(2바이트/파라미터)를 사용하며, 별도의 양자화(8bit, 4bit)를 적용하지 않았습니다.

이는 특히 고난도 수학·추론 태스크에서 중요한 선택입니다.

50스텝 이상 이어지는 논리 추론에서
초기 스텝의 작은 반올림 오차가 후반부로 갈수록 연쇄적으로 증폭될 수 있습니다.
이런 오류는 특히 수식 검증, 증명, 체인 오브 소트(chain-of-thought) 같은 태스크에서 치명적입니다.

NVIDIA는 이번 연구에서

양자화에 따른 노이즈를 배제한 상태에서 아키텍처 자체의 성질을 검증하는 데 목표를 둔 것으로 보입니다.
fp32(4바이트) 대신 16bit를 택해,
- 메모리는 절반(예: 12B 기준 48GB → 24GB)으로 줄이면서
- 수학·과학 추론에서는 허용 가능한 정밀도를 확보하는 절충점(일종의 골디락스 구간)이라고 설명합니다.

이는 동시에

24GB VRAM을 가진 RTX 계열 카드에서 12B Neotron Elastic을 올릴 수 있는 여지를 만든다는 점에서도 의미가 있습니다.

Neotron Elastic이 제시하는 AI 모델 배포의 방향과 한계

Neotron Elastic은 여러 측면에서 실질적인 인프라 관점의 진화를 보여줍니다.

긍정적인 지점부터 정리하면 다음과 같습니다.

하나의 12B 학습으로 6B·9B·12B를 동시에 얻고, 서로 독립이 아니라 계층적으로 연결된 상태를 유지합니다.
라우터 + 잔차 스트림 + 확률적 레이어 on/off 덕분에,
- 특정 레이어·헤드·채널을 제거해도 추가 파인튜닝 없이 동작 가능한 탄력성을 확보합니다.
토큰 수 7.22배, 메모리 42% 절감이라는 수치가 사실이라면,
- 데이터센터의 학습·배포 비용을 눈에 띄게 줄이는 것이 가능해집니다.
추론 정확도 기준으로
- 6B가 약 70%, 9B가 76%, 12B가 77.4% 수준을 보이며
- 작은 모델에 대해 "큰 모델의 논리 구조를 공유하는 효과"가 실제로 반영된 것으로 해석할 수 있습니다.

다만 현실적인 제약도 분명합니다.

모델이 수학·과학 중심으로 튜닝된 특화 모델이라는 점에서
- 일반적인 대화·창작·코드 등 범용 용도에서는 성능 프로파일이 다르게 나타날 수 있습니다.
Elastic 아키텍처는 구조가 상당히 복잡해
- 구현·디버깅·모니터링 비용이 기존 dense 모델보다 높을 가능성이 큽니다.
- 특히 라우팅 로직과 중요도 정렬, 그룹 마스킹이 얽혀 있어 프레임워크 수준 지원이 필수적입니다.
연구 단계에서 양자화를 의도적으로 배제했다는 점은
- 실제 서비스 환경에서 8bit·4bit 양자화까지 활용해 극단적 VRAM 절감을 하려는 요구와는 아직 거리가 있습니다.
- Elastic 구조와 양자화가 결합되는 경우의 오차 누적 문제는 별도 연구가 필요해 보입니다.

또 하나 눈에 띄는 대목은, 공개된 Hugging Face 체크포인트 기준 지난 한 달 다운로드가 33회 수준이라는 점입니다.

NVIDIA가 제시하는 구조적 아이디어에 비해
커뮤니티의 실제 활용·재현 사례는 아직 매우 제한적이며
논문·코드가 제시하는 수치들이 대규모 실전 워크로드에서도 그대로 유지될지는 검증이 부족한 상태입니다.

정리하면 Neotron Elastic은

"하나의 거대 모델에서 다수의 중소형 모델을 즉시 추출해 쓰는" 방향을 상당히 치밀한 수학·엔지니어링으로 밀어붙인 사례이며
GPU·VRAM 제약이 강한 환경에서의 LLM 배포 방식에 의미 있는 대안을 제시합니다.

다만 실제 서비스에 적용할 때는

타깃 도메인(수학·과학 vs 범용 대화),
양자화 전략,
라우팅·모니터링 복잡도,
인프라 운영 비용 구조

등을 같이 고려할 필요가 있습니다.

Elastic 계열 아키텍처는 향후

기업 내부 전용 LLM
온프레미스·에지 환경
연구용 고정밀 추론 모델

에서 특히 활용 가능성이 높은 설계로 보이며, GPU 아키텍처와 함께 "모델 쪽에서 하드웨어에 적응해 가는 흐름"이 더 강해질 가능성이 있습니다.

출처 및 참고 :