Introducing @huggingface/kernels: 200+ WebGPU Kernels for Local AI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

Hugging Face가 브라우저 로컬 추론의 기반을 개선하기 위해 207개 WebGPU 커널, 자바스크립트 로더 @huggingface/kernels, 기기별 검증 도구 Fleet을 공개했다.

📌 핵심 요약

• 207개 WebGPU 커널은 Apache-2.0 라이선스로 Hub의 개별 저장소에 공개됐으며, 연산 계약·셰이더 템플릿·정확성 테스트·벤치마크 사례를 버전 관리되는 패키지로 제공한다.
• @huggingface/kernels는 WebGPU 지원 브라우저에서 저장소 ID와 계약 버전으로 커널을 불러오며, 입력에 따라 출력 형상과 자료형을 도출하고 출력 메모리를 자동 할당한다.
• Apple M4에서 ORT WebGPU와 비교한 1,756개 사례 중 출력 일치와 신뢰할 수 있는 측정 조건을 충족한 809개 사례에서 기하평균 2.57배, 중앙값 1.90배의 속도 향상을 기록했다.
• 성능 수치는 개별 연산의 GPU 실행 시간만 측정한 결과로, 로딩·입력 업로드·셰이더 컴파일·출력 회수 등의 비용을 제외하며 전체 모델이나 다른 GPU·브라우저의 성능을 보장하지 않는다.
• Fleet은 브라우저에서 정확성과 성능을 검사하고 사용자 동의를 받아 실행 증거를 비공개로 수집한다. Hugging Face는 이를 기기별 오류 발견과 구현 변형 선택 개선에 활용하며, ONNX Runtime 팀과 개선 사항의 업스트림 반영도 추진하고 있다.

🧩 주요 포인트

1. 연산 계약과 검증 자료의 독립 배포 → 상위 런타임이 의존하는 인터페이스를 유지하면서 커널 구현을 개선할 수 있는 기반 마련.
2. Apple M4의 개별 연산 성능 향상과 측정 범위의 제한 → 도입 판단에서 GPU 실행 시간과 전체 모델 실행 성능을 구분할 필요.
3. Fleet의 동의 기반 기기별 검증 → 단일 장비 벤치마크를 보완하고 실제 하드웨어에 맞는 구현 변형 선택을 개선할 근거 확보.

🧠 상세 정리

1. 브라우저 추론을 위한 커널 기반 공개

Hugging Face의 WebAI 팀은 브라우저 추론을 빠르고 사용하기 쉽게 만들기 위한 기반으로 @huggingface/kernels와 초기 207개 WebGPU 커널을 공개했다. 브라우저 추론 개선에는 모델을 브라우저에 적합하게 표현하는 작업, 런타임의 효율적인 실행 계획, 개별 GPU 연산의 최적화가 함께 필요하며 이번 발표는 그중 커널 계층을 다룬다. 커널은 Hub의 webgpu-kernels 조직 아래 개별 저장소로 배포되고, Apache-2.0 라이선스를 사용하며 다양한 기계학습 구조와 작업에 필요한 연산을 포함한다. 함께 공개한 Fleet은 사용자의 브라우저에서 커널을 실행하고 정확성과 성능을 평가하는 도구다. 이번 구성은 연산 구현의 배포, 애플리케이션에서의 실행, 실제 기기에서의 검증을 연결해 브라우저 로컬 추론의 하위 기반을 개선하려는 접근이다.

2. 이식성과 성능을 구분해야 하는 이유

브라우저에서 실행되는 모델은 결국 행렬 곱셈, 정규화, 합성곱, 어텐션 기초 연산, 양자화, 데이터 배치 변환 같은 GPU 연산의 연속으로 처리된다. WebGPU는 현대 브라우저에서 사용할 수 있는 이식 가능한 API를 제공하고, WGSL은 실제 연산을 수행하는 셰이더의 공통 언어를 제공한다. 그러나 같은 연산과 출력을 구현한 셰이더라도 작업 그룹 크기, 메모리 접근 방식, 벡터화, 자료형, 연산 융합 전략에 따라 가속기별 성능이 크게 달라질 수 있다. 최적의 구현은 입력 형상뿐 아니라 기기, 브라우저, 사용 가능한 WebGPU 기능에 따라서도 달라진다. 따라서 커널을 개별적으로 검색하고 시험하고 벤치마크하며 버전 관리할 수 있게 하면, 상위 계층의 안정적인 계약을 유지하면서 실제 실행을 담당하는 기반을 독립적으로 개선할 수 있다.

