前提 — このPCで何がどこまで動くか

実測したハードウェア構成

結論としての実行可能ライン

VRAM 4GB は「小型モデルなら完全にGPUに載る／中型モデルは載らない」の境目にあたる。 4bit量子化での目安は次のとおり。

実行ソフトウェアの候補と比較

ローカルでLLMを走らせる手段は大きく4系統ある。本PCの制約（VRAM 4GB・Windows・単一ユーザー）で現実的なものを並べる。

候補A — llama.cpp（llama-server / llama-cli）

GGUF形式の量子化モデルを実行するC++実装。GPUに載りきらない分をCPUに逃がす「部分オフロード」を層単位で制御できる。 公式リリースに Windows 向け CUDA ビルド済みバイナリがあり、コンパイルは不要。

• 利点層数（-ngl）・KVキャッシュ量子化・コンテキスト長を細かく指定でき、4GBという厳しい枠に対して調整の余地が最も大きい
• 利点OpenAI互換のHTTP APIサーバと簡易WebUIが同梱される。他ツールからの接続先として使い回せる
• 利点zipを展開するだけで、レジストリもサービスも汚さない。プロジェクトフォルダ内で完結する
• 欠点モデルのダウンロードは自前。GGUFファイルを手で取得して配置する
• 欠点オプションが多く、初回は起動コマンドを組み立てる手間がある

候補B — Ollama 評価済み・不採用

内部で llama.cpp を使いつつ、モデル取得・常駐サーバ・APIを一体化したツール。ollama run qwen3:4b の一行で動き出す。 本PCでは一度導入したうえで、LM Studio に置き換える判断が既に下されている。

• 利点導入と運用が最も簡単。モデル管理も ollama pull で完結する
• 利点対応クライアントが多く、外部ツールから繋ぐ相手として最も普及している
• 欠点オフロード層数やKVキャッシュの調整が抽象化されており、4GBの枠を詰めきる用途では手が届きにくい
• 欠点常駐サービスとして入り、モデルの保存先も既定ではユーザープロファイル配下になる
• 実績過去に導入したがアンインストール済み。同じ理由で再導入しても状況は変わらない

候補C — LM Studio 導入済み・使用実績あり

GUIアプリ。モデル検索・ダウンロード・チャット・ローカルAPIサーバまで画面上で完結する。 本PCでは Claude Code から LM Studio のローカルAPIに問い合わせる形で使った実績があり、外部ツールとの接続まで確認できている。

• 利点既に入っているので追加コストがゼロ。GPUオフロード量をスライダーで動かして即座に効果を見られる
• 利点モデル比較の「試着室」として優秀。どのモデルが日本語で使えるかを短時間で判定できる
• 利点OpenAI互換APIサーバとしての実運用が確認済み。同じ接続方式が llama.cpp にもそのまま通じる
• 欠点GUI前提でありスクリプトからの再現性が低い。設定の差分を文書に残しにくい
• 欠点クローズドソースで、モデル保存先もアプリ管理下にある

候補D — vLLM / TGI / TensorRT-LLM

サーバ用途の高スループット推論エンジン。

• 不採用いずれも非量子化または高精度量子化の重みをVRAMに全展開する設計で、最低でも 12〜24GB クラスのGPUを想定している
• 不採用Windows ネイティブ対応が弱く、WSL2 経由になると VRAM がさらに目減りする

比較表

選択 — llama.cpp を主軸にする

採用案

llama.cpp を主軸に置く理由

1. 制約が厳しいほど、細かい制御が効く

4GBという枠では、7〜8Bモデルを「載る範囲だけGPUに置く」運用が現実的な選択肢になる。 llama.cpp は -ngl（GPUに載せる層数）を整数で指定でき、KVキャッシュ自体も量子化して容量を空けられる。 GUIのスライダーや自動判定に任せると、ここで数tok/sを取りこぼす。

2. 設定が一行のコマンドとして残る

起動オプションをそのまま .cmd ファイルに書けるので、「どの設定で何 tok/s 出たか」を文書と対応づけて記録できる。 第7章の検証計画は、この再現性があって初めて成立する。

3. プロジェクトフォルダで完結する

バイナリ・モデル・起動スクリプトをすべてこのプロジェクト配下に置ける。 不要になったらフォルダごと消せばよく、システムに残るものがない。

想定するフォルダ構成

20260824-local-llm-llama-cp/
├─ bin/
│   └─ llama.cpp/          … 公式配布のCUDAビルド一式を展開
├─ tools/50_run/
│   ├─ run-server.cmd       … llama-server の起動
│   └─ bench.cmd            … llama-bench による速度計測
├─ notes/10_plan/           … 本文書
├─ etc/                     … 補助スクリプト（git管理外）
└─ tmp/                     … 一時ファイル（git管理外）

C:\AI-models\                … GGUF の実体（LM Studio と共用・移動しない）

モデルは既に C:\AI-models にあり、LM Studio と共用する。 プロジェクト配下に複製せず、起動スクリプトから絶対パスで参照する（第7章 Step 2）。

