WebAssembly 및 WebGPU 개선사항이 웹에서 머신러닝 성능을 개선하는 방법을 알아봅니다.
웹상의 AI 추론
AI가 세상을 바꾸고 있다는 이야기를 모두 들어보셨을 겁니다. 웹도 예외는 아닙니다.
올해 Chrome에는 커스텀 테마 생성 또는 텍스트의 초안 작성 지원과 같은 생성형 AI 기능이 추가되었습니다. 하지만 AI는 그 이상입니다. AI는 웹 애플리케이션을 자체적으로 강화할 수 있습니다.
웹페이지에는 얼굴 선택, 동작 인식, 오디오 분류, 언어 감지와 같은 비전을 위한 지능형 구성요소를 삽입할 수 있습니다. 작년에 우리는 생성형 AI가 큰 인기를 얻었으며, 매우 인상적인 웹 기반 언어 모델의 몇 가지 데모가 소개되었습니다. 웹 개발자를 위한 실용적인 온디바이스 AI도 확인해 보세요.
오늘날 웹상의 AI 추론은 다양한 기기에서 사용할 수 있으며, AI 처리는 사용자 기기의 하드웨어를 활용하여 웹페이지 자체에서 수행될 수 있습니다.
이는 다음과 같은 이유로 강력한 효과를 발휘합니다.
- 비용 절감: 브라우저 클라이언트에서 추론을 실행하면 서버 비용이 크게 절감됩니다. 이는 일반 쿼리보다 훨씬 많은 비용이 들 수 있는 GenAI 쿼리에 특히 유용합니다.
- 지연 시간: 오디오 또는 동영상 애플리케이션과 같이 지연 시간에 특히 민감한 애플리케이션의 경우 모든 처리가 기기에서 이루어지면 지연 시간이 단축됩니다.
- 개인 정보 보호: 클라이언트 측에서 실행하면 개인 정보 보호 강화가 요구되는 새로운 유형의 애플리케이션을 사용할 수 있게 되어 데이터를 서버로 전송할 수 없게 됩니다.
오늘날 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 일단 한 번, WebAssembly로 최종적으로 실현된 모든 곳에서 실행을 참고하세요.
웹에서 AI 추론을 실행하는 대부분의 프로덕션 애플리케이션은 CPU 컴퓨팅 및 특수 목적 컴퓨팅과의 상호작용에 WebAssembly를 사용합니다. 네이티브 애플리케이션에서는 애플리케이션이 기기 기능에 액세스할 수 있으므로 범용 컴퓨팅과 특수 용도의 컴퓨팅에 모두 액세스할 수 있습니다.
웹에서는 이동성과 보안을 위해 어떤 프리미티브 세트가 노출되는지 신중하게 평가합니다. 이렇게 하면 웹의 접근성과 하드웨어에서 제공하는 최대 성능의 균형을 맞출 수 있습니다.
WebAssembly는 CPU의 이식 가능한 추상화이므로 모든 Wasm 추론은 CPU에서 실행됩니다. 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 워크로드의 경우 Google은 프레임워크 작성자 및 애플리케이션 파트너의 의견을 경청하면서 가장 많이 요청된 개선사항을 개발하고 제공하기 위해 전체적인 애플리케이션 뷰를 고려합니다. 이는 크게 3가지 카테고리로 분류됩니다.
- 성능에 중요한 CPU 확장 노출
- 더 큰 모델 실행 지원
- 다른 웹 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은 이 분야에서 몇 가지 다른 제안서를 준비하고 있습니다.
자바스크립트 프로미스 통합 (JSPI)
일반적인 C 및 C++ (및 기타 많은 언어) 애플리케이션은 일반적으로 동기 API를 대상으로 작성됩니다. 즉, 작업이 완료될 때까지 애플리케이션이 실행을 중지합니다. 이러한 차단 애플리케이션은 일반적으로 비동기를 인식하는 애플리케이션보다 작성하기가 더 직관적입니다.
비용이 많이 드는 작업이 기본 스레드를 차단하는 경우 I/O를 차단할 수 있으며 버벅거림이 사용자에게 표시됩니다. 네이티브 애플리케이션의 동기 프로그래밍 모델과 웹의 비동기 모델 사이에는 불일치가 있습니다. 이는 특히 포팅 비용이 많이 드는 레거시 애플리케이션에서 문제가 됩니다. Emscripten은 Asyncify를 사용하여 이 작업을 수행하는 방법을 제공하지만 코드 크기가 크고 효율적이지 않은 등 항상 최선의 옵션은 아닙니다.
다음 예는 덧셈을 위해 자바스크립트 프로미스를 사용하여 피보나치를 계산합니다.
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나 가속기의 특수 목적 컴퓨팅은 특히 대형 모델과 고급형 기기에서 훨씬 더 높은 성능을 제공할 수 있습니다. 이는 네이티브 애플리케이션과 웹 애플리케이션 모두에 해당합니다.
어떤 백엔드를 선택할지는 애플리케이션, 프레임워크, 도구 모음은 물론 성능에 영향을 미치는 기타 요소에 따라 달라집니다. 그렇더라도 Google은 코어 Wasm이 나머지 웹 플랫폼, 특히 WebGPU와 잘 작동할 수 있는 제안에 계속 투자하고 있습니다.