ウェブ上の AI 機能のほとんどはサーバーに依存していますが、クライアントサイド AI はユーザーのブラウザで直接実行されます。これには、低レイテンシ、サーバーサイドのコストの削減、API キー要件なし、ユーザー プライバシーの強化、オフライン アクセスなどのメリットがあります。TensorFlow.js、Transformers.js、MediaPipe GenAI などの JavaScript ライブラリを使用して、ブラウザ間で動作するクライアントサイド AI を実装できます。
また、クライアントサイド AI にはパフォーマンス上の課題もあります。ユーザーがダウンロードするファイルの数が増え、ブラウザの負荷が高くなります。うまく機能させるには、次のことを検討してください。
- ユースケース。クライアントサイド AI は、機能に適していますか？機能はクリティカル ユーザー ジャーニーに含まれていますか？含まれている場合、代替手段はありますか？
- モデルのダウンロードと使用に関するベスト プラクティス。詳細については、下記の説明をご覧ください。
モデルのダウンロード前
Mind ライブラリとモデルサイズ
クライアントサイド AI を実装するには、モデルと、通常はライブラリが必要です。ライブラリを選択する際は、他のツールと同様にサイズを評価します。
モデルサイズも重要です。AI モデルで何が大規模と見なされるかは、モデルによって異なります。目安として、5 MB はウェブページサイズの中央値の 75 パーセンタイルでもあります。より緩い数値は 10MB になります。
モデルサイズに関する重要な考慮事項は次のとおりです。
- タスク固有の AI モデルの多くは非常に小さい場合があります。アジアの言語で正確な文字分割を行う BudouX などのモデルは、GZIP 圧縮でわずか 9.4 KB です。MediaPipe の言語検出モデルは 315 KB です。
- ビジョンモデルでも適切なサイズに抑えることができます。Handpose モデルと関連するすべてのリソースの合計サイズは 13.4 MB です。これは、ほとんどの圧縮済みフロントエンド パッケージよりもはるかに大きいものの、ウェブページの中央値である 2.2 MB（デスクトップでは 2.6 MB）と同程度です。
- 生成 AI モデルは、ウェブリソースの推奨サイズを超える可能性があります。非常に小さな LLM または単純な NLP モデル（意見は分かれる）と見なされる DistilBERT の重量は 67 MB です。Gemma 2B などの小さな LLM でも 1.3 GB に達することがあります。これは、ウェブページの中央値の 100 倍以上のサイズです。
ブラウザのデベロッパー ツールで、使用する予定のモデルの正確なダウンロード サイズを評価できます。
モデルサイズを最適化する
- モデルの品質とダウンロード サイズを比較する。小さいモデルは、ユースケースに十分な精度を持ちながら、はるかに小さい場合があります。十分な精度を維持しながらモデルのサイズを大幅に縮小するために、ファインチューニングとモデルの縮小手法があります。
- 可能であれば、特殊なモデルを選択します。特定のタスクに合わせて調整されたモデルは、小さい傾向があります。たとえば、感情分析や有害性分析などの特定のタスクを実行する場合は、汎用的な LLM ではなく、これらのタスクに特化したモデルを使用します。
これらのモデルはすべて同じタスクを実行しますが、精度は異なり、サイズは 3 MB～1.5 GB と大きく異なります。
モデルを実行できるかどうかを確認する
すべてのデバイスで AI モデルを実行できるわけではありません。十分なハードウェア仕様を備えたデバイスでも、コストの高い他のプロセスが実行されているか、モデルの使用中に開始されている場合、苦労する可能性があります。
解決策が公開されるまで、今すぐできること:
- WebGPU のサポートを確認する。Transformers.js バージョン 3 や MediaPipe など、いくつかのクライアントサイド AI ライブラリは WebGPU を使用します。現時点では、これらのライブラリの一部は、WebGPU がサポートされていない場合に Wasm に自動的にフォールバックしません。クライアントサイド AI ライブラリに WebGPU が必要であることをご存じの場合は、AI 関連のコードを WebGPU 機能検出チェック内に含めることで、この問題を軽減できます。
- 電力不足のデバイスを除外する。Navigator.hardwareConcurrency、Navigator.deviceMemory、Compute Pressure API を使用して、デバイスの機能と負荷を見積もります。これらの API はすべてのブラウザでサポートされているわけではなく、フィンガープリントを防ぐために意図的に不正確な値を使用しています。ただし、消費電力が非常に低いと思われるデバイスを除外することはできます。
大規模なダウンロードのシグナル
大規模モデルの場合は、ダウンロードする前にユーザーに警告します。モバイル ユーザーよりも、PC ユーザーは大量のダウンロードに満足する傾向があります。モバイル デバイスを検出するには、User-Agent Client Hints API の mobile を使用します（UA-CH がサポートされていない場合は、User-Agent 文字列を使用します）。
サイズの大きなダウンロードを制限する
- 必要なものだけをダウンロードする。特にモデルが大きい場合は、AI 機能が使用されることが確実な場合にのみダウンロードしてください。たとえば、入力候補の AI 機能がある場合は、ユーザーが入力機能を使い始めたときにのみダウンロードします。
- Cache API を使用してデバイスにモデルを明示的にキャッシュに保存し、アクセスのたびにモデルがダウンロードされないようにします。暗黙的な HTTP ブラウザ キャッシュにのみ依存しないでください。
- モデルのダウンロードをチャンクに分割する。fetch-in-chunks は、大きなダウンロードを小さなチャンクに分割します。
モデルのダウンロードと準備
ユーザーをブロックしない
スムーズなユーザー エクスペリエンスを優先する: AI モデルがまだ完全に読み込まれていない場合でも、主な機能を機能させます。
進行状況を示す
モデルのダウンロード中に、完了した進捗状況と残り時間が表示されます。
- モデルのダウンロードがクライアントサイドの AI ライブラリによって処理される場合は、ダウンロードの進行状況を使用してユーザーに表示します。この機能が利用できない場合は、問題を報告してリクエストするか、コードを貢献することを検討してください。
- 独自のコードでモデルのダウンロードを処理する場合は、fetch-in-chunks などのライブラリを使用してモデルをチャンクで取得し、ダウンロードの進行状況をユーザーに表示できます。
- その他のおすすめの方法については、アニメーション化された進行状況インジケーターのベスト プラクティスと長時間の待機と中断に対応した設計をご覧ください。
ネットワークの中断を適切に処理する
モデルのダウンロード時間は、モデルのサイズによって異なります。ユーザーがオフラインになった場合にネットワークの中断を処理する方法を検討します。可能であれば、接続が切断されたことをユーザーに通知し、接続が復元されたらダウンロードを続行します。
接続が不安定な場合も、チャンクでダウンロードすることをおすすめします。
負荷の高いタスクをウェブワーカーにオフロードする
ダウンロード後のモデル準備ステップなど、負荷の高いタスクはメインスレッドをブロックし、ユーザー エクスペリエンスのジッターを引き起こす可能性があります。これらのタスクをウェブワーカーに移行すると役立ちます。
ウェブワーカーに基づくデモと完全な実装を確認する:
推論中
モデルをダウンロードして準備ができたら、推論を実行できます。推論は計算コストが高くなる場合があります。
推論をウェブワーカーに移動する
WebGL、WebGPU、WebNN のいずれかを使用して推論を行う場合は、GPU を使用します。つまり、UI をブロックしない別のプロセスで実行されます。
ただし、CPU ベースの実装（WebGPU がサポートされていない場合は WebGPU のフォールバックとなる Wasm など）では、推論を Web Worker に移動しても、モデルの準備時と同様にページの応答性が維持されます。
AI 関連のコード（モデルの取得、モデルの準備、推論）がすべて同じ場所にある場合は、実装が簡単になる場合があります。したがって、GPU が使用されているかどうかにかかわらず、ウェブワーカーを選択できます。
エラーを処理する
モデルがデバイスで実行されることを確認しても、ユーザーが後でリソースを大量に消費する別のプロセスを開始する可能性があります。これを軽減するには:
- 推論エラーを処理する。推論を
try/catchブロックで囲み、対応するランタイム エラーを処理します。 - WebGPU エラーを処理します。予期しないエラーと GPUDevice.lost の両方のエラーが発生します。これは、デバイスの処理が遅いために GPU が実際にリセットされた場合に発生します。
推論ステータスを示す
推論に即時に感じるよりも時間がかかる場合は、モデルが思考中であることをユーザーに知らせます。アニメーションを使用して待ち時間を軽減し、アプリが意図したとおりに動作していることをユーザーに示します。
推論をキャンセル可能にする
ユーザーがクエリをその場で絞り込むことができます。ユーザーが目にすることのないレスポンスを生成するためにシステムがリソースを浪費することはありません。