Groot-19B-A3B tient son contexte complet de 256K sur une seule RTX 5090 de 32 GB, et une limite de 24 GB ne suffit pas

Crédits

• Groot-19B-A3B-261023 : GrootTeam. Ils ont post-entraîné le modèle, publié les versions BF16, FP8, NVFP4 et GGUF (créées le 2026-10-23, sans accès restreint, étiquette license:apache-2.0), la couche MTP, les recettes vLLM et SGLang, les tableaux de benchmarks et les graphiques que nous avons utilisés comme tests de vision. Dépôts : BF16, FP8, NVFP4, GGUF.
• Modèle de base : Qwen3.6-35B-A3B de l'équipe Qwen.
• Service : le projet vLLM (0.32.0) et FlashInfer.
• Où nous l'avons repéré : AI Search, "AI finally sleeps, Gemini 4 Carbon, ETH cracked, energy-based models, Anthropic IPO: AI NEWS", mise en ligne le 2026-11-01, chapitre Groot à 47:33. La vidéo couvre quatre variantes de Groot ; cet article ne porte que sur le 19B.
• Notre part : le déploiement à travers la plateforme, les prompts et les tests, les mesures, l'échelle de VRAM, l'exemple du SDK et la vidéo de démo.

Modèle et fichiers

• Un modèle mixture-of-experts (MoE), l'architecture que nous avons expliquée dans notre article sur Sage-A1.5. Son architecture hybride vient de Qwen3.6-35B-A3B.
• Architecture Qwen3_5MoeForConditionalGeneration : environ 19B paramètres au total plus une couche MTP de 0,4B, environ 3B actifs par token. 40 couches, 10 à attention complète (full_attention_interval 4) et 30 à attention linéaire. Hidden 2048, 16 têtes d'attention, 2 têtes KV, head_dim 256, vocabulaire de 248 320. 128 experts routés plus 1 partagé, 8 routés actifs par token. max_position_embeddings 262 144, extensible à environ 1M avec YaRN (facteur 4.0), selon la page des auteurs.
• FP8 : blocs de 128x128, E4M3, activations dynamiques.
• Estimation approximative du KV pour les couches à attention complète : 10 couches x 2 têtes KV x 256 x 2 (K et V) x 2 B = 20 KiB par token, soit environ 5 GiB pour 256K, plus la couche MTP et les états de l'attention linéaire.

Affirmations des auteurs (non reproduites)

• Devant les deux sur 12 benchmarks sur 16. 45,7 % de paramètres totaux en moins que Qwen3.6-35B-A3B, 26,9 % de moins que Gemma-4-26B-A4B.
• Budget de tokens : sortie moyenne la plus courte des 12 modèles mesurés sur les 16 exécutions, 23,1 % de tokens de sortie en moins que Qwen3.6-35B-A3B et 65,6 % de moins que Gemma-4-26B-A4B.
• Réglages d'évaluation : mode réflexion à l'effort par défaut, temperature 1.0, top_p 0.95, top_k 20, contexte de 256K. Terminal-Bench 2.1 avec l'agent Claude Code (max_output_tokens 128K, max_turns 500, timeout de 12 h). NL2Repo-Bench avec l'agent Claude Code, max_turns 1000, contexte de 80K. HLE jugé par gpt-5.5.
• "Où il tourne" (présenté comme estimé à partir de la capacité mémoire) : BF16 sur un GPU de 48 ou 80 GB ; FP8 et NVFP4 à 256K sur une RTX 5090 ; GGUF à 128K sur une RTX 4060 Ti de 16 GB et à 256K sur une RTX 4090/3090 de 24 GB ; 256K sur les machines à mémoire unifiée de 128 GB. Face à Qwen3.6-35B-A3B : sur 16 GB, Groot tourne à 128K alors que Qwen3.6 ne se charge pas ; sur une RTX 5090, 256K contre 64K.
• Prérequis d'exécution : Transformers >= 5.8.1, vLLM >= 0.19.1, SGLang >= 0.5.10. Réflexion activée par défaut, désactivée avec chat_template_kwargs={"enable_thinking": False}, pas d'interrupteurs /think ni /nothink. Échantillonnage recommandé en réflexion : temperature 1.0, top_p 0.95, top_k 20, min_p 0, presence_penalty 1.5. Code : temperature 0.6, presence 0. Sans réflexion : temperature 0.7, top_p 0.8.

Installation

• Une RTX 5090, 32 607 MiB, 575 W, driver 595.91.07 (CUDA 13.2), compute capability 12.0, disque de 100 GB, sur notre cloud (InferenceKey Cloud).
• Pourquoi cette carte : le plan de test prévoyait une L40S pour l'exécution principale, mais l'affirmation phare des auteurs cite la RTX 5090, l'exécution principale est donc allée directement sur elle. Les échelons serrés ont tourné sur la même machine sous des plafonds de mémoire émulés.
• Les requêtes passaient par l'endpoint compatible OpenAI de la plateforme (/v1/chat/completions, streaming) ; les mesures de vitesse avec MTP désactivé allaient directement à vLLM.
• Backend vllm standard, vllm_version="0.32.0" (installe Transformers 5.19 et torch 2.13 pour CUDA 13). SGLang non utilisé.
• Un manager InferenceKey local construit depuis origin/main ce3af2dc a amorcé le worker. La production n'a pas été impliquée.
• Échantillonnage pour les mesures de vitesse : temperature 1.0, top_p 0.95, presence_penalty 1.5, streaming. top_k=20 vient de generation_config.json.

