Qué corre en cada una de mis máquinas

Con catorce máquinas y un puñado de herramientas, llega un momento en que ya no sabes qué está corriendo dónde. Este es el mapa de mis arneses y mis modelos: en qué máquina vive cada uno, por qué ahí, cómo se hablan entre ellas y qué riesgos acepto al tener algunas piezas expuestas a internet.

Un martes por la mañana me llegó un aviso de que un servicio respondía lento. Me pasé veinte minutos entrando en tres servidores distintos buscando dónde estaba corriendo, hasta que me acordé de que lo había movido a otra máquina dos semanas antes y no lo había apuntado en ningún sitio. Veinte minutos buscando mis propias cosas en mi propia casa. Como las llaves, pero con servidores.

Con ocho servidores internos, seis VPS y varias herramientas de inteligencia artificial repartidas entre ellos, sin un mapa uno acaba perdido. Y lo peor no es perder tiempo: es no saber qué tiene acceso a qué.

En Por qué tengo ocho servidores en casa y seis fuera expliqué el criterio que uso para decidir si algo va dentro o fuera: los datos que maneja, el coste, la disponibilidad que necesita y cuánto tiene que estar expuesto a internet. Aquí lo aplico pieza a pieza.

Tres palabras que se mezclan mucho.

El modelo es el cerebro: el que lee lo que le escribes y produce la respuesta. Por sí solo, solo genera texto. El arnés es el programa que rodea al modelo y le da herramientas, memoria y límites: lo que le permite leer un archivo, ejecutar una orden o guardar lo que ha hecho. Y un agente es, dicho rápido, modelo más arnés.

Y una cuarta que no hay que mezclar con las otras: el runtime, el programa que carga y ejecuta un modelo local, como Ollama o llama.cpp. No da herramientas ni permisos al modelo; solo lo pone a funcionar y atiende peticiones.

Las piezas que van a salir, cada una en su montón:

• Modelos: los locales (Qwen, Gemma, DeepSeek destilado...) y los de la nube (Claude, DeepSeek, GLM, Kimi, MiniMax).
• Runtimes: Ollama, LM Studio y llama.cpp.
• Arneses de agentes: Claude Code, DeepSeek Harness y OpenClaw.
• Herramienta de afinado: Unsloth.
• Automatización: algunos servicios pequeños y tareas programadas que he montado yo para conectarlo todo.

La inteligencia artificial local, la que funciona en mis máquinas sin enviar nada fuera, vive entera en la red interna. Ahí está la tarjeta gráfica que trabaja para los demás servicios, la del servidor gráfico. La otra que tengo va en el portátil de trabajo, y ahí solo pruebo modelos.

En el servidor gráfico, el de la RTX 4070 de 12 gigas, con Ubuntu, corren Ollama y llama.cpp. Ollama es el que atiende las peticiones del día a día de los demás servicios; llama.cpp lo uso cuando quiero afinar cómo se carga un modelo concreto o probar formatos nuevos.

En el portátil de trabajo, con Windows y una RTX 5070 de 8 gigas, está LM Studio. Es mi banco de pruebas: cuando sale un modelo que me interesa, lo descargo ahí, lo pruebo con su interfaz y decido si merece pasar al servidor gráfico. En el servidor está también Unsloth, que uso para ajustar modelos pequeños con mis propios datos, casi siempre de noche porque deja la gráfica ocupada durante horas.

¿Por qué ahí? Por tres razones. La gráfica: los modelos locales necesitan una, y los VPS no la tienen. Los datos: lo que proceso con modelos locales es precisamente lo que no quiero sacar de casa. Y el coste: no pago por cada uso, solo la luz y la máquina.

Cómo reparto el trabajo entre los cuatro programas lo cuento con más detalle en Ollama, LM Studio, llama.cpp y Unsloth, cuál uso para cada cosa.

De los más de 50 modelos que he probado, siguen instalados unos doce: ocho en el servidor gráfico y cuatro en el portátil. El resto los fui borrando cuando vi que no los usaba. Los discos no son infinitos, aunque al principio lo parezcan.

Claude Code es el arnés con el que más trabajo. Lo tengo en mi estación de trabajo, que es desde donde hago casi todo, y en dos de los servidores internos, donde se encarga de tareas de mantenimiento y de revisar registros. En los VPS no está instalado de forma permanente: cuando necesito que haga algo en uno, trabaja desde dentro de la red y entra con un usuario con permisos limitados.

La razón de tenerlo sobre todo en la red interna es sencilla: es donde tengo el control, donde están mis archivos y donde puedo ver con calma lo que ha hecho antes de darlo por bueno. Si algo sale mal, sale mal en casa, detrás de la puerta.

DeepSeek Harness lo llevo probando diez días. Lo he puesto en un servidor interno apartado, el de pruebas, sin acceso al resto de máquinas salvo a una carpeta compartida. Mientras no lo conozca bien, prefiero que juegue en su habitación. Cómo están yendo esos días lo cuento en Diez días trabajando con DeepSeek Harness.

En cuanto al acceso, cada arnés tiene su propio usuario en cada máquina donde entra, con los permisos justos para lo que hace. Ninguno tiene la llave de todo. No doy más detalle por razones obvias.

