还以为会很折腾，没想到一下就好了弄好了：7900xtx

[bwghh]

618 买的 7900xtx + 1200w金牌电源套装，6300左右。
有个闲置的老服务器，E52670 v2（原本是V1，听说没有pcie atomics，花了70块钱买了两块V2换上）64G ddr3，华硕Z9PA-D8主板，去年送人都没人要，今年拿来跑hermes了。
到货之后，就换上电源，插上显卡，开机。
配置如下：

Hardware: ASUS Z9PA-D8 + 2x E5-2670 V2 + 64GB DDR3 ECC + RX 7900 XTX 24GB
OS: Ubuntu 24.04 Server
Driver: Mesa 26.1.2 (RADV NAVI31)
Backend: Vulkan
llama.cpp: b9664 + 最新版自编译

两个模型：
Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf
Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-APEX-I-Compact.gguf
配对应的mmproj 。

启动脚本：
27B：

#!/bin/bash

# 1. 注入 AMD Vulkan 专属性能优化变量
export GGML_VK_ALLOW_GRAPHICS_QUEUE=1
export GGML_VK_VISIBLE_DEVICES=0

# 2. 启动服务
exec /data/llamacpp/llama-server-active \
   -m /data/models/Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf \
   --mmproj /data/models/mmproj-27B-F16.gguf \
   -ngl 999 \
   -c 131072\
   -np 1 \
   -ctk q8_0 -ctv q8_0 \
   -fa on \
   --image-min-tokens 1024 \
   --jinja \
   --chat-template-file /data/models/fix-chat_template.jinja \
   --spec-type draft-mtp --spec-draft-n-max 2 \
   --host 0.0.0.0 \
   --port 7890 \
   --api-key xxxxxxx \
   --alias qwen-36-27B\
   --metrics

35B：

#!/bin/bash

# 1. 注入 AMD Vulkan 专属性能优化变量
export GGML_VK_ALLOW_GRAPHICS_QUEUE=1
export GGML_VK_VISIBLE_DEVICES=0

# 2. 启动服务
exec /data/llamacpp/llama-server-active \
   -m /data/models/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-APEX-I-Compact.gguf \
   --mmproj /data/models/mmproj-35B-A3B-F16.gguf \
   -ngl 999 \
   -c 262144 \
   -np 1 \
   -b 2048 -ub 2048 \
   -ctk q4_0 -ctv q4_0 \
   -fa on \
   --cache-reuse 4096 \
   --image-min-tokens 1024 \
   --jinja \
   --chat-template-file /data/models/fix-chat_template.jinja \
   --host 0.0.0.0 \
   --port 7890 \
   --api-key xxxxxxx \
   --alias qwen-36-35BA3B \
   --metrics

速度情况：
Qwen3.6 35BA3B：开启后约剩余4G显存

简单测试了一个58000 token 大文本（约10万汉字）prefill 大概2000，decode 大概116-117。

简单测试问答与千字左右文本生成：decode速度大概 130+

图片分析速度跟大文本差不多，不浪费资源了。

Qwen3.6 27B，开启后约剩余1G显存

58000token 大文本：prefill 平均600，decode 大概45。

简单问答千字左右文本生成：decode 大概 70+

之前是用5090D32G vllm Qwen3.6-27B nvfp4量化。速度大概prefill 7000+ decode 200+。7900xtx 跑 35BA3B效果勉强能接近。目前就以35BA3B为主要模型在运行。

用途：
1 hermes 底座模型，配合修改过的jinja模板，实测没有出现bug，日常工作效果凑合。我不用hermes 开发，纯维护一些自动化脚本，rag库，搜索引擎服务之类的。
2 RSS重度使用者，vibe了一个自用的RSS阅读器，BYOK，无限token没心理负担，用llm实现快速新闻归类，新闻摘要，注意力等级标签等等。适合不喜欢推荐算法，希望保持大量阅读的用户：https://github.com/bemoons/KickRSS
3 沉浸式翻译，ocr，各种小ai应用等等。

[nami ryuu]

fix-chat_template.jinja \ 这个模板主要起什么作用？
你可以分享这个模板吗？我试一试你的这个。

[bwghh]

@nami-ryuu

好的，这个模板是从qwen3.5就在用的，主要是修复qwen系列工具调用标签的问题。
论坛好像没办法上传文件？
放在这里了：https://github.com/bemoons/KickRSS-Go/releases/download/kickRSS/fix-chat_template.tar.gz

[terry]

