vLLM et SGLang sur Strix Halo

L'essentiel

• vLLM est le serveur de référence du multi-utilisateurs : continuous batching natif, PagedAttention, métriques détaillées (TTFT, file d'attente, occupation KV) ².
• Sa doc liste gfx1151 avec ROCm 7.0.2 minimum ¹ ; les retours communautaires de 2026 décrivent des images patchées ^{4 5}. Contradiction non tranchée.
• Une seule comparaison publiée sur cette puce (Soothill, août 2026) : vLLM meilleur en montée en charge et en TTFT, mais quantifications non équivalentes ⁶.
• SGLang : non supporté officiellement sur gfx1151, image communautaire, 36 à 47 % derrière vLLM dans le même test. Non prioritaire.
• Position : évaluer vLLM, ne pas démarrer avec.

État du support gfx1151

Ce que vLLM apporte

• Ordonnancement : le continuous batching fonctionne au niveau de l'itération ; les séquences terminées libèrent leur place immédiatement. Anyscale a mesuré jusqu'à 23 fois le débit d'un batching statique sur GPU datacenter, avec une latence médiane améliorée ¹¹. llama-server fait aussi du continuous batching ; la différence tient à la maturité de l'ordonnanceur et à la gestion paginée du KV cache.
• Observabilité : vllm:num_requests_running, vllm:num_requests_waiting, vllm:kv_cache_usage_perc, vllm:time_to_first_token_seconds, vllm:inter_token_latency_seconds, vllm:e2e_request_latency_seconds ². C'est exactement ce que la Box doit surveiller pour tenir un SLA de temps de réponse ; llama-server n'expose ni TTFT ni file.
• Mesure Strix Halo (GMKtec EVO-X3, vLLM 0.26.0, llama.cpp b10333, ROCm 7.14.0) ⁶ :

Débits agrégés. Sur le 122B, les quantifications diffèrent (GGUF Q4_K_XL vs GPTQ) : la comparaison n'est pas à modèle égal. L'auteur conclut « there is no single fastest LLM server on Strix Halo ».

Ce que vLLM coûte

• Mémoire : vLLM pré-alloue le KV cache (fraction de la mémoire GPU) et charge les poids en BF16, FP8 ou via des quantifications GPTQ/AWQ ; le support des GGUF est partiel. Sur une machine à mémoire unifiée partagée avec la base vectorielle et l'interface, cette rigidité pèse. Chiffres à mesurer.
• Compatibilité modèles : les noyaux optimisés (AITER, FP8) sont désactivés sur gfx1x dans les images communautaires ; les MoE récents et les architectures hybrides sont les plus exposés.
• Complexité : pile Python + ROCm + Triton ; images de plusieurs Go ; dépendance à des patches tiers tant que le support upstream n'est pas confirmé.
• gpt-oss-120b sous vLLM sur Strix Halo : aucune mesure trouvée.

SGLang

Doc AMD officielle : MI300X et MI250 uniquement ⁷. Issue #5131 demandant gfx1151 fermée « inactive » sans réponse ⁸. Image communautaire SGLang 0.5.17 / ROCm 7.14 avec gfx1151 ajouté aux cibles AOT ¹⁰. Dans le test Soothill, SGLang est 36,2 à 46,7 % derrière vLLM ⁶. Apache-2.0 ⁹. Non prioritaire pour la Box.

Lemonade Server (AMD) propose un backend vLLM « expérimental, ROCm for Strix Halo » ¹² : signal que AMD y travaille, pas une garantie.

Quand basculer

Questions ouvertes

Ce qu'il reste à tester

• Évaluer vLLM sur ROCm gfx1151En septembre 2026, l'image officielle vllm/vllm-openai-rocm démarre sur gfx1151 avec ROCm 7.x sans patch, sert un MoE de taille moyenne, et donne un TTFT p95 inférieur à celui de llama-server à 5 clients ; mais elle ne sert pas gpt-oss-120b en MXFP4 sans conversion, et réserve plus de mémoire que llama-server pour un même contexte.À tester