vLLM ofrece soporte en día 0 para MiniMax-M3.1-Flash

MiniMax-M3.1-Flash es el modelo más reciente de la familia MiniMax-M3, con mejoras en tareas de razonamiento, codificación, agentes y visualización. También está diseñado para la eficiencia de inferencia, con un caché NVFP4 KV nativo, pesos NVFP4-quantizados MoE y un modelo DSpark para el decodificado especulativo.

vLLM soporta MiniMax-M3.1-Flash en el día 0 en las GPU NVIDIA Blackwell, en las GPU NVIDIA Rubin con kerneles dedicados Rubin, y en las GPU AMD MI350-series, ofreciendo un rendimiento sólido en cargas de trabajo agentic.

TL;DR

• MiniMax Sparse Attention (MSA) con un NVFP4 KV cache para tanto el indexador como la ruta de atención, además de NVFP4 MoE weights y un DSpark drafter.
• Kerneles Blackwell MSA utilizan la nueva instrucción CUDA 13.4 QMUL4 para desencuantizar NVFP4 a FP8 dentro del kernel: hasta 1.7× más rápido en el decodificador QK del indexador y 1.3× más rápido en el decodificador de atención dispersa.
• NVFP4 MegaMoE con fusión compartida de MXFP8 y lanzamiento temprano de TMEM: 20% menos latencia del kernel en el prellenado y 7% más rendimiento de llenado.
• Indexer decode context parallelism (DCP): hasta 3.3× más rápido en el indexador por capa esparsa, con un contexto de 512K en 4× GB300.
• QKV GEMM + norm + RoPE + fusión con KV-insert: 1.1–1.6× más rápido en el relleno previo con 512+ tokens y aproximadamente 19% menos P50 TTFT en TP4.
• FlashInfer PrimiTS backend para el diseñador DSpark: 1.3–2× más rápido que FlashAttention 4, 5% menos en tiempo total de procesamiento.
• Los núcleos de MSA de Rubin (SM107) también están integrados en vLLM con un rendimiento de última generación.
• Serie AMD MI350: el kernel MSA nativo NVFP4, el paralelismo de contexto de decodificación indexadora, la superposición de dos paquetes y el kernel mono proporcionan un aumento de rendimiento de 2–3× en todo el sistema.
• Servicio Agente: en NVIDIA GB300, hasta 418.9 tok/s por usuario en el extremo sensible a la latencia; en NVIDIA Rubin, hasta 724.9 tok/s por usuario y 191.5K tok/s totales por GPU; en AMD MI355X, hasta 133.3M tokens totales por dólar de TCO en el benchmark SemiAnalysis AgentX.
• Apoyo RL día-0: RL de punta a punta con veRL, FSDP2 y LoRA en el punto de control NVFP4.

Inicio rápido

Las imágenes preconstruidas están disponibles para ambos proveedores:

• NVIDIA: vllm/vllm-openai:minimax-m31-flash
• AMD: vllm/vllm-openai-rocm:minimax-m31-flash

Tenga en cuenta que el modelo estará disponible en la rueda de PyPI nocturna después de que el código sea revisado y fusionado en upstream, lo cual generalmente lleva aproximadamente una semana. Las recetas completas se encuentran en vLLM Recipes, y el checkpoint está en MiniMaxAI/MiniMax-M3.1-Flash.

TP4 en NVIDIA

Recomendamos el toolkit CUDA 13.4 para obtener el mejor rendimiento.

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4"}' \
  --speculative-config '{"method":"dspark","num_speculative_tokens":7,"attention_backend":"FLASHINFER_TS","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

TP4 en AMD

vllm serve MiniMaxAI/MiniMax-M3.1-Flash \
  -tp 4 \
  --reasoning-parser minimax_m3 \
  --block-size 128 \
  --kv-cache-dtype nvfp4 \
  --attention-config '{"indexer_kv_dtype": "nvfp4", "indexer_decode_cp": true}' \
  --quantization-config.moe mxfp8 \
  --speculative-config '{"method":"dspark","num_speculative_tokens":3,"attention_backend":"TRITON_ATTN","kv_cache_dtype":"fp8","draft_sample_method":"probabilistic"}' \
  --disable-hybrid-kv-cache-manager

