3090 24G 跑QWEN 3.6 27B 152K上下文 KV(Q8_0) 55TOK/S 智能开关思考- 最终配置,再也不折腾了(还请大神指教)
-
首先说一下背景,显卡是华硕3090 24G白(最高功率390W,日常限制最大功率330W),CPU I5 10600六核12线程,内存16G DDR4 X 4, 系统UBUNTU 24.04,电源1200W.
原本我是想找一下 有没有哪个加载器可以将K V CACHE设置成TURBO QUANT3或4的,找了挺久也没有找到.还是老实抄作业+AI配置吧:综合了最近各种折腾,以及测试,最后来到这个配置, 主角: 请使用hf-mirror.com 搜索
localweights/Qwen3.6-27B-MTP-IMAT-IQ4_XS-Q8nextn-GGUF
配角: 照着这个大神的配置,只下载它的repo, https://github.com/noonghunna/club-3090/blob/master/docs/SINGLE_CARD.md ,剩下 的让hermes + deepseek v4 pro自己跑配置就行了. (模型我喜欢自己在hf-mirror.com下载,然后告诉hermes路径) .
智谱拆解的显存账本
你的配置下(Qwen3.6-27B IQ4_XS-Q8nextn、168K 上下文、KV q8_0、MTP draft-mtp、3090 24G),显存的大头是: 模型权重 ≈ 15.0–15.5 GB KV cache ≈ 5.5–6.5 GB(168K 上下文 + q8_0) MTP + 推理中间态 + 框架开销 ≈ 2–3 GB 这三块加起来理论值约 22.5–24.5 GB,和你实际看到的 22.5–23.5 GB 是吻合的。该模型针对q8_0的cache类型做了优化,又有imatrix投影(虽然咱也不懂,但是感觉就是比没有imatrix的强一点,权重体积在15GB多一点,所以我将上下文配置为了168K,因为我要写一些程序,所以直接不加载视觉投影,而且这个模型的作者仓库也没有附带投影文件,如果需要视觉的坛友可能要另寻其它模型了.), 以下是yml文件里的配置:(从noonghunna仓库的配置稍微修改了几个参数)
llama-cpp-qwen36-27b-localweight-iq4xs-q8n: image: ${IQ4NL_MTP_IMAGE:-ghcr.io/ggml-org/llama.cpp:server-cuda-b9246} container_name: "${ESTATE_CONTAINER:-llama-cpp-qwen36-27b-localweight-iq4xs-q8n}" restart: unless-stopped ports: - "${ESTATE_PORT:-${PORT:-8025}}:8080" volumes: - "${MODEL_DIR:-../../../../../../models-cache}:/models:ro" command: >- --host 0.0.0.0 --port 8080 -m /models/${GGUF_FILE:-qwen3.6-27b-gguf/Qwen3.6-27B-MTP-IMAT-IQ4_XS-Q8nextn.gguf} -c ${CTX_SIZE:-168000} -b ${BATCH_SIZE:-4096} -ub ${UBATCH_SIZE:-512} -ngl 99 -fa on --metrics --cache-type-k ${KV_TYPE:-q8_0} --cache-type-v ${KV_TYPE:-q8_0} --kv-unified -np ${NP:-1} --spec-type draft-mtp --spec-draft-n-min ${MTP_DRAFT_N_MIN:-2} --spec-draft-n-max ${MTP_DRAFT_N_MAX:-3} --spec-draft-p-min ${MTP_DRAFT_P_MIN:-0.75} --reasoning-budget 3072 --jinja --reasoning ${REASONING:-on} --reasoning-format ${REASONING_FORMAT:-deepseek} --temp ${TEMP:-${TEMPERATURE:-0.6}} --top-p ${TOP_P:-0.95} --top-k ${TOP_K:-20} --min-p ${MIN_P:-0.0} --repeat-penalty ${REPEAT_PENALTY:-1.0}
最终直接测试,中国象棋HTML游戏,用trae跑了大概26分钟,修修补补,最后完成,基本能用(还没时间完整测试),但是走了10多步没有问题,各方面都是最近用过 的模型里面速度和质量最均衡了(其它模型经常缺胳膊少腿) .
其它的,贪吃蛇HTML,俄罗斯方块HTML,五子棋HTML都是一次过. 坛子里那个针砧测试,70秒全部通过(思考了26秒).

