企业官网建设流程全解析

上个月帮一个内部工具项目接入大模型能力，折腾了一周，最后把方案定在 Ollama 本地部署上。整个过程踩了不少坑，从驱动不对、显存不够，到服务起不来、局域网访问失败，几乎把新手能遇到的问题都碰了一遍。趁着记忆还热乎，把完整过程整理成这篇分享，从硬件选型到系统配置、从模型管理到 API 调用，再到常见问题排查，全部按实操顺序来讲，希望对正在做 Ollama 本地安装部署的朋友有帮助。

1. 为什么是 Ollama？本地化部署的核心思路

1.1 云 API 的三个痛点

一开始我根本没打算本地部署，直接想调云服务商的大模型 API，但很快发现三个绕不开的问题。

第一是数据隐私。内部工具要处理的材料里有不少敏感内容，按 API 的路子要把数据传到别人的服务器上过一遍，合规层面根本过不去。很多企业和团队做本地部署的第一动机就是这个，不是技术情怀，是数据根本出不了内网。

第二是成本不稳定。API 按 Token 计费，平时测试几百条消息看不出什么，一旦接进生产环境，调用量上去之后账单非常难看。尤其是做批量处理的任务，成本几乎是线性增长的。而本地部署是一次性硬件投入加电费，长期跑下来成本可控得多。

第三是离线可用。我给朋友做的那个小工具，经常要在没有互联网的环境里用，云 API 在这种场景下直接不可用。本地模型只要能跑起来，随时随地都能用，不依赖外网。

1.2 同类本地方案的横向对比

本地跑大模型其实不是只有 Ollama 一个选择，我在选型时还对比过 llama.cpp、vLLM、LocalAI 这几个方案，简单说说取舍逻辑。

llama.cpp 是底层运行时，性能很猛，纯 CPU 推理尤其有优势，但它的定位是给人做二次开发的底层库，不是开箱即用的服务。你要自己编译、自己写 HTTP 服务、自己对接前端，适合有精力折腾的开发者，不适合想快速落地的人。

vLLM 吞吐量确实高，主打高并发场景，适合做正经生产服务，但硬件门槛不低，显存小一点的机器跑起来很吃力。如果你要服务几百上千人，vLLM 可以考虑；如果只是自己团队几十个人用，这配置有点杀鸡用牛刀。

LocalAI 和 Ollama 定位比较接近，都是把模型封装成 API 服务。但我实测下来 Ollama 的生态更完善，模型仓库覆盖更全，社区热度高，周边工具（Web 界面、IDE 插件、各种 SDK）都默认支持它的接口。综合看下来，Ollama 是这个定位里最省心的选择。

1.3 谁适合用 Ollama

按我个人的使用感受，Ollama 最适合三波人：一是个人开发者，想在自己电脑上跑个大模型做开发调试，不想买云服务也不想折腾编译；二是小团队做内部工具，需要把大模型能力嵌进现有系统，但不想引入复杂的推理框架；三是隐私敏感的项目，数据必须留在本地，Ollama 用起来最直接。

它不适合的场景也有，比如超大流量的线上服务，这时候应该上专门的推理框架和 GPU 集群；比如需要训练微调模型而不只是做推理，Ollama 里没有训练链路，那得换别的工具链。

2. 装之前先看硬件：资源需求与模型选型

2.1 CPU 与内存的最低门槛

很多人上来就问代码怎么装，其实 Ollama 安装本身很简单，真正决定你能不能跑起来的是机器配置。先把硬件门槛说清楚，免得装完发现跑不动白折腾。

纯 CPU 跑推理不是不行，但体验取决于模型大小。以 7B 参数模型为例，大概需要 8GB 内存起步，能跑但速度慢，大概每秒几 token；13B 模型建议 16GB 内存；33B 和 70B 的模型想用 CPU 跑，我个人劝退，除非你只是拿来测试输出格式，否则那个速度会等到怀疑人生。

内存还有个容易被忽略的点：Ollama 加载模型时默认会把模型整个读进内存，如果系统内存本身被其他程序占了很大一部分，模型加载会大概率失败，报错信息还很不明确。所以标称 16GB 内存的机器，实际能拿来跑模型的可能只有一半多一点。建议内存最好按模型要求的 1.5 倍以上来配。

2.2 显存怎么算：量化与参数量对照

如果你有 NVIDIA 显卡，算显存就是部署前的必修课。这里需要理解量化这个概念：模型权重本来用 16 位浮点数保存，一个参数占 2 字节；量化到 4 位后一个参数只占 0.5 字节，体积缩到四分之一，同时推理时的显存压力和内存带宽压力都变小。代价是精度略降，但 Q4 量级的效果在大多数场景下感知不明显。

简单说一个经验公式：模型参数量（B）乘以量化位数的字节数，再留出 1.5 到 2GB 的上下文和运行开销，基本就是所需的显存大小。

我整理了一个常用速查表，按常见显卡档位倒推能跑什么模型：

