あなたは、非常に大規模で複雑なビデオゲームをコンピュータ上で動かそうとしていると想像してください。しかし、あなたはハードウェアに直接触れることを許さない、非常に厳格でセキュリティ意識の高いマネージャーを通じて、そのゲームを実行しなければなりません。これが、ウェブブラウザ内で人工知能（具体的には大規模言語モデル、LLM）を動かす世界です。これらのモデルは、物語を書いたり、数学を解いたり、会話を行ったりするチャットボットの背後にある「脳」です。これらをあなたのノートパソコンやスマートフォン上で高速に動作させるために、開発者は「WebGPU」と呼ばれる特別なツールを使用します。WebGPUを、あなたのブラウザがコンピュータのグラフィックスカード（通常、ビデオゲームの描画に使用される部分）と対話することを可能にする「ユニバーサルな翻訳機」だと考えてください。これにより、AIのための重い計算を行うことができるのです。

しかし、落とし穴があります。過去に、開発者がこれらのAIモデルを高速化しようとした際、彼らは個々の数学的なステップ（「カーネル」と呼ばれます）をより効率的にすること、つまり「車のエンジンを磨き上げる」ことに注力してきました。しかし、この論文は異なる問いを投げかけています。「もし車自体は高性能なのに、ドライバーが車に乗り降りするだけで時間を浪費しているとしたらどうだろうか？」と。ブラウザの世界では、あらゆる数学的ステップにおいて、「ディスパッチ（命令の送出）」、つまりブラウザからグラフィックスカードに対して作業を開始するようリクエストを送る必要があります。大きな謎は、「実際に計算を行っている時間」に対して、「リクエストを送るためにどれだけの時間が浪費されているのか」という点でした。これを理解することは極めて重要です。なぜなら、コンピュータに仕事を頼むためだけに時間を使いすぎると、たとえ数学的な計算がどれほど賢くても、チャットボットの動作は重く、もっさりしたものになってしまうからです。

「ストップ・アンド・ゴー」の交通渋滞

この論文の著者は、誰もがこれらのAIリクエストの速度測定を間違えていたことを発見しました。配達員が荷物を届ける時間を計る場面を想像してください。もし、配達員が倉庫を出発してから、家まで走り、荷物を置き、そして次の荷物を取りに倉庫まで戻ってくるまでの時間を計っているとしたら、あなたは「往復の全行程」を計っていることになります。しかし、AIの現実の世界では、ドライバーは荷物一つごとに倉庫に戻るわけではありません。彼らは一度に大量の荷物を運び、最後に一度だけ倉庫に戻ります。

この論文は、以前の測定方法が、すべての荷物に対してこの「往復全行程」を計っていたようなものだと指摘しています。彼らは、「リクエストを送信する時間（ディスパッチ）」と、「コンピュータが『終わりました』と言うのを待つ時間（同期）」を混同していました。この「待ち時間」は非常に大きく、450マイクロ秒もの停止時間を生じさせます。研究者たちがこの待ち時間を毎ステップに加算していたため、リクエストのコストは実際よりも約20倍高いと誤認していたのです。

「シーケンシャル・ディスパッチ（逐次送出）」と呼ばれる新しい手法を用いることで、著者は、ステップ間の長い待ち時間を挟まずに、リクエストを送信する行為そのものだけを計る方法を見つけ出しました。その結果、真のコストははるかに低いことが判明しました。一部のシステム（Vulkan）では24〜36マイクロ秒、他のシステム（Metal）では32〜71マイクロ秒でした。興味深いことに、このコストは「float32」または「float16」（小数点の数値を保存する2つの異なる方法）のどちらを使用しても同じでした。これは、遅延の原因が数学的な計算そのものではなく、ブラウザのルールにあることを証明しています。

真のボトルネック：多すぎる立ち寄り

単一のリクエストにかかる真のコストが判明した後、チームは「これは本当に問題なのか？」と問いかけました。これを知るために、彼らは制御された実験を行いました。標準的なAIモデルを取り上げ、そのパッケージング方法を変更しました。グラフィックスカードにテキストの1単語を処理させるために876回の小さなリクエストを送る代わりに、いくつかのステップを「融合（フューズ）」させることで、カードが受け取るリクエストの数を564回に減らしました。

ここでの肝となるのは、彼らはリクエスト内の数学的な計算を少しも速くしていないということです。コードをより賢くしたり、メモリ使用量を減らしたりもしていません。ただ単に、ブラウザがグラフィックスカードのドアを叩く回数を減らしただけなのです。

結果はどうだったでしょうか。AIは53%高速化しました。1単語を生成するのにかかる時間は、71.4ミリ秒から41.6ミリ秒へと短縮されました。

この実験は、最も一般的な設定（「バッチサイズ1」として知られる、一度に1単語ずつ処理する設定）において、最大の課題は数学が遅いことでも、メモリが不足していることでもないことを証明しました。問題は単純に、「ドアを叩く回数が多すぎる」ということだったのです。著者は、スピードアップの理由が、より優れた数学的コードや少ないメモリ使用量によるものではないことを明確に否定しました。変化したのは、ディスパッチの回数だけでした。

これが未来に意味すること

論文は、もしブラウザでAIチャットボットをスムーズに動作させたいのであれば、個々の数学的ステップを完璧にすることに固執するのではなく、それらをグループ化することに注力すべきであると結論付けています。それは、「配達トラックをより早く目的地に届けたいなら、ドライバーの走る速度を上げるのではなく、一度に運ぶ箱を大きくして、往復の回数を減らすべきだ」と気づくことに似ています。

著者は、解決策は「ディスパッチの償却（dispatch amortization）」にあると示唆しています。これは、簡単に言えば、それらの「ノック」のコストを多くのタスクに分散させることで、遅延の影響を最小限に抑える必要があるという意味です。これは、AIを実行するソフトウェアだけでなく、WebGPUのルール自体にも変更が必要になる可能性があることを示唆しています。例えば、ブラウザがステップごとに一つずつ確認するのではなく、「コマンドグラフ（事前に計画されたルート）」を受け入れられるようにすることなどです。

これらの知見は、特定のハードウェア（NVIDIA RTX 5090など）および特定のAI実行方法に基づいたものですが、メッセージは明確です。現在のところ、ブラウザ内のAIを高速化する秘訣は、より速いエンジンではなく、「立ち寄る回数を減らすこと」なのです。