
Perceptron Mk1.5 vs LFM2.5-2.6B-Base:知覚を借りるか、チェックポイントを所有して自分で仕上げるか
- typesafeNEWTypeSafe: Jev 1.132026-09-24$0.04 / $0.00 100万トークンあたり · 610 tok/s
- openaiNEWOpenAI: GPT-6 Luna2026-09-2237知能
- openaiNEWOpenAI: GPT-6 Sol2026-09-2248知能
- anthropicNEWAnthropic: Claude Opus 5.52026-09-2258知能
- grokNEWGrok 4.72026-09-2146知能
- OrcaNEWOrca: OrcaCyber Zero 1.02026-09-17$3.00 / $5.00 100万トークンあたり · 189 tok/s
- orcaNEWOrca: OrcaVerify Text 1.02026-09-16$2.00 / $0.00 100万トークンあたり · 1306 tok/s
- deepseekDeepSeek: DeepSeek V4.1 Flash2026-09-1040知能
- openaiOpenAI: GPT-6 Astra2026-09-0453知能77コーディング
- googleGoogle: Gemini 3.8 Flash2026-09-0241知能76コーディング
- qwenQwen: Qwen3.8 Max (0902)2026-09-0245知能76コーディング
- anthropicAnthropic: Claude Fable 5.12026-09-0153知能82コーディング
- AlibabaQwen: Qwen3.8 Flash2026-08-26$0.15 / $0.47 100万トークンあたり · 111 tok/s
- z-aiZ.ai: GLM 5.3 Flash2026-08-2642知能72コーディング
- DeepSeekDeepSeek: DeepSeek V4 Flash Vision (Exp)2026-08-21$0.22 / $0.66 100万トークンあたり · 225 tok/s
- z-aiZ.ai: GLM 5.32026-08-1845知能75コーディング
- obsidianQwen3.8 27B2026-08-1534知能68コーディング
- deepseekDeepSeek: DeepSeek V4 Pro 08132026-08-1236知能69コーディング
- grokSpaceXAI: Grok 4.62026-08-1244知能77コーディング
- metaMeta: Muse Spark 1.22026-08-0540知能72コーディング
これらのモデルはどちらも、片手で持ち上げられるようなハードウェアを対象としている。Perceptron Mk1.5は身体性エージェント向けの知覚モデルで、ベンダーによればドローン、四足歩行ロボット、スマートグラス、スマートフォンに搭載されるという。LFM2.5-2.6B-Baseは、Liquid AIがオンデバイス展開のために明示的に構築した2.69Bのオープンウェイトのチェックポイントであり、2.5GB未満のメモリで動作するほど小さい。この共通する物理的な野心だけが両者の唯一の共通点であり、スペックシート上で両者を比較しようとする人にとっては落とし穴だ。Perceptron Mk1.5はトークン単位で利用する完成品であり、テキスト、画像、動画、音声を入力として受け取り、テキストと機械可読な幾何データを出力する。2026年9月25日から稼働している。LFM2.5-2.6B-Baseは、指示チューニングもチャットテンプレートもベンチマークの主張もない、生の事前学習済み基盤モデルだ。他者が仕上げるために公開されたチェックポイントである。一方は今日、問いに答える。もう一方は、いずれそうするモデルのための原材料だ。
比較は、段階に名前を付けて初めて機能します。
提供済みのAPIをベースチェックポイントと並べて比べるのは直接対決ではなく、そう見せかけると、一方はベンダーによって完成済みで他方はまだ着手されていないという理由だけで、すべての行で一方が「勝つ」ような無意味な表ができあがる。有益な問いは、あなたの作業がどの段階にあるかだ。
Liquid AIはLFM2.5ファミリーを一連のチェックポイントとしてリリースし、ベースはその最初のものです。そのモデルカードには、30層にわたる総パラメータ数2.69B——22の二重ゲート付きショート畳み込みブロックと8のグループ化クエリ・アテンションブロック——が記載されており、約34兆トークンで学習され、語彙数は128,000トークン、コンテキスト長は131,072トークン、英語、中国語、日本語、韓国語、アラビア語を含む16言語をサポートしています。テキスト専用であり、因果言語モデルにすぎません。Liquid自身の推奨は率直です。このチェックポイントは、言語特化型またはドメイン特化型のアシスタント、独自データでの学習、新しいポストトレーニング手法の実験など、大規模なファインチューニングを必要とするタスク向けです。これを、このファミリーの公表スコアを実現するツール呼び出しエージェントに変えるのは、Liquidの4段階のポストトレーニングパイプラインであり、ベースにはこれは含まれていません。
Perceptron Mk1.5 はその弧のもう一端に位置する。Perceptron はすでにポストトレーニングを済ませ、出力形式を決め、その成果に価格を設定している——入力トークン100万あたり0.15ドル、出力100万あたり1.50ドル、キャッシュ済み入力は0.0375ドル。その仕様は、ベースチェックポイントのそれとは違って具体的だ:36,864トークンのコンテキスト、最大出力8,192トークン、4つの入力モダリティ、reasoning_effort 制御はデフォルトで high、チャット補完での関数呼び出し、JSON Schema と regex による制約付き応答。
両方を視野に入れておくべき理由は、総所有コストが逆方向に働くからだ。Mk1.5 はトークンあたりのコストが高く、始めるのは無料だ。LFM2.5-2.6B-Base は限界費用が無料で、ベースチェックポイントにとって唯一重要な通貨——あなたのエンジニアリング時間——の点では高くつく。
次元ごとに、役割を混同せずに
• 概要 — Perceptron Mk1.5 は、構造化された空間出力を備えたホスト型の知覚 API です。LFM2.5-2.6B-Base は、ダウンロード可能な 2.69B の事前学習済み因果言語モデルです。
• 入力 — Mk1.5はテキスト、画像、動画、音声(WAV、MP3、FLAC)に対応。LFM2.5-2.6B-Baseはテキストのみに対応。
• 出力 — Mk1.5 は、テキストに加えて、任意でポイント、ボックス、ポリゴン、クリップ、およびタイムスタンプ付きの <track> 要素、または JSON Schema で制約されたレスポンスを返します。ベースモデルは次のトークンのトークン確率を返しますが、それを有用にするための調整は何も行われていません。
• 単体利用 — Mk1.5 はキーを取得したその日から使えます。LFM2.5-2.6B-Base は、製品として通用する意味で質問に答えることはできません。出荷できるモデルにするには、ファインチューニングが、そして通常はチャットテンプレートが必要です。
• コンテキスト — Mk1.5 は 36,864 トークン、ベースは 131,072 トークン。オンデバイス・チェックポイントは、提供されている知覚モデルが保持するどんな内容のほぼ4倍ものテキストを保持している。
• フットプリント — Mk1.5 は Perceptron が実行する環境で動作し、公開されているレイテンシ作業は単一の H100 上で行われています。ベースは、2.5GB 未満でラップトップ、スマートフォン、またはエッジボックス上で動作するように設計されています。
• 根拠 — Mk1.5 の能力値を示す数値はすべて Perceptron 自身によるもので、それを裏づける独立した指標は存在しない。ベースモデルにはベンチマークに関する主張が一切ない。Liquid が公開しているスコアは、ポストトレーニング済みの LFM2.5-2.6B のものであり、このチェックポイントのものではない。
• ライセンス — Mk1.5はクローズドで、トークンごとにレンタルされます。LFM2.5-2.6B-BaseはLFM Open License v1.0の下で提供され、ダウンロードして保持できるウェイトが付属します。

