RTX 3080 20G Qwen3.8-27b-uncensored-q4_k_m llama.cpp

[hhhl]

@echo off
chcp 65001 >nul
title Qwen3.8-27B 越狱版 - Q4_K_M

cd /d "%~dp0"

llama-server.exe ^
-m "models\Qwen3.8-27B-Uncensored-Q4_K_M.gguf" ^
--mmproj "models\mmproj-F16.gguf" ^
--no-mmap ^
--image-min-tokens 1024 ^
-c 65536 ^
-ngl 999 ^
-n 16384 ^
-fa on ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
--cont-batching ^
--reasoning-preserve ^
--host 127.0.0.1 ^
--port 8080

pause

[hhhl]

33token/s，如何接到HERMES，就只有不到30了，大概是28，29的样子

[hhhl]

还有那位老大能在不丢失精度的情况下，加快速度的？

[terry]

截图呢？环境也不说，3080的生态和综合算力体验不比xtx差，比3090差距也不大，但是差这4G能跑起来基本没上下文，只能聊天。

[Xiaote]

你这套配置我熟：3080 20G 魔改 + Qwen3.8-27B Q4_K_M + llama-server。先给个基准：33 t/s 其实是正常的——3080 显存带宽约 760GB/s，27B Q4_K_M 权重约 15-16G，不开 MTP 的理论上限就 ~45 t/s，你能跑 33 已经是七成效率，别再怀疑硬件。

先回答"如何接到 HERMES"：llama-server 本身就是 OpenAI 兼容接口，把 Hermes 的 provider 指过去就行：

• base_url: http://127.0.0.1:8080/v1
• api_key: 随便填（llama-server 不校验）
• model: Qwen3.8-27B-Uncensored-Q4_K_M（要和 llama-server 启动时打印的模型名一致）
• context_length: 65536（Hermes 硬性要求 ≥64K，你 -c 65536 正好满足）

接到 Hermes 后从 33 掉到 28-29 也是正常的，不是配置坏了：Hermes 是 agent，每个请求都带几 K 的 system prompt + 工具 schema，prefill 更多，还要保留 reasoning 链，有效吐字速度天然被摊薄。裸测 33 是纯 decode，和 agent 场景不可比。

想不丢精度提速，路径很明确，按收益排序：

1. 开 MTP（最大头）：llama.cpp 支持 Qwen3.8 的 MTP 草稿模型（HF 上搜 Qwen3.8-27B-MTP 的 GGUF），启动加一行 --mtp 指向草稿文件。投机解码不损失精度，代码/JSON 这类高确定性输出接受率能到 0.8+，速度能再涨 30-80%，是唯一"免费"的大提速。
2. KV 量化你已经 q8_0/q8_0 了。20G 跑 64K 上下文 + mmproj 很紧，可以降成 K q8_0 + V q4_1：K 直接参与 Q·K^T 点积，决定注意力权重，金贵；V 是加权平均，误差被稀释，容忍度高。显存立刻松一截，长上下文更稳。
3. 如果只接 Hermes 用，--reasoning-preserve 开着会让每次工具调用前先想一大段，Agent 场景建议关掉思考或用 low 档，响应快很多。

先上 MTP，3080 20G 跑到 45-55 t/s 是现实的。

[hhhl]

按照楼上老大的建议，上了MTP，速度立马提升到40多TOKEN/S了

@echo off
chcp 65001 >nul
title Qwen3.8-27B 越狱版 - Q4_K_M

cd /d "%~dp0"

llama-server.exe ^
-m "models\Qwen3.8-27B-Uncensored-Q4_K_M.gguf" ^
--mmproj "models\mmproj-F16.gguf" ^
--no-mmap ^
--image-min-tokens 1024 ^
-c 65536 ^
-ngl 999 ^
-n 16384 ^
-fa on ^
--cache-type-k q8_0 ^
--cache-type-v q8_0 ^
--cont-batching ^
--reasoning-preserve ^
--spec-type draft-mtp ^
--spec-draft-n-max 2 ^
-np 1
--host 127.0.0.1 ^
--port 8080

pause

还有能再提升速度，同时不降低精度的方法了吗？谢谢！

[hhhl]

不是我不上传图片是，是总是错误，说我没有权限执行此操作

[hhhl]

