O KV cache sai da GPU: a Scality coloca o armazenamento na rota de inferência

O que aconteceu

Em 8 de outubro de 2026, a empresa de infraestrutura de dados Scality anunciou em São Francisco a disponibilidade imediata do AI Inference Factory. É uma pilha de software de código aberto para empresas, órgãos públicos e provedores neo-cloud implantarem e operarem inferência de IA em infraestrutura própria; segundo o comunicado, uma alternativa com suporte aos serviços de IA em nuvem, sem montar toda a pilha do zero.

A pilha tem quatro partes: modelos abertos validados e mantidos dentro da pilha; uma camada de serviço de inferência desagregada, com prefill e decode escalando separadamente; um plano de controle com autenticação, medição, roteamento para as GPUs com o contexto relevante e agendamento por SLA; e o Scality ADI, uma infraestrutura autônoma de gestão de dados com governança de políticas que atua como camada de armazenamento compartilhado.

É oferecido como licença de software ou serviço totalmente gerenciado, e foi demonstrado no Scality Day em Paris em 8 de outubro. A Scality diz que valida, distribui e mantém a pilha integrada para acompanhar modelos, tecnologias de serviço e requisitos de segurança.

[1]

Por que agora

O comunicado resume a motivação em três contas. Primeira: com preço por token na nuvem, quanto mais útil o fluxo de trabalho, mais imprevisível a fatura, e impossível de limitar. Segunda: versões e quantizações podem mudar a critério do provedor, arrastando os fluxos construídos em cima. Terceira: onde prompts, documentos e código proprietário são processados, sob qual jurisdição e quem pode cortar o acesso; as três perguntas de soberania para dados sensíveis e regulados. A aposta da Scality: a maioria terminará híbrida, com os processos críticos on-premises.

O comunicado cita a analista da IDC Nataliya Yezhkova: onde a infraestrutura puder hospedar e servir o estado do modelo com eficiência, a inferência local é uma opção crível para um número crescente de cargas corporativas e do setor público. Nota: é uma citação de endosso dentro do comunicado do fabricante, não um relatório independente da IDC.

[1]

A substância técnica

A parte mais sólida é o desenho do Scality ADI como camada compartilhada de KV cache. Na inferência, o KV cache cresce com o comprimento do contexto e estoura rápido a HBM da GPU; o convencional é deixá-lo no servidor GPU onde nasceu. A proposta da Scality: o ADI oferece um cache compartilhado multipetabyte que as GPUs leem com latência da mesma ordem da memória da GPU, restaurando contexto do armazenamento em vez de recomputá-lo, com melhor utilização de GPU e menor custo.

Acompanhado da desagregação prefill/decode: um pool de GPUs só faz prefill e grava o KV cache no ADI; outro só faz decode, lendo-o para gerar tokens. Qualquer GPU de decode pode assumir qualquer contexto, o prefill já não interrompe o decode e ambos os pools vão a plena carga.

Vale registrar o CTO Giorgio Regni: o KV cache no ADI é rápido o bastante para ficar na rota de serviço; restaurar um contexto do ADI é da mesma ordem da memória da GPU e 14 vezes mais rápido que recomputá-lo, com as GPUs ocupadas o tempo todo; o armazenamento já não é motivo para deixar o KV cache dentro do servidor GPU. O CEO Jérôme Lecat emoldura a narrativa de soberania: as organizações precisam de mais controle sobre onde a inferência roda, como os modelos são geridos e o que acontece com seus dados.

[1]

Lendo os números

A Scality publicou números de seus próprios testes, sem verificação independente: Gemma-3 27B carrega em 1,9 segundos via RDMA em paralelo no cluster, cerca de 10 vezes o NVMe local; 166 ms de warm time-to-first-token restaurando um contexto de 14K tokens do ADI, só 83 ms atrás da HBM; recuperação de KV cache 14 vezes mais rápida que recomputar a 14K e 72 vezes a 439K; cache de mais de 80 vezes a memória de uma GPU, com 1.000 sessões concorrentes retomáveis sem recomputar; 97% da velocidade de linha entre GPU e armazenamento; contexto restaurado antes do primeiro token, sem impacto mensurável na geração.

Para a desagregação em si, o comunicado cita dois estudos públicos de terceiros: DistServe (OSDI 2024), até 7,4 vezes mais requisições com as mesmas metas de latência; Mooncake, 75% mais requisições no tráfego de produção da Kimi. São números de pesquisa pública, não testes da Scality; é preciso separá-los dos números do fabricante.

As condições de ponto ideal são explícitas: 14K e 439K são os comprimentos escolhidos pelo comunicado; o impacto não mensurável depende de a restauração concluir antes do primeiro token, sem distribuição de latência de cauda publicada. Até haver reprodução de terceiros, o planejamento de capacidade deve descontar os números do fabricante e exigir medições com sua própria distribuição de contextos.

[1]

Soberania e abertura

A lista de compatibilidade é ampla: frameworks OpenCode, Hermes, Goose, LangGraph e Pydantic AI; modelos abertos validados como Mistral, Gemma, gpt-oss, Qwen, Kimi, GLM e DeepSeek; servidores padrão de Dell, HPE, Lenovo e Supermicro. Tudo é entregue como código aberto: o cliente pode inspecionar como o estado de inferência é armazenado e movido e propor contribuições, mas a Scality as revisa; a abertura é real, e o guardião também.

Duas contas a saldar. Primeira: código aberto com revisão da Scality não é o mesmo que open source comunitário puro; aproxima-se mais do open source comercial com tronco controlado pelo fabricante. É preciso perguntar por critérios de revisão, SLA de patches de segurança e limites de suporte após um fork. Segunda: quando o KV cache vira um ativo persistente, auditável e portátil entre GPUs, prompts e documentos descansam no armazenamento compartilhado como cache; política de residência, criptografia, auditoria de acesso e semântica de exclusão precisam ser reconstruídas; o comunicado promete governança de políticas e ciclos de vida aprovados por humanos no ADI, mas cala os mecanismos, justo o detalhe que um comprador regulado precisa amarrar antes de assinar.

[1]

Implicações e ações

Três implicações para equipes que avaliam inferência local ou soberana. Primeira: mudam as variáveis de otimização de custo; taxa de acerto do KV cache, latência de restauração e partilha prefill/decode já pesam tanto quanto quantas GPUs comprar; exija do fabricante medições com sua distribuição de contextos, não os números de ponto ideal do comunicado.

Segunda: o plano de controle decide a pilha; autenticação, medição, roteamento e agendamento por SLA determinam se a inferência local é um serviço operável ou um monte de GPUs nuas; a Scality colocá-lo entre as quatro partes mostra que entende a lógica de compra enterprise, e o comprador deveria receber com a mesma lista.

Terceira: três coisas ainda não podem ser afirmadas; sem reprodução independente, desconte os números no seu planejamento; zero clientes publicados, de modo que estabilidade em produção e rotas de atualização são incógnitas; e a pilha local troca a fatura por token por custos fixos de depreciação, energia e operações: mais previsível não é mais barato, e o TCO precisa dos seus próprios dados de carga. A narrativa de soberania precisa aterrissar no plano de dados: os pesos abertos são só o primeiro passo; a residência e jurisdição de KV cache, prompts e logs de auditoria são a verdadeira prova.

[1]