{ "@context": "https://schema.org", "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-02-09-transformers-js-v4-now-available-on-npm/#webpage", "@type": [ "WebPage", "ArchiveComponent" ], "articleBody": "![Overview](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/thumbnail-wide.png)\n\nWe're excited to announce that Transformers.js v4 is now available on NPM! After a year of development (we started in March 2025 🤯), we're finally ready for you to use it.\n\n```sh\nnpm i @huggingface/transformers\n```\n\n## Performance & Runtime Improvements\n\nThe biggest change is undoubtedly the adoption of a new WebGPU Runtime, completely rewritten in C++. We've worked closely with the ONNX Runtime team to thoroughly test this runtime across our ~200 supported model architectures, as well as many new v4-exclusive architectures.\n\nIn addition to better operator support (for performance, accuracy, and coverage), this new WebGPU runtime allows the same transformers.js code to be used across a wide variety of JavaScript environments, including browsers, server-side runtimes, and desktop applications. That's right, you can now run WebGPU-accelerated models directly in Node, Bun, and Deno!\n\n![WebGPU Overview](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/webgpu.png)\n\nWe've proven that it's possible to run state-of-the-art AI models 100% locally in the browser, and now we're focused on performance: making these models run as fast as possible, even in resource-constrained environments. This required completely rethinking our export strategy, especially for large language models. We achieve this by re-implementing new models operation by operation, leveraging specialized ONNX Runtime [Contrib Operators](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md) like [com.microsoft.GroupQueryAttention](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.GroupQueryAttention), [com.microsoft.MatMulNBits](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.MatMulNBits), or [com.microsoft.QMoE](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.QMoE) to maximize performance.\n\nFor example, adopting the [com.microsoft.MultiHeadAttention](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.MultiHeadAttention) operator, we were able to achieve a ~4x speedup for BERT-based embedding models.\n\n![Optimized ONNX Exports](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/speedups.png)\n\n## Repository Restructuring\n\nDeveloping a new major version gave us the opportunity to invest in the codebase and tackle long-overdue refactoring efforts.\n\n### PNPM Workspaces\n\nUntil now, the GitHub repository served as our npm package. This worked well as long as the repository only exposed a single library. However, looking to the future, we saw the need for various sub-packages that depend heavily on the Transformers.js core while addressing different use cases, like library-specific implementations, or smaller utilities that most users don't need but are essential for some.\n\nThat's why we converted the repository to a monorepo using pnpm workspaces. This allows us to ship smaller packages that depend on `@huggingface/transformers` without the overhead of maintaining separate repositories.\n\n### Modular Class Structure\n\nAnother major refactoring effort targeted the ever-growing models.js file. In v3, all available models were defined in a single file spanning over 8,000 lines, becoming increasingly difficult to maintain. For v4, we split this into smaller, focused modules with a clear distinction between utility functions, core logic, and model-specific implementations. This new structure improves readability and makes it much easier to add new models. Developers can now focus on model-specific logic without navigating through thousands of lines of unrelated code.\n\n### Examples Repository\n\nIn v3, many Transformers.js example projects lived directly in the main repository. For v4, we've moved them to a [dedicated repository](https://github.com/huggingface/transformers.js-examples), allowing us to maintain a cleaner codebase focused on the core library. This also makes it easier for users to find and contribute to examples without sifting through the main repository.\n\n### Prettier\n\nWe updated the Prettier configuration and reformatted all files in the repository. This ensures consistent formatting throughout the codebase, with all future PRs automatically following the same style. No more debates about formatting... Prettier handles it all, keeping the code clean and readable for everyone.\n\n## New Models and Architectures\n\nThanks to our new export strategy and ONNX Runtime's expanding support for custom operators, we've been able to add many new models and architectures to Transformers.js v4. These include popular models like GPT-OSS, Chatterbox, GraniteMoeHybrid, LFM2-MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1, and Youtu-LLM. Many of these required us to implement support for advanced architectural patterns, including Mamba (state-space models), Multi-head Latent Attention (MLA), and Mixture of Experts (MoE). Perhaps most importantly, these models are all compatible with WebGPU, allowing users to run them directly in the browser or server-side JavaScript environments with hardware acceleration. We've released several [Transformers.js v4 demos](https://huggingface.co/collections/webml-community/transformersjs-v4-demos) so far... and we'll continue to release more!\n\n## New Build System\n\nWe've migrated our build system from Webpack to esbuild, and the results have been incredible. Build times dropped from 2 seconds to just 200 milliseconds, a 10x improvement that makes development iteration significantly faster. Speed isn't the only benefit, though: bundle sizes also decreased by an average of 10% across all builds. The most notable improvement is in transformers.web.js, our default export, which is now 53% smaller, meaning faster downloads and quicker startup times for users.\n\n## New Library Features\n\nVersion 4 also adds new library features that make it easier to build robust, production-ready applications.\n\n### ModelRegistry\n\nThe new `ModelRegistry` API is designed for production workflows. It provides explicit visibility into pipeline assets before loading anything: list required files with `get_pipeline_files`, inspect per-file metadata with `get_file_metadata` (quite useful to calculate total download size), check cache status with `is_pipeline_cached`, and clear cached artifacts with `clear_pipeline_cache`. You can also query available precision types for a model with `get_available_dtypes`. Based on this new API, `progress_callback` now includes a `progress_total` event, making it easy to render end-to-end loading progress without manually aggregating per-file updates.\n\nSee \\`ModelRegistry\\` examples\n\n```javascript\nimport { ModelRegistry, pipeline } from \"@huggingface/transformers\";\n\nconst modelId = \"onnx-community/all-MiniLM-L6-v2-ONNX\";\nconst modelOptions = { dtype: \"fp32\" };\n\nconst files = await ModelRegistry.get_pipeline_files(\n \"feature-extraction\",\n modelId,\n modelOptions\n);\n// ['config.json', 'onnx/model.onnx', ..., 'tokenizer_config.json']\n\nconst metadata = await Promise.all(\n files.map(file => ModelRegistry.get_file_metadata(modelId, file))\n);\n\nconst downloadSize = metadata.reduce((total, item) => total + item.size, 0);\n\nconst cached = await ModelRegistry.is_pipeline_cached(\n \"feature-extraction\",\n modelId,\n modelOptions\n);\n\nconst dtypes = await ModelRegistry.get_available_dtypes(modelId);\n// ['fp32', 'fp16', 'q4', 'q4f16']\n\nif (cached) {\n await ModelRegistry.clear_pipeline_cache(\n \"feature-extraction\",\n modelId,\n modelOptions\n );\n}\n\nconst pipe = await pipeline(\n \"feature-extraction\",\n modelId,\n {\n progress_callback: e => {\n if (e.status === \"progress_total\") {\n console.log(`${Math.round(e.progress)}%`);\n }\n },\n }\n);\n```\n\n### New Environment Settings\n\nWe also added new environment controls for model loading. `env.useWasmCache` enables caching of WASM runtime files (when cache storage is available), allowing applications to work fully offline after the initial load.\n\n`env.fetch` lets you provide a custom fetch implementation for use cases such as authenticated model access, custom headers, and abortable requests.\n\nSee env examples\n\n```javascript\nimport { env } from \"@huggingface/transformers\";\n\nenv.useWasmCache = true;\n\nenv.fetch = (url, options) =>\n fetch(url, {\n ...options,\n headers: {\n ...options?.headers,\n Authorization: `Bearer ${MY_TOKEN}`,\n },\n });\n```\n\n### Improved Logging Controls\n\nFinally, logging is easier to manage in real-world deployments. ONNX Runtime WebGPU warnings are now hidden by default, and you can set explicit verbosity levels for both Transformers.js and ONNX Runtime. This update, also driven by community feedback, keeps console output focused on actionable signals rather than low-value noise.\n\nSee \\`logLevel\\` example\n\n```javascript\nimport { env, LogLevel } from \"@huggingface/transformers\";\n\n// LogLevel.DEBUG\n// LogLevel.INFO\n// LogLevel.WARNING\n// LogLevel.ERROR\n// LogLevel.NONE\n\nenv.logLevel = LogLevel.WARNING;\n```\n\n## Standalone Tokenizers.js Library\n\nA frequent request from users was to extract the tokenization logic into a separate library, and with v4, that's exactly what we've done. [@huggingface/tokenizers](https://www.npmjs.com/package/@huggingface/tokenizers) is a complete refactor of the tokenization logic, designed to work seamlessly across browsers and server-side runtimes. At just 8.8kB (gzipped) with zero dependencies, it's incredibly lightweight while remaining fully type-safe.\n\nSee example code\n\n```javascript\nimport { Tokenizer } from \"@huggingface/tokenizers\";\n\n// Load from Hugging Face Hub\nconst modelId = \"HuggingFaceTB/SmolLM3-3B\";\nconst tokenizerJson = await fetch(\n `https://huggingface.co/${modelId}/resolve/main/tokenizer.json`\n).then(res => res.json());\n\nconst tokenizerConfig = await fetch(\n `https://huggingface.co/${modelId}/resolve/main/tokenizer_config.json`\n).then(res => res.json());\n\n// Create tokenizer\nconst tokenizer = new Tokenizer(tokenizerJson, tokenizerConfig);\n\n// Tokenize text\nconst tokens = tokenizer.tokenize(\"Hello World\");\n// ['Hello', 'ĠWorld']\n\nconst encoded = tokenizer.encode(\"Hello World\");\n// { ids: [9906, 4435], tokens: ['Hello', 'ĠWorld'], ... }\n```\n\nThis separation keeps the core of Transformers.js focused and lean while offering a versatile, standalone tool that any WebML project can use independently.\n\n## Miscellaneous Improvements\n\nWe've made several quality-of-life improvements across the library. The type system has been enhanced with dynamic pipeline types that adapt based on inputs, providing better developer experience and type safety.\n\n![Type Improvements](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/types.png)\n\nAdditionally, we've added support for larger models exceeding 8B parameters. In our tests, we've been able to run GPT-OSS 20B (q4f16) at ~60 tokens per second on an M4 Pro Max.\n\n## Acknowledgements\n\nWe want to extend our heartfelt thanks to everyone who contributed to this major release, especially the ONNX Runtime team for their incredible work on the new WebGPU runtime and their support throughout development, as well as all external contributors and early testers.\n", "authors": [], "captured_at": "2026-10-04T12:50:30.804479567+00:00", "category": "ai", "content_html": "

\"Overview\"

\n

We're excited to announce that Transformers.js v4 is now available on NPM! After a year of development (we started in March 2025 🤯), we're finally ready for you to use it.

\n
npm i @huggingface/transformers\n
\n

Performance & Runtime Improvements

\n

The biggest change is undoubtedly the adoption of a new WebGPU Runtime, completely rewritten in C++. We've worked closely with the ONNX Runtime team to thoroughly test this runtime across our ~200 supported model architectures, as well as many new v4-exclusive architectures.

\n

In addition to better operator support (for performance, accuracy, and coverage), this new WebGPU runtime allows the same transformers.js code to be used across a wide variety of JavaScript environments, including browsers, server-side runtimes, and desktop applications. That's right, you can now run WebGPU-accelerated models directly in Node, Bun, and Deno!

\n

\"WebGPU

\n

We've proven that it's possible to run state-of-the-art AI models 100% locally in the browser, and now we're focused on performance: making these models run as fast as possible, even in resource-constrained environments. This required completely rethinking our export strategy, especially for large language models. We achieve this by re-implementing new models operation by operation, leveraging specialized ONNX Runtime Contrib Operators like com.microsoft.GroupQueryAttention, com.microsoft.MatMulNBits, or com.microsoft.QMoE to maximize performance.

\n

For example, adopting the com.microsoft.MultiHeadAttention operator, we were able to achieve a ~4x speedup for BERT-based embedding models.

\n

\"Optimized

\n

Repository Restructuring

\n

Developing a new major version gave us the opportunity to invest in the codebase and tackle long-overdue refactoring efforts.

\n

PNPM Workspaces

\n

Until now, the GitHub repository served as our npm package. This worked well as long as the repository only exposed a single library. However, looking to the future, we saw the need for various sub-packages that depend heavily on the Transformers.js core while addressing different use cases, like library-specific implementations, or smaller utilities that most users don't need but are essential for some.

\n

That's why we converted the repository to a monorepo using pnpm workspaces. This allows us to ship smaller packages that depend on @huggingface/transformers without the overhead of maintaining separate repositories.

\n

Modular Class Structure

\n

Another major refactoring effort targeted the ever-growing models.js file. In v3, all available models were defined in a single file spanning over 8,000 lines, becoming increasingly difficult to maintain. For v4, we split this into smaller, focused modules with a clear distinction between utility functions, core logic, and model-specific implementations. This new structure improves readability and makes it much easier to add new models. Developers can now focus on model-specific logic without navigating through thousands of lines of unrelated code.

\n

Examples Repository

\n

In v3, many Transformers.js example projects lived directly in the main repository. For v4, we've moved them to a dedicated repository, allowing us to maintain a cleaner codebase focused on the core library. This also makes it easier for users to find and contribute to examples without sifting through the main repository.

\n

Prettier

\n

We updated the Prettier configuration and reformatted all files in the repository. This ensures consistent formatting throughout the codebase, with all future PRs automatically following the same style. No more debates about formatting... Prettier handles it all, keeping the code clean and readable for everyone.

\n

New Models and Architectures

\n

Thanks to our new export strategy and ONNX Runtime's expanding support for custom operators, we've been able to add many new models and architectures to Transformers.js v4. These include popular models like GPT-OSS, Chatterbox, GraniteMoeHybrid, LFM2-MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1, and Youtu-LLM. Many of these required us to implement support for advanced architectural patterns, including Mamba (state-space models), Multi-head Latent Attention (MLA), and Mixture of Experts (MoE). Perhaps most importantly, these models are all compatible with WebGPU, allowing users to run them directly in the browser or server-side JavaScript environments with hardware acceleration. We've released several Transformers.js v4 demos so far... and we'll continue to release more!

\n

New Build System

\n

We've migrated our build system from Webpack to esbuild, and the results have been incredible. Build times dropped from 2 seconds to just 200 milliseconds, a 10x improvement that makes development iteration significantly faster. Speed isn't the only benefit, though: bundle sizes also decreased by an average of 10% across all builds. The most notable improvement is in transformers.web.js, our default export, which is now 53% smaller, meaning faster downloads and quicker startup times for users.

\n

New Library Features

\n

Version 4 also adds new library features that make it easier to build robust, production-ready applications.

\n

ModelRegistry

\n

The new ModelRegistry API is designed for production workflows. It provides explicit visibility into pipeline assets before loading anything: list required files with get_pipeline_files, inspect per-file metadata with get_file_metadata (quite useful to calculate total download size), check cache status with is_pipeline_cached, and clear cached artifacts with clear_pipeline_cache. You can also query available precision types for a model with get_available_dtypes. Based on this new API, progress_callback now includes a progress_total event, making it easy to render end-to-end loading progress without manually aggregating per-file updates.

\n

See `ModelRegistry` examples

\n
import { ModelRegistry, pipeline } from "@huggingface/transformers";\n\nconst modelId = "onnx-community/all-MiniLM-L6-v2-ONNX";\nconst modelOptions = { dtype: "fp32" };\n\nconst files = await ModelRegistry.get_pipeline_files(\n  "feature-extraction",\n  modelId,\n  modelOptions\n);\n// ['config.json', 'onnx/model.onnx', ..., 'tokenizer_config.json']\n\nconst metadata = await Promise.all(\n  files.map(file => ModelRegistry.get_file_metadata(modelId, file))\n);\n\nconst downloadSize = metadata.reduce((total, item) => total + item.size, 0);\n\nconst cached = await ModelRegistry.is_pipeline_cached(\n  "feature-extraction",\n  modelId,\n  modelOptions\n);\n\nconst dtypes = await ModelRegistry.get_available_dtypes(modelId);\n// ['fp32', 'fp16', 'q4', 'q4f16']\n\nif (cached) {\n  await ModelRegistry.clear_pipeline_cache(\n    "feature-extraction",\n    modelId,\n    modelOptions\n  );\n}\n\nconst pipe = await pipeline(\n  "feature-extraction",\n  modelId,\n  {\n    progress_callback: e => {\n      if (e.status === "progress_total") {\n        console.log(`${Math.round(e.progress)}%`);\n      }\n    },\n  }\n);\n
\n

New Environment Settings

\n

We also added new environment controls for model loading. env.useWasmCache enables caching of WASM runtime files (when cache storage is available), allowing applications to work fully offline after the initial load.

\n

env.fetch lets you provide a custom fetch implementation for use cases such as authenticated model access, custom headers, and abortable requests.

\n

See env examples

\n
import { env } from "@huggingface/transformers";\n\nenv.useWasmCache = true;\n\nenv.fetch = (url, options) =>\n  fetch(url, {\n    ...options,\n    headers: {\n      ...options?.headers,\n      Authorization: `Bearer ${MY_TOKEN}`,\n    },\n  });\n
\n

Improved Logging Controls

\n

Finally, logging is easier to manage in real-world deployments. ONNX Runtime WebGPU warnings are now hidden by default, and you can set explicit verbosity levels for both Transformers.js and ONNX Runtime. This update, also driven by community feedback, keeps console output focused on actionable signals rather than low-value noise.

\n

See `logLevel` example

\n
import { env, LogLevel } from "@huggingface/transformers";\n\n// LogLevel.DEBUG\n// LogLevel.INFO\n// LogLevel.WARNING\n// LogLevel.ERROR\n// LogLevel.NONE\n\nenv.logLevel = LogLevel.WARNING;\n
\n

Standalone Tokenizers.js Library

\n

A frequent request from users was to extract the tokenization logic into a separate library, and with v4, that's exactly what we've done. @huggingface/tokenizers is a complete refactor of the tokenization logic, designed to work seamlessly across browsers and server-side runtimes. At just 8.8kB (gzipped) with zero dependencies, it's incredibly lightweight while remaining fully type-safe.

\n

See example code

\n
import { Tokenizer } from "@huggingface/tokenizers";\n\n// Load from Hugging Face Hub\nconst modelId = "HuggingFaceTB/SmolLM3-3B";\nconst tokenizerJson = await fetch(\n  `https://huggingface.co/${modelId}/resolve/main/tokenizer.json`\n).then(res => res.json());\n\nconst tokenizerConfig = await fetch(\n  `https://huggingface.co/${modelId}/resolve/main/tokenizer_config.json`\n).then(res => res.json());\n\n// Create tokenizer\nconst tokenizer = new Tokenizer(tokenizerJson, tokenizerConfig);\n\n// Tokenize text\nconst tokens = tokenizer.tokenize("Hello World");\n// ['Hello', 'Ä World']\n\nconst encoded = tokenizer.encode("Hello World");\n// { ids: [9906, 4435], tokens: ['Hello', 'Ä World'], ... }\n
\n

This separation keeps the core of Transformers.js focused and lean while offering a versatile, standalone tool that any WebML project can use independently.

\n

Miscellaneous Improvements

\n

We've made several quality-of-life improvements across the library. The type system has been enhanced with dynamic pipeline types that adapt based on inputs, providing better developer experience and type safety.

\n

\"Type

\n

Additionally, we've added support for larger models exceeding 8B parameters. In our tests, we've been able to run GPT-OSS 20B (q4f16) at ~60 tokens per second on an M4 Pro Max.

\n

Acknowledgements

\n

We want to extend our heartfelt thanks to everyone who contributed to this major release, especially the ONNX Runtime team for their incredible work on the new WebGPU runtime and their support throughout development, as well as all external contributors and early testers.

\n", "content_markdown": "![Overview](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/thumbnail-wide.png)\n\nWe're excited to announce that Transformers.js v4 is now available on NPM! After a year of development (we started in March 2025 🤯), we're finally ready for you to use it.\n\n```sh\nnpm i @huggingface/transformers\n```\n\n## Performance & Runtime Improvements\n\nThe biggest change is undoubtedly the adoption of a new WebGPU Runtime, completely rewritten in C++. We've worked closely with the ONNX Runtime team to thoroughly test this runtime across our ~200 supported model architectures, as well as many new v4-exclusive architectures.\n\nIn addition to better operator support (for performance, accuracy, and coverage), this new WebGPU runtime allows the same transformers.js code to be used across a wide variety of JavaScript environments, including browsers, server-side runtimes, and desktop applications. That's right, you can now run WebGPU-accelerated models directly in Node, Bun, and Deno!\n\n![WebGPU Overview](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/webgpu.png)\n\nWe've proven that it's possible to run state-of-the-art AI models 100% locally in the browser, and now we're focused on performance: making these models run as fast as possible, even in resource-constrained environments. This required completely rethinking our export strategy, especially for large language models. We achieve this by re-implementing new models operation by operation, leveraging specialized ONNX Runtime [Contrib Operators](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md) like [com.microsoft.GroupQueryAttention](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.GroupQueryAttention), [com.microsoft.MatMulNBits](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.MatMulNBits), or [com.microsoft.QMoE](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.QMoE) to maximize performance.\n\nFor example, adopting the [com.microsoft.MultiHeadAttention](https://github.com/microsoft/onnxruntime/blob/main/docs/ContribOperators.md#com.microsoft.MultiHeadAttention) operator, we were able to achieve a ~4x speedup for BERT-based embedding models.\n\n![Optimized ONNX Exports](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/speedups.png)\n\n## Repository Restructuring\n\nDeveloping a new major version gave us the opportunity to invest in the codebase and tackle long-overdue refactoring efforts.\n\n### PNPM Workspaces\n\nUntil now, the GitHub repository served as our npm package. This worked well as long as the repository only exposed a single library. However, looking to the future, we saw the need for various sub-packages that depend heavily on the Transformers.js core while addressing different use cases, like library-specific implementations, or smaller utilities that most users don't need but are essential for some.\n\nThat's why we converted the repository to a monorepo using pnpm workspaces. This allows us to ship smaller packages that depend on `@huggingface/transformers` without the overhead of maintaining separate repositories.\n\n### Modular Class Structure\n\nAnother major refactoring effort targeted the ever-growing models.js file. In v3, all available models were defined in a single file spanning over 8,000 lines, becoming increasingly difficult to maintain. For v4, we split this into smaller, focused modules with a clear distinction between utility functions, core logic, and model-specific implementations. This new structure improves readability and makes it much easier to add new models. Developers can now focus on model-specific logic without navigating through thousands of lines of unrelated code.\n\n### Examples Repository\n\nIn v3, many Transformers.js example projects lived directly in the main repository. For v4, we've moved them to a [dedicated repository](https://github.com/huggingface/transformers.js-examples), allowing us to maintain a cleaner codebase focused on the core library. This also makes it easier for users to find and contribute to examples without sifting through the main repository.\n\n### Prettier\n\nWe updated the Prettier configuration and reformatted all files in the repository. This ensures consistent formatting throughout the codebase, with all future PRs automatically following the same style. No more debates about formatting... Prettier handles it all, keeping the code clean and readable for everyone.\n\n## New Models and Architectures\n\nThanks to our new export strategy and ONNX Runtime's expanding support for custom operators, we've been able to add many new models and architectures to Transformers.js v4. These include popular models like GPT-OSS, Chatterbox, GraniteMoeHybrid, LFM2-MoE, HunYuanDenseV1, Apertus, Olmo3, FalconH1, and Youtu-LLM. Many of these required us to implement support for advanced architectural patterns, including Mamba (state-space models), Multi-head Latent Attention (MLA), and Mixture of Experts (MoE). Perhaps most importantly, these models are all compatible with WebGPU, allowing users to run them directly in the browser or server-side JavaScript environments with hardware acceleration. We've released several [Transformers.js v4 demos](https://huggingface.co/collections/webml-community/transformersjs-v4-demos) so far... and we'll continue to release more!\n\n## New Build System\n\nWe've migrated our build system from Webpack to esbuild, and the results have been incredible. Build times dropped from 2 seconds to just 200 milliseconds, a 10x improvement that makes development iteration significantly faster. Speed isn't the only benefit, though: bundle sizes also decreased by an average of 10% across all builds. The most notable improvement is in transformers.web.js, our default export, which is now 53% smaller, meaning faster downloads and quicker startup times for users.\n\n## New Library Features\n\nVersion 4 also adds new library features that make it easier to build robust, production-ready applications.\n\n### ModelRegistry\n\nThe new `ModelRegistry` API is designed for production workflows. It provides explicit visibility into pipeline assets before loading anything: list required files with `get_pipeline_files`, inspect per-file metadata with `get_file_metadata` (quite useful to calculate total download size), check cache status with `is_pipeline_cached`, and clear cached artifacts with `clear_pipeline_cache`. You can also query available precision types for a model with `get_available_dtypes`. Based on this new API, `progress_callback` now includes a `progress_total` event, making it easy to render end-to-end loading progress without manually aggregating per-file updates.\n\nSee \\`ModelRegistry\\` examples\n\n```javascript\nimport { ModelRegistry, pipeline } from \"@huggingface/transformers\";\n\nconst modelId = \"onnx-community/all-MiniLM-L6-v2-ONNX\";\nconst modelOptions = { dtype: \"fp32\" };\n\nconst files = await ModelRegistry.get_pipeline_files(\n \"feature-extraction\",\n modelId,\n modelOptions\n);\n// ['config.json', 'onnx/model.onnx', ..., 'tokenizer_config.json']\n\nconst metadata = await Promise.all(\n files.map(file => ModelRegistry.get_file_metadata(modelId, file))\n);\n\nconst downloadSize = metadata.reduce((total, item) => total + item.size, 0);\n\nconst cached = await ModelRegistry.is_pipeline_cached(\n \"feature-extraction\",\n modelId,\n modelOptions\n);\n\nconst dtypes = await ModelRegistry.get_available_dtypes(modelId);\n// ['fp32', 'fp16', 'q4', 'q4f16']\n\nif (cached) {\n await ModelRegistry.clear_pipeline_cache(\n \"feature-extraction\",\n modelId,\n modelOptions\n );\n}\n\nconst pipe = await pipeline(\n \"feature-extraction\",\n modelId,\n {\n progress_callback: e => {\n if (e.status === \"progress_total\") {\n console.log(`${Math.round(e.progress)}%`);\n }\n },\n }\n);\n```\n\n### New Environment Settings\n\nWe also added new environment controls for model loading. `env.useWasmCache` enables caching of WASM runtime files (when cache storage is available), allowing applications to work fully offline after the initial load.\n\n`env.fetch` lets you provide a custom fetch implementation for use cases such as authenticated model access, custom headers, and abortable requests.\n\nSee env examples\n\n```javascript\nimport { env } from \"@huggingface/transformers\";\n\nenv.useWasmCache = true;\n\nenv.fetch = (url, options) =>\n fetch(url, {\n ...options,\n headers: {\n ...options?.headers,\n Authorization: `Bearer ${MY_TOKEN}`,\n },\n });\n```\n\n### Improved Logging Controls\n\nFinally, logging is easier to manage in real-world deployments. ONNX Runtime WebGPU warnings are now hidden by default, and you can set explicit verbosity levels for both Transformers.js and ONNX Runtime. This update, also driven by community feedback, keeps console output focused on actionable signals rather than low-value noise.\n\nSee \\`logLevel\\` example\n\n```javascript\nimport { env, LogLevel } from \"@huggingface/transformers\";\n\n// LogLevel.DEBUG\n// LogLevel.INFO\n// LogLevel.WARNING\n// LogLevel.ERROR\n// LogLevel.NONE\n\nenv.logLevel = LogLevel.WARNING;\n```\n\n## Standalone Tokenizers.js Library\n\nA frequent request from users was to extract the tokenization logic into a separate library, and with v4, that's exactly what we've done. [@huggingface/tokenizers](https://www.npmjs.com/package/@huggingface/tokenizers) is a complete refactor of the tokenization logic, designed to work seamlessly across browsers and server-side runtimes. At just 8.8kB (gzipped) with zero dependencies, it's incredibly lightweight while remaining fully type-safe.\n\nSee example code\n\n```javascript\nimport { Tokenizer } from \"@huggingface/tokenizers\";\n\n// Load from Hugging Face Hub\nconst modelId = \"HuggingFaceTB/SmolLM3-3B\";\nconst tokenizerJson = await fetch(\n `https://huggingface.co/${modelId}/resolve/main/tokenizer.json`\n).then(res => res.json());\n\nconst tokenizerConfig = await fetch(\n `https://huggingface.co/${modelId}/resolve/main/tokenizer_config.json`\n).then(res => res.json());\n\n// Create tokenizer\nconst tokenizer = new Tokenizer(tokenizerJson, tokenizerConfig);\n\n// Tokenize text\nconst tokens = tokenizer.tokenize(\"Hello World\");\n// ['Hello', 'ĠWorld']\n\nconst encoded = tokenizer.encode(\"Hello World\");\n// { ids: [9906, 4435], tokens: ['Hello', 'ĠWorld'], ... }\n```\n\nThis separation keeps the core of Transformers.js focused and lean while offering a versatile, standalone tool that any WebML project can use independently.\n\n## Miscellaneous Improvements\n\nWe've made several quality-of-life improvements across the library. The type system has been enhanced with dynamic pipeline types that adapt based on inputs, providing better developer experience and type safety.\n\n![Type Improvements](https://huggingface.co/datasets/huggingface/documentation-images/resolve/main/transformersjs-v4/types.png)\n\nAdditionally, we've added support for larger models exceeding 8B parameters. In our tests, we've been able to run GPT-OSS 20B (q4f16) at ~60 tokens per second on an M4 Pro Max.\n\n## Acknowledgements\n\nWe want to extend our heartfelt thanks to everyone who contributed to this major release, especially the ONNX Runtime team for their incredible work on the new WebGPU runtime and their support throughout development, as well as all external contributors and early testers.\n", "dateCreated": "2026-10-04T12:50:30.804479567+00:00", "date_created": "2026-02-09T00:00:00+00:00", "date_modified": "2026-02-09T00:00:00+00:00", "date_published": "2026-02-09T00:00:00+00:00", "description": "We're excited to announce that Transformers.js v4 is now available on NPM! After a year of development (we started in March 2025 🤯), we're finally ready for you to use it. npm i @huggingface/transformers Performance & Runtime Improvements…", "external_url": "https://huggingface.co/blog/transformersjs-v4", "git": { "commit": "ebb0941c5c06a2ab2377342d607535262a3e969e", "path": "items/huggingface-co/2026/02/2026-02-09-transformers-js-v4-now-available-on-npm.md", "permalink": "https://github.com/aymericbeaumet/aggr-instance/blob/ebb0941c5c06a2ab2377342d607535262a3e969e/items/huggingface-co/2026/02/2026-02-09-transformers-js-v4-now-available-on-npm.md" }, "id": "urn:aggr:item:486a8a433d9cdd242a06c6e2a2cb439d014712a1", "isBasedOn": { "@id": "https://huggingface.co/blog/transformersjs-v4" }, "mainEntity": { "@id": "https://huggingface.co/blog/transformersjs-v4", "@type": "CreativeWork", "archivedAt": { "@id": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-02-09-transformers-js-v4-now-available-on-npm/#webpage" }, "dateModified": "2026-02-09T00:00:00+00:00", "datePublished": "2026-02-09T00:00:00+00:00", "headline": "Transformers.js v4: Now Available on NPM!", "timeRequired": "PT6M", "url": "https://huggingface.co/blog/transformersjs-v4", "wordCount": 1340 }, "name": "Archived snapshot: Transformers.js v4: Now Available on NPM!", "preview": null, "reading_minutes": 6, "replicated_at": null, "source": "huggingface-co", "source_name": "Hugging Face - Blog", "summary": null, "tags": [], "temporalCoverage": "2026-10-04T12:50:30.804479567+00:00", "title": "Transformers.js v4: Now Available on NPM!", "url": "https://aggr.aymericbeaumet.com/items/huggingface-co/2026-02-09-transformers-js-v4-now-available-on-npm/", "word_count": 1340 }