Google、LiteRT.jsを発表――ネイティブLiteRTの推論パスをブラウザへ

GoogleはLiteRT.jsを公開し、LiteRTにJavaScript／TypeScriptインターフェースを追加した。これにより、Webページから`.tflite`モデルを直接読み込み、コンパイルして実行できる。今回の変更の要点は、JavaScript向けの演算コアを新たに構築することではなく、ネイティブのLiteRTランタイムをWebAssemblyにコンパイルし、既存の演算子最適化、量子化フロー、ハードウェアバックエンドをブラウザに持ち込むことにある。

CPUパスには、マルチスレッドとSIMDをサポートするXNNPACKを採用。GPUパスはML DriftがWebGPU経由で実行し、NPUは今後WebNN経由で接続される予定だが、現時点ではChromeとEdgeで実験的機能にとどまる。LiteRT TorchはPyTorchモデルを変換でき、AI Edge Quantizerではレイヤー単位で量子化方式を設定できる。公式にはTensorFlow.jsとの相互運用パッケージも提供されているため、既存アプリケーションは前処理と後処理のコードを維持したまま、モデル実行レイヤーだけを置き換えられ、移行コストを抑えられる。

Googleによると、画像および音声モデルのテストでは、LiteRT.jsは他のWebランタイムと比べて最大約3倍高速だった。また、GPUまたはNPUを使用した場合、LiteRT.jsのCPUパスに対して5～60倍の高速化を達成できるという。ただし、これらの数値は管理された環境下で2024年モデルのM4 MacBook Proを使って得られたものであり、Androidデバイス、Windows PC、異なるブラウザへそのまま一般化することはできない。ドライバー、熱設計、演算子カバレッジ、データ転送が結果を左右する可能性がある。

エンジニアリングチームにとっての価値は、小規模言語モデル、物体検出、音声処理、ベクトル検索、画像補正をクライアント側へ移し、サーバー推論コスト、ラウンドトリップ遅延、元データの外部送信を削減できる点にある。一方、モデルの重みは依然としてデバイスへダウンロードする必要があるため、初回読み込みのコストが増えるうえ、モデルの知的財産を保護する手段とはみなせない。

今後は、WebNNがブラウザ横断で一貫したNPUインターフェースとして確立するか、生成モデルのメモリ管理と演算子カバレッジが成熟するか、そして公式ベンチマークをより多様なハードウェアで再現できるかを見極める必要がある。本番採用の前に、開発者はコールドスタート、重みのキャッシュ、ピークメモリ、WASMへフォールバックする演算子の割合、エンドツーエンドの消費電力を引き続き測定する必要がある。