Hugging Face、ローカル AI 向け WebGPU カーネルライブラリ公開

Hugging Face の WebAI チームにとって、最大の目標の一つはブラウザでの推論を可能な限り高速化し、ユーザーフレンドリーにすることです。その実現には多層的な取り組みが必要です。モデルにはブラウザに適した表現形式が求められ、ランタイムは効率的な実行計画を立てる必要があります。さらに、スタックの最下層にある個々の GPU 演算も、さまざまなデバイスやブラウザの実装を最大限に活用できるものでなければなりません。

今日、私たちはその取り組みの第一歩として、`@huggingface/kernels` をリリースします。これは Hugging Face Hub から最適化された WebGPU カーネルを読み込んで実行するための最小限のライブラリです。同時に、huggingface.co/webgpu-kernels には初期コレクションとして207 のカーネルを公開しています。

このコレクションは、多様な機械学習アーキテクチャやワークロードで広く使用される演算を網羅しています。さらに重要な点は、各カーネルが完全なバージョン管理パッケージとして公開されていることです。インターフェース、シェーダーテンプレート、正しさの検証ケース、ベンチマークケース、そして利用方法に関する説明はすべて Hub 上で一体化されています。

また、WebGPU 上でカーネルを実行・評価するブラウザ内ベンチマークおよびテストスイート「Fleet」も公開します。ご自身の機器での結果だけでなく、従来のテストラボではカバーしきれない多様なデバイスからのパフォーマンスと正しさの証拠をコミュニティが提供できる仕組みです。ユーザーの同意を得た上で実行されたすべてのデータは、誤った結果や極端に遅いケースなどの不具合発見、カーネルバリアントの改善、実世界のハードウェア全体での最適化判断の向上に役立つ非公開のエビデンスとして活用されます。

TL;DR

• 207 個の WebGPU カーネルを、`webgpu-kernels` オルガニゼーション内の個別リポジトリとして公開。Apache-2.0 ライセンス。
• Hugging Face Hub から直接カーネルをダウンロード・準備・実行する JavaScript ロードライブラリ @huggingface/kernels を提供。
• マニフェスト、正しさのテスト、ベンチマークケース、WGSL シェーダーテンプレートなどを含む、各カーネルに対する明確な契約と再現可能なエビデンスを公開。
• 実世界の GPU 全体で正しさとパフォーマンスのエビデンスを集約し、カーネルとそのバリアントの改善に役立てるブラウザベースのベンチマークツール「Fleet」。

なぜカーネルから始めたのか？

ブラウザで動作するモデルは、最終的には GPU 演算の連続として実行されます。行列乗算や正規化、畳み込み、アテンションの基礎処理、量子化演算、データレイアウトの変換などです。WebGPU はこれらの操作をポータブルな API を通じて現代のブラウザで利用可能にし、WGSL はそれらを実行するシェーダーのための共通言語を提供します。

しかし、ポータビリティが自動的に高性能を保証するわけではありません。同じ演算を実装し、同じ出力を生成する 2 つのシェーダーでも、異なるアクセラレーター上では全く異なる挙動を示すことがあります。ワークグループサイズやメモリアクセスパターン、ベクトル化、データ型、融合戦略などはすべて性能に影響を与えます。最適な選択は、入力形状やデバイス、ブラウザ、利用可能な WebGPU の機能によっても変化します。

これが、カーネルが高速なブラウザ推論の基盤層を形成する理由です。上位ランタイムの効率性は、それらがディスパッチする演算次第で決まります。これらの演算を個別に発見・テスト・ベンチマーク・バージョン管理できるようにすることで、上位レイヤーとの安定した契約を保ちつつ、基盤そのものを独立して改善することが可能になります。

シェーダーの寄せ集めではなく、カーネルのリポジトリ

コレクション内の各カーネルには独自のリポジトリとカーネルカードが用意されています。カードには演算の意味、入力・出力、属性、サポートされるデータ型、ソースファイル、そしてすぐに実行可能な @huggingface/kernels の例が記載されています。

例えば、`ai.onnx.Add` は、多方向のブロードキャストを伴う要素ごとの加算演算を実装しています。これはニューラルネットワークにおける最も単純な操作の一つで、残差接続やバイアスの追加など、あらゆる場所で利用されています。

カードドキュメントには、2 つの入力値、ブロードキャスト後の出力形状、対応するデータ型、そして異なる形状やデバイス向けに用意されたバリアントが記載されています。

