Capacitar a agentes de IA que realmente puedan usar una computadora (abrir aplicaciones, hacer clic en botones, navegar por la web, escribir código) es uno de los problemas de infraestructura más difíciles en la IA moderna. No es un problema de datos. No es un problema de modelo. Es un problema de plomería.
Necesita poner en marcha cientos, potencialmente miles, de entornos de sistemas operativos completos con interfaces gráficas de usuario reales. Cada uno necesita ejecutar software real. Cada uno necesita manejar fallas impredecibles. Y es necesario que todos funcionen simultáneamente a un costo que no lleve a la quiebra a un laboratorio de investigación universitario.
Ese es el problema que ‘OSGym’, una nueva investigación de un equipo de investigadores del MIT, UIUC, CMU, USC, UVA y UC Berkeley, está diseñada para resolver.
¿Qué es un agente de uso informático?
Antes de analizar la infraestructura, es útil comprender qué es realmente un agente de uso de computadora. A diferencia de un chatbot que responde a indicaciones de texto, un agente de uso de computadora observa una captura de pantalla de un escritorio, decide qué hacer (hacer clic en un botón, escribir texto, abrir un archivo) y ejecuta esa acción a través del teclado y el mouse. Piense en ello como una IA que puede operar cualquier software como lo haría un humano.
Modelos como Claude Computer Use de Anthropic y Operador de OpenAI son los primeros ejemplos comerciales. Los modelos de investigación como UI-TARS, Agent-S2 y CogAgent están ampliando aún más los límites. Pero entrenar cualquiera de estos sistemas requiere enormes cantidades de datos de interacción generados dentro de entornos operativos reales, y ahí es donde las cosas se vuelven costosas y complicadas rápidamente.
El problema central: entornos aislados de sistemas operativos a escala
Un entorno de codificación o un entorno limitado de navegador web son relativamente livianos de ejecutar. Un entorno limitado de sistema operativo completo con una GUI no lo es. Cada máquina virtual necesita su propio disco de arranque (alrededor de 24 GB), su propia asignación de CPU y RAM, y su propia pila de visualización. Multiplique eso por cientos o miles de instancias paralelas y tendrá un problema de consumo de recursos que los presupuestos informáticos académicos típicos simplemente no pueden absorber.
Además de los costos de recursos, está el problema de la confiabilidad. El software falla. Se agota el tiempo de espera de las sesiones del navegador. Las aplicaciones se congelan. Si su proceso de capacitación no maneja estas fallas correctamente, una máquina virtual defectuosa puede detener un lote de capacitación completo.
OSGym aborda ambos problemas con cuatro optimizaciones arquitectónicas distintas.
Gestión descentralizada del estado del sistema operativo
La primera opción de diseño se refiere a cómo el sistema gestiona el estado de cada réplica del sistema operativo: rastreando si está en buen estado, qué tarea está ejecutando y cómo recuperarla si algo sale mal.
Un enfoque ingenuo utiliza un único administrador centralizado para todas las réplicas. Este es un clásico punto único de falla: a medida que el número de réplicas aumenta a miles, el administrador central se siente abrumado, la latencia aumenta y una falla puede detener todo el sistema. En cambio, OSGym le da a cada réplica del sistema operativo su propio administrador de estado dedicado. Cada administrador estatal expone métodos públicos modelados a partir de la API OpenAI Gym (reinicio, paso y apagado), pero maneja su propio monitoreo de salud y recuperación de fallas internamente. Un error en una réplica no se puede propagar a ninguna otra.
Orquestación de réplicas de SO basadas en hardware
Aquí hay una idea no obvia que surge de esta investigación: cuando ejecuta muchas réplicas del sistema operativo en un solo servidor, el cuello de botella depende de cuántas réplicas empaqueta por máquina. Para una pequeña cantidad de réplicas por servidor (K baja), el sistema está limitado por la CPU; la mayoría de las réplicas luchan por el tiempo del procesador. Pero a medida que se empaquetan más réplicas por servidor (K grandes), el cuello de botella se traslada a la RAM, y la RAM es dramáticamente más barata que la CPU.
Un módulo de RAM DDR4 de 32 GB suele costar entre el 10 y el 20 % de lo que cuesta una CPU de 16 núcleos. OSGym ejecuta réplicas como contenedores Docker (utilizando imágenes Docker de OSWorld como base) en lugar de máquinas virtuales completas para reducir la sobrecarga por réplica. Al elegir servidores con mayor capacidad de RAM y ejecutar más réplicas por máquina, el costo diario cae de alrededor de $300 por 128 réplicas en K=1, a aproximadamente $30 en K=64, aproximadamente $0,234 por réplica por día, un número que se ajusta cómodamente a muchos presupuestos de becas académicas.
Virtualización KVM con administración de discos de copia en escritura
El problema de aprovisionamiento de disco se resuelve con una técnica de sistema de archivos llamada copia en escritura reflink (CoW). Normalmente, poner en marcha 128 instancias de VM significaría duplicar una imagen base de 24 GB 128 veces: más de 3 TB de almacenamiento y 30 segundos de tiempo de aprovisionamiento por VM.
OSGym en su lugar usa cp –reflink=always en unidades NVMe formateadas con XFS. Cada imagen de disco por VM comparte bloques de disco físicos con la imagen base y solo asigna nuevos bloques cuando la VM realmente escribe en ellos. El resultado: 128 máquinas virtuales consumen 366 GB de disco físico en lugar de 3,1 TB (una reducción del 88%) y el tiempo de aprovisionamiento del disco cae de 30 segundos a 0,8 segundos por máquina virtual, una aceleración de 37 veces. Cada VM todavía ve su disco lógico completo de 24 GB con un rendimiento de CPU casi nativo.
Conjunto de contenedores robusto con recuperación de fallas multicapa
OSGym mantiene un grupo de corredores precalentado (de forma predeterminada, 128 corredores por nodo ejecutor) inicializado antes de que comience el entrenamiento. En lugar de crear y destruir máquinas virtuales según demanda, los ejecutores se reciclan entre tareas. Antes de la creación de cada VM, OSGym lee /proc/meminfo y /proc/loadavg para verificar que el host pueda acomodar de forma segura otra instancia, bloqueando la creación si la memoria disponible cae por debajo del 10% o por debajo de los 8 GB absolutos. Cada contenedor tiene una memoria limitada a 6 GB para evitar el aprovisionamiento excesivo en escenarios de ráfaga.
El sistema también ajusta los parámetros del kernel de Linux que de otro modo causarían fallas silenciosas en alta concurrencia; por ejemplo, fs.aio-max-nr aumenta de 65,536 a 1,048,576, y fs.inotify.max_user_instances de 128 a 8,192. La recuperación de fallas opera en dos niveles: en el nivel de paso, cada acción tiene hasta 10 reintentos de forma predeterminada; A nivel de tarea, si un corredor falla permanentemente, la tarea se reasigna automáticamente a un nuevo corredor.
Flujo de tareas unificado y servidor de datos centralizado
Dos elementos de diseño que son particularmente importantes para los desarrolladores que integran OSGym: cada tarea sigue un flujo de ejecución unificado de cuatro fases (Configurar, Restablecer, Operar, Evaluar) independientemente del software o dominio involucrado. Esta estandarización hace que sea sencillo agregar nuevos tipos de tareas sin cambiar la infraestructura circundante.
Por encima de la capa de réplica, una clase Python de servidor de datos centralizado expone una interfaz por lotes de entrada única (__next__ y async_step) que oculta toda la complejidad de la comunicación y las colas del administrador de estado. El método de pasos por lotes es asíncrono, lo que significa que el ciclo de entrenamiento nunca se bloquea mientras se espera que las réplicas del sistema operativo completen sus acciones.
Cómo se ven los números en la práctica
Utilizando 1.024 réplicas de sistemas operativos paralelos, el sistema recopiló trayectorias en diez categorías de tareas, incluidas LibreOffice Writer, Calc e Impress, Chrome, ThunderBird, VLC, VS Code, GIMP, configuración del sistema operativo y flujos de trabajo de múltiples aplicaciones, a aproximadamente 1.420 trayectorias por minuto, frente a 115.654 segundos sin paralelización. Todo el conjunto de datos costó 43 dólares en computación en la nube.
Luego, el equipo de investigación utilizó esos datos para ajustar Qwen2.5-VL 32B mediante un ajuste fino supervisado, seguido de un aprendizaje por refuerzo utilizando una canalización asincrónica semi-en línea basada en PPO (200 pasos, tamaño de lote 64, tasa de aprendizaje 1e-6). El modelo resultante logró una tasa de éxito del 56,3% en el punto de referencia OSWorld-Verified, competitivo con los métodos existentes para un modelo base de parámetros de 32B sin ajuste específico de la tarea.
Conclusiones clave
Capacitar a los agentes para el uso de computadoras es, en primer lugar, un problema de infraestructura: los entornos limitados de SO completos con GUI son mucho más pesados que los entornos de codificación o de navegador: cada VM necesita ~24 GB de disco, CPU y RAM dedicadas, y una pila de pantalla. Sin una optimización cuidadosa, escalar a cientos de réplicas es simplemente inasequible para la mayoría de los laboratorios académicos. La RAM es una palanca de escalamiento más inteligente que la CPU: la orquestación consciente del hardware de OSGym revela que empaquetar más réplicas por servidor desplaza el cuello de botella de la CPU a la RAM, y la RAM es entre 5 y 10 veces más barata. Esta información única reduce el costo por réplica de ~$2,10/día a tan solo $0,23/día. La gestión de discos de copia en escritura elimina el muro de almacenamiento. Al utilizar XFS reflink CoW (cp –reflink=always), OSGym reduce el consumo de disco físico en un 88 % y acelera el aprovisionamiento de disco de VM en 37 veces, convirtiendo un problema de 3,1 TB y 30 segundos por VM en uno de 366 GB y 0,8 segundos. La gestión estatal descentralizada es la clave para la solidez a escala. Darle a cada réplica del sistema operativo su propio administrador de estado dedicado significa que las fallas permanecen aisladas. Incluso partiendo de un estado completamente bloqueado, OSGym recupera automáticamente todas las réplicas en un período corto, lo cual es fundamental para trabajos de entrenamiento ininterrumpidos de larga duración. La investigación sobre agentes de uso de computadoras a escala académica ahora es financieramente viable. Con 1.024 réplicas que generan 1.420 trayectorias por minuto y un conjunto de datos completo que cuesta solo 43 dólares en computación en la nube, OSGym pone el costo de infraestructura de capacitar agentes informáticos de uso general al alcance de los presupuestos de investigación de las universidades.
Consulte el documento aquí. Además, no dude en seguirnos en Twitter y no olvide unirse a nuestro SubReddit de más de 120.000 ML y suscribirse a nuestro boletín. ¡Esperar! estas en telegrama? Ahora también puedes unirte a nosotros en Telegram.
¿Necesita asociarse con nosotros para promocionar su repositorio de GitHub O su página principal de Hugging O su lanzamiento de producto O seminario web, etc.? Conéctate con nosotros