在 AMD ROCm 与 Mac Metal 上运行 DeepSeek：兼容性矩阵与排错全指南

DeepSeek 是由 DeepSeek-AI 发布的一系列开放权重大语言模型，官方权重已公开（例如托管在 Hugging Face 上）。开放权重的优势在于：你可以直接下载完整模型参数，在本地或私有服务器上自行部署，而不必完全依赖托管聊天服务。

在实际使用中，许多 DeepSeek 变体体量巨大，没有 GPU 加速几乎无法获得可用的交互速度。问题在于，本地 LLM 生态长期围绕 NVIDIA CUDA 打磨：内核、运行时和社区测试都高度集中在 CUDA 上。当你尝试在非 CUDA 环境（如基于 ROCm 的 AMD GPU，或基于 Metal 的 Apple Silicon）上运行 DeepSeek 时，经常会遇到平台特有的差异：

哪些运行时真正稳定可用
哪些模型格式在该平台上更现实
能用到什么精度/量化方案
最先暴露的问题是驱动识别、算子不支持、显存压力，还是“GPU 没被用上”之类症状

因此，本文专门聚焦在 AMD ROCm 与 Mac Metal 上运行 DeepSeek：给出一个快速决策路径、一份按硬件划分的兼容性矩阵，以及针对这些非 CUDA 环境中最常见 DeepSeek 部署错误的排错指南。

第 1 部分：快速决策指南

使用 AMD GPU（ROCm）时

使用 AMD 官方支持的 PyTorch 栈
优先考虑已在 ROCm 上验证过的框架，例如 vLLM 或 Hugging Face Transformers
安装 ROCm 版 PyTorch（可通过 AMD Docker 镜像或 pip wheel 安装）：
- Linux: 参考 AMD 官方 ROCm + PyTorch 安装文档
- Windows（Radeon + Ryzen 平台）参考 AMD 提供的 pip wheel 指南
加载 DeepSeek 模型时使用 FP16（半精度） 或合适的量化格式
ROCm 版本务必与具体 GPU 型号的官方支持矩阵匹配
遇到 CUDA 专用代码时，用 HIP/ROCm 等价实现替换或打补丁（详见第 3 部分）

使用 Apple Silicon（Mac）时

使用带 Metal 后端的 llama.cpp，或使用体验更友好的 Ollama
将 DeepSeek 权重转换为适配 llama.cpp 的 GGUF 格式
Apple 统一内存有利于加载大模型，但仍建议对较大 DeepSeek 变体使用 4bit / 5bit 量化，以控制内存压力
编译或安装启用 Metal 的 llama.cpp，并确保开启 GPU offload（例如在 Python 绑定中设置 n_gpu_layers 等参数，更多排错见第 4 部分）

只能 CPU 运行时

仅作为无可用 GPU 或 GPU 兼容性问题难以解决时的兜底方案
选择最小的 DeepSeek 变体，或使用重度量化模型（如 7B 蒸馏模型的 4bit 版本）
大模型在 CPU 上推理会非常慢，响应可能以分钟计
可参考 DeepSeek 量化指南缩小模型体积，仅在开发/测试阶段使用 CPU
只要条件允许，优先使用任意可用 GPU（包括 Apple 集成 GPU）进行推理

第 2 部分：DeepSeek 兼容性矩阵概览

下表思路（此处为文字概述）可帮助你根据平台选择合适的运行时与模型格式，并定位常见问题对应的排错章节：

AMD ROCm：
- 运行时：ROCm 版 PyTorch + Transformers / vLLM（ROCm 构建）
- 精度：FP16 / BF16 为主，配合 8bit 或 4bit 量化
- 量化：AWQ / GPTQ / Quark 输出格式
- 常见问题：HIP GPU 不可见、ROCm 版本不匹配、CUDA-only 库报错、OOM
Mac Metal（Apple Silicon）：
- 运行时：llama.cpp（Metal 后端）/ Ollama
- 格式：GGUF（Q4 / Q5 等量化）
- 常见问题：Metal 未启用导致跑在 CPU、统一内存 OOM 或疯狂换页、编译/安装失败
CPU-only：
- 运行时：Transformers / llama.cpp CPU 模式
- 格式：高度量化（4bit 甚至 3bit 实验格式）+ 小模型

