从零开始本地部署大模型：OpenClaw养虾实战指南

我们折腾群里最近聊天的画风彻底变了。以前大家比的是谁家新框架跑得快，哪套配置敢开满负载，现在每天早上有人晒显存占用曲线，中午发一段本地模型的对话截图，到了晚上还会一本正经地问"明天该给虾换什么虾粮"。这里说的"虾"，就是跑在自己机器上的本地大语言模型；而"人人养虾"是 OpenClaw 这个开源项目带起来的风气——它把本地模型的下载、安装、配置、调用打包成了一条龙工具链，让普通用户也能在自家电脑或者小工作室里部署出自己的 AI 模型，像在阳台上养一缸虾那样轻松。这篇文章我想把从零开始"养虾"的完整过程、硬件门槛、选型思路、部署操作，以及我踩过的那些坑都梳理清楚，给准备入坑的朋友一份尽量少走弯路的参考。

1. 先搞清楚："养虾"养的到底是什么

1.1 本地模型的本质：一只住在硬盘里的"数字虾"

大语言模型本质上是一大堆权重参数加上一个推理程序。所谓"本地模型"，就是让这套东西完全运行在你自己的硬件上，不依赖任何云端服务。OpenClaw 这个项目做的事情很简单也很实在：把所有繁琐的底层操作包起来，让你像下载一个软件一样把模型拉下来，再通过统一的命令行和接口去使用它。

"养虾"这个说法我很喜欢，因为虾这个东西很形象——它小、好养活、品种多，而且带钳子（claw），正好对应 OpenClaw 的"爪"。社区里把下载模型叫"领虾苗"，把跑模型叫"下塘"，把调优叫"喂虾粮"，把模型崩溃叫"虾病了"。一套比喻下来，原本冷冰冰的本地推理突然就变得很有生活气息，也让很多本来不敢碰的人愿意试一试。

技术底子其实不复杂：模型文件通过一个推理框架加载进内存和显存，你输入一段文字，模型按概率逐字生成回复。关键在于"逐字生成"这个过程非常吃算力，所以硬件决定了你能养多大的虾、养得多快。理解了这一层，后面所有选型问题都能顺着推理出来。

1.2 为什么自己养，而不是直接买"虾肉"吃

很多人会问：云端 API 已经很成熟了，为什么要自己折腾本地模型？我的答案是有四批人各有各的理由。

第一批是隐私敏感型。公司内部文档、个人聊天记录、未公开的代码，这些东西送进别人的服务器总归不踏实。本地部署意味着数据完全不出门，连网都可以断掉，这一点对很多行业场景是硬需求。

第二批是成本敏感型。API 是按 token 计费的，高频调用、长文本处理、批量任务跑起来，账单涨得飞快。本地模型是一次性硬件投入，用多了反而划算，尤其适合那种一天要跑几百次批处理脚本的场景。

第三批是网络环境受限型。有些内网环境根本连不上外网服务，或者网络质量不稳定，这时候一个离线可用的本地模型就是唯一解。

第四批纯粹是折腾型。本地模型的训练细节、量化原理、推理性能调优，每一项都是很好的学习素材。我认识的好几个朋友，都是从"养虾"开始真正搞懂了注意力机制和 KV Cache 到底是怎么回事。

但我也得泼一盆冷水：本地模型目前的智商上限和商用大模型还是有差距的，尤其在做复杂推理、长文写作、常识问答的时候，差距很明显。如果你期望的是"免费版顶级大模型"，那大概率会失望。本地模型更像是一个听话、私密、可定制的基础员工，你需要调教它，而不是指望它天生全能。

1.3 什么样的人适合入坑

结合我这段时间观察到的社群情况，适合立刻入坑的人有三类：

• 有编程基础，想研究模型推理原理、量化细节的技术爱好者；
• 对数据隐私有明确要求，需要离线可用 AI 工具的从业者；
• 有旧电脑或者闲置显卡，想废物利用的低成本玩家。

暂时不适合的人我也直说：完全零基础又不想看任何文档的纯小白，以及手头连 8G 内存都没有的老古董机器用户。前者会因为配置问题崩溃，后者会因为跑不动而劝退。先把基础技能补一补，或者升级一下硬件再来，体验会好很多。

