---
name: local-llm-recommendation
description: 本地大模型选型与Hermes配置。当用户想装本地模型、对比模型优劣、配置Ollama+Hermes时激活。包含硬件检测→选型→配置全流程。
version: 1.0.0
---

# Local LLM Recommendation（本地大模型选型）

当用户说"装个本地模型"、"有没有适合我的"、"对比一下模型"、"怎么配Hermes+Ollama"时激活。

## 核心流程

### Step 0：先聊方案，再动手
用户偏好"先聊再动手"。不要直接执行操作，先给出方案讨论。

### Step 1：确认硬件真相
**永远不要靠印象猜硬件。** 必须实际验证：

```bash
# 内存
cat /proc/meminfo | grep MemTotal

# CPU
cat /proc/cpuinfo | grep "model name" | head -1
grep -c processor /proc/cpuinfo

# GPU/显存（唯一权威来源）
nvidia-smi --query-gpu=name,memory.total,driver_version --format=csv,noheader
```

或直接用 whichllm 一键检测（更全面）：
```bash
uvx whichllm@latest
```

### Step 2：用小搜搜模型
不要用 GitHub API、浏览器导航、或调度子任务去搜模型信息。唯一入口：
```bash
python "C:/Users/32295/.hermes/skills/anysearch-skill-2.1.0/scripts/anysearch_cli.py" search "关键词"
```

推荐搜索关键词模式：
- `"qwen3-vl:7b ollama vision model review"`
- `"best local llm chinese 8gb vram 2026"`
- `"模型名 ollama size context chinese"`

### Step 3：选型原则

#### 量化与显存匹配
| 模型大小 | Q4_K_M 占用 | 推荐显存 |
|---------|-------------|---------|
| 7-8B   | ~5-6GB      | 8GB ✅    |
| 13-14B | ~9-10GB     | 12-16GB |
| 30-32B | ~19-20GB    | 24GB    |

#### 模型选择矩阵（2026年7月）

**通用/聊天**
| 需求 | 推荐模型 | 大小 | 上下文 | 理由 |
|------|---------|------|--------|------|
| 聊天(聪明) | qwen3:8b | ~5.5GB | 128K | 8GB显存最稳妥的满血选择 |
| 聊天+看图(一个) | qwen3-vl:8b | ~6GB | 256K | 视觉+文本双强 |
| **MoE 大模型（8GB也能跑）** | **qwen3-35b-a3b** | ~6-7GB | 128K | MoE架构，总35B但每次只激活3B，比8B聪明很多 |

**MoE模型说明：** Qwen3-35B-A3B 是混合专家架构，总参数35B但推理时只激活3B参数。8GB显存下Q4量化后约6-7GB，能稳跑且速度不慢。这是2026年8GB显存用户从8B升级到更强模型的最佳跳板。来源：CSDN/AtomGit社区文章 + 知乎"8G显卡能跑的模型精选（2026年更新）"。

**视觉模型（专业看图，不要求聪明）**
| 需求 | 推荐模型 | 大小 | 显存 | 专长 |
|------|---------|------|------|------|
| 通用看图(轻量) | qwen3-vl:4b | 3.3GB | ~3GB | 同系列低版本，比8B快34%，质量降2-4% |
| 中文文档OCR | **GLM-OCR** | 2.2GB | ~2.5GB | 智谱AI，表格/印章/复杂排版，OmniDocBench 94.62分 |
| 纯文字提取(最快) | **LightOnOCR-2:1b** | 1.5GB | ~2GB | 端到端OCR，5.71页/秒 |
| 文档结构化 | **granite3.2-vision:2b** | 2.4GB | ~2.5GB | IBM出品，表格/图表/信息图提取 |

**注意：** `qwen3-vl` 系列比 `qwen2.5vl` 新一代，256K 上下文 vs 125K，且文本能力"on par with pure LLMs"。

#### 组合策略（小看图模型 + 云端聪明大模型）

当用户说"想要一个看图快的小模型配合一个聪明的大模型"时，这是推荐方案：

| 小看图模型 | 大小 | 显存 | 配合云端模型 |
|-----------|------|------|-------------|
| **qwen3-vl:4b**（3.3GB，通用） | ~3GB | ✅ RTX 5060 8GB 无压力 | deepseek-v4-flash |
| **GLM-OCR**（2.2GB，文档） | ~2.5GB | ✅ 极省 | deepseek-v4-flash |
| **LightOnOCR-2**（1.5GB，极速OCR） | ~2GB | ✅ 最省 | deepseek-v4-flash |

