Magistral Small

CONTEXT SCALING: null is a VERIFIED value, checked against config rather than left blank. config.json (mistralai/Magistral-Small-2509) declares rope_scaling null, rope_theta 1000000000 (1e9), max_position_embeddings 131072. Worth stating precisely because 1e9 looks like an extrapolation trick: it is not PI, NTK-aware scaling or YaRN - no scaling block exists at all. The long-context behaviour comes from the BASE being trained at 1e9, i.e. native. PARAMS: 24.01B is the safetensors count including the vision tower. KV: 40 * 8 * 128 * 2 * 2 bytes = 163,840 bytes/token = 160 KiB/token. ARCHITECTURE IS THE Mistral Small TEXT TOWER, NOT A NEW ONE: text_config is hidden 5120, 40 layers, 32/8 heads, head_dim 128, intermediate 32768, 131072 context, model_type mistral. Compare Mistral-Small-24B-Instruct-2501, which is the same dense text geometry without the vision tower. Magistral Small is a reasoning-tuned variant of that architecture, so for serving purposes it is a dense 24B with a 128k window and a small multimodal head, plus the reasoning-token behaviour that dominates its cost profile. confidence 0.75: I could not retrieve a dedicated Mistral announcement page for this checkpoint in this session; every architecture field is from config.json, which is authoritative. The Apache-2.0 licence string is asserted from the Mistral open-model family and should be confirmed against the model card before commercial reliance. The reasoning-token behaviour that defines Magistral is documented by Mistral but was not quotable from a primary page here, so it is not recorded as a field. 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. CONTEXT_SCALING_METHOD (native): SCHEME RECLASSIFIED (2026-10-04): was null (a rope_theta of 1e9 read as an extrapolation trick). config declares rope_scaling null and rope_theta 1e9: the BASE is trained at 1e9, so no scaling block exists at all.