Guía de hardware de OpenClaw: la puerta de enlace, el cómputo y el navegador son tres problemas separados

La mayoría de las discusiones sobre hardware para OpenClaw plantean la pregunta como "Mac mini vs workstation x86" y luego dedican 2.000 palabras a debatir sobre el ancho de banda de la memoria unificada. Ese es el eje equivocado.

La arquitectura de OpenClaw hace que la verdadera pregunta sea obvia: ¿qué estás ejecutando realmente? El proceso de gateway, la inferencia local y la automatización del navegador tienen perfiles de hardware completamente diferentes. Acertar con uno no significa acertar automáticamente con los demás.

Los tres roles de hardware

OpenClaw es gateway-first. Un único proceso Gateway gestiona tus superficies de mensajería — WhatsApp, Telegram, Slack — y ejecuta un control plane WebSocket al que se conecta todo lo demás (por defecto: 127.0.0.1:18789). Clients, automations y nodes se conectan ahí.

De ese diseño emergen tres roles de hardware:

• Gateway host — siempre encendido, gestiona las conexiones de canales y los datos del workspace, ejecuta herramientas
• Compute host — inferencia local, GPU, KV-cache, sesiones de modelos en paralelo
• Browser host — Playwright o CDP, gestiona tareas de automatización web

La propia documentación de OpenClaw trata "un gateway por host" como un principio de diseño: el gateway es el único proceso que debería gestionar una sesión de WhatsApp Web. Para aislamiento multiusuario, lo que necesitas son múltiples gateways en hosts separados — no un solo gateway compartido escalado verticalmente. Esto afecta las decisiones de compra más que cualquier benchmark.

Gateway: la estabilidad importa más que el rendimiento

El gateway en sí no requiere mucho cómputo. Lo que determina sus requisitos de hardware:

• Rendimiento single-thread para el event loop e I/O
• Suficientes cores para la ejecución de herramientas en paralelo — Playwright, ffmpeg, tareas CLI, containers
• Almacenamiento fiable para workspaces, adjuntos y logs que se acumulan continuamente

Sin inferencia local, 32 GB de RAM cubren cómodamente un gateway ejecutando Playwright y herramientas. Un Mac mini M4 (o M4 Pro) es un excelente gateway host — 10GbE opcional, hasta 64 GB de memoria unificada, 155 W de consumo máximo continuo. Un mini-PC x86 con 2.5GbE y un NVMe de calidad cubre el mismo terreno en Linux o WSL2.

El almacenamiento merece atención aquí. Workspaces, adjuntos, logs y artefactos de modelos crecen constantemente. El Samsung 990 Pro de 2 TB viene con 1.200 TBW y cifrado de disco completo AES-256 — esa cifra de resistencia importa más que la velocidad máxima de lectura secuencial para un gateway que funciona continuamente.

Inferencia local: la VRAM es la restricción

Añadir inferencia local cambia la ecuación por completo. El cuello de botella rara vez es el cómputo (FLOPS). Es la memoria: los pesos del modelo cargados en el formato de precisión adecuado, más una KV cache que crece linealmente con el batch size y la longitud de la secuencia.

Un ejemplo concreto: Llama 2 7B en FP16, contexto de 4K, batch size 1 necesita aproximadamente 2 GB solo para la KV cache. Escala el contexto o el paralelismo y agotarás la memoria disponible rápidamente. Más VRAM es la palanca más directa para contextos más largos y más sesiones concurrentes.

Aquí es donde el argumento de "la memoria unificada reemplaza la VRAM" choca con un muro estructural:

• Apple M4 Pro: 273 GB/s de ancho de banda de memoria unificada
• NVIDIA RTX 4090: 1.008 GB/s, 24 GB GDDR6X, 450 W TBP
• NVIDIA RTX 6000 Ada: 960 GB/s, 48 GB ECC VRAM, 300 W TBP

No son comparables para cargas de trabajo de serving. Apple Silicon maneja bien la inferencia para un solo usuario con modelos moderados. Para serving en equipo, contextos largos o múltiples sesiones en paralelo, x86 con una GPU discreta escala de maneras que el Mac mini no puede — no tiene slots PCIe, no hay camino hacia más VRAM, no hay opción de upgrade modular.

Una nota práctica sobre AMD: vLLM soporta ROCm, pero la matriz de compatibilidad oficial es limitada y la carga operativa es real. Verifica el soporte de ROCm para tu GPU específica antes de comprar. Los toolchains CUDA-first (vLLM, MLPerf) son el estándar en producción por una razón.

Automatización del navegador: la fricción de headless es real

Ejecutar OpenClaw en modo headless en un servidor está bien para el gateway en sí. La automatización web es donde las configuraciones headless generan fricción.

OpenClaw soporta tres patrones para el control del navegador:

• Node host proxy — un proceso node se ejecuta en la máquina del navegador; el gateway enruta las acciones del navegador a través de él
• Remote CDP — configura browser.profiles.<name>.cdpUrl para apuntar OpenClaw a un Chromium remoto mediante Chrome DevTools Protocol
• Local Playwright headless — funciona para la mayoría de la automatización server-side pero activa la detección de bots en algunos sitios