2. 池塘配多大：硬件门槛与选型逻辑

2.1 显存是钢需：先算清楚模型到底吃多少显存

本地推理最核心的硬件指标是显存。模型文件加载后要常驻显存，每次生成新 token 时所有参数都要参与计算，显存不够根本跑不起来，跑起来也会慢得难以忍受。

先说一个快速估算公式：全精度（FP16）下，模型参数每 10 亿个大约需要 2GB 显存。但实际部署很少有人跑全精度，因为量化技术可以把模型压缩到原来的一半甚至四分之一。以 4bit 量化为基准，每 10 亿参数大约只需要 0.6GB 到 0.8GB 显存，再加上上下文缓存和推理框架自身的开销，实际需求可以按参数量的 0.9 到 1.1 倍来估。

我整理了一张常见的选型对照表，按 4bit 量化、单次推理、不考虑超大上下文来算：

注意这只是一个粗糙的参考。上下文窗口拉长后，KV Cache 会吃掉额外显存，所以实际选型一定要在估算值之上留出 20% 到 30% 的余量。我自己第一次就吃过这个亏：按理论值买了台显存刚好够的机器，结果上下文一拉长，推理直接崩了，最后只能降级模型。

2.2 内存、硬盘与散热这些"配角"也不能省

很多人把注意力全放在显卡上，结果忽略了另外几个容易出问题的部件。

内存方面，16GB 是底线，32GB 会比较舒服。推理框架虽然主要用显存，但加载模型、处理输入输出、运行前端界面都会占内存。更关键的是，如果显存不够，模型的一部分层会退到内存里计算，内存太小就会直接卡死。

硬盘反而最容易被低估。现在的模型文件动辄 4GB 到 40GB，而且你可能同时养好几只虾、备份好几个版本。我建议至少留出 100GB 可用空间，如果打算玩大模型，500GB 的固态硬盘也不会浪费。另外模型读取很快，机械硬盘加载大模型会等得让人怀疑人生，尽量用固态。

散热和电源是那种"平时没感觉，出问题时才知道厉害"的部件。本地推理是长时间高负载运行，显卡温度常年顶着 80 度上下。我见过朋友用办公小主机跑 14B 模型，跑了半小时直接过热重启。有条件就上塔式散热，机箱风道别堵，电源功率留足 50% 的余量。

2.3 没有大显存的三个备选路线

如果手头确实没有好显卡，也不是完全没法玩，我试过几个替代方案：

第一个方案是纯 CPU 推理。选一个 7B 甚至 3B 级别的小模型，用低比特量化，纯 CPU 推理虽然慢，但胜在兼容性好、几乎什么电脑都能跑。实测下来，7B 量化模型在主流 CPU 上大概每秒能出 3 到 8 个 token，用来做简单的文本分类、关键词提取、格式转换完全够用。

第二个方案是云上租卡。把模型部署在别人的高配机器上，按小时付费。这个方案适合临时要跑大模型、又不想斥巨资买显卡的人。需要注意的是，云上部署要额外处理数据传输和远程访问的安全问题，别把敏感资料直接丢上去。

第三个方案是混合模式：小任务用本地小模型，大任务才调用云端 API。这样既保住了隐私底线，又能在关键任务上拿到更高的质量。我把这个方案叫"大小虾搭配"，性价比其实是最高的。

3. 虾苗怎么挑：参数规模、量化格式与任务匹配

3.1 参数规模不是越大越好

选模型的时候，最容易犯的错就是"我全都要"。70B 模型确实聪明，但你得先问问自己的显卡答不答应，自己的任务需不需要这么高的智商。

我的判断标准是：任务复杂度决定参数量下线，硬件条件决定上限。像 SQL 生成、代码补全这种结构性很强的任务，7B 模型就干得不错；写软文、做头脑风暴这种需要发散的任务，14B 起步会更稳；涉及逻辑推理、数学题、长文本因果分析，才建议上 32B 以上。