入手方法 — 配布バイナリか自前コンパイルか

llama.cpp を使うと決めたうえで、実行ファイルをどう手に入れるかにさらに選択がある。 公式が Windows 向けのビルド済みバイナリを配布しているので、コンパイルは必須ではない。

準備コストの比較

案A — 公式配布のビルド済みバイナリ

• 利点追加インストールが一切いらない。GPUドライバだけで動く
• 利点zipを展開するだけなので、失敗しても消せば元に戻る
• 利点更新はzipを差し替えるだけ。llama.cpp は更新が速いので、この差し替えの軽さは効く
• 欠点リリースタグの時点のコードしか使えない。ごく新しいモデルへの対応は数日〜数週間待つことがある
• 欠点コードに手を入れられない

案B — 自分でコンパイルする（CUDAバックエンド）

必要な準備（本PCの現状を実測）

導入コマンド（順序が重要）

REM 1) まず CMake
winget install Kitware.CMake

REM 2) 次に Visual Studio Build Tools（C++ワークロードを明示的に選ぶ）
winget install Microsoft.VisualStudio.2022.BuildTools

REM 3) 最後に CUDA Toolkit
winget install Nvidia.CUDA

Build Tools は winget で入れた後、Visual Studio Installer を開いて 「C++によるデスクトップ開発」ワークロードにチェックが入っているか確認する。 既定では最小構成しか入らず、MSVCコンパイラ本体が欠けることがある。

ビルド手順

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86
cmake --build build --config Release -j 4

成果物は build\bin\Release\ に出る。所要時間は本PCの4コアで 30〜90分を見込む。 CUDAカーネルのコンパイルが支配的で、CPUが遅いほど伸びる。

利点と欠点

• 利点最新コミットをその日のうちに使える。新しいモデル形式への対応が入った直後に試せる
• 利点自分のGPU向けだけをビルドするので、バイナリが小さく起動も軽い
• 利点コードに手を入れられる。ログを足す、パラメータを変えるといった実験ができる
• 欠点準備に約 13 GB のインストールと、初回1〜2時間の作業が要る
• 欠点llama.cpp を更新するたびに再ビルドが要る。zip差し替えの数十倍の手間になる
• 欠点VS・CUDA・CMakeの版の組み合わせで失敗しうる。ビルドエラーの切り分けが本題から逸れる
• 欠点速くならない。案Aと同じカーネルが動くだけで、推論速度に差は出ない

案C — 自分でコンパイルする（Vulkanバックエンド）

CUDAの代わりに Vulkan を使うビルド。-DGGML_VULKAN=ON を指定する。 CUDA Toolkit（5GB）が不要になり、代わりに Vulkan SDK（約 1GB）だけで済む。

• 利点準備が案Bより軽い。内蔵GPU（Iris Xe）でも動かせる
• 欠点NVIDIA GPU では CUDA バックエンドのほうが概ね速い。本PCでは CUDA が使える以上、選ぶ理由が薄い

Vulkan は「NVIDIAが使えない環境に持っていく」場合の逃げ道として覚えておく位置づけにとどめる。

採用案

案Bに切り替えるトリガー

1. 使いたいモデルの対応が最新コミットにしか入っておらず、リリースを待てない
   未発動b10612 で gemma-4 / Qwen3.5 / Ministral-3 / Nemotron-3 すべて読み込めた
2. 配布バイナリが本PCで起動しない、または特定の量子化で不正な出力が出る
   未発動CUDA 12.4 版がそのまま動作
3. llama.cpp のコード自体に手を入れて試したいことが出てきた
4. ビルド環境が他の用途（C++開発）でも必要になり、13GBが本計画だけの負担でなくなった

実測の結果、1・2 はいずれも発動しなかった。当初は手持ちに新しい系列が多いことから アーキテクチャ未対応を懸念していたが、リリースの更新が追いついていた。 案Bは当面必要ない。

モデルの選択 — 手持ち資産の棚卸し

モデルは新規に選ぶのではなく、既に C:\AI-models にあるものから選ぶ。 まずサイズ帯ごとの性格を押さえ、そのうえで手持ちを仕分ける。

サイズ帯ごとの性格

手持ちのモデル資産

C:\AI-models に LM Studio 経由で取得済みのGGUFが 26ファイル・約 86.0 GB ある （当初 30ファイル・98.5 GB あったが、後述のとおり重複分を整理した）。 新規ダウンロードを検討する前に、この中から選べるかを確認する。以下は本体モデル（mmproj を除く）の一覧。

「動くもの／動かないもの」の切り分け

手持ちに動かないモデルがあるとのことなので、原因を3つに分けて判別する。対処が全く違う。

原因1 — メモリ超過（サイズで判別できる）

上表で 大半がCPU 以下に該当するもの。 LM Studio が GPU に全部載せようとして失敗するか、載っても極端に遅い。 llama.cpp で -ngl を明示的に下げれば「動く」状態には持ち込める（速度は別問題）。 サイズと VRAM の引き算で事前に予測でき、原因としては最も分かりやすい。

原因2 — ランタイムがアーキテクチャに未対応

