ARTEMIS vs LFM2.5-2.6B-Base：その役割を果たせないチェックポイントと、それを必要とするハーネス

Google の ARTEMIS ロードマップには 4 つの項目があり、そのうちちょうど 1 つだけが、まだ明らかに存在しないモデルを必要としている。すなわち、低遅延でプライバシー優先の自動化のための、オンデバイス軽量視覚言語モデルだ。そうした用途の明白な候補は、LFM2.5-2.6B-Base のサイズクラスにあるもの、つまり Liquid AI の 26.9 億パラメータの事前学習済みチェックポイントで、オープンウェイトとして公開され、131,072 トークンのコンテキストと、スマートフォンに収まるほど小さいフットプリントを持つ。また、出荷時の状態では、その枠を埋めることはできない。そしてその理由は、誰かが両者を比較表に並べる前に理解しておく価値がある。Google の ARTEMIS は自然言語による Android 自動化ハーネスで、2026 年 8 月に Apache 2.0 の下でオープンソース化され、ADB を通じて実機の端末を操作し、Google Research の AndroidWorld ベンチマークで 99% 以上の完了率を主張している。LFM2.5-2.6B-Base は、指示チューニングもチャットテンプレートもなく、—意図的に—公開ベンチマークもない生の事前学習素材であり、自ら事後学習を行うチーム向けのものだ。一方は完成したソフトウェアで、未完成のモデル問題を抱えている。もう一方は未完成の重みで、完成したライセンス問題を抱えている。どちらも他方の代替ではなく、両者が本当に出会う場所は、あなたが推測するような場所ではない。

LFM2.5-2.6B-Baseとは実際には何なのか

ブランディングを剥ぎ取れば、それはオンデバイス処理のための入念に築かれた基盤であり、その仕様は、リーダーボードでの順位よりもメモリ帯域幅に最適化したかのように読める。

• サイズ — bfloat16 で 2.69B パラメータ、単一の約 5.39 GB シャードに格納され、「2.6B」として謳われている。

• アーキテクチャ — ハイブリッド分割で30層：8つのグループ化クエリ・アテンション層に対して22の二重ゲート付きショート畳み込みブロック、隠れ幅2048、8つのKVヘッドに対して32のアテンションヘッド、埋め込み共有。前世代と同じcode>Lfm2ForCausalLM/code> クラスなので、カスタムモデリングコードは不要です。

• トレーニング — 約34兆トークン、コンテキスト拡張のための専用の中間トレーニングフェーズを含む。

• 語彙 — 128,000トークン。非ラテン文字をより適切に扱えるよう、この世代で倍増しました。約2億6,200万パラメータ（モデルのおよそ10分の1）が、タイド埋め込みに含まれています。

• コンテキスト — ここではモデルカードと設定が食い違っており、知っておく価値があります。ドキュメントは131,072トークンをうたっていますが、code>config.json/code> は code>max_position_embeddings/code> を128,000に設定しています。128Kを前提にし、それを超えるものは未検証として扱ってください。

• 言語 — 16言語：英語、アラビア語、中国語、フランス語、ドイツ語、ヒンディー語、インドネシア語、イタリア語、日本語、韓国語、ポーランド語、ポルトガル語、ロシア語、スペイン語、タイ語、ベトナム語。

• ベンチマーク — なし。Liquidはベースチェックポイントに関する評価を一切公開しておらず、モデルカードではこの省略を意図的なものと位置づけている。この成果物はポストトレーニングされるために存在するのであり、生の状態で測定されるためのものではない。

その最後の一行こそがこのリリースの要点であり、「X vs LFM2.5-2.6B-Base」という比較を慎重に扱わなければならない理由でもあります。ベースチェックポイントは、何事についても意見を持ちません。Androidのワークフローを計画するよう頼んでも、それは確率的にあなたのテキストを続けるだけです。なぜなら、答え方を教わったことが一度もないからです。カードがこれを推奨するのは、大規模なファインチューニングが必要なケースに限られます。すなわち、特定言語向けのアシスタント、規制の厳しい業界におけるドメイン特化型のアシスタント、独自データでの学習、あるいは蒸留における生徒モデルとしての利用です。すぐに使える用途、たとえばツール呼び出しについては、Liquidは代わりに事後学習済みのLFM2.5-2.6Bを指し示しています。

ARTEMISがモデルに求めるもの――それはベースチェックポイントが提供するものではない

