Als je met AI werkt in je webshop, marketingstack of interne tooling, dan wil je vooral drie dingen: voorspelbaarheid, snelheid en controle over je data. Transformers.js v4 (preview) is geen ‘leuke update’, maar een stap die lokaal draaien van modellen in JavaScript een stuk volwassener maakt. En het fijne is: je hoeft het niet meer vanaf GitHub te bouwen. Je installeert het nu gewoon via NPM, test het rustig uit, en kijkt of het past bij jouw use case.
Wat er precies is aangekondigd
Transformers.js v4 (preview) is nu beschikbaar op NPM. Dat klinkt als een detail, maar in de praktijk scheelt het veel gedoe in teams en projecten. Waar je eerder v4 uit de broncode moest halen, is het nu één commando:
npm i @huggingface/transformers@next
De v4 releases blijven voorlopig onder de next tag verschijnen tot de volledige release. Reken dus op regelmatige updates. Mijn advies als je dit in een bedrijf wilt gebruiken: behandel het ook echt als preview. Prima om mee te bouwen en te testen, maar leg je productie afhankelijkheden nog niet vast alsof het v4.0.0 stabiel is.
Performance en runtime verbeteringen (de grote reden waarom dit telt)
De grootste verandering zit onder de motorkap: een nieuwe WebGPU runtime, helemaal opnieuw geschreven in C++. Die is samen met het ONNX Runtime team breed getest, niet op één of twee modellen, maar op ongeveer tweehonderd ondersteunde architecturen, plus een reeks nieuwe die specifiek voor v4 zijn toegevoegd.
Waarom jij daar iets van merkt, ook als je geen ML engineer bent? Omdat WebGPU de deur openzet naar sneller lokaal rekenen, zonder dat je meteen een servercluster hoeft op te tuigen of alles naar een externe API hoeft te sturen. Denk aan snellere embeddings voor zoek en aanbevelingen, realtime classificatie van klantvragen, of personalisatie in de browser zonder dat je iedere klik hoeft te loggen naar een third party.
Een tweede punt dat ik belangrijk vind: dezelfde codebase draait nu in meer JavaScript omgevingen. Niet alleen in de browser, maar ook server side en desktop. Met andere woorden: WebGPU versnelling kan nu ook in Node, Bun en Deno. Dat maakt architectuurkeuzes eenvoudiger. Je kunt een prototype in de browser starten en later delen van die logica server side hergebruiken zonder alles opnieuw te schrijven.
Waarom ze de export strategie hebben moeten herzien
Als je grotere taalmodellen lokaal wilt draaien, loop je snel tegen grenzen aan. Snelheid, geheugen, en vooral het feit dat ‘even exporteren naar ONNX’ niet genoeg is als je echt tempo wilt.
In v4 wordt daarom veel meer per operatie opnieuw geïmplementeerd, met gebruik van ONNX Runtime Contrib Operators die specifiek zijn bedoeld voor dit soort werk. Voorbeelden die genoemd worden zijn com.microsoft.GroupQueryAttention, com.microsoft.MatMulNBits en com.microsoft.QMoE. Dit zijn geen marketingtermen, maar bouwstenen die bepalen of een model praktisch bruikbaar is in een echte app.
Een concreet resultaat: door de com.microsoft.MultiHeadAttention operator te gebruiken is er bij BERT gebaseerde embedding modellen ongeveer vier keer snelheidswinst gehaald. Als je embeddings inzet voor site search, product matching of clustering van klantfeedback, dan is dat het verschil tussen ‘leuk voor een demo’ en ‘werkbaar in een proces’.
Offline gebruik: kleine zin, groot effect in de praktijk
Er is ook gewerkt aan offline ondersteuning. Door WASM bestanden lokaal in de browser te cachen, kan een Transformers.js toepassing na de eerste download zonder internet blijven draaien.
Dat klinkt misschien niche, maar ik heb in de praktijk genoeg situaties gezien waarin je dit wél wilt. Denk aan demo’s op een beurs, interne tools op een afgesloten netwerk, of toepassingen waarbij je niet afhankelijk wilt zijn van een externe verbinding voor iets dat eigenlijk lokaal kan. Minder variabelen betekent minder verrassingen.
Repository herstructurering: minder chaos, meer onderhoudbaarheid
Een nieuwe major versie is vaak het moment waarop teams eindelijk de rommel opruimen. Dat is hier ook gebeurd.
Allereerst is de repository omgezet naar een monorepo met pnpm workspaces. Tot nu toe was de GitHub repository in feite ook het NPM pakket. Zolang je maar één library hebt, werkt dat, maar zodra je subpackages wilt bouwen die dicht tegen de kern aan zitten, wordt het onhandig. Met workspaces kunnen ze kleinere pakketten uitbrengen die leunen op @huggingface/transformers, zonder dat je voor elk onderdeel een aparte repository hoeft te beheren.
Daarnaast is de structuur van de code aangepakt. In v3 zat alle modeldefinitie in één groeiend bestand, models.js, van meer dan achtduizend regels. Dat is niet alleen lastig lezen, het maakt het ook moeilijk om veilig nieuwe modellen toe te voegen. In v4 is dit opgesplitst in kleinere modules, met duidelijker scheiding tussen hulpfuncties, kernlogica en model specifieke implementatie. Voor ontwikkelteams betekent dit minder ‘waar moet ik zijn’ en meer focus op het stuk dat je daadwerkelijk aanpast.
Voorbeelden verplaatst en codeformatting strakgetrokken
Veel voorbeeldprojecten die in v3 in de hoofdrepository stonden, zijn verplaatst naar een aparte examples repository. Dat vind ik een gezonde keuze. Het houdt de kernbibliotheek overzichtelijk en maakt bijdragen aan voorbeelden laagdrempeliger.
Ook is de Prettier configuratie bijgewerkt en is de codebase opnieuw geformatteerd. Dat lijkt een detail, maar het voorkomt eindeloze discussies in PR’s en maakt reviewen sneller. Zeker bij grotere teams scheelt dat irritatie en tijd.
Nieuwe modellen en architecturen: meer dan alleen een langere lijst
Door de aangepaste export aanpak en betere ondersteuning van operators in ONNX Runtime zijn er veel nieuwe modellen en architecturen bijgekomen. Er worden onder andere GPT OSS, Chatterbox, GraniteMoeHybrid, LFM2 MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1 en Youtu LLM genoemd.
Belangrijker dan de namen is wat dit zegt over de onderliggende patronen die nu ondersteund worden. Denk aan Mamba (state space modellen), Multi head Latent Attention (MLA) en Mixture of Experts (MoE). Dat zijn architecturen die je steeds vaker terugziet in moderne modellen, en het feit dat ze WebGPU compatibel zijn, betekent dat je ze lokaal kunt draaien met hardware versnelling, zowel in de browser als in server side JavaScript.
Verwacht dus niet alleen ‘meer keuze’, maar vooral: meer kans dat een model dat jij wilt proberen ook echt netjes draait in jouw omgeving.
Nieuwe build system: sneller bouwen en kleinere bundles
De build pipeline is verhuisd van Webpack naar esbuild. Het effect is heel concreet: buildtijden gingen van ongeveer twee seconden naar tweehonderd milliseconden, een factor tien sneller.
Voor productteams betekent dit minder wachttijd tijdens itereren. En er is nog een tweede winst: bundlegroottes zijn gemiddeld rond tien procent kleiner geworden. De grootste winst zit in transformers.web.js, de standaard export, die nu drieënvijftig procent kleiner is. Dat vertaalt zich naar snellere downloads en een kortere opstarttijd, iets waar je gebruikers uiteindelijk wél iets van merken.
Tokenizers losgetrokken naar een aparte library
Een veelgehoorde wens was om tokenization los aan te bieden. In v4 is dat gedaan met @huggingface/tokenizers: een volledige refactor van de tokenization logica, bedoeld voor zowel browser als server side runtimes.
Wat ik er netjes aan vind: het blijft klein, ongeveer 8,8 kB gzip, zonder dependencies, en toch type safe.
Een voorbeeld zoals zij het laten zien ziet er zo uit:
import { Tokenizer } from "@huggingface/tokenizers";
// Load vanaf Hugging Face Hub
const modelId = "HuggingFaceTB/SmolLM3-3B";
const tokenizerJson = await fetch(
https://huggingface.co/${modelId}/resolve/main/tokenizer.json
).then((res) => res.json());
const tokenizerConfig = await fetch(
https://huggingface.co/${modelId}/resolve/main/tokenizer_config.json
).then((res) => res.json());
// Maak tokenizer
const tokenizer = new Tokenizer(tokenizerJson, tokenizerConfig);
// Tokenize tekst
const tokens = tokenizer.tokenize("Hello World");
// Of encode:
// const encoded = tokenizer.encode("Hello World");
Dit is vooral handig als je alleen tokenization nodig hebt, bijvoorbeeld voor pre processing in een webapp, zonder meteen het hele Transformers.js pakket mee te nemen.
Overige verbeteringen: types, logging en grotere modellen
Naast de grote blokken zijn er ook een paar verbeteringen die je pas waardeert als je ermee werkt. De types zijn aangescherpt, met pipeline types die zich aanpassen op basis van je inputs. Dat helpt om fouten eerder te zien, zeker in TypeScript projecten.
Ook is de logging verbeterd, zodat je meer controle hebt en beter snapt wat er tijdens uitvoering gebeurt.
En er is ondersteuning toegevoegd voor grotere modellen boven de 8 miljard parameters. In hun tests draait GPT OSS 20B (q4f16) rond zestig tokens per seconde op een M4 Pro Max. Dat is een specifiek voorbeeld, maar het laat zien dat ze de focus niet alleen op kleine modellen hebben gelegd.
Wat ik je zou aanraden als je dit in een bedrijf wilt inzetten
Als je in Nederland een marketing of e commerce team runt, is de verleiding groot om direct te springen op nieuwe AI tooling. Ik snap dat, want de druk op snelheid en kosten is hoog. Tegelijk wil je jezelf beschermen tegen onnodige omwegen.
Zie v4 daarom als iets om gecontroleerd te testen. Kies één concrete use case, bijvoorbeeld betere interne zoekresultaten op productdata, topic clustering van reviews, of een lokale assistent voor klantenservice drafts. Meet vervolgens drie dingen: laadtijd, latency tijdens gebruik, en beheerkosten in je eigen stack. Als dat klopt, kun je stap voor stap uitbreiden.
Het mooie van deze richting is dat lokaal draaien je meer grip geeft op privacy en afhankelijkheden. En dat is meestal precies wat je wilt als je op schaal gaat werken.
Dankwoord (terecht, want dit soort werk is zwaar)
Tot slot geven de makers expliciet krediet aan iedereen die heeft bijgedragen, met een extra dank aan het ONNX Runtime team voor hun werk aan de nieuwe WebGPU runtime en de ondersteuning tijdens de ontwikkeling. Ook externe contributors en vroege testers worden genoemd.
Dat soort samenwerking is vaak het verschil tussen een bibliotheek die in theorie veel kan en één die in de praktijk stabiel genoeg wordt om op te bouwen.