「新しいモデルを追加するたびに全台にpullし直すのが手間で、チームのサーバー台数が増えるほど管理コストが上がっている」
そんな課題を抱えるLinuxサーバー管理者は多いはずです。この記事では、NFS（Network File System）を使ってOllamaのモデルファイルを1か所に集約し、複数のOllamaサーバーで共有する構成手順を解説します。モデルのダウンロードは1回・保管はNFSサーバー1台だけで済み、クラスター全体のストレージ効率が大幅に改善します。Ubuntu Server上でのNFSサーバー構築からOllamaへのパス設定、systemdの依存関係設定まで一通り説明します。
この記事のポイント
・OLLAMA_MODELS環境変数でモデルパスを変更すれば、NFS上のモデルをそのまま使える
・NFSサーバー側の設定は /etc/exports へのエントリ追加とnfs-kernel-serverの起動だけ
・systemdのAfter=とRequires=でNFSマウントをOllama起動前に保証し、起動順のトラブルを防ぐ
・モデル追加作業を「書き込み許可サーバー1台」に集中させるポリシーで整合性を保つ
でも安心してください。プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
NFSでOllamaモデルを共有する仕組みと利点
OllamaはデフォルトでモデルファイルをOSごとに決まったディレクトリ（Linux: `~/.ollama/models` または `/usr/share/ollama/.ollama/models`）に保存します。このパスは環境変数 `OLLAMA_MODELS` で任意の場所に変更できます。NFS共有の仕組みはシンプルです。NFSサーバーがモデルディレクトリをエクスポートし、各OllamaサーバーがそのディレクトリをNFSマウントで読み込む。あとは `OLLAMA_MODELS` をNFSマウントポイントに向けるだけです。Ollama自体はモデルがローカルにあるかNFSにあるかを意識しません。
利点は3つあります。1つ目はストレージ効率です。70Bモデルのq4量子化（`llama3.3:70b-instruct-q4_0`）は約40GBを超えます。これを10台のサーバーで個別に持てば400GB以上消費しますが、NFS共有なら1か所40GBで済みます。2つ目は運用効率です。`ollama pull` をNFSサーバー側で1回実行すれば、全クライアントで即座に利用可能になります。3つ目は一貫性です。全サーバーが同じモデルファイルを参照するため、バージョンの食い違いが発生しません。
Ollamaの基盤環境がまだ整っていない場合は、先にUbuntu ServerでローカルLLMを構築する完全ガイドでOllamaをインストールしてから本記事に進んでください。
前提環境の確認とネットワーク要件
1. サーバー構成を確認する
本手順では以下の構成を前提とします。 NFSサーバー: Ollamaモデルを保管する専用（または兼用）サーバー。IPアドレス例: 192.168.1.10Ollamaサーバー（クライアント）: NFSをマウントしてOllamaを実行するサーバー群。IPアドレス例: 192.168.1.21、192.168.1.22
NFSサーバーはOllamaを動かす必要はありません。ファイルサーバーとして機能するだけなので、スペックが低いサーバーやNASを流用できます。モデルの読み込みはOllamaクライアント側が行います。
2. ネットワーク帯域を確認する
NFS経由のモデル読み込みにはネットワーク帯域が影響します。典型的なケースでは1Gbpsの内部ネットワークであれば実用的な速度で動作します。モデルのロード（Ollamaが最初にモデルをメモリに読み込む）は数秒から数十秒かかりますが、一度ロードが完了すれば推論はサーバーのRAM/VRAMで実行されるため、NFS帯域は推論速度には影響しません。# ネットワーク帯域の確認（iperf3が必要） # NFSサーバー側でサーバーモードで起動 $ iperf3 -s # Ollamaクライアント側でテスト実行 $ iperf3 -c 192.168.1.10 Connecting to host 192.168.1.10, port 5201 ... [ ID] Interval Transfer Bitrate [ 5] 0.00-10.00 sec 1.10 GBytes 944 Mbits/sec sender [ 5] 0.00-10.00 sec 1.09 GBytes 937 Mbits/sec receiver
NFSサーバーを構築してモデルディレクトリをエクスポートする
1. nfs-kernel-serverをインストールする
# NFSサーバーにパッケージをインストール $ sudo apt update && sudo apt install -y nfs-kernel-server $ sudo systemctl status nfs-server * nfs-server.service - NFS server and services Loaded: loaded (/lib/systemd/system/nfs-server.service; enabled) Active: active (running)
2. モデル保管ディレクトリを作成する
NFSでエクスポートするディレクトリを作成し、適切な所有者を設定します。# モデル保管ディレクトリを作成 $ sudo mkdir -p /srv/ollama/models $ sudo chown nobody:nogroup /srv/ollama/models $ sudo chmod 755 /srv/ollama/models $ ls -la /srv/ollama/ total 12 drwxr-xr-x 3 root root 4096 Oct 11 07:00 . drwxr-xr-x 3 root root 4096 Oct 11 07:00 .. drwxr-xr-x 2 nobody nogroup 4096 Oct 11 07:00 models
3. /etc/exportsにエクスポート設定を追加する
`/etc/exports` にNFSクライアントのIP範囲とオプションを記述します。# /etc/exports の末尾に追記（sudo で編集） /srv/ollama/models 192.168.1.0/24(rw,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534) # 設定を反映する $ sudo exportfs -ra $ sudo exportfs -v /srv/ollama/models 192.168.1.0/24(sync,wdelay,hide,no_subtree_check,anonuid=65534,anongid=65534,sec=sys,rw,root_squash,all_squash)
4. ファイアウォールにNFSを許可する
# ufw を使用している場合 $ sudo ufw allow from 192.168.1.0/24 to any port nfs $ sudo ufw status Status: active To Action From -- ------ ---- 2049/tcp ALLOW 192.168.1.0/24
OllamaクライアントサーバーでNFSマウントを設定する
以降の手順は、Ollamaが稼働する全クライアントサーバーで実施します。1. nfs-commonをインストールする
# クライアントサーバーにNFSクライアントパッケージをインストール $ sudo apt update && sudo apt install -y nfs-common $ sudo showmount -e 192.168.1.10 Export list for 192.168.1.10: /srv/ollama/models 192.168.1.0/24
2. マウントポイントを作成して手動マウントを確認する
# マウントポイントを作成 $ sudo mkdir -p /mnt/ollama-models # 手動マウントで到達確認 $ sudo mount -t nfs 192.168.1.10:/srv/ollama/models /mnt/ollama-models $ df -h | grep ollama 192.168.1.10:/srv/ollama/models 500G 320G 180G 64% /mnt/ollama-models $ ls /mnt/ollama-models blobs manifests
# 確認後に手動マウントを解除 $ sudo umount /mnt/ollama-models
3. /etc/fstabに永続マウントを設定する
`/etc/fstab` に追記して再起動後もマウントが維持されるようにします。# /etc/fstab の末尾に追記（sudo で編集） 192.168.1.10:/srv/ollama/models /mnt/ollama-models nfs defaults,_netdev,nofail,timeo=30,retrans=3 0 0 # fstabの設定を適用してマウントを確認 $ sudo mount -a $ df -h | grep ollama 192.168.1.10:/srv/ollama/models 500G 320G 180G 64% /mnt/ollama-models
OllamaのモデルパスをNFSマウント先に向ける
1. systemdのoverride.confでOLLAMA_MODELSを設定する
Ollamaをsystemdサービスとして動かしている場合、`OLLAMA_MODELS` 環境変数はoverride.confに設定します。# override.confを作成（または編集） $ sudo mkdir -p /etc/systemd/system/ollama.service.d $ sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF' [Service] Environment="OLLAMA_MODELS=/mnt/ollama-models" EOF # デーモンを再読み込みしてOllamaを再起動 $ sudo systemctl daemon-reload $ sudo systemctl restart ollama $ sudo systemctl status ollama * ollama.service - Ollama Service Active: active (running) $ ollama list NAME ID SIZE MODIFIED llama3.3:8b-instruct-q4_0 e8e4eb21ab0c 4.9 GB 3 days ago mistral:7b-instruct-q4_0 2ae6f6dd7a3d 4.1 GB 5 days ago
モデルの種類と量子化タグの選び方についてはローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイントで詳しく解説しています。NFS共有するモデルを選定する際に参照してください。
systemdでNFSマウントをOllama起動前に保証する
1. After=とRequires=の依存関係を設定する
`/etc/fstab` の `_netdev` だけでは、OllamaサービスがNFSマウントの完了を待たずに起動してしまうことがあります。systemdのユニットファイルに依存関係を明示します。# override.confに起動順序の依存関係を追加（既存のEnvironment行と合わせて書く） $ sudo tee /etc/systemd/system/ollama.service.d/override.conf << 'EOF' [Unit] After=network-online.target mnt-ollama\x2dmodels.mount Requires=mnt-ollama\x2dmodels.mount [Service] Environment="OLLAMA_MODELS=/mnt/ollama-models" EOF $ sudo systemctl daemon-reload $ sudo systemctl restart ollama
社内でのローカルLLM活用の判断軸については社内でChatGPTが使えないときの代替手段も参照してください。NFS共有のような中央集権型インフラが情シスのコスト削減に貢献する観点が整理されています。
読み取り専用と読み書きの使い分け
モデルの追加・削除（`ollama pull` / `ollama rm`）はファイルの書き込みを伴います。全サーバーに `rw` を付けると、複数台が同時にモデルをダウンロードしようとした場合にファイルの整合性が壊れる危険があります。典型的なケースでは「書き込み許可は1台のみ」という運用ポリシーを取ります。`/etc/exports` を以下のように分けることで制御できます。管理用サーバー（192.168.1.21）だけが `rw`、残りのOllamaサーバーは `ro`（読み取り専用）に設定します。
# /etc/exports — 管理サーバーだけrw、他はro /srv/ollama/models 192.168.1.21(rw,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534) /srv/ollama/models 192.168.1.22(ro,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534) /srv/ollama/models 192.168.1.23(ro,sync,no_subtree_check,all_squash,anonuid=65534,anongid=65534) $ sudo exportfs -ra && sudo exportfs -v
よくあるトラブルと対処法
**【マウント失敗: access denied / permission denied】**NFSサーバー側の `/etc/exports` にクライアントIPが含まれていない可能性があります。`sudo exportfs -v` でエクスポート一覧を確認し、クライアントIPまたはサブネットが含まれているか確認します。IPアドレスをサブネットではなく個別指定している場合、`/24` のCIDR表記と個別IP表記を混在させないようにしてください。
**【Ollamaがモデルを認識しない（ollama listが空）】**
`OLLAMA_MODELS` の設定が反映されていない可能性があります。`sudo systemctl cat ollama` で実際にロードされている環境変数を確認します。`OLLAMA_MODELS` が表示されない場合、`sudo systemctl daemon-reload && sudo systemctl restart ollama` を実行してください。
**【サーバー再起動後にOllamaが起動しない（NFSマウントが間に合わない）】**
`After=mnt-ollama\x2dmodels.mount` が設定されていないか、マウントユニット名が間違っている可能性があります。`sudo systemctl list-units --type=mount | grep ollama` で正確なユニット名を取得し、override.confに反映します。
**【推論が極端に遅い（NFS越しの読み込みが遅い）】**
モデルのロード（NFS→メモリ）はネットワーク速度に依存します。一度ロードされた後の推論はRAMやGPU内で完結するため遅くなりません。ロード自体が遅い場合は `rsize=1048576,wsize=1048576` をfstabのマウントオプションに追加してNFSの読み取りサイズを大きくすることで改善することがあります。
**【モデルファイルが壊れる（不完全なダウンロード）】**
複数のサーバーが同時に同じモデルを `ollama pull` しようとすると、NFSの書き込みが競合してファイルが破損することがあります。「モデル追加は管理サーバー1台のみ」のポリシーで防止してください。破損したモデルは `ollama rm モデル名` で削除し、管理サーバーで `ollama pull` で取り直します。
まとめ
本記事で設定したOllamaのNFSモデル共有構成を整理します。| 項目 | コマンド・設定 | 目的 |
|---|---|---|
| NFSサーバーインストール | sudo apt install -y nfs-kernel-server | モデル配布元の構築 |
| エクスポート設定 | /etc/exports に rw/ro オプション付きで追記 | 書き込み制御とクライアント範囲指定 |
| エクスポート反映 | sudo exportfs -ra | exports変更の即時反映 |
| クライアントインストール | sudo apt install -y nfs-common | OllamaサーバーへのNFSクライアント追加 |
| 永続マウント設定 | /etc/fstab に _netdev,nofail オプション付きで追記 | 再起動後もマウントを維持 |
| Ollamaモデルパス変更 | override.conf に Environment="OLLAMA_MODELS=/mnt/ollama-models" を追加 | OllamaにNFSモデルを認識させる |
| 起動順序の保証 | After=とRequires=にNFSマウントユニットを追加 | NFSマウント前のOllama起動を防止 |
NFS共有を含むOllamaクラスター構築を2日間のハンズオンで体験する
複数サーバーへのOllamaデプロイ、NFSによるモデル共有、LiteLLMプロキシによるチームAPI管理まで、実際のクラスター構成をゼロから組み立てる実習が含まれています。実機GPU環境で手を動かしながら習得したい方向けに、「ローカルAIマスターセミナー」を開催しています。
少人数（最大8名）ZOOMハンズオン形式で実施しています。
・Ubuntu ServerでローカルLLMを構築する方法｜Ollamaで機密データを外に出さず業務AIを動かす完全ガイド
・社内でChatGPTが使えないときの代替手段｜機密データを守るローカルLLMという選択肢
・ローカルLLMのモデルを比較する方法｜Llama3.3・Mistral・Gemma・Phi-4をUbuntuで使い分けるポイント
3,100名以上が実践した「型」を無料で公開中
プロのエンジニアはコマンドを暗記していません。
「現場で使える型」を効率よく使いこなしているだけです。
その「型」を図解60Pにまとめた入門マニュアルを、完全無料でプレゼントしています。
姓・名・メールの3つだけ／30秒／解除は3秒 ／ 詳細はこちら
この記事を書いた人
宮崎 智広（みやざき ともひろ）
株式会社イーネットマーキュリー代表。現役のLinuxサーバー管理者として20年以上の実務経験を持ち、これまでに累計3,100名以上のエンジニアを指導してきたLinux教育のプロフェッショナル。「現場で本当に使える技術」を体系的に伝えることをモットーに、実践型のLinuxセミナーの開催や無料マニュアルの配布を通じてLinux人材の育成に取り組んでいる。
趣味は、キャンプにカメラ、トラウト釣り。好きな食べ物は、ラーメンにお酒。休肝日が作れない、酒量を減らせないのが悩み。最近、ドラマ「フライトエンジェル」を観て涙腺が崩壊しました。
- 前のページへ：OllamaでPDFをローカル処理する方法｜pypdfとPythonでテキスト抽出・要約・質問応答を社内サーバーで完結させる手順
- この記事の属するカテゴリ：ローカルLLMへ戻る
無料メルマガで学習を続ける
Linuxの実践スキルをメールで毎週お届け。
登録は30秒、解除もいつでも可。
登録無料・いつでも解除できます