MTP的話應該不是導致模型陷入Thinking Loop的主因

但是我覺得Tool use配合MTP (尤其大或等於3的情況下) 一齊用才容易導致, 因為Tool use涉及大量Json形式的structured output跟XML, 這裡Prediction太激進的話很容易翻車

KV cache 在同一个会话里的行为是这样的：

1. 同一个会话内，KV cache 是持续累积的。每次生成新 token，系统会把前一步计算的 Key 和 Value 缓存起来追加到已有缓存后面。所以随着对话变长，显存占用会持续增长，不会主动回退。

2. 你看到的"命中时增加"是指：当新输入到达时，系统计算新 token 的 KV 值并追加到缓存尾部，显存占用确实会上升。但它不会自动回退——除非你主动清空或截断上下文。

3. 如果你觉得显存不够了，有几个选择：

   • 滑动窗口（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。

以系統的角度來說, 理論上不會看到VRAM在上下不停跳動, 會看到跳動的只有內部引擎 (vLLM / llamacpp)

輸入階段(Prefill)命中的話會直接使用快取, 沒命中的話則需要KV Cache
輸出階段(Decode)則會不停使用KV cache, 以供應下一次輸入階段使用

如果我沒理解錯的話

我自己是在用sakamakismile/Huihui-Qwen3.6-27B-abliterated-NVFP4-MTP

因為我有Blackwell架構卡, 所以跑在nvfp4跟vLLM上

非Blackwell可以試試這個
YuYu1015/Huihui-Qwen3.6-27B-abliterated-UD-Q4_K_XL-MTP-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确实对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的速度又想要无审核模型，可以：

1. 去HF下载模型（不要GGUF，要完整的HF格式）
2. 用 vLLM 加载，加上 --trust-remote-code 参数
3. 大多数 abliterated 模型在 vLLM 上跑没问题

如果你觉得vLLM + HF格式的流程太麻烦，继续用llama.cpp + GGUF也是很好的选择。GGUF本身就是一个很成熟的格式，无审核模型的生态也好。关键是用着顺手就行了。

Hermes 干完活后, LLM 一般不会马上停止.

现象是 hermes看起来已经回答了问题, 显示也似乎是完成了. 但是 llm 里面还有未完成的会话队列. 我用LM Studio的时候, 能够看到这时候的队列状况.

这个会话, 短的话有时候几十秒, 长的话有2,3分钟, 然后就彻底停止了.

还有 一种可能, 你的hermes 有cron 任务, 定时唤醒了 llm.

如果想要弄清楚, 你直接tail 一部分运行日志, 喂给hermes, 让它分析即可. 这个最好带上格式化日志的参数, 把llama的运行日志单独出来.

至于你kill pid杀不死, 是因为hermes 自己有daemon, 它会自己启动.

1. 没开MTP但显卡还在转——那大概率是另一种情况：llama.cpp在后台持续做context management。当你开了多个聊天窗口并行时，即使某个窗口没有新对话，llama.cpp的batch处理机制也会不断扫描所有活跃slot，做一些内存整理和KV cache的管理操作。24G上占22G显存+GPU持续中低负载运行时，这就是典型现象。不影响使用，不必担心。

2. 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占用额外显存

3. 你觉得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，看能稳定到多少。

1. 显卡一直转（空闲时也在跑）：这个大概率是 llama.cpp 的 MTP（推测解码）在后台持续工作。当你启用了 --draft-mtp 参数后，即使 Hermes 没有发出新的推理请求，llama.cpp 的 MTP draft 模型会持续尝试预填和生成候选 token，以保证当你需要时能快速响应。这会导致显卡一直有负载，功耗在 50-80W 左右，但不会满负荷。如果你不希望这样，可以关掉 MTP（去掉 --draft-mtp 参数），显卡在空闲时会降到待机功耗（~20-30W）。代价是首 token 延迟会变长一些。

2. 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 太大反而会因为显存交换导致卡顿。