小白到能玩# 4080 SUPER 32G 跑 Qwen3.8-27B 无审查版(Q6_K) 实测61.7t/s 完整部署与实测指南,自己从27t/s一路调上来的,分享给大家
-
4080 SUPER 32G 跑 Qwen3.8-27B 无审查版(Q6_K) 实测61.7t/s 完整部署与实测指南,自己从27t/s一路调上来的,分享给大家
看到《7900 XTX 跑 Qwen3.8-27B 实测 73.4 t/s 指南》的框架和测速方法论。我也来发一下我的经历，以下都是AI帮我写的
1. 先给结论
项目 结果 硬件 Ryzen 7 9800X3D + RTX 4080 SUPER 32GB + 系统内存 48GB 引擎 llama.cpp b10549（CUDA 后端，router 多模型模式） 模型 Qwen3.8-27B-Uncensored-Q6_K（Q6_K，20.9 GB，27.32B 参数，去审查版） 上下文 64K（模型原生 262K，不需要 YaRN） 工具调用 decode 61.7 t/s（接受率 0.94） 代码生成 decode 60.3 t/s（接受率 0.90） 中文创作 decode 44.4 t/s（接受率 0.53） 真实 Hermes agent 长对话 ~50 t/s（48K 上下文不截断，接受率最高 0.999） 起点 ~27 t/s（没开 MTP、多槽并发、KV 不量化） 一句话：这台机器跑 Qwen3.8-27B 的 Q6_K，短工具/代码题 60+ t/s、长 agent 对话 50 t/s 是常态，64K 全 GPU 加载无 OOM。
速度从来不是"显卡不行"，是我一开始没让草稿头帮忙、还开着一堆互相打架的并发。
2. 名词白话解释（新手先看这区）
名词 白话解释 t/s 每秒生成几个 token。中文大约 1 字 ≈ 1 token。 decode / generation 模型"吐字"阶段，就是你看到字一个一个冒出来的过程。 prefill / prompt processing 模型"读你问题"的阶段，吐第一个字前的那段沉默就是它。 TTFT 按下送出到第一个字出现的延迟。聊天体感主要看它。 量化（Q4/Q6…） 把模型权重压缩：Q4_K_M 约 4bit/参数，Q6_K 约 6bit，文件更大但更准。 KV cache 模型记"前面讲过什么"的缓存，放显存，上下文越大吃得越多。 MTP（投机解码） 模型用一个很便宜的"草稿头"先猜几个字，再用完整模型一次验证；猜对几个就赚几个。 draft acceptance（接受率） 草稿被验证通过的比例。这是本文的灵魂数字——0.9 和 0.3 的速度能差一倍。 n-max（--spec-draft-n-max） 一次让草稿头猜几个字，要自己扫，抄别人的没用。 offload / --fit-target 让多少层上显卡。显存够就全上，留一点余量更稳。 router 模式 llama-server 的新玩法：一个端口管理多个模型、网页里热切换。 YaRN 把模型位置编码外推到超过原生上下文；Qwen3.8 原生 262K，开 64K 根本用不到它。
3. 硬件与软件环境
换一项数字就可能不一样，所以全列出来。
硬件
项目 型号 CPU AMD Ryzen 7 9800X3D（8 核） 系统内存 48 GB GPU NVIDIA GeForce RTX 4080 SUPER 32 GB（不是普通 16GB 版，nvidia-smi 读数 32760 MiB） PCIe Gen4 ×16 显存占用 32K 上下文约 24.5 GB；64K 上下文实测约 26.5 GB / 32 GB，全 GPU 加载 软件
项目 版本 操作系统 Windows 10 Pro 23H2 推理引擎 llama.cpp b10549 / b2e5e9b28（CUDA 后端） 显卡驱动 NVIDIA 616.56（Studio） 模型文件 Qwen3.8-27B-Uncensored-Q6_K.gguf（20.9 GB，Q6_K，无 mmproj）
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逐项为什么这么设：
参数 值 原因 -c65536（64K） 主要用途是给 Hermes agent 当后端。agent 会把 system prompt+工具定义+调用结果+历史持续塞进上下文，32K 容易触发压缩；Hermes 官方对本地模型也建议约 64K。Hermes 的 context_length 必须等于这里的 65536。日常聊天 32K 也够，我上 64K 是给 agent 用的 --spec-type draft-mtp --spec-draft-n-max 2MTP 投机解码 最大提速来源，Qwen3.8 的 GGUF 自带草稿头不用另下模型。n-max 我扫过，2 是本机甜点位（见 §6），别抄帖子那台的 5 --cache-type-k/v q8_0KV 都压到 8bit 32G 显存塞 64K 还有余，两边都给满最稳。如果显存紧，按帖子的结论应该是 K 多给位、V 少给位（K8V4 优于 K4V8），而不是砍 K --parallel 1单槽 多槽会把 64K 上下文和显存切开，互相排队。单用户自用，一槽吃满 --reasoning off --reasoning-budget 0关思考链 血泪教训：只设 --reasoning-budget 0关不掉 Qwen3.8 的思考，模型会把生成额度全花在 <think> 里，表现为"每次都停在 8192 / Reasoning Cancelled"（详见 §7 坑 #2）--fit-target 2048自动分配、留 2GB 让 llama 自己算多少层上 GPU，显存留 2 GB 余量，比手动 -ngl 塞满稳 -n 8192单次生成上限 防失控保险丝。撞到它说明模型复读或没吐结束符，别盲目调大 -t 8CPU 线程 8 核机器。decode 是 GPU 瓶颈，线程数不用拉满
5. 最重要的一节：为什么数字对不上（27 → 51.8/43.4 → 61.7）
同一台机器，同一组参数，换一种测试负载，速度差 40%：
测试负载 decode 草稿接受率 中文散文创作 44.4 t/s 0.53 C++ 代码生成 60.3 t/s 0.90 工具调用（JSON） 61.7 t/s 0.94 为什么？MTP 的速度完全取决于草稿猜得准不准：
- 创作类文字：下一个字有一百种写法，草稿猜不中，接受率掉到 0.5，猜了白猜还倒赔验证成本；
- 代码 / JSON：格式高度固定（
{"name": "get_weather", "arg...后面几乎必然是uments"），草稿一猜一个准，接受率上 0.9，一次前向吐好几个字。
所以"这台机器能跑几 t/s"这个问题本身没有答案，必须先问"跑什么题"。
我最初量到 27 t/s，就是因为既没开 MTP、又多槽并发、KV 还不量化——拿最差的配置量了个数字，然后差点去怪显卡。这和帖主"拿创作题测投机解码、量出最坏情况然后怀疑硬件"是同一类错误。那为什么没到帖子的 73.4 t/s？
三层原因，每一层都是实打实的：
- 量化不同：帖子是 Q4_K_M（15.9 GiB），我是 Q6_K（20.9 GiB）。Q6 每个 token 要多搬约 5 GB 权重，decode 天花板本来就低一截；
- 平台不同：帖子是 AMD 7900 XTX 走 Vulkan，我是 NVIDIA 4080S 走 CUDA，架构和驱动都不同，不能直接比；
- 模型版本不同：帖子是官方 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 字段。负载 题目 decode prefill 接受率 备注 工具调用 "查台积电股价并总结近况"（带 web_search schema） 61.7 t/s 672 t/s 0.939 prompt 301 token，wall 2.4s 代码 C++17 线程安全 LRU cache 60.3 t/s 144 t/s 0.897 prompt 46 token 中文创作 300 字"山中湖泊日出" 44.4 t/s 270 t/s 0.527 和 9/3 历史值 43.4 一致 6-2. 真实 Hermes agent 负载（2026-09-03，读 llama-server slot 日志）
场景 decode 接受率 / mean len 其他 网页长输出（修复思考链前） 50.9 t/s 0.71 / 2.42 撞 -n 8192（当时 reasoning 没关掉）同轮 8207-token prompt — — prefill 1,601–1,712 t/s Hermes 短轮 ~50.7 t/s 0.999 / 3.00 上下文 48,334/65,536、truncated=0 Hermes 上下文压缩后重填 50–53 t/s 0.82 16.5K token 重 prefill ≈1,339 t/s Hermes 长生成 51.0–51.2 t/s 稳定 — 48K 上下文不掉速 结论：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 量化
改动 值 效果 MTP 投机解码 --spec-type draft-mtp --spec-draft-n-max 2提速主力 单并发 --parallel 1、maxModels 2→1资源还给唯一在用的对话 KV 量化 q8_0 / q8_0给上下文腾显存 显存策略 --fit-target 2048自动分配 + 留 2GB 实测：代码 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。
对照表
阶段 ctx 并发 MTP KV 实测 起点 32K 多并发（2 模型槽） 无 f16 ~27 t/s 第一刀后 32K parallel=1 draft-mtp, n=2 q8_0/q8_0 51.8（代码）/ 43.4（创作） 现行 64K parallel=1 draft-mtp, n=2 q8_0/q8_0 Hermes 长对话 ~50；9/6 短负载 61.7/60.3/44.4
8. 踩过的坑（按杀伤力排序）
-
拿没开 MTP / 多并发 / KV 不量化的配置量了个 27，差点去怪显卡
先问"慢在哪一层"再动手。先开 MTP 看接受率，再谈别的。 -
--reasoning-budget 0关不掉思考链（8192 停机）
网页端把 Qwen3.8 思考默认开到 xhigh，额度全被 <think> 吃光、正文空白。
正解：--reasoning off（+ 可再补 budget 0）。想留思考就把前端 Reasoning 降到 low、预算限 1024~2048。 -
脚本和服务脱节
服务都手动试到 42 t/s 了，磁盘上的脚本还是旧配置。改完必须重启验证日志里的n_slots = 1, n_ctx_slot = 65536，别信"我以为生效了"。 -
presets.ini 段名没对上模型 id → 路由表里多个幽灵条目
段名写[Qwen3.8-27B]，实际模型名是Qwen3.8-27B-Uncensored-Q6_K且没绑 model 路径，结果注册出一个永远 unloaded 的假模型。
要么段名改对并补model = 路径，要么干脆删掉该段（参数命令行已经全覆盖）。验证：启动日志Loaded N custom model presets，N=0 就是没读进去。 -
黑屏一次：NVIDIA 驱动崩溃（已解决）
时间线：nvlddmkm报错 → llama-server 崩溃（0xc0000409）→ 系统 Kernel-Power 41 重启。无 WHEA、无 OOM、30 天仅一次。
判定是驱动/CUDA 与 llama.cpp 的偶发冲突，610.88 → 616.56 清洁安装后未再发生。
复发预案：显卡恢复默认频率电压 → 关 MTP 对照 → 回退驱动 → 上下文降到 49152。别改 TdrDelay，那只是延长挂死时间。 -
模型的"记忆"会污染它自报的硬件
Hermes 长期记忆里残留了旧环境（AMD 7900 XTX / Vulkan）记录，模型照系统提示词念出了错误配置。换机器/改配置后记得清理长期记忆文件。 -
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. 附录：如何自己复现 / 再测
- 改完参数重启，看启动日志：
n_slots = 1, n_ctx_slot = 65536； - 验证实际生效参数：请求
/v1/models，看 loaded 模型的 status.args； - 测速：对着
/v1/chat/completions发三类题（工具 / 代码 / 创作），读返回 timings 的predicted_per_second和draft_n_accepted / draft_n； - 判断标准：接受率 < 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 自己扫。 -
4080 SUPER 32G 跑 Qwen3.8-27B 无审查版(Q6_K) 实测61.7t/s 完整部署与实测指南,自己从27t/s一路调上来的,分享给大家
看到《7900 XTX 跑 Qwen3.8-27B 实测 73.4 t/s 指南》的框架和测速方法论。我也来发一下我的经历，以下都是AI帮我写的
1. 先给结论
项目 结果 硬件 Ryzen 7 9800X3D + RTX 4080 SUPER 32GB + 系统内存 48GB 引擎 llama.cpp b10549（CUDA 后端，router 多模型模式） 模型 Qwen3.8-27B-Uncensored-Q6_K（Q6_K，20.9 GB，27.32B 参数，去审查版） 上下文 64K（模型原生 262K，不需要 YaRN） 工具调用 decode 61.7 t/s（接受率 0.94） 代码生成 decode 60.3 t/s（接受率 0.90） 中文创作 decode 44.4 t/s（接受率 0.53） 真实 Hermes agent 长对话 ~50 t/s（48K 上下文不截断，接受率最高 0.999） 起点 ~27 t/s（没开 MTP、多槽并发、KV 不量化） 一句话：这台机器跑 Qwen3.8-27B 的 Q6_K，短工具/代码题 60+ t/s、长 agent 对话 50 t/s 是常态，64K 全 GPU 加载无 OOM。
速度从来不是"显卡不行"，是我一开始没让草稿头帮忙、还开着一堆互相打架的并发。
2. 名词白话解释（新手先看这区）
名词 白话解释 t/s 每秒生成几个 token。中文大约 1 字 ≈ 1 token。 decode / generation 模型"吐字"阶段，就是你看到字一个一个冒出来的过程。 prefill / prompt processing 模型"读你问题"的阶段，吐第一个字前的那段沉默就是它。 TTFT 按下送出到第一个字出现的延迟。聊天体感主要看它。 量化（Q4/Q6…） 把模型权重压缩：Q4_K_M 约 4bit/参数，Q6_K 约 6bit，文件更大但更准。 KV cache 模型记"前面讲过什么"的缓存，放显存，上下文越大吃得越多。 MTP（投机解码） 模型用一个很便宜的"草稿头"先猜几个字，再用完整模型一次验证；猜对几个就赚几个。 draft acceptance（接受率） 草稿被验证通过的比例。这是本文的灵魂数字——0.9 和 0.3 的速度能差一倍。 n-max（--spec-draft-n-max） 一次让草稿头猜几个字，要自己扫，抄别人的没用。 offload / --fit-target 让多少层上显卡。显存够就全上，留一点余量更稳。 router 模式 llama-server 的新玩法：一个端口管理多个模型、网页里热切换。 YaRN 把模型位置编码外推到超过原生上下文；Qwen3.8 原生 262K，开 64K 根本用不到它。
3. 硬件与软件环境
换一项数字就可能不一样，所以全列出来。
硬件
项目 型号 CPU AMD Ryzen 7 9800X3D（8 核） 系统内存 48 GB GPU NVIDIA GeForce RTX 4080 SUPER 32 GB（不是普通 16GB 版，nvidia-smi 读数 32760 MiB） PCIe Gen4 ×16 显存占用 32K 上下文约 24.5 GB；64K 上下文实测约 26.5 GB / 32 GB，全 GPU 加载 软件
项目 版本 操作系统 Windows 10 Pro 23H2 推理引擎 llama.cpp b10549 / b2e5e9b28（CUDA 后端） 显卡驱动 NVIDIA 616.56（Studio） 模型文件 Qwen3.8-27B-Uncensored-Q6_K.gguf（20.9 GB，Q6_K，无 mmproj）
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逐项为什么这么设：
参数 值 原因 -c65536（64K） 主要用途是给 Hermes agent 当后端。agent 会把 system prompt+工具定义+调用结果+历史持续塞进上下文，32K 容易触发压缩；Hermes 官方对本地模型也建议约 64K。Hermes 的 context_length 必须等于这里的 65536。日常聊天 32K 也够，我上 64K 是给 agent 用的 --spec-type draft-mtp --spec-draft-n-max 2MTP 投机解码 最大提速来源，Qwen3.8 的 GGUF 自带草稿头不用另下模型。n-max 我扫过，2 是本机甜点位（见 §6），别抄帖子那台的 5 --cache-type-k/v q8_0KV 都压到 8bit 32G 显存塞 64K 还有余，两边都给满最稳。如果显存紧，按帖子的结论应该是 K 多给位、V 少给位（K8V4 优于 K4V8），而不是砍 K --parallel 1单槽 多槽会把 64K 上下文和显存切开，互相排队。单用户自用，一槽吃满 --reasoning off --reasoning-budget 0关思考链 血泪教训：只设 --reasoning-budget 0关不掉 Qwen3.8 的思考，模型会把生成额度全花在 <think> 里，表现为"每次都停在 8192 / Reasoning Cancelled"（详见 §7 坑 #2）--fit-target 2048自动分配、留 2GB 让 llama 自己算多少层上 GPU，显存留 2 GB 余量，比手动 -ngl 塞满稳 -n 8192单次生成上限 防失控保险丝。撞到它说明模型复读或没吐结束符，别盲目调大 -t 8CPU 线程 8 核机器。decode 是 GPU 瓶颈，线程数不用拉满
5. 最重要的一节：为什么数字对不上（27 → 51.8/43.4 → 61.7）
同一台机器，同一组参数，换一种测试负载，速度差 40%：
测试负载 decode 草稿接受率 中文散文创作 44.4 t/s 0.53 C++ 代码生成 60.3 t/s 0.90 工具调用（JSON） 61.7 t/s 0.94 为什么？MTP 的速度完全取决于草稿猜得准不准：
- 创作类文字：下一个字有一百种写法，草稿猜不中，接受率掉到 0.5，猜了白猜还倒赔验证成本；
- 代码 / JSON：格式高度固定（
{"name": "get_weather", "arg...后面几乎必然是uments"），草稿一猜一个准，接受率上 0.9，一次前向吐好几个字。
所以"这台机器能跑几 t/s"这个问题本身没有答案，必须先问"跑什么题"。
我最初量到 27 t/s，就是因为既没开 MTP、又多槽并发、KV 还不量化——拿最差的配置量了个数字，然后差点去怪显卡。这和帖主"拿创作题测投机解码、量出最坏情况然后怀疑硬件"是同一类错误。那为什么没到帖子的 73.4 t/s？
三层原因，每一层都是实打实的：
- 量化不同：帖子是 Q4_K_M（15.9 GiB），我是 Q6_K（20.9 GiB）。Q6 每个 token 要多搬约 5 GB 权重，decode 天花板本来就低一截；
- 平台不同：帖子是 AMD 7900 XTX 走 Vulkan，我是 NVIDIA 4080S 走 CUDA，架构和驱动都不同，不能直接比；
- 模型版本不同：帖子是官方 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 字段。负载 题目 decode prefill 接受率 备注 工具调用 "查台积电股价并总结近况"（带 web_search schema） 61.7 t/s 672 t/s 0.939 prompt 301 token，wall 2.4s 代码 C++17 线程安全 LRU cache 60.3 t/s 144 t/s 0.897 prompt 46 token 中文创作 300 字"山中湖泊日出" 44.4 t/s 270 t/s 0.527 和 9/3 历史值 43.4 一致 6-2. 真实 Hermes agent 负载（2026-09-03，读 llama-server slot 日志）
场景 decode 接受率 / mean len 其他 网页长输出（修复思考链前） 50.9 t/s 0.71 / 2.42 撞 -n 8192（当时 reasoning 没关掉）同轮 8207-token prompt — — prefill 1,601–1,712 t/s Hermes 短轮 ~50.7 t/s 0.999 / 3.00 上下文 48,334/65,536、truncated=0 Hermes 上下文压缩后重填 50–53 t/s 0.82 16.5K token 重 prefill ≈1,339 t/s Hermes 长生成 51.0–51.2 t/s 稳定 — 48K 上下文不掉速 结论：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 量化
改动 值 效果 MTP 投机解码 --spec-type draft-mtp --spec-draft-n-max 2提速主力 单并发 --parallel 1、maxModels 2→1资源还给唯一在用的对话 KV 量化 q8_0 / q8_0给上下文腾显存 显存策略 --fit-target 2048自动分配 + 留 2GB 实测：代码 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。
对照表
阶段 ctx 并发 MTP KV 实测 起点 32K 多并发（2 模型槽） 无 f16 ~27 t/s 第一刀后 32K parallel=1 draft-mtp, n=2 q8_0/q8_0 51.8（代码）/ 43.4（创作） 现行 64K parallel=1 draft-mtp, n=2 q8_0/q8_0 Hermes 长对话 ~50；9/6 短负载 61.7/60.3/44.4
8. 踩过的坑（按杀伤力排序）
-
拿没开 MTP / 多并发 / KV 不量化的配置量了个 27，差点去怪显卡
先问"慢在哪一层"再动手。先开 MTP 看接受率，再谈别的。 -
--reasoning-budget 0关不掉思考链（8192 停机）
网页端把 Qwen3.8 思考默认开到 xhigh，额度全被 <think> 吃光、正文空白。
正解：--reasoning off（+ 可再补 budget 0）。想留思考就把前端 Reasoning 降到 low、预算限 1024~2048。 -
脚本和服务脱节
服务都手动试到 42 t/s 了，磁盘上的脚本还是旧配置。改完必须重启验证日志里的n_slots = 1, n_ctx_slot = 65536，别信"我以为生效了"。 -
presets.ini 段名没对上模型 id → 路由表里多个幽灵条目
段名写[Qwen3.8-27B]，实际模型名是Qwen3.8-27B-Uncensored-Q6_K且没绑 model 路径，结果注册出一个永远 unloaded 的假模型。
要么段名改对并补model = 路径，要么干脆删掉该段（参数命令行已经全覆盖）。验证：启动日志Loaded N custom model presets，N=0 就是没读进去。 -
黑屏一次：NVIDIA 驱动崩溃（已解决）
时间线：nvlddmkm报错 → llama-server 崩溃（0xc0000409）→ 系统 Kernel-Power 41 重启。无 WHEA、无 OOM、30 天仅一次。
判定是驱动/CUDA 与 llama.cpp 的偶发冲突，610.88 → 616.56 清洁安装后未再发生。
复发预案：显卡恢复默认频率电压 → 关 MTP 对照 → 回退驱动 → 上下文降到 49152。别改 TdrDelay，那只是延长挂死时间。 -
模型的"记忆"会污染它自报的硬件
Hermes 长期记忆里残留了旧环境（AMD 7900 XTX / Vulkan）记录，模型照系统提示词念出了错误配置。换机器/改配置后记得清理长期记忆文件。 -
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. 附录：如何自己复现 / 再测
- 改完参数重启，看启动日志：
n_slots = 1, n_ctx_slot = 65536； - 验证实际生效参数：请求
/v1/models，看 loaded 模型的 status.args； - 测速：对着
/v1/chat/completions发三类题（工具 / 代码 / 创作），读返回 timings 的predicted_per_second和draft_n_accepted / draft_n； - 判断标准：接受率 < 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 自己扫。--reasoning off
--reasoning off 会变得很傻
-
-
--reasoning off
--reasoning off 会变得很傻
@johnnybegood
真的,但要分场景,不是全面变傻:对复杂推理/精确计算:会变笨。off 只是不让模型先想再答,权重没变,但少了 <think> 自我校验,多步算术容易翻车
对普通问答/创作/常规代码:几乎没差别,甚至更利落。
对 agent/工具调用:off 反而是对的,思考链会把输出预算吃光(你自己 9/3 实测过 8192 全被 <think> 吃掉、正文空白)。
所以正解不是"永远 off"或"永远 on",而是:服务端保持 off(保工具调用稳定),难题按请求临时开思考——请求体加 "chat_template_kwargs": {"enable_thinking": true} 即可 -
@CHAO-WANG 都能玩什么？
@johnnybegood
比如问问一些敏感问题，还有一些黄色小要求啥的，能做的事情很多啊，写个啥爬虫软件等等自己想把，正常模型不让干的他能干。 -
，
T terry 固定了此主题
-
我可以分享我的经验。。。有时候快，也要顾及出品
我试了几个，后来默默还原本来的设定，后来只是增加 至128k, 开启量化kv
我的工具需要产生110k...如果不足，会发生hard block，进行不下去 ，这是我故意的，这个工具我也是从50k 慢慢调教他的良率至110k
期间更换了几个model,他们的model出品都有瑕疵，
hauhau, huihui，llmfan46 全数不过关，就算nvfp4在我的显卡里，能够明显提速，在我的出品里，他不能，就是不能。。。后来才找到唯一的，JonathanColetti，Qwen3.8-27B-Uncensored-GGUF，
执行起来他是最慢的，但是凑合用还是可以
后来我尝试使用上一代qwen3.6 看看出品，上一代缺陷明显，动作不够多，不够细，人物还会漂。。。我做惯视频，我懂我需要什么
所以说真正能够让我本地模型投产的是Qwen3.8 27b
-
我可以分享我的经验。。。有时候快，也要顾及出品
我试了几个，后来默默还原本来的设定，后来只是增加 至128k, 开启量化kv
我的工具需要产生110k...如果不足，会发生hard block，进行不下去 ，这是我故意的，这个工具我也是从50k 慢慢调教他的良率至110k
期间更换了几个model,他们的model出品都有瑕疵，
hauhau, huihui，llmfan46 全数不过关，就算nvfp4在我的显卡里，能够明显提速，在我的出品里，他不能，就是不能。。。后来才找到唯一的，JonathanColetti，Qwen3.8-27B-Uncensored-GGUF，
执行起来他是最慢的，但是凑合用还是可以
后来我尝试使用上一代qwen3.6 看看出品，上一代缺陷明显，动作不够多，不够细，人物还会漂。。。我做惯视频，我懂我需要什么
所以说真正能够让我本地模型投产的是Qwen3.8 27b
-
我可以分享我的经验。。。有时候快，也要顾及出品
我试了几个，后来默默还原本来的设定，后来只是增加 至128k, 开启量化kv
我的工具需要产生110k...如果不足，会发生hard block，进行不下去 ，这是我故意的，这个工具我也是从50k 慢慢调教他的良率至110k
期间更换了几个model,他们的model出品都有瑕疵，
hauhau, huihui，llmfan46 全数不过关，就算nvfp4在我的显卡里，能够明显提速，在我的出品里，他不能，就是不能。。。后来才找到唯一的，JonathanColetti，Qwen3.8-27B-Uncensored-GGUF，
执行起来他是最慢的，但是凑合用还是可以
后来我尝试使用上一代qwen3.6 看看出品，上一代缺陷明显，动作不够多，不够细，人物还会漂。。。我做惯视频，我懂我需要什么
所以说真正能够让我本地模型投产的是Qwen3.8 27b
@imbiplaza-ASUS 感谢大佬分享
-
大佬，这个设置界面是自制的吗？看起来很惊艳，可否分享下？
拜谢！ -
@毅袁 这个是lm studio 原本的设定
@imbiplaza-ASUS 感谢回复，我去研究下
-
我可以分享我的经验。。。有时候快，也要顾及出品
我试了几个，后来默默还原本来的设定，后来只是增加 至128k, 开启量化kv
我的工具需要产生110k...如果不足，会发生hard block，进行不下去 ，这是我故意的，这个工具我也是从50k 慢慢调教他的良率至110k
期间更换了几个model,他们的model出品都有瑕疵，
hauhau, huihui，llmfan46 全数不过关，就算nvfp4在我的显卡里，能够明显提速，在我的出品里，他不能，就是不能。。。后来才找到唯一的，JonathanColetti，Qwen3.8-27B-Uncensored-GGUF，
执行起来他是最慢的，但是凑合用还是可以
后来我尝试使用上一代qwen3.6 看看出品，上一代缺陷明显，动作不够多，不够细，人物还会漂。。。我做惯视频，我懂我需要什么
所以说真正能够让我本地模型投产的是Qwen3.8 27b
@imbiplaza-ASUS 新出了个
DavidAU
/
Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF ， 据说是qwen3.8 智力天花板了， 你去试试呗， 看看怎么样 -
@imbiplaza-ASUS 新出了个
DavidAU
/
Qwen3.8-27B-TURBO-Fable-Cold-Fusion-735-882-Heretic-Uncensored-NEO-CODER-MAX-MTP-GGUF ， 据说是qwen3.8 智力天花板了， 你去试试呗， 看看怎么样