手持ちには gemma-4・Qwen3.5・Ministral-3・GLM-4.6V・Nemotron-3 といった新しい系列が多い。 GGUF は同じ拡張子でも中のアーキテクチャ識別子が違い、ランタイムが未対応だと 読み込み時点で「unknown model architecture」等のエラーで即座に失敗する。 サイズが小さくても落ちるのが特徴で、原因1と区別できる。

• 対処はランタイムの更新のみ。設定をいじっても直らない
• LM Studio ならランタイム更新、llama.cpp なら新しいリリースへの差し替え
• リリースにまだ入っていない場合、第4章の案B（自前コンパイル）に切り替える実際の理由になる

原因3 — mmproj（視覚アダプタ）の扱い

mmproj-*.gguf は画像入力用の投影器で、単体では動かない。本体モデルとペアで指定して初めて機能する。 手持ちでは gemma-3-4b / gemma-4 系 / GLM-4.6V / Ministral-3 / Qwen3.5 に付属している。

• テキスト用途ならmmproj を無視して本体だけ読み込めばよい。それで動くならモデル自体は健全
• llama.cpp で画像も使う場合は --mmproj で明示的に指定する
• mmproj も VRAM を消費する。gemma-3-4b の 0.79 GB は本体 2.32 GB に対して無視できない

採用案

初期構築に新規ダウンロードは要らない。第8章の Step 2 は「取得」ではなく「手持ちからの選定」になる。 そのうえで、最新の量子化形式とMoEには手持ちに無い伸びしろがあるため、第7章で別途検討する。

重複の整理 2026-08-25 実施済み

棚卸しの過程で、同じモデルが gemma\ と lmstudio-community\ の2箇所に置かれているものが見つかった。

同一性の検証

削除の前に、本当に同じものかを確かめた。結論から言うと、バイト単位では同一ではなかった。

最初に異なるバイトは先頭から 244 バイト目、つまり GGUF のメタデータ領域にあった。中身を読むと差は変換元リポジトリ名だけだった。

gemma\ 側            : general.name     = "Gg Hf Qat_Gemma 4 12B It Qat Q4_0 Unquantized"
                       general.basename = "gg-hf-qat_gemma-4"
lmstudio-community\ 側: general.name     = "Google_Gemma 4 12B It Qat Q4_0 Unquantized"
                       general.basename = "google_gemma-4"

テンソルデータ側は、末尾から 5GB / 2GB / 0.5GB の3地点で 8MB ずつハッシュを取って照合し、すべて一致した。 同じ量子化結果を、変換元リポジトリ名だけ違う形で2回取得していたことになる。

LM Studio 側の見え方

lms ls で確認すると、LM Studio は両方を別モデルとして認識していた。

gemma/gemma-4-12b-it-qat            12B    gemma4    7.15 GB
google/gemma-4-12b-qat (1 variant)  12B    gemma4    7.15 GB   ← lmstudio-community\ 側
gemma/gemma-4-e4b-it                7.5B   gemma4    6.33 GB
google/gemma-4-e4b (1 variant)      7.5B   gemma4    6.33 GB   ← lmstudio-community\ 側

同じモデルが一覧に2回並ぶ状態で、片方を消しても残った方は認識され続ける関係にあった。

実施した内容と結果

lmstudio-community\ 側の4ファイルを削除し、空になったフォルダも併せて片付けた。

削除後、LM Studio の一覧では残った側の修飾が外れて gemma-4-12b-it-qat / gemma-4-e4b-it と表示されるようになった。 同名の競合が解消されたためで、モデル自体は引き続き両方とも使える。

量子化・VRAM配分・コンテキスト長

量子化レベルの選び方

実測データ — どこで品質が落ちるか

Llama-3.1-8B-Instruct に対して13種類の量子化を横並びで評価した結果がある。 下表の「ベンチ平均」は GSM8K・HellaSwag・IFEval・MMLU・TruthfulQA の非加重平均。

読み取れること

• Q4 までは誤差の範囲。Q8 から Q4_K_S まで、ベンチ平均の落ちは1%未満に収まる。ここを削らない理由がない
• 3bit帯は「S か M か」で別物。Q3_K_M は −2.02% で踏みとどまるのに、Q3_K_S は −5.73% で崖から落ちる。論文も「実装の詳細が『3bit』という見出しと同等以上に効く」と述べている
• 壊れ方が均一ではない。GSM8K（数学推論）は Q3_K_S で 77.63 → 68.31 と 9.3ポイント落ちる一方、HellaSwag（常識）は基準から1ポイント程度しか動かない

Q2_K は上の評価には含まれていないが、別途 7B モデルで測った結果では perplexity の悪化が Q4_K_M の約16倍（+0.8698 対 +0.0535）。 3B クラスでは特定タスクが 0.0% になる報告もある。

I-quant（imatrix）という選択肢

IQ で始まる形式は、代表的なテキストで各重みの重要度を測った行列（imatrix）を使い、 効きの大きい重みにビットを厚く配る。同じビット数でも K-quant より品質が高くなる。