组合方式：本地小模型处理快速/简单/隐私相关截图，云端大模型处理需要深度理解的复杂图片。

#### 中文 bias 修正
- whichllm 的 benchmark 基于英文评测集，对 Qwen 系列中文能力评分偏低
- 中文场景下 Qwen 系列实际更强于评分数字
- Gemma/Llama 系列中文能力弱于 Qwen

### Step 4：Hermes 配置

#### Ollama provider 配置（2026年已知正确写法）
```yaml
# config.yaml custom_providers 部分
- name: ollama
  base_url: http://localhost:11434/v1
  api_key: ollama
  api_mode: chat_completions
  models:
    qwen3-vl:8b:
      context_length: 65536
```

**关键：必须用 `provider: custom` 而非 `provider: ollama`**
```yaml
# config.yaml 顶层
provider: custom
```

原因：`provider: ollama` 在 auxiliary_client.py 中未被识别，会静默回退到 OpenRouter（如果你有 OpenRouter key 的话）。

#### Ollama 上下文长度

**关键：Ollama 不一定会用模型的最大 context。** 你 `ollama pull` 的模型可能有自己的默认值，不一定等于模型实际支持的上限。**必须验证：**

```bash
ollama show qwen3:8b | grep -i -E "context|参数"
```

已知模型的实际 context 上限：

| 模型 | 支持上限 | Ollama 默认 | 差多少 |
|------|---------|------------|--------|
| qwen3:8b | **131,072** | 65,536 | 差一半 |
| qwen3-vl:4b | 32,768 | 32,768 | 匹配 |
| Llama 3.1 8B | 131,072 | 131,072 | 匹配 |
| Gemma 4 12B | 262,144 | 65,536 | 差很多 |

**Fix：用 Modelfile 创建自定义模型，强制开到上限：**

```bash
ollama create qwen3-8b-131k -f - << 'EOF'
FROM qwen3:8b
PARAMETER num_ctx 131072
EOF
```

然后用 `/model qwen3-8b-131k` 或在 config.yaml 中引用自定义模型名。

**为什么这很重要 — Hermes 会话压缩问题：**

当 Hermes 会话累积的 tokens 超过模型 context 窗口时，Hermes 会弹警告：

```
warning: Context window shrinks (1,000,000 → 65,536)
Session is ~372,832 tokens; qwen3:8b allows 65,536
(auto-compress at ~64,000)
Your next message will run preflight compression before the model replies.
```

这会导致每次发消息前先跑一次压缩（慢几秒），且早期对话内容被丢弃。**把 context 开到 131K 直接解决 70% 的"不丝滑"问题**——Session 从 37 万降到 13 万还是超，但压缩频率大幅降低。

**补充：如果还超怎么办？**
- `/new` 开新会话（最快）
- 在 Hermes config 中设置更激进的压缩阈值
- 用小搜搜 `hermes context compression settings`

### Step 5：只装一个 vs 装两个 vs 组合策略

如果用户需要看图+聊天：

| 方案 | 模型 | 显存占用 | 优点 |
|------|------|---------|------|
| 一个模型 | qwen3-vl:8b | ~6GB | 不用切，还剩2GB余量 |
| 两个本地模型 | qwen2.5vl:3b+qwen3:8b | ~2GB+~5GB | 各司其职 |
| **本地小图+云端聪明** | qwen3-vl:4b/GML-OCR + 云端大模型 | ~2-3GB | 🏆 推荐：快且聪明 |

**推荐组合策略：** 本地装一个小视觉模型（qwen3-vl:4b 或 GLM-OCR），日常看图走本地（快/免费），需要深度分析时切云端模型（deepseek-v4-flash 等）。这是速度、质量、成本的最佳平衡。

8GB 显存下两个本地模型不能同时驻留，但 Ollama 切模型会自动卸载旧模型。

## 已知陷阱

### ❌ 不要装 dericated/去对齐版
`huihui_ai/*-abliterated` 系列是粗糙的去对齐实现，指令跟随差，可能把自己当用户说话。需越狱版时用 `richardyoung/*`（Heretic方法，KL损伤小）或 `p-e-w/*-heretic`。