ARTEMIS は 2 つのモードを持つ制御ループです。Flash はリアクティブな観察・行動サイクルで、1 ステップあたりおよそ 3～5 秒です。Pro はマルチエージェントグラフで、1 ステップあたりおよそ 15～40 秒かかり、生きた Markdown プランを保持する Planner、フルツールセットを備えた Operator、そしてチェックポイントを検証する読み取り専用の Checker を備えています。検証は code>off/code>code>strict/code> までの 4 段階です。どちらのモードも、基盤となるモデルに同じことを求めます。スクリーンショットを見て、固定されたツールセットから 1 つのアクションを選び、1～2 秒でもう一度同じことを行う。それを 100 回、流れを見失わずに続けることです。

それは要求の厳しい依頼だ――厳格なスキーマの下での指示追従、根拠に基づく視覚理解、そして長期的な一貫性――そしてそれは、ベースチェックポイントには与えられていないスキル群そのものである。ARTEMIS自身がテストしたバックエンドはホスト型モデルだ：Gemini、Claude、GPT-4o、Qwen-VL。そのどれもがツール利用のために指示チューニングされており、そのどれもが大規模である。

つまり、ギャップはサイズの問題ではありません。2.6Bの事後学習済みモデルはツール呼び出しループを維持できます——Liquid自身の事後学習済みの兄弟モデルは、その指示追従評価のすべてとツール使用評価のほぼすべてにおいてGemma 4 E2B-itおよびE4B-itを上回ると主張していますが、これらは独立した検証のないベンダー報告の数値です。ギャップとは、ベースチェックポイントにはそうした学習が一切適用されていないため、ハーネスにまったく投入できないことです。

ライセンスのほうが、より際立った違いだ

こここそが勝負が実際に決まるところであり、ほとんどの比較が飛ばしてしまう部分です。

• ARTEMIS — Apache 2.0。商用利用も、フォークも、製品への組み込みも可能で、収益条件はありません。唯一の義務は、通知を保持し、変更点を明示することです。この義務は、MinitapがARTEMISの229ファイル中228ファイルが自社のApache-2.0 code>mobile-use/code>プロジェクトと一致し、著者名がforce-pushによって削除されたと主張したことを受け、プロジェクト自身が2026年9月に公の場で修正しなければなりませんでした。現在、リポジトリにはMinitapのクレジット表記が含まれています。

• LFM2.5-2.6B-Base — LFM Open License。Apache や MIT ではなく独自ライセンスです。年間売上高が1,000万ドル未満の場合、付与は広範かつ永続的で、ロイヤルティフリーです。その閾値以上では、ライセンスは商用利用には一切及びせず、Liquid に連絡する必要があります。これを基に構築する人にとって重要な点は、派生著作物は同じ条件を継承する。ポストトレーニングしたチェックポイントは、あなたが完全に所有する新しいものではありません——収益条件付きライセンスを引き継ぎ、適格な非営利団体向けの適用除外が設けられています。

その2つの事実を並べてみると、判断はあなたが誰かによって逆転する。スマホ側のエージェントを出荷したい資金調達済み企業には、自由に使えるApache-2.0のハーネスと、商用利用がまったくできない可能性のあるチェックポイントがある。個人開発者や、しきい値未満のスタートアップには両方があり、ライセンスは脚注にすぎない。どちらのベンダーも理不尽ではない——Liquidは自社の商用ティアを守っている企業であり、Googleはテストツールをオープンソース化している——だが「オープンウェイト」と「オープンウェイト」は同じ許諾ではなく、パラメータ数で止まる比較では、自分がどちらを持っているのかは分からない。

ファミリーです。ベースチェックポイントが、そこへ入るための間違った扉だからです。

オンデバイスのAndroidエージェントを目指すなら、ベースよりも3つの兄弟のほうが重要であり、ARTEMISロードマップが実際に必要としているのは、明白なほうではない。

• LFM2.5-2.6B — 事後学習されたエージェント向けの兄弟モデル。ベンダー報告によるスループットは、スマートフォンクラスのハードウェアで毎秒約30トークン、Ryzen AI Max+ 395で113、Apple M5 Maxで220となっており、2.5 GB未満で動作します。

• LFM2.5-VL-3B — ビジョン言語エッジモデル。同じベース上に構築され、SigLIP2 400M NaFlexエンコーダーを備え、ベンダー報告によるグラウンディング precision@1 は RefCOCO で 57.1 から 87.9 に向上。Liquid の説明によれば、オンスクリーン UI 要素における性能ははるかに大規模な Gemma モデルを上回り、4.7B の Qwen 3.5 に 0.7% 差まで迫る。未検証だが、画面を見ることができるこのファミリー唯一のモデルである。

• LFM2.5-230M — 抽出・分類向けのティアであり、推論重視の作業には明示的に推奨されません。

