> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tokios.com/llms.txt
> Use this file to discover all available pages before exploring further.

> ## Agent Instructions
> Tokios exposes private local models through https://api.tokios.com using an outbound-only connector tunnel.
> Use 'connector' for the local tokios-connector process.
> Use 'deployment' for the public model name in the API model field.
> Use 'upstream model id' for the model served by Ollama, llama.cpp, vLLM, LM Studio, or another local backend.
> API keys use the prefix sk-tok-. Connector tokens use the prefix ct-tok-.

# 전문가 혼합(MoE): 라우팅, 전문가 병렬 처리, 메모리

> 전문가 혼합(MoE)을 이해하십시오. 라우팅의 작동 방식, 메모리가 총 파라미터 수에 비례하는 이유, MoE를 사용하는 오픈 웨이트 모델을 설명합니다. 규모 산정 공식과 하드웨어 가이드를 포함합니다.

한 **Mixture of Experts (MoE)** 모델은 거대한 모델처럼 보이지만 각 토큰을 생성할 때마다 전체 가중치의 작은 일부만 사용합니다. 이러한 분리 — 거대한 전체 용량, 작은 토큰당 연산 — 가 최신 프론티어 오픈 웨이트 모델들이 MoE로 전환한 이유입니다. 이것이 바로 DeepSeek-V3처럼 전체 매개변수가 671B인 모델이 토큰당 37B만 활성화하면서도 여전히 671B 전체를 수용할 충분한 메모리가 필요한 이유이기도 합니다. 이 페이지에서는 라우팅 작동 방식, 서빙에서 전문가 병렬화가 의미하는 바, 그리고 MoE 모델의 하드웨어 사이징 방법을 설명합니다.

> [!NOTE]
>
> Last verified: 2026-10-14

## Mixture of Experts란

일반적인 **dense** 트랜스포머에서는 모든 토큰이 모든 레이어를 통과하며 각 포워드 패스에서 모든 매개변수를 활성화합니다. 70B dense 모델은 모든 토큰에 대해 70B 매개변수 전체를 사용합니다.

MoE 모델은 선택된 트랜스포머 블록의 피드포워드 서브레이어를 여러 병렬 **전문가** 서브네트워크와 각 토큰을 처리할 전문가를 결정하는 **라우터**(**게이팅 네트워크**라고도 함)로 대체합니다. 대부분의 전문가는 주어진 토큰에 대해 유휴 상태입니다. 256개의 전문가를 가진 모델은 토큰당 8개만 활성화할 수 있습니다 — 전체 용량의 약 3%를 각 스텝에서 사용하는 셈입니다.

그 결과:

* **전체 매개변수**는 모델에 필요한 메모리 양을 결정합니다(모든 전문가가 로드된 상태여야 합니다).
* **활성 매개변수**는 토큰당 연산 비용을 결정합니다(선택된 전문가만 실행됩니다).

이것이 핵심 트레이드오프입니다. MoE는 훨씬 작은 모델의 토큰당 연산 비용으로 매우 큰 모델의 지식 용량을 확보합니다 — 하지만 전문가가 작동하든 아니든 모든 전문가에 대한 메모리 비용은 여전히 지불해야 합니다.

## MoE 라우팅은 어떻게 작동하는가

각 MoE 레이어에는 토큰을 처리할 전문가를 선택하는 라우터가 있습니다. 프로덕션 모델에서 가장 일반적인 접근 방식은 **top-k 게이팅**입니다:

1. 라우터는 토큰의 히든 상태를 학습된 가중치 행렬과 곱한 다음 softmax를 적용하여 모든 전문가에 대한 확률 분포를 생성함으로써 각 전문가에 대한 점수를 계산합니다.
2. 가장 높은 점수를 가진 top-k 전문가가 선택됩니다. 이들의 출력은 softmax로 정규화된 가중치를 계수로 사용하여 결합됩니다.
3. 다른 모든 전문가는 해당 토큰에 대해 출력을 생성하지 않습니다 — 완전히 건너뛰어집니다.

