如果你用的是Ubuntu 22.04 / kernel 5.15，设置说明：
该模块为6.16+编写。5.15版本需要两个小修复：为Linux/Aperture.h做一个存根，以及在检查前把显卡切换到D0（GPU解锁问题#3中的修复）。
initramfs-tools在加载模块前运行了udev，所以Nvidia先抓卡，模块什么都不做。我改用初始化顶脚本加载它，这样它总是先于udev运行。
Sudo重启不够，显卡保留电源。关机，再开机。请查看journalctl -k -b |Grep gpu_unlock，你希望每张卡牌只“解锁一次”。
https://github.com/Zagitta/gpu-unlock
https://github.com/noonghunna/club-3090/issues/1755
预填充快了10%-15% 左右。 本地AI爆发的红利，还在增加！
首先说一下背景,显卡是华硕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 搜索
https://huggingface.co/Jackrong/Qwopus3.6-27B-Coder-MTP-GGUF
快速测试的话，看我文末评论所用参数，如果要稳定可以使用noon的 镜像。
配角: 照着这个大神的配置,只下载它的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度左右).
本来还想再多测几天再发帖的，但今晚实在兴奋得睡不着，干脆先把这套配置分享出来给同好们抄作业。经过几天折腾，终于在 HuggingFace 上找到了一个真正适配 24G 显卡长上下文场景的 MTP 模型，配合华为 KVarN KV 缓存量化和 Beellama 分支，把 3090 这块"24G 尴尬卡"压榨到了一个我自己都没想到的程度。
一句话结论
在 RTX 3090 24G 上，用 Qwen3.6-27B-smol-MTP-IQ4_NL.gguf + Beellma（6月16日编译版）+ KVarN K6/V5 KV 量化 + MTP n=3 推测解码，可以稳定撑起 168K 上下文，生成速度稳在 55 T/s 左右、接受率 70–80%，显存占用 22G 出头，编程实测可用度相当能打。
🧠 关键洞察：1. MTP 头的量化等级才是 24G 的命门
折腾了一圈带内置 MTP 的模型后，我发现一个被大多数人忽略的点：
大多数内置 MTP 的模型，注意力头（draft head）的量化控制都拉胯，尤其是那些 15G 以内的版本。
很多作者为了让模型在 16G 显卡上跑 32K 上下文、刷个分、发个推，根本没考虑真实长上下文需求。这类模型一旦上下文推到 80K–90K 之后，速度就会断崖式掉到 20–30 T/s——原因正是它们的 MTP 头也是 Q4 以下量化的，长上下文下 draft 质量崩了，接受率雪崩，推测解码反而变成累赘。
而这次找到的这款模型（作者 IHaveNoClueAndIMustPost），在模型卡上明确写明了"适配 131K 上下文的 24G 显卡，根据 KV 量化等级可增减"。目测它的 MTP 头应该是 Q6 级别的，这点至关重要！
24G 显卡的尴尬就在这里：
MTP 头选 Q8 → 占用偏大 → 没地方放高质量 KV Cache
MTP 头选 Q4 以下 → 短上下文看着快，长上下文接受率崩盘
Q6 级别的 MTP 头 + KVarN 量化的 KV Cache，是我目前试下来 24G 卡上最平衡的组合。
3.beellama 后期可能会由于 显存不足而产生 将Checkpoint 在显存与内存之间疯狂腾挪，直观的感受就是速率直降，如果你不想这样，那请加--cache-ram 0 （后果就是旧的检查点被覆盖，直接“失忆”，无法很好的完成工作！）
️ 环境与启动参数
硬件/软件：
GPU：RTX 3090 24G
CUDA：12.4（nvcc --version 确认）
推理后端：Beellma 3.2 预览版，6 月 16 日自编译版本（选它唯一的原因：支持华为 KVarN KV Cache）
模型：ubergarm-Qwen3.6-27B-smol-MTP-IQ4_NL-ihavenoclue.gguf（约 17G，Q4 级）
KV Cache：K = kvarn6，V = kvarn6，统一模式开启
6-22 上午最佳编程配置：
killall llama-server 2>/dev/null; sleep 3
/data/model2/beellma616-kv.cpp/build/bin/llama-server
-m /data/model3/ubergarm-Qwen3.6-27B-smol-MTP-IQ4_NL-ihavenoclue.gguf
-ngl 9999 --props
-fa on --metrics --ctx-size 168000 -n 16000
-ctk kvarn6 -ctv kvarn6 --kv-unified
--spec-type mtp --spec-draft-n-max 3
--jinja --no-mmap --mlock -np 1 -b 2048 -ub 512
--host 0.0.0.0 --port 8025
--reasoning off
--chat-template-kwargs '{"preserve_thinking":true}'
--reasoning-format deepseek --reasoning-budget 1024
--chat-template-file /data/model2/qwen3.6-27b-gguf/chat_template-Carnice27B-MTP-opt-v2.jinja
--temp 0.62 --top-k 20 --top-p 0.95 --min-p 0.05 --repeat-last-n 128
几个关键参数的取舍说明：
参数 取值 作用与取舍
-ctk kvarn6 -ctv kvarn6 K=6bit / V=6bit 华为 KVarN 方差归一化量化，长上下文下精度接近 Q8_0，显存压缩 3–5 倍
--kv-unified on K/V 统一缓冲，减少调度开销
--spec-type mtp --spec-draft-n-max 3 MTP n=3 每步预测 3 token，实测接受率 70–80%，再高接受率掉得明显
-b 2048 -ub 512 逻辑/物理批 偏保守以保证显存稳定，后续可试 ub=1024 提升预填充
--reasoning off --reasoning-budget 1024 关思考+预算 1024 编程任务关掉思考链更稳，避免 harness 冲突
--temp 0.62 --top-k 20 --top-p 0.95 --min-p 0.05 Qwen 推荐采样
🧪 实测三连：中国象棋 / 俄罗斯方块 / opencode 长上下文
测试一：中国象棋 HTML（多文件工作流）
一上来直接挑战老项目。这几天我已经把提示词改成多文件模式，明确禁止 AI 一次性生成单文件——这项目跑 MVP 也要 1500 行左右，单文件很容易卡死。
我没指望这个 Q4 的 17G 模型有多惊喜，所以没计时间就去洗澡了。洗完回来发现它还在自动调试，工具调用依然不完美。手动停掉、修了几个 JS 错误后，双机对战还是不能用，放弃。
毕竟是 Q4 的 17G 模型，不能期望太高。之前测这套提示词，只有 Qwopus-coder 27B 的表现最完美。
测试二：俄罗斯方块单文件（TRAE）
再在 TRAE 里测俄罗斯方块单文件，两分钟就完成了。让它修复 JS 错误后基本无错运行，TRAE 版 890 行。
测试三：俄罗斯方块单文件（opencode，本地模型）
同样提示词丢给 opencode，明确让它不要用在线模型。结果它用了 10 分钟左右、耗用 50K token，直接无错运行，opencode 版 850 行。
测试四：中国象棋（opencode 长上下文压测）
️
再让 opencode 跑中国象棋。此时任务 ID 已经到 19000 多了，拉到最上面只能看到 9000 多的。预填充速度已变为 1300 MB/s，说明旧的检查点已被弃用。
跑了一会儿后，opencode 的上下文到了 30 多 K tokens。约 12 分钟时，168K 上下文开始翻转，日志大量删除、重建 KV Cache——KVarN 在长上下文翻页时的表现比 Q4_0 平滑很多，没有出现明显的速度塌方。
到收尾整合阶段，opencode 思考得有点多，任务 ID 涨到 28000，速度降到 45 T/s。在这里它绕了 10 分钟才到最后一步——Qwen 这个配置的"智商"和 opencode 内置的 harness 应该产生了冲突，棋子位置都是错的。打断、让它上网查标准棋盘布局，还是做不好，只能放弃，让它做交接总结。
做完差点撞到 168K 上限，好险！这也说明这套配置的长上下文承压能力是真实的，不是跑分跑出来的。
性能与显存数据
指标 数值
显存占用 22G 出头（ub 不激进时可稳定，大胆点能压到 23G）
稳定生成速度 ~55 T/s
后期降速 ~45 T/s（上下文翻页 + 任务 ID 2.8 万时）
MTP 接受率 70–80%
预填充速度（缓存失效后） ~1300 MB/s
上下文翻转 约 12 分钟触发一次 KV Cache 重建
观察：填充率略偏低，如果把 -ub 从 512 改到 1024 应该有改善，下一步会试。
已知不足
这条提示在工具调用时会反复刷。问过 Gemini，查找的结论大概是建议用 --peg 参数处理 lazy grammar 与 raw tool marker 的冲突，但 Beellma 没有 --peg 这个参数。而我必须用 Beellma 的原因是它支持华为 KVarN KV Cache，这是硬需求，只能无奈放弃这个修复。
这套 chat_template-Carnice27B-MTP-opt-v2.jinja 是英文模板，IDE 里的思考过程、解释全是英文。如果能汉化就完美了。不过对我来说倒无所谓，正好练英语。有能力的同学可以基于它做个中文版 jinja 分享出来。
- CPU：AMD EPYC 7B13（米兰 Zen3，64核128线程，2.25/3.5GHz，谷歌定制U）
- 主板：技嘉 MZ32-AR0（E-ATX，SP3，4×PCIe 4.0 x16）
- BIOS：M31（2026-01-16，原生支持 Milan）
- 内存：16×16GB DDR4 ECC RDIMM（镁光，共256GB，8通道满插2DPC，实跑2133 MT/s）
实测约83G/S 速率.
- 显卡：2×RTX 3090 24G（驱动 615.71.09，开源内核模块+P2P补丁）无nvlink CPU可支持128通道（已为未来另外两张卡预留通道）
- 散热：金钱豹 M98PRO 双塔（6热管双滚珠双扇，SP3）
- 电源：长城 2600W 黑匣子
- 形态：开放式矿架（主板平放下层 + 双卡Gen4延长线上层）
- 系统：Ubuntu 26.04 LTS（内核 7.0.0-30）
刚升级主板和CPU，最想测试的莫过于这个模型了。
权重就要129G的,框架是glm 5.3 flash按作者主页下载的镜像. 按作者的建议，配置了64GB的NVME SWAP。（这张NVME盘性能不行，如果换4.0 3500MB/S的NVME效果还会好点）
（显卡在旧平台上面，外置那张开机，推理调用多了电源接口会爆灯，原因不明。到了新平台目前单卡限制230W，防止尖峰时电源无法稳定供给导致显卡供电接口爆红灯）
目测温度比3.8 27B高多了，可能不会当作 日常主力。(也不想跑完整的tool-eval测试）
内存要吃128G.(可能利益于富裕的总内存，交换文件并未被使用)
让hermes调用写骑自行车的html(这次nvtop温度较为正常了,平均60度上下）
效果比之前测的qwen 3.8 27B要好。
这里显示的也并非真实速度，目测平均速度在50-60t/s 以上，日常 使用已经足够了,但未达到作者所说的100t/s。
下面离线测试模型的文学能力(题目是四大名著里面随机的，所以模型没得作弊，
以前测试过QWEN 3.6，感觉它们会取巧，老是选择它们自己熟悉的章节。 如果先让它选两个随机数，可以防止它们作弊) ：
生成题目用了144秒。 把生成结果复制给智谱清言让它判分：
最后测试多风格俄罗斯方块HTML游戏：
最小思考12分钟无错生成，比QWEN 3.8 27B强一些，但是没有什么亮点。
总体来说，让我意外的：
qwen 3.8 flash next对CPU的需求似乎不高，但对主板双卡之间的连接性要求较高。跑满各自的带宽才能发挥显卡的最大价值。
5天下载量约74K。
号称综合分数超越原版，根治雷霆思考。
我看它的形态和noonghunna 的ultrafast档位差不多，所以直接套用那边的启动参数，把模型换成这个。 KV缓存采用INT8量化，双并行，每槽188K上下文. 总可用约400K上下文，但我没有跑完过。
单流的时候每张显卡各占用21.5G左右。
用来跑我的报表任务，比以前快了2倍，质量没有下降：
都是单个不到10K TOKEN的任务，所以能爆发峰值 160t/s 左右。
实际报表处理速度达到以前W8A8的1.6倍左右。
用opencode 调用 它来写的小小星球，用时10分钟左右：
提示词：用HTML5创建一个3D小行星地球，玩家可以在上面行走，并且它包含所有这些可以探索的生物群落（biomes），星球不必太大，但走起来依然有趣。故事背景是一个正在露营并四处探索的童子军男孩。游戏要有server.py，启动后随机寻找一个本机的空闲端口作为服务器，并自动从默认浏览器打开让用户试玩
总的来说感觉不错。希望尽快有人把它的qwen 3.8 flashnext 移植到 ampere平台。
发布日期：2026 年 10 月 18 日 | Stars：约 137 | 状态：更新非常活跃
2026 年 10 月 18 日，开发者 Zagitta 公开了 gpu-unlock 项目。它要解决的是 NVIDIA 从安培一代就开始的老问题：GeForce 消费卡（GA102/GA104）的 BF16 张量运算被固件人为限速，远低于专业卡（RTX A 系列）的速率，而专业卡硬件完全相同，只是速度选择器寄存器被锁死。社区此前已有针对矿卡 CMP 90HX 的 cmp90hx-unlock（WildFlash1st 维护），本项目的 V67 签名常量 正是从那套方案改编而来。
它是一个 Linux 内核模块，在 initramfs 阶段、NVIDIA 官方驱动绑定显卡之前 运行：
610.43.03 版官方包 中提取并校验过 SHA-256 的 GSP/Booter 固件，以带 V67 签名的方式完成解锁SS0 写 0x88888888（选中满速 BF16）；SS1 写 0x8（效果未验证）FLR 复位，再把干净的卡交还给未修改的原厂驱动它既不是 UEFI 程序也不是魔改驱动。 作者在 CachyOS 内核 + NVIDIA 615.71.09 驱动上验证：BF16/F16 运算约提升 40%。
| 限制项 | 说明 |
|---|---|
| 设备 ID | 只接受 GeForce/CMP 的 GA102/GA104，实测仅覆盖一张 RTX 3090（3090 Ti 等在 issue 请求中） |
| 启动方式 | 必须冷启动生效，热重启不支持 |
| 启用方式 | 通过内核命令行 gpu_unlock.targets= 显式 opt-in |
| 驱动绑定 | 固件输入严格钉死 610.43.03，换驱动需跟进适配 |
第一，运行时解锁，无变砖风险。 不刷 VBIOS、不写 EEPROM，断电重启即恢复原状——这是它比一切"改 BIOS 解锁"方案最优雅的地方。DKMS + Arch/Debian/RPM 三条打包路径，装起来像正常内核模块。
第二，收益精准命中 AI 推理场景。 sm_86 没有 FP8 和 FP4，3090 跑大模型最吃重的就是 BF16/INT8 张量核心。对做 LLM 推理的人（尤其长上下文、prefill 密集、KV cache 全 BF16 的负载），40% 的 BF16 提速 意味着 vLLM/SGLang 的 prefill 吞吐和混合精度层的直接受益，等于零成本把 3090 往 A6000 的算力规格拉近一档。游戏玩家基本无感——FP32/光栅不受此锁影响。
第三，注意边界。 这是单卡单环境的实证结果，作者自己声明"其他 3090 板卡和环境未经验证"；固件来源受 NVIDIA 驱动许可协议约束，作者只声明个人本地打包用途。加上驱动版本强绑定，目前更像给折腾党的高级工具，而非普适方案。对双 3090 机器（正好在用 615.71.09）来说值得关注——若后续适配驱动版本，INT8 W8A8 + 满速 BF16 的组合会明显补上 3090 长上下文推理的短板。
传统 FP32 CUDA 核心 GEMM、光栅化、显存带宽都不受这个锁影响。解锁的是张量核心速率选择器，纯标量/向量计算没戏。
这是很多人忽略的点：现在的 INT4/INT8 权重量化在 vLLM/SGLang 里几乎全是 "weight-only" 方案——反量化成 FP16 后跑 FP16 张量核心 GEMM。仓库作者实测原话是 "Faster BF16/F16 operations. About 40% gain"，F16 也在解锁范围内。所以这类模型的 prefill（compute-bound，张量核心吞吐决定速度）理论上直接吃到接近 40% 的提升。
仓库实测证据只覆盖 BF16。但有一个强旁证：
| 精度 | RTX 3090 | RTX A6000 | 比值 |
|---|---|---|---|
| INT8 (dense) | 142 TOPS | 308 TOPS | 2.17x |
| BF16 | 71 TFLOPS | 154.7 TFLOPS | 2.18x |
INT8 与 BF16 的锁死比例完全一致——说明 NVIDIA 在 GA102 上是把整条张量核心流水线（含 INT8/INT4）一起限速的。SS0 寄存器那 8 个 4-bit 字段大概率就是按精度分档的速率选择器，写 0x88888888 是把所有档位拉满。
Decode 是显存带宽瓶颈（每 token 把权重从显存搬一遍），不是算力瓶颈。这个解锁是算力解锁，3090 的 936 GB/s 带宽没人动过。收益集中在 prefill / 长上下文首 token（TTFT），稳态出字速度 t/s 不会明显变化。
W8A8 v3 属于第 ③ 层，值得实测验证：解锁前后各跑一次 vLLM 的 prefill 吞吐测试（如 vllm bench 长 prompt 的 TTFT，或 torch._int_mm 微基准）。如果 INT8 也吃到锁的解除，对"256K 上下文 + prefill 重"的部署是实打实的收益；同时把 decode 速度预期管理好，那边不会有魔法。
最近在HF社区还是挺火的 
下载前想着是穷人 的解药，是不是能让 20G显存实现27B 90%的性能和智商？
下载后一测，个人认为和QWEN 3.6 9B一个水平，应该还是欠缺优化，无法恢复原始模型的行为和精度。
16G+带tensor core的显卡应该都可以玩，在占用满90%-95%显卡的情况下，如果模型能正常跑。
速度如果是 x tokens /s
那么你的显卡价值 = RTX3090 24G的市场价 / 55 * x。
我用的是168K上下文，双F16 K V缓存。
简单的问题都是失败，我已经按官方推荐设置温度0.7，开启思考模式。
全程速度都非常稳, 55T/s。
一句话的俄罗斯方块，无法运行。
带提示词的俄罗斯。
完成度还行吧。 这个俄罗斯的消行 火花挺好看的。 但是最后一行经常有残影，很难看。
一句话的坦克大战，跑了4分钟，最后无法运行。
最后再测一下evalbench吧：
时间太长了（开了思考的），分数也不算高，全参数，262K上下文并没有实用性。 SHIFT+DELETE是它最后的归宿。
https://vramcalculator.com/strata-calculator/
输入你的配置,查看可以跑哪些QFN 3.8模型,GPU上能放多少个专家 (总共24600个)
有些显卡下面还有网友的速度,(有些比较旧.几天前的跑分) :
硬件：EPYC 7B13 (64C/128T, Zen3) + 2×RTX 3090 24G + 247G DDR4-2133 八通道 + NVMe
模型：Qwen3.8-Flash-Next-Uncensored IQ4_XS（orcarouter 无审查微调，97.5G GGUF）
引擎：Strata v0.1.38（Niko1221/Strata）
实测体感：限制250W 及 1570MHZ核心，温度可压到60度以下，三风扇无噪音。TG 稳定 90-120 t/s，长文写作 80 t/s 左右，262K 满上下文，视觉可用
10月8日升级后加参数: 150 t/s 是真的，而且日志里最高冲到 175.9 t/s。拉了全部引擎日志和 /metrics，归因分析如下：
你的 150+ 从哪来（三层叠加）
① 主因：pipeline-windows 2 生效了（双卡不再轮流干等）
0.1.39/0.1.40.1 时代层切分是“严格接力”——卡0算完传给卡1，每步有半个周期两张卡之一在空转（fork 作者实测“每张卡每步闲置过半”）。现在 --pipeline-windows 2 让卡0在卡1验证当前窗口时就开始算下一窗，空转时间被吃掉。你日志里整段稳态在 104-136 t/s 区间（旧基线 71-99），长答 9473 tok 跑出 124.6 t/s——这个稳态抬升就是流水线的贡献，+25~30%。
② 助推：热点会话的专家缓存命中 94-97%
你 150+ 的那几段（160.5/160.4/165.2/175.9）全部是 2 秒短段 + 94%+ 命中 + PCIe 传导只占 2-3.5%——热会话里专家几乎全在双卡缓存里，miss 极少，流水线不用等 PCIe 搬运，MTP 猜测链也顺。命中率低的段落（88.4% 那条只有 106.7 t/s）反证了这个相关性。
③ 波峰：MTP 接受率好的短段
短段（100-240 tok）样本小，若草稿层连中，单窗口提交多 token，瞬时速度就高——175.9 那条是典型的“波峰读数”。整段 MTP 接受率目前 68.5%，中规中矩。
“更快的卡放最后（跑 output head + draft）”在 0.1.40 已是自动行为（server 按 SM×clock 自己排卡），你的双 3090 同型号无此差异——这也是你复现干净的加分项。
10月8日,速度已经很满意 了,后续就是打磨质量了(3D鹈鹕骑车用了8分钟写成,增加细节另花10分钟) :
打开后要等几十秒加载three.js
pelican.html
| 去向 | 大小 | 说明 |
|---|---|---|
| 专家缓存（热点专家） | ~17.3 GiB/卡 | 6931/24576 个专家常驻 VRAM，随对话自适应换血 |
| 注意力/DeltaNet/QSA/KV 常驻窗 | ~5 GiB/卡 | KV 只驻留最近 32K（--kv-resident），更早的流式 |
| MTP 草稿头 | ~213 MiB | 10.6 万 token 词表的投机草稿层 |
| 视觉编码器预留 | ~1.4 GiB | mmproj 投影 + ViT 激活 |
| 剩余 | ~458 MiB | 安全垫 |
双卡分工是层切分流水线（0-22 层 / 23-47 层），不是张量并行——不需要 NVLink/P2P，PCIe 3.0 x16 老平台一样跑。
| 去向 | 大小 | 说明 |
|---|---|---|
| 全部专家权重（pinned） | ~61 GiB | VRAM 装不下的 1.7 万个专家，CPU 在位计算 |
| PLE n-gram 表（--ple-io ram 锁页） | ~28.8 GiB | 51B 参数的 lookup 表，锁进 RAM 免 SSD 抖动 |
| KV 流式区（262K ctx） | ~3.6 GiB | 13.7KB/token，超 VRAM 窗口的部分 |
| MTP 权重 + 运行时 + 杂项 | ~4 GiB |
关键认知：free 命令显示的 used 不含 PLE 锁页（mmap 页计入 Cached），看进程 RSS 才是真话。别被 70G 的假象骗了。
| 去向 | 核数 | 说明 |
|---|---|---|
| 专家池 worker | 63 | 默认 = 全部物理核 - 宿主线程，decode 时每核吃满 99.9% |
| 宿主循环 | 1 | token 调度 + GPU 提交 |
| SMT 兄弟线程 | 64 | 空闲（AVX2 内核吃满物理核就够了，开 SMT 反而抢带宽） |
"只用到一半 CPU"是 top 的错觉：物理核 64 个全在烧，SMT 线程闲着。如果能升级AVX-512的CPU，内核可以更快，但 Zen3 只有 AVX2——Engine 自带 iq_avx2.cpp 多 token 内核（实测 down 4.4 GB/s vs ggml 3.2，3-token 窗口 282us vs 414us），AVX2 用户不亏。
冷启动 35 秒完成 61G 专家加载（~27 GiB/s，八通道 DDR4-2133 的理论带宽约 120GB/s，单线程顺序读能跑到 1/4 理论值已经很扎实）。
Flash-Next 是 125B 总参 / 6B 激活的 MoE：48 层 × 512 专家，每 token 只激活 10 个。这个结构就是为 Strata 量身定做的——激活稀疏性让"专家分家"成为可能：
VRAM → 每 token 必经之路：注意力/DeltaNet/KV/草稿头
+ 热点专家缓存（自适应学习你的对话习惯，命中率爬到 97-99%）
RAM → 全部专家 pin 住。VRAM 没有的专家，CPU 就地计算——GPU 和 CPU 并行，互不等待
SSD → 28.8G PLE n-gram 表。每 token 只读几行（我们的环境 用 --ple-io ram 锁进内存后归零）
每生成一个词：草稿头先猜 3-5 个 token → 一次前向验证全部 → 平均 2.4-3.2 token/步落袋。MTP 接受率实测 70-96%（代码类任务更高），这就是 80-100 t/s 的直接来源。
CUDA0 算 0-22 层，CUDA1 算 23-47 层，一个 verify window 只有一次卡间握手。对比 vLLM 的 TP=2：不需要 NCCL allreduce 高速互联，不需要双卡同频，两张卡各自干自己的层——这就是为什么 3090 这种 PCIe 老卡也能高效组队。
VRAM 只留最近 32K 的 KV，历史部分放 pinned RAM 按需流式读。代价是 RAM ~13.7KB/token（262K 才 3.6G），换来的是显存让给专家缓存。官方数据：262K 上下文下这个设计让 Q2_0 从 50.9 提速到 62.6 t/s。 如果有需要还可用Yarn扩展到512K或 1M。
引擎按 expert profile（预训练统计的热度排名）初始摆放，运行中按你的实际对话持续换血——中文对话热起来的专家和写代码热起来的专家是两批人。实测命中率从 92.7% 爬到 99.2%，命中即免 CPU，这就是为什么跑得越久越快。
decode 时的关键路径是：GPU 算缓存专家（~13ms）‖ CPU 算未命中专家（~75ms）‖（偶发）SSD 读 PLE 行。三条路并行，最长的那条决定速度。PLE 锁内存后，CPU 专家计算成为唯一长杆——而这正好吃满你的 CPU。
cmake -B build -DSTRATA_ENABLE_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 ...
cmake --build build -j 48
模型三条件（任何微调版能不能上，看这三条）：
tools/iq_pack.py --compat-bf16 打包，专家权重不动）./build/native_expert_parity <shard1> 0 2——0 failures 就能上（IQ4_XS 就是这么实测出来的，官方文档还说没验证）打包 + 配置：iq_pack.py 生成 pack（index/dense/tokenizer，约 1.5G），配置 JSON 指定 pack/native/ple-gguf/MTP/层切分
服务：python3 -m serve.server --engine strata --config xxx.json --port 8025，自带 Web Chat/Monitor/OpenAI API/Anthropic API/视觉（mmproj + strata-vision helper）
三个必开参数：
--kv-resident 32768（KV streaming，长上下文提速 + 显存让位）--ple-io ram（PLE 表锁内存，decode 尾延迟稳）不开占用70G内存，开了占用105G左右--layer-split auto（双卡自动切层）上下文三档热切换（本机的做法）：131K / 262K 原生 / 512K YaRN（--rope-scaling yarn --rope-scale 2.0），一个脚本管三档配置，切换时同步 new-api 元数据
https://huggingface.co/orcarouter/Qwen3.8-Flash-Next-Uncensored-GGUF/tree/main 模型下载地址，考虑到CPU性能，我下载的是IQ4_XS，相对IQ3，质量稍好。
input: ["text"]，否则 agent 会发图卡死| 模式 | temperature | top_p | top_k | min_p | presence_penalty | repetition_penalty |
|---|---|---|---|---|---|---|
| 思考模式（规划/复杂任务） | 1.0 | 0.95 | 20 | 0.0 | 0.0 | 1.0 |
| Instruct 模式（日常对话/直答） | 0.7 | 0.80 | 20 | 0.0 | 1.5 | 1.0 |
reasoning_effort（none/low/medium/high）+ reasoning_budget_tokens 硬预算，服务端 shared-settings 全局注入不是单点快，是整个账本没有浪费：
别的方案在"怎么把模型塞进显存"上卷，Strata 在"怎么让整个 PC 变成一台异构推理机"上卷。它不是把服务器模型硬塞进桌面，而是把桌面变成了一台小服务器。
缺点也说清楚：不支持 AVX-512 的 CPU 少一档内核速度（AVX2 补齐了大半）；层切分流水线让单卡用户少一半专家缓存；量化到 IQ4_XS 后数学类推理略逊满血。但对本地部署的真实负载——agent 编码、长文档、日常对话——这些短板都不在关键路径上。
以上全部数据来自本机实测（2026-10），引擎与模型均开源可复现。欢迎交流不同硬件下的账本。
IQ4_XS 带视觉 正在编程过程中：
IQ3_S 速度还要更快一些
希望作者抓紧迭代，加入103G的UD_IQ4_XS，KLD和PPL可以进一步优化！
这个作者简直是天才。以前用27B还担心烧坏显卡，现在闭眼限240-250W，显卡，CPU，内存一起发力，长时间开着写程序，显卡温度也不会升高！质量还有保证。本地LLM跑中长程任务 时代真的要来了！
发现论坛里玩3090的朋友不少，但似乎都是各忙各的，每次有人晒跑分，底下想对比都没法比——基准不一样，配置也没标注，还有致命的一点是，只有一个t/s，想抄作业 ，但是又怕下载回来折腾一阵，只能跑32K 64K，实际跑不起来生产力，热闹一阵就散了。
所以想发起一个小活动，把大家的经验和数据攒到一起，攒出一份属于3090玩家的真实对比。分两个阶段，都很简单：
第一阶段：报名 + 投票（本帖）
想参加的，直接在主帖跟贴 留言 (其实也不限3090），选择你认可的评测套件，每张显卡一票（顺便说下自己的配置和NVLink情况更好）。
然后用投票决定统一用哪个测试套件。候选先列几个，欢迎补充：
zx-bench：https://github.com/suncityldp/zx-bench 楼主今天凌晨已经测了一下27B，感觉时间挺长。一套配置就 要3小时 。。。
tooleval
benchlocal
其他你觉得合适的（GAIA、AgentBench之类也行）
投票方式：回帖“投票 + 套件名 + 真实硬件照片”，少数服从多数。
截止日期：下周一9月21日 晚上23点59分
第二阶段：新帖晒成果
投票确定下来后我会另开一个新帖（链接到时候发在这里）。大家每周在周日前，把自己当时觉得最强的配置和跑分结果 ，发到新帖里，内容包括但不限于：
跑分 + 截图（有图有真相）
最满意的作品也可以晒（token efficiency 更佳）
附上硬件环境（有无NVLink）和操作系统环境 及选择原因等。
本活动接受各种建议。
附则：投票权重折算表（以3090=1票为基准）
投票权重按各卡稠密FP16张量算力相对3090折算。计算公式：票数 = FP16稠密 / 71，四舍五入到0.5的倍数。
未列出的卡可自行计算：查该卡FP16张量算力（稠密值），除以71即可。
消费级游戏卡
| 显卡 | 稠密FP16（TFLOPS） | 折算票数 | 参考价格 | ||||
|---|---|---|---|---|---|---|---|
| RTX 3060 12G | ~25 | 0.5 | 1.5-2k | ||||
| RTX 4060 / 4060 Ti | ~30-44 | 0.5 | 2-3k | ||||
| RTX 3070 / 3070 Ti | ~41-44 | 0.5 | 2-3k | ||||
| RTX 3080 / 3080 Ti | ~60-68 | 1 | 3-5k | ||||
| RTX 3090 | 71 | 1（基准） | 5-8k二手 | RTX 3090 Ti | ~80 | 1 | 6-9k |
| RTX 4070 / 4070 Ti | ~58-80 | 1 | 3-6k | ||||
| RTX 4080 | ~97 | 1.5 | 6-8k | ||||
| RTX 5070 | ~124 | 1.5 | 4-5k | ||||
| RTX 4090 | ~165 | 2.5 | 15-20k二手 | ||||
| RTX 5070 Ti | ~176 | 2.5 | 5-7k | ||||
| RTX 5080 | ~225 | 3 | 7-9k | ||||
| RTX 5090 | ~419 | （÷71 ≈ 6） | ? |
https://github.com/Doorman11991/smallcode
放个GITHUB页面应该不违规吧？
作者自称是专门为4B-35B本地模型设计的。
用npm的方式安装，我在UBUNUT 22.04和WIN10上都安装了。
且都有问题：
第1. 最开始初始化的时候 输入1个字符会变2个，粘贴的字符也自动翻倍。
作者的版本是昨天才更新的。 后来还是心痒痒的想跑起来，让HERMES给我拉取上个旧版来编译，还是有这个问题。。。 傻眼。。。 难道我自己的环境有问题，怎么两台都这样？ 而且作者页面有个issue还有两人也是同样问题。 最后死马当作活马医，两个就两个，结果它只是显示问题，实际传给程序的还是一倍字符。 解决了就能连接本地LLM了（QWEN 27B）
第2. 进去了，首先就是看官方那个唯一的文档，指明两条路：1是轻量版，适合新手入门
2是全量版rag，大概意思 就是30个编程语言的rag. 这个软件要给LLM套一层RAG，让它在写代码的时候自动带上外挂！ 那我肯定选那个语言多的啊 
运行命令的时候又报错了。。。 唉，这作者还真是不拘小节。
然后我在WIN10上用OPENCODE给我修复。 UBUNTU上用HERMES修复。。
最后两个都能跑了。 但UBUNTU上还是有BUG，2秒闪一次，然后还有TOOL调用 失败（目前还是裸的啥SKILL和MCP都没装）
最后就剩下 WIN10能跑了。 让它写俄罗斯方块，才10KB，和我以前 让QWEN写的功能差不多，但是文件体积小一半，还真有点拿了秘笈 武功更高的意思。 让它尝试修一下坏的中国象棋试试：
还是会闪，迟点来看结果。
中期测试过程：
Hermes的发现：
思考预算（thinking budget）在 SGLang + Qwen3.8 上怎么设
三条路径，可用性递减：
1. 软性控制（现在就能用）：就是 reasoning_effort（xhigh/medium/low），往 system prompt 注入自然语言指令让模型"少想点"。不是硬上限，靠模型自觉——上一轮交接已实测过。
2. --enable-strict-thinking + max_thinking_tokens（请求级字段）：
- server 加 --enable-strict-thinking，请求里传 max_thinking_tokens: N
- ⚠️ 关键发现：OpenAI 兼容接口（/v1/chat/completions）没有这个字段——ChatCompletionRequest schema 里没有它，serving_chat.py 构造 GenerateReqInput 时也不填。它只存在于原生 /generate 端点的 GenerateReqInput 上。而 Hermes 走的是 OpenAI 兼容层 → 这条路对 Hermes 是死路。
3. 环境变量 SGLANG_MAX_THINK_TOKENS=N（server 级硬上限，推荐）：
- 本机源码确认：environ.py L1011，注释原文 "Think tokens budget: negative means unlimited, >= 0 caps thinking tokens"
- 机制：ReasonerGrammarBackend 在 thinking 阶段做 vocab mask，达到 N 后强制输出 `
根据此发现，我将启动脚本添加了相应的参数，并在new api中加入 控制开关，测试无报错，马上用tooleval做 A/B 测试：
使用以下参数的nothink渠道模型，获得了53秒，100分的quick成绩 ：
{"operations": [
{"path": "temperature", "mode": "set", "value": 0.6},
{"path": "top_p", "mode": "set", "value": 0.945},
{"path": "top_k", "mode": "set", "value": 20},
{"path": "min_p", "mode": "set", "value": 0.055},
{"path": "max_tokens", "mode": "set", "value": 16384},
{"path": "repetition_penalty", "mode": "set", "value": 1.088},
{"path": "chat_template_kwargs.enable_thinking", "mode": "set", "value": false},
{"path": "reasoning_effort", "mode": "set", "value": "none"}
]}
【自8月21日起，所有测试和改进工作都是以 Qwen3.8-27B — Rotation + SmoothQuant + GPTQ W8A8-INT8 (+ BF16 MTP) 这个模型为中心来开展了。
8月21日：
测一下最高思考的跑分情况，结果有点反直觉，原本以为时间会很长，但是也就91秒（相比最小思考的52秒） ，但结果明显稳定许多。
改得有点冒火，我直接开GLM5.2 MAX让它来改改：
搞了快2小时，它终于肯交付了，模板文件厚了8KB.
实测min think:
min think 全测 ，从85分->95分 ， 时间从548秒增加到586秒，token效率依旧0.3 .
xhigh think 全测，有点意外，分数88分->91 分，时间从728秒减少到707秒，token效率从0.3降到了0.2 . 【不过也和大家的印象差不多，思考并不是越多越好】
本地AI玩了快两个月了，某一刻：我突然发现，和LLM或者是HERMES聊天，或者是让LLM担任AGENT，用IDE让它跑编程任务，本质上是一个工程问题，也是一个人机协同，思维同步的问题。
而不能像跟阿拉丁神灯许愿一样，期望模糊的打几个字。对面的AI就能像阿拉丁神灯一样，又快又好的回答你，或者瞬间帮你实现你要的结果。
能做到前者的，目前可能只有豆包，情绪价值拉满，但是可能答案和真实情况千差万别，能做到后者的，可能只有claude code 20X MAX套餐。
能同时做到两者的，趁早洗洗睡，梦里面肯定有。
不过落到实际的话，我目前努力的方向还是，怎样实现人机思维链的快速同步，目前给我感受最好的，也只有hermes了，目前策略是，开两个窗口，一个选 本地QWEN 3.6 27B，省TOKEN，智能思考。少于30字符的问题基本秒回（我有让它配置一个闲聊模式，不要发太重的SYSTEM PROMPT给LLM）。
另一个窗口，连接DEEPSEEK PRO，有编程任务 ，或者是本地配置任务 ，我都在里面跑，上下文量大管饱，最近华为显卡跟上了，也不会卡顿了。
不管哪个窗口，上下文满了，发送指令让它更新或总结记忆，然后/new重建session，接着爽聊。
其实看看现在的在线聊天AI，KIMI，千问，智谱，豆包，gemini,他们一直也是有类似的设计，默认快速，手动可以 选深度思考或者联网，资本也在做成本的权衡。
而我们有本地LLM条件的，可以自己想更多办法，工程化的去实现，从而不用受资本的压榨，又能将个人资料牢牢攥在自己 手中，免受绿泡泡倒卖资料给购物网站的困扰。
如此，实现人机的协同，让HERMES真正成为个人的 数字孪生，让它将目前时代的两个红利,QWEN 3.6 27B本地与DEEPSEEK PRO（或者claude code) 。通过不断与HERMES交互，将时代红利，个人现实，牢牢绑定。减轻个人负担，创造更多价值！
最后用清言的回答和HERMES的总结图，来结个贴：
起因是一篇20多天前的帖子，在作者的评测维度里面适合3090显卡，综合分数最好的跑HERMES的35B A3B模型是byteshape的4.19Bpw的qwen 35b a3b mtp。
https://www.reddit.com/r/hermesagent/comments/1twjvs8/i_ran_8_models_3_runs_8_benchmark_packs_on_a/
我的内存是64G，空闲大概40多G，使用的框架是ik_llama，权重我下载回来了。
考虑该模型权重为4.20 bpw,k v cache决定选用q5_0 q4_1, 主要怕Q8_0/Q5_1,产生的k v cache 与原始权重相差太大，导致结果不确定性增加，启动参数如下：
/data/model3/llama/ik-llama625/build/bin/llama-server \
--host 0.0.0.0 \
--port 8025 \
--model /data/model3/Qwen3.6-35B-A3B-IQ4_XS-4.19bpw.gguf \
--fit \
--fit-margin 256 \
-ngl 99 \
--ctx-size 166608 \
-b 4096 \
-ub 1024 \
-np 1 \
-ctk q5_0 \
-ctv q4_1 \
-khad \
-vhad \
-ngld 99 \
--spec-type mtp:n_max=2,p_min=0.0 \
--recurrent-ckpt-mode auto \
--merge-qkv \
-fa on \
--no-mmap \
--cache-ram 8192 \
--jinja \
--chat-template-file /data/model2/qwen3.6-27b-gguf/apex-qwen-chat-template.jinja \
--parallel-tool-calls \
--recurrent-ckpt-mode auto \
--chat-template-kwargs '{"preserve_thinking":true}' \
--reasoning off \
--reasoning-format deepseek \
--temp 0.6 \
--top-p 0.95 \
--top-k 20 \
--min-p 0.04 \
--repeat-penalty 1.08
这些参数已经尽量调整为最优。
首先跑一轮tool-eval(忽略模型名，因为那个脚本是固定的，我没改脚本里面的名字）：
91分已经是我测过的10多种参数和模型组合里面比较高的了。响应速度也是很快了，平均水平应该在320多秒。 只是token质量偏低，只有0.3pts/1k token (27B有 0.5 pts/1k).
实测让我的hermes调研员上google和reddit调研（有另一台qwen 3.5 9b mtp作为辅助模型处理长文本），续航终于可以上去了。跑了30多分钟，最终结果：
（质量肯定不如在线API，但是续航我已经很满意了)
最后的TOKEN生成速度：
显存占用：
附:伟人诗词测试六首,提示词:<|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量化(未开启视觉)模型的极限了:
双卡张量并行：温度与频率为什么必须协同
双 3090 风冷跑大模型的一点实战心得
一、TP 的本质：两张卡是拴在一起的
张量并行（TP=2）把每层权重矩阵切成两半，两张卡各算一半，但每一步都要 AllReduce 同步才能进入下一步。所以单个 step 的耗时永远由较慢的那张卡决定——典型的木桶效应：快卡算完只能原地干等，多出来的算力全部浪费在等待里。
二、频率差的来源：温度墙
满载时 GPU 普遍贴着温度墙跑。两卡因风道位置、积灰、硅脂老化差异，同负载下温度常差 5~10°C。热卡先触发降频，频率差一旦出现，慢卡就拖垮整条流水线，decode 速度肉眼可见地掉一截。
三、锁频不是万能解
锁频（-lgc）能把两卡频率钉死，但前提是散热扛得住：散热弱的卡根本锁不住，反而更热；且锁频牺牲自动 boost 的峰值性能（本机实测 decode 慢约 3.5%）。
四、正解：温度协同
与其追求"各自最凉"，不如把控制目标改成"两卡温差趋近于零"：
热卡风扇加速时，冷卡风扇同步跟进，维持同频散热；
两卡温度收敛 → 频率自然同步 → 谁也不用等谁；
实测 ΔT 5~6°C 时，约 26 秒收敛归零，两卡 SM 利用率重新持平。
一句话总结：TP 架构下整体性能 = min(卡1, 卡2)。频率协同保住下限，而温度协同是频率协同的前提。风冷双卡跑大模型的朋友，与其盯着单卡温度数字，先看看两卡温差。
我让GLM 5.2给我写了个风扇控制程序，后面再跑，感觉就顺多了：
—— 欢迎交流指正 ——
