自宅PCでローカルLLMを5モデル動かし比べた〜31Bから235Bまで実測【2026年版】

2026年6月23日

自宅のPCでローカルLLM（大規模言語モデル）を動かしていると、いつも迷うのが「結局どのサイズのモデルが実用なのか」です。そこで、手元の1台で 31B から 235B まで5つのモデルを実際に動かし、生成速度・GPUとCPUの分担・簡単な賢さを実測してみました。

結論から言うと、速度を決めるのは「モデルの総パラメータ数」ではなく、「1回の生成で実際に使われる“活性パラメータ”が、どれだけ速いメモリ（VRAM）に載っているか」でした。VRAMに収まる小さな活性のMoEが最速で、巨大でもVRAMから溢れると一気に遅くなります。

※ 本記事の数値は下記の実機での実測値です（確認日: 2026年6月16日）。モデル・量子化・設定・環境で変わります。

検証した環境

今回動かしたのはこのPCです。

GPUの選び方はGPU全機種スペック一覧、2枚挿しの実例はGPU2枚挿しの記事、Ollamaの導入はOllama導入記事も参考にしてください。

測定方法

公平になるよう、全モデルで条件をそろえました。

Ollama の API で、コンテキスト長は4096に固定、temperature=0、同じプロンプトを使用。生成速度（トークン毎秒）は同じ生成を複数回まわして中央値を取りました（裏で重い処理を走らせない状態で測定）。賢さは、連立方程式・論理・コード・ハルシネーション罠・指示追従などの小問題を解かせて確認しています。

用語の整理です。VRAMはGPUのメモリ容量、活性パラメータはMoE（混合エキスパート）で1トークンを作るとき実際に使われる一部の重み、量子化はモデルを圧縮してサイズを小さくする手法（例: Q2は約2bit、Q4は約4bit）です。

実測結果：5モデルの生成速度

順番に意味を見ていきます。

何が速度を決めたのか：活性パラメータ×メモリ

LLMが文章を生成する処理（decode＝1語ずつ作る）は、毎回モデルの重みをメモリから読み出します。速度はおおむね「1トークンで読む重みの量 ÷ そのメモリの速さ」で決まります。VRAM（RTX 3090で900GB/s超）とシステムのDDR4 RAM（おおむね40〜50GB/s）では、読み書きの速さにおよそ20倍前後の差があります。

ポイントは2つです。

VRAMに収まるか、溢れるか。モデルがVRAM 36GBに収まれば全部が速いVRAMで動きます。溢れた分は遅いDDR4 RAM側でCPUが処理するため、そこが足を引っ張ります。

毎回読む量＝活性パラメータ。denseモデルは毎トークン全パラメータを読みますが、MoEは一部の「専門家」だけを使うので読む量が少なくて済みます。

70Bが大きく遅くなった理由

いちばん分かりやすかったのが llama3.3:70b（dense・Q4で約42GB）です。実測はわずか3.5 tok/s。原因は明確でした。42GBの本体が36GBのVRAMに収まらず、約23%がDDR4 RAM側に退避していました（Ollamaの表示で「23%/77% CPU/GPU」）。遅いDDR4が律速となり、全体が一桁の速度にとどまります。

gemma4:31b（21GB）はVRAMに収まり、100% GPUで24.5 tok/sでした。「収まれば速い／溢れると約7分の1」という崖が、同じPCの中ではっきり出ました。

なお、コンテキスト長を増やすとKVキャッシュがVRAMをさらに圧迫し、70Bは32k設定だと2.4 tok/sまで落ちました（4kでは3.5）。長文を扱うほど不利です。

MoEの“限界突破”：120Bが70Bより速い

面白いのが gpt-oss:120b（MoE・活性5.1B・69GB）です。サイズは70Bより大きく、しかも過半（51%）がRAMに溢れているのに、生成は17.6 tok/s＝70B denseの約5倍でした。

理由は活性パラメータです。120Bでも毎トークン読むのは活性5.1Bだけ。70B denseが毎回70Bすべてを読むのに対し、120Bは読む量が桁違いに少なくて済みます。そのためRAMに溢れても速いまま走れます。「総量が大きくてもVRAMに入りきらなくても、活性が小さいMoEなら実用速度が出る」——これが大型モデルをローカルで動かす鍵でした。