后文各节会针对这些典型组合展开细节与排错方法。

第 3 部分：在 AMD ROCm 上运行 DeepSeek

在 AMD GPU 上运行 DeepSeek 需要完整的 ROCm 软件栈，并对默认假定 CUDA 的代码做少量调整。ROCm 通过 HIP 平台提供 GPU 加速，对 PyTorch 与 Transformer 模型基本兼容。下面介绍推荐的运行时组合及常见问题与解决方案。

问题 1：“No HIP GPUs are available”

症状：

启动 DeepSeek（vLLM 或 PyTorch）时报错：RuntimeError: No HIP GPUs are available
或简单提示找不到 GPU / 加速设备

可能原因：

程序无法访问 AMD GPU，常见是权限或驱动问题
裸机 Linux 上，当前用户可能无权访问 /dev/kfd 与 /dev/dri，尤其未加入 video 组
容器环境中，Docker 未正确透传 GPU 设备
也可能是 ROCm 未正确安装或初始化，但若你已能部分使用 ROCm，更大概率是权限/环境问题

解决步骤：

验证 ROCm 安装
在宿主机运行：rocminfo 或 rocm-smi，确认能识别 GPU。若检测不到，说明驱动或 ROCm 版本不匹配，需要按 GPU 型号与系统版本重新安装。
检查用户权限（裸机）
将当前用户加入 video 组，以访问 AMD GPU 设备：
```
sudo usermod -aG video $USER
# 注：需重新登录会话生效
```
容器配置（如使用 Docker）
启动容器时添加：
```
--device=/dev/kfd --device=/dev/dri --group-add=video
```
并优先使用 AMD 提供的 ROCm 容器镜像（如 rocm/pytorch）。
在 Python 中自检
在目标环境中运行：
```
import torch
print(torch.cuda.is_available())
print(torch.cuda.device_count())
```
在 ROCm 上，这里的 cuda 接口会映射到 HIP。若返回 True 且设备数 ≥ 1，说明 GPU 已可见；否则需重新检查驱动、权限与 PyTorch 构建是否为 ROCm 版。

兜底方案：

若最终仍无法让 GPU 可用（如 GPU 型号不受 ROCm 支持），只能退回 CPU 推理，仅适合小模型或短输入。也可考虑使用带 AMD GPU 的云主机。只要环境配置正确，AMD GPU 完全可以高效运行 DeepSeek。

问题 2：ROCm 版本不匹配或 “invalid device function”

症状：

DeepSeek 在加载或首轮推理时崩溃，报 hipErrorInvalidDeviceFunction 或莫名段错误
自编译扩展时出现 GFX 架构或 ISA 不支持相关错误

可能原因：

已安装的 ROCm 栈与 GPU 架构或上层软件期望不匹配
例如：新 GPU 搭配过旧 ROCm；或使用的 PyTorch 预编译包未包含该 GPU 的代码生成
本质是：GPU 内核代码无法在当前 GPU 上执行

解决步骤：

对齐 ROCm 版本与硬件
查阅 AMD 官方支持矩阵，确认当前 GPU 对应的最低/推荐 ROCm 版本。例如 RX 7800 XT（Navi 3x）通常需要 ROCm 5.6+。
优先使用官方 Docker 镜像
使用 rocm/pytorch: 等官方容器，往往能避免宿主机驱动与用户态库不匹配的问题。
重新安装或从源码编译 PyTorch
对于非常新的或少见的 GPU，可能需要从源码编译 PyTorch，并在构建参数中显式指定 GPU 架构，以确保 JIT/预编译内核覆盖你的设备。
必要时使用 HSA_OVERRIDE_GFX_VERSION
对极新但尚未正式支持的 GPU，可在 AMD 指南下谨慎使用该环境变量做临时兼容。
修改后重新自检
再次运行 torch.cuda.is_available() 与简单推理测试，确认不再出现 invalid device 错误。

兜底方案：

若 GPU 架构确实不在 ROCm 支持列表中，只能考虑：

更换为受支持的 GPU（NVIDIA 或旧一代受支持的 AMD）
使用 CPU 或云端服务