### ❌ 不要拿模型文件size当系统内存
6GB的GGUF ≠ 系统只有6GB RAM。这两个不相关。

### ❌ 不要同时跑两个大模型
8GB显存最多同时驻留一个7-8B模型（Q4）。两个模型=显存溢出→CPU offload→速度暴降。

### ❌ 不要忘了检查Ollama版本
新版模型可能需要新版Ollama：
- qwen2.5vl 需要 Ollama 0.7.0+
- qwen3-vl 需要 Ollama 0.12.7+

### ❌ 不要跳过三搜直接下模型
用户要求"去GitHub找找/大中小搜/调查一下"时，必须先完整搜索再决定。
不要跳步骤直接问"要下吗"/直接下。正确的搜索顺序：
小搜(AnySearch) → 中搜(wigolo) → GitHub(API/Discussions/代码搜索) → 对比后给方案。

用户说"你看着学习"=自己研究完再执行，不要每步请示。

### ❌ 不要只找官方，忽略社区大佬
用户纠正过："不一定是官方的，GitHub有很多大佬"
HF 社区大佬：bartowski(最稳), unsloth(快), richardyoung(越狱版), mradermacher(种类多)
搜索时优先找这些大佬的仓库。

### 🧠 Qwen3 Thinking Mode Token Budget Trap

Qwen3 的 thinking 模式（internal reasoning/CoT）会消耗大量 token 预算。如果 `num_predict` 设得太小，模型**只会输出 thinking 而不会输出实际回答**。

**症状：** API 返回 `"content": ""` 但 `"thinking"` 有数百字。这不是模型故障，是预算不足。

**修复：** 测试时确保 `num_predict >= 600`（复杂问题可能需要 800+）。日常使用可保持默认值。

**诊断脚本：**
```python
resp = json.loads(urlopen(req).read().decode())
print(f'Content({len(msg.get(\"content\",\"\"))}): {msg.get(\"content\",\"\")[:80]}')
print(f'Thinking({len(msg.get(\"thinking\",\"\"))}): {msg.get(\"thinking\",\"\")[:80]}')
```

0 字回答时的第一排查项。

### ⚡ Flash Attention 兼容性（Blackwell GPU 用户必读）
RTX 5060 (Compute Capability 12.0, Blackwell 架构) 在 Ollama v0.31.1 及更早版本上 Flash Attention **不可用**（启动后回答为空或超时）。

**修复：必须升级到 Ollama v0.32.1+**。
验证方式：
```bash
ollama --version  # 应 >= 0.32.1
set OLLAMA_FLASH_ATTENTION=1
ollama serve
```
FA=ON 实测效果（RTX 5060, Qwen3-8B）：TTFT −48%，速度 +36%，回答长度 +24%。
需设永久环境变量 `OLLAMA_FLASH_ATTENTION=1`，否则每次重启失效。

### 🔧 Context 尺寸优化（E-005 实验数据实测）
不要为了"以后可能会用到"而默认开大 Context。实测数据（RTX 5060 8GB, Qwen3-8B）：

| Context | TTFT | Speed | 总耗时 | 回答 |
|:-------:|:----:|:-----:|:------:|:----:|
| **4K** ⭐ | 144ms | **59.7 tok/s** | 9.5s | 223字 |
| 16K | 173ms | 31.7 tok/s | 16.5s | 145字 |
| 32K | 220ms | 20.4 tok/s | 24.1s | 73字 |

**结论：Context 每翻倍，速度降 40-50%。** 实际 Prompt 长度（而非上限）决定速度。

推荐策略：按任务配置多个 Modelfile 版本：
```bash
# fast: 聊天/问答/翻译
PARAMETER num_ctx 4096
# daily: 日常开发/代码/Agent
PARAMETER num_ctx 8192
# long: 文档/Git/论文/RAG
PARAMETER num_ctx 32768
```

### 🌡️ Temperature 优化（E-001/E-002 实验数据）
不要凭感觉或网络推荐设 temperature。实测 20 题评测结果（Qwen3-8B）：

| Temperature | 有效回答率 | 平均长度 | 排名 |
|:-----------:|:---------:|:--------:|:----:|
| **0.2** ⭐ | **90%** | **328字** | 🥇 |
| 0.4 | 80% | 280字 | 🥈 |
| 0.8 | 75% | 224字 | 🥉 |
| 0.6（默认） | 60% | 179字 | 最差 |

