WebAssembly と WebGPU の拡張機能により、ウェブ上での機械学習のパフォーマンスがどのように向上するかについて説明します。
ウェブでの 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 ワークロードは、計算ノードのグラフを介してテンソルをプッシュします。テンソルはこれらのノードの入力と出力であり、データに対して大量の計算を実行します。
これは、次の理由により重要です。
- テンソルは非常に大規模なデータ構造であり、数十億の重みを持つことができるモデルで計算を行います。
- スケーリングと推論は、データ並列処理につながる場合があります。つまり、テンソル内のすべての要素に対して同じオペレーションが実行されます。
- 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 for web を強化します。
- Google Meet に背景のぼかし機能が追加されました。これは、Wasm ベースのウェブ初の動画エフェクトの一つです。
- YouTube には、拡張現実エフェクトがいくつか用意されています。
- Google フォトではオンライン編集が可能です。
whisper-tiny、llama.cpp、ブラウザで実行されている Gemma2B などのオープンソース デモで、さらに詳しい情報を入手できます。
アプリケーションに対する総合的なアプローチ
プリミティブは、特定の ML モデル、アプリケーション インフラストラクチャ、ユーザーが期待する全体的なアプリケーション エクスペリエンスに基づいて選択する必要があります。
たとえば、MediaPipe の顔ランドマーク検出では、CPU 推論と GPU 推論は同等です（Apple M1 デバイスで実行）。ただし、分散が大幅に大きくなる可能性があるモデルもあります。
ML ワークロードに関しては、フレームワーク作成者やアプリケーション パートナーの意見に耳を傾けながら、リクエストの多い拡張機能を開発、提供するために、完全なアプリケーション ビューを検討します。これらは大きく 3 つのカテゴリに分類されます。
- パフォーマンスにとって重要な CPU 拡張機能を公開
- より大規模なモデルの実行を可能にする
- 他のウェブ API とのシームレスな相互運用を実現
コンピューティングの高速化
現在の WebAssembly 仕様には、Google がウェブに公開している特定の手順のみが含まれています。しかし、ハードウェアはさらに新しい命令を追加し、ネイティブと WebAssembly のパフォーマンスの差を広げています。
ML モデルに必ずしも高い精度が必要とは限りません。緩和 SIMD は、厳しい非決定性要件の一部を軽減する提案であり、パフォーマンスのホットスポットである一部のベクトル操作の Codegen を高速化します。さらに、緩和 SIMD では、既存のワークロードを 1.5 ～ 3 倍高速化する新しいドット積および FMA 命令が導入されています。これは Chrome 114 でリリースされました。
半精度浮動小数点形式では、IEEE FP16 では単精度値に使用される 32 ビットではなく 16 ビットが使用されます。単精度値と比較して、半精度値の使用、メモリ要件の削減（より大きなニューラル ネットワークのトレーニングとデプロイを可能にする）、メモリ帯域幅の低減にはいくつかの利点があります。精度が低下すると、データ転送と数学演算が高速になります。
大規模なモデル
Wasm リニアメモリへのポインタは 32 ビット整数として表されます。これには 2 つの結果があります。コンピュータの物理 RAM がそれよりもはるかに多い場合、ヒープサイズは 4 GB に制限され、Wasm をターゲットとするアプリケーション コードは 32 ビットポインタ サイズと互換性がなければなりません（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 と適切に連携できるようにする提案に引き続き投資していきます。