本地部署大模型：RX 7900 XTX + llama.cpp 全记录

发表于 更新于 分类于

在 AI 大模型的时代，”数据隐私”和”响应速度”越来越成为关注点。与其把敏感信息发送到云端 API，不如在自家局域网里跑一个本地模型。

本文记录我在 ai-server 上部署 Qwen 3.6 27B 的全过程 —— 从硬件选型、ROCm 环境搭建、llama.cpp 编译，到 systemd 守护和性能调优。希望给同样想在消费级 AMD 显卡上跑大模型的朋友一些参考。

🛠 一、硬件清单

组件 规格
主板 Gigabyte B460M AORUS ELITE（PCIe 3.0 x16）
CPU Intel Core i5-10400F（6 核 12 线程，2.9~4.3GHz）
GPU AMD Radeon RX 7900 XTX 24GB（蓝宝石 PULSE）
内存 24GB DDR4-2400（计划升级到 128GB）
系统盘 171GB SSD（可用 103GB）
系统 Ubuntu 24.04.4 LTS，Kernel 6.8.0-124
网络 无线 wlp5s0，内网环境

为什么选 AMD 显卡？

RX 7900 XTX 拥有 24GB GDDR6 显存。在消费级显卡里，24GB 这个价位段的选择并不多 —— NVIDIA 这边要 RTX 4090 才能达到 24GB，而 AMD 的 7900 XTX 价格更友好，性价比明显。配合 ROCm 7 的日益成熟，在消费级 AMD GPU 上跑 LLM 已经是一条完全可行的路。

⚠️ 注意： B460 主板的 PCIe 3.0 x16 带宽约为 16 GB/s，而 GDDR6 显存带宽超过 600 GB/s，两者相差 40 倍。这意味着当 KV cache 溢出到系统内存时，PCIe 带宽会成为非常明显的瓶颈。如果你要装机，建议至少选 PCIe 4.0 的主板。

🐳 二、ROCm 环境搭建

ROCm 是 AMD 的 GPU 计算平台，类似于 NVIDIA 的 CUDA。在 Ubuntu 24.04 上安装 ROCm 比想象中要顺利。

安装步骤

Ubuntu 24.04 的官方源已经包含了 ROCm 7 系列的软件包，直接通过 apt 安装即可：

1
2
3
# 添加 ROCm 仓库并安装
sudo apt update
sudo apt install rocm-hip-libraries rocm-device-libs rocm-smi-lib

安装完成后，确认 ROCm 版本：

1
2
3
# 查看 ROCm 信息
rocm-smi
hipcc --version

输出结果：

1
2
HIP version: 7.2.53211-97f5574fe2
AMD clang version 22.0.0git
1
2
Device  Node  IDs              Temp    Power  Partitions          SCLK  MCLK    Fan    Perf  PwrCap  VRAM%  GPU%
0       1     0x744c,   5113   67.0°C  61.0W  N/A, N/A, 0         0Mhz  772Mhz  60.0%  auto  303.0W  86%    0%

GPU 被正确识别为 gfx1100（Navi 31 架构），ROCm 运行正常。

安装过程中的注意点

内核模块：amdgpu 内核模块是 Ubuntu 24.04 自带的，安装完 ROCm 后会自动加载：

1
2
3
lsmod | grep amd
# amdgpu              17166336  3
# amdxcp                 12288  1 amdgpu

GPU 目标架构：RX 7900 XTX 对应的是 gfx1100。编译 llama.cpp 时需要指定这个目标，否则 GPU 加速无法生效。如果你的显卡型号不同，可以在 AMD GPU 列表 中查到对应的 gfx 代号。

用户权限：确保运行推理服务的用户在 video 用户组中，这样才有权限访问 GPU 设备：

1
sudo usermod -aG video elric

🔨 三、编译 llama.cpp

llama.cpp 是一个用纯 C/C++ 编写的 LLM 推理框架，支持 GGUF 格式的模型文件，对 AMD GPU 通过 ROCm/HIP 提供了良好的支持。

