LiteRT.jsがTensorFlow.jsを圧倒

WebGPUを使用したLiteRT.jsは、M2 MaxデスクトップGPU上でMobileNetV2の推論を0.41 msで実行し、2,439 FPSを実現しました。これは、同じハードウェア上のTensorFlow.jsよりも25倍以上高速です。モデルが大きくなるにつれてその差はさらに広がり、ウェブベースの機械学習は、かつてはネイティブアプリ専用とされていたパフォーマンス層へと進化しています。

ベンチマークが重要である理由

開発者はこれまで、主にWebGLバックエンドを介して、デバイス上での推論にTensorFlow.jsを使用してきました。WebGLはテンソル演算をブラウザの2Dグラフィックスパイプラインにマッピングします。これはどこでも動作しますが、ディープラーニングモデルが必要とする大規模な並列処理のために設計されたものではありません。次世代のグラフィックスAPIであるWebGPUは、GPUの演算ユニットへの直接的なアクセスを可能にします。LiteRT.jsは、TensorFlow-Liteモデルに対してWebGPUバックエンドの推論エンジンを提供する初のライブラリであり、Googleは3倍の高速化を報告しています。独立したテストではさらに大きな向上が示されており、WebGPUがウェブMLのデフォルトのパスになるかどうかが注目されています。

テストの実施方法

TensorFlow-Liteに変換された2つの画像分類モデル、MobileNetV2とEfficientNet-Lite4のベンチマークを実施しました。テストはAppleシリコンのM2 Maxチップ上で実行されました。各モデルについて、多数のイテレーションにわたる単一のフォワードパスのレイテンシを測定し、フレームレート（FPS）を算出しました。また、同じモデルをWebGLバックエンドのTensorFlow.jsで実行し、各ライブラリのコールドスタート時間を記録しました。

結果：速度と起動時間

  • MobileNetV2

    • LiteRT.js (WebGPU): レイテンシ 0.41 ms → 2,439 FPS
    • TensorFlow.js (WebGL): レイテンシ 10.82 ms → 92 FPS

  • EfficientNet-Lite4

    • LiteRT.js (WebGPU): レイテンシ 0.62 ms → 1,623 FPS
    • TensorFlow.js (WebGL): 報告なし（ただし、MobileNetV2の時点で既に25倍以上の差が出ています）

TensorFlow.jsは、最初の推論を行う前にWebGLシェーダーをコンパイルするために約10秒（10,014 ms）を必要としました。一方、LiteRT.jsは4.3 msで準備が整い、インタラクティブなアプリにおけるコールドスタートのペナルティを実質的に解消しました。

モデルのサイズを5倍に増やした際、レイテンシの上昇はわずか50%にとどまり、GPUの並列処理が追加の負荷の大部分を吸収することが確認されました。その結果、サーバーとの通信（ラウンドトリップ）を介さずに、ブラウザ上でリアルタイムのビデオストリーム、ARオーバーレイ、あるいはビジョンモデルの迅速なプロトタイピングを処理できるパフォーマンスの限界が押し上げられました。

数値に隠された課題

  • バッチ処理 – ほとんどのTensorFlow-Liteモデルは、バッチ次元が1に固定されています。一度の呼び出しで複数の画像を処理することは標準ではサポートされておらず、開発者はWeb Workerを生成するか、手動で入力をパイプライン化する必要があります。
  • メモリ管理 – LiteRT.jsはGPUテンソルを自動的にガベージコレクションしません。開発者は作成した各テンソルに対して.delete()を呼び出す必要があり、そうしないと数百回の推論後にGPUメモリを使い果たすリスクがあります。
  • ハードウェアの普及率 – WebGPUはデスクトップ版のChromeやFirefoxでは安定しています。しかし、AndroidのChromeやiOSのSafariを含むモバイルブラウザでは、実験的なフラグを有効にした場合にのみAPIが公開されているか、あるいは全く利用できません。これらのプラットフォームでは、WASMバックエンドが唯一の汎用的な手段となりますが、大きなモデルでは著しく低速になります。

これらの制約は、生の速度こそ印象的であるものの、それを実現するためのエンジニアリングの労力は決して小さくないことを意味しています。

制限事項とトレードオフ

TensorFlow.jsのWebGLバックエンドは、依然としてほぼ普遍的な互換性を提供しています。デスクトップ、Android、iOSといった多様なユーザー層をターゲットにする開発者は、スループットは低くなるものの、どこでも動作する単一のコードパスに頼ることができます。WASMバックエンドはほぼすべてのハードウェアで動作しますが、今回測定したような大きなモデルではWebGPUに及びません。

LiteRT.jsは、WebGPUが有効なデスクトップ環境をターゲットとする場合に真価を発揮します。.tfliteモデルを直接実行できるため、開発者は変換することなくHugging FaceやKaggleからモデルを読み込むことができ、元の量子化やパフォーマンスを維持できます。トレードオフとしては、展開できる環境が限定されることと、慎重なリソース管理が必要になることが挙げられます。

開発者が考慮すべき事項

  • ターゲットプラットフォーム – ウェブ専用のデスクトップツール（例：リアルタイムでスタイル変換を適用するデザインアプリ）であれば、LiteRT.jsとWebGPUの組み合わせが最適な選択肢となるでしょう。
  • モデルのサイズ – 計算負荷の高い大きなモデルほどGPUの並列処理の恩恵を受けられます。一方で、小さなモデルでは追加のエンジニアリングに見合うほどのメリットが得られない可能性があります。
  • メモリ管理の規律 – 明示的なテンソルの削除を計画するか、リソースを自動的に解放するスコープ内で推論呼び出しをラップするようにしてください。
  • フォールバック戦略 – WebGPUを有効にできないブラウザのために、WASMやWebGLによるフォールバックを用意し、より幅広いユーザーに対してアプリが機能するようにしてください。

まとめ

LiteRT.jsは、WebGPUがウェブベースの推論をミリ秒未満の領域へと押し上げられることを証明しており、デスクトップGPU上ではTensorFlow.jsの25倍を超える速度を実現します。この技術はまだ成熟の過程にあり、開発者はバッチ処理の制限、手動でのメモリ解放、および限定的なモバイルサポートへの対応を考慮する必要があります。リアルタイム性能を求めるデスクトップ優先の体験において、この新しいライブラリは非常に魅力的な道筋を提供しますが、クロスプラットフォームでの展開においては、従来のWebGLやWASMバックエンドが引き続き不可欠です。