WebAssembly と WebGPU の強化により、ウェブ上での ML のパフォーマンスがどのように向上するかについて学びます。
ウェブ上の AI 推論
誰もが「AI が世界を変えつつある」という話を耳にしたことがあるでしょう。ウェブも例外ではありません。
今年 Chrome には、カスタムテーマの作成や最初の下書き作成の支援など、生成 AI 機能が追加されました。しかし、AI はそれだけではありません。AI はウェブ アプリケーション自体を強化できます。
ウェブページにインテリジェントなコンポーネントを埋め込んで、顔の抽出やジェスチャーの認識、音声分類、言語検出などを行うことができます。昨年は、ウェブ上の大規模言語モデルの素晴らしいデモなど、生成 AI が注目を集めるようになりました。ウェブ デベロッパー向けの実用的なオンデバイス AI もぜひご覧ください。
現在、ウェブ上の AI 推論は、多くのデバイスで利用できます。AI 処理はユーザーのデバイス上のハードウェアを活用して、ウェブページ自体で行うことができます。
この機能が優れている理由はいくつかあります。
- 費用の削減: ブラウザ クライアントで推論を実行すると、サーバー費用が大幅に削減されます。これは、通常のクエリよりも桁違いに高額になる可能性のある生成 AI クエリの場合に特に役立ちます。
- レイテンシ: オーディオ アプリケーションや動画アプリケーションなど、レイテンシの影響を受けやすいアプリケーションの場合、すべての処理をデバイス上で行うとレイテンシが短縮されます。
- プライバシー: クライアントサイドで実行すると、データをサーバーに送信できない、プライバシーの強化を必要とする新しいクラスのアプリケーションを利用できるようになる可能性もあります。
現在ウェブで AI ワークロードが実行されている方法
現在、アプリケーション デベロッパーや研究者はフレームワークを使用してモデルを構築し、モデルは Tensorflow.js や ONNX Runtime Web などのランタイムを使用してブラウザで実行し、ランタイムでは実行に Web API を使用しています。
これらのランタイムはすべて、最終的には、JavaScript や WebAssembly を介して CPU で実行され、WebGL または WebGPU を介して GPU で実行されることになります。
ML ワークロード
機械学習（ML）ワークロードは、コンピューティング ノードのグラフを通じてテンソルを push します。テンソルはノードの入力と出力であり、データに対して大量の計算を実行します。
このプロセスが重要な理由は、次のとおりです。
- テンソルは非常に大規模なデータ構造であり、数十億の重みを持つモデルで計算を実行します。
- スケーリングと推論がデータ並列処理につながる可能性があります。これは、テンソル内のすべての要素に対して同じオペレーションが実行されることを意味します。
- ML に精度は必要ありません。月面に着陸するには 64 ビットの浮動小数点数が必要になるかもしれませんが、顔認識には 8 ビット以下の数字で十分かもしれません。
幸いなことに、チップの設計者は、モデルの実行を高速化し、よりクールにし、さらにはモデルの実行を可能にする機能を追加しました。
一方、WebAssembly チームと WebGPU チームでは、これらの新機能をウェブ デベロッパーに公開するよう取り組んでいます。ウェブ アプリケーション デベロッパーにとって、これらの低レベルのプリミティブを頻繁に使用することはないでしょう。使用しているツールチェーンまたはフレームワークが新機能と拡張機能をサポートするため、インフラストラクチャの変更を最小限に抑えつつメリットを得ることができます。ただし、アプリケーションのパフォーマンスを手動で調整する場合は、これらの機能が作業に関連しています。
WebAssembly
WebAssembly（Wasm）は、ランタイムが理解して実行できるコンパクトで効率的なバイトコード形式です。基本的なハードウェア機能を活用するように設計されているため、ネイティブに近い速度で実行できます。コードは検証され、メモリセーフのサンドボックス環境で実行されます。
Wasm モジュール情報は高密度のバイナリ エンコードで表されます。テキストベースの形式に比べ、デコードの高速化、読み込みの高速化、メモリ使用量の削減が可能になります。基盤となるアーキテクチャについて、最新のアーキテクチャではまだ一般的ではないことを前提としないという点で、ポータブルです。
WebAssembly の仕様は反復的であり、オープンな W3C コミュニティ グループで作業されています。
バイナリ形式はホスト環境を前提としないため、ウェブ以外のエンベディングでも適切に動作するように設計されています。
アプリケーションを一度コンパイルすれば、デスクトップ、ノートパソコン、スマートフォン、その他のブラウザ搭載デバイスなど、どこでも実行できます。詳しくは、WebAssembly で実現した一度の記述で、どこでも実行が可能になるをご覧ください。
ウェブ上で AI 推論を実行するほとんどの本番環境アプリケーションは、CPU コンピューティングと専用コンピューティングとのインターフェースの両方で、WebAssembly を使用します。ネイティブ アプリではデバイスの機能にアクセスできるため、汎用コンピューティングと専用コンピューティングの両方にアクセスできます。
ウェブでは、ポータビリティとセキュリティのために、どのプリミティブが公開されるかを慎重に評価しています。これにより、ウェブへのアクセスのしやすさと、ハードウェアが持つ最大限のパフォーマンスとのバランスが取れています。
WebAssembly は CPU の移植可能な抽象化であるため、すべての Wasm 推論は CPU で実行されます。これは最もパフォーマンスの高い選択肢ではありませんが、CPU は広く利用でき、ほとんどのデバイスのほとんどのワークロードで動作します。
テキストや音声などの小規模なワークロードでは、GPU が高コストになります。Wasm が正しい選択肢である最近の例がいくつかあります。
- Adobe は Tensorflow.js を使用して、Photoshop をウェブ向けに拡張しています。
- Google Meet に背景のぼかし機能が追加されました。これは、Wasm ベースの初のウェブ動画エフェクトの一つです。
- YouTube には、拡張現実効果がいくつか用意されています。
- Google フォトではオンライン編集が可能です。
whisper-tiny、llama.cpp、ブラウザで動作する Gemma2B などのオープンソース デモで、さらに多くの情報をご覧いただけます。
アプリケーションに対して包括的なアプローチを採用
プリミティブは、特定の ML モデル、アプリケーション インフラストラクチャ、ユーザーが意図する全体的なアプリケーション エクスペリエンスに基づいて選択する必要があります。
たとえば、MediaPipe の顔ランドマーク検出では、CPU 推論と GPU 推論は同等（Apple M1 デバイスで実行）ですが、ばらつきが著しく大きくなる可能性があるモデルがあります。
ML ワークロードに関しては、フレームワーク作成者やアプリケーション パートナーの意見に耳を傾けながら、アプリケーションの完全なビューを検討し、最もご要望の多かった機能強化を開発して提供します。これらは大きく 3 つのカテゴリに分類されます。
- パフォーマンスに不可欠な CPU 拡張機能を公開する
- より大規模なモデルの実行を可能にする
- 他のウェブ API とのシームレスな相互運用を実現
コンピューティングの高速化
現状では、WebAssembly 仕様には、ウェブに公開する特定の命令セットのみが含まれています。しかし、ハードウェアは新しい命令を追加し続けており、ネイティブと WebAssembly のパフォーマンスの差が大きくなっています。
ML モデルに高いレベルの精度は必ずしも必要というわけではありません。Relaxed SIMD は、厳密で非決定性に関する要件の一部を軽減する提案であり、パフォーマンスのホットスポットとなる一部のベクトル操作のコード生成を高速化します。さらに、Relax SIMD は新しいドット積命令と FMA 命令を導入し、既存のワークロードを 1.5 ～ 3 倍高速化します。これは Chrome 114 で実装されました。
半精度浮動小数点形式では、単精度値に使用される 32 ビットではなく、IEEE FP16 に 16 ビットを使用します。単精度値を使用する場合と比較して、半精度値を使用することにはいくつかの利点があります。メモリ要件が削減されるため、大規模なニューラル ネットワークのトレーニングとデプロイが可能になり、メモリ帯域幅が減少します。精度が低下すると、データ転送と数学演算が高速化されます。
より大規模なモデル
Wasm リニアメモリへのポインタは 32 ビット整数として表されます。これには 2 つの影響があります。1 つはヒープサイズが 4 GB に制限される（コンピュータの物理 RAM がそれよりもはるかに大きい場合）。もう 1 つは、Wasm をターゲットとするアプリケーション コードは 32 ビットのポインタ サイズと互換性がある必要があります。
特に、現在のような大規模モデルでは、これらのモデルを WebAssembly に読み込む場合は制限が厳しい場合があります。Memory64 提案では、リニアメモリを 4 GB より大きくしてネイティブ プラットフォームのアドレス空間と一致するようにすることで、こうした制限を取り除きます。
Chrome には完全に機能しており、年内にリリースされる予定です。現時点では、フラグ chrome://flags/#enable-experimental-webassembly-features を指定してテストを実施し、フィードバックをお寄せください。
ウェブの相互運用性の向上
WebAssembly は、ウェブ上での専用コンピューティングのエントリ ポイントになる可能性があります。
WebAssembly を使用すると、GPU アプリケーションをウェブに導入できます。つまり、デバイス上で実行できるのと同じ C++ アプリケーションを、若干の変更を加えてウェブでも実行できます。
Wasm コンパイラ ツールチェーンである Emscripten にはすでに WebGPU のバインディングがあります。ウェブでの AI 推論のエントリ ポイントであるため、Wasm は他のウェブ プラットフォームとシームレスに相互運用できることが重要です。現在、この分野でいくつかの提案に取り組んでいます。
JavaScript Promise 統合（JSPI）
一般的な C / C++（およびその他の多くの言語）アプリケーションは、一般的に同期 API に対して記述されます。つまり、アプリケーションはオペレーションが完了するまで実行を停止します。通常、このようなブロック アプリケーションは、非同期対応のアプリケーションよりも直感的に作成できます。
コストの高いオペレーションがメインスレッドをブロックすると、I/O がブロックされ、ジャンクがユーザーに表示されます。ネイティブ アプリケーションの同期プログラミング モデルとウェブの非同期モデルの間には、不一致があります。これは、移植に費用がかかるレガシー アプリケーションでは特に問題です。Emscripten は Asyncify でこの処理を行うための方法を提供しますが、コードサイズが大きく、効率が悪く、常に最適なオプションであるとは限りません。
次の例では、JavaScript の Promise で足し算を行って、フィボナッチを計算します。
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 を使用して Promise の結果にアクセスできます。- 特別なコマンドライン オプション
-s ASYNCIFY=2。これにより、JSPI を使用して Promise を返す JavaScript インポートとやり取りするコードを生成するオプションが呼び出されます。
JSPI の詳細、使用方法、メリットについては、v8.dev での WebAssembly JavaScript Promise Integration API の概要をご覧ください。現在のオリジン トライアルの詳細をご覧ください。
メモリ制御
デベロッパーが Wasm メモリを制御することはほとんどありません。モジュールは独自のメモリを所有します。このメモリにアクセスする必要がある API はすべてコピーインまたはコピーアウトする必要があり、この使用量は膨大になる可能性があります。たとえば、グラフィック アプリケーションでは、フレームごとにコピーインとコピーアウトしなければならない場合があります。
メモリ制御の提案は、Wasm リニアメモリをよりきめ細かく制御し、アプリケーション パイプライン全体でのコピー数を減らすことを目的としています。この提案はフェーズ 1 の段階です。現在、Chrome の JavaScript エンジンである V8 でプロトタイピングを行い、標準の進化についてお知らせしています。
最適なバックエンドを決定する
CPU はユビキタスですが、必ずしも最適な選択肢であるとは限りません。GPU やアクセラレータ上での専用コンピューティングは、特に大規模なモデルやハイエンド デバイスの場合、桁違いに高いパフォーマンスを実現できます。これは、ネイティブ アプリケーションとウェブ アプリケーションの両方に当てはまります。
どのバックエンドを選択するかは、アプリケーション、フレームワーク、ツールチェーンのほか、パフォーマンスに影響するその他の要因によって異なります。とは言え、Google は Wasm コアが他のウェブ プラットフォーム、特に WebGPU とうまく連携できるようにする提案に引き続き投資していきます。