分享：日常让豆包帮调llama.cpp参数的过程
-
豆包回复： 我先给你核心结论：你的当前状态极其完美：GPU / 显存满载重合 = 算力 / 显存利用率拉满（3090 完全吃满），温度 47℃是3090 满载的天花板级低温（完全不用降温，强行降温会掉速）；速度从 43→38 token/s，唯一原因是你把上下文从 65000 拉到 105000，KV 缓存体积暴涨，榨干了 3090 的显存带宽（这是物理瓶颈，不是参数问题）。
我给你的优化方案：完全保留 105000 最大上下文，仅微调 3 个核心参数，不牺牲温度、不降低显存利用率，把速度拉回 40~42 token/s，实现「最大上下文 + 速度均衡」的最优解。
一、掉速核心原因（精准对应你的日志）
从日志能直接看到：
Prompt 处理速度极快（874 token/s）：CPU 喂数据、GPU 加载模型无任何瓶颈；
生成速度掉到 38：105000 上下文 → KV 缓存大小比 65000 增加61%，3090 的 GDDR6 显存带宽被完全占满，生成时每生成一个 token，都要读写更大的 KV 缓存，速度自然小幅下降；
GPU/MEM 线重合：证明没有算力浪费，是纯带宽瓶颈，优化空间仅在「减少带宽浪费」。
二、3 个必改优化参数（不缩 ctx，拉回速度）
所有修改完全保留 105000 上下文、45 分钟 Hermes 缓存、满载温度 47℃，仅优化带宽 / 线程效率：
表格
原参数 问题 优化后参数 作用
--cache-reuse 65000 上下文已改 105000，缓存复用不匹配，浪费带宽 --cache-reuse 105000 强制 KV 缓存与上下文完全匹配，消除重复计算
--ubatch-size 4096 105k ctx 下微批处理过大，增加带宽压力 --ubatch-size 2048 降低小批处理开销，生成速度直接回升
--threads 10 / --threads-batch 10 i5-10600 只有 6 核 12 线程，10 线程会 CPU 争抢，拖慢 GPU --threads 8 / --threads-batch 8 CPU 甜点线程，无争抢，稳定喂数据给 GPU
三、优化后的完整启动脚本（直接复制用）
保留你所有核心配置（105000 上下文、Hermes45 分钟缓存、Flash Attention、全量 GPU 加载），仅修改上述 3 个参数，清理冗余：
bash
运行杀死旧进程，等待3秒确保释放资源
killall llama3-server 2>/dev/null; sleep 3
最大上下文105000 + 速度均衡优化（3090甜点配置）
cd ~ && LLAMA_SET_ROWS=0 ./llama3-server
-m /data/models/Qwen3.6-27B-Omnimerge-v4-IQ4_NLmanni.gguf
--mmproj /data/models/mmproj-Qwen_Qwen3.6-27B-f16.gguf
--host 0.0.0.0 --port 12026 --fit on
--ctx-size 105000 -n -1 \批处理优化（适配105k上下文，降低带宽压力）
--batch-size 8192 --ubatch-size 2048 \
KV缓存完全匹配105k上下文，无浪费
--cache-type-k q2_K --cache-type-v q2_K --cache-reuse 105000 \
CPU甜点线程（i5-10600 最优值，无争抢）
--parallel 1 --threads 8 --threads-batch 8 \
生成质量（不动，不影响速度）
--temp 0.85 --top_p 0.9 --top_k 24 --repeat_penalty 1.04 \
服务配置（不动）
--metrics --jinja --seed 42 --cont-batching \
思考模式（不动）
--reasoning-budget 768 --reasoning on --reasoning-format deepseek \
Hermes 45分钟缓存保留（不动）
--max-slots 8
--slot-reclaim-timeout 2700 \GPU核心加速（不动）
-ngl 99 -fa on
--memory-usage high
--max-batch-size 8192
--low-vram off
--no-penalty-off
--prompt-cache-full
--no-check-tensors
--log_file /tmp/fastllm-llm.log
四、优化后预期效果
速度：从 38 → 40~42 token/s（回升 3~4 token，接近原 65k 上下文的速度）；
上下文：完全保留 105000 最大上下文；
硬件：GPU/MEM 依然满载重合，温度稳定 47℃（不升不降）；
缓存：Hermes 本地请求 45 分钟自动续期，外部请求自动回收；
显存：依旧稳定 20.4G，不爆显存。
五、额外小贴士（针对你的硬件）
温度 47℃无需优化3090 满载运行 47℃是顶级散热水平，强行降功耗 / 风扇转速，会直接导致 GPU 降频，速度掉到 35 以下，得不偿失。
不要再提升 batch-size你已经设到 8192，是 3090 24G + 27B 模型的极限值，再大会爆显存 / 带宽溢出。
若追求极致速度可把 ctx-size 从 105000 → 95000，速度能直接回到 43 token/s，上下文仅损失 10k，几乎无感知（这是 3090 24G + 27B 模型的终极甜点配置）。
总结
掉速是105k 上下文的显存带宽物理瓶颈，不是参数错误；
仅改 3 个参数，保留最大上下文，速度拉回 40~42；
47℃满载温度完美，不用做任何降温调整；
脚本直接运行，就是 3090 24G + 27B 模型的最优均衡配置。 我直接按它的原样启动不墨迹。 -
目前看来，速度是稳的， 这里介绍一下，我用模型是 https://hf-mirror.com/ManniX-ITA/Qwen3.6-27B-Omnimerge-v4-GGUF/tree/main 模型大小 为15.8GB，按作者页面，去 https://hf-mirror.com/bartowski/Qwen_Qwen3.6-27B-GGUF 下载了 928MB的视觉文件，这些就 是权重的基础了。 我这样，是可以 用模型识别图片的，下面给出识别图片的测试。 -
美少女客串一下。
视觉能力调戏千问。
回复43 T/S，稳。
NVTOP图，截得有点晚了。 我的UBUNTU24.04，安装了cooler controld的 ，按结点温度疯狂压制，风扇不到100元吧，狠狠的给我转起来！
-
问： 我显存的峰值占用似乎在23.23G，剩下几百MB，峰值时回复速度掉到了38.5T/S，我现在是在等45分钟把我网页端 占的那些slot 释放
豆包： 先把你当前现状一句话看透
显存顶到 23.23G 只剩几百 MB 余量 = 直接踩 3090 24G 物理红线
不是算力不够，是显存完全塞满、无缓冲空余，llama.cpp 会微量把 KV 碎片往系统内存蹭、显存控制器满载拥堵，直接从 43 掉到 38.5 token/s，完全是显存溢出边界的典型降速。
你现在做法完全正确：不动 Hermes 会话，等 45 分钟超时把网页端多余 slot 自动释放，显存回落、碎片清空后，速度会自动回弹回 42~43 T/S。
现在网页端残留 slot 占着 KV 槽位，堆高了显存峰值，只要这些闲置 slot 释放掉，立马恢复满血。
一、为什么撑到 23.23G 就必掉速？
27B 模型 + mmproj 固定打底约 15.6G
多 slot 叠加 KV 缓存 + 105k 超大上下文 + q2_K KV 量化
吃到 23.23G 几乎占满 24G，没有预留显存缓冲区
llama.cpp 瞬时申请不到显存 → 内存映射 / 页交换 → 生成 token 延迟拉高 → 锁死 38.5
nvtop GPU/MEM 重合 = 带宽已经 100% 跑满，再堆 KV 只能降速
二、现在不用干等 45 分钟，可手动加速释放（不重启、不影响 Hermes）
你不用硬生生等满 45 分钟，现在做两步就能提前回落显存：
关闭网页端所有闲置对话标签，只留 Hermes；
静置 5~10 分钟不发新请求，闲置 slot 会进入完整 idle 状态；
llama.cpp 会主动压缩 KV 碎片、回收空闲槽位显存，不用等到 45 分钟超时也能回落。
重点：Hermes 的 127.0.0.1 会话只要有交互，slot 会持续续期，永远不会被回收，完全不影响你继续问问题。
三、根治方案：以后永远不让显存冲到 23.23G、稳定不掉速
核心思路：保留 Hermes 45 分钟长驻、保留 105000 大上下文，限制最大 slot 数量，卡死显存峰值不碰红线
关键改 2 个参数即可（其他全保留）
--max-slots 8 → 改成 --max-slots 4你日常就只用 Hermes + 偶尔网页端，4 个槽位完全够用；直接限制最多只开 4 个会话 KV 槽，从根源杜绝 slot 堆积撑满 23G 显存，峰值会锁在 21.5~22G，留 1G + 安全缓冲，再也不会踩内存边界掉速。
保持 --slot-reclaim-timeout 2700 不动Hermes 依旧 45 分钟续期不回收，网页端闲置照样 45 分钟自动清，逻辑不变。
顺带适配你 105k 上下文的配套小修正
--cache-reuse 105000 必须和 --ctx-size 105000 对齐（你之前已经拉了 ctx，这个要跟上）
--ubatch-size 2048 维持不变，降低瞬时 KV 显存尖峰
四、改完后的稳态效果
显存峰值锁死 21.5~22G，留有充足缓冲，不会再顶到 23.23G；
生成速度稳定 42~43 token/s，不再掉到 38.5；
Hermes 本地会话永久长驻、自动续期；
网页端闲置 slot 45 分钟自动清；
温度依旧 47℃ 完美不变，不升温、不用降功耗。
五、你现在当下建议
继续正常跟 Hermes 对话，不用停；
关掉网页端不用的对话，静置一会，等闲置 slot 逐步释放，显存回落、速度自动回弹；
下次重启服务时，把 --max-slots 8 改成 --max-slots 4 即可，一劳永逸解决显存撑满掉速问题。
我可以直接给你改好最终版完整启动脚本，你下次复制替换就行，要吗？ -
问： 我显存的峰值占用似乎在23.23G，剩下几百MB，峰值时回复速度掉到了38.5T/S，我现在是在等45分钟把我网页端 占的那些slot 释放
豆包： 先把你当前现状一句话看透
显存顶到 23.23G 只剩几百 MB 余量 = 直接踩 3090 24G 物理红线
不是算力不够，是显存完全塞满、无缓冲空余，llama.cpp 会微量把 KV 碎片往系统内存蹭、显存控制器满载拥堵，直接从 43 掉到 38.5 token/s，完全是显存溢出边界的典型降速。
你现在做法完全正确：不动 Hermes 会话，等 45 分钟超时把网页端多余 slot 自动释放，显存回落、碎片清空后，速度会自动回弹回 42~43 T/S。
现在网页端残留 slot 占着 KV 槽位，堆高了显存峰值，只要这些闲置 slot 释放掉，立马恢复满血。
一、为什么撑到 23.23G 就必掉速？
27B 模型 + mmproj 固定打底约 15.6G
多 slot 叠加 KV 缓存 + 105k 超大上下文 + q2_K KV 量化
吃到 23.23G 几乎占满 24G，没有预留显存缓冲区
llama.cpp 瞬时申请不到显存 → 内存映射 / 页交换 → 生成 token 延迟拉高 → 锁死 38.5
nvtop GPU/MEM 重合 = 带宽已经 100% 跑满，再堆 KV 只能降速
二、现在不用干等 45 分钟，可手动加速释放（不重启、不影响 Hermes）
你不用硬生生等满 45 分钟，现在做两步就能提前回落显存：
关闭网页端所有闲置对话标签，只留 Hermes；
静置 5~10 分钟不发新请求，闲置 slot 会进入完整 idle 状态；
llama.cpp 会主动压缩 KV 碎片、回收空闲槽位显存，不用等到 45 分钟超时也能回落。
重点：Hermes 的 127.0.0.1 会话只要有交互，slot 会持续续期，永远不会被回收，完全不影响你继续问问题。
三、根治方案：以后永远不让显存冲到 23.23G、稳定不掉速
核心思路：保留 Hermes 45 分钟长驻、保留 105000 大上下文，限制最大 slot 数量，卡死显存峰值不碰红线
关键改 2 个参数即可（其他全保留）
--max-slots 8 → 改成 --max-slots 4你日常就只用 Hermes + 偶尔网页端，4 个槽位完全够用；直接限制最多只开 4 个会话 KV 槽，从根源杜绝 slot 堆积撑满 23G 显存，峰值会锁在 21.5~22G，留 1G + 安全缓冲，再也不会踩内存边界掉速。
保持 --slot-reclaim-timeout 2700 不动Hermes 依旧 45 分钟续期不回收，网页端闲置照样 45 分钟自动清，逻辑不变。
顺带适配你 105k 上下文的配套小修正
--cache-reuse 105000 必须和 --ctx-size 105000 对齐（你之前已经拉了 ctx，这个要跟上）
--ubatch-size 2048 维持不变，降低瞬时 KV 显存尖峰
四、改完后的稳态效果
显存峰值锁死 21.5~22G，留有充足缓冲，不会再顶到 23.23G；
生成速度稳定 42~43 token/s，不再掉到 38.5；
Hermes 本地会话永久长驻、自动续期；
网页端闲置 slot 45 分钟自动清；
温度依旧 47℃ 完美不变，不升温、不用降功耗。
五、你现在当下建议
继续正常跟 Hermes 对话，不用停；
关掉网页端不用的对话，静置一会，等闲置 slot 逐步释放，显存回落、速度自动回弹；
下次重启服务时，把 --max-slots 8 改成 --max-slots 4 即可，一劳永逸解决显存撑满掉速问题。
我可以直接给你改好最终版完整启动脚本，你下次复制替换就行，要吗？@Jame-Huang 666
-
满了，这就 是马儿跑得慢的原因，所以问了3个AI，最后还是豆包胜，通过改chat_template, 在提示词中加入 /no think结尾，来禁止AI过度思考。
这里如果不用/no think结尾 ，起码要20多秒吧，浪费算力。
-
qwen已经被撑爆了，再继续运行没有 意义，我只好换deepseek v4 PRO,这里来个题外话，感觉生产力，还是deepseek香啊 。拿 flash狂造都可以 -
比较底层的修改，所以要慎重一些，上了pro模型 -
标签系统（全览）
| 标签 | 作用 | |------|------| | /no think | reasoning=none，不思考 casual模式默认没后缀就这个，如果确实需要LLM思考的话，用户会加/think| | /think | reasoning=默认级别 本地主会话默认啥也不输入就这个，但是如果CPU判断这是简单消息的话，要加上 /no think| | /deepp | 切 DeepSeek v4-pro，删标签，发消息（session级） | | /deepf | 切 DeepSeek v4-flash，删标签，发消息（session级） | | /qwe | 切回 Qwen 3.6 27B，删标签，发消息给 Qwen（session级） | 每个标签只在消息末尾生效。模型切换不持久（新会话默认本地 Qwen）。 处理顺序 消息到达 │ ├─ Step 0: 简单任务预判（仅主会话 + 无任何后缀标签） │ ├─ < 50 字符 │ ├─ 不含代码块（） │ ├─ 不含文件路径、复杂技术词 │ └─ 匹配简单句型（你好/什么是/帮我查/今天...） │ → 命中 → 自动追加 /no think │ ├─ Step 1: 提取末尾标签 │ 正则: /(no\s*think|think|deepp|deepf|qwe)$ │ ├─ Step 2: 冲突检查 │ /deepp /deepf /qwe 三者互斥 → 同时出现报错 │ /no think /think 二者互斥 → 同时出现报错 │ 模型标签 + 推理标签 → 可以共存 │ ├─ Step 3: 从 user_input 删除所有标签 │ ├─ Step 4: 模型切换（如有 /deepp /deepf /qwe） │ → 调用 switch_model()，session 级，不写 config │ ├─ Step 5: 决定 reasoning │ casual + auto_no_think + 无 /think → none │ 有 /no think → none │ 有 /think → 默认 │ deepseek 模式 → 不介入，保持用户设置 │ └─ Step 6: self.chat(cleaned_message) 各模式行为矩阵 | | casual | 主会话 | deepseek模式 | |--|--------|--------|-------------| | 无标签 | 自动 /no think | 自动判断简单→/no think | 深度思考（用户自控） | | /no think | reasoning=none | reasoning=none | reasoning=none | | /think | 覆盖，深度思考 | 深度思考 | 深度思考 | | /deepp | 切 v4-pro | 切 v4-pro | — | | /deepf | 切 v4-flash | 切 v4-flash | — | | /qwe | 切回 Qwen | 切回 Qwen | 切回 Qwen | 需要确认 DeepSeek 的模型名——deepseek-v4-pro 和 deepseek-v4-flash 是 API 里的实际 model ID 。我确认switch_model 的映射。
改动的文件1. ~/.hermes/config.yaml - custom_providers 加 deepseek 条目 - casual profile 加 auto_no_think: true 2. ~/.hermes/hermes-agent/cli.py - 在 self.chat()` 前插入 ~60 行：标签检测 + 模型切换 + reasoning + 简单预判 -
说说我的看法。小显存这么玩都是个 折腾。最后还是 大力出奇迹。 折腾也就是消磨了你的时间。这些经验其实都是应对这些没什么经济价值的娱乐项目。给自己找个事做。祝耍的愉快。复制你的技术再搞一遍的人就是不想打游戏。也想折腾一遍。
