調べてみたら、答えは「必ずしもそうではない」でした。しかも理由が、初学者にとってかなり大事な話だったので記録します。
まず結論
同じメモリの予算で比べるなら、巨大なモデルを無理に圧縮して動かすより、新しい世代の中型モデルを良い状態で動かすほうが、正確なことが多い——これが実測レポートの示す答えでした。
大きさ（パラメータ数）より、世代の新しさと、用途への特化のほうが効く。
理由①：モデルは「圧縮して」載せている
まず、初学者がつまずきやすい前提から。ローカルLLMを自分のマシンで動かすとき、モデルはそのままの姿では載りません。ファイルが大きすぎるので、量子化（りょうしか）という圧縮をかけて小さくしています。
画像に例えると分かりやすいです。同じ写真でも、軽く圧縮したものと、無理やり極限まで圧縮したものでは、後者は明らかに粗くなります。モデルも同じで、強く圧縮するほど賢さが削れていきます。
ここに罠があります。大きいモデルほど、手元のマシンに載せるには強い圧縮が必要になるのです。すると——
大きさで得た賢さを、圧縮による劣化が食い潰してしまう。
実際、極端に圧縮した巨大モデルが、素直なサイズのモデルに負ける、という報告もありました。「大きいほうが強い」は、同じ条件で載せられるならという但し書きつきの話だったわけです。
理由②：世代と特化が、サイズを上回る
もう一つの理由がこちらです。モデルは日進月歩で、新しい世代の中型モデルが、一世代前の大型モデルを上回ることが珍しくありません。
さらに、コード生成に特化して訓練されたモデルは、汎用の大型モデルよりその分野では強い。私がやりたいのはスクリプト作成とログ解析という限られた用途なので、汎用の巨大さより、用途への特化のほうが効くわけです。
実測の比較記事でも、ある程度のサイズを超えると品質はほぼ横並びになり、差がついたのは速度と安定性だったと報告されていました。つまり私がやる作業の難易度では、すでに品質は頭打ちに近いということです。
だから「速くて安定している」が正義になる
ここが実感として一番大きい部分でした。品質が横並びなら、選ぶ基準は自然とこうなります。
- ちゃんと最後までやり切るか（途中で迷子にならない）
- 速度が実用的か（待たされないこと自体が品質）
- 指示への素直さ（変な解釈をしない）
実際、少し前に「こんにちは」と挨拶しただけでモデルが暴走した話を書きました。あのとき問題だったのは賢さではなく安定性です。どんなに賢くても、止まらないモデルは使えません。賢さの最大値より、日常の安定——これが手元で使う道具の選び方でした。
ログ解析での実務的なコツ
もうひとつ、本業（システムのログを読む仕事）に関わる学びも。
最近のモデルは非常に長い文章を読めるのが売りですが、実務では巨大なログを丸ごと読ませないのが定石だそうです。理由は、読ませる量が増えるほど速度も精度も落ちるから。
正しい手順は、まず絞り込みのコマンドで必要な行だけ抜き出し、それを読ませて要約させる。AIに全部丸投げするのではなく、下ごしらえは人間（かコマンド）がやるわけです。これは以前、小さいモデルは「考える仕事」より「機械的な抽出」が得意だと学んだ話とも一致しています。
いちばん刺さった警告
調べる中で、実践者の記事にあった一文が刺さりました。
AIは作るのも得意だが、消すのも得意すぎる。
変更履歴の管理なしでAIに開発させるのは危険。
これは、このブログでずっと書いてきたことと同じでした。壊せる環境を用意する（使い捨てのコンテナ）、戻せる状態を作ってから進める（変更履歴の管理）。モデルの選び方より、この土台のほうが先だという話です。
おわりに ── 上を見る前に、足元を疑う
「もっと大きいモデルなら」と考えていたときの自分は、少し前に「もっとメモリの多いマシンなら」と考えていたときと、まったく同じ顔をしていたと思います。
あのときの結論はこうでした。足りないと思っていたのは性能ではなく、使い方だった。今回も同じで、必要だったのは大きいモデルではなく、用途に合った世代のモデルを、良い状態で動かすことでした。
上を見るのは簡単です。でも上を見る前に足元を疑うほうが、個人開発では安上がりで、学びも多い。ローカルLLMは高い機材が要る世界だと思われがちですが、案外そうでもない——というのが、ここ数週間の正直な実感です。
ローカルLLM / モデル選び / 量子化 / 個人開発
このブログでは、ローカルLLM・Aider・個人開発の試行錯誤をそのまま記録しています。