**结论：temperature=0.2 全面胜出。** 低温度下 Qwen3 的 thinking 模式更聚焦，输出更完整。

**注意：** 测试 autotune 时发现，无 autotune 时速度约 15-18 tok/s；加载 autotune 后提升至 ~60 tok/s。autotune 应作为本地推理标配（`pip install llm-autotune && autotune start --model 模型名`）。已验证 RTX 5060 兼容。

### 🟢 中国网络下的模型下载（含 VPN 代理检测）

#### 系统代理检测（自动找 VPN 端口）

终端 curl 不自动走系统代理，需要手动指定。先用脚本找到 VPN 代理端口：

```bash
# 方法1：查注册表（最常见，Clash/V2Ray/Trojan 都写在这）
reg query "HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings" /v ProxyServer
# 输出示例：127.0.0.1:7890

# 方法2：扫常见端口
for port in 7890 7891 10809 10808 1080 3128 8080; do
  code=$(curl -s --proxy "http://127.0.0.1:$port" \
    -o /dev/null -w "%{http_code}" "https://huggingface.co" --connect-timeout 3 2>&1)
  [ "$code" != "000" ] && echo "✅ 端口 $port 可用"
done
```

#### 带代理下载

```bash
# 通用模式
curl -L --proxy http://127.0.0.1:7890 -o file.gguf "https://huggingface.co/..."

# 设环境变量（一次性）
export https_proxy=http://127.0.0.1:7890
export http_proxy=http://127.0.0.1:7890
```

#### 国内镜像源（无需代理）

| 源 | 适用 | 地址 |
|------|------|------|
| HF Mirror | HuggingFace | `https://hf-mirror.com/...` |
| ModelScope | 阿里模型（Qwen等） | `https://modelscope.cn/...` |
| Ollama Mirror | Ollama 模型 | `set OLLAMA_MIRROR=https://docker.1panel.live` |

#### 已知陷阱

- ⚠️ `reg query` 的 `ProxyEnable=0x0` 表示系统级代理关闭，但 VPN 客户端仍可能在端口监听
- ⚠️ 即使找到代理端口，首次连接 HuggingFace 可能仍需要 5-10 秒初始化
- ⚠️ 浏览器下载通常比 curl 稳定（走系统代理栈而非 HTTP_PROXY 环境变量）
- ⚠️ 某些 VPN（如部分 SSTAP/SSR 变种）只代理浏览器不代理终端，此时只能浏览器下

### ⚠️ 中国网络下的 Ollama 下载问题（旧模式）
从中国大陆访问 Ollama 官方源（registry.ollama.ai）不稳定，常见报错：
```
Error: pull model manifest: ... read tcp ... An existing connection was forcibly closed by the remote host.
```

即使 ping 通（延迟 ~250ms），下载中仍可能被 CDN 断连。解决方法：

**方案A：国内镜像源**
```bash
set OLLAMA_MIRROR=https://docker.1panel.live
ollama pull qwen3-vl:4b
```

**方案B：开代理**
```bash
set HTTPS_PROXY=http://127.0.0.1:7890
ollama pull qwen3-vl:4b
```

**方案C：魔搭社区 ModelScope** — 国内托管
从 https://modelscope.cn 搜索模型，手动下载 GGUF。

### ⚠️ MiniCPM-V 4.6 幻觉风险警告
MiniCPM-V 4.6（1.3B）在同尺寸模型中性能最强，但真实用户测试发现：
- 凭空生成不存在的物体（"水上漂着一只鸭子"——图片里没有）
- 复杂文档OCR常有错字和遗漏
- 竖版古籍/手写混合场景质量差

来源：2026-05-21 开发者 OCR 对比测试。对于需要准确性的场景，qwen3-vl:4b 更可靠。

#### 社区 GGUF 量化大佬（按质量排序）
| 大佬 | HF 命名模式 | 特点 |
|------|------------|------|
| **bartowski** 🏆 | `bartowski/MODEL-GGUF` | **社区最知名**，多量化级别全，质量稳 |
| unsloth | `unsloth/MODEL-GGUF` | 量化快，但有时只出 Q8/Q6 |
| mradermacher | `mradermacher/MODEL-GGUF` | 量化种类多 |
| richardyoung | `richardyoung/MODEL-GGUF` | 特化 abliterated 版 |