ROCm 主要支持 GCN/RDNA 架构的离散显卡，部分老旧或移动端 GPU 不在支持范围内。

问题 3：“CUDA-only” 包相关错误（NCCL / bitsandbytes 等）

症状：

导入或运行 DeepSeek 代码时，报与 CUDA 库或 NVIDIA 符号相关错误：
- RuntimeError: CUDA error: no kernel image is available for execution
- 找不到 libcudart.so、nccl.dll 等
- bitsandbytes 提示“未编译 GPU 支持”

可能原因：

生态中部分库高度依赖 NVIDIA：
- NCCL 是 NVIDIA 的多卡通信库，在 AMD 上应使用 RCCL
- bitsandbytes 默认是 CUDA-only，需要 ROCm 分支
某些 DeepSeek 工具脚本直接调用 torch.cuda.xxx 或检查 NVIDIA 设备名

解决步骤：

避免不必要的 NCCL 初始化
若不做多卡分布式训练/推理，尽量避免触发 NCCL 初始化。在 ROCm 上应使用 RCCL 后端，并遵循框架的 ROCm 指南。
使用带 ROCm 支持的关键库
- bitsandbytes：安装 ROCm 版或带 HIP 支持的分支，AMD 文档中有具体 wheel 或源码构建说明
- 安装后 import bitsandbytes 不应再提示无 GPU 支持
修补硬编码 CUDA 的代码
- 若脚本中显式调用 torch.cuda.set_device、torch.cuda.is_available() 等，一般在 ROCm 上仍可工作（接口映射到 HIP）
- 但若代码检查 get_device_properties().name 是否包含 “NVIDIA”，则需删除或改写该逻辑
升级 Transformers 等上层库
使用较新的 Transformers/Accelerate 版本，避免旧版本中强行加载 CUDA 内核的历史问题。

兜底方案：

若短期内无法解决，可暂时强制 CPU 模式（如 device_map={'': 'cpu'}），但性能会大幅下降。长期建议使用支持 AMD 的分支或向上游提交补丁。

问题 4：内核启动失败或显存 OOM

症状：

模型成功加载，但推理时出现：
- RuntimeError: HIP error: invalid kernel launch
- “out of memory” 或 “Memory access fault”
多卡场景下，某一张卡挂掉或停滞
常在长上下文或生成大量 token 时出现

可能原因：

实际耗用显存超出 GPU 能力，或显存严重碎片化
某些算子在 ROCm 上实现不够稳健，在极大矩阵规模下触发 bug
多卡划分不合理，单卡负载过大

解决步骤：

降低显存压力
- 减小 batch size
- 缩短输入上下文长度（如从 32k 降到 8k 测试）
- 减小 max_new_tokens，减少 KV cache 占用
确保使用 FP16/BF16 而非 FP32
- FP16 显存占用减半
- 若 GPU 与 ROCm/PyTorch 支持 BF16，可优先尝试 BF16
尝试 ROCm 友好的优化路径
- 某些场景可尝试 ONNX Runtime + ROCm Execution Provider
- 需确认模型可顺利导出 ONNX，且算子受支持
升级 ROCm 与 PyTorch
- 新版本通常修复大量大模型相关 bug，并改进内存管理
显式清理缓存
- 在长时间循环中定期调用 torch.cuda.empty_cache()，缓解显存碎片化

兜底方案：

使用 Accelerate 的 device_map 将部分权重 offload 到 CPU 或多卡
使用 4bit 等更激进的量化，将显存占用降到 FP16 的 1/4

第 4 部分：在 Mac Metal 上运行 DeepSeek

Apple M1/M2/M3 系列芯片具备高带宽统一内存，是本地运行 LLM 的理想平台之一。但必须使用基于 Metal API 的软件栈，而非 CUDA。当前主流方案是：

llama.cpp + Metal 后端
或基于 llama.cpp/Metal 的 Ollama（提供更友好的 GUI 与 CLI）

推荐工作流：GGUF + llama.cpp / Ollama

准备 GGUF 格式 的 DeepSeek 模型：
- 从可信模型库下载社区转换好的 DeepSeek GGUF（注意核对基座模型、许可证与转换说明）
- 或使用 llama.cpp 官方转换脚本，将 Hugging Face checkpoint 转为 GGUF
使用 llama.cpp CLI 或 Ollama 运行：
- llama.cpp CLI 适合需要精细控制参数的用户
- Ollama 提供一键运行与缓存、GUI 等功能

