웹브라우저에서 GPU 가속 AI? Hugging Face가 207개 WebGPU 커널을 공개한 이유

브라우저 AI의 마지막 퍼즐, 커널 최적화

여러분, 혹시 브라우저에서 무거운 AI 모델을 실행해보셨나요? 분명 데모는 멋지게 동작하지만, 실사용하기에는 버벅임이 느껴지는 경험, 다들 있으실 겁니다. 이런 성능 저하의 핵심 원인 중 하나는 바로 브라우저가 GPU를 제대로 활용하지 못하기 때문입니다.

Hugging Face가 이 문제를 해결하기 위해 의미 있는 움직임을 시작했습니다. 바로 207개의 최적화된 WebGPU 커널 모음을 공개한 것입니다. 그리고 이 작업은 단순히 커널을 나열하는 수준을 넘어, AI 모델의 브라우저 실행 성능을 획기적으로 개선할 수 있는 토대를 마련했다는 점에서 주목할 만합니다. 이 글에서는 해당 커널 컬렉션의 특징과 실제 활용법을 자세히 분석해 보겠습니다.

왜 하필 '커널'부터 시작했을까?

브라우저에서 실행되는 AI 모델은 결국 행렬 곱셈, 정규화, 합성곱(Convolution) 등 일련의 GPU 연산의 연속입니다. WebGPU는 이러한 연산을 브라우저에서 실행할 수 있게 해주는 표준 API이며, WGSL은 GPU에서 실행되는 셰이더를 작성하는 언어입니다.

하지만 문제는 '휴대성(Portability)'이 '성능(Portability)'을 보장하지 않는다는 점입니다. 동일한 연산을 구현하더라도 GPU 아키텍처에 따라 성능이 크게 달라질 수 있습니다. 작업 그룹 크기, 메모리 접근 패턴, 벡터화, 데이터 타입 등 수많은 요소가 성능에 영향을 미치기 때문입니다.

Hugging Face가 커널부터 최적화하기 시작한 이유는, 상위 레벨 런타임의 효율성이 결국 디스패치하는 개별 연산의 효율성에 달려있기 때문입니다. 커널을 개별적으로 발견, 테스트, 벤치마킹, 버전 관리할 수 있게 만들면, 상위 레이어를 위한 안정적인 계약을 유지하면서 기반을 독립적으로 개선할 수 있습니다. 이는 마치 건물의 기초 공사를 튼튼히 하는 것과 같습니다. 상위 구조물을 아무리 화려하게 지어도 기초가 약하면 소용없으니까요.

단순한 셰이더가 아닌, '커널 저장소'의 개념

이번에 공개된 각 커널은 단순한 WGSL 셰이더 파일 하나가 아닙니다. 각 커널은 자체 저장소와 상세한 문서(카드)를 가지며, 여기에는 연산의 의미, 입력/출력, 속성, 지원 데이터 타입, 소스 파일, 그리고 바로 실행 가능한 @huggingface/kernels 예제가 포함되어 있습니다.

예를 들어, ai.onnx.Add 커널은 다차원 브로드캐스팅을 지원하는 요소별 덧셈 연산입니다. 이는 잔차 연결(Residual Connection)이나 바이어스 추가 등 신경망의 가장 기본적인 연산 중 하나이죠. 커널 카드에는 두 입력값, 브로드캐스팅된 출력 형태, 지원 데이터 타입, 그리고 다양한 형태와 장치에 사용 가능한 변형이 문서화되어 있습니다.

저장소 구조 살펴보기

커널 저장소는 다음과 같은 구조로 이루어져 있어, 구현을 이해하고 평가하는 데 필요한 모든 정보를 제공합니다.

• manifest.json: 연산 계약의 핵심입니다. 입력, 출력, 속성, 타입 제약 조건, 형태 유도 규칙을 정의합니다.
• metadata.json: 커널 식별자, 해시, 출처 정보를 기록합니다.
• test.json: 구현이 예상된 동작과 일치하는지 확인하는 정확성 테스트 케이스를 포함합니다.
• bench.json: 커널을 평가하는 데 사용되는 벤치마크 및 튜닝 케이스를 포함합니다.
• *.wgsl.jinja: 특정 요청과 장치에 맞는 셰이더를 생성하는 데 사용되는 매개변수화된 WGSL 구현 파일입니다.

