企业官网建设流程全解析

我先说明一下这篇要写什么：Ollama 是目前在 Linux 上本地跑大语言模型最顺手的工具，没有之一。它的安装、模型拉取、API 调用、服务管理，全部集中在一个命令行工具里，对刚接触本地大模型的人来说，几乎是门槛最低的一条路。但实际部署过程中，坑也不少：下载慢、显存不够、镜像失效、模型文件位置不对、GPU 根本不工作，等等。这篇文章我会把自己在 Linux 环境从零部署 Ollama 到日常使用的完整思路和踩坑记录写出来，尽量让你照着做就能跑起来，同时明白每一步为什么这么做。

1. 环境准备：先搞清楚你的机器能跑到什么程度

1.1 硬件评估：显存决定模型选型上限

在装任何东西之前，先对自己的机器做一个冷静的评估。Ollama 本身只是一个“壳”，真正吃资源的是你拉下来的大语言模型。跑模型时真正起决定作用的是三块硬件：显卡的显存大小、内存容量、硬盘剩余空间。

显存是第一个要看的硬指标。以目前主流的开源模型为例，7B 到 8B 参数量的模型，用 Q4_K_M 这种常见量化精度跑起来，大概需要 6GB 到 8GB 显存；13B 到 14B 参数量的模型需要 10GB 到 12GB 显存；32B 到 34B 的模型基本要 20GB 以上显存；70B 这个级别没有 40GB 以上的显存基本不用想。这里说的都是“至少能跑起来”的底线，真要开长上下文、并发请求，显存需求还要往上走。

注意：如果你手头只有一块 8GB 显存的消费级显卡，不用纠结，老老实实选 7B 级别的模型就对了。非要硬拉 14B 模型，也不是完全不能跑，但会把部分层卸载到 CPU 和内存上，速度会变得非常感人，每秒蹦几个 token 会严重打击使用体验。

内存也要重视。即便模型推理主要在显存里完成，Ollama 服务进程本身、模型加载时的临时缓冲、上下文窗口（context window）都会占用内存。我实际测试下来，跑 7B 模型建议系统内存不低于 16GB，其中留给 Ollama 相关进程的余量最好在 4GB 以上。如果上下文窗口开得很大（比如 32K），内存占用还会明显上涨。

硬盘是很多人忽略的一条。Ollama 的模型文件默认存放在~/.ollama/models目录下，模型文件动辄几个 GB 到几十个 GB，磁盘空间不够会直接导致拉取失败。你可以在安装前用df -h看一下根目录或家目录所在分区的剩余空间，心里有个数。如果家目录所在分区空间紧张，后面我会专门讲怎么改模型存储位置。

1.2 Linux 发行版选择：其实没有想象中挑剔

Ollama 官方对 Linux 的支持覆盖面相当广，常见的 x86_64 架构发行版基本都能跑。我自己在 Ubuntu 22.04、Debian 12、CentOS 7 这几类系统上都成功部署过，安装方式大同小异。

如果你是生产环境使用，我更推荐 Ubuntu 22.04 LTS 或 Debian 12 这类长期支持版本，原因有两条：一是内核版本比较新，对新显卡驱动的兼容性更好；二是 NVIDIA 驱动和容器运行时在这些系统上最容易装，社区资料也最多。CentOS 7 属于特殊情况，因为系统 glibc 版本偏低，Ollama 新版本可能存在兼容问题，要跑的话得像那篇文章里说的那样，考虑源码编译或者升级系统。

ARM 架构的机器，比如 Jetson Orin 这类边缘设备，Ollama 也支持，但要注意两点：CUDA 版本要求更严格，且官方预编译二进制不保证覆盖所有 ARM 平台。Jetson 用户建议直接查官方 GitHub Releases 里是否有对应版本的linux-arm64安装包，有就用，没有就转源码编译路线。

1.3 GPU 驱动：先装好再谈性能

如果你有 NVIDIA 显卡，在装 Ollama 之前务必先把 NVIDIA 驱动和 CUDA 环境搞定。Ollama 是通过 CUDA 来调用 GPU 的，驱动没装好，Ollama 就会静默退化到 CPU 模式，表现就是模型能跑但速度奇慢无比，很多人误以为模型不行，其实问题出在驱动上。