効き目が最も大きいのは Q2・Q3 の低ビット帯。均一な量子化が破綻し始める領域ほど、重要度による配分が生きる。 逆に言えば Q4 以上ではあまり差がつかない。

1bit帯は選択肢に入らない

Q1_K のような K-quant は存在しない。1bit帯にあるのは I-quant と三値量子化で、いずれも本PCでは使い道がない。

TQ系は通常のモデルを変換しても意味がなく、IQ1系を 4B や 9B に適用すれば完全に崩壊する。 本計画では対象外

4GB をどう配分するか

コンテキスト長の設定

KVキャッシュはコンテキスト長に比例してVRAMを食う。長さを倍にすればキャッシュも倍になる。 本PCでは以下を出発点とする。

KVキャッシュ量子化という手

llama.cpp は KVキャッシュ自体を8bit量子化できる（--cache-type-k q8_0 --cache-type-v q8_0）。 キャッシュ容量がおよそ半分になるので、その分を重みのオフロードに回せる。 8Bモデルを載せる場合はこれを併用する前提で層数を決める。

新規ダウンロードの検討 — 最新量子化とMoE

第5章のとおり手持ちだけでも始められるが、手持ちの大半は Q4_K_M の密モデルに偏っている。 量子化形式とMoEアーキテクチャの2つの軸には、4GB VRAM という制約に対して効く選択肢が残っている。 容量は 385 GB 空いているので、取得コスト自体は低い。

軸1 — 量子化形式

形式ごとの品質・サイズの関係は第6章にまとめた。新規取得の観点で効くのは IQ4_XS で、 Q4_K_M と同等品質のまま約1割小さく、9Bクラスを全層GPUに近づけられる。 ここでは手持ちにある特殊な形式2つと、誤解しやすい QAT の位置づけを整理する。

QAT はサイズを減らす技術ではない

手持ちの gemma-4-12B-it-QAT-Q4_0（6.50 GB）を見て 「QAT なら大きくても VRAM に載るのでは」と考えたくなるが、これは成り立たない。

• QAT（Quantization Aware Training）は学習側の手法で、量子化されることを織り込んで再学習する
• 適用先は既存の Q4_0 形式そのもの。ファイルサイズは通常の Q4_0 と変わらない
• 得られるのは「同じサイズでより高い品質」であって、サイズ削減ではない
• むしろ QAT の Q4_K_M 版は非QAT版より大きいという報告もある（9.5 GB 対 7.6 GB）

そして gemma-4-12B-it-QAT は密モデルなので、次節の MoE のようなエキスパート退避も効かない。 毎トークン全パラメータが必要で、6.50 GB を 4 GB に収める方法がない。 4GB VRAM では動かない

手持ちにある特殊な形式

軸2 — MoE（Mixture of Experts）

MoE は総パラメータのうち一部の expert だけを毎トークン使う構造で、計算量は active パラメータで決まる。 密モデルなら 30B は本PCで論外だが、active 3B の MoE なら計算量は 4B クラスに近い。

制約はメモリ側にある。使わない expert も含めて全体を保持する必要があるため、 RAM 16GB がそのまま上限になる。ここで効くのが llama.cpp の --n-cpu-moe だ。

何がGPUに残り、何がCPUに行くのか

考え方は「毎トークン必ず使う部分を、いちばん速いハードウェアに置く」。

これが密モデルで成立しない理由もはっきりしている。密モデルは100%のパラメータが常時必要で、 CPUに逃がした分がそのまま毎トークンの転送コストになる。MoE では逃がした重みの大半が毎回は触られない。

値の決め方

--n-cpu-moe N は routed expert を CPU に戻す層数を指定する。 注意点として、層は最上位（いちばん番号の大きい層）から数える。

Nを大きくするほど VRAM 使用は減るが、CPU側の負担が増えて遅くなる。 参考として、6GB VRAM の環境で 35B-A3B クラスを約 30 tok/s で動かした報告がある。

MoE候補

軸3 — MoE でだけ低ビット量子化が意味を持つ

第6章では「密モデルで Q2 まで下げるのは損な取引」と結論づけた。 MoE はこの結論が当てはまらない、唯一の例外になる。

なぜ MoE は低ビットに強いのか

• パラメータの大半がエキスパートに集中している。圧縮対象をエキスパートに絞り、それ以外を高い精度で残せば、誤差の蓄積を抑えられる
• エキスパートごとに使用頻度と重要度の偏りが大きく、imatrix や層別の混合精度が効きやすい
• 研究でも MoE は低ビット量子化に対して頑健とされ、エキスパート単位の感度分析に基づく手法が成果を出している

実例として、MoE向けの混合精度量子化は 21.3 GB で perplexity 6.552 / HellaSwag 83.5% を出しており、 45.3 GB の 8bit 版（6.536 / 82.5%）とほぼ同等の品質を半分以下のサイズで達成している。

本PCにとっての意味

つまり「密モデルでは切り捨てる 2bit 帯が、MoE では 30B クラスに手を届かせる手段になる」という構図になっている。 ただし 11 GB を RAM 16GB に載せると余裕はほとんど残らない。

