LFM2.5 1.2B JP 202606をM1 Max 64GBで動かしたらデコード208tok/sでJSON守るがモデル名をハルシネーションした

Liquid AIの LFM2.5-1.2B-JP-202606 をM1 Max 64GBで動かした。
llama.cpp（GGUF Q4_K_M）でデコード208 tok/s、短文整形は0.2秒で返る。
JSONの構造は守るがモデル名を「FDM2.5」にハルシネーションする、ツール呼び出しはGGUF経由では発火しない、といった限界も出た。

前に LFM2.5のハイブリッドアーキテクチャは整理した。
あの記事では、10層のdouble-gated LIV convolutionと6層のGQAで、TransformerでもMambaでもない構成になっている話を中心に書いた。
今回は構造ではなく、1.2Bを手元で実際に回して速度と用途の限界を見た。

旧LFM2-1.2BではなくLFM2.5を見る

Liquidのドキュメントでは、LFM2-1.2B は「deprecated」と明記され、改善版として LFM2.5-1.2B-Instruct を使うよう案内されている。
旧LFM2をあえて掘る理由は薄い。
モデル名だけで検索すると旧リポジトリも出てくるので、あとで落とすときにここで間違えそう。

LFM2.5の1.2B系は、Base、Instruct、Thinking、JP、VL、Audioまで分かれている。
ローカルで日本語チャットや小さなツール呼び出しを試すなら、まず LFM2.5-1.2B-JP-202606 を見る。
Hugging Faceのモデルカードでは、202606版は従来の LFM2.5-1.2B-JP より知識、指示追従、数学、コード、ツール使用で改善した最新版として出ている。

数値だけ拾うと、202606版は1.17Bパラメータ、16層（10層のLIV convolutionと6層のGQA）、語彙65,536、31.5Tトークン学習、32,768トークンコンテキスト、英日対応。
学習データのカットオフは2024年半ばなので、最近の出来事を聞くと普通に外す。
推奨生成設定は temperature=0.1、top_k=50、repetition_penalty=1.05。
細かい知識タスクには推奨しない、とモデルカード側でも書いてあるので、百科事典的な質問で勝負させるより、明確な指示、構造化出力、日英混在の小さな補助を投げるほうがテストになる。

JP版のベンチで何が高くて何が低いか

モデルカードは Qwen3-1.7B、Llama-3.2-1B、Gemma-3-1B あたりの2B未満と日本語ベンチで比べている。
スコアの内訳を見ると、このモデルの得意・不得意がそのまま出る。

ベンチ	スコア	何を測るか
J-MIFEval	79.08	日本語の指示追従
J-GSM8K	62.20	日本語の算数文章題
JMMLU	54.19	日本語の知識（多肢選択）
JHumanEval+	49.39	コード生成
JMMLU-ProX	36.23	難しめの知識・推論
ドメイン平均	53.11	—

指示追従（J-MIFEval）が79で高く、知識寄り（JMMLU-ProX）は36まで落ちる。
モデルカードの「知識タスクには推奨しない」はこの差のことだ。
だから手元のテストも、知識を問う質問は外して、指示通りに整形・構造化させたときに崩れないかを確かめる。

700MB台のGGUFとMLXがある

日本語版にもGGUFがある。
LiquidAI/LFM2.5-1.2B-JP-GGUF では Q4_0 が696MB、Q4_K_M が731MB、Q8_0 が1.25GB。
202606版にも LiquidAI/LFM2.5-1.2B-JP-202606-GGUF が用意されている。

MacならMLX版も見る。
Liquidの説明では、LFM2.5は llama.cpp、MLX、vLLM、ONNX などに対応している。
以前 Qwen3.6-35B-A3BをOllamaでM1 Maxに流したときは、巨大MoEでもM1 Max 64GBならGPU配置できた。
今回は1.2Bなのでメモリではなく、起動の軽さ、短文応答のレイテンシ、長めの日本語入力で速度が落ちるかを見たい。

M1 Max 64GBではメモリが制約にならないので、スマホ基準のQ4_K_Mだけでなく、Q8_0（1.25GB）も回して品質の上限を見る余地がある。
逆にスマホに乗せる前提で数字を揃えるなら、Q4_K_Mに固定して比べる。

llama.cpp なら、まずGGUFを直接読む。

llama-server -hf LiquidAI/LFM2.5-1.2B-JP-202606-GGUF:Q4_K_M \
  -c 4096 \
  --jinja \
  --temp 0.1 \
  --top-k 50 \
  --repeat-penalty 1.05 \
  --port 8765

