2.6BのローカルLLMで128Kの文脈は張れるか｜LFM2.5-2.6Bの必要VRAMを16GB GPUとCPUのみで実測

LFM2.5-2.6Bとは、Liquid AIが公開した端末内完結型のエージェント向けLLMである。

重みだけ見れば軽い。公式GGUFリポジトリのQ4_K_Mは1.67GB、Q4_0なら1.59GB。問題は、エージェント用途が「長いコンテキストを積んで、複数ステップを回す」使い方だという点にある。積んだトークンは重みとは別にメモリを食うので、ファイルサイズだけでは載るかどうかを判定できない。131,072トークンという公称コンテキスト長をどこまで使えるのかについて、Liquid AIは総メモリ量の公式値を出していない。

そこで当サイトの検証環境で実際に張って測った。増え方はコンテキスト長に正比例するが、その傾きは、同じ条件で測った密なTransformer（llama3.2:3b）の7分の1だった。

判断の分かれ目は「重みが軽いこと」ではない

パラメータ数から必要メモリを逆算する読み方は、もう成立しない。量子化で重みは3分の1前後まで縮み（このモデルならBF16の5.4GBに対しQ4_K_Mが1.67GB）、逆にエージェント用途では通常のチャット推論にはない負荷が乗る。「2.69Bだから軽い」という一行では、載るか載らないかを判定できない。

必要メモリは4つに分かれる。重み、コンテキスト保持分（KVキャッシュ）、計算に使う作業用バッファ、そしてランタイム自身が取る分だ。公式が数字を出しているのは重みだけで、残る3つは環境と使い方で決まる。エージェント用途ほど2つ目が支配的になる、というのが一般的な理解だった。

実測すると、このモデルでは2つ目の増え方が緩い。131,072トークンを張ってもコンテキスト保持分は2,048 MiBで、GPUに載った重みの1,589 MiBに対して1.3倍にとどまる。同じ条件で測った同規模の密なTransformerでは、同じ131,072トークンで14,336 MiB、重みの7.5倍に達した。「長文脈は小型モデルでも重い」という前提が、モデルによって成立したりしなかったりする。

この違いがどこから来ていて、どこまで頼れるのか。測った条件と数字を順に示す。

何をどう測ったか

測定対象は公式GGUFリポジトリのQ4_K_M（1,674,455,040バイト）。取得はOllama経由でhf.co/LiquidAI/LFM2.5-2.6B-GGUF:Q4_K_Mを指定し、降ってきたGGUFファイルをllama.cppへ直接渡している。Ollamaのランタイムで実行したわけではない点は区別が要る。以下の数字はすべてllama.cpp（ビルド3ce7da2c8 / b10092、2026年7月23日公開のCUDA版）のものだ。

メモリはllama.cppの起動ログが出す確保量（モデル・KVキャッシュ・再帰状態・計算バッファ）を一次データとし、あわせてGPU全体の使用量を起動前後で取っている。測定に使ったのは当サイトの検証環境のRTX 5060 Ti 16GB（Oculink接続）で、画面出力に使っていないため起動前のベースラインは毎回0 MiBだった。CPUのみの測定は-ngl 0 -dev noneで、GPU使用量の増分が0 MiBであることを確認している。Oculink接続の帯域は重みをVRAMへ読み込む時間に効く。主要な推論処理はGPU側で回るので、以下のt/sはスロット直挿しでも大きくは変わらないと考えられるが、直挿しとの比較は今回行っていない。

速度はllama-benchで測った。-dで指定した長さのトークンを先に流し込み、その状態から512トークンの処理と128トークンの生成を計測している。つまり「文脈を抱えた状態での速度」であって、空の状態からの速度ではない。繰り返しはGPU側が3回、CPU側が2回で、その平均を採っている。

対照にはllama3.2:3bのQ4_K_Mを使っている。全層がアテンションの密なTransformerで、パラメータ数が3.2Bと近い。同じGPU、同じllama.cppビルド、同じKVキャッシュ型で測ることで、環境側の違いは消せる。残る差はモデルの構造に由来するもので、その内訳は後の節で分解する。ただし重みは1,918 MiBと本モデルより2割ほど大きく、2024年公開の世代でもあるので、速度の比較についてはこの差を引いて読みたい。ここでの役割は推奨モデルではなく、層構成の違いを測るための物差しだ。

コンテキストを張るとメモリはどう増えるか