16GB 显存跑 70B 也不是完全不行，用 Q3 甚至 Q2 量化可以硬塞进去，但输出质量下降得厉害，推理速度也不太能忍。我实测的结论是：不要拿精度换容量，宁可模型小一档，效果也更好。

2.3 系统环境准备

硬件看完了，开始说系统。Linux 环境需要保证 glibc 版本不太老，Ubuntu 22.04 之后基本没问题。Windows 需要注意 GPU 驱动的 CUDA 版本，我的经验是驱动尽量装新版，旧版本踩过 CUDA 初始化失败的坑。macOS 如果是 Apple Silicon 芯片，Ollama 会走 Metal 加速，体验反而不错；Intel Mac 建议放弃，跑起来太慢。

硬盘空间也要提前想清楚。你以为模型不大，实际 7B 模型 Q4 量化后也有 4GB 多，70B 得有 40GB 以，上下。而且你会忍不住拉好几个模型来回切换，我现在的模型目录已经堆了 80 多 GB。建议准备 100GB 以上可用空间。

3. 三种安装方式与初始化配置

3.1 Linux 一键脚本到底做了什么

Linux 下安装 Ollama 最常用的就一条命令：

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

这条命令很多人复制粘贴就跑完了，但我不建议闭着眼执行，知道它在干什么才能排查问题。脚本实际做的事情是：检测当前系统的 CPU 架构（x86 还是 ARM），下载对应的 Ollama 二进制文件放到 /usr/local/bin，然后创建系统服务（systemd service）并启动。装完之后你执行 ollama --version 能看到版本号，就说明装上了。

有些环境不能联网安装，或者不想用脚本，可以手动下载二进制包解压，把 ollama 文件放进 /usr/local/bin，然后执行 ollama serve 手动启动服务。这个方法在离线内网环境很实用，我最开始给那台内网机器部署时就是用离线包方式搞定的。

3.2 Windows 和 macOS 安装

Windows 直接下载安装包，双击装完，右上角任务栏会多一个小图标，说明服务已经在后台跑起来了。默认安装路径和模型存储路径都在 C 盘，如果 C 盘紧张，可以在安装前用 OLLAMA_MODELS 环境变量预设模型目录。

macOS 下载解压之后把 Ollama.app 拖进应用程序目录就行。Apple Silicon 的 Mac 跑 7B 模型速度可用，13B 就开始偏慢。

3.3 Docker 方式安装

服务器上我更推荐 Docker，好处是隔离干净、升级方便、不污染宿主机环境。一条命令就能跑起来：

docker run -d -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama

这里的 -v 参数很关键，把容器内的模型目录挂载到名为 ollama 的卷上，否则容器删掉模型也跟着没了。端口映射 11434:11434 保证宿主机和容器服务能正常通信。

3.4 环境变量与服务配置

Ollama 装完默认只在本地回环地址监听，也就是只有本机能访问。如果你想让局域网内其他机器连上这台服务，需要设置监听地址：

export OLLAMA_HOST="0.0.0.0:11434"

还有几个比较常用的环境变量，我放一起列出来：

设置完环境变量后需要重启 Ollama 服务才能生效。Linux 下用 systemctl restart ollama 最方便，Windows 直接托盘退出再启动。

4. 模型下载、管理与运行时参数

4.1 认识模型仓库与量化标签

Ollama 自带模型仓库，不需要像传统方案那样自己去各个平台找权重文件。模型命名格式通常是“命名空间/模型名:标签”，比如 qwen2.5:7b 表示七参数版本 7B，llama3.1:8b 同理。

标签这里要重点说。默认标签（latest）一般指向官方推荐的量化版本，但不同模型的默认量化不一样。如果你对显存或精度有明确要求，建议在拉取时指定具体量化标签。我一般习惯用 Q4_K_M，平衡体积、速度和效果，兼顾场景比较多；存储空间管够的时候用 Q8_0，质量更稳一点；如果显存特别紧张再考虑 Q3。

4.2 常用模型管理命令

这里直接给你一份高频命令清单，照着抄就能用：

# 查看本机已下载的模型 ollama list # 拉取模型 ollama pull qwen2.5:7b # 直接下载并进入交互式对话 ollama run qwen2.5:7b # 查看模型详细信息 ollama show qwen2.5:7b # 删除模型 ollama rm qwen2.5:7b # 查看当前驻留内存的模型 ollama ps

我第一次没分清 run 和 pull 的区别，以为 run 只是运行，实际 run 会自动先拉取再进入聊天模式。如果只是服务端调用就不需要交互式对话，用 pull 拉下来就好。

有个小技巧：模型下载到一半中断了，再次执行 pull 会从断点续传，不用从头再下。实测下来这个体验比很多下载工具还稳，但前提是模型目录空间充足。

4.3 通过 Modelfile 定制模型

Ollama 有一个叫 Modelfile 的配置文件，可以从基础模型派生出定制模型，就像 Dockerfile 从基础镜像派生新镜像。典型场景是固定 system prompt、设置默认参数、加入文档知识等。