MSA primer

La familia de modelos MiniMax-M3 reemplaza la atención completa por una variante de atención bloque-sparse (arXiv 2606.13392) para hacer la inferencia más eficiente. El caché KV se divide en bloques de 128 tokens. Un indexador ligero califica cada clave en el contexto con una consulta de índice por grupo GQA, contra un único cabezal de clave de índice compartido, y luego maximiza esos puntajes para obtener un puntaje único por bloque. La atención principal se ejecuta entonces exactamente, pero solo sobre los 16 primeros bloques, y el bloque más reciente siempre se mantiene. Esto limita cada consulta a 2,048 claves, independientemente de la longitud del contexto.

La ganancia es mayor en la decodificación, y está limitada por el ancho de banda de memoria. Cada paso sigue escaneando las claves del índice para todo el contexto, pero eso es solo 128 bytes por token por capa, un octavo de los 1,024 bytes de K/V que la atención densa leería (FP8, 4 cabezas de KV × 128 dimensiones). Luego se lee todo el K/V solo para los 2,048 tokens seleccionados. En la decodificación de contexto largo, el tráfico HBM por paso disminuye a aproximadamente el 12.5% de lo que la atención densa lee.

Figura 1: Atención Esparsa MiniMax. El indexador de cada grupo GQA selecciona sus bloques KV más importantes, y cada cabezal de consulta en ese grupo atiende exactamente solo esos bloques. Proceda paso a paso.

¿Qué es nuevo en la arquitectura MiniMax-M3.1?

MiniMax-M3.1 mejora significativamente la eficiencia de inferencia en comparación con la generación anterior: fue entrenado de forma nativa con atención a la cuantización para una caché NVFP4 KV, y sus pesos MoE enrutados se almacenan en NVFP4. Los expertos de NVFP4 reducen el checkpoint de 451.5 GB (MiniMax-M3-MXFP8) a 250.1 GB, lo que representa una reducción del 44.6%. La caché NVFP4 KV necesita 34,560 bytes por token en lugar de 61,440 bytes en FP8, lo que implica una economía del 43.75% por token. Juntos, con cuatro GPU NVIDIA B300 con la implementación DEP4 y secuencias de 256K de tokens, M3.1 puede procesar 76 secuencias simultáneas, mientras que M3 con un caché KV de FP8 puede procesar 28, aproximadamente 2.7 veces más en el mismo hardware, lo que aumenta directamente el rendimiento de servicio.

Figura 2: MiniMax-M3.1 fue entrenado con conocimiento de cuantización para utilizar un caché NVFP4 KV tanto en el indexador como en la atención dispersa. Cambie el tipo de dato del caché KV, el paralelismo, la GPU o la longitud del contexto para ver cuántas secuencias caben.

Optimizaciones de rendimiento

vLLM ofrece un rendimiento sólido de MiniMax-M3.1 en varias plataformas de hardware. En las GPU NVIDIA, enviamos kernels optimizados para el almacenamiento NVFP4 KV. Nuestro repositorio MSA (vllm-project/MSA) contiene kernels ajustados para diferentes cargas de trabajo y operaciones. Estos incluyen la prealfusión y decodificación del índice MSA, la prealfusión y decodificación de atención dispersa, y un kernel específico para MSA con top-k.

Figura 3: Una capa de decodificador disperso MiniMax-M3.1 en Blackwell durante la decodificación (M ≤ 32), kernel por kernel. Las insignias numeradas marcan las optimizaciones en esta publicación; haga clic en una para resaltar sus kernels.

NVIDIA Blackwell optimizado kernes MSA

