ハクソク

世界を動かす技術を、日本語で。

Liquid AIが38Tで訓練された8B-A1B MoEを発表

21時間前原文(liquid.ai)

概要

LFM2.5-8B-A1B は、消費者向けハードウェアで高速かつ信頼性の高いツール呼び出しを実現するエッジAIモデル。 128Kコンテキストウィンドウ や語彙数の倍増など、前モデルから大幅に強化。 推論速度と圧縮効率 で同クラス最速を達成し、多言語対応も向上。 オンデバイスAIアシスタント やエージェント用途に最適化。 Hugging Face や Playground で即日利用可能。

LFM2.5-8B-A1B：パーソナルアシスタントがあなたのラップトップに

  • LFM2.5-8B-A1B は、 Liquid AI が開発したエッジAIモデル
  • LFM2-8B-A1B （2025年10月リリース）から大幅進化
  • 128Kトークン まで拡張したコンテキストウィンドウ
  • 事前学習データ を12T→38Tトークンへ増強
  • 語彙数 を65,536→128,000へ倍増、非ラテン文字の効率向上
  • 大規模強化学習 による性能向上
  • 推論速度・圧縮性能 が同クラス最高
  • MoE（Mixture of Experts）、 GQA、 ゲート付き短畳み込みブロック の組み合わせ
  • 推論専用モデル として設計、明示的な思考プロセスを経て回答生成
  • Hugging Face および Playground で Base / Post-trained モデルを公開

主な特徴

  • オンデバイスAIアシスタント ：ツールチェーン、複雑な指示への対応、全デバイスで動作
  • 圧縮性能 ：大規模密度モデルやMoEモデルと競合
  • 圧倒的なスループット ：CPU・GPUで同サイズ帯最速、llama.cpp/MLX/vLLM/SGLang対応
  • 低消費リソース ：エントリーラップトップでも快適動作

前バージョンからの主な変更点

  • コンテキストウィンドウ ：32,768→128,000トークンまで拡張
  • 語彙数 ：65,536→128,000トークンへ増強
    • ヒンディー語、タイ語、ベトナム語、インドネシア語、アラビア語 などで圧縮効率が大幅向上
  • 推論専用設計 ：思考チェーンを明示的に出力、MoE構造の特性を活かした高速推論
  • 品質向上 ：大規模事前学習＋推論設計でベンチマーク性能大幅向上

トレーニングとトークナイザーの改善

  • 語彙拡張 ：既存トークナイザーを拡張し、128K語彙に対応
    • BPEマージ を多言語コーパスで継続学習
    • 新規トークンはサブトークンの平均で初期化
    • 埋め込みのみ学習→全体継続学習の2段階適応
  • 1トークンあたりの文字数 が全16言語で向上
    • 例： ヒンディー語+120%、 タイ語+238%、 ベトナム語+117%
  • コンテキスト拡張 ：32K→128Kトークンに段階的拡張
    • RoPE base θ 拡大＋400Bトークンの長文データ追加学習
  • ループ抑制 ：長い推論での「無限ループ」発生を低減
    • ループ誘発トークンの確率分布を調整
    • RL（強化学習）でループ語の使用を抑制
  • ハルシネーション対策 ：知識限界超過時の「知らない」と明確に表現
    • avg@k報酬によるRLで信頼境界を明確化

ベンチマーク結果

  • AA-Omniscience Index や IFEval など主要ベンチマークで大幅な性能向上
  • 同等パラメータ帯の密度モデルや大規模MoE と比較し、指示追従・エージェントタスクで競合
  • 非ハルシネーション率 が飛躍的に向上（7.46→63.47%）
  • 数学・エージェントワークフロー でも高い競争力
  • Tau² Telecom などエージェント系ベンチマークで特に強み

主要比較モデル一覧

  • Granite-4.0-H-Tiny
  • Qwen3.5-4B
  • Gemma-4-E2B-IT など

