企业官网建设流程全解析

1. 省钱思路与整体方案

1.1 为什么要做本地部署

OpenClaw这类AI助手框架，功能越做越顺手，越容易让人忽略背后那条账单曲线。我自己用了一段时间之后，最先感受到的不是能力上限，而是每月的API费用在往上走。轻量聊天还好，一旦接上自动化任务、文档处理、批量代码审查，token消耗会以肉眼可见的速度膨胀。个人项目咬咬牙还能接受，小团队或者学生项目往往直接被预算卡住。

本地部署的核心思路，是把推理成本从“按token付费”变成“按电费摊销”。Ollama是我在这条路上用得最顺手的工具：它把模型文件下载、服务端启动、API暴露全部封装成极简命令，不需要自己写推理服务，也不用手动管理显存调度。装好之后，两条命令就能完成模型拉取和对话验证，再配一条环境变量就能把服务暴露到局域网。

这个方案解决的核心问题有三类：第一，降低高频使用场景的调用成本；第二，让数据请求不出内网，减少隐私顾虑；第三，不依赖外部服务可用性，断外网也能继续使用AI能力。适合人群包括自建知识库的个人用户、正在做自动化流程的开发者、以及数据中心安全要求高或者不想让数据流经公网链路的内部工具团队。

1.2 方案选型与成本对比

本地跑模型的方案其实不少，有直接写Python加载transformers的，有用各种推理框架的，也有自己封装API服务的。这些方案大多绕不开环境问题：依赖冲突、CUDA版本、显存分配，每一项都能消耗半天时间。Ollama的优势在于把复杂度下沉，模型格式统一、运行方式统一、接口统一，基本是开箱即用。

成本上做一个粗算，以7B量化模型为例，单次推理消耗的电费基本可以忽略，即使把整机功耗算进去，日常高频使用一天也不会超过一块钱。而同等使用量走云端API，按输入输出token累积计算，一个月下来几十到几百元是很常见的。对长期稳定使用的场景来说，本地部署的回本周期可能只需要一两个月。

硬件方面不用被“要一张好显卡”吓退。7B模型量化后大概4到5GB显存，现代游戏显卡基本都能跑。没有NVIDIA显卡，AMD显卡和纯CPU也都支持，CPU速度慢一些，但对低频调用场景完全够用。具体选型清单我放到第5章，先把安装和配置的全流程走通。

2. Ollama的安装与初始配置

2.1 安装前的环境确认

建议选一台24小时在线、网络稳定的机器当模型服务器，旧笔记本、迷你主机、NAS都可以。我个人用的是Linux环境，下面命令以Linux为主，Windows和macOS的差异点我会特别标注。

安装前先确认三件事：

1. 显卡情况。运行nvidia-smi，看显卡型号、驱动版本和显存大小。显存大小直接决定你能跑哪个档位的模型。没有NVIDIA显卡也不用慌，Ollama对AMD显卡和CPU都有支持，只是速度有差别。
2. 磁盘剩余空间。模型文件比较大，7B模型量化后约4到5GB，13B模型约8到9GB。如果模型打算放在非系统盘，需要留意Ollama的默认存储路径，必要时通过OLLAMA_MODELS环境变量改目录，这个变量在Linux和macOS下都有效，Windows下同样适用。
3. 网络连通性。拉取模型时需要访问模型仓库，一般家用宽带直连即可。如果之前下载经常失败，可以检查DNS设置，或者换一个网络时段再试。

我踩过的第一个坑就是磁盘空间。当时没看分区用量就直接把模型拉到默认目录，结果下载到一半提示磁盘满。后来用df -h看了一下，才发现系统分区已经没剩多少，最终把OLLAMA_MODELS指到了另一块数据盘才解决。建议你在下载之前就规划好模型存放路径，尤其是机器上有多块硬盘、系统盘又偏小的情况。

2.2 安装与模型拉取

Linux的安装方式非常简单，终端执行：

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

Windows和macOS可以直接下载官方安装包，按提示安装即可。装完先验证版本：

ollama --version

能正常显示版本号，说明安装成功。如果提示找不到命令，多半是安装路径没加入PATH，重新登录一次终端或者手动把安装目录加进环境变量就行。

接下来拉取模型。以我常用的通用型模型为例：

ollama pull qwen2.5:7b

