Por que a Modal aposta que GPU de IA não deveria vir em contratos fixos

Em entrevista ao podcast Latent Space, Erik Bernhardsson explica como a Modal cresceu até US$ 1 bilhão em receita anual vendendo GPU fatiada em vez de blocos fixos, e por que os sandboxes de agentes viraram um terço do negócio.

Nota da redação: este artigo cita o sobrenome do cohost Vibhu como "Sapra", mas a fonte consultada o identifica apenas como "Vibhu", sem sobrenome. Além disso, a reflexão final atribuída a Bernhardsson sobre demanda elástica vs. previsível aparece no material de origem apenas como título de um trecho da entrevista (marcação de tempo), sem o conteúdo da fala disponível para conferência. Mantemos o texto porque o argumento central do artigo (o modelo de GPU fatiada, os números de receita e a fatia de sandboxes) está integralmente verificado na fonte, mas sinalizamos essas duas atribuições específicas para que o leitor as considere com essa ressalva.

Em entrevista ao podcast Latent Space, Erik Bernhardsson explica como a Modal cresceu até US$ 1 bilhão em receita anual vendendo GPU fatiada em vez de blocos fixos, e por que os sandboxes de agentes viraram um terço do negócio.

A forma como a indústria de nuvem vende GPU tem um problema de geometria. Um contrato típico de capacidade garante um número fixo de placas por um período fixo: plotado num gráfico de uso por tempo, isso desenha um retângulo. O problema é que nenhuma carga real de inferência ou treinamento se comporta como um retângulo. Ela cresce, pica e cai ao longo do dia.

Essa é a tese que Erik Bernhardsson, CEO e cofundador da Modal, defendeu em entrevista ao podcast Latent Space, publicada em 22 de outubro de 2026 e conduzida por Vibhu Sapra e pelo novo cohost Basil Chatha. A conversa acontece poucos meses depois de a Modal levantar uma série D de US$ 750 milhões a uma avaliação de US$ 16 bilhões, menos de cinco meses depois da série C de US$ 5 bilhões. No mesmo período, a empresa diz ter cruzado US$ 1 bilhão em receita recorrente anualizada e ter criado quase três bilhões de sandboxes.

O retângulo é o problema, não a solução

Quem compra GPU reservando um número fixo de instâncias por meses enfrenta um dilema simples: comprar para o pico e pagar hardware ocioso na maior parte do tempo, ou comprar para a média e ficar sem capacidade justamente quando o produto decola. Bernhardsson descreve a aposta da Modal como uma espécie de transformação de duração: a empresa agrega a demanda de milhares de clientes diferentes, garante capacidade por baixo (via contratos próprios com provedores de GPU) e deixa cada cliente consumir só o que precisa, quando precisa.

A lógica só funciona se a demanda agregada for suave o bastante. Se todo cliente picasse no mesmo horário, o pool não ajudaria em nada; como as cargas de clientes diferentes picam em momentos diferentes, a soma delas tende a ser mais previsível que qualquer carga individual. É o mesmo princípio por trás de seguro e de mutualização de risco, aplicado a silício.

Bernhardsson reconhece o risco do lado do provedor: se a Modal trava capacidade nos preços de hoje e o preço da GPU cair depois, a empresa fica com estoque caro nas mãos. Ele diz não esperar um colapso iminente nos preços de GPU, mas trata essa possibilidade como parte do cálculo de risco do negócio, não como um cenário remoto demais para ignorar.

O sandbox que quase foi descontinuado

A Modal lançou sandboxes, ambientes isolados onde um agente pode rodar código gerado por um modelo, depois de perceber que LLMs↳LLMs48 conteúdosConsiderações básicas de hardware para modelos de linguagem em código aberto: Memória, Desempenho e ViabilidadeMarketing Tech · out 2025Modelos de linguagem sob ataque: o lado obscuro da IA generativaDevSecOps · mai 2025Criando um LLM – modelo de linguagem de grande escala – do zero com TransformersAI · abr 2024Ver tudo em AI → geravam código e que alguém precisaria de um lugar seguro para executá-lo. A adoção inicial foi modesta o bastante para a equipe discutir internamente se valia a pena manter o produto vivo.

O que mudou o jogo foi a chegada de agentes de codificação, agentes em background e treinamento por reforço, que passaram a demandar exatamente esse tipo de ambiente efêmero em escala. Hoje, segundo Bernhardsson, sandboxes respondem por cerca de um terço da receita da Modal, um resultado que ele diz não ter previsto no lançamento do produto.

