在Docker中Ollama使用AMD GPU运行大模型

我之前在物理服务器上直接 Ollama使用AMD GPU运行大模型 ，现在由于在服务器上安装了多块NVIDIA和AMD的计算卡，所以我改进为采用 Docker 容器化运行，以便能够隔离不同的GPU设备并且能够灵活调用。

准备工作

运行Ollama容器

授权docker容器访问host主机的AMD GPU
docker run -d \
    --device /dev/kfd \
    --device /dev/dri/renderD128 \
    --device /dev/dri/renderD129 \
    --security-opt seccomp=unconfined \
    -v ollama-amd:/root/.ollama \
    -p 11435:11434 \
    --name ollama-amd \
    ollama/ollama:rocm

此时容器运行了Ollama服务( /bin/ollama serve )

需要注意，上述运行命令Ollama服务默认只监听 127.0.0.1 ，所以后续使用 Ollama WebUI 会无法连接服务端口，并且没有 OLLAMA_ORIGINS (防止跨域报错)也会导致问题

运行Ollama+Open WebUI

为了方便使用，可以运行一个Ollama容器以及一个Open WebUI容器，并让两者通过 host 网络模式或利用 --add-host 参数互通:

  • 改进Ollama容器命令，监听所有接口并允许跨域:

运行Ollama容器并监听所有接口和允许跨域
docker run -d \
    --device /dev/kfd \
    --device /dev/dri \
    --security-opt seccomp=unconfined \
    -v ollama-amd:/root/.ollama \
    -p 11435:11434 \
    --name ollama-amd \
    -e OLLAMA_HOST=0.0.0.0 \
    -e OLLAMA_ORIGINS="*" \
    -e HSA_OVERRIDE_GFX_VERSION=9.0.6 \
    ollama/ollama:rocm

  • 启动Open WebUI并连接:

运行Open WebUI并连接Ollama
docker run -d \
    -p 3000:8080 \
    --add-host=host.docker.internal:host-gateway \
    -v open-webui:/app/backend/data \
    -e OLLAMA_BASE_URL=http://host.docker.internal:11435 \
    --name open-webui \
    ghcr.io/open-webui/open-webui:main

这里:

  • --add-host=host.docker.internal:host-gateway 在 Open WebUI 容器内部映射了一个特殊的域名 host.docker.internal ，指向物理宿主机

  • -e OLLAMA_BASE_URL=http://host.docker.internal:11435 WebUI通过这个地址找到Ollama的服务端口，也就是宿主机的 1435 端口

备注

更为方便的结合运行方式: Docker compose组合运行Ollama ，可以一键运行多个容器组合

模型选择

备注

本段模型对比选择由gemini推荐

由于服务器安装了 两块32GB的 AMD Radeon Instinct MI50 ，合计 64GB 显存适合运行 70B 级别（大模型门槛）和 MoE（混合专家）架构模型

通用类型

  • Qwen3-Next-30B-A3B (Reasoning 版): Qwen3 系列中的 30B 专家模型，采用了 A3B（Advanced Attention Architecture）架构，是2026年初最适合64GB显存环境的全能型模型

    • 完美适配显存：在 Q8（8-bit）量化下仅占用约 34GB 显存，留有充足空间（约 30GB）给 KV Cache，这意味着你可以处理长达 64k-128k 的长文本对话而不爆显存。

    • 双模式切换：支持“思维模式（Thinking）”，在处理复杂逻辑、翻译和常识推理时，智力表现逼近 GPT-4o。

    • 在极短文本的响应速度上，可能略慢于非推理版的 14B 模型。

  • Llama-3.3-70B (Q4_K_M量化): 全球生态最稳固的模型。在 64GB 显存上，可以跑起 4-bit 量化的 70B 模型

    • 知识面极其广博：在法律、医学和通用常识上非常稳健，回答风格更有“人性”。

    • 双卡均衡：在 Ollama 中，70B 会非常均匀地分布在两块 MI50 上，充分利用 HBM2 带宽。

    • 显存吃紧：4-bit 量化的 70B 模型大约占用 42GB-45GB。剩下的显存只能支持约 8k-16k 的上下文。如果你发给它的文档太长，模型会变笨或报错。

  • DeepSeek-V3-Lite / GPT-OSS-20B: 追求极速生成（例如每秒输出 50-80 个字），MoE 架构是首选

    • 推理速度极快：MoE 架构每次只激活部分参数，在 MI50 上的吞吐量远超同体积的 Dense 模型。

    • 支持超长上下文：这类模型通常针对 RAG（检索增强生成）优化，适合处理你刚才提到的“全项目代码分析”。

    • 缺点: 在极少数情况下，MoE 模型可能会出现“幻觉”，逻辑连贯性在超长对话中偶尔不如 70B 模型。

代码开发

代码开发可以采用 Ollama 集成编程工具 :

  • ollama launch claude (行为模拟模式): 模拟 Anthropic Claude 系列的对话风格和逻辑思维

    • 强解释性：它不仅给出代码，还会详细解释每一行代码的意图，适合学习和 Code Review

    • 防御性编程：更倾向于在代码中加入错误处理和边界检查

    • 对话记忆：对上下文的长程关联优化得更好，适合处理多文件的大型架构讨论

  • ollama launch codex (纯净补全模式): 模拟最初的 OpenAI Codex 或 GitHub Copilot 的底层逻辑

    • 极简输出：通常不废话，直接给出代码块

    • IDE 对齐：它的输出格式经过优化，可以直接被你的 VS Code 或 Cursor 插件无缝解析

    • 性能优先：减少了自然语言生成的 Token 消耗，推理速度（TPS）通常比 claude 模式更快

