NNNNzs

记一次本地大模型部署踩坑：N200 + 4060Ti 的 7B 终局

2026年04月26日1 次阅读0 人喜欢
AI 模型OpenClawOllamaNASLLM踩坑记录配置RTX4060TiIntel N200Qwen

记一次本地大模型部署踩坑：N200 + 4060Ti 的 7B 终局

从参数焦虑到速度为王，我的 OpenClaw 智能体终于有了称手的大脑

起因：NAS 上能跑多大的模型？

前段时间折腾 OpenClaw，突然想搞清楚我的 NAS 算力到底什么水平。我的 NAS 是零刻 Mini，CPU 是 Intel N200，插了 12GB 内存，跑的是飞牛 OS（基于 Debian）。

问了 Gemini，得到的答案让我有点意外：N200 相当于十年前的桌面 i5-4570/i7-3770 级别。多核性能平平，但单核不错，最关键的是功耗只有 6W，比老桌面 CPU 动辄 84W 省电太多了。

那本地跑大模型呢？Gemini 说得很直接：N200 上跑 8B 模型已经是极限，速度大概 1-3 tokens/s，就像一个打字极慢的新手，一个字一个字蹦出来。要想流畅点，得跑 1.5B/3B 这种小模型。

我有点不甘心。8B 真的就到头了？

初试：N200 上的 4B 模型

既然有了 Ollama，我决定试试 Qwen 3.5 系列。看了下官方列表，有 0.8B、2B、4B 几个规格。心一横，直接上 4B。

bash 复制代码 
ollama run qwen3.5:4b

结果直接报错：

复制代码 
Error: 500 Internal Server Error: model requires more system memory (5.4 GiB) than is available (4.3 GiB)

我有点懵，我明明有 12GB 内存啊？后来查了才知道，问题出在 Docker 容器上。我在 NAS 上跑 Ollama 是用 Docker 起的，如果容器启动时限制了内存，容器内部就只能看到那么多。加上飞牛 OS 本身和各种 Docker 容器（Home Assistant、qBittorrent 等）占用的空间，系统可用内存确实就剩 4.3GB 了。

这就像你有一间 12 平米的房子，但堆满了东西，真正能用的空间就那么大。

转场：用 4060Ti 试试

NAS 上跑不动，我想到了家里的台式机——RTX 4060 Ti 8GB 显卡，12GB 内存。这下应该够了吧？

我装了 Windows 版的 Ollama，直接上最新的 Qwen 3.6。这次我看准了 35B-a3b 版本——这是 MoE 架构的，虽然总参数有 35B，但每次只激活 3B，理论上速度应该不慢。

bash 复制代码 
ollama run qwen3.6:35b-a3b-nvfp4

结果又报错了：

复制代码 
Error: pull model manifest: 412: this model requires macOS

原来这个 -nvfp4 后缀的版本是 macOS 专供的，Windows 还不支持。换了个通用版：

bash 复制代码 
ollama run qwen3.6:35b-a3b-q4_K_M

这次能跑起来了，但速度……

残酷现实：7 分钟回答一个问题

我加了 --verbose 参数看详细输出，数据出来了：

复制代码 
total duration: 7m0.64s
eval rate: 1.33 tokens/s

1.33 tokens/s，这是什么概念？人类正常语速大约是每秒 3-5 个词。也就是说，模型每秒只能蹦出 1-1.5 个字。回答一个问题整整跑了 7 分钟！

任务管理器里，GPU 专用内存满了，系统内存也满了，但那个"共享 GPU 内存"却显示没占用。后来才知道，"共享显存"本质上就是你的物理内存，只是 Windows 的一种管理机制。当模型数据溢出时，Ollama 直接作为进程占用了系统内存，不会显示在共享显存那一栏。

问题很明显：35B 模型需要 22-24GB 空间，而我的 8G 显存 + 12G 内存总共才 20G，模型被迫拆分，一部分在显存，一部分在内存，还有部分在硬盘的虚拟内存里。数据在显存、内存、硬盘之间来回搬运，能快才怪。

有意思的是，我发现模型加载阶段硬盘读写 100%，等开始输出后硬盘占用就少了。这说明加载阶段在疯狂"搬运"数据，等模型就位后就只是计算了。虽然硬盘不忙了，但依然慢，因为 PCIe 带宽（15-30 GB/s）远低于显存带宽（288 GB/s）。

Qwen 3.6 的新特性：思考链

跑 3.6 的时候，我注意到输出里有这样的步骤：

复制代码 
analyze user input → identify key → formulate response → final output

这是 Qwen 3.6 引入的"推理链"功能，类似于 OpenAI 的 o1 或 DeepSeek R1。模型在回答前会先"思考"：拆解问题、确定考点、构思大纲，最后才给出答案。

对于 OpenClaw 这种 Agent 框架来说，这个功能很有用。模型在调用工具时会更精准，如果逻辑不通还会自己推翻重来。但这代价就是更长的思考时间，在我的 8G 显卡上，这个等待就更加明显了。

降级：14B 的勉强可用

35B 太慢了，我决定降级试试 14B。Qwen 3.6 首发只有 27B 和 35B-a3b，没有 7B/14B。所以我换回了 Qwen 2.5 系列。

bash 复制代码 
ollama run qwen2.5:14b --verbose
复制代码 
total duration: 17.79s
prompt eval rate: 2.97 tokens/s
eval rate: 5.27 tokens/s

总耗时降到了 17.8 秒，速度比 35B 快了 4 倍。但 5.27 tokens/s 在 AI 圈被称为"朗读速度"——比你阅读速度快一点点，但还没到流畅的程度。

对于 OpenClaw 来说，这个速度还是有点悬。Agent 需要理解指令、调用技能、解析结果，每一步都要等几秒，整个流程就慢了。