이러한 구조는 단순한 셰이더를 재사용 가능한 소프트웨어 산출물로 승격시킵니다. 인터페이스는 WGSL을 읽지 않아도 파악할 수 있으며, 정확성 및 성능 테스트 케이스가 구현과 함께 제공되고, 게시된 버전은 버전 관리가 되지 않은 파일 URL에 의존하지 않고 명시적으로 로드될 수 있습니다.

핵심 코드: Hub에서 커널 로드하고 실행하기

이제 실제로 어떻게 사용하는지 코드로 확인해보겠습니다. npm 패키지를 설치하고, WebGPU 지원 여부를 확인한 후, 커널을 불러와 실행하는 과정입니다.

// 1. npm 패키지 설치
// npm install @huggingface/kernels@preview

// WebGPU 지원 여부 확인
if ("gpu" in navigator) {
  console.log("WebGPU를 지원하는 브라우저입니다.");
} else {
  console.log("WebGPU를 지원하지 않는 브라우저입니다.");
}

// 2. @huggingface/kernels 라이브러리에서 getKernel 함수 import
import { getKernel } from "@huggingface/kernels";

// 3. Hub에서 커널 로드 (저장소 ID와 버전 지정)
const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });

// 4. 타입이 지정된 입력 데이터와 텐서 형태를 인자로 커널 실행
const { c } = await add({
  a: {
    data: new Float32Array([1, 2, 3, 4, 5, 6]),
    shape: [2, 3],
  },
  b: {
    data: new Float32Array([10, 20, 30]),
    shape: [3],
  },
});

console.log("결과:", c.data); // Float32Array([11, 22, 33, 14, 25, 36])

두 번째 입력값 b가 첫 번째 차원에 걸쳐 브로드캐스팅되어 [2, 3] 형태의 출력값을 생성합니다. 로더는 매니페스트 계약과 입력값을 기반으로 출력 형태와 논리적 데이터 타입을 유도하고, c를 자동으로 할당합니다. 이처럼 여섯 개의 부동 소수점 덧셈은 의도적으로 가장 작은 데모이며, 이 크기에서는 GPU 왕복 비용이 계산 비용보다 훨씬 큽니다. 중요한 것은 호출 패턴이 행렬 곱셈(ai.onnx.MatMul)과 같은 무거운 연산에서도 동일하게 유지된다는 점입니다. 저장소 ID와 입력값만 변경하면 됩니다.

성능은 얼마나 개선되었을까?

Hugging Face는 자체 벤치마크 결과를 공개했습니다. Apple M4 GPU에서 ONNX Runtime Web (ORT WebGPU)과 비교했을 때, 자체 커널 컬렉션이 기하 평균 2.57배, 중앙값 1.90배 더 빠른 성능을 보여주었습니다. 총 809개의 비교 케이스 중 629건에서 승리했습니다.

주요 연산별 성능 비교

일부 개별 케이스에서는 더 극적인 결과가 나왔습니다. 특히 4096 크기의 이중 선형 Einsum 연산은 0.136ms로 실행되어 ORT WebGPU의 1,396ms보다 10,000배 이상 빨랐습니다. 이는 일반적인 구현이 느린 경로에 직면했을 때 특수 커널이 얼마나 큰 이점을 제공할 수 있는지 보여주는 사례입니다. 다만, 이는 극단적인 케이스이며 모든 애플리케이션에서 기대할 수 있는 수준은 아닙니다.

Fleet: 커뮤니티 기반 벤치마킹의 시작

WebGPU 성능은 GPU, 브라우저, 드라이버에 따라 크게 달라집니다. 따라서 한 대의 머신에서의 결과는 전체 이야기를 말해주지 못합니다. Hugging Face는 이 문제를 해결하기 위해 Fleet이라는 브라우저 기반 벤치마킹 및 테스트 도구를 함께 공개했습니다.