其实这玩意现在太多人跑过，是非常确定的路，comfyUI都被大量验证了，AMD的生态已经很成熟了，只是少数算子和节点支持不好。可以补充一点自己的装机图片，更加真实。

论坛只能上传2M以内的附件，理论上可以开放大文件上传，因为架构和云端资源都支持，但是权限颗粒度不够，我以后稍微研究下，让高等级的人可以上传100M的附件。

[bwghh]

补充一点，测试了几个二进制版本，B9664版本的llamacpp vulkan 是速度最快的。最新的自编译版本B9755 速度也很快。两个版本之间的B975x 都会有10%左右的速度损失。应该是llamacpp主线在针对mtp做优化。

[hanyoud]

点赞 收藏，也打算入7900XTX

[bwghh]

最近更换了 ornith 1.0 35B 模型，号称A3B的速度，27B的能力，实测感觉不错，确实比Qwen3.6 35BA3B强一些，跑的速度差不多，也是prefill 3k多，decode 110t/s左右。建议更换。

[566656661]

@bwghh

Ornith是基於Qwen 3.6 35B A3B, 所以表現應該差不多, 強過27B這個我單純當是宣傳技巧

我對它的Gemma 4 31B微調更加感興趣, 畢竟目前還沒有一個基於Gemma 4的好用的編程模型

[llchen]

楼主是买的二手的显卡吗？

[williamlouis]

@llchen 新卡。不是二手。

[艷陽天]

@566656661 请问一下这个可以识图吗？我目前也是在测试这个模型，速度9x t/s快了一倍，但感觉智力上不及27B，让它改27B写的程式会愈改愈糟，现在是只能拿来聊天用

[johnnybegood]

什么？ 才618块？

[566656661]

@艷陽天

你要看模型卡有沒有寫有Vision Tower, 如果有就可以

如果沒寫的話要麻煩點去找模型自帶的model.safetensors.index.json看看有沒有visual/vision的字樣

以Ornith爲例, 這裏有寫visual

"model.visual.blocks.0.attn.proj.bias": "model-00016-of-00016.safetensors",
"model.visual.blocks.0.attn.proj.weight": "model-00016-of-00016.safetensors",
"model.visual.blocks.0.attn.qkv.bias": "model-00016-of-00016.safetensors",
"model.visual.blocks.0.attn.qkv.weight": "model-00016-of-00016.safetensors",

那這個模型就支援識圖

至於智力追不上27B也很正常, 畢竟無論怎麽微調, Activation只有3B

[bwghh]

@艷陽天

gguf的vision tower 是单独一个mmproj文件，要单独去下载的。一般不到1G。加载的时候加一行：-mmproj /data/models/mmproj-27B-F16.gguf \

智力不如27B是肯定的，用来编码的话还得是27B稠密模型。我不用来编码，主要就是三个用途：hermes 日常操作，翻译引擎/ocr引擎，再就是每天看rss用来做大量的摘要。这些都是速度越快越好。其实9B都够了，只是35B这个更好用。

[fcme]

跑代码的话27B肯定更稳，但是太慢了性子稍稍急一点就招架不住，尤其是agent类应用，输入远远远远大于输出，所以pp速度更重要27b我是等不及了，在R970零里面挂了一个高精度的35b也很爽。其实尤其是现在deepseek v4 flash太便宜了，本地部署的性价比真的是不太高

[Rex]

@bwghh 感谢分享，请问这个测试怎么跑？用什么环境、命令行、工具？

[Xiaote]

跑 benchmark 可以用以下几个工具：

1. llama-bench（最推荐，llama.cpp 自带）
   安装 llama.cpp 后直接用：
   llama-bench -m /path/to/model.gguf -n 128 -p 512
   这会输出 pp（prefill）和 tg（text generation）速度。

2. vLLM benchmark_serving
   如果已经搭好了 vLLM 服务：
   python -m vllm.entrypoints.openai.benchmark_serving --model <model> --tokenizer <tokenizer> --request-rate 1 --num-prompts 10

3. llama-cli 直接测延迟
   llama-cli -m /path/to/model.gguf -n 128 -p "Hello" --no-display-prompt -c 4096

对于 7900XTX 跑 Qwen3.6-27B：

• llama.cpp HIP 后端 + Q4_K_M：通常 30-50 t/s
• vLLM ROCm + AWQ：可能到 60-80 t/s
  建议用 llama-bench 先跑一轮，看 prefill 和 decode 速度，再决定用什么框架。