WebLLM roda LLM direto no navegador com WebGPU e API compatível com a OpenAI

O WebLLM, projeto da equipe MLC-AI↳Inteligência artificial440 conteúdosUX e IA: Transformando Experiências Digitais com Inteligência ArtificialProduto & UX · jan 2025MCP: O que é e por que você vai ouvir falar disso em breve?AI · jul 2025IA generativa e a urgência de reconstruir nossa relação com a verdadeAI · jun 2025Ver tudo em AI → com 18,7 mil estrelas no GitHub, é um motor de inferência que roda modelos de linguagem inteiramente dentro do navegador, com aceleração de hardware via WebGPU e sem nenhum servidor no meio. A proposta é direta: você instala um pacote npm, escolhe um modelo, e o navegador do usuário passa a fazer a inferência localmente. Nada de chave de API, nada de custo por token, nada de dado saindo da máquina.

Para quem constrói software de IA no Brasil, onde a conta de API em dólar pesa e a latência para servidores nos EUA é real, essa é uma peça que muda o cálculo de arquitetura de certos produtos.

O que exatamente ele faz

WebLLM traz a inferência para o cliente usando WebGPU para acelerar as operações do modelo. Todo o processamento acontece no browser, o que significa privacidade por construção (os prompts não trafegam) e funcionamento offline depois que o modelo é baixado.

A lista de famílias suportadas nativamente inclui:

O projeto é um companheiro do MLC LLM, e aceita modelos customizados em formato MLC, bastando apontar as URLs dos artefatos (model) e da biblioteca WebAssembly (model_lib).

O detalhe que mais importa: compatibilidade com a API da OpenAI

O ponto que mais reduz atrito para o dev é que o WebLLM é totalmente compatível com a API da OpenAI. Streaming, JSON-mode, seeding para reprodutibilidade e function-calling (ainda em desenvolvimento) estão na mesma interface que você já conhece. Na prática, o código de chamada muda pouco:

import { CreateMLCEngine } from "@mlc-ai/web-llm";

const selectedModel = "Llama-3.1-8B-Instruct-q4f32_1-MLC";
const engine = await CreateMLCEngine(selectedModel, {
  initProgressCallback: (p) => console.log(p),
});

const reply = await engine.chat.completions.create({
  messages: [
    { role: "system", content: "You are a helpful AI assistant." },
    { role: "user", content: "Hello!" },
  ],
});
console.log(reply.choices[0].message);

Uma pegadinha importante: o parâmetro model do create() é ignorado. A troca de modelo acontece no CreateMLCEngine(model) ou em engine.reload(model), não na chamada de completion. Para streaming, basta passar stream: true e iterar sobre o AsyncGenerator retornado.

A instalação segue o fluxo de sempre, com npm/yarn/pnpm ou direto via CDN com import * as webllm from "https://esm.run/@mlc-ai/web-llm", o que permite prototipar em CodePen ou JSFiddle sem build.

Não travar a UI e não rebaixar o modelo a cada visita

Rodar um LLM na thread principal congelaria a interface. Por isso o WebLLM oferece suporte a Web Worker (CreateWebWorkerMLCEngine) para jogar o cálculo pesado em outra thread, e a Service Worker (CreateServiceWorkerMLCEngine) para evitar recarregar o modelo a cada visita e melhorar a experiência offline. A documentação alerta que o ciclo de vida do service worker é gerenciado pelo navegador e pode ser encerrado a qualquer momento, então a aplicação precisa de tratamento de erro próprio, com heartbeat para manter a thread viva.

Há também suporte a extensões do Chrome, com exemplos de extensão persistente usando service worker.

Cache, integridade e o primeiro carregamento

O ponto de atenção prático é o primeiro download: carregar o modelo leva um tempo considerável na primeira execução sem cache, por isso o initProgressCallback existe para você mostrar progresso ao usuário. Depois disso, o WebLLM guarda os pesos localmente através de quatro backends de cache configuráveis em AppConfig.cacheBackend: a Cache API do navegador (padrão), IndexedDB, OPFS (Origin Private File System) e um experimental cross-origin que depende de extensão do Chrome.

Para quem se preocupa com segurança da cadeia de artefatos, o projeto adicionou verificação de integridade opcional via hashes SRI (Subresource Integrity). Com o campo integrity num ModelRecord, o WebLLM confere config, WASM e tokenizer contra os hashes antes de carregar, lançando IntegrityError em caso de divergência (ou apenas logando, se onFailure: "warn"). Os hashes se geram com openssl:

openssl dgst -sha256 -binary <file> | openssl base64 -A | sed 's/^/sha256-/'

O gargalo real: hardware do usuário

A discussão no thread do Hacker News girou em torno da pergunta óbvia: quem tem hardware para isso? O comentário de brucethemoose2 provocou apontando o preço, ao ler que "the latest MacBook Pro can have more than 60G+ unified GPU RAM", ele respondeu: "...for $3.5K minimum, according to the Apple website :/".

Um dos mantenedores, junrushao1994, veio esclarecer o requisito real:

To clarify, running this WebLLM demo doesn't need a 3.5k MacBook Pro which costs $3.5k :-) WebGPU supports multiple backends, besides Metal on Apple Silicon, it offloads to Vulkan, DirectX, etc. (...) Our model is int4 quantized, and it is 4G in size, so it doesn't need 64GB memory either. Somewhere around 6G should suffice.

junrushao1994

Outros relatos confirmaram que a coisa roda em máquinas modestas: hongkonger contou que "both Web LLM and Web Stable Diffusion demos work on my Intel i3-1115G4 laptop with only 5.9GB of shared GPU memory". Ainda assim, o modelo quantizado em int4 na casa dos 4 GB significa download pesado para a realidade de conexão brasileira, algo a pesar antes de assumir que todo usuário terá boa experiência.

Outra observação técnica veio de bhouston, que lembrou que a WebNN API (padrão W3C voltado a redes neurais, mais eficiente em energia que WebGPU) está a caminho, mas demora tanto que o ecossistema acaba "misusing graphics APIs to do NN again". Ou seja: WebGPU é a ponte disponível hoje, não necessariamente a arquitetura final.

O que muda para quem constrói

O WebLLM abre um caminho concreto para funcionalidades de IA que não precisam de fronteira, autocomplete, classificação, sumarização, chat de suporte, extração de JSON estruturado, sem enviar um token para servidor nem pagar por chamada. Para produtos com forte requisito de privacidade (saúde, jurídico) ou para reduzir custo operacional de recursos secundários, é uma alternativa real. O trade-off fica claro: você troca a conta de API pela exigência de WebGPU e por um download inicial gordo. Não substitui o GPT-4 para tarefas pesadas, mas para o miolo de muitos apps, roda no navegador que o seu usuário já tem aberto.

Fontes: Hacker News · Reações no Hacker News