k 값은 모델마다 다릅니다. DeepSeek-V3와 Qwen3은 k=8을 사용합니다. gpt-oss는 k=4를 사용합니다. Kimi K3는 토큰당 16개의 라우팅 전문가와 2개의 공유 전문가를 사용합니다.

### 공유 전문가

일부 아키텍처는 라우팅 점수와 관계없이 모든 토큰에 대해 활성화되는 **공유 전문가**의 하위 세트를 예약합니다. 공유 전문가는 일반적인 패턴(언어 모델링 기본, 포맷팅)을 처리하므로 라우팅 전문가가 특화될 수 있습니다. Qwen3-Next는 1개의 공유 전문가와 10개의 라우팅 전문가를 사용합니다. Kimi K3는 2개의 공유 전문가와 16개의 라우팅 전문가를 사용합니다. DeepSeek-V3와 원래의 Qwen3 MoE는 공유 전문가를 사용하지 않습니다 — 모든 활성 전문가는 라우터에 의해 선택됩니다.

### 로드 밸런싱

항상 토큰을 같은 소수의 전문가에게만 보내는 라우터는 MoE의 목적을 무색하게 합니다. 해당 전문가가 병목이 되는 동안 나머지는 유휴 상태가 되기 때문입니다. 프로덕션 모델은 전문가 사용량을 균형 있게 유지하기 위해 여러 전략을 사용합니다:

* **보조 손실** — 라우터를 균일한 전문가 사용 방향으로 밀어붙이는 학습 시간 페널티입니다. 대부분의 초기 MoE 모델(Switch Transformer, ST-MoE)이 이 접근 방식을 사용합니다. 비용은 특화도의 약간의 감소입니다. 라우터가 품질과 함께 균형을 최적화합니다.
* **보조 손실 없는 로드 밸런싱** — DeepSeek-V3는 추론 시간에 전문가별 라우팅 바이어스를 조정하는 바이어스 기반 접근 방식을 도입했습니다. 전문가가 목표 점유율보다 많은 토큰을 받으면 바이어스가 감소하여 선택될 확률이 낮아집니다. 이는 보조 손실의 품질 트레이드오프를 완전히 제거합니다.
* **Stable LatentMoE** — Kimi K3는 표준 top-k 게이팅에서 로드 불균형을 유발하는 분산을 줄이면서 토큰 간에 더 안정적인 전문가 할당을 생성하는 학습된 잠재 라우팅 메커니즘을 사용합니다.

실용적인 결론: 로드 밸런싱은 서빙 시간이 아닌 학습 시간에 해결됩니다. MoE 모델을 로컬에서 실행하는 사용자는 라우팅을 구성하지 않습니다 — 메모리와 병렬화를 구성합니다.

## MoE 메모리가 활성 매개변수가 아닌 전체 매개변수에 따라 확장되는 이유

MoE 모델을 로컬에서 실행하기 전에 이해해야 할 가장 중요한 사항입니다.

**모든 전문가는 항상 메모리에 상주해야 합니다.** 라우터는 동적으로 — 토큰마다, 레이어마다 — 어떤 전문가를 활성화할지 결정합니다. 주어진 프롬프트에 어떤 전문가가 필요할지 미리 알 수 없으므로 모든 전문가가 로드되어 준비 상태여야 합니다. 디스크에서 전문가를 온디맨드로 스와핑하는 것은 대화형 추론에는 훨씬 너무 느립니다.

즉, [Memory and offloading](/ko/concepts/memory-and-offloading.md)의 메모리 공식이 활성 매개변수가 아닌 **전체 매개변수**에 적용됩니다:

```text theme={"theme":{"light":"github-light","dark":"css-variables"}}
VRAM(GB) ≈ total_params(B) × bytes-per-param × 1.2
```

활성 매개변수는 토큰당 연산(따라서 생성 속도)에만 영향을 미치며 메모리에는 영향을 주지 않습니다.

### 계산 예제

