Wonderland

不聊编译，只谈参数。手把手教你配置 -ngl、-c、KV Cache 量化，在速度与显存间找到最佳平衡点。

在本地部署大模型时，llama.cpp 是绕不开的利器。但很多人在拿到模型文件（.gguf）后，面对一堆命令行参数往往不知所措。

本文将完全聚焦于运行时参数调优，帮你在不同硬件和场景下，用最少的命令榨干机器性能。

---

一、核心运行参数速查表

以下参数是每次运行几乎都会用到的“命脉”，掌握它们就掌握了调优的主动权。

参数	示例	作用与调优铁律
-m	-m llama.gguf	指定模型文件路径，必填项。
-ngl	-ngl 999	GPU卸载层数。将前 N 层扔进显存。铁律：显存够就设 999（全量进GPU），速度起飞；显存不够就手动降低，让CPU分担剩余层。
-c	-c 4096	上下文窗口。模型能记住的 Token 数量。铁律：越长越吃显存（平方级增长），够用就行，别贪多。
-t	-t 8	生成线程数。用于文本生成的CPU线程。铁律：设为电脑物理核心数（非超线程数），过大反而因线程切换变慢。
-tb	-tb 8	批处理线程数。处理初始Prompt时的线程。若不设，默认同 -t。纯CPU推理时可尝试设为物理核心的1.5倍来加速首响应。
-b	-b 1024	批处理大小。每次运算处理的最大Token数。增大可提高吞吐，但多吃显存。一般 512~1024 较稳妥。
-fa	-fa 1	Flash Attention。强烈建议无脑开启，几乎无损降低显存占用并加速推理。

---

二、灵魂拷问：模型量化了，还要量化 KV Cache 吗？

这是日常提问最高频的问题：“我用了 Q4_K_M 模型，还要不要加 -ctk q4_0 -ctv q4_0？”

直接答案：看显存，两者完全独立！

• 模型量化（如 Q4_K_M）：压缩的是模型的静态权重，加载完就固定了，占显存量 = 文件大小。
• KV Cache 量化（-ctk/-ctv）：压缩的是推理时动态生成的上下文缓存。默认是 FP16（16位浮点），长对话时这部分显存消耗巨大。

实战决策树：

1. 显存吃紧 或 上下文 > 8k → 必须开！
   • 黄金组合（强烈推荐）：-ctk q8_0 -ctv q4_0
     （Key用8-bit几乎无损，Value用4-bit极致省显存，省出空间让 -ngl 多塞几层进GPU，速度反而更快）。
   • 极限省显存：-ctk q4_0 -ctv q4_0（质量有微小损失，但能救命）。
2. 显存充裕（占用 < 80%）且上下文较短 → 不要开！
   • 保持默认 FP16，输出质量最稳，尤其在数学推理和代码生成场景下更精确。

---

三、不同场景下的“黄金参数组合”

针对不同的硬件条件，这里给出可直接套用的运行参数模板：

场景1：大显存土豪（如 24GB 显存跑 7B~13B 模型）

• 目标：追求极致速度
• 指令模板：bash./llama-cli -m model.Q4_K_M.gguf -ngl 999 -c 4096 -fa 1 -b 1024
• 解读：全量进GPU，开启Flash Attention，批处理拉高，线程随意（因为计算主要在GPU）。

场景2：长文档分析（上下文 32k）

• 目标：防止显存溢出（OOM）
• 指令模板：bash./llama-cli -m model.Q4_K_M.gguf -ngl 999 -c 32768 -fa 1 -ctk q8_0 -ctv q4_0
• 解读：拉长上下文，必开KV Cache量化保命。若仍爆显存，降低 -ngl 值或改用 -ctk q4_0。

场景3：纯CPU推理（无独立显卡）

• 目标：榨干多核性能
• 指令模板：bash./llama-cli -m model.Q4_K_M.gguf -ngl 0 -t $(nproc) -tb $(nproc) -c 2048
• 解读：-ngl 0 全部交给CPU，-t 设为物理核心数。如果首Token生成慢，可尝试将 -tb 翻倍。

场景4：显存极低（老显卡 4GB~6GB）

• 目标：先跑起来
• 策略：下载更大量化的模型（如 Q3_K_M 甚至 Q2_K），配合 -ngl 少量卸载，并强制开启 -ctk q4_0 -ctv q4_0，同时将 -c 限制在 2048 以内。

---

四、模型文件（.gguf）量化等级怎么选？

在下载模型时，后缀名决定了你的性能基准，这里给出一图流建议：

• Q4_K_M：⭐ 闭眼入的首选。速度、质量、大小的完美平衡点，适合90%的用户。
• Q5_K_M：比Q4质量高一点点（约2%），模型大约大1GB。适合显存有余且追求更高精度的用户。
• Q8_0：几乎无损，模型很大。适合做评测基准，日常使用性价比低。
• Q2_K / Q3_K：极致压缩，质量损失明显。仅在显存小于4GB的“绝境”下考虑。

---

五、运行时故障排查清单（救急用）

遇到报错别慌，按顺序排查：

现象	解决思路
CUDA out of memory	① 降低 -c → ② 开启 -ctk q8_0 -ctv q4_0 → ③ 降低 -ngl → ④ 换更大量化的模型（如Q3_K）。
生成速度慢得像蜗牛	① 确认 -ngl 是否设对了（若为0则在CPU跑，肯定慢）；② 检查 -t 是否设得太大（超过物理核心数）；③ 确认是否忘记加 -fa 1。
输出内容逻辑混乱、胡言乱语	① 检查 -c 是否超过模型原生支持长度；② 若开了 KV Cache q4_0，尝试改为 q8_0 或关闭；③ 模型量化级别太低（如Q2），换Q4_K_M重试。

