本地大模型部署 —— llama.cpp 实践记录
摘要: 使用 RTX 3060 12G 本地部署大模型的经验总结，涵盖模型下载、运行配置、接入 OpenClaw 的踩坑记录，以及显存瓶颈分析和优化思路。
环境与模型
- 显卡: RTX 3060 12G
- 推理框架: llama.cpp
- 模型: Qwen3.5 9B、Gemma 4 12B
模型下载
llama.cpp 需要 GGUF 格式 的模型文件。Qwen 官方仓库不提供 GGUF 格式，两种获取方式：
方式一：官方仓库 + 自行转换
- 安装 Git LFS：
git lfs install - 克隆官方仓库：
git clone <huggingface仓库地址> - 下载 llama.cpp 源码，使用自带的转换工具将模型转为 GGUF 格式
方式二：直接使用非官方 GGUF（本次采用）
直接从 Hugging Face 下载社区已转换好的 GGUF 文件，省去自行编译和转换的步骤，简单快捷。
运行方式
命令模式
参数较多，建议使用批处理文件/脚本运行，避免每次手动输入一长串命令。
llama-cli — 进入命令行对话界面，适合直接交互测试。
llama-server — 启动 HTTP 服务，提供兼容 OpenAI 规范的 API 接口，可供外部程序调用。
上下文窗口与显存占用
| 上下文窗口 | 显存占用（FP16） | P8 量化 |
|---|---|---|
| 128k | ~10.1G | ~9G+ |
| 64k | ~7G+ | ~6G+ |
24G 显存可稳定跑 128k 上下文，16G 显存推荐 64k，8G 以下显存建议更小的模型或更低的量化精度。
接入 OpenClaw 的问题
基础运行正常，但接入 OpenClaw 后频繁出现 超时 或 突然结束：
踩坑排查过程（点击展开）
-
怀疑 llama.cpp 配置问题
- 调整超时时间 → 无效
- 缩小上下文窗口 → 无效
- 不使用 P8 量化 → 无效
-
怀疑模型问题
- 换 Gemma 4 12B → 同样问题
-
发现规律
- 单次调用上下文超过 16k → 突然结束
- 超过 30k → 超时
根因分析
核心问题是 推理速度慢，而非显存不足。12G 显存并没有爆，跑 128k 上下文时显存占用约 10G，属于正常范围。
真正的问题在于 Qwen3.5 9B 这类小模型在大上下文窗口下的推理速度下降明显，以及 Agent 场景下上下文快速累积导致模型信息过多，推理能力跟不上。
简单说就是 RTX 3060 12G 算力不够，信息太多，脑子烧坏了。
解决方案与优化方向
| 方案 | 说明 | 可行性 |
|---|---|---|
| 升级显卡 | 换算力更强的卡（如 RTX 3090/4090） | ✅ 最直接有效 |
| 更激进量化 | 使用 Q4_K_M 甚至 Q3 量化减轻计算压力 | ⚠️ 帮助有限 |
| 限制上下文 | 手动裁剪上下文至 8k 以内 | ⚠️ 影响 Agent 能力 |
| 使用更小模型 | 换成 3B~7B 参数量的模型 | ⚠️ 提升有限 |
| 远端 API 调用 | 实在不行就调用云 API | 🤷 放弃本地 |
总结
llama.cpp 本身没有问题，Qwen3.5 9B 和 Gemma 4 12B 也都是优秀的模型。瓶颈在于 RTX 3060 12G 在中长上下文 Agent 场景下的推理速度。
在单轮对话或短上下文场景下体验良好，但一接入 OpenClaw 这类多工具链 Agent，上下文就会快速累积到 16k+，导致推理速度下降、超时甚至崩掉。
如果你也在类似的 Agent 场景中跑本地模型，建议优先考虑算力更强的显卡。