OpenClaw es distinto de los otros porque se maneja desde aplicaciones de mensajería. Le escribes desde el móvil y hace cosas. Eso significa que tiene que estar accesible desde fuera, y ahí empiezan los problemas.

Lo tengo en uno de los VPS, dedicado solo a él, y no en la red interna. Si alguien consigue entrar en una máquina donde corre un arnés, entra con las manos del agente: todo lo que el agente puede hacer, lo puede hacer el intruso. Por eso no quiero que esa máquina tenga camino libre hacia casa.

Las medidas que aplico, sin entrar en detalles sensibles: solo responde a mi cuenta de mensajería, el VPS tiene lo mínimo instalado, el arnés corre con un usuario sin privilegios, no tiene acceso a la red interna salvo para pedir respuestas a un modelo concreto y reviso sus registros cada pocos días. La exposición no se elimina; se hace pequeña. Y asumo que, si un día algo falla, el daño se quedará en esa máquina. Por eso no guarda nada que no pueda perder ni tiene claves que abran otras puertas.

Llevo poco con él y lo cuento en He empezado a jugar con OpenClaw.

Los seis VPS hacen de cara visible y de organizadores. Dos sirven webs, uno aloja OpenClaw, dos llevan los servicios que atienden a clientes y reparten el trabajo entre modelos, y el último hace de puerta de entrada hacia la red interna.

En ninguno hay modelos grandes. No tienen tarjeta gráfica, y alquilar una fuera de casa no me compensa para lo que hago. Así que el VPS organiza: recibe la petición, decide a quién se la pasa y devuelve la respuesta. Y se la pasa a un modelo de la nube (Claude, OpenAI, DeepSeek, GLM, Kimi o MiniMax) o a uno de la red interna.

Los servicios de clientes tiran de Claude para lo que requiere más calidad y de DeepSeek o GLM para tareas sencillas y repetitivas, por coste. Cuando los datos son sensibles, la petición va a un modelo local de la red interna.

La pregunta clave: ¿cómo llega una petición de fuera a un modelo de dentro sin dejar la red interna abierta?

Con un túnel cifrado que sale desde casa hacia el VPS que hace de puerta. La conexión la abre la red interna, no al revés, así que en el router de casa no hay puertas abiertas hacia dentro. El VPS solo puede pedir cosas concretas a través de ese túnel, no pasearse por la red. Imagínalo como un portero que sale a recoger los paquetes a la calle en vez de dejar la puerta del edificio abierta.

Eso sí: no abrir puertos en casa reduce la superficie de ataque, pero no elimina el riesgo. Si alguien toma el VPS puerta, tiene el otro extremo del túnel. Por eso, sin dar detalles, los dos extremos se identifican con sus propias llaves, el túnel solo deja pasar hacia las pocas direcciones y servicios que hacen falta, las máquinas de casa no pueden salir a internet por él, cada conexión queda registrada, me llega un aviso si el túnel se cae o si aparece tráfico que no toca, y tengo preparado cómo anular las llaves y generar otras si sospecho algo.

¿Y cuando se cae algo? En julio se fue la luz en casa unas tres horas. Los VPS siguieron funcionando, pero todo lo que dependía de modelos locales se quedó sin respuesta. Los servicios que tenían alternativa en la nube tiraron de ella; los que no, devolvieron errores hasta que volvió la corriente.

El punto débil que sé que tengo: el VPS puerta es uno solo. Si se cae, la red interna queda aislada del exterior. Lo tengo apuntado para resolver y todavía no lo he hecho.

El esquema, en una frase: ocho máquinas en casa, con los modelos en el servidor gráfico; seis VPS fuera, con OpenClaw aislado en el suyo; y un único túnel cifrado que sale de casa hacia el VPS puerta.

Lo mismo, en versión de lista:

• Casa, servidor gráfico (RTX 4070, 12 GB): Ollama, llama.cpp y Unsloth; los modelos del día a día.
• Portátil de trabajo (RTX 5070, 8 GB): LM Studio, para probar modelos.
• Casa, estación de trabajo: Claude Code.
• Casa, servidor de pruebas: DeepSeek Harness, aislado.
• Casa, resto: copias, servicios siempre encendidos, agentes, el cliente del túnel y un servidor para un cliente.
• Fuera, seis VPS: dos webs, OpenClaw aislado, dos de servicios de clientes y el VPS puerta.
• Entre ambos: un único túnel cifrado que sale de casa hacia el VPS puerta.

Desde aquel martes, el mapa no es solo dónde corre cada cosa. Para cada servicio apunto qué datos toca (públicos, míos o de clientes), de quién es, dónde está su copia y cuándo la probé, cuándo cambié sus claves por última vez y cuándo lo actualicé. Las claves las cambio al menos una vez al año, y enseguida si alguien deja de necesitarlas o sospecho algo.

Si montara todo hoy, cambiaría un par de cosas. Pondría dos VPS puerta en lugar de uno, para no depender de una sola máquina. Apuntaría desde el primer día qué corre en cada sitio, en un documento que se actualice solo. Y separaría antes la máquina de pruebas del resto, que durante meses convivió con servicios que sí importaban.

Lo que queda por responder es la pregunta de fondo, y la contesto en ¿Compensa tener servidores propios?.