Esse crescimento muda o que a infraestrutura precisa entregar. Um agente de codificação típico cria um ambiente, roda código, inspeciona o resultado e tenta de novo, muitas vezes por tarefa. Nesse ciclo, a latência de criar e restaurar o ambiente deixa de ser detalhe de operação e vira parte da experiência que o usuário final sente ao usar o agente.

Startup rápido como característica de infraestrutura, não acidente

Elasticidade só funciona se a capacidade chegar rápido o suficiente para importar. No material técnico da Modal sobre GPU serverless, a empresa descreve o maquinário por trás disso: um buffer de GPUs já disponíveis, um sistema de arquivos próprio, checkpointing de processos e snapshots de memória de GPU. Juntas, essas peças reduzem o trabalho necessário para colocar outra réplica de um modelo no ar.

É um exemplo concreto de como uma decisão de infraestrutura aparece, na ponta, como responsividade↳Design responsivo4 conteúdosDicas de Front-End para usabilidade, acessibilidade, performance e responsividadeProduto & UX · fev 2025Tipos de layouts e suas diferençasProduto & UX · jan 2025Dica de ouro: Saiba como fazer uma navbar responsivaDev (Back & Front) · jun 2025Ver tudo em Produto & UX → e custo de uma aplicação. Um modelo que leva segundos a mais para subir de um snapshot frio, multiplicado por milhares de execuções de agente por dia, vira uma conta visível no fim do mês.

No início da entrevista, ao falar sobre por que construiu tanta coisa do zero em vez de usar Kubernetes↳Kubernetes18 conteúdosGerenciamento de infraestrutura multicloud com Kubernetes proporciona otimização e economiaDevSecOps · set 2021Azure Kubernetes Services – AKS: referências gratuitas e dicas para solução de problemas comunsDevSecOps · abr 2019Kubernetes em produção: o que ninguém te conta e você aprende tarde demaisDev (Back & Front) · abr 2026Ver tudo em DevSecOps → e Docker, Bernhardsson resumiu a lógica por trás dessas escolhas de engenharia:

Minha tese é que toda nova era de tecnologia esbarra nas limitações das ferramentas existentes, seja na web, na nuvem, no mobile, em PCs ou em IA. As ferramentas existem, mas muitas vezes não são particularmente boas, e você precisa repensá-las para colher os benefícios e dar o tranco necessário para construir nesse novo mundo.

My thesis is like, every new sort of era of technology kind of runs up against limitations of tools, whether that's the web, the cloud, mobile, PCs, or AI. Tools exist, but they're often not particularly good, and you often need to rethink those tools in order to reap the benefits and really turbo charge and start building for this new world.Erik Bernhardsson, CEO e cofundador da Modal

O que muda para quem constrói agentes no Brasil

Para quem roda agentes ou inferência fora dos Estados Unidos, o argumento central tem efeito prático direto na planilha de custo. Contratar GPU reservada por meses, no modelo clássico de nuvem, exige acertar de antemão um volume de uso que ninguém consegue prever com precisão num produto de IA em crescimento. Pagar por uso elástico (seja via Modal, seja via qualquer concorrente que adote a mesma lógica) troca esse risco de capital por um risco de preço unitário, geralmente mais alto por hora de GPU, mas sem o compromisso de longo prazo.

A conta muda de figura especialmente para times que constroem produtos com agentes de codificação ou execução de ferramentas, onde o padrão de uso é em rajadas curtas e imprevisíveis, não em cargas estáveis de inferência. Nesse perfil, pagar por um cluster fixo tende a significar GPU ociosa na maior parte do tempo; a lógica de pool elástico foi desenhada justamente para esse caso.

Vale a ressalva: a elasticidade da Modal depende de agregar demanda de clientes como Suno, Runway, Cognition e Decagon, citados por Bernhardsson na entrevista. Equipes com carga muito previsível e constante (um modelo de produção já maduro, rodando 24 horas no mesmo volume) podem achar mais barato negociar capacidade reservada diretamente com um provedor de nuvem ou neocloud, porque aí o prêmio pago pela flexibilidade deixa de fazer sentido.

A pergunta que fica, segundo o próprio Bernhardsson na entrevista, é até onde a demanda por compute de IA segue crescendo de forma elástica e até onde ela começa a se acomodar em padrões mais previsíveis, parecidos com os das cargas de backend↳Back-end49 conteúdosIntegração front-end com backend: 7 decisões que evitam caos entre APIs, BFF e GraphQLDev (Back & Front) · abr 2026Como criar uma FAKE API REST para testes — JSONPlaceholderDev (Back & Front) · set 2025Construindo um aplicativo de bate-papo de IA simples com Spring AI e AngularDev (Back & Front) · jul 2025Ver tudo em Dev (Back & Front) → tradicionais.

Fonte: Latent Space