Local LLM Primer
ローカルLLMを、仕組みから理解する
手元でLLMを動かすと、すぐに壁にぶつかります。27Bは動くのに70Bは落ちる。長い会話をしていると急にメモリが足りなくなる。最強のGPUを積んだのに思ったほど速くない。 ここでは手順書ではなく、その理由を扱います。
計算が関わるところは、読むだけで終わらせません。その場で数字を動かして確かめられます。
学習パス
上から順に読むと積み上がるように並べています。とくに第2章は、自分のマシンで何が動くかを自分で計算できるようになる章です。
モデルの正体
ダウンロードしたあのファイルの中に、何が入っているのか。ここが分かると以降の話が全部つながります。
LLMは次の1トークンを予測しているだけ
自己回帰生成のループ。「考えている」ように見える正体と、1トークンずつという性質。
トークンは単語ではない
日本語がトークン効率で不利な理由。コンテキストと速度と課金に効いてくる。
「7B」のBは、行列の中の数字の個数
パラメータ＝重み＝数字。パラメータ数 × バイト数 ＝ 必要メモリという関係。
AttentionとKVキャッシュ
同じ計算を二度しないための仕組み。このサイトで最も重要な概念。
チャットテンプレートを間違えるとモデルは壊れる
ベースとInstructの違い。性能が出ないとき、疑うべきはモデルではない。
MoE — メモリは食うのに、速い
総パラメータとアクティブパラメータ。320B/18Bという極端な比率の意味。
LoRA — 行列に差分を足すだけ
元のモデルを触らずに性格を変える仕組み。アダプタが数十MBで済む理由。
なぜ手元のPCで動くのか
70Bのモデルが140GBなら、なぜ128GBのマシンで動くのか。このサイトで最も実利がある章です。
必要メモリの見積もり式
パラメータ数 × 0.6 ＋ KVキャッシュ。実在モデル4つで誤差5%以内に当たる。
量子化は、何を捨てているのか
数字の丸め。サイズと精度が線形でないことが「4bitが標準」の理由。
量子化フォーマットは実行環境で決まる
GGUF / MLX / AWQ / GPTQ。迷ったらGGUFでいい理由。
長い会話で落ちる原因はKVキャッシュ
トークン数に比例して増える。GQAという発明がなければ長文は扱えなかった。
速度を決めているのは演算性能ではない
理論上限 ＝ メモリ帯域 ÷ 1トークンあたりの読み出し量。このサイトの山場。
1台に載らないときは
テンソル並列とパイプライン並列。そして帯域は足し算にならない。
結局、どれを使えばいいのか
Ollama、LM Studio、llama.cpp、vLLM、SGLang。これらは同じ土俵にいません。
Ollamaとllama.cppは競合していない
実行環境は3層に分かれる。この構造が分かると大半の疑問が解ける。
手元で動かすなら、この4つ
llama.cpp / Ollama / LM Studio / MLX の使い分け。
最初の1文字が遅い理由
prefillは演算性能、decodeはメモリ帯域。別物として理解する。
サーバ系エンジンが存在する理由
バッチ処理。重みを1回読めば8人分に使い回せる。1人で使うなら恩恵はゼロ。
temperatureは確率分布の形を変えている
モデルの中身はいじっていない。出てきた確率の扱い方を変えているだけ。
なぜ全部がOpenAI互換APIなのか
base_urlを2行変えるだけでクラウドとローカルを行き来できる。