Soporte Day-0 para Flint en vLLM

vLLM es compatible con Flint de Recursive desde el día 0. Tanto sus checkpoints NVFP4 como BF16 se ejecutan en una sola GPU, y una única solicitud decodifica a unos 500 tokens/s en una GB200, incluso con 100K tokens de contexto.

Flint es un MoE de 40B parámetros que activa solo unos 2.5B parámetros por token, con atención de ventana deslizante en la mayoría de las capas y un contexto de 262K tokens. Se distribuye como dos checkpoints separados: NVFP4 (entrenado con conciencia de cuantización) y BF16.

Inicio rápido

La imagen de Docker del día 0 vllm/vllm-openai:flint (x86_64 y arm64, CUDA 13.0) incluye soporte para Flint integrado:

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:flint \
  RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

El soporte para Flint se está fusionando en vLLM (#62938). Con una compilación de vLLM que lo incluya, se sirve de la misma manera:

# NVFP4 checkpoint (GGUF): config and tokenizer come from the BF16 repo
vllm serve RecursiveSI/flint-nvfp4-gguf \
  --hf-config-path RecursiveSI/flint --tokenizer RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none
 
# BF16 checkpoint
vllm serve RecursiveSI/flint \
  --enable-auto-tool-choice --tool-call-parser glm47 \
  --reasoning-parser glm47 --exclude-tools-when-tool-choice-none

Arquitectura del modelo

Flint es un MoE pre-norm de 49 capas con tamaño oculto 2048. Lo que lo distingue es cuán pequeña es la parte que atiende a todo el contexto.

Figura 1: La pila de capas de Flint y sus dos subcapas. En dorado se marca lo que difiere de un MoE pre-norm estándar. Ábrelo a pantalla completa.

• Atención mayormente local. 35 capas atienden a una ventana deslizante de 513 tokens con RoPE; las otras 14 atienden al contexto completo sin codificación posicional. Solo esas 14 conservan KV para toda la secuencia, por lo que la caché cuesta 28 KiB por token.
• Attention sinks aprendidos, GQA con 32 cabezas de consulta y 4 cabezas KV, y RMSNorm de Q/K por cabeza.
• 256 expertos, sigmoid top-6, más un experto compartido. Las capas 0 y 1 usan un MLP denso en su lugar.

El checkpoint NVFP4 es un archivo GGUF cuyos bloques están en el formato NVFP4 de NVIDIA con un orden de bytes diferente. vLLM lo reempaqueta sin pérdida en tiempo de carga y lo ejecuta weight-only (W4A16), con activaciones y caché KV en BF16, como lo hace la implementación de referencia de Recursive. Cada kernel de Flint sigue los puntos de redondeo de la referencia, y la precisión coincide con ella en GSM8K, GPQA-Diamond, MRCR de contexto largo y una suite de llamadas a herramientas.

Optimizaciones

Nuestra primera implementación, construida a partir de las capas estándar de vLLM, era lenta con tamaños de lote pequeños: un paso de decodificación ejecutaba 1,096 kernels, muchos de ellos ajustados para lotes mucho más grandes. Los reemplazamos con kernels específicos para Flint de una change a la vez, verificando cada uno contra la referencia.

Figura 2: Latencia de model-forward en una GB200 después de cada cambio, para decodificación con lote 1 a 100K de contexto y un prefill de 8,192 tokens. Cambia el checkpoint o muestra la tabla para cada forma. Ábrelo a pantalla completa.

• Norm de Q/K, RoPE y escritura de caché KV fusionadas (−8%): un kernel en lugar de tres.
• Kernels MoE para lotes pequeños (−27%): GEMV de router y expertos que leen solo los pesos de los expertos seleccionados. También la mayor ganancia en prefill.
• GEMV denso de lote pequeño (−25%) sobre los mismos pesos NVFP4 empaquetados que el kernel de lote grande.
• Kernels de norma y SiLU (−10%) que siguen el redondeo de la referencia.
• Atención en decode (−5%) con sinks y ventanas deslizantes, en CuTe DSL.
• Ruta de decode de baja latencia (−14%), mostrado a continuación.

Para hasta 8 solicitudes, la ruta de baja latencia ejecuta cada capa MoE como siete kernels: la norma de Q/K, RoPE, el routing y la combinación de expertos se funden en los kernels GEMV vecinos. Cada kernel se lanza con lanzamiento dependiente programático, de modo que carga sus pesos mientras el anterior sigue ejecutándose.

Figura 3: Los siete kernels de una capa MoE en la ruta de decode de baja latencia.

En total, el decode NVFP4 pasó de 4.81 a 1.78 ms (2.7×), el decode BF16 de 3.53 a 2.34 ms (1.5×), y un prefill de 8K tokens de 207 a 145 ms (1.4×). Un forward ahora ejecuta 346 kernels en lugar de 1,096. Servido de extremo a extremo, el decode con batch-1 a 100K de contexto toma 2.06 ms por token (unos 485 tokens/s), que incluye el forward más la LM head y el muestreo.

Notas de uso

• Flint emite tool calls y bloques de thinking al estilo de GLM-4.7, de ahí los glm47 parsers. --exclude-tools-when-tool-choice-none elimina las definiciones de herramientas del prompt cuando tool_choice es "none", igual que la referencia.
• Los ajustes de muestreo por defecto son temperature 1.0, top-p 0.95 y top-k 20. El razonamiento cuenta para max_tokens, así que reserve al menos 32K para problemas difíciles.
• Los kernels de Flint están orientados a una única GPU Blackwell (TP=1, caché KV en BF16); otras configuraciones recurren a las capas estándar de vLLM.