另一个容易被忽略的因素是速度。模型越大，每生成一个 token 的时间越长。聊天场景下，每秒 10 到 20 个 token 体感还过得去；如果只有每秒 2 个 token，等回复的过程会让人焦虑到想摔键盘。所以选模型前，先想清楚自己能不能忍受那个速度。

3.2 量化：用一点智商换一身轻

量化是本地模型能"人人养得起"的最大功臣。它做的事情很简单：把原本用 16 位浮点数存的权重，压缩成 8 位整数甚至 4 位整数，模型体积直接缩水一半以上，速度还更快，代价是智商有一点点下降。

以我实测的经验来说：8bit 量化对输出质量的影响几乎可以忽略，4bit 量化在大多数任务上下降也不明显，但在一些需要严谨推理的场景里确实会出现"答非所问"的情况。所以我通常推荐从 4bit 量化起手，跑通了再决定要不要换更高精度。

量化文件也有细分，常见的有 K 量化和普通量化，还有一些特殊变体。实际操作中我建议认准社区评分高、下载量大的那个量化档位，一般默认推荐哪个就用哪个。真没必要为了那 1% 的精度提升多花几个小时的下载时间。

3.3 同一个家族的"不同亚种"

除了规模和量化，还要注意模型的"性格"差异。同一个底座可以调教出不同变种：有的侧重对话，有的侧重指令执行，有的专门为代码优化，还有的适合函数调用和工具使用。

OpenClaw 在导入模型的时候会识别这些能力标签。以我平时的工作流为例，跑批处理脚本时用的是"指令版"，追求稳定和格式正确；跟模型闲聊、做创意发想的时候切到"对话版"，回复更活泼、更像真人。这里没有绝对的好坏，只有合不合适。

还有一点要提：有些模型是"基座版"，没有经过指令微调，它只会接着你的话往下续写，不会乖乖回答你的问题。新手刚入坑最容易踩这个坑——兴冲冲下了个大模型，发现它根本不好好说话，其实是虾苗选错了亚种。

3.4 我总结的三条选苗原则

养了几个月虾之后，我给自己定了三条选苗规矩，分享出来供你参考：

第一，先定任务再定大小。动手下载前先列一个清单：这个模型要干什么，需要多高的智商，我能忍受多慢的速度。清单写清楚了再对照表格选尺寸，不要凭感觉。

第二，默认选 4bit 量化。除非跑出来的结果明显不对，否则不建议一上来就追求高精度。等把流程跑通、确认了自己的需求，再往高精度升级也不迟。

第三，显存余量至少留 20%。不要卡着理论值买配置，上下文窗口、并发请求、后台任务都会动态占用显存。余量留足，后面能少很多麻烦。

4. 从下载到开张：OpenClaw 部署实操

4.1 准备阶段：目录规划与软件安装

第一次部署 OpenClaw 之前，先把目录结构规划好。我的习惯是把模型、配置、日志分开存，方便后续同时管理多只虾：

mkdir -p ~/openclaw/models mkdir -p ~/openclaw/config mkdir -p ~/openclaw/logs

然后在 OpenClaw 安装完成后，先跑一轮环境自检命令，它会检查显卡驱动、计算环境、可用内存和磁盘空间。这一步很重要，能提前发现驱动装错、计算库版本不匹配之类的问题：

openclaw doctor

我第一次部署时就是靠这个命令发现显卡计算库没装上，自己手动折腾了半天，结果一条自检就定位了问题。所以千万别跳过自检这一步。

4.2 拉取模型与校验完整性

OpenClaw 的模型管理命令做得比较顺手。拉取模型、安装、校验可以一条命令搞定：

openclaw pull shrimp-14b-q4 openclaw verify models/shrimp-14b-q4

下载模型建议用断点续传工具或者 OpenClaw 自带的下载器。模型文件动辄好几个 GB，网络一抖动就可能下载失败，断点续传能省下大量重复劳动。校验那一步也不是走过场，我遇到过模型文件下载不完整导致推理结果乱码的问题，verify 出来的哈希值对不上，重新下载才好。

4.3 配置文件里的几个关键项

OpenClaw 启动时会读取一个配置文件。我挑几个直接影响使用体验的字段说一下，拿我的配置做示例：