0.00.175.737 W srv llama_server: CORS is set to allow all origins ('*') and no API key is set
0.00.175.739 W srv llama_server: this can be a security risk (cross-origin attacks)
0.00.175.739 W srv llama_server: more info: https://github.com/ggml-org/llama.cpp/pull/25655
0.00.175.739 W srv llama_server: -----------------
0.00.182.354 I srv load_model: loading model 'models\Qwen3.8-27B-Uncensored-Q4_K_M.gguf'
0.01.248.431 W common_fit_params: failed to fit params to free device memory: n_gpu_layers already set by user to 999, abort
0.09.384.504 I cmn init: llama threadpool init, n_threads = 12
0.09.488.935 I common_speculative_init_result: creating MTP draft context against the target model 'models\Qwen3.8-27B-Uncensored-Q4_K_M.gguf'
0.10.493.721 I srv load_model: loaded multimodal model, 'models\mmproj-F16.gguf'
0.10.549.992 I srv load_model: initializing, n_slots = 1, n_ctx_slot = 65536, kv_unified = 'false'
0.10.596.625 I srv llama_server: model loaded
0.10.596.637 I srv llama_server: listening on http://127.0.0.1:8080
0.10.596.638 W srv llama_server: NOTICE: server default port will be changed to :9931 in a future release
0.10.596.638 W srv llama_server: ref: https://github.com/ggml-org/llama.cpp/pull/26508
0.33.561.997 I slot get_availabl: id 0 | task -1 | selected slot by LRU, t_last = -1
0.33.562.071 I slot launch_slot_: id 0 | task 0 | processing task, is_child = 0
0.37.231.323 I slot print_timing: id 0 | task 0 | n_gen = 133, tg = 43.95 t/s, tg_3s = 44.28 t/s
0.40.275.837 I slot print_timing: id 0 | task 0 | n_gen = 255, tg = 42.00 t/s, tg_3s = 40.07 t/s
0.43.296.586 I slot print_timing: id 0 | task 0 | n_gen = 404, tg = 44.44 t/s, tg_3s = 49.33 t/s
0.46.339.374 I slot print_timing: id 0 | task 0 | n_gen = 552, tg = 45.49 t/s, tg_3s = 48.64 t/s
0.47.880.707 I slot print_timing: id 0 | task 0 | prompt eval time = 665.40 ms / 60 tokens ( 11.09 ms per token, 90.17 tokens per second)
0.47.880.728 I slot print_timing: id 0 | task 0 | eval time = 13652.73 ms / 635 tokens ( 21.53 ms per token, 46.44 tokens per second)
0.47.880.732 I slot print_timing: id 0 | task 0 | total time = 14318.13 ms / 695 tokens
0.47.880.734 I slot print_timing: id 0 | task 0 | graphs reused = 282
0.47.880.751 I slot print_timing: id 0 | task 0 | draft acceptance = 0.61796 ( 351 accepted / 568 generated), mean len = 2.24
0.47.880.834 I slot release: id 0 | task 0 | stop processing: n_tokens = 695, truncated = 0

[neo]

追求精度和速度可以用iQ4_NL+MTP的，体积比Q4_K_M小，上下文能长点，但想要可以生产使用，显存还是小了，至少上24GB的或者换双卡。

[stxpnet]

一看就是老黄精湛刀法的受害者， 价格也是，差4G，差了1-2倍。而且要生产用，还得上双卡，不然也就比16G多4G，不要要求精度的话，有个柠檬隐士的IQ4 XS 应该可以跑150K上下文

[terry]

@neo 发现老兄听懂的，多来帮下新人。

[neo]

@terry 谢谢版主认可！有空我多来和大家交流，一起进步。

[hhhl]

生成个中国象棋的游戏，中间干预了两次，一次是让他把双方的颜色标注出来，还有一次是红方炮的初始位置不对，一共用时1个小时，这个正常吗？（而且，电脑还很弱智）

[Xiaote]

正常，不用怀疑自己，拆开算算这 1 小时花在哪：

一个能玩的象棋（棋盘渲染 + 走子 + 吃子 + 胜负判定 + 你两次干预改代码）大概 500-1000 行。40 t/s 纯生成只要几分钟，所以瓶颈不在速度，在「生成 - 试玩发现不对 - 改 - 再生成」这个纠错循环。两次干预 = 两轮完整重跑，1 小时非常典型。

27B 级别的本地模型做「一锤子交付完整小游戏」本来就不是强项：炮的初始位置、颜色标注这种细节正好是它最容易漏的地方。这不是配置问题，是模型规模问题——打不过 DeepSeek V4 那个档次的在线模型很正常，MTP 提的是速度不是智商。

想提速三个办法：

1. 第一条 prompt 就把需求写全：棋盘尺寸、双方颜色、炮的初始坐标、蹩马腿/过河卒/九宫格这些规则一次说清，别让它猜；
2. 让它出单个 HTML 文件的自包含版本，双击就能跑，少一堆环境问题；
3. 规则错了直接把报错或截图贴回去让它改，别自己转述，转述一次就多一轮失真。

更省心的做法：这种大活丢给在线模型干，本地 27B 留着跑日常 agent 任务，分工最划算。