企业官网建设流程全解析

前阵子有个临时需求，要给一批内部文档做摘要和问答。直接用在线大模型服务其实很方便，但文档里有大量未公开的业务细节，每次都把内容丢给别人的接口，我这边心里一直不踏实。加上那段时间线上服务隔三差五抽风，一个长文档跑到一半连接断了，整个流程就得重来。于是我把目光放到了本地部署Ollama上——在自己机器上跑开源模型，数据不出本机，断网也能用，花多少电费自己心里有数。这篇就聊一聊我从零开始把Ollama部署起来、跑通模型、直到接入现有工具链的全过程，包括中间踩过的几个坑。如果你也想在自己电脑上部署一套本地大模型，这篇文章应该能帮你少走不少弯路。

1. 别急着装，先算清楚本地部署Ollama这笔账

1.1 什么样的需求才值得落到本地

先说结论：本地部署不是万金油，但有些场景确实非它不可。

第一类是数据敏感的活。比如处理内部文档、客户代码、私人对话记录，这些内容一旦送给在线服务，就脱离了你的控制范围。本地模型跑完的中间结果、生成内容、上下文缓存全部留在本机磁盘上，关掉服务就干干净净。对于把隐私当底线的人来说，这是最根本的动机。我当时就是因为文档里全是未公开的业务细节，才决定把整条链路搬到本地。

第二类是网络不稳定的场景。在线API依赖外网，网络波动、服务商限流、高峰期排队，都会让你的自动化流程随时中断。本地部署之后，模型常驻本机，请求走的是localhost，只要机器不宕机，接口就一直可用。离线环境更是如此——有些工作台本身就不允许联网，这时候本地模型几乎是唯一选择。

第三类是成本可预测。在线API按token计费，看起来单次很便宜，但跑批量任务、长文档、频繁迭代提示词时，账单会变得非常难控。本地部署的成本是固定的：一次硬件投入加上日常电费。模型推理过程中的电力开销远低于同样量的在线API费用。我自己算过一笔账，把周末跑批量的活全部切到本地之后，一个月省下来的额度相当可观。

1.2 不适合本地的三种情况

反过来，下面三种情况我劝你别折腾本地部署。

第一，硬件太老。内存低于8GB的老办公本，跑7B参数模型都够呛，加载要等很久，生成速度也慢得让人怀疑人生。除非你愿意接受每分钟几百字符的龟速输出，否则不建议。

第二，对模型能力天花板有要求。本地能跑得动的开源模型，参数规模摆在那里，复杂代码生成、多步数学推理、长文本深度理解这类任务，和在线大模型还是有明显差距。如果你的核心场景是这些，别为难自己的机器，踏实用在线服务更省心。

第三，需要生产级高并发。本地单机模型的并发能力有上限，特别是没有专业显卡时，连开几个会话内存就吃紧了。真要对外提供稳定服务，还是得靠正经的云端资源。

提示：本地部署和在线服务不是非此即彼。我现在的做法是——日常总结、格式转换、文本分类全走本地；遇到真正困难的推理任务再调用在线服务。混搭使用，成本和体验都能兼顾。

1.3 本地与在线的关键差异对照

2. 装好不是重点，环境检查才是部署成功的一半

2.1 不同系统的安装入口

Ollama的安装本身没什么难度，三种主流系统都有官方路子：

• Windows：下载官方安装包，图形化向导，双击点完就行，装完自动注册为系统服务。
• macOS：用brew装最省事，brew install ollama，装完直接命令行启动。
• Linux：官方提供一键脚本，curl -fsSL https://ollama.com/install.sh | sh，脚本会自己处理systemd服务注册。

但我要提醒一句：装好不等于部署完成。很多人就是卡在这一步之后——装完了，却不知道模型下到哪、服务怎么控制、环境变量没配对，结果一跑就报错。

2.2 安装后的三项环境检查

部署完先别急着拉模型，按下面三步检查环境。

第一，磁盘空间。模型文件体积超出很多人的预期：7B参数模型大概4GB左右，13B到8GB，70B直接奔着40GB去。用df -h看一眼剩余空间，别等下载到一半才提示磁盘满。如果系统盘空间紧张，在下一步就提前把模型目录迁出去。

第二，GPU识别情况。有独立显卡的机器，确认驱动装好，跑nvidia-smi看看显存和使用情况。Apple Silicon的Mac用户要注意Metal支持是否正常。怎么判断Ollama是否用上了GPU？很简单：运行一个模型，观察加载日志里有没有GPU相关的识别信息，或者直接用同一模型对比CPU模式和默认模式的生成速度，速度快一倍以上说明GPU生效了。

