Ollama und llama.cpp in Docker mit AMD Strix Halo, ROCm und Fedora 43

Zusammenfassung

In diesem Artikel wird beschrieben, wie man llama.cpp und Ollama unter Fedora 43 auf einem AMD Strix Halo System mit ROCm-Unterstützung zum Laufen bringt. Es werden die bekannten Probleme mit dem aktuellen Linux-Kernel 6.18, der AMD-Firmware und Docker-Berechtigungen auf der GPU behandelt.

Die Lösung umfasst:

• Downgrade des Linux-Kernels auf 6.17
• Downgrade der AMD-Firmware auf eine kompatible Version
• Konfiguration der korrekten Kernel-Parameter
• Berechtigungen für Docker-Container mit GPU-Zugriff

Einleitung

Bei der Einrichtung von llama.cpp und Ollama auf AMD-GPU-Systemen, insbesondere auf dem AMD Strix Halo, gibt es jedoch einige technische Herausforderungen, die man berücksichtigen muss.

In diesem Artikel werden wir die notwendigen Schritte durchgehen, um die Umgebung unter Fedora 43 aufzusetzen, wobei wir uns auf das ROCm-Stack konzentrieren. Andere Linux-Varianten benötigen etwas andere Vorgehen, oder funktionieren vielleicht sogar ohne zusätzliche Workarounds.

Hintergrund

ROCm und AMD-GPU-Treiber

ROCm (Radeon Open Compute Platform) ist eine Open-Source-Plattform zur GPU-Programmierung, die auch von AMD-GPUs unterstützt wird. Für die Ausführung von Modellen wie LLMs auf AMD-GPUs ist es notwendig, dass:

• Ein funktionierender AMD-Treiber (amdgpu) installiert ist
• Die Firmware kompatibel ist
• Docker-Container Zugriff auf die GPU-Devices haben ( /dev/kfd, /dev/dri/card*)

Probleme mit Kernel 6.18 und Firmware

In den letzten Versionen des Linux-Kernels (6.18) sowie der AMD-Firmware (MES) treten Probleme auf, die zu Abstürzen von llama.cpp und Ollama führen. Zum einen hat das Kernel Modul „amdxdna“ einen Fehler, und zum anderen ist die neueste offizielle AMD Firmwareversion 0x00000083 für MES nicht mit Linux kompatibel.

Vorbereitungen

Kernel-Parameter einstellen

Wir müssen einige Kernel-Parameter setzen, um den vollen RAM (128GB) eines Strix Halo Systems zu nutzen:

$ sudo grubby --update-kernel=ALL --args='amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432'

Wir können danach direkt überprüfen, ob die Parameter korrekt gesetzt worden sind:

$ sudo grubby --info=ALL | grep args                                                                                             
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
args="ro rhgb quiet mitigations=off amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"

Den Hintergrund zu den Einstellungen findet man unter anderem hier:

• https://community.frame.work/t/amd-strix-halo-llama-cpp-installation-guide-for-fedora-42/75856
• https://www.jeffgeerling.com/blog/2025/increasing-vram-allocation-on-amd-ai-apus-under-linux/
• https://blog.linux-ng.de/2025/07/13/getting-information-about-amd-apus/

Firmware-Probleme beheben

Die aktuelle Firmwareversion 0x00000083 von AMD ist nicht mit Linux kompatibel. Weitere Details findet man z.B. hier:

• https://bbs.archlinux.org/viewtopic.php?id=310497
• https://github.com/ROCm/ROCm/issues/5724
• https://github.com/kyuz0/amd-strix-halo-toolboxes/blob/main/docs/troubleshooting-firmware.md

Der folgende Befehl zeigt die aktuelle Firmware Version:

$ sudo cat /sys/kernel/debug/dri/128/amdgpu_firmware_info | grep MES
MES_KIQ feature version: 6, firmware version: 0x0000006f
MES feature version: 1, firmware version: 0x00000083

Falls hier unter „MES feature version“ die Firmware version „0x83“ angezeigt wird, wie oben, dann müssen wir auf eine ältere Version downgraden:

$ sudo dnf install amd-gpu-firmware-0:20251021-1.fc43
$ sudo dracut -f

Nach einem Neustart sollte die kompatible Version 0x80 installiert sein:

