Actualidad empresarial BlackHold News
Buscar en BlackHold News
Infraestructura de servidores para agentes de inteligencia artificial

Google acelera hasta 45 veces los sandboxes de agentes en GKE para reducir GPUs ociosas

Google Cloud anunció el 29 de septiembre la disponibilidad general de GKE Agent Sandbox optimizado para reinforcement learning y de un nuevo SDK de orquestación para cargas de agentes. En sus pruebas, el tiempo hasta el primer comando cayó de 44–85 segundos a entre 1,1 y 8,8 segundos, con mejoras de hasta 45 veces en los peores casos, según el Google Cloud Blog.

El objetivo: que las GPU no esperen a los sandboxes

En entrenamiento y evaluación agéntica, los modelos generan acciones en aceleradores y ejecutan código en entornos aislados. Cuando miles de sandboxes tardan minutos en arrancar, las GPU permanecen ociosas esperando al entorno más lento del lote.

Google afirma que su nueva capa mantiene entornos precalentados, utiliza image streaming y reutiliza pods entre ejecuciones para reducir tanto el tiempo de arranque como la presión sobre el plano de control de Kubernetes.

De 7,5 minutos a menos de 10 segundos en el peor caso

En los benchmarks publicados, la latencia máxima pasó de 450 segundos a menos de 10. La compañía también afirma que el reciclaje de pods reduce en tres veces la creación de nuevos pods durante ráfagas de entrenamiento.

Las pruebas incluyeron hasta 18.312 sandboxes simultáneos y miles de imágenes distintas, un escenario pensado para laboratorios de IA y startups que ejecutan evaluaciones masivas.

SDK en Python e integraciones con herramientas de RL

El Agent Sandbox RL SDK expone una API asíncrona de Python para gestionar warm pools sin obligar al equipo a escribir YAML específico. Google incluye integraciones con Gymnasium, NVIDIA NeMo Gym y OpenHands.

Para una pyme que no entrena modelos a gran escala, el anuncio es menos relevante. El impacto directo está en empresas de IA, proveedores de software agéntico y equipos que ejecuten grandes baterías de evaluación o código no confiable.

Qué debería medir una empresa antes de adoptarlo

La decisión debe basarse en coste de aceleradores, tiempo de espera, volumen de sandboxes y requisitos de aislamiento. Mantener entornos calientes consume CPU y almacenamiento, por lo que el ahorro real depende de cuánto coste evita en GPU o TPU ociosa.

El contexto se puede ampliar con las capacidades agénticas de Google Workspace, el sandbox local de GitHub Copilot, CodeQL, el Microsoft Defender ISOC, las passkeys y el parche crítico de GitLab.

Fotografía: panumas nikhomkhai / Pexels.

Scroll al inicio