Ollama-Modelle auf die NVMe legen

TL;DR

Das Installationsskript legt die Modelle unter /usr/share/ollama/.ollama/models. Das ist oft die Systemplatte. Ein dichtes 70B in Q4 braucht allein für die Gewichte etwa 35–40 GB, jedes weitere Modell kommt dazu. Die Variable OLLAMA_MODELS zeigt auf die NVMe. Sie muss in der systemd-Unit stehen, nicht in der Shell des Administrators. Der Nutzer ollama braucht Schreibrecht auf dem Ziel, einschließlich der Elternordner.

Platte wählen: NVMe oder SATA. Größe des Modells: 2 GPUs für 70B.

Wohin der Dienst schreibt

Die Ollama-FAQ nennt drei Defaults:

Unter Linux ist /usr/share/ollama das Home des Dienstnutzers. Eine Variable in ~/.bashrc des Administrators sieht der Dienst nicht. Er startet über systemd, mit eigener Umgebung.

Pfad in der Unit setzen

Ollama beschreibt das Setzen von Umgebungsvariablen so: systemctl edit ollama.service, dann unter [Service] eine Environment-Zeile, danach Daemon neu laden und den Dienst starten.

[Service]
Environment="OLLAMA_MODELS=/mnt/nvme/ollama-models"

sudo mkdir -p /mnt/nvme/ollama-models
sudo chown -R ollama:ollama /mnt/nvme/ollama-models
sudo systemctl daemon-reload
sudo systemctl restart ollama

chown steht so in der FAQ. Der Zielordner muss dem Nutzer ollama gehören.

Zwei Fehler kommen immer wieder, beide aus dem Rechtepfad und nicht aus der Variable selbst:

• Der Pfad liegt unter /home/…. Home-Verzeichnisse sind oft 750. Der Nutzer ollama kommt nicht hinein, auch wenn der letzte Ordner ihm gehört.
• Ollama legt fehlende Elternordner selbst an. Gehört /mnt/nvme root und ist nicht beschreibbar, scheitert schon das Anlegen, obwohl ollama-models korrekt gehört wurde.

Der Mountpunkt der Platte ist der Pfad in der Unit. Ein Symlink aus dem Home auf die NVMe zeigt auf einen Ort, den der Dienst nicht betreten darf.

Bereits geladene Modelle bleiben im alten Ordner. Sie umziehen per Kopie, oder sie werden nach dem Neustart neu gezogen. Der Dienst liest nicht beide Orte gleichzeitig.

Warum die zweite Platte NVMe ist

Der Flaschenhals ist das einmalige Laden in den GPU-Speicher, nicht die Tokenrate danach. Eine SATA-Platte verlängert diesen Start. Die NVMe kürzer. Der Vergleich der Busse steht im Beitrag zu NVMe und SATA. Die Systemplatte bleibt für Ubuntu und Docker. Die Modellplatte ist austauschbar, ohne das System neu zu installieren.

Backup der Konfiguration ist ein anderes Verzeichnis als die Modellblobs. Modelle lassen sich neu ziehen. Ein angepasstes Modelfile und die Vektordaten nicht. Dafür reicht diese Pfadänderung nicht.