使用 ollama 部署本地大模型 qwen2.5 3b/7b

1. ollama是什么

在介绍ollama之前，需要知道几个概念。

llm：这是我们常说的大语言模型，比如 qwen2.5，glm5.3，deepseek 4.1 flash，gpt-6.1 sol之类的。它是一个超大的神经网络，输入文字，它会输出“下一个最可能的文字”，循环到生成完整回答。

llama.cpp：用 C/C++ 写的本地运行 LLM 的引擎，特点是能在 CPU / 普通电脑上跑，不需要 GPU

知道这两个概念之后，那么 ollama 是基于 llama.cpp 等引擎包装的本地模型管理工具，一条命令下载/运行模型，自动暴露 OpenAI 兼容 API。类比的话，就是类似于 Docker 之于容器——ollama run qwen2.5:3b 就像 docker run

2. 大语言模型的参数规模

在大语言模型的名字后面，常常看到一些类似 3B, 7B, 70B, 671B 等等。这个 B 就是 Billion，十亿的意思，表示的神经网络中的权重系数，或者通俗点叫做参数。参数（权重）是模型在训练中学到的所有“知识 + 语言能力 + 推理模式”的存储单元。参数越多，能装的模式越复杂，但推理时要做更多乘加运算、占更多内存。所以它同时影响三件事：能力↑、内存↑、速度↓。

用一个直观例子感受差别

同一次失败后重新提问，不同档位的典型表现：

• 0.5B：可能直接忽略你上一句话的语境
• 3B：理解了你要什么，但逻辑链条一长就断
• 7B：能做对，偶尔在第三步出错
• 32B+：稳定做对，还会指出你问题里隐含的假设

我们当前（2026.10.08）商用的大模型的参数规模大概是这样的

DeepSeek-V4.1-Flash: 763B，GLM-5.3：744B，Kimi K3：2.8T，Qwen3.8：2.4T。当然，他们的架构是MoE架构，跟上面的 3B/7B（稠密架构） 不是完全一回事，但是你可以感受下短短一两年，这个大模型能力的变化以及对于硬件的需求增长。

3. 使用 ollama 部署在本地部署qwen2.5 3b 和 7b

1. 环境

机器：Apple M2

CPU/GPU: 8 核 CPU + 10 核 GPU

内存：16GB 统一内存

操作系统：macOS 26.6.2

2. 安装与常驻 

brew install ollama
brew services start ollama    # 后台常驻 + 开机自启

brew services start 之后 Ollama 就是一个永远在线的服务（类似 Docker daemon），监听 localhost:11434，之后所有 run/pull/API 调用都直接可用，不再需要手动 ollama serve。

3. 拉模型，跑模型

ollama pull qwen2.5:3b        # 1.9GB
ollama pull qwen2.5:7b        # 4.7GB
ollama run qwen2.5:7b "你好，你是谁啊"

三个关于生命周期的体感：

1. pull ≠ 运行。pull 只是把 GGUF 文件下载到 ~/.ollama/models/（类比 docker pull 下载镜像），第一次 run 时才有几秒钟的"载入内存"等待
2. 模型按需加载、空闲自动卸载。默认空闲 5 分钟后内存归还系统（ollama ps 可查看当前加载状态）。从这个设计来看，ollama 的实验，测试的属性很强。当然可以通过写 OLLAMA_KEEP_ALIVE 环境变量让大模型常驻内存，但是作为测试用途，没必要。
3. 同一服务可以共存多个模型，但内存是硬约束——3B 约 2.5GB、7B 约 5GB，同时常驻两个再加系统开销就会逼近红线

验证 OpenAI 兼容 API（这是所有上层应用集成的通用入口）：

curl http://localhost:11434/v1/chat/completions \
  -d '{"model":"qwen2.5:7b","messages":[{"role":"user","content":"你好"}]}'

4. 3B vs 7B 感受

两个模型都跑通后，基本资源使用是

3b：磁盘，1.9gb。内存，2.5gb