El caché KV se almacena en NVFP4, mientras que la consulta permanece en FP8; por lo tanto, no podemos utilizar las instrucciones nativas del tensor core NVFP4 para la multiplicación de matrices. En su lugar, el kernel descuantifica el caché KV NVFP4 a FP8 y ejecuta una operación MMA en FP8. Para mantener bajo el costo de descuantización, utilizamos una nueva instrucción PTX específica para Blackwell introducida en CUDA 13.4: mul.e4m3x4.e2m1x4.e4m3x4 (SASS QMUL4). Esta instrucción escala cuatro valores NVFP4 según su factor de escala y produce cuatro valores FP8 en una sola instrucción. Esto requiere muchas menos instrucciones de núcleo CUDA que el anterior camino de ida y vuelta en FP16. El resultado es un aceleración de hasta 1.7× en el kernel de decodificación del indexer QK y de 1.3× en el kernel de decodificación de atención esparsa.

NVFP4 MegaMoE

MegaMoE es un bloque fundamental para las implementaciones modernas de expertos paralelos (EP). Hemos ampliado MegaMoE de DeepGEMM con precisión NVFP4 mediante expertos compartidos MXFP8 fusionados, y los hemos abierto al código público en nuestra versión derivada (vllm-project/DeepGEMM). Añadir el soporte NVFP4 a MegaMoE no es solo un cambio de tipo de dato. NVFP4 reduce a la mitad los bytes por elemento y duplica el rendimiento de los núcleos de tensores en comparación con el método FP8×FP4 anterior. El resto del kernel también debe cambiar, de lo contrario, la pipeline queda desequilibrada.

Una de esas cambios es la liberación de la etapa TMEM al principio del epilogo de FC1. Anteriormente, la etapa TMEM se liberaba solo después de que terminara el epilogo. Esa espera era innecesaria, ya que el epilogo se ejecuta completamente en registros. La etapa TMEM puede ser liberada tan pronto como el acumulador se cargue en los registros, antes de que ocurra cualquier operación aritmética. Esto reduce la latencia total del kernel en el prelleno en un 20%, donde el cálculo más rápido con NVFP4 es de mayor importancia. También aumenta el rendimiento general del prelleno en un 7%.

Indexador NVFP4 DCP (decodación de paralelismo de contexto)

En el servicio de baja latencia, cada GPU evalúa su propio índice para todo el contexto. En los cuatro GPUs, esto significa que cada capa de indexación lee el caché de índice completo cuatro veces. La indexadora DCP divide el trabajo según el contexto. Cada GPU evalúa los cuatro índices para una cuarta parte de las páginas. Luego, envía su top-16 local para cada índice a través de NVLink al GPU que posee ese índice, lo que permite fusionar los candidatos en el top-16 final. La selección sigue siendo precisa, y el indexador funciona hasta 3.3 veces más rápido por capa dispersa, con un contexto de 512K en 4× GPU NVIDIA GB300.

QKV GEMM + norm + RoPE + KV inserción fusión

Las proyecciones de QKV y indexador de MiniMax-M3.1 se utilizan para escribir el tensores completo de QKV en HBM. Un segundo kernel lo lee de nuevo para obtener la norma, RoPE y la inserción en el cache KV. Fusionamos toda la cadena en un único kernel GEMM, cuyo proceso final procesa el acumulador FP32 uno por uno. Aplica la norma y RoPE a la consulta de petición y a la consulta de índice. También cuantifica K, V y la clave del índice a NVFP4 y los escribe directamente en sus cachés. El tensores de QKV nunca entra en contacto con HBM. En GB300, llenar lotes de 512 o más tokens funciona 1.1–1.6× más rápido, y el tiempo hasta el primer token (TTFT) en P50 disminuye aproximadamente un 19% en TP4.

FlashInfer PrimiTS para el DSpark drafter

MiniMax-M3.1 utiliza DSpark como su diseñador de decodificación especulativa, el cual ejecuta GQA no causal con una ventana deslizante de 4096 tokens. Anteriormente, vLLM ejecutaba el diseñador en FlashAttention 4, que no está optimizado para las formas de decodificación. Cambiamos a el backend PrimiTS de FlashInfer. PrimiTS es 1.3–2× más rápido que FlashAttention 4 y reduce el tiempo total de procesamiento en un 5%.

Punto de referencia para carga de trabajo agente en NVIDIA GB300

