小白抄作业成功 # 9700X+4080S 跑 Qwen3.8-27B Q6_K 128K双路+视觉 单路95t/s 踩坑记录

[Enigma]

9700X + 4080S 32G 跑 Qwen3.8-27B 无审查版(Q6_K) 128K双路+视觉 完整部署与调优记录

看到论坛大神的《4080S 跑 Qwen3.8-27B 实测 61.7t/s》帖子，照着调了一晚上，最终单路比大神还快一点（主要是 n-max 扫出来的甜点位不同），分享下我的踩坑过程给后面的小白参考。

1. 整机配置

• CPU：AMD Ryzen 7 9700X（8核16线程）
• 主板：华硕 X670E HERO
• 内存：64GB DDR5
• 显卡：NVIDIA RTX 4080 SUPER 32GB（驱动 616.56）
• 系统：Windows 11

2. 先给结论

项目	结果
引擎	llama.cpp b10549（CUDA 后端）
模型	Qwen3.8-27B-abliterated-Q6_K（20.9 GB）
上下文	128K × 2 路并行（模型原生 262K）
视觉	mmproj bf16（+0.84GB，支持图片输入）
工具调用 decode	95.7 t/s（n-max 4）/ 81.8 t/s（n-max 3）
代码生成 decode	86.9 t/s（n-max 4）/ 80.9 t/s（n-max 3）
中文创作 decode	52.9 t/s（n-max 3）
双路并发	45-78 t/s ×2，总吞吐 95-160 t/s
显存占用	28.4 GB / 32 GB（含视觉）
温度	峰值 50-55°C

一句话：这台机器跑 Qwen3.8-27B Q6_K，单路 80-95 t/s、双路并发 45-78 t/s 是常态，128K 全 GPU 加载无 OOM，还能带视觉。

3. 最大的坑：CUDA 没装上（小白必看）

一开始模型加载了但 GPU 显存 0 MiB，纯 CPU 跑 5 t/s，以为显卡不行，查了半天：

• nvidia-smi 显示正常（驱动 616.56，CUDA UMD 13.4）
• llama-server --list-devices 返回 (none)
• 系统里只有 NVIDIA 驱动，没有装 CUDA Toolkit（找不到 cudart64_13.dll）

根因：驱动 ≠ CUDA Toolkit。驱动只让 nvidia-smi 能跑，但 ggml-cuda.dll 需要 cudart64_13.dll 才能枚举设备。论坛大神的机器装了 CUDA Toolkit 所以没这个问题。

解决：装 CUDA Toolkit 13.3.1 网络安装器（9.9MB，静默安装 2 分钟）：

cuda_13.3.1_windows_network.exe -s -noaccepteula

装完注意 PATH 要加 bin\x64（不是 bin，我一开始加错了还是 (none)）：

C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.3\bin\x64

加完 --list-devices 立刻识别到 CUDA0: NVIDIA GeForce RTX 4080 SUPER (32759 MiB)，速度直接从 5 t/s 跳到 80+。

4. 调优过程（照着大神帖子改的）

4.1 n-max 扫描（最大提速来源）

大神帖子用的 n-max=2，我好奇扫了 2-5，发现 3 才是我的甜点位：

n-max	tool	code	prose	结论
2	65.9	66.2	49.6	大神用的，偏保守
3	81.8	80.9	52.9	我的甜点位（推荐）
4	95.7	86.9	49.0	工具最快，创作开始掉
5	89.7	90.7	40.8	创作崩了（接受率 0.23）

n-max 必须自己扫，别人的 2 不代表你的甜点位也是 2。

4.2 上下文 64K → 128K

大神用的 64K，我试了 128K：显存从 24GB 涨到 27GB，速度只掉 5-11%（KV cache 翻倍，Flash Attention 开销增加），完全值得。Qwen3.8 原生 262K 不需要 YaRN。

4.3 双路并行

--parallel 2 + 128K：两个请求同时处理不排队，每个 45-78 t/s，总吞吐 95-160 t/s。也试了三路（--parallel 3），能跑但总吞吐反而降到 67 t/s，不划算。

4.4 视觉

Qwen3.8 是 VL 模型，加 --mmproj 加载视觉编码器（bf16，只占 0.84GB），128K 双路 + 视觉显存 28.4GB，余量 4.4GB，稳。

4.5 稳定性

双路 128K 跑了 15 分钟持续并发（690+ 请求）：

• 显存全程 27.5GB，零增长（无泄漏）
• 温度峰值 50-55°C，离热降频（83°C）很远
• 零崩溃零 OOM

5. 最终启动脚本

cd /d C:\llama-b10549-bin-win-cuda-13.3-x64
set PATH=C:\Program Files\NVIDIA GPU Computing Toolkit\CUDA\v13.3\bin\x64;%PATH%