源码克隆与构建

1
2
3
4
5
git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
mkdir build && cd build
cmake .. -DGGML_HIP=ON -DGPU_BUILD_TARGETS=gfx1100 -DCMAKE_BUILD_TYPE=Release
make -j$(nproc)

关键构建参数说明

参数 说明
-DGGML_HIP=ON 启用 HIP 后端，让 AMD GPU 加速生效
-DGPU_BUILD_TARGETS=gfx1100 指定 GPU 目标架构为 Navi 31（RX 7900 XTX）
-DCMAKE_BUILD_TYPE=Release Release 模式编译，性能更好

构建结果确认

编译完成后，可以通过 cmake -LH .. 查看配置摘要，确认关键项：

1
2
3
4
5
GGML_HIP:BOOL=ON
GGML_HIP_GRAPHS:BOOL=ON
GGML_HIP_MMQ_MFMA:BOOL=ON
GPU_BUILD_TARGETS:STRING=gfx1100
CMAKE_BUILD_TYPE:STRING=Release
  • GGML_HIP_GRAPHS=ON 表示 GPU 计算图优化已启用，可以提升推理效率
  • GGML_HIP_MMQ_MFMA=ON 表示使用了 AMD 的矩阵乘法加速指令
  • GGML_AVX、GGML_AVX2、GGML_AVX512 全部为 OFF —— 因为 GPU 承担了主要计算，CPU 指令集优化的收益不大

经验之谈： 编译时间取决于 CPU 核心数。i5-10400F（6 核）大约需要 15-20 分钟。如果用的是更多核心的 CPU，可以进一步缩短。

📦 四、模型选择

模型是本次部署的核心选择。我选用了 Qwen 3.6 27B 的 abliterated 版本：

1
2
3
模型文件: huihui-qwen3.6-27b-abliterated-q4_k_m.gguf
大小: 16.5GB
量化: Q4_K_M（4-bit 混合精度）

为什么是 abliterated 版本？

abliterated（去拒绝化）版本是通过 OBLITERATUS 工具处理过的模型。它去除了模型的安全拒绝机制，让输出更加自由灵活。

对于本地私有部署来说，这个特性非常实用：

  • ✅ 不会无缘无故拒绝回答问题 —— 云端模型经常因为安全策略拒绝回答一些完全正常的问题，本地部署的 abliterated 版本则直接给出答案
  • ✅ 输出更直接 —— 不需要绕过安全过滤，回答更自然
  • ✅ 更适合个人使用和开发调试 —— 没有安全层的干扰，方便测试和迭代

为什么选 Qwen 3.6 27B？

27B 参数规模是一个甜蜜点 —— 比 7B/8B 强一个档次，同时 24GB 显存用 Q4_K_M 量化（约 16.5GB）后可以装下，还留有显存给 KV cache 和系统开销。

如果你显存更大（48GB+），可以考虑 Qwen 3.6 更大参数的版本。如果显存更小（12GB 左右），7B/8B 的模型会更合适。

⚙️ 五、systemd 守护进程

为了让模型服务持续运行，配置了 systemd 服务。这样即使 SSH 断开，服务也不会停止。

服务文件

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
# /etc/systemd/system/llama.service
[Unit]
Description=Llama CPP Server with ROCm Acceleration (64K + Continuous Batching)
After=network.target

[Service]
Type=simple
User=elric
ExecStart=/home/elric/llama.cpp/build/bin/llama-server \
  -m /home/elric/llama.cpp/models/huihui-qwen3.6-27b-abliterated-q4_k_m.gguf \
  --alias qwen3.6-27b \
  --host 0.0.0.0 \
  --port 1234 \
  -ngl 99 \
  --flash-attn on \
  -np 1 \
  -b 4096 \
  -ub 1024 \
  --ctx-size 65536 \
  -ctk q8_0 \
  -ctv q8_0 \
  --threads 6 \
  --jinja
