Haga más con menos: Cómo GKE puede reducir su costo por agente en un 75%

En la era actual, las aplicaciones en la nube modernas están evolucionando de un conjunto de herramientas pasivas a una flota de trabajadores digitales autónomos que razonan, planifican y toman medidas en una amplia gama de tareas. Para los equipos de ingeniería de plataformas que diseñan estos entornos, el enfoque más sencillo es a menudo implementar un agente en un marco de código abierto como OpenClaw y Hermes que se ejecutan en una máquina virtual (VM). Pero a medida que esas cargas de trabajo se despliegan en producción y se escalan para admitir más usuarios o casos de uso, los equipos se enfrentan rápidamente a un desafío crítico: los agentes de IA tienden a operar en ráfagas; durante un tiempo, procesan activamente las solicitudes o ejecutan el código, seguido de largos períodos de inactividad mientras esperan la entrada del usuario o los desencadenantes externos. Si confías en las asignaciones de cómputo estáticas, los agentes inactivos siguen consumiendo valiosos CPU y memoria. La pregunta es: ¿cómo puedes empaquetar de forma segura más agentes en una huella de cómputo fija sin sacrificar la fiabilidad, la escalabilidad o la eficiencia? La respuesta es incorporar la orquestación de forma proactiva como parte integral de tu arquitectura. La orquestación te ayuda a desbloquear una mejora drástica en la economía de unidades y la escalabilidad, la facilidad de uso y la fiabilidad desde el principio. Google Kubernetes Engine (GKE) ofrece capacidades de orquestación sofisticadas. Para ayudarte a aprovechar al máximo tu capacidad de cómputo, probamos el número máximo de agentes de IA que se pueden empaquetar en un solo nodo de GKE que se ejecuta en una instancia de Google Compute Engine VM (n2-standard-48) — sin degradación del rendimiento o fallos repetidos. Utilizando un perfil de OpenClaw, aplicamos optimizaciones progresivas para demostrar el papel significativo que puede desempeñar la orquestación para ejecutar cargas de trabajo de agentes a escala — lee más para obtener más información. Caso de uso base: ejecutar OpenClaw en microVMs. Para ejecutar de forma segura cargas de trabajo de agentes no fiables, se requiere un aislamiento fuerte. Un enfoque común es ejecutar cada agente en una microVM dedicada (como los contenedores Kata) en un despliegue de Kubernetes, que proporciona un fuerte aislamiento a nivel de hardware. Si bien esto proporciona el límite de seguridad necesario, casi inmediatamente se enfrenta a una pared de escalado. Cada microVM requiere su propio sistema operativo invitado que consume recursos de CPU y memoria, lo que limita los recursos reales disponibles para tus agentes reales. En este escenario de base, nos enfrentamos a una pared de escalado en 61 agentes de OpenClaw en un nodo de GKE estándar antes de que la fiabilidad cayera y las comprobaciones de estado de la carga de trabajo empezaran a fallar regularmente. Optimización 1: Empaquetar la densidad con GKE Agent Sandbox. Para abordar esto, migramos la misma carga de trabajo de agente de microVM a GKE Agent Sandbox, un primitivo de Kubernetes que está diseñado específicamente para los requisitos de seguridad y rendimiento de ejecutar agentes. En lugar de depender de sistemas operativos invitados pesados, GKE Agent Sandbox utiliza el contenedor sandbox de código abierto seguro, gVisor. gVisor utiliza un kernel de espacio de usuario (el Sentry) para interceptar y filtrar las llamadas al sistema. Esto proporciona un aislamiento de producción seguro para la ejecución de código no fiable al tiempo que mantiene el tamaño ligero de los contenedores de Kubernetes estándar. Esto reduce la sobrecarga, lo que permite desplegar 88 agentes de OpenClaw dentro de la misma VM antes de que falle — un aumento del 44 % en el número de agentes que puedes ejecutar en la misma capacidad fija al tiempo que mantienes un perímetro de seguridad altamente fiable. No es sorprendente entonces que cuando GKE Agent Sandbox alcanzó la disponibilidad general en mayo, su uso creció en más de 7 veces en menos de cuatro semanas. Puntos clave: En nuestras pruebas, al migrar agentes de tipo OpenClaw a GKE Agent Sandbox, conseguimos ejecutar más del 40 % más de agentes por vCPU y reducir el coste por agente en más de un 30 %, al tiempo que mantenemos un perfil de rendimiento similar. Optimización 2: El valor de la orquestación. Si bien GKE Agent Sandbox optimiza las cargas de trabajo activas, para resolver el problema de los agentes de IA inactivos, debes hacer que la orquestación de la carga de trabajo sea una parte central de tu arquitectura de agente. En lugar de dejar que los agentes inactivos se ejecuten en segundo plano, puedes utilizar instantáneas de Pod de GKE para hacer un “instantánea” (congelar) y almacenarlas en el almacenamiento persistente, lo que libera sus recursos de CPU y memoria físicos al clúster. Cuando llega un nuevo desencadenador de tareas, un controlador ligero de Kubernetes o puerta de enlace de eventos intercepta la solicitud e indica a GKE que reinicie el agente desde la instantánea. Esto ocurre en milisegundos. Este patrón te permite sobre-subscribir de forma fiable los recursos de cómputo físicos basándose en el comportamiento de la carga de trabajo, para que puedas meter más agentes en el mismo nodo. Sin embargo, la sobre-subscripción no es un enfoque único y viene con un conjunto de compromisos: Diferentes agentes de IA tienen diferentes requisitos de latencia y modelos de ejecución. Si tratas a todos los agentes de la misma manera, o bien degradarás la experiencia del usuario con la latencia, o bien arruinarás tu proyecto con VM sobre-provisionadas. Con GKE, puedes ejecutar una plataforma de agentes que admita implementaciones adaptadas para diferentes tipos de agentes y casos de uso, cada una afinada para sus requisitos de rendimiento y coste únicos. GKE admite un espectro de comportamientos de carga de trabajo de agentes, equilibrando la sensibilidad a la latencia frente a la densidad de recursos. Aquí tienes algunos ejemplos de cargas de trabajo de agentes con requisitos de rendimiento muy diferentes: Asistente de codificación en tiempo real (latencia sensible): Los agentes dirigidos a los desarrolladores necesitan tiempos de arranque de subsegundos (<1 s) y no toleran la colas. Al combinar las instantáneas de Pod de GKE con las “pools” de agentes, GKE mantiene “pools” de agentes pre-calientes e aislados que se pueden ejecutar casi instantáneamente. Compañero autónomo (equilibrado): Los agentes de fondo interactivos pueden tolerar tiempos de arranque promedio (unos segundos). La funcionalidad de suspensión y restablecimiento de GKE restaura estos agentes bajo demanda, para que no consuman recursos mientras están inactivos. Agente de fondo sin encabezado (tolerante a la latencia): Los trabajos cron diarios de análisis o investigación pueden tolerar retrasos en la cola; no comprometerás los resultados de tu negocio esperando a que se ejecuten estos trabajos durante una hora mientras está disponible la capacidad del clúster. Para ahorrar en estos agentes, simplemente utiliza la sobre-subscripción máxima de recursos. En otras palabras, en lugar de forzar a todo el clúster, GKE admite diferentes comportamientos simultáneamente a través de nodos y configuraciones de carga de trabajo. Considera el problema de la “rebaño”, donde un gran número de agentes despiertan y demandan capacidad al mismo tiempo. GKE ofrece un dial afinable con funciones como “pools” de agentes y suspensión y restablecimiento para equilibrar los posibles ahorros de costes frente a un rendimiento garantizado en función de tus requisitos específicos — optimizado para el rendimiento o el coste: optimizado para el rendimiento: Si tu caso de uso requiere un rendimiento garantizado de subsegundos durante picos de tráfico repentinos, puedes provisionar búferes utilizando “pools” de agentes. En esta configuración, pudimos ejecutar 133 agentes de OpenClaw en el mismo nodo. Optimizando para el coste: Para las cargas de trabajo que son tolerantes a la latencia o que se pueden programar, las tasas de sobre-subscripción más altas aumentan significativamente la densidad del nodo. En esta configuración, ejecutamos 274 agentes en el mismo nodo (>3x más que la línea base) manteniendo los tiempos de inicio por debajo de cinco segundos. Optimizando para el coste: Al combinar GKE Agent Sandbox con la funcionalidad de suspensión y restablecimiento de GKE, puedes congelar los agentes inactivos para sobre-subscribir la capacidad de cómputo fija. Para agentes con actividad intermitente, esto puede habilitar hasta 3,5 veces más densidad de agentes y reducciones de coste de hasta el 75 % por agente, al tiempo que se mantiene un perímetro de seguridad altamente fiable. Escala tus agentes, no tu presupuesto. Como hemos demostrado, adoptar las funciones adecuadas de la plataforma y considerar la orquestación desde el principio puede alterar drásticamente el valor que obtienes de tu capacidad de cómputo. GKE te permite alinear fácilmente tu infraestructura con tus objetivos empresariales — ya sea priorizando ahorros de costes o optimizando para el rendimiento. Y esto es solo el principio. En Google Cloud, estamos innovando continuamente nuevas formas de ayudarte a gestionar los requisitos de la era de los agentes. ¿Estás listo para obtener más de tu capacidad de cómputo? Consulta la documentación de GKE Agent Sandbox y descubre cómo GKE está ayudando a los equipos a innovar más rápido y por menos.