WebAssembly 및 WebGPU 개선사항을 통해 웹에서 머신러닝 성능을 개선하는 방법을 알아보세요.
웹 기반 AI 추론
AI가 세상을 변화시키고 있다는 이야기를 들어보셨을 것입니다. 웹도 예외는 아닙니다.
올해 Chrome에는 맞춤 테마 만들기, 텍스트 초안 작성 지원 등 생성형 AI 기능이 추가되었습니다. 하지만 AI는 그 이상입니다. AI는 웹 애플리케이션 자체를 보강할 수 있습니다.
웹페이지에는 얼굴 인식, 동작 인식과 같은 비전, 오디오 분류 또는 언어 감지를 위한 지능형 구성요소를 삽입할 수 있습니다. 작년에는 웹상의 대규모 언어 모델에 대한 매우 인상적인 데모를 포함하여 생성형 AI가 큰 인기를 얻었습니다. 웹 개발자를 위한 실용적인 온디바이스 AI를 확인해 보세요.
웹상의 AI 추론은 현재 광범위한 기기에서 사용할 수 있으며, AI 처리는 사용자 기기의 하드웨어를 활용하여 웹페이지 자체에서 수행할 수 있습니다.
이 기능은 다음과 같은 이유로 강력한 효과를 발휘합니다.
- 비용 절감: 브라우저 클라이언트에서 추론을 실행하면 서버 비용이 크게 절감됩니다. 이 기능은 일반 쿼리보다 훨씬 더 많은 비용이 들 수 있는 생성형 AI 쿼리에 특히 유용할 수 있습니다.
- 지연 시간: 오디오나 동영상 애플리케이션과 같이 지연 시간에 특히 민감한 애플리케이션의 경우 모든 처리가 기기에서 발생하면 지연 시간이 줄어듭니다.
- 개인 정보 보호: 클라이언트 측에서 실행하면 개인 정보 보호를 강화해야 하는 새로운 유형의 애플리케이션을 출시하여 데이터를 서버에 전송할 수 없습니다.
현재 웹에서 AI 워크로드가 실행되는 방식
오늘날 애플리케이션 개발자와 연구원은 프레임워크를 사용하여 모델을 빌드하고, 모델은 Tensorflow.js 또는 ONNX Runtime Web과 같은 런타임을 사용하여 브라우저에서 실행하며, 런타임은 웹 API를 사용하여 실행합니다.
이러한 모든 런타임은 결국 JavaScript 또는 WebAssembly를 통해 CPU에서 실행되거나 WebGL 또는 WebGPU를 통해 GPU에서 실행됩니다.
머신러닝 워크로드
머신러닝 (ML) 워크로드는 연산 노드의 그래프를 통해 텐서를 푸시합니다. 텐서는 노드에 대해 대량의 계산을 수행하는 이러한 노드의 입력 및 출력입니다.
이는 다음과 같은 이유로 중요합니다.
- 텐서는 수십억 개의 가중치를 가질 수 있는 모델에서 계산을 수행하는 매우 큰 데이터 구조입니다.
- 확장 및 추론으로 데이터 동시 로드가 발생할 수 있습니다. 이는 텐서의 모든 요소에서 동일한 작업이 수행됨을 의미합니다.
- ML에는 정밀도가 필요하지 않습니다. 달에 착륙하려면 64비트 부동 소수점 숫자가 필요할 수 있지만 얼굴 인식에는 8비트 이하의 숫자만 있으면 됩니다.
다행히 칩 설계자들은 모델을 더 빠르고 멋지게 실행하며 모델을 전혀 실행할 수 있도록 하는 기능을 추가했습니다.
한편, WebAssembly 및 WebGPU 팀에서는 이러한 새로운 기능을 웹 개발자에게 노출하기 위해 노력하고 있습니다. 웹 애플리케이션 개발자라면 이러한 낮은 수준의 프리미티브를 자주 사용하지 않을 것입니다. 사용 중인 도구 모음 또는 프레임워크가 새로운 기능과 확장 프로그램을 지원할 것으로 예상되므로 인프라를 최소한의 변경만으로도 이점을 누릴 수 있습니다. 그러나 성능을 위해 애플리케이션을 수동으로 조정하려는 경우 이러한 기능은 작업과 관련이 있습니다.
WebAssembly
WebAssembly (Wasm)는 런타임에서 이해하고 실행할 수 있는 작고 효율적인 바이트 코드 형식입니다. 기본 하드웨어 기능을 활용하도록 설계되었기 때문에 기본에 가까운 속도로 실행할 수 있습니다. 코드는 메모리 안전의 샌드박스 환경에서 검증되고 실행됩니다.
Wasm 모듈 정보는 밀집 바이너리 인코딩으로 표현됩니다. 텍스트 기반 형식에 비해 디코딩이 빨라지고 로드 속도가 빨라지며 메모리 사용량이 줄어듭니다. 최신 아키텍처에 아직 일반적이지 않은 기본 아키텍처에 대해 가정하지 않는다는 점에서 이식성이 있습니다.
WebAssembly 사양은 반복되며 공개 W3C 커뮤니티 그룹에서 작업합니다.
바이너리 형식은 호스트 환경에 대해 가정하지 않으므로 웹이 아닌 임베딩에서도 잘 작동하도록 설계되었습니다.
애플리케이션은 한 번 컴파일하여 데스크톱, 노트북, 휴대폰 또는 브라우저가 있는 기타 기기 등 어디서나 실행할 수 있습니다. 자세한 내용은 Write once, run never run at WebAssembly(WebAssembly로 실현된 모든 곳에서 실행)를 확인하세요.
웹에서 AI 추론을 실행하는 대부분의 프로덕션 애플리케이션은 CPU 컴퓨팅 및 특수 목적 컴퓨팅과의 상호작용에 WebAssembly를 사용합니다. 네이티브 애플리케이션에서는 범용 컴퓨팅과 특수 목적 컴퓨팅에 모두 액세스할 수 있습니다. 애플리케이션이 기기 기능에 액세스할 수 있기 때문입니다.
웹에서는 이동성과 보안을 위해 어떤 프리미티브 세트가 노출되는지 신중하게 평가합니다. 이를 통해 웹의 접근성과 하드웨어에서 제공하는 최대 성능 사이의 균형을 유지할 수 있습니다.
WebAssembly는 CPU의 이동식 추상화이므로 모든 Wasm 추론은 CPU에서 실행됩니다. 성능이 가장 좋은 선택은 아니지만 CPU는 널리 사용할 수 있으며 대부분의 기기에서 대부분의 워크로드에서 작동합니다.
텍스트 또는 오디오 워크로드와 같은 작은 워크로드의 경우 GPU는 비용이 많이 듭니다. 최근 몇 가지 사례를 통해 Wasm을 제대로 선택해야 합니다.
- Adobe는 Tensorflow.js를 사용하여 웹용 Photoshop을 개선합니다.
- 웹 기반 최초의 Wasm 기반 동영상 효과 중 하나인 Google Meet에 배경 블러가 추가되었습니다.
- YouTube에는 몇 가지 증강 현실 효과가 있습니다.
- Google 포토에서는 온라인 편집 기능을 사용할 수 있습니다.
whisper-tiny, llama.cpp, 브라우저에서 실행되는 Gemma2B 등 오픈소스 데모에서 더 많은 내용을 확인할 수 있습니다.
애플리케이션에 대한 종합적인 접근 방식
특정 ML 모델, 애플리케이션 인프라, 사용자를 위해 전반적으로 의도한 애플리케이션 환경에 따라 프리미티브를 선택해야 합니다.
예를 들어 MediaPipe의 얼굴 특징 인식에서는 CPU 추론과 GPU 추론이 비슷하지만 (Apple M1 기기에서 실행됨), 편차가 훨씬 더 클 수 있는 모델도 있습니다.
ML 워크로드의 경우 가장 많이 요청된 개선 사항을 개발하고 제공하기 위해 프레임워크 작성자와 애플리케이션 파트너의 의견을 경청하는 동시에 전체적인 애플리케이션 뷰를 고려합니다. 이는 크게 세 가지 카테고리로 나눌 수 있습니다.
- 성능에 중요한 CPU 확장 프로그램 노출
- 더 큰 모델 실행 지원
- 다른 Web API와의 원활한 상호 운용
컴퓨팅 속도 향상
WebAssembly 사양은 웹에 노출하는 특정 명령 집합만 포함합니다. 그러나 하드웨어는 새로운 명령을 계속해서 추가하고 있으며, 이로 인해 기본 및 WebAssembly 성능 간의 격차가 벌어집니다.
ML 모델에 항상 높은 수준의 정밀도가 필요한 것은 아니라는 점을 기억하세요. 느슨한 SIMD는 엄격한 비결정성 요구사항을 일부 줄여 성능 핫스팟인 일부 벡터 작업의 코드 생성 속도를 높이는 제안입니다. 또한 완화된 SIMD에는 기존 워크로드의 속도가 1.5~3배 빨라지는 새로운 내적 및 FMA 명령이 도입되었습니다. Chrome 114에서 출시되었습니다.
절반 정밀도 부동 소수점 형식은 단일 정밀도 값에 사용되는 32비트 대신 IEEE FP16에 16비트를 사용합니다. 단일 정밀도 값에 비해 절반 정밀도 값을 사용하면 메모리 요구사항이 줄어들고, 이를 통해 더 큰 신경망을 학습시키고 배포할 수 있고, 메모리 대역폭을 줄일 수 있다는 장점이 있습니다. 정밀도가 감소하면 데이터 전송 및 수학 연산 속도가 빨라집니다.
더 큰 모델
Wasm 선형 메모리에 대한 포인터는 32비트 정수로 표시됩니다. 이로 인해 힙 크기가 4GB로 제한되고(컴퓨터의 물리적 RAM이 이보다 훨씬 큰 경우), Wasm을 대상으로 하는 애플리케이션 코드는 32비트 포인터 크기와 호환되어야 하는 두 가지 결과가 있습니다.
특히 오늘날과 같은 대형 모델의 경우 이러한 모델을 WebAssembly로 로드하는 것이 제한될 수 있습니다. Memory64 제안서에서는 선형 메모리가 4GB보다 크고 네이티브 플랫폼의 주소 공간과 일치하도록 이러한 제한을 없앱니다.
Chrome에서 완전히 정상적으로 구현되고 있으며 올해 말 출시될 예정입니다. 지금은 chrome://flags/#enable-experimental-webassembly-features
플래그를 사용하여 실험을 실행하고 의견을 보내실 수 있습니다.
웹 상호 운용성 개선
WebAssembly는 웹에서 특수 목적 컴퓨팅을 위한 진입점이 될 수 있습니다.
WebAssembly를 사용하여 GPU 애플리케이션을 웹으로 가져올 수 있습니다. 즉, 기기에서 실행할 수 있는 동일한 C++ 애플리케이션을 약간만 수정하여 웹에서도 실행할 수 있습니다.
Wasm 컴파일러 도구 모음인 Emscripten에는 이미 WebGPU 바인딩이 있습니다. 이는 웹에서 AI 추론의 진입점이므로 Wasm이 나머지 웹 플랫폼과 원활하게 상호 운용되는 것이 중요합니다. Google은 이 분야에서 몇 가지 제안을 진행하고 있습니다.
JavaScript 프로미스 통합 (JSPI)
일반적인 C 및 C++ (많은 다른 언어 포함) 애플리케이션은 일반적으로 동기 API에 대해 작성됩니다. 즉, 작업이 완료될 때까지 애플리케이션 실행이 중지됩니다. 이러한 차단 애플리케이션은 일반적으로 비동기를 인식하는 애플리케이션보다 더 직관적으로 작성할 수 있습니다.
비용이 많이 드는 작업이 기본 스레드를 차단하면 I/O가 차단될 수 있으며 버벅거림이 사용자에게 표시됩니다. 네이티브 애플리케이션의 동기 프로그래밍 모델과 웹의 비동기 모델 간에 불일치가 있습니다. 이는 특히 포팅에 비용이 많이 드는 기존 애플리케이션의 경우에 문제가 됩니다. Emscripten은 Asyncify를 사용하여 이 작업을 수행하는 방법을 제공하지만, 코드 크기가 크고 비효율적이기 때문에 항상 최선의 선택은 아닙니다.
다음 예는 덧셈을 위해 JavaScript 프로미스를 사용하여 피보나치를 계산합니다.
long promiseFib(long x) {
if (x == 0)
return 0;
if (x == 1)
return 1;
return promiseAdd(promiseFib(x - 1), promiseFib(x - 2));
}
// promise an addition
EM_ASYNC_JS(long, promiseAdd, (long x, long y), {
return Promise.resolve(x+y);
});
emcc -O3 fib.c -o b.html -s ASYNCIFY=2
이 예에서는 다음 사항에 유의하세요.
EM_ASYNC_JS
매크로는 필요한 모든 글루 코드를 생성하므로 일반 함수에서와 마찬가지로 JSPI를 사용하여 프로미스 결과에 액세스할 수 있습니다.- 특수 명령줄 옵션
-s ASYNCIFY=2
그러면 JSPI를 사용하여 프로미스를 반환하는 JavaScript 가져오기와 인터페이스하는 코드를 생성하는 옵션이 호출됩니다.
JSPI, 사용 방법, 이점에 대한 자세한 내용은 v8.dev에 WebAssembly JavaScript Promise Integration API 소개를 참고하세요. 현재의 오리진 트라이얼에 대해 알아보세요.
메모리 제어
개발자는 Wasm 메모리를 제어할 수 없습니다. 모듈이 자체 메모리를 소유합니다 이 메모리에 액세스해야 하는 모든 API는 복사하거나 복사해야 하며, 그러면 사용량이 실제로 증가할 수 있습니다. 예를 들어 그래픽 애플리케이션은 각 프레임에 대해 복사 및 복사가 필요할 수 있습니다.
메모리 제어 제안서의 목표는 Wasm 선형 메모리를 더 세밀하게 제어하고 애플리케이션 파이프라인 전반의 사본 수를 줄이는 것입니다. 이 제안은 1단계이며 Chrome의 JavaScript 엔진인 V8로 프로토타입을 제작하여 표준의 발전을 알리고 있습니다.
적합한 백엔드 결정
CPU가 널리 보급되어 있지만 항상 최상의 선택은 아닙니다. GPU 또는 가속기의 특수 목적 컴퓨팅은 특히 대형 모델과 고급 기기에서 훨씬 더 높은 성능을 제공할 수 있습니다. 이는 네이티브 애플리케이션과 웹 애플리케이션에 모두 적용됩니다.
어떤 백엔드를 선택할지는 애플리케이션, 프레임워크, 도구 모음은 물론 성능에 영향을 미치는 기타 요인에 따라 달라집니다. 그렇긴 하지만, 우리는 핵심 Wasm이 나머지 웹 플랫폼, 특히 WebGPU와 잘 작동할 수 있도록 하는 제안에 계속 투자하고 있습니다.