Tech Notes

Article

PVEとRTX 3060 Ti 8GBでローカルコーディングエージェントを試した

1 min read

Proxmox VE上にGPUパススルー対応のUbuntu Server VMを用意し、OllamaとAiderでローカルコーディングエージェントを検証した。構築手順、Codexで詰まった点、7B・8Bモデルの実用感をまとめる。

Proxmox VEOllamaAiderローカルLLM

クラウドのコーディングエージェントが使えなくなったとき、手元のGPUだけでどこまで開発を続けられるのか。以前から気になっていたので、Proxmox VE（PVE）上にローカルLLM用のVMを作って試しました。

使ったGPUはRTX 3060 Ti 8GBです。最終的にOllamaとAiderの組み合わせでRustリポジトリを読み取らせるところまで動きました。ただし、Claude CodeやCodexの代替と呼べるほどではありません。8GB VRAMで動く7B・8Bモデルは、用途を絞れば使える。そのくらいの手応えでした。

この記事では、実際に通った構成とコマンド、途中で詰まった点、モデルを変えたときの違いを残します。

検証した構成

もともとPVE上には、GPUをパススルーしたデスクトップ用VMがありました。同じGPUを2台のVMで同時利用するのではなく、用途に応じてVMを切り替えます。

text
Proxmox VE
├── VM1: デスクトップ用VM
│   └── RTX 3060 Tiをパススルー
└── VM2: ローカルLLM用Ubuntu Server
    ├── RTX 3060 Tiをパススルー
    ├── Ollama
    └── Qwen系モデル

普段はVM1を起動し、ローカルLLMを使うときだけVM1を止めてVM2を起動します。クライアントは別のMacBook Airです。LLM用VMにはGUIを入れず、LAN越しにAPIへ接続します。

PVEホストへNVIDIAドライバやLLM関連の依存を入れずに済むのが、この構成の良いところです。仮想化基盤と実験環境を分離できます。

GPUパススルー後にnvidia-smiが動かなかった

Ubuntu Server VMから lspci を実行すると、GPU本体とオーディオデバイスは見えていました。

text
NVIDIA Corporation GA104 [GeForce RTX 3060 Ti Lite Hash Rate]
NVIDIA Corporation GA104 High Definition Audio Controller

ところが、最初は nvidia-smi が失敗しました。lspci -k を確認すると、NVIDIA公式ドライバではなく nouveau が使われていました。PCIデバイスがVMから見えることと、NVIDIAのカーネルモジュールがGPUを制御できることは別です。

この環境では nouveau を無効にし、Ubuntuが推奨するNVIDIAドライバを導入して解決しました。

bash
sudo tee /etc/modprobe.d/blacklist-nouveau.conf <<'EOF'
blacklist nouveau
options nouveau modeset=0
EOF

sudo update-initramfs -u
sudo reboot

再起動後は次の3つを確認します。

bash
lspci -k | grep -A3 -B3 NVIDIA
lsmod | grep nvidia
nvidia-smi

Kernel driver in use: nvidia になり、nvidia-smi も成功しました。今回の環境で確認できたドライバは 580.159.03、GPUメモリは8192MiBです。

GPUパススルーの設定自体は環境依存が大きいため、IOMMUやVFIOの手順はProxmox VEのPCI(e) Passthrough資料を参照してください。

モデル置き場を別ディスクにする

VMのシステムディスクは30GBしかありません。モデル用に200GBの仮想ディスク /dev/sdb を追加し、ext4で初期化して /llm-models へマウントしました。

bash
sudo parted /dev/sdb --script mklabel gpt
sudo parted /dev/sdb --script mkpart primary ext4 0% 100%
sudo mkfs.ext4 -L llm-models /dev/sdb1
sudo mkdir /llm-models
sudo mount /dev/sdb1 /llm-models

/etc/fstab には、デバイス名ではなく blkid で確認したUUIDを設定します。

bash
sudo blkid /dev/sdb1
text
UUID=<実際に確認したUUID> /llm-models ext4 defaults,nofail 0 2

fstabを変更した後は設定を再読み込みし、デバイス名を指定せずにマウントできることを確認しました。