235Bへの限界チャレンジ

最後に、総パラメータ最大の Qwen3-235B-A22B（Q2量子化・約85GB）に挑みました。このPCはVRAM36GB＋RAM62GB＝合計98GBなので、Q2に圧縮すれば理論上ギリギリ載ります。

実は、動かすまでが大変でした。

ollamaは分割GGUF（235B Q2は2ファイル構成）を直接読めず、ローカル指定でも先頭ファイルだけでは連結できませんでした。別の実行環境（llama-cpp-pythonのCUDA版）はこのCPU（Zen2）で命令セットが合わず起動時にクラッシュ。最終的に、llama.cppのツールをソースからビルドして2ファイルを1つにマージし、ollamaに取り込んで動かしました。

結果は 生成 約3.9 tok/s。ロードに97秒、メモリは合計119GB分が常駐し、71%がRAM/CPU側、29%だけがVRAMという分担でした。出力は日本語として概ね成立し、連立方程式も正しく立式できましたが、Q2まで圧縮したぶん、ごく稀に文字の崩れも見られました。

活性22Bなのになぜ遅い？

「MoEで活性22Bなら速いのでは？」と思うかもしれませんが、2つの不利が重なりました。

ひとつは、活性22Bは“小さくない”こと。gpt-ossの活性5.1Bの約4倍あり、1トークンで読む・計算する量も約4倍です。単純計算ならgpt-ossの17.6 tok/sの約4分の1＝4.4 tok/s前後で、実測の3.9とおおむね一致します。もうひとつは、その大半（71%）が遅いDDR4側でCPU処理されること。この2つが重なって、総量最大の235Bが70B dense並みの速度まで落ちました。

235Bが本質的に遅いのではなく、このPCのVRAM36GB＋遅いDDR4という制約で遅くなっています。もし235Bが全部、速い大容量メモリ（256〜512GBのユニファイドメモリ等）に載れば、活性22Bでももっと速く動くはずです。ここに、大容量・高帯域の一体型メモリ機（Mac Studioや大容量ミニPC）の存在意義があります。大容量メモリ機の比較は大容量メモリPC比較の記事にまとめています。

賢さはどうだったか

今回の小問題（連立方程式・論理・コード・ハルシネーション罠・指示追従）では、5モデルとも基本タスクは概ね正答でした。連立方程式はいずれも正しく立式し、「実在しないものを選べ（月面都市）」の罠も全モデルが正解、JSON出力の指示にも素直に従いました。基本的な用途では、サイズより“ちゃんと答えるか”の差は小さい印象です。235BはQ2圧縮の影響でごく稀に崩れがあり、量子化を攻めるほど品質は落ちる点は意識しておきたいところです。

結論：どのサイズが実用か

このPC（VRAM36GB＋RAM62GB）での実感をまとめます。

• いちばん快適なのは、VRAMに収まる小さな活性のMoE（qwen3.6:35b-a3b＝95.5 tok/s）や中型dense（gemma4:31b＝24.5 tok/s）。日常使いはこの帯が現実解。
• 大型でも、活性の小さいMoE（gpt-oss:120b＝17.6 tok/s）はVRAMから溢れても実用速度。知識量と速度の両取りができる“おいしい”帯。
• 70B denseや235Bは、VRAMに収まらず遅いRAMに大量退避するため一桁の速度。動くが常用は厳しい。これらを速く使うには、VRAMを増やす（24GB×2など）か、大容量・高帯域の一体型メモリ機が必要。

ローカルLLMは「大きいほど良い」ではなく、自分のVRAMに“活性が収まる”モデルを選ぶのが、実用への近道でした。

検証に使用した機材

本記事の測定はこのPCで行いました。価格・在庫は変動するため、購入前に最新情報をご確認ください。

• NVIDIA RTX 3090（VRAM 24GB・中古実勢 約13〜18万円）：VRAMに収まる中型モデルを快適に動かす中核
• NVIDIA RTX 3060（VRAM 12GB）：補助・小型モデル用
• DDR4 メモリ（64GB）：VRAMに収まらない大型を“動かすだけ”なら容量が効く（ただし速度は出にくい）
• 大型LLMを1台で動かす大容量メモリPCの選択肢は 大容量メモリPC比較の記事 を参照