3. 셰이더를 재사용 가능한 패키지로 구성

각 커널 저장소에는 연산의 의미, 입력과 출력, 속성, 지원 자료형, 소스 파일, 바로 실행할 수 있는 사용 예제를 설명하는 커널 카드가 포함된다. 예시인 ai.onnx.Add는 다방향 브로드캐스팅을 지원하는 원소별 덧셈으로, 잔차 연결이나 편향 추가 등에 쓰이며 카드에서 입력과 출력 형상 및 구현 변형을 확인할 수 있다. manifest.json은 입력·출력·속성·자료형 제약·형상 도출 규칙을 정의하는 기준이고, metadata.json은 커널 식별자와 다이제스트 및 출처 정보를 기록한다. test.json은 정확성 사례를, bench.json은 벤치마크와 튜닝 사례를 담으며, *.wgsl.jinja 파일은 요청과 기기에 맞는 셰이더를 생성하는 매개변수화된 구현을 제공한다. 이 구성 덕분에 개발자는 WGSL을 직접 읽지 않고도 인터페이스를 살펴볼 수 있고, 구현과 함께 제공되는 검증 자료 및 명시적인 배포 버전을 활용할 수 있다.

4. 로더의 호출 방식과 계약 버전

@huggingface/kernels는 npm의 preview 패키지로 설치하며, 실행하려면 브라우저·운영체제·GPU·드라이버 조건에 따라 제공되는 WebGPU 지원이 필요하다. getKernel에 Hub 저장소 ID와 계약 버전을 전달한 뒤, 반환된 함수에 자료형이 지정된 입력 데이터와 텐서 형상을 넣는 방식으로 사용한다. 덧셈 예제에서는 형상 [2, 3]의 입력에 형상 [3]의 입력을 브로드캐스팅하고, 로더가 manifest 계약과 입력을 바탕으로 출력 형상 및 논리적 자료형을 도출해 출력 메모리를 자동 할당한다. 여섯 개 실수의 덧셈에서는 GPU 왕복 비용이 계산 비용보다 크지만, 같은 호출 방식은 최적화 효과가 나타나는 ai.onnx.MatMul 같은 무거운 연산에도 적용된다. Add 커널에는 동일 형상, 벡터화된 브로드캐스팅, 스칼라 처리, 일반 브로드캐스팅용 변형이 있어 호출과 기기에 맞춰 선택할 수 있다. version: 1은 공개된 커널 계약의 버전이며 ONNX opset, 연산자의 since_version, 모델 리비전과 별개이므로 구현이 바뀌어도 자바스크립트 측 계약을 안정적으로 유지할 수 있다.

5. Apple M4에서 확인한 연산별 성능

성능 비교는 Apple M4 GPU에서 ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a의 ORT WebGPU를 대상으로 진행됐다. 전체 207개 연산의 1,756개 테스트 사례에서 시작해, 양쪽 출력이 일치하고 신뢰할 수 있는 실행 시간을 얻은 809개 사례를 최종 비교에 사용했다. 이 범위에서 공개 커널은 기하평균 2.57배, 중앙값 1.90배 빨랐으며, 사례별로는 629승·176패·4무를 기록했다. 대표 연산별 표에서는 Add가 5개 사례에서 3.52배, MatMul이 29개 사례에서 1.14배, Softmax가 12개 사례에서 2.11배, LayerNormalization이 6개 사례에서 2.22배의 속도 향상을 보였다. 따라서 결과는 비교 대상 전반에서 성능 개선이 있었음을 보여주지만, 모든 연산과 모든 입력에서 동일한 배율로 빨라졌다는 의미는 아니다.

6. 극단적인 개선 사례와 측정의 한계

일부 특수 사례에서는 일반적인 결과보다 훨씬 큰 차이가 나타났는데, 크기 4096의 이중 선형 Einsum 식 i,ij,j는 공개 커널에서 0.136밀리초, ORT WebGPU에서 1,396밀리초가 걸려 10,000배 이상 빨랐다. 형상 [256, 4096]의 행 단위 CumSum도 0.016밀리초 대 4.784밀리초로 301배의 속도 향상을 보였으며, 원문은 이를 일반 구현이 느린 실행 경로에 진입할 때 특화 커널의 효과를 보여주는 예외적 사례로 설명한다. 측정 대상은 GPU 자체에서 수행한 작업으로 한정했고, 커널 로딩, 세션 생성, 입력 업로드, 셰이더 컴파일, 출력 회수 비용은 제외했다. 매우 짧은 작업은 측정이 어렵고 작은 사례는 GPU 캐시의 영향을 받을 수 있으므로 수치를 모든 애플리케이션에 대한 성능 약속으로 해석할 수 없다. 또한 전체 모델이 아닌 개별 연산의 결과이며 GPU와 브라우저에 따라 실제 성능이 달라지고, Hugging Face는 ONNX Runtime 팀과 개선 사항을 업스트림에 반영하는 작업도 진행하고 있다.

