企业官网建设流程全解析

1. 为什么本地跑大模型这件事，Ollama 值得你花一个下午

很多人第一次接触本地大模型，脑子里冒出来的第一个念头是"我是不是得先搞一张 4090"。这个想法劝退了至少一半的人。实际情况是，如果你只是想在自己电脑上跑一个能对话、能写代码、能做简单推理的模型，一张普通的消费级显卡，甚至只有核显的笔记本，都能跑起来。关键不在于硬件有多猛，而在于你有没有选对工具链。

Ollama 就是那个把门槛砍到脚踝的工具。它的定位很像 Docker 之于容器——你不需要懂底层推理引擎怎么调度显存、怎么管理 KV Cache、怎么做量化，只需要一条命令就能把模型拉下来跑起来。它的核心价值在于三点：模型管理傻瓜化、推理服务开箱即用、API 接口标准化。你下载完安装包，打开终端敲一行ollama run qwen3.5:2b，等几分钟模型下载完，就能直接对话了。整个过程不需要配 Python 环境，不需要装 CUDA 工具链，不需要手动编译任何东西。

这篇文章适合几类人看：一是完全没接触过本地大模型部署、想先跑通一个再说的人；二是已经用过在线 API、但想搞清楚本地部署到底怎么回事的人；三是想拿 Ollama 当后端、给自己的 AI Agent 或者知识库项目做推理服务的人。我会从安装、模型选择、日常使用、API 调用、性能调优、常见报错排查这几个角度，把整个链路讲透。中间会穿插一些我自己踩过的坑，比如下载慢怎么办、模型跑起来报 500 错误怎么定位、显存不够怎么降级，这些都是文档里不会细说但实际一定会遇到的问题。

先把结论放前面：Ollama 不是性能最强的方案，vLLM 在吞吐量上确实比它猛得多，但 Ollama 是上手成本最低、维护最省心的方案。对于个人开发者、小团队做原型验证、本地知识库问答这类场景，它完全够用。等你真的需要高并发、多卡推理了，再迁移到 vLLM 也不迟。

2. 安装这一步，Windows 和 Linux 的坑完全不一样

2.1 Windows 下的安装路径与常见卡点

Windows 用户直接去官网下载.exe安装包，双击下一步就行。安装完成后，Ollama 会默认在后台启动一个服务，监听127.0.0.1:11434。你打开 PowerShell 或者 Windows Terminal，输入ollama --version，如果能打印出版本号，说明装好了。

但这里有几个 Windows 特有的坑，我逐个说。

第一个是安装包下载慢。官网的下载服务器在境外，国内直连经常几十 KB/s，一个几百 MB 的安装包能下半小时。解决办法是找国内镜像源，或者用离线安装包。很多技术社区会同步更新 Ollama 的离线安装包，搜"ollama 离线安装包"就能找到。下载完之后直接双击安装，效果和官网版本完全一样。

第二个是模型下载慢。这个比安装包更让人抓狂，因为模型动辄几个 GB。Ollama 默认从官方 registry 拉取模型，国内访问速度很不稳定。你可以通过设置环境变量OLLAMA_HOST来指定镜像源，具体做法是在系统环境变量里新增一条，或者在 PowerShell 里临时设置：

$env:OLLAMA_HOST="你的镜像源地址"

设置完之后重启 Ollama 服务，再执行ollama pull就会走镜像源。实测下来，配好镜像之后下载速度能从几百 KB/s 提升到几 MB/s，一个 4GB 的模型几分钟就能拉完。

第三个是端口占用。Ollama 默认用 11434 端口，如果你之前装过其他本地推理服务占了这个端口，Ollama 会启动失败。排查方法是：

netstat -ano | findstr 11434

如果发现有进程占用，记下 PID，用tasklist | findstr PID看是哪个程序，然后决定是杀掉它还是改 Ollama 的端口。改端口也是通过环境变量OLLAMA_HOST=127.0.0.1:11435来实现。

2.2 Linux 下的一键脚本与手动安装

