Cluster 2x DGX Spark RDMA + Qwen 3.8 27B mono-spark

Fiche de réalisation : janvier 2026, en production depuis février 2026.

Objectif

Disposer d'une plateforme locale qui fait tourner DeepSeek V4 Flash 284B (13B actifs) en FP4 et Qwen 3.8 27B en FP8, avec deux contextes distincts : 1 million de tokens pour DeepSeek sur un cluster de deux Spark, 262 144 tokens pour Qwen sur un mono-spark. La plateforme doit accepter des appels concurrents depuis plusieurs agents internes via LiteLLM, et router chaque requête vers le modèle le plus adapté via un routeur sémantique.

Matériel

Poste	Référence	Quantité
Serveur GPU	NVIDIA DGX Spark : 128 Go mémoire unifiée, ConnectX-7 200 Gb/s	3
Switch RDMA	NVIDIA Spectrum-3 200 GbE, 8 ports	1
Câblage	QSFP56 DAC 200 Gb/s, 1 m	4
Onduleur	APC Smart-UPS 3000 VA, double conversion	1
Baie 12 U	APC NetShelter, 19 pouces, 600 x 1000 mm	1

Coût total

Poste	Détail	Montant HT
DGX Spark	3 x 3 800 €	11 400 €
Switch Spectrum-3 + DAC	1 800 € + 200 €	2 000 €
Onduleur + baie	1 100 € + 300 €	1 400 €
Prestation QDNA	6 semaines d'ingénierie, intégration et mise en production	6 800 €
Total investissement		21 600 €

Coût récurrent annuel estimé : 1 200 € d'énergie (les 3 Spark consomment 1 100 W en charge moyenne), 600 € de maintenance onduleur, 400 € de bande passante interne.

Étapes et calendrier

Semaine 1 : Cadrage et choix matériel. Atelier d'une demi-journée : cas d'usage, contexte maximal attendu, débit cible, contraintes réseau. Décision : trois DGX Spark plutôt qu'une DGX Station, car la latence d'un seul noeud Spark ne couvre pas DeepSeek FP4 1M de contexte. Validation du format NVFP4 sur les poids DeepSeek.
Semaine 2 : Réception et mise en baie. Les trois Spark sont arrivées en baie 12 U, onduleur branché, ventilation vérifiée. Le switch Spectrum-3 est configuré en mode RoCE v2, deux liens entre chaque Spark et le switch pour la redondance (quatre liens au total utilisés, deux en réserve).
Semaine 3 : Mise en cluster RDMA. Configuration de NCCL pour pointer sur les interfaces ConnectX-7, validation d'un test de bande passante `nccl-tests all_reduce_perf` : 185 Gb/s mesurés entre les deux Spark, soit 92 % du nominal. Premier démarrage d'un modèle DeepSeek shardé sur deux noeuds, mesure du préremplissage à 1 M de contexte en 28 secondes.
Semaine 4 : Harness DeepSeek. Mise en place du script d'orchestration qui pousse les poids sur les deux noeuds, configure le KV cache sparse, surveille la latence inter-noeuds. Validation d'un débit de 68 tokens par seconde en single-user, 45 tokens par seconde en charge modérée (10 utilisateurs).
Semaine 5 : Orchestration LiteLLM et routeur sémantique. Déploiement de LiteLLM comme point d'entrée unique, branche « deepseek » sur le cluster Spark, branche « qwen » sur le mono-spark. Le routeur sémantique analyse chaque requête et choisit la branche selon le contenu : requêtes factuelles courtes vers Qwen, génération longue ou raisonnement vers DeepSeek.
Semaine 6 : Tests de charge et mise en production. Tests Locust : 200 utilisateurs virtuels, débit pic de 1 800 requêtes par minute, latence p95 à 1,8 seconde. Bascule de la production, validation des sla de réponse, débogage d'une boucle de retry sur le routeur sémantique qui doublonnait les requêtes.

Tailles de contexte et débit mesurés

Modèle	Matériel	Quantification	Contexte max	Préfill 1 M (Qwen 262 K)	Débit single-user
DeepSeek V4 Flash 284B (13B actifs)	Cluster 2 x Spark RDMA	NVFP4	1 048 576 tokens	28 s	68 tok/s
Qwen 3.8 27B	DGX Spark mono	FP8	262 144 tokens	3 s	120 tok/s

Harness DeepSeek sur les deux noeuds

Le harness repose sur trois briques :

vLLM en mode tensor-parallel shardé sur 2 GPU : chaque Spark expose un unique GPU Grace-Blackwell, NCCL fait le pont RDMA. Le modèle DeepSeek est découpé en deux shards, l'attention et les experts distribués sur les deux noeuds.
Cache KV sparse avec préremplissage segmenté : pour gérer 1 M de contexte, le cache KV est organisé en segments de 128 K, montés à la demande selon la fenêtre active. La sortie ne décode jamais les segments inactifs, ce qui ramène la consommation mémoire à 64 Kio par token au lieu de 256 Kio.
Supervision de la latence inter-noeuds : un watchdog mesure en continu le RTT RDMA. Si la moyenne mobile dépasse 12 µs, le cluster déclenche une alerte et coupe le trafic inter-noeuds pour basculer en mode dégradé (contexte limité à 512 K).

