Ollama kann GPU in Docker auf QNAP nicht nutzen (RTX 3090, CUDA-Initialisierung schlägt fehl)

Igorgogi · 12. April 2026 um 12:20

Hallo zusammen,

ich versuche, Ollama mit GPU-Beschleunigung innerhalb von Docker auf meinem QNAP NAS auszuführen, aber es fällt immer auf die CPU zurück. Ich habe schon einiges an Debugging betrieben und würde mich über jeden Rat oder eine Bestätigung freuen, ob dies eine bekannte Einschränkung ist.

Mein Setup

QTS: 5.2.9
Kernel: 5.10.60-qnap
GPU: NVIDIA GeForce RTX 3090
NVIDIA-Treiber (QPKG): 575.64.05
Treibertyp: NVIDIA Open Kernel Module
Docker: Container Station + CLI (--gpus all)

Was funktioniert

nvidia-smi funktioniert auf dem Host (über Container)
nvidia-smi funktioniert innerhalb von Containern
/dev/nvidia* Geräte sind vorhanden
NVIDIA-Module geladen:

nvidia
nvidia_uvm
nvidia_modeset
nvidia_drm

GPU-Passthrough zu Containern scheint also zu funktionieren.

Was NICHT funktioniert

Ollama erkennt die GPU nicht und nutzt immer die CPU:

inference compute id=cpu library=cpu
total_vram="0 B"

Obwohl die GPU verfügbar ist.

Was ich getestet habe

1. Verschiedene Ollama-Versionen

0.20.6-rc1
0.20.5
0.19.0

→ gleiches Ergebnis (nur CPU)

2. CUDA-Bibliotheken

Innerhalb des Containers sind CUDA-Bibliotheken vorhanden:

/usr/lib/ollama/cuda_v12/libcudart.so.12
/usr/lib/ollama/cuda_v12/libcublas.so.12
/usr/lib/ollama/cuda_v12/libcublasLt.so.12

Anfangs zeigte ldd fehlende Bibliotheken, aber nach Setzen von:

LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/cuda_v12:/usr/lib/x86_64-linux-gnu

→ alle Abhängigkeiten werden korrekt aufgelöst.

3. Scheitert trotzdem

Trotzdem schlägt die CUDA-Initialisierung in Ollama fehl:

ggml_cuda_init: failed to initialize CUDA: initialization error

4. Kernel-Logs (das sieht verdächtig aus)

NVRM: nvCheckOkFailedNoLog: Check failed: Out of memory [NV_ERR_NO_MEMORY]
NVRM: faultbufCtrlCmdMmuFaultBufferRegisterNonReplayBuf_IMPL: Error allocating client shadow fault buffer

Mein aktueller Stand

Es sieht so aus, als ob:

GPU-Passthrough funktioniert (Docker-Seite OK)
CUDA-Bibliotheken sind vorhanden
aber CUDA-Initialisierung zur Laufzeit fehlschlägt

Da ich das NVIDIA Open Kernel Module verwende, vermute ich:

es unterstützt in dieser Umgebung möglicherweise keine CUDA-Workloads vollständig

oder es gibt ein Kompatibilitätsproblem mit dem QNAP-Kernel (5.10.60)

Fragen

Hat jemand erfolgreich Ollama (oder eine andere CUDA-intensive App) mit GPU auf QNAP ausgeführt?
Ist das eine bekannte Einschränkung des NVIDIA Open Kernel Module auf QNAP?
Ist es möglich, den proprietären NVIDIA-Treiber statt des Open Modules zu verwenden?
Hat jemand solche NV_ERR_NO_MEMORY-Fehler schon einmal gesehen?

Workaround

Aktuell überlege ich:

Ollama auf einer separaten Linux-Maschine (Debian/Ubuntu) laufen zu lassen
und QNAP nur für UI/Services zu verwenden

marcoi · 12. April 2026 um 18:07

Wenn du eine Docker-Compose-Datei verwendest, füge Folgendes zum Abschnitt „ollama“ hinzu.

    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all 
              capabilities: [gpu]

OliverLam · 14. April 2026 um 08:40

Hallo, was meinst du mit:

Docker: Container Station + CLI

nvidia-smi funktioniert auf dem Host (über Container)

===

Bitte folge diesen Schritten, um dein Problem zu überprüfen:

Erfasse die GPU-Einstellungen im Kontrollpanel.
image2514×1496 294 KB

Verwende diese YAML-Datei, um eine neue Anwendung in Container Station zu erstellen.

services:
  ollama:
    image: ollama/ollama:latest
    volumes:
      - ollama:/root/.ollama
    restart: unless-stopped
    environment:
      - OLLAMA_SCHED_SPREAD=1
    ports:
      - 11434:11434
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all 
              capabilities: [gpu] 
