Google libera TPU Sync para mover la caché KV entre TPU

Una caché KV (caché clave-valor) es la memoria de trabajo que un modelo de lenguaje construye al leer una consulta: por cada token ya procesado, guarda valores intermedios para no recalcularlos cada vez que produce una palabra nueva. Cuanto más larga es la conversación o el documento, más crece esta caché, y normalmente reside en la memoria de gran ancho de banda (HBM), escasa y cara, del chip acelerador.

Google acaba de publicar TPU Sync, una biblioteca nativa en C++ de código abierto diseñada para mover y gestionar esa caché entre sus procesadores de IA TPU (tensor processing units). Según TechBytes, que resume una entrada del blog de Google Cloud firmada por los ingenieros Fenghui Zhang y Weiren Yu, la biblioteca también sincroniza los parámetros de los modelos en los flujos de aprendizaje por refuerzo. SemiAnalysis indica que TPU Sync se llamaba antes TPU-raiden, y Open Source For You presenta el proyecto como TPU Raiden, publicado bajo licencia Apache 2.0.

¿Por qué hay que mover la caché KV?

La inferencia de un modelo de lenguaje tiene dos fases, explica Open Source For You: el prefill, en el que el modelo lee todo el prompt, y el decode, en el que genera la respuesta token a token. El servicio desagregado ejecuta ambas fases en conjuntos de hardware distintos, de modo que tras el prefill la caché KV debe enviarse a los chips que se ocupan del decode. Sin una biblioteca de transferencia, señala SemiAnalysis, el servicio externo en TPU se limita al modo agregado, aunque Google lleva años aplicando la desagregación internamente para Gemini.

Una segunda necesidad es la descarga a memoria externa. Cuando la HBM de un chip no puede contener la caché de todos los usuarios, explica SemiAnalysis, los datos deben viajar de la HBM a la DRAM del host y volver. Mark Lohmeyer, vicepresidente y director general de infraestructura de IA y computación de Google, dijo en una conferencia telefónica, según The Next Platform el 9 de noviembre de 2026, que en las cargas agénticas los TPU permanecen a menudo inactivos buena parte del tiempo. TPU Sync, explicó, saca la memoria de trabajo del chip cuando un agente se pausa y la restaura cuando se reanuda, lo que libera el acelerador para otras tareas y reduce el coste por carga agéntica. The Next Platform añade que, al ser software, Google puede retroportar TPU Sync a generaciones anteriores de TPU.

¿Qué rendimiento anuncia Google?

Las cifras siguientes proceden de TechBytes, con fecha del 9 de noviembre de 2026, que las atribuye al blog de Google Cloud. No pudimos leer la entrada de Google en sí, así que son cifras comunicadas por el fabricante y retransmitidas por un medio secundario.

• La latencia de transferencia clave-valor baja más de un 90 % en modelos abiertos Mixture of Experts de 235.000 a 480.000 millones de parámetros, según TechBytes.
• El Time to First Token (TTFT), el retraso antes de que aparezca la primera palabra de una respuesta, cae un 90 % de media en pruebas de prefix caching y de servicio desagregado, frente a configuraciones estándar, según TechBytes.
• El componente raw_transfer alcanza hasta 223 GB/s de caudal agregado entre dispositivo y host, en ambos sentidos, en hosts TPU Ironwood v7x, frente a un límite físico PCIe Gen5 de 256 GB/s, según TechBytes.
• En la red del centro de datos, el software sostiene unos 192 Gbit/s en una tarjeta de red de 200 Gbit/s y 350 Gbit/s en dos tarjetas con reparto NUMA, según TechBytes.

¿Cómo funciona TPU Sync por dentro?

Según TechBytes, TPU Sync se apoya en transferencias por acceso directo a memoria (DMA, un mecanismo de hardware que copia memoria sin implicar al procesador) que conservan la disposición de los datos, combinadas con aliasing de búferes in situ. La biblioteca evita la serialización en Python y las copias intermedias al trabajar directamente con los búferes PJRT de JAX y los tensores de PyTorch, y las transferencias ocurren fuera del grafo de compilación de XLA. SemiAnalysis describe la misma idea como transferencias sin copia, obtenidas extrayendo los descriptores de hardware nativos de los búferes PJRT.

De acuerdo con TechBytes, el entorno de ejecución se organiza en tres módulos. Un almacén clave-valor global actúa como registro que asocia huellas de prompts con bloques de almacenamiento físicos y dirige los desalojos de los menos usados recientemente. Un controlador de clúster se ocupa de la planificación y de las concesiones. Un gestor de caché local sigue el estado de los bloques del dispositivo, gestiona la memoria del host fijada y mantiene una copia de arranque rápido en memoria compartida bajo /dev/shm. La jerarquía de memoria abarca la HBM, la DRAM del host fijada, los SSD locales y Google Cloud Managed Lustre.

En integraciones, TechBytes menciona enlaces oficiales para PyTorch mediante TorchTPU y para JAX, un conector para los motores de servicio vLLM, SGLang y llm-d, y primitivas de bajo nivel para Pathways y los flujos JAX multicontrolador.

¿Cuáles son los límites y qué madurez tiene?

TechBytes afirma que las transferencias entre HBM y DRAM del host están listas para producción, mientras que el almacenamiento por niveles hacia sistemas compartidos como Managed Lustre o backends POSIX externos sigue en validación experimental. El módulo de sincronización de pesos para aprendizaje por refuerzo también es experimental, y alcanzar el caudal de red máximo exige dos tarjetas de red de 200 Gbit/s configuradas con reparto NUMA. Open Source For You, cuyo artículo no lleva fecha, va más allá y califica el proyecto de aún en desarrollo activo y todavía no destinado al uso general en producción, de modo que el panorama de madurez difiere según las fuentes.

SemiAnalysis aporta un ángulo competitivo. Su avance de InferenceX compara el TPU v7 agregado con los Nvidia B200 y B300 agregados, y afirma que los sistemas GB200 y GB300 NVL72 de Nvidia lideran actualmente una parte de la curva en servicio desagregado. Una comparación con un TPU v7 desagregado está prevista cuando la desagregación basada en TPU-Sync se optimice en la pila externa, y SemiAnalysis espera que el soporte de Mooncake Store en TPU se construya sobre las primitivas de TPU-Sync.

¿Qué cambia para una empresa?

Para una empresa de España o América Latina que ejecute o alquile asistentes y agentes de contexto largo en Google Cloud, mover la caché KV pasa a ser algo que se configura en lugar de algo que hay que construir. Los pasos prácticos son probar el conector con vLLM o SGLang con sus propios prompts, medir el tiempo hasta el primer token antes y después, y comprobar qué niveles de memoria siguen marcados como experimentales antes de depender de ellos. Los equipos que entrenan con aprendizaje por refuerzo deberán validar el módulo de sincronización de pesos en sus propias topologías de entrenadores y muestreadores. Ninguna de las cifras publicadas sustituye a una prueba con su propia carga de trabajo.