La documentación de OpenClaw lo señala directamente: para sitios como X/Twitter, una sesión de navegador normal en el host del gateway es más fiable que una sandboxed o headless. El control remoto del navegador es efectivamente acceso de operador — trátalo así en tu modelo de seguridad. Mantén los puertos del gateway y del node solo en tu tailnet.

Para automatización del navegador a escala o donde el manejo de CAPTCHAs importa, los servicios de navegador alojados (Browserless se integra con OpenClaw) son la respuesta práctica. No estás pagando por la capacidad de automatización — estás pagando para no gestionar la infraestructura.

Niveles de hardware

Entrada (personal/hobbyist)

El Mac mini M4 cubre bien este nivel en el lado Apple. En Linux, un mini-PC x86 con 2.5GbE, 32 GB de RAM y un NVMe de 1 TB gestiona el gateway más herramientas sin problemas. Usuarios de Windows: OpenClaw recomienda WSL2 (Ubuntu) para mantener consistente el tooling de Linux — presupuesta RAM extra para el overhead de la VM.

Mantén la inferencia vía API en este nivel. Las cuentas de la inferencia local no cuadran hasta que tengas una carga de trabajo que justifique el hardware.

Freelancer / solo-pro

Una workstation con una sola GPU: 12–16 cores, 64–128 GB de RAM, 2× NVMe (SO/servicios y workspace/base de datos separados), GPU en el rango de 16–24 GB de VRAM. La RTX 4090 (24 GB, ~1.008 GB/s) es el techo prosumer, pero 450 W de TBP es una consideración real para una máquina siempre encendida.

10GbE empieza a valer la pena una vez que el host de inferencia está en una máquina separada y estás moviendo artefactos de modelos o adjuntos grandes por la red regularmente.

Empresa / equipo

Separa los roles: gateway host, servidor de inferencia, browser node. Una máquina combinada no es la respuesta a escala de equipo.

El argumento de seguridad importa aquí independientemente del rendimiento: el gateway es un límite de operador autenticado. Los usuarios que acceden al gateway tienen acceso a nivel de operador. Los approval gates reducen errores pero no aplican aislamiento por usuario. Múltiples gateways en hosts separados es la arquitectura correcta para despliegues multiusuario.

Servidor de inferencia: la RTX 6000 Ada (48 GB ECC, 960 GB/s, 300 W) es una elección de producción más sostenible que la RTX 4090. La memoria ECC importa para cargas de trabajo de larga duración. 300 W en la pared no requiere repensar PSU y refrigeración como sí lo hacen 450 W.

Para plataforma: Threadripper PRO (128 lanes PCIe 5.0) o EPYC (12 canales de memoria DDR5) dependiendo de si multi-GPU o el ancho de banda de memoria es la restricción determinante.

La cuestión del Mac mini

El Mac mini M4 es un buen gateway host. El hardware encaja con lo que un gateway necesita: bajo consumo en idle, 10GbE disponible, hasta 64 GB de memoria unificada, silencioso.

La narrativa de "Apple Silicon es suficiente para todo" se desmorona en el serving. 273 GB/s de ancho de banda de memoria unificada frente a 960 GB/s en una GPU dedicada es una diferencia estructural, no una nota al pie de un benchmark. Suma que no hay slots PCIe para más VRAM, no hay ruta de upgrade interna, y que los stacks de serving en producción son CUDA-first — y el panorama queda claro.

La arquitectura duradera: mantén el gateway barato y estable, lleva la inferencia a un host separado con VRAM real. Eso mantiene el gateway fiable y hace que la capa de inferencia sea reemplazable sin tocar tus superficies de mensajería.

Si estás depurando una configuración de hardware específica de OpenClaw con un asistente de IA, pega la URL de este post en la conversación. La arquitectura y el razonamiento por niveles aquí le dan al modelo suficiente contexto para responder preguntas de seguimiento sobre tu setup.

Dónde ejecutar esto

Si quieres OpenClaw sin gestionar la cuestión del hardware, xCloud lo aloja de forma managed. Obtienes el gateway sin un fin de semana de decisiones de infraestructura — útil mientras evalúas si la inferencia local vale la inversión para tu carga de trabajo real.

Para el lado VPS — cualquier cosa desde el gateway host hasta el servidor de inferencia — Hetzner cubre el rango desde 4,85 €/mes en un CX22 hasta servidores GPU dedicados cuando la inferencia local se pone seria. 10 € de crédito inicial.

(Enlaces de afiliado — recibimos una pequeña comisión si te registras, sin coste para ti.)

Recursos

• Documentación de OpenClaw — arquitectura del gateway, Node host proxying, configuración de remote CDP
• Documentación de vLLM — rutas de soporte de GPU para CUDA y ROCm y matrices de compatibilidad
• OpenClaw en un VPS: deploy seguro con Docker y Tailscale — patrones de despliegue del gateway
• Managed OpenClaw hosting vs. DIY VPS — comparación de costes y trade-offs