RTX 5060 Ti、Q4_K_M、KVキャッシュはf16、同時実行は1本。この条件で固定し、コンテキスト長だけを4,096から131,072まで変えて起動時の確保量を測った。

KVキャッシュは1トークンあたり16.00 KiBちょうどで、5点すべてが正確に比例している。端数が出ないのは、確保量が層数とヘッド構成から一意に決まるためだ。再帰状態 — アテンションではない畳み込み側の層が持つ内部状態 — は0.34 MiBのままコンテキスト長に反応しない。計算バッファは4,096の75.03 MiBから131,072の199.03 MiBまで緩やかに増える（ホスト側にも別枠の計算バッファがあり、こちらは12.01 MiBから136.01 MiBへ増えた）。

重みの扱いには一点、注意がいる。GPU側に載ったのは1,589.03 MiBだが、これとは別にホスト側へ205.08 MiBが残る。起動ログによれば、トークン埋め込み（token_embd.weight、q6_K）がGPU向けのバッファ型に置けず、CPU側へ回されるためだ。-ngl 99で全層をGPUへ指定してもこの1つは残る。なおllama.cppはファイルサイズを1.55 GiB（4.94 BPW）と表示するが、GPU側1,589.03 MiBとホスト側205.08 MiBの合計はそれを上回る。起動ログではtoken_embd.weightの読み込みが2回出ており、出力層と共有する重みが二重に実体化されている可能性がある。ここは確定していないので、内訳の算術としては扱わない。

同規模の密なTransformerと並べる

対照も同じやり方で測る。GPU・ビルド・KVキャッシュ型はそのままで、モデルだけllama3.2:3bのQ4_K_Mに差し替えた。

1トークンあたりで見ると16.00 KiB対112 KiBで、ちょうど7倍の開きがある。

対照側の131,072トークンの行は、そのまま「16GBに収まった」と読めない。GPU側の確保要求は重み1,918.35 MiB＋KV 14,336 MiB＋計算バッファ194.01 MiBで16,448 MiBになり、llama.cppが認識するカード容量16,310 MiBを超える。起動ログにもfailed to fit params to free device memoryの警告が出ている。GPU使用量の増分15,942 MiBは頭打ちになった値で、超過分はGPUに載っていない。今回のWindows／NVIDIAドライバ環境では、VRAMを超えた分がエラーで止まらず共有システムメモリへフォールバックした。NVIDIA側にはこのフォールバックを抑止する設定もあるので、超過時にどう振る舞うかは環境で変わる。

いま3Bクラスの密なモデルで32,768トークンを扱っていて空きが苦しいなら、同じ長さで空くのは表の差分そのものだ。3,584 MiBが512 MiBになり、3GB強が戻る。その3GBを画像生成モデルの同居に回すのか、コンテキストをさらに伸ばすのか、本数を増やすのか。次の判断はそこへ移る。

コンテキスト長とVRAMの関係そのものを掘り下げた測定はVRAM 16GBでローカルLLMのコンテキスト長はどこまで伸ばせるかとローカルLLMで長文を扱うとVRAMはどれだけ増えるかで扱っている。どちらも密なTransformerでの測定で、そこで見えた「壁」の位置が層構成によって動く、というのが今回の結果だ。

なぜ7倍差が出るのか

Hugging Face公式モデルカードによれば、LFM2.5-2.6Bの30層の内訳はdouble-gated short convolutionブロックが22、grouped-query attention（GQA）ブロックが8というハイブリッド構成である。全層をアテンションで組む一般的なTransformerとは配分が違う。

この配分がまずメモリに出る。KVキャッシュはアテンション層が過去のトークンを保持するための領域なので、畳み込み側の22層は持たない。実測の16.00 KiBを8層で割ると1層あたり2.00 KiBだ。同じ割り方を対照のllama3.2:3b（28層すべてアテンション）に当てると、112 KiB ÷ 28層で1層あたり4.00 KiBだ。

つまり7倍の内訳は2つある。KVを持つ層の本数で3.5倍（8層対28層）、1層あたりのKV量でさらに2倍（GQAのKVヘッド数×ヘッド次元が、片方は片方の半分）。その積が7倍になる。層構成だけでも、ヘッド構成だけでも7倍には届かない。起動ログが出す構成値もこれと一致していて、LFM2.5-2.6BはKVを持つ層が8つ、その各層でK側・V側とも512次元。llama3.2:3bは28層すべてが持ち、各層1,024次元だった。

