Qué es TensorCast y por qué puede cambiar la infraestructura de los grandes modelos

TensorCast es una propuesta de capa “Tensor-as-a-Service” (TaaS): un sistema distribuido y programable que gestiona el ciclo de vida de los tensores —su identidad, ubicación, movimiento, transformación, intercambio y materialización— de forma independiente del cómputo que los produce o consume. 1

La idea es introducir una capa común allí donde hoy suelen convivir soluciones separadas: cargadores de pesos, sistemas de KV Cache, rutas de red, planificadores y backends de almacenamiento. En lugar de optimizar cada componente por separado, las aplicaciones podrían definir políticas sobre el estado tensorial y dejar que el runtime ejecute su colocación y transferencia dentro del clúster. 1

El problema que intenta resolver

Los sistemas que sirven grandes modelos de lenguaje no solo deben cargar los pesos del modelo. También tienen que mover y conservar bloques de KV Cache —la información intermedia que permite continuar una conversación sin recalcular todo desde cero—, además de otros estados temporales.

Tradicionalmente, cada tipo de dato queda ligado a una parte distinta de la infraestructura: el motor de inferencia administra una parte, el router decide a qué instancia enviar una petición, la red mueve los datos y el almacenamiento conserva determinadas copias. Esta fragmentación dificulta combinar políticas como reutilizar pesos, enrutar según la localidad de la caché o trasladar una sesión junto con su estado. 1

TensorCast plantea que la gestión del ciclo de vida de los tensores es una capa de sistemas que falta. A diferencia de un almacén de objetos convencional, que suele tratar los datos como bloques opacos, TensorCast les asigna identidad, propiedad, ubicación y reglas de ciclo de vida explícitas. Y, a diferencia de un framework centrado en el cómputo, no se limita a programar tareas: también coordina qué ocurre con el estado tensorial antes, durante y después de la ejecución. 1

Cómo funciona TensorCast

• Tensores como objetos de primera clase: un peso, un bloque de KV Cache o un estado intermedio puede identificarse sin que el motor tenga que saber en qué nodo, GPU o medio de almacenamiento se encuentra. 1
• Primitivas combinables: operaciones como mover, transformar, replicar, precargar o materializar tensores pueden combinarse en políticas adaptadas a cada carga de trabajo. Así, una nueva optimización no exige reescribir toda la infraestructura de bajo nivel. 1
• Separación entre política y mecanismo: el desarrollador define qué política quiere mediante las API de TensorCast; el runtime se encarga de la ejecución distribuida y del movimiento de datos sin obligar a modificar el motor de ejecución subyacente. 1
• Separación entre plano de control y plano de datos: el Global Store (GS) mantiene metadatos como el estado de los nodos y Workers, la ubicación de los tensores, la propiedad y la información de planificación. Los Workers, en cambio, realizan las transferencias efectivas. El GS coordina, pero no transporta las cargas tensoriales, lo que evita convertirlo en un cuello de botella. 1

El sistema utiliza distintas estrategias según el tipo de estado. Los objetos relativamente estáticos y de baja cardinalidad, como los pesos del modelo, pueden registrarse de forma centralizada en el Global Store. Los estados dinámicos y numerosos, como los bloques de KV Cache, se distribuyen entre shards; un Worker responsable de cada shard mantiene la propiedad y la consistencia mediante arrendamientos (leases) y tokens de bloqueo (fencing tokens). 1

Menos copias al materializar los datos

Cuando un tensor debe estar disponible para un motor, TensorCast puede exponer réplicas en memoria GPU mediante CUDA IPC o en memoria CPU mediante identificadores locales memfd. Para fuentes remotas, admite escrituras directas a través de RDMA, una tecnología de red de baja latencia que permite transferir datos entre máquinas con una intervención reducida del procesador. 6

La meta es evitar copias innecesarias y aprovechar rutas de intercambio directo entre GPUs o dentro del mismo nodo cuando están disponibles. En la práctica, esto permite que la ubicación física del tensor quede desacoplada de la lógica de la aplicación, sin renunciar a mecanismos de transferencia eficientes.

Por qué simplifica la migración de KV Cache

En un servicio convencional, trasladar una conversación de varias rondas a otra instancia puede exigir cambios coordinados en tres lugares: el router de peticiones, la implementación de KV Cache del motor de inferencia y el backend de caché o red.

Con TensorCast, una política puede identificar los objetos tensoriales asociados a la sesión, solicitar su colocación o materialización en el Worker de destino y dirigir allí las siguientes peticiones. El runtime se encarga de localizar los datos, transferirlos y vincularlos a la memoria correspondiente. 1

Esto no significa que migrar una sesión sea gratuito. La ventaja es que la política se expresa una sola vez en la capa de gestión del ciclo de vida, en lugar de duplicarse en varios componentes estrechamente conectados. De ese modo resulta más sencillo probar estrategias que crucen fronteras del sistema, como enrutar según la localidad de la caché, reutilizar pesos o colocar juntos estados relacionados. 1

Qué resultados experimentales se han presentado

Los autores integraron TensorCast con vLLM y SGLang, dos frameworks utilizados para servir modelos de lenguaje, y evaluaron la materialización y sincronización de pesos, la gestión de KV Cache y el enrutamiento programable de peticiones. 1

Entre los resultados comunicados se encuentran los siguientes:

• El rendimiento de KV Cache fue competitivo con Mooncake, un sistema especializado para esa función, aunque TensorCast conserva la posibilidad de definir políticas que abarquen varios componentes. 1
• Para iniciar una instancia de Qwen3-235B-A22B, un modelo con 235.000 millones de parámetros totales y 22.000 millones de parámetros activados, el trabajo informa de un arranque hasta 228,6 veces más rápido que con sistemas de archivos distribuidos habituales. 12
• En cargas de trabajo de agentes con alta concurrencia y conversaciones de varias rondas, una política programable de TensorCast redujo hasta un 93,2% el tiempo mediano hasta el primer token, conocido como TTFT por sus siglas en inglés. 1

Estos datos apuntan al potencial de TensorCast para una infraestructura de IA elástica y con estado: el arranque rápido de modelos, el enrutamiento consciente de la caché, la migración de sesiones y la reutilización de tensores podrían tratarse como políticas programables, en vez de como optimizaciones aisladas de cada framework.

Aun así, las cifras proceden de los experimentos comunicados por los autores en un preprint de investigación. Será necesario reproducirlas de forma independiente y comprobar su comportamiento en entornos de producción a gran escala antes de extraer conclusiones definitivas. 1