ai.onnx.Add リポジトリには、マニフェストファイル、正しさの検証ケース、ベンチマーク用データ、そして WGSL シェーダーテンプレートがパッケージ化されています。

カードの背後にあるリポジトリには、実装を理解し評価するために必要なアーティファクトが格納されています。

• manifest.json は操作契約における真実の源です。入力、出力、属性、型制約、形状導出ルールを定義しています。

• metadata.json にはカーネル識別子、ダイジェスト、および出所情報が記録されます。

• test.json には正答ケースが含まれており、実装が期待される動作に合致しているか検証できます。

• bench.json にはベンチマークおよびチューニング用のケースが含まれており、カーネルの評価に用いるワークロードを代表しています。

• *.wgsl.jinja ファイルには、特定のリクエストとデバイスに対してシェーダーを生成するために使用されるパラメータ化された WGSL 実装が格納されています。

この構造により、シェーダーが再利用可能なソフトウェアアーティファクトへと変換されます。WGSL を読まなくてもインターフェースを検査可能であり、正しさやパフォーマンスに関するケースは実装と一体となって管理されます。また、公開されたバージョンは、バージョン指定のないファイル URL に依存するのではなく、明示的にロード可能です。さらに、カスタム WebGPU カーネルを開発したり、これらの操作を独自のランタイムに統合したりする開発者にとって、本カーネルはリファレンス実装としても機能します。

Hub からのカーネル読み込み

npm からパッケージをインストールしてください：

npm install @huggingface/kernels@preview

これらのカーネルを実行するには、WebGPU サポートに対応したブラウザが必要です。WebGPU の利用可否は、ブラウザやオペレーティングシステム、GPU、ドライバーに依存します。JavaScript では "gpu" in navigator と記述することで、対応状況を確認できます。

@huggingface/kernels は、カーネルリポジトリとアプリケーションをつなぐブリッジの役割を果たします。Hub リポジトリ ID と契約バージョンを指定して getKernel を呼び出し、返された関数に型付きの入力データとテンソルの形状を渡すことで利用可能です。以下に、バイアス加算の簡単な例を示します。

import { getKernel } from "@huggingface/kernels";

const add = await getKernel("webgpu-kernels/ai.onnx.Add", { version: 1 });

const { c } = await add({
  a: {
    data: new Float32Array([1, 2, 3, 4, 5, 6]),
    shape: [2, 3],
  },
  b: {
    data: new Float32Array([10, 20, 30]),
    shape: [3],
  },
});

2 つ目の入力は第 1 次元にブロードキャストされ、形状が [2, 3] の出力を生成します。ローダーはこの出力形状と論理データ型をマニフェスト契約および入力情報から導出し、変数 c を自動的に確保します。

6 つの浮動小数点数を加算するデモは、あえて最小限のものにしています。この規模では、GPU へのデータ転送にかかるオーバーヘッドの方が計算コストよりも遥かに大きくなります。ここで重要なのは呼び出しパターンです。行列乗算（ai.onnx.MatMul）のように最適化されたカーネルが真価を発揮する重厚な演算においても、このパターンは全く同じまま維持されます。変わるのはリポジトリ ID と入力データだけです。

この基本的な演算例からも、カーネルに複数のバリアントが必要である理由がわかります。形状が等しい加算であれば直接ベクトル化されたパスを使用できますが、ブロードキャストされた入力には異なるインデックス処理ロジックが必要です。公開されている Add カーネルには、形状が等しい場合、ベクトル化ブロードキャスト、スカラー処理、一般的なブロードキャストに対応するバリアントが含まれています。ランタイムは、アプリケーション側の API を変更することなく、現在の呼び出しやデバイスに最適な実装を選択できます。

version: 1 オプションは、公開されているカーネル契約のバージョン 1 を選択します。これは ONNX のオペセット、演算子の since_version、あるいはモデルのリビジョンとは別個の概念です。これらの概念を明確に分離しておくことで、アプリケーション側は安定した JavaScript 向けの契約に依存しつつ、その背後でカーネルの実装を進化させることが可能になります。

カーネルのパフォーマンスはどの程度か？

