LiteRT V2を読む：オンデバイス推論の変換、実行、アクセラレーター

TensorFlow Liteの後継としての出発点

LiteRTは、TensorFlow Liteの流れを引き継ぐGoogleのオンデバイスランタイムとしてREADMEに位置付けられています。対象はエッジプラットフォームでの機械学習と生成AIの展開です。モデルをクラウドへ送らず、端末上で推論する構成を選びたい場合の、変換、最適化、実行の入口を一つのリポジトリへまとめています。

READMEの表現には高性能という評価がありますが、これはプロジェクトの説明であって、特定の端末やモデルに対する独立した測定結果ではありません。推論速度、メモリ使用量、消費電力、モデルの精度低下は、演算子、量子化、ドライバー、端末の発熱で変わります。LiteRTを選ぶ際は、フレームワーク名やスター数から結論を出さず、実際の利用モデルと端末を検証対象に置く必要があります。

モデルを実行形式へ運ぶ道筋

READMEの図は、PyTorch、TensorFlow、JAXのモデルをLiteRTの実行系へ渡す流れを示しています。PyTorch向けにはLiteRT Torch Converterがあり、通常の.tflite形式と、LLM向けの.litertlm形式を扱うGenerative Torch APIが案内されています。AI-Edge Quantizerは、変換後のモデルを最適化する段階として置かれています。

最終的なLiteRT Runtimeは、C++、Kotlin、JavaScriptなどから利用し、CPUではXNNPack、GPUではML Drift、対応するTPUやNPUでは各ハードウェアの経路を使う構成です。変換できたことと、対象端末で最適に実行できることは別の状態です。変換時の警告、未対応演算子、精度評価、モデルサイズ、初回読み込み時間を保存し、元のフレームワークと結果を比較する試験が必要です。

Compiled Model APIとアクセラレーター

LiteRT V2の機能として、Compiled Model APIが挙げられています。READMEは、自動的なアクセラレーター選択、明示的なdelegate指定を減らす構成、非同期実行、NPUへの配布、入出力バッファーの効率的な処理を特徴として説明しています。アプリケーション側でハードウェアごとの分岐を書く範囲を抑えられる可能性があります。

NPUについては、主要なチップセット提供者のNPUへ一つのAPIからアクセスする統一経路が案内されています。GPU側ではML Driftと新しいバッファー相互運用性により、複数のGPUバッファー間の待ち時間を抑えるという説明があります。これらはREADMEが示す設計上の主張です。端末ごとの対応演算子、ドライバーの版、フォールバック時のCPU負荷、非同期処理の完了条件を確認しないまま、同じ速度や機能が得られると判断してはいけません。

LiteRT-LMとLiteRT.jsの二つの展開先

生成AIではLiteRT-LMが案内され、LLMを端末上へ展開する入口になります。LiteRT-LMの実行系にはPython、C++、Kotlin、Swift、JavaScriptから接続できるとREADMEの図に記載されています。通常の画像や音声モデルとは、メモリ要求、トークン生成、量子化、応答時間の評価方法が違うため、生成AIを導入する場合はモデルの種類を先に固定する必要があります。

Web向けにはLiteRT.jsがあり、WebGPUとWASMを使ってブラウザ内でクライアントサイドMLを実行します。ブラウザで処理する構成は、サーバーへ入力画像や音声を送らない設計を検討できる一方、端末ごとのWebGPU対応、初回モデル転送、ブラウザのメモリ制限、WASMへのフォールバックを確認しなければなりません。READMEの「secure」という表現だけで、アプリケーション全体の安全性や入力データの扱いまで保証されるわけではありません。

AndroidからIoTまでの対応表を読む

対応プラットフォームの表には、Android、iOS、Linux、macOS、Windows、Web、IoTが並びます。CPUは広く示され、GPU APIにはAndroidのOpenCLやOpenGL、iOSのMetal、LinuxやWindowsのWebGPUなどが挙げられています。NPUやハードウェアアクセラレーターにはGoogle Tensor、Intel、MediaTek、Qualcomm、AppleのANE、Raspberry Piなどが記載されています。

表の一部にはアスタリスクが付き、READMEは対応が今後の項目であることを示しています。チップ名が一覧にあることは、すべてのモデルと演算子が同じ経路で動くことを意味しません。対象端末を決めたら、CPUのみ、GPU、NPUの各経路で同じ入力を実行し、結果の一致、遅延、メモリ、失敗時の代替動作を記録します。WebとIoTは実行環境の差が大きいため、対応表を製品仕様書としてそのまま使わない判断が必要です。

モデル一覧とサンプルの使い方

READMEはHugging FaceのLiteRT Communityで提供されるモデルとして、Gemma 4、音声認識モデル、画像分類モデルの系統を紹介しています。サンプルアプリケーションはlitert-samplesリポジトリへ案内され、Compiled Model APIを使う例や、画像分割で事前コンパイルと端末内コンパイルを比較する例が示されています。

これらは導入を始めるための教材です。サンプルが動くことは、自分のモデル、入力サイズ、端末、配布方式で同じ結果になる証拠ではありません。サンプルのモデル版、前処理、後処理、アクセラレーター指定、評価指標を読み、自分のデータで置き換えてください。Hugging Face上の各モデルのライセンス、重みの配布条件、量子化済みかどうかも別に確認します。モデルを取得できたことと、商用アプリへ再配布できることを混同しないことが重要です。

LiteRT CLIと導入の最初の一歩

LiteRT CLIは、AIコーディングエージェントのワークフローを支援するコマンドラインツールキットとして紹介されています。READMEの簡易手順では、Python 3.13の仮想環境をuvで作り、litert-cli-nightlyを入れ、litert --helpを実行します。nightlyパッケージを使う手順であるため、試行時には取得した版と依存関係を保存してください。

このCLIはモデルを端末へ展開する全工程の代わりではありません。変換、量子化、ランタイムへの組み込み、端末側の測定、配布パッケージの作成は、モデルと対象環境に応じた確認が必要です。依存解決でエラーになる場合のヒントとしてUV_INDEX_URLもREADMEに登場しますが、環境変数を設定すれば互換性問題が消えるという意味ではありません。開発用の補助ツールと、アプリの実行時ランタイムを分けて管理してください。

リリース、ビルド、Apache-2.0

LiteRTはnightly build、continuous build、その他のビルドを用意し、安定版を6から8週間の周期で目指すとREADMEに記載しています。リリース一覧には2026年8月13日公開のv2.2.0が掲載されています。更新周期は計画の手掛かりになりますが、個別のAPI互換性や端末サポートを保証するものではありません。

ソースからのビルドではDocker、CMake、Bazelに関するドキュメントが案内されています。ライセンスはApache-2.0で、利用、複製、改変、配布や特許に関する条件を確認できます。ライセンスはセキュリティ、推論精度、サポート、可用性を保証しません。導入時は安定版かnightlyかを固定し、変換したモデルと実行ランタイムを同じ試験記録へ紐付け、対象端末での性能と精度をリリース前に再測定してください。

編集部の結論

LiteRTは、モデルを端末側へ持ち込み、CPUだけでなくGPUやNPUも使って推論したい開発者向けの基盤です。PyTorch、TensorFlow、JAXから複数の形式へ変換し、C++、Kotlin、JavaScriptなどの実行先を選べる構成は広い一方、READMEの対応表は個別端末での性能や全機能の完成を保証しません。必要なモデル、OS、アクセラレーター、量子化精度を決め、対象端末で変換から推論まで測定してください。

公式情報源

1. Official documentation
2. Official README
3. Project repository
4. Release notes