AI News HubLIVE
サイト内リライト3 分で読了

WebGPUの機能検出だけではスマートフォンで小型LLMを実行するには不十分だった

筆者はスマートフォンのブラウザで小型言語モデルを実行しようと試み、WebGPUの機能検出だけでは成功を保証できないことを発見した。4つのテスト環境では、WebGPUが利用可能であっても、ページのリロード、ダウンロードの停止、パフォーマンスの顕著な差などにより実行が失敗した。

ソースHacker News AI著者: Littice

筆者は、スマートフォンのブラウザ上でサーバー推論を行わずに小型言語モデルを実行しようと考えた。機能検出は簡単で、WebGPUアダプターを要求し、その制限を読み取り、バッファサイズが十分に大きければ実行できると想定する。テストしたすべてのブラウザ環境でWebGPUが公開されており、報告された制限はモデルの重みを格納するのに十分に見えた。しかし、実際に実行してみると結果は異なった。

デバイスが報告するGPU能力と、推論が完了するかどうかは別の問題である。以下は筆者が測定した4つのケースである。すべての数値はリポジトリ内の生の測定ファイルに基づく。使用したモデルはLlama-3.2-1B-Instruct、Qwen2.5-1.5B-Instruct、Qwen2.5-0.5B-Instructで、約4ビットに量子化されている。エンジンはWebLLM 0.2.84、transformers.js 4.2.0、wllama 3.4.1である。各実行はコールドキャッシュで、短いプロンプトは約50トークン、長いプロンプトは約1200トークンである。

1つ目のケース:iPhone上のSafariで生成中にページがリロードされる。デバイスはiPhone 11 Pro Max、iOS 18.7、Safari 26.5。webgpu: true、Appleアダプター、f16対応、maxBufferSizeは715827880バイトを報告。最初のチェックとしてはモデルの重みに十分なサイズだった。しかし、どの実行も完了しなかった。Qwen2.5-1.5BをWebLLMで使用した場合、728 MBすべてをダウンロードした後、初期化で「TypeError: Load failed」で失敗。Llama-3.2-1BをWebLLMで使用した場合はさらに進み、WebGPUバックエンドでの生成段階に達したが、生成中にページがリロードされ、JavaScriptで可視の例外やキャッチ可能なメモリ不足エラーはなかった。より小さなQwen2.5-0.5Bをwllamaで使用した場合も初期化時に同様の現象が発生し、タブが準備完了になる前にリロードされた。このデバイスでは、すべてのエンジンとモデルで実行完了数はゼロであった。障害モードは処理可能なエラーではなく、背後でタブが再起動するというものである。

2つ目のケース:LINEのアプリ内ブラウザはWebGPUを公開するが、実行は完了しない。デバイスはPixel 8a、8 GBメモリ、Android 16上のLINEアプリ内ブラウザで開いた。webgpu: true、Arm Valhallアダプター、f16対応、maxBufferSizeは4294967292バイト(4 GB上限)を報告。アダプターの制限は、成功したChromeの実行と区別できなかった。Llama-3.2-1Bのセッションは開始され、ダウンロード中に停滞し、一度も完了しなかった。そのセッションの結果ファイルには空の実行リストが含まれていた。アダプター報告は、アプリ内ブラウザがダウンロードと初期化を完了するかどうかについて何も教えてくれなかった。実際には完了しなかった。

3つ目のケース:同じハードウェアとモデルで、エンジンのみで約2倍のスループット差。Windowsデスクトップ(AMD RDNA 4 GPU、Chrome 148)で、同じLlama-3.2-1Bを短いプロンプトで3つのエンジンすべてで実行した。すべてのケースでWebGPUが存在し使用された。デコード速度は3回の実行の中央値である。WebLLM 0.2.84は196.17トークン/秒、transformers.js 4.2.0は125.41トークン/秒、wllama 3.4.1は97.61トークン/秒。最速のエンジンは最遅の約2倍の速度であった。WebGPUサポートフラグはすべて同じだが、測定されたスループットは異なる。

4つ目のケース:Pixel 8aは実行を完了するが、長いプロンプトのプリフィルに76秒かかる。デバイスは再びPixel 8a、今回はアプリ内ブラウザではなく通常のChrome 149。Arm Valhallアダプターは同じ4 GBのバッファ上限を報告。ここではモデルが読み込まれ完了まで実行されたため、完全なタイミングが得られた。短いプロンプト(52入力トークン)では、最初のトークンまでの時間は約3.8秒(3782、3954、3752ミリ秒)。長いプロンプト(1213入力トークン)では、最初のトークンまでの時間は77153、76996、76449ミリ秒、つまり76〜77秒であった。その後のデコード速度は約9トークン/秒を維持した。1行のプロンプトを数秒で処理する同じデバイスが、1ページのコンテキストを読むのに1分以上かかる。

これら4つのテスト環境を通じて、WebGPUの公開と大きなアダプター制限は、小型LLMの実行が完了するかどうかを予測するには十分ではなかった。機能検出はWebGPUを要求できるかどうかを答えるだけで、推論が完了するかどうかは答えなかった。