畳み込み側の22層が何も持たないわけではない。再帰状態として0.34 MiBを確保している。ただしこれはコンテキスト長を32倍にしても0.34 MiBのままだった。この層が持つのは直近わずか数トークン分の固定長の窓で、履歴の長さとは無関係だからだ。裏を返せば、長文脈に伴って増えるKVキャッシュのコストはこの8層で決まり、長距離の履歴を直接保持する役割もこの8層が担う。

KVキャッシュ量子化での削減量

KVキャッシュの型はf16のほかにq8_0が選べる。ほかの条件はそのままに、型だけを変えて測り直した。

KVキャッシュ自体の削減率は、どの長さでもほぼ47%で揃った。ただしGPU全体で見た削減はそれより小さい。131,072トークンではKVが960 MiB減る一方、計算バッファが199.03 MiBから400.04 MiBへ増えるため、差し引き758 MiBの削減にとどまる。4,096トークンでは計算バッファはほぼ変わらないので、この目減りは長い文脈でだけ起きる。元のKVが2GBしかないうえに一部を計算バッファで払い戻すことになるので、このモデルではKVキャッシュ量子化の優先度は高くない。なお今回測ったのは確保量だけで、出力品質への影響は測っていない。

エージェントを複数本立てたときに効いてくるもの

エージェント運用では同時実行数が効く。同時に走るリクエストはそれぞれが自前のコンテキストを持つためだ。今回使用したllama.cpp b10092の構成では、--parallelで指定したスロット間で-cの総枠が分割され、1スロットあたりの長さ（起動ログのn_ctx_seq）は総枠をスロット数で割った値になった。

この構成では、KVキャッシュの総量は-cの値だけで決まり、本数は「その総量を何本に分けるか」を決めている。4本立てても-cを増やさなければメモリは増えず、代わりに1本あたりが32,768トークンへ縮む。4本それぞれに公称どおりの131,072トークンを持たせたければ-c 524288が要り、そのときKVは8,192 MiB、GPU全体で10,114 MiBに達した。再帰状態だけはスロットごとに持つので0.34 MiBから1.38 MiBへ増えるが、KVの8,192 MiBに比べれば無視できる量だ。

この-cの意味はllama.cpp固有である点に注意がいる。Ollamaのnum_ctxは1スロットあたりの長さで、総量はそれに並列数を掛けた値だ。vLLMの--max-model-lenも1系列あたりで、KVは別途確保するプールから配られる。「本数×長さでKVが決まる」という考え方は移るが、どのつまみに何を渡すかはランタイムごとに違う。

重み1.55 GiBのモデルが10GBを超える。増えているのは重みではなく、本数×長さで決まる領域だ。16GBのGPUなら4本×131,072トークンで残りは6GB程度で、8本に増やすには1本あたりを縮めるしかない。

同時に何本も走らせない使い方なら、この表は1本の行だけ見れば足りる。その場合に効いてくるのは、131,072トークンを張ってなお12GB空くという事実の方だ。空いた分は本数に回すこともできるし、画像生成モデルを常駐させたまま同居させる、より大きい別モデルと二段構えにする、といった回し方もできる。小型モデルを選ぶ意味は「載るから」ではなく、余らせた分の振り替え先を選べるところにある。

速度はどこまで落ちるか

文脈を抱えた状態での生成速度を、深さを変えて測った。RTX 5060 TiとCPUのみ、それに対照のllama3.2:3bを並べる。数字は1秒あたりの生成トークン数である。

GPUでは131,072トークンを抱えても95.47 t/sで、空の状態の48%を維持した。

対照側の131,072トークンは数字が出せなかった。1回分の計測に90分かけて完了しない。主役モデルは同じ深さを含む4条件を3回ずつ、計12計測を2分で終えている。メモリ側で見たとおり、この長さでは確保要求がカード容量を超えており、今回のWindows／NVIDIAドライバ環境では超過分が共有システムメモリへフォールバックした。その状態でも動きはするが、計測が終わらない速度になる。表の空欄そのものが、16GBのGPUではこの長さを扱えないという結果だ。

