Che cos’è TensorCast e perché può cambiare la gestione dei modelli AI

TensorCast è un livello di infrastruttura proposto come modello “Tensor-as-a-Service” (TaaS): un sistema distribuito e programmabile che gestisce identità, posizione, trasferimento, trasformazione, condivisione e materializzazione dello stato dei tensori, indipendentemente dal calcolo che li genera o li utilizza. 1

L’idea punta a superare una frammentazione tipica dei sistemi di serving dei grandi modelli linguistici: caricamento dei pesi, gestione della KV Cache, trasferimenti di rete e accesso allo storage vengono spesso implementati in componenti distinti. TensorCast propone invece una superficie di controllo comune per applicare politiche dinamiche sull’intero ciclo di vita dei tensori.

Perché è stato sviluppato

I sistemi basati su modelli di grandi dimensioni non devono gestire soltanto i pesi persistenti. Devono anche coordinare blocchi di KV Cache, che cambiano rapidamente durante le conversazioni, oltre ad attivazioni e altri stati intermedi. Tradizionalmente, queste funzioni sono distribuite tra motori di inferenza, scheduler, backend di cache, sistemi di storage e meccanismi di rete. 1

Questa organizzazione a silos rende difficile combinare ottimizzazioni che attraversano più componenti. Per esempio, spostare una sessione conversazionale insieme alla sua KV Cache può richiedere modifiche coordinate al router delle richieste, al motore di inferenza e al backend della cache.

TensorCast tratta quindi la gestione del ciclo di vita dei tensori come un livello di sistema distinto: l’applicazione descrive cosa vuole ottenere, mentre il runtime decide come localizzare, posizionare, trasferire e materializzare lo stato sulle risorse del cluster. 1

L’approccio differisce sia dai normali object store, che considerano i dati principalmente come blocchi opachi, sia dai framework centrati sul calcolo, che si concentrano soprattutto sulla pianificazione dei task e non sull’intero ciclo di vita dello stato tensoriale. 1

Come funziona TensorCast

• Tensori come oggetti di prima classe: ogni tensore ha un’identità esplicita, informazioni su proprietà, ownership, posizione e ciclo di vita. Un motore può così riferirsi a un peso, a un blocco di KV Cache o a uno stato intermedio senza dover conoscere in anticipo quale nodo, GPU o supporto di memoria lo ospiti. 1
• Primitive componibili: operazioni come trasferimento, trasformazione, prefetching, replica e materializzazione possono essere combinate in politiche adatte al singolo carico di lavoro. 1
• Separazione tra policy e meccanismi: gli sviluppatori possono scrivere una politica attraverso le API di TensorCast, lasciando al runtime l’esecuzione distribuita e il movimento dei dati. In questo modo non è necessario modificare ogni volta l’infrastruttura sottostante. 1
• Separazione tra piano di controllo e piano dati: il Global Store (GS) conserva metadati come stato dei nodi e dei Worker, posizione dei tensori, ownership e informazioni di scheduling. I Worker eseguono invece i trasferimenti effettivi. Il GS coordina le operazioni senza diventare il canale attraverso cui passano tutti i payload tensoriali. 1
• Metadati con strategie diverse: oggetti relativamente statici e con cardinalità contenuta, come i pesi del modello, possono essere tracciati centralmente. Stati dinamici e numerosi, come i blocchi di KV Cache, vengono invece distribuiti tra più shard; un Worker di riferimento mantiene ownership e coerenza usando lease e fencing token. 1
• Materializzazione efficiente: le repliche locali possono esporre memoria GPU tramite CUDA IPC o memoria CPU tramite handle memfd locali. Per le sorgenti remote, TensorCast supporta scritture dirette via RDMA, riducendo le copie intermedie quando l’hardware lo consente. 6

Perché la migrazione della KV Cache è più semplice

In un’architettura tradizionale, spostare una sessione multi-turno può richiedere l’intervento simultaneo del router, del motore che gestisce la KV Cache e del backend di rete o storage. Con TensorCast, una politica può identificare gli oggetti tensoriali associati alla sessione, richiederne il posizionamento o la materializzazione sul Worker di destinazione e indirizzare lì le richieste successive. Il runtime si occupa di ricerca, trasferimento e collegamento alla memoria. 1

Il vantaggio non consiste nell’eliminare il costo del trasferimento. Consiste nel definire la politica una sola volta a livello di ciclo di vita dei tensori, invece di reimplementarla in diversi componenti strettamente collegati. Questo rende più pratiche strategie basate sulla località della cache, sul riutilizzo dei pesi o sulla collocazione ravvicinata di stati correlati. 1

I risultati sperimentali

Gli autori hanno integrato TensorCast con vLLM e SGLang, due framework utilizzati per il serving e l’inferenza di modelli linguistici, e hanno valutato la materializzazione e la sincronizzazione dei pesi, la gestione della KV Cache e il routing programmabile delle richieste. 1

I risultati riportati indicano che:

• le prestazioni nella gestione della KV Cache sono competitive con quelle di Mooncake, un sistema specializzato per questo compito, pur mantenendo la possibilità di definire politiche che coinvolgono più componenti; 1
• l’avvio di un’istanza di Qwen3-235B-A22B è risultato fino a 228,6 volte più rapido rispetto ai comuni file system distribuiti; il modello conta 235 miliardi di parametri complessivi, di cui 22 miliardi attivati. 12
• negli scenari con agenti che gestiscono conversazioni multi-turno ad alta concorrenza, una politica TensorCast ha ridotto fino al 93,2% il tempo mediano al primo token, noto come TTFT (time-to-first-token). 1

Perché può essere importante per l’infrastruttura AI

Questi risultati suggeriscono che TensorCast potrebbe essere utile per infrastrutture AI elastiche e stateful, nelle quali avviare rapidamente un modello, riutilizzare lo stato già presente e instradare le richieste in base alla località della cache sono operazioni fondamentali.

La promessa principale è architetturale: invece di incorporare ogni ottimizzazione in un singolo framework, rete o backend di storage, le organizzazioni potrebbero esprimere nuove strategie come politiche programmabili sullo stato tensoriale.

È però importante interpretare con cautela i numeri sulle prestazioni. Si tratta dei risultati sperimentali riportati dagli autori in un preprint di ricerca; servono quindi riproduzioni indipendenti e verifiche su ambienti di produzione su larga scala prima di valutare l’impatto operativo definitivo. 1