我怀疑是显存没吃满，或者上下文占用了太多空间。Gemini 建议我限制 num_ctx 到 4096，减少 KV Cache 占用，让更多参数留在显存里。

终局：7B 的起飞

最后我试了下 Qwen 2.5-Coder 7B。

bash 复制代码 
ollama run qwen2.5-coder:7b --verbose
复制代码 
total duration: 1.86s
prompt eval rate: 103.74 tokens/s
eval rate: 55.44 tokens/s

起飞了！

对比一下数据：

指标 35B 14B 7B
输出速度 1.33 t/s 5.27 t/s 55.44 t/s
理解速度 0.72 t/s 2.97 t/s 103.74 t/s
总耗时 7 分钟 17.8 秒 1.86 秒

1.33 到 55.44，提升了 40 倍！从 7 分钟到 1.86 秒，完全两个次元的体验。

55.44 tokens/s 说明模型完全驻留在 8GB 显存内，显卡满血运行。31 个字符的指令 0.3 秒就读完，输出 76 个字符只需要 1.3 秒，这才叫"秒回"。

那个问题：小模型会不会很蠢？

说实话，一开始我也有"参数焦虑"。毕竟 35B 的智力肯定比 7B 强，但慢得要命。

但后来想通了，我的场景是什么？让 OpenClaw 写代码、调用 API、解析 JSON、处理简单的自动化任务。Qwen 2.5-Coder 7B 是专门为代码和逻辑优化过的，在这些"垂直领域"，它的智力已经超过了很多半年前的 70B 模型。

更重要的是，对于 Agent 任务来说，速度本身就是智力的一部分。

  • 慢模型（35B）：虽然聪明，但思考 7 分钟。这期间如果网络波动或者指令有歧义，你要再等 7 分钟。
  • 快模型（7B）：虽然偶尔犯错，但秒回。你可以在 OpenClaw 里通过"反思机制"快速纠错。

公式就是：1 个聪明的慢模型 < 3 个互相校验的快模型

如何让小模型更聪明？

如果你担心小模型"蠢"，可以给它打几个补丁：

  1. RAG（检索增强生成）：别让模型硬背知识。你有技术博客和 NAS 文档，通过向量数据库把资料喂到它嘴边，模型只需要做阅读理解，表现出来的智力就很高。

  2. Few-Shot（给范例）：小模型最怕"猜"。你在写 OpenClaw 技能时，在 Prompt 里给它 1-2 个正确的调用示例，错误率会从 30% 降到 1% 以下。

  3. 任务拆分：不要让模型一次性完成大工程。让它先写思路，再写代码。Qwen 2.5 系列处理分步指令非常出色。

Claude Code + Ollama

既然本地模型跑起来了，自然想试试 Claude Code。Claude Code 原生是为了 Anthropic API 设计的，但 Ollama 已经实现了 Anthropic Messages API 的兼容。

最简单的启动方式：

bash 复制代码 
ollama launch claude --model qwen2.5-coder:7b

或者手动配置环境变量：

环境变量 设置值
ANTHROPIC_BASE_URL http://localhost:11434
ANTHROPIC_AUTH_TOKEN ollama
ANTHROPIC_API_KEY (空)

Claude Code 的工作方式是"代理式"的，会不断扫描目录、读取文件、尝试运行测试。这个过程会产生很长的上下文，如果用 14B 或 27B，速度太慢会导致超时。7B-Coder 刚好，既支持 Tool Use，又有足够的显存余裕。

我的最终配置

折腾一圈，我的"全家桶"配置是这样的：

  • NAS（N200 + 12GB）：跑 Qwen 3.5-1.5B/2B，做简单的指令识别和任务触发。虽然智力不如 7B，但功耗低、响应快，适合 24 小时在线的轻量级 Agent。
  • PC（4060Ti 8GB + 12GB）：跑 Qwen 2.5-Coder 7B，做复杂代码编写、逻辑分析和深度任务。55 tokens/s 的速度，真正的"秒回"体验。
  • 云端后备：通过 OpenClaw 接入 DeepSeek API，遇到 7B 搞不定的，花几分钱调用云端最强模型。这比买几张 4090 划算多了。

总结

这次踩坑让我明白几个道理：

  1. 参数不是越大越好。对于 8G 显卡，7B 就是顺畅的终点，14B 是忍耐的极限，27B 以上纯粹是折磨。
  2. 速度和体验比智力更重要。尤其是 Agent 这种高频交互场景，1.8 秒回完和 7 分钟回完，完全是两个次元的体验。
  3. 小模型不是蠢，是专。Qwen 2.5-Coder 7B 在写代码和调用工具上，比很多通用的大模型还要强。
  4. 硬件决定上限。N200 适合跑轻量级任务，4060Ti 才是本地大模型的主战场。不要指望用一个 6W 的 CPU 跑 GPT-4 级别的模型。

如果你也有类似的硬件配置，别纠结参数量了。选一个能跑满显存、秒速响应的 7B 模型，那种"刷屏"的感觉，比等半天蹦出一个字的"大模型"爽太多了。

写于 2026 年 4 月 26 日，南京。

附录：Qwen 版本速查表

版本 特点 推荐场景
Qwen 2.5 工业标准，生态成熟，参数齐全 最推荐，稳定开发首选
Qwen 3.5 过渡版本，端侧优化，偏科生 不推荐，除非需要在 N200 上跑极小模型
Qwen 3.6 最新版，强化 Agentic Coding 和推理链 追求智力可用，但小参数版本尚未发布
Qwen 3 不存在，被分拆成 2.5-Max 和 3.5/3.6 ❌ 忽略

我的 OpenClaw 技能项目：https://github.com/NNNNzs/agent-skills

加载评论中...