深さ0では両者の差は1.2倍しかない。この差は重みサイズの比（1.87 GiB対1.55 GiB＝1.21倍）とほぼ一致するので、文脈がない状態の速度差は主に重みの読み出し量で説明がつく。効いてくるのは深さを増やしたときの傾きで、32,768トークンでは差が2.3倍まで開く。増えた分はKVキャッシュの読み出し量の違いと整合しており、メモリ側で見た構造が速度側にも出ていると読める。ただし層構成が原因だと分離して言い切るには、同じモデルで層数だけを変えた対照が要る。ここでは整合の指摘に留める。

CPUのみでも31.09 t/sが出た。読む速度は上回る。ただし公式が「常に思考してから答える推論モデル」としているとおり、チャットテンプレートが応答の冒頭に<think>を付与するため、最終回答が出るまでの体感待ち時間は生成速度の数字より長くなる。32,768トークンを抱えると15.27 t/sまで落ち、GPUとの差は6.4倍から10.2倍へ開く。文脈が長くなるほどGPUの有無が効いてくる。GPUなしでの推論そのものの成立条件はGPUなしでローカルLLMは実用になるかで扱っている。

CPU側で気をつける点がひとつ。CPUのみで動かすと、重み本体の1,580.03 MiBとは別に、CPU向けに組み直した1,138.50 MiBが確保される。llama.cppのバッファ行を足すと約2.7 GiBで、GGUFファイルの1.67GBだけを見て見積もると足りない。ただし重み側はメモリマップされるため、実際に常駐するRAM量は今回測れていない。2.7 GiBは上限として読む値だ。

プロンプト処理側の速度も落ち方が大きい。5060 Tiで512トークンの処理は、深さ0の9,434 t/sから131,072トークンで2,060 t/sへ、CPUのみでは258.17 t/sから32,768トークンで105.38 t/sへ落ちた。長い文脈を毎回読み直す使い方をするなら、生成速度よりこちらが体感に効く。

ツール呼び出しは成立するか

エージェント用途を名乗る以上、ツールを呼べるかどうかが要だ。llama.cppのサーバを-c 8192・1スロットでOpenAI互換エンドポイントとして立て、天気取得と文書検索の2つの関数を定義して、天気を聞く問いをtemperature 0.3で5回投げた（公式GGUFリポジトリの実行例は0.1を推奨しており、そこより振れやすい設定になる）。

5回ともget_weatherを選び、引数は毎回{"city": "Tokyo", "unit": "celsius"}だった。摂氏で聞いたことがunitに反映されている。応答までは0.31〜0.36秒（文脈を積んでいない状態での値で、長い文脈を抱えればプロンプト処理側が効いてくる）。続けてツールの実行結果を返したところ、その内容を踏まえた最終回答も返ってきた。

言えるのは、2.6Bクラスでもツール呼び出しの形式は崩れず、引数のJSONが5回とも解釈可能だったところまで。ここから先は実際のタスクで確かめる領域で、見るべきは3点ある。ツール定義を実運用の数（10個前後）まで増やしても選択がぶれないか、ツールを使うべきでない問いで余計に呼ばないか、ツール実行結果を返した後の最終回答がその結果を正しく踏まえているか。最初の1点は形式面なので数分で確認できる。

なおllama.cppでツール呼び出しを使うには、サーバ起動時に--jinjaを付けてモデル付属のチャットテンプレートを使わせる必要がある。このモデルは常に思考してから答える設計で、テンプレートがアシスタント応答の開始時に<think>タグを直接付与する。応答をそのままアプリのUIへ流すと思考部分が混ざるので、<think>から</think>までを落とす処理を挟むか、対応済みのクライアントを使うことになる。ツール呼び出しは既定では<|tool_call_start|>と<|tool_call_end|>で挟んだPythonの関数呼び出し形式で出力される（システムプロンプトで指示すればJSON形式にもできる）。今回OpenAI互換エンドポイント側でJSONの引数として受け取れたのは、llama.cppがこの形式を解釈しているためだ。llama.cpp側は2026年8月13日にLFM2系のツール呼び出しで引数名の解析を修正しており（PR #26960）、ここでの結果はその修正が入る前のb10092での値だ。引数名が共通の接頭辞を持つツール定義では、新しいビルドで挙動が変わりうる。

公称スペックとライセンス

ここまでの実測とは別に、公式が出している値を並べる。総パラメータは2.69B、コンテキスト長は131,072トークン、語彙サイズは128,000。事前学習には約34兆トークンを使い、語彙は既存トークナイザを拡張する形で128Kへ倍増させている。対応言語は日本語を含む16言語だが、日本語での品質を測ったベンチマークは確認できていない。テキスト専用で、画像などのマルチモーダル入力は扱わない。

