单卡 AMD Radeon AI Pro R9700 (32GB) + Qwen3.6-27B + Hermes Agent 本地部署经验+LLM公网部署
-
硬件配置
部件 型号 参数 CPU Intel Core i7-7700K 4核8线程 @ 4.2GHz GPU AMD Radeon AI Pro R9700 × 1 32GB VRAM, gfx1201, ROCm 内存 DDR4 32GB 存储 NVMe SSD 937GB (可用 ~630GB) OS Ubuntu 24.04.4 LTS 内核 6.19.14 软件栈
组件 版本/说明 ROCm 7.8.0 (rocm-smi 4.0.0) llama.cpp b4672 (自编译, GCC 13.3.0) Hermes Agent Nous Research 最新版 模型 Qwen3.6-27B-Q4_K_M.gguf (17.1GB) 上下文 128K tokens (131072) llama-server 启动参数详解
#!/bin/bash exec /home/lw/llama.cpp/build/bin/llama-server \ -m /home/lw/models/Qwen3.6-27B-Q4_K_M.gguf \ --host 0.0.0.0 --port 8080 \ --n-gpu-layers 999 \ -c 131072 \ --cache-type-k q8_0 \ --cache-type-v q8_0 \ --mlock \ --timeout 120 \ --defrag-thold 0.1 \ --no-cache-prompt \ --cache-ram 0 \ --reasoning off参数说明
参数 作用 为什么这么设 -ngl 999全部层卸载到 GPU R9700 32GB 足够放下 Q4_K_M 的 27B 模型 -c 131072上下文 128K 日常够用;256K 下 R9700 预填充太慢 --cache-type-k/v q8_0KV cache 用 q8_0 精度 比默认 f16 省一半 KV cache 显存,质量损失极小 --mlock锁定内存防 swap 单卡显存 32GB 接近满载时,防止系统把模型 swap 到硬盘 --cache-ram 0禁用 CPU RAM 缓存 避免跨请求 prompt cache 触发崩溃 --no-cache-prompt禁用 prompt 缓存 同上,防崩 --defrag-thold 0.1KV 缓存碎片整理 长时间运行时显存碎片化会降低性能 --reasoning off关闭 thinking 输出 Claude Code 不需要 thinking 内容,省带宽 --timeout 120请求超时 120 秒 匹配 Claude Code 超时设置 性能基准
场景 耗时 计算 短对话 (24 tok 输入 + 2 tok 输出) 0.63 秒 几乎瞬时响应 长文处理 (1133 tok 输入 + 50 tok 输出) 8.16 秒 适合日常编程对话 Prefill 速度 ~186 tok/s Decode 速度 ~24 tok/s 正常单卡水平 VRAM 占用 23.2/34.2 GB (68%) 还有余量,不 OOM 关键对比:双 R9700 用户因 PCIe 跨卡通信瓶颈,Prefill 仅 ~21 tok/s。单卡反而快 9 倍!
与 Hermes Agent 配合
在
~/.hermes/config.yaml中配置:model: default: Qwen3.6-27B-Q4_K_M.gguf provider: ubuntu-llm base_url: http://192.168.8.195:8080/v1 api_key: llm_G4eXme-... api_mode: chat_completionsllama-server原生支持 OpenAI API(/v1/chat/completions),所以任何兼容 OpenAI 的客户端都能直连。跨机器调用
Windows Claude Code 直连(无需代理)
新版 Claude Code 原生支持 Anthropic API,而
llama-server也原生实现了/v1/messages端点,不需要中间代理:setx ANTHROPIC_BASE_URL http://192.168.8.195:8080 claude --dangerously-skip-permissions注意:不要加
/v1后缀!Claude Code 会自动拼接/v1/messages,写全路径会变成/v1/v1/messages报 400。MacMini Hermes Agent / OpenClaw 配置
model: base_url: http://192.168.8.195:8080/v1 api_mode: chat_completionsOpenClaw (client) → llama-server on Ubuntu (192.168.8.195:8080)性能对比:直连 vs 代理
方式 延迟 维护 推荐 ANTHROPIC_BASE_URL直连最低 无需额外进程 优先 OpenAI 兼容代理(中间人) 多一次转换 加个进程要维护 仅当直连不可用时 工具脚本
模型切换:
~/swap-model.sh./swap-model.sh qwen # 切换到 Qwen3.6 ./swap-model.sh gemma # 切换到 Gemma-4systemd 开机自启:
~/.config/systemd/user/qwen-server.service[Unit] Description=Qwen3.6-27B LLM Server After=network-online.target [Service] Type=simple ExecStart=/usr/bin/sg render -c '/bin/bash /home/lw/run_qwen.sh' WorkingDirectory=/home/lw/models Restart=on-failure RestartSec=10 [Install] WantedBy=default.targetsystemctl --user enable qwen-server.service # 开机自启 systemctl --user start qwen-server.service # 立即启动Hermes Agent cron 保姆监控
每分钟自动检查 llama-server 健康状态,挂了自动重启:
hermes cron create \ --name "llama-server watchdog" \ --schedule "every 5m" \ --prompt "Check if llama-server is running on localhost:8080. If down, restart it with ~/run_qwen.sh." \ --deliver local \ --toolsets terminal公网部署注意事项
如果想把内网的 llama-server 暴露到公网使用,需要注意以下几点:
安全第一
绝对不要把 llama-server 直接暴露在公网!llama-server 本身没有认证机制,直接暴露等于把你的 32GB 显存和 100% GPU 让全网随意调用。
推荐方案:用 Cloudflare Tunnel(cloudflared)做安全穿透:
# 安装 cloudflared wget https://github.com/cloudflare/cloudflared/releases/latest/download/cloudflared-linux-amd64 -O /usr/local/bin/cloudflared chmod +x /usr/local/bin/cloudflared # 创建 tunnel cloudflared tunnel create my-llm-tunnel # 配置 DNS cloudflared tunnel route dns my-llm-tunnel your-domain.com # 创建配置文件 ~/.cloudflared/config.yml配置示例:
tunnel: <tunnel-id> credentials-file: /root/.cloudflared/<tunnel-id>.json ingress: - hostname: llm.your-domain.com service: http://localhost:8080 - service: http_status:404# 启动 tunnel(作为 systemd 服务) cloudflared service install systemctl start cloudflaredCloudflare Tunnel 的好处:零暴露(没有开端口、没有公网 IP 映射)、自带 DDoS 防护、可加 Access 策略做额外认证。
轻量替代方案
如果不想用 Cloudflare,可以用 frp 做反向代理:
# 服务端(公网 VPS) frps -c frps.toml # 客户端(内网 Ubuntu) frpc -c frpc.tomlfrpc.toml:serverAddr = "your-vps-ip" serverPort = 7000 [[proxies]] name = "llama-server" type = "tcp" localIP = "127.0.0.1" localPort = 8080 remotePort = 8080性能考虑
- 公网穿透会引入额外延迟(Cloudflare ~20-50ms,frp ~5-15ms)
- 对于短对话(低 token)影响不大
- 对于长上下文(大量 prefill)主要耗时在推理本身,网络延迟占比小
- 建议在客户端侧加 keep-alive 和 连接复用,避免每次请求重新建 TCP 连接
避坑指南
1. 不要用
-fa on(Flash Attention)ROCm 下 Flash Attention 绝大部分版本默认启用(
auto),显式指定反而不一定兼容。如果让它自动检测,它会在支持的设备上自动开启,不支持的设备上自动降级。2. 双卡用户注意 PCIe 瓶颈
双 R9700 用
--split-mode tensor会因为 PCIe 瓶颈导致 Prefill 降到 19 tok/s。推荐用--split-mode layer按层切分。单卡用户无此问题。3.
--cache-type-k/v q8_0一定要加这是性价比最高的优化。默认 f16 的 KV cache 吃显存非常多。q8_0 质量损失几乎不可感知(Q4_K_M 权重才是主要误差来源),但显存占用减半。
4.
--no-cache-prompt+--cache-ram 0防崩组合llama-server 的跨请求 prompt cache 在长时间运行的场景下有时会触发 segfault 或卡死。禁用后每次请求重新处理 prompt,速度略降但稳定性大幅提升。
5.
--mlock防止 swap 降速单卡 32GB 跑 27B Q4_K_M 时,系统可能会把部分页面 swap 到硬盘。
--mlock锁定物理内存页,避免推理过程中卡在缺页中断。6. MTP/Eagle2 模型可进一步提速
如果有 Qwen3.6 的 Eagle2/MTP 版本(Multi-Token Prediction),Prefill 速度可从 ~186 tok/s 提升到 ~562 tok/s(3x)。目前没有公开的 GGUF 版本,有条件的可以自己从官方权重导出。
总结
单卡 AMD Radeon AI Pro R9700 (32GB) + Qwen3.6-27B Q4_K_M 是一个生产可用的本地推理方案:
- 编程助手、代码补全、工具调用 — 流畅无压力
- 128K 上下文 — 日常使用足够
- Hermes Agent + Claude Code 直连 — 无需代理,延迟最低
- VRAM 余量 ~30% — 不会 OOM
- 256K 上下文 — 速度太慢,不推荐
- 超长文档处理 — 27B 模型的推理速度上限在那,建议降级到 14B 以下
总体感受:Qwen3.6-27B 的推理能力极强,工具调用准确,配合 Hermes Agent 联网检索效果很好。对于预算有限(一块 R9700 卡 + 普通 PC)又想跑本地大模型的用户来说,这个配置是目前性价比最高的方案之一。
-
我自己有試過用Cloudflare跟Tailscale把目前的vLLM放到公網
注重隱秘的話就選Tailscale
注重安全 + 方便的話就選CloudflareCloudflare 因爲内部Caching, WAF rule enforcement的關係基本上資料在Cloudflare内部是裸奔的狀態
@566656661 设个api就好了