先说结论
我原本只是想验证一件事：
一台十多年前的旧电脑，如果只升级显卡，能不能变成一台真正可用的本地 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 和使用方式，最佳值都会不同。