v4.0.0 기준
Transformers.js v4,
WebGPU가 항상 빠를까요?
2026년 2월 9일, Hugging Face가 약 1년간의 개발 끝에 Transformers.js v4를 정식 출시했습니다. WebGPU 런타임을 C++로 완전히 재작성하고, 20B 파라미터 모델을 브라우저에서 돌리는 데모까지 공개했죠. 그런데 막상 수치를 뜯어보면, “WebGPU = 빠름”이라는 공식이 무조건 성립하지 않습니다. 어떤 상황에서 WASM이 WebGPU를 이기는지, 숫자로 직접 따져봤습니다.
v4에서 진짜 달라진 것 — C++ 재작성이 왜 중요한가
Transformers.js v4의 핵심은 WebGPU 런타임을 C++로 완전히 재작성한 것입니다. v3까지는 JavaScript 기반 ONNX Runtime Web 위에서 WebGPU를 사용했는데, v4에서는 Microsoft ONNX Runtime 팀과 직접 협업해 C++ 네이티브 WebGPU 런타임을 도입했습니다. (출처: Hugging Face 공식 블로그, 2026.02.09)
재작성의 실질적인 효과는 두 가지입니다. 첫째, 연산자(Operator) 지원 범위가 크게 넓어졌습니다. 이전에는 지원되지 않는 연산자가 CPU fallback으로 조용히 넘어가는 일이 잦았는데, v4에서는 com.microsoft.GroupQueryAttention, com.microsoft.MatMulNBits 같은 Contrib Operator들을 직접 활용해 모델별로 연산을 최적화합니다. 둘째, 같은 코드가 브라우저·Node·Bun·Deno에서 모두 동작합니다. 런타임 추상화가 한 단계 올라간 셈입니다.
v3와의 가장 큰 체감 차이는 대형 모델 지원입니다. v3에서는 8B 파라미터 이상의 모델을 안정적으로 돌리기 어려웠지만, v4에서는 20B 이상 모델도 공식 지원 목록에 포함됩니다. GPT-OSS, Chatterbox, LFM2-MoE 등 새로운 아키텍처가 이 덕분에 추가됐습니다.
BERT 4배, 번들 53% — 수치로 본 성능 변화
공식 문서에 딱 이렇게 나옵니다. com.microsoft.MultiHeadAttention 연산자를 적용한 결과, BERT 기반 임베딩 모델의 속도가 약 4배 빨라졌습니다. (출처: Hugging Face 공식 블로그 transformersjs-v4, 2026.02.09)
v4가 강조하는 “4배 빠른 BERT”는 WebGPU 기준 수치입니다. WASM 백엔드를 쓰는 기존 프로젝트는 라이브러리를 업그레이드해도 이 속도 향상을 바로 체감할 수 없습니다. device: ‘webgpu’를 명시적으로 지정해야 v4의 성능 개선이 적용됩니다. 그냥 npm 업데이트만 하면 기본값은 여전히 WASM입니다.
빌드 시스템도 Webpack에서 esbuild로 교체됐습니다. 공식 기록상 빌드 시간이 2초에서 200밀리초로 줄었고(10배 단축), 번들 크기도 평균 10% 감소했습니다. 특히 기본 내보내기 파일인 transformers.web.js는 v3 대비 53% 작아졌습니다. (출처: Hugging Face 공식 블로그, 2026.02.09)
번들이 절반 이상 줄었다는 건 초기 로딩 속도 개선으로 직결됩니다. CDN으로 Transformers.js를 불러오는 프로젝트라면 별다른 코드 변경 없이 페이지 로드 속도가 개선됩니다.
| 항목 | v3 | v4 | 변화 |
|---|---|---|---|
| BERT 임베딩 속도 | 기준 | 약 4배 향상 | +300% |
| 기본 번들 크기 | 기준 | 53% 감소 | −53% |
| 빌드 시간 | 약 2초 | 약 200ms | 10배 단축 |
| 지원 모델 최대 파라미터 | 8B 이하 | 20B+ (공식 테스트) | 대폭 확대 |
| Tokenizers.js 번들 크기 | 코어 포함 | 8.8kB (gzip, 독립 패키지) | 분리·경량화 |
(출처: Hugging Face 공식 블로그 transformersjs-v4, 2026.02.09)
WebGPU가 WASM보다 느릴 때가 있습니다
솔직히 말하면, 이 부분이 v4 관련 글들이 잘 다루지 않는 포인트입니다. SitePoint의 실측 벤치마크(2026.02.25, Transformers.js v3.x 기준 — v4에서도 동일한 원리가 적용됩니다)에 따르면, 소형 임베딩 모델에서 WASM이 WebGPU를 이깁니다.
⚠️ all-MiniLM-L6-v2 (22M 파라미터) 단일 문장 추론 기준
WASM: 8~12ms / WebGPU: 15~25ms (M2 MacBook Air 기준) — WebGPU가 더 느립니다.
(출처: SitePoint “WebGPU vs WebASM: Browser Inference Benchmarks”, 2026.02.25)
이유는 구조적입니다. WebGPU 추론은 입력 데이터를 CPU 메모리에서 GPU 버퍼로 올리고, 연산 후 다시 CPU로 읽어오는 왕복 비용이 발생합니다. 모델이 작을수록 연산 시간보다 이 왕복 비용이 커집니다. GPU가 바빠질 만큼 계산량이 없으면 이동 비용만 추가로 쓰는 셈입니다.
반면 생성형 모델(LLM)에서는 격차가 뒤집힙니다. TinyLlama-1.1B로 128 토큰 생성 시, 이산(discrete) GPU 기준 WebGPU는 초당 25~40 토큰, WASM은 2~5 토큰입니다. 10~15배 차이입니다. M2 통합 그래픽에서도 WebGPU 15~25 TPS vs WASM 3~6 TPS로 WebGPU가 압도합니다. (출처: SitePoint, 2026.02.25)
임베딩 검색, 텍스트 분류처럼 단발 추론이 많은 서비스는 WebGPU 전환이 오히려 성능 하락을 일으킬 수 있습니다. v4 업그레이드 후 device: 'webgpu'를 무조건 켜는 것보다, 모델 크기와 작업 유형에 따라 백엔드를 구분하는 게 맞습니다.
브라우저 밖에서도 됩니다 — Node, Bun, Deno
v4의 변화 중 개발자 입장에서 실질적으로 유용한 부분이 바로 이것입니다. 기존에는 WebGPU 가속 모델은 브라우저에서만 쓸 수 있었습니다. v4부터는 Node.js, Bun, Deno에서도 동일한 WebGPU 가속 파이프라인을 사용할 수 있습니다. (출처: Hugging Face 공식 블로그, 2026.02.09)
이 변화가 의미하는 건 코드 재사용입니다. 브라우저 프론트엔드와 Node 백엔드에서 같은 파이프라인 코드를 그대로 씁니다. 지금까지는 브라우저용 Transformers.js 코드와 서버용 Python transformers 코드를 별도로 유지해야 했는데, v4에서는 단일 JavaScript 코드베이스로 통합이 가능합니다.
단, 서버 환경에서 WebGPU를 쓰려면 런타임이 WebGPU API를 지원해야 합니다. Node.js 22 이상 또는 Bun 최신 버전이 필요하며, GPU 드라이버 설정도 별도로 필요합니다. 이유는 아직 공식 문서에서 별도 설명 없이 환경별 설정을 직접 확인해야 합니다.
ModelRegistry와 Tokenizers.js — 실무에서 달라지는 것
v4에서 새로 생긴 ModelRegistry API는 프로덕션 환경에서 유용합니다. 모델을 실제로 로드하기 전에 필요한 파일 목록과 총 다운로드 크기를 미리 조회할 수 있고, 캐시 여부도 확인 가능합니다. 사용자에게 “다운로드 약 340MB” 같은 안내를 보여주기 전에 서버에서 사전 계산할 수 있다는 뜻입니다.
기존 v3에서는 모델 로딩이 시작돼야 파일 수와 크기를 알 수 있었습니다. v4 ModelRegistry로는 로딩 전에 get_file_metadata()로 파일 크기를 합산하고, is_pipeline_cached()로 캐시 확인 후 조건부 다운로드가 가능합니다. UX에서 빈 로딩 스피너 대신 퍼센트 기반 프로그레스를 보여줄 수 있습니다.
Tokenizers.js도 별도 패키지(@huggingface/tokenizers)로 분리됐습니다. gzip 기준 8.8kB로, 의존성이 없습니다. 토크나이저만 쓰고 싶은 경우 전체 Transformers.js를 설치할 필요가 없어집니다. (출처: Hugging Face 공식 블로그, 2026.02.09) 프론트엔드 번들 최적화에서 꽤 실용적인 선택지가 생긴 셈입니다.
로깅도 정리됐습니다. ONNX Runtime WebGPU 경고가 기본적으로 숨겨지고, env.logLevel로 단계를 직접 설정합니다. v3에서 콘솔에 ONNX 경고가 쏟아지던 상황에서 벗어날 수 있습니다.
브라우저에서 20B 모델 — 가능하지만, 조건이 있습니다
Hugging Face 공식 발표에서 GPT-OSS 20B (q4f16 양자화)를 M4 Pro Max에서 초당 약 60 토큰으로 실행하는 데모를 공개했습니다. “브라우저에서 이게 될 리 없다”는 생각이 맞지 않았습니다. (출처: Hugging Face 공식 블로그, 2026.02.09)
그런데 조건을 보면 현실적인 제약이 명확합니다. q4f16 양자화는 파라미터당 약 2바이트를 씁니다. 20B 모델 기준으로 40GB 정도의 이론적 메모리가 필요하지만, MoE 구조와 양자화 최적화로 실제로는 더 적습니다. SitePoint 벤치마크 기준, 1.1B INT4 모델도 GPU 메모리 600MB~1GB를 씁니다. (출처: SitePoint, 2026.02.25) 저사양 기기나 GPU 메모리가 적은 환경에서는 대형 모델 실행이 사실상 불가능합니다.
브라우저 호환성도 걸립니다. WebGPU는 Chrome 113+, Edge 안정 버전에서 기본 활성화됩니다. Firefox는 118+에서 플래그를 켜야 쓸 수 있고, 기본 비활성 상태입니다. Safari는 아직 실험적 지원 단계입니다. 서비스 대상 기기가 다양하다면 반드시 WASM 폴백 경로를 같이 만들어야 합니다.
📌 브라우저 WebGPU 가용성 요약
- Chrome 113+ / Edge 안정: 기본 활성화 ✅
- Firefox 118+: 플래그 수동 활성화 필요 ⚠️
- Safari (macOS/iOS): 실험적, 불안정 ❌
- WASM: 모든 주요 브라우저 기본 지원 ✅ (속도 제한 있음)
(출처: SitePoint, web.dev/learn/ai/client-side, 2026.02.25)
자주 묻는 것들
v3에서 v4로 업그레이드하면 바로 빨라지나요? +
device: 'webgpu'를 명시해야 합니다. 또한 패키지명이 v2의 @xenova/transformers에서 v3 이후 @huggingface/transformers로 바뀐 점도 확인이 필요합니다.
WASM이 더 빠른 케이스를 어떻게 확인하나요? +
performance.now()로 두 백엔드의 추론 시간을 20회 측정해 중앙값을 비교하는 방법이 가장 확실합니다. Hugging Face에서 제공하는 WebGPU Embedding Benchmark 스페이스도 활용할 수 있습니다.
Safari에서 Transformers.js v4 WebGPU를 쓸 수 있나요? +
navigator.gpu의 존재 여부를 런타임에 확인한 뒤 분기 처리하는 방식이 권장됩니다.
Tokenizers.js를 Transformers.js 없이 단독으로 쓸 수 있나요? +
@huggingface/tokenizers가 독립 패키지로 분리됐습니다. gzip 기준 8.8kB, 의존성 없음. npm i @huggingface/tokenizers로 설치 후 Hugging Face Hub에서 tokenizer.json을 fetch해서 사용합니다. 모델 추론 없이 토크나이저 기능만 필요한 프로젝트에 적합합니다.
모델 다운로드 없이 오프라인에서도 동작하게 할 수 있나요? +
env.useWasmCache = true 설정으로 WASM 런타임 파일을 캐싱할 수 있고, Origin Private File System(OPFS)을 활용하면 모델 가중치도 로컬에 저장해 재방문 시 네트워크 없이 실행 가능합니다. 단, OPFS는 Chrome 86+, Safari 15.2+, Firefox 111+ 이상이 필요하며, 저장 용량 한도는 브라우저마다 다릅니다.
마치며
Transformers.js v4는 “브라우저 AI”라는 말이 더 이상 데모 수준이 아님을 보여준 릴리스입니다. C++ 재작성 WebGPU 런타임, 20B 모델 지원, Node/Bun/Deno 통합까지 — 개발 환경이 실질적으로 달라졌습니다.
다만 “WebGPU = 항상 빠름”은 사실이 아닙니다. 소형 임베딩 모델은 WASM이 더 빠르고, WebGPU 첫 실행엔 1~5초의 셰이더 컴파일 비용이 생깁니다. Firefox와 Safari의 WebGPU 지원은 아직 불완전하고, 저사양 기기에서 대형 모델은 GPU 메모리 부족으로 실행이 안 됩니다. 번들 크기 53% 감소와 빌드 속도 10배 향상은 체감할 수 있는 수준의 실질 변화입니다.
개인적으로 가장 실용적인 변화는 ModelRegistry와 Tokenizers.js 분리입니다. 모델을 서비스에 붙이는 과정에서 UX와 번들 최적화 두 가지 문제가 한꺼번에 해결됩니다. v4 전환을 고려하고 있다면 이 두 가지부터 적용해보는 게 가장 빠른 체감 변화를 줄 것 같습니다.
- Hugging Face 공식 블로그 — Transformers.js v4: Now Available on NPM!
https://huggingface.co/blog/transformersjs-v4 (2026.02.09) - Hugging Face GitHub — transformers.js 공식 저장소
https://github.com/huggingface/transformers.js/ - SitePoint — WebGPU vs WebASM: Browser Inference Benchmarks
https://www.sitepoint.com/webgpu-vs-webasm-transformers-js/ (2026.02.25) - web.dev — The client-side AI stack
https://web.dev/learn/ai/client-side (2026.01.29)
본 포스팅은 2026년 3월 31일 기준으로 작성됐습니다. Transformers.js v4.0.0 및 관련 서비스의 정책·UI·기능·수치는 이후 업데이트로 달라질 수 있습니다. 본 포스팅 작성 이후 서비스 정책·UI·기능이 변경될 수 있으므로, 최신 정보는 공식 Hugging Face 문서에서 직접 확인하시기 바랍니다.
댓글 남기기