| Model | Total params | Active params | Experts (active/total) | Memory at 4-bit (\~0.5 B/param) | Memory at 8-bit (\~1 B/param) |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 8 of 256 | \~403 GB | \~805 GB |
| Kimi K2 | 1T | 32B | 8 of 384 | \~600 GB | \~1,200 GB |
| Kimi K3 | 2.8T | 104B | 16+2 of 896 | \~1,680 GB | \~3,360 GB |
| Qwen3-30B-A3B | 30.5B | 3.3B | 8 of 128 | \~18 GB | \~37 GB |
| Qwen3-235B-A22B | 235B | 22B | 8 of 128 | \~141 GB | \~282 GB |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 10+1 of 512 | \~1,440 GB | \~2,880 GB |
| GLM-5.3 | 753B | \~40B | Not publicly specified | \~452 GB | \~904 GB |
| gpt-oss-20b | 21B | 3.6B | 4 of 32 | \~13 GB | \~25 GB |
| gpt-oss-120b | 117B | 5.1B | 4 of 128 | \~70 GB | \~140 GB |

1.2x 계수는 적당한 컨텍스트 길이에서의 KV 캐시, 활성화 및 프레임워크 오버헤드를 고려한 것입니다 — dense 모델과 동일한 공식입니다. 전체 사이징 유도는 [Memory and offloading](/ko/concepts/memory-and-offloading.md)을 참조하세요.

### 실제로 이것이 의미하는 바

Qwen3-30B-A3B는 전체 매개변수가 30.5B이지만 활성 매개변수는 3.3B입니다. 3.3B dense 모델과 비슷한 속도로 토큰을 생성하지만 — 30.5B 전체에 대한 메모리가 필요합니다. 4-bit에서는 약 18 GB이며, 24 GB GPU에 맞습니다. dense 30B 모델은 4-bit에서 비슷한 메모리가 필요하지만 더 느리게 토큰을 생성합니다. 30B 전체의 매개변수를 3.3B가 아닌 토큰당 처리하기 때문입니다.

반면, Kimi K3는 전체 매개변수가 2.8T이고 활성 매개변수가 104B입니다. 104B dense 모델과 비슷한 속도로 토큰을 생성하지만 — 가중치만 약 1.4 TB의 메모리가 4-bit에서 필요합니다. 소비자나 프로슈머 하드웨어로는 감당할 수 없습니다.

## MoE vs dense 모델

| | Dense | MoE |
| - | - | - |
| **Parameters per token** | All parameters | Only active parameters (a fraction of total) |
| **Memory** | Scales with total parameters | Scales with total parameters (same formula) |
| **Compute per token** | Scales with total parameters | Scales with active parameters only |
| **Generation speed** | Limited by total parameter count | Limited by active parameter count — often much faster than a dense model of the same total size |
| **Knowledge capacity** | Limited by total parameters | Total parameters can be much larger for the same per-token compute |
| **Hardware requirement** | Must fit total parameters | Must fit total parameters (not active) |
| **Multi-GPU serving** | Tensor parallelism splits layers | Expert parallelism splits experts across GPUs |

핵심 통찰: MoE는 지식 용량을 토큰당 연산으로부터 분리합니다. 671B 매개변수 MoE가 37B 활성으로 70B dense 모델의 품질을 일치하거나 초과하면서 70B 속도로 토큰을 생성할 수 있습니다 — 하지만 671B 상당의 메모리가 필요합니다.

## 전문가 병렬화: 다중 GPU에서 MoE 서빙

MoE 모델이 단일 GPU에 맞지 않을 때 분산해야 합니다. **전문가 병렬화**는 MoE를 위한 특화된 분산 전략입니다:

* 각 GPU는 전체 전문가의 하위 세트를 보유합니다. 256개 전문가 모델이 8개 GPU에 분산되면 각 GPU는 32개 전문가를 보유합니다.
* 포워드 패스 중에 라우터의 결정은 어떤 토큰을 어떤 GPU로 보내야 하는지 결정합니다. GPU 3의 전문가로 라우팅된 토큰은 처리를 위해 GPU 3으로 전송되고, 결과가 돌아옵니다.
* 비전문가 레이어(어텐션, 임베딩)는 일반적으로 표준 **텐서 병렬화**를 사용하여 분할되며, 각 GPU는 모든 레이어의 가중치 행렬의 슬라이스를 보유합니다.