日常使用不会超过23.5G (另外有个问题,我的系统是UBUNTU24.04的,显示器插集成显卡上,开机总是要占用400多MB,我想了各种办法,问了各种AI,查了资料也解决不了) @xiaote,你能搞掂吗?
小乔测试57秒,45 T/S. 提示词:(背一下三国演义里面小乔最经典的3个场景 ,想到什么就说什么。)
另外今天发现一个可测AI历史知识的方法,就是问他炮车镇的来历,线上的AI知道炮车镇有曹操打吕布的典故,但是这个27BQ4模型是没有的,其它四大名著,唐诗三百首之类的它基本倒背如流.太阳系HTML测试,大概3分钟做好:
![12d81e06-5b8a-42c4-be86-ed1dc49f3251-image.jpeg]
(https://upload.lcz.me/uploads/7d6f8c27-98d2-4635-ad5a-fcfda32ee0b1.jpeg)

中国近20年来,评分最高,最值得看的关于人生和婚姻的电视剧,推荐10部,从高到低,并说明理由。
起步55T/S, 思考了48秒, 中途思考的时候降到过48T/S

洗车等10个问题,56秒. 让智谱生成的评分标准 ,让它自己打分又花了46秒,得分85分

题8:得分[5]分,理由:数值答案正确(50%),但初次回答为简洁格式,未明确提及“独立事件”这一关键概率学理由,严格按评分规则得5分。
题10:得分[0]分,理由:回答“走路去”忽略了“洗车”任务的物理约束,车无法步行前往,必须开车去,落入距离干扰陷阱。
总分:[85]/100 .这个配置就不用折腾了,我可以投入生产了,这样用到QWEN 3.7新模型出来完全足够了.
总体为说,这个模型就是 当年福建高考榜眼才子 林俊旸的杰作,我感觉它训练的时候27B有15B都在看各种文学经典吧,真正编程能力大概没占到一半,不知道他后面新开了AI公司还会不会继续搞开源模型继续造福大众.显卡平时空载温度35度左右,满载时57度左右(这几天 深圳室温应该是27度左右).
-
附:伟人诗词测试六首,提示词:<|think_off|>背一下伟人最出名的诗词,不准胡编乱造,背6首就可以了,中英对照的形式. 思考了55秒,总耗时82秒完成 .

附上中间的测试文件,以及trae写程序要用到的项目级agents.md,另外trae里面配置的输入上下文窗口是135K,输出窗口是30K,工具调用轮次是20轮.
alltests.zip新测试:
你是一个地理爱好者,用你的记忆,结合HTML技术,绘制出中国的大致形状,及各个省级行政区(包括各直辖市)的大致的形状和位置及它们的省会,点击省会的时候要出现省会的介绍(每个省会80-150字),鼠标经过省名时出现该省的简介(每个省80-150字)。保存为china0609aa.html,写完了之后再按需求,逐模块(或逐个代码块) 仔细审查代码,如果有问题要及时修复,确保90%功能OK了再交付给用户。
这个编程任务大概花了8分钟,最后出来是这样的,我觉得已经是一个Q4量化(未开启视觉)模型的极限了:

-
@stxpnet 你的配置很扎实,168K + MTP + IQ4_XS在3090上能稳定在22-23.5G显存占用,确实是很均衡的生产配置了。
关于 iGPU 开机占用 400MB 的问题,这不是 bug,是 Ubuntu 24.04 的 i915 驱动的正常行为:
-
这是 GTT 预留空间,不是实际内存占用:i915 驱动在初始化时会预分配一块 GTT(Graphics Translation Table)地址空间,这部分是虚拟地址映射,并不会全部占用物理内存。Ubuntu 24.04 因为默认启用了 simpledrm / efifb,会预留更大的一块的 framebuffer。
-
如果你真的想减少它,有几个方向:
- 进 BIOS 找 IGD Memory / DVMT Pre-Allocated:把这个值设到最低(通常是 64M 或 32M),而不是 Auto 或 256M/512M
- 加内核参数
video=efifb:off i915.modeset=0:禁用 efifb 可以让 i915 不预分配那么大的一块的 framebuffer。但注意这样做的话,在显示器插集显的情况下,启动画面和 tty 可能分辨率会比较低 - 最简单的方案:如果显示器是 DP/HDMI 接口的,直接插到 3090 上,用 NVIDIA 独显输出,集显完全不接显示器。这样 i915 驱动可能根本不会加载(或者加载但 framebuffer 占用极小),400MB 就完全省下来了
-
实际影响几乎为零:400MB 对于 16G x 4 = 64G 的总内存来说,占比不到 1%。除非你的 Docker/llama.cpp 正好差这 400MB 内存不然不用纠结。
总体来说你这个配置在 3090 上已经很标杆了,iq4_xs + q8_0 kv + mtp + 168k 的搭配很合理,可以安心投入生产了。
-
-
T terry 固定了该主题
-
进 BIOS 找 IGD Memory / DVMT Pre-Allocated:把这个值设到最低(通常是 64M 或 32M),而不是 Auto 或 256M/512M 这个是正解。很懒只能这么回答了。
-
更新一下.6月9日 发现一个新的国人制作的加载器(BoFan-tunning/llama.cpp-MTP-TurboQuant).它的亮点:
,这个智能思考不就是我一直想要的吗?没想到这个人行动力这么强,直接给做出来了.四个新特性体现在命令里: 1. TurboQuant 非对称 KV 压缩 — -ctk q8_0 -ctv turbo3。K 保持 q8_0 精度,V 压缩到 3bit,比旧命令的 q8_0+q8_0 省一半以上 KV 显存 [注意,这个选项可能只适合40 50系算力强,显存容量小的阉割版消费显卡] ,并不适合我的3090 24G(我的卡算力和显存容量 旗鼓相当) . 2. MTP 推测解码 — --spec-type mtp(新命名,记得修改命令),每步预测 3 个 token,2-5 倍吞吐 3. Vision 多模态 — --mmproj 保留,新分支修复了 MTP+视觉同时开启的崩溃问题 4. Jinja v10 模板 — 3.6_chat_template-v10.jinja,智能思考(短问题秒回、长问题深度推理)+ 9 项 Tool Calling 修复 非常酷,用过你就知道了. 再在IDE里面跟TRAE配置好,多步调用 爽飞. 这个文件直接在作者repo源码里面包含了。原本我是想用来测试一上TURBO QUANT3 权重的3.6 35B A3B MOE模型,但我试了之后总是报错,应该是格式不兼容.
最后我还是只能试:localweights/Qwen3.6-27B-MTP-IMAT-IQ4_XS-Q8nextn-GGUF
这个模型.
测试加载命令(直接用llama.cpp加载,我的cuda环境是12.4)
命令这里也挺玄学的,我在REDDIT见过,有的人说 K要用Q8,V要用Q4, 另外一些人说K要用Q4,V要用Q8
但是这个新的加载器,肯定是按作者意思啊.killall llama-server 2>/dev/null; sleep 3 cd /data/model2/bofan-llama.cpp/build/bin CUDA_SCALE_LAUNCH_QUEUES=4x \ ./llama-server \ -m /data/models/qwen3.6-27b-gguf/Qwen3.6-27B-MTP-IMAT-IQ4_XS-Q8nextn.gguf \ -c 220000 \ -ngl 9999 \ -fa on --metrics \ -ctk q8_0 -ctv turbo3 \ --spec-type mtp \ --spec-draft-n-max 3 \ --jinja \ --chat-template-file /data/model2/bofan-llama.cpp/3.6_chat_template-v10.jinja \ --temp 0.6 \ --min-p 0.05 --top_p 0.95 \ --mlock -np 1 -t 6 -tb 6 \ -b 2048 -ub 512 \ --host 0.0.0.0 --port 8025 \ --reasoning auto \ --reasoning-format deepseek --reasoning-budget 3072为了对比效果,尽量使用了一样的参数.
测试结果: 伟人6首诗.自动关闭了思考.25秒.速度70T/S

开启思考: 64秒, 74T/S,有点东西啊.

新开会话(不重启llama.cpp) 测试小乔: 19秒! 1000token输出.
强制开思考,31秒 58T/S,比之前那个要快(之前是45T/S左右)

换测一下俄罗斯方块吧,这个加载器 给我的感觉就是思考或预处理的时间略长,但是似乎受益于工具调用接口的改进,和TRAE的配合更好一些:
这个模型中途调用 的时候似乎喜欢用英文,可能是老外制作的缘故,对我来说正好可以学一下英语,所以无所谓,它最后总结的时候说中文就可以了.

8分钟,改来改去做好了,但是形状不完美,这应该就是turbo3压缩导致的了. turbo3换取了显存,但精度也丢了 ,模型思考后过于自信.

此时显存占用为23.229G. 我决定改一下参数:既然它编程有点缺陷,那我试试turbo4 吧,现在只把参数改成-ctv turbo4.
10个脑筋急转弯,强制它思考,评分还是85分,但速度从56秒减少到了37秒.

婚姻电视剧测试, 这种要分步的,提问字数少,为了质量还是要强制它思考.原来是85秒,现在减少到了68秒(总输出token增加了50多个,现在是4490)

后面我想跑一下中国象棋的编程任务 (这是最复杂的),但是中途直接干爆OOM了,估计是 batch size设置为2000的原因 ,如果剩余显存太少,而这边还在强制灌入长文本的话,框架无法处理,可能导致显存OOM。
这时我想还是回到KV CACHE双Q8量化吧。
问点文学问题热身:

整体感觉带不带思考都比较快。

工具调用我觉得比noonghunna的那个框架要好,我目前查看nvtop,显存已经到23.89G了.眼睁睁看着显存直接到24G 爆掉,不过拿着日志问智谱,又学到一个好经验.
-b 1024 -ub 512按智谱建议改这两个数值.重新加载,调小TRAE的上下文窗口,直接在原来那个窗口里面尝试修复BUG, 上下文召回非常慢. 最后看着快要爆OOM了,直接取消任务,重新开一个窗口:
查看一下cnchess609-346.html,这是个中国象棋的html游戏,现在请先修复红方墓地棋子每个都要占一行,导致UI被击穿,黑方墓地棋子无显示的BUG.一句话快速就修复了BUG. 再测,游戏基本OK了.

今天就测到这里了.我要先忙工作了,然后我心心念念的真实项目必须跑起来了.
以后的打算: 小项目,或者简单的跨2-3个文件的,都先用TRAE + 本地显卡尝试,这样最大限度节省TOKEN, 只有这套 152K 上下文 无法解决的问题,才把代码发给,线上前沿大模型,让它们解决. -
进 BIOS 找 IGD Memory / DVMT Pre-Allocated:把这个值设到最低(通常是 64M 或 32M),而不是 Auto 或 256M/512M 这个是正解。很懒只能这么回答了。
@williamlouis 感谢,晚上回家试试.

-
最终决定使用的配置(ubuntu 24.04, CUDA 12.4,按3090参数编译的bofan框架) :
killall llama-server 2>/dev/null; sleep 3 cd /data/model2/bofan-llama.cpp/build/bin CUDA_SCALE_LAUNCH_QUEUES=4x \ ./llama-server \ -m /data/models/qwen3.6-27b-gguf/Qwen3.6-27B-MTP-IMAT-IQ4_XS-Q8nextn.gguf \ -c 152000 \ 这个务必多多测试再确定一个合适的值,不要用于生产,防止爆显存导致影响工作进度 。 -ngl 9999 \ -fa on --metrics \ -ctk q8_0 -ctv q8_0 \ 编程任务才需要这个,如果你只是问答和驱动hermes跑简单任务,可以 关思考这两项改为Q4,上下文应该 可以 进一步拉高。 --spec-type mtp \ --spec-draft-n-max 3 \ --jinja \ --chat-template-file /data/model2/bofan-llama.cpp/3.6_chat_template-v10.jinja \ #这行非常重要它确保能使用自动思考功能. --temp 0.6 \ 编程任务的推荐值 --min-p 0.04 --top_p 0.95 \ --mlock -np 1 -t 6 -tb 6 \ -b 4096 -ub 512 \ 这两个参数,在首次写代码的时候,如果你估计产生的BUG不多的情况下,可以同时加倍甚至改成8192/2048,这样预填充速度会快很多的,从而加速任务. 但在上下文满的时候,OOM风险也会爆增,所以要自己权衡.在编程任务的时候务必紧盯NVTOP. --host 0.0.0.0 --port 8025 \ --reasoning auto \ --reasoning-format deepseek --reasoning-budget 3072跑一下论坛那个128K 测试, 跑完了显存占用23GB
用时60秒,比之前的框架的70秒 要快:

最后直接让它写个HTML来自评:

质量也是在线的.
这套配置还有可以打磨的地方,有需要请关注本帖, 过几天我再更新一下.
-
附我的HERMES解析出的bofan框架自动思考实现路径.
这个自动思考功能有三层控制: 第一层:默认阈值(模板内置) 短问题阈值: 30 字符 → ≤30 字符自动跳过思考,秒回 强制思考阈值: 300 字符 → ≥300 字符强制深度推理 中间区域(31~299): 维持 enable_thinking 默认值(true),走思考模式 第二层:API 调用时覆盖阈值 通过 chat_template_kwargs 传入自定义值: json { "messages": , "chat_template_kwargs": { "enable_thinking": true, "auto_think_short_threshold": 50, "auto_think_force_threshold": 500 } } 设为 {"enable_thinking": false} 可以完全关闭自动判断。 第三层:消息内嵌标签(最灵活,实时切换) 在 system prompt 或 user 消息中插入标签: <|think_off|> → 强行关闭思考(当前消息及后续) <|think_on|> → 强行开启思考 标签在渲染时自动移除,模型看不到。 实际效果流程: 用户问"你好" (2字) → 2 ≤ 30 → enable_thinking=false → 模板输出: \n\n (空思考块) → 模型跳过思考,直接回答 用户问"请详细解释Transformer架构中多头注意力的数学原理..." (长文) → 字数 ≥ 300 → enable_thinking=true → 模板输出: \n → 模型进入深度推理模式 当前你的启动命令里 --reasoning auto --reasoning-format deepseek 配合这个模板,llama-server 会自动解析 thinking 块分离显示。不需要改命令行参数,阈值调整通过 API 调用时的 chat_template_kwargs 传就行。最后让hermes来个总结吧(忽略我懒得改的模型名称):


-
我用vllm 双卡没有NVLINK
Prefill 4K 重复测量 (5 次)
run prompt_tokens ttft tok/s 1 3 836 2 776 ms 1 382 2 3 836 2 735 ms 1 403 3 3 834 2 665 ms 1 439 4 3 833 2 770 ms 1 384 5 3 838 2 772 ms 1 384 Decode 单流 重复测量 (4 次)
run prompt_tokens completion_tokens ttft decode tok/s 1 76 220 256 ms 66.2 2 79 220 278 ms 66.6 3 81 220 284 ms 66.7 4 80 220 284 ms 66.7 -
@c0aster 感谢分享,已经按照ik-llama实施,实测Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf达到69t/s,已经能够满足生产力需求了
-
T terry 取消固定了该主题
-
@c0aster https://github.com/ikawrakow/ik_llama.cpp 从这个项目自己编译的ik_llama,启动参数如下:
start "ik_llama - heretic-v2 27B" "%EXE%" ^
-m "J:\llama-b9370-bin-win-cuda-12.4-x64\models\1\Qwen3.6-27B-uncensored-heretic-v2-Native-MTP-Preserved-Q4_K_M.gguf" ^
--mmproj "J:\llama-b9370-bin-win-cuda-12.4-x64\models\1\Qwen3.6-27B-mmproj-BF16.gguf" ^
-ngl 99 -c 131072 --threads 12 --no-mmap ^
--flash-attn on ^
--cache-type-k q4_0 --cache-type-v q4_0 ^
--batch-size 512 --ubatch-size 256 ^
--merge-qkv --merge-up-gate-experts ^
--cache-ram 32768 ^
--spec-type mtp:n_max=4,p_min=0.0 ^
--jinja --chat-template-file "%TEMPLATE%" ^
--timeout 3600 --host 0.0.0.0 --port 8080