快速验证驱动是否就绪的办法是执行nvidia-smi，如果你能看到类似下面这样的输出，说明驱动正常：

+-----------------------------------------------------------------------------+ | NVIDIA-SMI 525.105.17 Driver Version: 525.105.17 CUDA Version: 12.0 | |-------------------------------+----------------------+----------------------+ | GPU Name Persistence-M| Bus-Id Disp.A | Volatile Uncorr. ECC | | Fan Temp Perf Pwr:Usage/Cap| Memory-Usage | GPU-Util Compute M. | |===============================+======================+======================| | 0 NVIDIA GeForce RTX 3060 Off | 00000000:01:00.0 On | N/A | +-------------------------------+----------------------+----------------------+

如果连nvidia-smi都提示找不到命令，那就要先把 NVIDIA 驱动装好。这里我不展开驱动安装的具体步骤，因为每个发行版差异很大，但可以给一条通用建议：Ubuntu/Debian 系直接装nvidia-driver-535（或更新的版本号）这个包，然后重启，基本能解决绝大多数问题。

2. 安装 Ollama：三种方式，按需选择

2.1 官方一键脚本：最快但可能遇到网络问题

官方提供了一条安装命令，绝大多数教程里都会写：

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

这条命令做的事情是：检测系统架构、确定 libc 版本、下载对应的二进制包、配置 systemd 服务、创建ollama用户、启动服务。安装过程是全自动的，装完就能用。

但国内用户执行这条命令时，最常遇到的问题有两个：一是ollama.com这个域名访问不通或者速度极慢，导致安装脚本下载二进制包失败；二是curl下载过程中被中断，留下一个损坏的脚本。无论是哪种情况，你会看到的都是报错信息，英文的，诸如curl: (28) Operation timed out或者Error: Unable to download ollama之类。

提示：如果你多次执行安装脚本都超时，大概率不是你的操作有问题，而是网络环境下访问官方源不稳定。这时候别反复试，直接换下面的方法。

2.2 手动下载安装包：绕开安装脚本的网络瓶颈

这里分享一个更稳的方式：访问 Ollama 的 GitHub Releases 页面，手动下载对应 Linux 架构的二进制压缩包。下载后把文件放到一个合适的目录，解压，然后自己配置 systemd 服务。

具体步骤大致是这样：

# 下载 linux-amd64 版本的压缩包，注意替换版本号 wget https://github.com/ollama/ollama/releases/download/v0.1.44/ollama-linux-amd64.tgz # 解压到 /usr/lib/ollama 目录（目录可以自定义） sudo mkdir -p /usr/lib/ollama sudo tar -C /usr/lib/ollama -xzf ollama-linux-amd64.tgz # 为 ollama 可执行文件建立符号链接，方便直接调用 sudo ln -s /usr/lib/ollama/bin/ollama /usr/local/bin/ollama # 创建独立用户 sudo useradd -r -s /bin/false -m -d /usr/lib/ollama ollama # 启动服务（临时验证） ollama serve &

这样临时跑起来后，再用ollama run测试能否拉起模型。确认没问题后，再配置 systemd 服务实现开机自启。GitHub 如果也不好访问，可以试试国内的一些镜像加速渠道，把上面命令里的 URL 前缀换成你能访问的镜像地址，原理是一样的。

2.3 Docker 部署：更干净，也更适合一机多服务

如果你的 Linux 机器上已经装好了 Docker 和 NVIDIA Container Toolkit，用容器方式部署 Ollama 是另一个很有优势的选择。最大的好处是隔离干净，不会污染系统环境，也方便后续迁移。

拉镜像并启动容器：

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

这条命令里几个参数的作用分别是：

• --gpus=all：让容器内可以使用宿主机全部 GPU，不加这条，容器内只能 CPU 跑。
• -v ollama:/root/.ollama：把模型数据放到 Docker 卷里，容器删了模型还在。
• -p 11434:11434：把容器内的 11434 端口映射到宿主机，方便外部调用 API。

容器方式部署后，需要进入容器执行模型操作：

docker exec -it ollama ollama run qwen2.5:7b

