LiteRT-LM v0.19.0：ウェブモデルのストリーミング、音声モデルのサポート

1. ウェブモデルを複数の入力経路から読み込む

v0.19.0のリリースノートによると、ウェブSDKは全モデルを分割して受信・処理するストリーミング方式で読み込み、実際の演算を担う処理環境であるGPUバックエンドを標準で使用する。画像と音声の入力にも対応した。ウェブAPIガイドは、モデルの動作を決める数値情報であるモデルの重みをアドレスから直接取得し、ストリーミングすると説明する。開発者はリモートアドレスだけでなく、ブラウザー内のデータもモデル入力に接続できる。

ウェブAPIガイドはモデル入力としてHTTP・HTTPSアドレス、Hugging Faceリポジトリを指すアドレス、ブラウザーのファイルやバイトストリーム、順に渡されるデータの流れを挙げる。リポジトリのアドレスだけを渡すと、エンジンのバックエンドに合うモデルファイルを選ぶ。複数のファイルが条件に合う場合は1つを読み込み、残りのファイルを警告で知らせる。

最も簡単な例は、モデルリポジトリのアドレスをエンジンに渡す方法だ。

const engine = await Engine.create({
  // The model's Hugging Face repository
  model: 'hf://litert-community/gemma-4-E2B-it-litert-lm',
  // Or the URL of a model file, on Hugging Face or anywhere else
  // model: 'https://huggingface.co/litert-community/gemma-4-E2B-it-litert-lm/resolve/main/gemma-4-E2B-it-gpu.litertlm',
});

モデルの読み込み後はエンジンで会話を作成して使用する。ウェブAPIガイドは、使用後にエンジンを削除してリソースを解放するよう案内している。

2. ウェブの遅延は入力形式によって変わる

Googleの発表によると、EmbeddingGemma 2はMacBook Pro M5でWebGPUを使用した際、以下の遅延時間を記録した。概要ページに記載されたモデルサイズは485 MBだ。入力の組み合わせを変えるとウェブアプリの待ち時間がどう変化するかを示す実行例だ。

表：ウェブ入力の組み合わせ別の遅延時間

条件：EmbeddingGemma 2（740Mマルチモーダル、485 MB）、MacBook Pro M5、WebGPU、Google AI Edgeドキュメントに基づく

単位：ミリ秒

テキストに画像や音声を加えた入力は、テキストだけの場合より遅延が長かった。そのため、ブラウザーにマルチモーダル処理を組み込む際は、入力方式による待ち時間の差を製品の操作フローに反映する必要がある。

3. 音声認識と合成モデルを1つの実行基盤にまとめる

リリースノートはQwen3-ASRなどの音声認識モデルとKokoroなどの合成モデルへの対応を発表した。リポジトリの実験用実行ツールは、モデルごとに別々のツールを使う代わりに、1つの実行ファイルと共通のC++インターフェースで入力を渡して出力を受け取る構造だ。

Qwen3-TTSも新たな対応リストに加わった。この共通実行基盤では、エンジンを一度作成してからセッションにテキストや音声を入力し、結果を小さな単位で受け取って処理する。

Kokoroのモデルカードは、82Mパラメーターのモデルを351 MBの単一ファイルにまとめ、24 kHzの音声と9の言語・方言、54の音声を提供すると説明する。GPU用ファイルは中間的な音響表現を実際の音に変換する部分をGPUで処理し、汎用ファイルはCPUとGPUで使用できる。

モデルカードに掲載された同社発表によると、Galaxy S26で18.3秒の英語の段落をaf_heartの音声で合成した際、GPU用ファイルは4.0秒、実行中の最大メモリ使用量であるピークメモリは485 MBを記録した。Snapdragon 8 Elite Gen 5とAdreno GPUを搭載した機器でCPUを4スレッド使用し、測定前に実行して状態を安定させるウォームアップを1回行った結果だ。

同じ段落・音声・ウォームアップ条件で汎用ファイルをGPUで実行すると3.9秒と1,030–1,225 MB、CPUで実行すると4.7秒と975 MBだった。GPU用ファイルは、この機器のGPU実行同士で比較すると、合成速度をほぼ維持しながらメモリ使用量を抑える選択肢だ。

4. C API 1.0.0はエラーと結果の受け渡し方法を変える

今回のリリースはC APIを1.0.0に引き上げ、互換性を損なう変更を含む。失敗する可能性のある関数は状態コードを返し、結果をout_*パラメーターで渡す。外部から呼び出せるよう公開された関数名であるエクスポートシンボルも、litert_lm_*系統に限定する。既存の関数シグネチャ、つまり関数名と入出力の規則に合わせて書かれたCコードは、新しいヘッダーに合わせて修正する必要がある。

ヘッダーには、実際に読み込まれたライブラリのAPIバージョンを確認する関数が追加された。呼び出し側はコンパイルに使用したヘッダーのバージョンと、実行中のライブラリのバージョンを比較できる。アプリとは別にライブラリを入れ替える配布方式なら、この確認を連携手順に組み込める。

エラー処理の規則も変わった。成功は0、失敗は正の状態コードで、失敗した呼び出しのスレッドで最後のエラーメッセージを読む。ポインターの結果は失敗時にNULLに設定され、数値型の結果は失敗時には書き込まれない。負の戻り値を検査していたコードは、状態コードの判定に変更する必要がある。

5. 実行経路の拡大とリソース・移行コストを併せて検討する

共通実行ツールは複数の音声モデルを扱う手間を減らす代わりに、対応モデルの実装をまとめてリンクする。独自のアプリは必要なモデル実装だけをリンクし、未使用の依存関係と実行ファイルのサイズを減らせる。機能拡充の利点を得ながら配布サイズを管理する方法だ。

GPU用の音声ファイルを選ぶ際は、LiteRTのGPU実行に対応した機器が必要だ。また、1.0.0より前のライブラリにはAPIバージョン確認関数がないため、実行中に必要なライブラリを読み込む動的ローディング方式のアプリは、この関数が見つからなければ互換性のないライブラリとして扱う必要がある。

今回の更新の実質的な価値はウェブと音声モデルの活用経路を広げる点にあり、導入判断では機器のリソースとC APIの移行作業も併せて検討する必要がある。