OllamaでHF GGUFを直接呼べる環境なら、同じモデルをOllama側からも試す。
ただし、このモデルでOllamaのチャットテンプレートが期待通り効くかは確認対象に入れる。
LFM2.5はChatML風テンプレートで、ツール呼び出しは <|tool_call_start|> / <|tool_call_end|> トークンを使う。

ollama run hf.co/LiquidAI/LFM2.5-1.2B-JP-202606-GGUF:Q4_K_M

MLXは、202606版のMLXリポジトリを使って、GGUFとの差を見る。
Apple SiliconではGGUF/MetalとMLXで速度やメモリの出方が変わることがあるので、同じプロンプトを投げる。

実際に試してみた

環境

項目	値
マシン	M1 Max 64GB
OS	macOS 26.5 (Darwin 25.5.0)
llama.cpp (ggml)	0.10.1 (Homebrew)
Ollama	0.17.7
mlx-lm	0.31.3
モデル	`LiquidAI/LFM2.5-1.2B-JP-202606-GGUF` Q4_K_M (694MB) / Q8_0 (1.25GB)
コンテキスト	4096 / 32768

起動とメモリ

llama.cppのログから拾った情報。

llama-server -hf LiquidAI/LFM2.5-1.2B-JP-202606-GGUF:Q4_K_M \
  -c 4096 --jinja --temp 0.1 --top-k 50 --repeat-penalty 1.05 --port 8765

項目	ctx 4096	ctx 32768
常駐メモリ (RSS)	838 MB	1,171 MB
KVキャッシュ	—	384 MB (f16)
Metal配置	全17層GPU (MTL0)	全17層GPU (MTL0)
Flash Attention	auto → enabled	auto → enabled
Fused Gated Delta Net	enabled (autoregressive + chunked)	enabled (autoregressive + chunked)

GGUFメタデータ上の n_ctx_train は128,000。
モデルカードでは32,768と書いてあるが、GGUF側は128kが焼かれている。
ctx 32768で起動すると n_ctx_seq (32768) < n_ctx_train (128000) という注意が出る。

アーキ名は lfm2、tokenizer種別は gpt2（pre: lfm2）。
語彙65,536、テンプレートはChatML形式（<|im_start|>/<|im_end|>）。

短文の体感速度

投げたプロンプト

次の文章を、意味を変えずに短くして。

M1 MaxでローカルLLMを試すときは、速度だけでなく起動時間とテンプレート崩れも見る。

出力（llama.cpp、Ollama、MLXすべて同じ結果）

M1 MaxでローカルLLMを試す際は、速度・起動時間・テンプレート崩れを確認する。

決定的に同じ文が出る。temperature 0.1だと再現性が高い。

実行系	prompt tok/s	decode tok/s	total ms
llama.cpp ctx 4096 (1回目)	1,544	208	164
llama.cpp ctx 4096 (2回目)	1,194	209	192
llama.cpp ctx 32768	1,175	204	197
Ollama (Q4_K_M)	664	208	285
MLX (safetensors, f32ロード)	57	126	1,220

llama.cppのGGUF Q4_K_MがM1 Maxで最速。
Ollamaはデコードは同等だがプロンプト処理で半分。
MLXはデコードが126 tok/sと明確に遅い。safetensors直読みで量子化がかかっていないのが原因と思われる。

JSONを壊さないか

投げたプロンプト

次の入力からJSONだけを返して。
キーは title, tags, summary。
tagsは日本語の短い文字列配列。

入力:
LFM2.5 1.2B JP 202606をM1 Maxで試す。GGUFとMLXで速度を比べ、JSON出力と日英翻訳も見る。

Q4_K_Mの出力

{
  "title": "FDM2.5 速度比較実験",
  "tags": ["FDM2.5", "速度比較", "M1 Max"],
  "summary": "GGUFとMLXを用いてFDM2.5の速度を比較し、JSON出力と日本語翻訳を提供する。"
}

Q8_0の出力

{
  "title": "LFM2.5 1.2B JP 202606をM1 Maxで試す",
  "tags": ["Firmware", "Performance", "JP", "202606", "M1 Max"],
  "summary": "GGUFとMLXを使用して速度を比較し、JSON出力と日英翻訳を提供します。"
}

JSON構文としてはどちらもパース成功。構造は守る。
ただしQ4_K_Mは「LFM2.5」を「FDM2.5」にハルシネーションする（llama.cppでもOllamaでも再現）。
Q8_0では正しく「LFM2.5」が出た。量子化で英数字固有名詞の精度が落ちている。