Docker 方案也有一个需要留意的点：ollama命令在宿主机上默认不存在，每次操作要么通过docker exec进入容器，要么在宿主机上也装一个客户端来连接容器的服务。我自己的习惯是宿主机装客户端，容器只跑服务，这样命令行操作体验最接近原生部署。

3. 模型下载与加速：绕开下载慢的“拦路虎”

3.1 为什么下载这么慢

新手第一次运行ollama run qwen2.5:7b时，如果模型还没在本地，Ollama 会先去 model library 拉取。国内网络环境下，直接拉取官方源经常只有几 KB/s 到几十 KB/s 的速度，一个 4GB 左右的模型能下到怀疑人生。

这个问题本质上是模型文件的托管源访问不畅导致的。明白这一点后，解决思路就很清晰了：把模型文件的下载源头替换掉，或者直接手动导入已经下载好的模型文件。

3.2 通过环境变量配置国内加速源

Ollama 官方预留了配置镜像地址的环境变量。你可以在启动 Ollama 服务之前，通过OLLAMA_BASE_URL指向一个你这边能快速访问的模型托管服务地址。不同版本的 Ollama 支持的镜像变量名略有差别，我实测时用的变量是OLLAMA_BASE_URL，也有旧版本用的是OLLAMA_HOST或OLLAMA_ORIGINS这类只影响服务监听地址的参数，两者不要混淆。

配置方法：修改/etc/systemd/system/ollama.service文件（或者ollama用户下的环境变量文件），在[Service]段中添加Environment配置项：

[Service] Environment="OLLAMA_BASE_URL=https://你的加速地址"

保存后重载配置并重启服务：

sudo systemctl daemon-reload sudo systemctl restart ollama

提示：如果你不知道有哪些可用的加速地址，可以去开源社区找找公开的 Ollama 镜像加速站。这类服务经常变动，最好选那些有维护记录、长期更新的地址。这里不推荐具体哪一个，因为时效性太强，今天能用明天可能就失效了。

3.3 离线部署：最稳妥的大模型导入方案

如果你所在环境的网络连镜像站都不稳定，那最省事的方案就是“曲线救国”：在另一台网络环境正常的电脑上先下载好模型文件（或者去模型分享站点直接下载 GGUF 格式的模型文件），再拷贝到目标 Linux 机器上。

Ollama 提供了一个非常方便的模型导入机制，支持 GGUF 格式文件。步骤大概是：

第一步，准备一个Modelfile，内容至少要指定模型路径：

FROM /path/to/your/model.gguf

第二步，执行导入命令：

ollama create mymodel -f Modelfile

第三步，验证模型是否可用：

ollama run mymodel

这个方法特别适合内网环境、国产化服务器、Jetson 边缘设备这些没法连外网的场景。我曾在两套完全隔离的内网服务器上靠这种方式部署过多个模型，稳定性和体验都比在线拉取好得多。

还有一个小技巧：如果你平时用另一台电脑的 Ollama 下载过模型，可以直接把~/.ollama/models目录下对应模型的整个目录拷贝到目标机器的同一位置，再执行ollama list检查能否识别。注意 Ollama 内部还有一层对模型文件的散列目录结构，直接拷贝时要保证路径完整，否则可能识别失败。

3.4 编译安装：极端环境下的最后手段

当官方安装包和加速镜像都不可用，而且目标机器的 CPU 架构、glibc 版本跟官方编译产物不匹配时，只能走源码编译这条路。这属于比较极端的场景，整体成本和维护负担都不小。

官方仓库提供了在 Linux 上编译的指导。基本流程是：

# 克隆仓库 git clone https://github.com/ollama/ollama.git cd ollama # 生成本地代码（需要 Go 环境和 cmake） go generate ./... go build .

编译本身没有什么玄学，跟着 README 走就行。真正的坑在于生成 ROCm/CUDA 相关代码时，依赖的编译工具链版本必须匹配，不然编出来还是 CPU 版本。如果你不是特别着急用新版本特性，我个人建议：能装预编译版就装预编译版，编译这个路线留给特定架构和特定需求的环境。

4. 核心使用命令与日常操作

4.1 模型生命周期管理

Ollama 的命令行体系可以说是“所见即所得”，其中最常用的命令我用一个表格整理出来：