では、最適化されたカーネルは実際にどれほどの差を生むのでしょうか？私たちは Apple M4 GPU 上で、ONNX Runtime Web 1.30.0-dev.20260826-b1f76d586a を使用し、当社のコレクションと ORT WebGPU を直接比較しました。対象としたのは全 207 種類の演算にわたる 1,756 のテストケースです。そのうち、両者の出力が一致し、信頼性の高い計測結果が得られた 809 ケースを最終的な評価対象としました。

これらの比較結果において、当社のカーネルは幾何平均で2.57倍、中央値でも1.90倍高速化され、629勝・176敗・4分けという成績を収めました。ここでは、よく知られる 4 つの演算について詳しく見ていきましょう。

個々の成果には、非常に大きなものもありました。特に難しい双一次 Einsum のケース（i,ij,j でサイズ 4096）では、当社のカーネルでは 0.136 ms で実行されたのに対し、ORT WebGPU では 1,396 ms かかりました。これは10,000 倍以上の高速化です。また、[256, 4096] の行方向 CumSum は、0.016 ms 対 4.784 ms で301 倍高速でした。これらはどこでも期待できるような速度向上というよりは特殊なケースですが、汎用的な実装がボトルネックに陥った際に、専門的なカーネルがいかに役立つかを示しています。

測定は GPU 上での実際の処理時間に限定しており、カーネルの読み込みやセッション作成、入力データのアップロード、シェーダーのコンパイル、出力結果の取得といったセットアップ時間は含んでいません。非常に短いワークロードは計測が難しく、小規模なケースでは GPU キャッシュの影響を受けるため、これらの数値はあらゆるアプリケーションでの保証というよりも、有用な比較指標として捉えてください。

これらは個々の演算の結果であり、完全なモデル全体の性能ではありません。正確なパフォーマンスは GPU やブラウザによって異なります。そのため、より広範な状況を把握するには Fleet のような仕組みが不可欠です。

また、これらの改善を ONNX Runtime チームと連携して本流（upstream）に反映させることで、ONNX Runtime Web エコシステム全体への恩恵を目指しています。

単一デバイスからファームへ

WebGPU のパフォーマンスは GPU やブラウザ、ドライバによって大きく異なります。ある一台の機械での結果だけでは、全体の姿を把握することはできません。Fleet を使えば、誰でもブラウザ上で正準性と性能チェックを実行でき、自社のハードウェア上でカーネルがどのように動作するかを確認できます。

同意を得た上で、各実行はデバイス固有の障害の特定やバリアント間の比較、選択ルールの改善に役立つ証拠を非公開で提供します。目的はシンプルです。広範な実世界のカバー範囲を活用し、すべてのユーザーにとってカーネルをより高速かつ信頼性の高いものにする。

WebAI 向けの共有基盤の構築

初期の 207 のカーネルは出発点に過ぎず、最終形態ではありません。カーネルを Hugging Face Hub で個別に公開することで、シェーダーをすべてのランタイムに直接埋め込むことなく、共通の場所で契約の確認、実装の比較、正しさの検証再現、パフォーマンスの改善が可能になります。

このコレクションは、Hub のより広範なカーネルエコシステムの一部でもあります。Kernels ページでは、WebGPU カーネルが CUDA、ROCm、Metal、その他のプラットフォーム用のカーネルと並び、Hub 上の他のアーティファクトと同様にフィルタリングやソート、探索が可能です。

*Hub の Kernels ページに表示される WebGPU カーネル 207 個を、プラットフォームでフィルターしたものです。

これらの要素は互いに補完し合っています：

• カーネルリポジトリは、透明性がありバージョン管理された操作契約を定義します。
• @huggingface/kernels は、JavaScript からそれらの操作を簡単に読み込んで実行できるようにします。

Fleet は、従来のベンチマークラボではカバーしきれないはるかに広範なデバイス群にわたって、実世界の証拠を収集します。

貢献された各実行結果は、失敗の発見やチューニングの指針、バリアント選定の改善、そして将来のカーネルバージョンの検証支援などにつながります。

これは、ブラウザ推論スタックにおける次のステップに向けた低レベルな基盤です。私たちはこれらのカーネルをより高水準なモデルツールと連携させ、操作カバレッジの拡大を続け、WebAI エコシステム全体で高速なローカル推論が使いやすくなることを目指しています。

WebGPU カーネルコレクション を探索したり、`@huggingface/kernels` を試したり、Fleet へ参加 してご自身のデバイスからの証拠を提供し、皆のためにカーネルをより良くするお手伝いをしてください。