server: host: 127.0.0.1 port: 8080 model: path: models/shrimp-14b-q4 context: 4096 gpu_layers: 999 sampling: temperature: 0.7 top_p: 0.9 repetition_penalty: 1.05

先看 context。这个字段决定模型能记住多长的对话历史，值越大越聪明，但也越吃显存。4096 是我认为平衡点比较好的一档，日常聊天够用，做长文分析再往上调。

再看 gpu_layers。它决定模型有多少层被分配到显卡上计算。填 999 是让 OpenClaw 尽可能把所有层都往显卡里塞，跑得最快；但如果显存不够，就要手动减这个值，让一部分层留在内存里。

最后是采样参数。temperature 控制随机性，0.7 左右是标准值，要它更稳就降到 0.4，要它更活跃就调到 1.0。repetition_penalty 是防复读机的，遇到模型翻来覆去说同一句话的时候，优先调它。

4.4 首次启动与验证

配置好之后，启动服务：

openclaw serve --config config/site.yaml

然后再开一个终端，用命令行直接跟你的虾对话：

openclaw chat --model shrimp-14b-q4

第一次对话我建议别整太复杂的，先问一句"你是基于什么模型构建的？请用一句话说明你的能力范围"。这一步不是为了测试智商，而是验证整个链路通不通。如果模型有正常回复，说明加载成功、推理正常、输出没乱码，这个虾算是正式下塘了。

4.5 首次运行时的三个检查点

跑起来之后别急着开心，按下面的顺序看一眼状态：

第一，显存占用。用系统监控工具看显卡显存占用率，如果跑一个简单问答就吃掉 90% 以上的显存，说明配置偏紧，后续上下文一拉长就会爆。

第二，显卡温度。连续对话五分钟，看温度是否稳定在安全范围内。温度异常说明散热有问题，得处理，不然长时间运行容易崩。

第三，日志输出。OpenClaw 的日志里能看到每轮请求的耗时和显存记录，这些数据后面调优都用得上，记得存好。

5. 虾病了怎么办：高频故障与完整排查链路

5.1 显存爆掉：加长上下文后的血泪教训

这是我踩得最深的一个坑。之前跑一个 14B 模型，默认上下文 4096 一切正常。后来我想让它读一篇比较长的文档，把 context 调到了 8192，结果推理执行到一半直接报错，日志里写的是显存分配失败。

排查链路是这样的：先看显卡显存，发现确实满了；再看内存，也吃掉了很大一块。问题根源在于 KV Cache——上下文越长，这个缓存占用的显存就越多，而且是线性增长。最后我的解决方法是把 context 调回 4096，然后改用分块读取文档的方式，把长文拆成几段分别问。这也提醒我一件事：显存余量不只是留给模型权重的，更要留给上下文。

5.2 中文输出翻车：繁体、乱码、复读机

本地模型最容易让中文用户抓狂的就是输出质量不稳定。我遇到过三类翻车：突然切繁体、出现乱码、不通顺的复读。

排查看下来，大部分问题出在采样参数和提示词模板上。切繁体和乱码通常是 temperature 太高，模型在概率分布上飘了，降到 0.5 以下就好很多。复读则多半是模型没理解对话格式，需要检查 OpenClaw 是否正确套用了对应的提示词模板。

另外还有一个小技巧：如果模型总是在特定话题上复读，可以手动调高 repetition_penalty 到 1.1 或 1.15。但注意别调太高，否则模型会变得语无伦次，像被掐住脖子一样。

5.3 速度慢到怀疑人生：显卡根本没干活

有段时间我的虾慢得离谱，生成一句话要半分钟。一开始我以为模型太大，后来无意间看了一眼显卡状态，发现显存占用 0%，CPU 却拉满。

这才是问题所在：模型层全部被塞到了 CPU 上计算，显卡在旁边看戏。原因多半是 gpu_layers 配置没生效，或者显卡计算环境安装不完整。排查方法是先看任务管理器里的 GPU 占用，如果没有利用率，说明加载逻辑有问题；再去检查 OpenClaw 的日志里是否提示"model loaded to CPU only"之类的话。修复后 gpu_layers 生效，速度瞬间提升十倍不止。

