llama.cpp on RTX 3060 — ドキュメント索引

PVE ホスト + CT 9902 での llama.cpp 運用記録。

読む順

#	文書	内容
1	OPERATION.md	現在の実設定。まずこれを見る。
2	QUANT-TABLE.md	量子化の選び方（決定用サマリー）。どのモデルにするか迷ったら。
3	QUALITY-REPORT.md	クォント × 速度 × 品質の測定詳細（付録に統計・出典）
4	PLAN.md	当初の計画（2026-10-07 時点）
5	history/	調査の詳細ログ（時系列）

30秒サマリー

ホスト    PVE 9.2.21 / kernel 6.17.13-21-pve
GPU       RTX 3060 12GB / driver 615.71.09 (DKMS, ホストとCT で同一版)
CT 9902   Ubuntu 24.04 / llama.cpp b11437 / CUDA 12.0
モデル    Qwen3.6-35B-A3B-UD-IQ3_S.gguf (14.29 GB, SSD /opt/ssd)
性能      gen 40.1 t/s / 品質 89.0% (IQ3_S, v2 196 ケース)  [IQ4_NL なら 29.5 t/s / 95.2%]
          ロード 12〜15 秒 (SSD 配置後、HDD では 40〜130 秒)
_ctx_     96000 (agent 必須要件のため固定)

制約: /etc/llama-server.local は編集しない。 設定変更は必ず /etc/llama-server.tune（最終段オーバーレイ）経由。

把握すべき 3 点

1. GPU 消失事故はもう起きない 旧 580.173.02 は .run 展開物で DKMS 未登録だったため、カーネル更新のたびに CT 9902 の GPU が消えていた。615.71.09 に更新し DKMS 登録済み。 kernel 7.0 系は NVIDIA open module がビルドできないため 6.17.13-21-pve に固定。

2. 速度は VRAM 12 GB への「収まり」で決まる 量子化のビット幅ではない。モデルが 12 GB に収まらなければ、 超過分が CPU 側で帯域律速になる。14 GB 付近が費用対効果のクロスポイント。

3. コード生成では Q5/Q6 より IQ 系が上 Q6_K は 25 t/s かつ品質 90.3%（v1）で、IQ3_S(40.1 t/s / 89.0%（v2）)より両方悪い。

196 ケース × 8 反復の比較（v2: 付録3）では、Q5_K_S(31.1 t/s / 89.3%) と IQ3_S(40.1 t/s / 89.0%) は コード生成品質において区別できない。Welch の t 検定、符号検定、範囲の分離の すべてで有意差なし。14 課題のうち 9 課題は 8 回反復すべてが同一スコア。 Q5_K_S を選ぶ「品質が高い」という根拠は測定されておらず、速度差のみが実在する。

数値の出典（v1 = 31 ケース / v2 = 196 ケース）と量子化の選び方は QUANT-TABLE.md に整理した。詳細は QUALITY-REPORT.md 付録3。

ディレクトリ構成

.
├── README.md                 この文書（索引）
├── OPERATION.md              現在の実設定・運用手順
├── QUANT-TABLE.md            量子化の選び方（決定用サマリー）
├── QUALITY-REPORT.md         クォント × 速度 × 品質の測定詳細
├── PLAN.md                   当初の計画（2026-10-07）
├── ai2_tune.md               チューニング会話ログ（索引付きの生ログ）
├── scripts/                  計測・テストスクリプト（[詳細](scripts/README.md)）
├── history/                  調査の詳細ログ（[索引](history/README.md)）
└── backup-20261007/          作業前バックアップ

history/

