웹사이트에 간단한 분류기(Classifier)를 추가해 달라는 요청을 받았습니다. 그런데 250MB의 다운로드를 보게 되었습니다.

한 클라이언트가 저에게 아주 간단한 것을 요청했습니다.

ChatGPT가 아닙니다.

에이전트(Agent)도 아닙니다.

송장을 설명하고, React 컴포넌트를 생성하며, 3개 국어로 시를 쓸 수 있는 멀티모달 어시스턴트(Multimodal assistant)도 아닙니다.

그저 웹사이트에 임베디드(Embedded)된 작은 분류기(Classifier)일 뿐이었습니다.

그 작업은 가장 긍정적인 의미에서 지루하게 들렸습니다:

텍스트를 가져와서, 분류하고, 결과를 반환하며, 속도를 유지할 것.

그래서 저는 일반적인 솔루션들을 살펴보기 시작했습니다.

그러다 문서를 읽는 것을 멈추고, 몸을 뒤로 기대며 스스로에게 묻게 되는 그런 순간이 찾아왔습니다:

우리가 진심으로 이렇게 하려는 건가요?

왜냐하면 제가 계속 마주하게 된 답변은 다음과 같았기 때문입니다:

거대한 런타임(Runtime)을 다운로드하고

거대한 모델(Model)을 다운로드하고

거대한 ML 스택(ML stack)을 초기화한 뒤

단 하나의 작은 텍스트 조각을 분류한다

한 설정에서는, 그 경로가 사용자당 거의 250 MB에 육박했습니다.

단순한 분류기를 위해서 말이죠.

웹사이트에서.

서버로부터.

매번 말입니다.

아니요. 죄송하지만, 이건 말도 안 됩니다.

문제점

현재 웹에는 이상한 습관이 하나 있습니다.

작은 AI 기능 하나를 요구하면, 답변은 종종 다음과 같습니다:

건설 회사 전체를 통째로 데려오세요.

하지만 때때로 저에게는 건설 회사가 필요하지 않습니다.

저는 건설 현장에 있는 사람 한 명이 필요합니다.

한 가지 작업.

한 가지 도구.

한 가지 결과.

이는 특히 단순 분류(Classification), 임베딩(Embeddings), 시맨틱 검색(Semantic search), 라우팅(Routing), 필터링(Filtering), 랭킹(Ranking), 작은 로컬 결정(Small local decisions)의 경우에 그러합니다.

모든 AI 문제에 LLM(Large Language Model)이 필요한 것은 아닙니다.

모든 웹사이트에 전체 추론 엔진(Inference engine)이 필요한 것도 아닙니다.

우리가 더 작게 생각하기를 게을리했다는 이유로, 모든 사용자가 250 MB의 다운로드 세금을 지불해서는 안 됩니다.

그래서 저는 파헤치기 시작했습니다

저는 다음과 같은 단순한 것을 원했습니다:

브라우저에서 실행될 것
추론(Inference)을 위해 서버를 필요로 하지 않을 것
실제로 배포할 수 있을 만큼 충분히 작을 것
트랜스포머(Transformer) 스타일의 모델과 작동할 것
텍스트를 토큰화(Tokenize)할 수 있을 것
BERT와 유사한 순전파 추론(Forward inference)을 수행할 수 있을 것
임베딩(Embeddings)이나 분류 입력(Classification input)을 생성할 수 있을 것
ONNX Runtime, Candle, ndarray, 또는 인터넷의 절반을 함께 끌고 오지 않을 것

처음에는 이렇게 생각했습니다:

“분명 누군가 이미 아주 작은 버전을 만들어 놓았을 거야.”

세상에는 훌륭한 도구들이 이미 많이 나와 있습니다.

Transformers.js는 강력합니다.

ONNX Runtime Web도 강력합니다.

Candle도 강력합니다.

하지만 바로 그것이 문제였습니다.

이 도구들이 강력한 이유는 범용적 (General)이기 때문입니다.

저에게는 범용성이 필요하지 않았습니다.

저에게 필요한 것은 특수성 (Narrow)이었습니다.

저에게 필요한 것은 작음 (Small)이었습니다.

그래서 직접 하나를 만들었습니다.

wasmicro를 소개합니다

wasmicro는 웹을 위한 아주 작은 트랜스포머 추론 런타임 (Transformer inference runtime)을 만들려는 저의 시도입니다.

현재 WASM 번들 크기:

~94 KB

94 MB가 아닙니다.

94 KB입니다.

프로젝트 주소는 여기 있습니다:

https://github.com/Xzdes/wasmicro

라이브 데모:

https://xzdes.github.io/wasmicro/

완벽하지는 않습니다.

끝나지도 않았습니다.

여전히 테스트 중입니다.

하지만 이미 제가 필요로 했던 일을 해내고 있습니다: 거대한 런타임을 배포하지 않고도 브라우저에서 작은 트랜스포머 스타일의 파이프라인 (Pipeline)을 실행하는 것 말입니다.

현재 기능

현재 wasmicro는 다음을 지원합니다:

자체 소유의 아주 작은 텐서 (Tiny owned tensors)
safetensors 로딩
WordPiece 토크나이저 (Tokenizer)
BERT 인코더 순전파 (Forward pass)
임베딩 (Embeddings)을 위한 평균 풀링 (Mean pooling)
WASM 바인딩 (Bindings)
SIMD128 행렬 곱셈 (Matmul) 경로
i8/u8/q4 양자화된 (Quantized) 가중치 타입
HuggingFace 모델을 위한 컨버터 (Converter) 도구

설계 원칙은 간단합니다:

만약 그것이 WASM 번들을 더 작게 만들거나, 더 빠르게 만들거나, 혹은 트랜스포머 아키텍처 (Transformer architecture)에 유용하게 만들지 않는다면, 아마도 포함될 이유가 없을 것이다.

학습 (Training) 없음.

자동 미분 (Autograd) 없음.

옵티마이저 (Optimizer) 없음.

범용 텐서 프레임워크 (General tensor framework) 없음.

“모듈 동물원 (Module zoo)” 없음.

오직 순전파 추론 (Forward inference)만 존재합니다.

왜 그냥 큰 런타임을 사용하지 않나요?

때로는 런타임이 문제 자체보다 더 크기 때문입니다.

만약 제가 본격적인 AI 애플리케이션을 구축하고 있다면, 네, 저는 본격적인 AI 인프라를 사용할 것입니다.

만약 저에게 WebGPU, 다양한 아키텍처, 이미지 모델, 오디오 모델, 생성 (Generation), 파이프라인 (Pipelines), 폴백 백엔드 (Fallback backends), 그리고 폭넓은 모델 지원이 필요하다면, 저는 큰 도구들을 사용해야 할 것입니다.

하지만 웹사이트에 내장될 작은 분류기 (Classifier)가 필요한 것이라면 어떨까요?

저는 AI 생태계 전체를 원하지 않습니다.

저는 가장 작으면서도 유용한 것을 원합니다.

그 차이는 마치 다음과 같은 고용의 차이와 같습니다:

건설 회사 전체를 고용하는 것
또는 적절한 도구를 가진 작업자 한 명을 고용하는 것

웹은 계속해서 저에게 회사 전체를 던져주고 있습니다.

저에게는 작업자가 필요했습니다.

현재 수치

현재 WASM 번들 크기는 다음과 같습니다:

wasm-opt -Oz 적용 후 약 94 KB

제가 스스로 설정한 엄격한 크기 상한선은 다음과 같습니다:

250 KB

기본 라이브러리 의존성 세트는 의도적으로 매우 작게 구성되었습니다.

이 프로젝트는 다음과 같은 것들을 가져오는 것을 피합니다:

ndarray
candle
rayon
serde_json
chrono
getrandom

변환기 CLI (converter CLI)는 데스크톱 머신에서 실행되며 브라우저로 배포되지 않기 때문에 더 무거운 의존성을 사용할 수 있습니다.

브라우저 런타임 (runtime)은 작게 유지됩니다.

더 빠른가?

그것은 "빠르다"는 것이 무엇을 의미하느냐에 달려 있습니다.

만약 완전히 최적화된 WebGPU 런타임에 맞서 GPU 상에서의 최대 처리량 (maximum throughput)을 의미하는 것이라면, 아마 아닐 것입니다.

그것은 제가 싸우려는 대상이 아닙니다.

제가 관심을 두는 싸움은 다음과 같습니다:

콜드 스타트 (cold start)
첫 번째 유효한 결과 (first useful result)
작은 런타임 (small runtime)
단순한 임베딩 (embedding)/분류 (classification) 작업
CPU/WASM 경로
거대한 프레임워크 다운로드 없음

저는 다음 항목들로 경쟁하고 싶습니다:

로드 시간 (time to load)
첫 번째 임베딩까지의 시간 (time to first embedding)
런타임 크기 (runtime size)
...

"누가 200개의 모델 아키텍처를 지원하는가"로 경쟁하는 것이 아닙니다.

그것은 다른 게임입니다.

부족한 점

많습니다.

이것은 아직 초기 단계입니다.

이 프로젝트에는 여전히 다음과 같은 것들이 필요합니다:

더 나은 공개 벤치마크 (benchmarks)
더 쉬운 모델 다운로드 방식
더 최적화된 어텐션 (attention) 경로
순전파 (forward) 중 할당 (allocation) 감소
BERT를 위한 더 나은 q4 로딩
더 깔끔한 제로 설정 (zero-config) 예제
더 많은 브라우저 측정
더 많은 실제 분류 데모

또한, 현재 라이브 데모는 사용자가 모델 파일을 직접 제공할 것을 요구합니다.

이것은 이상적이지 않습니다.

하지만 핵심을 증명하기에는 이미 충분합니다:

작은 AI 작업을 수행하기 위해 항상 거대한 런타임이 필요한 것은 아닙니다.

진짜 교훈

이것은 단순한 클라이언트 작업으로 시작되었습니다.

"웹사이트에 분류기 (classifier)를 추가해 주세요."

그 후 저는 일반적인 경로를 살펴보았고 그 비용을 확인했습니다.

그리고 저는 작은 기능을 위한 해답이 다음과 같다는 것을 받아들일 수 없었습니다:

수백 메가바이트를 배포하고 아무도 눈치채지 않기를 바란다.

사용자는 눈치챕니다.

브라우저는 눈치챕니다.

모바일 연결은 눈치챕니다.

콜드 스타트도 눈치챕니다.

그래서 저는 더 작은 것을 만들었습니다.

그것이 완벽하기 때문이 아니라 말입니다.

대안이 잘못된 것처럼 느껴졌기 때문입니다.

마지막 생각

현재 AI 툴링 (AI tooling)은 놀라운 수준입니다.

하지만 우리는 또한 게을러지고 있습니다.

편리하다는 이유로 가장 큰 도구에 손을 뻗습니다.

때로는 그것이 옳습니다.

때로는 그것이 터무니없습니다.

작업에 기중기가 필요하다면 기중기를 사용하십시오.

작업에 망치를 든 한 사람이 필요하다면, 건설 회사를 보내지 마십시오.

wasmicro는 망치를 만들기 위한 저의 시도입니다.

작고.

좁고.

여전히 거칠지만.

이미 유용합니다.

GitHub: