Ollama on KnightLi的博客

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

Fri, 15 May 2026 23:27:50 +0800

最近 Claude Code 在 AI 开发工具圈很火，原因不难理解：它不像普通聊天机器人那样只回答问题，而是可以读取项目、修改代码、执行终端命令、安装依赖，并尝试自动修复报错。

真正的问题在成本。Claude 官方 API 在长上下文、大型项目、多轮 Agent 调用和自动修 Bug 场景下，Token 消耗会很快变大。于是出现了一种新的玩法：继续使用 Claude Code 的 Agent 外壳，但把模型请求转发给本地 Ollama。

这条链路的关键工具是 CC Switch。

这套方案解决什么问题

可以把它理解为：

1
2
3

Claude Code 桌面版
+ CC Switch API 转发层
+ Ollama 本地模型

Claude Code 继续负责项目操作、终端执行、文件修改和 Agent 流程；真正负责推理的大模型，则换成本地运行的 Qwen、DeepSeek、Gemma、GLM 等模型。

这样做的吸引力很直接：

不依赖 Claude 官方 API。
没有持续 Token 计费压力。
模型和数据可以留在本机。
小项目、脚本、网页、运维任务可以低成本反复试。

但它不是“免费获得 Claude Sonnet 能力”。本地模型的工程理解、长上下文稳定性和复杂任务规划，仍然会受模型能力、显存、量化版本和上下文长度限制。

基本准备

前置环境主要包括：

安装 Git。
安装 Claude Code 官方桌面版。
安装最新版 Ollama 客户端。
下载 CC Switch 开源工具。
在 Ollama 中准备合适的本地模型。

模型选择可以按显存来定。常见选择包括：

Qwen 3.6 / Qwen 3.5
Gemma4
DeepSeek R1
GLM

如果显存不大，优先选择较小参数或较低量化版本。不要一开始就用超大模型，否则很容易出现加载慢、上下文短、响应卡顿或直接显存不足。

CC Switch 关键配置

这套方案里最关键的配置项是下面几项。

请求地址：

`1`	`http://127.0.0.1:11434/v1`

API 格式：

`1`	`OpenAI Chat Completions`

认证字段选择：

`1`	`ANTHROPIC_API_KEY`

Claude Code 桌面版的自定义配置文件末尾，还需要加入注册表修改命令：

`1`	`"inferenceModels"="[\"haiku\",\"sonnet\",\"opus\"]"`

这一步的作用，是让 CC Switch 把模型名称注入到 Claude Code 里显示。Claude Code 以为自己在调用 Claude 模型，实际请求已经被 CC Switch 转发到了本地 Ollama。

Claude Code 强在哪里

很多人第一次接触 Claude Code，会把它当成高级聊天工具。但它和普通 AI 聊天客户端不太一样。

普通聊天式 AI 通常是：

1
2

你问一句
它答一句

Claude Code 更接近：

`1`	`AI + IDE + Terminal`

它可以读取项目结构，例如：

src/
components/
package.json
docker-compose.yml

然后尝试完成一串操作：

分析代码。
修改文件。
安装依赖。
执行命令。
查看报错。
再次修改。
重新运行项目。

这也是为什么很多开发者把它叫做 AI 开发 Agent。它的价值不只是“写一段代码”，而是能围绕项目状态连续行动。

Ollama 在这里扮演什么角色

Ollama 负责在本机运行模型。

这套组合的核心逻辑是：

Claude Code 负责 Agent 能力和项目操作。
CC Switch 负责把 Claude Code 的请求转成兼容本地模型的 API。
Ollama 负责实际推理。
本地模型返回结果后，再交给 Claude Code 继续执行。

所以，这不是把 Ollama 变成一个普通聊天窗口，而是把它接进 Claude Code 的工作流。

对于小型任务，这种组合会很有吸引力。比如：

生成一个 HTML 页面。
修改小型前端项目。
写自动化脚本。
处理 Docker 配置。
做 VPS 运维辅助。
生成简单工具或测试代码。

类似“帮我生成一个赛博朋克风格的个人主页网站”这类任务，本地模型可以完成项目创建、网页生成、动画和特效配置，并尝试自动运行。

体验边界在哪里

这套玩法很有意思，但边界也要说清楚。

目前本地模型仍然很难完全替代 Claude Sonnet，尤其在这些场景里：

长上下文理解。
大型工程结构分析。
多步骤推理。
复杂项目架构调整。
长时间连续修 Bug。

项目一复杂，本地模型更容易出现：

逻辑混乱。
修改错误文件。
反复修同一个 Bug。
忘记前文上下文。
对项目结构判断不稳定。

所以更合理的定位是：它适合低成本试验、小项目、脚本任务和局部代码修改；不适合一开始就把大型生产项目完全交给它自动改。

多模态兼容性还不稳定

这套链路还有一个明显问题：Vision 多模态兼容性。

虽然 Ollama 已经支持一些 Vision 模型，但 Claude Code + CC Switch + Ollama 这条链路对图片支持并不完整。常见情况是：用户上传了图片，但 AI 仍提示没有看到图片。

这并不一定是模型不支持 Vision，而是整条链路里：

Claude Code 更偏代码 Agent。
CC Switch 主要处理 API 转发。
Ollama 模型能力和请求格式还要匹配。
图片输入在不同客户端和模型之间并不总是无缝传递。

所以目前更适合的场景还是：

编程。
终端操作。
项目文件修改。
自动化脚本。

而不是：

图片理解。
OCR。
多模态聊天。
复杂视觉任务。

适合谁尝试

这套方案适合几类人：

想体验 Claude Code Agent 工作流，但不想持续消耗 Claude API 的用户。
已经在本机跑 Ollama 的本地大模型玩家。
做小项目、脚本、网页、运维工具的开发者。
想测试本地模型真实编程能力的人。
对数据本地化更敏感的用户。

不太适合：

完全不想折腾配置的人。
希望获得 Claude Sonnet 同等能力的人。
需要稳定处理大型生产代码库的人。
强依赖图片输入和多模态能力的人。

使用建议

如果要尝试，建议按低风险方式开始：

先用测试项目，不要直接接生产仓库。
选择中小模型，确认 Ollama 本身运行稳定。
先做 HTML、脚本、配置文件这类简单任务。
每次修改后自己检查 git diff。
不要让它在不确认的情况下批量删除或重构文件。
多模态任务暂时不要依赖这条链路。

如果项目比较复杂，最好把任务拆小：让它只改一个模块、一个函数、一个页面或一个配置文件。这样比“一句话让它重构整个项目”可靠得多。

小结

Claude Code + Ollama + CC Switch 的意义，不是让本地模型立刻变成 Claude Sonnet，而是把本地模型接进一个真正能操作项目的 Agent 外壳里。

这让本地 AI 开发助手第一次变得更接近真实生产力工具：它可以看项目、改文件、跑命令、修错误，而不是只在聊天框里给建议。

但它的能力上限仍然取决于本地模型本身。小项目和自动化任务会很有价值；大型工程、长上下文和复杂推理仍然需要更强模型。

如果你的目标是“零 API 成本、无 Token 焦虑、在本机反复试 AI 编程 Agent”，这套方案值得折腾。只是要记住：它是本地开发助手，不是万能自动程序员。

适合 RTX 3060 显卡运行的本地 LLM 模型推荐

Fri, 08 May 2026 09:25:24 +0800

RTX 3060 最常见的是 12GB 显存版本。它不是顶级 AI 显卡，但用来跑本地 LLM 很合适，尤其适合 7B、8B、9B、12B 级别模型。

如果只想快速选型，可以先记住一句话：

RTX 3060 12GB 优先选 8B 左右模型的 Q4_K_M 或 Q5_K_M 量化；想要更稳就选 Q4，想要更好质量再试 Q5。

不要一上来就追 32B、70B。它们即使用低比特量化和 CPU offload 能跑，速度和体验通常也不适合日常使用。

先看显存边界

RTX 3060 12GB 跑本地 LLM，真正限制是显存。

大致可以这样理解：

模型规模	推荐量化	3060 12GB 体验
3B / 4B	Q4、Q5、Q8	很轻松，速度快
7B / 8B / 9B	Q4_K_M、Q5_K_M	最推荐，质量和速度平衡好
12B / 14B	Q4_K_M	可以尝试，注意上下文不要太大
30B 以上	Q2 / Q3 或部分 offload	能折腾，但不推荐日常使用
70B 以上	极低量化或大量 CPU/RAM 参与	更像实验，不适合普通使用

本地 LLM 不只是模型文件大小占显存。上下文长度、KV cache、批处理大小、推理框架和显卡驱动都会占资源。

