Ollama CPU-fallback detection cannot fire on AMD systems

Author: chriscrosstalkCreated Sep 14, 2026Updated Sep 14, 2026

Problem

v1.35.0-rc.1 added log-based detection for Ollama silently falling back to CPU, so that GPU passthrough auto-remediation can fire. The detector itself handles ROCm correctly, but the provider that calls it returns early unless the NVIDIA runtime is registered. As a result the detection never runs on an AMD system.

Evidence

A server with an AMD Phoenix1 iGPU on v1.35.0-rc.1, configured for ROCm and silently running CPU-only:

ollama image : ollama/ollama:rocm
devices      : /dev/kfd, /dev/dri   (both passed into the container)
ollama log   : msg="inference compute" id=cpu library=cpu    <-- CPU-only
gpuHealth    : {"status":"ok","hasNvidiaRuntime":false,
                "hasRocmRuntime":false,"ollamaGpuAccessible":true}

The admin log on that same box:

[GpuPassthroughRemediationProvider] No NVIDIA runtime registered — skipping.

So the one machine that is actually falling back to CPU is the one the detection skips.

For contrast, a second AMD box (Radeon 890M) on the same release is genuinely accelerated and reports honestly — library=ROCm compute=gfx1150, hasRocmRuntime: true. Both report status: "ok" and ollamaGpuAccessible: true, so there is nothing in the UI to distinguish the working box from the broken one.

Root cause

admin/providers/gpu_passthrough_remediation_provider.ts requires the NVIDIA runtime before reading the Ollama logs. admin/app/services/ollama_compute.ts already matches library=(CUDA|ROCm|Vulkan) → gpu and library=cpu → cpu, so the detector is vendor-neutral; only the caller's guard is not.

Suggested fix

Gate the provider on "a GPU runtime is expected" rather than specifically NVIDIA — i.e. run when either hasNvidiaRuntime or hasRocmRuntime is true, or when the Ollama container was created with /dev/kfd / /dev/dri devices or a ROCm image tag, since hasRocmRuntime is false on exactly the broken case above.

Related

This overlaps the broader gpuHealth false-positive behaviour (#1325), where status: "ok" and ollamaGpuAccessible: true are asserted without a probe. That has now been observed on ARM, Intel and AMD hardware. This issue is narrower: the new detection added in v1.35.0-rc.1 does not cover the AMD case it appears to cover.

Files involved

  • admin/providers/gpu_passthrough_remediation_provider.ts — the NVIDIA-only guard
  • admin/app/services/ollama_compute.ts — the detector (already vendor-neutral)
  • admin/app/services/system_service.tsgpuHealth assembly

Source: Crosstalk-Solutions/project-nomad