volumes:
  ollama:

Öffne ein Terminal in deinem neuen Ollama-Container und gib nvidia-smi ein, um zu überprüfen, ob die NVIDIA-GPU erkannt wird.

Igorgogi · 15. April 2026 um 17:08

Hallo,

vielen Dank. Mit:

„Docker: Container Station + CLI“
meine ich, dass ich beides getestet habe:

Container, die über QNAP Container Station erstellt wurden
Container, die manuell über die Docker CLI gestartet wurden

Zur Klarstellung:

nvidia-smi existiert nicht als nativer Befehl in der QNAP-Shell,
funktioniert aber korrekt innerhalb von Docker-Containern, die mit GPU-Zugriff gestartet wurden.

Ich werde nun dein vorgeschlagenes minimales Container-Station-Setup testen und prüfen:

nvidia-smi innerhalb des Containers
ob Ollama beim Start weiterhin nur die CPU erkennt

Mein ursprüngliches Problem ist, dass Ollama oft meldet, dass nur die CPU verwendet wird, selbst wenn die GPU im Container sichtbar ist:

inference compute id=cpu library=cpu
total_vram="0 B"

und manchmal:

ggml_cuda_init: failed to initialize CUDA: initialization error

Ich werde die Ergebnisse deines YAML-Tests berichten.

SteveKo · 17. April 2026 um 10:01

Wir vermuten derzeit, dass dieses Problem möglicherweise auch durch einen Fehler bei der Speicherzuweisung im Treiber verursacht wird. Wir werden entsprechend ein Update veröffentlichen, das auf den neuen Treiber abzielt. Wir entschuldigen uns für etwaige Unannehmlichkeiten, die dadurch entstanden sein könnten!

Tom1964 · 18. April 2026 um 05:44

Für mich sieht es so aus, dass nach einem Neustart ollama + GPU genutzt werden können. Nach einiger GPU-Leerlaufzeit ist die GPU in ollama jedoch nicht mehr ansprechbar. Interessanterweise wird sie dann in QTS sichtbar und emby (.qpkg, nicht die Container-Version) kann sie verwenden. Und das, obwohl die GPU eigentlich dem Container und NICHT QTS zugewiesen ist.

Wie kann das sein?

Tom1964 · 18. April 2026 um 14:41

Nach mehreren Versuchen kann ich ebenfalls nicht mehr auf die GPU im Container zugreifen, um Ollama mit der GPU zum Laufen zu bringen. Sogar nvidia-smi funktioniert in der Ollama-Konsole. Gleiche Konfiguration wie bei Igorgogi. Aber Ollama kann den verfügbaren VRAM der GPU nicht erkennen und entscheidet sich daher für die Nutzung der CPU. Es wird ein sehr kleines LLM-Modell ausgewählt. Verfügbarer VRAM: 12GB

±----------------------------------------------------------------------------------------+
| Processes: |
| GPU GI CI PID Type Process name GPU Memory |
| ID ID Usage |
|=========================================================================================|
| No running processes found |
±----------------------------------------------------------------------------------------+

Ollama Log:

