<![CDATA[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
  • 性价比较高的本地大模型方案
]]>https://lcz.me/topic/982/amd-7900-xtx-24g-vulkan-llama.cpp-跑-qwen3.6-27b-本地推理实测RSS for NodeTue, 11 Aug 2026 13:47:00 GMTFri, 31 Jul 2026 08:05:35 GMT60<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Tue, 04 Aug 2026 04:26:21 GMT]]>我选方案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 收益确实比云端大模型小，但"看不出区别"很多时候是因为你压根看不见思考过程才下的结论。先把输出流式化，观察几天再决定关不关，比拍脑袋直接关掉更靠谱。

]]>https://lcz.me/post/11383https://lcz.me/post/11383Tue, 04 Aug 2026 04:26:21 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Tue, 04 Aug 2026 01:11:35 GMT]]>另请教：qwen3.6:27B 默认开启thinking，这会导致使用体验降低，因为thinking过程中，Hermes/codex界面几分钟或者几十分钟无输出，用户以为卡死了;
举例：C盘满了，我让Local LLM清理磁盘垃圾，他花了2个小时，垃圾一个也没少，除了费电，我不知道它在干什么。
为了解决这个问题，有两个方案：
1 牺牲部分回复质量，关闭thinking模式;
2 想办法让thinking的过程也显示在Agent中，改善体验，并不改善执行速度;
请问大家一半怎么选？

我的个人感受：本地LLM 的智商天然跟云端没有可比性，对于本地模型，thinking 不 thinking 没明显的区别。 大家的看法呢？

]]>https://lcz.me/post/11355https://lcz.me/post/11355Tue, 04 Aug 2026 01:11:35 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Tue, 04 Aug 2026 01:23:12 GMT]]>@Zhen-Li 感谢回复;
目前的方案： 使用了主模型 + 5GB的本地图像识别模型;
在主模型和图像识别模型前面加了一个智能代理，识别图文，分配到该分配的模型处理，代理还能加一些逻辑，比如：context符合一定条件自动触发压缩等

]]>https://lcz.me/post/11354https://lcz.me/post/11354Tue, 04 Aug 2026 01:23:12 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Mon, 03 Aug 2026 11:28:48 GMT]]>@Fan-Rex hermes web-UI里直接可以设置不同的事用不同的模型7a56b6bb-97e0-4e22-a458-8c8f3911e671-image.jpeg

]]>https://lcz.me/post/11315https://lcz.me/post/11315Mon, 03 Aug 2026 11:28:48 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 10:51:41 GMT]]>你把需求告诉Hermes，它自己会配置skill，如果qwen做不到，就让deepseek帮它配好。好像Hermes自带这个，我视频里讲过，实操啊

]]>https://lcz.me/post/11101https://lcz.me/post/11101Fri, 31 Jul 2026 10:51:41 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 10:43:09 GMT]]>期望效果是：若干图片 + 若干文字给Hermes，Hermes知道图片找在线模型或者本地LLM先解析为文字，然后再找QWEN3.6:27B做后续工作。问题是：这里的路由怎么做？用什么工具？能有个方向？ 图片识别小模型估计比较好找

]]>https://lcz.me/post/11099https://lcz.me/post/11099Fri, 31 Jul 2026 10:43:09 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 10:18:05 GMT]]>没啥好的办法，暂时就这个模型最好了，其它的模型都是傻逼。或者部署一个单独的模型识别图片。对了openrouter上有免费的图片模型识别图片，够用的，让hermes自己去配置就好了。

]]>https://lcz.me/post/11092https://lcz.me/post/11092Fri, 31 Jul 2026 10:18:05 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 10:13:46 GMT]]>@terry
图片识别方面，有什么后续解决方案呢？ 等新的模型？ 或者双模型？双模型路由怎么办？ ccswitch只能同时启动一个模型的

]]>https://lcz.me/post/11091https://lcz.me/post/11091Fri, 31 Jul 2026 10:13:46 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 09:50:46 GMT]]>非常不错的分享，图片识别慢是通病，很正常，我之前在3.5识别还挺快的，3.6反而慢了，不知道啥原因，但是可以识别。分享不错，下次最好让AI整理成Markdown格式，配一些土图片，效果会更好。

]]>https://lcz.me/post/11080https://lcz.me/post/11080Fri, 31 Jul 2026 09:50:46 GMT<![CDATA[Reply to AMD 7900 XTX 24G + Vulkan + llama.cpp 跑 Qwen3.6-27B 本地推理实测 on Fri, 31 Jul 2026 09:17:24 GMT]]>目前测试发现的问题：图片识别吃力，耗时久，请问有人遇到过类似现象？如何解决？

]]>https://lcz.me/post/11075https://lcz.me/post/11075Fri, 31 Jul 2026 09:17:24 GMT