所以 12GB 显存并不等于可以直接加载 12GB 模型文件。更稳的做法是给系统和上下文留余量。

推荐一：Qwen3 8B

如果你主要用中文，Qwen3 8B 是 RTX 3060 上很值得优先尝试的模型。

适合场景：

中文问答。
摘要和改写。
日常知识助手。
简单代码解释。
本地 RAG。
轻量 Agent 流程。

建议选择：

1
2
3

Qwen3 8B GGUF
Q4_K_M：优先推荐
Q5_K_M：质量更好，但显存压力更高

Qwen 系列对中文更友好，日常写作、资料整理和中文指令理解通常比较顺。如果你不知道第一款本地中文模型选什么，可以先从它开始。

推荐二：Llama 3.1 8B Instruct

Llama 3.1 8B Instruct 是一个很稳的通用模型，英文能力和工具生态都比较成熟。

适合场景：

英文问答。
轻量代码辅助。
通用聊天。
文档摘要。
提示词测试。
对比不同推理工具。

建议选择：

1
2
3

Llama 3.1 8B Instruct GGUF
Q4_K_M：速度和显存更稳
Q5_K_M：回答质量更好

如果你主要处理英文资料，或者想要一个生态成熟、教程多、兼容性好的模型，Llama 3.1 8B 仍然是很好的基准选择。

推荐三：Gemma 3 12B

Gemma 3 12B 更接近 3060 12GB 的上限选择。

它比 8B 模型更吃显存，但在 Q4 量化下仍然有机会在 3060 12GB 上跑起来。适合想在单卡上尝试更大一点模型的人。

适合场景：

更高质量的通用问答。
英文内容处理。
较复杂的总结和分析。
对 8B 模型不满意时的升级尝试。

建议选择：

1
2
3

Gemma 3 12B GGUF
Q4_K_M 或官方 QAT Q4
上下文不要开太大

如果运行时爆显存，可以先降低上下文长度，或者换回 8B 模型。对 3060 来说，12B 是“能试”，不是“无脑推荐”。

推荐四：DeepSeek R1 Distill Qwen 8B

如果你想在本地体验推理风格模型，可以试 DeepSeek R1 Distill Qwen 8B 一类 8B 蒸馏模型。

适合场景：

简单推理题。
分步骤分析。
学习推理模型输出风格。
本地低成本实验。

建议选择：

1
2

DeepSeek R1 Distill Qwen 8B GGUF
Q4_K_M

需要注意，这类模型有时会输出更长的推理过程，速度和上下文占用可能比普通指令模型更明显。日常聊天不一定比 Qwen3 8B 更舒服，但用来做推理实验很合适。

推荐五：Phi / MiniCPM / 小尺寸模型

如果你的 3060 不是 12GB 版本，而是 8GB 版本，或者电脑内存也比较小，可以优先考虑 3B、4B 级别模型。

适合场景：

快速问答。
简单摘要。
嵌入到本地小工具。
低延迟聊天。
老电脑测试。

这类模型质量不一定能和 8B、12B 相比，但胜在轻、快、部署简单。

量化怎么选

本地模型常见格式是 GGUF，常见量化包括 Q4、Q5、Q6、Q8。

简单选择：

量化	特点	适合谁
Q4_K_M	体积小，速度好，质量够用	3060 首选
Q5_K_M	质量更好，占用更高	8B 模型可以试
Q6 / Q8	更接近原始质量，占用更大	小模型或显存宽裕时
Q2 / Q3	很省显存，但质量下降明显	大模型折腾用

对 RTX 3060 12GB 来说，最实用的是：

1
2
3

8B 模型：Q4_K_M 或 Q5_K_M
12B 模型：优先 Q4_K_M
更大模型：不建议作为日常主力

用什么工具运行

新手可以从 Ollama 开始，优点是安装和运行简单。

常见命令形式：

1
2

ollama run qwen3:8b
ollama run llama3.1:8b

如果想更细地控制 GGUF 文件、GPU layers、上下文长度，可以用 llama.cpp 或基于 llama.cpp 的图形工具。

常见选择：

Ollama：最省心，适合新手。
LM Studio：图形界面友好，适合手动下载和切换模型。
llama.cpp：控制最细，适合折腾性能。
text-generation-webui：功能多，适合测试不同后端。

如果只是本地聊天和简单问答，Ollama 或 LM Studio 就够了。

上下文不要开太大

很多模型宣传支持很长上下文，但 RTX 3060 运行时不要盲目开到最大。

上下文越长，KV cache 占用越高，显存压力也越大。即使模型能加载，长上下文也可能导致速度下降。

建议：

1
2
3

普通聊天：4K 到 8K
文档摘要：8K 到 16K
长文档 RAG：优先切片，不要硬塞全文

3060 更适合“中等上下文 + 好模型 + 好检索”，不适合把几十万 token 一次性塞进去。

不同用途怎么选

如果你主要写中文：

1
2

优先：Qwen3 8B Q4_K_M
备选：DeepSeek R1 Distill Qwen 8B

如果你主要写英文：

1
2

优先：Llama 3.1 8B Instruct Q4_K_M
备选：Gemma 3 12B Q4_K_M

如果你想跑得快：

1
2
3

3B / 4B 模型
8B Q4_K_M
上下文控制在 4K 到 8K

如果你想质量更好：

1
2
3

8B Q5_K_M
12B Q4_K_M
接受速度变慢

如果你想写代码：

1
2

8B 代码模型可以辅助解释和小改动
复杂工程任务仍建议用云端强模型

本地 3060 模型适合做代码解释、函数补全、小脚本生成和离线辅助；大型项目重构、复杂 bug、跨文件 Agent 任务，不要期待它达到 Claude Sonnet 或 GPT-5 级别。

3060 本地 LLM 的合理预期

RTX 3060 12GB 的定位很清楚：它适合把本地 LLM 从“玩具”变成“日常可用工具”，但不是让你在家里复刻顶级云端模型。

它的优势是：

成本低。
显存比 8GB 卡宽裕。
8B 模型体验不错。
可以离线使用。
适合隐私敏感资料的本地处理。

它的限制是：

大模型很难流畅。
长上下文会吃显存。
推理速度不如高端卡。
本地小模型复杂推理能力有限。
多模态和 Agent 工作流会更吃资源。

所以最稳的路线是：用 8B 模型做日常本地助手，用 12B 模型做质量尝试，复杂任务交给云端模型。

小结

RTX 3060 12GB 最推荐的本地 LLM 选择是：

中文通用：Qwen3 8B Q4_K_M
英文通用：Llama 3.1 8B Instruct Q4_K_M
更高质量尝试：Gemma 3 12B Q4_K_M
推理实验：DeepSeek R1 Distill Qwen 8B Q4_K_M
低显存快速体验：3B / 4B 小模型

量化优先选 Q4_K_M，8B 模型可以尝试 Q5_K_M。工具优先从 Ollama 或 LM Studio 开始。

不要把 3060 当成大模型服务器。把它当成本地知识助手、隐私文档处理器、轻量代码助手和模型实验卡，会更符合它的实际能力。

参考链接

Qwen3 8B GGUF：https://huggingface.co/Qwen/Qwen3-8B-GGUF
Llama 3.1 8B GGUF：https://huggingface.co/macandchiz/Llama-3.1-8B-Instruct-GGUF
Gemma 3 12B GGUF：https://huggingface.co/unsloth/gemma-3-12b-it-GGUF
llama.cpp：https://github.com/ggml-org/llama.cpp
Ollama：https://ollama.com

解决 Ollama 使用 CPU 而不使用 GPU 运算的问题

Fri, 24 Apr 2026 18:30:00 +0800

本地跑大模型时，最让人困惑的一类问题就是：机器明明有显卡，Ollama 却还是主要吃 CPU，速度也慢得离谱。

先说结论，这类问题通常不是单一原因。最常见的几类分别是：

Ollama 根本没有识别到可用 GPU
驱动、ROCm 或 CUDA 环境没装对
Ollama 服务启动时没有继承正确环境变量
模型太大，实际已经退回到 CPU 或 CPU/GPU 混合加载
AMD 平台存在额外兼容性问题，比如 ROCm 版本、gfx 代号或设备可见性设置不对

下面按最省时间的顺序排查。

1. 先确认是不是“真的没用 GPU”

最直接的方法是看：

`1`	`ollama ps`

重点看 PROCESSOR 一列。

100% GPU：说明模型完整跑在显卡上
100% CPU：说明完全没用上显卡
48%/52% CPU/GPU 这类结果：说明模型部分进显存、部分落到系统内存

如果你看到的是 100% CPU，后面就该重点查环境和服务配置。
如果看到的是混合加载，那不一定是“显卡没生效”，更可能是显存不够。

2. 先排除最常见的误区：模型装不进显存

很多人以为只要装了 GPU，Ollama 就一定会全显卡推理。实际上不是。

如果模型太大、上下文太长，或者机器上已经有别的模型占着显存，Ollama 很可能会退回到：

部分 GPU + 部分 CPU
直接 100% CPU

这时候可以先做两个最简单的验证：

换一个更小的模型测试
比如先用 4B、7B 这类小模型，而不是一上来就跑更大的参数量。
卸载其他已加载模型后再试
先看 ollama ps，确认没有别的模型占着显存。

如果小模型能上 GPU，大模型不行，问题往往就不在驱动，而在显存容量。

3. 检查显卡驱动和底层环境是不是可用

如果连小模型都只能跑 CPU，下一步就该看底层环境。

NVIDIA 方向

先确认驱动正常，系统能看到显卡。常见检查方式包括：

`1`	`nvidia-smi`

如果这里都报错，Ollama 基本不可能正常使用 GPU。

AMD / ROCm 方向

如果你是 AMD GPU，尤其是 ROCm 环境，重点先看：

1
2

rocminfo
rocm-smi

如果这些工具都不能正常列出设备，说明问题还在 Ollama 之前，先不要继续折腾应用层。

对 AMD 来说，最常见的问题不是“有没有装驱动”，而是：

ROCm 版本和系统版本不匹配
当前 GPU 架构支持不完整
设备虽然存在，但运行环境没有正确暴露给 Ollama

4. 重启 Ollama 服务，不要只重开终端

这是非常高频的坑。

很多人装完驱动、改完环境变量、补完 ROCm 之后，只是重新开了一个终端，然后直接继续 ollama run。但如果 Ollama 是以后台服务方式运行，它很可能还在用旧环境。

所以更稳的做法是：

完整重启 Ollama 服务
必要时直接重启系统

如果你是在 Linux 上以服务方式运行，通常要确认服务进程已经重新拉起，而不是沿用之前的旧进程。

5. 检查服务环境变量有没有真正传进去

这一步在 AMD ROCm 环境尤其重要。

有些机器在终端里手动执行命令没问题，但 Ollama 服务还是只跑 CPU，原因是服务进程没有拿到你在 shell 里设置的变量。

常见需要关注的变量包括：

1
2

ROCR_VISIBLE_DEVICES
HSA_OVERRIDE_GFX_VERSION

其中：

ROCR_VISIBLE_DEVICES 用来限制或指定 ROCm 能看到哪些 GPU
HSA_OVERRIDE_GFX_VERSION 常见于某些 AMD 平台兼容性处理

如果你只是在当前终端里临时 export 了变量，但 Ollama 是 systemd、桌面后台服务或其他守护进程启动的，这些变量未必会生效。

也就是说，终端里“看起来已经设置好了”，不代表 Ollama 真的拿到了。

6. AMD 平台重点看 ROCm 兼容性

从公开页面信息看，这个问题对应的视频主题本身就落在 AMD Max+ 395、strix halo、AMD ROCm 这条线上。
这类环境里，Ollama 不走 GPU，往往比 NVIDIA 平台更依赖版本匹配。

可以优先排查下面几项：

ROCm 版本是否适合当前系统和当前显卡
当前 GPU 是否属于 ROCm 支持较好的架构范围
是否需要补 HSA_OVERRIDE_GFX_VERSION
是否是旧版 Ollama 或旧版底层推理库导致兼容问题

如果你已经确认 rocminfo 正常、GPU 也能被系统识别，但 Ollama 仍然只跑 CPU，那大概率要回到版本组合上重新检查，而不是继续盲目调模型参数。

7. Docker、WSL 或远程环境要额外检查设备映射

如果你不是直接在裸机跑，而是在下面这些环境里运行：

Docker
WSL
远程容器
虚拟化环境

那还要多看一层：GPU 设备有没有真正暴露进去。

典型现象是：

宿主机能看到 GPU
容器里 Ollama 却只能跑 CPU

这时要先确认不是 Ollama 本身的问题，而是容器或子系统根本没拿到 GPU 访问权限。

8. 最后再看日志，而不是一开始就瞎猜

如果前面都查过了，最有效的做法不是继续反复重装，而是直接看 Ollama 启动日志和运行日志。

重点看两类信息：

有没有识别到 GPU
有没有出现驱动、库加载、设备初始化失败之类的报错

只要日志里明确出现类似“未找到兼容 GPU”或“初始化 ROCm/CUDA 失败”，排查方向就会立刻清晰很多。

排查顺序

如果你只想记最短路径，可以按这个顺序来：

ollama ps 看现在到底是 GPU、CPU 还是混合加载
换一个更小的模型，排除显存不够
用 nvidia-smi、rocminfo、rocm-smi 先确认底层环境正常
完整重启 Ollama 服务
检查服务环境变量，尤其是 AMD 的 ROCR_VISIBLE_DEVICES、HSA_OVERRIDE_GFX_VERSION
如果是 Docker / WSL，再检查设备映射
最后看日志定位具体报错

Ollama 多显卡使用笔记：显存叠加、GPU 选择和常见误区

Sun, 19 Apr 2026 00:18:00 +0800

折腾 Ollama 本地推理时，经常会遇到类似问题：我现在有一张显卡，主板还有空 PCIe 槽，再加几张 GPU 对 Ollama 有帮助吗？多显卡是否必须同型号？显存能不能叠加？会不会像训练框架那样多卡并行加速？

这篇整理一下 Ollama 多显卡的实际行为。重点先说结论：

Ollama 支持多 GPU。
多 GPU 最大价值通常是让更大的模型放进总显存，而不是线性提升 token/s。
默认策略下，如果模型能完整放进某一张 GPU，Ollama 倾向于放在单卡上。
如果模型无法完整放进单张 GPU，Ollama 会把模型分布到可用 GPU 上。
不同型号 GPU 可以被 Ollama 看到并使用，但性能和分配效果不一定理想。
不需要 SLI / NVLink 才能用多卡。
想限制 Ollama 使用哪些 GPU，需要用 CUDA_VISIBLE_DEVICES、ROCR_VISIBLE_DEVICES 或 GGML_VK_VISIBLE_DEVICES。

官方行为：先单卡，放不下再多卡

Ollama FAQ 里对多 GPU 加载逻辑说得比较直接：加载新模型时，Ollama 会估算模型所需 VRAM，并和当前可用显存比较。如果模型能完整放进某一张 GPU，它会加载到那张 GPU 上；如果单张 GPU 放不下，才会分布到所有可用 GPU 上。

这个策略的原因是性能。单卡加载通常能减少推理时跨 PCIe 总线的数据传输，因此往往更快。

所以不要把 Ollama 的多 GPU 理解成“有几张卡就自动几倍加速”。更准确的理解是：

小模型能进单卡：通常单卡跑。
大模型单卡放不下：跨多卡分层加载。
显存仍不够：一部分会落到系统内存，速度会明显下降。

可以用下面命令确认模型到底加载到了哪里：

`1`	`ollama ps`

输出里的 PROCESSOR 会显示类似：

1
2
3

100% GPU
48%/52% CPU/GPU
100% CPU

如果看到 48%/52% CPU/GPU，说明已经有一部分在系统内存里了。此时多加 GPU 或换更大显存的卡，通常比继续依赖 CPU/RAM 更有意义。

多 GPU 不是简单叠算力

本地大模型推理和游戏里的 SLI 不是一回事。Ollama 多卡时，更常见的是把模型的不同层或张量放到不同设备上。这样可以用多张卡的显存装下更大的模型，但推理过程中仍然可能需要设备之间传递数据。

因此，多 GPU 带来的收益通常分两种：

显存收益：更容易装下大模型，或者避免落到 CPU/RAM。
性能收益：只有在原本单卡装不下或严重混 CPU 时，提升才会很明显。

如果一个 8B 或 14B 模型本来就能完整放进单张 3090，强行拆到两张卡不一定更快，甚至可能因为跨卡传输变慢。Ollama 官方默认“能单卡就单卡”的策略，就是为了避免这类不必要的跨 PCIe 开销。

不需要 SLI 或 NVLink

Ollama 多 GPU 不依赖 SLI。多张普通 PCIe GPU 只要驱动和 Ollama 能识别，就可以被调度。

NVLink 或更高 PCIe 带宽可能对某些跨卡场景有帮助，但它不是 Ollama 多 GPU 的前提条件。很多二手 GPU 服务器或工作站，靠普通 PCIe 多卡也能跑。

真正要注意的是 PCIe 带宽。x1、x4、x8、x16 的差异会影响模型加载到显存的速度；如果频繁切换大模型，PCIe 链路会更容易成为瓶颈。模型加载完成后，生成阶段受 PCIe 的影响通常会小一些，但跨卡分层仍然可能带来额外开销。

比较稳的建议是：

能用 x16 / x8 就不要用矿卡 x1 转接。
大模型频繁切换时，PCIe 带宽更重要。
如果模型长期常驻显存，PCIe 带宽瓶颈会相对不明显。
多卡机器要重点看主板 PCIe 拓扑和 CPU 直连通道。

如何限制 Ollama 使用哪些 NVIDIA GPU

NVIDIA 多卡环境下，用 CUDA_VISIBLE_DEVICES 控制 Ollama 能看到哪些卡。

临时运行：

`1`	`CUDA_VISIBLE_DEVICES=0,1 ollama serve`

只让 Ollama 用第二张卡：

`1`	`CUDA_VISIBLE_DEVICES=1 ollama serve`

强制不用 NVIDIA GPU，可以给一个无效 ID：

`1`	`CUDA_VISIBLE_DEVICES=-1 ollama serve`

官方文档提醒，数字 ID 的顺序可能变化，更可靠的是用 GPU UUID。先查看 UUID：

`1`	`nvidia-smi -L`

输出类似：

1
2

GPU 0: NVIDIA GeForce RTX 3090 (UUID: GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx)
GPU 1: NVIDIA GeForce RTX 3070 (UUID: GPU-yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy)

然后指定 UUID：

`1`	`CUDA_VISIBLE_DEVICES=GPU-xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx ollama serve`

如果 Ollama 是 Linux systemd 服务安装的，需要写到服务环境变量里：

`1`	`sudo systemctl edit ollama.service`

加入：

1
2

[Service]
Environment="CUDA_VISIBLE_DEVICES=0,1"

然后重载并重启：

1
2

sudo systemctl daemon-reload
sudo systemctl restart ollama

AMD 和 Vulkan 的选择变量

AMD ROCm 环境下，用 ROCR_VISIBLE_DEVICES 控制可见 GPU：

`1`	`ROCR_VISIBLE_DEVICES=0,1 ollama serve`

如果要强制不用 ROCm GPU，也可以用无效 ID：

`1`	`ROCR_VISIBLE_DEVICES=-1 ollama serve`

Ollama 官方 GPU 文档还提到，如果用实验性的 Vulkan 支持，可以通过 GGML_VK_VISIBLE_DEVICES 选择 Vulkan GPU：

`1`	`OLLAMA_VULKAN=1 GGML_VK_VISIBLE_DEVICES=0 ollama serve`

如果 Vulkan 设备有问题，可以禁用：

`1`	`GGML_VK_VISIBLE_DEVICES=-1 ollama serve`

AMD 多卡比 NVIDIA 更容易遇到驱动、ROCm 版本、GFX 版本支持的问题。官方文档中也提到 Linux 下 ROCm 驱动版本、HSA_OVERRIDE_GFX_VERSION 等兼容性处理。多张不同代 AMD 卡混用时，先确认每张卡是否单独可用，再考虑多卡。

Docker 里怎么暴露多张 GPU

如果用 Docker 跑 Ollama，NVIDIA 环境通常需要先安装 nvidia-container-toolkit，然后用 --gpus 暴露设备。

暴露全部 GPU：

docker run -d \
  --gpus=all \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

只暴露指定 GPU：

docker run -d \
  --gpus '"device=0,1"' \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

也可以结合环境变量：

docker run -d \
  --gpus=all \
  -e CUDA_VISIBLE_DEVICES=0,1 \
  -v ollama:/root/.ollama \
  -p 11434:11434 \
  --name ollama \
  ollama/ollama

如果容器里 nvidia-smi 看不到卡，Ollama 也不可能用到 GPU。先排查 Docker GPU passthrough，再排查 Ollama。

`OLLAMA_SCHED_SPREAD` 是什么

在一些多 GPU 配置讨论里，会看到 OLLAMA_SCHED_SPREAD=1 或 OLLAMA_SCHED_SPREAD=true。它和 Ollama 的调度策略有关，常被用于希望模型或请求更分散地利用多张 GPU 的场景。

可以这样设置：

`1`	`OLLAMA_SCHED_SPREAD=1 ollama serve`

或者 systemd：

1
2

[Service]
Environment="OLLAMA_SCHED_SPREAD=true"

不过它不是万能开关。开启后并不等于 token/s 线性增长，也可能因为多个模型同时加载、显存估算、上下文长度和 KV cache 增长导致 OOM。官方 FAQ 的核心策略仍然是：如果单 GPU 能完整容纳模型，单 GPU 通常更高效；单 GPU 放不下时才跨多 GPU。

所以建议把 OLLAMA_SCHED_SPREAD 当成高级调度实验项，而不是多卡必开项。先理解默认行为，再根据实际 ollama ps、日志和 nvidia-smi 观察结果调整。

怎么观察多卡是否真的用上

常用观察命令：

`1`	`ollama ps`

`1`	`watch -n 0.5 nvidia-smi`

查看 Ollama 服务日志：

`1`	`journalctl -u ollama -f`

如果使用 Docker：

`1`	`docker logs -f ollama`

你需要关注：

Ollama 是否发现兼容 GPU。
模型是否显示 100% GPU 或 CPU/GPU 混合。
每张卡显存是否有占用。
加载模型时是否多卡显存同时增长。
生成时 token/s 是否比 CPU/RAM 混跑明显改善。
是否频繁 OOM 或卸载模型。

如果只看 GPU 利用率，很容易误判。LLM 推理时 GPU 利用率不一定长期满载，尤其是多卡、低 batch、小上下文、慢 CPU 或慢 PCIe 环境下。

常见误区

误区 1：两张 12GB 显卡等于一张 24GB 显卡

不完全等价。多卡可以让模型跨设备放置，但跨卡访问有额外开销。它能解决“放不下”的问题，不一定等价于单张大显存卡的速度和稳定性。

误区 2：不同型号显卡不能混用

不一定。只要驱动、计算能力和运行库都支持，Ollama 可以看到多张 GPU。但混用时，速度通常受较慢卡、较小显存和 PCIe 拓扑影响。最稳的多卡配置仍然是同型号、同显存、同代驱动支持良好的卡。

误区 3：多卡一定比单卡快

不一定。如果模型能完整放进单张快卡，单卡可能更快。多卡主要适合大模型、长上下文、单卡显存不够的情况。

误区 4：必须有 NVLink / SLI

不需要。普通 PCIe 多卡也能被 Ollama 使用。NVLink 不是前提。

误区 5：加 GPU 后不用重启服务

不一定。Linux systemd 服务、Windows 后台应用、Docker 容器都可能需要重启，才能重新识别设备和环境变量。

选卡建议

如果目标是 Ollama 本地推理，优先级大致是：

单卡显存越大越省心。
同型号多卡比混合多卡更容易排错。
PCIe 通道越完整，加载大模型越舒服。
老卡要先确认 CUDA compute capability 或 ROCm 支持。
多卡电源、散热和机箱风道要提前算清楚。

对于预算有限的二手平台：

双 3090 仍然是很常见的大显存方案。
P40 / M40 这类老 Tesla 显存大，但功耗、散热、驱动和性能都要权衡。
4070 / 4070 Ti 这类新卡能效好，但单卡显存容量限制更明显。
多张 8GB 老卡能折腾，但不建议为了大模型长期使用。

小结

Ollama 多显卡支持可以理解成“显存扩展优先，性能加速其次”。如果模型能完整放进一张 GPU，默认单卡通常更快；如果单卡放不下，多卡可以把模型分布到多张 GPU 上，避免大量落到 CPU/RAM，从而让大模型变得可用。

实际配置时，先用 ollama ps 看模型加载位置，再用 nvidia-smi 或 ROCm 工具观察显存占用。需要限制 GPU 时，NVIDIA 用 CUDA_VISIBLE_DEVICES，AMD ROCm 用 ROCR_VISIBLE_DEVICES，Vulkan 用 GGML_VK_VISIBLE_DEVICES。如果在 Docker 中运行，先确保容器层面能看到 GPU。

多卡不是魔法。它能帮你装下更大的模型，但不保证线性加速。真正稳定好用的路线，仍然是尽量选大显存单卡或同型号多卡，并把驱动、PCIe、电源、散热和模型量化一起考虑。

参考链接

Ollama FAQ：How does Ollama load models on multiple GPUs?：https://github.com/ollama/ollama/blob/main/docs/faq.mdx
Ollama GPU 文档：Hardware support / GPU Selection：https://github.com/ollama/ollama/blob/main/docs/gpu.mdx
Ollama Docker Hub：https://hub.docker.com/r/ollama/ollama
NVIDIA Container Toolkit：https://github.com/NVIDIA/nvidia-container-toolkit

Windows 用 WSL + Ollama 本地部署 Hermes Agent，并接入 Telegram

Sat, 18 Apr 2026 00:48:22 +0800

如果你想在 Windows 上尽量低门槛地跑 Hermes Agent，一个比较顺手的路径是：

宿主系统继续用 Windows
在 WSL 里跑 Ubuntu
用 Ollama 提供本地模型
让 Hermes Agent 直接连接本地 Ollama 接口

这样做的好处是环境相对干净，命令大多按 Linux 方式执行，同时又不需要单独准备一台 Linux 机器。

整体流程

这套部署可以拆成 5 步：

启用 WSL 并安装 Ubuntu
在 Ubuntu 里补齐 Python、Node.js、Git 等运行环境
安装 Ollama 并拉取本地模型
安装 Hermes Agent，再接入 Telegram

如果你只想先把 Hermes Agent 跑起来，其实做到第 4 步就已经接近完成了。

1. 安装 WSL 和 Ubuntu

在管理员权限的 PowerShell 里执行：

`1`	`wsl --install`

安装完成后重启电脑，然后继续安装 Ubuntu：

`1`	`wsl --install -d Ubuntu`

之后打开 Windows Terminal，切到 Ubuntu 环境，后续命令基本都在这里执行。

2. 更新 Ubuntu，并安装基础环境

先更新系统：

1
2

sudo apt update
sudo apt upgrade -y

然后安装 Python、解压工具、Node.js 和 Git。

安装 Python

`1`	`sudo apt install python3-pip python3-venv -y`

安装 zstd

`1`	`sudo apt install -y zstd`

安装 Node.js

1
2

curl -fsSL https://deb.nodesource.com/setup_22.x | sudo -E bash -
sudo apt install -y nodejs

安装 Git

1
2

sudo apt update
sudo apt install -y git

安装完成后可以顺手检查一下：

1
2
3

node -v
npm -v
git --version

3. 安装 Ollama，并拉取 Gemma 4

安装 Ollama：

`1`	`curl -fsSL https://ollama.com/install.sh \| sh`

如果你打算给 Hermes Agent 配一个本地模型，可以直接从 Gemma 4 开始。

例如：

`1`	`ollama run gemma4:e4b`

如果机器资源更弱，也可以试：

`1`	`ollama run gemma4:e2b`

更大的版本还有：

1
2

ollama run gemma4:26b
ollama run gemma4:31b

对大多数 Windows + WSL 的普通机器来说，gemma4:e4b 通常是一个更实际的起点。

4. 安装并配置 Hermes Agent

安装命令：

`1`	`curl -fsSL https://raw.githubusercontent.com/NousResearch/hermes-agent/main/scripts/install.sh \| bash`

安装完成后，给它指定 Ollama 的本地接口：

`1`	`http://127.0.0.1:11434`

模型名填你本地实际在用的那个，例如：

`1`	`gemma4:e4b`

如果安装脚本要求刷新 shell，可以执行：

`1`	`source ~/.bashrc`

Hermes Agent 常用命令

平时最常用的是下面几个：

启动

hermes

重新进入配置

`1`	`hermes setup`

配置聊天平台网关

`1`	`hermes setup gateway`

更新

`1`	`hermes update`

接入 Telegram 的基础步骤

如果你要让 Hermes Agent 通过 Telegram 收发消息，核心还是先跑一遍：

`1`	`hermes setup gateway`

然后准备 Telegram 侧需要的两个东西：

用 BotFather 创建机器人
用 @userinfobot 获取你的 User ID

拿到这些基础信息后，再按 Hermes Agent 的网关配置继续填入即可。

这一套方案适合什么人

这套方式比较适合下面几类用户：

平时主力系统就是 Windows
不想单独折腾完整 Linux 主机
想先把本地 Agent 跑通，再慢慢扩展聊天平台接入
希望优先用本地模型，不依赖云端 API

如果你只是想本地体验一个 Agent，而不是一开始就做复杂生产部署，这条路线已经足够实用。

需要注意的几个点

WSL 本质上还是一层兼容环境，极端场景下稳定性未必和原生 Linux 完全一样
大模型能不能跑得顺，最终还是取决于你的内存、显存和 CPU / GPU 条件
gemma4:e4b 虽然是比较现实的起点，但具体体验还是要看机器配置
Hermes Agent 的聊天平台接入属于“能力扩展”，先把本地模型链路跑通，再加 Telegram，会更稳

结论

如果你想在 Windows 上尽量简单地本地部署 Hermes Agent，比较顺的顺序就是：

WSL -> Ubuntu -> Ollama -> Gemma 4 -> Hermes Agent -> Telegram

先把本地模型跑通，再做网关接入，成功率会高很多。
对大多数用户来说，这比一上来就堆很多组件更容易排错，也更适合后续继续扩展。

Windows 局域网访问 Ollama API 设置指南

Sat, 11 Apr 2026 16:43:52 +0800

如果你希望局域网内其他设备访问本机 Ollama API，可以按下面步骤配置。

设置监听端口

先将 Ollama 监听地址改为所有网卡：

OLLAMA_HOST=0.0.0.0:11434

打开防火墙

打开防火墙高级设置后，新建一条入站规则并放行目标端口（例如 8080）：

按下 Win + S，搜索并打开“Windows Defender 防火墙”。
点击“高级设置”。
选择“入站规则” -> “新建规则…”。
规则类型选“端口”，点击“下一步”。
选择协议（通常是 TCP），在“特定本地端口”输入要开放的端口号（例如 8080），点击“下一步”。
选择“允许连接”，点击“下一步”。
在“配置文件”中勾选“域”“专用”“公用”，点击“下一步”。
为规则命名（例如 OpenPort8080），点击“完成”。

运行 Ollama

Ollama run 模型

通过 API 访问模型

curl http://192.168.x.xxx:11434/api/generate -d '{
  "model": "gemma4",
  "prompt": "这个是什么模型?"
}'

Gemma 4 本地调用指南：从一键运行到开发集成

Fri, 10 Apr 2026 22:54:17 +0800

如果你想在本地调用 Gemma 4（Google 2026 年发布的新一代开源模型），可以按需求从这四类方案里选。

1) 最快上手：Ollama（推荐）

这是门槛最低的方式，适合快速测试、日常对话和本地 API 调用。

`1`	`ollama run gemma4`

特点：

Win/Mac/Linux 都可用
自动处理硬件加速
提供兼容 OpenAI 风格的本地 API

2) 图形界面：LM Studio / Unsloth Studio

如果你更习惯桌面 GUI（类似 ChatGPT），这两类工具更顺手。

LM Studio：可直接搜索和下载 Hugging Face 上的 Gemma 4 量化模型（如 4-bit、8-bit），并查看资源占用。
Unsloth Studio：除了推理，也支持低显存微调。对 6GB-8GB 显存机器更友好。

3) 低配与极致控制：llama.cpp

适合老机器、纯 CPU 场景，或希望深度控制推理参数的用户。

你可以使用 .gguf 模型文件配合量化版本，在更低硬件门槛下运行 Gemma 4。

4) 开发集成：Transformers / vLLM

如果你要把 Gemma 4 接进自己的应用：

Transformers：适合 Python 项目内直接加载模型
vLLM：适合高性能 GPU 场景和高吞吐推理服务

快速选型

需求	推荐工具	硬件门槛
我只想马上跑起来	Ollama	低（自动适配）
我更喜欢图形界面	LM Studio	中
显存很紧张（6GB-8GB）	Unsloth / llama.cpp	低
我要做本地 AI 应用开发	Ollama / Transformers / vLLM	中到高
我要做微调训练	Unsloth Studio	中到高

模型尺寸建议

Gemma 4 有多种尺寸（如 E2B、E4B、31B）。

普通办公本优先选量化后的 E2B / E4B
显存更充足时再尝试更大版本

Ollama 云模型是什么，怎么用

Thu, 09 Apr 2026 18:42:32 +0800

如果你平时用 Ollama 跑本地模型，应该很容易理解云模型。

区别只有一个核心点：
本地模型是在你的电脑上推理，云模型是在 Ollama 的云端推理，再把结果返回给你。

云模型是什么

Ollama 云模型保留了 Ollama 的调用方式，但把计算位置从本地换到了云端。

这样做的好处是：

本地硬件压力更小
更容易使用本地机器跑不动的大模型
仍然可以沿用熟悉的 Ollama 工作流

和本地模型的区别

对比项	本地模型	云模型
运行位置	本机	云端
硬件要求	高	低
延迟	更低	受网络影响
隐私性	更强	请求会发送到云端

如果你更在意隐私、低延迟和离线使用，本地模型更合适。
如果你本地硬件不够，但又想体验更大的模型，云模型更方便。

怎么识别云模型

当前 Ollama 的云模型一般会带 -cloud 后缀，例如：

`1`	`gpt-oss:120b-cloud`

可用模型列表可能会变化，实际以 Ollama 官方页面为准。

怎么用

先登录：

`1`	`ollama signin`

登录完成后，直接运行云模型：

`1`	`ollama run gpt-oss:120b-cloud`

如果你是在代码里调用，也可以配置 API Key：

`1`	`export OLLAMA_API_KEY=your_api_key`

Python 示例：

import os
from ollama import Client

client = Client(
    host="https://ollama.com",
    headers={"Authorization": "Bearer " + os.environ["OLLAMA_API_KEY"]},
)

messages = [
    {"role": "user", "content": "为什么天空是蓝色的？"}
]

for part in client.chat("gpt-oss:120b-cloud", messages=messages, stream=True):
    print(part["message"]["content"], end="", flush=True)

小结

Ollama 云模型可以理解成一句话：

命令基本没变，只是模型不在你本地跑了。

如果你的电脑带不动大模型，但你又想继续用 Ollama 的方式调用模型，云模型就是一个很直接的方案。

从 Hugging Face 下载 GGUF 模型并导入 Ollama

Thu, 09 Apr 2026 11:00:07 +0800

如果某个模型在 Ollama 官方库里没有现成版本，或者你想使用 Hugging Face 上的特定 GGUF 文件，可以手动下载后再导入 Ollama。

第 1 步：从 Hugging Face 下载 GGUF 文件

先在 Hugging Face 上找到目标模型对应的 GGUF 文件。通常会看到多个量化版本，例如：

Q4_K_M
Q5_K_M
Q8_0

选择哪个版本，取决于你的显存、内存和你对速度、质量的取舍。下载后把 .gguf 文件放到固定目录，后面在 Modelfile 里直接引用。

第 2 步：编写 Modelfile

在模型文件同目录新建一个 Modelfile。最基本的写法如下：

`1`	`FROM ./model.gguf`

如果文件名不同，就改成实际文件名，例如：

`1`	`FROM ./gemma-3-12b-it-q4_k_m.gguf`

如果只是先跑起来，通常这一行 FROM 就够了。

第 3 步：导入到 Ollama

然后执行：

`1`	`ollama create myModelName -f Modelfile`

myModelName 是你希望在 Ollama 里使用的本地模型名
-f Modelfile 表示从这个配置文件创建模型

创建成功后，这个 GGUF 文件就会成为一个可直接调用的本地模型。

第 4 步：运行模型

创建完成后直接运行：

`1`	`ollama run myModelName`

之后它的使用方式就和 ollama pull 下来的模型基本一致。

如何查看现有模型的 Modelfile

如果你不确定 Modelfile 应该怎么写，可以直接查看现有模型的配置：

`1`	`ollama show --modelfile llama3.2`

这条命令会输出 llama3.2 的 Modelfile 内容，适合拿来参考：

FROM 应该怎么写
模板和 system prompt 是怎么组织的
参数是如何声明的

什么时候适合用这条路线

下面这些场景适合从 Hugging Face 手动导入：

Ollama 官方库里还没有你要的模型
你想使用某个特定量化版本
你已经手动下载好了 GGUF 文件
你想更精细地控制模型封装方式

如果官方库里已经有现成版本，直接 pull 通常更省事；但当你需要特定量化或自定义封装时，GGUF + Modelfile 会更灵活。

常见注意点

FROM 后面的路径必须和实际 .gguf 文件位置一致。
文件名里如果有空格或特殊字符，建议先改成更简单的名字。
不同 GGUF 量化版本对内存和速度影响很大，导入成功不代表运行一定流畅。
如果模型是聊天模型，后续通常还需要根据其格式调整 prompt 模板，效果才会更稳定。

结论

从 Hugging Face 下载 GGUF 文件再导入 Ollama 并不复杂。准备好模型文件，写一个最小可用的 Modelfile，再执行 ollama create，就可以把第三方 GGUF 模型接入 Ollama。

Ollama 下载模型 pull 速度很慢的排查和解决办法

Thu, 09 Apr 2026 10:42:39 +0800

ollama pull model_name:tag 在有些地区下载速度会很慢，而且过程并不稳定。

如果你遇到的是大模型下载到一半反复中断、报错 TLS handshake timeout 或 unexpected EOF，那么问题很可能不只是 registry.ollama.ai 本身，而是后续跳转到的实际下载链路。

这篇文章记录一次简单直接的排查思路：先拿到模型文件的真实下载地址，再确认最终流量落到哪里，最后只针对关键域名做网络优化。

获取模型文件的下载地址

可以借助下面这个项目，把 Ollama 模型对应的 manifest 和 blob 下载地址直接提取出来：

https://github.com/Gholamrezadar/ollama-direct-downloader

以 gemma4:latest 为例，可以提取出类似下面这些链接。

Manifest 地址

`1`	`https://registry.ollama.ai/v2/library/gemma4/manifests/latest`

Blob 地址

https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2
https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:56380ca2ab89f1f68c283f4d50863c0bcab52ae3f1b9a88e4ab5617b176f71a3

如果你只是想快速验证，也可以直接用 curl 下载 manifest 和 blob：

curl -L "https://registry.ollama.ai/v2/library/gemma4/manifests/latest" -o "latest"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11" -o "sha256-f0988ff50a2458c598ff6b1b87b94d0f5c44d73061c2795391878b00b2285e11"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a" -o "sha256-4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a"
curl -L "https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2" -o "sha256-7339fa418c9ad3e8e12e74ad0fd26a9cc4be8703f9c110728a992b193be85cb2"

跳转后的真实下载地址

尝试用 wget 下载其中一个 blob，会发现请求并不是一直停留在 registry.ollama.ai，而是会继续跳转到一个 Cloudflare R2 对象存储地址：

wget https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
--2026-04-09 09:22:04--  https://registry.ollama.ai/v2/library/gemma4/blobs/sha256:4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a
Resolving registry.ollama.ai (registry.ollama.ai)... 104.21.75.227, 172.67.182.229, 2606:4700:3034::ac43:b6e5, ...
Connecting to registry.ollama.ai (registry.ollama.ai)|104.21.75.227|:443... connected.
HTTP request sent, awaiting response... 307 Temporary Redirect
Location: https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?... [following]
--2026-04-09 09:22:05--  https://dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com/ollama/docker/registry/v2/blobs/sha256/4c/4c27e0f5b5adf02ac956c7322bd2ee7636fe3f45a8512c9aba5385242cb6e09a/data?...
Resolving dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com (dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com)... 172.64.66.1, 2606:4700:2ff9::1
Connecting to dd20bb891979d25aebc8bec07b2b3bbc.r2.cloudflarestorage.com|172.64.66.1|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 9608338848 (8.9G) [application/octet-stream]

从日志里可以看到几个关键信息：

registry.ollama.ai 返回了 307 Temporary Redirect
最终下载地址落在 *.r2.cloudflarestorage.com
真正承载大文件传输的，实际上是后面的对象存储域名

这一步很重要，因为它说明如果你的代理或分流规则只覆盖了 registry.ollama.ai，但没有处理 *.r2.cloudflarestorage.com，那下载仍然可能很慢，甚至反复中断。

调整网络设置

确认真实下载链路之后，排查方向就会清晰很多。

如果你正在使用代理、分流或自定义 DNS，建议优先检查下面几件事：

registry.ollama.ai 和 *.r2.cloudflarestorage.com 是否走了同一条稳定线路
代理规则是否只覆盖了前者，而漏掉了后者
当前出口是否适合持续下载数 GB 到数十 GB 的大文件

这类问题的关键并不是“能不能打开官网”，而是“跳转后的对象存储链路是否稳定、是否能长时间持续传输”。很多时候，真正需要优化的是 Cloudflare R2 这一层，而不是前面的 registry 域名。

调整前后的对比

下面是一次实际下载 gemma4:31b-it-q8_0 时的表现。

调整前，下载速度较慢，而且会在中途报错：

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  38% ▕██████████████████████                                    ▏  12 GB/ 33 GB  1.2 MB/s   4h40m
Error: max retries exceeded: unexpected EOF

调整后，再次下载同一个模型时，速度和稳定性都有明显改善：

1
2
3

PS C:\Users\knightli> ollama run gemma4:31b-it-q8_0
pulling manifest
pulling a0feadb736f5:  46% ▕████████████████████████████████████████████████████████████████▏ 15 GB/ 33 GB  8.5 MB/s  35m23s

这并不意味着所有网络环境都能得到同样结果，但至少说明了一点：瓶颈很可能不在 Ollama 客户端本身，而在实际的大文件下载链路。

OpenClaw 对接本地 Gemma 4：完整配置指南

Wed, 08 Apr 2026 18:18:00 +0800

这篇文章演示如何把 OpenClaw 对接到本地 Gemma 4 模型（通过 Ollama 提供接口）。

如果你还没完成本地部署，可先参考：

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

第 1 步：启动 Ollama API 服务

先启动 Ollama 服务：

`1`	`ollama serve`

你可以用下面的命令快速测试 API 是否正常：

curl http://localhost:11434/api/generate -d '{
  "model": "gemma4:12b",
  "prompt": "你好"
}'

如果能返回模型输出，说明本地 API 已可用。

第 2 步：配置 OpenClaw 接入 Ollama

OpenClaw 配置文件路径通常为：

`1`	`~/.openclaw/config.yaml`

编辑 config.yaml，在 models 中新增一个本地模型条目：

models:
  # 你已有的模型配置...

  gemma4-local:
    provider: ollama
    base_url: http://localhost:11434
    model: gemma4:12b
    timeout: 120s

第 3 步：设置默认模型（可选）

如果你希望默认走 Gemma 4，可添加：

`1`	`default_model: gemma4-local`

第 4 步：重启并验证 OpenClaw

重启 OpenClaw：

`1`	`openclaw restart`

查看模型列表：

`1`	`openclaw models list`

发起一次对话测试：

`1`	`openclaw chat --model gemma4-local "你好"`

如果对话返回正常，说明 OpenClaw 已成功接入本地 Gemma 4。

常见排查

connection refused：先确认 ollama serve 是否在运行。
模型找不到：检查模型名是否与 ollama list 一致（例如 gemma4:12b）。
响应超时：可适当提高 timeout，并优先测试较小模型。

如何在笔记本电脑上运行 Gemma 4：5 分钟本地部署指南

Wed, 08 Apr 2026 18:06:00 +0800

如果你想在笔记本上本地运行 Gemma 4，Ollama 是目前最省事的方式之一。即使不折腾复杂环境，通常 5 分钟左右也能跑起来。

第 1 步：安装 Ollama

打开 https://ollama.com，下载对应系统的安装包。
按系统完成安装：

macOS：拖到 Applications。
Windows：运行 .exe 安装程序。
Linux：使用官网提供的安装脚本。

安装完成后，Ollama 会以后台服务形式运行。除初次安装外，日常可以只用简单命令。

第 2 步：下载 Gemma 4 模型

打开终端，执行：

`1`	`ollama pull gemma4:4b`

如果你的机器性能更强，可以改成 12b 或 27b。下载完成后，模型会保存在本地。

查看已下载模型：

`1`	`ollama list`

第 3 步：启动模型

`1`	`ollama run gemma4:4b`

这会在终端打开交互式对话。输入问题后回车即可；结束会话可输入：

/bye

如果你更喜欢网页聊天界面，可以配合 Open WebUI 使用。它可以把 Ollama 包装成浏览器端 UI，通常通过 Docker 几分钟即可完成配置。

笔记本性能优化建议

Apple Silicon（M2/M3/M4）：默认走 Metal，加速效果通常很好，12B 也有不错体验。
NVIDIA 显卡：检测到兼容 GPU 时会自动使用 CUDA，建议提前更新驱动。
仅 CPU 推理：可以运行，但大模型会明显变慢；多数 CPU-only 场景建议优先 4B。
释放内存：加载大模型前尽量关闭占内存应用。经验上每 10 亿参数大约需要 0.5GB 到 1GB 内存。

模型怎么选

Gemma 4 1B：适合轻量问答、基础摘要、快速查询；复杂推理能力有限。
Gemma 4 4B：适合多数日常任务（写作辅助、代码辅助、资料总结），速度和质量平衡较好。
Gemma 4 12B：适合更长上下文和更复杂任务，在代码与推理场景更稳。
Gemma 4 27B：适合高要求任务，效果更接近云端大模型，但对硬件要求明显更高。

如何判断 Ollama 模型是否已加载到 GPU

Mon, 06 Apr 2026 10:15:18 +0800

想确认 Ollama 模型有没有真正跑在 GPU 上，最直接的方法是查看当前已加载模型的处理器占用信息。

使用命令

`1`	`ollama ps`

示例输出

1
2

NAME        ID            SIZE    PROCESSOR   UNTIL
llama3:70b  bcfb190ca3a7  42 GB   100% GPU    4 minutes from now

如何解读 `PROCESSOR` 列

100% GPU：模型完全加载在 GPU 显存中。
100% CPU：模型完全加载在系统内存中（未使用 GPU 推理）。
48%/52% CPU/GPU：模型部分在内存、部分在显存中，属于混合加载。

实用建议

如果你预期使用 GPU，但看到 100% CPU，先检查显卡驱动、CUDA/ROCm 环境和 Ollama 运行参数。
模型参数量较大、显存不足时，通常会出现 CPU/GPU 混合加载。
排查性能问题时，先执行 ollama ps 再看速度数据，能更快定位瓶颈。

总结

ollama ps 是判断模型是否真正使用 GPU 的第一步。重点看 PROCESSOR 列即可快速确认当前加载位置，并据此决定后续优化方向。

Ollama 模型默认存储位置与迁移方法（防止 C 盘爆满）

Mon, 06 Apr 2026 09:38:00 +0800

本地跑大模型时，最容易先爆掉的往往是系统盘。Ollama 默认会把模型下载到用户目录或系统目录，如果不提前规划路径，C 盘很快就会吃满。

Ollama 常见默认模型目录

Windows：C:\Users\<用户名>\.ollama\models
macOS：~/.ollama/models
Linux：/usr/share/ollama/.ollama/models（部分安装方式可能不同）

Windows：把模型目录迁移到非系统盘

建议把模型目录迁移到例如 D:\OllamaModels，核心方法是设置系统环境变量 OLLAMA_MODELS。

1. 新建目标目录

例如先创建：D:\OllamaModels

2. 配置系统环境变量

变量名：OLLAMA_MODELS
变量值：D:\OllamaModels

可在“系统属性 -> 高级 -> 环境变量”中添加，也可用命令行设置（管理员 PowerShell）：

`1`	`[System.Environment]::SetEnvironmentVariable("OLLAMA_MODELS", "D:\OllamaModels", "Machine")`

3. 重启 Ollama（或重启系统）

环境变量生效后，重新启动 Ollama 服务/应用。若不确定是否已生效，直接重启电脑最稳妥。

4. 验证新目录是否生效

下载或拉取任意模型后，检查 D:\OllamaModels 下是否出现新文件。

5. 清理旧目录（确认无误后）

确认模型已在新目录正常工作，再删除旧目录内容，回收 C 盘空间。

常见问题

设置后仍写入 C 盘怎么办

先确认环境变量是“系统变量”而不是“当前会话临时变量”。
确认 Ollama 进程已重启。
检查变量名是否准确：必须是 OLLAMA_MODELS。

是否需要迁移旧模型文件

如果你不想重复下载，可在停止 Ollama 后手动复制旧模型到新目录，再启动 Ollama 验证。

在 Linux 上彻底卸载 Ollama（含残留清理）

Mon, 06 Apr 2026 09:16:29 +0800

如果你需要在 Linux 上彻底移除 Ollama，可以按下面顺序执行。本文会清理服务、可执行文件、模型目录，以及 ollama 用户和用户组。

卸载前提醒

以下命令会删除本机 Ollama 模型文件（通常在 /usr/share/ollama），请先确认是否需要备份。
命令默认使用 sudo，请确保当前账号有管理员权限。

1. 停止并移除 systemd 服务

sudo systemctl stop ollama
sudo systemctl disable ollama
sudo rm -f /etc/systemd/system/ollama.service
sudo systemctl daemon-reload

2. 删除 Ollama 可执行文件

OLLAMA_BIN="$(command -v ollama)"
if [ -n "$OLLAMA_BIN" ]; then
  sudo rm -f "$OLLAMA_BIN"
fi

3. 删除 Ollama 相关库目录（如存在）

如果你的安装方式在 lib 目录写入了 Ollama 文件，可按下面方式清理：

1
2
3

for d in /usr/local/lib/ollama /usr/lib/ollama /lib/ollama; do
  [ -d "$d" ] && sudo rm -rf "$d"
done

4. 删除模型与数据目录

`1`	`sudo rm -rf /usr/share/ollama`

5. 删除系统用户与组（如存在）

1
2