\033]11;?\033\time=2026-04-18T14:24:46.098Z level=INFO source=routes.go:1752 msg=“server config” env=“map[CUDA_VISIBLE_DEVICES: GGML_VK_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES: HSA_OVERRIDE_GFX_VERSION: HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_CONTEXT_LENGTH:0 OLLAMA_DEBUG:INFO OLLAMA_DEBUG_LOG_REQUESTS:false OLLAMA_EDITOR: OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:xxx OLLAMA_KEEP_ALIVE:5m0s OLLAMA_KV_CACHE_TYPE: OLLAMA_LLM_LIBRARY:cuda OLLAMA_LOAD_TIMEOUT:5m0s OLLAMA_MAX_LOADED_MODELS:0 OLLAMA_MAX_QUEUE:512 OLLAMA_MODELS:/root/.ollama/models OLLAMA_MULTIUSER_CACHE:false OLLAMA_NEW_ENGINE:false OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NO_CLOUD:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:xxx app://* file://* tauri://* vscode-webview://* vscode-file://*] OLLAMA_REMOTES:[ollama.com] OLLAMA_SCHED_SPREAD:true OLLAMA_VULKAN:false ROCR_VISIBLE_DEVICES: http_proxy: https_proxy: no_proxy:]”

time=2026-04-18T14:24:46.103Z level=INFO source=types.go:60 msg=“inference compute” id=cpu library=cpu compute=“” name=cpu description=cpu libdirs=ollama driver=“” pci_id=“” type=“” total=“31.3 GiB” available=“25.7 GiB”

time=2026-04-18T14:24:46.102Z level=INFO source=routes.go:1810 msg=“Listening on [::]:11434 (version 0.20.7)”

time=2026-04-18T14:24:46.102Z level=INFO source=images.go:506 msg=“total unused blobs removed: 0”

time=2026-04-18T14:24:46.101Z level=INFO source=images.go:499 msg=“total blobs: 25”

time=2026-04-18T14:24:46.103Z level=INFO source=runner.go:67 msg=“discovering available GPUs…”

time=2026-04-18T14:24:46.103Z level=INFO source=routes.go:1860 msg=“vram-based default context” total_vram=“0 B” default_num_ctx=4096

xBenny · 4. Mai 2026 um 18:33

Hallo, ich kann ein sehr ähnliches Problem auf meinem QNAP bestätigen — gleicher Treiber, gleiches QTS, andere GPU.

Meine Konfiguration:

NAS: QNAP TS-673A - 32 GB RAM
GPU: RTX 3050 OC Low Profile 6G (GA107)
QTS: 5.2.9 / Kernel: 5.10.60-qnap
NVIDIA-Treiber: 575.64.05 (Open Kernel Module)
CUDA: 12.9
Docker über Container Station, runtime: nvidia-runtime

Container, die die GPU nutzen:

Jellyfin — NVENC-Hardware-Transkodierung
go-vod — NVENC für Nextcloud Memories Videobearbeitung

Beide Container verwenden runtime: nvidia-runtime mit NVIDIA_VISIBLE_DEVICES auf die GPU-UUID gesetzt und NVIDIA_DRIVER_CAPABILITIES=compute,video,utility. Kein privileged: true, keine manuelle Geräte-Einbindung — nvidia-runtime übernimmt das automatisch.

Was funktioniert (zumindest anfangs):

nvidia-smi auf dem Host und im Container ✓
NVENC-Hardware-Encoding in Jellyfin ✓
NVENC in go-vod für Nextcloud Memories ✓

Nach einer Phase der Inaktivität schlägt die CUDA-Initialisierung plötzlich in allen GPU-Containern fehl — Jellyfin und go-vod funktionieren dann gleichzeitig nicht mehr. Ein kompletter NAS-Neustart ist die einzige zuverlässige Lösung. Das Neustarten der Container bringt nichts.

Ich habe alles ausprobiert, was ich finden konnte:

nvidia-smi -pm 1 (Persistenzmodus) — keine Wirkung
privileged: true — führte zu Startproblemen
manuelles Geräte-Mounten — kein Effekt
cgroupfs-Treiber in der docker.json — leichte Verbesserung

Ich habe seit fast einem Monat ein Support-Ticket bei QNAP offen. Die einzigen Antworten waren, dass „daran gearbeitet wird“ — kein ETA, kein Workaround, keine konkreten Infos. Es ist extrem frustrierend, da dies ein klar reproduzierbares Problem ist, das mehrere Nutzer mit unterschiedlichen GPUs in diversen Forenthreads betrifft.

Jase001 · 10. Mai 2026 um 13:36

Mögliche Lösung, bis ein Treiber-Workaround von QNAP veröffentlicht wird

Ich hatte genau das gleiche Problem – es hat mich fast in den Wahnsinn getrieben! Ollama und Open WebUI laufen im Container Station, eine RTX 3060 12GB GPU ist durchgereicht (passthrough). Jedes Mal, wenn Ollama nach der ersten Nutzung in den Leerlauf ging, wurde standardmäßig auf die CPU umgeschaltet, obwohl die GPU laut nvidia-smi als verfügbar angezeigt wurde – es gab keine Möglichkeit, die GPU ohne einen Neustart des Containers wieder online zu bekommen.

Am Ende habe ich Ollama auf eine NVME umgezogen und seither funktioniert alles einwandfrei – selbst ein schneller Modellwechsel führt dazu, dass das neue Modell in die GPU geladen und praktisch sofortige Ergebnisse geliefert werden. Wenn Ollama in den Leerlauf geht, entlastet die GPU wie gewohnt, aber sobald ich einen Chat starte, springt die GPU an und alles läuft sofort. Nach meiner Erfahrung war Ollama einfach zu langsam, wenn es auf einer NAS-HDD (Ironwolf) installiert war, und deshalb hat sich die GPU deaktiviert und die CPU wurde genutzt.

Ich hoffe, das hilft anderen in der Zwischenzeit weiter!

achimede333 · 10. Mai 2026 um 20:42

Hallo,

ich habe das gleiche Problem wie du (RTX Pro 4000 Blackwell), egal ob es um das RAG in Qsirch oder in einem Ollama-Container geht. Es kommt häufig, aber unregelmäßig vor (nicht immer nach der gleichen Wartezeit), dass das Modell statt der GPU die CPU nutzt. Ich habe dazu ebenfalls ein Support-Ticket eröffnet (warte noch auf eine Antwort).

Ich entdecke Ollama jetzt seit ein paar Tagen und lerne gerade die grundlegenden Befehle kennen, aber ich kann nicht herausfinden, woher das Problem kommt.

Bei mir liegen alle Anwendungen, Container und Modelle auf RAID-SSDs.

xBenny · 10. Mai 2026 um 21:42

Meine Container liegen dauerhaft auf SSD, daher ist das für mich keine Option. Ich habe seit einem Monat ein Ticket offen und bisher nur die Rückmeldung erhalten, dass daran gearbeitet wird. Ich habe weitere Informationen nachgetragen, aber bislang keine Antwort erhalten.

NA9D · 10. Mai 2026 um 22:18

Frag immer wieder nach, was mit dem Ticket los ist…

xBenny · 11. Mai 2026 um 17:42

Antwort vom 7.5. ist …

Hallo

Danke für deine Rückmeldung, bitte habe etwas Geduld, unser Entwicklungsteam braucht etwas Zeit für dieses Problem.

Momentan arbeitet unser Entwicklungsteam noch daran.

Sobald es Neuigkeiten von ihnen gibt, werde ich dich umgehend informieren. Vielen Dank.

heymrdj · 5. Juni 2026 um 14:22

Ich habe seit etwa Januar das gleiche Problem, nachdem das Firmware-Update herauskam, das eine manuelle Neuinstallation des Nvidia-Treibers erforderlich machte. Ich habe Q-202606-32810 eröffnet, um eine weitere Anlaufstelle für Logs oder Ähnliches bereitzustellen, um das Problem zu lösen, da ich allmählich Schwierigkeiten im Workflow bekomme, wenn die CPU-Auslastung auf 100% steigt, sobald auf sie statt auf CUDA zurückgegriffen wird.

heymrdj · 8. Juni 2026 um 14:17

Ich kann bestätigen, dass das Upgrade auf QuTS Hero 6.0 (und das zugehörige NvKernel-Treiber-Update) mein Problem gelöst hat. Diejenigen, mit denen ich zusammengearbeitet habe, konnten etwa 2 Millionen Assets über OCR laufen lassen, die Prozesse beenden, sodass die GPU in den Leerlauf ging, die Modelle wechseln und dann am Wochenende mehrere andere Workloads ohne Probleme ausführen. Heute Morgen wurden Jobs gestartet, nachdem etwa 18 Stunden keine Jobs gelaufen waren, und die Modelle wurden problemlos geladen, anstatt mir die GPU-Fehler zu melden.

achimede333 · 8. Juni 2026 um 15:02

Leider war ich in meinem Fall zum Zeitpunkt meiner ersten Beiträge bereits in der Beta von QuTS Hero 6, mit den neuesten Treibern, und der Umstieg auf die finale Version hat nichts verändert. Ich habe immer noch einen Wechsel von der GPU zur CPU. Allerdings habe ich eine „Verbesserung“ festgestellt, und das könnte an einem Speicherüberlauf auf der Seite des Modells liegen. Ich werde das in den nächsten Tagen weiter beobachten.
Hinweis: Mein Support-Ticket wurde ohne Unterstützung geschlossen.

xBenny · 8. Juni 2026 um 18:21

Ich habe die Antwort unten gefunden. Ich habe es ausprobiert, zuerst hat es nichts gebracht. Ich musste das NAS neu starten, aber auch das hat nicht geholfen, es wurde sogar schlimmer und das System konnte die Grafikkarte nicht nutzen. Dann habe ich den NvKernelDriver neu installiert und plötzlich hat alles funktioniert. Es sind jetzt 5 Stunden vergangen und alles läuft. Mal sehen, wie es morgen aussieht…

Hi

Unser Entwicklungsteam bietet eine vorübergehende Lösung an.

Bitte greifen Sie per SSH auf das NAS zu und führen Sie folgenden Befehl aus:

# sync; echo 3 > /proc/sys/vm/drop_caches

Starten Sie anschließend die Anwendung neu. Falls das Problem weiterhin besteht, sollte ein kompletter Neustart helfen.

Vielen Dank.

xBenny · 9. Juni 2026 um 10:49

Nach ein paar Stunden ist das Problem wieder da, also ist das nicht einmal eine temporäre Lösung.