O que é o TensorCast e por que ele pode mudar a infraestrutura de LLMs

TensorCast é uma camada proposta de Tensor-as-a-Service (TaaS) — ou “tensor como serviço” — para gerenciar, de forma distribuída e programável, o ciclo de vida dos tensores usados na infraestrutura de inteligência artificial. Isso inclui definir a identidade de cada tensor, onde ele deve ficar, como será movido ou transformado, quem pode compartilhá-lo e quando será materializado na memória de CPU ou GPU. 1

A ideia central é separar o gerenciamento do estado dos tensores da computação que os produz ou consome. Na prática, isso pode substituir a criação de soluções isoladas para carregamento de pesos, gerenciamento de KV Cache, transferência pela rede e acesso a sistemas de armazenamento por uma interface comum para políticas de serving de IA mais dinâmicas. 1

Por que o TensorCast foi desenvolvido

Sistemas baseados em grandes modelos de linguagem precisam lidar com tensores persistentes e distribuídos. O problema não se limita aos pesos do modelo: também envolve blocos altamente dinâmicos de KV Cache — o estado usado para manter o contexto de uma conversa — e outros estados intermediários gerados durante a execução. 1

Tradicionalmente, cada parte desse trabalho fica embutida em um componente diferente: o mecanismo de inferência, o escalonador, o roteador de requisições, a rede ou o backend de armazenamento. Esse modelo fragmentado dificulta combinar ou alterar políticas, como:

• reaproveitar pesos já carregados em outra instância;
• direcionar uma requisição para o servidor que já possui o KV Cache correspondente;
• migrar uma sessão entre máquinas sem reimplementar a lógica em vários componentes;
• replicar ou transformar tensores de acordo com o perfil de cada carga de trabalho.

O TensorCast trata o gerenciamento do ciclo de vida dos tensores como uma camada de sistemas que estava faltando. A aplicação descreve o que deve acontecer com o estado, enquanto o runtime decide como executar a colocação, a movimentação, a transformação e a materialização nos recursos disponíveis do cluster. 1

Essa abordagem também se diferencia de um object store tradicional, que normalmente enxerga os dados como blocos opacos, e de frameworks centrados em computação, que priorizam o agendamento de tarefas — não o ciclo de vida do estado tensorial. 1

Como funciona a arquitetura

O desenho do TensorCast combina alguns elementos principais:

• Tensores como objetos de primeira classe: cada tensor possui identidade, proprietário, localização e regras explícitas de ciclo de vida. Assim, o mecanismo de inferência pode referenciar um peso, um bloco de KV Cache ou um estado intermediário sem precisar codificar exatamente em qual nó, GPU ou mídia de armazenamento ele está.
• Primitivas combináveis: operações como movimentação, transformação, prefetching, replicação e materialização podem ser combinadas em políticas específicas para cada carga de trabalho. O desenvolvedor não precisa alterar a infraestrutura de baixo nível a cada nova otimização.
• Separação entre política e mecanismo: as políticas são escritas usando as APIs do TensorCast, enquanto o runtime executa a distribuição e a transferência dos dados sem exigir mudanças no mecanismo de execução subjacente. 1
• Separação entre plano de controle e plano de dados: o Global Store (GS) mantém metadados do cluster, como estado dos workers e dos nós, localização dos tensores, propriedade e informações de escalonamento. Os Workers, por sua vez, realizam a movimentação efetiva dos dados. O GS coordena a operação, mas não transporta os grandes payloads de tensores, evitando tornar-se um gargalo de transferência. 1

O sistema usa estratégias diferentes conforme o tipo de estado. Objetos com menor cardinalidade e mais estáticos, como pesos de modelos, podem ser acompanhados centralmente pelo Global Store. Já estados numerosos e dinâmicos, como o KV Cache, são fragmentados. Nesse caso, um Worker responsável pelo fragmento mantém a propriedade e a consistência usando leases e tokens de fencing. 1

Para materializar os dados, réplicas mantidas pelos Workers podem expor memória de GPU por meio de CUDA IPC ou memória de CPU por meio de identificadores locais memfd. Quando a origem está em outro nó, o TensorCast oferece gravações diretas via RDMA, reduzindo cópias desnecessárias e permitindo caminhos de compartilhamento locais ou entre GPUs quando o hardware suporta essas operações. 6

Por que a migração do KV Cache fica mais simples

Em uma arquitetura convencional de serving, mover uma sessão de conversa com várias rodadas pode exigir alterações coordenadas no roteador de requisições, na implementação de KV Cache do mecanismo de inferência e no backend de cache ou rede.

Com o TensorCast, uma política pode identificar os objetos de tensor associados à sessão, solicitar que sejam posicionados ou materializados no Worker de destino e encaminhar para lá as próximas requisições. O runtime fica responsável por localizar, transferir e vincular o estado à memória adequada. 1

Isso não significa que a migração deixe de ter custo. O ganho é que a política é expressa uma vez na camada de ciclo de vida dos tensores, em vez de ser reimplementada em diversos componentes fortemente acoplados. Com isso, estratégias que atravessam diferentes partes da infraestrutura — como roteamento baseado na localidade do cache, reutilização de pesos e co-localização de estados relacionados — tornam-se mais fáceis de testar e implantar. 1

O que os experimentos mostraram

Os autores integraram o TensorCast aos mecanismos de inferência vLLM e SGLang. A avaliação incluiu materialização e sincronização de pesos, gerenciamento de KV Cache e roteamento programável de requisições. 1

Os principais resultados relatados foram:

• desempenho de KV Cache competitivo com o Mooncake, um sistema especializado nessa função, mantendo a flexibilidade para criar políticas que abrangem vários componentes; 1
• inicialização de uma instância do Qwen3-235B-A22B até 228,6 vezes mais rápida do que em sistemas de arquivos distribuídos comuns. O modelo tem 235 bilhões de parâmetros no total, dos quais 22 bilhões são ativados; 12
• redução de até 93,2% no tempo mediano até o primeiro token (TTFT) em cargas de trabalho de agentes com alta concorrência e múltiplas rodadas de conversa. 1

Por que isso importa para a infraestrutura de IA

Os resultados sugerem que o TensorCast pode ser útil em infraestruturas de IA elásticas e orientadas a estado. Inicializar modelos mais rapidamente, reaproveitar tensores já disponíveis, migrar sessões com consciência do cache e adaptar o roteamento ao estado do cluster poderiam ser tratados como políticas programáveis, e não como otimizações isoladas de cada framework. 1

Ainda assim, é importante interpretar os números com cautela: eles são resultados experimentais divulgados pelos autores em um preprint de pesquisa. A reprodução independente e a validação em ambientes de produção em larga escala continuam necessárias antes de medir o impacto prático da proposta em diferentes configurações de hardware e cargas de trabalho. 1