第三，端口占用。Ollama默认监听11434端口。如果你机器上有其他服务占了这个端口，Ollama会启动失败。先用netstat -ano | findstr 11434（Windows）或lsof -i :11434（macOS/Linux）查一下。冲突了就通过下文的环境变量改掉。

2.3 重要的环境变量

环境变量是Ollama部署里最容易被忽略的一环。把它们集中记一下：

Windows用户去系统环境变量里加，macOS和Linux用户在~/.zshrc或~/.bashrc里export。如果用systemd托管（Linux一键脚本默认就是），则要在服务文件里加Environment字段，改完重启服务。

3. 第一次跑通模型：从拉取模型到正常对话的完整操作

3.1 拉取与运行一条命令即可

环境检查没问题，接下来就是拉模型。Ollama仓库里模型命名规则是名称:标签，标签通常代表参数规模和量化方式。我建议先显式拉取，不要直接ollama run让它自动下，这样你能完整看到下载进度：

ollama pull qwen2.5:7b

下载完成后，运行：

ollama run qwen2.5:7b

提示：如果下载过程中网络中断了，不用慌，重新执行一次ollama pull，它会基于已下载的部分继续，不需要从头开始。

为什么要用:7b这个标签？因为同一个名字下往往有多个参数版本，比如qwen2.5:0.5b、qwen2.5:7b、qwen2.5:14b、qwen2.5:72b。如果你什么都不写，可能拉到一个默认版本，未必适合你的机器。先看ollama run --help或者直接在模型仓库页面确认标签，再决定拉哪个。

3.2 交互模式里的常用操作

进入交互模式后，直接输入问题就能对话。这个模式背后有一整个会话上下文，你当前说的话它会结合前面几轮一起理解。演示一下：

>>> 帮我列一个周末去超市的采购清单，两个人三天量 >>> 现在把清单里的水果单独挑出来

第二句它知道"清单"指的是上一轮生成的内容，这就是上下文的效果。交互模式里还有几个内置命令值得记：

• /bye：退出交互模式。
• /help：查看所有内置命令。
• /set parameter temperature 0.7：临时调整采样温度，数字越高输出越随机，越低越保守。
• /show info：查看当前模型元信息，比如参数量、上下文长度。

3.3 量力而行：先选量化版本

很多人第一次部署，恨不得直接拉最大版本的模型，结果跑不动。这里必须理解量化是什么。

量化可以类比成图片压缩：同样的图片，无损格式体积大、质量高；有损格式体积小、画质略有损失。模型的量化也是这个思路，把权重从高精度压缩到低精度，换取更小的内存占用。Ollama仓库里常见的量化标签有q2_k、q3_k_m、q4_k_m、q5_k_m、q8_0，数字越大精度越高、体积越大。举个例子，同一个7B模型：

我个人的建议：第一次部署先选q4_k_m，跑通流程、观察资源占用，觉得质量不够再换更高精度的版本。预算有限的时候，q4_k_m是性价比最高的起点。

4. 模型文件管理：目录结构、磁盘占用与自定义Modelfile

4.1 模型到底存在哪里

用Ollama时间长了，迟早要面对一个问题：模型文件在哪？怎么清理？

默认情况下，模型存放在：

• macOS：~/.ollama/models
• Windows：C:\Users\你的用户名\.ollama
• Linux：~/.ollama/models

进入目录后你会看到几个子目录，最核心的是blobs和manifests。blobs里是以哈希命名的真正权重文件，体积巨大；manifests里则是标签的索引信息，负责把模型名映射到具体文件。

这里有一个我踩过的坑：有一次C盘红了，我以为手动把blobs下某个大文件删掉就能省空间，结果ollama list里模型还在，但一运行就报文件缺失。原因是manifests里的索引还指着那个文件。后来我只能重新拉一遍。正确的删除方式永远是用ollama rm 模型名，它会同步清理索引和实体文件。

4.2 把模型目录挪到另一个盘

如果你的系统盘空间捉襟见肘，迁目录是必须操作。流程不复杂，但顺序有讲究：

1. 先停掉Ollama服务。
2. 把整个.ollama/models目录移动到你想要的新位置。
3. 设置环境变量OLLAMA_MODELS指向新目录。
4. 启动Ollama服务。
5. 跑ollama list验证，能正常列出就说明迁移成功。

我当时就是把OLLAMA_MODELS指向了一块容量充足的机械盘，虽然读取速度不如系统盘，但模型加载本来就以分钟计，这点差距完全可接受。

4.3 用Modelfile定制一个属于自己的模型