vLLM ofrece un rendimiento sólido en cargas de trabajo de servicio agentic. Realizamos una prueba de benchmark para nuestra imagen del día 0 en NVIDIA GB300 con el benchmark SemiAnalysis AgentX (detallado en nuestro artículo anterior). En el extremo sensible a la latencia, MiniMax-M3.1-Flash alcanza 418.9 tokens por segundo por usuario. Más adelante en el rango de rendimiento, mantiene cada usuario por encima de 200 tokens por segundo mientras sirve 38.6K tokens totales por segundo por GPU. En el extremo del rendimiento, alcanza 153.8K tokens por segundo por GPU, aproximadamente 24 veces el punto más interactivo, mientras que cada usuario sigue viendo alrededor de 127 tokens por segundo.

Figura 4: Frontera de Pareto de AgentX para MiniMax-M3.1-Flash en NVIDIA GB300, con 7 tokens especulativos y longitudes de aceptación sintética de 3.16–3.26 tokens (incluyendo el primer token). Pase el cursor sobre un punto para ver sus métricas.

NVIDIA Rubin MSA optimizado

También optimizamos este modelo en las GPU NVIDIA Rubin. Para mitigar la sobrecarga de conversión de NVFP4 a FP8, convertimos directamente NVFP4 a FP16 y ejecutamos el score MMA en FP16 para el indexador. Esto reduce las instrucciones de descuantificación en aproximadamente un tercio, y los scores se vuelven exactos, en lugar de llevar la reredondeo E4M3 para ejecutar FP8 MMA.

Con ≤4 consultas, el indexador de un solo head decode kernel va más lejos: aplica cada escala de bloque una vez por resultado MMA con el fma.rn.f32x2.f16x2 compactado de SM107, en lugar de una vez por valor K. Esto también permite ocultar más latencia al ejecutar tres CTAs por SM. La mayor memoria compartida de Rubin (328 KB vs 228 KB en Blackwell) y las columnas adicionales de memoria Tensor (576 vs. 512 en Blackwell) hacen eso posible.

Finalmente, debido a que Rubin tiene más SMs que Blackwell, los planificadores de trabajo determinan el tamaño de sus azulejos basándose en el número de SMs, de modo que el trabajo se distribuye de manera equitativa entre las 212 SMs de Rubin.

El relleno de la atención escasa también se beneficia de las optimizaciones de dominio local. Asignamos los búferes parciales a través de la API de memoria virtual CUDA, de modo que las páginas de 2 MB se alternan entre los dos dominios, y el kernel combinado entrega cada tela a un CTA cuyo SM se encuentra en el dominio que alberga los datos de esa tela. En Rubin, los kernels de atención de relleno y decodificación utilizan MMA densa FP8 con K=64 por instrucción, lo que reduce a la mitad la cantidad de instrucciones de MMA y permite operar al doble de la velocidad de FP8 de Blackwell.

Punto de referencia para carga de trabajo agente en NVIDIA Rubin

En NVIDIA Rubin, MiniMax-M3.1-Flash avanza aún más en el mismo benchmark. En el ámbito de la latencia, alcanza 724.9 tokens por segundo por usuario. Más adelante en el límite, mantiene cada usuario por encima de 200 tokens por segundo, mientras sirve un total de 157.3K tokens por segundo por GPU. En cuanto al rendimiento, alcanza 191.5K tokens por segundo por GPU, aunque cada usuario sigue viendo aproximadamente 134 tokens por segundo, lo que equivale a aproximadamente 1.5× GB300 con la misma tasa por usuario.

Figura 5: Frontera de Pareto de AgentX para MiniMax-M3.1-Flash en NVIDIA Rubin. Pase el cursor sobre un punto para ver su configuración y métricas.

Soporte para GPU AMD

En las GPU AMD, incorporamos soporte para el almacenamiento de cache NVFP4 KV, de modo que las implementaciones AMD también pueden utilizar el formato de baja precisión para reducir la memoria de almacenamiento del cache KV. Para la decodificación, añadimos un indexer DCP para acelerar la decodificación con contexto largo, y un kernel mono que mejora la inferencia con baja latencia. Para el prellenado, el paralelismo de secuencias y la superposición de lotes duales reducen la comunicación dentro del motor, y una nueva disposición del almacenamiento de cache KV permite que cada bloque KV se mueva al nodo de decodificación en un único transfer. Los kernels MSA y mono están construidos en FlyDSL, el DSL de Python de AMD para los kernels de GPU, con la ayuda del equipo de FlyDSL.

