在 AMD ROCm 与 Mac Metal 上运行 DeepSeek：兼容性矩阵与故障排查指南

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

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

• 哪些推理框架在该平台上更稳定
• 哪种模型格式更实用
• 能用到什么精度/量化方案
• 最先暴露的错误是驱动识别、算子不支持、显存压力，还是“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 安装），然后以 FP16（半精度）或合适的量化格式加载 DeepSeek 模型。
• ROCm 版本务必与具体 GPU 型号的官方支持矩阵匹配。
• 如果遇到代码中硬编码的 CUDA 调用，需要替换或打补丁为 HIP/ROCm 等价实现（详见第 3 部分）。

如果你使用 Apple Silicon（Mac）：

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

如果只能 CPU 运行：

• 仅作为无可用 GPU 或 GPU 兼容性问题难以解决时的兜底方案。
• 选择最小的 DeepSeek 变体，或使用高强度量化（如 7B 蒸馏模型的 4 比特版本），否则推理速度会慢到“按分钟计时”。
• 可以参考 DeepSeek 量化指南缩小模型体积，将 CPU 部署仅用于开发/调试；只要条件允许，优先使用 GPU（包括 Apple 集成 GPU）进行推理。

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

本节原文为一张矩阵，概括不同平台上推荐的运行时与模型格式，并标注典型问题及对应排查章节。核心要点如下（HF = Hugging Face，FP16 = 半精度浮点）：

• AMD ROCm： PyTorch（ROCm 版）+ Transformers / vLLM，优先 FP16 或 4/8 比特量化（AWQ/GPTQ）。
• Mac Metal： GGUF + llama.cpp（Metal）或 Ollama，优先 4 比特 GGUF。
• CPU： 仅适合小模型或重度量化模型，作为最后备选。

详细的运行时与错误排查，分别见第 3、4、5 部分。

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

在 AMD GPU 上运行 DeepSeek 需要完整的 ROCm 软件栈，并对默认“只考虑 CUDA”的代码做一些小改动。ROCm 通过 HIP 平台提供 GPU 加速，与 PyTorch 和 Transformer 模型基本兼容。下面先给出推荐运行时，再逐一拆解常见问题与解决方案。

推荐的 AMD 运行时组合

如果你的 AMD GPU 支持 ROCm（如 Radeon RX 6000/7000 系列或 Instinct 系列），加载 DeepSeek 主要有两条路线：

1. vLLM on ROCm

   • vLLM 是为高效推理和 VRAM 利用优化的推理引擎，现已提供实验性/社区驱动的 ROCm/HIP 支持。
   • 使用前务必查阅 vLLM 官方文档确认当前版本对 ROCm 的支持状态。
   • 在 AMD 上使用 vLLM，可获得良好的多卡扩展能力和较快的 token 生成速度，尤其适合 DeepSeek 这类 MoE（Mixture-of-Experts）大模型。
   • 确保使用 ROCm 版 vLLM 构建；必要时按文档设置 VLLM_USE_V1=0 等环境变量。
   • 若使用 GPTQ/AWQ 等量化模型，注意 MoE 层可能需要补丁（例如自定义 gptq_marlin.py 以支持按 expert 量化），具体以 vLLM 文档为准。

2. Transformers（Hugging Face）+ ROCm 版 PyTorch

   • 传统做法：使用 AutoModelForCausalLM.from_pretrained 加载模型。
   • 安装与 ROCm 版本匹配的 PyTorch（如 pip install torch==2.x.y+rocm），并使用兼容版本的 Transformers。
   • 在 ROCm 版 PyTorch 中，设备字符串通常仍暴露为 cuda，但底层实际通过 HIP/ROCm 执行。
   • 确认 GPU 已被 PyTorch 识别后，再将模型迁移到加速设备。
   • 可通过 torch.set_default_dtype(torch.float16) 或 model.half() 使用 FP16；部分 8/4 比特流程也已支持。
   • BitsAndBytes 8 比特： 需安装带 ROCm 支持的 fork（AMD 文档中有 0.44+ HIP 版安装说明），然后才能使用 load_in_8bit=True。
   • AMD Quark： AMD 自家的量化工具，可导出原生 PyTorch 或 Hugging Face AWQ 格式模型。
   • 4 比特可使用 AutoGPTQ 或 Hugging Face 的 AutoAWQ 加载 AWQ/GPTQ 模型，在 20GB 级别消费级显存上运行中等规模 DeepSeek 模型。

