Plataforma de IA da Databricks Reduz Custos de Infraestrutura em 90% nos Casos de Migração

A Databricks lançou uma plataforma de IA agnóstica a modelos que automatiza a seleção de runtime e dimensionamento automático para cargas de trabalho heterogêneas, suportando tudo, desde classificadores scikit-learn de 2 MB em núcleos de CPU único até LLMs com 70B parâmetros finamente aperfeiçoados em oito GPUs. A plataforma atualmente lida com mais de 300.000 consultas por segundo com menos de 10 milissegundos de sobrecarga de latência p99, e clientes que migram de pilhas autogerenciadas relataram redução de até 90% nos custos de infraestrutura.

A arquitetura da plataforma é baseada em três componentes principais: implantações totalmente isoladas do Kubernetes para cada endpoint, seleção automática de runtime e um dimensionador adaptativo. Os modelos são empacotados usando MLflow, padronizando a interface entre modelos clássicos de ML e grandes modelos de GPU. O tráfego é direcionado através de um proxy PoP e balanceador de carga compartilhado para pods específicos do modelo, cada um executando uma imagem de contêiner associada a uma versão específica do modelo e equipado com um sidecar de observabilidade para métricas, logs e rastros. Para motores de inferência, a plataforma padroniza um servidor MLflow Gunicorn assíncrono para modelos tradicionais e escala para backends otimizados para GPU - vLLM, NVIDIA Triton, ou runtime fornecido pelo cliente - para cargas de trabalho maiores, tudo sob uma única interface de serviço uniforme. A Databricks também oferece implantação de clique único do ambiente de treinamento para produção, garantindo uma correspondência exata do ambiente para acelerar a iteração e o rollback.

A telemetria pós-produção é integrada ao Unity Catalog via registro e rastreamento nativo do OpenTelemetry, com tabelas de inferência transmitindo cada solicitação para o Delta. Uma interface adicional de "Código Gênio" é fornecida para consulta operacional, embora nenhuma métrica de latência ou precisão seja fornecida para esta camada.

A plataforma visa eliminar a necessidade de ajuste manual, criando perfis dos recursos do modelo e padrões de tráfego em tempo real e dimensionando adequadamente. O número de 300K QPS é um agregado em toda a plataforma, não um número de ponto único para planejamento de capacidade, e a alegação de economia de 90% nos custos é específica para cenários de migração. A figura de sobrecarga de latência de infraestrutura de menos de 10ms p99 refere-se à latência da infraestrutura de serviço, não ao tempo de inferência do modelo de ponta a ponta.

Enquanto a promessa de "nenhum botão" é atraente, a lacuna de comportamento quando o perfil do dimensionador automático diverge dos padrões reais de tráfego permanece uma preocupação, pois este é um modo de falha comum para sistemas dinâmicos que confiam em características de agrupamento históricos para prever a utilização da GPU. Como cada endpoint é uma implantação totalmente isolada do Kubernetes, equipes de plataforma também devem considerar o overhead de início frio por endpoint e base de orquestração, especialmente ao implantar vários micro-classifiers ao lado de um menor número de pontos finais LLM pesados. A falta de benchmarks independentes e a ausência de métricas de desempenho publicadas do eval harness ou Genie Code deixam uma lacuna para equipes que precisam validar o overhead de rastreamento antes de habilitar o registro de payload em escala.

O empacotamento do modelo deve ser tratado como o invariante, com MLflow atuando como o padrão, e deixe a camada de serviço abstrair a seleção de runtime. No entanto, sempre exija uma saída documentada para quando as suposições de tráfego do dimensionador automático falharem.