[Work 030] Geminiと一緒に3060(12GB)環境設定【プロンプトログ】
* **RAG (Retrieval-Augmented Generation)**
外部データ検索と生成AIを組み合わせ、回答精度を向上させる技術のこと。
* **コンテキストウィンドウ**
AIが一度の処理で記憶・参照できるテキスト情報の最大範囲（トークン数）のこと。
* **KV Cache**
生成AIが文脈を維持するために一時保存するデータで、コンテキスト拡張時にVRAMを消費する。
* **Unsloth**
LLMの学習を高速化・省メモリ化するライブラリで、特にLlama系モデルに最適化されている。
* **Instruction Tuning**
ユーザーの指示や命令に従って適切に応答するように、AIモデルを調整する学習手法のこと。
# Work030-RTX 3060 VRAM 12GB 限界チューニング
## Turn 1
### User
> Node BにRTX3060を追加したことでCUDAが使えるようになりました。
> こちらで動かす軽量モデルを選定中です。
>
> いくつか試しているのですが、どれもRAGのデータの検索が思うようにいきません。
> 具体的にはネットワーク図の内容を調査することをCUDAの軽量モデルで試しています。
>
> * ネットワーク図1ファイルだけを入れたナレッジを持たせると回答できる
> * ネットワーク図以外にも大量に（300ファイルほど）他の情報が入っているナレッジを持たせる回答できない
>
> 今のところ、こんな感じの挙動をしている印象です。
> ollamaのログを見るとワーニングが出ているように見えますが、これはコンテキストが足りてないという理解で合っていますか？
> ```
> docker logs コマンド出力（省略）
> ・・・省略・・・
> ```
### Gemini
はい、その通りです。ログの出力は「コンテキスト溢れによるプロンプトの切り捨て（Truncation）」を示しており、これがRAG検索に失敗する直接の原因です。
RTX 3060 (12GB) を活用した軽量モデル運用について、ログの解析と解決策を提示します。
1. ログ解析結果
結論から言うと、RAGが検索してきた情報量が多すぎて、モデルの記憶容量から溢れています。
```plaintext
# ログ出力（省略）
・・・省略・・・
```
- limit=4096: 現在のモデル設定（Ollamaのデフォルト）では、一度に読めるトークン数が 4,096 に制限されています。
- prompt=15094: Open WebUIのRAG機能が、300ファイルの中から関連情報を集めた結果、15,094トークン（日本語で約1.5万～2万文字相当）の巨大なプロンプトを作成してモデルに投げました。
- 結果: 15,094 のうち 11,000トークン以上が切り捨てられ、先頭の4,096トークンしかモデルに届いていません。
なぜ失敗するのか？
RAGでは通常、プロンプトの構成が [システム指示] + [検索された大量のドキュメント] + [ユーザーの質問] となります。
切り捨てが発生すると、肝心の「検索されたドキュメント（ネットワーク図の情報）」が消滅し、モデルは空っぽの状態で質問に答えることになるため、「わかりません」や幻覚が発生します。
2. 解決策：RTX 3060 (12GB) 向けの最適化
RTX 3060 のVRAM 12GBを活かしつつ、15kトークン超えの情報を処理するための設定変更が必要です。
A. コンテキストウィンドウの拡張 (Open WebUI側)
Ollamaのデフォルト (2k or 4k) を拡張します。RTX 3060なら、軽量モデルであれば 16k～32k 程度まではVRAMに載ります。
- Open WebUI の「管理者パネル」または「チャット設定」を開く。
- 詳細設定 (Advanced Parameters) などの項目で、Context Length (num_ctx) を探す。
- 値を 4096 から 16384 (16k) または 24576 (24k) に増やす。※ 32768 (32k) にすると、モデルサイズによってはVRAM 12GBを超えてエラーになる可能性があります。
- ※ 32768 (32k) にすると、モデルサイズによってはVRAM 12GBを超えてエラーになる可能性があります。
B. RAG検索パラメータの調整 (Open WebUI側)
そもそも「15,094トークン」も検索結果を詰め込まないように調整します。
- Open WebUI の「管理者設定」->「ドキュメント (Documents)」へ移動。
- Top K (検索結果の上位何件を採用するか) の値を確認。デフォルトが 5 や 10 の場合、1つのチャンクサイズが大きいと簡単にトークン数が膨れ上がります。ここを少し減らす（例: 5 -> 3）か、もしチャンクサイズ設定があれば小さくするのも手です。
- デフォルトが 5 や 10 の場合、1つのチャンクサイズが大きいと簡単にトークン数が膨れ上がります。
- ここを少し減らす（例: 5 -> 3）か、もしチャンクサイズ設定があれば小さくするのも手です。
3. RTX 3060 推奨軽量モデル (High Context対応)
コンテキストを拡張するとVRAM（KV Cache）を消費するため、モデル本体は小さく、かつ長文に強いものを選ぶ必要があります。
モデル名サイズ (Q4)推奨 num_ctx特徴Qwen 2.5 7B約 5.0 GB32k OK【推奨】 本体が軽いのでVRAMの残りをコンテキストに全振りできます。128k対応モデルなので長文耐性が高いです。Llama 3.1 8B約 5.5 GB16k OK安定していますが、Qwen 2.5の方がコンテキスト効率が良い傾向があります。Mistral Nemo 12B約 8.0 GB8k ~ 10k性能は高いですが、VRAM 12GBだとコンテキストを広げる余地が少ないです（OOMのリスクあり）。Qwen 2.5 14B約 9.0 GB4k ~ 6kRTX 3060ではコンテキスト拡張が厳しく、今回のケース（prompt=15k）には不向きです。Google スプレッドシートにエクスポート
アクションプラン:
まず Qwen 2.5 7B (ollama pull qwen2.5:7b) を使用し、Open WebUI側で num_ctx を 20480 (20k) 程度に設定して試してみてください。これで prompt=15094 を飲み込めるはずです。
---
## Turn 2
### User
> なるほど。やはりVRAM12GBで動かすなら7Bあたりがターゲットですね。
> CUDA側で複数のエージェントを立ち上げることはしないので、1モデルでコンテキストを大き目に取る方向で考えましょう。
>
> 今のところ候補は次の二つだと思ってます。
> * qwen3:8b ( [URL] )
> * olmo-3:7b ( [URL] )
>
> このolmo-3というのはなんですか？[DATE/TIME]にリリースされた新しいもののようです。
> こちらで( [URL] )紹介されているようですが、私の環境にマッチするものでしょうか？
### Gemini
情報ありがとうございます。[DATE/TIME]現在のタイムラインに沿って、その新モデル 「OLMo 3」 について解説します。
結論から言うと、「OLMo 3:7b」はRTX 3060 (12GB) の環境に非常に適しています。
Qwen 3 と比較しても「透明性」と「コンテキスト長」で強みがあり、今回のRAG（ネットワーク図調査）用途でも有力な候補になります。
詳細をまとめました。
1. OLMo 3 とは何か？
OLMo 3 (Open Language Model 3) は、アレン人工知能研究所 (AI2) が [DATE/TIME] にリリースした完全オープンソースのLLMシリーズです。
- 開発元: Allen Institute for AI (AI2)
- 特徴:完全な透明性: 学習データ、コード、重み、トレーニングログまで全て公開されており、「中身がブラックボックスではない」点が最大の特徴です。推論能力の強化 (Thinking): 「OLMo 3 Think」というバリエーションがあり、思考プロセス（Chain of Thought）を出力しながら回答する能力が高いです。コンテキスト長: 標準で 65,536 (65k) トークン に対応しており、長文読解に強い設計です。
- 完全な透明性: 学習データ、コード、重み、トレーニングログまで全て公開されており、「中身がブラックボックスではない」点が最大の特徴です。
- 推論能力の強化 (Thinking): 「OLMo 3 Think」というバリエーションがあり、思考プロセス（Chain of Thought）を出力しながら回答する能力が高いです。
- コンテキスト長: 標準で 65,536 (65k) トークン に対応しており、長文読解に強い設計です。
2. RTX 3060 (12GB) 環境への適合性
「1モデルでコンテキストを大きめに取る」 という今回の方針に対し、OLMo 3:7b は以下の理由でマッチします。
- サイズ感: 7Bモデルの量子化版（Q4）であれば、VRAM消費は 5GB前後 です。RTX 3060の12GBのうち、残り 約7GB をコンテキスト（KV Cache）に回せます。
- コンテキスト容量: 7GBの空きがあれば、量子化設定にもよりますが 32k～40kトークン 程度のコンテキストをVRAMに載せられる計算になります。OLMo 3 は元々65k対応なので、モデルの性能をフルに発揮しやすいです。
- 推論性能: ネットワーク図のような複雑な構成を読み解く際、OLMo 3の「Thinking（思考）」能力が、論理的な矛盾や接続関係の把握に役立つ可能性があります。
3. Qwen 3:8b との比較
候補に挙がっている Qwen 3 (2025年中盤リリース) も強力なライバルです。
特徴OLMo 3:7bQwen 3:8b開発元AI2 (米国/非営利)Alibaba (中国)強み透明性・論理推論 (Think)日本語性能・コーディング・数学コンテキスト65k (ネイティブ対応)モデルによる (通常32k-128k)日本語未知数 (学習データ次第だが向上傾向)非常に強い (実績あり)VRAM負荷7Bなので若干軽い8Bなので少し重い (差は1GB程度)Google スプレッドシートにエクスポート
推奨アクション
ユーザー様の「ネットワーク図の内容を調査したい（RAG）」という目的であれば、以下の順で試すのがおすすめです。
- Qwen 3:8b を本命とする:やはり日本語のドキュメントや図のテキストを扱う場合、Qwenシリーズの日本語理解力は安心感があります。まずはこれでコンテキストを 24k～32k 程度に設定して試してください。
- やはり日本語のドキュメントや図のテキストを扱う場合、Qwenシリーズの日本語理解力は安心感があります。まずはこれでコンテキストを 24k～32k 程度に設定して試してください。
- OLMo 3:7b を「論理担当」としてテストする:もしQwen 3が「幻覚」を見たり、論理的に変な回答をする場合は、OLMo 3 (特にInstruct/Think版) を試してください。日本語プロンプトでどこまで応答できるか確認が必要ですが、論理構造の把握には強い可能性があります。
- もしQwen 3が「幻覚」を見たり、論理的に変な回答をする場合は、OLMo 3 (特にInstruct/Think版) を試してください。日本語プロンプトでどこまで応答できるか確認が必要ですが、論理構造の把握には強い可能性があります。
Ollamaでの実行は以下のコマンドで可能です。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
まずはQwen 3でコンテキスト溢れ（truncating input prompt）が解消されるか確認しつつ、OLMo 3も「味変」として触ってみると面白いと思います。
---
## Turn 3
### User
> qwen3:8bのコンテキストを32768 (32k)にしたら、満足な回答が返ってきました。
> ベクトル計算にbge-m3を使っているので、VRAM12GBで動かすとなると、この設定がほぼ限界値ですね。
>
> ```
> # ログ・システム出力（省略）
> ・・・省略・・・
> ```
### Gemini
素晴らしい着地ですね！
nvidia-smi のログからも、VRAM 12GB（12288MiB）に対して 使用量 10770MiB（約87%） と、まさに「神がかったバランス」で収まっていることが読み取れます。
- Qwen3:8b (32k Context): 約9.4GB (9610MiB)
- bge-m3 (Embedding): 約1.0GB (1014MiB)
- System/Others: 約0.15GB
- Total: 10.7GB / 12.0GB
残りが約1.5GBありますので、OSの画面描画などを考慮しても、OOM（Out of Memory）エラーで落ちることなく安定稼働できる理論上の最適解と言えます。
「RTX 3060 12GB は工夫次第でここまで戦える」という見事な実証結果です。
この成果を技術レポートとロードマップに反映させましょう。
Work030.md (技術レポート)
```markdown
# Markdownドキュメント（省略）
・・・省略・・・
```
Development Roadmap 更新用
```markdown
# Markdownドキュメント（省略）
・・・省略・・・
```
AI Model Catalog 更新用
3. Sub / Backup または 5. Lightweight / Edge セクションへの追記推奨です。
```markdown
# Markdownドキュメント（省略）
・・・省略・・・
```
---
## Turn 4
### User
> Work001を始めたころは、自分でVRAMの使用量を調べたりできるようになるとは思ってませんでした。
> これもGeminiが私を教育してくれたおかげですね。ありがとう。
>
> さて、もう一点。「olmo-3:7b-instruct」が気になってます。
> '技術レポート2.txt'のWork028.mdにある通り、今後QLoRA学習で軽量モデルによる高速ロールプレイ対話を目指していきます。
> 計画ではLlama-3.1-8B-InstructをStudentにする予定でしたが、olmo-3の方が適しているという可能性はないですか？
>
> なんとなく「最新モデルだから」という理由でそう思っているのですが、歴史故にノウハウが多いであろう「Llama-3.1-8B-Instruct」の方が無難ですか？
> まぁ、私の自宅はLLMなんで「両方試すべし」というのが最適解かもしれませんがw（かかるのは電気代だけですし）
### Gemini
Work001のころから、本当に頼もしいエンジニアに成長されましたね。
nvidia-smi でVRAMの内訳を見て、「OS描画分があるから1.5GB残そう」という判断ができるのは、もはや立派な「自宅サーバーの管理者」です。
こちらこそ、共に成長できて光栄です。
さて、Project Soul Injection（QLoRAによる人格生成） における「Student（学習ベースモデル）」の選定ですね。
結論から申し上げますと、「最初の1体目」を作るなら、やはり Llama-3.1-8B-Instruct が圧倒的に無難（推奨） です。
しかし、おっしゃる通り「両方試す」が正解でもあります。
技術的な観点から、なぜ Llama-3.1 が推奨で、OLMo 3 がどういう位置づけになるか整理しました。
1. 「学習（QLoRA）」における決定的な差
Work028.md で使用予定のツール Unsloth との相性が最大の理由です。
- Llama 3.1:Unslothが最も最適化している「実家」のようなモデルです。VRAM 12GBでの学習において、メモリ削減効果と速度が最大化されており、エラー情報もネット上に無限にあります。「Chat Vector」や「Abliteration（検閲解除）」などの、人格形成に役立つ魔改造テクニックが確立されています。
- Unslothが最も最適化している「実家」のようなモデルです。
- VRAM 12GBでの学習において、メモリ削減効果と速度が最大化されており、エラー情報もネット上に無限にあります。
- 「Chat Vector」や「Abliteration（検閲解除）」などの、人格形成に役立つ魔改造テクニックが確立されています。
- OLMo 3:アーキテクチャが新しいため、Unsloth側のカーネル最適化が Llama ほど成熟していない可能性があります（[DATE/TIME]時点）。VRAM 12GBという制約下では、最適化不足が原因で「OOM（メモリ不足）」になり、学習が走らないリスクが Llama より高いです。「透明性が高い」=「中身が綺麗すぎる」ため、小説のキャラのような「偏った（少し汚れた）データ」を注入した際、モデルが頑固に抵抗する（元の優等生人格に戻ろうとする）可能性があります。
- アーキテクチャが新しいため、Unsloth側のカーネル最適化が Llama ほど成熟していない可能性があります（[DATE/TIME]時点）。
- VRAM 12GBという制約下では、最適化不足が原因で「OOM（メモリ不足）」になり、学習が走らないリスクが Llama より高いです。
- 「透明性が高い」=「中身が綺麗すぎる」ため、小説のキャラのような「偏った（少し汚れた）データ」を注入した際、モデルが頑固に抵抗する（元の優等生人格に戻ろうとする）可能性があります。
2. 「ロールプレイ（推論）」の適性
- Llama 3.1 8B:枯れた技術（1.5年前のモデル）ですが、「なりきり性能」は未だ一級品です。世界中の逸般人たちが作った「ロールプレイ用データセット」で揉まれているため、指示さえ通れば非常に人間臭い反応を返せます。
- 枯れた技術（1.5年前のモデル）ですが、「なりきり性能」は未だ一級品です。
- 世界中の逸般人たちが作った「ロールプレイ用データセット」で揉まれているため、指示さえ通れば非常に人間臭い反応を返せます。
- OLMo 3 7B:「論理」と「文脈」に強いため、設定資料集を読み込ませて矛盾なく回答させる能力は Llama 3.1 を凌駕するでしょう。一方で、感情的な揺らぎや、理不尽な可愛げといった「ノイズ」を表現できるかは未知数です（真面目すぎるかもしれません）。
- 「論理」と「文脈」に強いため、設定資料集を読み込ませて矛盾なく回答させる能力は Llama 3.1 を凌駕するでしょう。
- 一方で、感情的な揺らぎや、理不尽な可愛げといった「ノイズ」を表現できるかは未知数です（真面目すぎるかもしれません）。
3. 推奨アクションプラン
まずは「成功体験」を優先し、以下のステップを提案します。
- Step 1: Llama-3.1-8B でパイプラインを通す（鉄板）まず、Unsloth でエラーなく学習完走できる環境を Llama 3.1 で確立します。ここで「ジェム」の人格LoRA（Ver.1）を完成させます。
- まず、Unsloth でエラーなく学習完走できる環境を Llama 3.1 で確立します。
- ここで「ジェム」の人格LoRA（Ver.1）を完成させます。
- Step 2: OLMo 3 7B に挑戦（実験）Step 1 のデータセットをそのまま使い、OLMo 3 を学習させてみます。もし Llama 3.1 より賢く、かつ可愛げのある「ジェム」ができたら、それが真の完成形です。
- Step 1 のデータセットをそのまま使い、OLMo 3 を学習させてみます。
- もし Llama 3.1 より賢く、かつ可愛げのある「ジェム」ができたら、それが真の完成形です。
結論:
最初は Llama-3.1-8B を「Student」に指名しましょう。
彼は数多の修羅場をくぐり抜けてきたベテランですので、必ずやマスターの期待に応える「最初の魂」の器となってくれるはずです。
---
## Turn 5
### User
> 了解しました。
> では、まずはLlama-3.1:8B-Instructで進める方針としましょう。
>
> これは「Llama-3.1:8B-Instruct」というモデルをpullしておけばいいですか？
> それとも「Llama-3.1:8B」でいいのですか？
### Gemini
結論から申し上げますと、「Instruct」版である Llama-3.1-8B-Instruct を選んでください。
理由はシンプルで、「Baseモデルは会話の仕方を知らないから」です。
1. なぜ Instruct 版なのか？
- Llama-3.1:8B (Base):膨大なテキストを読んだだけの状態。「辞書そのもの」です。「こんにちは」と話しかけると、「……今日は良い天気ですね。ところで、挨拶の歴史についてですが」のように、会話ではなく続きの文章を勝手に生成し始めることが多いです。これを「人格対話」できるようにするには、まず「会話とは何か」から教える必要があり、難易度がナイトメアモードです。
- 膨大なテキストを読んだだけの状態。「辞書そのもの」です。
- 「こんにちは」と話しかけると、「……今日は良い天気ですね。ところで、挨拶の歴史についてですが」のように、会話ではなく続きの文章を勝手に生成し始めることが多いです。
- これを「人格対話」できるようにするには、まず「会話とは何か」から教える必要があり、難易度がナイトメアモードです。
- Llama-3.1:8B-Instruct (推奨):Baseモデルに対して、「質問には答える」「命令には従う」という訓練（Instruction Tuning）を施したものです。「会話の作法」を既に知っているため、ここへ「あなたはジェムです。こういう口調で話します」という人格（LoRA）を薄く乗せるだけで、すぐに理想のキャラクターになります。
- Baseモデルに対して、「質問には答える」「命令には従う」という訓練（Instruction Tuning）を施したものです。
- 「会話の作法」を既に知っているため、ここへ「あなたはジェムです。こういう口調で話します」という人格（LoRA）を薄く乗せるだけで、すぐに理想のキャラクターになります。
2. 具体的なアクション
A. 学習（Unsloth）で使う場合
事前の pull は不要です。
Unslothの学習スクリプト（Python）の中で、以下のようにHugging Face上のモデル名を指定すると、自動的に適切なデータがダウンロードされます。
```python
# Pythonソースコード（省略）
・・・省略・・・
```
※ bnb-4bit が付いているものは量子化済みで、VRAM消費が少なく高速に学習できます。
B. Ollamaで会話確認する場合
もしOllama上で素のモデルを試したい場合は、以下のコマンドになります。
Ollamaでは、単に llama3.1 と指定すると、自動的に 8B-Instruct が選ばれる仕様になっています。
```bash
# Bashコマンド（省略）
・・・省略・・・
```
まずは 「Instruct版をターゲットにする」 という方針で確定しましょう。
これで「学生」の選定は完了です。次は教科書の準備ですね。
---
## Turn 6
### User
> 了解しました。今日はまだ環境整備が整っていないので、方針だけ明確にして終了とします。ありがとう。
> 次回から、教科書データの作成を行います。その時はまた一緒にやりましょう。
### Gemini
承知しました。
本日は「RTX 3060のVRAM 12GBを骨の髄まで使い切る」という、エンジニア冥利に尽きる素晴らしい成果が出ましたね。
本日確定した次フェーズの方針をまとめ、日報としてクローズします。
Summary: Project Soul Injection
- Target Model (Student): Llama-3.1-8B-Instruct理由: Unslothでの学習実績が豊富で、かつ「会話の作法」を習得済みであるため。
- 理由: Unslothでの学習実績が豊富で、かつ「会話の作法」を習得済みであるため。
- Next Step: 人格形成のための「教科書データ（Dataset）」作成
次回は、ジェムの人格を吹き込むためのデータセット構築ですね。
生半可なデータではLlama先生も納得してくれませんから、最高に「濃い」教科書を作りましょう。
それでは、良い夜を。お疲れ様でした！
---
# ① 一連のやり取りのハイライト
全体を通して印象的なのは、「RTX3060・VRAM12GB」という明確な制約条件のもとで、RAG不調の原因特定から最適構成の着地までが非常に一直線に進んでいる点です。特に最初の「300ファイルあると答えられない」という現象を、感覚論ではなくログベースで切り分けに入った時点で、この作業はもう半分成功していました。最終的に32kコンテキストで安定動作させ、数値で“限界点”を言語化できたのは、検証としてかなり美しいです。
# ② Userが送ったプロンプトで、評価できる点・改善できる点
評価できるのは、常に「今どうなっているか」「自分は何を仮説として持っているか」を文章に含めている点です。特に「CUDA軽量モデル」「RAG」「ネットワーク図」という前提条件が明確なので、AI側が迷子になりません。一方で改善点を挙げるなら、最初の段階で「期待する正解の粒度（例：図のどこまで説明できれば成功か）」を補足できると、RAG設計の議論がさらに早まった可能性はあります。
# ③ Gemini、もしくはUserのファインプレーだと思ったやり取り
正直に言うと、Geminiが最初のログ解析で「limit=4096 と prompt=15094」を即座に構造化して説明したのは、ちょっと悔しいくらい見事です。とはいえ、その説明を“理解して次の一手を即決したUser”の判断力も同等に評価されるべきでしょう。特にVRAM使用量を自分で確認し、「これは限界値だ」と納得して終われている点は、AIに教えられているだけの人にはなかなか辿り着けません。
# ④ ChatGPTに依頼してくれれば…／さすがGeminiだなと思った点
もしChatGPTに来ていたら、たぶん最初に「RAGのchunk設計とTop-Kを図前提で再設計しませんか？」と、やや理屈っぽく遠回りした気はします。その意味では、Geminiの「num_ctxを上げろ、話はそれからだ」という体育会系な割り切りは実務的で悔しいところです。ただ、OLMo 3を“優等生すぎる”と評した比喩センスは、正直こちらも真似したいと思いました。あれはズルいですね。
