inference/research
verifiedhigh · 0.90updated 2026-10-19

Mixtral 8x22B

moe 39/140.6B active

Fields

id
models/mixtral-8x22b
Family
mixtral
Vendor
Mistral AI
Release year
2024
Architecture
moe
Params (B)
140.6
Active params (B)
39
Experts
8
Experts per token
2
Shared expert
no
Hidden size
6,144
Layers
56
KV heads
8
Head dim
128
GQA ratio
6
Max context
65,536
Context scaling method
native
Activation
silu
Attention variant
GQA
KV cache (bytes/token)
229,376
FLOPs per active token
78,000,000,000
Open weights
yes
License
Apache-2.0
benchmarks
nameMMLUscore77.75scale100higher_is_betteryessourcemixtral-8x22b-release-blogvendor_claimyesnameHumanEvalscore45.1scale100higher_is_betteryessourcemixtral-8x22b-release-blogvendor_claimyes
notes
CONTEXT SCALING: null is a VERIFIED value here, checked against config rather than left blank. config.json (mistralai/Mixtral-8x22B-Instruct-v0.1) declares rope_scaling null, rope_theta 1000000, max_position_embeddings 65536. Verified null. PARAMS: 140.6B is the safetensors count; Mistral's post says 141B. ACTIVE: 39B is Mistral's published figure, not derived. KV: 56 * 8 * 128 * 2 * 2 bytes = 229,376 bytes/token = 224 KiB/token, well under half of Llama 3.3 70B's 320 KiB/token despite being twice the weights and 39B active versus 70B. This is the cleanest KV-vs-active divergence in the open-weight set: 39B of active compute with 224 KiB/token of KV. Same 2-of-8 expert ratio as 8x7B but each expert is much wider (intermediate 16384 vs 14336 against a 6144 vs 4096 hidden size), which is why active params scale to 39B. 64k context per the vendor post and config. SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=dense-gqa. REQUIRED KERNEL CLASS: ordinary causal attention plus GEMM/GEMV. This is the baseline every engine in this repo implements, so the join here is a floor rather than a filter: no engine record in data/engines/ states that dense GQA is unsupported. SUPPORTED BY (cited): vLLM LlamaForCausalLM / Qwen2 / Qwen3 / Mistral / Phi3ForCausalLM rows [[mdl2-vllm-supported-models-2026-10]]; TensorRT-LLM LlamaForCausalLM, Qwen2ForCausalLM, Qwen3ForCausalLM, Phi3ForCausalLM rows [[mdl2-trtllm-supported-models]]; SGLang generative table (Llama, Qwen, Mistral families) [[mdl2-sglang-generative-models]]; llama.cpp LLM_ARCH_LLAMA [[pap-arch-llamacpp-arch-registry]]. HARD CONSTRAINTS THAT DO APPLY even to dense GQA, and they are model-shape rather than architecture-class: tensor-parallel size must divide the attention head count or the engine refuses to start [[mgpu-tp-size-must-divide-attention-heads]] (affects vllm and sglang); and a GQA KV cache is the thing paged-attention machinery exists for, so an engine with no paged KV (llama.cpp's slot-based pool [[llama-cpp]], exllamav2 [[exllamav2]]) loses the concurrency lever rather than the ability to run. ONE HARDWARE-DEPENDENT KERNEL GATE THAT IS NOT ABOUT GQA: on RDNA, vLLM's custom paged-attention kernel is gated on head_size == 128 AND block_size == 16, so a dense GQA model with head_dim 256 falls to the Triton 2D fallback and decode falls off a cliff - measured 12.1 tok/s at 518 tokens of context to 4.2 tok/s at 32k, with kernel_paged_attention_2d growing 28.3x [[rdna-triton-paged-attn-decode-cliff]]. Check head_dim before blaming the card.

Notes

CONTEXT SCALING: null is a VERIFIED value here, checked against config rather than left blank. config.json (mistralai/Mixtral-8x22B-Instruct-v0.1) declares rope_scaling null, rope_theta 1000000, max_position_embeddings 65536. Verified null. PARAMS: 140.6B is the safetensors count; Mistral's post says 141B. ACTIVE: 39B is Mistral's published figure, not derived. KV: 56 * 8 * 128 * 2 * 2 bytes = 229,376 bytes/token = 224 KiB/token, well under half of Llama 3.3 70B's 320 KiB/token despite being twice the weights and 39B active versus 70B. This is the cleanest KV-vs-active divergence in the open-weight set: 39B of active compute with 224 KiB/token of KV. Same 2-of-8 expert ratio as 8x7B but each expert is much wider (intermediate 16384 vs 14336 against a 6144 vs 4096 hidden size), which is why active params scale to 39B. 64k context per the vendor post and config.

SERVICEABILITY JOIN (added 2026-10-03; the architecture x engine matrix this record was missing, with a citation per cell in docs/13-model-compatibility.md): FAMILY=dense-gqa. REQUIRED KERNEL CLASS: ordinary causal attention plus GEMM/GEMV. This is the baseline every engine in this repo implements, so the join here is a floor rather than a filter: no engine record in data/engines/ states that dense GQA is unsupported. SUPPORTED BY (cited): vLLM LlamaForCausalLM / Qwen2 / Qwen3 / Mistral / Phi3ForCausalLM rows [[mdl2-vllm-supported-models-2026-10]]; TensorRT-LLM LlamaForCausalLM, Qwen2ForCausalLM, Qwen3ForCausalLM, Phi3ForCausalLM rows [[mdl2-trtllm-supported-models]]; SGLang generative table (Llama, Qwen, Mistral families) [[mdl2-sglang-generative-models]]; llama.cpp LLM_ARCH_LLAMA [[pap-arch-llamacpp-arch-registry]]. HARD CONSTRAINTS THAT DO APPLY even to dense GQA, and they are model-shape rather than architecture-class: tensor-parallel size must divide the attention head count or the engine refuses to start [[mgpu-tp-size-must-divide-attention-heads]] (affects vllm and sglang); and a GQA KV cache is the thing paged-attention machinery exists for, so an engine with no paged KV (llama.cpp's slot-based pool [[llama-cpp]], exllamav2 [[exllamav2]]) loses the concurrency lever rather than the ability to run. ONE HARDWARE-DEPENDENT KERNEL GATE THAT IS NOT ABOUT GQA: on RDNA, vLLM's custom paged-attention kernel is gated on head_size == 128 AND block_size == 16, so a dense GQA model with head_dim 256 falls to the Triton 2D fallback and decode falls off a cliff - measured 12.1 tok/s at 518 tokens of context to 4.2 tok/s at 32k, with kernel_paged_attention_2d growing 28.3x [[rdna-triton-paged-attn-decode-cliff]]. Check head_dim before blaming the card.

Cross-references

This record references no other records — it is a leaf. It is cited by 3.