Modal vai além do Kubernetes para escalar 1 milhão de sandboxes concorrentes em segundos

A Modal criou 1 milhão de sandboxes concorrentes em menos de um minuto, com mediana de startup-to-code abaixo de 0,5 segundo. Os staff engineers Colin Weld e Connor Adams detalharam o redesenho que sustentou esses números em artigo coberto pela InfoQ. Em vez de adaptar o Kubernetes, a Modal retirou a coordenação central do caminho de criação e passou a tratar scheduling como balanceamento de carga.

Por que o Kubernetes trava nessa escala

Segundo Weld e Adams, sistemas tradicionais de orquestração como Kubernetes dependem de coordenação centralizada e estado fortemente consistente. Operar 1 milhão de sandboxes exige dezenas de milhares de nodes, e operações com custo O(containers) ou O(nodes) tendem a encontrar limites.

No Kubernetes, a carga sobre o algoritmo de agendamento e o etcd cresce com o número de nodes e pods. Pods e nodes gravam no etcd várias vezes, o que pode gerar problemas sérios com alta taxa de criação ou churn elevado; o etcd também não é nativamente shardável dentro de uma keyspace. Superar essas limitações é possível, mas exige trabalho sério, como reescrever ou substituir o etcd e paralelizar o agendador.

Estado por worker e agendamento horizontal

A mudança fundamental foi parar de coordenar globalmente e fazer com que cada worker se tornasse a própria fonte de verdade sobre seus recursos. Em vez de um scheduler único e serializado, a Modal implantou uma frota de scheduling servers em paralelo, o que permite escalar horizontalmente a camada de agendamento.

No caminho de criação, o scheduling server seleciona um worker e o contata diretamente via RPC para solicitar a criação do sandbox. O worker aceita se tiver recursos livres; caso contrário, rejeita. A regra de projeto adotada foi que toda carga O(sandboxes) ou O(nodes) precisa escalar horizontalmente por padrão, enquanto o caminho de criação deve ser o mais simples possível e todo o resto fica em segundo plano.

O gargalo restante e o benchmark

Na arquitetura resultante, os autores identificam um único gargalo: os workers publicam seu estado em um único Redis stream. Testes de carga indicam que essa peça continua viável até bem acima de 100.000 workers. No benchmark divulgado, a mediana de startup-to-code ficou abaixo de 0,5 segundo.

Jim Dowling, CEO da Hopsworks, comentou no LinkedIn que novos problemas técnicos aparecem a cada ordem de grandeza e que o time provavelmente iterou várias vezes para chegar a uma taxa confiável de 50 mil criações por segundo. Esse número não consta do relato oficial da Modal, mas dá contexto à dificuldade de estabilizar o pico.

O que muda para infraestrutura de IA

Alex Jones, principal AI engineer da AWS, avaliou que a parte central da conquista da Modal foi não tentar estender o Kubernetes, mas contorná-lo por inteiro depois de entender suas limitações. Ele descreve o caso como o primeiro sinal crível de que o Kubernetes não está se adaptando rápido o bastante para o que a infraestrutura GenAI realmente precisa, segundo a cobertura da InfoQ.

Para Jones, caminhamos para um desacoplamento entre coordenação e execução. O plano de execução quer o que a Modal construiu: fronteiras de isolamento que aparecem em milissegundos. O plano de coordenação, onde fluxos multiagente precisam de memória compartilhada e limites de segurança sobrepostos, ainda quer o que sistemas com formato Kubernetes fazem bem.

A Modal é uma plataforma serverless voltada a cargas de IA, com acesso programático a CPUs, GPUs, containers, inferência, treinamento, batch jobs e sandboxes isoladas. Não está sozinha: Unikraft, Google Substrate e Overdrive perseguem objetivos semelhantes.

Ressalvas: quando esse modelo faz sentido

O redesenho da Modal não é um substituto universal do Kubernetes. A troca de consistência forte por decisões locais e rejeições de solicitação funciona bem para execução efêmera e churn alto, mas não cobre cenários em que coordenação global e estado compartilhado são requisitos centrais. O próprio Alex Jones ressalta que o plano de coordenação segue precisando de sistemas como Kubernetes.

Além disso, o gargalo do Redis stream único é assumido: os testes sugerem viabilidade até acima de 100.000 workers, mas a arquitetura continua dependente de uma fila central para atualização de estado. Para times que operam alta criação e destruição de sandboxes, o agendamento horizontal com estado local no worker é uma alternativa concreta. Para workflows multiagente com memória compartilhada ou orquestração duradoura, o modelo Kubernetes-shaped continua relevante. O caso Modal importa menos como anúncio de substituição e mais como divisão mais clara entre plano de execução e plano de coordenação.