NVFP4 MSA kernel

MiniMax-M3.1 está entrenado con una caché NVFP4 KV (QAT) tanto para la atención principal como para el indexador, pero CDNA4 no tiene instrucciones nativas para descuantificar NVFP4. Para mantener los kernels MSA rápidos, convertimos la descuantificación en una búsqueda en tabla. Hay solo 256 escalas posibles de E4M3 y ocho magnitudes de E2M1, por lo que precomparamos todo el valor escalado, ya redondeado a FP8, en una tabla de 2 KB en LDS. v_perm_b32 Byte permute más uno XOR para los bits de signo, luego convierte cuatro valores FP4 a FP8. El kernel también desencadena una página con prefijo compartido solo una vez para hasta 64 solicitudes que la compartan. Juntas, estas acciones hacen que la decodificación esparsa sea hasta 2.5 veces más rápida que convertir los bloques seleccionados a FP8 y ejecutar el kernel de atención FP8.

Indexador NVFP4 DCP

Utilizamos el mismo indexador de paralelismo en contexto de decodificación en AMD como en NVIDIA, y en CDNA4 proporciona una ventaja adicional. Sin DCP, cada GPU en TP4 obtiene su propio índice en todo el contexto, por lo que la caché de índice se lee cuatro veces. También hace que los núcleos de matriz se utilicen poco. Un paso de decodificación DSpark-3 tiene solo 4 filas de consulta por solicitud, lo que llena solo 4 de las 16 columnas del 16×16×128 FP8 MFMA. Con DCP, cada GPU evalúa las cuatro cabezas en un cuarto del contexto, de modo que 4 cabezas × 4 filas llenan todas las 16 columnas. Un único kernel intercambia las consultas de índice, evalúa sus bloques y escribe los resultados de cada cabezal directamente en la memoria del GPU propietario a través de Infinity Fabric. Una negociación desde el dispositivo garantiza que esto funcione dentro de los gráficos HIP. El propietario luego selecciona los 16 mejores, y como los resultados son idénticos bit a bit a la versión con una sola GPU, la selección es precisa. En el 4× MI355X, el indexador funciona hasta 2.8× más rápido por capa dispersa con 45 solicitudes de 30K–210K tokens.

SP + DBO prelleno y transferencia de KV de una lectura

En TP4, el relleno previo con petición larga en el MI355X está limitado por la comunicación, tanto entre las GPU dentro de un nodo como entre los nodos de relleno y decodificación. Dentro del motor, la superposición de dos lotes (DBO) oculta los tensores paralelos detrás del cálculo del otro microlote. El paralelismo de secuencias (SP) reduce el tráfico en sí. Cada GPU mantiene un cuarto de los tokens; la salida de atención se intercambia de todos a todos en MXFP8, de modo que cada GPU ejecuta el completo o_proj sobre sus propios tokens, y la salida MoE se distribuye de forma reducida. Esto reduce el tráfico por GPU de unos 36 KB a 20 KB por token por capa, y las normas, la cuantización y el enrutador se ejecutan sobre solo un cuarto de los tokens.

Un motor de relleno previo más rápido solo ayuda si la caché KV también puede llegar al nodo de decodificación rápidamente. El diseño de caché KV capa por capa de vLLM divide cada bloque KV en 125 páginas pequeñas, y cada página necesita su propio leído NIXL RDMA. Cambiamos a un diseño de bloque exterior que almacena cada bloque en una fila contigua de 1.82 MB, de modo que NIXL lo mueve con un único leído. Juntos, el motor y la transferencia de caché KV hacen que los lotes de relleno de 16K+ tokens sean 1.8–2.1× más rápidos en un 4× MI355X.

Kernel mono de baja latencia