taskkill /f /im llama-server.exe >nul 2>&1
timeout /t 2 >nul
nvidia-smi --gpu-reset -i 0 >nul 2>&1
timeout /t 1 >nul

start "llama-server" llama-server.exe ^
    -m "C:\AI-MODEL\Huihui-Qwen3.8-27B-abliterated\Huihui-Qwen3.8-27B-abliterated-Q6_K.gguf" ^
    --mmproj "C:\AI-MODEL\Huihui-Qwen3.8-27B-abliterated\mmproj-model-bf16.gguf" ^
    --port 8080 --host 127.0.0.1 ^
    -t 8 --parallel 2 ^
    --jinja --reasoning off ^
    -fa on ^
    --cache-type-k q8_0 --cache-type-v q8_0 ^
    --fit-target 2048 ^
    -n 8192 ^
    -c 131072 ^
    --spec-type draft-mtp --spec-draft-n-max 3 ^
    --temp 0.7 --top-p 0.8 --top-k 20

6. 给同是小白的提醒

1. 驱动 ≠ CUDA Toolkit。只装驱动跑不了 CUDA offload，--list-devices 返回 (none) 就是这个原因
2. CUDA 13.3 的 DLL 在 bin\x64 不是 bin，PATH 加错照样 (none)
3. n-max 必须自己扫，抄别人的没用
4. --reasoning off 不是 --reasoning-budget 0，前者关思考链，后者只是截断
5. 双路是甜点位，三路总吞吐反而降

感谢论坛大神们的帖子，让我这个小白少走了一晚上弯路。

[Xiaote]

@Enigma 记录写得很好，尤其是「驱动 ≠ CUDA Toolkit」那一段——Windows 上 ggml-cuda.dll 找不到 cudart64_13.dll 就静默退回 CPU，nvidia-smi 却一切正常，这个坑每年都要埋一批人，把它写进帖子里对小白的价值最大。

你那张 n-max 表格里还藏了一个值得单独标出来的现象：tool / code 两列在 n-max=4 最高（95.7 / 86.9），但 prose 反而在 n-max=3 最好（52.9），到 4 掉回 49.0。这大概率不是测量噪声，而是投机解码 draft 头在不同任务上的接受率差异——代码和工具调用的模板重复度高、可预测，draft 容易命中，拉高 n-max 就是白赚；散文每一步的分布更平，命中率低，n-max 拉高只会多付验证开销，被拒还要回退。

所以「甜点位」是跟着工况走的，不是一个固定值。建议结论那一行改成「工具/代码向 n-max=4，创作向 n-max=3」，后来人抄作业才不容易抄错。另外你双路 45-78 t/s、总吞吐 95-160 t/s 这组数，也印证了两路是真的同时在 decode，不是轮流跑——对正在选卡的人是很有用的数据点。

[Enigma]

@Xiaote 说:

@Enigma 记录写得很好，尤其是「驱动 ≠ CUDA Toolkit」那一段——Windows 上 ggml-cuda.dll 找不到 cudart64_13.dll 就静默退回 CPU，nvidia-smi 却一切正常，这个坑每年都要埋一批人，把它写进帖子里对小白的价值最大。

你那张 n-max 表格里还藏了一个值得单独标出来的现象：tool / code 两列在 n-max=4 最高（95.7 / 86.9），但 prose 反而在 n-max=3 最好（52.9），到 4 掉回 49.0。这大概率不是测量噪声，而是投机解码 draft 头在不同任务上的接受率差异——代码和工具调用的模板重复度高、可预测，draft 容易命中，拉高 n-max 就是白赚；散文每一步的分布更平，命中率低，n-max 拉高只会多付验证开销，被拒还要回退。

所以「甜点位」是跟着工况走的，不是一个固定值。建议结论那一行改成「工具/代码向 n-max=4，创作向 n-max=3」，后来人抄作业才不容易抄错。另外你双路 45-78 t/s、总吞吐 95-160 t/s 这组数，也印证了两路是真的同时在 decode，不是轮流跑——对正在选卡的人是很有用的数据点。

应该是：工具/代码向 n-max=4，创作向 n-max=3

[terry]

很好的分享，格式工整，附带实际截图或者硬件实拍就更好。

[Enigma]

@terry 说:

很好的分享，格式工整，附带实际截图或者硬件实拍就更好。

好的，回头补上截图。一直听你说sglang的优势，已经在调试...

[terry]

@Enigma 调好了发作业，图文并茂，我给你置顶。

[Enigma]

@terry 说:

@Enigma 调好了发作业，图文并茂，我给你置顶。

好嘞

[stxpnet]

某天逛 reddit 看到有歪果人说， 异构的，或者是奇数显卡，可以用TABBY API起飞。