公式が公表しているベンチマークでは、ツール利用を測るToolSandboxが77.83。同じ表で9.7BのQwen3.5-9Bが76.44、4.7BのQwen3.5-4Bが75.55、gemma-4-E4B-itが65.00となっている。指示追従のIFBenchも59.17でQwen3.5-9Bの56.47を上回る。一方で数学系のAIME25は51.87にとどまり、Qwen3.5-9Bの56.07には届かない。「4倍近いサイズのモデルを上回る」が成立しているのはツール利用と指示追従の領域で、推論の重い領域までは広がっていない。公式自身も、エージェンティックなコーディングと知識集約タスクを非推奨用途として挙げている。この表は公式自身の計測なので序列を鵜呑みにする話ではないが、読み方としては「同じ4〜9Bクラスと比べて上回るのはツール利用と指示追従の側」で、2.6Bを選ぶ理由もそこに絞られる。ツール呼び出しが主目的でなく要約や知識応答が中心なら、同じVRAMに載る4B級を選ぶ方が素直だ。

速度の公称値は次のとおり。Liquid AIの計測では、Apple M5 Max上で220 tokens/sのデコード、メモリ使用は2.5GB未満。AMD Ryzen AI Max+ 395では113 tokens/s、スマートフォン（機種非公表）では30 tokens/sを維持するとされる。いずれもLiquid AIによる計測で、第三者検証は確認できていない。「2.5GB未満」がどれだけのコンテキストを積んだ状態の値かは公表されておらず、今回の測定でも4,096トークンで1,862 MiB、131,072トークンで3,970 MiBと差が出ている。4,096トークン時の値に近い、短い文脈での値と考えられる。

公式GGUFリポジトリには8ファイルが並ぶ。Q4_0が1.59GB、QADと付いたQ4_0が同じく1.59GB、Q4_K_Mが1.67GB、Q5_K_Mが1.94GB、Q6_Kが2.22GB、Q8_0が2.87GB、BF16とF16が各5.4GB。QAD版は事後量子化版とは別系統の、量子化を織り込んだ蒸留チェックポイントだとリポジトリのREADMEに明記されている。同じサイズのファイルが2つ並ぶので、取得時にファイル名で区別する。

今回測ったのはQ4_K_Mだが、VRAM 16GB級ならもっと上を選ぶ余地がある。131,072トークンを張ってもGPU全体で3,970 MiBなので、重みが0.3GB増えるQ5_K_M、0.6GB増えるQ6_Kに上げても4〜5GB台に収まる。VRAMを他と分け合わないなら、下げる理由の方が薄い。逆にCPUのみで回す構成や8GB環境ならQ4_K_Mが基準線だ。

ライセンスはLFM Open License v1.0（lfm1.0）。本文はApache 2.0をベースに数点だけ変更したもので、年商1000万ドル以上（法文は「$10,000,000 or more」）になると無償の商用利用の権利が切れ、Liquid AIから商用ライセンスを購入する必要がある。判定は関連会社を含む法人単位。501(c)(3)相当の非営利法人が非商用・研究目的で使う場合はこの閾値の対象外だが、営利企業の社内研究は免除の対象と読めない。閾値を下回る個人開発者や小規模チームであれば、この収益条件による制限は生じない（法的助言ではないので、業務で使うなら原文を確認したい）。

入手経路｜Ollama公式ライブラリに2.6Bタグはない

公式が挙げる配布形式とランタイムの一覧は広い。Hugging Faceのモデルカードには、配布形式として native (Safetensors)・GGUF・MLX・ONNX が、対応ランタイムとして Transformers・vLLM・llama.cpp・MLX・LM Studio・SGLang が並ぶ。ただし一覧に名前があることと、普段の手順でそのまま落とせることは別で、このモデルはその差が大きい。

この一覧にOllamaは入っていない。公式ライブラリのlfm2.5にも8B（8b-a1b）系のタグしか存在せず、lfm2.5:8b（8b-a1b-q4_K_M）が5.2GBで並ぶだけで2.6Bは無い。ollama pull lfm2.5:2.6bのような操作では降ってこないので、普段Ollamaで統一している環境ではここが最初の分かれ目になる。公式リストにあるllama.cppやLM Studioの経路とは手順が変わる。

