Google、オンデバイスAI用LiteRT（ライトアールティー）にC++でモデルを組み立てる「Tensor API（テンソルAPI）」SAM 2はMacBook ProでApple MLX比約1.5倍と同社

Googleは現地時間2026年10月19日、オンデバイスAI向けの実行基盤LiteRT（ライトアールティー）に、C++でモデルとその前後処理を直接組み立てられる「LiteRT Tensor API（テンソルAPI）」を公開した。Google Developers Blogの発表によると、同じC++のグラフをCPU・GPU・NPUで動かせ、モデルファイルなしでXNNPACK経由のCPU実行もできる。デモのSAM 2（Meta製の画像・動画セグメンテーションモデル）はMacBook Proで、同社のテストではApple MLXの約1.5倍の速さだったという。

3行まとめ

1. Googleが2026年10月19日、LiteRTにC++でモデルを組み立てる「Tensor API」を公開。同じグラフをCPU・GPU・NPUで動かせると説明
2. SAM 2をTensor APIで書いた結果、MacBook ProでApple MLXの約1.5倍（Google測定）、WebGPUで10fps未満から30fps超（コーディングエージェントが改良）
3. 変換経路は引き続き「ほとんどのプロジェクトに勧める既定」で、Tensor APIは細かい制御が要る場合の選択肢という位置づけ

本記事の内容は、日本時間10月20日2時台に公式ページで確認したものです。

何ができるようになったのか

Tensor APIは、LiteRTランタイムの上に載る「軽量な作成層」だとブログは説明している。FullyConnected、Softmax、BatchMatMulのような演算をC++の関数として呼び、グラフを1演算ずつ組み立てる。GitHubのREADMEによると、演算は90種類以上（要素ごとの演算、活性化、reshape・transpose・gather、リダクション、matmul、conv、正規化、量子化など）で、グラフは呼び出した時点では計算せず、依存関係を記録するだけの作りだという。

ブログが挙げる特徴は4つある。

実行の仕方は2通りある。バックエンドはTensorのテンプレート引数で選ぶ。TfLiteMixinTagを付けると.tfliteファイルを書き出し、LiteRTがCPU・GPU（オープンソースのML Drift）・NPUで動かす。XnnpackMixinTagならモデルファイルなしでXNNPACK経由のCPU実行になる。両方のタグを付ければ、1つの定義から両方を選べる。READMEにはこれに加え、ML Driftで.tfliteを介さずOpenCLやWebGPU上のGPUで直接動かすMlDriftMixinTagも載っている。

ブログは使い分けの流れも示している。まずXNNPACKの直接実行で、.safetensorsから重みを読みつつ試行錯誤し、出荷するときに.tfliteを書き出してモバイルやLiteRT.js（ブラウザ）で動かす、という手順だ。

誰が使えるのか、日本では

今回取得した4つのページには、日本を含む地域別の提供条件や料金の記載は見当たらなかった（日本語版のページも確認できていない）。ブログが案内しているのは、LiteRTのGitHubリポジトリのtensor/ディレクトリ、API解説（tensor_api.md）、リファレンス実装のSAM 2サンプル（litert-samples）、ライブデモ、Gemma 4とGemma 3のLLMサンプルである。ライセンスの種類は、取得したページの文字からは読み取れなかったので、使う前にリポジトリで確認してほしい。

ビルド面では、READMEに次の記載がある。

• Bazelでのビルドが基本で、LiteRTのリポジトリ内、または自分のワークスペースから外部リポジトリとして取り込める
• CMakeは「コアとTFLiteバックエンドが対象」で、XNNPACKとML Driftのバックエンドとランナーは、現時点ではBazelのみ
• WebAssemblyの場合は、C++で書いてEmscriptenでコンパイルし、できた.tfliteをLiteRT.js（WebGPU）に渡す

READMEの手順を見る限り、C++で書いてBazel（一部はCMake）でビルドすることが前提になっている。

数字はどこまで確かか

ブログの数字は次のとおりで、いずれもGoogleの測定・説明だ。