重量ルート、正直なコスト計算

LFM2.5-2.6B-Base の魅力が重みは無料だという点にあるのなら、その文を正直に言い換えれば、重みはプロジェクトの中で最も安価な部分だということになる。独自データでのファインチューニングとは、データセット、学習実行、そのファインチューニングがうまくいったかを教えてくれる評価ハーネス、そしてサービング経路——Transformers、vLLM、SGLang、あるいは Liquid がそれぞれ CPU、クロスプラットフォーム、Apple Silicon 展開向けに公開している GGUF、ONNX、MLX のビルドのいずれか——を意味する。それらのどれも珍しいものではなく、2.69B なら、70B のファインチューニングが決して触れることのないハードウェアに収まる。しかしベースチェックポイントは出発点であり、スケジュール上のリスクは完全に取引のあなた側にある。
その見返りとして得られるのはコントロールです。16言語トークナイザーと131Kコンテキストにより、ドメイン特化のファインチューニングが事前学習とスペースを奪い合うことはありません。2.5GB未満のフットプリントは、デプロイ先がデータセンターではなくデバイスであることを意味し、それがこのファミリーの存在意義そのものです。そして、LFM Open License があればその成果を手元に残せます——競合他社が、あなたが利用できるのと同じAPIからレンタルすることのできないスペシャリストです。
系譜に賭ける前に知っておく価値のある第三者の証拠が1つあり、欠けている点も1つある。Liquidのポストトレーニング済みLFM2.5-2.6Bには独立した測定がある。Artificial AnalysisはこれをIntelligence Index 8とし、同クラス49モデル中9位にランク付けしている。ベースチェックポイントにはそれがなく、ページも存在しない。これは事前学習済み基盤モデルとしては普通のことであり、判決として扱うのではなく率直に述べておく価値がある。ポストトレーニング済みモデルの指数が教えてくれるのは、指数帯の小さい端にあるこの出発点からパイプラインが何を生み出すかであり、あなたのファインチューンが何を生み出すかではない。
APIルート、そしてホステッドモデルにとって「オンデバイス」とは何を意味するのか

