Architecture Box v1

L'essentiel

• La Box v1 est une machine unique (candidate : Framework Desktop, Ryzen AI Max+ 395, 128 Go) sous Linux, sur laquelle tous les services tournent dans Docker Compose.
• Le runtime d'inférence candidat est llama-server (llama.cpp) exposant une API OpenAI-compatible ; l'interface candidate est Open WebUI, qui porte aussi le RAG et les comptes en V1.
• La base vectorielle n'est pas tranchée : PostgreSQL + pgvector (une seule base pour tout) ou Qdrant (filtrage par permissions intégré à l'index). C'est la question Q-004.
• La mémoire unifiée de 128 Go est la ressource à budgéter : modèle, KV cache, embeddings et services doivent tenir avec une marge. Le tableau ci-dessous donne des ordres de grandeur, tous marqués comme estimations à mesurer.
• Tout ce qui suit est une hypothèse de travail : elle sert à écrire le POC, pas à figer le produit.

Composition candidate

Schéma de déploiement Docker Compose

Services

Règles de configuration :

• Ports : seul caddy publie des ports sur l'hôte. Tous les autres services sont joignables uniquement par nom sur un réseau Docker interne. Un docker ps ne doit montrer aucun autre port publié.
• Accès GPU : les conteneurs d'inférence reçoivent les périphériques /dev/dri (Vulkan) et, si ROCm, /dev/kfd, ainsi que les groupes video et render. Aucun autre conteneur n'a accès au GPU.
• Volumes : les modèles GGUF sont montés en lecture seule ; les documents sources sont montés en lecture seule ; les données applicatives vivent dans des volumes nommés, tous inclus dans la sauvegarde.
• Secrets : jamais en clair dans compose.yaml. Fichier .env en permissions 600 ou secrets Docker ; clés générées à l'installation et consignées dans le coffre du prestataire, pas dans le dépôt Git.
• Versions : chaque image est figée sur un tag précis et le fichier Compose est versionné. Les mises à jour se font par changement de tag, test, puis redéploiement.
• Redémarrage : restart: unless-stopped partout ; l'ordre de démarrage est garanti par depends_on avec conditions de santé (healthcheck) sur PostgreSQL et llama-server.
• Réglage mémoire GPU : la part de mémoire unifiée allouable au GPU dépend de la réservation BIOS et des paramètres GTT/TTM du noyau. La documentation AMD recommande de garder la réservation BIOS petite et d'augmenter la limite partagée. La valeur pratique atteignable reste à mesurer sur la machine (Q-011).

Allocation mémoire cible

La machine dispose de 128 Go de mémoire unifiée partagée entre le CPU et le GPU. Le tableau suivant budgète cette mémoire pour un scénario de référence : modèle de chat gpt-oss-120b, quatre slots de 32 000 tokens chacun, embeddings et reranker chargés, base vectorielle pgvector.

Points d'attention :

• Le modèle change tout. Un modèle dense de 70 milliards de paramètres en Q4 pèse plus de 40 Go et son KV cache est bien plus lourd par token (de l'ordre de 10 Go pour 32k tokens f16 selon les calculs de la recherche inférence, donc environ 40 Go pour quatre slots de 32k). Il consommerait toute la marge et serait par ailleurs lent en génération, car limité par la bande passante mémoire. Les architectures MoE à faible nombre de paramètres actifs sont plus adaptées à cette machine. Voir Inférence et Multi-utilisateurs.
• Le KV cache se quantifie. Passer le cache en q8_0 divise son empreinte par deux, au prix d'une perte de qualité à mesurer.
• Le nombre de slots est un choix. Quatre slots couvrent l'hypothèse « 1 à 3 utilisateurs actifs simultanément » avec une réserve. Le débit par utilisateur baisse quand les slots sont occupés en même temps (voir la question Q-001).
• La limite GPU n'est pas 128 Go. Selon les réglages, la part allouable au GPU rapportée par la communauté se situe entre 96 et 120 Go environ ; la valeur exacte sur notre machine reste à mesurer (Q-011).

Points de choix et alternatives

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
• Scan de vulnérabilités des images Docker de la BoxLes images officielles de la pile retenue ne contiennent aucune vulnérabilité critique exploitable dans le contexte de la Box (services non exposés, réseau interne), et un scan mensuel automatisé avec Trivy plus un SBOM par image permettent de suivre les correctifs sans effort excessif.À tester
• Valider l'installation reproductibleUne personne compétente en administration Linux mais sans connaissance préalable du projet réinstalle la Box en moins d'une demi-journée à partir de la page Installation et du dépôt de configuration, et obtient le même résultat à la checklist de validation que l'installation initiale.À tester