5.4 重启后服务起不来

有一回我给机器装了系统更新，重启之后 OpenClaw 怎么样都起不来。报错信息很模糊，只说"failed to start"。排查过程是最典型的故障定位思路：先看端口占用，发现 8080 被一个残留进程占着；杀掉之后服务能起了，但新请求又一直超时。

再查日志，发现模型文件校验失败。原来是上次运行时生成了一个临时文件，断电后处于不一致状态。清理临时文件、重新 verify 模型、再启动，问题才彻底解决。这次之后我把 OpenClaw 做成了带锁文件的服务，启动前自动清理残留，再没出过同样的问题。

我把这段时间遇到的高频问题整理成一个速查表，方便你直接对照：

6. 把虾养肥：本地模型的高级玩法

6.1 变成全家桶：接入聊天界面与多端调用

命令行用熟了之后，你会想要一个更舒服的界面。OpenClaw 服务本身就暴露了标准的 HTTP 接口，我把它接到了自己常用的聊天前端上，手机、平板、电脑都能访问同一个本地模型。

操作上只需要把配置里的 host 从 127.0.0.1 改成局域网地址，然后在别的设备上填上服务地址就行。这里必须提醒一句：如果要暴露到公网，一定要加鉴权，否则你的虾就是所有人共享的虾。我建议默认只在内网用，真需要远程访问就加一层身份验证再上。

6.2 给虾开小灶：私人知识库

养虾最有成就感的时刻，是把它从一个通用助手变成懂你业务的助理。实现方式就是现在社区常说的知识库方案：把你的文档切块、变成向量、存进向量库，每次提问时先检索相关内容，再连同问题一起丢给模型。

我之前搭过一个个人笔记助手的例子。把历史笔记整理成 markdown 文件，按章节切块，构建了一个小规模向量库。之后问它"我上个月记录的关于某个方案的思路是什么"，它能准确引用笔记内容回答，而不是凭空编造。这个能力对做研究、写文档的朋友来说非常实用。

注意一点：知识库的质量取决于文档切块和检索效果。切得太碎会丢失上下文，切得太大又会超出模型的上下文窗口。我一般按 500 字左右一个块，再加 100 字重叠，效果比较稳。

6.3 多只虾分工协作

养虾养出经验之后，我不再只用一只虾了。OpenClaw 支持配置多个模型档案，一键切换，所以我现在的标配是：一只 7B 模型负责分类、抽取、格式转换这种高频率低难度任务；一只 14B 模型负责日常对话和写作；偶尔有大活，再临时上 32B 模型跑一跑。

分工的好处显而易见：小模型快、省电、不占资源，整天开着也没压力；大模型只在需要的时候启动，避免长时间高负载。这一套下来，我电脑的日常负担其实比原来只跑一个大模型还要低。

6.4 定时投喂：自动化工作流

把模型接进定时任务之后，你会发现很多事情可以完全自动化。我用脚本做了两个特别实用的场景：

一个是日志摘要。服务器每天产生大量日志，我写了一个定时任务，每天凌晨把当天的日志按时间段切成几段，交给本地模型生成摘要，第二天早上看一眼摘要就知道有没有异常。另一个是日报起草，把当天的工作记录丢给模型，让它整理成结构化的日报草稿，稍微改改就能发。

自动化这件事的爽点在于，一旦跑通就不需要再人工介入。模型就安安静静蹲在那一角，每天自动干活，定期看看日志有没有异常就行。

我自己在实际操作中最大的体会是：养虾这事，头两周最痛苦，要跟硬件斗、跟配置斗、跟模型脾气斗；但只要把一只虾稳定养起来，后面基本就是一马平川。现在每天开机第一件事就是看一眼日志，顺手跟模型聊两句确认状态，已经成了跟浇水养花一样的日常习惯。如果你正准备入坑，我的建议很简单：别追求一步到位，先找一台能跑 7B 模型的机器，老老实实养一只小虾，跑通了再慢慢换大缸、加配置。等你把一只虾养到能干活的那一天，回头再看这一段折腾的路，会觉得每一分钟都值。