Linux 用户最省事的方式是官方的一键安装脚本：

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

这条命令会自动检测你的系统架构，下载对应的二进制文件，配置好 systemd 服务，然后启动。装完之后systemctl status ollama能看到服务在跑。

但如果你是在公司内网或者网络受限的环境里，一键脚本大概率会卡在下载那一步。这时候就手动装：去 GitHub Releases 页面下载对应架构的压缩包，解压到/usr/local/bin/，然后手动写一个 systemd unit 文件。手动安装的好处是你能完全控制安装路径和运行参数，比如指定模型存储目录、限制显存占用等。

手动安装的 systemd 配置大概长这样：

[Unit] Description=Ollama Service After=network-online.target [Service] ExecStart=/usr/local/bin/ollama serve User=ollama Group=ollama Restart=always RestartSec=3 Environment="OLLAMA_MODELS=/data/ollama/models" Environment="OLLAMA_HOST=0.0.0.0:11434" [Install] WantedBy=multi-user.target

这里有两个参数值得注意。OLLAMA_MODELS指定模型存储路径，默认是~/.ollama/models，如果你系统盘空间紧张，一定要改到大盘上。OLLAMA_HOST=0.0.0.0:11434让服务监听所有网卡，这样局域网内其他机器也能访问你的 Ollama 服务。但要注意，开放到 0.0.0.0 意味着同网络下任何人都能调用你的模型，如果是公司内网还好，如果是公网环境一定要加防火墙规则或者反向代理做鉴权。

2.3 Docker 方式：适合想隔离环境的场景

如果你不想污染宿主机环境，或者想在 NAS、服务器上跑，Docker 是最干净的方式。官方提供了ollama/ollama镜像，基础用法：

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

如果要跑 GPU 加速，需要装 NVIDIA Container Toolkit，然后加上--gpus all参数：

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

Docker 方式的坑在于模型数据持久化。如果你不挂载 volume，容器一删模型就没了，下次还得重新下载。上面命令里的-v ollama:/root/.ollama就是把模型目录挂到 named volume 上。如果你想挂到宿主机具体路径，写成-v /your/path:/root/.ollama就行。

还有一个容易忽略的点：Docker 容器内的 Ollama 默认只监听容器内的 127.0.0.1，虽然你做了端口映射，但外部还是访问不到。需要在启动时加环境变量-e OLLAMA_HOST=0.0.0.0，让容器内的服务监听所有网卡。

3. 模型怎么选：参数、量化与你的硬件匹配表

3.1 参数量不是越大越好，先看显存

Ollama 支持的主流模型参数量从 0.5B 到 70B 都有。很多人一上来就想拉 70B 的模型，结果发现要么跑不起来，要么跑起来慢得像蜗牛。选模型的第一原则是看你的显存。

一个粗略的估算公式：模型以 FP16 精度加载时，每 10 亿参数大约占 2GB 显存。也就是说，7B 模型需要约 14GB 显存，13B 需要约 26GB，70B 需要约 140GB。这个数字对大多数人来说显然不现实，所以实际用的都是量化版本。

量化就是把模型权重从 FP16 压缩到更低精度，常见的有 Q4_K_M、Q5_K_M、Q8_0 等。Q4 表示 4-bit 量化，Q8 表示 8-bit。量化等级越低，模型越小、跑得越快，但精度损失也越大。实测下来，Q4_K_M 是性价比最高的档位，精度损失在可接受范围内，显存占用只有 FP16 的四分之一左右。

下面这张表是我实测整理的，供你选模型时参考：

如果你只有 8GB 显存，7B 或 8B 的 Q4 版本是最舒服的选择。如果连独显都没有，只有核显加 16GB 内存，可以试试 2B 或 3B 的小模型，虽然能力有限，但跑个简单问答没问题。

3.2 不同模型的能力差异，别只看榜单

选模型不能只看参数量，不同模型擅长的方向差别很大。我按实际使用体验分几类说。

通用对话类：Qwen 系列、Llama 系列是首选。Qwen 在中文理解上明显更强，Llama 在英文任务上更稳。如果你主要用中文，优先选 Qwen。