軸4 — Gemma E2B/E4B の Per-Layer Embeddings

手持ちの gemma-4-E2B-it（3.19 GB）と gemma-4-E4B-it（4.97 GB）は、 MoE とは別の仕組みで「サイズの割に軽い」可能性がある系列。

名前の E は effective（実効）の意味。PLE のテーブルは大きいがルックアップ専用で、 行列積には参加しない。設計上は低速なメモリ側に置ける性質を持つ。

手持ちの gpt-oss-20b は評価し直す

第5章の表では総サイズだけを見て 実行困難 と分類したが、 これは MoE であることを考慮していない判定だった。 active 3.6B なので、--n-cpu-moe で expert をCPUに逃がせば、生成速度は 20B の密モデルとは別物になる。 新規ダウンロードを検討する前に、まずこれを実測する。

採用案

優先度1は追加取得ゼロで済むので、これを先に回してから優先度2以降の要否を決める。 MoEが期待外れなら優先度3は不要になり、13 GB の取得を省ける。

取得時の置き場

LM Studio の検索から落とせば C:\AI-models 配下の既存の系列フォルダに入り、 llama.cpp からも同じ絶対パスで参照できる。Hugging Face から直接取得する場合も、 <配布元>\<モデル名>-GGUF\ という既存の規約に合わせて置く。

導入手順（ステップ計画）

各ステップは独立して確認できる単位に分けている。1つ終えるごとに動作を確かめてから次へ進む。

Step 1 — llama.cpp のバイナリを配置

第4章で採用した案A（配布バイナリ）に沿って進める。公式リリースページから Windows 向けの CUDA ビルド一式を取得する。必要なのは2つのzip。

• llama-b<番号>-bin-win-cuda-<版>-x64.zip … 本体
• cudart-llama-bin-win-cuda-<版>-x64.zip … CUDAランタイムDLL

両方を bin\llama.cpp\ の同じ階層に展開する。DLLが本体と別フォルダにあると起動時に読み込めない。

bin\llama.cpp\
  llama-server.exe
  llama-cli.exe
  llama-bench.exe
  ggml-cuda.dll
  cudart64_*.dll   ← cudart 側のzipから
  ...

確認

.\bin\llama.cpp\llama-server.exe --version

バージョンが表示され、ログに CUDA デバイスとして RTX 3050 Ti が出れば成功。

Step 2 — 手持ちモデルの参照方法を決める

第5章のとおり新規ダウンロードは不要で、C:\AI-models の Qwen3-4B-Instruct-2507 をそのまま使う。 ただし 98.5 GB あるモデル群をプロジェクト配下にコピーするのは無駄なので、参照方法を選ぶ。

本計画では絶対パス指定で進める。プロジェクト配下に models\ は作らない。

Step 3 — 起動スクリプトを用意

tools\50_run\run-server.cmd として、以下を出発点にする。

@echo off
"%~dp0..\..\bin\llama.cpp\llama-server.exe" ^
  -m "C:\AI-models\qwen\Qwen3-4B-Instruct-2507-GGUF\Qwen3-4B-Instruct-2507-Q4_K_M.gguf" ^
  -ngl 99 ^
  -c 8192 ^
  --host 127.0.0.1 ^
  --port 11434
pause

確認

起動後、ブラウザで http://127.0.0.1:11434 を開くと同梱のチャットUIが出る。日本語で数往復して応答を確認する。

Step 4 — 大きいモデルの部分オフロード設定を詰める

第二候補の Qwen3.5-9B（5.24 GB）を指定し、-ngl を変えながら「VRAMに収まる最大の層数」を探す。 起動ログに実際のVRAM使用量が出るので、それと nvidia-smi を突き合わせる。

-ngl 18 → 起動する / 速度は？
-ngl 21 → 起動する / 速度は？
-ngl 24 → メモリ不足で落ちる → 21 が上限

KVキャッシュ量子化（--cache-type-k q8_0 --cache-type-v q8_0）を足すと、この上限が数層伸びる。

Step 5 — Claude Code からの接続に切り替える

llama-server は OpenAI 互換のエンドポイントに加えて、Anthropic 形式の http://127.0.0.1:11434/v1/messages にも応答する。 Claude Code は Anthropic 形式で話すため、変換の層を挟まず、環境変数で接続先を向けるだけで繋がる。

• サーバは Claude Code 向けの設定で起動する（tools\50_run\run-server-cc.cmd）
• Claude Code は root の cc1.cmd から起動する。ANTHROPIC_BASE_URL を http://127.0.0.1:11434 に向け、モデル名はサーバの --alias に合わせる

コンテキストは 65536 が要る

Claude Code は最初の要求だけで約 63,000 トークンある（システムプロンプトとツール定義）。 常用の -c 8192 では「request (63484 tokens) exceeds the available context size (8192 tokens)」 （要求が使えるコンテキストを超えている）で拒否される。

65536 の KV キャッシュは VRAM 4GB に載らないため、RAM 側に置く（-nkvo）。 q8_0 に量子化し、スロットは1つ（-np 1）にする。サーバの RAM 使用は約 7.6 GB。

