GKE dynamic slicing chega à disponibilidade geral e promete TPUs mais resilientes e eficientes

O ponto central do Dynamic Slicing no GKE é separar duas coisas que antes andavam coladas: o provisionamento físico de nodepools e a formação lógica do slice de TPU. Na base, o time faz uma conversão única de toda a capacidade em nodepools uniformes de 16 VMs (um cube, topologia 4x4x4). A partir daí, o slice é montado sob demanda, sem o ciclo de excluir e recriar nodepools.

Há duas formas. No super-slicing, o OCS (optical circuit switching) das TPUs conecta vários cubes na hora do agendamento, conforme a topologia pedida no manifest do workload. O exemplo do Google é um slice 4x4x16, com 64 VMs Ironwood e 256 chips, formado por quatro cubes. No sub-slicing, um cube é dividido em slices menores e isolados, rodando jobs diferentes ao mesmo tempo. Ao fim do job, o scheduler desfaz o slice e devolve as partições ao pool.

Na operação, entra o slice controller no cluster e o scheduler do GKE (ou um próprio). O workload pede o slice por annotations, e o controller cria um Slice Custom Resource. Também surge o nodepool de provisionamento incremental: o GKE sobe o pool com os hosts saudáveis mesmo que alguns do cube estejam com falha, e adiciona os pendentes quando se recuperam. Na falha, o super-slice remove o cube ruim e se refaz com os saudáveis (1 a 2 minutos), e o sub-slice usa partições saudáveis. O recurso vale para todas as regiões com TPU, mas só no modo TPU All Capacity sob reserva.

Para quem opera plataforma de IA no GKE, isso muda o custo operacional: menos nodepools estáticos por topologia, menos toil de recriação e menos capacidade ociosa por causa de host com defeito. A restrição de uso apenas com reserva (All Capacity) pesa no planejamento, então vale checar isso antes de redesenhar o desenho de capacidade. Os ganhos de 5x e 4,5x são números do Google, e convém medir no seu próprio workload.