Mesures · Intel Arc Pro B60
Intel Arc Pro B60 pour l’inférence LLM : ce que font vraiment quatre cartes
Trois modèles MoE gardés en VRAM en même temps sur 4× Arc Pro B60 24 Go, servis par llama.cpp (SYCL) et vLLM-XPU. Mesuré les 10 et 11 septembre 2026 sur une machine qui porte aussi une charge de production : ces chiffres sont un plancher, pas un plafond. Chaque chiffre, script et panne est dans notre dépôt public.
La machine
| GPU | 4× ASRock Arc Pro B60 Creator 24 Go (BMG-G21), chacune en PCIe x8 Gen3 |
|---|---|
| Hôte | Intel i9-9980XE, X299 (2018), 64 Go DDR4-3200 |
| OS / pilote | Ubuntu 24.04, noyau 7.0 HWE, pilote xe, GuC 70.72.1 |
| Moteurs | intel/vllm:0.21.0-xpu et llama.cpp SYCL (image server-intel) |
Trois modèles résidents en même temps
| Carte | Modèle | Format / moteur | Poids |
|---|---|---|---|
| 0 | gpt-oss-20b | MXFP4 · vLLM-XPU | 13 Go |
| 1 | Qwen3-Coder-30B-A3B | GGUF Q4_K_XL · llama.cpp SYCL | 17,7 Go |
| 2 + 3 | Qwen3-Next-80B-A3B | GGUF Q3_K_XL · llama.cpp SYCL | 35,6 Go |
130 milliards de paramètres au total, environ 3 milliards actifs par token dans chaque modèle. 81,7 Go sur 96 utilisés, poids et cache KV compris.
Débit d’un modèle seul, à chaud
| Modèle | Génération | Lecture du prompt (~4k tokens) |
|---|---|---|
| Qwen3-Coder-30B-A3B | 82,4 tokens/s | 4 098 tokens en 4,2 s |
| gpt-oss-20b | 41,2 tokens/s | 3 307 tokens en 2,4 s |
| Qwen3-Next-80B-A3B | 36,2 tokens/s | 4 098 tokens en 10,3 s |
Le premier appel après chargement est 3 à 4 fois plus lent : envoyer une requête de préchauffe avant le vrai trafic.
Montée en charge : où ça tient, où ça casse
Avec les trois modèles servant 12 requêtes simultanées, 3 600 tokens sont sortis en 30,3 s (119 tokens/s agrégés), sans erreur et sans qu’un modèle ralentisse l’autre. Modèle par modèle, c’est le moteur qui décide de tout.
gpt-oss-20b sous vLLM-XPU (batching continu)
| Requêtes simultanées | Par requête | Agrégé |
|---|---|---|
| 1 | 35,1 tokens/s | 35,1 |
| 2 | 35,0 tokens/s | 70,0 |
| 4 | 33,6 tokens/s | 133,9 |
| 8 | — | 241 |
Qwen3-Next-80B sous llama.cpp SYCL (sans batching continu)
| Requêtes simultanées | Par requête | Agrégé |
|---|---|---|
| 1 | 32,0 tokens/s | 32,0 |
| 2 | 14,5 tokens/s | 28,8 |
| 4 | 7,0 tokens/s | 20,7 |
Correction, publiée ouvertement : notre première mesure de concurrence divisait les tokens par le temps total. Elle flattait les modèles rapides et cachait la régression du 80B. Les tableaux ci-dessus sont les chiffres corrigés.
Règle de conception qu’on en tire : tout ce qui est sensible à la latence (voix, complétion interactive) va au modèle servi par vLLM. Un grand modèle sous llama.cpp sert environ deux utilisateurs simultanés, pas quatre.
Ressources de l’hôte et consommation
| Au repos, 3 modèles chargés | Sous 12 requêtes simultanées | |
|---|---|---|
| RAM hôte disponible | 43,1 Go sur 62 | 41,5 Go (creux) |
| VRAM utilisée | 81,7 Go sur 96 | idem |
| Consommation, 4 cartes | 163 W | 211 W au pic |
| Températures | 52–62 °C | 52–62 °C |
64 Go de RAM hôte suffisent pour cette configuration. La contrainte est au chargement, pas en service : les modèles doivent être chargés l’un après l’autre.
Onze pannes rencontrées
La partie qui n’est documentée nulle part ailleurs. Les messages d’erreur exacts et les correctifs sont dans le dépôt.
- vLLM-XPU ne sert que les quantisations qui ont un noyau XPU natif : MXFP4 marche, la plupart des MoE quantifiés échouent sur un chemin réservé à NVIDIA.
- AWQ exige --dtype float16 explicitement.
- oneCCL ne peut pas échanger les handles IPC entre workers, ce qui bloque le parallélisme de tenseurs.
- Deux processus sur le même GPU peuvent bloquer l’hôte.
- Les modèles doivent être chargés l’un après l’autre : les chargements parallèles ont gelé la machine trois fois.
- La première inférence après chargement est 3 à 4 fois plus lente.
- Docker --ipc host annule sans prévenir shm_size.
- Une carte dont le connecteur 8 broches est débranché disparaît simplement du bus PCI.
- Les cartes Battlemage affichent x1 dans lspci : c’est cosmétique, lire le port racine.
- Le firmware GuC 70.44.1 était instable ; le 70.72.1 de kernel.org l’a corrigé, sans redémarrage.
- Vulkan n’est pas une alternative à SYCL pour la génération.
Quelles cartes mères prennent quatre cartes
Les Arc Pro à turbine font deux slots d’épaisseur, ce qui élimine la plupart des cartes serveur. Mesuré sur les plans des fabricants : les ASUS Pro WS WRX90E-SAGE SE et W790E-SAGE SE en prennent quatre sur 8 emplacements ; les Supermicro H13SSL-N et H12SSL-i seulement trois. Tableau complet dans le dépôt.
Pas encore mesuré
- Le parallélisme de tenseurs, quelle que soit la taille (bloqué, voir plus haut)
- Arc Pro B70 et Arc Pro B60 Dual : pas encore de cartes
- Contexte long au-delà de 64k
Utiliser les données
Code sous MIT, documentation et mesures sous CC BY 4.0 : reprenez les chiffres, citez le dépôt. Une erreur ? Ouvrez une issue.
La même pile, livrée
SOKKAN Anchor, c’est cette machine, assemblée à Genève avec les trois modèles déjà en service et une API compatible OpenAI. Vous pouvez tester le modèle de code 30B sur ces mêmes cartes avec une clé d’essai avant d’acheter.