2回目は、共通部分の KV キャッシュが再利用され、差分だけを読み込む。 サーバを起動したままにしておけば、待たされるのは最初の1回だけになる。

LM Studio と llama.cpp のサーバはポートを分けて同時に立てられるので、 接続先を行き来させながら応答を比較でき、切り替えに失敗しても元に戻せる。

その後の試験で分かったこと（2026-09-30）

上の 63,000 トークンのうち、利用者の共通ルールだけで約 41,000 トークンあった。 ホームを空のフォルダに替えて読ませないと約 20,000 トークンに減り、思考も切ると、20GB 以下の 20 本中 15 本がファイルの読み書きに合格した。 いまの run-server-cc.cmd と cc1.cmd は、この設定（gemma-4-E4B・--reasoning off・ホーム W:\temp\cc1-home）で作り直してある。 詳細は ローカルLLM で AI エージェントを使う — 試験結果、使い方は 使う・試す手順。

Step 6 — MoEモデル（gpt-oss-20b）を試す

第7章の優先度1にあたる。手持ちの gpt-oss-20b を、expert 層だけCPUに逃がす指定で起動する。

llama-server.exe ^
  -m "C:\AI-models\OpenAI\gpt-oss-20b-GGUF\gpt-oss-20b-MXFP4.gguf" ^
  -ngl 99 ^
  --n-cpu-moe 24 ^
  -c 4096 ^
  --host 127.0.0.1 --port 8080

本PCの VRAM 4GB ではまず全層のエキスパートをCPUに置くところから始め、 VRAMが余っていれば値を下げていく。小さいほどエキスパートがGPUに残って速くなるが、VRAMを超えると落ちる。

判断

• 10 tok/s 以上MoEに見込みあり。第7章の優先度3（Qwen3-30B-A3B の IQ2_M）へ進む
• 3〜10 tok/s用途を限れば使える。優先度3の取得は保留し、優先度2（IQ4_XS）を先に試す
• 3 tok/s 未満RAM が足りていない。MoE路線は打ち切り、4Bクラスに絞る

実行中は nvidia-smi と併せてタスクマネージャのメモリ使用量も見る。 コミット済みメモリが物理RAMを超えていれば、遅さの原因はCPU性能ではなくディスク読みにある。

Step 7 — gemma-4-E4B-it で PLE の効果を測る

第7章の優先度1'。手持ちの gemma-4-E4B-it（4.97 GB）は total 8B / effective 4.5B で、 差分の Per-Layer Embeddings がオフロードされるかどうかで結果が変わる。これも追加取得ゼロで判定できる。

llama-server.exe ^
  -m "C:\AI-models\gemma\gemma-4-E4B-it-GGUF\gemma-4-E4B-it-Q4_K_M.gguf" ^
  -ngl 99 ^
  -c 4096 ^
  --host 127.0.0.1 --port 8080

まず -ngl 99 で試し、VRAM不足で落ちるなら Step 4 と同じ要領で上限を探す。

判断

• 20 tok/s 前後effective 4.5B 相当で動いている。PLE が効いており、4Bクラスと同等の枠で扱える
• 6〜10 tok/s8B 相当の素直な部分オフロード。Qwen3.5-9B と同じ土俵で比較する

比較の基準は Step 3 の Qwen3-4B（25〜40 tok/s）と Step 4 の Qwen3.5-9B。 この2つに挟んで、E4B がどちら側に着地するかを見る。

検証計画と評価基準

測る項目

比較する組み合わせ

1〜7 は手持ちのモデルだけで実施でき、追加取得を伴わない。8・9 は第7章の優先度2・3を実行した場合のみ。

6・9 は RAM が律速になるため、他のアプリを閉じた状態で測る。 それ以外はVRAM側の勝負なので、画面表示を内蔵GPUに寄せた状態に揃える。

質問セット（固定）

モデル間の比較を成立させるため、毎回同じ質問を同じ順で投げる。

1. 日本語での要約 — 400字程度の文章を3行にまとめさせる
2. 日本語での説明 — 技術用語をひとつ、初心者向けに説明させる
3. 指示追従 — 「箇条書き5項目、各20字以内」のような形式制約を守れるか
4. 簡単なコード生成 — PowerShellで指定した処理を書かせる
5. 長文の読解 — 2000字程度を貼り、特定箇所について質問する

結果を受けての判断

この計画で決めていないこと

• 解決重複ファイル 12.6 GB の整理 → 2026-08-25 に実施（第5章）
• 解決新規モデルの取得（第7章）→ 実測の結果、不要と判断（第10章）
• 解決自前コンパイル（第4章の案B）→ トリガー1・2とも発動せず、当面不要
• 解決速度・品質の実測 → 第10章。用途による使い分けまで確定
• 未定常用する用途。基盤が整ったので、実際に使いながら決める段階に入った
• 未定モデルの更新方針。新しいモデルが出るたびに追随するか、固定するか
• 解決Claude Code からの接続切り替え → 変換の層なしで繋がることを確かめ、スクリプトにした（第8章 Step 5）