Ollama有个杀手级功能：Modelfile，相当于模型的Dockerfile。你可以基于某个基础模型，定制系统提示词、默认参数，生成一个全新的本地模型。这样每次对话都自动带上你预设的行为规范，不用在客户端里反复粘贴提示词。

一个实际例子。我需要一个专门做技术文档总结的助手，于是写了个Modelfile：

FROM qwen2.5:7b PARAMETER temperature 0.3 PARAMETER top_p 0.9 SYSTEM 你是我的技术写作助手。你的任务是阅读用户给出的技术文档内容，然后用简洁的中文分点总结。禁止输出客套话，直接给结论。

保存后执行：

ollama create doc-assistant -f ./Modelfile ollama run doc-assistant

从这个例子能看到Modelfile的语法：FROM指定基础模型，PARAMETER设置推理参数，SYSTEM定义系统提示词。除了这些，Modelfile还支持挂载上下文内容、设置停止词等，你可以慢慢探索。

4.4 让模型常驻内存，避免反复加载慢

每次从冷启动运行模型，都要先加载权重文件，轻则十几秒，重则数分钟。如果频繁在多个模型间切换，体验会非常割裂。

Ollama默认会把你操作过的模型在内存里留一段时间，这个时间由OLLAMA_KEEP_ALIVE控制。我建议日常使用设为10m或30m，既能覆盖大部分连续操作，又不会长期占着内存。内存非常紧张的时候可以设为0，模型用完立刻释放，代价是下次再跑要重新加载。

5. 当显存不够用：量化选型与性能调优的实测心得

5.1 先搞清楚"卡"在哪一环

本地跑模型时，性能瓶颈往往不是计算速度，而是内存带宽和容量。我手头有台只有16GB内存、没有独立显卡的台式机，跑7B量化模型能出活，但跑13B就明显吃力：加载时间翻倍，生成速度掉到每秒钟几个字。用一句话总结：参数量决定了模型需要多少内存，量化决定了同样参数下能压到多小，但压缩是有质量的代价的。

所以部署前先想清楚：你的机器内存是多大？模型加载后加上系统占用和上下文缓存，还能不能喘口气？给个参考值：16GB内存的机器，跑7B的q4_k_m比较舒适；32GB的机器可以尝试13B；真要跑70B，请准备64GB以上内存或一块大显存显卡。

5.2 实测下来影响速度的几件事

我实际跑下来发现，影响生成速度的主要是这么几件事：

第一，上下文长度。上下文越大，模型记忆的对话历史越多，但KV缓存占用的内存也成倍增长。上下文从2048拉到8192，内存占用能翻两倍不止。如果你的对话不需要很长的历史，别盲目调大，默认值够用就行。

第二，并行请求数。OLLAMA_NUM_PARALLEL控制同一时刻有多少请求可以用同一个已加载模型处理。这个值开得太高，会抢内存；开太低，遇到并发任务会排队。我建议先从默认值开始，观察任务队列，再决定往上加还是往下减。

第三，CPU线程数。Ollama在纯CPU推理时，能利用多核。OLLAMA_NUM_THREADS设成物理核心数通常最合适——设得比物理核心多，线程切换反而拖慢速度。这个参数我调过几次，超过物理核心数之后生成速度不升反降。

测速方法也很简单：进入交互模式让模型输出一段长文字，结束时Ollama会显示生成了多少token、耗时多少、每秒多少token。对比不同模型、不同上下文时，就能直观看到差距。

5.3 纯CPU推理有没有救

纯CPU推理的确慢，但也不是完全不能忍。如果实在没有显卡，几条思路能显著改善体验：

• 选小参数量模型。7B起步，不行就3B、1.5B。
• 选低量化版本。q4_k_m跑不动的，试q3_k_m或q2_k。
• 关掉其他吃内存的进程。浏览器大堆标签页、IDE全开着，内存和CPU带宽都会受影响。
• 控制上下文长度。长文档任务分段喂，不要一次性塞太多。

用一句话概括我的经验：CPU推理适合"事情能办成就行"的场景，不适合追求实时交互。做批量离线处理其实无所谓，挂机跑就行。

5.4 我现在用的稳定参数组合

分享一套我实测稳定的配置。以16GB内存、纯CPU环境为例：

export OLLAMA_MODELS="/data/ollama" export OLLAMA_KEEP_ALIVE="10m" export OLLAMA_NUM_PARALLEL="2" export OLLAMA_MAX_LOADED_MODELS="2" export OLLAMA_NUM_THREADS="8"

NUM_PARALLEL=2允许一个模型同时处理两个请求，多开一个任务不用重新排队；MAX_LOADED_MODELS=2适用于我会在技术助手和通用聊天之间切换的场景；线程数按物理核心填的。这套组合用了一个多月，没有出现过OOM也没被卡死过。