第一次拉取会把整个模型下载到本地，速度取决于带宽和仓库状态，耐心等即可。下载完成后可以用下面命令查看本地已有模型：

ollama list

输出类似这样：

NAME ID SIZE MODIFIED qwen2.5:7b xxxx 4.7GB ...

注意模型名后面的:tag是有意义的，同一个系列会区分不同量化等级和规模，后面配置接口时必须使用完整的模型名，漏掉:7b或写错大小写都会导致模型找不到。

2.3 初验：本地跑通一次对话

先来最简单的一步：

ollama run qwen2.5:7b

进入交互界面后随便问一句“用一句话介绍你自己”，能正常输出，说明模型推理链路没问题。此时Ollama的API服务其实已经在后台运行，只是默认只绑定在本机回环地址上。

离开交互界面，直接测一把API：

curl http://127.0.0.1:11434/api/tags

如果返回一段包含模型列表的JSON，说明API服务正常。这一条验证非常关键，后续所有局域网访问、对接OpenClaw的操作，都是建立在这个API服务之上的。到这一步，单机部署已经完成，接下来要解决的是如何让局域网内的其他设备也能调用。

2.4 安装常见问题快查

安装阶段遇到的问题不算多，但有几个高频场景我列一下：

这些都属于一次性问题，解决之后基本不会再遇到。真正需要花时间的是局域网配置和对接环节，下面展开讲。

3. 局域网API：让其他设备也能调用

3.1 理解Ollama的默认监听

Ollama默认只监听127.0.0.1，也就是只允许本机访问。这是官方在安全上做的收紧，防止服务一启动就直接暴露到内网。局域网内其他设备想调这个API，第一步就是把这个监听地址放开。

但放开之前，要先想明白一个前提：内网环境是否可信。一旦把服务绑定到0.0.0.0，同一局域网内所有能访问该端口的设备，都有能力调用你的模型。家庭自用、公司内部可信网络的场景下，这个风险可控；但如果网络里有大量陌生设备接入，我建议先做好访问控制再放开，可以通过防火墙限制来源IP，或者在前面加一层带鉴权的代理。

另外一个容易忽略的点是，OpenClaw如果和Ollama装在同一台机器上，其实保持默认监听也能工作，地址填127.0.0.1就行。只有当客户端和模型服务器不在同一台设备上，或者你想让多台设备共享一个模型服务时，才需要做局域网暴露。

3.2 修改监听地址与端口

Linux下通过systemd服务管理时，推荐用override配置来修改：

sudo systemctl edit ollama

在打开的编辑器里填入：

[Service] Environment="OLLAMA_HOST=0.0.0.0:11434"

保存后重载并重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

如果没有使用systemd，而是手动启动服务，就直接在启动命令前加环境变量：

OLLAMA_HOST=0.0.0.0:11434 ollama serve

macOS也可以用上面的方式。Windows用户在系统设置里添加环境变量OLLAMA_HOST，值为0.0.0.0:11434，保存后重新打开终端或重启服务即可。

改完之后确认监听状态：

ss -tlnp | grep 11434

看到类似0.0.0.0:11434的输出，说明已经成功监听所有网卡。此时把本机验证时那条curl命令里的地址换成局域网地址来测：

curl http://<服务器局域网IP>:11434/api/tags

能正常返回JSON，说明局域网API已经打通。

3.3 防火墙、路由器与固定IP

监听地址放开之后，还有两个容易卡住的地方：防火墙和IP地址变化。

Linux上如果启用了ufw，需要放行11434端口：

sudo ufw allow 11434/tcp

没有启用ufw但用了其他防火墙方案，比如firewalld，就用firewall-cmd --permanent --add-port=11434/tcp再加firewall-cmd --reload。Windows用户需要在“高级安全Windows Defender防火墙”里新建入站规则，允许TCP 11434端口访问。macOS如果在系统设置里开了应用防火墙，也要把Ollama加入允许列表。

跑在虚拟机里的模型服务，还需要额外检查虚拟机网络模式。NAT模式下，宿主机和局域网其他设备不一定能直接访问到虚拟机，改成桥接模式通常是最省事的解决方案。我在某次部署中，服务进程看着一切正常，局域网就是访问不通，排查到最后发现是虚拟机网络模式的问题，改成桥接后立刻通了。