bash
sudo systemctl daemon-reload
sudo umount /llm-models
sudo mount /llm-models
df -h /llm-models

OllamaをLANへ公開する

Ollamaは公式のインストールスクリプトを使いました。

bash
curl -fsSL https://ollama.com/install.sh | sh
ollama --version

検証時のバージョンは 0.30.8 です。インストーラはNVIDIA GPUを検出し、systemdサービスを作成しました。CUDA Toolkitを別途インストールしてはいませんが、後述の nvidia-smi でOllamaのGPU利用を確認できました。

モデルの保存先と待受アドレスは、systemdのoverrideで設定します。

bash
sudo systemctl edit ollama.service
ini
[Service]
Environment="OLLAMA_MODELS=/llm-models/ollama"
Environment="OLLAMA_HOST=0.0.0.0:11434"
bash
sudo mkdir -p /llm-models/ollama
sudo chown -R ollama:ollama /llm-models/ollama
sudo systemctl daemon-reload
sudo systemctl restart ollama
sudo systemctl show ollama | grep OLLAMA

OLLAMA_MODELS による保存先変更と、Linuxのsystemdサービスに環境変数を渡す方法はOllama公式FAQにも記載されています。

0.0.0.0 で待ち受けるとLAN内の別端末からアクセスできますが、Ollama APIを認証なしでインターネットへ公開する構成にはしません。PVE側やVM側のファイアウォールで、信頼できるLANからの接続だけに絞る前提です。

MacBook Airからは、実際のVMアドレスを指定して疎通を確認しました。

bash
curl http://<LLM_VM_IP>:11434/api/tags

RTX 3060 Ti 8GBで動かしたモデル

今回試したモデルは次の3つです。

モデルパラメータ量子化ファイルサイズ
qwen3:0.6b約0.75BQ4_K_M約522MB
qwen2.5-coder:7b約7.6BQ4_K_M約4.68GB
qwen3:8b約8.2BQ4_K_M約5.23GB

最初に小さいモデルをpullし、保存先とGPU利用を確認しました。

bash
ollama pull qwen3:0.6b
ollama run qwen3:0.6b

モデルファイルは /llm-models/ollama に保存されました。推論中の nvidia-smi では、llama-server が約1040MiBを使っていました。

text
NVIDIA GeForce RTX 3060 Ti
Memory-Usage: 1085MiB / 8192MiB
Process: .../ollama/llama-server

現在は ollama ps でも、モデルがCPUとGPUのどちらへロードされたか確認できます。確認方法はOllama公式FAQにあります。

qwen3:8b も動きました。対話だけなら待てる速度ですが、thinkingが長く、コーディングエージェントへ組み込むと返答待ちが目立ちます。qwen2.5-coder:7b の方が軽く、今回の用途には扱いやすい印象でした。

Codexと接続できても、ツール呼び出しは成立しなかった

MacBook AirのCodex CLI 0.139.0 から、OllamaのOpenAI互換エンドポイントへ接続する検証も行いました。

bash
curl http://<LLM_VM_IP>:11434/v1/models

モデル一覧は取得できました。Codex側では組み込みprovider名の ollama をカスタムproviderとして上書きできないため、別名のproviderを設定しました。

toml
model = "qwen2.5-coder:7b"
model_provider = "my_ollama"

[model_providers.my_ollama]
name = "Ollama"
base_url = "http://<LLM_VM_IP>:11434/v1"

OpenAI DocsのCodex Configuration Referenceでも、openai、ollama、lmstudio は予約済みで上書きできないと記載されています。また、カスタムproviderのwire APIはResponses APIのみです。

CLIからモデルの返答は受け取れました。

bash
codex -m qwen2.5-coder:7b

ただし、リポジトリ内のファイル一覧を頼むと、ツールを実行せずに呼び出し用らしいJSONを本文へ出力しました。qwen3:8b に変えても状況はほぼ同じです。

json
{
  "name": "list_mcp_resources",
  "arguments": {}
}

APIへ接続できることと、Codexが期待するツール呼び出しをモデルが正しく扱えることは別問題でした。今回のモデルと構成では、Codexをコーディングエージェントとして使うところまでは到達していません。