Fleet을 사용하면 누구나 브라우저에서 정확성 및 성능 검사를 실행하고, 자신의 하드웨어에서 커널이 어떻게 동작하는지 확인할 수 있습니다. 사용자가 동의하면 각 실행은 장치별 실패를 발견하고, 변형을 비교하며, 선택 규칙을 개선하는 데 도움이 되는 증거를 비공개로 기여하게 됩니다. 궁극적인 목표는 광범위한 실제 커버리지를 활용하여 모든 사용자를 위해 커널을 더 빠르고 안정적으로 만드는 것입니다.

현실적 적용과 한계, 그리고 앞으로의 방향

이번 Hugging Face의 접근 방식은 브라우저 AI 생태계에 중요한 이정표를 세웠습니다. 커널을 독립적으로 게시하고, 명확한 계약과 재현 가능한 증거를 제공함으로써, 커뮤니티가 협력하여 기반을 함께 개선할 수 있는 길을 열었습니다.

다만, 몇 가지 한계점도 존재합니다.

• 측정 범위: 벤치마크는 GPU에서 실행되는 작업 시간만 측정했으며, 커널 로딩, 세션 생성, 셰이더 컴파일 등 오버헤드는 제외했습니다. 실제 애플리케이션에서는 이러한 요소들이 큰 비중을 차지할 수 있습니다.
• 개별 연산 결과: 이번 결과는 개별 연산에 대한 것이며, 전체 모델의 성능은 GPU와 브라우저에 따라 달라질 수 있습니다.
• WebGPU 지원 환경: WebGPU는 아직 모든 브라우저와 기기에서 지원되지 않습니다. 지원 범위가 넓어질수록 이 라이브러리의 활용도는 더욱 높아질 것입니다.

하지만 그럼에도 불구하고, 이 기술이 가져올 변화는 분명합니다. 특히 복잡한 AI 모델을 서버 없이 클라이언트에서만 실행하려는 시도가 늘어나고 있는 상황에서, WebGPU 커널 최적화는 필수적인 요소로 자리 잡을 것입니다.

AI 에이전트 신뢰성과의 연결점

흥미롭게도, 이번 커널 최적화 작업은 AI 에이전트의 신뢰성을 확보하는 것과도 맞닿아 있습니다. AI 모델이 브라우저에서 빠르고 안정적으로 실행될수록, 사용자에게 더 나은 경험을 제공하고, 더 복잡한 작업을 안전하게 처리할 수 있는 기반이 마련되기 때문입니다. NVIDIA 검증된 에이전트 스킬 AI 에이전트 신뢰성 확보의 새로운 기준에서 논의되는 것처럼, 에이전트의 성능과 안정성은 결국 하부 인프라의 효율성에 크게 의존합니다.

또한 이번에 공개된 접근 방식은 대규모 AI 시스템을 설계할 때의 중요한 원칙을 보여줍니다. 개별 구성 요소를 독립적으로 테스트하고, 버전 관리하며, 성능을 측정하는 것은 비단 브라우저 AI뿐만 아니라, 암 진단을 혁신하는 AI, Artera의 AWS 기반 확장 가능한 아키텍처 설계와 같은 헬스케어 AI 시스템에서도 핵심적인 요소입니다.

결론: 브라우저 AI의 새로운 지평

Hugging Face가 공개한 207개의 WebGPU 커널과 Fleet 도구는 브라우저 AI의 판도를 바꿀 잠재력을 지니고 있습니다. 이는 단순한 성능 개선을 넘어, 커뮤니티가 함께 성능과 정확성 증거를 축적하고 개선해 나가는 새로운 개발 패러다임을 제시합니다.

다음 단계로는 WebGPU 커널 컬렉션을 직접 탐색해보고, 자신의 하드웨어에서 Fleet을 실행해 결과를 확인해보는 것을 추천합니다. 또한, @huggingface/kernels 라이브러리를 사용해 간단한 프로젝트에 적용해보면서 브라우저 AI의 가능성을 체감해보시기 바랍니다. 이는 단순한 기술 소개를 넘어, 더 빠르고 민주화된 AI 환경을 위한 초석이 될 것입니다.