Se você curte a ideia de rodar modelos de IA 100% local (sem depender de API paga e sem enviar dados sensíveis pra terceiros), o Transformers.js v4 (preview) ficou bem mais interessante: ele ganhou um runtime WebGPU reescrito em C++ e agora o mesmo código pode rodar com aceleração no browser e também em runtimes como Node/Bun/Deno.
Fonte principal (leitura obrigatória): Hugging Face Blog — Transformers.js v4 Preview: Now Available on NPM
1) Instalação (v4 preview no NPM)
O v4 ainda está sendo publicado sob a tag next. Para testar agora:
npm i @huggingface/transformers@next
Dica prática: crie um projeto separado só para testes do v4. Como é preview, as mudanças podem quebrar exemplos antigos do v3.
2) O pulo do gato: WebGPU também fora do navegador
A mudança mais relevante do v4 é a adoção de um novo runtime WebGPU (reescrito em C++), testado com ~200 arquiteturas suportadas. Na prática, isso abre caminho para rodar modelos com aceleração:
- No browser (o clássico) — ideal para demos e apps que precisam de privacidade por padrão.
- No Node/Bun/Deno — útil para automações, CLIs e micro-serviços que você quer manter offline/local.
Insight aplicável #1: se você faz automações (relatórios, categorização, resumo, embeddings), dá para experimentar um fluxo híbrido: inferência local quando há GPU/cliente compatível e fallback para WASM quando não houver.
3) Performance de verdade: operadores do ONNX Runtime
Para ganhar velocidade (e ampliar suporte), o projeto passou a aproveitar Contrib Operators do ONNX Runtime, como com.microsoft.MultiHeadAttention, GroupQueryAttention, MatMulNBits e QMoE.
O próprio post cita um exemplo concreto: ao adotar MultiHeadAttention, eles viram ~4× de speedup em modelos de embeddings baseados em BERT.
Insight aplicável #2: para casos de uso “real” (busca semântica, recomendação, clustering), comece testando embeddings. É onde a melhoria de performance costuma se traduzir mais rápido em UX (latência menor) e custo (menos infraestrutura).
4) Tokenização separada: @huggingface/tokenizers
Outra mudança excelente do v4: a tokenização virou uma lib independente. O pacote @huggingface/tokenizers é leve (o post menciona ~8,8kB gzipped) e com zero dependências. Um exemplo (adaptado do artigo):
import { Tokenizer } from "@huggingface/tokenizers";
const modelId = "HuggingFaceTB/SmolLM3-3B";
const tokenizerJson = await fetch(
`https://huggingface.co/${modelId}/resolve/main/tokenizer.json`
).then(r => r.json());
const tokenizerConfig = await fetch(
`https://huggingface.co/${modelId}/resolve/main/tokenizer_config.json`
).then(r => r.json());
const tok = new Tokenizer(tokenizerJson, tokenizerConfig);
console.log(tok.tokenize("Hello World"));
console.log(tok.encode("Hello World"));
Insight aplicável #3: se o seu gargalo é “pré-processamento”, separar tokenização do resto ajuda a modularizar: dá para tokenizar em um worker (browser) ou pré-processar no backend e mandar apenas IDs para o cliente.
5) Um checklist rápido para aplicar hoje
- Escolha 1 tarefa: embeddings para busca interna, classificação de tickets, ou resumo curto.
- Teste 2 runtimes: WebGPU (se disponível) vs WASM (fallback) e compare latência.
- Meça antes de “otimizar”: tempo de download do modelo, tempo de warm-up e tempo por requisição.
- Planeje offline: o v4 menciona cache de WASM para uso offline após o primeiro download — ótimo para apps que rodam em campo/sem internet.
Pergunta: você usaria IA local no navegador/desktop para qual tarefa primeiro: embeddings, classificação ou chat?
![FRI – Ficando Rico Com [IA]](https://ficandoricocomia.com/wp-content/uploads/2025/10/cropped-fri2.png)
Deixe um comentário