本セッションでは、Googleのコーマック・ブリックがエッジデバイス上で動作する極小LLM（TLM）とエージェントスキルの最新動向について解説する。Gemma 4を用いたシステムレベルの生成AIと、アプリ内生成AIのアプローチの違いを整理し、LiteRT-LMを通じたモバイルやIoT機器へのデプロイ手法を提示する。さらに、デバイス上での関数呼び出しの仕組みや、極小モデルのファインチューニングの実装例について、デモを交えながら詳細に紹介している。
自己紹介と本セッションの概要
こんにちは、コーマック・ブリックと申します。私はGoogle AI Edgeのチームで働いており、AIモデルをエッジ環境に展開する取り組みを行っています。私たちが開発している技術は自社の製品向けに社内で使用しているものであり、同時にオープンソース製品として皆さんにも提供しているものです。この一環として、私たちはGemmaチームとも非常に緊密に連携しています。彼らもまた、エッジデバイスをターゲットとした多くのモデルを公開しているからです。
私の簡単な経歴を紹介させていただきますね。ここ10年ほど、私はずっとエッジAIに注力してきました。2016年にNeurIPSのイベントで、Raspberry Piに接続したUSB型のハードウェアアクセラレータ上でGoogleNetを動かしたのが始まりでした。長年にわたり本当に楽しい経験をしてきました。その後Intelに入社し、現在すべてのノートパソコンに搭載されているNPUのアーキテクチャ開発を主導しました。そして3年前、エッジAIのテックリードとしてGoogleに移ってきました。ご想像の通り、この数年間は本当に目まぐるしくも素晴らしい日々でした。本日は、私たちが現在どのような地点にいるのかを共有し、モバイルAIの現状や最先端の技術、そしてモデル展開の様々なパターンについて概要をお伝えできることを嬉しく思います。
このセッションで焦点を当てたいのは、極小LLMとエージェントスキルの2つです。極小LLMとは非常にサイズの小さいモデルのことです。一方、エージェントスキルはこれまで大きなモデルでしか実現できませんでしたが、現在ではより大きなモデルをデバイス上でスムーズに機能させることが可能になっています。どちらも最近になってようやく実現可能になった、非常にエキサイティングな新しい方向性です。つい先週、DeepMindチームと一緒にGemma 4をローンチした際にも、私たちはAndroidとiOSアプリの連携をサポートし、モバイルでできることの新たな可能性を切り開きました。本日はそこを深掘りしつつ、極小モデルを使ってどのようなことができるのかについても見ていきます。これがプレゼンテーションの2つの構成要素となります。
ここからは、先ほどお話しした内容の具体的な概要になります。まず、エッジにおけるAIとは何か、スモール言語モデルや極小言語モデルとはどのようなものかを見ていきます。次に、今非常に話題になっているGemmaモデルを取り上げ、私たちのチームの専門領域でもある様々な種類のエッジデバイス上でのGemmaモデルのパフォーマンスについて確認します。その後、先週公開された最新世代のGemmaモデル上に構築され、AndroidやiOSを含む多くのプラットフォームで動作するエージェントスキルについて解説します。後半では極小モデルに焦点を当て、エッジデバイス向けに極小モデルをどのようにファインチューニングしてデプロイするかを見ていきます。そして最後に、単なるサンプルアプリではなく、Gemmaテクノロジーに基づく極小LLMを使用して私たちのチームが実際に構築したリアルなアプリの例をご紹介します。
エッジAIの利点と導入のメリット
さて、皆さんはすでにこのセッションに参加されているので、エッジAIに興味をお持ちなのは言うまでもないことでしょう。エッジで処理を実行することには多くのメリットがあります。たとえば、リアルタイムの音声翻訳など、ループ内に組み込まれた非常にレイテンシに敏感な処理においては、レイテンシの削減やユーザー体験の向上が見込めます。これは私たちのチームが昨年Pixel向けに出荷した機能で、リアルタイムの音声翻訳を可能にするものです。クラウドサービスを使って必要なレイテンシ要件を満たしながらこれを実行するのは非常に困難です。そのため、オフラインかつエッジで実行できることが、レイテンシやユーザー体験の要件を満たす鍵となります。
また、プライバシーも間違いなく重要な要素です。メッセージングアプリ内でAIを使用する人々は、自分のメッセージがデバイス上に留まり、完全に暗号化されてプライベートが保たれることを望みます。LLMがデプロイされる好例として、このようにプライバシーが極めて重要なユースケースをサポートすることが挙げられます。オフラインでの使用は言うまでもなく便利ですし、コスト削減のメリットもあります。ノートパソコンのユーザーにとってもこの点はますます重要になってきており、デスクトップ環境でのエージェントのワークフローで消費するトークン処理の一部を、スモール言語モデルを使って実験的に処理しようとするトレンドが見られます。つまりコスト削減を模索している方々もいるということです。
LiteRT-LMとエッジ展開の技術スタック
私たちのチームが提供しているのは、人々がアプリを構築するためのツールです。MediaPipeや、モバイルおよびエッジで動作するLLMランタイムであるLiteRT-LM、そして標準的な推論フレームワークであるLiteRTを提供しています。LiteRTはかつてTensorFlow Liteと呼ばれていたものです。長年にわたり、これらはさまざまな製品で使用されてきました。GoogleフォトでもMediaPipeが使われていますし、YouTubeショートの面白いエフェクトを使ったことがあれば、それらも私たちのチームがYouTubeチームと共同で、MediaPipeやその裏で動くさまざまなディープラーニングトラッキングモデルを使用して構築したものです。これらもすべて同じMediaPipeとLiteRTテクノロジー上に構築されています。
今日、すべてのAndroidスマートフォンはシステムサービスの一部としてこれを使用しています。あるいは、Androidに同梱されているバージョンのスタックを基に構築されたサードパーティのアプリでも使用されています。しかし、私たちのスタックはAndroidをはるかに超えて動作します。Androidのシステムサービスとして利用できるだけでなく、同じLiteRTファイルを持ってくれば、iOS、macOS、Linux、Windows、ウェブ、あるいはIoTデバイスなどにもそのままデプロイできます。これが、この展開方法が非常に役立つ理由です。ただし一つ注意点があり、同じファイルがCPUとGPUの両方にデプロイできるということです。NPUの場合は特別なコンパイルが必要になり、結果としてNPU専用のファイルが出来上がります。とはいえ、先週公開したGemmaモデルであっても、一つのファイルで幅広いデバイスのCPUとGPUの両方で動作するという事実は間違いありません。
デバイス上のLLMで最近よく見られるユースケースとしては、プライバシー重視の処理や音声エージェント、そしてローカルエージェントによるツール呼び出しといった非常に人気のあるワークフローが挙げられます。私たちのスタックの中ではLiteRT-LMが活躍します。後ほど詳しく見ますが、これはデバイス上で極小LLMをクロスプラットフォームで実行するのに役立ち、あらゆる異なるハードウェアアクセラレータをサポートしているため非常に高速です。
システムレベル生成AIとアプリ内生成AIのトレンド
ここで非常に重要なコンセプトをお話しします。今日、2つの大きなトレンドが起きています。1つ目は、システムレベルの生成AIです。非常に大規模なモデルがモバイルフォンに搭載される場合、あるアプリを起動したときに、あなたにぴったりのレストランを見つけるためだけに40億パラメータのモデルをその都度ダウンロードするようなことは起こりません。代わりに、OS自体に大きなモデルを組み込むのがトレンドです。私たちはこれをシステムレベル生成AIと呼んでいます。これらのモデルはOSにもよりますが、大体20億から50億パラメータの範囲に収まります。私たちが緊密に連携しているAndroidチームとApple Intelligenceチームの両方が、モバイルOSベンダーとして同じような選択をしているのがわかります。
中央に組み込みモデルが存在し、AndroidではそれがAI Coreと呼ばれています。要約APIやプロンプトAPIなど、開発者が利用できるAPIのセットも増えてきています。これらのAPIはプレミアムなAndroidデバイスやAppleデバイスで利用可能です。Appleはもちろん独自のApple Intelligenceを持っていますが、トレンドとしてこれは非常に重要です。組み込みモデルを活用したいのであれば、このシステムレベルのアプローチが最適です。
もう1つのトレンドがアプリ内生成AIであり、ここで極小LLM、つまり本プレゼンテーションで私たちがTLMと呼んでいるものがより重要になってきます。システム生成AIは通常、プロンプティングや後で紹介するスキルを通じてカスタマイズされ、デバイスにプリロードされた基盤モデルです。一方、アプリ内生成AIは特定のタスク向けにカスタムされており、アプリやウェブページと一緒にロードされます。ウェブ上でも展開されています。一般的に、これらはより幅広いリーチをターゲットにしています。プレミアムデバイスだけでなくすべてのデバイスで動作することが求められます。なぜなら、私たちが仕事をしている多くのアプリ開発チームにとって、ユーザーへのリーチは非常に重要だからです。
驚くべきことに、単一のタスク向けにファインチューニングを行えば、要約や文字起こし、音声からアクションへの変換といったシンプルなタスクにおいて、LLMから非常に強力なパフォーマンスを引き出すことができます。タスクの複雑さにもよりますが、1億から5億パラメータの範囲のモデルで非常に信頼性の高いパフォーマンスを得られます。良い例として、昨年12月にFunction Gemmaをローンチしました。これは関数呼び出し専用の2億7000万パラメータのモデルです。Android開発者に関連する10種類の異なる関数呼び出しを音声から行うテストを実施したところ、社内の評価セットで85パーセントから90パーセントを超える信頼性を達成しました。この非常に小さなモデルだけでiOSやAndroidデバイスに広く展開可能であり、後ほど詳しく見るサンプルアプリで実際に試すことができます。これが極小LLMモデルの有用な使用例の一つです。
現在、アプリ内生成AIとして展開するためにモデルをファインチューニングすることへのアプリ開発チームの関心が高まっています。システム生成AIはプロンプトやスキルでカスタマイズしますが、極小LLMを実際の環境で機能させるには、ある程度のファインチューニングを行うことを強くお勧めします。特に5億パラメータ以下のモデルではそれが当てはまります。5億パラメータ以上であれば、モデルに汎用的なタスクをこなさせることもできるかもしれませんが、それ未満の本当に極小なモデルでは、本番レベルの信頼性を得るためにファインチューニングが必要だというのが私たちの経験則です。
エッジ向けモデル：Gemma 4の特徴とパフォーマンス
さて、ここからはGemma 4についてお話しします。先週ローンチされたGemma 4モデルは、先ほど説明したシステム生成AIのカテゴリーに該当します。Gemma 4を使えば、これからご覧いただくように多くの強力なことが可能です。まずサイズについてですが、2つの小さなサイズ、E2BとE4Bがあります。E2Bという名前は、モデルを実行するためにRAMに存在する必要があるパラメータが約20億個であることに由来しています。これらのモデルで私たちが見ている制限要因の一つは、デバイス内で確実に実行するためにどれだけのRAMが必要かということです。E4Bは、デバイス上で40億パラメータで実行できるように最適化されています。
モデル自体にはさらに多くのパラメータが使われていますが、モデルが使用するその他のパラメータについては、今週後半にDeepMindが詳しく説明する予定ですので、そちらのトークもご覧ください。簡単に言うと、モデルのその他のパラメータはレイヤーごとの埋め込みに使用されます。私たちのランタイムでは、実際にはそれらのパラメータをすべてロードする必要はありません。2Bと4BはRAMに常駐させて維持する必要がありますが、その他のパラメータは通常メモリマップされ、自己回帰ループの中でレイヤーごとの埋め込みテーブルの1行だけを1回ロードすれば済みます。次のトークンの推論を行うために必要なのは、数百バイトか数千バイトのデータだけです。そのため推論を進めていく中で、PLEテーブル全体をメモリにロードする必要が生じることは決してありません。OSによっては、古いトークンが使用していたメモリをうまく解放してくれます。これが、効果的という概念を持っている理由です。
小さなモデルは様々なプラットフォームで動作します。E2BおよびE4BモデルはAI Coreのロードマップに含まれています。現在実験用に利用可能なこれらのモデルは、将来の適切な時期にAndroidチームによってAI Coreに統合され、より幅広いデバイスでより広く利用できるようになる予定です。今週のこのイベントで、AI Coreチームのオリーがそのロードマップの正確な詳細を共有するトークンがあるはずです。また、DeepMindチームのオマーもGemmaの世界全体についてより深いダイブを行います。参考までにスライドの下にある2つのモデルについても触れておきますが、これらもエッジに関連するものの、今日の私のトークの焦点ではありません。これらはユーザーがノートパソコンで実行するためのもので、コンシューマー向けのノートパソコンで非常によく動くようにサイズが最適化されています。おそらく32GBのRAMを搭載しているような環境ですね。非常に強力で有用なモデルですが、今回はあまり焦点を当てません。
E2BとE4Bのどちらのモデルも、知識や推論など幅広いタスクにおいて優れたパフォーマンスを示しています。しかし、モデルのユーザーとしての私の視点から見て、前世代と比較した大きな進歩の一つは、関数呼び出しが組み込まれていることです。これは素晴らしい機能です。さらに、思考機能も組み込まれています。この思考と関数呼び出しの組み合わせこそが、デバイス上でスキルを実行する能力を解き放つのです。後ほどご覧いただきますが、スキルを記述してモデルに与えるだけで、モデルはそれを理解し使用することができます。これにより、ここ数ヶ月で非常に人気を集めているパターンをモバイルに持ち込み、新しいタイプのモバイル体験を生み出すことが可能になります。また、E2BとE4Bはマルチモーダルであり、音声、画像、テキストをサポートしています。大きいモデルは画像とテキストのみをサポートしています。
デプロイメントの観点からのもう一つの変更点は、Gemmaモデルが初めて標準的なApache 2.0ライセンスでリリースされたことです。これにより、より多くの人が使いやすくなりました。これについてもオマーのトークで詳しく聞けると思いますが、ここでも言及しておきます。
これがGemma全般についてのお話でした。次は、私たちのランタイムとプラットフォーム上でのGemmaのディープダイブです。先ほどの図と同じように、トークナイザーやモデルを実行するために必要なその他のコンポーネントを1つのパッケージに収めた単一のLiteRT-LMファイルがあります。この単一のモデルが、モバイル、デスクトップ、組み込みシステムなど、これらすべてのクラスのデバイスで動作します。特に画像入力を伴う組み込みスペースにおいて、新しいIoTユースケースの可能性が広がっていることに非常に興奮しています。
少し細かい表になりますが、パフォーマンスを掘り下げてみましょう。これは現時点でのスナップショットだと考えてください。私たちのチーム自身、そしてIntel、Raspberry Piチーム、Qualcommチームといった様々なパートナーと協力しながら、これらの数値を最適化し続けています。20億パラメータのモデルに関しては、ハイエンドのAndroidスマートフォンのGPU上で秒間数千トークンという非常に魅力的なパフォーマンスを達成できます。MacBookでも同様です。表の下2行はRaspberry Piでの実行結果で、秒間約133トークンを処理できます。これは、妥当なレイテンシでシンプルな画像分析のユースケースを実行するのに十分な速度です。
一番下の行はハードウェアアクセラレータ上で実行しているものです。これはQualcommのIoTロボティクス開発プラットフォームですが、NPUを使用することでずっと優れたパフォーマンスが得られるため、ここでも非常に魅力的な結果が出ています。E4Bモデルでも、これに比例する形である程度プリフィルとデコードのパフォーマンスは落ちますが、パラメーター数を考慮すれば当然であり、幅広いプラットフォームで利用可能です。
デバイス上でのエージェントスキルと関数の実行
では、これらのモデルで何ができるのでしょうか。本当にたくさんのことができます。単なる画像分析や音声の文字起こし、翻訳といったものをお見せするのではなく、新しくできるようになったことについてお話ししたいと思います。Gemma 4モデルは前任のモデルと比べてもそうした処理はずっと得意になっていますが、私の視点から見て最も新しいのは、デバイス上のエージェントスキルです。
私たちはiOSとAndroidの両方で利用可能なGoogle AI Galleryというアプリを用意しています。これを使うと、基本的なAIチャット、画像への質問、音声からの文字起こしや翻訳、あるいは音声から関数呼び出しへのユースケースなど、多くのことができます。本日はエージェントスキルについて深く掘り下げていきます。
デモ映像が再生されるといいのですが。これは厄介ですね。申し訳ありません。スライドを公開する前に修正しておきます。ちょっと待ってください、音声が機能するか試してみましょう。
映像は再生されていますが、音が出ていませんね。お見せしているのは、今日の気分と睡眠の記録をつけたいという音声入力から始まるデモです。今日は8時間睡眠をとって、エイミーと遊ぶのが楽しみだ、という内容を記録しています。これは気分の推移や睡眠を記録するジャーナルスキルアプリです。そして、過去7日間の気分の傾向を分析してほしいと頼んでいます。
ここで起きているのは、この気分トラッカーアプリが気分の状態や観察結果を日記に記録し、LLMが後でそのコンテンツを要約してくれるという処理です。カレンダーの確認なども行っています。ここで面白いのは、それが箇条書きのリストになっていることです。これ以上繰り返すのはやめておきます。本当に興味深いのは、これがどのように行われているかという仕組みです。
後でさらに詳しく見ますが、これはカスタムのファインチューニングではありません。私たちがモデルに対して、モデルが呼び出せるJavaScriptを少し含んだ特定のスキルを与え、自由記述のテキストインターフェースを通じてモデルがそのスキルを使用し、適用しているだけなのです。この場面では実際には2つのスキルが呼ばれています。1つは気分トラッカーのスキルで、もう1つはマップスキルでした。そして今、Wikipediaをクエリするスキルを使ってオスカーの最新情報を検索しています。
時間が止まったような静的なモデルではなく、地図検索や音声でエントリーを追加・削除できるインタラクティブなジャーナル、さらには最新の関連知識を追加するようなスキルを使って、モデルを拡張することが非常に簡単になっています。ここではWikipediaの情報を表示しています。
これもチームの誰かが開発した面白いスキルで、ムードミュージックスキルというものです。1枚の画像に基づいて音楽を作曲するウェブサービスを呼び出して、それを再生します。誰かの朝食のシーンに合わせてローファイ音楽を作曲するといった具合です。これはモデルを本当に簡単に拡張できる新しいパラダイムであり、後で裏側の仕組みを見たときにお分かりいただけるように、かなりローコードな方法で実現しています。
デモはこのくらいにして、これらをどのように構築したかについて説明します。私たちが構築したスキルは非常に効率的です。指示はオンデマンドでロードすることができます。これは条件付きの深さのプログレッシブ・ディスクロージャーと呼ばれる原理を使用しています。MCPワークフローのように必要なすべての関数についてすべてを記述しなければならないのとは異なり、私たちが構造化したスキルは、エージェントが最初に見るのはスキルの1行の説明だけです。もしエージェントがそれが面白そう、役に立ちそうだと判断した場合、さらに詳細を求めます。エージェントはスキルをロードするためのスキルを教えられています。そこでエージェントはスキルをロードし、それをどのように使うか、そのスキルを実行するためにどの関数呼び出しを使えるかというすべての詳細を調べます。
このパターンは、エッジモデルにおけるトークン効率と信頼性の観点から特に重要です。もしすべてのスキルの詳細をエッジモデルのコンテキストにロードしなければならないとしたら、モデルが推論しなければならないコンテキストの量が膨大になってしまいます。軽量なモデルでは、それは最終的にパフォーマンスを低下させます。軽量モデルはデバイス上で実行できる点は素晴らしいのですが、非常に長いコンテキストウィンドウにわたる推論能力には限界があるからです。コンテキストウィンドウをより凝縮することができれば、特定のアプリを出荷する際に見ている品質指標、つまり打率を上げることができます。
2つ目の部分はツールアクセスです。これは新しいツールを動的に統合するのに役立ちます。Wikipediaや天気予報サービスを調べるような、より多くの情報を取得するための入力ツールのセットがあります。また、マップで何かを表示したり、カードで表示したりするなど、新しい出力をユーザーに提示するのに役立つ出力ツールのセットもあります。入力と出力を拡張するスキルの両方を持たせることができます。また、ドメイン固有の知識ベースを導入するのにも役立ちます。先ほどのWikipediaを呼び出すスキルは、社内の顧客CRMやローカルのRAGシステムからデータを求めるスキルに簡単に置き換えることができるでしょう。
スキルのアーキテクチャと実装の裏側
スキルの構造の中には、skill.mdというファイルがあり、オプションでスクリプトやアセットがあります。skill.mdは常に処理されるメタデータです。ここにある例はPDFからテキストと表を抽出するもので、PDFをトリガーとして抽出を行います。指示はモデルがそのスキルが必要だと判断したときにのみロードされ、このパターンが特に重要になります。scriptsフォルダの中では、カスタムのJavaScriptを書くこともサポートしており、アプリ内でレンダリングすることができます。これはiOSとAndroid両方のシステム内で拡張するための非常に簡単な方法です。
少し深く掘り下げると、アプリに同梱されている独自のシステムプロンプトがあります。そこに一連のスキルの説明がシステムプロンプトに追加されます。そしてユーザーが何かを求めたとき、モデルはメタデータを読んでスキルをトリガーするかどうかを決定します。その後、内部にあるスキルのロードアプリを呼び出します。その関数呼び出しからのツール応答が、skill.mdファイルの内容になります。これでその内容がコンテキストウィンドウに入り、モデルはこれらの関数について知ることになります。そして実行を呼び出します。ここにはJavaScriptも含まれており、スキルファイルから取得したJavaScriptを実行するツールを呼び出し、その応答も呼び出します。
このワークフローの一部として言及しておくべきもう一つのことは、Function Gemmaを信頼性のために移植した際に行ったことの一つが、ランタイム内に制約付きデコーディングを適用したことです。ただしこれは、ツールを呼び出して出力を生成するときにのみ適用されるように調整されています。また、呼び出すべき特定のツールに絞って制約をかけることもできます。つまり、このシステムでは一般的なJSONの制約を持つだけでなく、モデルが使用できるツールが限られた有限のセットであることを知っているため、より強力な制約付きデコーディングを行うことができます。これにより、システム全体としてより信頼性の高いものが構築できます。
モデルの能力が向上するにつれて、例えば100億パラメータのような非常に大きなモデルを実行している場合は、このような厳密な制約付きデコーディングから得られるマージンはそれほど重要ではなくなりますが、20億パラメータのモデルのようなデバイス上の非常に小さなモデルにとっては、強力なガードレールを提供し、本番環境で有用な品質に引き上げるための非常に役立つツールとなります。
アプリ内では使用するスキルを切り替えることができます。任意の時点で有効にしておくスキルの説明の数も決めることができます。これはピアノ演奏スキル、バーチャルピアノをロードしているところです。実際にキーをタップして音を鳴らすことができます。これはJavaScriptを使ったものです。また、カスタムスキルをロードすることもできます。自分でスキルを書いてURLからロードできるので、自分のアプリのアイデアのためにGemmaでスキルをプロトタイピングしたい場合にとても楽しい機能です。
スキルにはAPIキー、つまりシークレットキーを持たせることもできるので、ウェブサービスを使用する必要がある場合は、ユーザーにキーの入力を促すことができます。これは先ほどのムードミュージックの例ですね。GitHubのページにはディスカッションの場があり、ユーザーが自分で書いたスキルを投稿しています。コミュニティのスキルで私たちが気に入ったものは、アプリの注目のスキルとして引き上げて紹介することができます。
ここで重要なポイントは、モデルを拡張するための障壁が非常に低いということです。エンドユーザーにとって関連性の高い方法でモデルを拡張することが、非常に簡単になっています。これから、それがどれほど簡単かをもう少し深く見ていきましょう。
スキルのアーキテクチャをもう一段階深く見ると、独自のオーケストレーターがあります。スキルレジストリがあり、スキルをロードするためのスキルを呼び出します。スキルの中にはJavaScriptスキルや、ネイティブインテントがあります。少なくともAndroidシステムでは、Androidシステムインテントやネイティブインテントを呼び出すことができ、スキルの中でそれらを使用することができます。たとえばWi-Fiのオンオフを切り替えたい場合など、JavaScriptで利用可能なAndroid全体に公開されているインテントは確実に使用できます。そして、ペルソナやシナリオデータとなるskill.mdがあり、特定のリソースがあります。先ほど言ったように、完全にオフラインで実行されるJavaScriptの場合もあれば、音楽作曲スキルのようにWeb APIを呼び出してAPIキーが必要になり、ユーザーにプロンプトが表示されるものもあります。これらもGalleryアプリ内で動作します。
内部で持っている定義済みのツールとして、スキルをロードする機能、JavaScriptを実行する機能、インテントを実行する機能があります。オーケストレーターはこれら3つのスキルを使用するだけで、システム全体を機能させることができます。
これも効果をテストする例です。私たちのGeminiのプロダクトマネージャーが、レストランルーレットスキルを見せています。英語で返信してくださいとお願いしていますね。実は、Gemini CLIやクラウドコードを使ってスキルを開発するのは非常に簡単で、チームに約80個のスキルを作ってもらいました。何を見せるかについてたくさんの選択肢がありましたし、みんな開発を楽しんでいました。
これがレストランルーレットの構造です。APIキーの入力を求め、10件のレストランを検索し、場所と料理を返します。そしてindex.jsファイルがあり、シンプルなWebビューをレンダリングして本物のルーレットのように表示し、ご自身でコードを書くこともできます。ソースコード全体が利用可能です。
私たちが最もよく使ったパターンは、スキルを書くためにスキルを使うというものでした。Gemini CLI、クラウドコード、またはアンチグラビティを使用します。AI Edge Gallery用のスキルを書きたいと伝えるだけでいいのです。Gemini CLIで機能する例として、ドキュメントやいくつかのスキルの例を読ませてから、作りたいスキルをおねがいします。この時はオフラインアーカイバーでした。例えばロンドンで撮った写真に基づいて、通り過ぎたチャーチルの銅像について調査し、帰りの飛行機の中で読めるように情報をまとめてくれるといったアイデアです。Wikipediaのコンテンツを取得してローカルに保存し、インデックスを作成します。
CLIを使用すると、Android ADBスキルがあるので、ADB経由で接続された電話を使ってスキル自体をテストするよう依頼することもできます。アプリが実際に動作するか、アプリ内でスキルが意図した通りに機能するかをテストし、検証して返してくれます。
約80のスキルのうち半分以上は、最初はバイブコーディングで作成されたものでした。これにより、読者にとって有用な方法でLLMを拡張して新しいことを行うための障壁が大幅に下がります。
ここで質問がありました。ここにある例はすべてデバイス上の最小モデルで動いているのですか、というご質問ですね。録画用にもう一度繰り返します。すべての例は4B、つまり40億パラメータモデルで動いています。2Bモデルでもスキルは機能しますが、スキルの複雑さや数によっては結果が変わる可能性があります。
ChromeのCVP拡張で試してみましたかというご質問ですね。ローカルモデルを使ってブラウザで動かすというアイデアです。まだやっていませんが、試してみる価値のある面白いアイデアです。
Galleryアプリについていくつか言及しておきます。Galleryはオープンソースプロジェクトであり、最初にお見せしたLiteRT-LMのツーリングの上に構築されています。アプリ自体、遊んでいて楽しいですし、電話上のモデルでこれが可能か、どれくらいの速度で動くかといったプロトタイピングにも使えます。ソースコードにも完全にアクセスできます。モデルはオープンソースのLiteRTやLiteRT-LMのインフラストラクチャの上で動いています。もしGalleryで気に入ったものがあれば、基礎となるオープンソースAPIを取り出し、Hugging Faceのページからモデルを引っ張ってきて直接実行することで、同じ体験や速度を得ることができます。Galleryに関するGitHubディスカッションでは、コミュニティがアップロードしたエンターテインメントからブラックジャックまで、様々なスキルが紹介されています。自分でスキルを開発したら、ぜひそこに投稿して他の人が見つけやすくしてください。
極小モデルのファインチューニングとアプリへのデプロイ
次に話題を変えます。スキルに関して見てきたことは、主にモバイルフォンでシステム生成AIとして展開される2Bや4Bモデルに当てはまるものでした。IoTやデスクトップなどの用途では、自分でモデルをロードして、先ほど見たQualcommのIoTプラットフォームのような本番環境で使うこともできます。しかし、今日アプリ内にモデルをデプロイし、本番環境のアプリとして出荷する場合、より小さなモデルを使用する人が増えています。私たちが極小モデルと呼んでいる、10億パラメータ未満のモデルです。アプリ内にLLMをデプロイするチームと協力する際に見られるワークフローを簡単に見てみましょう。
Galleryを動かしているエンジンであるLiteRT-LM自体もオープンソースプロジェクトで、C++とJavaのAPIを持っています。Swift APIもまもなく登場しますし、先週からPython APIも追加され、Pythonでの開発を好むIoT開発者にとって有用です。これはLLMファイルを取り込み、自己回帰ループを完全に実行するために必要なコンポーネントを持ち、使いやすいAPIを介してそれを公開します。クロスプラットフォームであり、ハードウェアアクセラレーションとも同じAPIで使用できます。Gemma 4向けにはまだ公開していませんが、過去の小さなモデル向けにはMediaTekやIntelのシリコンで動作するものも公開しています。
ワークフローとしては、Transformersから始まり、LiteRT向けに最適化し量子化も組み込まれたLiteRT Torchというパッケージを使います。そこからLiteRT-LMファイルが生成され、Galleryアプリでプロトタイピングするか、任意のプラットフォームでLiteRT-LMを使用して直接デプロイします。高度なユースケース向けにはLiteRT Torch Generative APIがあり、独自の極小モデルをゼロから書き、トレーニングすることもサポートしています。
NPUへのデプロイに関するスタックの図です。重要なポイントは2つあります。1つ目は、私たちが最適化ライブラリに多大な投資を行っているということです。CPU向けのXNNPACKと、GPU向けの最適化ライブラリがあります。Googleの多くのファーストパーティアプリがこれらに依存しているため、優れたパフォーマンスを発揮し、可能な限り幅広いデバイスで動作するようにすることに非常に意欲的です。これらはJITワークフローを使用し、CPUとGPUの両方で機能する単一のアーティファクトを生成します。NPUの場合は少し特殊で、AOTコンパイルワークフローを使用し、事前にベンダーのコンパイラプラグインを呼び出して、特定のNPUに特化したアーティファクトを生成する必要があります。しかし、実際のアプリ開発ワークフローはNPU、CPU、GPU間で非常に似ており、エクスポートと推論はとてもシンプルです。
サードパーティのモデルもサポートしています。Qwenの60億パラメータモデルがアプリ内で動作している様子や、Hugging Faceから任意のLiteRT-LMファイルをロードして実行し、ベンチマークの統計情報を取得できることも示しています。各チャットの下にあるアイコンをクリックすると、プリフィルやデコードの統計情報が表示されます。
別のサードパーティモデルとして、AppleのFastVLMという5億パラメータの素晴らしいモデルがあります。これはQualcommのハードウェアアクセラレーションを使って非常に高速に動作しています。動画入力を伴いながらシーンを説明してとループで実行しています。デバイス上にデプロイ可能なモデルで何ができるかを示す良い例です。4ビット量子化を行えば、アプリのサイズに250メガバイトから260メガバイト追加するだけでこの体験を提供できるでしょう。このような汎用的な5億パラメータの極小モデルもありますが、特定のタスクにはファインチューニングが必要です。他にも文字起こしや翻訳に特化した小さなモデルがたくさんあり、Hugging Faceのページでサポートしています。
私たちが発表したFunction Gemmaは、関数呼び出しのためにさらにファインチューニングできる汎用モデルであり、Colabノートブックも用意しています。Gemmaモデルが公開される際、PTやITの接尾辞がつくことがあります。関数呼び出しのやり方をモデルに教えるのは実際には指示チューニングを通じて行われるため、関数呼び出し用にファインチューニングするためのモデルとして公開されたFunction GemmaはITモデルです。完全なファインチューニングを自分で行いたい専門家向けにはPTチェックポイントが役立ちます。また、Embedding Gemmaという3億パラメータの強力なテキスト埋め込みモデルもあり、RAGのユースケースに非常に役立ちます。これもデバイス上のユースケースに有用な極小モデルの例です。
より高度な使い方として、コードディレクトリを使って独自のLLaMAやPhi、Qwenのバリアントを完全にカスタマイズして書くこともできます。
実践例：音声文字起こしとテキスト推敲アプリ「Eloquent」
極小LLMを使って構築した実際のアプリの例として、AI Edge EloquentというiOSアプリを紹介します。これは文字起こしモデルですが、プレゼンテーションでよくある「ええと」や「あの」といった言葉の言い淀みを自動的に推敲して削除してくれる機能を持っています。後で使うためにメッセージを口述筆記したい場合、話し言葉の癖をきれいに整えてくれます。また、特定の技術用語を正しく認識するためのバイアスリスト機能もあります。例えばLLMの文脈でのLoRAなどです。これらをすべてオフラインで、無料で実行できます。
アーキテクチャとしては、マイク入力が音声認識エンジンに入り、フィルタリングされていない文字起こしが生成されます。それと個別の単語リストが、テキスト推敲専用の極小LLMエンジンに入力されます。これらを1つのLLMで構築することもできたかもしれませんが、モバイル開発の現実として、文字起こしエンジンをアプリ内の他のユースケースでもモジュールとして再利用したいという要望があります。そのため、モジュール性を考慮してモデルを分けるという実用的な選択をしています。
これらのエンジンは公式に公開されたGemmaモデルそのものではなく、Gemma 3の270Mモデルから派生させ、文字起こしやテキスト推敲のために私たちがファインチューニングしたものです。クラウド上の強力なLLMを使って大量の合成データを生成し、それを基に極小モデルをファインチューニングするというアプローチをとっています。このワークフローは非常に強力で、社内でも多くのプロダクトで活用されています。
質疑応答
推敲のステップに関する質問ですね。メインモデルの中で行われるのか、それとも別なのかというご質問ですが、先ほど説明したように別のモデルに分けて推敲を行っています。
ファインチューニングに関する質問ですね。10個の関数呼び出しで86パーセントの信頼性とのことですが、ファインチューニング前はどれくらいでしたかというご質問です。おおよそ40数パーセントだったものが86パーセントに向上しました。特定の簡単な関数では93パーセントを超える非常に高い信頼性がありましたが、いくつかの難しい関数が平均を下げていました。極小モデルにおいて、ファインチューニングは評価指標を20から40ポイントも押し上げる非常に重要な要素です。
Web向けのColabについてのご質問です。LiteRTファイルを出力するまでのColabはありますが、Web上でのLiteRT-LMのサポートは現在進行中です。最新状況はGitHubをご確認ください。
Gemma 4の極小モデルのファインチューニングマニュアルについてのご質問です。先週公開されたのはスモールとミディアムサイズであり、現時点で私たちが公開している極小モデルはGemma 3系のものです。そちらについてはワークフローが公開されています。
Eloquentアプリがヨーロッパでダウンロードできない件については、大変有用なフィードバックとしてチームに持ち帰ります。
まとめです。システム生成AIとしての中規模または小規模モデルがモバイルデバイスで普及しつつあります。これらは組み込みプラットフォームにも最適です。デバイスのメモリ制限を考慮すると、広くデプロイするには極小モデルが最適です。私たちはDeepMindとのパートナーシップを通じて、より強力なモデルを提供し、ファインチューニングのワークフローをできるだけ簡単にして、この技術をよりアクセスしやすいものにしたいと考えています。
エッジモデルの安全性についてのご質問ですね。Gemmaチームは安全性に多大な時間を費やしています。システム生成AIとしてOSに組み込まれる際には、システムベンダー側でも入力と出力の安全性チェッカーを追加するレイヤーが設けられます。極小モデルの場合は、APIや機能のスコープが非常に限定的になるため、モデルが完全に予測不可能な回答を生成するリスクが低く、安全性の担保がしやすいという利点があります。
5090へのデプロイに関するご質問です。直接的なドキュメントは思い当たりませんが、NvidiaはGemmaのパートナーであり、彼らのTensorRT-LLMでサポートされているはずですので、Nvidiaのウェブサイトを確認してみてください。
複数のスキルをチェーンで実行することに関するご質問です。アプリ内で複数のスキルをオンにして、プロンプトで明確に指示を出せば機能します。例えばWikipediaで調べて、3つのポイントに要約し、フラッシュカードで表示してといった具合です。ただ、モデルが出たばかりなので、どこまで複雑なスキルスタックが可能かは現在も限界をテストしている段階です。
コンテキストウィンドウについてのご質問です。E2BとE4Bのモデルは32Kまでサポートしており、より大きなモデルは128Kをサポートしています。私たちのGalleryアプリではパフォーマンスの理由から8Kや12Kをデフォルトにしていますが、メモリの最適化もしっかり行われています。
iOSアプリについてのご質問です。AI Edge GalleryはiOSとAndroidの両方で利用可能で、オープンソースです。macOS版は今後の課題としておきます。
ファインチューニングと複数モデルのメモリ消費のトレードオフについてのご質問です。E2Bのようなサイズであればスキルやプロンプトによるカスタマイズを推奨します。より極小のモデルであればファインチューニングを推奨します。また、LoRAを使ったファインチューニングであれば、モデルをロードしたままLoRAアダプターを動的に入れ替えできるため、数十メガバイト程度の小さな容量の追加で複数のタスクを切り替えることができ、ロボティクスなどの組み込みシステムに非常に適しています。
ありがとうございました。時間になりましたので、これで終わりにします。ランチを楽しんでください。
コメント