Day-0-Unterstützung für Flint auf vLLM

vLLM unterstützt Flint von Recursive ab Tag 0. Sowohl der NVFP4- als auch der BF16-Checkpoint laufen auf einer einzelnen GPU, und eine einzelne Anfrage dekodiert mit etwa 500 tokens/s auf einem GB200, selbst mit 100K tokens Kontext.

Flint ist ein 40B-Parameter-MoE, das pro Token nur etwa 2.5B Parameter aktiviert, mit Sliding-Window-Attention in den meisten Schichten und einem Kontext von 262K tokens. Es wird als zwei separate Checkpoints ausgeliefert: NVFP4 (quantisierungsbewusst trainiert) und BF16.

Schnellstart

Das Day-0-Docker-Image vllm/vllm-openai:flint (x86_64 und arm64, CUDA 13.0) hat Flint-Unterstützung bereits eingebaut:

# 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

Die Flint-Unterstützung wird in vLLM zusammengeführt (#62938). Mit einem vLLM-Build, der sie enthält, wird der Server auf dieselbe Weise gestartet:

# 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

Modellarchitektur

Flint ist ein 49-Schichten-Pre-Norm-MoE mit versteckter Größe 2048. Was ihn auszeichnet, ist, wie wenig davon den gesamten Kontext betrachtet.

Abbildung 1: Flints Schichtenstapel und seine beiden Unterschichten. Gold markiert, was sich von einem standardmäßigen Pre-Norm-MoE unterscheidet. Vollbild öffnen.

• Überwiegend lokale Aufmerksamkeit. 35 Schichten achten auf ein 513-token-Sliding-Fenster mit RoPE; die anderen 14 achten auf den gesamten Kontext ohne Positionskodierung. Nur diese 14 behalten KV für die gesamte Sequenz, sodass der Cache 28 KiB pro Token kostet.
• Gelernte Attention Sinks, GQA mit 32 Query- und 4 KV-Köpfen sowie per-head Q/K RMSNorm.
• 256 Experten, sigmoid top-6, plus ein geteilter Experte. Die Schichten 0 und 1 verwenden stattdessen ein dichtes MLP.

Der NVFP4-Checkpoint ist eine GGUF-Datei, deren Blöcke NVIDIAs NVFP4-Format in einer anderen Byte-Reihenfolge sind. vLLM packt sie beim Laden verlustfrei um und betreibt sie weight-only (W4A16), mit BF16-Aktivierungen und KV-Cache, so wie es Recursives Referenzimplementierung tut. Jeder Flint-Kernel folgt den Rundungspunkten der Referenz, und die Genauigkeit entspricht ihr bei GSM8K, GPQA-Diamond, Long-Context MRCR und einer Tool-Calling-Suite.

Optimierungen

Unsere erste Implementierung, aufgebaut auf vLLMs Standard-Schichten, war bei kleinen Batchgrößen langsam: Ein Dekodierungsschritt lief 1,096 Kernel, von denen viele für viel größere Batches abgestimmt waren. Wir ersetzten sie Schritt für Schritt durch Flint-spezifische Kernel und prüften jeden gegen die Referenz.

Abbildung 2: Model-Forward-Latenz auf einem GB200 nach jeder Änderung, für Batch-1-Dekodierung bei 100K Kontext und einem 8,192-token-Prefill. Schalten Sie den Checkpoint um oder zeigen Sie die Tabelle für jede Form an. Vollbild öffnen.

• Fusionierte Q/K-Norm, RoPE und KV-Cache-Schreibvorgang (−8%): ein Kernel statt dreien.
• MoE-Kernels für kleine Batches (−27 %): Router- und Expert-GEMVs, die nur die Gewichte der ausgewählten Experten lesen. Auch der größte Prefill-Gewinn.
• Kleinserien-Dichte-GEMV (−25 %) auf denselben gepackten NVFP4-Gewichten wie der Kernel für große Batches.
• Norm- und SiLU-Kernels (−10 %), die auf die Rundung der Referenz folgen.
• Attention entschlüsseln (−5%) mit Sinks und Sliding Windows, in CuTe DSL.
• Dekodierungspfad mit niedriger Latenz (−14%), unten dargestellt.

Bei bis zu 8 Anfragen durchläuft der Latenzarme-Pfad jede MoE-Schicht als sieben Kernels: Q/K-Norm, RoPE, Routing und das Expert-Combine werden in die benachbarten GEMV-Kernels integriert. Jeder Kernel wird mit programmatic dependent launch gestartet, sodass er seine Gewichte lädt, während der vorherige noch läuft.

Abbildung 3: Die sieben Kernels einer MoE-Schicht auf dem Pfad für Decodierung mit geringer Latenz.

Insgesamt ging NVFP4-Decode von 4.81 auf 1.78 ms zurück (2.7×), BF16-Decode von 3.53 auf 2.34 ms (1.5×) und ein 8K-Token-Prefill von 207 auf 145 ms (1.4×). Ein Forward läuft nun mit 346 Kernels statt 1,096. End-to-End ausgeliefert dauert Batch-1-Decode bei 100K Kontext 2.06 ms pro Token (etwa 485 Token/s), was dem Forward plus LM-Kopf und Sampling entspricht.

Hinweise zur Verwendung

• Flint emittiert Toolaufrufe und Thinking-Blöcke im Stil von GLM-4.7, daher die glm47 Parser. --exclude-tools-when-tool-choice-none entfernt Tool-Definitionen aus dem Prompt, wenn tool_choice ist "none", übereinstimmend mit der Referenz.
• Die Standard-Sampling-Einstellungen sind temperature 1.0, top-p 0.95 und top-k 20. Reasoning zählt zu max_tokens, daher sollten Sie für schwierige Probleme mindestens 32K einplanen.
• Die Flint-Kernels zielen auf eine einzelne Blackwell GPU (TP=1, BF16 KV cache); andere Konfigurationen greifen auf vLLMs Standard-Layer zurück.