手元にあるRTX 3080 Tiを、ローカルAI用に使ってみることにしました。今回はProxmox上にUbuntuの仮想マシンを作り、GPUを渡して、OllamaからQwen3 8Bを動かす構成です。
結果から書くと、UbuntuでGPUを認識し、Ollamaから日本語の要約や案内文を作れました。短い要約のテストでは、モデルの読み込みを含む初回は約48秒、同じ入力での2回目は約2.4秒でした。
この記事では、2026年9月29日の構築記録と10月5日の実機テストをもとに、ProxmoxのGPUパススルー設定、起動時につまずいた点、実際の回答例をまとめます。
今回使った構成
構成は次のとおりです。
| 項目 | 今回の環境 |
|---|---|
| 仮想化環境 | Proxmox VE |
| ゲストOS | Ubuntu 24.04.4 LTS |
| 仮想マシンへの割り当て | 4 vCPU・メモリ8GiB・ディスク40GiB |
| GPU | GeForce RTX 3080 Ti |
| GPUメモリ | 12GiB |
| 実行ソフト | Ollama |
| モデル | Qwen3 8B(qwen3:8b) |
| 量子化 | Q4_K_M |
| 今回設定したコンテキスト長 | 16,384 |
Ubuntu用のメモリは8GiB、GPUメモリ(VRAM)は12GiBです。
今回のモデルは保存サイズが約5.2GBでした。動かすときに必要なメモリは、コンテキスト長などの設定で変わります。今回の設定では、実行中のGPUメモリ使用量は約6.3GiBでした。
Ollamaの公式対応表にもRTX 3080 Tiは掲載されています。手元のGPUが使えるか調べるなら、最初にOllamaのハードウェア対応表を確認すると話が早いです。
ProxmoxでRTX 3080 TiをGPUパススルーする
GPUパススルーは、ホストに取り付けたGPUを仮想マシンから直接使えるようにする仕組みです。今回はRTX 3080 TiをUbuntuへ渡し、AIの計算に使いました。渡している間、そのGPUをホストや別の仮想マシンで同時に使うことはできません。
先にIOMMUとホストの画面出力を確認した
作業前のログでは、IOMMUとIRQ remappingが有効になっていました。GPU本体と付属の音声機能は同じIOMMUグループにあり、そのグループにほかの機器は見当たりませんでした。
| 機能 | 今回のPCIアドレス |
|---|---|
| RTX 3080 Ti本体 | 0000:01:00.0 |
| GPU付属の音声機能 | 0000:01:00.1 |
PCIアドレスはPCごとに異なります。自分の環境ではProxmoxのPCIデバイス一覧や、ホスト側のlspci -nnで確認します。
また、GPUを渡す前に、マザーボード側の映像出力で画面を表示できることも確認しました。今回の構成では、ホストの画面出力をそちらへ切り替えてから進めています。
IOMMUの対応や有効化はCPU・マザーボードによって変わります。まだ有効になっていない環境では、Proxmox公式のPCIパススルー設定とマザーボードの設定を先に確認してください。
GPUと音声機能をPCIマッピングでまとめて渡した
今回はProxmoxの「データセンター → リソースマッピング → PCI」でGPUのマッピングを作り、Ubuntuの仮想マシンに割り当てました。GPU本体だけでなく、同じカードの音声機能も含めています。