模型 tag 的概念要特别说一下。“qwen2.5:7b”里的7b是 tag，它代表的是该模型的某个版本或量化档位。Ollama 模型库里的同一个模型往往有多个 tag，比如qwen2.5:7b-instruct-q4_K_M就明确指出了指令微调和量化类型。日常使用建议直接ollama run加不加 tag 都可以，Ollama 会使用默认 tag；但如果你很在意内存占用和效果平衡，手动指定量化 tag 会更精准。

4.2 交互对话与上下文管理

输入ollama run modelname后，你就进入了类似 OpenAI Playground 的交互界面。直接输入中文或英文提问即可得到回答。要注意的是，模型本身是否支持中文，取决于你选择的模型基座，比如 Qwen 系列、Yi 系列对中文支持都很友好；而 Llama 3.1 这类以英文为主的模型，虽然也能输出中文，但效果自然不如原生中文模型。

交互过程中有几个实用操作：

• /bye：退出交互界面，服务仍然在后台运行。
• /clear：清空当前的上下文，让模型“失忆”。
• /?：查看当前会话支持的快捷指令。

如果你觉得每次启动交互都要占一个终端，想直接在脚本里用，可以用一次性问答模式：

ollama run qwen2.5:7b "用一句话介绍你自己"

这个模式非常适合写自动化脚本，比如定时拉取新闻然后让模型总结。

4.3 上下文窗口、温度等参数的调整

想让模型输出更符合你的预期，光靠默认参数是不够的。在交互界面中输入/set parameter num_ctx 8192可以把上下文窗口扩大到 8192；输入/set parameter temperature 0.7可以调整回答的随机性。温度越低回答越保守、越稳定，温度越高回答越发散、越有“创意”。

这类参数也可以在Modelfile里预先固化，或者通过 API 请求里的options字段覆盖。我自己的经验是：写代码和做逻辑推理用低温度（0.1 到 0.3），做文案构思用 0.7 到 0.9，具体数值要根据模型微调几次才找得到感觉。

4.4 修改内置服务配置

默认情况下，Ollama 服务监听在127.0.0.1:11434，也就是只允许本机访问。如果你想通过局域网内其他电脑访问这台机器的模型服务，需要修改监听地址。

修改方式依然是在 systemd 服务文件 / 环境变量中追加：

Environment="OLLAMA_HOST=0.0.0.0:11434"

改完重启服务。这样同一局域网内的其他设备就可以通过http://这台机器的IP:11434来调用 API 了。

注意：把服务暴露到局域网等于所有人都能调用你的模型服务，如果没有鉴权机制，轻则被陌生人疯狂拉满显存，重则模型服务崩溃。建议只在可控的信任网络中开放，或者前面套一层 API 网关做访问控制。

5. 常见问题与排查技巧实录

5.1 模型下载速度慢到怀疑人生

解决思路分为在线和离线两条，前面已经详细展开过。这里只补充一句：很多人在设置完镜像环境变量后，发现不起作用，原因是修改完 systemd 环境变量后没有执行sudo systemctl daemon-reload && sudo systemctl restart ollama。环境变量的改动必须重启服务才能生效，这是一个非常不起眼但极其常见的失误。

5.2 GPU 不工作，Ollama 总是用 CPU

症状很明显：提问一个简单问题，可能要思考几十秒，ollama ps里显示PROCESSOR列是100% CPU。

排查步骤要按顺序来：

1. 确认nvidia-smi能正常输出。
2. 如果是 Docker 部署，检查启动命令里是否加了--gpus=all。
3. 原生安装的话，执行ollama serve手动启动一次，在日志里看有没有加载 CUDA 相关的信息。
4. 检查驱动版本和 CUDA 版本是否过老，Ollama 新版本通常要求 CUDA 11.3 以上。

有一种情况特别无语：驱动和 CUDA 都正常，但 Ollama 服务是在驱动安装之前启动的。这种时候系统里可能有多个 Ollama 进程在跑，互相抢占资源。先sudo pkill ollama，再重新拉起服务，往往就好了。

5.3 显存不够怎么硬跑

如果你只有 8GB 显存却想跑 14B 模型，Ollama 的机制是默认把部分层放 GPU、剩下的放 CPU，这叫“部分卸载”。这种模式下模型的加载时间会拉长，推理时也会出现 GPU 和 CPU 之间频繁交换数据的情况，速度会明显下降。

