허깅페이스는 9월 1일 Hub에서 최적화된 WebGPU 커널을 내려받아 준비하고 실행하는 자바스크립트 로더 라이브러리 @huggingface/kernels를 공개했다. 함께 공개된 것은 행렬 곱셈, 정규화, 컨볼루션, 어텐션 기본 연산, 양자화 연산, 데이터 레이아웃 변환 등 다양한 머신러닝 아키텍처를 아우르는 이미 튜닝된 GPU 연산자 207개다. 라이선스는 Apache-2.0이다.
가장 이례적인 부분은 구성 방식이다. 커널마다 인터페이스 정의, 셰이더 템플릿, 정확성 테스트, 벤치마크 데이터를 갖춘 별도 저장소로 배포된다. Hub에 올라간 순간부터 연산자와 모델은 버전 관리, 다운로드, 참조에서 완전히 같은 체계를 공유한다.
809건의 대조 테스트
성능 수치는 ORT WebGPU 1.30.0-dev와의 직접 비교에서 나왔다. 809개 테스트 케이스에서 기하평균 2.57배, 중앙값 1.90배 속도 향상을 기록했고, 승패 기록은 629승 176패 4무였다. 개별 연산자로 쪼개보면 Add는 3.52배, Softmax는 2.11배, LayerNormalization은 2.22배 빨라졌다.
단순 계산하면 승률은 약 78%다. 기하평균 2.57배가 중앙값 1.90배를 크게 웃도는 것은 분포가 오른쪽으로 치우쳐 있다는 뜻이다. 소수의 연산자가 유난히 크게 빨라지면서 평균을 끌어올린 셈이다. 실제 워크로드에서 체감할 속도 향상은 발표에서 강조하는 수치보다는 중앙값에 더 가까울 가능성이 크다. 결론의 방향 자체가 바뀌는 것은 아니지만, 기대치는 한 번 조정해둘 필요가 있다.
커널과 함께 공개된 것이 Fleet이라는 브라우저 내장 벤치마크 도구다. 발상은 크라우드소싱으로, 누구든 자기 기기에서 돌리면 성능과 정확성에 대한 증거가 하나씩 쌓이는 구조다. WebGPU의 하드웨어 파편화는 서버용 CUDA보다 훨씬 심각하다. 내장 GPU, 외장 GPU, 모바일 GPU, 브라우저별 구현마다 성능 차이가 크고, 몇 대의 실험실 장비만으로는 전체 그림을 파악할 수 없다. 테스트를 사용자에게 분산시키는 것은 현실적인 해법이다.
왜 커널 층에서 막혀 있었나
브라우저에서 모델을 돌리는 매력은 늘 분명했다. 연산이 사용자 기기에서 일어나니 서버는 연산 비용을 부담하지 않고, 데이터도 기기 밖으로 나갈 필요가 없다. 그런데도 도입이 지지부진했던 것은 대개 모델 포맷이나 추론 프레임워크 탓이 아니라 그 아래 층, 즉 커널 탓이었다. 같은 Softmax라도 잘 짠 것과 그럭저럭 짠 것의 차이가 실시간 동작 여부를 가른다.
이전까지 이 층은 추론 런타임 전체와 묶여서만 업그레이드할 수 있었다. 더 빠른 어텐션 구현으로 바꾸려면 보통 다음 프레임워크 버전을 기다려야 했다. 커널을 독립 저장소로 쪼개면서 연산자는 단독으로 교체하고, 롤백하고, 개선할 수 있는 단위가 됐다. 특정 GPU에 맞춰 튜닝한 행렬 곱셈 커널을 특정 모델 하나에만 적용하는 일도, 이론상으로는 다른 코드를 건드리지 않고 가능해진다.
호출 방식도 짧게 압축돼 있다. 커널 객체를 받아서 바로 함수처럼 부르면 된다.
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });실행 조건은 브라우저의 WebGPU 지원이고, 확인 방법은 "gpu" in navigator 한 줄이면 된다.
온디바이스 도구에 미치는 영향
이번 업데이트의 수혜 대상은 구체적이다. 브라우저 안에서만 동작하는 이미지 처리, 로컬 음성 전사, 오프라인 번역, 프라이버시에 민감한 도구를 만드는 팀들이다. 이런 제품의 비즈니스 모델은 서버가 정적 파일만 내려주고 연산 비용을 지지 않는다는 전제 위에 서 있고, 브라우저에 담을 수 있는 모델 규모는 커널 성능이 그대로 결정한다. 커널 전체가 대략 두 배 빨라지면 실용 가능한 모델 크기의 상한도 한 단계 올라가고, 예전엔 3초 걸리던 작업이 1초 안쪽으로 들어올 수 있다.
보수적으로 봐야 할 부분도 분명히 짚어야 한다. 벤치마크 비교 대상은 ORT WebGPU의 dev 빌드이고, 경쟁 상대도 계속 업데이트되고 있다. 연산자 207개는 많아 보이지만 커버하는 것은 흔한 연산이고, 흔치 않은 구조를 만나면 결국 직접 작성해야 한다. WebGPU 지원 자체는 여러 브라우저로 퍼졌지만 모바일 구현 완성도는 제각각이라, 기기별 실제 동작은 Fleet 같은 도구로 직접 확인해야 한다.
커널을 주소 지정 가능하고 버전 관리되며 크라우드로 검증되는 자산으로 바꿔놓은 것은, 단순히 속도가 두 배 됐다는 사실보다 장기적으로 더 중요한 의미를 갖는다. 모델 가중치는 이미 이런 방식으로 유통돼 왔고, 인프라 코드가 뒤따라오는 것은 시간문제였을 뿐이다.
참고 출처: 허깅페이스 공식 블로그, CocoLoop, 허깅페이스 Hub 저장소. 커널 수, 809개 테스트 케이스, 기하평균 2.57배와 중앙값 1.90배 속도 향상, 629승 176패 4무 승패 기록 및 연산자별 배율은 공식 발표를 기준으로 확인했다. 승률 계산과 분포 편향 분석은 편집부의 개략적 추정이다.