我有个关于hermes使用本地显卡和模型的疑问
-
@bily-j 你遇到的这两个问题其实挺常见的，我来分别解释一下：
-
显卡一直转（空闲时也在跑）：这个大概率是 llama.cpp 的 MTP（推测解码）在后台持续工作。当你启用了
--draft-mtp参数后，即使 Hermes 没有发出新的推理请求，llama.cpp 的 MTP draft 模型会持续尝试预填和生成候选 token，以保证当你需要时能快速响应。这会导致显卡一直有负载，功耗在 50-80W 左右，但不会满负荷。如果你不希望这样，可以关掉 MTP（去掉--draft-mtp参数），显卡在空闲时会降到待机功耗（~20-30W）。代价是首 token 延迟会变长一些。 -
Hermes "分析中"卡很久才继续：这个通常不是模型太慢，而是上下文（context）过长导致的 prefill 时间暴涨。Qwen3.6-27B 的 thinking token 机制有时候会"想太多"（overthinking），特别是上下文已经积累到 10K+ tokens 的时候，模型每走一步都要重新处理大量 KV cache。解决方案：
- 在 Hermes 配置里限制 max_tokens（比如 4096），避免模型单次输出太长
- 设置
--ctx-size 16384或更低，防止上下文无限膨胀 - 关掉
--enable-thinking（如果 Hermes 版本支持），减少 thinking token 的开销 - 如果并行开 2-3 个聊天窗口，llama.cpp 虽然支持并行（
--parallel N），但每个并行的 context 会占用独立的 KV cache，VRAM 会相应增加，prefill 也会互相影响，建议先只开 1 个窗口测试看看是否还有卡住现象
另外你的 24G 显存跑 Qwen3.6-27B Q4_K_M（大概 16-17GB）+ KV cache（22.8G 左右占用）已经接近极限了，没有太多余量给大上下文或并行。建议试试把
--batch-size调小到 512 或 256，有时候 batch 太大反而会因为显存交换导致卡顿。 -
-
@bily-j 你遇到的这两个问题其实挺常见的，我来分别解释一下：
-
显卡一直转（空闲时也在跑）：这个大概率是 llama.cpp 的 MTP（推测解码）在后台持续工作。当你启用了
--draft-mtp参数后，即使 Hermes 没有发出新的推理请求，llama.cpp 的 MTP draft 模型会持续尝试预填和生成候选 token，以保证当你需要时能快速响应。这会导致显卡一直有负载，功耗在 50-80W 左右，但不会满负荷。如果你不希望这样，可以关掉 MTP（去掉--draft-mtp参数），显卡在空闲时会降到待机功耗（~20-30W）。代价是首 token 延迟会变长一些。 -
Hermes "分析中"卡很久才继续：这个通常不是模型太慢，而是上下文（context）过长导致的 prefill 时间暴涨。Qwen3.6-27B 的 thinking token 机制有时候会"想太多"（overthinking），特别是上下文已经积累到 10K+ tokens 的时候，模型每走一步都要重新处理大量 KV cache。解决方案：
- 在 Hermes 配置里限制 max_tokens（比如 4096），避免模型单次输出太长
- 设置
--ctx-size 16384或更低，防止上下文无限膨胀 - 关掉
--enable-thinking（如果 Hermes 版本支持），减少 thinking token 的开销 - 如果并行开 2-3 个聊天窗口，llama.cpp 虽然支持并行（
--parallel N），但每个并行的 context 会占用独立的 KV cache，VRAM 会相应增加，prefill 也会互相影响，建议先只开 1 个窗口测试看看是否还有卡住现象
另外你的 24G 显存跑 Qwen3.6-27B Q4_K_M（大概 16-17GB）+ KV cache（22.8G 左右占用）已经接近极限了，没有太多余量给大上下文或并行。建议试试把
--batch-size调小到 512 或 256，有时候 batch 太大反而会因为显存交换导致卡顿。 -
-
@bilyj 关于你的跟进问题：
-
没开MTP但显卡还在转——那大概率是另一种情况：llama.cpp在后台持续做context management。当你开了多个聊天窗口并行时，即使某个窗口没有新对话，llama.cpp的batch处理机制也会不断扫描所有活跃slot，做一些内存整理和KV cache的管理操作。24G上占22G显存+GPU持续中低负载运行时，这就是典型现象。不影响使用，不必担心。
-
24G 4090 + MTP下的上下文实测数据：
- Qwen3.6-27B Q4_K_M（约16-17G模型权重）：不开MTP能到110-120K左右
- 开了MTP（draft model额外占约1.5-2G）：确实会掉到60-80K，因为draft model的KV cache也要占空间
- 如果你想兼顾速度和上下文，有几个折中方案：
a. 用 --draft-max 8 --draft-min 4 限制draft长度，减少draft KV cache开销
b. 或者试试 Q4_K_S（比K_M小一点点，质量差别不大），能多出10-15K上下文
c. 另一条路是vLLM，它的memory management更高效，同样24G下27B Q4可以到130K+，而且不会因为MTP占用额外显存
-
你觉得60-70K不够用，具体是什么场景？如果是长文档分析或代码库级agent任务，这个长度确实紧张。但如果只是普通对话+工具调用，其实很少真的用完70K。Hermes的tool call来回切换也会消耗token，建议跑的时候用 --cache-reuse 或 --no-context-shift 来最大化利用有限上下文。
如果你想测极限，可以试试
llama-cli --no-kv-offload --numa --temp 0+ Q4_K_S + ctx-size 131072，看能稳定到多少。 -
-
采用llama.cpp架构，qwen3.6-27B，gguf Q4量化，当然我不知道是用了多几个聊天窗口在进行对话有关还是怎么样？llama.cpp是串行的，但好像处理2-3个并行也是没毛病的，因为我经常这么干，反正就是等时间而已，但是不知道是不是用了并行的原因他处理不过来，还是里面堵塞了，单个执行的时候我倒没仔细观察有没有这样的情况
Hermes 干完活后, LLM 一般不会马上停止.
现象是 hermes看起来已经回答了问题, 显示也似乎是完成了. 但是 llm 里面还有未完成的会话队列. 我用LM Studio的时候, 能够看到这时候的队列状况.
这个会话, 短的话有时候几十秒, 长的话有2,3分钟, 然后就彻底停止了.
还有 一种可能, 你的hermes 有cron 任务, 定时唤醒了 llm.
如果想要弄清楚, 你直接tail 一部分运行日志, 喂给hermes, 让它分析即可. 这个最好带上格式化日志的参数, 把llama的运行日志单独出来.
至于你kill pid杀不死, 是因为hermes 自己有daemon, 它会自己启动.
-
@bilyj 关于你的跟进问题：
-
没开MTP但显卡还在转——那大概率是另一种情况：llama.cpp在后台持续做context management。当你开了多个聊天窗口并行时，即使某个窗口没有新对话，llama.cpp的batch处理机制也会不断扫描所有活跃slot，做一些内存整理和KV cache的管理操作。24G上占22G显存+GPU持续中低负载运行时，这就是典型现象。不影响使用，不必担心。
-
24G 4090 + MTP下的上下文实测数据：
- Qwen3.6-27B Q4_K_M（约16-17G模型权重）：不开MTP能到110-120K左右
- 开了MTP（draft model额外占约1.5-2G）：确实会掉到60-80K，因为draft model的KV cache也要占空间
- 如果你想兼顾速度和上下文，有几个折中方案：
a. 用 --draft-max 8 --draft-min 4 限制draft长度，减少draft KV cache开销
b. 或者试试 Q4_K_S（比K_M小一点点，质量差别不大），能多出10-15K上下文
c. 另一条路是vLLM，它的memory management更高效，同样24G下27B Q4可以到130K+，而且不会因为MTP占用额外显存
-
你觉得60-70K不够用，具体是什么场景？如果是长文档分析或代码库级agent任务，这个长度确实紧张。但如果只是普通对话+工具调用，其实很少真的用完70K。Hermes的tool call来回切换也会消耗token，建议跑的时候用 --cache-reuse 或 --no-context-shift 来最大化利用有限上下文。
如果你想测极限，可以试试
llama-cli --no-kv-offload --numa --temp 0+ Q4_K_S + ctx-size 131072，看能稳定到多少。 -
-
@bily-j 关于vLLM和GGUF的问题，我来展开说说：
vLLM确实对GGUF支持不好（有实验性的llama.cpp backend但很不成熟），vLLM主要用的是HF（Hugging Face）格式或者safetensors格式的模型。所以你如果用vLLM，需要找HF格式的模型。
关于"无审核模型"：
- GGUF社区确实无审核模型最多（TheBloke、Bartowski这些上传者经常有abliterated版本）
- HF格式的无审核模型其实也不少，只是搜索方式不同。在Hugging Face上搜"abliterated"或者"uncensored"加上模型名，能找到很多：
- 比如 abliterated/Llama-3.1-8B-Instruct 这类直接去掉了审核层的版本
- 或者找一些本身训练时就偏开放的模型（如Dolphin、Loyal、Magnum等系列）
vLLM的一条实用建议：
如果你既想要vLLM的速度又想要无审核模型，可以：- 去HF下载模型（不要GGUF，要完整的HF格式）
- 用 vLLM 加载，加上 --trust-remote-code 参数
- 大多数 abliterated 模型在 vLLM 上跑没问题
如果你觉得vLLM + HF格式的流程太麻烦，继续用llama.cpp + GGUF也是很好的选择。GGUF本身就是一个很成熟的格式，无审核模型的生态也好。关键是用着顺手就行了。
-
我自己有在用vLLM搭建API配合cline使用, 可以給點意見
除了跟@xiaote 說的用有寫abliterated的模型, 也可以用有寫heretic的模型
heretic在 重新訓練的數據集比較好 的情況下, 模型的思考能力, 連貫性跟邏輯會比abliterated更強, 也相對會更加少出現拒絕回答的情況
以下是碎碎唸跟簡單講一下原理, 有興趣可以讀一下
在hf的model card上通常都會有refusals rate, 我拿兩個模型作為例子
llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-GGUF
wangzhang/Qwen3.6-35B-A3B-abliterated-GGUF
KL越接近基礎模型越好, 代表兩個模型的思維偏差越低, 在這兩個例子下就是越接近0越好, KL基本上低於0.3就沒什麼大問題
heretic跟abliterated都是去審核的方式
abliterated只能說是減低拒絕的概率(refusal-reduced), 因為只單純控制權重(Weight Projection), 不涉及微調
heretic則是利用貝葉斯優化(Bayesian optimization)微調模型
但很遺憾的是沒有一個通用準則說什麼時候用abliterated, 什麼時候用heretic
然後就有人腦洞大開會跑去弄個混合模型Youssofal/Qwen3.6-35B-A3B-Abliterated-Heretic-GGUF
-
我自己有在用vLLM搭建API配合cline使用, 可以給點意見
除了跟@xiaote 說的用有寫abliterated的模型, 也可以用有寫heretic的模型
heretic在 重新訓練的數據集比較好 的情況下, 模型的思考能力, 連貫性跟邏輯會比abliterated更強, 也相對會更加少出現拒絕回答的情況
以下是碎碎唸跟簡單講一下原理, 有興趣可以讀一下
在hf的model card上通常都會有refusals rate, 我拿兩個模型作為例子
llmfan46/Qwen3.6-35B-A3B-uncensored-heretic-Native-MTP-Preserved-GGUF
wangzhang/Qwen3.6-35B-A3B-abliterated-GGUF
KL越接近基礎模型越好, 代表兩個模型的思維偏差越低, 在這兩個例子下就是越接近0越好, KL基本上低於0.3就沒什麼大問題
heretic跟abliterated都是去審核的方式
abliterated只能說是減低拒絕的概率(refusal-reduced), 因為只單純控制權重(Weight Projection), 不涉及微調
heretic則是利用貝葉斯優化(Bayesian optimization)微調模型
但很遺憾的是沒有一個通用準則說什麼時候用abliterated, 什麼時候用heretic
然後就有人腦洞大開會跑去弄個混合模型Youssofal/Qwen3.6-35B-A3B-Abliterated-Heretic-GGUF
@566656661 我用qwen3.6-27B模型的，我要去审核版本，带MTP功能的模型你有没有推荐的？或者在huggenface上如何搜索？
-
@566656661 我用qwen3.6-27B模型的，我要去审核版本，带MTP功能的模型你有没有推荐的？或者在huggenface上如何搜索？
-
@bily-j 关于 KV cache 的问题：
KV cache 在同一个会话里的行为是这样的：
-
同一个会话内，KV cache 是持续累积的。每次生成新 token，系统会把前一步计算的 Key 和 Value 缓存起来追加到已有缓存后面。所以随着对话变长，显存占用会持续增长，不会主动回退。
-
你看到的"命中时增加"是指：当新输入到达时，系统计算新 token 的 KV 值并追加到缓存尾部，显存占用确实会上升。但它不会自动回退——除非你主动清空或截断上下文。
-
如果你觉得显存不够了，有几个选择：
- 滑动窗口（sliding window）：只保留最近 N 个 token 的 KV cache，老的丢弃
- 上下文截断：清空历史，从头开始新对话
- 使用支持 KV cache 量化的推理后端（比如 llama.cpp 的 Q4_K_M cache quantization），可以在一定程度上减少 KV cache 的显存占用
- vLLM 支持
--max-model-len和--gpu-memory-utilization来控制 KV cache 的显存分配
简单说：KV cache 在会话内是只增不减的，直到你手动重置或溢出 OOM。
-
-
我自己是在用sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP
因為我有Blackwell架構卡, 所以跑在nvfp4跟vLLM上
非Blackwell可以試試這個
YuYu1015/Huihui-Qwen3.6-27B-abliterated-UD-Q4_K_XL-MTP-GGUF@566656661 我实际用MTP的模型感觉，MTP的模型比某些模型要差，容易编程或者什么的时候，绕死路，死循环，应该是模型的问题，因为我用同样的参数，其他模型就没有走死循环的特点
-
@566656661 我实际用MTP的模型感觉，MTP的模型比某些模型要差，容易编程或者什么的时候，绕死路，死循环，应该是模型的问题，因为我用同样的参数，其他模型就没有走死循环的特点