ただしGGUFそのものは公式配布されているので、Ollamaのhf.co指定なら取得できる。今回の測定でもこの経路を使い、ollama pull hf.co/LiquidAI/LFM2.5-2.6B-GGUF:Q4_K_Mで1,674,455,040バイトのGGUFが手元に落ちた。取得できたことと、Ollamaのランタイムで期待どおり動くことは別で、今回はそこまで確認していない。以降の測定はこのGGUFファイルをllama.cppへ直接渡して行っている。

バージョン条件が公式に明記されているのはvLLM 0.14（等号でのピン指定）、SGLang 0.5.10以降、Transformersの3つ。ただしTransformersは公式ドキュメントが5.2.0以降、モデルカードが5.0.0以降と割れているので、確実を期すなら5.2.0以降に合わせる。llama.cpp・LM Studio・MLX・ONNX Runtimeについては最低バージョンの記載を確認できなかった。今回動かしたllama.cppはb10092で、このビルドは本モデルをlfm2系のアーキテクチャとして読み込んだ。

llama.cpp周りではもう一点、AMX_INT8を有効にしてビルドした環境でLFM2系のモデルがCPU推論中にアサート失敗を起こすという報告があり、該当issueはnot plannedとしてcloseされている。ただし報告で名指しされているのはLFM2.5-VL-1.6B・LFM2.5-1.2B-Instruct・LFM2-2.6B-Expで、本モデル自体での再現報告ではない。今回のCPU測定で読み込まれたのはAlder Lake向けのCPUバックエンドで、AMXを使うビルドではない。この構成では31.09 t/sで問題なく生成できた。逆に言えば、AMXを有効にしたビルドでの挙動はこの測定からは何も言えない。

環境別に、どの経路から始めるか

NVIDIAのGPUがあり、まず感触を確かめたいならGGUF経由が最短だ。公式GGUFリポジトリのQ4_K_Mをllama.cppに渡し、コンテキスト長を明示して起動する。

llama-server -m <取得したGGUFファイル> -c 8192 -ngl 99

ツール呼び出しまで試すなら、これに--jinjaを足してモデル付属のチャットテンプレートを使わせる。-cは省略しない。省略すると環境によっては131,072トークンを取りにいき、今回の測定でいえば2,048 MiBを最初から確保する。-ngl 99は全層をGPUへ載せる指定で、CPUオフロードが起きていないかは起動ログの層配置で確認できる。

GUIで完結させたいなら公式GGUFをLM Studioに読み込ませる経路。Appleシリコン機ならMLX版が素直で、Liquid AIが220 tokens/sを報告しているM5 Maxも同じAppleシリコン機だ。ただし報告値がどのランタイムでの計測か、どれだけの文脈を積んだ状態かは公式の記述からは区別できない。今回の測定では文脈を131,072トークンまで積むと生成速度が空の状態の48%まで落ちたので、220 tokens/sも短い文脈での値として読む方が安全だ。

サーバとして複数リクエストを捌く前提なら、バージョン条件が明記されているvLLM 0.14かSGLang 0.5.10以降。並列処理を前提にKVキャッシュ管理が作り込まれているランタイムなので、本数を増やす構成ではここが本命になる（今回は測っていない）。

ローカルモデルに実際にツールを叩かせるところまで作り込む流れは、姉妹サイトのOpenJarvisでローカルAIアシスタントを作る完全手順でも扱っている。

どう判断するか

今回の測定から言えるのは、VRAM 16GB級の環境でこのモデルを使うなら、コンテキスト長はほぼ制約にならないということだ。131,072トークンを張っても3,970 MiBで、残り12GBが空く。同じことを密なTransformerでやると16GBに収まらないので、ここは明確な差がつく。

制約になるのは並列本数の方だ。4本それぞれに131,072トークンを与えると10,114 MiB。本数と1本あたりの長さの積で決まるので、どちらを優先するかを先に決める。今回測定したb10092の構成では、その積をそのまま-cに設定した。

速度は5060 Tiで95〜199 t/s、CPUのみで15〜31 t/s。GPUがあれば長文脈でも余裕があり、なければ短い文脈に寄せることになる。

用途の線引きは公式自身が引いている。公表ベンチマークではツール利用と指示追従で4倍近いサイズのモデルを上回る一方、エージェンティックなコーディングと知識集約タスクは非推奨用途とされる。この2つが主目的なら、モデル選定からやり直す方が早い。

