A IA local no navegador com WebLLM elimina a chamada de inferência por requisição, mas exige download único dos pesos, memória suficiente e WebGPU compatível. O visitante assume o processamento; você assume a entrega dos arquivos. Decida tarefa por tarefa, com testes reais em dispositivos reais.
O que é WebLLM e o que a IA local no navegador resolve
A WebLLM é a biblioteca do projeto MLC que executa modelos de linguagem dentro do navegador via WebGPU, eliminando a chamada a um provedor de inferência. O ganho é concreto: requisições que rodam localmente não geram cobrança por token de entrada ou saída.
O projeto faz parte do ecossistema MLC, ligado ao desenvolvimento de compiladores de modelos para hardware heterogêneo. A biblioteca cuida da coordenação; o espaço de execução dos cálculos fica com o navegador.
O que a IA local no navegador não resolve: hospedagem do site, entrega dos arquivos do modelo e o trabalho da máquina do visitante. O visitante precisa baixar os pesos, mantê-los em memória e gastar bateria. Você continua pagando banda pela entrega.
Em resumo, o custo de inferência sai da sua fatura e entra no dispositivo de quem usa o recurso. Essa transferência é a decisão de arquitetura, não um detalhe de implementação.
Por que o primeiro carregamento é o custo real
O primeiro carregamento é o gargalo: antes de responder qualquer coisa, o navegador precisa baixar os pesos do modelo, a biblioteca compilada, o tokenizer e a configuração. Na configuração padrão do projeto, os arquivos de modelo vêm do Hugging Face e as bibliotecas compiladas têm URLs próprias.
A documentação do WebLLM avisa que o carregamento inicial pode levar um tempo considerável. Mostre progresso na interface, ou o usuário vai achar que o botão quebrou.
Por padrão, os ativos são armazenados no Cache API do navegador, que é armazenamento gerenciado no próprio dispositivo. Em visitas seguintes, os arquivos podem ser reaproveitados em vez de baixados de novo.
Cache não significa pronto para executar. O runtime ainda precisa abrir os pesos e montar o estado de trabalho na memória — a estante e a mesa são recursos diferentes, com limites diferentes.
Como o WebGPU executa o modelo no dispositivo
Três peças fazem a geração acontecer: os pesos guardam os parâmetros aprendidos, o WebLLM coordena o runtime de inferência e o WebGPU dá acesso à GPU do dispositivo para o trabalho numérico. O WebGPU é a API do navegador para computação em GPU, e o WebAssembly cobre o trabalho de CPU dentro do runtime.
A primeira etapa processa a instrução e o texto selecionado como tokens, chunks de texto que o modelo manipula. Esse processamento inicial prepara o estado que o modelo usa para começar a gerar.
Depois, o runtime produz um token por vez, acrescenta à resposta e continua a partir do estado atualizado. O texto aparece no editor conforme os pedaços retornam, até uma condição de parada ou o limite de saída.
Os pesos permanecem disponíveis durante todo o processo. O navegador não baixa o modelo de novo a cada palavra — ele reaplica os mesmos parâmetros aprendidos a uma entrada e a uma resposta crescente.
Web Worker mantém a interface responsiva
O WebLLM suporta executar o engine em um Web Worker, thread separada dentro do navegador. A interface envia a requisição, o worker gerencia a geração e mensagens devolvem a saída para a página, o que evita travar rolagem e digitação.
A separação melhora a responsividade, mas não cria uma GPU extra nem reduz a memória necessária. Dá para oferecer um botão de cancelar durante a geração; o computador ainda tem um trabalho real a terminar ou interromper.
Vale lembrar que o trabalho pesado concorre com o restante do que o usuário faz na máquina.
Quantização: o que 16 bits versus 4 bits custa
Quantização reduz os bits usados por parâmetro, e a conta é direta: um modelo ilustrativo de 1 bilhão de parâmetros ocupa cerca de 2 GB de pesos brutos em 16 bits e cerca de 500 MB em 4 bits. É aritmética de armazenamento, antes de metadados e memória de runtime.
O requisito real de memória inclui buffers de trabalho e o estado usado ao processar o prompt e gerar texto. Em modelos de atenção, contexto maior tende a aumentar esse estado. Ou seja: um download que cabe no disco ainda pode falhar na alocação de memória.
A precisão menor também pode afetar a qualidade. O arquivo menor não garante que uma frase como "podemos lançar na sexta, se os testes passarem" continue preservando a incerteza e a condição.
Reexecute os testes da tarefa sempre que mudar a precisão do modelo. Economizar memória tornando o recurso menos útil é uma forma caríssima de economizar.
Quem paga a conta: tabela de trade-offs
A decisão entre inferência local e na nuvem envolve dimensões diferentes de custo, capacidade e privacidade. A tabela abaixo resume o que muda em cada rota.
| Dimensão | Inferência local (WebLLM) | Inferência na nuvem |
|---|---|---|
| Custo por requisição | Sem cobrança de provedor | Cobrança por token de entrada e saída |
| Custo de entrega | Banda de hospedagem dos pesos | Banda da API, menor por chamada |
| Primeiro uso | Download e preparo do modelo | Pronto após a chamada de rede |
| Memória | Buffers e estado na máquina do visitante | No servidor do provedor |
| Compatibilidade | Exige WebGPU e contexto seguro | Qualquer navegador com rede |
| Privacidade | Processamento local, mas rotas do app importam | Texto sai do dispositivo |
O visitante paga em memória, tempo de processamento e energia. Isso pode significar consumo de bateria competindo com outras tarefas. Meça esses custos em dispositivos representativos, com o modelo que você pretende entregar.
Do seu lado, entregar um arquivo grande tem custo de banda sob o arranjo de hospedagem escolhido, e atualizações de modelo podem exigir novo download. Se o visitante só precisa de uma reescrita curta, o custo de preparação pode ser uma troca ruim.
Privacidade no navegador não é automática
O engine de inferência pode processar a seleção localmente, mas analytics, relatórios de erro, salvamento de documentos ou um fallback na nuvem ainda podem enviar texto para fora. Sem inspecionar essas rotas, não dá para afirmar que o texto do usuário fica no dispositivo.
A inspeção de rede precisa cobrir o carregamento, a geração e o que acontece depois. Uma resposta funcionando offline mostra que aquela geração não precisou de rede; não prova que o app nunca envia nada quando a conectividade volta.
Mantenha a promessa de privacidade tão estreita quanto a evidência coletada. Execução local, filtro por lista de permissões e ausência de serviço gerenciado obrigatório ajudam a montar uma arquitetura isolada, mas não comprovam conformidade regulatória nem adequação a setores regulados por si só.
Para testar a geração offline, carregue o app e o modelo, desconecte a rede e envie uma reescrita nova. Mantenha o original e a nova resposta visíveis — uma resposta antiga em uma janela de chat não provaria nada.
Como decidir entre local, nuvem e híbrido
Local faz sentido quando o modelo escolhido passa nos testes da tarefa, o dispositivo executa com folga e o uso repetido justifica o download. Nuvem faz sentido quando a capacidade necessária ou o suporte de dispositivos não existe no parque instalado.
Um caminho híbrido pode oferecer as duas rotas de forma explícita. Se o carregamento local falhar, ofereça a opção de servidor e explique que ela envia a seleção para fora do dispositivo. Deixe o usuário escolher antes de o texto sair.
Para avaliar a funcionalidade, separe a primeira visita da visita de retorno:
- Na primeira visita, registre o download e o tempo até o assistente ficar pronto.
- Na visita de retorno, verifique o que foi reaproveitado do cache.
- Meça a espera até a primeira saída visível e o tempo até uma reescrita completa e útil.
- Avalie a qualidade junto com o tempo e mantenha as falhas de carregamento nos resultados.
- Dê às tarefas não suportadas um desfecho claro e preserve o texto selecionado se a inicialização falhar.
Comece por uma tarefa limitada, teste as respostas e os custos por dispositivo, e só então decida onde esse trabalho pertence. Se o usuário precisa de formato fixo de resposta, o WebLLM suporta saída estruturada, mas um formato válido não garante que a classificação esteja correta.
Perguntas frequentes
- WebLLM é gratuito para usar em produção?
A biblioteca é aberta e não cobra por inferência, mas a gratuidade não é total. Você paga hospedagem e banda pelos arquivos do modelo, e o visitante paga em download, memória e bateria. Meça esses custos antes de tratar a adoção como economia garantida.
- A WebLLM funciona em qualquer navegador ou dispositivo?
Não. Ela depende de WebGPU, que exige navegador e dispositivo compatíveis, e páginas em produção precisam de contexto seguro, normalmente HTTPS. Detectar a API é só o começo: o pedido por um adaptador de GPU utilizável ainda pode falhar.
- Posso dizer que o texto do usuário nunca sai do dispositivo?
Só depois de inspecionar toda a aplicação. Analytics, relatórios de erro, salvamento remoto ou um fallback na nuvem ainda enviam texto para fora. A inferência local cobre a geração, não as outras rotas de dados do seu app.
- Por que o modelo "cached" ainda demora para responder?
Porque cache é armazenamento, não memória de trabalho. O runtime ainda precisa abrir os pesos e montar o estado de execução, além de alocar buffers. O navegador também pode limpar dados do site ou remover entradas armazenadas quando o espaço aperta.
- Vale a pena para uma única reescrita de texto curto?
Provavelmente não. O custo de preparação do modelo só se dilui com uso repetido. Para uma requisição isolada, a nuvem costuma ser mais barata em tempo e experiência; o cálculo muda quando a mesma tarefa roda muitas vezes.