Fedora WorkstationでローカルLLMを実行する3つのアプローチ
個人PCやワークステーションのFedora環境でLLMを快適に動作させる場合、主に以下の3つの構成パターンが考えられます。
- フルネイティブ(ベアメタル): Ollamaのバイナリを
/usr/local/binに配置し、Open WebUIをvirtualenvやuvで構築する方法。ハードウェア性能を極限まで引き出せますが、環境の整理やメンテナンスに手間がかかります。 - フルコンテナ(Podman/Dockerスタック): OllamaとWebUIの両方をコンテナ化する方法。FedoraのルートレスPodman経由でNVIDIA GPUをパススルーするためにCDI(Container Device Interface)を設定すると、
/dev/nvidia*のアクセス権限エラーに直面しやすくなります。 - ハイブリッド構成(推奨): OS上にOllamaを直接インストールしてCUDAドライバーをフル活用しつつ、Open WebUIのみをPodmanコンテナへ逃がしてWeb環境をスマートに分離する方法です。
各方式のメリット・デメリットを検証
1. フルベアメタル構成
メリット: 推論速度は最速です。名前空間や仮想化によるオーバーヘッドが一切なく、CUDAドライバーまわりのトラブルシューティングも迅速に行えます。
デメリット: Open WebUIは大量のPythonライブラリやNode.jsパッケージに依存しています。ホスト環境に直接導入するとOSが散らかりやすく、将来的なアップグレードやアンインストール時に余計な時間が取られます。
2. フルコンテナ構成
メリット: ライフサイクル管理が非常に容易です。Composeファイルを破棄するだけで、簡単に環境を初期化できます。
デメリット: FedoraではSELinuxがデフォルトでEnforcing(強制モード)に設定されています。ルートレスコンテナからNVIDIAドライバーへのアクセスを許可しようとすると、SELinuxを無効化するかカスタムポリシーを作成しない限り、permission deniedエラーが頻繁に発生します。
3. ハイブリッド構成(Ollama Native + Open WebUI Container)
このアプローチこそが最も実用的な解決策です。OllamaはRPM Fusionが提供する akmod-nvidia ドライバーを直接認識し、100%のレイヤーをvRAMへ確実にオフロードします。その一方で、依存関係が複雑なWebUIインターフェースは単一のPodmanコンテナ内に完全に隔離されます。
Fedoraワークステーションでハイブリッド構成を選ぶべき理由
FedoraをメインOSとして2年以上運用して実感したのは、このディストリビューションのカーネル更新サイクルの早さです。カーネルバージョンが上がるたび、akmodsによってNVIDIAモジュールが自動的に再ビルドされます。
Ollamaをネイティブ実行していれば、コンテナランタイムを破損することなく、サービスが新しいドライバーをスムーズに追従できます。OSをクリーンに保ちながら、デバイスパススルーに伴うSELinuxの煩雑な設定ストレスから完全に解放されます。
具体的な構築手順
ステップ1:RPM FusionからNVIDIAドライバーをインストール
まずは、システムがグラフィックボードを正しく認識しているか確認します。
nvidia-smi
新規インストール環境やオープンソースのNouveauドライバーが動作している場合は、DNF経由で公式ドライバーパッケージを導入します。
sudo dnf install -y akmod-nvidia xorg-x11-drv-nvidia-cuda
# akmodsによるカーネルモジュールのビルド完了を待機(通常2〜3分)してから再起動
sudo akmods --force
sudo reboot
ステップ2:Ollamaの導入とsystemdサービスの最適化
公式スクリプトを実行してOllamaをインストールします。
curl -fsSL https://ollama.com/install.sh | sh
初期状態のOllamaは内部ループバックアドレス 127.0.0.1:11434 のみでリッスンします。パフォーマンスを最大化し、WebUIとの通信を安全に許可するために、systemdのオーバーライドファイルを作成します。
sudo systemctl edit ollama.service
コメントアウトされている2行の間に、以下のチューニング設定を記述します。
[Service]
Environment="OLLAMA_HOST=127.0.0.1:11434"
Environment="OLLAMA_ORIGINS=*"
Environment="OLLAMA_FLASH_ATTENTION=1"
Environment="OLLAMA_KEEP_ALIVE=24h"
各フラグの実用上の効果:
OLLAMA_FLASH_ATTENTION=1: RTX 2000番台以降のアーキテクチャにおいて、8k〜32kトークンの長いコンテキスト処理時に約15%〜25%のvRAM消費を削減します。OLLAMA_KEEP_ALIVE=24h: モデルをvRAM上に常駐させます。一定時間チャットを行わなかった後でも、NVMe SSDからモデルを再読み込みする4〜6秒の待ち時間を排除できます。
設定を反映するためにデーモンをリロードします。
sudo systemctl daemon-reload
sudo systemctl restart ollama
ステップ3:モデルのダウンロードとCUDAオフロードの検証
動作確認用に定番モデルをプルします。ここでは qwen2.5:7b(Q4_K_M版:vRAM占有量 約4.7GB)を使用します。
ollama run qwen2.5:7b
別のターミナルウィンドウを開き、nvidia-smi を実行してください。テキスト生成中に ollama_llama_server プロセスがvRAMを確保し、GPU使用率が90%〜100%まで上昇していれば、GPUの認識は成功です。RTX 3060 12GB環境であれば、通常50〜65 tokens/sec前後の速度が得られます。
ステップ4:PodmanでOpen WebUIを起動
Fedoraには標準でPodmanが組み込まれているため、別途Dockerを追加する必要はありません。イメージ更新時にも会話履歴が保持されるよう、ボリュームを作成します。
podman volume create open-webui-data
podman run -d \
--name open-webui \
--network host \
-v open-webui-data:/app/backend/data:Z \
-e OLLAMA_BASE_URL=http://127.0.0.1:11434 \
--restart always \
ghcr.io/open-webui/open-webui:main
押さえておくべき2つの技術的ポイント:
- ボリュームの
:Zフラグ: 必須の指定です。このフラグにより、Podmanがボリュームに対して適切なSELinuxコンテキスト(container_file_t)を自動付与し、SQLiteデータベースへの予期せぬ Permission Denied エラーを完全に防止します。 --network hostフラグ: コンテナがホストのネットワーク名前空間を直接共有します。ブリッジネットワークの設定やfirewalldのポート開放を行うことなく、WebUIからOllamaの127.0.0.1:11434にダイレクト接続できます。
ステップ5:初期アカウントのセットアップ
ブラウザを起動し、http://localhost:8080 にアクセスします。最初に登録したアカウントが自動的に管理者権限(Admin)を持ちます。Settings > Models に移動すると、ダウンロード済みのモデルが一覧表示され、すぐに利用可能な状態になっていることが確認できます。
実務で役立つチューニングのヒント
- vRAM容量を超えるモデルの実行: 8GB vRAMのGPU(RTX 3070/4060など)で14Bモデル(約9GBのvRAMが必要)を動かす場合、Ollamaは自動的にレイヤーを分割し、一部をGPU、残りをシステムRAMへ退避させます。処理速度は12〜18 tokens/sec程度に低下しますが、問題なく動作します。
- モデル保存先の変更: デフォルトでは
/usr/share/ollama/.ollama/models(ルートパーティション配下)に保存されます。ルート容量が不足している場合は、systemdに環境変数Environment="OLLAMA_MODELS=/mnt/nvme-data/ollama_models"を追加して、セカンダリNVMeドライブなどへ逃がしてください。 - テレメトリ送信の無効化: 完全なプライバシー環境を維持したい場合は、Podmanの起動引数に
-e SCARF_NO_ANALYTICS=true -e DO_NOT_TRACK=trueを追加してください。

