MiniMax-M2.7

M2.7 is the current MiniMax release; M2.1, M2.5 and M2.7 share an identical config apart from context length (M2 196608, M2.1 196608, M2.7 204800), so this record covers the M2 line. Vendor for M2: 230B total / 10B activated; safetensors total 228.69B; our config arithmetic gives 228.6B, matching. The card makes the serving thesis explicit - '10B activations = responsive agent loops + better unit economics'. MiniMax's ATTENTION PATTERN, which the brief asked to check: M2 dropped the hybrid lightning attention of M1 entirely. config attn_type_list is 1 for all 62 layers - every layer is full attention, plain GQA, no MLA. This is the opposite direction from everyone else in this slice, who are all moving to hybrid attention. Consequence: kv_cache_bytes_per_token = 62 layers x 8 kv_heads x head_dim 128 x 2 x 2 bytes = 62 x 8 x 128 x 2 x 2 = 253,952 B/token (248 KiB). For only 10B active. That is 3.7x DeepSeek-V3's KV at ~1/4 the compute, and 31 GiB of KV per 128k sequence. So M2 minimises decode FLOPs at the cost of maximal KV growth - a deliberate trade for agentic loops at moderate context, and a poor trade for long-context batch serving. Compare MiniMax-M1, where the same vendor got 40 KiB/token at 45.9B active using hybrid attention. MoE: 256 local experts, 8 per token, shared_intermediate_size 0 i.e. NO shared expert. All 62 layers MoE. hidden 3072, intermediate 1536 (which doubles as the expert intermediate size - a narrow many-expert design), vocab 200064. gqa_ratio 6 (48 heads / 8 kv heads). use_mtp true with num_mtp_modules 3. Context 204800, rope_theta 5000000, rotary_dim 64, use_qk_norm true. Released with fp8 e4m3 128x128 block quantization. LICENCE IS THE HEADLINE CAVEAT: MiniMax-M2.7 ships under a 'NON-COMMERCIAL LICENSE' (MIT-style terms, commercial use requires prior written authorization). That is a hard restriction and a change from M1's Apache-2.0. 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.