En bajo concurrencia, la decodificación en las GPU AMD está limitada por el lanzamiento: la sobrecarga de lanzamiento del kernel toma más tiempo que los cálculos matemáticos. La decodificación mono soluciona esto al ejecutar cada capa de decodificador MoE esparso como un único lanzamiento de kernel FlyDSL. Ese único lanzamiento cubre todo, desde la proyección QKV y la atención esparsa hasta el tensor-parallel all-reduces y el MXFP4 MoE, reemplazando aproximadamente 1,170 lanzamientos de kernel. En el MI350X en TP4, esto hace que el paso de decodificación sea hasta 2.3 veces más rápido y duplica el rendimiento de entrada de 8K y salida de 1K en condiciones de baja concurrencia. En un rastro de codificación agentic, aumenta la interactividad en un 50–65%.

Benchmark de carga de trabajo agente en AMD MI355X

La implementación de AMD también ofrece un rendimiento sólido por costo. En el benchmark InferenceX AgentX, MiniMax-M3.1-Flash alcanza 331.0 tokens por segundo por usuario en el extremo de la frontera sensible a la latencia. Más adelante en la frontera, mantiene cada usuario por encima de 170 tokens por segundo, mientras entrega 34.6M tokens totales por dólar de TCO. En el extremo de eficiencia de costos, alcanza 133.3M tokens por dólar, casi 10 veces el punto más interactivo, mientras que cada usuario sigue viendo aproximadamente 79 tokens por segundo.

Figura 6: Frontera de Pareto de AgentX para MiniMax-M3.1-Flash en AMD MI355X, en tokens totales por dólar de TCO. c1 y c4 utilizan una longitud de aceptación sintética de 3.2 tokens con 7 tokens especulativos; los otros puntos utilizan 2.45 tokens con 3 tokens especulativos. Pase el cursor sobre un punto para ver sus métricas.

Soporte RL día-0

Ejecutamos RL en MiniMax-M3.1, comenzando desde su punto de control NVFP4, y entrenamos únicamente adaptadores LoRA de rango-32. El entrenador veRL cuantiza el modelo base de la misma manera en que el motor lo sirve: con NVFP4 en los expertos enrutados y MXFP8 en las otras proyecciones, y sincroniza únicamente los adaptadores con el motor después de cada paso. Por otro lado, en el lado del motor, los expert LoRA se ejecutan dentro del kernel NVFP4 MoE de FlashInfer TRTLLM, por lo que los expertos base siguen funcionando en el kernel normal de servicio.

Antes del entrenamiento, comprobamos que el entrenador y el motor estén de acuerdo en tres aspectos. El motor recibe exactamente los pesos que envía el entrenador, ambos redirigen cada token a los mismos expertos (replay de enrutamiento) y ambos asignan logprobs cercanos a los mismos tokens.

El espacio restante se corrige mediante muestreo de importancia a nivel de token (TIS), con una proporción de importancia limitada en 2. Como cada lote recibe un único paso de optimizador, el entrenador utiliza los logprobs de despliegue como los logprobs antiguos y omite el paso adicional hacia adelante que los reescribiría.

En DAPO-Math-17K, con 16 GB de GPU y 300 unidades de rendimiento, 200 pasos de GRPO aumentan la precisión en AIME-2024 de 36.3% a 67.5%. Durante el mismo proceso, la recompensa de entrenamiento aumenta de −0.06 a 0.67, y el KL de entrenamiento/despliegue permanece bajo, disminuyendo de 0.040 a 0.024.

Figura 7: RL en día 0 en MiniMax-M3.1-Flash con veRL en DAPO-Math-17K (16× GB300, 200 pasos GRPO): precisión AIME-2024, recompensa de entrenamiento y KL entre entrenamiento y ejecución. Utilice las tabas para cambiar entre ellas.

Agradecimientos

Expresamos nuestra sincera gratitud al equipo de MiniMax por el open-sourceing de MiniMax-M3.1-Flash. También agradecemos a Inferact, NVIDIA y AMD (Hongxia Yang por el kernel mono, Felix Marty, Andy Luo, Felix Li, Hattie Wu, Gilbert Lei y Peng Sun) por brindar soporte en el día 0 para el modelo en vLLM, así como al equipo de FlyDSL por su ayuda con los kernels AMD y con la comunidad de vLLM.