Browser Use otimiza browsers em nuvem com Firecracker: sessões em <1s e US$ 0,02/h

A Browser Use não só trocou unikernels por Firecracker, ela resolveu um paradoxo operacional: como rodar VMs isoladas *dentro de VMs* sem pagar o preço da latência aninhada? A resposta está em três camadas técnicas interligadas: (1) otimização de page faults com userfaultfd e mapeamento de memória em 2MB pages, reduzindo chamadas ao host em 91x; (2) gerenciamento dinâmico de vCPUs, desafixadas na inicialização para distribuir carga, depois afixadas com prioridade real-time e alocação por core físico completo (não por thread); e (3) um fork de Chromium modificado *no nível do binário*, não via injeção de JS, eliminando rastros detectáveis de automação. Isso explica por que o tempo final de criação da sessão (825ms p50) é mais rápido que o cold start do GKE Autopilot (que ainda leva segundos) e quase 2x melhor que o Hive da Vercel (5s para builds, mas não para sessões interativas).

O fato de usarem EC2 regular, e não bare-metal .metal, é uma decisão arquitetural calculada, viabilizada apenas a partir de fevereiro de 2026, quando a AWS ativou suporte nativo à virtualização aninhada em instâncias Intel de 8ª geração. Antes disso, essa abordagem era tecnicamente possível, mas impraticável em produção por causa da latência imprevisível. Hoje, ela se tornou o novo padrão de eficiência para workloads efêmeros e multitenantes: segurança forte (isolamento de VM), custo baixo (EC2 sob demanda) e velocidade extrema (sub-1s). O próximo passo, snapshot após o Chromium já estar rodando, exigirá lidar com estado gráfico, rede e fingerprinting em runtime, um desafio que vai além do que o CRIU ou QEMU fazem hoje.

Na cobertura anterior de 27/05/2026 sobre a Vercel, o Firecracker foi usado para acelerar builds, cargas de execução única, sem estado persistente. Na Browser Use, ele agora orquestra sessões interativas com estado completo (cookies, cache, login, renderização), exigindo restauração de snapshots com precisão de milissegundos e controle granular de CPU/memória. Também houve evolução concreta em relação ao artigo de 13/05 sobre o GKE: enquanto o Google otimiza o startup de nodes inteiros, a Browser Use isola *cada sessão* em sua própria microVM, um nível de granularidade que o Kubernetes não oferece nativamente, mesmo com Standby Buffer. E diferentemente da NetEase Games (05/11), que reduziu cold start de LLMs com pré-carregamento de dados em GPU, aqui o gargalo é o próprio navegador executando em CPU, exigindo engenharia de baixo nível no kernel Linux (userfaultfd), no hypervisor (Firecracker) e no browser (fork do Chromium).

Essa arquitetura define um novo benchmark para aplicações serverless interativas: não basta iniciar rápido, é preciso iniciar *isolado*, *fingerprintado* e *indetectável*, tudo em menos de um segundo. Para devs, isso significa que testes end-to-end, automação de scraping ético e integração com sistemas anti-bot deixam de ser tradeoffs entre custo, velocidade e segurança. Para plataformas de CI/CD, é um aviso: o futuro do provisionamento efêmero não está em containers ou unikernels, mas em microVMs com controle de estado em tempo real. E para equipes de infra, mostra que 'VM dentro de VM' deixou de ser um hack e virou padrão operacional, desde que você saiba onde aplicar userfaultfd, como gerenciar hyperthreads e por que prioridade real-time em vCPUs elimina falhas em escala.