比如我要做一个始终用中文简短回答的客服助手：

FROM qwen2.5:7b PARAMETER temperature 0.2 PARAMETER top_p 0.7 SYSTEM 你是某产品客服助手，请始终使用简体中文回答，回复尽量简洁专业。

保存成 Modelfile，然后执行：

ollama create my-assistant -f Modelfile

之后就能直接 ollama run my-assistant，每次都会自动带上这些默认设置。这个能力实际使用中很实用，等于省掉应用侧每次拼 prompt 的重复操作。

5. 把模型接到你的应用里：API 与生态集成

5.1 原生 API 与 OpenAI 兼容接口

Ollama 服务装好后默认监听 11434 端口，它提供了一套原生 HTTP API，最常用的两个端点是 /api/generate 和 /api/chat。

无需编程语言限制，curl 就可以直接测试：

curl http://localhost:11434/api/chat -d '{ "model": "qwen2.5:7b", "messages": [{ "role": "user", "content": "用一句话介绍你自己" }] }'

返回的 JSON 里最主要是 message.content 字段，就是模型生成的文本。默认是流式输出，每次返回一小段。如果不想要流式，可以在参数里加 "stream": false。

更实用的是 Ollama 提供了 OpenAI 兼容的接口，地址是 http://localhost:11434/v1，这意味着你之前写好的 OpenAI SDK 代码几乎不用改，只换 base_url 就能对接本地模型。我现有项目里的不少代码就是这么接过来的，替换成本非常低。

5.2 Python 调用示例

用 Python 编写调用代码，可以直接用 requests 或者 openai 库。用 openai 库的方式我贴一下：

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": "system", "content": "你是文本摘要助手，输出简洁的中文摘要。"}, {"role": "user", "content": "帮我总结下面这段内容：……"} ], stream=False ) print(response.choices[0].message.content)

注意 api_key 随便填一个非空值就行，本地服务不校验这一点。如果要用流式输出，把 stream 设为 True，遍历 response 拿到增量文本，适合做打字机回显效果。

5.3 Web 界面与开发工具集成

纯 API 只能命令行和代码调用，很多非技术背景的人用起来不直观。我给那台部署机器配了 Open WebUI，一条 Docker 命令就能起一个类似 ChatGPT 的界面：

docker run -d -p 3000:8080 \ --add-host=host.docker.internal:host-gateway \ -v open-webui:/app/backend/data \ --name open-webui --restart always \ ghcr.io/open-webui/open-webui:main

这样团队里的人通过浏览器打开 http://服务器IP:3000 就能直接跟模型对话，多用户支持、历史会话管理都有。实测下来很稳，唯一的注意点是第一次启动会初始化数据库，耐心等一两分钟再刷新页面。

开发工具方面，VS Code 里的 Continue 插件我比较推荐，它能直接配 Ollama 做代码补全和问答，改一下配置指向本地 11434 端口就能用，适合有代码库内部保密需求的开发场景。

6. 常见问题排查与调优心得

6.1 问题速查表与解决思路

把这段时间遇到的典型问题汇总一下，按“现象 → 原因 → 解决”的格式整理成速查表：

第一条尤其要重视。我遇到过服务明明显示在运行，但外部访问一直失败，后来发现是 Docker 部署时忘了把端口映射出去，容器内部服务是好的，宿主机根本没暴露端口。建议部署后先 curl 本机测试，再逐层检查外部访问，不要一上来就怀疑服务挂了。

6.2 几个提升稳定性的经验

调试阶段建议开 verbose 或者直接用 ollama serve 前台模式跑，日志都打在终端里，出问题能第一时间看到真实报错。用 systemd 服务方式跑的要把日志拉出来，journalctl -u ollama -f 在排查时帮了我大忙。

关于模型切换，默认 Ollama 只会保留一个模型驻留内存，切换模型时旧模型会被卸出，下次再用又得重新加载。如果你的应用要频繁切换多套模型，建议用 OLLAMA_MAX_LOADED_MODELS 调大驻留数量，同时配合 OLLAMA_KEEP_ALIVE 把空闲保留时间设长一点。显存不够的话不要这么做，会导致加载失败。

还有一个容易踩的坑：用 Docker 方式部署时，环境变量要写在 docker run 的参数里，写在宿主机上不生效。我第一次就犯了这个错，宿主机配了 OLLAMA_HOST 但容器里没传进去，改完重启容器才生效。

最后我必须强调一下：个人使用场景优先跑 7B 量级的量化模型，先把整个链路跑通，再慢慢尝试更大模型。不要一开始就想着上 70B 模型，那会让前面的部署过程变成灾难。我自己最顺手的配置是 13B Q4 模型配 16GB 显存，速度和效果都满意，已经稳定跑了两周没重启过。根据我的实际体会，Ollama 的本地化部署难点从来不在安装本身，而在后续的调优和排障，这些经验才是真正让项目稳定跑起来的关键。