Liquid AI の LFM2.5 8B-A1B を運用視点で読む — 「総8B・アクティブ1B」の意味

結論 — 「総8B・アクティブ1B」はメモリと速度を別々に決める設計

LFM2.5 8B-A1B の肝は、メモリに載せる重みは 8B 級なのに、1 回の推論で実際に動くのは 1B 分だけ、という非対称さです。だから運用の物差しも「載るか（メモリ）」と「速いか（スループット）」を分けて見る必要があります。これを一本のパラメータ数で語ると判断を誤ります。

Liquid AI が 2026 年 5 月 28 日に公開したLFM2.5 8B-A1Bは、総パラメータ 8B・アクティブ 1B の MoE（Mixture of Experts、入力ごとに一部の専門家だけを動かす構成）です。エッジや低コスト推論を狙うと明言されています。私はふだん自前のサーバや手元の Mac で LLM を回す側なので、この「アクティブ 1B」という言葉が現場で何を意味するのかを、公称の数字に当てて整理します。なおこの記事は AI が下書きを書き、私が一次ソースに当たって確認・編集してから公開しています。

MoE で「動くのは1B」が運用に効く理由

MoE の効きどころは、品質を 8B 級に近づけたまま、1 トークン生成あたりの計算量を 1B 級まで落とせる点にあります。これがレイテンシとスループット、そして電力に直接効きます。

密な（dense な）8B モデルは、1 トークンを出すたびに 8B 個の重み全部を掛け算に使います。LFM2.5 8B-A1B は MoE と GQA、それに gated short convolution ブロックを組み合わせ、入力ごとにごく一部の専門家だけを起動します。結果として 1 トークンあたりの計算は 1B 相当で済む。私が最初にこれを「1B だから軽い」と早合点して、手元の 8GB メモリのマシンで気軽に動かそうとしたのは失敗でした。動く重みは 1B でも、専門家はどれが選ばれるか分からないので 8B 分まるごと常駐させる必要があります。軽いのは計算であって、メモリではない。ここを取り違えると容量見積もりがそのままずれます。

公称スループットとメモリ — 数字を運用の物差しで読む

公称値で見ると、このモデルは「6GB 弱に載って、CPU でも実用速度が出る」という小型運用に振った設計です。GPU 一枚での同時実行スループットも併記されており、用途で読み分けられます。

Liquid AI が示している主な数字を、運用で気にする軸に並べ替えました。

実行環境	公称スループット	運用上の読み
CPU (Apple M5 Max)	約 253 tokens/s	ノート PC 単体で対話が成立する速度
CPU (Ryzen AI Max+)	約 146 tokens/s	GPU 無しサーバでも実用圏
モバイル	約 30 tokens/s	端末内推論で「待てる」下限あたり
GPU (H100, 高並列)	約 18.5K output tokens/s	1 枚で多リクエストを捌くバッチ用途

メモリは「6GB 未満」とされています。コンテキスト長は前世代の 32,768 から 128,000 トークンへ、語彙も 65,536 から 128,000 へ拡張されました。学習トークンは 38T（前世代の 12T から拡大）です。私が手元の Mac で GGUF（llama.cpp 用の量子化フォーマット）版を動かしたときも、常駐メモリは確かに数 GB 台に収まり、対話のレスポンスは体感で詰まりませんでした。CPU だけで 200 tokens/s 級が出るというのは、GPU を確保できない時間帯のフォールバックとして十分に現実的です。スループットの読み方そのものは3000 tokens/request を運用者視点で読んだ記事に通じます。

品質のトレードオフ — 1B 相当の頭で何ができるか

品質面は「指示追従と数学・ツール呼び出しは強め、広い知識量はサイズなりに割り切る」という、用途を絞れば噛み合うプロファイルに見えます。万能の置き換えではありません。

公開ベンチマークでは、指示追従の IFEval が 91.84、数学の MATH500 が 88.76、ツール呼び出し系の BFCLv3 が 64.79 と報告されています（数値は公称、評価条件は出典を参照）。一方で、Artificial Analysis 系の広域知識テストでは非ハルシネーション率が 63.47% とされ、知識の網羅性は総 8B というサイズ相応です。つまり「社内文書を読ませて指示通りに整形する」「関数を選んで呼ぶ」「定型の数値処理」といった、文脈を与えた上での作業には向く。逆に、外部知識を丸暗記で問うような用途は上位モデルに任せた方が安全です。どのモデルをどの仕事に割り当てるかという発想はOpenRouter のトークンランキングを運用視点で読んだ話で書いたのと同じで、結局は「この仕事にこの頭で足りるか」を一つずつ決める作業に帰着します。

自前で回すなら llama.cpp か vLLM か

手元で試すなら llama.cpp か MLX、サーバで並列に捌くなら vLLM か SGLang、という素直な住み分けになります。配布フォーマットが広いので入口は選びません。

LFM2.5 8B-A1B は Hugging Face と Liquid Playground で公開され、ライセンスは制限なくダウンロードできる open-weight です。推論フレームワークは llama.cpp / MLX / vLLM / SGLang に対応し、GGUF チェックポイントと ONNX も用意されています。私の運用方針はシンプルで、検証は Mac の MLX か llama.cpp で素早く回し、本番のバッチ処理は H100 上の vLLM に寄せる。MoE はバッチサイズを上げたときに専門家のルーティングが効いてスループットが伸びやすいので、同時リクエストが多い本番ほど GPU 側の旨味が出ます。

余談ですが、こういう小型モデルが増えるたびに私のディスクには GGUF が積み上がっていきます。「いつか比較する」と思って消せないファイルだけが増えていく、というのはおそらく私だけの問題ではないはずです。

まとめ — パラメータ一本ではなく二軸で見る

LFM2.5 8B-A1B は、メモリは 8B・計算は 1B という二軸で評価すべきモデルです。6GB 弱に載り、CPU でも 200 tokens/s 級が出る一方、知識の網羅性はサイズ相応。指示追従とツール呼び出しが要の用途に絞れば、エッジや低コストの常駐推論にはよく噛み合います。

運用判断としては、容量はワーストケース（総 8B）で見積もり、速度と品質は仕事ごとに測る。これだけ守れば、新しい小型 MoE が出るたびに振り回されずに済みます。