6. 把本地模型接进工作流：Ollama的API接口实战

6.1 原生API接口一览

Ollama启动后默认监听localhost:11434，它提供了一套标准的REST接口，最常用的四个：

先用一行命令验证服务可用：

curl http://localhost:11434/api/tags

返回里会带上模型列表，说明服务和模型都正常。一个最简单的对话请求长这样：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:7b", "messages": [ {"role": "user", "content": "用一句话解释什么是KV缓存"} ] }'

响应里会包含生成的文本、耗时的token统计等字段。这就是把本地模型接进自动化脚本的基础。

6.2 用OpenAI兼容接口无缝迁移

Ollama还提供了一个非常有用的兼容路径：/v1/chat/completions。这意味着你之前写的任何对接OpenAI风格接口的代码，只需要改两行——base_url改成http://localhost:11434/v1，api_key随便填个字符串，就能直接跑在本地模型上。

我写过一个Python小例子：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama", ) response = client.chat.completions.create( model="qwen2.5:7b", messages=[ {"role": "user", "content": "把下面这段文字改写得更口语化：本系统基于本地部署的Ollama平台，为用户提供离线智能问答服务。"} ], ) print(response.choices[0].message.content)

跑通这个，你的脚本就同时兼容了"本地免费"和"在线强大"两种后端，需要切换时只改配置不改代码。

6.3 局域网访问与安全边界

如果你的工作流不止一台机器，可以让Ollama监听局域网。把OLLAMA_HOST设为0.0.0.0:11434，重启服务，另一台机器上就能用http://服务器IP:11434访问。

但这里必须郑重提醒：Ollama默认没有任何鉴权机制，谁都能调用你的模型。暴露到公网等于把你的算力免费送给别人用，还有可能被塞入恶意内容。我的建议是，只在内网可信环境开放；非要跨网络访问，尽量通过网络设备做访问控制，或者在前边加一层认证服务，别把裸端口直接露出去。

7. 部署过程中的真实故障排查：四个高频问题的排查链路

7.1 模型下载中断，重跑却卡在同一个位置

刚部署那会儿，我拉一个比较大的模型，下到83%时网络断了。重新执行ollama pull，进度条停在83%附近不动，一度以为卡死了。但其实这是正常现象：Ollama拉取支持断点续传，它要校验已下载的分片、从断点继续，这个过程可能看起来很"慢"。多等等，或者再重试一次。这里切记：不要手动去删blobs目录里的临时文件，你删掉的是别人续传的依赖。真要给"卡住"下结论，先盯十分钟再说。

7.2 模型加载到一半，进程被系统直接杀掉

有一次我尝试跑一个大参数模型，加载过程走到一半，shell直接返回Killed。这基本是内存耗尽后系统OOM机制动手了。排查链路是这样的：先用free -m看剩余内存，如果swap区也在剧烈波动，基本实锤；Linux下可以用dmesg | grep -i oom看内核日志，能直接看到是哪个进程被杀了。

处理办法：要么换成更小参数量的模型，要么用更低的量化精度。加swap只能缓解，不能根治，模型体量远超物理内存时，换模型才是正路。记住这个教训——下载模型前先看模型体积，跟机器内存对比一下再动手。

7.3 报"model not found"，但ollama list明明有

我踩过一次很无语的坑：执行ollama run qwen2.5:7b-q4_k_m，系统报模型不存在；但ollama list里明明列出了qwen2.5:7b-q4_k_m。后来才发现，我把标签名记混了。Ollama对模型名的匹配是精确的，名称:标签必须完全一致。排查方式就一条：ollama list看准确全名，复制粘贴到run命令里，不要凭记忆手敲。

7.4 局域网连不上，但本机访问一切正常

本机curl localhost:11434/api/tags正常，另一台机器却超时，这个问题九成出在监听地址上。Ollama默认只绑定127.0.0.1，外面的机器当然连不进来。把OLLAMA_HOST改成0.0.0.0:11434，重启服务，再在另一台机器用curl http://服务器IP:11434/api/tags验证。Windows用户还要检查防火墙弹窗有没有放行端口，别漏掉这一环。

这套流程走完之后，我已经把摘要脚本、文档分类工具、简单的问答机器人全部切到了本地Ollama上。现在每天的数据处理基本离网运转，只有极少数高难度任务会走在线接口。最后再分享一个操作习惯：我每次要跑批量任务前，都会先ollama list看一眼模型在不在，再curl /api/tags确认服务活着，这两步花不了十秒钟，但能帮我避开大量"装好了却跑不起来"的尴尬时刻。