推論エコシステムとデバイス対応

  • LEAP ：iOS/Android向けエッジAIプラットフォーム
  • llama.cpp ：エッジ推論用GGUFチェックポイント
  • MLX ：Apple Silicon最適化
  • vLLM/SGLang ：GPU高速推論
  • ONNX ：多様なアクセラレータ対応
  • CPU推論 ：M5 Maxで253トークン/秒、Ryzen AI Max+ 395で146トークン/秒、スマホでも約30トークン/秒
  • GPU推論 ：Nvidia H100 SXM5で18.5Kトークン/秒（高同時実行時）

デモ：Local Cowork

  • LocalCowork デスクトップエージェントでLFM2.5-8B-A1Bを動作確認
    • 1台のラップトップ＋13 MCPサーバー＋67ツール
    • クラウド・APIキー不要、完全オンデバイス
    • ツール選択の高速化・信頼性向上
    • 全処理が1秒未満で完了、データは外部送信なし

利用開始・今後の展望

  • オープンウェイト ：ダウンロード・ファインチューニング・デプロイ自由
  • 即日高速推論 ：Apple/AMD/Intel/Qualcomm/Nvidia各社ハードウェア対応
  • 多様なバリエーション ：ベースモデルから音声・画像特化型までカバー
  • オンデバイスAIエージェント時代 の第一歩

引用情報

  • Liquid AI, “LFM2.5-8B-A1B: Personal Assistant On Your Laptop,” Liquid AI Blog, May 2026.
  • https://www.liquid.ai/blog/lfm2-5-8b-a1b

Hackerたちの意見

これめっちゃ面白いね！特にワクワクしてるのは、これがVLAs（ビジョン・ランゲージ・アクションモデル）用のアーキテクチャをスケールさせるかもしれないから。モデルがスパースになると、ローカルホストのモデルデモでリアルタイムのアクションが増えるってことだし、試してみたい人にはいいリンクだよ。 https://playground.liquid.ai/chat?model=cmppnbgse000004l4bc8...

質問：汚れた車があって、洗車場まで50メートルなんだけど、歩いて行くべき？それとも車で行くべき？ 答え：……だから、特に理由がなければ、洗車場まで歩いた方がいいよ。

└

これらのモデルがまだトレーニングデータに取り入れてないのが驚きだね。去年、ClaudeとChatGPTにこの質問をしたときも、どちらも見逃してたし。

└

車を洗いたいって気持ちを表現してなかったね。ちょっと促したら、面白くなった：> 車をきれいにしたいって気持ちは洗車場と関係あるのかな？それともそこに行くことに？ > きれいな車を持ちたいという気持ちは、洗車場の存在や利用、そこに行くこととは関係ないよ。それは、清潔さを達成するためにどれだけの努力、時間、リソースを投資するかをどれだけ大切に思うかから来てるんだ。自分でやるのか、プロのサービスにお金を払うのか、さっと歩いて行くルーチンを楽しむのか、いろんな方法がある。近くの洗車場に車で行くのもその一つに過ぎないし、最終的にはどれだけの時間があるか、いくら使いたいか、洗車の質、手作業とアウトソーシングの好みなどの要因に依存する。今回は歩くのが一番シンプルで早いけど、きれいな車を手に入れるためには必ずしも必要じゃない。常識はもちろんあるけど、日常生活で「明らか」な決定を導く膨大な暗黙の前提を過小評価しちゃいけないね。

└

不合理ってわけじゃなさそうだね。

└

ガソリンスタンドには、車よりも歩いて行くことが多いんだ。

小さいモデルが本当にすごくなってきたね。最近、Qwen3.5:4Bが思ってたよりもずっと優秀だって気づいたんだ。LiquidがRLやファインチューニングに注力してるのと組み合わせると、最小限のハードウェアでめちゃくちゃ性能がいいモデルができる。自分でファインチューニングすれば、速くてプライベートで、インターネット接続も必要ない専門的なツールが手に入るよ。

└

qwen3.5 4bは何に使ったの？