llama.cpp（Metal 后端）

编译启用 Metal
- 按官方文档使用 CMake 构建，开启 GGML_METAL=ON 等选项
- 不同版本的构建选项与二进制名称可能略有差异，以仓库说明为准
Python 绑定（llama-cpp-python）
- 安装时确保启用 Metal 支持（参考官方安装文档）
- 安装完成后，通过 n_gpu_layers 等参数开启 GPU offload
命令行示例（具体参数以版本文档为准）：
```
./main -m DeepSeek.gguf --n-gpu-layers 
```
- --n_gpu_layers 指定要 offload 到 GPU 的层数
- 若不设置或为 0，则全部在 CPU 上运行
- 实践中可从较小值开始，确认 Metal 已生效，再逐步增大直到接近内存上限

Ollama

安装 Ollama for Mac（仅支持 Apple Silicon，不支持 Intel Mac）

若官方仓库暂未收录 DeepSeek，可编写自定义 Modelfile：

FROM ./DeepSeek.gguf

然后执行：

ollama create deepseek-local -f Modelfile
ollama run deepseek-local

Ollama 会自动使用 Metal 加速，只要系统为 Apple Silicon 且模型量化格式受支持。

Mac 问题 1：Metal GPU 未被使用（推理极慢）

症状：

推理速度极慢，CPU 占用很高，GPU 几乎空闲
llama.cpp 启动日志中只提到 CPU，未提到 Metal
Ollama 使用时所有 CPU 核心满载，GPU 无明显负载

可能原因：

llama.cpp 未以 Metal 支持编译
运行时未设置 n_gpu_layers，导致全部在 CPU 上执行
使用的是 Intel Mac（不支持 Metal LLM 推理）

解决步骤：

确认编译启用 Metal
- 重新编译 llama.cpp，确保 CMake 选项中开启 Metal
- 查看启动日志或 --help 输出，确认 Metal backend 已启用
运行时指定 --n_gpu_layers
- 即便只设置 --n_gpu_layers 1，也能验证 Metal 是否生效
- 为获得更高性能，逐步增加 offload 层数，直到接近内存上限
监控 GPU 使用情况
- 使用 macOS 活动监视器或 Metal 性能工具，确认 GPU 有负载
Ollama 特殊注意
- 确保下载的是 ARM64 版本，未通过 Rosetta 运行
- 自定义 Modelfile 中引用的 GGUF 量化格式需为 Ollama/llama.cpp 支持的类型

兜底方案：

若无法启用 Metal（如旧 Mac 或配置问题），只能使用 CPU 推理。此时应选择最小的 DeepSeek 变体（如 7B 或蒸馏版），或改用远程服务器推理。

Mac 问题 2：统一内存 OOM 或疯狂换页导致卡顿

症状：

Mac 内存占用飙升，系统明显变卡，甚至进程被系统杀死
长上下文或大模型时尤为明显
llama.cpp 可能提示 KV cache 或上下文内存分配失败

可能原因：

Apple Silicon 使用统一内存，CPU 与 GPU 共享物理内存，但可用于 GPU 的部分有限
模型权重 + KV cache + 中间激活占用过大，触发系统换页
上下文长度过长（如 32k+），注意力与 KV cache 占用随上下文线性甚至更快增长

解决步骤：

使用更小的量化（更低 bit）
- 若 Q5 或复杂 4bit 格式仍 OOM，可尝试最基础的 Q4_0
- 5bit 模型通常比 4bit 大约 25%，在边缘场景差异明显
降低上下文长度
- 避免一上来就使用极长上下文
- 先用 2048 / 4096 token 测试稳定性
监控内存压力
- 关注 macOS 内存压力图是否变红
- 若频繁换页，需进一步减小模型或上下文
选择更小的模型变体
- 16GB 内存的 Mac 上，大多数 30B 级别模型即便 4bit 也非常吃力
- 优先选择 7B / 13B 级别 DeepSeek 变体

兜底方案：