想要手动控制卸载策略，可以这样设置：

OLLAMA_GPU_LAYERS=20

这个值表示把模型的前 20 层放到 GPU，剩下的由 CPU 处理。具体设多少层合适，没有标准答案，建议从 10 层起步，逐步增加，观察显存占用和生成速度，找到一个平衡点。如果设得太高，显存溢出，Ollama 反而会直接报错。

5.4 磁盘告急：模型存储位置怎么迁移

模型默认存在~/.ollama/models，家目录空间不够用时，可以把整个目录迁移到大容量磁盘上。推荐做法是修改环境变量OLLAMA_MODELS指向新路径，然后把旧目录的数据同步过去。

# 停止服务 sudo systemctl stop ollama # 迁移目录 sudo mv ~/.ollama/models /data/ollama_models # 修改服务文件，增加环境变量 # Environment="OLLAMA_MODELS=/data/ollama_models" # 重载并启动 sudo systemctl daemon-reload sudo systemctl start ollama

这里有个小坑：如果你把目录整体mv走了，旧路径没了，系统又会自动创建一个空目录。下次再 pull 模型时，可能又拉到旧路径去了，白白占一份磁盘空间。所以迁移后务必检查环境变量是否真的生效，用ollama list确认模型列表还完整。

5.5 多模型同时跑还是按需加载

Ollama 的机制是：一次只能加载“一组”模型进显存，如果你用完模型 A 没停掉，接着去 run 模型 B，Ollama 会先把模型 A 从显存里清除，再加载 B。这个“挤牙膏”机制在某些场景下很麻烦，比如 Web 端多人使用不同模型时，每个人的第一次请求都会慢很多。

应对措施是提高 Ollama 的服务层并发能力，修改环境变量OLLAMA_NUM_PARALLEL控制并发请求数，以及OLLAMA_MAX_LOADED_MODELS控制最多同时保持加载几个模型。后一个值如果设置为 2 或更大，就能让多个模型同时驻留显存，切换时的加载延迟会小很多。代价自然是显存占用更高，具体怎么取舍要结合你的硬件来看。

6. 进阶使用：从命令行走向真实应用

6.1 HTTP API 调用：与你的应用对接

Ollama 自带一套与 OpenAI 兼容的 HTTP API，通过11434端口对外提供服务。这意味着你可以用任何支持 HTTP 请求的编程语言调用本地模型，实现“私有化模型服务”。

一个最简单的 Python 调用示例：

import requests import json url = "http://localhost:11434/api/generate" payload = { "model": "qwen2.5:7b", "prompt": "用一句话解释什么是大语言模型", "stream": False } response = requests.post(url, json=payload) result = response.json() print(result["response"])

返回结果里还有total_duration、eval_count这些性能指标，可以用于统计每次请求的耗时和 token 生成速度。/api/chat接口则是更接近 ChatGPT 的交互方式，支持多轮对话历史传入。

6.2 配合 Open WebUI 搭建私人聊天界面

命令行交互适合开发者，但对普通人来说，一个图形化聊天界面才是“能用”的标准。目前最主流的方案是 Open WebUI，它是一个独立服务，把 Ollama 作为后端，提供类似 ChatGPT 的 Web 界面，还内置了多用户管理、知识库（RAG）支持。

Docker 方式启动一个 Open WebUI 容器：

docker run -d -p 3000:8080 \ -v open-webui:/app/backend/data \ -e OLLAMA_BASE_URL=http://宿主机IP:11434 \ --name open-webui \ ghcr.io/open-webui/open-webui:main

启动后访问http://服务器IP:3000，注册一个管理员账号，然后在设置里把 Ollama 服务地址填成http://宿主机IP:11434，就能在界面上看到你本地已有的所有模型，直接选一个开始对话。

6.3 集成 LangChain 等框架

如果你的目标是构建一个带业务逻辑的 Agent 应用，Ollama 也可以作为 LangChain 的 LLM 后端。

from langchain_community.llms import Ollama llm = Ollama( model="qwen2.5:7b", base_url="http://localhost:11434", temperature=0, num_ctx=8192 ) response = llm.invoke("请用三句话介绍你自己") print(response)