下面按“症状—原因—解决步骤”的结构，逐条说明在 AMD 上常见问题。

问题 1：“No HIP GPUs are available” 错误

症状：

• 通过 vLLM 或 PyTorch 启动 DeepSeek 时，报错：RuntimeError: No HIP GPUs are available，或提示找不到 GPU/加速器。

可能原因：

• 程序无法访问 AMD GPU，常见是驱动或权限问题：
  • 裸机 Linux 上，当前用户可能没有访问 /dev/kfd、/dev/dri 的权限（未加入 video 组）。
  • 容器环境中，启动参数未正确透传 GPU 设备。
  • ROCm 未正确安装或初始化（若 rocminfo/rocm-smi 也看不到 GPU，则多半是驱动问题）。

解决步骤：

1. 验证 ROCm 安装：

   • 在宿主机运行 rocminfo 或 rocm-smi，确认 GPU 被识别。
   • 若无法识别，按 AMD 官方文档重新安装与 GPU 型号匹配的 ROCm 版本。

2. 检查用户权限（裸机）：

   • 将当前用户加入 video 组：
     • sudo usermod -aG video $USER，然后注销/重新登录。
   • 这是 AMD 官方推荐的方式，使 PyTorch(HIP) 在非 root 用户下访问 GPU。

3. 容器配置（如使用 Docker）：

   • 启动容器时添加：--device=/dev/kfd --device=/dev/dri --group-add=video 等参数。
   • 优先使用 AMD 提供的 ROCm 容器镜像（如 rocm/pytorch），并按官方说明启动。

4. 在 Python 中测试：

import torch
print(torch.cuda.is_available())
print(torch.cuda.device_count())

• 在 ROCm 版 PyTorch 中，这里的 cuda 实际映射到 HIP。
• 期望输出：True 且设备数量 ≥ 1；否则说明 GPU 仍不可用，要回头检查驱动、权限和 PyTorch 版本。

兜底方案：

• 若 GPU 型号或驱动确实不受支持，只能退回 CPU 推理（极慢，仅适合小模型或短 prompt）。
• 可考虑使用带 AMD GPU 的云主机，或更换为受 ROCm 支持的显卡。

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

症状：

• DeepSeek 在加载或首轮推理时崩溃，报错类似：hipErrorInvalidDeviceFunction，或出现莫名段错误。
• 自行编译的扩展可能提示 GFX/ISA 不支持。

可能原因：

• 安装的 ROCm 版本与 GPU 架构不匹配，或 PyTorch/扩展未针对当前 GPU 生成合适的代码：
  • 新 GPU + 旧 ROCm 版本。
  • 使用了不包含当前 GPU 架构代码生成的预编译 PyTorch。

解决步骤：

• 对齐 ROCm 与硬件：

  • 查阅 AMD 官方支持矩阵，确认当前 GPU 对应的 ROCm 最低版本。
  • 例如 RX 7800 XT（Navi 3x）通常需要 ROCm 5.6+。

• 优先使用官方 Docker 镜像：

  • 使用 rocm/pytorch: 等官方镜像，减少宿主机与容器环境不一致带来的问题。

• 重新安装/编译 PyTorch：

  • 对于非常新的或少见的 GPU，可能需要从源码编译 PyTorch，并在构建参数中显式指定 GPU 架构。

• 必要时设置环境变量：

  • 某些极新 GPU 可在 AMD 指南下谨慎使用 HSA_OVERRIDE_GFX_VERSION，但需严格按官方说明操作。

• 完成上述调整后，再次运行 torch.cuda.is_available() 等简单测试，确认不再出现 invalid device 错误。

兜底方案：

• 若 GPU 架构完全不在 ROCm 支持列表中，只能：
  • 换用受支持的 GPU（NVIDIA 或旧一代 AMD），或
  • 退回 CPU / 云端推理。

问题 3：“只支持 CUDA”的依赖报错（如 NCCL、bitsandbytes）

症状：