프로덕션 서빙 런타임인 vLLM과 TensorRT-LLM은 어텐션 레이어에 대한 텐서 병렬화와 MoE 레이어에 대한 전문가 병렬화를 결합합니다. 그 결과를 **혼합 병렬화**라고 합니다. vLLM 문서에서 구성을 자세히 다루고 있으며, 핵심 설정은 전문가 병렬화가 텐서 병렬화와 별도의 병렬화 축이라는 점입니다.

실용적인 시사점: MoE 모델은 GPU 간의 고대역폭 인터커넥트(NVLink, InfiniBand)의 이점을 누리는데, 이는 라우팅 단계에서 토큰이 GPU 간에 이동해야 하기 때문입니다. PCIe로만 연결된 클러스터는 크로스 GPU 통신으로 인한 상당한 속도 페널티를 경험합니다.

## 어떤 오픈 웨이트 모델이 MoE를 사용하는가

현재 세대의 프론티어 오픈 웨이트 모델은 MoE로 크게 전환되었습니다. 2026년 기준 현황입니다:

### 50B 미만 전체 (1-2개의 소비자용 GPU로 4-bit에서 실행 가능)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| gpt-oss-20b | 21B | 3.6B | 32 | 4 | Apache 2.0 |
| Qwen3-30B-A3B | 30.5B | 3.3B | 128 | 8 | Apache 2.0 |

### 50B-250B 전체 (다중 GPU 또는 고메모리 통합 시스템)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| gpt-oss-120b | 117B | 5.1B | 128 | 4 | Apache 2.0 |
| Qwen3-235B-A22B | 235B | 22B | 128 | 8 | Apache 2.0 |

### 250B+ 전체 (서버 클래스 하드웨어 필요)

| Model | Total | Active | Experts | Active per token | License |
| - | - | - | - | - | - |
| DeepSeek-V3 / R1 | 671B | 37B | 256 | 8 | MIT (V3), custom (R1) |
| GLM-5.3 | 753B | \~40B | MoE | MoE | Custom (see [GLM-5.3](/ko/models/glm-5.3.md)) |
| Kimi K2 | 1T | 32B | 384 | 8 | Custom |
| Qwen3.8-2.4T-A95B | 2.4T | 95B | 512 | 10+1 shared | Apache 2.0 |
| Kimi K3 | 2.8T | 104B | 896 | 16+2 shared | Custom |
| DeepSeek V4.1-Flash | 552B | 8B in / 16B out | MoE | Asymmetric | MIT |

출처: HuggingFace의 모델 카드와 아래에 링크된 공식 기술 보고서.

## 로컬 추론을 위한 실용적 결론

MoE는 모델 카드에 적힌 숫자의 의미를 바꿉니다:

* **활성 매개변수**는 모델이 토큰을 생성하는 속도를 알려줍니다. 671B MoE가 37B 활성으로 대략 37B 속도로 생성합니다.
* **전체 매개변수**는 모델에 필요한 메모리 양을 알려줍니다. 같은 671B MoE는 671B 상당의 VRAM이 필요하며 37B가 아닙니다.
* **전문가 수와 라우팅**은 품질과 학습 효율성에 영향을 미치는 아키텍처 세부사항이지만, 로컬 추론 사용자는 이를 구성하지 않습니다 — 메모리와 병렬화를 구성합니다.

MoE 모델이 "2.4T 매개변수, 95B 활성"이라고 광고되는 것을 보면, 이렇게 해석하세요: "95B 속도로 생성, 2.4T의 메모리 필요." 하드웨어는 전체 크기에 맞게 사이징하고, 활성 수의 속도를 즐기세요.