可行方案:

  • 长上下文开发 (claude 模式): ollama launch claude --model qwen3-coder-next:70b

    • Qwen3-Coder 的 70B 版本在模拟 Claude 的复杂逻辑时表现最强

  • 实时代码自动补全 (codex 模式): ollama launch codex --model qwen3-coder-next:14b

    • 14B 模型在 MI50 上的推理几乎是瞬间的，适合作为 IDE 后端，实现零延迟的 Tab 补全(也可以选择32B模型)

加载模型

Qwen3-Next

运行 qwen3-next 模型
# A3B 代表 "Activated 3 Billion"（激活 30 亿参数）
# 建议显式设置上下文，Qwen3-Next 的强项是 256k 长文本
docker exec -it ollama-amd ollama run qwen3-next:80b-a3b-instruct-q4_K_M \
   --set parameter num_ctx 32768

# thinking
docker exec -it ollama-amd ollama run qwen3-next:80b-a3b-thinking-q4_K_M

备注

注意 大模型命名含义

由于 Qwen3-Next 采用了 Gated DeltaNet (线性注意力的变体) 架构，它处理长文本的效率极高。在 12GB 的 KV 缓存下，它能支持比普通 Llama 模型多出数倍的上下文长度。

Qwen3-Coder-Next

运行 qwen3-coder-next 模型
# A3B 代表 "Activated 3 Billion"（激活 30 亿参数）
# 建议显式设置上下文，Qwen3-Next 的强项是 256k 长文本
docker exec -it ollama-amd ollama run qwen3-coder-next:q4_K_M \
  --set parameter num_ctx 32768 \
  --set parameter num_gpu 999 \
  --set parameter repeat_penalty 1.1 \
  --set parameter temperature 0.7

  • --set parameter num_ctx 32768 (上下文窗口)

    • 默认的 4k 或 8k无法处理大量文件，所以设置为32k

    • 硬件对齐：Qwen3 系列支持超长上下文，但在 64GB 显存中，扣除模型占用的 50GB 左右，32k 是一个非常稳妥的平衡点。它能保证你在处理中大型代码文件时，AI 不会因为“忘记”前面的内容而产生幻觉。

  • --set parameter num_gpu 999 (强制全层加载)

    • 作用：确保将模型的所有层（Layers）全部推入两块 MI50。

    • 效果：如果不设置，Ollama 可能会保守地将几层留在 CPU (768GB RAM) 里，这会导致推理速度瞬间从“秒出”降到“字蹦”。

  • --set parameter repeat_penalty 1.1 (重复惩罚)

    • 编程专用：Qwen3 在生成超长代码时，偶尔会陷入某种循环。稍微调高惩罚值（默认 1.0）可以有效避免 AI 反复输出同一行注释或代码。

  • 要让它一次性分析整个项目，除了上述命令，还需要调整 num_predict （最大生成长度）: --set parameter num_predict 4096 (需要 AI 帮你写一个超长的完整文件，例如超过 1000 行代码)

配置文件

为了能够不必每次都输入大量参数，可以将参数写入文件:

  • 在Host主机创建 Coder.Modelfile

配置 Coder.Modelfile
FROM qwen3-coder-next:q4_K_M
PARAMETER num_ctx 32768
PARAMETER num_gpu 999
PARAMETER temperature 0.7
PARAMETER repeat_penalty 1.1
SYSTEM "你是一个资深的架构师和程序员，精通各种编程语言和高性能计算。你会给出简洁、高效且符合工业标准的重构建议。"

  • 导入并运行:

导入并运行
docker exec -i ollama-amd ollama create MyCoder -f - < Coder.Modelfile
docker exec -it ollama-amd ollama run MyCoder

Llama3

运行 llama3 模型
docker exec -it ollama-amd ollama run llama3.3:70b-instruct-q4_K_M \
  --set parameter num_ctx 24576 \
  --set parameter num_gpu 999 \
  --set parameter num_thread 16 \
  --set parameter temperature 0.6 \
  --set parameter top_p 0.9

Llama 3.3 是典型的 Dense（稠密）模型，对显存的占用和计算资源的消耗更加“扎实" (参数及说明由gemini推荐):

  • 块 MI50 (64GB) 上，由于 Llama 3.3-70B (q4_K_M) 自身已经占据了约 42GB - 45GB 的空间，留给上下文（KV Cache）的余量比 Qwen3 要稍微紧凑一些

  • num_ctx 24576 (约 24k 上下文): 在 70B 规模下，32k 上下文可能会将显存撑到 60GB 以上。为了留出一些缓冲空间防止 OOM（显存溢出）导致容器崩溃，24k 是一个极度稳定的上限(大约能一次性放入15-20 个标准长度的 Python 文件进行分析)

  • num_gpu 999 (全显卡加速): Llama 3.3-70B 有 80 层（Layers）。强制设为 999 可以确保 Ollama 将这 80 层均匀分布在两块 MI50 上（每块卡约负担 40 层）

  • num_thread 16 (多线程预处理): 虽然推理靠 GPU，但模型加载和 Prompt 的初步解析（Prefill 阶段）会用到 CPU，设置 16 线程可以显著加快按下回车到 AI 开始出字之间的响应速度

参考