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
逐项为什么这么设：
| 参数 | 值 | 原因 |
|---|---|---|
-c |
65536（64K） | 主要用途是给 Hermes agent 当后端。agent 会把 system prompt+工具定义+调用结果+历史持续塞进上下文，32K 容易触发压缩；Hermes 官方对本地模型也建议约 64K。Hermes 的 context_length 必须等于这里的 65536。日常聊天 32K 也够，我上 64K 是给 agent 用的 |
--spec-type draft-mtp --spec-draft-n-max 2 |
MTP 投机解码 | 最大提速来源，Qwen3.8 的 GGUF 自带草稿头不用另下模型。n-max 我扫过，2 是本机甜点位（见 §6），别抄帖子那台的 5 |
--cache-type-k/v q8_0 |
KV 都压到 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 8 |
CPU 线程 | 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 自己扫。