#	日時	内容
00	10-07	計画との照合・ロールバック手順
01	10-07	ストレージは初期ロードのみ
02	10-07	MTP 投機的 decoding の検証
03	10-07	IQ2_M のダウンロード
04	10-07	「HDD ロードで速度が出ないか」への回答
05	10-08	「起動時 30 tps → 4〜7 tps」の真因
06	10-08	IQ 系クォント実測・クロスポイント確定
07	10-08	コード生成能力テスト
08	10-08	ペナルティ設定の調整
09	10-08	品質比較表の作成
10	10-10	IQ3_S → IQ4_NL 切替（品質優先）
11	10-10	IQ4_NL → IQ3_S 差し戻し（速度優先）
12	10-10	Underdog-Saluki-27B 評価（不採用）
13	10-10	GLM-4.7-Flash 評価（Qwen に及ばず）
14	10-10	Strata / XeStrata 調査メモ（MoE オフロード手法）
15	10-10	MoE オフロード調整（--n-cpu-moe 16 採用、+16%）
16	10-11	Q5 への MoE オフロード検証（不成立）と heretic i1 評価
17	10-11	heretic i1-IQ3_S 評価（品質最高91.0%・速度は劣る）
18	10-11	量子化指紋マップ（ラベルではなく中身で見る）
19	10-11	難問スイート v3/v3.1（設計力の物差しを作る）

各チャプタ末尾に途中で出した誤った結論と訂正を記録している。

scripts/

CT 9902 に push して使う計測スクリプト群。

スクリプト	用途
bench.py	生成速度(t/s)の計測
quality_suite.py	コード生成品質の比較スイート
repeat_task.py / repeat_task2.py	単一課題の反復テスト
verify_code.js	生成コードを node で実行検証
check_code.py	生成コードの破綻検出
gen_task.py / gen_tetris.py	コード生成テスト
evict.py	ページキャッシュの意図的破棄
patch_wrapper.py	wrapper へのオーバーレイ層注入（適用済み）

使い方

# 転送
pct push 9902 scripts/bench.py        /root/bench.py
pct push 9902 scripts/quality_suite.py /root/qs.py

# 速度計測（512 トークン以上推奨）
pct exec 9902 -- python3 /root/bench.py 512 speedtest

# 品質計測（14 課題 × 196 ケース × 8 反復）
pct exec 9902 -- python3 /root/qs.py IQ3S 5 '{}' 4000 0.2

詳細は scripts/README.md。

履歴

• 2026-10-07: 調査開始。GPU ドライバと速度問題を特定
• 2026-10-07: ドライバ 615.71.09 化、kernel 6.17.13-21-pve へ移行
• 2026-10-07: tps-guard の誤検知停止、MTP 投機的 decoding の有効化
• 2026-10-08: IQ 系クォント の評価、IQ3_S 採用、ペナルティ調整
• 2026-10-08: ドキュメント整備（本索引・OPERATION.md 作成）
• 2026-10-10: IQ3_S → IQ4_NL 切替（品質優先）。QUANT-TABLE.md 追加、数値の出典を明記
• 2026-10-10: IQ4_NL → IQ3_S 差し戻し（速度優先）
• 2026-10-10: 他系統を評価 — Saluki-27B（不採用）、GLM-4.7-Flash（Qwen に及ばず）。SSD 容量を 27GB 回収（空き 70G）
• 2026-10-10: MoE オフロード調整 — --n-cpu-moe 16 採用で A/B 中央値 38.0→44.3 t/s（+16%）
• 2026-10-11: Q5 クラス検証 — --n-cpu-moe は Q5 では不成立。heretic i1-Q5_K_S は品質 89.6%（UD-Q5_K_S 88.1%）だが IQ3_S を置換せず
• 2026-10-11: heretic i1-IQ3_S 評価 — 品質 91.0%（過去最高）だが速度 30 t/s。HDD/SSD 無関係、原因はエキスパートの量子化レシピ
• 2026-10-11: 量子化指紋マップ — ラベルではなくテンソル構成で速度を整理（scripts/quant_fingerprint.py 追加）
• 2026-10-11: 難問スイート v3/v3.1 を作成 — v2 と v3.1 は順位が逆転。heretic i1 は v2 最良→v3.1 最下位。総合最良は IQ3_XXS