搜索模式：`huggingface.co/bartowski/MODEL-GGUF`

#### Hermes 需要本地模型的五大要求
| # | 要求 | 原因 | 最低标准 |
|---|------|------|---------|
| ① | **工具调用** | Hermes 靠工具干活（搜索、跑代码、操作电脑） | **必须有原生 function calling** |
| ② | **上下文** | 对话+工具调用信息量大 | 至少 8K，最好 32K+ |
| ③ | **中文** | 用户全程中文沟通 | 中文理解必须好 |
| ④ | **显存** | RTX 5060 8GB | 模型 ≤ 5GB，留空间给上下文 |
| ⑤ | **速度** | 不能等太久 | 至少 10 tok/s |

**8GB VRAM 最优解排序：**
1. **Qwen3-8B Q4_K_M** (~5GB) — 2025年4月发布，原生工具调用+推理模式，131K上下文 ✅
2. Qwen2.5-7B Q4_K_M (~4.5GB) — 2024年10月，旧版但稳定
3. Llama-3.1-8B Q4_K_M (~5GB) — 中文弱 ⚠️

**不能升：** Qwen3-8B Q8_0 (8.7GB) ❌ Qwen2.5-14B Q4_K_M (~8GB) ❌ 都没空间给上下文

### 越狱版（abliterated/uncensored）模型指南
**原则：用户不主动要就不推荐。用户要越狱版时：**

| 来源 | 质量 | 说明 |
|------|------|------|
| **richardyoung/MODEL-Abliterated-GGUF** 🏆 | ⭐⭐⭐⭐ | Heretic 库去对齐，KL损伤小，已有 Q4_K_M 可直接用 |
| huihui_ai/MODEL-abliterated-v2 | ⭐⭐⭐ | 新方法去对齐，效果好于 v1，但可能损伤指令跟随 |
| DuoNeural/MODEL-Abliterated-GGUF | ⭐⭐⭐ | 另一选项 |

**推荐：** `richardyoung/Qwen3-8B-Abliterated-GGUF` 的 `qwen3-8b-abliterated-Q4_K_M.gguf`（4.7GB）。
使用与正常版相同，llama.cpp 启动命令一致。

**已知问题：** abliterated 模型可能减少但不会完全消除拒绝，且可能影响指令遵循精度。

## 用户期望管理：本地模型 vs API云端模型

这是一个必须主动处理的类问题。用户从API模型（DeepSeek v4、Kimi等）切回本地模型时，几乎一定会问"为什么这么笨"。**原因不在模型，在用户预期没对齐。** 这节教你如何正确管理这种落差。

### 核心差异一览

| 维度 | 本地模型（如Qwen3-8B） | API云端模型（DeepSeek v4 Flash） |
|------|----------------------|-------------------------------|
| 参数量 | 80亿 | 数百亿~万亿级（云端集群） |
| 算力 | 你在单机上分配多少就是多少 | 云端大规模GPU集群 + 弹性扩展 |
| 知识广度 | 训练截止日早，知识面受限 | 持续版本更新，覆盖面广 |
| 推理深度 | 简单问答/教学/代码片段够用 | 复杂逻辑/长文/多步推理更强 |
| 成本 | 零费用，无调用限制 | 按token计费 |
| 隐私 | 数据不出本机 | 数据经过第三方服务器 |
| 速度 | 受本地GPU/CPU限制 | 通常更快（云端集群） |

### 用户问"为什么这么笨"时的回应框架

**不要说：** "因为本地模型参数少/算力差/知识旧"（用户听了觉得你在找借口）

**应该说的模式：**

1. 先承认差异：「本地Qwen3-8B有80亿参数，DeepSeek云端有几百亿。参数差了10倍，深度自然不同。」
2. 给具体对比：「刚才那个问题如果让小Q（本地）答，XX方面会不如DeepSeek，但YY方面本地反而更好/够用。」
3. 再点明本地价值：「但它零费用、无限制、数据不出门。日常教学/代码/对话，完全够用。」
4. 收尾问用户意图：「要不切回本地？还是先挂着DeepSeek用？」

### 什么时候该主动切换模型

