Les trois machines
Les trois machines sont des GMKtec EVO-X2, basées sur le processeur AMD Ryzen AI Max+ 395 avec de la mémoire unifiée. C'est ce point — la mémoire unifiée — qui rend ce matériel particulièrement adapté aux modèles de langage locaux : pas de transfert GPU/CPU, la totalité de la RAM est visible par le moteur d'inférence. Chaque machine tourne sous Ubuntu avec une stack d'inférence différente selon son rôle.
Machine 1 — Le nœud de codage (128 GB)
C'est la machine dédiée à l'assistance au développement via Cline dans VS Code. Elle fait tourner deux modèles en permanence : Qwen3.6-27B (le modèle "plan") et Qwen3.6-35B-A3B (le modèle "act").
La distinction entre les deux est volontaire. La phase plan, c'est celle où Cline réfléchit à ce qu'il va faire — il décompose la tâche, identifie les fichiers à modifier, structure l'approche. Pour ça, un modèle dense de 27B avec de bonnes capacités de raisonnement structuré est idéal. La phase act, c'est l'exécution : générer du code, modifier des fichiers, écrire des tests. Le 35B-A3B est un modèle MoE qui n'active qu'une fraction de ses paramètres à chaque inférence — il est plus rapide pour ce type de requêtes courtes et répétées, ce qui compte quand Cline enchaîne les actions.
Le tout est exposé via un routeur FastAPI sur le réseau local, et accessible depuis les postes de développement Windows via LLMRouter.exe, un petit exécutable tray qui intercepte les requêtes Cline et les redirige vers le bon modèle selon la phase. Cline ne voit qu'une seule URL, le routeur fait le reste. C'est portable — la même config fonctionne au bureau, à la maison, ou depuis n'importe quel poste sans rien installer.
Machine 2 — Le nœud RAG (96 GB)
C'est la machine centrale du projet, celle qui fait tourner RAG Pro. Elle héberge l'ensemble du pipeline documentaire et conversationnel qui sert à la fois d'outil quotidien et de terrain d'expérimentation.
RAG Pro v3 est aujourd'hui structuré autour d'un système de plugins. L'idée de base : le core de l'application ne sait pas ce que signifie "indexer un document" — ce n'est pas son rôle. Il sait router une requête vers le bon plugin selon le type de projet, gérer les jobs d'ingestion, streamer les réponses. Les plugins, eux, portent la logique métier.
Il y a aujourd'hui cinq plugins actifs :
- Documents — le plugin RAG classique. PDF, DOCX, TXT sont découpés, vectorisés, indexés dans Qdrant avec une recherche hybride (sémantique + BM25). C'est la base du projet, celle qui répond aux questions sur la documentation Oracle ERP, les exports markdown, les procédures internes.
- Analyse de données — pensé pour les fichiers XLSX et CSV issus de l'ERP. Un fichier de 12 000 lignes peut être chargé, profilé, et interrogé en langage naturel. Le plugin génère du code pandas validé par AST plutôt que de tenter une réponse directe — ce qui garantit que les calculs sont justes même sur des volumes importants.
- Code project — pour les bases de code Python, JS, TS. Index de symboles, graphe de dépendances, recherche sémantique sur le code source. Sert de base à la migration DirectSalesVD v2.
- Migration VBA — spécifique aux fichiers XLSM qui contiennent du code VBA. Extraction de la logique métier, cartographie des macros, génération de l'équivalent Python. Directement connecté au chantier de migration des outils Excel de production.
- Web search avec mitigation — le plugin le plus récent. Plutôt que de renvoyer le premier résultat d'une source unique, il interroge plusieurs sources en parallèle et croise les résultats avant de les injecter en contexte. L'objectif est de mitiger les biais d'une source unique et d'améliorer la fiabilité des réponses sur des sujets qui évoluent — versions de librairies, documentation en ligne, procédures Oracle Apex.
Le modèle principal sur cette machine est Qwen3.6-35B-A3B en BF16, avec un contexte de 262K tokens. C'est ce contexte étendu qui permet d'ingérer des fichiers volumineux ou des historiques longs sans perdre la cohérence de la réponse.
L'API context pour Cline est aussi portée par cette machine. Concrètement : quand Cline travaille sur un fichier Python, il peut interroger RAG Pro pour récupérer du contexte pertinent — documentation ERP associée, autres modules du projet, historique des changements. C'est la boucle qui fait que le codage assisté n'est pas juste de la génération de code générique mais quelque chose d'ancré dans la réalité du projet. Cline sur la machine 1 tire du contexte depuis la machine 2 — c'est le local dev bouclé sur lui-même.
Machine 3 — Le nœud image (96 GB)
C'est la machine la plus récente dans son rôle actuel. Elle est dédiée à la génération d'images via des modèles de diffusion, complètement isolée des deux autres pour éviter toute contention mémoire pendant les générations.
Deux modèles sont actifs :
- FLUX.1-Schnell — modèle de diffusion rapide de Black Forest Labs. Génération en quelques étapes, bon rapport vitesse/qualité pour une première passe ou des itérations rapides.
- FLUX.1-Kontext — la variante contextuelle du même modèle, pensée pour les modifications d'image à partir d'une image source. Idéal pour des cas où on part d'un visuel existant et qu'on veut le faire évoluer de manière cohérente.
Le worker est un service FastAPI (qwen-image-worker) avec une architecture flip-flop : un seul modèle est chargé en mémoire à la fois. Quand une requête arrive pour l'autre modèle, le modèle actif est déchargé proprement avant que le suivant soit initialisé. Ça évite de saturer les 89 GB de mémoire unifiée en voulant garder les deux en RAM simultanément.
La connexion avec la machine 2 est directe : RAG Pro expose une interface de génération d'image qui passe par le worker de la machine 3. Les utilisateurs interagissent depuis l'interface RAG Pro, le résultat revient via le réseau local. L'idée à terme est qu'un prompt optimisé puisse être construit côté machine 2 (via le LLM) avant d'être envoyé à la machine 3 — un worker de prompt dédié est en cours de réflexion pour ça.
Ce que ça change dans la pratique
L'intérêt de cette architecture à trois nœuds n'est pas technique pour le plaisir d'être technique. C'est que chaque machine peut évoluer indépendamment. Si on change le modèle d'inférence sur la machine 1, ça n'affecte pas le RAG. Si on ajoute un plugin sur la machine 2, ça ne touche pas la génération d'image. Et surtout, les workflows peuvent tourner en parallèle — Cline qui refactore du code pendant que le RAG répond à une question, pendant qu'une image se génère en arrière-plan.
Le cluster est entièrement on-premises, sans dépendance cloud. Les données ne quittent pas le réseau local. Pour des usages qui touchent à de la documentation interne ou à du code propriétaire, c'est un prérequis, pas un choix.