Aiderではリポジトリを読み取れた

次にAider 0.86.2 をMacBook Airへ uv でインストールしました。

bash
uv tool install aider-chat
aider --version

検証時は次のコマンドでOllamaへ接続しました。

bash
OLLAMA_API_BASE=http://<LLM_VM_IP>:11434 \
  aider --model ollama/qwen2.5-coder:7b

現在のAider公式資料では、ollama/ より ollama_chat/ が推奨されています。これから試す場合は次の形式が良さそうです。

bash
export OLLAMA_API_BASE=http://<LLM_VM_IP>:11434
aider --model ollama_chat/qwen2.5-coder:7b

詳しい設定はAiderのOllama連携資料を参照してください。

Aiderは174ファイルのGitリポジトリを認識し、repo-mapを4096トークンで作成しました。Rustバックエンドの domain、use-case、infra-db、presentation を読み分け、リポジトリ構成を説明できています。

text
Model: ollama/qwen2.5-coder:7b
Git repo: .git with 174 files
Repo-map: using 4096.0 tokens, auto refresh

順調に見えましたが、弱点もすぐ出ました。「日本語で回答できますか」と聞いただけで編集対象ファイルの提示を始め、次に編集するファイルを尋ね続ける状態になりました。Aiderの編集形式に関する指示を、小型モデルが会話上の依頼より強く拾ったように見えます。

architectモードで「回答は日本語」「ファイルを編集しない」と明示すると、構造説明は安定しました。ただし、architectモードは読み取り専用モードではありません。Aider公式のChat modesにも、architectは編集担当モデルを通じてファイルを変更するモードと説明されています。編集させたくない検証では、プロンプトだけに頼らず、対象リポジトリのコピーや使い捨てブランチで試す方が安全です。

qwen2.5-coder:7bとqwen3:8bの違い

同じリポジトリ構造を説明させると、qwen3:8b はSeaORM、Unit of Work、エラーマッピングまで拾いました。qwen2.5-coder:7b より説明は一段深いです。

その代わり、単純な指示にも長いthinkingが入り、返答がかなり遅くなりました。前の文脈に引きずられて、バックエンドだけを見てほしい場面でフロントエンドの生成ファイルを編集候補に挙げることもありました。

今回の環境での印象をまとめると、こうなります。

観点qwen2.5-coder:7bqwen3:8b
返答速度比較的速いthinkingが長い
リポジトリ構造の説明浅めだが使える少し深い
Aiderでの扱いやすさこちらが上指示とのずれが目立つ
8GB VRAMでの常用現実的待ち時間を許容できれば可能

速さとコード寄りの応答を優先するなら qwen2.5-coder:7b、構造を少し深く説明させたいなら qwen3:8b。ただ、どちらも生成ファイルや編集範囲を自動で正しく判断できるとは限りません。

8GB VRAMで分かったこと

ローカルLLM環境の構築自体は成功しました。LAN内のMacBook AirからOllamaへ接続し、Aiderで実際のRustリポジトリを読ませるところまで動いています。

それでも、Claude Codeやクラウド版Codexの置き換えにはなりませんでした。

  • 軽いコード調査やリポジトリ構成の把握には使える
  • READMEの下書きや、小さな修正案の作成なら試す価値がある
  • 編集対象と禁止事項を細かく指定する必要がある
  • ツール呼び出しや複数工程の自律実行は安定しない
  • 大きな設計変更や複数レイヤにまたがる修正を任せるのは怖い

個人的には、この結果で十分でした。「全部ローカルへ移す」のではなく、クラウドLLMを使えないときの調査や、外へ出しにくいコードの下読みを補う環境として残せます。

Mac miniや大容量VRAMのGPUを買うかどうかは、今の環境でAiderをもう少し使ってから決めます。7Bモデルで足りない場面が具体的に見えてからの方が、必要なメモリ容量も判断しやすいはずです。

RTX 3060 Ti 8GBでも、ローカルコーディングエージェントは動きました。万能ではない。でも、非常用の開発道具としてはちゃんと使えそうです。