• 导入或运行 DeepSeek 相关代码时，报错指向 CUDA 或 NVIDIA 专用库，例如：
  • RuntimeError: CUDA error: no kernel image is available for execution
  • 找不到 libcudart.so、nccl.dll 等。
  • bitsandbytes 提示“未编译 GPU 支持”。

可能原因：

• LLM 生态中很多库默认只支持 NVIDIA CUDA：
  • NCCL 是 NVIDIA 的多卡通信库，ROCm 对应的是 RCCL。
  • bitsandbytes 默认是 CUDA 版，需要单独安装 ROCm fork。
  • 某些脚本直接调用 torch.cuda.xxx 并假定是 NVIDIA 设备。

解决步骤：

1. 避免不必要的 NCCL 路径：

   • 若不做多卡分布式训练/推理，尽量避免初始化 NCCL。
   • 在 ROCm 环境中，使用基于 RCCL 的分布式后端，并按官方指南配置。

2. 使用 ROCm 版关键库：

   • bitsandbytes：安装带 HIP 支持的 ROCm fork，AMD 文档中有具体 wheel 或源码分支说明。
   • 安装成功后，import bitsandbytes 不应再提示“无 GPU 支持”。

3. 修补硬编码 CUDA 的代码：

   • 若 DeepSeek 相关脚本显式调用 torch.cuda.set_device、torch.cuda.is_available() 并假定是 NVIDIA，可适度修改逻辑：
     • 大多数 CUDA API 在 ROCm 中已通过别名兼容，但若代码检查 device_properties().name 是否包含“NVIDIA”，就需要去掉或改写。

4. 升级 Transformers 等上层库：

   • 新版本通常更 GPU 无关，避免旧版本中“强行加载 CUDA 内核”的问题。

兜底方案：

• 若短期内无法修好 CUDA 依赖，可暂时强制在 CPU 上运行（如 device_map={'': 'cpu'}），代价是性能大幅下降。
• 长期建议使用已适配 AMD 的 fork 或向上游提交补丁。

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

症状：

• 模型能加载，但推理时出现：
  • RuntimeError: HIP error: invalid kernel launch
  • “out of memory” 或 “Memory access fault” 等错误。
• 多卡场景下，可能只有某一张卡挂掉。
• 常在长上下文或长输出生成时触发。

可能原因：

• 实际上已经耗尽或严重碎片化了显存，或触发了某些 HIP 内核实现的 bug：
  • DeepSeek 模型巨大，长上下文时注意力和 KV cache 占用显存极高。
  • 某些大矩阵运算在 ROCm 上缺少成熟优化路径，在极端规模下可能崩溃。
  • 多卡切分不当，导致单卡负载过大。

解决步骤：

• 降低显存压力：

  • 减小 batch size 或 prompt 长度，例如从 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：

  • 新版本通常改进了内存管理与内核稳定性，尤其是 ROCm 5→6 期间对大模型支持有明显提升。

• 显式清理缓存：

  

  • 在长时间循环中，适时调用 torch.cuda.empty_cache()（在 ROCm 上同样清理 HIP 缓存），缓解显存碎片化。

兜底方案：

• 若缩小负载仍频繁 OOM，可考虑：
  • 使用 Accelerate 的 device_map 将部分权重 offload 到 CPU 或多卡。
  • 使用 4 比特量化模型（显存占用约为 FP16 的 1/4）。

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

Apple M1/M2 系列芯片（Apple Silicon）具备高带宽统一内存，是本地运行 DeepSeek 等 LLM 的不错平台。但前提是使用针对 Apple GPU 的 Metal API，而非 CUDA。llama.cpp 的 Metal 后端可以在 Apple Silicon 上启用 GPU 加速，Ollama 则在其基础上提供更易用的界面。

推荐的 Mac 工作流

• 使用 GGUF 格式 的 DeepSeek 模型，并通过 llama.cpp（或基于 llama.cpp 的 Ollama）运行。
• GGUF 是本地推理的事实标准格式，支持高效加载与原生量化。
• 你可以：
  • 从可信模型库下载社区已转换好的 DeepSeek GGUF（注意核对基座模型、许可证与转换说明），或
  • 使用 llama.cpp 官方转换脚本，将 Hugging Face checkpoint 转为 GGUF。
