브라우저에서 AI 모델은 어떻게 실행할까?

왜 브라우저에서 AI를 실행할까

대부분의 AI 기능은 서버를 호출합니다. 사진이나 텍스트를 업로드하면 데이터 센터의 GPU가 모델을 실행하고 결과가 돌아오죠. 브라우저 AI는 이 구조를 뒤집습니다. 모델을 한 번 내려받고, 방문자 자신의 기기가 작업을 합니다.

• 개인정보 보호: 사진, 오디오, 문서가 기기 안에 머뭅니다. 업로드하거나 저장할 필요가 없어서 여러 나라의 개인정보 보호법을 지키기도 쉬워집니다.
• 사용당 서버 비용 없음: 사이트는 GPU 시간이 아니라 모델 파일 호스팅 비용만 냅니다. 무료 도구가 가능한 이유입니다.
• 처음 로드한 뒤에는 오프라인에서도 작동하고, 요청마다 생기는 네트워크 지연이 없습니다.
• 계정이나 API 키가 필요 없습니다.

단점도 분명합니다. 첫 방문에는 큰 다운로드가 필요하고, 속도는 방문자의 하드웨어에 달려 있으며, 소형·중형 모델만 들어갑니다. 수백억 개 파라미터의 대형 챗 모델은 아직 서버가 필요합니다. 오늘날 잘 맞는 작업으로는 배경 제거, 이미지 업스케일, 깊이 추정, 음성 인식, 번역, 텍스트 분류, 임베딩, 작은 이미지·언어 모델이 있습니다. 예를 들어 cv.cm의 배경 제거와 음성-텍스트 변환 도구는 이 방식으로 BiRefNet과 Whisper를 실행하며, 아무것도 업로드하지 않습니다.

네 개의 층: 모델, 런타임, 백엔드, 라이브러리

ONNX는 신경망을 위한 개방형 형식입니다. PyTorch로 학습한 모델을 ONNX로 내보내면 ONNX Runtime Web이 여러 백엔드로 실행할 수 있습니다. WASM 백엔드는 모든 ONNX 연산자를 지원하지만 GPU 백엔드는 일부만 지원하므로, 모델이 WebGPU에서는 실패해도 WASM에서는 작동할 수 있습니다. Transformers.js는 직접 작성해야 했을 부분을 대신 채워 줍니다. 이미지 크기 조정, 텍스트의 토큰 변환, 오디오 디코딩, 날것의 출력 숫자를 레이블·마스크·텍스트로 바꾸는 일입니다.

WebGPU와 WebAssembly 비교

WebGPU는 페이지가 그래픽 카드를 화면 그리기와 범용 연산 모두에 쓸 수 있게 하는 W3C 웹 표준입니다. 신경망에서는 연산 쪽이 중요합니다. 행렬 곱셈이 수많은 GPU 코어에서 병렬로 실행됩니다. WebAssembly는 컴파일된 코드를 CPU에서 네이티브에 가까운 속도로 실행하며 모든 최신 브라우저에서 작동합니다.

실무에서는 WebGPU를 먼저 시도하고 WASM으로 대체하세요. 브라우저 이름으로 판단하지 말고, 브라우저에 어댑터를 요청해 기능을 확인합니다.

// Check what this device can do before loading a model.
async function pickBackend() {
  if (!("gpu" in navigator)) return { device: "wasm" };      // no WebGPU API
  const adapter = await navigator.gpu.requestAdapter();
  if (!adapter) return { device: "wasm" };                    // API exists, no usable GPU
  const f16 = adapter.features.has("shader-f16");             // half-precision support
  return { device: "webgpu", f16 };
}

console.log(await pickBackend(), "threads:", self.crossOriginIsolated);

멀티스레드 WASM은 SharedArrayBuffer를 사용하는데, 브라우저는 페이지가 교차 출처 격리 상태일 때만 이를 허용합니다. 그러려면 Cross-Origin-Opener-Policy와 Cross-Origin-Embedder-Policy 헤더를 보내야 합니다. 없으면 WASM은 단일 스레드로 실행되어 훨씬 느립니다.

최소한의 Transformers.js 예제

Transformers.js에서는 작업 하나가 pipeline 호출 한 번입니다. 라이브러리가 모델을 내려받고, 선택한 장치와 데이터 타입에 맞는 파일을 고르고, 호출할 수 있는 함수를 돌려줍니다.

import { pipeline } from "@huggingface/transformers";

const { device } = await pickBackend();     // from the snippet above

// First call downloads the model and caches it. Later visits load from cache.
const classify = await pipeline(
  "sentiment-analysis",
  "Xenova/distilbert-base-uncased-finetuned-sst-2-english",
  {
    device,                                  // "webgpu" or "wasm"
    dtype: device === "webgpu" ? "fp32" : "q8",
    progress_callback: (p) => console.log(p.status, p.file ?? "", p.progress ?? ""),
  }
);

console.log(await classify("This runs entirely on my laptop."));
// [{ label: "POSITIVE", score: 0.99... }]