通过减少 n_gpu_layers，将部分层退回 CPU 执行，降低 GPU 侧内存压力
使用更激进的量化（如实验性 3bit），或换用内存更大的机器

Mac 问题 3：Metal / Xcode 构建与安装失败

症状：

pip install llama-cpp-python 失败，报 C++/CMake/Metal 相关错误
手动编译 llama.cpp 时，CMake 提示找不到 Metal 框架或编译器

可能原因：

未安装 Xcode 命令行工具
CMake 或相关开发工具版本过旧
未正确设置 Metal 构建选项或 macOS 部署目标版本

解决步骤：

安装 Xcode 命令行工具
- 终端执行：xcode-select --install
- 安装完成后用 xcode-select -p 确认路径
更新 CMake 等工具
- 使用 Homebrew 安装/升级：brew install cmake
正确设置 CMake 选项
- 构建 llama.cpp 时启用 -DGGML_METAL=ON
- 必要时设置 MACOSX_DEPLOYMENT_TARGET=12 或更高，避免符号不兼容
使用预编译包
- 若本地编译困难，可使用 Conda Forge 上的预编译 llama-cpp-python（通常已启用 Metal）
Ollama 安装注意
- 确保 macOS 版本 ≥ 12，且为 Apple Silicon 机型

兜底方案：

若始终无法编译带 Metal 的版本，可暂时使用 CPU-only 构建，或关注 Core ML 等替代路线（目前对 DeepSeek 尚不成熟）。

第 5 部分：按平台选择模型格式与量化策略

不同平台适合的模型格式与量化方案差异较大，下面按硬件给出建议。

Apple Silicon（Mac）：首选 GGUF

格式：GGUF（GGML 的后继格式），是 llama.cpp 及其生态在 Mac 上的事实标准
原因：
- 针对本地推理优化的内存映射与加载方式
- 原生支持多种量化方案
实践建议：
- 将 DeepSeek 转为 GGUF 后再在 Mac 上运行
- 大模型优先使用 4bit（如 Q4_0、Q4_K 等）
- FP16 GGUF 虽可行，但通常过大，只能在 CPU 上跑，体验较差

AMD ROCm（AMD GPU）：FP16 + AWQ/GPTQ

高端显卡（如 48GB+ Instinct）：
- 可直接使用 FP16/BF16，获得最佳精度
消费级显卡：
- 推荐 4bit 量化，平衡显存与精度
AWQ（Activation-aware Weight Quantization）：
- AMD 官方重点支持的 4bit 方案
- 已集成在 Hugging Face autoawq 与 AMD Quark 中
- 优点：不依赖 CUDA 特定内核，使用标准算子即可
GPTQ：
- 另一种流行的 4bit 方案，通常通过单一 INT4 矩阵乘内核获得高性能
- 在部分实现中，GPTQ 可能比 AWQ 更快，但对运行时与 HIP 支持要求更高
- 某些高性能项目（如 exllama / exllamav2）目前仍是 CUDA 专用，AMD 上需谨慎评估

选择建议：

使用 Transformers / Accelerate + ROCm 时，AWQ 往往更“开箱即用”
GPTQ 可能需要 AutoGPTQ + trust_remote_code=True，并视具体实现决定是否真正跑在 HIP 上
若使用 vLLM 或 text-generation-inference，需要确认其 GPTQ/AWQ 内核是否支持 HIP

混合精度与分层量化

DeepSeek 的 MoE 架构对精度较敏感，实践中常见策略是：

大部分层使用 Int4
对关键专家层保留 Int8 或 FP16

在 AMD 上，部分工具支持“排除某些层不做 4bit 量化”，实现混合精度模型。若你发现纯 4bit 模型质量明显下降，可尝试：

使用混合量化（关键层高精度）
或退一步选择更小的模型，但保持更高精度

在 Mac 上，llama.cpp 的量化通常是全局统一的，暂不易做精细分层控制。

版本兼容提醒：

GGUF 有版本号，需使用与模型格式匹配的最新 llama.cpp
AWQ/GPTQ 也依赖库版本，需保持 Transformers、vLLM 等为较新版本

第 6 部分：常见问题索引

下面是 DeepSeek 在 AMD ROCm 与 Mac Metal 部署时的常见问题索引，以及对应章节：