• 拿到 .gguf 文件后：
  • 可直接用 llama.cpp CLI 运行，获得最大控制权；
  • 或用 Ollama 以获得更友好的 GUI/CLI 体验。

llama.cpp（Metal）

• 在 Mac 上编译 llama.cpp 时，开启 Metal 支持（参考官方 build 文档）。
• 若使用 Python 绑定（llama-cpp-python），安装时同样要确保启用 Metal（官方文档有 macOS 安装说明）。
• 安装完成后，通过 n_gpu_layers 等参数开启 GPU offload，即便只 offload 部分层，也能显著快于纯 CPU。

示例（具体命令行参数以当前版本文档为准）：

./main -m DeepSeek.gguf --n-gpu-layers 

• --n_gpu_layers 指定要 offload 到 GPU 的层数：
  • 若不设置或为 0，则全部在 CPU 上运行。
  • 实践中可先给一个较小值确认 Metal 已生效，再逐步增大，直到接近内存上限或出现不稳定。
  • 例如 32GB 内存的 M2 Pro/Max 通常可以 offload 相当多层，统一内存也允许在必要时回退到 RAM（但会变慢）。

Ollama

• 安装 Ollama for Mac，通过 GUI 或 CLI 运行 DeepSeek。
• 若官方仓库中尚无 DeepSeek，可编写自定义 Modelfile，在其中引用本地 GGUF 文件，例如：FROM ./DeepSeek.gguf。
• 然后执行 ollama run your-model-name 即可。
• Ollama 会自动在 Apple Silicon 上使用 Metal 加速（Intel Mac 不支持）。

下面是 Mac 上常见问题与解决方案。

问题 1：Metal GPU 未被使用（DeepSeek 极慢）

症状：

• 推理速度极慢，CPU 占用很高，GPU 几乎空闲。
• llama.cpp 启动日志中只提到 CPU，没有 Metal；Ollama 中也表现为 CPU 满载、GPU 空闲。

可能原因：

• Metal 后端未启用，或未设置 GPU offload：
  • llama.cpp 未以 Metal 选项编译。
  • 运行时未指定 n_gpu_layers，默认全部在 CPU 上执行。
  • 机器为 Intel Mac，不支持 Metal LLM 推理。

解决步骤：

1. 确认编译启用 Metal：

   • 手动编译 llama.cpp 时，使用 -DGGML_METAL=ON 等选项。
   • 使用 llama-cpp-python 时，按官方文档在安装阶段启用 Metal，并通过小模型测试 GPU offload 是否生效。

2. 运行时指定 --n_gpu_layers：

   • 任何正数都能验证 Metal 是否在工作，例如 --n_gpu_layers 1。
   • 为获得最佳速度，逐步增加 offload 层数，直到接近内存极限。

3. 监控 GPU 使用情况：

   • 使用 macOS 活动监视器或 Metal 性能工具，确认 GPU 是否有负载。

4. Ollama 特殊注意：

   • 确保使用的是 Apple Silicon 版 Ollama，而非在 Rosetta 下运行的 Intel 版。
   • 自定义 Modelfile 中只需正确引用 GGUF 文件，Ollama 会自动使用 Metal。

兜底方案：

• 若 Metal 始终无法启用，只能退回 CPU 推理：
  • 选择最小的 DeepSeek 变体（如 7B 或蒸馏版）。
  • 或将推理放在外部服务器，通过 API 从 Mac 访问。

问题 2：Mac 上内存不足或频繁交换导致卡顿

症状：

• 系统 RAM 占用飙升，整体变得卡顿，甚至进程被系统杀掉。
• llama.cpp 可能提示 KV cache 或上下文分配失败。

可能原因：

• Apple Silicon 使用 统一内存，CPU 与 GPU 共享同一物理内存：
  • 实际可用于 GPU 的内存有限，当模型权重 + KV cache + 其他进程占用过高时，macOS 会开始交换（swap）。
  • 一旦大量 swap，性能会急剧下降，甚至导致进程被系统终止。
• 长上下文窗口会显著增加注意力与 KV cache 占用：
  • 短 prompt 运行正常，长 prompt 或大 batch 时突然变得极慢或崩溃。

解决步骤：

