看到《7900 XTX 跑 Qwen3.8-27B 实测 73.4 t/s 指南》的框架和测速方法论。我也来发一下我的经历，以下都是AI帮我写的

1. 先给结论

一句话：这台机器跑 Qwen3.8-27B 的 Q6_K，短工具/代码题 60+ t/s、长 agent 对话 50 t/s 是常态，64K 全 GPU 加载无 OOM。
速度从来不是"显卡不行"，是我一开始没让草稿头帮忙、还开着一堆互相打架的并发。

2. 名词白话解释（新手先看这区）

3. 硬件与软件环境

换一项数字就可能不一样，所以全列出来。

硬件

软件

4. 最终配置（可直接复制）

我的实际启动方式：启动.bat → 一键脚本，等价于下面这行（router 模式 + 全参数写死）：

llama-server.exe ^
    --models-dir E:\aiYY\llama.cpp\models ^
    --models-preset E:\aiYY\llama.cpp\presets.ini ^
    --host 127.0.0.1 --port 8080 ^
    -t 8 --parallel 1 -c 65536 -n 8192 ^
    -fa on --cache-type-k q8_0 --cache-type-v q8_0 ^
    --jinja ^
    --spec-type draft-mtp --spec-draft-n-max 2 ^
    --reasoning off --reasoning-budget 0 ^
    --temp 0.7 --top-p 0.8 --top-k 20 --presence-penalty 1.0 ^
    --fit-target 2048

逐项为什么这么设：

5. 最重要的一节：为什么数字对不上（27 → 51.8/43.4 → 61.7）

同一台机器，同一组参数，换一种测试负载，速度差 40%：

为什么？MTP 的速度完全取决于草稿猜得准不准：