id -u ollama >/dev/null 2>&1 && sudo userdel ollama
getent group ollama >/dev/null 2>&1 && sudo groupdel ollama

6. 验证是否已卸载完成

1
2

command -v ollama || echo "ollama binary not found"
systemctl status ollama || true

如果以上检查没有再找到 ollama，说明已经卸载完成。

大模型量化详解：FP16、Q8、Q5、Q4 到 Q2 怎么选？

Sun, 05 Apr 2026 22:09:11 +0800

量化的核心目标很简单：用少量精度损失，换取更小体积、更低显存占用和更快推理速度。
对本地部署用户来说，选对量化版本，往往比盲目追求大参数更重要。

什么是量化

量化是指把模型参数从高精度格式（如 FP16）压缩为更低位宽格式（如 Q8、Q4）。

可以把它理解为：

原始模型：像高精度照片，清晰但文件大。
量化模型：像压缩照片，细节略损但更轻更快。

常见量化版本对比

量化版本	精度/位宽	体积	质量损失	推荐场景
FP16	16 位浮点	最大	几乎无损	研究、评测、追求极致质量
Q8_0	8 位整数	较大	几乎无损	高配电脑，兼顾质量与性能
Q5_K_M	5 位混合	中等	轻微损失	日常主力，平衡方案
Q4_K_M	4 位混合	较小	可接受损失	通用默认，性价比高
Q3_K_M	3 位混合	很小	明显损失	低配设备，能跑优先
Q2_K	2 位混合	最小	较大损失	极限资源场景，临时可用

量化命名规则

以 gemma-4:4b-q4_k_m 为例：

gemma-4:4b：模型名称与参数规模。
q4：4 位量化。
k：K-quants（改进量化方法）。
m：medium（中等级别，常见还有 s/small、l/large）。

如何按显存快速选型

内存/显存	推荐量化
4 GB	Q3_K_M / Q2_K
8 GB	Q4_K_M
16 GB	Q5_K_M / Q8_0
32 GB+	FP16 / Q8_0

建议先从能稳定跑起来的版本开始用，再逐步提高精度，而不是一上来就追求最大模型。

实战建议

默认从 Q4_K_M 开始，先验证真实任务效果。
如果答案质量不够，再升到 Q5_K_M 或 Q8_0。
如果主要瓶颈是显存或速度，再降到 Q3_K_M。
每次切换量化版本，都用同一批测试问题做对比。

结论

质量优先：FP16 或 Q8_0。
平衡优先：Q5_K_M。
通用默认：Q4_K_M。
低配兜底：Q3_K_M 或 Q2_K。

选型的本质不是“越大越好”，而是“在你的硬件条件下，达到最稳定可用的效果”。

谷歌 Gemma 4 模型对比：2B/4B/26B/31B 怎么选？

Sun, 05 Apr 2026 08:30:00 +0800

Gemma 4 主打 多模态 与 本地离线运行，并提供从轻量端到高性能端的完整模型梯度。对大多数本地部署用户来说，关键不是“选最大”，而是“选最匹配硬件与任务的版本”。

Gemma 4 各模型对比

下表用于快速选型参考；具体性能与资源占用请以实际部署环境测试为准。

模型	参数规模	定位	主要优势	主要限制	推荐场景
Gemma 4 2B	20 亿	超轻量	延迟低、资源占用小、部署门槛最低	复杂推理与长链路任务能力有限	移动端、IoT、轻量问答、简单自动化
Gemma 4 4B	40 亿	轻量增强	比 2B 更稳的理解与生成能力，仍易本地部署	高强度编码/复杂 Agent 任务上限有限	本地助手、基础文档处理、多语言日常任务
Gemma 4 26B	260 亿	高性能（专家混合）	推理和工具调用能力明显提升，适合生产工作流	显存需求显著上升，硬件门槛更高	编程助手、复杂工作流、企业内部 Agent
Gemma 4 31B	310 亿	高性能（稠密）	综合能力最强，复杂任务稳定性更好	资源消耗最高，部署与调优成本最大	高要求推理、复杂代码任务、重度自动化

怎么选：按硬件和任务倒推

如果你主要看“能不能跑、跑得顺不顺”，可以按下面选：

8GB 显存：优先 2B/4B。
12GB 显存：优先 4B 或更高模型的量化版本。
24GB 显存：可重点考虑 26B，并按任务评估 31B 量化版。
更高显存或多卡：可尝试 31B 的高精度配置。

建议优先保证稳定性和推理速度，再逐步提升模型规模。

四类典型使用场景

1) 本地通用助手

优先模型：4B
原因：成本和效果平衡好，适合长期常驻运行。

2) 代码与自动化

优先模型：26B
原因：在多步骤任务、工具调用、脚本生成上更稳。

3) 高难度推理与复杂 Agent

优先模型：31B
原因：复杂上下文下的稳定性更高，容错更好。

4) 边缘设备与轻量离线

优先模型：2B
原因：最容易在资源受限设备落地。

部署建议（Ollama 方向）

最实用的做法是“小步快跑”：

先用 4B 建立可运行基线（速度、内存、效果）。
把你的真实任务做成固定测试集（例如 20 条常见问题 + 10 个自动化任务）。
再升级到 26B/31B 对比准确率、时延和显存成本。
只在“收益明显”时升级大模型。

这样可以避免一上来就追求大参数，结果出现卡顿、吞吐低、维护复杂的问题。

结论

Gemma 4 的真正价值，不是单纯“参数更大”，而是给了从轻量到高性能的一整套可落地梯度：

想低成本快速上线：从 2B/4B 开始。
想把本地 AI 真正接入生产流程：优先 26B。
想冲复杂推理与重度自动化：再上 31B。

Gemma 4 的最佳选择通常不是参数最大，而是与硬件条件和任务目标匹配度最高的版本。

Ollama on KnightLi的博客

Claude Code + Ollama 本地部署教程：用 CC Switch 打造免费 AI 编程助手

这套方案解决什么问题

基本准备

CC Switch 关键配置

Claude Code 强在哪里

Ollama 在这里扮演什么角色

体验边界在哪里

多模态兼容性还不稳定

适合谁尝试

使用建议

小结

适合 RTX 3060 显卡运行的本地 LLM 模型推荐

先看显存边界

推荐一：Qwen3 8B

推荐二：Llama 3.1 8B Instruct

推荐三：Gemma 3 12B

推荐四：DeepSeek R1 Distill Qwen 8B

推荐五：Phi / MiniCPM / 小尺寸模型

量化怎么选

用什么工具运行

上下文不要开太大

不同用途怎么选

3060 本地 LLM 的合理预期

小结

参考链接

解决 Ollama 使用 CPU 而不使用 GPU 运算的问题

1. 先确认是不是“真的没用 GPU”

2. 先排除最常见的误区：模型装不进显存

3. 检查显卡驱动和底层环境是不是可用

NVIDIA 方向

AMD / ROCm 方向

4. 重启 Ollama 服务，不要只重开终端

5. 检查服务环境变量有没有真正传进去

6. AMD 平台重点看 ROCm 兼容性

7. Docker、WSL 或远程环境要额外检查设备映射

8. 最后再看日志，而不是一开始就瞎猜

排查顺序

Ollama 多显卡使用笔记：显存叠加、GPU 选择和常见误区

官方行为：先单卡，放不下再多卡

多 GPU 不是简单叠算力

不需要 SLI 或 NVLink

如何限制 Ollama 使用哪些 NVIDIA GPU

AMD 和 Vulkan 的选择变量

Docker 里怎么暴露多张 GPU

OLLAMA_SCHED_SPREAD 是什么

怎么观察多卡是否真的用上

常见误区

误区 1：两张 12GB 显卡等于一张 24GB 显卡

误区 2：不同型号显卡不能混用

误区 3：多卡一定比单卡快

误区 4：必须有 NVLink / SLI

误区 5：加 GPU 后不用重启服务

选卡建议

小结

参考链接

Windows 用 WSL + Ollama 本地部署 Hermes Agent，并接入 Telegram

整体流程

1. 安装 WSL 和 Ubuntu

2. 更新 Ubuntu，并安装基础环境

安装 Python

安装 zstd

安装 Node.js

安装 Git

3. 安装 Ollama，并拉取 Gemma 4

4. 安装并配置 Hermes Agent

Hermes Agent 常用命令

启动

重新进入配置

配置聊天平台网关

更新

接入 Telegram 的基础步骤

这一套方案适合什么人

需要注意的几个点

结论

Windows 局域网访问 Ollama API 设置指南

设置监听端口

打开防火墙

运行 Ollama

通过 API 访问模型

`OLLAMA_SCHED_SPREAD` 是什么

如何解读 `PROCESSOR` 列