tagsの質はどちらも微妙。Q4_K_Mは日本語タグの指示を守ったがモデル名が壊れ、Q8_0は英語タグになった。
1.2Bの知識量ではモデル名を正確に保持しつつ指示も完璧に守るのは限界がある。

日英混在を投げる

投げたプロンプト

次の作業メモを、あとで再実行できる短い手順に直して。

llama-server was started with --jinja, but the response still included tool_call tokens.
Maybe the chat template is not applied by the client.
M1 Max 64GB / Q4_K_M / ctx 4096.

出力（Q4_K_M、Ollama）

**修正手順：**

1. **設定ファイルの確認**
   - `--jinja` オプションが正しく適用されているか再確認する。
   - チャットテンプレートがクライアント側で正しく読み込まれているか検証する。

2. **応答ログの分析**
   - 出力ログを抽出し、`tool_call tokens` が含まれる箇所を特定する。
   - 該当部分がテンプレート未適用の結果かどうかを判断する。

3. **設定パラメータの調整**
   - `--jinja` オプションの使用方法を再確認し、必要に応じて正しい構文に修正する。
   - 例：`--jinja` の代わりに `--template` を使用するなど。

（以下省略、全376トークン）

日英混在のメモを受け取って手順化すること自体はできた。
ただし異様に冗長。1.2Bモデルは「短く答えて」と明示しないと長く書く傾向がある。
技術語（--jinja、tool_call tokens）は壊さず残しているので、ログ整理用途の下地にはなる。

デコード速度は211 tok/sで短文と変わらない。出力が長い分だけ実時間が伸びる（1.7秒）。

ツール呼び出しの形を見る

テキストプロンプト形式で投げた場合。

利用可能なツール:
get_weather(city: string) -> string

ユーザー:
東京の天気を調べて、短く答えて。

出力

東京の天気は晴れで、気温は約20℃です。

ツールを呼ばず直接回答してしまう。
OpenAI互換の tools パラメータをAPIレベルで渡しても同様。

{
  "tools": [{
    "type": "function",
    "function": {
      "name": "get_weather",
      "description": "指定した都市の現在の天気を返す",
      "parameters": {"type": "object", "properties": {"city": {"type": "string"}}, "required": ["city"]}
    }
  }]
}

結果はtool_callフィールドなし、contentに直接「東京の現在の天気は晴れで、気温は約20℃です。」と出力。

モデルカードではツール呼び出しを用途に挙げているが、llama.cpp/Ollama経由ではツール呼び出し形式の出力が得られなかった。
<|tool_call_start|> / <|tool_call_end|> のような特殊トークンを出す挙動がGGUFで再現できていないか、テンプレート側の問題かもしれない。
エージェント用途に使うなら、HuggingFaceのtransformers経由で特殊トークンが出るか別途確認が要る。

32768トークンを本当に使うか

ctx 32768で起動し直して、8,867バイト（2,529トークン）のブログ記事を丸ごと入力した。

以下の記事の要点を3行で抽出して。

（LFM2.5ハイブリッドアーキテクチャ記事の全文）

出力

1. Liquid AIはMIT CSAIL由来の「液体ニューラルネットワーク」を基に、エッジデバイス向けに
   Attention＋短距離畳み込みのハイブリッドアーキテクチャを採用したスタートアップ。
2. LFM2.5の核心はAttentionと短距離畳み込みの組み合わせで、1.2Bモデルでは全16レイヤーの
   うち10層がDouble-gated LIV convolution、6層がGrouped Query Attentionを用い、
   CPUでのprefill/デコード速度がTransformerの約2倍、メモリ効率も優れる。
3. 従来のSSM系に代わる「どっちでもないやつ」として、GQA・短距離畳み込み・線形Attentionの
   最適なトレードオフを実現。（256トークンで切れ）

項目	結果
input tokens	2,529
prompt processing	2,628 tok/s (962ms)
decode	204 tok/s
要約の質	記事の核心を拾えている。ハルシネーションなし

2,500トークン程度の入力でも速度低下は見られない。
prefill（入力読み込み）は短文時（50トークン）の1,200 tok/sより大幅に速く出ている（2,628 tok/s）。
バッチ処理のほうが効率が良いのか、キャッシュの影響か。

