Dónde falla la configuración con openclaw
Analicé un caso con un PC gaming que ejecuta qwen en una RTX 5090 y un MacBook M5 Pro como plataforma de respaldo. El escenario es muy cotidiano: durante el día, mi modelo local vuela en la tarjeta gráfica potente; por la noche, apago Ollama en el escritorio y las solicitudes deberían redirigirse sin problemas al Mac. En teoría, parece un failover estándar. En la práctica, se traduce en heartbeats colgados, timeouts de la API del LLM y la sensación de que el router simplemente no se cree que el primer backend ha caído.
Y aquí está mi principal conclusión: el problema, muy probablemente, no está en Ollama, sino en la capa de proxy. Si un proxy espera demasiado por un socket, no sabe cortar los timeouts de forma agresiva o no mantiene un modelo de health-check adecuado, se quedará colgado en el nodo inactivo hasta 40 minutos. Para tareas cron y agentes en segundo plano, esto es especialmente molesto, porque el pipeline parece estar vivo, pero en realidad ya no lo está.
No construiría un sistema así en torno a openclaw/lm-proxy si el objetivo es una conmutación automática y fiable. La idea de 'try connection1, except connection2' es sensata, pero en un entorno de producción no es suficiente. Se necesitan timeouts cortos, reintentos, estado de los backends y un enrutamiento claro.
Qué usaría en su lugar
Para un entorno autoalojado como este, elegiría LiteLLM como un proxy unificado compatible con OpenAI frente a las dos instancias de Ollama. Un Ollama se ejecuta en la RTX 5090 y el otro en el MacBook M5 Pro. Los clientes, agentes, cron y todo lo demás se comunican con LiteLLM, no directamente con Ollama.
Por qué me gusta esto: cambio el endpoint de mis aplicaciones una sola vez y luego gestiono el enrutamiento desde un único lugar. Puedo definir el backend principal en el escritorio, el de respaldo en el Mac, y si quiero, un tercer nivel: un servicio en la nube como OpenRouter. Esto ya no es una integración de IA improvisada, sino una capa de transporte adecuada para modelos locales.
La idea básica de la configuración es la siguiente:
- principal (primary): Ollama en la RTX 5090
- respaldo (fallback): Ollama en el Mac M5
- timeout: 15-30 segundos, no más
- reintentos (retries): 1-2, de lo contrario solo alargas la latencia
- un alias de modelo común para el cliente, para que no le importe dónde se está ejecutando realmente
Si tu qwen3.5:35b-a3b no coincide en nombre o recursos con qwen3.5:27b en el Mac, yo no lo ocultaría por completo. Es mejor asignar un nombre lógico a la clase de tarea en lugar de fingir que los modelos son idénticos. De lo contrario, surgirán extrañas discrepancias en las respuestas y terminarás depurando el comportamiento del modelo en lugar de problemas de red.
Qué cambia esto para el negocio y la automatización
El beneficio más valioso aquí no es el ahorro en la nube, sino la previsibilidad. Cuando la automatización con IA depende de la inferencia local, no puedes permitir que un pipeline espere media hora a una GPU inactiva. El negocio no necesita heroísmo del hardware, necesita una ruta de solicitud que no se quede colgada.
Ganan los equipos que tienen varios nodos y una arquitectura de IA clara: una máquina potente para tareas pesadas, una más débil como respaldo y la nube como capa de emergencia. Pierden aquellos que codifican la lógica de conmutación en cada script por separado. Ya lo he visto: primero 'lo dejamos hardcodeado temporalmente', y seis meses después nadie recuerda por qué las tareas nocturnas solo fallan los viernes.
En Nahornyi AI Lab, a menudo construimos este tipo de soluciones de IA para empresas: modelos locales, proxies, colas, fallback, monitorización y publicación segura de servicios en la red interna. Y casi siempre, el problema no está en el modelo en sí. Lo que se rompe es el pegamento entre los componentes: timeouts, enrutamiento, health checks, estado de las colas.
Si se hace bien, la configuración PC + Mac es totalmente viable. Yo colocaría LiteLLM como capa intermedia, le daría a cada Ollama un timeout corto, añadiría un endpoint de salud simple y verificaría por separado cómo se comportan el streaming, cron y las generaciones largas. Una tarde de configuración convierte la magia en una arquitectura de soluciones de IA gestionable.
Soy Vadim Nahornyi de Nahornyi AI Lab y he compartido este análisis desde la experiencia práctica. No colecciono estas configuraciones autoalojadas en mis marcadores, sino que realmente las construyo, depuro e integro en flujos de trabajo reales.
Si quieres, puedo ayudarte a analizar tu stack particular: qué mantener en local, cómo implementar IA sin apaños frágiles y dónde es mejor colocar una ruta de respaldo. Escríbenos a Nahornyi AI Lab y estudiaremos tu caso en detalle.