Pas à pas avec l'exemple du SDK

1. Clonez inferencekey-sdk et ouvrez examples/groot-19b-a3b-fp8-agent-vllm-private-nvidia/ (commit 1c254204).
2. Compilez le SDK Python en local avec maturin (voir examples/CONTRIBUTING.md, section 4) et pip install -r requirements.txt (requests>=2.31).
3. cp .env.example .env et renseignez INFERENCEKEY_SDK_TOKEN (ik_sdk_, scopes workload:read et workload:write), INFERENCEKEY_API_KEY (ik_live_, avec le workload dans allowed_endpoints), INFERENCEKEY_PROJECT et IK_WORKER_ID (un worker NVIDIA privé de 32 GB ou plus avec un driver CUDA 13, 580 ou plus récent). Optionnel : GROOT_CONTEXT (par défaut 262144), GROOT_MTP (par défaut 1), IK_KEEP_ALIVE=1.
4. python main.py. Le déroulé : ensure() d'un workload vllm fixe épinglé à votre worker (ExecutionPolicy.FIXED), wait_until_ready(timeout=2400), une question simple avec generate_text(), le prompt des auteurs "I love Groot backwards" en streaming, un appel d'outil get_weather avec le résultat de l'outil renvoyé, le graphique des auteurs comme image, les réponses dans outputs/answers.json, puis delete() sauf si IK_KEEP_ALIVE=1.

La commande que l'exemple déploie :

vllm serve GrootTeam/Groot-19B-A3B-261023-FP8 --max-model-len 262144 \
  --gpu-memory-utilization 0.92 --max-num-seqs 8 --enable-prefix-caching \
  --limit-mm-per-prompt '{"image": 2, "video": 0}' \
  --reasoning-parser qwen3 --enable-auto-tool-choice --tool-call-parser qwen3_coder \
  --speculative-config '{"method": "qwen3_next_mtp", "num_speculative_tokens": 2}'

Pour servir sans réflexion, ajoutez :

--default-chat-template-kwargs '{"enable_thinking": false}'

Sortie principale de l'exemple : le prompt à l'envers, 460 tokens en 2,12 s à 307,1 tok/s, réponse "toorG evol I" ; la question d'explication du MoE en 3,8 s.

Délais