다음 단계를 위해서는 [GPU model-fit guide](/ko/guides/model-fit.md)를 사용하여 특정 MoE 모델과 양자화가 다운로드 전에 하드웨어에 맞는지 확인하세요.

## 더 깊이 알아보기

> **[Memory and offloading](/ko/concepts/memory-and-offloading.md)**
>
> 정밀도별 바이트당 매개변수와 오프로딩 메커니즘을 포함한 전체 사이징 공식.

> **[Quantization](/ko/concepts/quantization.md)**
>
> MoE와 dense 모델 모두의 메모리 방정식을 바꾸기 위해 바이트당 매개변수를 줄입니다.

> **[How inference works](/ko/concepts/how-inference-works.md)**
>
> 디코드가 메모리 대역폭에 제한되는 이유와 활성 매개변수가 생성 속도에 영향을 미치는 방식.

> **[Model serving and scaling](/ko/concepts/model-serving-and-scaling.md)**
>
> 병렬화 전략, 다중 GPU 서빙, 런타임이 모델을 분산하는 방식.

## MoE를 사용하는 모델

> **[Kimi K3](/ko/models/kimi-k3.md)**
>
> 2.8T 전체, 104B 활성, Stable LatentMoE 라우팅을 갖춘 896개 전문가.

> **[DeepSeek](/ko/models/deepseek.md)**
>
> V3/R1은 671B/37B, V4.1-Flash는 552B에 비대칭 8B/16B 활성.

> **[Qwen3](/models/qwen3)**
>
> 30B-A3B 및 235B-A22B MoE 티어, 128개 전문가에 top-8 라우팅.

> **[Qwen3.8](/ko/models/qwen3.8.md)**
>
> 2.4T 플래그십, 95B 활성, 512개 전문가, 10개 라우팅 + 1개 공유.

> **[GLM-5.3](/ko/models/glm-5.3.md)**
>
> 753B 전체, \~40B 활성, 1M 컨텍스트의 MoE.

> **[gpt-oss](/models/gpt-oss)**
>
> 20b(32개 전문가) 및 120b(128개 전문가), top-4 라우팅, Apache 2.0.

## 모델이 로드되고 실행된 후

MoE 모델을 하드웨어에 로드하는 것이 첫 번째 단계입니다. `localhost`에서 요청에 응답하기 시작하면, 다음 단계는 다른 어디선가 도달할 수 있게 만드는 것입니다.

> **[Give it a stable endpoint](/ko/quickstart.md)**
>
> Tokios는 모델을 선택, 호스팅 또는 파인튜닝하지 않습니다 — 로컬에서 실행되면 Tokios는 어디서든 호출할 수 있는 안정적이고 인증된 엔드포인트로 변환합니다.

## 자주 묻는 질문

> **Why does an MoE model need memory for all experts if only a few are active?**
>
> 라우터는 각 토큰마다 다른 전문가를 선택하므로 모든 전문가에 접근할 수 있어야 합니다. 어떤 순간에는 k개의 전문가만 작동하지만, 다음 토큰은 완전히 다른 세트가 필요할 수 있습니다. 이는 모든 전문가 가중치가 항상 메모리(VRAM 또는 RAM)에 상주해야 함을 의미합니다 — 활성 매개변수가 아닌 전체 매개변수로 사이징해야 합니다.

> **How do I know if my hardware can run an MoE model?**
>
> 계산해 보세요: 전체 매개변수 × 바이트당 가중치. 4-bit(대부분의 MoE 모델의 기본 양자화 하한)에서는 `total_params × 0.5 GB`입니다. KV 캐시와 오버헤드를 위해 20%를 추가하세요. 그 숫자가 결합된 VRAM + RAM에 맞으면 모델이 로드됩니다. 맞지 않으면 어떤 최적화로도 바꿀 수 없습니다 — 더 많은 메모리나 더 작은 모델이 필요합니다.