局域网访问方式确定之后，建议顺手给服务器设备设置固定IP地址。方法是在路由器DHCP设置里绑定设备的MAC地址，分配一个固定IP。否则一旦重启、DHCP重新分配，IP一变，客户端和OpenClaw里的配置全部要跟着改，排查起来非常头疼。

重要提示：Ollama本身不提供身份认证。绑定0.0.0.0之后，局域网内知道地址的人可以直接调用。安全和便利的平衡点，一定要在这一步想清楚再继续。

3.4 局域网多设备访问实测

打通局域网访问之后，我实际测过几类常见设备。同一网段内的笔记本和台式机，直接访问服务完全没问题。手机浏览器访问http://服务器IP:11434也能看到Ollama的提示页面。还有一台装OpenClaw的旧笔记本，走到局域网内任意网络接口，配置好API地址之后，都能稳定连接模型服务器。

实测下来的延迟数据很有参考价值：有线局域网环境下，一个普通对话请求从发出到拿到首个返回字符，基本在1秒以内，体感上和调用本地模型没有区别。Wi-Fi环境下会略高一些，但普通使用也能接受。如果同时有多台设备发起流式输出，Wi-Fi带宽可能会被吃满，文字还能勉强跟上，图片或长文本输出就会出现明显卡顿。多设备高频并发的场景，建议优先考虑有线连接。

4. 与OpenClaw对接的实操路径

4.1 模型接入方式

OpenClaw这类AI助手框架，一般都会留出自定义模型或自定义API的入口。对接Ollama有两种常见方式，按兼容性优先级列一下。

第一种，走OpenAI兼容接口。Ollama原生提供了/v1路径的OpenAI风格API，地址填：

http://<服务器局域网IP>:11434/v1

这样写的好处是，很多为云端API设计的框架配置不需要大改，把原来的https://api.xxx.com/v1换成这个局域网地址就行，只是把协议从https换成http，端口改为11434。

第二种，如果框架本身支持Ollama协议，可以直接把base_url填成：

http://<服务器局域网IP>:11434

框架会自动使用Ollama原生接口通信。两种方式最终的效果都是把模型推理请求从云端切到本地，区别只在于框架侧走的协议路径不同。

对接时有几个细节很容易踩坑。第一，框架侧即使要求填API Key，随便填一个占位字符串就行，比如ollama或者local，Ollama本身不校验Key，但也不能留空，否则某些框架会报配置不完整。第二，模型名必须和ollama list输出完全一致，包括:7b这种tag后缀，否则框架会提示模型不存在。第三，OpenClaw跑在哪台设备、要调哪台服务器的Ollama，就把地址填成对应的局域网IP，不要填127.0.0.1，除非两者在同一台机器上。

4.2 参数调优与实际效果

把模型接入框架只是开始，真正决定用起来舒不舒服的是参数匹配。Ollama相对云端API有一个优势：所有参数都是本地可控的，调试起来非常直观。

几个常用的调整维度：

• 温度temperature：我习惯设0.7左右，兼顾稳定性和一定的创造性。需要更严谨的输出时放到0.2到0.4，需要发散创意时可以调到1.0以上。
• 上下文长度num_ctx：默认有些模型只有2048，处理长文档时会明显感觉到“忘事”。做知识类任务建议加到8192或更高，但代价是显存占用上升，需要在自己机器的显存余量范围内调整。
• 并发数OLLAMA_NUM_PARALLEL：Ollama有一定并发能力，但机器配置不高时并发过多容易触发内存溢出。低配机器建议设成1或2，优先保证单次响应稳定。
• 最大加载模型数OLLAMA_MAX_LOADED_MODELS：显存不大时建议设成1，避免多个模型反复换入换出造成严重卡顿。

我用7B模型做实际体验后的结论是：日常问答、文案改写、代码补全、常见报错分析，完全够用，速度和云端API接近，只是略慢一点点。做复杂推理、长文档分析或者高质量代码重构时，模型推理质量问题开始暴露，这时候13B档位模型的差距就很明显。显存到16GB的话，直接上13B档位，体验会有实质提升。

效果好坏不能只看模型档位。OpenClaw这一侧的任务编排方式对体验影响也很大，把大的任务拆成小步骤、控制每次请求的上下文长度，不论云端还是本地都能跑得更稳。我在对接时把OpenClaw的提示词做了精简，并用挂了多次任务，确实比一开始一股脑丢给模型要稳定得多。

4.3 多机协作场景

