AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测
-
一、硬件
- CPU: AMD Ryzen 5 7500F (6核12线程, 5.08GHz, AVX-512)
- GPU: AMD Radeon RX 7900 XTX (Navi 31, 24GB GDDR6) 蓝宝石 PULSE
- 内存: 24GB DDR5
- 存储: 1TB NVMe SSD 系统: Ubuntu 26.04 LTS, Kernel 7.0
- 网络: 有线网 + ZeroTier VPN (MTU 2800)
二、软件 推理引擎: llama.cpp (Vulkan 后端)
- GPU 驱动: Vulkan RADV (Mesa 26.0.3, Vulkan 1.4.335)
- 模型: Qwen3.6-27B-Q4_K_M (16GB, 273亿参数)
- 多模态: mmproj-Qwen3.6-27B-f16.gguf (885MB)
为什么选 Vulkan RADV 而不是 ROCm？ 系统自带 mesa-vulkan-drivers，零额外配置，编译时加 -DGGML_VULKAN=on 就行。对于推理来说性能足够，省去了 ROCm 的折腾。
三、启动参数
llama-server --host 0.0.0.0 --port 8080 -m Qwen3.6-27B-Q4_K_M.gguf --mmproj mmproj-Qwen3.6-27B-f16.gguf --no-mmproj-offload -ngl 999 -c 262144 -b 512 -ub 512 -fa auto -ctk q4_0 -ctv q4_0 --spec-type draft-mtp --spec-draft-n-max 2 --jinja --reasoning-preserve参数说明： -ngl 999: 所有模型层 offload 到 GPU -c 262144: 上下文窗口 262K tokens -b 512 / -ub 512: 批处理大小 -fa auto: Flash Attention，减少显存占用 -ctk q4_0: Key Cache 4-bit 量化 -ctv q4_0: Value Cache 4-bit 量化 --spec-type draft-mtp: MTP 推测解码 (Multi-Token Prediction) --spec-draft-n-max 2: 每步推测 2 个 token --no-mmproj-offload: 视觉编码器放 CPU 省显存 --jinja: Jinja 模板，适配 Qwen 格式 --reasoning-preserve: 保留推理链标记
显存占用： 模型权重 ~16.0 GB + KV Cache ~2.5 GB + 引擎 ~1.5 GB + 系统 ~1.0 GB 实际使用 23.3 GB / 24.0 GB，剩余 0.7 GB
四、测速方式
- 测速题目：生成1000字解释TCP/IP协议 Prompt: 61 tokens，max_tokens: 2048，temperature: 0.7
测试分为两组：
- 非流式请求 — 端到端完整生成，读取 llama.cpp 内置 timings
- 流式请求 — 逐 token 记录时间戳，测量 TTFT 和生成间隔分布
数据来源：
- 推理速度取自 llama.cpp 内部计时（排除 HTTP/网络开销）
- 流式数据通过 Python 逐 chunk 解析 time.time() 差值
- 长上下文 prefill 数据来自 server log
- GPU 温度/显存从 sysfs hwmon 读取
网络测试：
- Loopback TCP 吞吐量测试（10MB 数据）
- Ping 网关延迟测试（10 次）
- 内存带宽测试（Python array 读写 256MB）
五、测速结果
- 【非流式请求 — 完整生成 2048 tokens】 （llama.cpp 内置计时） Prompt tokens: 61 Output tokens: 2048 输出字符数: 5419 总耗时: 31.16s
- Prompt 阶段: 478.7ms (127 tok/s) Generation 阶段: 28.23s (72.5 tok/s, 13.8ms/tok) 总生成速度: 65.7 tok/s 推测解码: 1718 个 draft 生成, 1188 个被接受 (69% 接受率)
- 【流式请求 — 完整生成 2044 tokens】 TTFT (首 token): 425ms 总耗时: 29.10s 总生成速度: 71.3 tok/s 平均间隔: 14.0ms/tok
- 【长上下文 Prefill — server log】 Prefill 速度: 842 tok/s (2560 tokens, 3.04秒) 835 tok/s (4096 tokens, 4.90秒) 809 tok/s (8192 tokens, 10.13秒)
- 【短测试 — server log】 短 Prefill: 63 tok/s (12 tokens, 冷启动) 短 Generation: 91 tok/s (30 tokens, 330ms) 短 TTFT: 190ms 短 MTP 接受率: 100% (19/19 accepted, mean len 2.90)
- 【GPU 状态】（测速完成后） 温度: Edge 68°C / Junction 74°C / Memory 82°C 显存: 23.3 GB / 24.0 GB
- 【网络测试】 Loopback TCP: 55.3 MB/s Ping 网关: 0.54ms 平均，0% 丢包（0.40-0.82ms） 内存写入带宽: 26.4 GB/s 内存读取带宽: 28.8 GB/s
六、总结
- 7900 XTX 24GB + Vulkan RADV + llama.cpp + Qwen3.6-27B：
- 完整生成 66 tok/s，流式输出 71 tok/s，14ms/tok 流畅度足够
- 长上下文 Prefill 840+ tok/s（2560+ tokens 批量）
- MTP 推测解码 69% 接受率，显著加速生成
- 24GB 显存占用 23.3GB（97%），模型权重全部 offload 到 GPU, 系统内存显示 ~15GB 占用为 mmap 映射，实际物理可用 ~7GB
- 性价比较高的本地大模型方案
-
，
T terry 固定了此主题
-
非常不错的分享，图片识别慢是通病，很正常，我之前在3.5识别还挺快的，3.6反而慢了，不知道啥原因，但是可以识别。分享不错，下次最好让AI整理成Markdown格式，配一些土图片，效果会更好。
-
，系统 取消固定了此主题
-
期望效果是：若干图片 + 若干文字给Hermes，Hermes知道图片找在线模型或者本地LLM先解析为文字，然后再找QWEN3.6:27B做后续工作。问题是：这里的路由怎么做？用什么工具？能有个方向？ 图片识别小模型估计比较好找
-
另请教：qwen3.6:27B 默认开启thinking，这会导致使用体验降低，因为thinking过程中，Hermes/codex界面几分钟或者几十分钟无输出，用户以为卡死了;
举例：C盘满了，我让Local LLM清理磁盘垃圾，他花了2个小时，垃圾一个也没少，除了费电，我不知道它在干什么。
为了解决这个问题，有两个方案：
1 牺牲部分回复质量，关闭thinking模式;
2 想办法让thinking的过程也显示在Agent中，改善体验，并不改善执行速度;
请问大家一半怎么选？我的个人感受：本地LLM 的智商天然跟云端没有可比性，对于本地模型，thinking 不 thinking 没明显的区别。 大家的看法呢？
-
我选方案2，但要说清楚：这不是"改善体验"的锦上添花，而是必要的信息可见性——你那个C盘例子恰恰证明了这一点。
两小时没清出垃圾，大概率不是 thinking 的锅，而是工具循环卡死：模型在反复尝试同一个失败的命令（权限不足的删除、被占用的文件、路径写错），thinking 只是它"心里的话"，真正卡住的是你看不见的工具调用过程。不把思考过程和工具调用都流式显示出来，你根本分不清它是"在想"还是"卡死了"——这才是你说的体验问题的根源。
怎么让 thinking 可见：Qwen3.6 走 OpenAI 兼容接口时，思考内容在 reasoning_content 字段里，Hermes/codex 这类前端透传这个字段就会流式显示出来。你本地跑 qwen3.6:27B，Ollama 的兼容接口对 Qwen3 系也会把 thinking 透传出来，前端能看到就不存在"以为卡死"的问题了。实在不想折腾的话，llama.cpp 有 --no-thinking 可以直接关。
我的建议是按任务分流，别全局开关：
- 简单任务（清理磁盘、改配置、跑固定流程）：关 thinking，快和稳优先；
- 复杂任务（写代码、排错、方案设计）：开 thinking，但配一个能显示思考过程的前端，至少能看出它卡在哪一步、重试了几次。
至于"本地模型 thinking 没区别"——27B 这种规模的模型 thinking 收益确实比云端大模型小，但"看不出区别"很多时候是因为你压根看不见思考过程才下的结论。先把输出流式化，观察几天再决定关不关，比拍脑袋直接关掉更靠谱。
