ローカルLLM入門:自分のPCでモデルを動かす

ローカルLLMとは

ローカルLLMは、モデルの重み(学習で得たパラメータ)をダウンロードし、自分のPCの上で推論する使い方です。ClaudeのようなクラウドのAPIは、入力を事業者のサーバーに送って結果を受け取ります。ローカルでは、入力も出力も手元のマシンの中で完結します。仕組みはどちらも同じで、次のトークンを確率で選ぶ処理を繰り返します(基礎はLLMはどう動くかを参照)。違うのは、どこで計算するかです。

公開されているモデルの種類や性能は入れ替わりが早いので、この記事では特定のモデル名や性能の数字を載せません。選ぶときは、各モデルの公式ページとライセンスを確かめてください。

クラウドとローカルの違い

どちらが優れているかではなく、用途で選びます。機密性の高い文書を外に出したくない、ネットワークがない場所で使いたい、試行錯誤で大量に呼び出したい、といった場面はローカルが向きます。一方、最高の品質が必要な作業や、機材を持たない場合はクラウドが現実的です。両方を使い分ける人も多くいます。

必要なメモリを見積もる

ローカルで最初にぶつかる制約はメモリです。モデルの重みをメモリに載せる必要があり、その大きさは「パラメータ数 × 1パラメータあたりのバイト数」でおおよそ決まります。1パラメータを16ビット(2バイト)で持てば、70億パラメータ(7B)で約14GBです。次のコードで、サイズと精度ごとの目安を出します。JavaScript版とPython版の出力は同じです(筆者がNode.jsとPython 3で実行して確認)。

// 重みのメモリ量の目安(GB) = パラメータ数(十億) × 1パラメータあたりのバイト数
const GB = (billions, bits) => (billions * 1e9 * bits / 8) / 1e9;

for (const size of [7, 14, 32, 70]) {
  const row = [16, 8, 4].map((bits) => `${bits}bit ${GB(size, bits).toFixed(1)} GB`);
  console.log(`${size}B:`, row.join(' / '));
}

# 重みのメモリ量の目安(GB) = パラメータ数(十億) × 1パラメータあたりのバイト数
def gb(billions, bits):
    return (billions * 1e9 * bits / 8) / 1e9

for size in [7, 14, 32, 70]:
    row = [f"{bits}bit {gb(size, bits):.1f} GB" for bits in [16, 8, 4]]
    print(f"{size}B:", " / ".join(row))

7B: 16bit 14.0 GB / 8bit 7.0 GB / 4bit 3.5 GB
14B: 16bit 28.0 GB / 8bit 14.0 GB / 4bit 7.0 GB
32B: 16bit 64.0 GB / 8bit 32.0 GB / 4bit 16.0 GB
70B: 16bit 140.0 GB / 8bit 70.0 GB / 4bit 35.0 GB

手元のメモリに収まるかは、アプリのローカルLLMのメモリ見積もりで試せます。パラメータ数・精度・使えるメモリを選ぶと、重みの大きさと目安の判定が出ます。

これは重みだけの値です。実際には、会話の長さに応じて増えるキャッシュ(KVキャッシュ)や、OSと他のアプリの分も必要なので、表の値より余裕を見ます。

ここでいう「メモリ」は、動かし方によって指すものが変わります。

• GPU(NVIDIAなど)を使う場合:ビデオメモリ(VRAM)です。重みがVRAMに収まれば速く動きます。収まらない分をメインメモリに逃がせる場合もありますが、かなり遅くなります
• Apple Siliconの場合:CPUとGPUが同じメモリ(ユニファイドメモリ)を共有します。ビデオメモリという別枠はなく、普通のメモリがモデルにも使われます。ただしOSなどの分もあるので、全部をモデルに使えるわけではありません
• CPUだけで動かす場合:メインメモリです。動きますが、GPUより遅くなります

量子化で小さくする

表のとおり、1パラメータあたりのビット数を減らすと、メモリは比例して小さくなります。これが量子化です。精度を落とす代わりに、同じモデルを小さなメモリで動かせます。配布されているモデルの多くは、4ビット前後に量子化したものが用意されています。

• ビット数を減らすほど軽くなるが、回答の品質は少しずつ下がる
• 小さなモデルを高い精度で動かすより、大きなモデルを4ビットで動かす方が良いことが多い、と言われる。ただしモデルと用途で変わるので、手元で比べる
• 品質の差は、使う予定のタスクで試して確かめる。一般的な数字だけで決めない

Ollamaで動かす

手軽に始めるには、Ollamaのようなツールを使います。モデルの入手、量子化済みの形式での実行、ローカルAPIの提供をまとめて扱えます。ほかにLM Studio(画面付き)や、その土台になっているllama.cppなどがあります。

# モデルを取得して対話を始める(<モデル名> はOllamaのモデル一覧から選ぶ)
ollama run <モデル名>

# 取得済みのモデルを確かめる
ollama list

Ollamaは起動すると、手元(localhost)でAPIを待ち受けます。自分のプログラムからは、そこにHTTPで問い合わせます。最初に取得するモデルは、上の見積もりで空きメモリに収まる大きさを選びます。コマンドやAPIの詳細は変わることがあるので、公式ドキュメントで確認してください。

向いている用途と限界

• 向いている:機密文書の要約や分類、オフラインでの利用、大量の下書きや整形、仕組みを学ぶための実験
• 限界:大きなモデルほどは賢くない場合がある、長い文脈や複雑な推論は不安定になりやすい、応答速度は手元のマシンの性能に左右される
• 注意:ローカルで動かしても、モデルは間違えます。ローカルかクラウドかにかかわらず、出力は確かめてから使います

始める前の確認

• 使いたいタスクは、小さめのモデルで足りる内容か
• 空きメモリに、重みとキャッシュの余裕を足した量が収まるか
• 選んだモデルのライセンスが、用途(商用利用など)を許しているか
• 保存先の容量は十分か(モデルは数GB〜数十GBある)
• 出力の品質を、自分のタスクで比べたか

大きなモデルや複数人での利用、長い文脈を扱う場合は、続編のローカルLLMを本格的に動かすを参照してください。