よくある質問

Q. VRAM 8GBのGPUでも動きますか？

131,072トークンを張った状態でllama.cppが確保したのは、重み1,589 MiB＋KV 2,048 MiB＋計算バッファ199 MiB。ランタイム分を含めたGPU使用量の増分は3,970 MiBだった。この確保量はGPUの容量では変わらないので、8GBのカードでも同じ約3.9GBを見込めばよい。ただし今回は画面出力に使っていないGPUでの測定で、表示に使っているカードではその分を差し引く必要がある。8GB環境での実測ではない。

Q. コンテキスト長は最初から131,072にしておけばいいですか？

使わない長さの分もメモリを先に確保する。-c 131072なら起動時点で2,048 MiBがKVキャッシュに回る。1トークンあたり16.00 KiBなので、-c 8192なら128 MiB、-c 4096なら64 MiB。実際に使う長さに合わせた方が並列本数を増やせる。

Q. Ollamaで普段どおり使えますか？

公式ライブラリのlfm2.5には8B系のタグしかなく、2.6Bのタグは無い。hf.co/LiquidAI/LFM2.5-2.6B-GGUF:Q4_K_Mを指定した取得は成功したが、Ollamaのランタイムでの動作は今回確認していない。検索すると個人が上げた2.6Bのタグが見つかることがあるが、これは公式ライブラリのものではない。公式ライブラリにあるlfm2.5:8b（5.2GB）はLFM2.5-8B-A1B系で、2.6Bとは別モデルだ。

Q. 日本語で使えますか？

対応言語16言語に日本語が含まれる、というのがLiquid AIの公表内容だ。ただし日本語での品質を測ったベンチマークは確認できておらず、今回の測定でも出力品質は扱っていない。日本語でツールを呼ばせたり長文を処理させたりする前提なら、実際の出力を見てから判断することになる。

Q. 商用利用はできますか？

ライセンスはLFM Open License v1.0（lfm1.0）で、本文はApache 2.0をベースに数点だけ変更したもの。年商1000万ドル以上になると無償の商用利用の権利が切れ、Liquid AIから商用ライセンスを購入する必要がある。判定は関連会社を含む法人単位。501(c)(3)相当の非営利法人が非商用・研究目的で使う場合は閾値の対象外だが、営利企業の社内研究は免除されない。

まとめ

131,072トークンを張っても3,970 MiB。この数字がこのモデルの使い方を決めている。同じ条件で測った密なTransformerが16GBに収まらないことを考えると、長文脈を前提にした使い方でVRAMの余裕がまったく違う。理由はKVを持つ層が30層中8層だけであることと、その8層の1層あたりKV量が対照の半分であることの積で、どちらもパラメータ数からは読めない。

見積もりの順序としては、1本あたりに使うコンテキスト長と本数を先に決め、その積（今回測定したb10092の構成では-cに渡す値）に16.00 KiBを掛けてKVキャッシュを出し、GPUに載る重みの1,589 MiBを加える。これに計算バッファ（1本あたりの長さで決まり、32,768トークンで約103 MiB、131,072トークンで約199 MiB）とランタイム分の約134 MiBを乗せると、今回の測定10本すべてで実測のGPU使用量と一致した。起動前に必要量を計算できる。

ツール呼び出しは形式として成立していた。ただし試したのは1種類の問いを5回で、実運用の信頼性を語れる範囲ではない。出力品質も測っていない。採否は実際のタスクで動かしてから決めることになる。

参考資料

• Liquid AI 公式: LFM2.5-2.6B モデルカード (Hugging Face)
• Liquid AI 公式: LFM2.5-2.6B-GGUF リポジトリ
• Liquid AI 公式ドキュメント: LFM2.5-2.6B 対応ランタイムとバージョン条件
• Liquid AI 公式ブログ: LFM2.5-2.6B
• Liquid AI 公式: LFM Open License v1.0
• Ollama 公式ライブラリ: lfm2.5 タグ一覧
• llama.cpp: LFM2 系ビルド構成に関する Issue #19184
• llama.cpp: LFM2 のツール呼び出し引数名の解析修正 PR #26960

同じ小型クラスで、思考トークンの量が体感を決めた例は「Qwen3.8-4B」は使えるか｜土台のQwen3.5-4Bと同条件でRTX 5080/5060 Ti実測にまとめた。