誰かローカルコワーク [1] を使ったことある？デモがそこにあるんだよね。そうじゃないの？ [1] https://github.com/Liquid4All/cookbook/tree/main/examples/lo...

Liquidはすごい仕事をしてるけど、ちょっとモデルを過剰にトレーニングしてる気がするな。38Tトークンって、8Bモデルには多すぎるんじゃない？

└

それのデメリットは何？ 限界利益が減るときに止まるんじゃないの？

うわ、チンチラのスケーリングはアクティブパラメータの20倍だね。ミストラルはチンチラの2倍だったから、これは1800倍ってことか。

今、バグ修正のベンチマークでこれを試してみたけど、思ったほどのパフォーマンスじゃなかった。Qwen2.5-Coder-3B（2年前のモデル）が、幅広く上回ってて、約50%のバグを修正したのに対して、こっちは約12%しか修正できなかった。確かに、これはコーダー専用モデルじゃないけど、Gemmaモデルとのベンチマークパフォーマンスや、2年新しいこと、8Bの総パラメータを持つMoEだってことを考えると、もっと競争力があると思ってたんだ。

└

コーディング専用のファインチューニングは、ほんとにすごい向上を見せてたよ。Qwen2.5-3B-Instructも利用可能だし、もしよかったら、もう少し一般的なモデルがあなたのベンチマークでどうなるか知りたいな。[0] - https://huggingface.co/Qwen/Qwen2.5-3B-Instruct

└

OpenCodeで試してみたけど、ツールコールを使うのがほとんど無理だったから、それがあなたのテストで悪い結果になった理由かもしれないね。

└

OpenRouterでアクセスできるようになったら試してみるけど、前のLFM2モデル（lfm-2-24b-a2b）はテストで全然ダメだった。20問中1問しか正解しなかったし、Gemma 31BやQwen 35b-a3bには全然及ばない（あっちは10問中7問くらい正解する）。

└

個人的には、Qwen 3.6 35B-A3Bみたいに8ビット量子化で約49GBのメモリを使うモデルより小さいものは、信頼性が低すぎて使えないと思ってる。ローカルのノートパソコンでモデルを動かすより、デスクの下にあるシステムにVPN経由でアクセスして処理させた方がいい。信頼性が低いツールを使うリスクを冒すより、そっちの方が安心だからね。最近は80億パラメータとか（それ以下のモデルも）にはあまり興味がなくて、別に困ってない感じ。

精度の数字を見てみると、これらはまだあまり知らないことが明らかだし、私の一番の努力を任せる気にはなれない。でも、どこに向かってるかは見えるよ。量子化やMoEの技術がどんどん良くなっていく中で、「自分のマシンで動かせるくらい十分良い」ってのが、今私がフロンティアラボに払ってるお金をどんどん食っていくんだ。もしローカルモデルが必要なことの80%を処理できるようになったら、サブスクリプションの意味がなくなるよ。

そろそろ知識圧縮の数学的限界にぶつかる時期じゃない？これらの8Bモデルの知識ベンチマークが、オーバーフィッティングせずにどんどん良くなるとは思えないんだけど。

└

モデルに専門的なツール（例えば、質問応答用のウェブ検索）へのアクセスを与えると、知識をモデルの重みとして保存する必要がなくなるから、改善の余地が出てくる。ベンチマークにはオーバーフィッティングするかもしれないけど（異なるタスクには異なるツールが必要な場合もあるから）、特定のベンチマークの質問には必ずしもオーバーフィッティングしないから、ドメイン内の一般化はかなり良くなるかも。似たようなアプローチの例として、Teapot AIは非常に小さなモデルをトレーニングして、コンテキストウィンドウ内で答えが見つかる質問だけに答えるようにしてる。完璧ではないけど、より大きくて一般的なモデルと比べると、かなり良い結果を出してるよ。

Liquidの前のモデルをテストしたけど、残念ながら大きな主張に対して実際のパフォーマンスはイマイチだった。