実測結果 — 2026-08-25

第8章の Step 1〜3 を実施し、第9章の検証を llama-bench で測った。 使用ビルドは b10612（CUDA 12.4 / Windows x64 の配布バイナリ）。

この章の数値は、RAM 16GB（15.8 GB）で、画面表示が VRAM を 808 MiB 使っていた状態で測ったもの。 32GB への増設と画面表示を内蔵GPU に任せたあとの測り直しは、章末の「32GB での再測定」に追記した。

環境の実測値

生成速度（tg）の比較

測定結果の一覧

pp512・tg の単位は tok/s。tg は No1・No3・No7 が tg128、それ以外は tg64。

分かったこと

1. 4Bクラスは 56 tok/s で頭打ち — 系列によらない

Qwen3-4B（56.49）と gemma-3-4b（56.25）が誤差の範囲で一致した。 モデル固有の性質ではなく、このGPUのメモリ帯域が決めている上限と考えてよい。 計画時の予測は 25〜40 tok/s だったので、実測が予測を4割上回った。

2. E4B の PLE は本当に分離される 仮説が的中

第7章の軸4で「llama.cpp が PLE をオフロードするか未確認」としていた点に、明確な答えが出た。

load_tensors: offloading 41 repeating layers to GPU
load_tensors:   CPU_Mapped model buffer size =  2730.00 MiB   ← PLE テーブル
load_tensors:        CUDA0 model buffer size =  2868.05 MiB   ← 計算に使う重み

ファイルは 4.95 GiB あるが、GPUに載るのは 2868 MiB だけ。残り 2730 MiB の PLE は CPU 側に置かれる。 その結果 7.52B のモデルが 45 tok/s で動く。9Bクラスの 8 tok/s とは桁が違う。

KVキャッシュも 14 MiB しか使わない。shared_kv_layers = 18 と sliding window attention の組み合わせによるもので、コンテキストを伸ばしても VRAM を圧迫しにくい。

3. -ngl は「越えると崩れる」— 徐々に遅くなるのではない

Qwen3.5-9B で -ngl を振ると、20〜24 で 8 tok/s 前後を保ち、28 で 2.53 に落ちた。 -ngl 99 では 1.55 まで下がる。

4. MoE は動いたが、RAM が律速で伸びない（RAM 16GB 時）

gpt-oss-20b は --n-cpu-moe で確かに動き、密モデルの20Bとしてはあり得ない速度が出た。 ただし最良でも 5.89 tok/s、しかも測定のばらつきが ±2.0 と大きい。

• 11.27 GiB を RAM 15.8 GB に載せるため、OS と合わせて常に逼迫している
• -ncmoe を下げるとGPU側が増えて速くなるが、14 まで下げると VRAM 超過で崩れる
• 最適点は 18 付近。上下どちらに動かしても遅くなる

第7章の判断基準では「3〜10 tok/s：用途を限れば使える。優先度3の取得は保留」に該当する。

5. コンテキストは 8192 が上限 — 16384 は崩れる（画面表示が VRAM を使っていた時）

Qwen3-4B で会話の深さを変えて測ると、速度は素直には落ちず、ある点で崩壊した。

計画では「余裕があれば 16384 まで伸ばす」としていたが、その余裕は無かった。 モデル重み 2.32 GiB に対して空きが 3287 MiB しかないため、 16k 分の KV キャッシュを置くと超過する。-c 8192 を上限として運用する。

サーバとしての動作確認

llama-server を起動し、OpenAI 互換エンドポイントに日本語で問い合わせた。

API 経由の 39.5 tok/s が llama-bench の 56.5 tok/s より低いのは、 HTTP のやり取りとプロンプト処理を含んだ実効値のため。体感速度としてはこちらが実態に近い。

品質評価 — 差が出るのは知識を問うときだけ

第9章の質問セット5問を、Qwen3-4B と gemma-4-E4B の両方に同じ条件で投げた。 当初は3問だけで「速度と品質が逆転する」と結論づけたが、 残る2問（要約・長文読解）を加えると差が出る場面はもっと限定的だった。

Q1 と Q5——文章が手元にある課題では、両者に差がつかなかった。 差が出たのは Q2 と Q4、いずれもモデル内部の知識に依存する設問である。

Q1「413字の文章をちょうど3行に要約」

計画書の本文から抜き出した 413 字を素材にした。両者とも3行という指示を守り、内容も素材に忠実だった。

• Qwen3-4B — 合格3.2 秒。素材の順に沿って要点を拾う
• gemma-4-E4B — 合格17.9 秒（うち思考 987 字）。 「制約 → 手段 → 理由」と論理の順に組み替えており、整理はこちらが上

質としては E4B がわずかに勝るが、5.6 倍の時間を払う差ではない。

Q2「量子化を初心者向けに150字で説明」

Q3「注意点を5項目・各20字以内」

• Qwen3-4B — 合格「メモリ確保／プロセス監視／エラーログ確認／エンジン選定／冷却環境確認」。項目数・字数とも指示どおり
• gemma-4-E4B — 未完思考が長く、max_tokens=400 では回答本体に到達しなかった

