Databricks usa o AI Runtime para sustentar experimentos de pesquisa com centenas de GPUs

A Databricks descreve como o time de pesquisa em IA usa o Databricks AI Runtime (AIR) no dia a dia. O time treina modelos que alimentam o ai_parse_document e o ai_extract, das AI Functions, com SFT, RL offline e RL online. Os modelos vão de poucos bilhões de parâmetros a quase um trilhão, em GPUs NVIDIA H100 ou B300. As maiores execuções usam centenas de GPUs por dias ou semanas, com rede de alta largura de banda.

O AIR faz preflight checks nos nós e monitora a saúde durante a execução. Detecta falhas de comunicação NCCL, throttling térmico ou de energia e problemas de driver, e isola (cordon) o nó problemático para que os próximos jobs não caiam nele. A AIR CLI lança cargas de forma programática, e os mesmos containers Docker do desenvolvimento local servem para treinar, com imagens compartilhadas no Databricks Artifact Registry. O AIR cria e gerencia os experimentos MLflow automaticamente, e os dados ficam no Unity Catalog, acessados via FUSE mounting. Com agentes propondo e rodando experimentos (o chamado autoresearch), o número de jobs de treinamento nas pesquisas de AI Functions cresceu 8x. Os agentes usam a Databricks CLI e o databricks-air-skills para lançar cargas concorrentes e ler métricas do MLflow.

Em 3 de julho de 2026, o CEVIU noticiou "Como a Databricks garante a confiabilidade de GPUs em larga escala para IA", sobre falhas como jobs interrompidos e lentidões silenciosas. Agora a empresa mostra essa confiabilidade em uso real, no próprio time de pesquisa, com health checks e isolamento de nós. Já em 20 de março de 2026, o CEVIU publicou "Escalando a Autopesquisa de Karpathy: O Que Acontece Quando o Agente Recebe um Cluster de GPUs", com cerca de 910 experimentos em 8 horas. O relato da Databricks traz o mesmo padrão para dentro de uma empresa, com o aumento de 8x nos jobs.

Para quem opera pipelines de treinamento, a leitura é que, quando agentes disparam centenas de experimentos, startup lento e erro confuso viram gargalo antes de qualquer limite de modelo. Interface programática, erros claros e rastreamento automático passam a ser requisito de infraestrutura, não conveniência.