A3B와 A4B의 정확한 의미: MoE 모델은 토큰마다 일부 전문가만 쓴다

35B-A3B라는 표기를 처음 보면 헷갈린다. 35B 모델이라는 건지, 3B 모델이라는 건지, 둘 중 어느 쪽 기준으로 성능과 용량을 봐야 하는지 애매하다. 답은 둘 다다. 다만 쓰임이 다르다. 35B는 모델이 보유한 전체 파라미터 수이고, A3B는 한 토큰을 처리할 때 실제 계산 경로에 참여하는 활성 파라미터 수다.

이 차이는 MoE, 즉 Mixture of Experts 구조 때문에 생긴다. Dense 모델은 거의 모든 파라미터를 매번 사용한다. 반면 MoE 모델은 여러 전문가 expert를 가지고 있고, 입력과 문맥에 따라 일부 expert만 선택한다. 그래서 전체 모델은 크지만, 매 토큰의 계산량은 훨씬 작게 만들 수 있다.

A3B는 3B 모델이라는 뜻이 아니다

Qwen3.6-35B-A3B를 예로 들면 전체 파라미터는 약 35B다. 모델 파일 안에는 350억 개 규모의 가중치가 들어 있다. 그런데 토큰 하나를 처리할 때는 그중 약 3B 정도의 파라미터 경로만 활성화된다. 그래서 A3B는 active 3 billion parameters의 약자처럼 이해하면 된다.

이 말은 “다운로드가 3B 모델만큼 작다”는 뜻이 아니다. 다운로드와 저장은 전체 35B 기준이다. 어떤 expert가 언제 필요할지 모르기 때문에 전체 expert 가중치를 가지고 있어야 한다. 대신 실제 토큰 생성 계산량은 35B dense 모델보다 훨씬 작아질 수 있다.

비유하면 회사 전체 직원은 350명인데, 매 회의마다 주제에 맞는 전문가 30명만 회의실에 들어오는 구조다. 회사 전체 인력과 자료는 350명분이 필요하지만, 이번 의사결정에 직접 참여하는 사람은 30명인 셈이다.

A4B는 A3B보다 토큰당 계산량이 크다

Gemma-4-26B-A4B라면 전체 파라미터는 26B이고, 토큰당 활성 파라미터는 약 4B다. 단순히 active parameter만 보면 A4B가 A3B보다 한 토큰을 만들 때 더 많은 계산을 한다. 그래서 같은 하드웨어와 비슷한 구현이라면 A3B가 더 빠를 가능성이 있다.

하지만 품질은 active parameter만으로 결정되지 않는다. 전체 파라미터, 학습 데이터, router 품질, expert 수, 후처리, 컨텍스트 학습, 토크나이저, 양자화 품질이 모두 영향을 준다. 35B-A3B가 26B-A4B보다 나을 수도 있고, 특정 작업에서는 반대일 수도 있다.

그래도 운영 관점에서 A3B와 A4B는 매우 유용한 힌트다. “이 모델이 전체 크기 대비 얼마나 가볍게 토큰을 생성할 수 있는가”를 알려주기 때문이다.

Dense 모델과 MoE 모델의 차이

Qwen3.6-27B-4bit처럼 A3B, A4B 표기가 없다면 대체로 dense 모델로 해석한다. Dense 모델은 전체 27B 파라미터가 거의 매 토큰 계산에 관여한다. 따라서 다운로드도 27B 기준, 메모리도 27B 기준, 토큰당 계산량도 27B 기준에 가깝다.

반면 35B-A3B는 다운로드와 메모리는 35B 기준이지만, 토큰 생성 계산량은 3B active 기준에 가깝다. 이 때문에 MoE 모델은 큰 모델의 지식량과 작은 모델의 계산 효율을 동시에 노린다. 로컬 LLM에서 MoE가 매력적인 이유가 여기에 있다.

다만 MoE는 구현체 최적화가 중요하다. 라우터가 expert를 고르는 과정, GPU 메모리 배치, 런타임의 MoE 지원 수준에 따라 실제 속도가 달라진다. 이론상 A3B라고 해도 런타임이 비효율적이면 기대만큼 빠르지 않을 수 있다.

Active parameter는 속도와 전력에 가깝다

Active parameter는 주로 토큰당 계산량, 생성 속도, 전력, 발열과 연결된다. 한 토큰을 만들 때 더 많은 파라미터가 계산에 참여하면 GPU나 CPU가 해야 할 연산이 늘어난다. 그래서 A3B는 A4B보다 가볍고, 27B dense는 A3B MoE보다 훨씬 무겁게 느껴질 가능성이 높다.

하지만 active parameter가 다운로드 용량을 줄여주지는 않는다. 다운로드 용량은 전체 파라미터 수와 양자화 bit가 결정한다. 35B-A3B-4bit의 파일 크기는 3B 4bit가 아니라 35B 4bit에 가깝다. 이 구분을 놓치면 “왜 A3B인데 파일이 20GB나 되지?”라는 오해가 생긴다.

또한 긴 컨텍스트를 쓰면 KV cache가 커진다. A3B라서 생성 계산량이 효율적이어도, 128K 컨텍스트를 열면 실행 중 메모리는 크게 늘 수 있다. Active parameter는 계산량의 축이고, context는 메모리의 또 다른 축이다.

토큰마다 expert 선택이 달라진다

MoE 모델은 모든 입력에 같은 expert를 쓰지 않는다. 문맥과 토큰에 따라 router가 어떤 expert를 사용할지 고른다. 코딩 문맥에서는 코드 관련 패턴을 잘 가진 expert가 선택될 수 있고, 수학 문맥에서는 다른 expert가 선택될 수 있다. 실제로는 그렇게 명확히 사람처럼 분리되어 있지는 않지만, 운영 관점에서는 “토큰마다 일부 expert만 고른다”고 이해하면 충분하다.

이 구조 덕분에 MoE 모델은 전체 파라미터를 크게 유지하면서도 토큰당 계산량을 낮출 수 있다. 대형 dense 모델을 로컬에서 돌리기 어려운 이유는 매 토큰마다 전체 모델을 지나야 하기 때문이다. MoE는 이 부담을 줄이는 방향의 설계다.

실행 체크리스트

• A3B, A4B는 다운로드 용량이 아니라 토큰당 활성 계산량으로 이해한다.
• MoE 모델의 전체 파라미터는 저장·다운로드·메모리 기준이고, active parameter는 속도·연산량 기준이다.
• Dense 모델은 보통 전체 파라미터와 활성 파라미터가 거의 같다.
• 35B-A3B는 3B 모델이 아니라, 35B를 저장하고 매 토큰 약 3B를 쓰는 모델이다.
• A3B가 A4B보다 대체로 빠를 수 있지만, 품질은 학습과 구조가 함께 결정한다.
• 긴 context에서는 A3B라도 KV cache 메모리 부담이 커진다.
• 실제 선택은 tokens/sec, 메모리 사용량, 작업별 품질 테스트로 확인한다.

정리하면 A3B와 A4B는 MoE 모델을 이해하는 핵심 표기다. 전체 모델이 얼마나 큰지와, 매 토큰마다 실제로 얼마나 계산하는지는 별개의 문제다. 로컬 LLM을 고를 때 이 둘을 나눠 보면 “왜 큰 모델인데 빠른지”, “왜 A3B인데 다운로드는 큰지”가 자연스럽게 이해된다.