7900xtx qwen3.8 27b 63t/s
-
7900 XTX 上 llama.cpp Vulkan + MTP 实战：Qwen3.8-27B 跑出 63 t/s
核心结论：在 AMD Radeon RX 7900 XTX（gfx1100）上，通过自编译 llama.cpp Vulkan 后端 + MTP 投机解码，让 27B 参数的 Qwen3.8 模型在 24GB 显存内跑满 ~63 t/s。关键在于正确搭建 Vulkan 工具链，并理解 MTP 与显存 offload 策略的冲突与取舍。
硬件与软件配置
部件 型号 / 版本
CPU Intel i5-13400（10核 16线程）
内存 DDR5 32GB
显卡 AMD Radeon RX 7900 XTX 24GB（gfx1100）
GPU 驱动 RADV（Mesa 23.2.1，radeon_icd）
系统 Ubuntu 22.04（内核 6.8.0-136，glibc 2.35）
推理引擎 llama.cpp master（commit 9d57ce4，自编译 Vulkan 后端）
🧠 模型信息
项目 详情
主模型 Qwen3.8-27B-Q4_K_M.gguf（17.1 GB）
视觉编码器 mmproj-F16.gguf（928 MB）
架构 qwen35（Gated DeltaNet 线性注意力）
启动参数（Vulkan + MTP）
bash/llama.cpp/build-vulkan/bin/llama-server
-m /models/qwen38/Qwen3.8-27B-Q4_K_M.gguf
--mmproj /models/qwen38/mmproj-F16.gguf
--spec-type draft-mtp
--spec-draft-n-max 3
-c 163840
-ub 512
--cache-type-k q4_0
--cache-type-v q8_0
--parallel 1
--host 0.0.0.0
--port 8080
--jinja
--chat-template-kwargs '{"enable_thinking": false}'
--timeout 600
--api-key '你的key'
关键参数详解
参数 说明
--spec-type draft-mtp 启用 MTP 投机解码（Multi-Token Prediction），核心提速手段
--spec-draft-n-max 3 每次最多预测 3 个草稿 token
️ 去掉 -ngl MTP 与全量 offload（-ngl 999）冲突会 OOM；去掉后显存自适应分配
-c 163840 160K 上下文（Gated DeltaNet 线性注意力，长上下文下仍省显存）
-ub 512 最大 batch 大小
--cache-type-k q4_0
--cache-type-v q8_0 KV 缓存量化（K: q4_0，V: q8_0），进一步压低显存占用💡 核心权衡：-ngl 999 看似能把所有层塞进 GPU，但 MTP 的 nextn 预测层需要额外显存空间。全量 offload 会挤爆 24GB，导致 OOM。让 llama.cpp 自适应分配反而能跑满。
实测性能
指标 数值
生成速度 ~63 t/s（MTP 投机解码开启）
显存占用 ~23.85 GB / 24 GB（MTP nextn 层同时进 GPU）在 24GB 显存几乎跑满的情况下仍维持 63 t/s，说明 MTP 的草稿 token 接受率与线性注意力的长上下文效率形成了很好的正反馈。
️ 构建要点（Ubuntu 22.04 自编译踩坑）以下是编译 Vulkan 后端时最容易翻车的几个点，按优先级排列：
-
glslc 必须从 shaderc 源码编译
Ubuntu 22.04 官方仓库没有 glslc，需从 shaderc 源码编译「真」glslc。
需包含 glslang 16.x，以匹配系统 gcc 11 的 ABI。 -
别用 conda-forge 的 glslcconda-forge 版本用 gcc 14 构建，在 22.04 上编译复杂 shader 时会段错误（exit 139）。
-
Vulkan-Headers 需升级到最新
llama.cpp 最新 master 使用 Vulkan 1.4 API。
系统默认的 Vulkan-Headers 1.3.204 不够用，必须更新到最新版本。
️ 易漏点：别漏掉 vk_video/ 子目录，否则链接失败。 -
CMake 目标名是 glslc_exe
编译 shaderc 时，CMake 目标名是 glslc_exe 而非 glslc。写错目标名会导致构建找不到可执行文件。
一句话总结在 gfx1100 的 24GB 大显存上，MTP 投机解码 + KV 量化 + 去掉强制 -ngl 三招组合，让 27B 模型在显存吃紧的极限下依然跑出 63 t/s 的可用速度。搭建 Vulkan 工具链时，源码编译 glslc（gcc 11 ABI）+ 升级 Vulkan-Headers 1.4 是绕不开的两大硬门槛。
-
-
这个会oom? 上下文是不是太长了点？128k一般够用了。
mtp设置为2也可以。kv缓存用--cache-type-k q5_0
--cache-type-v q4_1 \ 试试看呢？这样应该能跑q5精度的模型 -
@yao wang 你说的"接入智能体响应太慢"，和解码速度（63 t/s）是两码事，这其实是两个瓶颈：Agent 每一轮都要重新 prefill 全部上下文 + 模型的 thinking 链，TTFT（首 token 延迟）才是体感瓶颈。27B 这种模型 thinking 链一长，一轮 prefill 就是几万 token，TTFT 直接上秒级；MTP 只加速 decode，对 prefill 一点忙都帮不上。
几个实操建议：
- Agent 场景上下文别开 128K，32K-64K 完全够用，prefill 量直接砍半，TTFT 立竿见影。
- KV cache 量化照 AGI 说的来（--cache-type-k q5_0 --cache-type-v q4_1），省带宽、省显存，对 Vulkan 后端尤其划算。
- 工具调用场景把 thinking 压到 low 档或直接关掉——Agent 循环里 thinking 的收益很低，延迟几乎全是它贡献的。
- 想追 TTFT 可以试试 vLLM/SGLang 的 prefix cache：跨轮复用公共前缀，多轮 Agent 的体感最接近在线 API。这正是隔壁 DSH 帖子里"缓存命中 99%、基本没有 prefill"的原因。
另外 exllm 说"3.8 工具调用不如 3.6"，这个观察和论坛里其他几个人的实测能对上（terry 的测试也提到 3.8 工具调用有问题）。除了模板 v22 给 xhigh/low 注入额外提示词、思考链变长之外，3.8 的工具调用稳定性和 3.6 比确实有退步。"会写代码"和"会稳定地调工具"是两个维度，Agent 场景目前 3.6 更稳是合理结论，等社区把 3.8 的坑填完再切也不迟。
-
@CHIA AN YANG 你这个"30 几"和"抄作业都做不到"其实是两个问题，拆开看：
速度 30 几 t/s：你对比的 50-60 都是裸测——无思考链、无工具调用、纯单轮输出的解码速度（yao wang 的 63、hayate 的 55 都是这种跑法）。Agent 场景每轮都要重新 prefill 全部上下文 + thinking 链，还有工具 schema 占的 token，体感速度天然要打对折以上。27B Q4 开了 MTP 的话，agent 模式下 30 几 t/s 其实是正常水平，不是机器的问题。
"把作业贴给他抄都做不到"：这是工具调用质量问题，不是速度问题。这楼里 exllm 的实测已经说得很清楚——3.8 的 27B 调工具不如 3.6，同样用 opencode 改 C++ 项目，3.6 会自己调工具完成，3.8 得提示才动。所以 Agent/工具类任务建议先用 3.6 的 Q4_K_M，3.8 留给纯生成场景。
两个立竿见影的调整：上下文别开 128K，32-64K 完全够用（prefill 量直接减半）；简单任务把思考链关掉（--reasoning-budget 0）或用 low 档，速度和成功率都能回来。
-
@stxpnet 这个问题其实可以一句话说清：K 比 V 金贵，所以 K8V4 更好。
为什么 K 需要更多位数？看 attention 的计算路径就明白了：
- K 直接参与 Q·K^T 点积，产出的是注意力权重。K 的量化误差会直接污染"该看哪些 token"的权重分布——权重算错，模型就看错地方，这是方向性错误，损失最大。
- V 是拿注意力权重去做加权求和，误差被权重平均稀释。V 上的一点噪声只会让输出值轻微偏移，属于幅度误差，容忍度高得多。
所以 KV cache 量化从来都是不对称的：K 多给位、V 少给位。llama.cpp 默认推荐的 --cache-type-k q5_0 --cache-type-v q4_1 就是这个思路（K 用 5bit、V 用 4bit），更讲究的用 K q8_0 + V q4_1。
内存账也算一下：K8V4 和 K4V8 每 token 都是 12 bit（8+4 和 4+8），显存占用一模一样。既然内存不吃亏，纯质量取舍，那当然是精度给到更关键的那一侧——K8V4 完胜。
另外提醒一句：V 也尽量别用 q4_0，q4_1（带 scale 和 min）比 q4_0 稳，长上下文下质量退化更小。Ollama 里设 OLLAMA_KV_CACHE_TYPE=q4_1 或直接上 K8V4（llama.cpp 侧 --cache-type-k q8_0 --cache-type-v q4_1）都行。
-
我的agent做不到50-60 ,,,,怎麼跑都30幾...無言,把作業貼給他抄 都做不到
-
坑走完了 7900xtx實測可以到70幾~
