この記事は、Antigravity SDK（記事の説明では、Google Antigravity を支えているのと同じエージェント型の機能を使って開発者が開発できるようにするもの）が、さまざまなローカルモデルと実行オプションにわたってローカルのワークフローをサポートすることを発表している。最初のサポート対象は、Google AI Edge の LiteRT 上で動作する Gemma 4 26B A4B である。記事は、この新しいサポートによってエージェント型の支援をローカルモデル上で完全にオフラインで実行できると述べ、それとは別に、ローカルマシンが発揮できる性能をより引き出すため、ワークフローを LiteRT と Gemma 4 26B に向けて最適化し、ローカルの GPU と RAM を効率的に使えるようにしたと述べている。
記事の大部分はデモンストレーションである。SDK と LiteRT-LM のインストール、モデルのインポート、LiteRTAgentConfig で設定したエージェントの実行という短いセットアップの後、2 つの例を示している。クラウドのモデルが計画を立て、ローカルモデルの群れがセキュリティパッチの適用タスクを実行するハイブリッドなパイプラインと、ローカルのエージェントが 1 つのプロンプトからターミナル用のリソース監視ユーティリティを構築する例である。
要点
- エージェントをローカルで実行する理由として 4 つが挙げられている。API のコストやレート制限がないこと、コードとリクエストをローカルマシン上にとどめられるプライバシー（記事はコンプライアンス上の制約がある企業環境向けとして特に取り上げている）、接続が不安定な場所でのオフラインでの耐障害性、そしてトークン効率の高いローカルの処理と、必要に応じたより大きなクラウドモデルとを組み合わせるハイブリッドなワークフローである。
- 推奨されるハードウェアは、24GB を超える VRAM またはユニファイドメモリを備えたマシンである。
- 記事は Architect-Builder パターンを、クラウドモデルの規模とローカルモデルの利点を組み合わせる良い方法として説明している。そのデモでは、クラウドの Gemini 3.8 Flash が計画役と指揮役を務め、ローカルの Gemma 4 26B のインスタンスが重い作業を担う。
- そのデモでは、クラウドのモデルが 3 つの脆弱なモジュールに対する監査とパッチ適用のタスクを、ファイル名とタスクの説明だけを使って分解するため、ソースコードはマシンの外に出ない。その後ローカルのモデルが、記事が敵対的監査ループと呼ぶものを実行する。脆弱性を再現し、修正の候補を書き、パッチを批評し、回帰テストスイートに照らして検証する。
- 記録されたその実行について、記事は、クラウドのモデルが消費したトークンは 95 で、全トークン（3,322）の 97.2% がローカルで処理され、テストに合格する検証済みのパッチが得られたと報告している。これらは Google 自身のデモの 1 回の実行から得られた数値である。
- 2 つ目の例では、エージェントが psutil と rich のライブラリを使った Python のターミナルダッシュボードを書き、その
requirements.txtを生成し、結果をテストする。これらはすべてローカルマシン上で行われる。 - SDK は LiteRT のほかに、
LocalOpenAIAgentConfigを通じて任意の OpenAI 互換サーバー（Ollama、LM Studio、vLLM が挙げられている）をサポートしており、記事によれば、これによって開発者はエージェントのオーケストレーション、ツール、ワークフローを変えることなくローカルの推論バックエンドを差し替えられる。
背景
これはベンダー自身による発表であり、その性能に関する記述は評価ではなく自社のデモンストレーションから得られたものである。このハイブリッドのデモは、計画と実行を規模も場所も異なるモデルの間で分担する具体例である。計画役はタスクの説明とファイル名を見て、実行役はコードを見る。記事は、この分担がプライバシーとコストの両方に役立つと論じている。