$ sudo cat /sys/kernel/debug/dri/128/amdgpu_firmware_info | grep MES
MES_KIQ feature version: 6, firmware version: 0x0000006f
MES feature version: 1, firmware version: 0x00000080

Kernel downgraden auf 6.17

Da der aktuelle Kernel 6.18 noch nicht alle Probleme leider einen Fehler in dem von ROCm benötigten „amdxdna“ Modul einhgeführt, müssen wir auf Kernel 6.17 zurückgreifen. Informationen findet man hier:

• https://lore.kernel.org/regressions/870872aa-28e9-412a-bac6-8020bf560e4f@amd.com/

Sobald der Fehler in der 6.18er Kernelversion behoben ist, können wir wieder einen aktuellen Kernel einsetzen.

$ sudo dnf install kernel-6.17.1-300.fc43.x86_64 kernel-devel-6.17.1-300.fc43

Falls man auf über akmod verwaltete zusätzliche Module angewiesen ist (z.B. für VirtualBox), dann muss man diese ggf auch noch bauen:

$ sudo akmods --kernels 6.17.1-300.fc43.x86_64 --rebuild

Um sicherzustellen, dass der ältere 6.17er Kernel bei dem nächsten Neustart auch verwendet wird, sollten wir mit grubby diesen als Vorgabewert festlegen:

$ sudo grubby --info=ALL
index=0
kernel="/boot/vmlinuz-6.18.7-200.fc43.x86_64"
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
root="UUID=3efbd456-93ef-4137-8d64-086e3350362b"
initrd="/boot/initramfs-6.18.7-200.fc43.x86_64.img $tuned_initrd"
title="Fedora Linux (6.18.7-200.fc43.x86_64) 43 (Workstation Edition)"
id="ff402323dc314daf9777a1840e96601e-6.18.7-200.fc43.x86_64"
index=1
kernel="/boot/vmlinuz-6.18.6-200.fc43.x86_64"
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
root="UUID=3efbd456-93ef-4137-8d64-086e3350362b"
initrd="/boot/initramfs-6.18.6-200.fc43.x86_64.img $tuned_initrd"
title="Fedora Linux (6.18.6-200.fc43.x86_64) 43 (Workstation Edition)"
id="ff402323dc314daf9777a1840e96601e-6.18.6-200.fc43.x86_64"
index=2
kernel="/boot/vmlinuz-6.17.1-300.fc43.x86_64"
args="ro rhgb quiet mitigations=off $tuned_params amd_iommu=off amdgpu.gttsize=131072 ttm.pages_limit=33554432"
root="UUID=3efbd456-93ef-4137-8d64-086e3350362b"
initrd="/boot/initramfs-6.17.1-300.fc43.x86_64.img $tuned_initrd"
title="Fedora Linux (6.17.1-300.fc43.x86_64) 43 (Workstation Edition)"
id="ff402323dc314daf9777a1840e96601e-6.17.1-300.fc43.x86_64"

In diesem Fall oben ist der Eintrag mit dem Index „2“ der erwünschte Kernel. Diesen können wir wie folgt als Vorgabewert festlegen:

$ sudo grubby --set-default-index 2
The default is /boot/loader/entries/ff402323dc314daf9777a1840e96601e-6.17.1-300.fc43.x86_64.conf with index 2 and kernel /boot/vmlinuz-6.17.1-300.fc43.x86_64

Jetzt noch einmal neustarten, und dann können wir verifizieren, dass wir einen 6.17er Kernel verwenden:

$ uname -a
Linux strix 6.17.1-300.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Mon Oct  6 15:37:21 UTC 2025 x86_64 GNU/Linux

Docker-Konfiguration für Ollama und llama.cpp

Nun können wir und endlich an die Konfiguration der beiden Anwendungen Ollama und llama.cpp machen. Als erstes müssen wir sicherstellen, dass Docker-Container Zugriff auf die GPU-Devices haben. Hierfür müssen wir die Berechtigungen über passende Gruppenmitgliedschaften vergeben.