litert-samplesのREADMEには、ベンチマークの条件が書かれている。入力は中心に白い円を置いた512x512の合成画像で、GPUはfp16、5回のウォームアップのあとに20回を計測し、中央値を取る。MLX側の比較対象は、Python版MLX（avbiswas/sam2-mlx）とiOSのMLX-Swiftである。再現用のコマンドも載っている。

Tensor APIのREADMEには、別の数字もある。セグメンテーションのサンプルで、Samsung S25上のGPUゼロコピーのパイプラインは10ms、CPU経路は83msだという。

数字の条件が文書ごとに違う

ここは読み比べて気づいた点だ。ブログは「512x512でWebGPU上で30fps超」と書く。一方、Tensor APIのREADMEのSAM 2動画デモの行は「約30fps（1オブジェクト、384pxモデル、720p動画、M4 ProのChrome）」と書いている。モデルの入力解像度の表記が両者で違うので、「30fps」を単純に比べるのは避けたほうがよい。どちらが何を指すのかは、今回のページからは判別できなかった。

前と何が違うのか

ブログは、従来の道をこう整理している。まず、PyTorchのモデルをLiteRT Torchで変換してLiteRTランタイムで動かす方法は「最も早く確実な本番への道」で、ほとんどのプロジェクトに勧めるという。ただし、新しいアーキテクチャに対応したい、フレームワーク側の更新を待たずに別の変換方針を試したい、といった場合には、開発者がネイティブC++やシェーダー言語で計算を手書きしてきた。

ブログはその例として、Apple MLXとllama.cppを挙げている。そうした実装はMetal・OpenCL・Vulkanなど特定のバックエンドに強く結びつき、ハードが変わるたびに書き直しになる。CPU・GPU・NPUをまたぐバッファの受け渡しと同期、前処理・推論・後処理のつなぎ込みにも、手作業が多くかかるという。Tensor APIはこの両立（ネイティブ作成の自由度と、複数ハードで動く移植性）を狙うもの、というのがGoogleの説明だ。

筆者が公式ページで確かめたこと

日本時間10月20日2時14分台にブログを取得した時点で、「Times cover…（時間は…を含む）」という注記から測定時間の表か図があるとみられるが、取得した本文の文字には数値が出ておらず、読めた数字は「約1.5倍」という記述と、その注記（前後処理は約0.34ms加算、出力は参照実装と一致）だけだった。iOSやAndroidでの具体的なミリ秒は、今回の取得結果では確認できていない。代わりに、litert-samplesのREADMEで測定条件と手順を読み、Tensor APIのREADMEと突き合わせて上の「条件の違い」に気づいた。私が実際にビルドして動かしたわけではない。

確認できていないこと、これからの予定

• NPUの扱い：ブログは「同じグラフをNPUで動かせる」と書く一方、「今後の取り組み」として、ML Driftの直接バックエンド、NPUに向く演算、グラフ全体の自動量子化を挙げている。NPUでの性能数値は、取得したページには見当たらなかった。
• ベンチマーク機種：ブログの「MacBook Pro」について、チップの世代はブログの本文には書かれていない。
• Python版：Pythonで書いて.tfliteを書き出す機能と、画像サイズ・バッチサイズ・系列長が変わる場合の動的形状への対応拡大は、ブログが「追加中」と書いている。
• エージェントによる最適化：SAM 2の改良はGoogleのコーディングエージェント「Antigravity（アンチグラビティ）」が行い、各変更をHugging FaceのSAM 2で確かめてから採用したと書かれている。何回の試行で何が効いたかの内訳は、取得したページにはなかった。
• 全体として、性能の数字はGoogle自身による測定で、第三者の再現は今回確認できていない。

出典と確認時刻

• Native Model Authoring for Edge with LiteRT Tensor API（Google Developers Blog、2026年10月19日）
• LiteRT Tensor API README（GitHub）
• LiteRT Tensor API リファレンス（GitHub）
• SAM 2.1 画像パイプラインとベンチマーク（litert-samples、GitHub）

いずれも日本時間2026年10月20日2時14分台に取得しました。本記事は続報があり次第更新します。