| 场景 | 推荐模型 | 理由 |
|------|---------|------|
| 日常教学/CET-4单词 | 本地 Qwen3-8B | 够用、免费、上下文128K够长 |
| 复杂代码/架构设计 | DeepSeek v4 Flash | 推理深度更强 |
| 长文分析（>50K tokens） | DeepSeek（200K上下文） | 本地模型超上下文会压缩 |
| 隐私数据 | 本地模型 | 数据不出本机 |
| 批量任务/高频率调用 | 本地模型 | 零费用，不限频 |

### 已知陷阱

❌ 不要一上来就说"本地模型本来就不如API"——用户会觉得你在贬低自己，技术落差和技术失效是两回事
❌ 不要用对比表格挡枪——用户问"为什么笨"，你先回答原因，再总结对比
❌ 不要在用户问为什么时插入成本/隐私的推销——先回答问题，再提优势
✅ 用户在DeepSeek上得到的答案质量高是正常的——直接承认差异，给出切换选项

## 本地模型定制化（Modelfile + 工具调用）

### 场景
选好模型后，需要让它懂用户场景、会调工具。适合给本地模型注入身份认知+行为规范。

### Modelfile 模式
```bash
# 1. 写 Modelfile
echo 'FROM qwen3:4b-instruct-2507-q4_K_M
SYSTEM "你是小Q，吉冠佳的助手。教单词格式..."
' > Modelfile

# 2. 建模型
ollama create my-custom-model -f Modelfile

# 3. 测试
python -c "
import urllib.request, json
data = json.dumps({'model':'my-custom-model','messages':[{'role':'user','content':'hi'}]}).encode()
req = urllib.request.Request('http://localhost:11434/api/chat',data=data)
print(json.loads(urllib.request.urlopen(req,timeout=30).read())['message']['content'])
"
```

### System Prompt 设计原则（4B模型）
- **不超过500字符**，否则模型记不住开头
- 教格式时**带一个具体示例**，比纯描述效果好
- 核心三要素：身份认知 + 关键格式 + 工具意识
- 细节知识（配置、API地址等）存在外部文件里，让模型调工具读

### 工具调用（function calling）
新版 Qwen3-2507 系列支持原生 function calling（`qwen3:4b-instruct-2507-q4_K_M` 已验证）：

```python
tools = [{
    'type': 'function',
    'function': {
        'name': 'search_web',
        'description': '搜索互联网',
        'parameters': {
            'type': 'object',
            'properties': {
                'query': {'type': 'string'}
            },
            'required': ['query']
        }
    }
}]
```

Ollama 会在响应中返回 `tool_calls` 字段，Python 脚本截获后执行对应工具，再把结果喂回给模型做第二轮回答。

### 知识库文件模式
不适合塞进 system prompt 的详细信息存在 Markdown 文件里：
- 模型不知道时会自动调用 `read_knowledge` 工具读取
- 更新文件后不需要重建模型
- 文件路径：`C:/Users/32295/Desktop/xiaoq_knowledge_base.md`

### 编码铁律
**必须用 Python 传中文给 Ollama，不能用 bash curl。** bash 传中文会乱码（模型收到乱码字后会答非所问或报错），Python 传 UTF-8 编码没问题。

### 已知限制
- 4B模型的多轮交互能力弱，每次调用都是新的（无状态）
- 复杂指令（多步流程）可能执行不完整
- 工具调用不是每次都能触发，Prompt 要写明"可以搜索"
- 连续批量调用会超时，应一个一个来

## Ollama → llama.cpp 迁移（Windows）

### 什么时候该切

| 指标 | Ollama | llama.cpp |
|------|--------|-----------|
| 后台进程 | ✅ 常驻（吃资源） | ❌ 不跑时不占 |
| 显存控制 | ❌ 自动管理 | ✅ `-ngl` 精确控制 GPU |
| 安装 | ✅ `ollama pull` | ❌ 手动下 GGUF |
| 预编译 | ✅ 官方 | ✅ GitHub Releases 全平台 |

**主要原因：** Ollama 后台常驻进程持续占用~90MB 内存和 CPU。llama.cpp 按需调用更轻量。

### 卸载 Ollama（Windows）

```bash
taskkill /F /IM ollama.exe && taskkill /F /IM "ollama app.exe"
ollama rm model1 model2              # 可选
rm -rf "$HOME/AppData/Local/Programs/Ollama"   # 程序目录
rm -rf "$HOME/.ollama"                          # 数据目录
where ollama                          # 应找不到
```