> **What is the difference between shared experts and routed experts?**
>
> 공유 전문가는 모든 토큰에서 활성입니다 — 언어 모델링과 같은 일반적인 작업을 처리합니다. 라우팅 전문가는 게이팅 네트워크에 의해 토큰마다 선택됩니다. DeepSeek-V3는 256개의 라우팅 전문가를 사용하며 8개가 활성이고 공유 전문가는 없습니다. Kimi K3는 896개 전문가에 16개 라우팅 + 2개 공유를 사용합니다. Qwen3.8은 512개 전문가에 10개 라우팅 + 1개 공유를 사용합니다.

> **Can I run an MoE model on a single GPU?**
>
> 작은 모델만 가능합니다. Qwen3-30B-A3B(30.5B 전체, \~18 GB at 4-bit)는 24 GB GPU에 맞습니다. gpt-oss-20b(21B 전체, \~13 GB at 4-bit)도 맞습니다. 약 50B 이상의 전체 매개변수는 다중 GPU 서빙(전문가 병렬화를 지원하는 vLLM, SGLang) 또는 CPU 오프로드가 있는 고통합 메모리 시스템(Mac Studio, DGX Spark)이 필요합니다.

> **What is expert parallelism and when do I need it?**
>
> 전문가 병렬화는 전문가 레이어를 다중 GPU에 분할합니다 — GPU 0은 전문가 0-63을, GPU 1은 전문가 64-127을 보유하는 식입니다. 각 GPU는 자신 전문가의 출력을 계산하고 all-to-all 통신을 통해 결합됩니다. 전체 전문가 가중치가 단일 GPU에 맞지 않을 때 필요합니다. vLLM과 SGLang 모두 지원합니다. 구성은 [vLLM optimization guide](/ko/guides/vllm-optimization.md)을 참조하세요.

## 출처

* [DeepSeek-V3 Technical Report](https://arxiv.org/abs/2412.19437) — 671B 전체, 37B 활성, 256개 전문가, 보조 손실 없는 로드 밸런싱.
* [Kimi K2: Open Agentic Intelligence](https://arxiv.org/abs/2507.20534) — 1T 전체, 32B 활성, 384개 전문가, 토큰당 8개 활성.
* [Kimi K3 model card](https://huggingface.co/moonshotai/Kimi-K3) — 2.8T 전체, 104B 활성, 896개 전문가, Stable LatentMoE.
* [Qwen3 Technical Report](https://arxiv.org/abs/2505.09388) — 128개 전문가, 8개 활성, Qwen3 MoE에서 공유 전문가 없음.
* [Qwen3-Next-80B-A3B](https://qwen.ai/blog?id=4074cca80393150c248e508aa62983f9cb7d27cd) — 512개 전문가, 10개 라우팅 + 1개 공유.
* [Qwen3.8-Max announcement](https://qwen.ai/blog?id=qwen3.8) — 2.4T 전체, 95B 활성, 512개 전문가.
* [gpt-oss model card](https://arxiv.org/abs/2508.10925) — 32개 전문가(20b) 및 128개 전문가(120b), 토큰당 4개 활성.
* [GLM-5.3 model card](https://huggingface.co/zai-org/GLM-5.3) — 753B 전체, \~40B 활성.
* [Mixture of Experts Explained (localaimaster.com)](https://localaimaster.com/blog/mixture-of-experts-explained) — 라우팅 메커니즘과 메모리 시사점.
* [Mixture-of-Experts LLMs (Cameron R. Wolfe)](https://cameronrwolfe.substack.com/p/moe-llms) — Top-k 게이팅 공식화와 학습 역학.
* [MoE training in Qwen3-235B and Kimi-K2](https://medium.com/clickbait-programming/moe-training-in-qwen3-235b-a22b-and-kimi-k2-c51f582d2ef5) — 학습된 라우팅 비교.
* [vLLM MoE Playbook](https://rocm.blogs.amd.com/software-tools-optimization/vllm-moe-guide/README.html) — 전문가 병렬화 및 혼합 병렬화 구성.
* [Expert Parallelism in TensorRT-LLM](https://nvidia.github.io/TensorRT-LLM/advanced/expert-parallelism.html) — 다중 GPU 전문가 분산 전략.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.