7b：磁盘，4.7gb。内存，5gb

我尽量不使用主观词语来衡量表现，我用一个下面这个实验来说明差别吧。

我本机正好安装了 deepseek harness（DSH），我把这两个本地模型都接入了DSH（它是支持OpenAI 兼容 API 的）

在介绍两个大模型的表现之前，先简单介绍下dsh这类agent的工作方式：

DSH 与模型之间不是简单的一问一答。每次我发出一句"你好啊"，它实际发给模型的内容包括：

1. 系统提示词：定义它当前扮演的角色、行为规则、可用的输出格式
2. 十几个工具的定义：每个工具（读写文件、任务清单、派发子任务……）都用 JSON Schema 严格规定名称、用途、必填参数和类型
3. 对话历史：这个会话到目前为止的所有往来内容

模型收到后，生成回复。回复有两种形态：纯文字回答，或者一次工具调用——以结构化 JSON 声明"我要调用 write 工具，参数是……"。真正执行工具的是 DSH 而不是模型：DSH 解析这段 JSON、校验参数、在本地执行，然后把执行结果（成功输出或报错）追加进对话历史，再次请求模型继续。如此循环，直到模型给出文字回答。

也就是说，模型的每一次响应都要在"十几个工具的定义 + 全部历史 + 用户消息"的约束下做出精确决策：调不调？调哪个？参数逐字段符合 Schema 吗？——这个背景对理解下面的实验很关键。

 

实验的结果是这样的

• 7B：正常工作。哪怕只说"你好"，它也正确判断"不需要调任何工具"，直接文字回复

• 3B：彻底崩掉。它开始幻觉式地疯狂调用工具，而且参数 JSON 全是坏的——缺必填字段、给空值，同一个错误重试九次。它陷入了"调工具 → 报错 → 再调 → 再报错"的死循环，最终上下文被错误信息塞满

有意思的是对照实验：对 3B 明确说"只回答文字，不要调用任何工具"，它立刻恢复正常。说明它崩的不是对话能力，而是"在十几个工具的 Schema 约束下做'该不该调用、如何填参'的决策"——这个认知负担正好压垮了 3B 的天花板。

截图如下

 

为什么同一个环境，7B 稳定而 3B 崩溃？从这次实验能拆出三层原因：

1. "不调用工具"本身是一个决策，且是最难的那种。 面对一句"你好啊"，正确行为是"识别出所有工具都不适用，输出纯文字"。这意味着模型要真正“读懂"十几个工具的用途描述，而不是机械地模仿"环境里有工具，我就该用"的模式。7B 做到了，3B 做不到——它表现出了更强的"用工具"倾向，推测是参数量小时，模型对"工具存在"这一信号的反应压过了对"工具是否适用"的判断。

2. 严格的 JSON 输出对小模型是硬挑战。 工具调用要求模型在自由生成的过程中，逐字段匹配 JSON Schema：必填字段不能少、类型不能错、格式不能漂。7B 能稳定做到；3B 生成的 JSON 缺必填字段、给空值，甚至同一个错误重试九次都不纠正——说明它不是随机失误，而是没有稳定的内部能力去满足这个格式约束。值得一提的是，qwen2.5 3B 官方是宣称支持工具调用的——所以这不是"功能有没有"，而是"能力够不够"：简单场景（一两个工具）它也许能应付，十几个工具叠加完整对话历史，就超出了容量。

3. 死循环是错误反馈机制的代价。 DSH 把每次调用的报错文本追加进上下文让模型"改错"，这本是 agent 自我修正的设计。但对 3B，报错信息反而进一步挤占了它本就有限的可用上下文和注意力，修正从未发生，循环直到崩溃。同样的机制在 7B 上工作良好——同一个安全网，只接得住够重的模型。

由此得到的可操作结论：为 agent 场景选模型时，下限不在"能不能聊"，而在结构化输出的可靠性。任何要接工具、接工作流的场景，7B 量级是起步线；小模型请限制在纯对话。