Restart=always
RestartSec=5

[Install]
WantedBy=multi-user.target

然后启用服务：

1
2
sudo systemctl enable llama.service
sudo systemctl start llama.service

启动参数详解

参数 值 说明
-ngl 99 将所有层 offload 到 GPU，CPU 只做调度和采样
--flash-attn on 开启 FlashAttention，大幅加速注意力计算
-b 4096 批次大小，更大的批次提升 GPU 利用率
-ub 1024 微批次大小，影响单次计算粒度
--ctx-size 65536 上下文窗口 64K tokens
-ctk / -ctv q8_0 KV cache key/value 量化为 q8_0
--threads 6 CPU 线程数（与 i5-10400F 核数匹配）
--jinja 启用 Jinja 模板，支持 ChatML 等模板格式

显存预算：为什么是 q8_0 + 64K？

这部分值得多花点篇幅，因为这是整个配置最关键的决策。

KV cache 存储了对话历史中的注意力信息。它越大，能记住的上下文就越长，但也越占显存。量化策略需要在精度和显存之间做权衡。

24GB 显存的账本：

项目 q8_0 + 64K ✅ q8_0 + 128K ❌ q4_0 + 128K ✅
模型权重（Q4_K_M） ~16.5 GB ~16.5 GB ~16.5 GB
KV cache（最大） ~3.8 GB ~7.5 GB ~3.8 GB
ROCm 运行时 + 框架 ~1-2 GB ~1-2 GB ~1-2 GB
合计 ~21-22 GB ~25-26 GB ~21-22 GB
结果 ✅ 安全 ❌ 溢出到系统内存 ✅ 安全

q8_0 + 128K 会溢出 24GB 显存。 之前配置就是这样，VRAM 占用达到 86%，KV cache 溢出走 PCIe 3.0（仅 16 GB/s），生成速度直接从 25 t/s 掉到 10 t/s 以下。

最终方案：q8_0 + 64K

  • ✅ 显存安全（~22 GB，留了 ~2 GB 余量）
  • ✅ q8_0 高精度 KV cache，长对话不丢失上下文精度
  • ✅ 64K 上下文对日常使用完全够用（约 4-5 万汉字）
  • ✅ 速度稳定在 ~25 t/s，不波动

如果你选择 q4_0 KV cache： 每个 token 只需约 32KB，128K 上下文占用约 3.8GB，显存压力更小。适合想要更大上下文窗口的情况。

q8_0 的优势： 精度更高，长对话中缓存命中率更好，减少不必要的重算。实测下来，在显存够用的前提下，q8_0 带来的稳定性提升是值得的。

📊 六、性能实测

以下是实际运行中的数据，全部从服务日志直接抓取（journalctl -u llama.service）：

生成速度（Decoding）

场景 速度 延迟
持续长生成（800+ tokens） ~25 tokens/s ~40ms/token
短对话（KV 缓存命中） ~25 tokens/s ~40ms/token
长对话（KV 缓存未命中） ~24.6-24.8 t/s ~40.5ms/token

~25 tokens/s 的持续生成速度意味着一段 200 词的英文回复大约需要 8 秒完成，完全满足实时对话的需求。

Prompt 处理速度（Prefill）

Prompt 长度 速度 延迟
~1000 tokens（典型对话） ~428 tokens/s ~2.3ms/token

FlashAttention 的加速效果非常明显。

系统资源

指标 数值
GPU 显存占用 ~76%（约 18.2GB / 24GB）
GPU 温度 42°C（待机），63°C（负载）
GPU 功耗 88W（空闲） / ~300W（峰值）
服务运行时间 持续运行，稳定无故障
日志错误 0 条

💡 七、调优心得

1. 显存预算是第一要务

最开始用了 q8_0 + 128K 上下文，显存压到 86%，KV cache 溢出走 PCIe 3.0，速度直接腰斩。将 --ctx-size 降到 64K 后，显存降到 ~76%，速度稳定在 25 t/s，问题彻底解决。