代码类：Qwen-Coder、DeepSeek-Coder 这类专门针对代码训练的模型，在代码补全和生成上比通用模型强不少。如果你拿 Ollama 做编程助手，直接上代码专用模型。

嵌入类：如果你要做知识库、RAG 这类应用，需要的是 embedding 模型而不是对话模型。Qwen3-Embedding 系列是常见选择，它把文本转成向量，供检索使用。注意 embedding 模型不能用ollama run直接对话，它只提供向量化接口。

推理类：DeepSeek-R1 系列带思维链，适合需要多步推理的任务，但输出速度慢，因为模型会先"想"一大段再给答案。

我的建议是：先拉一个 7B 或 8B 的通用模型跑通流程，确认环境没问题，再根据具体需求换专用模型。不要一上来就纠结哪个模型最强，跑起来比选什么更重要。

3.3 拉取与运行模型的实际操作

拉取模型用ollama pull：

ollama pull qwen3.5:2b

运行模型用ollama run：

ollama run qwen3.5:2b

run命令如果发现本地没有这个模型，会自动先拉取再运行。进入交互界面后，直接输入问题回车就行。退出用/bye或者 Ctrl+D。

查看本地已有模型：

ollama list

删除不需要的模型：

ollama rm qwen3.5:2b

这里有个实用技巧：如果你只是想测试模型能不能跑，不要拉完整版。很多模型提供了小参数版本，比如qwen3.5:2b只有 2B 参数，下载快、占用小，适合验证环境。确认没问题了再拉大模型。

4. 把 Ollama 变成你的 API 后端：接口调用与集成

4.1 原生 API 的基本用法

Ollama 启动后会在11434端口暴露一套 REST API。最常用的是生成接口：

curl http://localhost:11434/api/generate -d '{ "model": "qwen3.5:2b", "prompt": "用一句话解释什么是量化", "stream": false }'

stream设为false时，接口会等模型生成完一次性返回。设为true则流式返回，适合做打字机效果。对话接口是/api/chat，格式略有不同：

curl http://localhost:11434/api/chat -d '{ "model": "qwen3.5:2b", "messages": [ {"role": "user", "content": "你好"} ], "stream": false }'

messages数组里可以放多轮对话历史，role支持system、user、assistant三种。system消息用来设定模型的人设和行为规则，比如"你是一个专业的 Python 助手，回答要简洁"。

4.2 兼容 OpenAI 接口：让现有工具直接接入

Ollama 从某个版本开始提供了 OpenAI 兼容接口，路径是/v1/chat/completions。这意味着任何支持 OpenAI API 的客户端，只要把 base_url 改成http://localhost:11434/v1，就能直接连 Ollama。

这个特性非常实用。比如你用 Chatbox 这类客户端，在设置里把 API 地址改成 Ollama 的地址，模型名填你在 Ollama 里拉取的模型名，就能像用在线 API 一样用本地模型。很多 AI Agent 框架、知识库工具也都支持自定义 OpenAI 兼容接口，接上 Ollama 就能跑。

用 Python 调用的话，可以直接用 openai 库：

