Google Cloud libera Z4M, série otimizada para storage voltada a IA/ML e sistemas de arquivos paralelos

A Z4M entra em disponibilidade geral no Compute Engine como série otimizada para storage, em VM e bare-metal. O alvo são cargas de IA/ML que movem muito dado: checkpointing, cache distribuído de chave-valor (KV) e sistemas de arquivos paralelos. Os números do Google: até 168.000 GiB de Local SSD, até 400 Gbps de Cloud RDMA, 192 vCPUs e 1.536 GiB de memória. Em desempenho, são até 15,6 milhões de IOPS de leitura aleatória e 75.600 MiB/s de leitura sequencial, ganhos de até 70% e 110% sobre a Z3. O RDMA reduz a latência de acesso a dados em até 60% frente ao TCP, segundo o Google.

Para quem opera, o detalhe de manutenção pesa. O sistema avisa com vários dias de antecedência. VMs com até 42.000 GiB de LSSD aceitam live migration. VMs com 84.000 GiB ou mais e as instâncias bare-metal precisam ser terminadas e reiniciadas, com os dados preservados. A orquestração fica com o Cluster Director e o Cluster Toolkit, com topologia compacta (desempenho) ou distribuída (alta disponibilidade) por domínios de disponibilidade. Também há suporte a Hyperdisk (Balanced, Throughput e Extreme), até 512 TiB por instância. O acesso é pelo console, escolhendo Z4M na família Storage-Optimized, em VM ou node pool do GKE, em regiões selecionadas.

A cobertura anterior não trata da Z4M, mas há um ponto de contato real: o Agent Substrate, citado pelo Google como uso das instâncias bare-metal para sandboxes isolados. Em 17 de setembro de 2026, o CEVIU noticiou "Google Cloud Lança Agent Substrate para Potencializar Agentes de IA no GKE", descrevendo um runtime de código aberto e seguro por padrão para agentes de IA. Agora o Google posiciona a Z4M bare-metal como base para esse tipo de carga em escala.

Para quem opera plataforma de IA, a Z4M mexe em três frentes: onde fica o checkpoint, como o cache KV escala e quanto custa manter GPU ociosa esperando dado. A diferença entre live migration e reinício forçado deve entrar no desenho de resiliência, sobretudo nos tamanhos maiores de LSSD. Os números de latência e CPU de Nutanix e Silk vêm de testes de parceiros, então vale validar com a sua carga antes de migrar.