---

最后的话

调优的本质是显存、速度、精度的三角博弈。没有万能神药，建议从一组保守参数（如 -ngl 999 -c 4096 -fa 1）出发，利用 nvidia-smi 观察显存变化，每次只调整一个变量（比如单独调整 -ctk 或 -ngl），直至找到最适合你硬件的那组“最优解”。

HERMES-AGENT 是一个功能强大的 CLI AI 代理工具，它能够帮助用户自动化完成各种复杂任务，包括代码开发、文件管理、网站发布、数据分析等。

## 什么是 HERMES-AGENT

HERMES-AGENT 是一个基于大语言模型的自主 AI 代理，运行在命令行环境中，它能够理解用户的自然语言指令，并调用各种工具来完成任务。它具备持久化记忆能力，可以记住用户的偏好设置和环境信息，在多个会话间保持上下文。

## 核心特性

1. **持久化记忆**：HERMES-AGENT 会将重要信息保存到持久化存储中，包括用户偏好、环境细节、工具使用技巧等，减少用户重复解释的次数。

2. **技能系统**：支持可扩展的技能系统，预内置了大量技能覆盖各种场景：
– 软件开发：代码审查、项目规划、调试
– 数据科学：Jupyter 笔记本、模型训练、可视化
– DevOps：GitHub 工作流、Webhook 管理
– 媒体处理：YouTube 字幕、音乐生成、图像处理
– 社交平台：社交媒体发帖、内容管理
– 智能家居：设备控制、自动化场景

3. **多工具支持**：集成了浏览器自动化、代码执行、文件操作、终端命令等多种工具，能够处理复杂的跨步骤任务。

4. **子代理编排**：支持生成多个子代理并行处理任务，提高工作效率。

5. **技能共享**：用户可以将成功解决问题的工作流保存为技能，供未来使用或分享给其他用户。

## 使用场景

– **自动化发布**：像现在这样，自动登录 WordPress 并发布文章，全程无需人工干预。
– **代码开发**：根据需求生成代码、调试错误、审查代码变更。
– **研究分析**：搜索文献、整理数据、生成分析报告。
– **内容创作**：撰写文章、生成图表、制作多媒体内容。
– **系统管理**：批量处理文件、管理进程、自动化日常维护任务。

## 技术特点

HERMES-AGENT 设计为模块化架构，易于扩展新的工具和技能。它支持多种模型提供商，可以根据需求选择合适的大语言模型。每个任务都可以灵活选择不同的模型来平衡性能和成本。

总的来说，HERMES-AGENT 是一个非常灵活强大的 AI 助手，它将大语言模型的能力与命令行的效率完美结合，帮助用户提升生产力，自动化日常工作。

4070

4060Ti

最近在使用apisix做一个接入网关，遇到比较多的内存相关问题：

使用apisix版本3.7.0，生产集群中遇到内存持续缓慢增长的现象，google后官方确实有个etcd timer相关的内存泄漏bug：https://github.com/apache/apisix/pull/10614

测试环境修复此bug后，压测验证仍存在内存增长问题。压测环境为

1. 模拟随机报文发送（1k～1m） -> apisix (ext-plugin <-> JavaPluginRunner) -> Server — 1k tps压测几分钟后，系统出现oom
2. 模拟固定报文发送（4k） -> apisix (ext-plugin <-> JavaPluginRunner) -> Server — 1k tps压测，openresty进程内存占用稳定

github中找到了类似的问题：https://github.com/apache/apisix/issues/8461，但官方并没有认可此bug并给修复。修改apisix/plugins/ext-plugin/init.lua后，重新进行1压测，内存已稳定。

推测为flatbuffers.builder的Clear没有清理buffer内存，为提高性能采用了复用的策略，在此场景1下会导致每个buffer都会增长到接近1m的大小，导致内存占满；

传送门：https://s.tixbay.net

总体试用下来，qwen2:7b > llama3:8b > gemma:7b > qwen:4b

qwen2是最近刚出的，中文回答、代码生成效果都不错，llama3的中文比较糟糕，gemma:7b有时候生成的内容会有重复或者缺失，qwen4b只能算个demo

• 进入管理员模式powershell

执行：Get-NetTCPSetting | Select SettingName, CongestionProvider

• 默认为：

SettingName      CongestionProvider
———–      ——————
Automatic
InternetCustom   CUBIC
DatacenterCustom CUBIC
Compat           NewReno
Datacenter       CUBIC
Internet         CUBIC

• 开启命令：

netsh int tcp set supplemental Template=Internet CongestionProvider=bbr2

netsh int tcp set supplemental Template=Datacenter CongestionProvider=bbr2

netsh int tcp set supplemental Template=Compat CongestionProvider=bbr2

netsh int tcp set supplemental Template=DatacenterCustom CongestionProvider=bbr2

netsh int tcp set supplemental Template=InternetCustom CongestionProvider=bbr2

• 开启后显示：

SettingName      CongestionProvider
———–      ——————
Automatic
InternetCustom   BBR2
DatacenterCustom BBR2
Compat           BBR2
Datacenter       BBR2
Internet         BBR2

event ancrel.10004 纳米熔炉
event ancrel.10005 空中穹顶
event ancrel.10006 次元制造机
event ancrel.10007 财富中心
event ancrel.10008 营养中心
event ancrel.10009 四级奇点

resource sr_dark_matter 20000 暗物质

getPoemText