Q4「PowerShell で .gguf をサイズ降順に一覧」

• Qwen3-4B — 惜しい動作するが -Recurse が無く、「配下」という指定を満たしていない
• gemma-4-E4B — 正確-Recurse 付き。サイズをMB換算し、パスも表示する実用的な形

Q5「1970字の文章を読み、2点を答える」

第7章の本文から 1970 字を素材にし、その文章にしか書かれていない情報を2つ問うた。 事前知識では答えられない設問である。

1. --n-cpu-moe の層の数え方の注意点は何か（正解: 最上位の層から数える）
2. CPUオフロードが密モデルで成立せず MoE で成立する理由は何か

1970字の文脈を保持し、そこから正確に答える能力は 4B でも十分にあった。 第2章で「小型帯では日本語の破綻が少ない」と見込んだ点は、読解でも裏付けられた形になる。

E4B は reasoning モデルだった

E4B が遅かった理由は速度ではなく出力量にあった。応答は2つのフィールドに分かれて返る。

生成 570 トークンのうち大半が思考で、生成速度自体は 41.1 tok/s と速い。 それでも 13.9 秒かかるのは、答えにたどり着くまでに書く量が多いためで、 この思考が Q2 の正答と Q4 の -Recurse を生んでいる。

使い分けの結論

5問を通して見ると、分岐点は「対話か事実か」ではなく 「答えが渡した文章の中にあるか、モデルの中にあるか」だった。

実運用では「モデルに思い出させるのではなく、資料を渡す」形に寄せるほど 4B で足りることになる。 E4B が要るのは、渡す資料が用意できない場面に絞られる。

計画時の予測と実測の対比

結論と方針（RAM 16GB）

第7章の追加取得の判断

結局、追加ダウンロードは不要という結論になった。 手持ちの Qwen3-4B と gemma-4-E4B の2本で、速度側と品質側の両方が埋まっている。

32GB での再測定

RAM を 32GB に増設し、画面表示を内蔵GPU に任せたあとで、RAM と VRAM に左右されるものを測り直した。 ブラウザなどを閉じ、空き RAM 19.1 GB・VRAM 空き 3962 MiB の状態で、1つずつ順番に測っている。

結果

単位は tok/s（tg）。Qwen3-4B の基準と gemma-4-E4B は tg128、それ以外は tg64。「pp512」の行はプロンプトを読む速さ。

分かったこと

• GPU だけで動くものは変わらない。Qwen3-4B は全層が VRAM にあり、RAM を使わない
• gemma-4-E4B は、生成は変わらず、プロンプトを読む速さが 1.6 倍になった。CPU 側に置く PLE（2730 MiB）が生成を遅らせるほどではなかったことになる
• 重みの一部を CPU 側に置くものが大きく速くなった。Qwen3.5-9B は 1.8 倍、gpt-oss-20b は 3.2 倍。 1枚から2枚になってメモリの帯域が倍になったためと考えられる。gpt-oss-20b は、RAM の逼迫が解けた分もさらに上乗せされている
• 崩れる境目は動かない。Qwen3.5-9B は 24 と 28 の間、gpt-oss-20b は 18 と 14 の間で、上の測定と同じ。 VRAM が 675 MiB 増えても、層をもう1段 GPU に載せるには足りない
• KV キャッシュを q8_0 にすれば、コンテキスト 16384 が使える。上の測定では同じ設定で止まっていた。 画面表示を内蔵GPU に任せて空いた分で、KV キャッシュが VRAM に収まった
• gpt-oss-20b は第9章の合格ライン（15 tok/s）を超えた。上の測定では「用途限定」としていたが、対話にも使える速さになった
• Qwen3-30B-A3B（16.5 GB）も合格ラインを超えた。-ncmoe 40 で 16.6 tok/s（2 回測って 16.54・16.60）。39 以下は VRAM があふれて値が揺れ、7〜14 tok/s に落ちる。 文脈を 16384 トークン入れると、40 では VRAM があふれて 0.35 tok/s に落ちる。KV キャッシュの分だけ -ncmoe を 44 に上げれば 12.9 tok/s（48 でも 13.0 でほぼ同じ）
• Qwen3-30B-A3B を 65536 トークンで使うのは無理。KV を RAM に置く（-nkvo）と VRAM はあふれないが、注意の計算を CPU がするため深さ 16384 で 4.4 tok/s、65536 で 1.3 tok/s。cc1 と同じ使い方（65536・-nkvo）には向かない

結論と方針（RAM 32GB）

上の「結論と方針（RAM 16GB）」は RAM 16GB での測定に基づく。再測定の結果を受けて、次のとおり改める。 現在の構成（RAM 32GB・画面表示は内蔵GPU）では、こちらを正とする。

第7章の追加取得の判断（見直し）

コンテキストの上限は「8192」から「KV を q8_0 にすれば 16384」に改める。 Claude Code のように 6 万トークンを超える要求は、KV を RAM 側に置く -nkvo で扱う（第8章 Step 5）。