我们折腾群里最近聊天的画风彻底变了。以前大家比的是谁家新框架跑得快哪套配置敢开满负载现在每天早上有人晒显存占用曲线中午发一段本地模型的对话截图到了晚上还会一本正经地问明天该给虾换什么虾粮。这里说的虾就是跑在自己机器上的本地大语言模型而人人养虾是 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 量化、单次推理、不考虑超大上下文来算模型参数量理论显存需求推荐最低配置适合的任务场景7B 级别6GB 左右8GB 显卡翻译、摘要、代码补全、闲聊14B 级别10GB 左右16GB 显卡中等难度的写作、结构化信息抽取32B 级别18GB 左右24GB 显卡复杂指令跟随、角色扮演、长文档分析70B 级别38GB 左右专业级显卡或双卡高难度推理、高质量长文生成注意这只是一个粗糙的参考。上下文窗口拉长后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 做成了带锁文件的服务启动前自动清理残留再没出过同样的问题。我把这段时间遇到的高频问题整理成一个速查表方便你直接对照症状常见原因优先排查项推理中途报错显存不足、KV Cache 超限看显存占用降低 context输出乱码、繁体采样参数偏高降 temperature重复同一句话参数设置不当、模板错误调 repetition_penalty检查模板速度极慢模型没有放入显存看 GPU 占用检查 gpu_layers服务起不来端口占用、模型文件损坏看日志清理残留进程verify 模型6. 把虾养肥本地模型的高级玩法6.1 变成全家桶接入聊天界面与多端调用命令行用熟了之后你会想要一个更舒服的界面。OpenClaw 服务本身就暴露了标准的 HTTP 接口我把它接到了自己常用的聊天前端上手机、平板、电脑都能访问同一个本地模型。操作上只需要把配置里的 host 从 127.0.0.1 改成局域网地址然后在别的设备上填上服务地址就行。这里必须提醒一句如果要暴露到公网一定要加鉴权否则你的虾就是所有人共享的虾。我建议默认只在内网用真需要远程访问就加一层身份验证再上。6.2 给虾开小灶私人知识库养虾最有成就感的时刻是把它从一个通用助手变成懂你业务的助理。实现方式就是现在社区常说的知识库方案把你的文档切块、变成向量、存进向量库每次提问时先检索相关内容再连同问题一起丢给模型。我之前搭过一个个人笔记助手的例子。把历史笔记整理成 markdown 文件按章节切块构建了一个小规模向量库。之后问它我上个月记录的关于某个方案的思路是什么它能准确引用笔记内容回答而不是凭空编造。这个能力对做研究、写文档的朋友来说非常实用。注意一点知识库的质量取决于文档切块和检索效果。切得太碎会丢失上下文切得太大又会超出模型的上下文窗口。我一般按 500 字左右一个块再加 100 字重叠效果比较稳。6.3 多只虾分工协作养虾养出经验之后我不再只用一只虾了。OpenClaw 支持配置多个模型档案一键切换所以我现在的标配是一只 7B 模型负责分类、抽取、格式转换这种高频率低难度任务一只 14B 模型负责日常对话和写作偶尔有大活再临时上 32B 模型跑一跑。分工的好处显而易见小模型快、省电、不占资源整天开着也没压力大模型只在需要的时候启动避免长时间高负载。这一套下来我电脑的日常负担其实比原来只跑一个大模型还要低。6.4 定时投喂自动化工作流把模型接进定时任务之后你会发现很多事情可以完全自动化。我用脚本做了两个特别实用的场景一个是日志摘要。服务器每天产生大量日志我写了一个定时任务每天凌晨把当天的日志按时间段切成几段交给本地模型生成摘要第二天早上看一眼摘要就知道有没有异常。另一个是日报起草把当天的工作记录丢给模型让它整理成结构化的日报草稿稍微改改就能发。自动化这件事的爽点在于一旦跑通就不需要再人工介入。模型就安安静静蹲在那一角每天自动干活定期看看日志有没有异常就行。我自己在实际操作中最大的体会是养虾这事头两周最痛苦要跟硬件斗、跟配置斗、跟模型脾气斗但只要把一只虾稳定养起来后面基本就是一马平川。现在每天开机第一件事就是看一眼日志顺手跟模型聊两句确认状态已经成了跟浇水养花一样的日常习惯。如果你正准备入坑我的建议很简单别追求一步到位先找一台能跑 7B 模型的机器老老实实养一只小虾跑通了再慢慢换大缸、加配置。等你把一只虾养到能干活的那一天回头再看这一段折腾的路会觉得每一分钟都值。