この記事の要点
画面出力に使っていない VRAM 16GB のカード (RTX 5060 Ti) では、LFM2.5-24B-A2B の4ビットのファイルが全部載り、KV キャッシュを8ビットにすれば配布元が示す最長の文脈でも GPU だけで読み込めた。KV キャッシュが16ビットのままでも読み込めたが、最長の文脈では共有 GPU メモリの使用が q8_0 より増えた。
4ビットのファイルが 16GB に載りきらず、重みの一部を CPU 側に置いた Qwen3.6-35B-A3B と比べると、入力の処理も生成も大きく速かった。一方で、思考なしの指定でも思考が入り、出力の上限を短くした要約では答えの本文まで届かなかった。
Claude Code の小さな作業では、説明とバグ修正はどちらのモデルもこなし、機能追加を最後まで終えた回は Qwen3.6-35B-A3B の方が多かった。Ollama の公式ライブラリの lfm2.5 には2026年10月15日に 24B のタグが加わったが、本記事では試していない。本記事では配布元の GGUF を取り込み、Ollama 0.40.4 で動かした。
LFM2.5-24B-A2BはVRAM 16GBのカードで動くか
配布元の Liquid AI が公開している GGUF のリポジトリには、4ビットの Q4_K_M (14.53GB、14,526,258,464 バイト) と、量子化を考慮した蒸留で作った QAD-Q4_0 (13.58GB、13,578,190,880 バイト) のほか、Q5_K_M・Q6_K・Q8_0 などが並んでいる。配布元は llama.cpp で動かす例も載せている。ファイルの大きさはそのまま動かすときに要る VRAM ではなく、実際にはここに KV キャッシュ (会話の途中の計算結果をためておく領域。文脈を長くするほど大きくなる) などが加わる。
VRAM 16GB の RTX 5060 Ti (画面出力に使っていないカード) では、KV キャッシュを8ビット (q8_0) にすると、配布元が示す最長の文脈の長さ (一度に扱える入力と出力の長さ。コンテキスト長) である 131,072 トークンでも、Q4_K_M の全部の層を GPU に置けた。トークンは文字のかたまりで、モデルはこの単位で文章を扱う。モデルを読み込んだ直後の使用量は 15,740MiB。1秒おきに記録した共有 GPU メモリ (GPU がメインメモリから借りて使う領域) の使用は最大 216MiB で、文脈 65,536 の回 (最大 152MiB) や QAD-Q4_0 の 131,072 の回 (最大 216MiB) と同じくらいだった。いずれも llama.cpp b11218 で 2026年10月14日に測った読み込み直後の値で、作業中はこれより少し増える。
KV キャッシュを16ビット (f16) のままにして文脈 131,072 トークンで読み込むと、読み込み直後の使用量は 15,976MiB、共有 GPU メモリの使用は最大 984MiB になった。q8_0 の同じ文脈の回 (最大 216MiB) より約 770MiB 多い。共有 GPU メモリの使用は q8_0 の回でも 150〜220MiB ほど出ており、増えた分がどの領域 (重み・KV キャッシュ・作業用の領域など) の使用なのかは確かめていない。この状態での速さも測っていない。
VRAM 12GB・8GB のカードは試していない。Q4_K_M のファイル (14.53GB) も QAD-Q4_0 のファイル (13.58GB) も、それだけで 12GB を超えるので、ファイルの大きさから計算する限り、12GB のカードでは全部の層を GPU に置く形にはならず、一部を CPU 側に置いて動かすことになる。その形での LFM2.5-24B-A2B の速さは測っていない。
比べる相手の Qwen3.6-35B-A3B は、unsloth が配布する4ビットの GGUF (UD-Q4_K_M) が 22.13GB あり、16GB のカードには全部は載らない。llama.cpp の自動調整 (--fit) に任せると、重みの一部を CPU 側 (メインメモリ) に置く形で読み込み、文脈 65,536 で読み込んだ直後の GPU の使用量は RTX 5060 Ti で 14,112MiB、RTX 5080 で 15,248MiB だった。本記事の Qwen3.6-35B-A3B の値はすべてこの構成のもので、全部 GPU に載せた値ではない。Qwen3.6-35B-A3B がどんなモデルで、ローカルでどう動かすかはQwen3.6-35B-A3B のローカル実行ガイドで扱っている。
| ファイル | 大きさ | VRAM 16GB のカードでの置き方 (本記事の測定) |
|---|---|---|
| LFM2.5-24B-A2B Q4_K_M | 14.53GB | 全部 GPU |
| LFM2.5-24B-A2B QAD-Q4_0 | 13.58GB | 全部 GPU |
| Qwen3.6-35B-A3B UD-Q4_K_M | 22.13GB | 一部 CPU |
表の「全部 GPU」はモデルのすべての層を GPU に載せた状態、「一部 CPU」は重みの一部を CPU 側 (メインメモリ) に置いた状態を指す。文脈の長さごとの使用量の細部は「文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）」の節にまとめた。
LFM2.5-24B-A2Bとは
配布元のモデルカードによると、LFM2.5-24B-A2B は MoE (全体のパラメータのうち、1トークンごとに一部 (エキスパート) だけを使って計算する作り) のモデルで、全体で 24.0B (240億) のパラメータを持ち、1トークンの計算に使うのは 2.45B。MoE の各ブロックに64のエキスパートがあり、そのうち4つを使う。層は40で、そのうち30が短い畳み込みのブロック、10が GQA (注意の層)。文脈の長さは 131,072 トークンで、扱うのは文章だけ (画像は扱わない)。同じ LFM2.5 の小さいモデルで長い文脈に要る VRAM を測った結果は、LFM2.5-2.6B の必要 VRAM を 16GB GPU と CPU のみで実測した記事にある。
配布元はこのモデルを、答える前に必ず思考する (答える前に考えを書き出す) モデルと説明しており、チャットテンプレートが答えの書き出しに思考の印 <think> を直接入れる。思考を切るテンプレートの設定は配布元の説明に無く、本記事の測定でも、llama.cpp b11218 の llama-server では思考なしを指定した要求で思考が入り、Ollama 0.40.4 では既定の設定のまま思考が入った。llama-server の起動時の指定など、要求ごとの指定以外で思考を止める方法は試していない。
配布元は16のベンチマークで Qwen3.6-35B-A3B などと比べた表を載せており、どのモデルも vLLM で評価したとしている。そのうち、LFM2.5-24B-A2B が上の項目と Qwen3.6-35B-A3B が上の項目から本記事で5項目を選ぶと次のとおり。残りの11項目は配布元の表にある。
| ベンチマーク (配布元の値) | LFM2.5-24B-A2B | Qwen3.6-35B-A3B |
|---|---|---|
| LiveClaw | 48.09 | 38.19 |
| AutomationBench | 27.69 | 8.72 |
| IFBench | 74.69 | 64.21 |
| SWE-Bench Verified (OpenCode) | 51.00 | 66.20 |
| GPQA Diamond | 74.42 | 83.69 |
LiveClaw・AutomationBench・IFBench は LFM2.5-24B-A2B が上、SWE-Bench Verified と GPQA Diamond は Qwen3.6-35B-A3B が上になっている。どれも配布元の測り方の値で、本記事では確かめていない。本記事で行った作業の結果とも同じ軸ではない。
使い方について配布元は、推論しながらツールを呼ぶエージェントに使うことを勧める一方で、知識を多く要する作業に単独で使うことは勧めておらず、検索と組み合わせるよう書いている。
ライセンスは Apache 2.0 ではなく LFM Open License v1.0。第5条は、年間売上が 1,000 万米ドル以上の事業者 (支配関係のある会社を合わせた単位) による商用利用を、このライセンスの対象外としている。ここに書いたのは条文の要約で、個々の利用が認められるかどうかの判断ではない。
QAD-Q4_0 について配布元は、Q4_0 に量子化したときに失われる分を取り戻すよう学習させた (量子化を考慮した蒸留) ファイルと説明している。本記事では QAD-Q4_0 の使用量と速さだけを測り、答えの中身は確かめていない。
配布元が推奨するサンプリングは temperature 0.1・top_k 50・repetition_penalty 1.05 で、GGUF にもこの値が入っており、llama.cpp は指定が無ければこの値を使うと配布元は書いている。本記事のチャットの課題は要求で温度0 (greedy) を指定したので、この推奨値では測っていない。
Ollamaで読み込めるか
2026年10月15日の時点で、Ollama の公式ライブラリの lfm2.5 には 24B のタグ (lfm2.5:24b、15GB、文脈 128K) がある。lfm2.5:24b は 24b-a2b-q4_K_M のタグと同じもので、ほかに 24b-a2b-q4_0・24b-a2b-q8_0・24b-a2b-bf16 のタグもある。本記事では公式ライブラリのタグは試しておらず、配布元の GGUF を取り込んだものと同じ設定・速さで動くかは確かめていない。2026年10月14日に確認した時点では、並んでいたタグは 8b (8b-a1b) のものと latest で、24B のタグは見つけられなかった。本記事の Ollama の測定は、配布元の GGUF を自分で取り込んで行った。以下はその手順と結果になる。
別の lfm2 のページには 24b のタグ (lfm2:24b、14GB、文脈 32K) があるが、これは前の世代の LFM2-24B-A2B で、LFM2.5-24B-A2B ではない (2026年10月15日に確認)。配布元は、LFM2.5-24B-A2B は LFM2-24B-A2B の作りを引き継いで文脈の長さを 32K から 131K トークンに伸ばし、LFM2-24B-A2B と違って必ず思考してから答えると説明している。
Ollama のドキュメントは、GGUF を取り込むときは Modelfile の FROM にファイルのパスを書き、ollama create でモデルを作る手順を示している。次は取り込むときの Modelfile の例で、FROM のパスは GGUF を置いた場所に合わせる。測定ではこの1行だけの Modelfile で取り込み、ほかの指定は足していない。
FROM C:/models/LFM2.5-24B-A2B-Q4_K_M.ggufModelfile を置いたフォルダーで取り込み、起動する例 (lfm24b は自分で付ける名前)。
ollama create lfm24b -f Modelfile
ollama run lfm24bOllama 0.40.4 では、この Modelfile で ollama create が通った。取り込んだモデルは種類が lfm2moe・量子化が Q4_K_M と表示され、機能としてツール (tools)・思考 (thinking)・文章の生成 (completion) が並んだ。RTX 5060 Ti だけを使う設定で読み込むと全部が GPU に載り (Ollama の表示で 14.7GB)、文脈の長さの既定は 4,096 だった。測定に使った Ollama 0.40.4 は、リリースの記録によると 2026年10月12日に公開されたもの。
Ollama のドキュメントは、文脈の長さの既定を VRAM の量で決めるとしており、24GiB 未満では 4k としている。変えるには、アプリの設定のスライダーを動かすか、OLLAMA_CONTEXT_LENGTH を付けて ollama serve を起動する。Ollama で文脈を伸ばしたときの使用量と速さは測っていない。
動作の確かめとして、税込み合計の問題 (税率の違う2つの商品を買ったときの税込み合計を、問題文の決まりどおりに四捨五入して求めるもの) を、温度などを指定せず Ollama の既定のまま3回出した。2回は 1,229円で正解し、1回は「税額は切り捨てが慣例」として問題文の「四捨五入」を切り捨てに読み替え、1,228円と答えた。生成 (decode。答えのトークンを1つずつ書き出す処理) は1秒あたり 176.6〜178.5 トークンで、思考の部分は 9,129〜13,253 字あった。3回だけの結果で、llama-server で温度0を指定した回とはサンプリングが違う。読み替えた理由は確かめていない。問題の中身は「Claude Code・チャットで試した結果」の節で説明する。
ツール呼び出しも1回だけ試した。都市の現在の気温を返すツール (get_temperature) を1つ渡し、「東京と大阪の今の気温を調べて、どちらが暖かいか教えて」と聞くと、東京の分の呼び出し1件だけを返し、大阪の分は呼ばなかった。1回だけの結果で、ツール呼び出しの得手不得手を言える量ではない。ツールの結果を返したあとの続きは試していない。
文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）
ここからは起動の指定と使用量の細部に入る。次は VRAM 16GB のカードで、全部の層を GPU に置き、KV キャッシュを8ビットにして最長の文脈で起動する例。容量の表は、これと同じ指定で文脈の長さ (-c) と KV キャッシュの型を変えて測った。
llama-server -m LFM2.5-24B-A2B-Q4_K_M.gguf -ngl 99 --fit off -c 131072 -ctk q8_0 -ctv q8_0 -fa on --parallel 1| 文脈の長さ (トークン) | Q4_K_M・KV キャッシュ q8_0 | Q4_K_M・KV キャッシュ f16 | QAD-Q4_0・KV キャッシュ q8_0 |
|---|---|---|---|
| 4,096 | 14,104MiB | 14,140MiB | 13,200MiB |
| 32,768 | 14,432MiB | 14,728MiB | 測っていない |
| 65,536 | 14,868MiB | 測っていない | 測っていない |
| 131,072 | 15,740MiB | 15,976MiB (共有 GPU メモリの使用が最大 984MiB) | 14,836MiB |
カードは OCuLink で外付けした、画面出力に使っていない RTX 5060 Ti 16GB で、待機時の使用は 0MiB。llama.cpp b11218 の llama-server を -ngl 99 --fit off --parallel 1・flash attention on で起動し、モデルを読み込んだ直後に nvidia-smi で読んだ使用量 (MiB) を載せた。131,072 と 65,536 の q8_0、131,072 の f16、QAD-Q4_0 の 131,072 は読み込みをやり直して同じ値になり、その回は Windows の GPU メモリのカウンタを1秒おきに記録して共有 GPU メモリの使用も見た。画面出力に使っているカードは表示の分だけ空きが減り、作業中は読み込み直後より少し増える。
Q4_K_M・KV キャッシュ q8_0 では、文脈を 4,096 から 131,072 トークンへ伸ばしても、読み込み直後の使用量は 1,636MiB 増えただけで、文脈1トークンあたり約13KiB だった。QAD-Q4_0 も同じ範囲で同じく 1,636MiB 増えた。この増え方には、KV キャッシュ以外に文脈とともに大きくなる作業用の領域も含まれる。
同じ測り方で以前測った Underdog Saluki 27B (Qwen3.8-27B を2ビット中心に量子化したもの) は、KV キャッシュ q8_0 で文脈1トークンあたり約39KiB ずつ増えていた。LFM2.5-24B-A2B の増え方はその3分の1ほどになる。Underdog Saluki 27B の値は 2026年10月10日に RTX 5060 Ti・llama.cpp b11218 で測った読み込み直後の使用量で、モデルの大きさも量子化も違う。文脈ごとの使用量はUnderdog Saluki 27B を VRAM 16GB で測った記事に載せている。
増え方が小さかったのは、KV キャッシュを持つのが注意の層 (GQA) で、配布元の説明では40層のうち10層しかなく、すべての層が注意の層のモデルより KV キャッシュが小さくなるためと考えられる。Underdog Saluki 27B の層の作りは本記事では確かめておらず、3分の1という差がこの層の数だけで決まるとは言えない。層ごとの使用量も測っておらず、切り分けてはいない。
Q4_K_M を文脈 131,072 トークンで読み込んだ回では、KV キャッシュを q8_0 にした方が、f16 のときより共有 GPU メモリの使用を抑えられた。f16 でも読み込みはできたが、その状態での速さと安定性は測っていない。読み込み直後の使用量で f16 と q8_0 を比べると、差は 4,096 で 36MiB、32,768 で 296MiB だった。q8_0 と f16 で答えの質に差が出るかも確かめていない。
文脈の長さを llama.cpp の自動調整に任せる (-c を外して -fitc 16384 を付け、--fit に選ばせる) と、Q4_K_M では RTX 5080 で 16,384、RTX 5060 Ti で 19,200 トークンしか選ばれなかった。QAD-Q4_0 では 73,984 と 88,320 だった。自動調整は空きを多めに残して選ぶので、--fit off で 131,072 まで載ったこととは食い違わない。選ばれる長さはそのときの空きメモリと設定で変わり、決まった上限の値ではない。長い文脈を使うなら -c で長さを指定する。
QAD-Q4_0 は Q4_K_M よりファイルが約1GB 小さく、同じ文脈での読み込み直後の使用量は 900MiB ほど少なかった (4,096 で 13,200MiB 対 14,104MiB、131,072 で 14,836MiB 対 15,740MiB)。
画面出力に使っている RTX 5080 (16GB) でも、Q4_K_M を文脈 40,960・KV キャッシュ q8_0 で全部 GPU に載せて動いた。読み込み直後の使用量は画面の表示の分を含めて 15,571MiB。画面の表示が使う量は 1.2〜1.4GB ほどで、表示する内容で変わる。RTX 5080 では 131,072 の容量は測っていない。
入力の処理と生成の速さ（RTX 5080・RTX 5060 Ti）
速さは2つに分けて測った。入力の処理 (prefill) は渡した文章をまとめて処理する段階で、入力が長いほど最初のトークンが返るまでの待ち時間に効く。LFM2.5-24B-A2B では、最初のトークンは思考の書き出しで、答えの本文ではない。生成 (decode) は答えのトークンを1つずつ書き出す段階で、文字が流れていく速さにあたる。表の値はどちらも1秒あたりのトークン数で、「入力の処理 / 生成」の順に並べた。
| モデルと置き方 | 1K の入力 | 4K の入力 | 32K の入力 |
|---|---|---|---|
| LFM2.5-24B-A2B Q4_K_M・RTX 5080・全部 GPU (40,960) | 4,479 / 231.2 | 5,907 / 207.2 | 5,716 / 180.1 (5.63秒) |
| LFM2.5-24B-A2B QAD-Q4_0・RTX 5080・全部 GPU (自動調整 73,984) | 5,484 / 240.9 | 7,326 / 230.5 | 7,493 / 211.5 (4.23秒) |
| Qwen3.6-35B-A3B UD-Q4_K_M・RTX 5080・一部 CPU (65,536) | 548 / 69.9 | 722 / 69.5 | 834 / 69.1 (37.89秒) |
| LFM2.5-24B-A2B Q4_K_M・RTX 5060 Ti・全部 GPU (40,960) | 2,903 / 179.9 | 3,551 / 175.7 | 3,255 / 139.2 (9.73秒) |
| LFM2.5-24B-A2B QAD-Q4_0・RTX 5060 Ti・全部 GPU (自動調整 88,320) | 3,221 / 185.8 | 3,884 / 173.8 | 3,576 / 143.8 (8.84秒) |
| Qwen3.6-35B-A3B UD-Q4_K_M・RTX 5060 Ti・一部 CPU (65,536) | 298 / 54.6 | 395 / 53.7 | 409 / 49.0 (77.28秒) |
32K の列の括弧は、要求を送ってから最初のトークンが届くまでの秒数。llama.cpp b11218 の llama-server で、KV キャッシュ q8_0、flash attention on、--parallel 1。入力はコード系の文章で毎回先頭を変え、値は API の応答の時刻から求めた。生成は 256 トークン、温度0 (greedy)、思考なしを指定し、各3回の中央値をとった。LFM2.5-24B-A2B の Q4_K_M は -ngl 99 --fit off -c 40960 で層をすべて GPU に置いた。QAD-Q4_0 は -c を外し -fitc 16384 を付けて --fit に文脈の長さを選ばせ、全部の層が GPU に載った。Qwen3.6-35B-A3B は -c 65536 を指定して層の載せ方を --fit に任せた。RTX 5060 Ti は画面出力に使っていないカード、RTX 5080 は画面出力に使っているカード。CPU は Core i7、メインメモリは DDR5。
LFM2.5-24B-A2B の Q4_K_M を全部 GPU に載せると (文脈 40,960)、生成は1秒あたり RTX 5080 で 231.2 (1K の入力)〜180.1 (32K の入力) トークン、RTX 5060 Ti で 179.9〜139.2 トークンだった。32K の入力で最初のトークンが返るまでは RTX 5080 で 5.63秒、RTX 5060 Ti で 9.73秒。
Qwen3.6-35B-A3B (UD-Q4_K_M) は重みの一部を CPU 側に置いた構成で、文脈 65,536 のとき生成は1秒あたり RTX 5080 で 69.9〜69.1 トークン、RTX 5060 Ti で 54.6〜49.0 トークン。32K の入力で最初のトークンが返るまで、RTX 5080 で 37.89秒、RTX 5060 Ti で 77.28秒かかった。35B-A3B 級の MoE が 16GB からあふれたときに速さがどう変わるかは、2枚目の GPU でオフロードを解消した RTX 5080+5060 Ti の実測で詳しく測っている。
同じ GPU・同じ入力の長さで比べると、LFM2.5-24B-A2B (全部 GPU) は重みの一部を CPU 側に置いた Qwen3.6-35B-A3B に対して、生成が約2.6〜3.3倍、入力の処理が約7〜10倍速く、32K の入力で最初のトークンが返るまでの時間は約7〜8分の1だった。これは全部 GPU に載せた Qwen3.6-35B-A3B との比でも、モデルそのものの速さの比でもなく、16GB のカードに載せたときの構成どうしの比になる。ファイルの大きさも違う (14.53GB 対 22.13GB)。
速さの測定では思考なし (reasoning_effort none) を指定したが、LFM2.5-24B-A2B が生成した256トークンはすべて思考の中で、答えの本文は始まっていなかった。速さの値は生成したトークンの数で測っているので有効だが、答えの中身はこの測定では見ていない。Qwen3.6-35B-A3B は思考なしの指定で思考を切っている。
QAD-Q4_0 は自動調整の文脈 (RTX 5080 で 73,984・RTX 5060 Ti で 88,320) のまま測り、生成は1秒あたり RTX 5080 で 240.9〜211.5 トークン、RTX 5060 Ti で 185.8〜143.8 トークンと、Q4_K_M と同じくらいかやや速かった。文脈の指定が Q4_K_M の 40,960 とは違い、QAD-Q4_0 の答えの中身は確かめていない。
Claude Code・チャットで試した結果
ここでの値はすべて RTX 5060 Ti・文脈 40,960 で測り、LFM2.5-24B-A2B は全部 GPU、Qwen3.6-35B-A3B は --fit に任せて重みの一部を CPU 側に置いた構成で動かした。
Claude Code の3つの作業
使ったのは、レシートの税を計算する小さな Python のリポジトリで、テストが1件失敗するバグを仕込んである。その複製で、次の3つの作業を3回ずつ行った。
- コードの説明: リポジトリの構成と、失敗するテストの原因を説明する (ファイルは変えない)。原因は Python の round が偶数への丸めをすること
- バグ修正: テストが全部通るようにバグを直す。直せばテストは6件すべて通る
- 機能追加: CSV ファイルから品目のリストを読み取る関数と、そのテストを足す
Claude Code 2.1.293 を llama-server (Anthropic 互換の API) につなぎ、-p で動かした。Read・Edit・Write・Glob・Grep と python -m pytest を確認なしで実行してよいツールとして許可し、--max-turns 30、外からの打ち切りは 1,800秒。表の値は作業1つの所要 (秒) とその間のやり取りの回数で、テストは作業のあとに別に pytest を回した結果 (コードの説明はファイルを変えない作業なので省いた)。
| モデル | 回 | コードの説明 | バグ修正 | 機能追加 | 作業後のテスト (バグ修正 / 機能追加) |
|---|---|---|---|---|---|
| LFM2.5-24B-A2B | 1回目 | 236.4秒 / 13回 | 483.6秒 / 23回 | 上限で打ち切り 773.4秒 / 31回 | 6件通過 / 8件通過 |
| LFM2.5-24B-A2B | 2回目 | 135.9秒 / 10回 | 155.3秒 / 8回 | 779.2秒 / 回数は記録できず | 6件通過 / 8件通過 |
| LFM2.5-24B-A2B | 3回目 | 108.6秒 / 10回 | 227.4秒 / 12回 | 上限で打ち切り 592.5秒 / 31回 | 6件通過 / 1件失敗・5件通過 |
| Qwen3.6-35B-A3B | 1回目 | 181.6秒 / 12回 | 150.0秒 / 12回 | 807.6秒 / 回数は記録できず | 6件通過 / 12件通過 |
| Qwen3.6-35B-A3B | 2回目 | 164.4秒 / 11回 | 154.8秒 / 13回 | 204.8秒 / 21回 | 6件通過 / 13件通過 |
| Qwen3.6-35B-A3B | 3回目 | 103.9秒 / 14回 | 124.3秒 / 12回 | 218.8秒 / 20回 | 6件通過 / 16件通過 |
「回数は記録できず」の回は、終わったときの記録にやり取りの回数が正しく残らなかった。小さなリポジトリの3つの作業の結果で、大きなリポジトリや長い作業の結果ではない。
コードの説明とバグ修正は、LFM2.5-24B-A2B も Qwen3.6-35B-A3B も3回とも終えた。コードの説明ではどの回も失敗するテストの原因 (Python の round が偶数への丸めをすること) を挙げ、ファイルを変えなかった。バグ修正の後はどの回もテストが6件すべて通った。
機能追加は、Qwen3.6-35B-A3B が3回とも終え、作業後のテストは 12・13・16件が通った。この件数は元からある6件とモデルが足したテストの合計で、件数の違いは足したテストの数の違いになる。LFM2.5-24B-A2B は1回目がやり取りの上限 (--max-turns 30) で打ち切られた。ただし関数とテストのファイルはできていて、テストは8件通った。2回目は終えた (8件通過)。3回目も上限で打ち切られ、関数のファイルを作れず、テストは元からある1件の失敗が残った。
3回目の機能追加の記録を見ると、LFM2.5-24B-A2B はファイルのパスの頭に余計な「/」を付けてファイルを開こうとしては何度も失敗し、作業フォルダーの外まで関数のファイルを探しに行くうちに上限に達していた。1回の記録を見た範囲のことで、失敗の原因が思考の長さにあるかは確かめていない。
チャットの3つの課題
llama-server に直接3つの課題を出した。思考 (reasoning) の強さは high、1回の出力の上限は 8,192 トークン、要求に温度0 (greedy) を指定し、どの課題も3回ずつ出した。温度0なので、答えは3回とも同じだった。
税込み合計の問題は、10% の商品と 8% の商品を別々に合計し、それぞれ1円未満を四捨五入して税額を出す店で、105円 (10%) と 1,031円 (8%) を1つずつ買ったときの税込み合計を、途中の式も書いて求めるもの。税額は 105×0.10=10.5 で11円、1,031×0.08=82.48 で82円になり、合計は 105+1,031+11+82=1,229円が正解。LFM2.5-24B-A2B も Qwen3.6-35B-A3B も3回とも 1,229円で正解した。
ただし LFM2.5-24B-A2B は、正解した答えにも、問題文の「1円未満を四捨五入」を「税額が1円未満のときの決まり」と読み、「税額がどちらも1円以上なので、このルールは影響しなかった」という趣旨の補足を書いていた。実際は 10.5円を11円にするところで四捨五入が効いている。「Ollamaで読み込めるか」の節で Ollama から出した3回の答えにも、税額が1円以上だからという同じ読み方の補足があった。Qwen3.6-35B-A3B の答えにはこの補足は無かった。
PC 構成の相談は、VRAM 16GB の GPU が1枚とメインメモリが 96GB の PC で、総パラメータ 100B を超える MoE の LLM を動かすとき、GPU とメインメモリにそれぞれ何を置くと速くなるかを理由と合わせて説明させるもの。決まった正解が無いので、答えが最後まで出たかだけを見た。両モデルとも3回とも答え終え、思考を含めて LFM2.5-24B-A2B は 3,751 トークン、Qwen3.6-35B-A3B は 4,040 トークンを書いた。答えの内容の正しさは採点していない。
コードを書く課題は、フォルダーの中の .log ファイルをすべて読み、「ERROR」を含む行の数をファイルごとに数えて多い順に表示する関数を、標準ライブラリだけで書かせるもの。両モデルとも関数を返したが、その関数が正しく動くかは確かめていない。
| 課題 | LFM2.5-24B-A2B (全部 GPU) | Qwen3.6-35B-A3B (一部 CPU) |
|---|---|---|
| 税込み合計の計算 (正解 1,229円) | 21.5〜24.3秒・正解 (3,852 トークン) | 30.7〜34.8秒・正解 (1,693 トークン) |
| PC 構成の相談 | 21.3〜23.7秒・答え終えた (3,751 トークン) | 75.1〜82.4秒・答え終えた (4,040 トークン) |
| コードを書く | 8.2〜9.1秒・関数を返した (1,450 トークン) | 52.0〜57.0秒・関数を返した (2,867 トークン) |
時間は3回の範囲で、トークン数は思考を含む。
生成は LFM2.5-24B-A2B の方が約3倍速いが、税込み合計の問題では思考を含めて 3,852 トークンを書き、Qwen3.6-35B-A3B の 1,693 トークンの2倍以上になった。そのため所要の差は生成の速さの差ほどは開かず、ほかの2つの課題のほうが差が大きく出た。
出力の上限が短い要約
出力の上限を 2,048 トークンにして、英語の技術記事10本を日本語で要約させた (思考なしを指定、温度 0.3)。Qwen3.6-35B-A3B は10本とも要約を返した (318〜576 トークン)。LFM2.5-24B-A2B は10本とも 2,048 トークンを使い切り、答えの本文は空だった。思考なしの指定でも思考が止まらず、思考の途中で上限に達したとみられる。思考の中身は記録しておらず、出力の上限を大きくした場合は試していない。
Qwen3.6-35B-A3Bとどちらを選ぶか
ここまでの結果を、手元の使い方ごとに並べ直す。どちらかを勧めるものではなく、見比べるための材料として置く。
| 手元の使い方 | 本記事で分かったこと | 結果のある節 |
|---|---|---|
| VRAM 16GB のカードで長い文脈を使いたい | 画面出力に使っていない RTX 5060 Ti では、LFM2.5-24B-A2B は KV キャッシュを q8_0 にすれば最長の文脈でも全部 GPU に載った (読み込み直後の値)。画面出力に使っているカードは表示の分だけ空きが減る | 「文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）」 |
| VRAM 16GB のカードで速さを取りたい | 32K までの入力で測った範囲では、全部 GPU の LFM2.5-24B-A2B が、重みの一部を CPU 側に置いた Qwen3.6-35B-A3B より入力の処理も生成も速かった。最長の文脈いっぱいの入力での速さは測っていない | 「入力の処理と生成の速さ（RTX 5080・RTX 5060 Ti）」 |
| 思考を切って短い答えを返させたい | LFM2.5-24B-A2B は思考なしを指定しても思考し、出力の上限を短くした要約では答えの本文が出なかった。Qwen3.6-35B-A3B は思考なしの指定で思考を切れた | 「LFM2.5-24B-A2Bとは」「Claude Code・チャットで試した結果」 |
| Claude Code に小さなリポジトリの作業をやらせたい | 説明とバグ修正はどちらも全回こなし、機能追加を最後まで終えた回は Qwen3.6-35B-A3B の方が多かった。小さなリポジトリでの結果 | 「Claude Code・チャットで試した結果」 |
| Ollama で動かしたい | 2026年10月15日に公式ライブラリに加わった lfm2.5:24b は試していない (lfm2:24b は前の世代の別のモデル)。配布元の GGUF を Modelfile で取り込む形では、文脈の既定 4,096 のまま RTX 5060 Ti で全部 GPU に載った | 「Ollamaで読み込めるか」 |
| 事業で使う | LFM2.5-24B-A2B は LFM Open License で、年間売上が一定以上の事業者の商用利用を対象外とする条文がある。Qwen3.6-35B-A3B のライセンスは本記事では扱っていない | 「LFM2.5-24B-A2Bとは」 |
検証環境と測り方
GPU は2枚で、画面出力に使っている RTX 5080 (16GB) と、OCuLink で外付けし、画面出力には使っていない RTX 5060 Ti (16GB) で測った。CPU は Core i7、メインメモリは DDR5。推論には llama.cpp b11218 の llama-server を使い、KV キャッシュ q8_0・flash attention on・--parallel 1 を基本に、全部 GPU の構成は -ngl 99 --fit off で、Qwen3.6-35B-A3B は層の載せ方を --fit に任せて起動した。速さは 1K・4K・32K の入力に対して 256 トークンを温度0で生成させ、3回の中央値をとった。使用量はモデルを読み込んだ直後に nvidia-smi で読み、一部の回は Windows の GPU メモリのカウンタを1秒おきに記録して共有 GPU メモリの使用も見た。測定機の詳しい構成は検証環境のページにまとめている。
本記事の実測値は、2026年10月14日に llama.cpp b11218・Ollama 0.40.4・Claude Code 2.1.293 で測ったもの (比べた Underdog Saluki 27B の値は 2026年10月10日の測定)。
測定に使った llama.cpp b11218 は、リリースの記録によると 2026年9月27日に公開されたビルド。測ったファイル (LFM2.5-24B-A2B の Q4_K_M・QAD-Q4_0、Qwen3.6-35B-A3B の UD-Q4_K_M) は、手元で計算した sha256 が配布元のリポジトリに載っている値と一致した。
Claude Code 2.1.293 は llama-server (Anthropic 互換の API) につなぎ、両モデルとも同じ番号の Claude Code・同じ作業・同じ設定で測った。Claude Code をこの形でローカルのサーバーにつなぐ使い方は、測定のための構成になる。チャットテンプレートは、Qwen3.6-35B-A3B は GGUF に入っているもののままで、会話の途中に system メッセージが来ても例外を出さなかったので変えていない。LFM2.5-24B-A2B も GGUF に入っているテンプレートのまま使った。
次のことは測っていない。
- VRAM 12GB・8GB のカード
- LFM2.5-24B-A2B を一部 CPU 側に置いたときの速さ
- QAD-Q4_0 の答えの中身
- Ollama で文脈を伸ばしたときの使用量と速さ
- Ollama の公式ライブラリの lfm2.5:24b を使ったときの動作 (取り込んだモデルと同じ設定・速さになるか)
- KV キャッシュを q8_0 にしたときと f16 のときの答えの質の差
- Qwen3.6-35B-A3B の UD-Q4_K_M を全部 GPU に載せた場合 (22.13GB で、16GB のカードには載らない)
- Qwen3.6-35B-A3B の UD-Q4_K_M 以外の量子化のファイル
- 配布元の推奨サンプリングでのチャットの結果
- 最長の文脈 (131,072 トークン) いっぱいの入力を処理させたときの使用量と速さ
- llama-server の起動時の指定など、要求ごとの指定以外で LFM2.5-24B-A2B の思考を止めたときの挙動
まとめ
画面出力に使っていない VRAM 16GB のカード (RTX 5060 Ti) では、LFM2.5-24B-A2B の4ビットのファイルは全部の層が GPU に載り、KV キャッシュを q8_0 にすれば配布元が示す最長の文脈でも読み込めた。ただし読み込み直後の値で、最長の文脈いっぱいの入力は処理させていない。画面出力に使っているカードは表示の分だけ空きが減る。12GB 以下のカードでは動かしていないので、ファイルの大きさと「文脈の長さごとに要るVRAM（RTX 5060 Ti 16GB）」の表を、手元のカードの容量と見比べることになる。
16GB に載りきらず重みの一部を CPU 側に置いた Qwen3.6-35B-A3B と比べると、32K までの入力で測った範囲では、入力の処理も生成も LFM2.5-24B-A2B の方が速かった。一方で、小さなリポジトリでの Claude Code の作業 (各3回) では、機能追加を最後まで終えた回は Qwen3.6-35B-A3B の方が多かった。作業1つにかかった時間は作業によってどちらが短いかが分かれ、回ごとのばらつきも大きかった。
思考なしの指定でも思考が入り、出力の上限を 2,048 トークンにした要約では答えの本文まで届かなかった (思考の途中で上限に達したとみられる)。
参考資料
- LiquidAI/LFM2.5-24B-A2B (Hugging Face)
- LiquidAI/LFM2.5-24B-A2B-GGUF (Hugging Face)
- Qwen/Qwen3.6-35B-A3B (Hugging Face)
- unsloth/Qwen3.6-35B-A3B-GGUF (Hugging Face)
- Ollama ライブラリ: lfm2.5 のタグ
- Ollama ライブラリ: lfm2
- Ollama ドキュメント: Importing a Model
- Ollama ドキュメント: Context length
- Ollama v0.40.4 (リリース)
- llama.cpp server README
- llama.cpp b11218 (リリース)