Wir halten uns dabei ein wenig an die offizielle Dokumentation von AMD (https://rocm.docs.amd.com/projects/install-on-linux/en/latest/install/3rd-party/llama-cpp-install.html), die allerdings von einem Ubuntu System als Host-System ausgejt.

Die Gruppen sind letztlich einfache numerische IDs sind, und die Zuordnung von IDs zu Namen erfolgt über eine einfache Textdatei /etc/group. Nur kann diese Textdatei und damit die Zuordnung auf dem Host System und in dem Docker-Container abweichen, weshalb es am besten ist, dass wir die numerischen IDs auf dem Hostsystem ermitteln

Gruppen-IDs ermitteln

$ ls -lnd /dev/kfd /dev/dri/card*
crw-rw----+ 1 0  39 226, 1  4. Feb 19:27 /dev/dri/card1
crw-rw-rw-. 1 0 105 235, 0  4. Feb 19:27 /dev/kfd

In diesem Fall sind die benötigten Gruppen-IDs die 39 und 105.

Docker Compose für llama.cpp

Die folgende beispielhafte docker-compose.yml Datei für llama.cpp fragt nach 10 einfachen Schritten, um eine Webseite zu bauen. Natürlich ist dieser Anwendungsfall nur zum Test, ob llama.cpp funktioniert, und ob auch die Beschleunigung mit ROCm verwendet wird:

services:
  llamacpp:
    image: rocm/llama.cpp:llama.cpp-b6652.amd0_rocm7.0.0_ubuntu24.04_full
    container_name: llamacpp
    read_only: true
    command:
      - "--run"
      - "-m"
      - "/data/granite-3b-code-base-2k-Q4_K_M-GGUF/granite-3b-code-base-2k-q4_k_m.gguf"
      - "-p"
      - "'Building a website can be done in 10 simple steps:'"
      - "-n"
      - "512"
      - "-fa"
      - "on"
      - "--n-gpu-layers" 
      - "999"
    ports:
      - 8000:8000
    devices:
      - /dev/kfd
      - /dev/dri
    group_add:
      - video
      - 39
      - 105
      - render
    volumes:
      - ./data:/data
      - type: tmpfs
        target: /tmp

Nun kann der Container gestartet werden:

$ docker compose up
Attaching to llamacpptach
llamacpp  | ggml_cuda_init: GGML_CUDA_FORCE_MMQ:    no
llamacpp  | ggml_cuda_init: GGML_CUDA_FORCE_CUBLAS: no
llamacpp  | ggml_cuda_init: found 1 ROCm devices:
[...]
llamacpp  | 'Building a website can be done in 10 simple steps:' +
llamacpp  | 				'Choose a template from the list (10s), upload your content (20s), and preview (5s).' +
llamacpp  | 				'So, your website is ready in 40s - that is why we offer free website building.' +
llamacpp  | 				'Now, you have a great opportunity to create your own website for free. ' +
[...]
llamacpp  | llama_perf_sampler_print:    sampling time =       8.84 ms /   526 runs   (    0.02 ms per token, 59515.73 tokens per second)
llamacpp  | llama_perf_context_print:        load time =     628.53 ms
llamacpp  | llama_perf_context_print: prompt eval time =      31.36 ms /    14 tokens (    2.24 ms per token,   446.44 tokens per second)
llamacpp  | llama_perf_context_print:        eval time =    7566.82 ms /   511 runs   (   14.81 ms per token,    67.53 tokens per second)
llamacpp  | llama_perf_context_print:       total time =    7619.04 ms /   525 tokens
llamacpp  | llama_perf_context_print:    graphs reused =        508
llamacpp  | llama_memory_breakdown_print: | memory breakdown [MiB] |  total     free    self   model   context   compute    unaccounted |
llamacpp  | llama_memory_breakdown_print: |   - ROCm0 (Graphics)   | 131072 = 119266 + (3413 =  2032 +    1280 +     101) +        8392 |
llamacpp  | llama_memory_breakdown_print: |   - Host               |                     111 =    98 +       0 +      13                |
llamacpp exited with code 0

Ollama

Die folgende docker-compose.yml Datei konfiguriert Ollama zur Nutzung von ROCm:

services:
  ollama:
    image: ollama/ollama:0.15.2-rocm
    container_name: ollama
    read_only: true
    restart: unless-stopped
    cpuset: 0-15
    environment:
      - OLLAMA_NUM_PARALLEL=1
      - OLLAMA_MAX_LOADED_MODELS=2
      - OLLAMA_CONTEXT_LENGTH=32768
      - OLLAMA_KEEP_ALIVE=720m
      - OLLAMA_KV_CACHE_TYPE=q8_0
      - OLLAMA_FLASH_ATTENTION=1
    ports:
      - 11434:11434
    devices:
      - /dev/kfd
      - /dev/dri
    group_add:
      - 39
      - 105
    volumes:
      - data:/root/.ollama
      - type: tmpfs
        target: /tmp

volumes:
  data:

Der Container kann analog gestartet werden:

$ docker compose up                                                                                        8.6s
[+] up 2/2
 ✔ Network ollama_default Created                                                                                                 0.0s
 ✔ Container ollama       Created                                                                                                 0.1s
Attaching to ollama
ollama  | time=2026-02-04T18:38:47.824Z level=INFO source=routes.go:1631 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.ffm.dimajix.net:8080 HTTP_PROXY:http://proxy.ffm.dimajix.net:8080 NO_PROXY:*.ffm.dimajix.net,127.0.0.0/8 OLLAMA_CONTEXT_LENGTH:32768 OLLAMA_DEBUG:INFO OLLAMA_FLASH_ATTENTION:true OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://0.0.0.0:11434 OLLAMA_KEEP_ALIVE:12h0m0s OLLAMA_KV_CACHE_TYPE:q8_0 OLLAMA_LLM_LIBRARY: OLLAMA_LOAD_TIMEOUT:5m0s OLLAMA_MAX_LOADED_MODELS:2 OLLAMA_MAX_QUEUE:512 OLLAMA_MODELS:/root/.ollama/models OLLAMA_MULTIUSER_CACHE:false OLLAMA_NEW_ENGINE:false OLLAMA_NOHISTORY:false OLLAMA_NOPRUNE:false OLLAMA_NUM_PARALLEL:1 OLLAMA_ORIGINS:[http://localhost https://localhost http://localhost:* https://localhost:* http://127.0.0.1 https://127.0.0.1 http://127.0.0.1:* https://127.0.0.1:* http://0.0.0.0 https://0.0.0.0 http://0.0.0.0:* https://0.0.0.0:* app://* file://* tauri://* vscode-webview://* vscode-file://*] OLLAMA_REMOTES:[ollama.com] OLLAMA_SCHED_SPREAD:false OLLAMA_VULKAN:false ROCR_VISIBLE_DEVICES: http_proxy:http://proxy.ffm.dimajix.net:8080 https_proxy:http://proxy.ffm.dimajix.net:8080 no_proxy:localhost,127.0.0.0/8,10.0.0.0/8,172.16.0.0/12,192.168.0.0/16,169.254/16,ffm.dimajix.net,cloud.dimajix.net,kimai.dimajix.net]"
ollama  | time=2026-02-04T18:38:47.916Z level=INFO source=images.go:473 msg="total blobs: 134"
ollama  | time=2026-02-04T18:38:47.920Z level=INFO source=images.go:480 msg="total unused blobs removed: 0"
ollama  | time=2026-02-04T18:38:47.924Z level=INFO source=routes.go:1684 msg="Listening on [::]:11434 (version 0.15.2)"
[...]

Ob Ollama auch tatsächlich funktioniert, können wir einfach über eine Abfrage im Docker Container testen:

$ docker exec -ti ollama bash -c "OLLAMA_HOST= ollama run qwen3-coder:30b"                                                        8.8s
>>> Hello!
Hello! It's nice to meet you! How can I help you today?

Ergebnis

Nach erfolgreicher Einrichtung können wir mit beiden Tools LLMs auf der GPU ausführen:

• llama.cpp: Lädt ein Modell und führt eine Prompt-Abfrage aus.
• Ollama: Startet einen Server und ermöglicht das Laden und Ausführen von Modellen über REST-API.

Beide Tools nutzen die GPU- und NPU-Ressourcen und zeigen eine gute Performance.

Fazit

In diesem Artikel haben wir gesehen, wie man llama.cpp und Ollama unter Fedora 43 auf einem AMD Strix Halo System zum Laufen bringt. Die Herausforderungen lagen in:

• Fehlerhaftem Kernelmodul in Linux 6.18
• Inkompatible Firmware-Versionen von AMD
• Notwendigkeit von Berechtigungen für Docker-Container

Die Lösung umfasst:

• Downgrade des Kernels auf 6.17
• Downgrade der AMD-Firmware
• Korrekte Konfiguration von Docker mit Zugriff auf /dev/kfd und /dev/dri