この対戦におけるベースチェックポイントにとって不快な結論はどれか：ARTEMISのロードマップ項目はビジョン要件、ベースはテキストのみであり、そのスロットを埋めるファミリーメンバーは、すでにビジョンエンコーダとポストトレーニングの両方が適用されたVLバリアントである。Android自動化スタックにおけるベースチェックポイントの役割は、スマートフォンを操作することではない。それは、最終的にそうするであろうあらゆる小規模モデルの土台となる原材料であることだ。

両者が実際に交わるところ：まだ誰も作っていないフライホイール

修辞ではなく実在する唯一のつながりがこれであり、それは通常とは逆方向に流れている。ARTEMISで最も過小評価されている機能はエージェントではなく、そこから排出される副産物の方だ。実行ごとにクラッシュスタック、キーフレームのスクリーンショット、圧縮されたステップのセッション台帳、診断レポートを記録し、Proはアクションが失敗するたびに「実行インシデント」を開き、後で成功して解消されるまでそれをコンテキスト内に保持する。これは、UIエージェントの認識が誤っていたまさにその瞬間のラベル付きコーパスだ。

それと、その目的のすべてがポストトレーニングにあるチェックポイントを組み合わせれば、明らかなループが出来上がる。ホスト型モデルでハーネスを実行し、自分のアプリでつまずいたトレースを集め、まさにそのフレームで2.6Bモデルをファインチューニングする。これは、Liquid自身のカードがベースチェックポイントを公開する根拠として挙げている種類の独自データセットだ——「自分のデータでトレーニングする」——そして収益ゲート付きライセンスは、しきい値未満のチームには理にかなったルートであり、それを超えるチームには相談が必要になることを意味する。

はっきり言っておくと、そのアイデアの位置づけについては、誰もこのループを公表しておらず、どちらのベンダーもそれを提案しておらず、どちらの側もそれを検証した証拠もない。それは結果ではなく提案であり、そう読まれるべきものだ。しかし、この二つの成果物がカテゴリー錯誤ではなく協働者であると言えるのは、この枠組みにおいてのみである。

ファインチューニングまで進むなら、比較対象セットが問題のもう半分だ。LFM2.5-2.6B-Base は当社のカタログには載っていない——LFM2.5 のどのバリアントも載っていない——ので、そのチェックポイントは Liquid 自身の配布チャネルと、いつものサードパーティホストから入手することになる。ルーティングされたカタログが真価を発揮するのは、ツール利用において打ち負かさなければならないモデル群に対して自分のファインチューニングをベンチマークする場面だ。1つのキーと1つの請求で、しかもフェイルオーバー付きなので、あるプロバイダーの不調な午後が、あなたの評価の不調な午後にはならない。この取り組みの目的が、実際に行動に移すつもりの直接対決であるなら、それは本当に役立つものだ。

それで、どれがあなたの問題なんですか？

今四半期に Android アプリを自動でテストしたいなら、必要なのは ARTEMIS です。LFM2.5-2.6B-Base は答えの一部ではありません — ARTEMIS をホスト型ビジョンモデルに対して実行し、ステップごとに料金を支払うことになります。そして、オンデバイス VLM に関するロードマップ項目はやがて登場し、まだ測定していないコスト問題を解決するでしょう。

ネットワークのない携帯端末で動作しなければならない製品を作っているなら、小型モデル路線を選びたくなる。そしてLFM2.5-2.6B-Baseは、その解決策の一部ではなく、そのプロジェクトの始まりである。あなたはそれを事後学習することになり、最初の学習スクリプトを書く前に、収益予測と照らし合わせてLFM Open Licenseを読むことになる。そして、エージェントが画面を見る必要があるなら、代わりにVLバリアントにたどり着くことになる。

唯一やってはいけないのは、この二つを横に並べ、ハーネスのほうが高性能だと宣言して、そのまま先に進むことだ。有益な比較は、二つの完全なスタックの間で行うものだ — ホスト型モデル＋ハーネス 対 ファインチューニング済みの小型モデル＋自分で構築するフレームワーク — そしてそのうち片方だけが公開ベンチマークで成功率を公表しており、それは、もう片方にクラウド料金が一切かからないという事実とちょうど同じ価値がある。

ルーティングされたカタログがその価値を発揮するのは、ツール使用において打ち負かさなければならないモデルに対して、あなたのファインチューニングをベンチマークすることです。それは1つのキーと1つの請求で行われ、フェイルオーバーにより、プロバイダーの不調があなたの評価の不調にならないようにします。

LFM2.5-2.6B-Base は当社のカタログにはありません — LFM2.5 のいずれのバリアントも同様です — そのため、このチェックポイントは Liquid 自身の配布と通常のサードパーティホストから入手することになります。