这种集成方式最大的好处是：不需要申请任何云端 API key，数据不出本地，完全私有化。对数据敏感的内部工具、内部知识库问答这些场景，Ollama + LangChain 是成本最低的搭建路径。

6.4 从“能跑”到“跑好”：一些值得养成的习惯

用过一段时间后你会发现，本地跑模型和用云端 API 的心态完全不同。云端 API 想的是“调一个接口”，本地模型得把自己当作“运维人员”。有几个习惯能显著提升使用体验：

• 固定模型版本，不要随手ollama run让系统随意拉最新版。在测试环境和生产环境都固定好 tag，避免模型更新后行为不一致。
• 定期用ollama list检查磁盘占用，把不用的模型及时删掉。
• 备份Modelfile。自己调过的参数和自定义 prompt 模板，都值得写进 Modelfile 并提交到代码仓库，这样换机器时能一键复现。
• 理解ollama ps的输出。它显示的是当前已加载模型、加载时长、上下文长度、处理器分布，排查性能问题时第一步就是看它。

7. 模型选型建议：不同需求对应的推荐模型

7.1 按显存大小分类

很多人第一次部署成功后会陷入选择困难：到底哪个模型最适合我？我的建议很简单，先看显存，再定档位：

这个表格只是一个起点，不是硬性规则。不同模型对显存的实际占用差异很大，建议选定模型后直接ollama pull，然后用ollama run实测显存占用和生成速度，再决定固化在哪个量化档位。

7.2 按使用场景分类

代码生成场景，我实测下来 Qwen2.5-Coder 系列和 DeepSeek-Coder-V2-Lite 都表现不错，尤其是 Qwen2.5-Coder-7B 在补全、解释代码、生成单元测试这些任务上完成度很高。

中文通用对话场景，Qwen2.5-Instruct、GLM-4-Chinese、Yi-1.5-Chat 都是首批可以尝试的候选。它们对中文语义的理解深度和多轮对话能力在开源模型里是第一梯队。

英文推理场景，Llama 3.1-8B 和 Mistral-Nemo-12B 综合表现很均衡，前者在指令跟随上有惊喜，后者对长上下文处理更稳健。

视觉多模态场景，Ollama 的模型库已经支持llama3.2-vision、minicpm-v这类视觉语言模型，可以直接传图片给它问题。实测下来识别日常图片里的物体、文字、简单图表没问题，但复杂场景的推理能力跟 GPT-4V 这种云端闭源模型差距还很明显。

7.3 用 hard requirement 反向压测

选型还有一个反向思路：先把要处理的真实任务样本准备好，分别在候选模型的多个量化版本上跑一遍，用三个维度打分：“回答相关性”“格式符合度”“响应速度”。很多负责任的做法是建立一个内部的模型评估集，每次模型库有更新就重新测一遍。这个工作量听起来大，实际上准备好脚本后，每次只需要执行几分钟。

我自己用的评估脚本大致是这样：准备 10 个固定问题，循环调用模型 API，把结果保存到文本，再人工打分。打分表里会记录这次测试的模型 tag、量化等级、上下文长度、耗时。这样做几次之后，你对自己机器的“真实能力”会有远比任何测评文章都清楚的认识。

8. 最后分享一点实际体会

接触 Ollama 这段时间，我最深的感受是：本地大模型的门槛已经被这个工具压得非常低了，真正决定体验好坏的反而是工程细节。从镜像加速到显存管理，从模型选型到 API 集成，每一环都不复杂，但任何一环没做好都会让整体体验打折扣。

我最初就是因为下载慢差点放弃这个方向，后来通过离线导入模型解决了问题，从此养成一个习惯：能用离线包解决的就不在线硬等。现在每次给新机器部署 Ollama，我会把常用的模型文件提前拷贝到 U 盘里，到了现场直接导入，整个部署过程可以压缩到十分钟以内。

如果你刚拿到一台新 Linux 机器准备跑大模型，我的建议是先别急着追求最新最大的模型，用小参数模型把整条链路跑通，确认 GPU 驱动、服务状态、API 调用都正常之后，再慢慢升级模型。这个顺序能帮你省掉无数浪费在排错上的时间。