7. Fleet을 통한 실제 기기 검증

WebGPU 성능은 GPU뿐 아니라 브라우저와 드라이버에 따라서도 달라지므로, 한 대의 장비에서 얻은 결과만으로 전체 환경을 설명하기 어렵다. Fleet은 누구나 브라우저에서 커널의 정확성과 성능을 검사하고 자신의 하드웨어에서 어떻게 동작하는지 확인할 수 있도록 제공된다. 사용자가 동의하면 각 실행에서 나온 증거가 비공개로 기여되며, 이는 일반적인 시험실만으로는 다루기 어려운 실제 기기 범위를 보완한다. 수집된 증거는 잘못된 출력이나 비정상적으로 느린 사례 등 기기별 문제를 발견하고, 구현 변형을 비교하며, 적절한 변형을 고르는 규칙을 개선하는 데 쓰인다. 이 방식은 단일 벤치마크 수치를 확대 해석하기보다 다양한 실제 환경의 검증 결과를 축적해 커널의 속도와 신뢰성을 개선하려는 발표의 핵심 연결 고리다.

8. 공유 기반과 후속 확장 방향

초기 207개 커널은 최종 범위가 아니라 출발점이며, Hub에 커널을 독립적으로 게시하면 계약 검토, 구현 비교, 정확성 검사 재현, 성능 개선을 위한 공통 공간이 생긴다. 개발자는 모든 런타임에 셰이더를 직접 내장하지 않고도 이 공개 자산을 활용할 수 있으며, 사용자 정의 WebGPU 커널이나 자체 런타임을 만드는 과정에서 참조 구현으로 삼을 수도 있다. Hub의 Kernels 페이지에서는 WebGPU 커널을 CUDA, ROCm, Metal 등 다른 플랫폼의 커널과 함께 검색하고 필터링하고 정렬할 수 있다. 전체 구조에서 저장소는 투명한 버전별 연산 계약을 제공하고, @huggingface/kernels는 자바스크립트 실행을 연결하며, Fleet은 실제 기기의 검증 증거를 축적한다. Hugging Face는 이 기반을 상위 모델 도구와 연결하고 연산 지원 범위를 계속 확대해 WebAI 생태계에서 빠른 로컬 추론을 더 쉽게 사용할 수 있도록 하겠다는 방향을 제시했다.

🧾 핵심 주장 / 시사점

• 연산 계약, 구현, 검증 사례를 함께 배포하는 방식은 커널 최적화를 상위 런타임과 분리하면서도 동작을 재현하고 검토할 수 있게 한다.
• 평균적인 성능 향상과 특수 사례의 극단적인 개선은 구분해서 해석해야 하며, 개별 GPU 연산의 속도만으로 전체 모델의 사용자 체감 성능을 판단할 수 없다.
• Fleet의 가치는 벤치마크 참여 수 자체보다 다양한 기기에서 오류와 느린 구현을 발견하고 변형 선택을 개선할 근거를 확보하는 데 있다.

✅ 액션 아이템

• @huggingface/kernels 적용 대상 브라우저의 WebGPU 지원 여부와 사용할 커널의 계약 버전 확인.
• Apple M4의 기하평균 2.57배 결과를 참고하되, 제외된 준비·전송 비용을 포함한 전체 모델 실행 성능 검증.
• Fleet으로 대상 기기의 정확성과 성능을 확인하고, 실행 증거의 비공개 기여 여부를 사용자 동의에 따라 결정.

❓ 열린 질문

• 적용 대상 브라우저는 WebGPU를 지원하며 필요한 연산이 207개 WebGPU 커널에 포함되는가?
• 로딩·입력 업로드·셰이더 컴파일·출력 회수 비용을 포함하면 전체 모델 실행 성능은 얼마나 개선되는가?
• Fleet으로 대상 GPU·브라우저를 검사했을 때 정확성 오류나 구현 변형별 성능 차이가 나타나는가?