**注意：** `unins000.exe /SILENT` 和 `Get-Package | Uninstall-Package` 实测均失败。`rm -rf` 最可靠。

### 下载预编译版

1. 打开 https://github.com/ggml-org/llama.cpp/releases
2. 选最新 release，下载 `...-win-cuda-12.4-x64.zip`
3. 解压到任意目录

**中国网络：** GitHub 直连~20KB/s。推荐浏览器+梯子下载（237MB 几分钟）。

**核心命令：**
```bash
llama-server.exe -m model.gguf -ngl 99 --port 8080   # 服务器+浏览器UI
llama-cli.exe -m model.gguf -ngl 99 -p "你好" -n 256   # 命令行
```

## 参考工具
- **whichllm** ⭐5726: `uvx whichllm@latest` 自动检测硬件+推荐模型
- **多源搜索** skill: 用小搜查模型信息
- **OnlyTerp/hermes-optimization-guide** ⭐507: 他人Hermes配置实战

## 模型推荐索引

### 8GB VRAM 主力模型速查

| 优先级 | 模型 | 量化 | 大小 | 工具调用 | 中文 | 上下文 | 来源 |
|--------|------|------|------|---------|------|--------|------|
| 🥇 | **Qwen3-4B Abliterated** ⭐ (2026-07-24 验证) | Q4_K_M | **2.4GB** | ✅ 原生 | ⭐⭐⭐ | 64K 稳跑 | Melvin56 (mlabonne) |
| 🥇 | **Qwen3-8B** | Q4_K_M | ~5GB | ✅ 原生 | ⭐⭐⭐ | 131K | bartowski/richardyoung |
| 🥇 | **Qwen3-8B Abliterated** | Q4_K_M | ~4.7GB | ✅ 原生 | ⭐⭐⭐ | 131K | richardyoung |
| 🥈 | Qwen2.5-7B | Q4_K_M | ~4.5GB | ✅ 原生 | ⭐⭐⭐ | 32K | bartowski |

**Qwen3-4B vs 8B 取舍 (RTX 5060 8GB 实测):**
| 指标 | 8B (5GB) | 4B (2.4GB) | 差值 |
|------|----------|------------|------|
| VRAM idle (64K ctx) | 7.7GB | 5.2GB | 省 2.5GB |
| 速度 (64K ctx, ngl=99) | 24 t/s | ~45 t/s | +21 t/s |
| Hermes Agent 稳定性 | ❌ 频繁崩 | ✅ 稳跑 | 决定性差异 |
| 复杂推理 | ⭐⭐⭐⭐ | ⭐⭐⭐ | 略弱 |
| 工具调用 | ✅ | ✅ | 相同 |

**结论:** 如果 Hermes Agent 在 8B 上频繁崩溃(OOM+服务断连)，4B 是唯一能稳定运行 Hermes Agent 全功能的 64K 模型。2026-07-24 已验证: Melvin56/Qwen3-4B-abliterated-GGUF (Q4_K_M, 2.36GB). Hermes 配置: 8081端口, ngl=99, ctx=65536.

### 视觉模型速查

| 模型 | 大小 | 质量 | 速度 | 推荐 |
|------|------|------|------|------|
| Qwen2.5-VL-3B Q4_K_M + mmproj | ~2.6GB | ⭐⭐⭐⭐ 好 | ⚡⚡ 快 | 🌟 **推荐** |
| Moondream2 | 770MB | ⭐⭐ 一般 | ⚡ 很快 | 轻量看图 |
| Qwen2.5-VL-7B | ~5GB | ⭐⭐⭐⭐⭐ 强 | ⚡ 一般 | 显存太紧不推荐 |

### 三搜找模型流程

用户说"帮我找模型"时：

1. **先搜小搜**（AnySearch）：`site:huggingface.co MODEL GGUF`
2. **再搜中搜**（wigolo）：确认效果和推荐
3. **最后搜 GitHub API/Discussions**：看社区讨论

**必搜资源：**
- Function Calling 文档（llama.cpp docs/function-calling.md）
- WhichLLM benchmark
- 官方 llama.cpp README
- 社区大佬 HF 页面（bartowski / unsloth）