本地 AI 工作站搭建与极限调优报告

[kevon]

Local_AI_Report.pdf
新人一个，搞了几乎一周，终于完成了，供大家参考。如有好的建议，请不吝赐教。

[kop wang]

恭喜，这个pdf的生成有几点值得说道。
其实我个人不排斥AI文章，但是AI内容需要楼主审核。比如这个pdf的结构就不是特别理想：
1、关键信息后置或隐藏太深。比如楼主采用的是什么模型，几位量化，这些都藏的太靠后了。对于新手而言可能这些信息才是最重要的。
2、尽量把关键信息发在论坛正文，而不是以附件的形式。这样更方便大家伙通过搜索引擎或者论坛内检索的方式找到你的分享。
3、缺失一些关键的数据。比如楼主只表达了decode速度，没明显体现prefill速度。从Hermes的使用来讲，prefill和decode我个人理解，对于响应或者体验的影响是一半一半。对于Coding场景，这个比例应该是2：1，prefill其实更加关键。

再次感谢楼主的分享。

[williamlouis]

已读。如果是 Q3的话 价值大大的折扣。恭喜楼主折腾成功。希望继续研究Q4。还是Q3的话。不要继续深入了。

[kevon]

抱歉各位，这是我第一次在论坛发技术分享帖，确实没有做好，十分感谢指正。
补充核心信息：
| 模型 | Qwen3.6-27B-Q3_K_M.gguf（Qwen3.6-27B，Q3_K_M 量化） |
| 推理引擎 | llama.cpp （llama-server） |
| 显存占用 | ~14.0 GB / 16.3 GB（稳态） |
| 上下文窗口 | 131,072 Tokens |
| GPU offload | -ngl 50（50层 GPU / 14层 CPU） |
| 部署方式 | pipx 安装 Hermes Agent v0.16.0，委派模式（云端 DeepSeek 规划 + 本地 Qwen 执行） |
Prefill 速度 ：
实测补充如下：
|场景 | Prompt Tokens | Prefill (TTFT) | Prefill 速度 | Decode 速度 |
| 短对话 | 21 tok | 0.54s | 39.2 tok/s | 15.2 tok/s |
| 长文档分析 | 2,527 tok | 2.46s | 1,026 tok/s | 14.4 tok/s |
| Coding 场景 | 7,261 tok | 6.92s | 1,049 tok/s | 13.3 tok/s |
对于 Coding 场景，Prefill 确实是瓶颈（TTFT 6.9s），Decode 反而相对稳定（13-15 tok/s）。 在 16GB 显存下跑 27B 模型 + 128K 上下文，KV Cache 用了 q4_0 压缩（从 ~8GB 压到 ~2.5GB），但是，5070Ti也只能这样了，各位有什么好的建议，我一定认真测试完善。

再次感谢各位专业反馈，受益匪浅

[kevon]

@williamlouis q4我的确试过了，能用，太卡了，hermes要求至少64k上下文，实际使用效果很差。另外，64k上下文也经常停下来压缩文档，q4基本无法使用。16g也就这样了，最终还是要换显卡才行。
对比测试报告：

Qwen3.6-27B: Q4_K_M vs Q3_K_M 实测对比报告
硬件: RTX 5070 Ti (16GB) + AMD 9800X3D (8核/16T)
日期: 2026-06-11

基础信息

             Q3_K_M        Q4_K_M        变化

文件大小 13.6 GB 16.8 GB +23.5%
GPU 层数 -ngl 50 -ngl 48 -2层
VRAM 加载后 13884 MB 15422 MB +1.5G
VRAM 余量 2416 MB 818 MB -66%
系统 RAM (mmap) 6.2 GB 16.8 GB +10.6G

Prefill & Decode 速度对比

场景 Q3_K_M Q4_K_M 变化

短对话 (6~21 tok) P:39 D:15.2 P:35 D:11.7 P:-11% D:-23%
中等 (400~500 tok) P:623 D:14.4* P:623 D:11.6 P:0% D:-19%
长上下文 (2000~2500 tok) P:1026 D:14.4 P:1038 D:11.3 P:+1% D:-22%
大压力 (6671~7261 tok) P:1049 D:13.3 P:938 D:10.6 P:-11% D:-20%

• Q3_K_M 中等场景为外推估算

首字延迟 TTFT 对比

场景 Q3_K_M Q4_K_M 变化
短对话 (6~21 tok) 0.54s 0.17s -69%
中等 (400~500 tok) — 0.64s —
长上下文 (2000~2500 tok) 2.46s 1.95s -21%
大压力 (6671~7261 tok) 6.92s 7.11s +3%

[kevon]

@williamlouis 你给个建议？哪个更适用点？

[Xiaote]

@kevon 你的对比测试做得很详细，赞一个。对于5070 Ti 16G跑27B + Hermes这个组合，我的建议如下：

从实测数据来看，Q4_K_M的decode速度降了20-23%，在交互式使用场景下感知很明显。而且余量只剩818MB，一旦Hermes需要调用其他工具（比如联网搜索），很容易触发offload，体验会断崖式下降。

建议方案（按推荐优先级）：

1. 继续用Q3_K_M，但优化KV Cache
   你目前的Q3_K_M配置已经很合理。建议试试--cache-type-k q4_0 --cache-type-v q4_0（如果还没启用），可以把KV Cache再压一压，留出更多余量给工具调用。

2. IQ4_XS比Q4_K_M更适合16G
   Q4_K_M文件太大（16.8GB），基本把显存塞满了。IQ4_XS介于Q3和Q4之间，文件小不少，但精度比Q3好。如果追求更好的模型质量又不想掉速度，这个值得一试。

3. 如果Hermes工具调用频繁，可以考虑降模型
   27B在16G上跑Hermes确实有压力。如果经常遇到卡顿或压缩文档，可以试试Qwen3.6-14B（Q4_K_M或Q8），速度快很多，而且对于工具调用和简单推理来说差距不大。

总结：你现在的Q3_K_M配置其实是5070 Ti 16G上跑27B Hermes的最佳平衡点。不用因为williamlouis说的"Q3价值打折扣"而焦虑——在显存受限的情况下，能流畅用比追求量化精度更重要。换个角度说，能用Q3跑128K上下文+Hermes工具链，本身就是很实用的配置。