Guide matériel OpenClaw : la passerelle, le calcul et le navigateur sont trois problèmes distincts

La plupart des discussions hardware autour d'OpenClaw posent la question sous l'angle « Mac mini vs workstation x86 », puis consacrent 2 000 mots à débattre de la bande passante mémoire unifiée. C'est le mauvais axe d'analyse.

L'architecture d'OpenClaw rend la vraie question évidente : qu'exécutez-vous réellement ? Le processus gateway, l'inférence locale et l'automatisation du navigateur ont des profils hardware complètement différents. Bien dimensionner l'un ne garantit pas automatiquement les autres.

Les trois rôles hardware

OpenClaw est conçu gateway-first. Un seul processus Gateway gère vos surfaces de messagerie — WhatsApp, Telegram, Slack — et fait tourner un control plane WebSocket auquel tout le reste se connecte (par défaut : 127.0.0.1:18789). Les clients, les automatisations et les nodes s'y connectent tous.

De cette conception émergent trois rôles hardware :

• Hôte gateway — toujours actif, gère les connexions aux canaux et les données du workspace, exécute les outils
• Hôte de calcul — inférence locale, GPU, KV-cache, sessions de modèles parallèles
• Hôte navigateur — Playwright ou CDP, gère les tâches d'automatisation web

La propre documentation d'OpenClaw traite « un gateway par hôte » comme un principe de conception : le gateway est le seul processus qui devrait posséder une session WhatsApp Web. Pour l'isolation multi-utilisateurs, vous voulez plusieurs gateways sur des hôtes séparés — et non un gateway partagé mis à l'échelle. Cela influence les décisions d'achat bien plus que n'importe quel benchmark.

Gateway : la stabilité compte plus que la performance

Le gateway en lui-même n'est pas gourmand en calcul. Ce qui détermine ses exigences hardware :

• Performance single-thread pour la boucle événementielle et les I/O
• Suffisamment de cores pour l'exécution parallèle des outils — Playwright, ffmpeg, tâches CLI, containers
• Stockage fiable pour les workspaces, pièces jointes et logs qui s'accumulent en continu

Sans inférence locale, 32 Go de RAM couvrent confortablement un gateway exécutant Playwright et des outils. Un Mac mini M4 (ou M4 Pro) est un excellent hôte gateway — 10GbE en option, jusqu'à 64 Go de mémoire unifiée, 155 W de consommation continue maximale. Un mini-PC x86 avec 2.5GbE et un NVMe de qualité couvre le même périmètre sous Linux ou WSL2.

Le stockage mérite une attention particulière ici. Les workspaces, pièces jointes, logs et artefacts de modèles grossissent en permanence. Le Samsung 990 Pro 2 To est livré avec 1 200 TBW et un chiffrement AES-256 sur disque complet — cette endurance compte davantage que la vitesse de lecture séquentielle maximale pour un gateway fonctionnant en continu.

Inférence locale : la VRAM est la contrainte

Ajouter l'inférence locale change complètement l'équation. Le goulot d'étranglement est rarement le calcul (FLOPS). C'est la mémoire : les poids du modèle chargés dans le format de précision approprié, plus un KV cache qui croît linéairement avec la taille du batch et la longueur de séquence.

Un exemple concret : Llama 2 7B en FP16, contexte 4K, batch size 1 nécessite environ 2 Go pour le KV cache seul. Augmentez le contexte ou le parallélisme et vous épuisez rapidement la mémoire disponible. Plus de VRAM est le levier le plus direct pour des contextes plus longs et davantage de sessions concurrentes.

C'est ici que l'argument « la mémoire unifiée remplace la VRAM » se heurte à un mur structurel :

• Apple M4 Pro : 273 Go/s de bande passante mémoire unifiée
• NVIDIA RTX 4090 : 1 008 Go/s, 24 Go GDDR6X, 450 W TBP
• NVIDIA RTX 6000 Ada : 960 Go/s, 48 Go ECC VRAM, 300 W TBP

Ces configurations ne sont pas comparables pour des workloads de serving. Apple Silicon gère bien l'inférence mono-utilisateur avec des modèles de taille modérée. Pour du serving en équipe, des contextes longs ou plusieurs sessions parallèles, un x86 avec GPU dédié offre une scalabilité que le Mac mini ne permet pas — pas de slots PCIe, pas de chemin vers plus de VRAM, aucune option de mise à niveau modulaire.

Une note pratique sur AMD : vLLM supporte ROCm, mais la matrice de compatibilité officielle est restreinte et la charge opérationnelle est réelle. Vérifiez le support ROCm pour votre GPU spécifique avant d'acheter. Les toolchains CUDA-first (vLLM, MLPerf) sont le choix par défaut en production pour de bonnes raisons.

Automatisation navigateur : les frictions du mode headless sont réelles

Faire tourner OpenClaw en headless sur un serveur convient parfaitement pour le gateway lui-même. C'est l'automatisation web qui crée des frictions en mode headless.

OpenClaw supporte trois modes de contrôle du navigateur :

• Node host proxy — un processus node tourne sur la machine du navigateur ; le gateway route les actions navigateur à travers lui
• Remote CDP — configurez browser.profiles.<name>.cdpUrl pour pointer OpenClaw vers un Chromium distant via le Chrome DevTools Protocol
• Playwright headless local — fonctionne pour la plupart des automatisations côté serveur mais déclenche la détection de bots sur certains sites