1. 使用更小的量化：

   • 优先选择 4 比特 GGUF（如 Q4_0），若 Q4_K/Q5_0 仍 OOM，可退回更基础的 Q4_0。
   • 5 比特模型比 4 比特大约多 25% 体积，在边缘内存场景差异明显。

2. 降低上下文长度：

   • 避免一上来就使用极长上下文，先用 2048 或 4096 token 测试。
   • 对 DeepSeek 这类大模型，超长上下文在 Mac 上本就会非常慢，必要时考虑迁移到服务器级 GPU。

3. 监控内存压力：

   • 观察 macOS 内存压力图，变红说明已在大量交换。
   • 若发现首轮 prompt 处理极慢，而后续生成变快，可能是部分计算被挤到 CPU/ANE 上。

4. 选择更小的模型变体：

   • 16GB 内存的 Mac 上，32B 4 比特模型往往过于吃紧。
   • 优先选择 7B/13B 级别的 DeepSeek 变体。

兜底方案：

• 若仍频繁 OOM，可通过减少 n_gpu_layers 将部分层退回 CPU：
  • 例如从 --n_gpu_layers 50 降到 --n_gpu_layers 30。
  • 这是一种“分层到不同设备”的折中方案，牺牲部分速度换取稳定性。
• 若仍不稳定，只能进一步减小量化比特数或换用内存更大的机器。

问题 3：Metal 或 Xcode 相关的构建/安装失败

症状：

• 安装 llama.cpp 或 llama-cpp-python 时失败：
  • pip 安装报错，CMake 提示找不到 Metal 框架或编译器。

可能原因：

• 构建 Metal 版本需要完整的 Xcode 命令行工具和正确的 CMake 配置：
  • 未安装 Xcode CLI 工具，导致找不到 Apple Clang 或 Metal SDK。
  • CMake 版本过旧或环境变量未正确设置。

解决步骤：

1. 安装 Xcode 命令行工具：

   • 终端执行：xcode-select --install。
   • 用 xcode-select -p 确认路径已指向开发者目录。

2. 更新构建工具：

   • 使用 Homebrew 安装最新 CMake 等：brew install cmake。

3. 正确设置 CMake 选项：

   • 编译 llama.cpp 时使用 -DGGML_METAL=ON 等参数。
   • 必要时设置 MACOSX_DEPLOYMENT_TARGET=12 或 13，避免符号兼容性问题。

4. 使用预编译发行版：

   • 若本地编译困难，可考虑使用 Conda Forge 上的预编译包（通常已启用 Metal）。

5. Ollama 安装注意：

   • 确保系统版本在 macOS 12+，并使用官方安装方式（dmg 或 Homebrew）。

兜底方案：

• 若始终无法构建 Metal 版，可暂时使用 CPU-only 版本，但性能会大幅下降。
• 也可以关注 Core ML 生态（Apple 已提供 Llama 2 的 Core ML 转换），未来 DeepSeek 也可能出现类似方案。

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

不同硬件平台适合的模型格式和量化策略差异很大。本节给出按平台的推荐组合。

Apple Silicon（Mac）：首选 GGUF

• GGUF（GGML 的后继格式）是 Mac 上通过 llama.cpp 运行 LLM 的事实标准：
  • 支持高效内存映射与原生量化。
  • llama.cpp 工具链可直接将 Hugging Face 模型转换为 GGUF。
• 建议：
  • 大模型优先使用 4 比特量化（如 DeepSeek 30B 的 Q4_0.gguf），显著降低内存占用。
  • FP16 GGUF 虽可行，但通常过大，往往只能在 CPU 上跑，体验较差。

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

• 在 AMD 上通常使用 PyTorch 或类似框架，格式选择更灵活：

  • 若显存充裕（如 48GB+ 的 Instinct MI210/MI300X），可直接使用 FP16/BF16，获得最佳精度。
  • 大多数用户会选择 4/8 比特量化以降低显存占用。

• AWQ（Activation-aware Weight Quantization）：

  • 4 比特权重量化方案，AMD 官方工具 Quark 与 Hugging Face autoawq 均已支持。
  • 优点是依赖标准算子，不强绑 CUDA，自然适配 ROCm。

