Cómo ejecutar un agente de AI en una máquina virtual y mantener el modelo en la GPU del host: una configuración con Strata

Un agente que instala paquetes, ejecuta scripts y modifica archivos por su cuenta ahorra horas. Pero, en la práctica, le estás dando a un becario permisos de administrador en tu portátil. Basta una alucinación en un script de limpieza o un postinstall en un repositorio desconocido para que las consecuencias lleguen al sistema principal.

La salida obvia es una máquina virtual. El problema es que normalmente no se le puede asignar la GPU, y un modelo local sin tarjeta gráfica funciona con una lentitud desesperante. Un análisis publicado en Habr propone separar el «cerebro» de las «manos».

Cómo funciona la configuración

Hay tres componentes.

El host se encarga de la inferencia. Ejecuta la aplicación de escritorio Strata, que expone una API compatible con OpenAI (el puerto predeterminado es 47831). El código ajeno no llega aquí ni se ejecuta.

La máquina virtual en modo NAT es el entorno aislado. Contiene VS Code y la extensión Cline; también es donde se descomprimen archivos, se instalan dependencias y se ejecutan scripts dudosos. Si algo sale mal, se restaura la máquina virtual desde una instantánea en unos cinco segundos.

La pasarela de red obliga a que todo el tráfico del hipervisor en el host pase por un proxy SOCKS mediante Proxifier. Si el código que se analiza incluye telemetría o una conexión inversa, al exterior solo se expondrá la IP del proxy, no la de la red doméstica.

Un ejemplo sencillo: quieres analizar rápidamente un repositorio desconocido de GitHub. Lo clonas en la máquina virtual y le pides al agente que compile el proyecto y ejecute las pruebas. El modelo piensa en la tarjeta gráfica del host, mientras que todo se ejecuta dentro del entorno aislado.

Dónde falla todo

Lo más interesante aquí no es la idea en sí, sino dos trampas de red.

La primera: los servidores locales de modelos (Strata, Ollama, LM Studio) solo escuchan en 127.0.0.1 de forma predeterminada. No son accesibles desde la máquina virtual, ni siquiera a través de la pasarela 10.0.2.2. El autor lo resuelve con portproxy, integrado en Windows. Un comando netsh interface portproxy redirige el puerto y una regla del cortafuegos lo abre. La comprobación es sencilla: ejecutar curl.exe 10.0.2.2:47831/v1/models desde la máquina virtual debe devolver un JSON con la lista de modelos. De esa respuesta se toma el valor exacto del campo id, que se necesitará en Cline.

La segunda trampa es menos evidente. Cuando la máquina virtual se conecta a 10.0.2.2, el proceso del sistema svchost.exe acaba procesando el paquete. Proxifier lo intercepta e intenta enviarlo a una dirección local a través del servidor SOCKS remoto. La conexión se queda bloqueada. Se soluciona con una regla de excepción: aplicaciones — Any (precisamente porque el tráfico pasa por svchost), hosts — 10.0.2.2, 127.0.0.1, localhost y las subredes locales, puerto — 47831, acción — Direct. La regla debe situarse por encima de la regla general del hipervisor. Como el puerto está fijado explícitamente, el resto del tráfico de la máquina virtual hacia internet sigue pasando exclusivamente por el proxy.

En Cline, la configuración es la siguiente: proveedor OpenAI Compatible, Base URL 10.0.2.2:47831/v1, clave — cualquier palabra no vacía, Model ID — el nombre que devuelve el servidor. Conviene desactivar el uso de modelos separados para los modos Plan y Act para no duplicar la configuración.

Qué tener en cuenta en la práctica

El aislamiento depende de la disciplina. Hay que desactivar las carpetas compartidas y el portapapeles bidireccional de la máquina virtual; de lo contrario, el entorno aislado pierde su sentido. No se debe iniciar sesión en cuentas personales ni guardar allí claves y tokens reales: Auto-approve en Cline permite al agente hacer todo lo que esté a su alcance dentro de la máquina.

También hay un punto débil que el artículo no aborda. El comando portproxy utiliza listenaddress=0.0.0.0, lo que significa que el puerto escucha en todas las interfaces del host, y la regla del cortafuegos del ejemplo no restringe el origen. Si estás conectado a una red Wi-Fi compartida, tiene sentido limitar la regla a la subred de la máquina virtual mediante el parámetro remoteip o vincular listenaddress a la dirección del adaptador virtual. Esta es nuestra conclusión, no una recomendación del autor. Además, una máquina virtual no ofrece garantías absolutas: escapar del hipervisor es poco frecuente, pero posible, y habrá que mantener actualizada la instantánea.

La conclusión para el desarrollador: necesitas un agente enjaulado, no uno «inteligente». La configuración se puede montar en una tarde con software gratuito y sirve para auditar código ajeno, analizar paquetes sospechosos y experimentar con el modo autónomo. Conviene exportar el perfil de Proxifier y crear una instantánea limpia justo después de comprobar la IP externa.