La documentation d'OpenClaw le signale directement : pour des sites comme X/Twitter, une session navigateur classique sur l'hôte du gateway est plus fiable qu'une session sandboxée ou headless. Le contrôle navigateur distant équivaut en pratique à un accès opérateur — traitez-le comme tel dans votre modèle de sécurité. Limitez les ports du gateway et des nodes à votre tailnet uniquement.

Pour l'automatisation navigateur à grande échelle ou lorsque la gestion des CAPTCHA est importante, les services de navigateur hébergés (Browserless s'intègre avec OpenClaw) sont la réponse pragmatique. Vous ne payez pas pour la capacité d'automatisation — vous payez pour ne pas gérer l'infrastructure.

Paliers hardware

Entrée de gamme (personnel/hobbyiste)

Le Mac mini M4 couvre bien ce palier côté Apple. Sous Linux, un mini-PC x86 avec 2.5GbE, 32 Go de RAM et un NVMe de 1 To gère le gateway plus les outils sans friction. Utilisateurs Windows : OpenClaw recommande WSL2 (Ubuntu) pour maintenir la cohérence des outils Linux — prévoyez de la RAM supplémentaire pour l'overhead de la VM.

Gardez l'inférence via API à ce palier. Le calcul économique de l'inférence locale n'est pas rentable tant que vous n'avez pas un workload qui justifie le matériel.

Freelance / solo-pro

Un workstation mono-GPU : 12–16 cores, 64–128 Go de RAM, 2× NVMe (OS/services et workspace/base de données séparés), GPU dans la gamme 16–24 Go de VRAM. La RTX 4090 (24 Go, ~1 008 Go/s) est le plafond prosumer, mais 450 W de TBP est une considération réelle pour une machine toujours allumée.

Le 10GbE devient pertinent dès que l'hôte d'inférence est sur une machine séparée et que vous transférez régulièrement des artefacts de modèles ou de volumineuses pièces jointes à travers le réseau.

Entreprise / équipe

Séparez les rôles : hôte gateway, serveur d'inférence, node navigateur. Une machine combinée n'est pas la bonne réponse à l'échelle d'une équipe.

L'argument sécuritaire compte ici indépendamment de la performance : le gateway est une frontière opérateur authentifiée. Les utilisateurs qui accèdent au gateway disposent d'un accès de niveau opérateur. Les portes d'approbation réduisent les erreurs mais n'imposent pas l'isolation par utilisateur. Plusieurs gateways sur des hôtes séparés est l'architecture correcte pour les déploiements multi-utilisateurs.

Serveur d'inférence : la RTX 6000 Ada (48 Go ECC, 960 Go/s, 300 W) est un choix de production plus maintenable que la RTX 4090. La mémoire ECC compte pour les workloads de longue durée. 300 W au mur ne nécessite pas de repenser l'alimentation et le refroidissement comme le font 450 W.

Pour la plateforme : Threadripper PRO (128 lignes PCIe 5.0) ou EPYC (12 canaux mémoire DDR5) selon que le multi-GPU ou la bande passante mémoire est la contrainte limitante.

La question du Mac mini

Le Mac mini M4 est un bon hôte gateway. Le matériel correspond à ce dont un gateway a besoin : faible consommation au repos, 10GbE disponible, jusqu'à 64 Go de mémoire unifiée, silencieux.

Le discours « Apple Silicon suffit pour tout » s'effondre au niveau du serving. 273 Go/s de bande passante mémoire unifiée contre 960 Go/s sur un GPU dédié est une différence structurelle, pas une note de bas de page dans un benchmark. Ajoutez qu'il n'y a pas de slots PCIe pour plus de VRAM, aucun chemin de mise à niveau interne, et que les stacks de serving en production sont CUDA-first — et le tableau est clair.

L'architecture pérenne : gardez le gateway peu coûteux et stable, déportez l'inférence vers un hôte séparé avec de la vraie VRAM. Cela maintient la fiabilité du gateway et rend la couche d'inférence remplaçable sans toucher à vos surfaces de messagerie.

Si vous déboguez une configuration hardware OpenClaw spécifique avec un assistant IA, collez l'URL de cet article dans la conversation. L'architecture et le raisonnement par paliers présentés ici donnent au modèle suffisamment de contexte pour répondre aux questions de suivi sur votre setup.

Où l'héberger

Si vous voulez OpenClaw sans avoir à gérer la question du matériel, xCloud l'héberge en mode managé. Vous obtenez le gateway sans un week-end de décisions d'infrastructure — utile pendant que vous évaluez si l'inférence locale vaut l'investissement pour votre workload réel.

Côté VPS — de l'hôte gateway au serveur d'inférence — Hetzner couvre la gamme de 4,85 €/mois sur un CX22 jusqu'aux serveurs GPU dédiés quand l'inférence locale devient sérieuse. 10 € de crédit de départ.

(Liens affiliés — nous recevons une petite commission si vous vous inscrivez, sans coût supplémentaire pour vous.)

Ressources

• Documentation OpenClaw — architecture du gateway, Node host proxying, configuration remote CDP
• Documentation vLLM — chemins de support GPU CUDA et ROCm et matrices de compatibilité
• OpenClaw sur un VPS : déploiement sécurisé avec Docker et Tailscale — patterns de déploiement du gateway
• Hébergement OpenClaw managé vs. VPS DIY — comparaison des coûts et compromis