• De ensure() à prêt sur un worker à froid : 611,5 s. Installation de vLLM 0.32.0 environ 170 s, téléchargement des poids 27,8 s, chargement 51,7 s (19,67 GiB), préchauffage du moteur 312,6 s (compilation 37,5 s, deux captures de CUDA graphs et du spéculateur d'environ 2 min chacune, JIT FlashInfer).
• Redémarrage à chaud (MTP désactivé, caches sur disque) : préchauffage du moteur 86,8 s (compilation 37,1 s), poids 19,24 GiB en 23,4 s.

Mémoire

• --gpu-memory-utilization 0.92, contexte de 262 144, MTP activé : KV disponible 6,77 GiB = 307 024 tokens, concurrence maximale 1,17x. Pool de CUDA graphs 0,19 GiB.
• Idem avec MTP désactivé : 7,37 GiB = 376 253 tokens, 1,44x.
• nvidia-smi chaque seconde : 30 226 MiB en service, pic de 32 016 sur 32 607 MiB pendant le prompt de 205K (530 à 566 W).

Vitesse (une requête, streaming)

• La comparaison MTP mélange deux chemins (MTP activé à travers la gateway, MTP désactivé en direct). Le surcoût de la gateway n'était pas mesurable dans notre précédent test de Sage-A1.5 et n'a pas été remesuré ici.
• Tokens de raisonnement (usage.completion_tokens_details.reasoning_tokens, exécutions en direct) : 120 sur 125 pour la question courte ; 2 043 sur 2 383 et 6 785 sur 7 156 pour les essais. reasoning_content de 9,6K à 23,7K caractères sur les essais.

Outils, vision, réflexion

• L'exemple get_weather des auteurs : {"city": "Paris"}, JSON valide, 0,9 s ; réponse finale 0,96 s.
• Deux villes : un tour avec deux appels get_weather parallèles (Lisbonne, Oslo ; 101 tokens de complétion, 0,93 s), puis la réponse (50 tokens, 0,88 s), 1,81 s au total. Prise enregistrée : 2,9 s (tour 1 de 454 tokens en 1,99 s, tour 2 de 65 tokens en 0,91 s). La longueur du raisonnement sur les tours d'outils n'a pas été capturée de façon fiable dans le test principal (0 caractère enregistré, alors que la prise enregistrée montre 1 287 et 147 caractères).
• Graphique en nuage de points (9 279 tokens de prompt) : "Groot-19B-A3B ... approximately 42" en 4,12 s. Graphique en barres (16 329 tokens de prompt) : "52.10 ... Gemma-4 (26.52) and Qwen3.6 (43.82)" en 9,21 s, premier token à 7,25 s.
• chat_template_kwargs={"enable_thinking": false} à travers l'endpoint : a quand même réfléchi (571 caractères de raisonnement, 157 tokens de complétion).

Échelle de VRAM

Erreur avec le plafond de 24 GB :

ValueError: To serve at least one request with the model's max seq len (65536), (1.66 GiB KV cache is needed, which is larger than the available KV cache memory (0.48 GiB). Based on the available memory, the estimated maximum model length is 9648.

Plafond de 16 GB, NVFP4 : vLLM journalise que le GPU n'a pas de support FP4 natif et se rabat sur une compression FP4 des poids seuls avec le kernel Marlin, puis la compilation JIT de FlashInfer 0.7.0.post1 de gen_gemm_sm120_group_gemm_fp8_groupwise_e4m3_bf16_majorfalse_sm120 et de ses voisins échoue (nvcc 13.0.88), et se termine par RuntimeError: Engine core initialization failed.

Non essayés : un échelon FP8 de 24 GB à 9,6K ou moins (le propre chiffre de vLLM dit qu'il démarrerait, mais les auteurs recommandent au moins 128K), la version GGUF sur llama.cpp, NVFP4 sur une autre version de vLLM ou de FlashInfer ou sur SGLang, de vraies cartes de 24 et 16 GB, la RTX PRO 4500 32 GB, la L40S, BF16. La ligne de compatibilité du README du SDK cite aussi les RTX PRO 4500/5000, L40S et cartes de classe A6000 ; seule la RTX 5090 a été mesurée.

Problèmes restants

1. L'endpoint ignore chat_template_kwargs, top_k et min_p. La page des auteurs désactive la réflexion par requête avec chat_template_kwargs={"enable_thinking": False}. Le ChatCompletionRequest du manager n'a pas ces champs, ils sont donc ignorés. La réflexion ne peut pas être désactivée par requête. Contournement : --default-chat-template-kwargs sur le serveur. Statut : ouvert, fonctionnalité manquante.
2. Premier démarrage lent. 611,5 s à froid, surtout le préchauffage du moteur. Le worker n'installe pas flashinfer-cubin avec vLLM 0.32 (avertissement "FlashInfer's precompiled kernels are missing"). Statut : ouvert.
3. Fenêtre complète à la limite de la carte. Moins de 600 MiB libres pendant le prompt de 205K. Gardez les autres processus hors du GPU, ou réglez GROOT_CONTEXT=131072.
4. NVFP4 ne démarre pas sur la RTX 5090 avec vLLM 0.32.0 (voir l'échelle) : pas de chemin FP4 natif sur sm_120, vLLM utilise donc le repli Marlin sur les poids seuls, puis la compilation JIT de FlashInfer échoue. Cela peut venir de l'image de notre worker, à laquelle il manque flashinfer-cubin (problème 2). Options : ajouter les kernels précompilés, essayer une autre version de vLLM ou de FlashInfer, ou essayer SGLang (aucune testée). Pour les cartes de 16 et 24 GB, les auteurs renvoient à la version GGUF sur llama.cpp (non testée). Statut : ouvert, peut-être l'image de notre worker.
5. Erreurs sur la page du modèle. Les commandes de service utilisent Groot/Groot-19B-A3B-261023, qui ne se résout pas (API HF 401) ; le dépôt est GrootTeam/Groot-19B-A3B-261023. Le front matter renvoie vers un fichier LICENSE qui répond 404 dans les quatre dépôts ; la licence n'existe que comme étiquette apache-2.0 et dans les métadonnées. Statut : signalé ici, toujours sur la page.
6. Dépréciation. vLLM 0.32 journalise qwen3_next_mtp comme alias déprécié de mtp. Cela fonctionne.
7. Limite du scheduler. Les réglages spéculatifs fixent max_num_scheduled_tokens à 2048.

Image de synthèse

Vidéo de démo

La démo commentée de 143 secondes : le déploiement dans le panneau, l'appel d'outil à deux villes sur la RTX 5090, le graphique des auteurs et l'échelle de mémoire. L'affiche montre notre tenant de démo.

Sources

• Page du modèle et dépôts : BF16, FP8, NVFP4, GGUF (README identique dans les quatre), et le lien LICENSE (404 le 2026-11-03).
• Listings de l'API Hugging Face des quatre dépôts, récupérés le 2026-11-03.
• Exemple du SDK, commit 1c25420460d2277219490af8bcf0ec7c173aa423.
• Vidéo d'AI Search, IGICYFyP_EI, où nous avons repéré le modèle.
• Nos propres logs : les logs de vLLM et du worker, les relevés nvidia-smi chaque seconde, et les sorties JSONL des tests de vitesse, d'aiguille, d'outils, de graphiques et de réflexion.