教训： 24GB 显存不是无限的，q8_0 精度虽好，但 128K KV cache 会吃掉 7.5GB，加上 16.5GB 模型就 24GB+，一定会溢出。先算账，再调参。

2. PCIe 3.0 是隐形的瓶颈

B460 主板的 PCIe 3.0 带宽只有 ~16 GB/s。当显存不足、KV cache 被 offload 到系统内存时，每次 token 生成都要通过 PCIe 总线搬运数据，延迟显著增加。

实际体验： 当 KV cache 溢出到 CPU 内存时，生成速度能从 25 t/s 掉到 10 t/s 以下。确保 KV cache 完全留在显存里是提升性能的第一要务。

如果你要装机： 尽量选 PCIe 4.0 以上的主板。PCIe 3.0 在显存溢出时拖累严重。

3. 批次参数影响很大

将 -b 从 2048 提升到 4096、-ub 从 512 提升到 1024 后，GPU 利用率更高，生成速度从 ~21 tokens/s 提升到了 ~25 tokens/s。更大的批次意味着 GPU 的计算单元能更好地并行工作，减少等待。

建议： 如果你的显卡显存充裕，可以把 -b 设得更大（8192），看看效果。

4. KV cache 量化策略

早期配置使用 q4_0 KV cache，后来调整为 q8_0。虽然显存占用从 ~65% 上升到了 ~76%，但长对话场景下的生成速度更加稳定。原因是 KV cache 精度更高，减少了缓存失效带来的重算 —— 每次不用重新处理之前的上下文。

结论： 在显存预算内，优先给 KV cache 更高的量化精度。但前提是 总显存不溢出 —— 如果 q8_0 会溢出，那就果断用 q4_0。

5. 16GB 内存偏紧

系统原只有 16GB 内存，llama 进程本身就要占用约 6GB。加上系统和后台进程，可用内存比较紧张。在高负载时，系统会用到 Swap，影响响应速度。

已升级到 24GB，计划最终升级到 128GB M.2，不仅给 llama.cpp 更多余量，还能彻底解决内存瓶颈。

🔗 八、接入 Hermes Agent

部署完成后，模型通过 OpenAI 兼容 API 提供服务。Hermes Agent 通过自定义 provider 连接到本地端点：

1
http://localhost:1234/v1

这意味着：

  • 数据不出局域网 —— 所有对话内容完全私有
  • 无 API 调用费用 —— 一次部署，长期使用
  • 低延迟 —— 局域网内响应，没有公网往返

我的日常使用场景是：通过 Telegram 发消息给 Hermes，Hermes 调本地模型推理，整个流程在局域网内完成。写文章、查资料、调试代码……完全不需要把数据送到云端。

📝 九、总结

在消费级硬件上部署 27B 参数的本地大模型是完全可行的。RX 7900 XTX 的 24GB 显存是一个甜蜜点，配合 ROCm 7 和 llama.cpp，可以实现稳定的推理服务。

核心经验：

  1. 显存预算是硬约束 —— 24GB 要精确计算：模型 + KV cache + ROCm 开销，超出就会溢出
  2. q8_0 + 64K 是 24GB 显存的甜点配置 —— 高精度 KV cache + 安全显存余量 + 稳定速度
  3. PCIe 带宽不容忽视 —— 尽量让数据留在显存内，装机时选 PCIe 4.0 主板
  4. abliterated 版本更适合本地私有部署 —— 没有安全层的干扰，输出更自由
  5. systemd 守护 + OpenAI API 兼容 = 即插即用的服务 —— 任何支持 OpenAI API 的客户端都能直接接入

下一步： 内存升级到 128GB M.2，移除 Windows 11，让这台机器纯粹为 AI 推理服务。

本文中的性能数据来自 2026 年 7 月的实际运行日志，测试环境为局域网内部。llama.cpp 版本为 v9873（commit a4107133a）。