모듈 스크립트나, 더 좋게는 웹 워커에서 실행하세요. 모델 추론은 수백 밀리초 이상 멈출 수 있는데, 워커에서는 페이지가 계속 반응합니다. WebGPU는 워커 안에서도 쓸 수 있습니다. 느린 연결에서는 큰 모델의 첫 로드가 오래 걸릴 수 있으니 다운로드 진행률을 사용자에게 보여 주세요.

다운로드 크기, 양자화, 캐싱

다운로드 크기는 대략 파라미터 수에 파라미터당 저장 바이트 수를 곱한 값입니다. 이 간단한 계산으로 모델이 실용적인지 알 수 있습니다.

download size  ~  number of parameters  x  bytes per parameter

                      fp32 (4 B)   fp16 (2 B)   int8 / q8 (1 B)   q4 (0.5 B)
 50 million params      200 MB       100 MB          50 MB            25 MB
 500 million params     2.0 GB       1.0 GB         500 MB           250 MB
 1 billion params       4.0 GB       2.0 GB         1.0 GB           500 MB

Real files differ a little: some layers stay at higher precision,
and the tokenizer and config add a few MB.

양자화는 가중치를 더 적은 비트로 저장합니다. fp16은 fp32의 절반 크기, 8비트 양자화(q8)는 4분의 1, 4비트(q4)는 약 8분의 1로 줄입니다. 가중치가 작을수록 더 빨리 내려받고 메모리도 덜 씁니다. 대신 정확도가 조금 떨어지는데, 8비트에서는 보통 작고 4비트에서는 더 눈에 띕니다. 특히 소형 모델이나 작은 오류가 드러나는 이미지 생성 같은 작업에서 그렇습니다. Transformers.js는 dtype 옵션으로 변형을 고릅니다. 기본값은 WASM에서 q8, WebGPU에서 fp32이며, 쓸 수 있는 옵션은 모델 배포자가 내보낸 것에 따라 다릅니다.

캐싱 덕분에 두 번째 방문이 빨라집니다. Transformers.js는 기본적으로 내려받은 파일을 브라우저의 Cache API에 저장합니다. 브라우저는 디스크 크기를 기준으로 사이트마다 저장 용량 할당량을 주며, 데스크톱에서는 수 기가바이트가 되는 경우가 많습니다. 하지만 이 저장소는 최선 노력(best-effort) 방식이어서 기기 공간이 부족하면 브라우저가 지울 수 있고, Safari는 며칠 동안 사용자가 상호작용하지 않은 사이트의 스크립트로 만든 데이터를 삭제할 수 있습니다. 사이트는 navigator.storage.persist()로 영구 저장을 요청하고 navigator.storage.estimate()로 사용량을 확인할 수 있습니다.

휴대폰과 그 밖의 한계

• 메모리: 모델에는 가중치와 작업 공간을 위한 메모리가 필요합니다. 모바일 브라우저는 탭당 메모리를 데스크톱보다 훨씬 적게 주며, 모델이 너무 크면 경고 없이 탭을 닫을 수 있습니다. 모바일용 모델은 작게, 보통 수백 메가바이트 이하로 유지하세요.
• 휴대폰의 WebGPU: 지원 여부는 브라우저, 운영체제 버전, GPU 드라이버에 따라 다릅니다. 항상 WASM 경로나 분명한 안내 메시지를 준비하세요.
• 발열과 배터리: GPU 작업이 길어지면 휴대폰이 뜨거워지고, 시스템이 칩 속도를 낮춥니다. 처음에 2초 걸리던 작업이 다섯 번째에는 훨씬 오래 걸릴 수 있습니다.
• 데이터 요금제: 모바일 연결에서 큰 다운로드를 하기 전에 사용자에게 경고하세요.
• 정밀도: 일부 GPU는 빠른 반정밀도(fp16)를 지원하지 않거나 조금 다른 숫자를 내므로 기기마다 출력이 약간 다를 수 있습니다.
• 모델 라이선스는 그대로 적용됩니다. 브라우저에서 모델을 실행한다고 이용 약관이 바뀌지 않습니다.

브라우저 AI를 배포하기 전 체크리스트

1. 품질 기준을 충족하는 가장 작은 모델을 고르고, 양자화 버전들을 나란히 테스트하세요.
2. 어댑터 요청으로 WebGPU를 감지하고 WASM으로 대체하세요.
3. 사이트를 HTTPS로 제공하고, WASM 스레드가 필요하면 교차 출처 격리를 켜세요.
4. 추론은 웹 워커에서 실행하고 다운로드와 처리 진행률을 보여 주세요.
5. 페이지 로드 때 모델을 내려받지 마세요. 사용자가 작업을 시작할 때까지 기다려야, 페이지를 읽기만 하는 방문자가 기가바이트 단위 다운로드를 떠안지 않습니다.
6. 모델 파일은 고정된 버전으로 호스팅하고 캐시하세요.
7. 개발용 노트북만이 아니라 저사양 휴대폰에서도 테스트하세요.