ctx 4096のときの短文速度とctx 32768の短文速度はほぼ同じ（デコード 208 vs 204 tok/s）なので、コンテキスト長を広げてもオーバーヘッドは小さい。

Q4_K_M vs Q8_0

項目	Q4_K_M	Q8_0
ファイルサイズ	694 MB	1.25 GB
decode (Ollama)	208 tok/s	157 tok/s
JSON構文	OK	OK
モデル名ハルシネーション	あり (LFM→FDM)	なし
prompt processing (Ollama)	664 tok/s	516 tok/s

Q8_0は速度が25%落ちる代わりに、固有名詞のハルシネーションが消える。
M1 Max 64GBならQ8_0の1.25GBでもメモリは余裕なので、精度重視ならQ8_0を選ぶ手はある。
体感の差は「一瞬」か「ほぼ一瞬」程度。短文ならどちらも数百ミリ秒で片付く。

会話のナチュラルさ

「LFM2.5-1.2B-JPは会話がナチュラル」という評判を見かけたので確認した。

systemプロンプトなしで雑談を投げると、箇条書きの丁寧語で返ってくる。

入力: 今日めっちゃ暑いんだけど、なんか涼しくなる方法ない？

出力:
暑いときの涼しさ対策は、以下の方法が有効です：
1. **水分補給** こまめに水や水分補給できる飲み物を摂ることで体温調節を助けます。
2. **風通しの良い場所へ移動** 窓を開ける、扇風機を使う（以下略）

systemに「カジュアルに話す友達です。敬語は使わないで。」を入れるとこう変わる。

出力: 日差し遮るやつ持って行けばいいよ！日傘とか帽子で直接光を避けよう。水分補給も忘れずに、
冷たい飲み物飲んで体を冷やすのが一番だよ。窓の外を見て、風通しのいい場所へ移動するのもアリ。
ちょっとした工夫で楽になるはず！

マルチターンで文脈を引き継いだ場合。

入力: 家の中にいるんだけどエアコンつけたくないんだよね、電気代やばくて

出力: 窓を開けて通風させるか、薄手のカーテンで風通し作るのがいい。湿気取りの除湿機使えば
快適になるよ。自然の風を活かすだけでも効果あるから、それがベスト！

systemプロンプトの指示追従は良い。「敬語を使わないで」でちゃんとタメ口になる。
1.2Bにしてはトーンの切り替えがスムーズで、不自然な丁寧語の混入がない。
「ナチュラル」と言われている理由はたぶんここで、小型モデルにありがちな「指示を無視して丁寧語に戻る」が起きにくい。

ただし内容の深みはない。雑談相手としてはリアクションが薄く、同じパターンの返しが続く。
「会話がナチュラル」は「文体コントロールが効く」であって「面白い返答が来る」ではない。

知識の限界とハルシネーション

学習データのカットオフは2024年半ば。
「Claude 4 Opusってどんなモデル？」と聞いたらこうなった。

**Claude 4 Opus** は、Microsoftが開発したオープンソースの自然言語処理（NLP）モデルで…
- **開発者**: Microsoft Research
- **リリース日**: 2023年（オープンソースとして公開）
- **パラメータ数**: 約1.5億パラメータ

全部でたらめ。知らないことを「知らない」と言えず、自信満々に嘘をつく。
1.2Bは知識量が足りないうえに、不確実性の表現ができない。
知識を問う質問はこのモデルの守備範囲外で、モデルカードの「細かい知識タスクには推奨しない」はこのことだ。

ファインチューニングの可能性

1.2Bパラメータは個人でファインチューニングできるサイズか。
LoRA/QLoRAなら十分できる。

フル精度で約2.4GB (fp16)、量子化済みなら700MB台
QLoRAなら学習時のVRAM使用量は4〜8GB程度
M1 Max 64GBのUnified MemoryでもMLXベースの学習は現実的

LLMのファインチューニングで何をやるかという話は、大きく3パターンに分かれる。

手法	やること	用途
SFT (Supervised Fine-Tuning)	入力と期待出力のペアで訓練	指示追従の強化（「JSONでだけ返せ」「この口調で話せ」）
DPO / RLHF	良い応答と悪い応答のペアで方向修正	安全性チューニング、トーン調整
継続事前学習	追加コーパスで知識を入れ直す	ドメイン知識の追加（法律、医学、社内用語）

1.2Bでファインチューニングするなら、SFTで「自分のユースケースに特化した応答パターン」を入れるのが現実的。
たとえば、自分のブログ記事のメタデータ抽出に特化させる、特定のJSON形式だけを出力するように訓練する、など。
知識を足す継続事前学習は1.2Bだと元の知識を壊しやすい（catastrophic forgetting）ので、やるなら慎重に。