Perceptron Mk1.5のデプロイの話は、対象リストが示唆するよりも複雑であり、正確を期す価値がある。ベンダーの発表では、ドローン、四足歩行ロボット、スマートグラス、携帯電話がデプロイ対象として挙げられている。モデル自体はapi.perceptron.incからAPIキーで保護されて提供されており、Perceptronが公開したレイテンシの根拠は単一のH100上での3回の実行の中央値である。単一のH100はドローンではない。現実的な解釈は、Mk1.5がネットワーク接続または併設コンピューティングボックスを持つロボットの知覚レイヤーであり、機体内で動作するモデルではない、ということだ。そして、それを前提にオフライン機器を計画する人は、ハードウェアを設計する前にその前提を検証すべきである。
ネットワーク前提が成り立つなら、APIルートがもたらすのは、ベースチェックポイントではどんな代償を払っても得られないもの、すなわち座標だ。Mk1.5の<track>出力は空間観測とそのタイムスタンプを含むので、クリップはシーンの説明ではなく、時間の経過に伴う物体位置として返ってくる。付け加えると、asset_idxフィールドは、1つのリクエストで複数の画像や動画を別々に指定できるようにし、リクエストの形は制御ループと一致する — 参照フレームを入力し、幾何を出力し、モデルと何かを動かすコードの間に解析段階はない。
コストはすでに列挙したとおりです。36,864トークンのコンテキスト、1アイテムあたり16,384トークンの音声上限(Perceptronのドキュメントでは毎分約750トークンとしておよそ21.8分とされています)、reasoning_effortのデフォルト値がhighであるため設定していないすべての呼び出しで最も高コストな推論パスに対して課金されること、そしてモデルを販売している当の企業が作成した一連のベンチマーク主張です。ハンドトラッキングの数値こそ、自分の映像で検証すべきものです。エゴセントリックなhand_boxで0.9433、Perceptron自身の実行によるGemini 3.1 Proが0.4467というのは大きな差であり、ベンダー評価における大きな差こそ、まさに再現する価値のあるものです。
どちらも当社のカタログには掲載されておらず、そのことが判断を変えます。
現在、Perceptron Mk1.5もLFM2.5-2.6B-BaseもOrcaRouterではルーティングされていません。Mk1.5にはルートがまったくないため、それに到達するにはベンダー自身のAPIを使うしかありません — pip install "perceptron>=0.4.0" と PERCEPTRON_API_KEY — また、Liquid AIには当社のカタログにどのサイズのモデルも存在しないため、ベースチェックポイントは呼び出しではなくLiquidのHugging Faceからのダウンロードです。
それは聞こえほど重要ではない。というのも、この二つは互換可能なエンドポイントではなく、どんな価格論を持ち出してもそうなることはないからだ。ここでルーティング層が寄与するのは、まだ開かれている判断の部分である。Mk1.5 上に知覚サービスを、ファインチューニングした LFM2.5-2.6B-Base 上にテキスト専門サービスを構築するなら、二つの統合と二つの障害モードを抱え込むことになる。その手前に OpenAI 互換のゲートウェイを置けば、どちらか側で起きたプロバイダー障害はジョブの失敗ではなくフォールバックになり、ルーティングルールを使えば、アプリケーションにどれがどれかを意識させることなく、ビジョンのトラフィックとテキストのトラフィックを別々のモデルへ振り分けられる。200以上のモデルをカバーし、プロバイダーの定価を0%のマークアップでそのまま通す単一のAPIは、ベンダーの価格変更が次回の更新時ではなく当日に反映される、その形のバージョンだ — ただし、この二つに限って言えば、今日時点でゲートウェイは利用可能な近道というより検討事項である。
何をすべきか、そして何を測定すべきか
タスクが「このフレーム内でこのオブジェクトを見つけて、それがどこにあるかを返す」というものなら、Mk1.5 を借りて、本番の経路をそれに委ねる前に、自分の動画で hand-box の主張を検証してみよう。ネットワーク前提分の予算を見込み、reasoning_effortそのまま受け入れるのではなく意図的にhigh36,864 トークンのウィンドウを、それが本当にそうであるところの厳格な制約として扱おう。構造化された出力こそが成果物であり、下流のコードがパース段階なしで座標を消費できるなら、それは多くのビジョンパイプラインが静かに精度を落としている場所での、確かな節約になる。
「誰も持っていないデータで調整した2.6Bモデルを、GPUのないどこかで動かしたい」というのがあなたのタスクなら、LFM2.5-2.6B-Baseをダウンロードし、始める前にファインチューニングの費用を正直に見積もろう。チェックポイントは無料だが、エンジニアリングは無料ではない。そして、このファミリー自身の教訓——事後学習済みの兄弟モデルが独立系インデックスで8を獲得していること——は、ベースモデルと完成したモデルの間の隔たりこそが実際の作業の存在する場所だということを思い出させる。どちらも間違った答えではない。それらは別々の買い物であり、唯一の本当の誤りは、自分で仕上げなければならない基盤を、すでに製品であるかのように扱うことだ。
2つのモデル、2つの統合、2つの障害モードというのは、見た目よりも厳しい状況です。OrcaRouterなら自動フェイルオーバーを設定できるので、どちらかのプロバイダーで障害が起きても、ジョブが失敗するのではなくフォールバックに縮退します。
