AgentesCódigo Abierto 🇺🇸 28.07.2026 00:01

Kimi y el equipo de kvcache-ai publican AgentENV en código abierto — una plataforma distribuida para entrenar RL de agentes a escala Kimi K3

Moonshot AIMoonshot AI
El equipo de Moonshot AI y kvcache-ai han lanzado AgentENV (AENV) bajo la licencia MIT — un sistema distribuido para ejecutar entornos de agente utilizando micro-MV de Firecracker. Permite la creación rápida de sandbox, pausa, reanudación y bifurcación, acelerando el entrenamiento RL de agentes para el modelo Kimi K3 (2,8 billones de parámetros, MoE). El proyecto es compatible con E2B, simplificando la migración de agentes existentes.
El equipo de Moonshot AI (creador del modelo Kimi K3), junto con kvcache-ai, ha publicado en código abierto (licencia MIT) la plataforma AgentENV: un sistema distribuido para la ejecución a gran escala de entornos de agentes, utilizado para el entrenamiento por aprendizaje por refuerzo (RL) de su modelo de mezcla de expertos (MoE) con 2,8 billones de parámetros, Kimi K3. Cada entorno aislado (sandbox) es una micro-MV Firecracker con su propio kernel de Linux, sistema de archivos y espacio de nombres de red, lo que proporciona aislamiento a nivel de kernel. La gestión del ciclo de vida de los entornos aislados se realiza mediante una API HTTP Axum que enruta las solicitudes a un orquestador. El sistema de archivos raíz (rootfs) se ejecuta a través de ublk en espacio de usuario, utilizando overlaybd para imágenes por capas: las capas base son de solo lectura y compartidas entre los entornos aislados, mientras que cada entorno tiene su propia capa superior de escritura. Dentro de la MV invitada, el demonio envd (puerto 49983) maneja comandos, operaciones de archivos e informes de estado; un proxy inverso enruta el tráfico HTTP y WebSocket desde los clientes a los servicios de la MV. Se presta especial atención a la reducción de sobrecarga: la caché de páginas del host se comparte entre los datos de almacenamiento y las instantáneas de memoria, y un mecanismo de inflado de memoria (memory ballooning) permite recuperar el exceso de memoria del invitado para el host, lo que admite sobreasignación a medida que los entornos divergen. Las características clave incluyen instantáneas (snapshots), pausa, reanudación y bifurcación (fork). Las instantáneas son incrementales, no completas. Según los datos reportados, cargar o reanudar desde una instantánea toma menos de 50 ms, pausar menos de 100 ms, y las instantáneas incrementales, incluso bajo una carga pesada de escritura, se completan en menos de 100 ms. La característica de bifurcación, específica para RL, permite clonar un entorno aislado en ejecución en hasta 16 entornos aislados hijos independientes en el mismo nodo. El entorno padre se pausa brevemente durante la captura y luego se reanuda. Todas las instancias hijas heredan el sistema de archivos, la memoria y la configuración de recursos del padre. Esto permite que la configuración costosa (instalación de dependencias, clonación de repositorios) se realice una vez, y luego el estado se bifurca en ejecuciones paralelas. Las instantáneas se guardan en almacenamiento de objetos compatible con S3 o en un sistema de archivos distribuido. De forma predeterminada, cada entorno aislado tiene un TTL; al expirar, no se elimina sino que se pausa; para eliminarlo, debe pasar autoPause: false en la creación. Las imágenes se cargan bajo demanda a través de overlaybd con una caché de disco local que almacena datos calientes y expulsa datos fríos. Esto evita precalentar cada imagen en todos los nodos y puede exceder la capacidad del disco local. El estado se organiza en tres capas: un espacio de trabajo del recolector para artefactos, un repositorio de instantáneas (almacenamiento persistente) y una caché de ejecución local para configuraciones derivadas. Se admiten dos backends de repositorio: posix_fs (predeterminado) y oss (a través de un cliente común compatible con S3, se debe especificar explícitamente la región). Un transporte P2P opcional basado en iroh puede anunciar artefactos a nodos vecinos, pero está deshabilitado por defecto. Para almacenamiento compartido, se recomienda un ancho de banda mínimo de 1 Gbit/s, y se recomienda encarecidamente 10 Gbit/s o más. Para una transición fácil, AgentENV proporciona una API HTTP compatible con E2B: solo configure E2B_API_URL en su propio servidor, y los SDK oficiales de Python/TypeScript de E2B funcionarán sin cambios de código en los agentes. También está disponible una CLI nativa, aenv. El despliegue requiere Linux 6.8+ y /dev/kvm; el script de instalación está orientado a Ubuntu 24.04. La CLI es compatible con Linux y macOS en x86_64 y arm64, mientras que el servidor requiere Linux (necesita KVM). Se documentan cinco métodos de despliegue: un script de instalación con systemd, una imagen Docker, Docker Compose para simulación de clúster, manifiestos de Kubernetes con gateway, scheduler y DaemonSet, y compilación desde código fuente en Rust. En despliegues multinodo, se añaden un gateway en el puerto 8080 y un scheduler en el puerto 9090.
Fuente: MarkTechPost — original
Nuestros artículos anteriores sobre este tema ↓
Noticias frescas