【雑記】ローカルLLM、半年で選び方が変わりすぎている

ローカルLLM、消しました。

3月に VPS へ入れて、記事まで書いたやつです。使わなくなったから消した。それだけの話です。

で、消してから2026年のモデルの出方を追っていたら、あのとき悩んだ選び方が丸ごと古くなっていて、なんとも言えない気分になりました。

先に断っておくと、今回は完全に机上の話です。手元に環境が無いので実測値はゼロ。そういう記事だと思って読んでください。

消したやつの話

3月の記事はこれです。

VPS上に Ollama + 軽量ローカルLLMを構築した手順 | Lazy Developer

GPUなしのVPS上に、Ollama と軽量なローカルLLMを構築した記録です。今回は「中国製モデルは避けたい」「日本語に強いものがよい」という条件で、ELYZA 系の日本語モデルを採用しました。 6 vCPU / 11 GiB RAM / GPUなし のVPSでも、短文用途なら十分実用になります。 一

lazy-developer.jp

6 vCPU / 11 GiB RAM / GPUなし に Ollama を入れて、ELYZA の 8B を q4_k_m で回す構成。短文なら実用、長文は重い、初回ロードはとにかく待つ。OLLAMA_KEEP_ALIVE=-1 で常駐させて、コールドスタートだけは避けるようにしていました。

モデルを選んだ基準は2つで、日本企業であること、日本語寄りの調整が入っていること。

当時はこれが一番大事だと思っていたんですよね。

手順書の半分が、もう要らない

ここが一番こたえました。

3月の記事、後半はほとんど権限エラーとの殴り合いです。

Hugging Face から 4.9 GB の GGUF を curl で引っ張って、置き場所を /usr/share/ollama/import に決めて、Modelfile を書いて、ollama create でようやく名前が付く。途中で Modelfile が読めずに permission denied、GGUF の所有者を ollama:ollama に揃え直して、また create・・・。

そもそも tar に --zstd を付け忘れて怒られるところから始まってますからね、あの記事。

今は ollama pull して ollama run で終わります。公式ライブラリに載っているモデルなら、それだけ。GGUF をどこに置くかも、Modelfile に何を書くかも、考えなくていい。

あの格闘、何だったんだ。

systemd で常駐させる話と、127.0.0.1 に閉じる話は今でも生きているので全損ではありません。でも「モデルを入れる」章はまるごと消えます。

技術記事を書く側の教訓としては、手順は腐る、というだけの話です。分かってはいたのですが、腐り方が想像より速かった。

Raspberry Pi で動く時代になっていた

Gemma 4 が出たのが2026年4月2日。Google DeepMind から、Apache 2.0 で。

サイズの刻み方を見てほしい。

※ コンテキスト長は公式ブログだと「128K」とだけ書かれていて、モデルカードではサイズ別に分かれています。表はモデルカードの数字です。

問題は E2B のほうで、2bit や 4bit の重みなら 1.5 GB 未満のメモリで動くデバイスがある、と公式ブログに書いてあります。Raspberry Pi 5 の CPU で prefill 133 tokens/s、decode 7.6 tokens/s という数字つきで。

Raspberry Pi。

3月の自分は 11 GiB のメモリに 4.9 GB のモデルを載せて、「複数モデル常駐は厳しめです」とか真顔で書いていたわけです。それが手のひらサイズの基板で動いている。

もちろん E2B と 8B を同列に語るのは乱暴で、実効 2.3B のモデルに ELYZA 8B と同じ日本語を期待したら、たぶんがっかりします。それでも「そもそも載るのか」を心配する下限は、一段どころか二段くらい下がりました。

線引きの参考に書いておくと、OpenAI の gpt-oss は 120b が 80GB の GPU 1枚、20b が 16GB メモリのエッジデバイスで動くとされています。20b は 11 GiB の VPS には載らない。この「載る、載らない」の境界を眺めているだけでも、けっこう面白いです。

