Docker compose组合运行Ollama
在 在Docker中Ollama使用AMD GPU运行大模型 能够很轻松地运行起Ollama,不过需要手工一一去启动不同用途的容器,例如 Grafana通用可视分析平台 Prometheus监控 。所以,选择 Docker Compose 来调度和启动容器组合,则会方便很多。
Docker compose运行
创建
docker-compose.yml组合docker容器:
ROCm 5.7services:
# 1. Ollama 服务 (AMD ROCm)
ollama-amd:
image: ollama/ollama:0.1.29-rocm
container_name: ollama-amd
restart: unless-stopped
ports:
- "11435:11434"
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 关键新增参数 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在两块 MI50 上
- OLLAMA_MAX_LOADED_MODELS=1 # 针对大模型,限制同时加载的模型数,防止抢显存
- OLLAMA_FLASH_ATTENTION=true # 建议:AMD 显卡开启可节省大量显存
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
ulimits: # 允许容器锁定内存,防止 GPU 驱动初始化失败
memlock: -1
stack: 67108864
# --- 必须保留,否则新内核会拦截 GFX906 的底层指令 ---
privileged: true
devices:
# --- 显式映射计算端口和渲染节点,防止容器内驱动扫描不存在的显示设备 ---
- /dev/kfd:/dev/kfd
- /dev/dri/renderD128:/dev/dri/renderD128
- /dev/dri/renderD129:/dev/dri/renderD129
volumes:
- ollama_data:/root/.ollama
# 2. Open WebUI
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama-amd:11434
depends_on:
- ollama-amd
# 3. AMD GPU Exporter (监控核心)
# 注意:这需要宿主机安装了 ROCm 驱动,因为它要读取物理 GPU 数据
amdgpu-exporter:
image: rocm/device-metrics-exporter:v1.4.2
container_name: amdgpu-exporter
restart: unless-stopped
ports:
- "5000:5000"
devices:
- /dev/dri:/dev/dri
- /dev/kfd:/dev/kfd
# 4. Prometheus (时序数据库)
prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
# 5. Grafana (可视化面板)
grafana:
image: grafana/grafana:latest
container_name: grafana
restart: unless-stopped
ports:
- "3001:3000"
depends_on:
- prometheus
volumes:
ollama_data:
open-webui_data:
备注
这里的配置是经过反复排查和验证后得到的可行配置,详细排查见下文 docker compose运行Ollama异常排查
上述配置中 Prometheus监控 需要引用一个
prometheus.yml配置来抓取GPU数据:
global:
scrape_interval: 5s # 每5秒抓取一次,实现实时监控
scrape_configs:
- job_name: 'gpu_metrics'
static_configs:
- targets: ['amdgpu-exporter:5000']
启动:
docker compose up -d
此时会看到docker并行拉取容器运行的各个镜像,如果没有报错,则最后同时启动Ollama以及Open WebUI和 Grafana通用可视分析平台 Prometheus监控
配置grafana
访问 http://服务器IP:3001 (默认账号密码均为 admin),首次登录会提示修改密码
添加数据源:
Connections -> Data Sources选择
Prometheus,在URL中填入http://prometheus:9090,然后点击Save & Test
导入面板:
点击右上角
+号 ->Import,搜索AMD GPU专用的ID(可以从Grafana官方的dashboard分发网站查找)
配合Open WebUI
访问 http://服务器IP:3000 Open WebUI创建的第一个用户帐号是管理员帐号,请为自己设置一个帐号
验证连接
点击页面左下角的
个人头像/用户名选择
Settings(设置) -> Connections,应该看到有一个Ollama API的配置,指向的是http://ollama-amd:11434也就是前面docker-compose.yml中配置,点击配置按钮,并点刷新,此时验证正常就说明连接成功
加载模型
在 Settings -> Models 中可以交互方式加载模型(选择 Manage ),可以直接输入Ollama官网的模型名称进行下载: llama3.3:70b-instruct-q4_K_M 举例。这个下载支持断点续传,如果下载意外中断,重试会继续进行(不过如果容器被杀死再下载模型还得重头开始)
下载指定模型,例如 llama3.3:70b-instruct-q4_K_M
docker compose运行Ollama异常排查
我最初采用的 docker-compose.yml 使用了默认最新的 ollama 镜像, docker-compose.yml 配置如下:
docker-compose.ymlservices:
# 1. Ollama 服务 (AMD ROCm)
ollama-amd:
image: ollama/ollama:rocm
container_name: ollama-amd
restart: unless-stopped
ports:
- "11435:11434"
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
devices:
- /dev/kfd:/dev/kfd
- /dev/dri:/dev/dri
volumes:
- ollama_data:/root/.ollama
# 2. Open WebUI
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama-amd:11434
depends_on:
- ollama-amd
# 3. AMD GPU Exporter (监控核心)
# 注意:这需要宿主机安装了 ROCm 驱动,因为它要读取物理 GPU 数据
amdgpu-exporter:
image: rocm/device-metrics-exporter:v1.4.2
container_name: amdgpu-exporter
restart: unless-stopped
ports:
- "5000:5000"
devices:
- /dev/dri:/dev/dri
- /dev/kfd:/dev/kfd
# 4. Prometheus (时序数据库)
prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
# 5. Grafana (可视化面板)
grafana:
image: grafana/grafana:latest
container_name: grafana
restart: unless-stopped
ports:
- "3001:3000"
depends_on:
- prometheus
volumes:
ollama_data:
open-webui_data:
但是,启动运行后发现运行 llama3.3:70b-instruct-q4_K_m 模型时发现 AMD MI50 两块GPU完全没有负载,而CPU疯狂运算。gemini提示虽然设置了正确的 HSA_OVERRIDE_GFX_VERSION ,但是对于70B大模型需要防范几个问题:
70B 模型在 Q4 量化下约占 42GB。Ollama 默认可能认为单块 MI50(32GB)装不下,或者因为你没有设置 并行显卡参数,导致它放弃 GPU 直接回退到 CPU
修订 docker-compose.yml 的环境变量,在 ollama-amd 的 environment 中添加以下关键项:
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 新增以下内容 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在多块显卡上
- OLLAMA_INTEL_GPU=0 # 屏蔽可能干扰的集成显卡
- HIP_VISIBLE_DEVICES=0,1 # 显式指定使用的两块 GPU 编号
内存锁限(Memlock)配置: 对于 MI50 这种级别的高性能计算卡,容器需要能够锁定内存以进行高效的 DMA 传输。如果 Docker 限制了内存锁定,Ollama 的 ROCm 后端可能会初始化失败
在 ollama-amd 服务下添加 ulimits:
ollama-amd:
# ... 其他配置 ...
ulimits:
memlock: -1
stack: 67108864
修改配置以后销毁容器(docker compose提供了down命令):
docker compose down
注意, docker compose down 会停止并删除当前YAML文件中定义的所有容器、网络。由于模型文件(数据)保存在 valumes 中,所以不会丢失
重新启动:
docker compose up -d
检查容器日志:
docker logs ollama-amd 2>&1 | grep -iE "gpu|rocm|total"
发现检测GPU失败:
time=2026-02-23T12:55:23.976Z level=INFO source=routes.go:1663 msg="server config" env="map[CUDA_VISIBLE_DEVICES: GGML_VK_VISIBLE_DEVICES: GPU_DEVICE_ORDINAL: HIP_VISIBLE_DEVICES:0,1 HSA_OVERRIDE_GFX_VERSION:9.0.6 HTTPS_PROXY: HTTP_PROXY: NO_PROXY: OLLAMA_CONTEXT_LENGTH:0 OLLAMA_DEBUG:INFO OLLAMA_EDITOR: OLLAMA_FLASH_ATTENTION:false OLLAMA_GPU_OVERHEAD:0 OLLAMA_HOST:http://0.0.0.0:11434 OLLAMA_KEEP_ALIVE:5m0s OLLAMA_KV_CACHE_TYPE: OLLAMA_LLM_LIBRARY: 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:[* 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:true OLLAMA_VULKAN:false ROCR_VISIBLE_DEVICES: http_proxy: https_proxy: no_proxy:]"
time=2026-02-23T12:55:23.977Z level=INFO source=images.go:473 msg="total blobs: 6"
time=2026-02-23T12:55:23.977Z level=INFO source=images.go:480 msg="total unused blobs removed: 0"
time=2026-02-23T12:55:23.978Z level=INFO source=runner.go:67 msg="discovering available GPUs..."
time=2026-02-23T12:55:23.978Z level=WARN source=runner.go:489 msg="if GPUs are not correctly discovered, unset and try again"
time=2026-02-23T12:55:43.395Z level=INFO source=runner.go:464 msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-9332612173497dfc]" error="runner crashed"
time=2026-02-23T12:55:44.849Z level=INFO source=runner.go:464 msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-6a92216172f0fcb5]" error="runner crashed"
time=2026-02-23T12:55:44.850Z 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="755.4 GiB" available="755.4 GiB"
time=2026-02-23T12:55:44.850Z level=INFO source=routes.go:1768 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096
这说明直接设置 HIP_VISIBLE_DEVICES:0,1 反而导致了Docker 内部,ROCm 有时会因为 PCI ID 的映射问题产生混淆:
删除
HIP_VISIBLE_DEVICES:0,1删除
ROCR_VISIBLE_DEVICES(如果有手动设置)
并添加一个debug参数:
services:
ollama-amd:
image: ollama/ollama:rocm
container_name: ollama-amd
restart: unless-stopped
# 临时使用 root 用户运行,排除权限崩溃
user: root
ports:
- "11435:11434"
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
ulimits:
memlock: -1
stack: 67108864
# 关键:透传所有渲染节点,有些 MI50 需要访问 /dev/dri/renderD128 之外的控制节点
privileged: true
devices:
- /dev/kfd:/dev/kfd
- /dev/dri:/dev/dri
volumes:
- ollama_data:/root/.ollama
volumes:
ollama_data:
神奇啊 发现居然是 privileged: true 生效后解决了问题,现在 docker logs ollama-amd 看到日志似乎正常了:
privileged: true 之后日志似乎正常了...
time=2026-02-23T13:11:42.583Z level=DEBUG source=runner.go:146 msg="verifying if device is supported" library=/usr/lib/ollama/rocm description="AMD Radeon Graphics" compute=gfx906 id=GPU-6a92216172f0fcb5 pci_id=0000:0d:00.0
time=2026-02-23T13:11:42.583Z level=DEBUG source=runner.go:146 msg="verifying if device is supported" library=/usr/lib/ollama/rocm description="AMD Radeon Graphics" compute=gfx906 id=GPU-9332612173497dfc pci_id=0000:86:00.0
time=2026-02-23T13:11:42.584Z level=INFO source=server.go:431 msg="starting runner" cmd="/usr/bin/ollama runner --ollama-engine --port 39295"
time=2026-02-23T13:11:42.584Z level=DEBUG source=server.go:432 msg=subprocess PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin OLLAMA_DEBUG=1 OLLAMA_HOST=0.0.0.0 OLLAMA_ORIGINS=* HSA_OVERRIDE_GFX_VERSION=9.0.6 LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 OLLAMA_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm ROCR_VISIBLE_DEVICES=GPU-9332612173497dfc GGML_CUDA_INIT=1
time=2026-02-23T13:11:42.584Z level=INFO source=server.go:431 msg="starting runner" cmd="/usr/bin/ollama runner --ollama-engine --port 35923"
time=2026-02-23T13:11:42.584Z level=DEBUG source=server.go:432 msg=subprocess PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin OLLAMA_DEBUG=1 OLLAMA_HOST=0.0.0.0 OLLAMA_ORIGINS=* HSA_OVERRIDE_GFX_VERSION=9.0.6 LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 OLLAMA_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm ROCR_VISIBLE_DEVICES=GPU-6a92216172f0fcb5 GGML_CUDA_INIT=1
这说明确实需要 privileged: true ,那么结合上面所述,配置应该修订为:
...
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 关键新增参数 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在两块 MI50 上
- OLLAMA_MAX_LOADED_MODELS=1 # 针对大模型,限制同时加载的模型数,防止抢显存
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
ulimits: # 允许容器锁定内存,防止 GPU 驱动初始化失败
memlock: -1
stack: 67108864
privileged: true
...
上述修订完成后,再次运行,发现还是无法将模型运行在GPU上
这就需要排查Ollama是如何评估模型加载的: Ollama 有一个“自我保护”机制:如果它计算出 模型权重 + KV Cache(上下文) 超过了可用显存的 90%,它会为了防止 OOM(显存溢出)而直接放弃 GPU,转向 CPU。
70B 模型约 42GB,双卡 64GB。如果你在 WebUI 里的上下文(num_ctx)默认设置得很大(比如默认 32k),KV Cache 会吃掉剩下的所有显存。
解决方法: 强制限制上下文长度
在 Open WebUI 中,不要直接提问。
点击模型选择框旁边的 “设置/控制”图标。
找到 Advanced Parameters (高级参数)。
找到 GPU Layers (num_gpu) ,设置 81 表示将所有层都加入GPU: Llama 3.3-70B (Q4_K_M) 的层数通常是 81 层(80层 Transformer + 1层 Output)
找到 Context Length (num_ctx),手动输入 4096 或 8192。
再次尝试提问,观察 rocm-smi。
警告
问题尚未解决,待继续排查
目前发现操作系统启动以后,容器启动后系统有大量的 [kworker/22:21+events] 的进程是D状态。怀疑Docker容器没有正确挂载物理服务器设备(/dev/kfd 和 /dev/dri)
排查没有识别AMD GPU
我仔细观察了 docker logs ollama-amd 输出日志:
time=2026-03-14T14:02:00.036Z level=INFO source=runner.go:67 msg="discovering available GPUs..."
time=2026-03-14T14:02:00.036Z level=WARN source=runner.go:485 msg="user overrode visible devices" HSA_OVERRIDE_GFX_VERSION=9.0.6
time=2026-03-14T14:02:00.036Z level=WARN source=runner.go:489 msg="if GPUs are not correctly discovered, unset and try again"
time=2026-03-14T14:02:00.047Z level=INFO source=server.go:431 msg="starting runner" cmd="/usr/bin/ollama runner --ollama-engine --port 34193"
time=2026-03-14T14:02:00.049Z level=DEBUG source=server.go:432 msg=subprocess PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin OLLAMA_SCHED_SPREAD=true OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_FLASH_ATTENTION=true OLLAMA_DEBUG=1 OLLAMA_HOST=0.0.0.0 OLLAMA_ORIGINS=* HSA_OVERRIDE_GFX_VERSION=9.0.6 LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 OLLAMA_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm
time=2026-03-14T14:02:03.444Z level=DEBUG source=runner.go:437 msg="bootstrap discovery took" duration=3.407844412s OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs=map[]
time=2026-03-14T14:02:03.444Z level=DEBUG source=runner.go:124 msg="evaluating which, if any, devices to filter out" initial_count=2
time=2026-03-14T14:02:03.444Z level=DEBUG source=runner.go:146 msg="verifying if device is supported" library=/usr/lib/ollama/rocm description="AMD Radeon Graphics" compute=gfx906 id=GPU-6a92216172f0fcb5 pci_id=0000:0d:00.0
time=2026-03-14T14:02:03.444Z level=DEBUG source=runner.go:146 msg="verifying if device is supported" library=/usr/lib/ollama/rocm description="AMD Radeon Graphics" compute=gfx906 id=GPU-9332612173497dfc pci_id=0000:86:00.0
time=2026-03-14T14:02:03.444Z level=INFO source=server.go:431 msg="starting runner" cmd="/usr/bin/ollama runner --ollama-engine --port 35989"
time=2026-03-14T14:02:03.445Z level=DEBUG source=server.go:432 msg=subprocess PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin OLLAMA_SCHED_SPREAD=true OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_FLASH_ATTENTION=true OLLAMA_DEBUG=1 OLLAMA_HOST=0.0.0.0 OLLAMA_ORIGINS=* HSA_OVERRIDE_GFX_VERSION=9.0.6 LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 OLLAMA_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm ROCR_VISIBLE_DEVICES=GPU-9332612173497dfc GGML_CUDA_INIT=1
time=2026-03-14T14:02:03.445Z level=INFO source=server.go:431 msg="starting runner" cmd="/usr/bin/ollama runner --ollama-engine --port 33271"
time=2026-03-14T14:02:03.446Z level=DEBUG source=server.go:432 msg=subprocess PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin OLLAMA_SCHED_SPREAD=true OLLAMA_MAX_LOADED_MODELS=1 OLLAMA_FLASH_ATTENTION=true OLLAMA_DEBUG=1 OLLAMA_HOST=0.0.0.0 OLLAMA_ORIGINS=* HSA_OVERRIDE_GFX_VERSION=9.0.6 LD_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm:/usr/local/nvidia/lib:/usr/local/nvidia/lib64 OLLAMA_LIBRARY_PATH=/usr/lib/ollama:/usr/lib/ollama/rocm ROCR_VISIBLE_DEVICES=GPU-6a92216172f0fcb5 GGML_CUDA_INIT=1
time=2026-03-14T14:02:06.889Z level=INFO source=runner.go:464 msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-9332612173497dfc]" error="runner crashed"
time=2026-03-14T14:02:06.890Z level=DEBUG source=runner.go:437 msg="bootstrap discovery took" duration=3.445504905s OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-9332612173497dfc]"
time=2026-03-14T14:02:06.890Z level=DEBUG source=runner.go:153 msg="filtering device which didn't fully initialize" id=GPU-9332612173497dfc libdir=/usr/lib/ollama/rocm pci_id=0000:86:00.0 library=ROCm
time=2026-03-14T14:02:08.574Z level=INFO source=runner.go:464 msg="failure during GPU discovery" OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-6a92216172f0fcb5]" error="runner crashed"
time=2026-03-14T14:02:08.574Z level=DEBUG source=runner.go:437 msg="bootstrap discovery took" duration=5.128695412s OLLAMA_LIBRARY_PATH="[/usr/lib/ollama /usr/lib/ollama/rocm]" extra_envs="map[GGML_CUDA_INIT:1 ROCR_VISIBLE_DEVICES:GPU-6a92216172f0fcb5]"
time=2026-03-14T14:02:08.574Z level=DEBUG source=runner.go:153 msg="filtering device which didn't fully initialize" id=GPU-6a92216172f0fcb5 libdir=/usr/lib/ollama/rocm pci_id=0000:0d:00.0 library=ROCm
time=2026-03-14T14:02:08.574Z level=DEBUG source=runner.go:40 msg="GPU bootstrap discovery took" duration=8.54474583s
time=2026-03-14T14:02:08.574Z 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="755.4 GiB" available="755.1 GiB"
time=2026-03-14T14:02:08.574Z level=INFO source=routes.go:1768 msg="vram-based default context" total_vram="0 B" default_num_ctx=4096
日志的第8,9行显示Ollama尝试使用 /usr/lib/ollama/rocm 来测试两块GPU卡是否支持;但是很不幸,后续日志显示测试名利出现 runner crashed (第14,17行日志)。这导致Ollama放弃使用GPU,转而采用CPU架构(第21行日志)
我检查Host主机 dmesg 日志,发现有关于 amdgpu 的日志错误:
[ 29.296253] [drm:amddrm_sched_entity_push_job [amd_sched]] *ERROR* Trying to push to a killed entity
[ 29.296382] [drm:amddrm_sched_entity_push_job [amd_sched]] *ERROR* Trying to push to a killed entity
[ 32.624021] evm: overlay not supported
[ 77.208518] systemd-journald[890]: /var/log/journal/23ad7a2782044325b13a337fcb6a4a4a/user-1000.journal: Journal file uses a different sequence number ID, rotating.
[ 252.183832] INFO: task kworker/0:0:8 blocked for more than 122 seconds.
[ 252.184309] Tainted: P OE 6.8.0-106-generic #106-Ubuntu
[ 252.184337] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 252.184366] task:kworker/0:0 state:D stack:0 pid:8 tgid:8 ppid:2 flags:0x00004000
[ 252.184377] Workqueue: events amdgpu_tlb_fence_work [amdgpu]
[ 252.185286] Call Trace:
[ 252.185290] <TASK>
[ 252.185297] __schedule+0x27c/0x6b0
[ 252.185312] schedule+0x33/0x110
[ 252.185318] schedule_timeout+0x157/0x170
[ 252.185327] dma_fence_default_wait+0x1e1/0x220
[ 252.185336] ? __pfx_dma_fence_default_wait_cb+0x10/0x10
[ 252.185343] dma_fence_wait_timeout+0x116/0x140
[ 252.185351] amdgpu_tlb_fence_work+0x29/0x140 [amdgpu]
[ 252.186049] process_one_work+0x184/0x3a0
[ 252.186060] worker_thread+0x306/0x440
[ 252.186067] ? __pfx_worker_thread+0x10/0x10
[ 252.186072] kthread+0xf2/0x120
[ 252.186083] ? __pfx_kthread+0x10/0x10
[ 252.186091] ret_from_fork+0x47/0x70
[ 252.186101] ? __pfx_kthread+0x10/0x10
[ 252.186111] ret_from_fork_asm+0x1b/0x30
[ 252.186121] </TASK>
[ 252.186125] INFO: task kworker/0:1:10 blocked for more than 122 seconds.
[ 252.186154] Tainted: P OE 6.8.0-106-generic #106-Ubuntu
[ 252.186181] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
[ 252.186207] task:kworker/0:1 state:D stack:0 pid:10 tgid:10 ppid:2 flags:0x00004000
[ 252.186215] Workqueue: events amdgpu_tlb_fence_work [amdgpu]
[ 252.186919] Call Trace:
[ 252.186921] <TASK>
[ 252.186925] __schedule+0x27c/0x6b0
[ 252.186933] schedule+0x33/0x110
[ 252.186940] schedule_timeout+0x157/0x170
[ 252.186946] dma_fence_default_wait+0x1e1/0x220
[ 252.186952] ? __pfx_dma_fence_default_wait_cb+0x10/0x10
[ 252.186958] dma_fence_wait_timeout+0x116/0x140
[ 252.186964] amdgpu_tlb_fence_work+0x29/0x140 [amdgpu]
[ 252.187652] process_one_work+0x184/0x3a0
[ 252.187659] worker_thread+0x306/0x440
[ 252.187665] ? __pfx_worker_thread+0x10/0x10
[ 252.187670] kthread+0xf2/0x120
[ 252.187678] ? __pfx_kthread+0x10/0x10
[ 252.187685] ret_from_fork+0x47/0x70
[ 252.187692] ? __pfx_kthread+0x10/0x10
[ 252.187700] ret_from_fork_asm+0x1b/0x30
[ 252.187708] </TASK>
[ 252.187789] INFO: task kworker/0:2:308 blocked for more than 122 seconds.
[ 252.187818] Tainted: P OE 6.8.0-106-generic #106-Ubuntu
[ 252.187845] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
...
上述日志是启动 ollama-amd 容器后出现的(我对比了关闭容器启动后,上述报错不再出现),那么这里为何会出现 [drm:amddrm_sched_entity_push_job [amd_sched]] *ERROR* Trying to push to a killed entity
Google Gemini提出的改进建议主要有:
既然物理主机
rocm-smi正常,但是运行容器就触发内核报错Trying to push to a killed entity,这说明 ROCm驱动与Docker容器在硬件抽象层(Hardware Abstraction Layer)的握手失败我以为可能需要安装 AMD Container Toolkit ,不过AMD的ROCm容器主要依赖内核驱动(KFD/DRM)的直接透传,和 NVIDIA Container Toolkit 不同不需要处理复杂的库映射,所以这里并不需要安装
amd container toolkitgemini提示我当前使用的 Ubuntu 24.04 内核 6.8 可能太新,而 MI50(GFX906)属于较老的硬件架构,在处理容器级硬件重置时存在严重的同步问题
为了能够兼容旧硬件,添加特定的硬件访问环境变量来规避内核调度错误,修订
docker-compose.yml:
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 关键:针对老卡在新内核上的稳定性补丁 ---
- HSA_ENABLE_SDMA=0 # 禁用某些可能导致 D 状态进程的 DMA 引擎
- ROC_ENABLE_PRE_VEGA=1 # 确保对 GFX9 架构的兼容性
# --- 关键新增参数 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在两块 MI50 上
- OLLAMA_MAX_LOADED_MODELS=1 # 针对大模型,限制同时加载的模型数,防止抢显存
- OLLAMA_FLASH_ATTENTION=true # 建议:AMD 显卡开启可节省大量显存
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
不过,我实践下来, 上述修订方法并没有解决,报错依旧
gemini另外一个建议我觉得很有可能: 回退ROCm版本,因为 AMD Radeon Instinct MI50 我当时在调研时就发现官方RELEASE说明中最高只有ROCm 5.7.1版本是明确支持MI50的,最新的ROCm 6.x发布文档中已经声明不再支持GCN 5代,也就是 不再明确支持MI50 ,虽然在Reddit帖子中有人报告在ROCm 6.3.2中依然可以使用MI50(我的实践也验证物理主机上使用似乎没有问题,但是看来容器兼容性存在限制)
但是存在一个问题,就是 Ollama 官方镜像的哪个TAG对应使用的是 ROCM 5.7 呢?
Google了一下,找到一个早期Ollama构建Dockerfile中指定 ROCM_VERSION=5.7 的案例 prawilny/ollama-rocm-docker ,也就是说,我需要到Ollama官方源代码仓库中搜索找到对应这样的Dockerfile的TAG,来找到合适的官方镜像版本
我在 GitHub: ollama/ollama/Dockerfile 中查看,发现当前的Dockerfile中已经使用了 ROCMVERSION=7.2 ,所以需要找出早期版本。Gemini提供了一些线索:
查找 2024年2月到3月 左右的提交。当时正是 ROCm 从 5.7 迁移到 6.0 的窗口期
尝试
ollama/ollama:0.1.29-rocm,原因是: 在 0.1.30 之前,Ollama 普遍使用的是 ROCm 5.x 基础镜像。0.1.29 是一个公认的在老旧硬件上比较稳定的版本
ROCm 5.7services:
# 1. Ollama 服务 (AMD ROCm)
ollama-amd:
image: ollama/ollama:0.1.29-rocm
container_name: ollama-amd
restart: unless-stopped
ports:
- "11435:11434"
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 关键新增参数 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在两块 MI50 上
- OLLAMA_MAX_LOADED_MODELS=1 # 针对大模型,限制同时加载的模型数,防止抢显存
- OLLAMA_FLASH_ATTENTION=true # 建议:AMD 显卡开启可节省大量显存
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
ulimits: # 允许容器锁定内存,防止 GPU 驱动初始化失败
memlock: -1
stack: 67108864
# --- 必须保留,否则新内核会拦截 GFX906 的底层指令 ---
privileged: true
devices:
# --- 显式映射计算端口和渲染节点,防止容器内驱动扫描不存在的显示设备 ---
- /dev/kfd:/dev/kfd
- /dev/dri/renderD128:/dev/dri/renderD128
- /dev/dri/renderD129:/dev/dri/renderD129
volumes:
- ollama_data:/root/.ollama
# 2. Open WebUI
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama-amd:11434
depends_on:
- ollama-amd
# 3. AMD GPU Exporter (监控核心)
# 注意:这需要宿主机安装了 ROCm 驱动,因为它要读取物理 GPU 数据
amdgpu-exporter:
image: rocm/device-metrics-exporter:v1.4.2
container_name: amdgpu-exporter
restart: unless-stopped
ports:
- "5000:5000"
devices:
- /dev/dri:/dev/dri
- /dev/kfd:/dev/kfd
# 4. Prometheus (时序数据库)
prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
# 5. Grafana (可视化面板)
grafana:
image: grafana/grafana:latest
container_name: grafana
restart: unless-stopped
ports:
- "3001:3000"
depends_on:
- prometheus
volumes:
ollama_data:
open-webui_data:
果然,通过指定 ollama:0.1.29-rocm 能够避免启动容器启动Ollama进程crash,检查Host主机的 dmesg 日志可以看到没有再出现异常的 *ERROR* Trying to push to a killed entity ,系统也没有再出现D住的进程
通过确认 docker logs ollama-amd 也可以看到容器正常初始化
time=2026-03-15T00:51:37.550Z level=INFO source=images.go:806 msg="total blobs: 0"
time=2026-03-15T00:51:37.555Z level=INFO source=images.go:813 msg="total unused blobs removed: 0"
time=2026-03-15T00:51:37.555Z level=INFO source=routes.go:1110 msg="Listening on [::]:11434 (version 0.1.29)"
time=2026-03-15T00:51:37.556Z level=INFO source=payload_common.go:112 msg="Extracting dynamic libraries to /tmp/ollama2854516936/runners ..."
time=2026-03-15T00:51:42.831Z level=INFO source=payload_common.go:139 msg="Dynamic LLM libraries [cpu_avx rocm_v60000 cpu cuda_v11 cpu_avx2]"
time=2026-03-15T00:51:42.831Z level=DEBUG source=payload_common.go:140 msg="Override detection logic by setting OLLAMA_LLM_LIBRARY"
time=2026-03-15T00:51:42.831Z level=INFO source=gpu.go:77 msg="Detecting GPU type"
time=2026-03-15T00:51:42.831Z level=INFO source=gpu.go:191 msg="Searching for GPU management library libnvidia-ml.so"
time=2026-03-15T00:51:42.831Z level=DEBUG source=gpu.go:209 msg="gpu management search paths: [/usr/local/cuda/lib64/libnvidia-ml.so* /usr/lib/x86_64-linux-gnu/nvidia/current/libnvidia-ml.so* /usr/lib/x86_64-linux-gnu/libnvidia-ml.so* /usr/lib/wsl/lib/libnvidia-ml.so* /usr/lib/wsl/drivers/*/libnvidia-ml.so* /opt/cuda/lib64/libnvidia-ml.so* /usr/lib*/libnvidia-ml.so* /usr/local/lib*/libnvidia-ml.so* /usr/lib/aarch64-linux-gnu/nvidia/current/libnvidia-ml.so* /usr/lib/aarch64-linux-gnu/libnvidia-ml.so* /opt/cuda/targets/x86_64-linux/lib/stubs/libnvidia-ml.so* /opt/rocm/lib/libnvidia-ml.so* /usr/local/lib/libnvidia-ml.so* /opt/rh/devtoolset-7/root/libnvidia-ml.so*]"
time=2026-03-15T00:51:42.833Z level=INFO source=gpu.go:237 msg="Discovered GPU libraries: []"
time=2026-03-15T00:51:42.833Z level=INFO source=cpu_common.go:11 msg="CPU has AVX2"
time=2026-03-15T00:51:42.833Z level=INFO source=amd_linux.go:50 msg="AMD Driver: 6.12.12"
time=2026-03-15T00:51:42.833Z level=INFO source=amd_linux.go:88 msg="detected amdgpu versions [gfx906 gfx906]"
time=2026-03-15T00:51:42.833Z level=DEBUG source=amd_common.go:16 msg="evaluating potential rocm lib dir /tmp/ollama2854516936/rocm"
time=2026-03-15T00:51:42.833Z level=DEBUG source=amd_common.go:16 msg="evaluating potential rocm lib dir /usr/bin"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_common.go:16 msg="evaluating potential rocm lib dir /usr/bin/rocm"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_common.go:16 msg="evaluating potential rocm lib dir /usr/share/ollama/lib/rocm"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_common.go:16 msg="evaluating potential rocm lib dir /opt/rocm/lib"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_linux.go:279 msg="host rocm linked /opt/rocm/lib => /tmp/ollama2854516936/rocm"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_linux.go:123 msg="skipping rocm gfx compatibility check with HSA_OVERRIDE_GFX_VERSION=9.0.6"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_linux.go:152 msg="discovering VRAM for amdgpu devices"
time=2026-03-15T00:51:42.835Z level=DEBUG source=amd_linux.go:171 msg="amdgpu devices [0 1]"
time=2026-03-15T00:51:42.835Z level=INFO source=amd_linux.go:246 msg="[0] amdgpu totalMemory 32752M"
time=2026-03-15T00:51:42.835Z level=INFO source=amd_linux.go:247 msg="[0] amdgpu freeMemory 32752M"
time=2026-03-15T00:51:42.835Z level=INFO source=amd_linux.go:246 msg="[1] amdgpu totalMemory 32752M"
time=2026-03-15T00:51:42.835Z level=INFO source=amd_linux.go:247 msg="[1] amdgpu freeMemory 32741M"
time=2026-03-15T00:51:42.835Z level=DEBUG source=gpu.go:180 msg="rocm detected 2 devices with 58944M available memory"
使用异常排查
我在实际通过Open WebUI下载 llama3.3:70b-instruct-q4_K_M 模型运行时出现报错: 500: exception done_getting_tensors: wrong number of tensors; expected 724, got 723 ,此时检查 docker logs ollama-amd 可以看到日志:
...
llama_model_load: error loading model: done_getting_tensors: wrong number of tensors; expected 724, got 723
llama_load_model_from_file: exception loading model
time=2026-03-15T09:22:07.085Z level=DEBUG source=dyn_ext_server.go:158 msg="failure during initialization: exception done_getting_tensors: wrong number of tensors; expected 724, got 723"
time=2026-03-15T09:22:07.085Z level=WARN source=llm.go:170 msg="Failed to load dynamic library /tmp/ollama2854516936/runners/cpu_avx2/libext_server.so exception done_getting_tensors: wrong number of tensors; expected 724, got 723"
...
检查模型:
docker exec -it ollama-amd ollama list
输出显示
NAME ID SIZE MODIFIED
llama3.3:70b-instruct-q4_K_M a6eb4748fd29 42 GB 43 minutes ago
上述报错实际上很可能是模型下载过程中由于网络波动导致某个分块(blob)不完整,所以通过以下命令删除掉模型并重新下载:
docker exec -it ollama-amd ollama rm llama3.3:70b-instruct-q4_K_M
docker exec -it ollama-amd ollama pull llama3.3:70b-instruct-q4_K_M
但是很不幸,我重新拉取模型之后,再次测试依然是相同的报错。看起来并不是模型下载问题,因为使用 ollama pull 下载模型最后有校验,显示下载是成功的
另一个怀疑点是 Ollama 0.1.29 的 GGUF 格式兼容性 : Llama 3.3 及其权重格式在不断更新。这里我使用的 0.1.29 是较早的版本,而 llama3.3:70b 默认拉取的可能是使用较新 llama.cpp 工具链量化的 GGUF 文件。新版 GGUF 可能包含旧版 Ollama 无法识别的 Metadata 层。
gemini建议我尝试:
尝试拉取版本更早、兼容性更好的 Llama 3 镜像进行测试:
ollama pull llama3:70b-instruct-q4_K_M,如果Llama 3能够成功而 3.3 失败的话,就表明是版本不兼容另一个尝试是采用5.x系列中较晚发布的
ollama:0.1.32-rocm看看能否在不导致驱动崩溃情况下运行Llama 3.3
我首先调整了镜像,改为采用 ollama/ollama:0.1.32-rocm ,并且为了能够不重复下载model,我修订了容器挂载的卷目录,即 docker-compose.yml 如下:
services:
# 1. Ollama 服务 (AMD ROCm)
ollama-amd:
# image: ollama/ollama:0.1.29-rocm
image: ollama/ollama:0.1.32-rocm
container_name: ollama-amd
restart: unless-stopped
ports:
- "11435:11434"
environment:
huatai@zcloud:~/ollama$ cat docker-compose.yml
services:
# 1. Ollama 服务 (AMD ROCm)
ollama-amd:
# image: ollama/ollama:0.1.29-rocm
image: ollama/ollama:0.1.32-rocm
container_name: ollama-amd
restart: unless-stopped
ports:
- "11435:11434"
environment:
- OLLAMA_HOST=0.0.0.0
- OLLAMA_ORIGINS=*
- HSA_OVERRIDE_GFX_VERSION=9.0.6
# --- 关键:针对老卡在新内核上的稳定性补丁 ---
#- HSA_ENABLE_SDMA=0 # 禁用某些可能导致 D 状态进程的 DMA 引擎
#- ROC_ENABLE_PRE_VEGA=1 # 确保对 GFX9 架构的兼容性
# --- 关键新增参数 ---
- OLLAMA_SCHED_SPREAD=true # 强制将模型分布在两块 MI50 上
- OLLAMA_MAX_LOADED_MODELS=1 # 针对大模型,限制同时加载的模型数,防止抢显存
- OLLAMA_FLASH_ATTENTION=true # 建议:AMD 显卡开启可节省大量显存
# 先不设 VISIBLE_DEVICES,让它扫全量
- OLLAMA_DEBUG=1 # 开启详细调试日志
ulimits: # 允许容器锁定内存,防止 GPU 驱动初始化失败
memlock: -1
stack: 67108864
# --- 必须保留,否则新内核会拦截 GFX906 的底层指令 ---
privileged: true
devices:
# --- 显式映射计算端口和渲染节点,防止容器内驱动扫描不存在的显示设备 ---
- /dev/kfd:/dev/kfd
- /dev/dri/renderD128:/dev/dri/renderD128
- /dev/dri/renderD129:/dev/dri/renderD129
volumes:
# --- 将默认的ollama_data全局卷/var/lib/docker/volumes/ollama_ollama_data/_data目录改为当前目录下ollama_data,避免重复下载model
#- ollama_data:/root/.ollama
- ./ollama_data:/root/.ollama
# 2. Open WebUI
open-webui:
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
restart: unless-stopped
ports:
- "3000:8080"
environment:
- OLLAMA_BASE_URL=http://ollama-amd:11434
volumes:
# --- 将默认的open-webui_data全局卷目录改为当前目录下open-webui_data
- ./open-webui_data:/app/backend/data
depends_on:
- ollama-amd
# 3. AMD GPU Exporter (监控核心)
# 注意:这需要宿主机安装了 ROCm 驱动,因为它要读取物理 GPU 数据
amdgpu-exporter:
image: rocm/device-metrics-exporter:v1.4.2
container_name: amdgpu-exporter
restart: unless-stopped
ports:
- "5000:5000"
devices:
- /dev/dri:/dev/dri
- /dev/kfd:/dev/kfd
environment:
- AMDGPU_METRICS_EXPORTER_PORT=5000
- HSA_OVERRIDE_GFX_VERSION=9.0.6 # 匹配 MI50
# 4. Prometheus (时序数据库)
prometheus:
image: prom/prometheus:latest
container_name: prometheus
restart: unless-stopped
ports:
- "9090:9090"
command:
- '--config.file=/etc/prometheus/prometheus.yml'
volumes:
- ./prometheus.yml:/etc/prometheus/prometheus.yml
depends_on:
- amdgpu-exporter
# 5. Grafana (可视化面板)
grafana:
image: grafana/grafana:latest
container_name: grafana
restart: unless-stopped
ports:
- "3001:3000"
depends_on:
- prometheus
#volumes:
#ollama_data:
#open-webui_data:
但是发现ollama-amd容器的日志同样报错 done_getting_tensors: wrong number of tensors; expected 724, got 723 :
ollama-amd 日志显示报错ggml_cuda_init: GGML_CUDA_FORCE_MMQ: no
ggml_cuda_init: CUDA_USE_TENSOR_CORES: yes
ggml_cuda_init: found 2 ROCm devices:
Device 0: AMD Radeon Graphics, compute capability 9.0, VMM: no
Device 1: AMD Radeon Graphics, compute capability 9.0, VMM: no
llm_load_tensors: ggml ctx size = 0.83 MiB
llama_model_load: error loading model: done_getting_tensors: wrong number of tensors; expected 724, got 723
llama_load_model_from_file: exception loading model
terminate called after throwing an instance of 'std::runtime_error'
what(): done_getting_tensors: wrong number of tensors; expected 724, got 723
time=2026-03-15T14:25:37.320Z level=ERROR source=routes.go:120 msg="error loading llama server" error="llama runner process no longer running: -1 "
time=2026-03-15T14:25:37.320Z level=DEBUG source=server.go:832 msg="stopping llama server"
[GIN] 2026/03/15 - 14:25:37 | 500 | 7.356857106s | 172.18.0.5 | POST "/api/chat"
看来模型文件下载应该是正常的,而且 ollama:0.1.32-rocm 这样稍微新一点的镜像也没有解决问题,那么是否要尝试llama3的模型看看是否是旧版Ollama不支持Llama3.3的新tensor结构?
docker exec -it ollama-amd ollama pull llama3:70b-instruct-q4_K_M
我在 I can't run llama3.1 #6048 找到的解释看起来说明了原因(也是加载模型报tensors数量不一致): 原因是Ollama依赖 llama.cpp ,最新的 llama.cpp 创建的GGUF文件不能被旧版本llama.cpp 处理,如果要使用旧版本llama.cpp需要自己使用旧版本llama.cpp来转换hf到GGUF。
另外Hugging Face上 Missing Tensors in Q5_K_S + Q5_K_M #8 也是同样的报错问题,需要使用较新版本的 llama.cpp 来处理,所以在我这种使用旧版 Ollama 的情况,也同样是因为旧版 llama.cpp 无法处理新版本GGUF导致的
我这里大概率是因为我为了能够在Ollama中使用旧版本ROCm,使用了早期版本的Ollama镜像,这种旧版本Ollama镜像打包的是旧版本 llama.cpp ,无法处理最新的GGUF文件。
解决的方法可能是:
采用早期的llama3,那些早期的llama3通常会使用旧版本llama.cpp创建的GGUF。这种方法可能会成功,但是带来的问题是无法体验最新的模型
另一种方式我感觉是自己用旧版本 llama.cpp 来转换模型的hf文件到 GGUF,这样理论上能体验最新版本的模型,就是比较麻烦一些 ,我准备参考 Llama 3.1 GGUF incompatibility using latest release of llama.cpp and text-generation-webui. #6301 提供的hf转GGUF方法来实现
另外,我想到的一个方法是对于我现在使用的旧硬件 AMD Radeon Instinct MI50 ,如果不是用容器直接物理主机运行Olama,那么有可能是可以直接使用最新版本的ROCm (之前我记得尝试用物理主机运行Ollama是成功的,看起来去掉容器化这层是有可能使用最版本ROCm,这样或许会减少很多麻烦)
最终解决
采用 将HF转为GUFF