Liquid AIのLFM2.5はライセンスが lfm1.0 で、商用利用可能、派生物の配布も可能。
ファインチューニングして自分のモデルとして使うことにライセンス上の障壁はない。

競馬予想に使えるか（思考実験）

個人でファインチューニングできるサイズなんだから、競馬の情報を叩き込んで予想を出させられないか。
継続事前学習でレース結果・血統・馬場状態を覚えさせて、SFTで「レース情報を入れたら予想フォーマットで返す」パターンを仕込む。スマホに載せればパドック見ながらローカルで予想が出る。

ただ壁が多い。

1.2Bの容量で覚えられる知識量に限界がある。全馬の血統テーブルを暗記させるのは無理で、入力時に渡す形（RAG的なアプローチ）になる
継続事前学習で競馬知識を入れると日本語能力が壊れるリスク（catastrophic forgetting）
そもそも競馬予想は「正解データ」が確率的。過去の勝ちパターンを学習しても、未来のレースでは馬場や体調が違う
リアルタイムのオッズや当日の馬体重は学習時に存在しないので、推論時に渡す仕組みが別途必要

現実的な落とし所としては、1.2Bモデルをファインチューニングするのではなく、1.2Bを「構造化出力エンジン」として使い、入力にレース情報を全部テキストで渡して、決まったフォーマットで予想を吐かせるほうが動く。
予想ロジック自体はモデルに入っていなくていい。入力のデータ量とプロンプトで勝負する形になる。
32,768トークンのコンテキストがあるので、1レース分の出走表＋過去戦績＋血統は全部入る。

同じ1.2Bがスマホに乗るか

M1 Maxで動かす話とは別に、このサイズはそもそもスマホ向けに作られている。
LFM2.5-1.2B-JP-202606のモデルカードでも、推奨用途に「オンデバイスのパーソナルアシスタント」が入っている。
Liquid AIはLFM2系を最初からエッジ（サーバーではなく、スマホや組み込み機器のような手元のデバイス）向けに設計していて、スマホ実行用に LEAP SDK と Apollo アプリまで出している。

メモリは余裕がある。
日本語版GGUFはQ4_0が696MB、Q4_K_Mが731MBなので、4bit量子化なら1GBを切る。
LEAPのAndroid SDKは実機RAM 3GB以上、ApolloアプリはRAM 4GB以上を要求するので、ここ数年のスマホならまず収まる。

スマホでの速度感（同型Thinking版の公称値）

速度はThinking版（同じ1.2Bアーキ）の公称値が参考になる。
JP-202606そのものの数字ではないが、層構成もサイズも同型なので桁感はつかめる。

チップ（端末）	実行系	prefill	decode	メモリ
Snapdragon 8 Elite for Galaxy（S25 Ultra）	llama.cpp / CPU / Q4_0	336 tok/s	70 tok/s	720MB
Snapdragon 8 Elite（ROG Phone 9 Pro）	NexaML / NPU	4,391 tok/s	82 tok/s	0.9GB
Apple A19 Pro	Cactus / CPU / INT8	420 tok/s	64 tok/s	1,128MB

デコード（生成）はCPUでもNPUでも60〜82 tok/sの範囲に収まり、生成速度は実行系を変えても大きくは伸びない。
差がつくのはprefill（入力を読み込む段階）で、NPU（スマホのAI専用処理ユニット）に載せると桁が一つ変わり、長い入力を投げても初動の待ちが短い。

そもそもNPU搭載スマホは普通にある

「NPUのあるスマホなんてあるのか」と思うかもしれないが、2024年以降のフラッグシップ機にはほぼ全部入っている。

チップ	搭載端末の例	NPU名称
Snapdragon 8 Gen 3 / 8 Elite	Galaxy S24 Ultra / S25 Ultra, ROG Phone 9	Hexagon NPU
Apple A17 Pro / A18 Pro / A19 Pro	iPhone 15 Pro / 16 Pro / 17 Pro	Neural Engine (16コア)
Google Tensor G4	Pixel 9 Pro	Google TPU
MediaTek Dimensity 9300	vivo X100 Pro	APU 790

これらのNPUは画像処理やカメラAIに使われているだけでなく、LLM推論にも使える。
ただし「NPUでLLMを動かす」には専用のランタイムが必要で、llama.cppのCPU実行とは別物。
LFM2.5の場合はLiquid AI自身がNexaMLやLEAP SDKでNPU対応を出しているので、対応チップなら使える。