MoE は、まだ様子見

Qwen3.5 が2026年2月16日、いきなり 397B-A17B の MoE から始まりました。2月24日に 122B-A10B、35B-A3B、27B。3月2日に 9B、4B、2B、0.8B。全部 Apache 2.0 で、すでに Qwen3.6 系まで来ています。

A17B の A はアクティブパラメータ。総パラメータが 397B でも、1回の推論で動くのは 17B ぶんだけという構造です。Gemma 4 の 26B A4B も同じで、25.2B のうち働くのは 3.8B。

これを見て「小さいメモリでも動くのでは」と思ったのですが、重み自体は総パラメータぶんをどこかに置くはずで、そこがどうなるのか分かっていません。可能性はある、くらいに留めておきます。

測ってもいないことを断言するのが、一番かっこ悪いので。

Apple Silicon、Apple Silicon、Apple Silicon

Ollama の2026年を並べます。

• 3月30日: Apple Silicon で MLX 駆動をプレビュー提供開始
• 6月5日: v0.30 で GGUF まわりを改善し、llama.cpp 経由の対応モデルを拡大
• 6月11日: MLX エンジンの更新で Apple Silicon 上の品質、速度、メモリ効率を改善
• 6月29日: multi-token prediction によって Apple Silicon 上の Gemma 4 が平均で最大90%高速化

見ての通りです。

Mac を持っている人には最高の半年だったはず。CPU 推論で粘っている Linux VPS 勢に効いたのは、v0.30 の対応モデル拡大くらいでしょうか。

スケジューラも改善されて、OOM 由来のクラッシュが減ったという話もあります。11 GiB で GPU なしの環境と格闘していた身としては、これは素直にありがたい。当時ほしかった。

あと Ollama、7月9日に 8,800万ドル調達しています。ローカルで動かすためのランタイムにその規模の金が入る時代になったわけで、数ヶ月で消した側としては、ちょっと申し訳ない気持ちになりました。

組み直すか

組むなら Gemma 4 の E4B からでしょうね。3月の 8B より小さくて、しかもマルチモーダル。

書いていて指がうずうずしてきましたが、VPS からは消したあとです。11 GiB の CPU-only で E4B が何 tokens/s 出るのか、興味はある。ないものは測れない。

消した理由が「使わなくなったから」なので、選択肢が増えたことと自分が使うかどうかは、そもそも別の話でした。

短文の下書き、要約、日本語の壁打ち。3月に想定していた用途は、結局クラウド側でやったほうが速くて楽だったんですよね。

【雑記】結局どの AI（ LLM ）使えばいいの？問題を考える | Lazy Developer

「今一番性能がいい LLM って何?」 「コーディングならどれ使えばいい?」 「結局ChatGPTでいいの?」 こういう質問、最近やたらと聞かれるんですよね。 でも正直に言うと、 この質問に明確な答えを出すのはもう無理ゲー だと思っています。 理由は単純で、状況が変わりすぎるから。 1週間前の「最強」が今日も最強とは限

lazy-developer.jp

ローカルに意味が出るのは、外に出せないデータを触るときか、単純に自分で動かすのが楽しいとき。

自分は後者でした。だから飽きたら消えた。

おわりに

半年で変わったのは、だいたいこの3つです。

• 導入が pull と run で済むようになって、GGUF と Modelfile の格闘が消えた
• Apache 2.0 の軽量モデルが揃って、Raspberry Pi で動く水準まで降りてきた
• ランタイム側の投資は Apple Silicon 向きで、Linux の CPU 推論勢への恩恵は薄い

下がったのは構築の難易度だけです。使い続けるかどうかの話は、半年前と一ミリも変わっていません。

たぶんまた気まぐれに入れ直して、また消すんだと思います。そのときこの記事を読み返して「もう古い」と思うところまで、なんとなく想像がつく。