• GPTQ：

  • 另一种流行的 4 比特方案，通常通过单个 INT4 矩阵乘内核实现高效推理。
  • 在部分实现中，GPTQ 可能比 AWQ 更快，但对运行时和内核实现依赖更强：
    • 某些项目（如 exllama/exllamav2）高度依赖 CUDA Triton 内核，在 ROCm 上需要额外适配。

• 实践建议：

  • 使用 Transformers/Accelerate + ROCm 时，AWQ 更“开箱即用”：
    • 可用 Quark 或 AutoAWQ 量化并加载。
  • GPTQ 在 ROCm 上通常需要 AutoGPTQ + trust_remote_code=True 等配置，性能是否优于 AWQ 取决于具体实现。

混合精度与其他策略

• DeepSeek 的 MoE 架构对精度较敏感，纯 4 比特有时会明显损失质量。
• 社区实践表明：
  • Int4 + Int8 混合（对敏感层保留 8 比特）能显著改善质量。
  • 某些工具支持“按层选择量化精度”，可只对部分层做 4 比特量化。
• 在 Mac 上，llama.cpp 目前主要是统一量化，难以做精细分层控制；在 AMD 上，通过 PyTorch + 自定义量化工具可以实现更灵活的混合精度方案。

无论使用哪种量化方式，都要确保运行时版本与量化格式匹配：

• GGUF 有版本号，需使用支持对应版本的最新 llama.cpp。
• AWQ/GPTQ 也依赖 Transformers、vLLM 等库的版本支持。

第 6 部分：常见问题索引

下面是常见 DeepSeek 部署问题与本指南中对应的解决位置：

• “No HIP GPUs are available”（AMD ROCm）

  • 含义：程序未检测到 AMD GPU。
  • 解决：见第 3 部分“问题 1：No HIP GPUs are available”，多半是权限或环境配置问题。

• Mac 上 DeepSeek 只跑在 CPU 上（Metal 未启用）

  • 表现：生成极慢、CPU 满载、GPU 空闲。
  • 解决：见第 4 部分“问题 1：Metal GPU 未被使用”，需要编译启用 Metal 并设置 --n_gpu_layers。

• 显存不足 / GPU 内存错误（AMD 与 Mac 通用）

  • 解决：
    • AMD：见第 3 部分“问题 4：内核启动失败或显存 OOM”。
    • Mac：见第 4 部分“问题 2：内存不足或交换导致卡顿”。
  • 通用思路：量化、缩短上下文、减小 batch size。

• “invalid device function” 等设备函数错误（AMD）

  • 含义：GPU 架构与 ROCm/内核编译目标不匹配。
  • 解决：见第 3 部分“问题 2：ROCm 版本不匹配或 invalid device function”。

• Mac 上构建/安装失败（Metal 或 Xcode）

  • 解决：见第 4 部分“问题 3：Metal 或 Xcode 相关构建/安装失败”，关键是安装 Xcode CLI 工具并正确设置 CMake 选项。

• 量化后输出异常（答非所问或乱码）

  • 含义：量化过度或量化配置不当导致模型退化。
  • 解决：见第 5 部分关于混合精度的建议，尝试：
    • 使用更高比特（如 5/8 比特），或
    • 对关键层保留更高精度，或
    • 换用更小但精度更高的模型变体。

结语

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

• AMD ROCm 为 Radeon/Instinct GPU 提供了成熟的推理平台，配合 ROCm 版 PyTorch、Transformers、vLLM 以及 AWQ/GPTQ 等量化方案，可以高效部署大规模 DeepSeek 模型。
• Apple M 系列 Mac 借助 Metal 加速的 llama.cpp/Ollama，可以在本地流畅运行中小规模 DeepSeek 模型，配合 GGUF + 4 比特量化，在 16–32GB 统一内存机器上也能获得可用体验。

部署时务必注意：

• 驱动、ROCm、PyTorch、llama.cpp 等版本要与硬件和模型格式匹配；
• 遇到错误先对照本指南的“症状—原因—解决步骤”排查；
• 不要犹豫使用量化与混合精度，将模型压缩到与你的硬件能力相匹配的规模。

如需了解官方 DeepSeek 模型列表、功能差异与更多部署选项，可参考 DeepSeek 主指南，结合本篇的 ROCm/Metal 实战建议，为你的硬件选择最合适的模型与格式。