M1 Maxで測った208 tok/s（デコード）は、スマホのCPU実行（64〜70 tok/s）の約3倍。
NPUに載せてもデコードは82 tok/s程度なので、生成速度だけ見ればM1 Maxの圧勝。
ただしスマホの利点はポケットに入ることと、常時起動していることだ。

問題はJP版をどう載せるか

「1.2Bがスマホで動くか」はほぼ解決済みで、残るのは「JP-202606版をどう載せるか」だ。
スマホ側の実行ルートは大きく2つある。

ひとつはApolloアプリ（iOS/Android、完全ローカル）やLEAP SDKのモデルライブラリから落とす正規ルート。
ただしライブラリに並ぶのは LFM2-1.2B のような汎用版が中心で、LFM2.5-1.2B-JP-202606 がそのまま並んでいるとは限らない。

もうひとつはGGUFを直接読ませるルート。
LEAPのAndroid SDKには任意のオンディスクGGUFを読む loadSimpleModel があり、llama.cppベースの汎用GGUF実行アプリでも、同じ700MB台のGGUFを置けば動く。
JP版を試すならこちらになる。

flowchart TD
    A[LFM2.5-1.2B-JP-202606<br/>をスマホで動かす] --> B{正規ライブラリに<br/>JP版がある?}
    B -- ある --> C[Apollo / LEAPで<br/>直接ダウンロード]
    B -- ない --> D[JP版GGUF Q4_K_M<br/>を用意]
    D --> E[loadSimpleModel か<br/>汎用GGUFアプリで読む]

最低ラインはAndroid 12以上、実機RAM 3GB以上（LEAP SDK基準）。
iOSはApolloかSwift SDK経由になる。

サイズもアーキも最初からスマホ向けなので、性能面で詰まる要素はない。
引っかかるとすれば、JP-202606版が正規ライブラリに並ぶのを待つか、GGUFを手で置く手間を取るか、そのどちらかを選ぶところだけだ。
同じQ4_K_Mをスマホでも回せば、M1 Maxで測ったデコード速度と桁で比べられる。

ブラウザでも動くか

700MB台ならブラウザのWebGPU/WebAssemblyでも一応動く。
wllama（llama.cppのWasmビルド）でGGUFをそのまま読むか、MLC LLMのWebGPU版で動かすルートがある。
初回700MBのダウンロードが要るのと、ネイティブ実行比で速度が1/3〜1/5に落ちるのとで、実用にはならない。
「インストールなしでLLMが動く」という技術デモとしては成立するサイズではある。

たぶん比較対象はQwenよりTinySwallow

公式ベンチでは Qwen3-1.7B や Llama-3.2-1B-Instruct と並べている。
ただ、手元で日本語の小さな補助役として見るなら、比較対象はQwen3.6 35Bのような大型モデルではない。
TinySwallow、Gemma 3 1B、Sarashina 1B台、Hy-MT2 1.8Bのような「軽いが用途が違うモデル」と比べるほうが近い。

Hy-MT2 1.8BをM1 Maxで動かした記事では、翻訳専用モデルとしてJSON、SRT、HTML、用語拘束を投げた。
LFM2.5-1.2B-JP-202606は翻訳専用ではないので、同じ土俵で勝ち負けを見るより、短文整形、構造化、日英混在メモ、軽いツール呼び出しを見る。

1.2Bで一番気になるのは、賢さの上限より失敗の軽さだ。
700MB台で起動して、数十トークンの返答が速く、JSONをそこそこ守るなら、常駐させるローカル補助モデルとして置き場所がある。

旧LFM2-1.2BではなくLFM2.5を見る

JP版のベンチで何が高くて何が低いか

700MB台のGGUFとMLXがある

実際に試してみた

環境

起動とメモリ

短文の体感速度

JSONを壊さないか

日英混在を投げる

ツール呼び出しの形を見る

32768トークンを本当に使うか

Q4_K_M vs Q8_0

会話のナチュラルさ

知識の限界とハルシネーション

ファインチューニングの可能性

競馬予想に使えるか（思考実験）

同じ1.2Bがスマホに乗るか

スマホでの速度感（同型Thinking版の公称値）

そもそもNPU搭載スマホは普通にある

問題はJP版をどう載せるか

ブラウザでも動くか

たぶん比較対象はQwenよりTinySwallow

参照したもの