“No HIP GPUs are available”（AMD ROCm）
- 含义：程序未能识别到 AMD GPU
- 解决：见第 3 部分“问题 1：No HIP GPUs are available”
Mac 上 DeepSeek 跑在 CPU 而非 GPU（Metal 未启用）
- 现象：推理极慢、CPU 满载、GPU 空闲
- 解决：见第 4 部分“Mac 问题 1：Metal GPU 未被使用”，确保编译启用 Metal 并设置 --n_gpu_layers
显存 OOM / 内存不足错误
- AMD：见第 3 部分“问题 4：内核启动失败或显存 OOM”
- Mac：见第 4 部分“Mac 问题 2：统一内存 OOM 或疯狂换页”
- 通用思路：量化 + 减小上下文 + 控制 batch size
“invalid device function”等 ROCm 相关错误
- 含义：GPU 架构与 ROCm/内核代码不匹配
- 解决：见第 3 部分“问题 2：ROCm 版本不匹配或 invalid device function”
Mac 上构建/安装失败（llama.cpp / llama-cpp-python / Ollama）
- 解决：见第 4 部分“Mac 问题 3：Metal / Xcode 构建与安装失败”，重点检查 Xcode CLI 与 CMake 配置
量化后输出异常（答非所问或明显“糊”）
- 可能是量化过度（纯 4bit 且无混合精度）
- 解决：见第 5 部分“混合精度与分层量化”，尝试更高精度或混合量化

硬件兼容性与性能会随驱动、ROCm 版本和 llama.cpp 更新而变化。部署生产环境前，请始终查阅官方文档与最新兼容性说明。

结语

在 NVIDIA 生态之外运行 DeepSeek 完全可行，只要选择合适的运行时与配置：

AMD ROCm：为 Radeon / Instinct GPU 提供成熟的加速平台，配合 ROCm 版 PyTorch、Transformers、vLLM 以及 AWQ/GPTQ 等量化方案，可以高效部署 DeepSeek
Apple Metal（Mac）：借助 Metal 加速的 llama.cpp 或 Ollama，在 M 系列 Mac 上运行中等规模的 DeepSeek 模型完全可行，尤其配合 4bit GGUF 量化

实践中，请始终注意：

驱动、ROCm、PyTorch、Transformers、llama.cpp 等版本要彼此匹配
根据显存/内存情况合理选择模型规模与量化精度
遇到错误先对照本文问题索引逐项排查

想了解官方 DeepSeek 模型列表与更多使用方式，可参考 DeepSeek 主指南。充分理解模型变体与部署格式，有助于你在 AMD ROCm 与 Apple Metal 环境中选出最适合的组合。

在 AMD ROCm 与 Mac Metal 上运行 DeepSeek：兼容性矩阵与排错全指南

第 1 部分：快速决策指南

使用 AMD GPU（ROCm）时

使用 Apple Silicon（Mac）时

只能 CPU 运行时

第 2 部分：DeepSeek 兼容性矩阵概览

第 3 部分：在 AMD ROCm 上运行 DeepSeek

推荐的 AMD 运行时栈

问题 1：“No HIP GPUs are available”

问题 2：ROCm 版本不匹配或 “invalid device function”

问题 3：“CUDA-only” 包相关错误（NCCL / bitsandbytes 等）

问题 4：内核启动失败或显存 OOM

第 4 部分：在 Mac Metal 上运行 DeepSeek

推荐工作流：GGUF + llama.cpp / Ollama

llama.cpp（Metal 后端）

Ollama

Mac 问题 1：Metal GPU 未被使用（推理极慢）

Mac 问题 2：统一内存 OOM 或疯狂换页导致卡顿

Mac 问题 3：Metal / Xcode 构建与安装失败

第 5 部分：按平台选择模型格式与量化策略

Apple Silicon（Mac）：首选 GGUF

AMD ROCm（AMD GPU）：FP16 + AWQ/GPTQ

混合精度与分层量化

第 6 部分：常见问题索引

结语

标签

评论

相关阅读

2026 年的 DeepSeek：从 V2 到 V3.2 发生了什么变化，现在的用户该怎么看

如何为品牌拍摄撰写AI图像提示词

什么是Claude托管代理？