from openai import OpenAI client = OpenAI( base_url="http://localhost:11434/v1", api_key="ollama" # 随便填，Ollama 不校验 ) response = client.chat.completions.create( model="qwen3.5:2b", messages=[ {"role": "system", "content": "你是一个有帮助的助手"}, {"role": "user", "content": "介绍一下你自己"} ] ) print(response.choices[0].message.content)

注意api_key虽然随便填，但不能不填，否则 openai 库会报错。这是客户端库的要求，不是 Ollama 的要求。

4.3 并发与超时设置

Ollama 默认同时只处理一个请求，如果你并发调用，后面的请求会排队。对于个人使用这没问题，但如果你要接多个客户端，需要调整OLLAMA_NUM_PARALLEL环境变量：

OLLAMA_NUM_PARALLEL=4 ollama serve

这个值设成几，就允许几个请求同时处理。但要注意，并发数越高，单个请求的速度越慢，因为显存和算力是共享的。设成 2 到 4 是比较合理的范围。

超时方面，Ollama 默认的请求超时比较长，但如果你在客户端设置了较短的超时，长文本生成可能会被截断。建议客户端超时设到 120 秒以上，给模型足够的生成时间。

5. 性能调优：让模型跑得更快、更稳

5.1 显存不够时的降级策略

显存不够是最常见的问题。表现是模型加载失败，或者加载成功但一推理就报错。Ollama 提供了一些参数来缓解。

第一个是num_gpu，控制有多少层跑在 GPU 上。默认情况下 Ollama 会尽量把所有层放 GPU，显存不够时自动降级到 CPU。你也可以手动指定：

ollama run qwen3.5:2b --num-gpu 20

数字表示放在 GPU 上的层数。层数越少，显存占用越低，但速度越慢。如果完全放 CPU 跑，速度会慢一个数量级，但至少能跑起来。

第二个是num_ctx，控制上下文窗口大小。默认是 2048 或 4096，上下文越大显存占用越高。如果你不需要处理长文本，把它调小能省不少显存：

ollama run qwen3.5:2b --num-ctx 1024

第三个是换更小的量化版本。同一个模型，Q4 比 Q8 省一半显存。如果 Q4 还跑不动，可以找 Q3 甚至 Q2 的版本，但精度损失会比较明显。

5.2 速度优化的几个实用参数

除了显存，速度也是大家关心的。影响速度的主要因素有三个：模型大小、量化等级、硬件性能。在硬件固定的情况下，能调的就是参数。

num_thread控制 CPU 推理时的线程数。如果你用 CPU 跑，把它设成物理核心数（不是超线程数）通常最快：

ollama run qwen3.5:2b --num-thread 8

num_predict控制最大生成 token 数。默认是 128，对于长回答可能不够。设成 -1 表示不限制，但这样模型可能会一直生成下去。建议设成 512 到 2048 之间的值。

还有一个容易被忽略的点：首次加载模型慢是正常的。模型需要从磁盘读入显存，几个 GB 的模型读几秒到几十秒都正常。加载完之后，后续请求就快了。所以不要因为第一次慢就以为配置有问题。

5.3 模型存储位置与磁盘 IO

模型默认存在系统盘的用户目录下。如果你系统盘是 SSD 还好，如果是机械盘，加载速度会明显变慢。把模型目录改到 SSD 上能提升加载速度。

改法是通过OLLAMA_MODELS环境变量：

export OLLAMA_MODELS=/ssd/ollama/models

Windows 下在系统环境变量里新增这一条，然后重启 Ollama 服务。注意改完之后，之前下载的模型不会自动迁移，需要手动把旧目录的文件拷过去，或者重新下载。

6. 那些文档里不写但一定会遇到的报错

6.1 500 Internal Server Error 的排查链路

ollama run时报500 internal server error: llama-server process是最让人头疼的错误之一，因为它只告诉你"出错了"，不告诉你为什么。我踩过几次之后总结了一套排查流程。

第一步，看 Ollama 的服务日志。Linux 下用journalctl -u ollama -f，Windows 下在%LOCALAPPDATA%\Ollama\目录找日志文件。日志里通常会有更具体的错误信息，比如"out of memory"或者"failed to load model"。

第二步，如果是显存不足，日志里会明确写 OOM。这时候按上一节的降级策略处理：减小num_gpu、减小num_ctx、换更小的量化版本。

第三步，如果日志里没有明显错误，可能是模型文件损坏。删掉重新拉：

ollama rm qwen3.5:2b ollama pull qwen3.5:2b

第四步，如果重新拉还是不行，检查 Ollama 版本和模型是否兼容。有些新模型需要较新版本的 Ollama 才能跑，老版本会报错。升级 Ollama 到最新版通常能解决。

6.2 下载中断与断点续传

模型下载到一半断了是常事，尤其是大模型。好消息是 Ollama 支持断点续传，重新执行ollama pull会从断点继续，不会从头开始。但如果中断次数太多，模型文件可能损坏，这时候只能删掉重来。

为了避免下载中断，建议在网络稳定的时段拉模型，或者配好国内镜像源。如果实在拉不下来，可以找别人下载好的模型文件，手动放到OLLAMA_MODELS目录下对应的位置。Ollama 的模型目录结构是models/blobs/存实际文件，models/manifests/存元数据，手动放置时需要两个目录都对应上。

6.3 端口冲突与服务启动失败

Ollama 启动失败最常见的原因是端口被占用。除了前面说的netstat排查，还有一个简单办法：直接改端口。

OLLAMA_HOST=127.0.0.1:11435 ollama serve

改完之后，所有客户端调用的地址也要相应改成新端口。如果你用的是 OpenAI 兼容接口，base_url 要改成http://localhost:11435/v1。

另一个启动失败的原因是权限问题。Linux 下如果 Ollama 以非 root 用户运行，但模型目录权限不对，会启动失败。检查OLLAMA_MODELS目录的属主和权限，确保运行 Ollama 的用户有读写权限。

7. 从 Ollama 到 vLLM：什么时候该换，怎么换

7.1 两者的定位差异

Ollama 和 vLLM 经常被拿来比较，但它们其实解决的是不同层次的问题。Ollama 是面向个人和小团队的本地推理工具，强调易用性和开箱即用。vLLM 是面向生产环境的高性能推理引擎，强调吞吐量和并发能力。

具体来说，vLLM 的核心优势是 PagedAttention 和连续批处理，能在高并发场景下把 GPU 利用率拉满。同样的硬件，vLLM 的吞吐量可能是 Ollama 的几倍甚至十几倍。但代价是部署复杂度高得多，需要配 Python 环境、装 CUDA 依赖、写启动脚本，模型格式也要转换。

Ollama 的优势是简单。一条命令跑起来，模型自动管理，API 开箱即用。对于个人开发、原型验证、小规模使用，它的性能完全够。你不会因为用了 Ollama 而觉得慢，除非你同时有几十个请求在排队。

7.2 迁移的时机判断

什么时候该从 Ollama 换到 vLLM？我总结几个信号：

• 你的服务同时有超过 5 个并发请求，且对响应时间敏感
• 你需要多卡推理，单卡显存不够
• 你需要部署 70B 以上的大模型
• 你需要精细控制推理参数，比如自定义调度策略
• 你要做生产级服务，需要监控、限流、负载均衡

如果以上都不满足，继续用 Ollama 就好，没必要为了性能数字折腾自己。

7.3 迁移的实际操作要点

真要迁移到 vLLM，核心步骤是：装 vLLM、下载模型权重（注意 vLLM 用的是 HuggingFace 格式，不是 Ollama 的 GGUF 格式）、写启动命令、配 OpenAI 兼容接口。

vLLM 的启动命令大概长这样：

python -m vllm.entrypoints.openai.api_server \ --model Qwen/Qwen3.5-7B \ --served-model-name qwen3.5-7b \ --port 8000 \ --tensor-parallel-size 1

启动后同样暴露 OpenAI 兼容接口，客户端把 base_url 从 Ollama 的地址改成 vLLM 的地址就行。模型名从 Ollama 的qwen3.5:2b改成 vLLM 的qwen3.5-7b。

Docker 部署 vLLM 的话，官方镜像vllm/vllm-openai是常见选择。注意镜像本身不带模型，模型需要挂载进去或者启动时下载。挂载方式：

docker run --gpus all -v /path/to/models:/models -p 8000:8000 \ vllm/vllm-openai:latest \ --model /models/Qwen3.5-7B \ --served-model-name qwen3.5-7b

迁移过程中最容易踩的坑是模型格式不兼容。Ollama 用的 GGUF 格式 vLLM 不认，需要重新下载 HuggingFace 格式的权重。另外 vLLM 对 CUDA 版本和 PyTorch 版本有要求，装之前先看官方文档的兼容性矩阵，别盲目装最新版。

8. 把 Ollama 接进你的 AI Agent 和知识库

8.1 作为 Agent 的推理后端

AI Agent 的核心是"让模型自己决定下一步做什么"，它需要频繁调用推理接口。Ollama 的 OpenAI 兼容接口让这件事变得很简单，大多数 Agent 框架都支持自定义 LLM 后端。

以常见的 Agent 框架为例，配置大概是这样：

from langchain_openai import ChatOpenAI llm = ChatOpenAI( base_url="http://localhost:11434/v1", api_key="ollama", model="qwen3.5:2b", temperature=0.7 )

配好之后，Agent 的工具调用、多轮对话、任务规划都会走本地模型。好处是数据不出本地，隐私有保障，而且没有 API 调用费用。坏处是本地模型的能力通常不如在线大模型，复杂任务可能搞不定。

我的建议是：用本地模型做简单任务，复杂任务走在线 API。比如意图识别、文本分类、简单问答用 Ollama，需要深度推理的任务再调在线模型。这样既省成本又保证效果。

8.2 搭建本地知识库的完整链路

用 Ollama 搭知识库是很多人关心的场景。核心链路是：文档切分、向量化、存储、检索、生成。

向量化用 embedding 模型，比如qwen3-embedding:0.6b：

ollama pull qwen3-embedding:0.6b

调用 embedding 接口：

import requests response = requests.post( "http://localhost:11434/api/embeddings", json={ "model": "qwen3-embedding:0.6b", "prompt": "你要向量化的文本" } ) vector = response.json()["embedding"]

拿到向量之后存到向量数据库里，检索时把用户问题也向量化，做相似度匹配，找到最相关的文档片段，拼进 prompt 里让对话模型生成答案。

这条链路里最容易出问题的是切分策略。切得太碎，检索到的片段缺乏上下文；切得太大，检索精度下降。一般建议按语义切分，每段 200 到 500 字，段间保留一定重叠。具体参数要根据你的文档类型调，没有万能值。

8.3 多模型协作的实践思路

Ollama 支持同时加载多个模型，你可以让不同模型干不同的事。比如用小模型做意图识别，用大模型做最终生成，用 embedding 模型做检索。这种"模型编排"的思路在资源有限时特别有用。

实现方式是在代码里根据任务类型切换模型名。Ollama 会按需加载模型，但注意同时加载多个模型会占用更多显存。如果显存紧张，可以让模型串行使用，用完一个卸载一个。Ollama 默认会在模型闲置一段时间后自动卸载，这个时间可以通过OLLAMA_KEEP_ALIVE环境变量控制。

OLLAMA_KEEP_ALIVE=5m ollama serve

设成5m表示模型闲置 5 分钟后卸载。设成-1表示永不卸载，适合频繁调用的场景。设成0表示用完立即卸载，适合显存极度紧张的场景。

9. 我实际用下来的一些体会

Ollama 这个工具最大的价值不是技术多先进，而是它把"本地跑大模型"这件事从"需要折腾半天"变成了"五分钟搞定"。我见过太多人卡在环境配置上，还没跑到模型就放弃了。Ollama 把这一层完全屏蔽掉，让你能专注于用模型解决问题，而不是配环境。

但它也有明显的边界。并发一高就排队，大模型跑不动，精细控制能力弱。所以我的用法是：Ollama 做开发和原型，vLLM 做生产部署。两者不是替代关系，是不同阶段的工具。

最后分享一个实用习惯：每次拉新模型之前，先ollama list看看本地已经有什么，别重复下载。模型文件很占空间，一个 7B 的 Q4 模型就 4GB 多，拉十几个模型硬盘就满了。定期清理不用的模型，用ollama rm删掉，能省不少空间。

还有一点，如果你在 Windows 上用，建议把模型目录改到非系统盘。Ollama 默认装在 C 盘用户目录下，模型多了 C 盘很快就红了。改OLLAMA_MODELS环境变量这一步，越早做越好，等 C 盘满了再改就麻烦了。