같은 페이지 · 같은 GPU · 같은 가중치 · 숫자마다 어댑터

유사 솔루션 실측 비교

오늘 브라우저에서 WebGPU 로 신경망을 학습하는 라이브러리는 셋 — TF.js, jax-js, Burn — 이고, 추론만 하는 런타임이 하나, ONNX Runtime Web 이다. 이 페이지는 그 넷을 borch.ts 와 같은 페이지, 같은 GPU 에서, 같은 시드 데이터 또는 torch 에서 내보낸 같은 가중치로 돌리고, 숫자 아래마다 어댑터를 찍는다. borch 가 지는 행은 남기고, 모든 표를 재현하는 명령은 맨 아래에 있다. Chrome 과 WebGPU 가 필요하다. 숫자는 그날 그 카드의 것이고, run 이 움직일 때 움직인다.

학습 — ResNet-18 (CIFAR), 스텝당 ms

같은 구조, SGD 0.05/0.9, 교차엔트로피, 같은 시드 픽셀; 워밍업 2회 뒤 5회 측정, 매 스텝 손실 리드백을 넣어 GPU 가 끝나는 시점까지 시계에 들어간다. 라이브러리마다 자기 레이아웃(NHWC 또는 NCHW)과 자기 옵티마이저로 돈다 — 그 차이가 비교의 일부다.

2026-09-03 에 같은 페이지는 TF.js 대비 2.2–2.9× 였다. TF.js 는 움직이지 않았고(같은 바이트, 86.4 → 86.5), borch 가 움직였다 — subgroup 행렬 위의 합성곱 backward, 융합된 옵티마이저 스텝, 카드마다 측정으로 고른 커널. jax-js 에는 BatchNorm 과 교차엔트로피 모듈이 없어 그 스텝은 있는 것으로 조립했고, Burn 의 wasm wgpu 백엔드는 단일 스레드로 리드백마다 동기화한다(그리고 batch 16 에서 4090 이 Metal 보다 2.3× 빠르다 — borch 와의 거리가 카드 따라 움직이는 유일한 라이브러리). 각각 그 라이브러리가 오늘 브라우저에서 할 수 있는 최선이지, 그 라이브러리의 최적 구현은 아니다.

추론 — ResNet-18 (CIFAR) forward, ms

torch 에서 한 번 내보낸 같은 신경망 — borch.ts 에는 safetensors, ORT 에는 ONNX — 이고, 두 런타임이 시드 입력에서 torch 의 logits 를 1e-3 안에서 재현한 뒤에만 표를 찍는다(실측 ~5e-8). 워밍업 3회 뒤 20회 평균, forward 마다 scope 하나, 리드백 포함. borch 행은 eval forward 를 기록해 되감은 것(compiled(model))이다.

같은 1,000장 held-out CIFAR-10 의 top-1, 이 시험을 위해 학습한 신경망, 5080: borch f32 92.40 %, borch int8 static 92.50 %, ORT f32 92.40 %, ORT int8 92.50 %. 양자화된 신경망은 같은 신경망이고, 다른 것은 누가 GPU 에서 돌리느냐다. ORT 의 int8 파일은 모든 어댑터에서 자기 f32 보다 WebGPU 에서 느리고(Metal 6×, 5080 11–28×) batch 1 에서는 wasm 프로바이더보다도 느리다 — 양자화된 합성곱이 WebGPU 프로바이더의 것이 아니다.

추론 — ViT-Tiny/16 (224², 1000 클래스) forward, ms

timm 의 vit_tiny_patch16_224 seed 0, borch 쪽은 bimm-ts 모델, 둘 다 torch 의 logits 로 게이트(실측 ~1e-6). 트랜스포머용으로 이 라이브러리에 쓴 것은 없다: 선형층은 합성곱의 GEMM 타일로, 어텐션은 배치 행렬곱과 subgroup softmax 로 돈다.

이 페이지가 말하지 않는 것

• 모델 하나씩. ResNet-18 은 32 × 32 CIFAR 이고 ViT 는 tiny 다. 더 큰 입력과 더 큰 모델(57 MB 창으로 파인튜닝한 346 MB ViT-Base 는 docs/SCALE.md 에 따로 있다)은 이 표 밖이다.
• Chrome 만, 그것도 최근 것. Safari 와 Firefox 는 재지 않았다. 어댑터마다 기계 하나. Linux Chrome 은 5080 과 4090 에서 ORT 에 f16 을, borch 에 f32 subgroup 행렬을 주지 않는다(int8 만). 4090 의 Chrome 은 그 행을 재던 아침에 143 이었고, 그 Chrome 의 WGSL 전단은 int8 합성곱의 subgroupMatrixStore 를 거부했다(151·153 은 subgroup_id 에 더는 적용하지 않는 uniformity 규칙). 라이브러리는 fault 를 세어 숫자를 찍지 않았고, 행은 Chrome 153 의 것이다.
• 노트북의 오후 행이 범위인 것은 기계가 사용 중이었기 때문이다. 모든 라이브러리가 함께 2–3× 느렸고 비율은 유지됐다. 기계 없는 시간은 인용은 되어도 반박은 안 되기에 어댑터가 모든 행에 있다.
• borch 에 없는 것: f16 연산 커널(Metal 에서 ORT 의 f16 이 비기는 이유), LLM 디코드, 일반 그래프 IR. int8 은 합성곱만, 그리고 카드가 int8 subgroup 설정을 내주는 곳에서만.
• eager 는 이 표가 아니다. compiled 없이 모델을 부르는 페이지는 eager 행을 본다: Metal 에서 되감기의 1.1–1.35×, 5080 batch 1 에서는 ORT 와 대등, 4090 에서는 뒤진다(5.8 대 3.7) — 카드가 짧은 burst 사이에 클럭을 내리고 eager 루프가 그 틈을 준다. batch 16 은 둘 다 eager 로도 앞선다.
• 첫 호출은 컴파일한다. Metal 과 5080 에서 0.05 초, 노트북 D3D12 에서 0.16 초(브라우저가 컴파일된 파이프라인을 다음 방문까지 보관해 두 번째는 0.015 초), 입력 모양당 한 번.

재현

이 페이지의 모든 표는 소프트웨어 어댑터를 거부하고 숫자 아래에 기계를 적는 러너가 찍는다.

git clone https://github.com/playidea-lab/borch && cd borch && npm ci && npm run build:ts
npm run compare:ts          # 학습 vs TF.js · 추론 vs ORT Web f32/f16/int8 · ViT-Tiny
npm run compare-peers:ts    # jax-js 와 Burn (Burn crate 는 tests/browser/burn_resnet18 에서 빌드)
npm run capture:ts          # 기록, 튜너, 첫 호출의 비용

숫자마다 뒤에 있는 원장 — run 전에 적은 예측과 그중 틀린 것 — 은 docs/BOOK.md("How fast it is"), docs/INFER.md, docs/INT8.md, docs/GEMM.md, docs/COMPILER.md, docs/FIRST.md 다. 바이트 고정: TF.js 4.22.0, jax-js 0.1.25, Burn 0.21, ONNX Runtime Web 1.29.0 (tests/browser/assets.lock).