本地部署还有一个很实用的场景：多台设备共享一个模型服务。同一局域网里，可以有一台专门跑Ollama的服务器，笔记本、台式机、甚至迷你主机上的OpenClaw实例都走局域网API调用。

这样做的收益很明显。第一，每台客户端不需要重复下载模型文件，也不需要各自配显卡，共用一份算力资源。第二，维护只集中在服务器端，模型升级、更换都只改一台机器，客户端不用管。第三，模型文件集中存放，磁盘占用也更好管理。

从实操看，多机共享时要注意一个隐性瓶颈：Wi-Fi带宽。办公室或家里的无线网络，多台设备同时请求大模型流式输出时，网络竞争会比较明显。建议把并发数调低，或者给模型服务器用有线连接。如果是高负载团队使用，可以再考虑在服务器上限制单次请求的最大token数，避免个别任务长时间占用计算资源。

5. 常见问题与排查记录

5.1 API连通性排查

我最常遇到的典型场景是：OpenClaw那边配置全都填好了，还是一直报连接失败。这种问题的排查顺序很重要，从近到远一层层来。

首先在本机验一次，排除服务状态问题：

curl http://127.0.0.1:11434/api/tags

本机不通，先看服务是否在运行，ps aux | grep ollama确认进程存在，再看ss -tlnp | grep 11434确认端口监听。本机通、局域网不通，重点看三处：监听地址是不是0.0.0.0、防火墙有没有放行、两台机器的IP是不是同一网段。

ping <服务器局域网IP>

能通但端口不通，用telnet试试：

telnet <服务器局域网IP> 11434

如果端口连不上，基本就是防火墙拦截或监听地址没改成功。如果telnet能连上但API返回异常，那问题可能出在请求格式上，比如模型名写错或路径拼错。把这几层排查做完，绝大部分连通性问题都能定位。

5.2 性能与显存问题

另一个高频问题是“模型响应慢”。可疑点不少，但不外乎几类：模型没有跑到GPU上、显存不够导致部分层被换到CPU计算、或者并发任务互相争抢算力。

用ollama ps查看当前加载的模型，正常情况下应该能看到模型已经驻留在GPU。再用nvidia-smi看显存占用，如果显存占用接近上限但模型仍在跑，可能已经出现CPU回退。此时最有效的解法是换更小的模型，或者换量化等级更低的版本。

显存不足还有一个常见连带现象：同时加载多个模型导致反复换入换出，表现为“第一次请求很慢，后面变快”。如果OpenClaw里配置了多个模型备用，建议把OLLAMA_MAX_LOADED_MODELS=1，让Ollama只常驻一个模型，减少换载开销。

如果机器完全没有独立显卡，纯CPU推理的物理上限就在那里，这种情况适合低频轻量的使用方式。调整OpenClaw侧的请求频率、缩短单次对话长度之后，体验会好不少。别指望CPU跑大模型能有多快，定位就是“能用但不追求速度”。

5.3 模型选择参考

模型选择直接关系省钱方案的最终体验，给一份我实测过、有代表性的参考清单：

同一档位里的不同模型风格差异也很大，有的更适合中文，有的更适合指令遵循。如果主要跑中文任务，优先选中文语料占比高、对中文表达更友好的模型；如果做代码相关任务，选有专项训练的模型效果更明显。

一个容易忽略的点：量化等级不是越低越好。Q4量化占用显存少，但输出质量对比高量化版会有可感知的下降。显存有富余时，优先选更高量化等级，或者直接上原版精度，别为了省那点显存牺牲质量。模型名的tag里一般会注明量化等级，下载前看一眼再决定。

最后再补一个安全提醒：局域网放开API之后，模型本身不具备鉴权能力。如果对安全性要求比较高，建议在Ollama前面加一层带鉴权的代理，只放行携带正确Key的请求，这个改造工作量不大，但对安全性提升明显，尤其是多人共享模型的场景，一定要做。

我在实际使用中的体会是：本地部署的价值不在于替换一切云端服务，而是把日常高频、低敏感的推理需求分流到本地，把云端预算留给更重型的任务。省钱计划的核心不是“绝对不花钱”，而是把钱花在刀刃上。这套方案我跑了几个月，稳定性和成本表现都符合预期。如果后面再升级，我会优先考虑扩充显存和换更高档位的模型，到时候整个方案的体验还能再上一个台阶。