構築時の設定の要点は次のとおりです。
| 設定項目 | 今回の設定 |
|---|---|
| マッピングの対象 | 0000:01:00のGPU・音声機能 |
| 仮想マシンのマシンタイプ | Q35 |
| BIOS | OVMF(UEFI) |
| EFIディスク | Secure Bootキーなし |
| GPUの割り当て | PCIマッピングを指定、PCI-Express有効 |
GPU本体と音声を、別々の代替候補として登録しないように確認した点もポイントでした。最終的にはUbuntu側で両方の機能を認識できています。
設定中には、作業用アカウントにマッピングを作成・使用する権限がなく、管理者側での設定が必要になる場面もありました。管理者にマッピングを作成してもらい、そのマッピングへの使用権限を追加して進めました。権限を絞ったアカウントで作業する場合は、GPUの設定に加えてアクセス権も確認する必要があります。
今回はホストのGRUBやブラックリストを変更していない
この作業では、ホストのGRUB、VFIOの設定、ドライバのブラックリストを追加変更せずに、GPUを付けた仮想マシンが起動しました。作業前からIOMMUが有効だった環境での結果です。
ホストのドライバからGPUを切り離す処理はProxmoxが試みますが、うまくいかない環境では追加設定が必要になります。公式ドキュメントの「Host Configuration」に手順があります。今回は、既存の設定を確認してから必要な作業を進めました。
IOMMUグループの不一致で起動できなくなった
後日、仮想マシンを起動すると、PCIマッピングのiommugroupが一致しないというエラーで止まりました。
PCI device mapping invalid (hardware probably changed):
'iommugroup' does not match for 'codex-3080ti' (13 != 14)
管理画面を確認すると、保存されたマッピングのグループは14、編集画面に表示されるRTX 3080 Tiの現在のグループは13でした。番号が食い違った理由までは分かっていません。
今回は、次の操作で起動できるようになりました。
- 「データセンター → リソースマッピング → PCIデバイス」を開く。
- 対象のマッピングを展開し、ノードの行にある鉛筆アイコンで編集する。
- RTX 3080 Tiと付属音声のPCIアドレス・IOMMUグループを確認する。
0000:01:00の「すべての機能を1つのデバイスとしてパススルー」を一度選択解除し、選び直して保存する。- 仮想マシンを起動する。
このとき、一覧のグループ14に表示されていたのはRealtekのネットワーク機器でした。数字だけを合わせるのではなく、対象がRTX 3080 Tiであることを確認して選び直しています。
Ubuntuにドライバを入れ、GPUが見えるか確認する
Proxmoxの画面にGPUが表示されていても、仮想マシンのUbuntuから使えるかは別に確認します。
UbuntuにはNVIDIAの595-server-open系ドライバを導入しました。その後、Ubuntu側で使った確認コマンドはこちらです。
nvidia-smi
実行して、RTX 3080 TiとVRAM 12,288MiBを確認しました。
ここでGPUが見えないなら、先にGPUの割り当てやドライバを調べる段階です。モデルを何度もダウンロードし直すより、UbuntuがGPUを認識できているかを先に見た方が、問題を分けて考えられます。
OllamaからQwen3 8Bを起動する
Ollamaを導入したUbuntu上で、次のコマンドからモデルを起動します。
ollama run qwen3:8b
今回の確認では、短いテスト用の応答を返せるところまで動きました。
インストール方法はOSによって変わるので、これから導入する場合はOllamaのLinux向け公式案内を確認してください。
「GPUがある」と「モデルがGPUに載った」を分けて確認
次に確認したのが、モデルを実行している状態でのこちらのコマンドです。
ollama ps
今回の検証では、PROCESSOR欄が100% GPUになっていました。
この表示は、モデルがGPU側に読み込まれていることを確認するためのものです。「GPUがフル稼働している」という意味ではありません。公式FAQでも、モデルの読み込み先を確認する方法として案内されています。
私の環境では、次の順番で確認しました。
- UbuntuからRTX 3080 Tiが見える。
- Ollamaでモデルが起動する。
- テストの返答が返ってくる。
ollama psでGPU側への読み込みを確認する。
順番に確認しておくと、うまくいかないときにどこで止まっているかが分かります。
実際に日本語の要約と案内文を作ってみた
2026年10月5日、同じUbuntuへSSH接続し、OllamaのAPIで短い日本語の要約と案内文作成を試しました。テストの実行と時間の記録はCodexに任せています。
測定時は、GPUをほかの用途で使わない状態にしました。GPU電力上限は350W、Ollamaは0.34.4、コンテキスト長は16,384です。生成条件はtemperatureを0、seedを42、出力上限を2,048トークンにそろえました。
初回は約48秒、同じ要約の2回目は約2.4秒
電話代行をAI受付へ切り替えた経緯をメモにして、「社内共有用に3つの箇条書きで要約して」と依頼しました。同じメモを続けて送り、その後に思考モードをOFFにした場合も試しています。
| テスト | 思考モード | 回答本文が出始めるまで | 回答完了まで |
|---|---|---|---|
| 要約・初回(モデル未読み込み) | ON | 47.06秒 | 47.96秒 |
| 同じ要約・2回目 | ON | 1.54秒 | 2.40秒 |
| 同じ要約・思考モード変更後 | OFF | 1.46秒 | 2.19秒 |
| 社内向け案内文の作成 | OFF | 0.05秒 | 0.60秒 |
初回の約48秒のうち、Ollamaが報告したモデル読み込み時間は約44.4秒でした。今回の環境では、最初の読み込みが待ち時間の大半を占めています。
2回目はモデルが読み込まれた状態で、同じ入力のキャッシュも効いていました。各条件1回ずつの測定なので、この表は今回の短文テストの結果です。「本文が出始めるまで」は思考の表示を含めず、最初の回答文字がAPIから届くまでを測りました。APIの思考出力と計測項目はOllama公式に説明があります。
生成部分の速度は約110〜126トークン/秒。思考モードONでは思考分も含むため、日本語の文字数/秒とは別です。テスト後のGPUメモリ使用量は約6.3GiBで、OllamaのAPIでもモデルの読み込みサイズとVRAM側のサイズが一致していました。
要約は読みやすいが、言い切り方には確認が必要
入力したのは、月3,000円の電話代行からAI受付へ切り替えたこと、機器の追加購入費0円、約40回のテストでAPI利用料約1ドル、24時間対応、Chatwork通知、作成に丸一日ほどかかったことをまとめたメモです。
思考モードOFFでは、次の回答が返ってきました。
- 月3000円の電話代行サービスから、既存機器を活用したAI電話受付に切り替えた。
- API利用料はテスト約40回で約1ドル、受付時間は24時間対応となった。
- 作成とテストは他の業務をしながら約1日で完了し、用件はChatworkで共有できる。
3つの箇条書きにまとまり、残された数字も元のメモに沿っています。一方、機器の追加購入費が0円だった点や、営業電話が多かった背景は省かれました。費用の比較に使うなら、追加購入費の情報は補いたいところです。
思考モードONの回答では、電話代行を「廃止」と表現していました。入力には契約を解約したかまでは書いていないので、使うなら「切り替えた」に直します。文章は読めても、元のメモより強い言い切りになっていないかは確認が必要でした。
案内文は約0.6秒で完成。ただし文字数は短め
次に、「AI電話受付への切り替え、24時間対応、Chatwork通知、必要に応じた折り返し、試験運用中であること」を伝え、150字程度の案内文を頼みました。
会社の電話受付をAIに切り替えました!24時間対応で、受付した用件はこのチャットに通知されます。担当者は確認の上、必要に応じて折り返してください。まだ試験運用中なので、気になる通知があればお知らせください!
回答は103字で、指定した150字程度より短めでした。伝えたい内容は入っていて、短い社内チャットの下書きとしては使えそうです。「受付した」を「受け付けた」に直し、感嘆符を減らせば、落ち着いた案内文になります。
今回の範囲では、短い要約や案内文を作る用途には手応えがありました。長文の読解やコード修正はまだ試していません。
まとめ
ProxmoxでRTX 3080 TiをGPUパススルーし、Ubuntu上のOllamaでQwen3 8Bを動かせました。IOMMUの状態を確認し、Q35・OVMFの仮想マシンにPCIマッピングでGPUを割り当てています。GPUの認識はnvidia-smi、モデルの読み込み先はollama psで確認しました。
実際に短い要約と案内文も作れました。初回のモデル読み込みには時間がかかりましたが、読み込み後は短い文章なら数秒以内に返ってきています。数字や言い切り方を確認しながら、まずは文章の下書きに使ってみたいと思います。
OllamaのAPIはUbuntu内だけで使い、LAN内のほかの機器には公開していません。