Écosystème LiteLLM et routeur sémantique

LiteLLM expose deux routes : /v1/chat/deepseek (cluster Spark) et /v1/chat/qwen (mono-spark). L'API externe est conforme OpenAI, un seul client pour les deux modèles. Les logs sont unifiés dans une base SQLite locale, expurgés après 30 jours.
Routeur sémantique : un embedding léger (bge-small) calcule la similarité cosinus entre la requête et un référentiel de 200 prototypes étiquetés à la main. Au-dessus de 0,72 de similarité avec un prototype « raisonnement long », la requête part vers DeepSeek. Sinon, vers Qwen. Latence ajoutée : 18 ms.
OpenCode : les agents internes (au nombre de quatre : refactor, revue, documentation, migration) consomment l'API LiteLLM. Le découpage agent ↔ modèle est explicite : Qwen pour les agents rapides et peu coûteux, DeepSeek pour le refactor de fichiers longs et la revue d'architecture.
Router OpenRouter : un second routeur, silencieux, réplique les requêtes vers OpenRouter (Claude Opus 5, GPT-5.5) pour les comparaisons de qualité. Activé uniquement sur 1 % du trafic, avec échantillonnage et logs de divergence.
Mem0 + couche sémantique QDNA : les succès et échecs des agents sont mémorisés par `(tâche, modèle, latence, score qualité)`. La couche sémantique enrichit chaque requête d'un résumé du contexte projet et des préférences utilisateur apprises.
Hermes Agent : orchestrateur de haut niveau, déclenche les sous-agents, accumule les résultats, gère les fallbacks. Hermes ne touche jamais aux chemins RDMA : il appelle LiteLLM en HTTP, c'est LiteLLM qui pousse vers le cluster.

Schéma

                 ┌───────────────────────────────┐
                 │  Hermes Agent                  │
                 │  (orchestrateur, HTTP)         │
                 └───────────────┬───────────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │  Routeur sémantique (bge-small)│
                 │  + couche mémoire Mem0        │
                 └───────────────┬───────────────┘
                                 │
                 ┌───────────────▼───────────────┐
                 │  LiteLLM (point d'entrée)      │
                 │  /v1/chat/deepseek  /v1/chat/qwen │
                 └───┬───────────────────────┬───┘
                     │ RDMA over RoCE v2     │ PCIe
                     │                       │
       ┌─────────────▼──────────┐ ┌─────────▼─────────┐
       │  Spark #1 + Spark #2    │ │  Spark #3        │
       │  cluster NVFP4 2x128Go │ │  Qwen 3.8 27B FP8 │
       │  DeepSeek V4 Flash 284B│ │  mono-noeud       │
       │  NCCL all_reduce 185G/s│ │  128 Go unifiés  │
       └────────────────────────┘ └───────────────────┘
                        │
                 ┌──────▼──────┐
                 │  Switch    │
                 │ Spectrum-3 │
                 │ 200 GbE    │
                 └────────────┘

Mesures en exploitation (six premiers mois)

Indicateur	Valeur
Requêtes servies par jour	14 500 (moyenne), pic à 31 800
Latence p50	0,42 s
Latence p95	1,8 s
Taux de routage vers DeepSeek	34 %
Taux de routage vers Qwen	66 %
Coût marginal par requête	0,001 € (amortissement + énergie)
Disponibilité sur six mois	99,97 % (une interruption de 2 h 30 sur onduleur)

Vous voulez reproduire cette architecture ?

Cadrage offert en une demi-journée, sur la base de vos cas d'usage et de votre volumétrie.

Réserver un échange

Questions fréquentes

Pourquoi deux DGX Spark plutôt qu'une seule ?

Pour servir DeepSeek V4 Flash 284B (13B actifs) en FP4, qui dépasse la mémoire d'une seule unité (128 Go). Le RDMA ConnectX-7 entre les deux Spark forme un domaine de 256 Go unifiés, suffisant en NVFP4.

Quel contexte maximal en pratique ?

DeepSeek : 1 M de tokens avec cache KV sparse sur 2 noeuds. Qwen 3.8 27B mono-spark : 262 144 tokens (262 K) en FP8, qui passent dans les 128 Go de la Spark.

Quel temps de mise en production ?

Six semaines depuis la signature jusqu'à la première requête validée. Trois semaines sur l'intégration matérielle et le cluster, une semaine sur le harness DeepSeek, deux semaines sur l'orchestration LiteLLM et le routeur sémantique.

Quel coût total d'investissement ?

Trois Spark à 3 800 € pièce, switch RDMA, onduleur, baies et câblage : 14 800 € matériel. Plus 6 800 € de prestation QDNA, soit 21 600 € hors énergie et bande passante.