Las demandas de CPU de la IA agéntica de Google ponen bajo escrutinio la capacidad inactiva
Google afirma que los agentes de IA crearán nuevas demandas de CPU, incluso cuando sus entornos de ejecución pasen largos periodos esperando. Por tanto, las demandas de CPU de la IA agéntica de Google plantean un problema más difícil que simplemente añadir procesadores: mantener disponibles trabajadores de software persistentes sin reservar hardware inactivo. Las CPU, los procesadores de propósito general que ejecutan código de aplicaciones, pasan a ser fundamentales cuando los agentes van más allá de generar respuestas y comienzan a operar software.
En una entrevista con EE Times del 30 de octubre, el ejecutivo de Google Cloud Mark Lohmeyer describió agentes que llaman a servicios, navegan sitios web y ejecutan código. Esas actividades amplían el trabajo computacional alrededor del modelo. Las GPU, procesadores optimizados para cálculos paralelos, y las TPU de Google, chips especializados para aprendizaje automático, siguen encargándose de gran parte del cómputo del modelo. La aplicación circundante necesita su propia capacidad de ejecución.
Esto presiona a las plataformas en la nube y a los equipos de infraestructura empresarial. Un sistema diseñado en torno a la velocidad de servicio del modelo aún puede decepcionar cuando los agentes esperan espacios de trabajo, pierden el estado de sesión o reservan recursos innecesariamente. AWS persigue servicios de ejecución similares, ofreciendo a los compradores una referencia competitiva. La competencia central se da entre entornos reservados de forma continua e infraestructura que preserva el trabajo de un agente mientras libera cómputo inactivo.
Las demandas de CPU de la IA agéntica de Google van más allá del servicio de modelos
El argumento de Google se refiere a la infraestructura que rodea a un modelo de IA, no a un reemplazo de procesadores especializados para IA.
Lohmeyer, vicepresidente y gerente general de infraestructura de IA y cómputo de Google, describió esta distinción en la discusión sobre cargas de trabajo de agentes. Según EE Times, los agentes convierten la solicitud de un usuario en subtareas que implican ejecución ordinaria de software. La carga de trabajo resultante es intermitente, lo que crea requisitos diferentes para procesadores, almacenamiento y gestión de recursos.
La relevancia reside en lo que ocurre después de que un modelo selecciona una acción. Producir una instrucción plausible y completar la tarea indicada consumen recursos distintos. Un navegador debe cargar una página, un programa debe ejecutarse y una aplicación debe devolver un resultado. Añadir inteligencia a la decisión no elimina esas operaciones.
Un agente, es decir, software que utiliza un modelo para seleccionar y realizar acciones hacia un objetivo, conecta estas etapas. Su utilidad depende de la secuencia completa. Una respuesta rápida del modelo ofrece un beneficio limitado si el siguiente entorno de ejecución tarda demasiado en estar disponible.
Esto ayuda a explicar por qué los requisitos de CPU merecen atención junto con la capacidad de servicio de modelos. El servicio de modelos consiste en ejecutar un modelo entrenado para producir resultados. La ejecución total de un agente incluye esa operación, pero también el código y los servicios que lo rodean. Medir solo el modelo deja una parte de la aplicación fuera del panorama de rendimiento.
La entrevista tampoco establece un ganador universal entre los procesadores. Lohmeyer describió que Google Cloud utiliza procesadores Intel y AMD junto con sus chips Axion basados en Arm. Arm y x86 son familias de conjuntos de instrucciones de procesador, que determinan las instrucciones de máquina que ejecuta el software. Diferentes cargas de trabajo de agentes pueden favorecer distintas combinaciones de rendimiento por núcleo, cantidad de núcleos y almacenamiento conectado.
Esta distinción importa para interpretar el titular. Más actividad de agentes no significa automáticamente que todas las categorías de CPU se beneficien por igual. Una carga de trabajo dominada por la ejecución de programas difiere de otra dominada por la espera de servicios externos. Los compradores aún necesitan comprender el trabajo que realmente ejecutan.
La infraestructura de agentes de Google ahora hace más concreto ese argumento. El 22 de octubre, Google presentó Agent Compute Engine, describiendo un servicio que ya respalda tareas de trabajo de Gemini. Su anuncio apuntaba a la disponibilidad en vista previa para clientes en los próximos meses. Al 1 de noviembre, esa redacción no debe interpretarse como disponibilidad general.
La secuencia da a la entrevista un contexto específico. Google está explicando un problema de ejecución mientras prepara un servicio comercial destinado a abordarlo. Esto vuelve relevante su explicación de ingeniería, al tiempo que da a los lectores una razón para distinguir la arquitectura documentada de los beneficios esperados para los clientes.
Los equipos de infraestructura asumen el costo de la espera
La presión inmediata recae sobre los equipos responsables de mantener listos los entornos de agentes entre ráfagas de trabajo útil.
Un entorno persistente conserva material de trabajo entre interacciones. Esto puede incluir archivos, software instalado y estado de aplicaciones. La persistencia hace útil a un agente durante una tarea prolongada, pero complica la gestión de recursos. Mantener la información disponible y mantener asignado un procesador son requisitos distintos.
Considere un asistente de programación que trabaja en un cambio de repositorio. Lee archivos, ejecuta un programa, espera la salida del modelo y pide aprobación a un desarrollador. El espacio de trabajo sigue siendo relevante durante esas pausas. El procesador no necesariamente debe permanecer reservado durante el mismo periodo.
Esta es una carga de trabajo ilustrativa, no una implementación medida de un cliente. Muestra por qué el tiempo transcurrido de una sesión puede representar erróneamente la demanda real de ejecución. Una sesión puede seguir siendo valiosa mientras está inactiva. Tratar cada sesión abierta como continuamente ocupada oculta esa distinción.
La consecuencia alcanza al modelo de negocio de la aplicación. Un comprador que adquiere una experiencia de agente quiere trabajo completado y continuidad fiable. El proveedor de infraestructura debe proporcionar esos resultados mientras decide cuánto hardware reservar. Una mala asignación puede aumentar el gasto operativo sin mejorar el resultado del usuario.
La utilización de CPU de agentes, la proporción de capacidad de procesador disponible dedicada a ejecutar trabajo, cobra relevancia aquí. Sin embargo, una cifra de utilización promedio no describe toda la experiencia. Una plataforma puede mostrar un uso promedio bajo y aun así tener dificultades cuando muchos agentes en espera se activan a la vez.
Esto crea requisitos operativos contrapuestos. Los proveedores quieren compartir capacidad de manera eficiente, mientras que los usuarios esperan acceso inmediato cuando el trabajo se reanuda. Agrupar entornos estrechamente solo ayuda si el sistema puede gestionar la actividad renovada. Las demoras durante periodos de alta actividad pueden eliminar el beneficio de mantener las sesiones disponibles.
La descripción de Google del 15 de septiembre de Agent Substrate aborda explícitamente los entornos de ejecución inactivos y las ráfagas de actividad. La empresa describe software que separa la ejecución de agentes de la gestión de las máquinas subyacentes. También ofrece distintos enfoques de aislamiento, lo que refleja que las cargas de trabajo no comparten requisitos de seguridad idénticos.
La presión se extiende a las compras empresariales. Las conversaciones sobre capacidad ahora deben incluir cómo un agente se pausa, conserva el trabajo y se reanuda. Una especificación de procesador por sí sola no puede responder esas preguntas. El comportamiento del servicio entre ráfagas de ejecución se convierte en parte del producto adquirido.
Esto también cambia la responsabilidad interna. Un equipo de aplicaciones puede elegir un marco de agentes mientras un equipo de plataforma gestiona su tiempo de ejecución, el entorno que ejecuta su software. Si ninguno de los equipos mide la asignación de recursos inactivos, el consumo innecesario puede quedar entre sus responsabilidades. El problema resultante aparece en la factura de infraestructura, no en la evaluación del modelo.
Para los desarrolladores, la implicación práctica es arquitectónica. Las experiencias de usuario de larga duración no deberían requerir automáticamente reservas de procesador de igual duración. Que una plataforma pueda separar esos ciclos de vida determina la facilidad con la que un prototipo útil se amplía hasta convertirse en un servicio.
Los espacios de trabajo persistentes desafían el cómputo reservado de forma continua
La cuestión central de diseño es si un agente puede conservar su entorno de trabajo mientras cede el hardware que temporalmente no necesita.
Las aplicaciones tradicionales ya gestionan periodos inactivos, por lo que el problema subyacente tiene precedentes. Las cargas de trabajo de agentes lo agudizan al combinar código potencialmente no confiable con espacios de trabajo personalizados y continuos. El entorno debe seguir siendo útil entre interrupciones sin convertirse en una asignación permanente innecesaria.
Una microVM es una máquina virtual reducida que utiliza virtualización de hardware para aislar su entorno de ejecución. Un sandbox es un entorno restringido destinado a contener código y limitar su acceso. Estos conceptos se superponen en las plataformas de agentes, pero describen cosas diferentes: un mecanismo de implementación y un propósito de seguridad.
El mecanismo no resuelve por sí solo la economía. Una pequeña máquina aislada puede seguir reservando recursos sin hacer nada. La eficiencia depende de cómo el servicio gestione todo su ciclo de vida. Iniciar, pausar, preservar, restaurar y eliminar un entorno se convierten en operaciones relevantes.
Una instantánea, es decir, una representación guardada del estado de ejecución, ofrece una forma de preservar la continuidad. Restaurar ese estado puede evitar reconstruir un entorno desde el principio. Sin embargo, guardar y restaurar también implican almacenamiento y movimiento de datos. Sacar una carga de trabajo de la memoria activa traslada los requisitos a otro lugar.
Esto hace que la planificación de CPU sea inseparable de la planificación de almacenamiento. Liberar procesadores ayuda menos cuando restaurar un entorno crea una demora prolongada. Del mismo modo, preservar todo indefinidamente puede generar una obligación de almacenamiento creciente. Un diseño completo necesita políticas para el estado retenido, además de la ejecución activa.
La explicación técnica de Google sobre entornos de agentes persistentes describe la creación de puntos de control de sesiones inactivas mientras se preservan archivos y memoria. Crear puntos de control significa guardar un estado de ejecución recuperable. Google también describe mantener credenciales de larga duración fuera de los entornos invitados y enrutar solicitudes mediante puertas de enlace controladas. Estas son descripciones de la empresa sobre su diseño, no hallazgos de seguridad independientes.
El punto analítico más amplio es que la continuidad se convierte en una propiedad de sistemas. Los usuarios experimentan un agente como una tarea en curso, mientras que la infraestructura puede atravesar distintos estados de recursos por debajo. Una implementación exitosa oculta esas transiciones sin perder trabajo ni debilitar los controles de acceso.
AWS ofrece una comparación útil a través de su presentación del 22 de junio de Lambda MicroVMs. AWS describe entornos aislados para código escrito por usuarios o generado por IA, con control directo del ciclo de vida y estado preservado. Su implementación se basa en Firecracker, la tecnología de virtualización ligera de la empresa.
Esta comparación respalda la existencia de un problema compartido de infraestructura. No establece que los servicios de Google y AWS rindan por igual, admitan cargas de trabajo idénticas o impongan restricciones operativas equivalentes. Sus descripciones publicadas proporcionan un punto de partida para la evaluación, no una comparación concluida.
Por tanto, la infraestructura de agentes de Google forma parte de una transición más amplia hacia la gestión de entornos de ejecución como parte de la aplicación de agentes. La competencia relevante no consiste simplemente en qué proveedor ofrece más núcleos de procesador. Se trata de qué servicio preserva el trabajo útil, gestiona la reanudación de la actividad y hace comprensible el consumo de recursos.
Para los compradores, esta distinción cambia la pregunta de evaluación. Preguntar con qué rapidez se inicia un entorno vacío no es suficiente. La pregunta más reveladora se refiere a un espacio de trabajo real, con dependencias y trabajo conservado, que vuelve a estar operativo tras una interrupción.
Una mayor densidad de agentes no establece una previsión de demanda de CPU
Una explicación creíble de trabajo adicional de CPU es distinta de la evidencia que muestra cuánto hardware adicional necesitará el mercado.
Las demandas de CPU de la IA agéntica de Google contienen fuerzas opuestas. Más tareas de agentes generan trabajo de ejecución adicional. Una mejor compartición de recursos reduce el hardware necesario para dar soporte a una determinada población de agentes. El resultado neto depende de la adopción, la intensidad de las cargas de trabajo y la eficacia de las mejoras de infraestructura.
El propio material de ingeniería de Google ilustra por qué importa esta distinción. En un benchmark de densidad de agentes del 30 de julio, la empresa probó una carga de trabajo de OpenClaw con una configuración fija de máquinas. Informó de que podía admitir más agentes mediante cambios en la ejecución y la gestión de recursos. Estos hallazgos se refieren a una carga de trabajo y una configuración concretas.
No deberían convertirse en un multiplicador universal para implementaciones de producción. Diferentes agentes retienen distintas cantidades de memoria, ejecutan software diferente y pasan distintos periodos esperando. Las configuraciones de seguridad también afectan a los recursos disponibles para las aplicaciones. Un resultado de densidad necesita sus condiciones circundantes para seguir siendo significativo.
La misma cautela se aplica en la otra dirección. Una previsión de expansión del trabajo de CPU no establece que los procesadores se conviertan en el recurso limitante para todos los agentes. Algunas aplicaciones pasarán más tiempo esperando respuestas del modelo. Otras encontrarán restricciones de servicios externos o retrasos de almacenamiento.
Por tanto, la utilización de CPU de los agentes es útil como parte de un conjunto de mediciones más amplio. Una cifra alta puede indicar una ejecución productiva, pero también puede acompañar a la contención y a tareas retrasadas. Una cifra baja puede indicar desperdicio, pero también puede reflejar una capacidad de reserva intencional. La interpretación requiere datos de rendimiento y fiabilidad de la aplicación.
La unidad comercial también importa. Contar agentes iniciados puede favorecer a un servicio que completa poco trabajo útil. Contar sesiones activas puede ocultar fallos repetidos o tareas abandonadas. Los resultados completados y aceptados ofrecen una base más exigente para evaluar si las mejoras de infraestructura benefician a los clientes.
También existe otra incertidumbre en torno a la palabra “agente”. Una solicitud breve de ejecución de código y un espacio de trabajo de navegador persistente pueden llevar ambas esa etiqueta. Sus requisitos de procesador y persistencia difieren. Agruparlos en una categoría de demanda indiferenciada oculta la mezcla de cargas de trabajo que determina las necesidades reales de recursos.
Por eso, la narrativa sobre la CPU debería evitar declarar un ganador de arquitectura. Los diseños de Intel, AMD y basados en Arm compiten dentro de configuraciones de servicio más amplias. La compatibilidad de software, la capacidad de memoria y el acceso al almacenamiento pueden influir en el resultado junto con la velocidad de ejecución del procesador. Una comparación a nivel de aplicación debe mantener coherentes sus criterios de éxito.
La conclusión mejor respaldada es más limitada que una previsión de mercado. Google ha identificado el trabajo de ejecución ordinario como un componente importante de los servicios de agentes. La dirección de su producto aborda la brecha entre las sesiones continuas y la actividad intermitente. La escala de la demanda de hardware resultante sigue siendo una cuestión empírica.
Esto deja margen tanto para una mayor adopción como para una mejor eficiencia. Si los agentes resultan útiles en más flujos de trabajo, la ejecución total puede crecer pese a una mejor compartición de recursos. Si la adopción decepciona, la mejora de la infraestructura por sí sola no generará una demanda sostenida. El mecanismo técnico explica una oportunidad sin establecer su tamaño final.
El aislamiento debe sobrevivir al impulso por una mejor utilización
Recuperar recursos inactivos crea valor solo cuando la plataforma preserva los límites de seguridad y el estado de trabajo que necesitan los clientes.
Los agentes pueden ejecutar código influido por la salida del modelo y por información externa. Esto crea una relación de confianza distinta de la que existe al ejecutar únicamente software escrito y revisado por los desarrolladores de una aplicación. El entorno de ejecución debe tener en cuenta acciones que su operador no autorizó explícitamente.
El aislamiento limita a qué puede acceder un entorno de ejecución. La autorización determina qué acciones puede realizar una identidad. Estos controles resuelven problemas relacionados pero distintos. Un entorno aislado aún puede hacer un uso indebido del acceso que un sistema le concede legítimamente.
Esta distinción evita un error común de categorización. Un límite de ejecución seguro no establece que un agente comprenda correctamente una solicitud. Tampoco establece que toda acción permitida responda a la intención del usuario. Los controles de infraestructura contienen la ejecución, mientras que los controles de la aplicación gobiernan la tarea.
El debate sobre eficiencia debe preservar ambas capas. Consolidar más trabajo sobre hardware compartido aumenta la importancia de una separación fiable. Conservar sesiones plantea cuestiones sobre los datos retenidos y la expiración de accesos. Reanudar un espacio de trabajo no debería restaurar silenciosamente permisos que ya no son apropiados.
Consideremos un agente de investigación empresarial que lee documentos internos y prepara una sesión informativa. El agente necesita suficiente continuidad para conservar su progreso. Su acceso debe seguir reflejando los permisos actuales del usuario. Un espacio de trabajo guardado y una decisión de autorización no deberían tratarse como registros intercambiables.
Este ejemplo también conecta el diseño de infraestructura con la calidad de la información. Conservar un proceso solo ayuda cuando el sistema retiene las fuentes y el material de trabajo adecuados. Los equipos que crean una base de conocimiento con capacidad de búsqueda afrontan un reto organizativo relacionado: mantener la evidencia técnica recuperable durante el trabajo continuo. Esa preocupación complementa la persistencia del entorno de ejecución sin sustituirla.
La resiliencia operativa merece la misma atención. Un entorno que se reanuda correctamente en condiciones normales podría comportarse de manera diferente tras una escritura interrumpida o una conexión fallida. Los compradores necesitan entender qué sobrevive a una pausa y qué debe recrear la aplicación. De lo contrario, la aparente continuidad puede ocultar una recuperación incompleta.
El mismo principio se aplica a la limpieza. Un agente que deja de trabajar debería acabar liberando recursos según una política de retención explícita. Conservarlo todo indefinidamente crea obligaciones innecesarias. Eliminar con demasiada agresividad socava la experiencia continua que la infraestructura se diseñó para ofrecer.
Estas son razones para examinar cuidadosamente las afirmaciones de Google, sin descartar el diseño subyacente. La documentación de la empresa explica los límites y el comportamiento previstos. Las pruebas independientes y la experiencia operativa establecen cómo se comportan esas funciones en condiciones reales de aplicación. Ninguna debe sustituirse por la otra.
La implicación para la compra es concreta. Evalúe conjuntamente el aislamiento, la continuidad y la eficiencia de recursos. Un servicio que optimiza una dimensión mientras deja las otras poco claras no resuelve el problema completo de infraestructura. El resultado relevante es trabajo útil entregado dentro de un modelo de seguridad y operación aceptable.
La próxima evidencia debería proceder del acceso, las cargas de trabajo y los resultados
La siguiente etapa de esta historia depende del comportamiento de ejecución visible para los clientes, en lugar de afirmaciones adicionales de que los agentes necesitan CPU.
La primera señal es el acceso práctico a Agent Compute Engine. El anuncio de Google de octubre apunta a la disponibilidad en vista previa en los próximos meses. Durante los próximos meses, las condiciones de acceso publicadas, las configuraciones compatibles y los límites operativos mostrarán cómo pueden los clientes evaluar esa arquitectura.
Una vista previa reforzaría la historia al desplazar el debate hacia un comportamiento observable del servicio. Un acceso limitado seguiría aportando evidencia útil, pero restringiría las comparaciones. La documentación debería aclarar esos límites en lugar de dejar que los lectores los infieran a partir de descripciones del uso interno de Google.
La segunda señal son las pruebas representativas de cargas de trabajo. Las comparaciones útiles deberían incluir ejecución activa, espera, interrupción y recuperación dentro de la misma tarea. Un entorno que se inicia rápidamente pero se reanuda mal no ofrece una continuidad coherente. Del mismo modo, un estado inactivo eficiente importa menos si las transiciones repetidas interrumpen el trabajo.
Estas pruebas deberían revelar la carga de trabajo y las condiciones que la rodean. Los requisitos de memoria, los archivos retenidos, la concurrencia y la configuración de aislamiento afectan a la interpretación. Las comparaciones se vuelven más informativas cuando incluyen AWS u otros servicios de ejecución relevantes bajo requisitos de aplicación equivalentes.
Esta evidencia reforzaría el argumento de Google si una mejor gestión de recursos preserva las tasas de finalización y la capacidad de respuesta. Debilitaría el caso comercial si los ahorros exigen retrasos inaceptables o una compatibilidad de aplicaciones más limitada. Cualquiera de los dos resultados proporcionaría más información que un benchmark aislado de procesadores.
La tercera señal son los informes de clientes sobre trabajo completado. Las implementaciones empresariales pueden revelar si la infraestructura de ejecución sigue siendo una restricción material después de elegir el modelo. También pueden mostrar si los entornos persistentes mejoran suficientemente la finalización de tareas como para justificar su complejidad operativa.
Esos informes deberían distinguir los problemas del modelo de los problemas del entorno de ejecución. Un agente que elige la acción equivocada presenta un fallo distinto al de un entorno que no puede reanudarse. Combinar ambos en una única cifra de éxito dificulta evaluar la infraestructura. Separarlos ayuda a los compradores a entender qué mejoras importan.
Las demandas de CPU de la IA agéntica de Google serán más fáciles de evaluar cuando estas señales aparezcan juntas. El acceso al servicio establece qué pueden utilizar los clientes. Las pruebas representativas establecen cómo se comporta la ejecución. Los resultados de los clientes establecen si el sistema resultante produce suficiente valor como para respaldar un despliegue continuado.
Por ahora, la información respalda un cambio claro de énfasis. Las aplicaciones de agentes requieren atención a la ejecución de software que rodea a un modelo, incluidos los periodos en que dicha ejecución se detiene. Las CPU siguen siendo esenciales para ese trabajo, mientras que la persistencia y la gestión de recursos determinan con qué eficiencia las plataformas las proporcionan.
Comience con un flujo de trabajo que su organización realmente quiera que complete un agente. Identifique qué etapas ejecutan código, cuáles esperan y cuáles requieren archivos o permisos retenidos. Pida a los posibles proveedores que demuestren esas transiciones utilizando la misma tarea y los mismos criterios de aceptación. Mantenga la evaluación centrada en el trabajo completado, el estado recuperable y un consumo de recursos comprensible. Ese enfoque ofrece a desarrolladores y compradores una forma práctica de evaluar el argumento de Google a medida que nuevos servicios se vuelven accesibles. La decisión depende menos de aceptar una previsión amplia de demanda de CPU que de establecer si una plataforma respalda económicamente una experiencia de agente continua. ¿Qué ocurre con el ordenador de su agente cuando el agente no tiene nada que hacer?
