15 年老平台 + 单张 RX 7900 XTX 跑 Qwen3.8-27B：本地 Coding Agent 实测
-
先说结论
我原本只是想验证一件事：
一台十多年前的旧电脑，如果只升级显卡，能不能变成一台真正可用的本地 Coding Agent Server？
实际测试下来，答案是：可以。
我的平台是非常老的 Intel Sandy Bridge 平台，只有 16GB DDR3，没有 ReBAR，CPU 也只是 i5-2400。
唯一真正有算力的硬件，是一张：
AMD Radeon RX 7900 XTX 24GB
目前我最终使用的组合是：
项目 配置 模型 Qwen3.8-27B 量化 Q4_K_M GGUF Backend llama.cpp GPU Backend Vulkan / Mesa RADV MTP MTP5 Context 98K KV Cache K=q8_0 / V=q4_1 Parallel 1 Prompt Cache 开启 Reasoning 关闭 Client VS Code Agent API OpenAI-compatible API 在真实 Coding Agent 工作流里，实测大致可以做到：
项目 实测 Decode 约 40～46 tokens/s 长 Prompt Processing 约 490～540 tokens/s Context 50K+ 可以正常工作 25 Steps Agent Task 约 6 分钟 46 Steps Agent Task 约 7 分 18 秒 而且这里说的不是单纯让模型“写一段代码”。
我实际跑的是完整 Agent Loop：
读取项目 → 修改代码 → 执行命令 → 启动网页 → Browser / Playwright 测试 → 找问题 → 修改 → Retest → 完成任务
所以这次实验给我的最大结论其实不是“7900 XTX 能跑多少 token”。
而是：
对于可以主要放进显存的量化模型，旧 CPU、DDR3、老主板并不一定会让整台机器失去作为 Local AI Server 的价值。
如果手上本来已经有一台旧电脑，只想搭一台本地 Coding Agent Server，未必一定要先把整个平台全部换掉。
一、实验背景
这台机器并不是专门为了 AI 新装的。
原来的硬件大概是：
硬件 配置 CPU Intel Core i5-2400 CPU 规格 4 Core / 4 Thread 架构 Sandy Bridge 平台 B75 RAM 16GB DDR3 SSD SATA SSD 系统 Ubuntu Server GPU RX 7900 XTX 24GB 因此这个实验的核心思路很简单：
尽量不要让旧 CPU 参与模型计算，把主要推理工作留在 GPU VRAM。
换句话说，我并不是想证明 i5-2400 很适合跑 AI。
真正想测试的是：
当模型主要在 GPU 上运行时，Host 平台到底可以旧到什么程度？
二、我的主要用途：Coding Agent，而不是聊天
这台 Server 主要不是拿来聊天。
我的目标是让它成为一台：
Local Coding Agent Server
Client 主要使用 VS Code Agent，通过 OpenAI-compatible Chat Completions API 连接本地模型。
Agent 会实际执行：
Agent Workflow Read repository Edit files Terminal command Browser automation Playwright Debug Retest Subagent review 因此我比较关心的并不是单轮 Benchmark，而是：
长 Context、多轮 Tool Calling、Prompt Cache、Agent Loop 和真实任务完成时间。
这也是为什么下面很多数据，和普通“问一句问题然后看 token/s”的 Benchmark 会有一点不同。
三、最终比较满意的配置
目前我实际长期使用的大致配置如下。
项目 配置 模型 Qwen3.8-27B Q4_K_M GGUF 大小 大约 17～18GB Backend llama.cpp GPU Backend Vulkan / Mesa RADV Context 98,304 tokens Parallel 1 KV Cache K q8_0 KV Cache V q4_1 MTP MTP5 Prompt Cache 开启 Reasoning OFF 这里有一个很重要的前提：
必须使用保留 MTP / NextN layers 的 GGUF。
不是所有同名 Q4_K_M GGUF 都可以直接开启 MTP。
因为 Host 平台太旧，我最后没有继续花时间折腾 ROCm Host compatibility。
对这台机器而言，Vulkan 方案已经足够稳定。
实际 Agent Session 已经跑到：
55,899 tokens
而没有发生 truncation。
这也让我改变了一个原本的看法：
以前觉得 64K Context 已经很大。
实际跑 Coding Agent 后，会发现：
64K 并没有想象中那么宽裕。
因为除了聊天内容之外，还有：
Context 内容 System Prompt Tool Schema Agent History File Context Tool Results 这些东西增长得很快。
四、KV Cache：目前使用 K8 / V4.1
我最开始为了尽量省显存，使用过：
阶段 K V 最初 q4_0 q4_0 目前 q8_0 q4_1 也就是我现在使用的：
K8 / V4.1
原因很简单。
24GB VRAM 不只是存模型，还要同时容纳：
Model + KV Cache + MTP + llama.cpp Buffers + Long Context
因此我没有把 K/V 两边都开得很高。
目前对我的 Workload 来说：
K8 / V4.1 是比较实际的平衡点。
五、MTP5 的实际收益
我一开始使用的是 MTP2，后来改成 MTP5。
实际结果：
MTP Decode Acceptance Mean Accepted Length MTP2 约 39～40 t/s 约 71% 约 2.4 MTP5 约 44～46 t/s 约 64～69% 约 4.2～4.5 MTP5 其中两次 Agent Request：
Prompt Prompt Processing Decode Acceptance Mean Accepted Length 20,149 tokens 489.70 t/s 44.26 t/s 64.30% 4.21 45,222 tokens 538.98 t/s 44.49 t/s 69.41% 4.47 实际生成过程中经常看到：
43～46 t/s
所以在我的机器上，大致可以理解成：
MTP2：约 39～40 t/s
MTP5：约 44～46 t/s
六、MTP 不能只看 Acceptance %
这个也是我实际跑过以后才觉得比较有意思的地方。
MTP2 MTP5 Acceptance 约 71% 约 64～69% Mean Accepted Length 约 2.4 约 4.2～4.5 Decode 约 39～40 t/s 约 44～46 t/s 只看 Acceptance：
71% 比 64% 高
很容易觉得 MTP2 比较好。
但实际 Decode Speed 反而是 MTP5 更快。
所以我现在看 MTP，不会只盯着 Acceptance Rate。
至少要一起看：
Acceptance % + Mean Accepted Length + Decode tokens/s + 最终任务时间
最终还是以真实 Workload 为准。
七、两次真实 Agent Task
两次比较完整的测试：
测试 Steps 时间 Test 1 25 Steps 约 6 分钟 Test 2 46 Steps 7 分 18 秒 25 Steps / 6 分钟
Agent 自己完成：
写 HTML、写 CSS、写 JavaScript、启动本地 Server、打开 Browser、Playwright Test、Search Test、Filter Test、Add Issue、Validation、Close / Reopen、Delete、LocalStorage、Reset、Mobile 375px Test、Desktop Layout Check、找 UI 问题、修改 CSS、Retest、检查 Console Error。
整个过程没有人工接手。
46 Steps / 7 分 18 秒
这一次包括：
Main Agent、Responsive Review Subagent、Browser Automation、Mobile Test、Desktop Test、Console Test、CSS Fix、Retest。
Subagent 还额外发现了几个 UI 问题，例如：
- Mobile Toolbar 有异常空白
- Touch Target 太小
- Narrow Screen Badge Wrapping 不理想
Main Agent 再根据 Review 修改 CSS，然后重新测试。
最终验证：
项目 结果 375px 无 Horizontal Scroll Buttons ≥ 44px Mobile Stat Cards 2 Columns Desktop 4 Columns Console 0 Errors 如果单纯拿 Steps 去除时间：
测试 平均时间 25 Steps / 360 秒 ≈ 14.4 秒 / Step 46 Steps / 438 秒 ≈ 9.5 秒 / Step 当然 Agent Step 本身并不是完全相同的工作量，所以这个数字不能当正式 Benchmark。
不过它至少说明一件事：
真实 Agent 工作流的总时间，不是单纯由 Output Token Speed 决定。
八、一次 56K Context 的实际 Session
其中一个比较长的 Agent Session，结束时数据是：
指标 数据 Final Context 55,899 tokens Truncated 0 Decode 40.84 t/s Generated 720 tokens MTP Acceptance 64.327% Accepted 550 Draft Generated 855 Mean Accepted Length 4.22 生成过程中我看到过：
44.59 t/s、44.61 t/s、43.52 t/s、42.83 t/s
所以在我的使用方式里：
40～46 t/s 是一个比较接近真实 Coding Workload 的范围。
九、长 Context 下，真正慢的可能不是 Decode
这是这次实验里我觉得很值得分享的一点。
其中一次 Request：
阶段 Tokens 性能 耗时 Prefill 45,222 tokens 538.98 tokens/s 约 84 秒 Decode 455 tokens 44.49 tokens/s 约 10 秒 也就是说这一轮 Request 大概是：
84 秒 Prefill vs 10 秒 Decode
所以 Coding Agent 到了 40K～50K Context 以后：
真正的等待时间很可能主要来自 Prompt Processing，而不是 Output Token Speed。
这也是为什么我后来没有只追求把 Decode 从 40 t/s 调到 45 t/s。
因为如果每一轮都要重新 Prefill 50K Token，
那多出来的几 t/s，其实不是最大的性能差异。
十、Prompt Cache 对 Coding Agent 非常重要
多轮 Coding Agent 的请求，经常会和上一轮共享大量 Prefix。
例如：
System Prompt + Tool Schema + Conversation History + Project Context
我实际在 Log 里面看过：
LCP Similarity = 0.999
在一个已经很长的 Conversation 里，下一轮如果 Prefix Cache 命中，
实际可能只需要重新 Evaluate：
二十多个新 Tokens
这种情况下，Agent 的体感和重新 Prefill 几十 K Token 完全是两回事。
所以对我来说：
Prompt Cache 是 Coding Agent 配置里非常重要的一部分。
十一、16GB RAM 反而是这台机器最需要注意的地方
项目 数据 GPU VRAM 24GB Host RAM 16GB DDR3 Host Memory Peak 13GB+ Host Prompt Cache 1GB 实际运行时，也曾经出现少量 Swap。
老机器一旦开始 Swap，整个 Ubuntu 的响应会明显变差。
因此我没有照搬一些 64GB / 128GB RAM Server 的配置。
对这台机器来说：
稳定性比多一点 Host Cache 更重要。
十二、我给模型进程加了 RAM 保护
因为只有 16GB RAM，我还给模型进程加了 Memory Limit。
大致逻辑类似：
MemoryHigh=12G MemoryMax=14G MemorySwapMax=0 OOMPolicy=stop OOMScoreAdjust=500 Restart=on-failure RestartSec=60这些设置不是为了提升性能。
目的只有一个：
宁愿模型服务失败，也不要因为 Swap 把整台 Server 一起拖死。
对旧机器尤其有用。
十三、没有 ReBAR 也可以跑
这台 B75 平台没有 Resizable BAR。
在 Vulkan 环境下我另外使用了：
GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1至少在我这台没有 ReBAR 的老平台上，目前运行稳定。
因此：
没有 ReBAR 并不代表 llama.cpp + Vulkan + 7900 XTX 就一定不能用。
它当然不是理想平台，但对于“把旧电脑重新利用起来”这种场景，仍然有实际价值。
十四、Parallel=1 不等于 Agent 不能使用 Subagent
我之前也测试过：
Parallel=2
后来因为主要只有一个 Coding Agent 长时间工作，所以最终改成：
Parallel=1
有意思的是：
VS Code Agent 仍然可以启动：
Main Agent + Subagent
原因是：
Agent / Subagent 和 llama.cpp Parallel Slot 并不是同一个概念。
Parallel=1 代表：
同一时间只有一个 LLM inference slot。
但 Harness 仍然可以管理多个 Agent Context。
它们的模型请求可以排队使用同一个 Slot。
而且像下面这些操作：
Playwright、Browser、Terminal、Read File
本身也不等于 GPU 正在 Decode。
所以实际使用中：
VS Code: Main Agent + Subagent llama.cpp: Parallel = 1是可以正常工作的。
十五、Reasoning OFF 也能完成完整 Agent Workflow
目前我的配置是：
项目 配置 Reasoning OFF Thinking false 前面提到的：
- 25 Steps / 6 分钟
- 46 Steps / 7 分 18 秒
都是在这个状态下完成。
至少对于我的 Coding Workflow：
Read → Edit → Test → Browser → Debug → Retest
关闭 Explicit Reasoning 并不代表 Agent 就无法完成复杂任务。
因为 Agent 本身已经形成了一个外部循环：
Tool → Result → Next Action
另外一个实际好处是：
不会先生成很长一段 Thinking，然后才真正开始 Call Tool。
十六、一个真正让我卡了很久的坑：Qwen Tool Loop + Jinja
这个问题反而比 GPU 更麻烦。
最开始的时候：
- 普通 Chat 正常
- 第一轮 Tool Call 正常
- Edit 正常
但 Agent 连续跑了一段时间之后，会突然出现：
HTTP 500
Server Log 会看到类似：
Jinja Exception: No user query found in messages.Coding Harness Retry 几次以后，整个 Workflow 就会失败。
一开始我怀疑过很多东西：
Context、MTP、GPU、Vulkan、VRAM
最后发现和这些都没有直接关系。
真正的问题是：
Qwen Chat Template + 多轮 Agent Tool History
十七、换 Chat Template 后，Agent Loop 才真正稳定
后来我换用了针对 Qwen Agent / Tool Loop 修正过的 Chat Template，
通过：
--jinja --chat-template-file <chat-template>加载。
之后同类型 Agent Workflow 可以连续跑几十个 Steps。
之前经常出现的：
No user query found in messages基本消失。
所以如果有人遇到这种情况：
Qwen 普通聊天完全正常，但 llama.cpp 接 Coding Agent，跑多轮 Tool Calling 后突然 Jinja 500
我会建议优先检查：
Chat Template
而不是先怀疑显卡或者 Context。
十八、另一个坑：同名 GGUF 不代表内容一样
我第一次下载 Qwen3.8-27B Q4_K_M GGUF 时：
- Chat 正常
- Coding 正常
- Tool Calling 正常
但一开：
--spec-type draft-mtp就报：
model doesn't contain MTP layers原因是那个 GGUF 并没有保留 MTP / NextN layers。
后来换了一个明确支持 MTP 的 conversion 才正常。
所以：
Qwen 原始模型支持 MTP，不代表所有 Community GGUF 都支持 MTP。
即使文件名都叫：
Qwen3.8-27B-Q4_K_M
不同：
Repository、Converter、Conversion 时间、Export 方式
里面实际保留的 Tensor 都可能不同。
所以不要只看文件名。
十九、目前的性能汇总
类别 项目 配置 / 实测 硬件 CPU Intel Core i5-2400 硬件 Platform B75 / Sandy Bridge 硬件 RAM 16GB DDR3 硬件 GPU AMD Radeon RX 7900 XTX 24GB 模型 Model Qwen3.8-27B 模型 Quant Q4_K_M 模型 GGUF MTP-capable GGUF Backend Runtime llama.cpp Backend GPU Vulkan / RADV 配置 Parallel 1 配置 Context 98,304 配置 KV K q8_0 配置 KV V q4_1 配置 Batch 512 配置 uBatch 512 配置 Flash Attention ON 配置 MTP 5 配置 Reasoning OFF 配置 Prompt Cache ON 性能 Decode 约 40～46 tokens/s 性能 Long Prompt Processing 约 490～540 tokens/s MTP5 Acceptance 约 64～69% MTP5 Mean Accepted Length 约 4.2～4.5 Session Final Context 55,899 tokens Session Truncated 0 Workflow 25 Steps 约 6 分钟 Workflow 46 Steps 7 分 18 秒
二十、这次实验最重要的几个发现
如果把整个实验浓缩成几条，我觉得最值得分享的是：
-
模型只要主要留在显存里，Host 平台可以比想象中旧很多。
我的 i5-2400 和 DDR3 并没有阻止 7900 XTX 把 27B Q4 模型跑到 40～46 t/s。
-
Coding Agent 的瓶颈不能只看 Decode Speed。
Context 到 40K～50K 以后，Prefill 时间可能远远超过 Decode 时间。
-
Prompt Cache 对 Agent 的价值非常高。
特别是 Tool Schema、System Prompt 和 Conversation History 很长的时候。
-
MTP 是否有效，要看真实任务。
Acceptance Rate 高，不代表最终一定更快。
-
GGUF 是否保留 MTP Layers 很重要。
同一个模型、同一个量化名称，不同 conversion 可能完全不同。
-
Chat Template 对 Tool Calling 稳定性非常重要。
普通 Chat 能跑，并不代表多轮 Agent Tool Loop 一定能跑。
-
16GB RAM 可以用，但已经非常接近下限。
这种配置里，RAM 稳定性反而比 CPU 性能更值得关注。
二十一、最后的结论
这次实验原本只是想看看：
一台十几年前的旧 PC，加一张现代 GPU，到底还能不能重新利用。
实际结果比我预期好。
目前这台机器已经不是只能跑一句 Prompt 的 Demo。
它可以实际完成：
Build → Run → Browser → Playwright → Test → Find Problem → Edit → Retest → Finish
这样的完整 Coding Agent Workflow。
所以如果手上本来已经有旧 PC，而需求主要是：
单用户 / 少量用户的 Local LLM 或 Coding Agent Server
我觉得不一定要一开始就把：
CPU、主板、RAM、SSD、GPU
全部换成新平台。
只要模型大小和显存配置合适，
先把预算集中到 GPU，旧 Host 继续使用，在某些场景下其实是完全可行的。
至少 Qwen3.8-27B Q4 + RX 7900 XTX 24GB + llama.cpp Vulkan 这个组合，在我这里已经从“能跑”，走到了“真的可以拿来工作”。
附录：当前 llama.cpp 参数参考
参数 设置 Backend Vulkan GPU Layers all Host Offload 尽量避免 Load Mode mmap Parallel 1 Context / Slot 98,304 KV Cache K q8_0 KV Cache V q4_1 Prompt Cache ON Host Prompt Cache 1024 MB Batch 512 uBatch 512 Flash Attention ON Continuous Batching ON MTP ON MTP n-max 5 MTP Draft K q4_0 MTP Draft V q4_0 Reasoning OFF CPU Threads 4 对应参数大致如下：
--gpu-layers all --no-host --fit off --load-mode mmap --parallel 1 --kv-unified --kv-unified-per-slot 98304 --cache-type-k q8_0 --cache-type-v q4_1 --cache-ram 1024 --cache-prompt --cache-reuse 256 --batch-size 512 --ubatch-size 512 --flash-attn on --cont-batching --spec-type draft-mtp --spec-draft-n-max 5 --spec-draft-type-k q4_0 --spec-draft-type-v q4_0 --reasoning off --jinja --chat-template-file <qwen-agent-chat-template> --threads 4 --threads-batch 4这些参数并不是所谓的“最佳答案”。
它们只是我在：
i5-2400 + 16GB DDR3 + RX 7900 XTX 24GB
这台机器上，经过实际 Coding Agent Workload 后，目前觉得性能、显存占用和稳定性比较平衡的一组配置。
不同 RAM、Context、模型 conversion 和使用方式，最佳值都会不同。
-
幸好我加入auto continue 功能，如今跑一组coding
两个小时 1千万tok
-
最终解了。不要在这个平台上升级R 9700 32G。可以看看我的贴子。AMD 显卡最后一档 7900XTX 再升级就拉跨。这个主机比我的还老。
-
谢谢大哥分享详实的数据。
虽然不想做伸手党，但通读了帖子也没有发现具体是哪个模型。
我让AI给总结了一个清单，能麻烦大哥看一下您用的是哪个模型吗？
Qwen3.8-27B GGUF 模型推荐指南
参考帖子：15 年老平台 + 单张 RX 7900 XTX 跑 Qwen3.8-27B：本地 Coding Agent 实测
帖子核心需求总结根据 lcz.me 帖子（作者 hoyin258），帖主要求的 Qwen3.8-27B 模型需要满足以下条件：
需求 要求 量化格式 Q4_K_M GGUF（约 17-18GB） MTP 支持 保留 MTP 5 layers（用于 spec decode 加速） Flash Attention 支持 Chat Template 带 Jinja template（Tool Calling 稳定） KV Cache 支持 q8_0/q4_1 用途 Coding Agent（长 Context、多轮 Tool Calling） 显存 24GB（RX 7900 XTX）
Hugging Face 推荐模型
推荐 1（最匹配）：unsloth/Qwen3.8-27B-GGUF- 链接: https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
- 下载量: 1050万次（最热门）
- 推荐理由:
提供 UD-Q4_K_M 量化（16.5 GB）— 最接近帖主使用的 Q4_K_M- 提供 MTP/mtp-Qwen3.8-27B-Q4_0.gguf（1.37 GB）— MTP 草稿模型
- 提供 UD-Q4_K_XL（17.6 GB）— 更接近 17-18GB 范围
- 提供 UD-Q5_K_M（19.8 GB）— 如果你的显存足够，质量更好
- 提供 UD-Q5_K_S（18.7 GB）— 另一个接近 18GB 的选择
- 带有 mmproj 视觉投影器
- 官方添加了 Unsloth 风格 chat template
- Apache 2.0 许可证
- 由 Unsloth AI（知名量化团队）维护
可用量化版本速查
量化 文件大小 BPW 说明 UD-Q4_K_M 16.5 GB ~4.9 推荐，平衡质量与速度UD-Q4_K_XL 17.6 GB ~5.2 比 Q4_K_M 略大略好 UD-Q5_K_S 18.7 GB ~5.7 质量更高 UD-Q5_K_M 19.8 GB ~5.9 如果显存允许，推荐此档 UD-Q6_K 22 GB ~6.6 最高质量 llama.cpp 启动命令参考
llama-server \ -m Qwen3.8-27B-UD-Q4_K_M.gguf \ --mtp-model MTP/mtp-Qwen3.8-27B-Q4_0.gguf \ --gpu-layers all \ --no-host \ --fit off \ --load-mode mmap \ --parallel 1 \ --kv-unified \ --kv-unified-per-slot 98304 \ --cache-type-k q8_0 \ --cache-type-v q4_1 \ --cache-ram 1024 \ --cache-prompt \ --cache-reuse 256 \ --batch-size 512 \ --ubatch-size 512 \ --flash-attn on \ --cont-batching \ --spec-type draft-mtp \ --spec-draft-n-max 5 \ --spec-draft-type-k q4_0 \ --spec-draft-type-v q4_0 \ --reasoning off \ --jinja \ --threads 4 \ --threads-batch 4
推荐 2（带 MTP + Vision + 中文优化）：cygnal/Qwen3.8-27B-heretic-ara-Q4_K_M-MTP-GGUF- 链接: https://huggingface.co/cygnal/Qwen3.8-27B-heretic-ara-Q4_K_M-MTP-GGUF
- 下载量: 3.5万次
- 推荐理由:
- Q4_K_M-MTP 量化（16 GB）— 已集成 MTP，单文件即用
- 保留完整 MTP tensors（866 个）
- 包含 mmproj 视觉投影器
- 基于 heretic-ara 微调（去除审查、中英双语优化）
- 对 AMD Vulkan 有优化
- 标注了 AMD Strix Halo/RDMA3.5 优化
- 提供 ROCmFP4-FAST 极速量化（14 GB，~42 t/s）
️ 下载量较少，社区验证不如 unsloth 充分- ️ 是"abliterated/uncensored"版本，适合 Coding Agent（更少拒绝回答），但可能更自由奔放
可用量化版本
文件 大小 BPW 说明 Qwen3.8-27B-heretic-ara-ROCmFP4-FAST.gguf 14 GB 4.26 
最快，~42 t/s，需 ROCmFPX forkQwen3.8-27B-heretic-ara-Q4_K_M-MTP.gguf 16 GB 4.83 推荐，开箱即用Qwen3.8-27B-heretic-ara-Q6_K-MTP.gguf 21 GB 6.56 更高质量 mmproj-Qwen3.8-27B-heretic-ara-BF16.gguf 931 MB — 视觉投影器 llama.cpp 启动命令（单文件版）
llama-server \ -m Qwen3.8-27B-heretic-ara-Q4_K_M-MTP.gguf \ --gpu-layers all \ --parallel 1 \ --kv-unified-per-slot 98304 \ --cache-type-k q8_0 \ --cache-type-v q4_1 \ --flash-attn on \ --cont-batching \ --cache-prompt \ --jinja \ --threads 4
各模型对比模型 量化 大小 MTP Vision 下载量 适合场景 unsloth/Qwen3.8-27B-UD-Q4_K_M Q4_K_M 16.5GB 需额外下载 1050万+ 最均衡推荐 unsloth/Qwen3.8-27B-UD-Q5_K_M Q5_K_M 19.8GB 需额外下载 — 质量更高 cygnal/heretic-ara-Q4_K_M-MTP Q4_K_M 16GB 内置3.5万 开箱即用 unsloth/Qwen3.8-27B-Q4_1 Q4_1 17.5GB 需额外下载 — 接近帖主尺寸
最终建议方案 A：最接近帖主配置（推荐）
使用 unsloth/Qwen3.8-27B-UD-Q4_K_M + unsloth 的 MTP 草稿模型，两者都来自同一团队，兼容性最好。
模型：Qwen3.8-27B-UD-Q4_K_M.gguf（16.5 GB） MTP：MTP/mtp-Qwen3.8-27B-Q4_0.gguf（1.37 GB）方案 B：开箱即用
使用 cygnal/Qwen3.8-27B-heretic-ara-Q4_K_M-MTP，MTP 已内置，单文件即可启动。
模型：Qwen3.8-27B-heretic-ara-Q4_K_M-MTP.gguf（16 GB） MTP：内置，无需额外文件方案 C：追求更高质量
如果显存足够，使用 unsloth/Qwen3.8-27B-UD-Q5_K_M（19.8 GB），在 24GB 显存上也能放下，质量更高。
重要注意事项1. 模型架构特点
Qwen3.8-27B 采用 Gated DeltaNet + Gated Attention 混合架构：
- 64 层，隐藏维度 5120
- Token 词汇表：248,320
- 原生上下文长度：262,144 tokens（可扩展至 1,000,000）
- 内置 MTP（Multi-Token Prediction）训练
2. Chat Template 对 Tool Calling 的重要性
"普通 Chat 能跑，并不代表多轮 Agent Tool Loop 一定能跑。"
- 使用
--jinja参数启用 Jinja2 模板渲染 - 推荐使用带 Unsloth 风格 template 的版本
- 多轮 Tool Calling 稳定性与 Chat Template 强相关
3. MTP 是否保留 Layers 很重要
"同一个模型、同一个量化名称，不同 conversion 可能完全不同。"
- 检查 GGUF 文件中是否包含 MTP tensors
- unsloth 版本将 MTP 单独放在
MTP/目录下 - cygnal 版本将 MTP 内置在单文件中
4. 显存与量化选择
量化 大小 24GB 显存能否放下 推荐程度 Q4_K_M ~16-17GB 可以Q4_K_XL ~17-18GB 可以Q5_K_S ~18-19GB 可以Q5_K_M ~19-20GB 可以Q6_K ~22GB ️ 勉强Q8_0 ~29GB 
放不下— 5. 官方原始模型
- Hugging Face: https://huggingface.co/Qwen/Qwen3.8-27B
- 格式: Transformers (Safetensors)
- 特点: 官方原版，适合 vLLM / SGLang 推理
- 注意: 不是 GGUF 格式，需要自行转换或用 Transformers 加载
相关链接- 原始帖子：https://lcz.me/topic/1508/6
- Unsloth Qwen3.8-27B-GGUF：https://huggingface.co/unsloth/Qwen3.8-27B-GGUF
- cygnal heretic-ara Q4_K_M-MTP：https://huggingface.co/cygnal/Qwen3.8-27B-heretic-ara-Q4_K_M-MTP-GGUF
- 官方 Qwen3.8-27B：https://huggingface.co/Qwen/Qwen3.8-27B
- llama.cpp 文档：https://github.com/ggerganov/llama.cpp
生成时间：基于 Hugging Face 页面信息，模型更新请以官方页面为准。
-
博主用的应该是 Qwen3.8-27B 系列，帖子里没点名具体量化档。我补一下 7900XTX 24G 上常见的几个 GGUF 档：
- Q4_K_M：约 16.6G 权重 + KV，24G 还能留 7G 左右做上下文，速度最快（40-50+ tok/s），长上下文党首选。
- Q5_K_M：约 19G，精度更稳但上下文剩得少，偏 32-64K 短窗。
- Q6_K：约 22G，贴 24G 线，大上下文或 offload 会顶到内存，别配大 ctx。
- Q8_0：约 27G+，超 24G，只能 offload 或换 48G 卡。
如果是跑 coding agent（长上下文 + 多轮），Q4_K_M + KV 量化（q8_0）+ 16-32K 上下文是 7900XTX 24G 的甜点。注意你这平台是 Sandy Bridge + 16G DDR3，无 ReBAR——权重走显存、上下文走内存时内存带宽会拖后腿，所以别开太大的 ctx 或做太多 offload。
具体博主用的哪个档，可以让博主补充确认；但这几档在 agent 场景的速度差没想象中大，Q4_K_M 最划算。
-
更新：RX 7900 XTX 跑 Qwen3.8-27B —— 换 Unsloth UD-Q4_K_M 后上 128K + Q8/Q8 KV + K4V + Vision
上一篇：
发布之后，我又继续跑了一段时间的真实 Coding Agent 任务，也调整了几项配置。
这次不重复上一篇已经讲过的硬件、Vulkan、Chat Template、Agent 工作流，只记录 真正改变的地方、为什么这样改，以及后来遇到的问题。
目前核心变化如下：
项目 上一版 当前 GGUF 普通 Q4_K_M Unsloth UD-Q4_K_M 模型大小 ~17.1 GB ~16.5 GB Context 98,304 131,072（128K） KV Cache K q8_0 q8_0 KV Cache V q4_1 q8_0 N-gram K4V OFF ON，N32 / M48 MTP n-max 5 n-max 2 Vision 未作为主要配置 BF16 mmproj ON Parallel 1 1
1. 最大变化：换成 Unsloth UD-Q4_K_M
现在使用：
Qwen3.8-27B-UD-Q4_K_M也就是 Unsloth Dynamic Quant 版本。
相比普通 Q4_K_M，模型文件本身大约从：
~17.1 GB降到：
~16.5 GB大约省下 600 MB 左右。
600 MB 看起来不算很多，但对于只有 24 GB VRAM 的 RX 7900 XTX 来说，其实非常有价值。
因为模型权重省下来的显存，可以重新分配给：
- 更大的 Context
- 更高精度的 KV Cache
- Vision mmproj
- MTP draft context
- Vulkan temporary buffers
- allocator / fragmentation headroom
所以这次调整的核心思路不是：
模型越小越好。
而是：
把模型权重省出来的显存，重新投资到更有价值的地方。
2. Context：98K → 128K
上一篇我使用：
98,304现在改成：
131,072也就是完整的 128K Context。
原因来自实际 Coding Agent 使用。
真实 Agent Session 的 Context 增长速度比普通聊天快很多，因为里面不只是用户输入，还包括：
System Prompt Tool Schema File Context Tool Results Browser / Terminal output Agent History Subagent result Compaction 前后的历史上一篇已经实际跑到过 50K+ Context。
继续跑更复杂任务之后，我觉得 98K 已经不算特别宽裕，所以这次直接提高到 128K。
目的不是为了数字好看，而是：
减少长任务中途因为 Context 不够而提前压缩 / 丢掉早期信息。
3. KV Cache：K8/V4.1 → Q8/Q8
上一篇：
K = q8_0 V = q4_1现在：
K = q8_0 V = q8_0这项调整不是为了提高 token/s。
KV Quantization 更主要是在交换：
KV 精度 vs Context 容量可以简单理解：
Context Size = 可以保留多少历史 KV Precision = 这些历史的 attention state 保存得有多精细以前为了塞下更大的 Context，我把 V 压到 q4_1。
现在因为 Unsloth UD-Q4_K_M 本身省了一部分 VRAM，所以我把省出来的显存重新投入 KV：
更小的模型权重 + 128K Context + Q8/Q8 KV对于长时间 Coding Agent，我目前更喜欢这个组合。
我没有继续为了追 160K / 200K Context 而把 KV 压得更低。
4. 新增加
ngram-map-k4v上一篇主要使用 MTP。
现在改成：
--spec-type ngram-map-k4v,draft-mtp并使用：
--spec-ngram-map-k4v-size-n 32 --spec-ngram-map-k4v-size-m 48 --spec-ngram-map-k4v-min-hits 1也就是：
N = 32 M = 48 min_hits = 1这部分主要参考了 LCZ 上另一篇 RX 7900 XTX Vulkan 优化实测：
K4V 和 MTP 的区别
MTP：
模型自己预测后面的 token ↓ Target model 验证K4V：
从当前 Context 中寻找已经出现过的 token pattern ↓ 找到相同内容 ↓ 直接拿后面的内容作为 speculative draft ↓ Target model 验证这对 Coding Agent 很合适。
因为 Coding Agent 经常做的是：
读取已有代码 ↓ 只修改其中几行 ↓ 大量结构保持不变例如：
- Source code rewrite
- HTML / CSS
- JSON / YAML
- Tool arguments
- 重复的函数结构
- 大段代码只修改少量内容
这些场景很容易命中已有 Context。
为什么使用 N=32
N 太小的时候，容易出现：
格式很像 但实际内容已经不同结果 N-gram 不断给出错误 draft，最后全部被 Target model reject。
所以我现在使用比较保守的：
N = 32 M = 48对 Coding / Source Rewrite 比较适合。
5. MTP：n=5 → n=2
上一篇：
--spec-draft-n-max 5现在：
--spec-draft-n-max 2这里不是因为 n=2 比 n=5 快。
反而 n=5 在我之前的测试中，decode 可以明显更快。
但后来我遇到了一次真正麻烦的稳定性问题。
实际发生过一次 AMD GPU hard hang
一次长时间 Agent Session 中：
llama-server 正常运行 ↓ 长 Context + MTP ↓ AMDGPU 出现 gfx ring timeout ↓ MES / GPU reset failed ↓ 模型停止生成 ↓ Client 5 分钟收不到 stream ↓ pi-ai stream idle timeout after 300000ms ↓ 最后需要 hard reset最开始看到：
pi-ai stream idle timeout after 300000ms很容易误以为只是 Client timeout。
但检查 kernel log 后发现，真正先发生的是：
amdgpu ring gfx timeout也就是说：
GPU 已经挂住 ↓ llama-server 没有新 token ↓ Client 等了 300 秒 ↓ 才出现 timeout所以这个 timeout 是 结果，不是根因。
6. 后来发现 upstream 也有人遇到类似问题
继续查 llama.cpp issue 后，发现已经有非常接近的报告：
Qwen3.8-27B + AMD Vulkan / RADV + draft-mtp + Long Context / Long Prefill会出现：
vk::Queue::submit: ErrorDeviceLost AMDGPU ring timeout GPU reset其中一个很有价值的 A/B 是：
MTP OFF → 同一配置可以通过 125K+ prompt MTP ON → 长 prompt 中途 DeviceLost相关 issue：
https://github.com/ggml-org/llama.cpp/issues/27306
所以我现在把：
MTP n=5降低到：
MTP n=2主要是减少 speculative workload，让配置保守一点。
但这里必须说明：
n=2 并不是已经证明可以修复 AMD Vulkan MTP hang。
Upstream 仍然有 n=2 出现 DeviceLost 的案例。
所以我现在把 MTP2 看成：
比较保守的 Performance Setting而不是：
已经解决稳定性的 Fix
7. 现在正式加入 Vision
当前也同时加载：
Qwen3.8-27B UD-Q4_K_M + Qwen3.8 BF16 mmproj核心设置：
--mmproj <Qwen3.8-BF16-mmproj> --image-min-tokens 1024 --image-max-tokens 2240这样 Coding Agent 可以真正处理网页 Screenshot / UI。
例如：
修改网页 ↓ Browser Test ↓ Screenshot ↓ Vision 查看 UI ↓ 发现 layout / CSS 问题 ↓ 继续修改 ↓ Retest所以现在同一张 RX 7900 XTX 同时承担：
27B LLM + 128K Q8/Q8 KV + Vision + K4V + MTP2
8. 当前真实 VRAM 使用
最近一次真实 Agent Task 运行中看到：
VRAM used : 21.53 / 23.98 GiB VRAM free : 2.45 GiB GTT : 1.29 GiB GPU : 77%也就是说：
UD-Q4_K_M + 128K + Q8/Q8 + Vision + K4V + MTP2目前仍然可以完整放进一张 24GB RX 7900 XTX。
剩 2.45GB 并不是浪费
我现在反而不追求：
23.9 / 23.98 GiB才算“利用率高”。
Vulkan 运行过程中还需要：
- Compute workspace
- Temporary buffers
- Vision buffers
- MTP draft context
- Vulkan allocator
- Fragmentation headroom
而且 7900 XTX / Vulkan 已经有人实测到：
显存并没有真正 OOM，但因为 allocation / GTT / fragmentation，性能会突然出现 cliff。
所以现在我的思路是：
尽量让所有主要 inference workload 留在 VRAM + 同时保留一定 VRAM headroom而不是把最后几百 MB 都塞满。
9. 当前公开版核心配置
下面只保留跟性能有关的参数，不放本机路径、IP、API Key：
GGML_VK_DISABLE_HOST_VISIBLE_VIDMEM=1 --device Vulkan0 --gpu-layers all --no-host --fit off --load-mode mmap --mmproj <Qwen3.8-BF16-mmproj> --image-min-tokens 1024 --image-max-tokens 2240 --parallel 1 --kv-unified --kv-unified-per-slot 131072 --cache-type-k q8_0 --cache-type-v q8_0 --cache-ram 1024 --cache-prompt --batch-size 512 --ubatch-size 512 --flash-attn on --cont-batching --spec-type ngram-map-k4v,draft-mtp --spec-draft-n-max 2 --spec-ngram-map-k4v-size-n 32 --spec-ngram-map-k4v-size-m 48 --spec-ngram-map-k4v-min-hits 1 --reasoning off --jinja --chat-template-file <fixed-qwen-agent-template> --threads 4 --threads-batch 4
10. 这次更新我觉得最重要的不是 token/s
上一篇更像是在证明：
十几年前的平台 + 单张 RX 7900 XTX，确实可以跑一个真正能工作的 27B Coding Agent。
这一轮调整之后，我更关注的是：
显存怎么分配而不是单独追某一个 Benchmark 数字。
现在的思路是：
Unsloth UD-Q4_K_M ↓ 模型权重省 ~600MB ↓ 把空间重新投入： ↓ 128K Context + Q8/Q8 KV + Vision + K4V + MTP + VRAM Headroom我觉得这比：
只追更低 Quant 或者 只追更高 Context 数字更加适合真实 Coding Agent。
总结
从上一篇到现在，真正变化可以压缩成一句：
普通 Q4_K_M 98K K8 / V4.1 MTP5 ↓ Unsloth UD-Q4_K_M 128K Q8 / Q8 K4V + MTP2 Vision其中我觉得最值得分享的经验有三个：
1. 小一点的 GGUF 不只是省空间
省出来的 VRAM 可以重新投资到：
Context KV Precision Vision Speculative Decoding Headroom对于 24GB 显卡，这种显存重新分配很有价值。
2. K4V 对 Coding Agent 很实用
特别是 Source Rewrite、HTML/CSS、JSON/YAML 这种大量复用旧内容的任务。
3. MTP 确实很快，但 AMD Vulkan 长任务仍然要谨慎
我实际遇到过一次：
AMDGPU ring timeout + GPU reset failed而 upstream 也有接近的 Qwen3.8 + RADV + draft-MTP 报告。
所以目前我不会把 MTP 当成一个完全没有代价的“免费加速开关”。
目前这套配置还会继续跑真实 Agent workload。
现阶段我觉得：
24GB 显卡最重要的不只是“模型能不能塞进去”，而是如何在 Model、KV、Context、Vision、Speculative Decoding 和安全余量之间分配这 24GB。
对我自己的工作负载来说，目前这版比上一篇更合理。