• 创作类文字：下一个字有一百种写法，草稿猜不中，接受率掉到 0.5，猜了白猜还倒赔验证成本；
• 代码 / JSON：格式高度固定（{"name": "get_weather", "arg... 后面几乎必然是 uments"），草稿一猜一个准，接受率上 0.9，一次前向吐好几个字。

所以"这台机器能跑几 t/s"这个问题本身没有答案，必须先问"跑什么题"。
我最初量到 27 t/s，就是因为既没开 MTP、又多槽并发、KV 还不量化——拿最差的配置量了个数字，然后差点去怪显卡。这和帖主"拿创作题测投机解码、量出最坏情况然后怀疑硬件"是同一类错误。

那为什么没到帖子的 73.4 t/s？

三层原因，每一层都是实打实的：

1. 量化不同：帖子是 Q4_K_M（15.9 GiB），我是 Q6_K（20.9 GiB）。Q6 每个 token 要多搬约 5 GB 权重，decode 天花板本来就低一截；
2. 平台不同：帖子是 AMD 7900 XTX 走 Vulkan，我是 NVIDIA 4080S 走 CUDA，架构和驱动都不同，不能直接比；
3. 模型版本不同：帖子是官方 unsloth 带审查版，我的是 Uncensored 去审查变体——权重根本不是一个模型。论坛有人说"Q6_K 只有 28 t/s"，那通常是没塞进显存；我 32G 塞得下，所以 Q6 能稳定 44~62。

一句话：数字要带测法和配置才有意义，抄任何人的数字（包括这篇）都不如自己跑一遍。

6. 效能实测（全部附测法）

6-1. 短负载复测（2026-09-06）

测法：POST /v1/chat/completions，temperature=0.6, top_p=0.5, top_k=15，单次请求，读返回 timings 字段。

6-2. 真实 Hermes agent 负载（2026-09-03，读 llama-server slot 日志）

结论：agent 真实长对话 ~50 t/s 是常态，短工具/代码题 60+ 是"可预测性红利"，别拿短题数字去承诺长对话体验。
另外注意：agent 的瓶颈往往是 prefill 不是 decode（我见过 Hermes 一轮 prompt 8K~16K token），等几十秒别慌，看日志是 prefill 还是 decode。

7. 参数调校过程与完整对照表（27 → 现在）

按时间顺序讲，每个数字都有据可查（脚本备份 + 调试记录）。

起点：~27 t/s

最初的启动脚本（8/16 版）有三个问题：32G 档位故意关掉了 KV 量化（f16）、同时驻留 2 个模型、压根没有 MTP。
三个问题叠加：显存被 KV 吃紧、多槽互相抢、草稿头没用上。结果就是 ~27 t/s，还一度让我怀疑是 Q6_K 或者显卡的问题。

第一刀（提升最大）：开 MTP + 单并发 + KV 量化

实测：代码 51.8 t/s（接受率 ~0.70）、创作 43.4 t/s（~0.50），对比原点约 60–90% 提升。

第二刀：修"每次 8192 就停"（思考链吃光额度）

现象：生成停在 8192、显示 Reasoning — Cancelled。
原因：网页端默认把 Qwen3.8 思考开到 xhigh，模型把额度全花在 <think>，正文还没开始就被 -n 8192 截断。
修法：--reasoning-budget 0 不算关，要 --reasoning off（它才会把模板 enable_thinking 设 false）。

第三刀：32K → 64K（给 Hermes agent 用）

• 顺带修正一个认知错误：脚本里 YARN_ORIG_CTX = 32768（注释"Qwen3 系列是 32768"）是错的——Qwen3.8-27B 原生上下文 262K，64K 根本不需要 YaRN；
• 显存账：32K 用 24.5GB，64K 估算 25–28GB，实测 26.5GB ✓，全 GPU。

对照表

8. 踩过的坑（按杀伤力排序）

1. 拿没开 MTP / 多并发 / KV 不量化的配置量了个 27，差点去怪显卡
   先问"慢在哪一层"再动手。先开 MTP 看接受率，再谈别的。

2. --reasoning-budget 0 关不掉思考链（8192 停机）
   网页端把 Qwen3.8 思考默认开到 xhigh，额度全被 <think> 吃光、正文空白。
   正解：--reasoning off（+ 可再补 budget 0）。想留思考就把前端 Reasoning 降到 low、预算限 1024~2048。

3. 脚本和服务脱节
   服务都手动试到 42 t/s 了，磁盘上的脚本还是旧配置。改完必须重启验证日志里的 n_slots = 1, n_ctx_slot = 65536，别信"我以为生效了"。

4. presets.ini 段名没对上模型 id → 路由表里多个幽灵条目
   段名写 [Qwen3.8-27B]，实际模型名是 Qwen3.8-27B-Uncensored-Q6_K 且没绑 model 路径，结果注册出一个永远 unloaded 的假模型。
   要么段名改对并补 model = 路径，要么干脆删掉该段（参数命令行已经全覆盖）。验证：启动日志 Loaded N custom model presets，N=0 就是没读进去。

5. 黑屏一次：NVIDIA 驱动崩溃（已解决）
   时间线：nvlddmkm 报错 → llama-server 崩溃（0xc0000409）→ 系统 Kernel-Power 41 重启。无 WHEA、无 OOM、30 天仅一次。
   判定是驱动/CUDA 与 llama.cpp 的偶发冲突，610.88 → 616.56 清洁安装后未再发生。
   复发预案：显卡恢复默认频率电压 → 关 MTP 对照 → 回退驱动 → 上下文降到 49152。别改 TdrDelay，那只是延长挂死时间。

6. 模型的"记忆"会污染它自报的硬件
   Hermes 长期记忆里残留了旧环境（AMD 7900 XTX / Vulkan）记录，模型照系统提示词念出了错误配置。换机器/改配置后记得清理长期记忆文件。

7. Connection handling canceled ≠ 模型问题
   多数是上游客户端主动断开（点停止、切会话、Hermes 压缩后重连）。先看是不是客户端行为，别急着改服务端。

9. 不要做的事

• 不要照抄任何配方（包括这篇）而不自己测一遍——n-max 甜点位、上下文大小都取决于你的负载和量化。
• 不要把 --spec-draft-n-max 抄成 5/6/8——本机 Q6_K + CUDA 实测 2 最稳，更大的值不保证更快（帖主那台 8 直接崩到 45 t/s）。
• 不要用 --cache-type-k q4_0——K 决定"看哪里"，别饿死它。要省显存压 V（q4_1），不压 K。
• 不要以为 --reasoning-budget 0 就是关了思考——用 --reasoning off。
• 不要拿创作题 / 超短 prompt 测速当基准——那是投机解码的最坏情况，专门用来吓自己的。
• 不要信任何没附测法的 t/s（包括这篇的，所以上面每个数字都写了测法）。
• 不要在 --parallel 1 下并发打本地模型——会排队。

10. 附录：如何自己复现 / 再测

1. 改完参数重启，看启动日志：n_slots = 1, n_ctx_slot = 65536；
2. 验证实际生效参数：请求 /v1/models，看 loaded 模型的 status.args；
3. 测速：对着 /v1/chat/completions 发三类题（工具 / 代码 / 创作），读返回 timings 的 predicted_per_second 和 draft_n_accepted / draft_n；
4. 判断标准：接受率 < 0.5 = 你的工作负载不适合投机解码或 n-max 开太大；同一配置 run-to-run 抖动 ~7% 属正常，小于 7% 的差距别当提升。

11. 未测项目与已知限制（诚实揭露）

• n-max 没扫全：现在停在 2，但短负载接受率已经到 0.94、agent 轮到过 0.999/mean len 3.0——接受率这么高，理论上 n-max=3~4 可能更快，值得哪天扫一遍 2/3/4/5/6/8。
• 超长上下文 prefill 没测：只实测到 16.5K token 的 prefill（~1,339 t/s），64K 塞到 3~5 万 token 的首字延迟未知。
• Q4_K_M 对照没跑：只有 Q6_K 一个档，想比"量化 vs 速度"可以下个 Q4_K_M 放 models 目录，router 会自动注册。
• 能力/安全没按帖子的 20 题重测：帖子官方版测出 19/20，但那是带审查版；我这是 Uncensored 去审查版，B4（压力话术下守住）/ B10（已授权时不过度保守）这类安全边界题必须自己验证一遍再让它碰真实工具。
• mmproj 多模态没装：纯文本模型，看图要另配。
• 系统内存 48GB 是够的，但 --cache-ram 还没开大：目前 Hermes 长对话 LCP 缓存复用正常（0.69~0.997），如果哪天日志出现"放弃快取"，再按帖子的做法把 prompt cache 开到 16~32GB。

结语

这台 4080 SUPER 32G 最终在工具调用场景跑到 61.7 t/s、真实 agent 长对话稳定 ~50 t/s、64K 全开无 OOM——全程是自己 9/3 一天内一步步试出来的，起点只有 27。
过程中最大的收获不是那几个参数，而是三条经验：先开投机解码看接受率再谈别的、单用户就把并发砍到 1、关思考链要用对参数。
如果你也要复现，记住帖子和这篇共同的那句话：数字必须带测法，接受率是灵魂，n-max 自己扫。