本地跑大模型这件事，Ollama 出现之前是折腾，出现之后是“一行命令”。ollama run llama3.1，回车，模型下载完就能对话——这个体验确实把门槛打下来了。但用了一段时间之后会发现，它把“能跑起来”做到了极致，把“跑得舒服”留给了你自己。

这篇不黑不吹，优点先讲清楚，坑一个一个摆出来，最后给结论：什么人适合直接用它，什么人该绕开。

先说立场：Ollama 不是烂项目。一个能把本地大模型从极客玩具变成普通人工具的项目，方向是对的。它的坑，大多是“简单”这个定位本身带来的取舍。

先说好的：它到底好在哪

第一，安装和上手是真的简单。macOS、Linux、Windows 都有官方安装包，装完就是一个命令行工具加一个后台服务。不用配 Python 环境，不用装一堆依赖，不用手写加载代码。对比之前本地跑模型要折腾的 llama.cpp 编译、权重格式转换、显存参数调优，Ollama 把这些全藏起来了。

ollama pull qwen2.5:7b（拉取模型）

ollama run qwen2.5:7b（下载完直接开聊）

ollama list（看本地有哪些模型）

ollama ps（看当前加载了哪些模型）

第二，模型库够全，命令统一。Llama、Qwen、Mistral、DeepSeek 这些主流开源模型，官方模型库里基本都有，名字一换就能跑。不用再去各个项目主页找权重、研究加载方式。对想快速试不同模型的人来说，这个统一入口省了大量时间。

第三，API 兼容 OpenAI 格式。这是很多人忽略但实际最有用的优点。Ollama 默认在 http://localhost:11434 提供服务，并且提供了兼容 OpenAI 的接口，/v1/chat/completions、/v1/models 都能用。意思是你手头现成的、按 OpenAI 格式写的代码，改个 base_url 就能切到本地模型，不用重写调用层。

from openai import OpenAI

同样的客户端代码，改个地址就能连本地模型

client = OpenAI(

    base_url="http://localhost:11434/v1",

    api_key="ollama",

)

resp = client.chat.completions.create(

    model="qwen2.5:7b",

    messages=[{"role": "user", "content": "用一句话解释什么是向量数据库"}],

)

print(resp.choices[0].message.content)

第四，自定义模型有标准姿势。通过 Modelfile 可以基于现有模型改系统提示词、调温度等参数，类似 Dockerfile 的写法，改完 ollama create 就能用。想给模型固定一个角色、一种回答风格，不用每次在代码里拼提示词。

FROM qwen2.5:7b

SYSTEM "你是一名资深的 Python 工程师，回答要给出可直接运行的代码，并注明关键步骤。"

PARAMETER temperature 0.3

所以结论的前半句很明确：个人尝鲜、快速试模型、本地搭个能用的对话或 RAG 原型，Ollama 仍然是目前最顺手的选择之一。

再说坑：五个被吐槽最多的地方

坑一：默认上下文只有 2048 个 token

这是最容易踩、也最容易被误判为“模型变笨”的坑。Ollama 的 num_ctx 参数默认值是 2048，超过这个长度的对话历史会被截断。你跟模型聊着聊着，它突然“失忆”，开始答非所问，很可能不是模型不行，是上下文窗口满了。

解法是有的，启动或调用时把 num_ctx 调大：

ollama run qwen2.5:7b -- --num_ctx 8192

或者在 API 调用里传 options：

resp = client.chat.completions.create(

    model="qwen2.5:7b",

    messages=[...],

    extra_body={"options": {"num_ctx": 8192}},

)

但调大上下文要付出代价：显存占用跟着涨，速度跟着降。所以这不是一个“改个数字就完事”的设置，而是一个需要根据机器配置权衡的取舍。官方默认 2048 保证了低配机器也能跑，但也意味着默认体验对稍长一点的对话并不友好。

坑二：并发请求会排队

Ollama 默认情况下，同一个模型同一时间只处理一个请求，后来的请求要排队等。个人用没感觉，一旦把它当成团队内部的小服务，或者接了两三个应用同时调用，延迟会突然变大。

可以通过环境变量调大并行数：

OLLAMA_NUM_PARALLEL=4 ollama serve

但并行数不是免费的，每个并发请求都要分走一部分显存和算力。机器配置不够，调大并行反而会让所有请求一起变慢。如果你的场景真的需要高并发，Ollama 不是为这个设计的，它更像一个“个人工作站工具”，而不是“生产级推理服务”。这两者之间的界线，用之前要先想清楚。

坑三：显存和速度，全看硬件脸色

本地跑模型，体验完全取决于你的显卡。有独显和没独显，是两个世界：有独显时对话流畅，没独显、纯 CPU 推理时，生成速度会明显变慢，长回答要等上一阵。模型越大越明显，7B 尚可，13B 以上在纯 CPU 上基本只能尝鲜。

模型体积本身也是成本：7B 的量化模型几个 GB，70B 的要几十 GB。下载要时间、要硬盘，加载要显存。“本地免费跑大模型”这个说法没错，但前提是你已经有一台配置够用的机器，硬件成本并没有消失，只是从按量付费变成了提前投入。

所以选型之前先算一笔账：这台机器的显存够不够跑你想用的模型、硬盘够不够存几个模型、CPU 推理的速度你能不能接受。三个问题有一个答不上来，就先别急着下结论。

坑四：API 默认没有鉴权，暴露出去就是裸奔

Ollama 默认只监听 127.0.0.1:11434，也就是只接受本机访问，这是对的。但很多人为了让局域网其他机器或远程服务调用，会把监听地址改成 0.0.0.0：

OLLAMA_HOST=0.0.0.0:11434 ollama serve

改完之后要意识到：Ollama 的 API 默认没有任何鉴权措施，任何人只要能连上这个端口，就能调用你的模型、拉取和删除模型。暴露到公网是非常危险的操作。如果确实需要远程访问，至少要在前面加一层反向代理做鉴权，或者用防火墙限制来源 IP。这个坑不是 Ollama 的 bug，而是“简单”定位下有意省掉的部分，但新手很容易在不知情的情况下踩进去。

坑五：模型更新全靠手动重新拉取

模型出新版本了，Ollama 不会自动提醒、也不会自动更新。你要自己 ollama pull 一遍，旧版本还占着磁盘，得手动 ollama rm 清理。模型装得多了，磁盘占用和版本管理就成了一笔糊涂账。官方模型库的更新节奏不慢，半年下来本地可能攒了一堆叫不上名字、不知道还能不能用的旧版本。定期 ollama list 清理一次，是用 Ollama 的必修课。

什么时候用它，什么时候绕开

个人尝鲜、试不同开源模型：直接用，最顺手

本地搭 RAG / 对话原型：适合，API 兼容 OpenAI 省事

隐私数据不想出内网：适合，模型和数据都在本地

团队内部小范围共享服务：能用，但要处理并发和鉴权

高并发生产推理：绕开，换专门的推理服务框架

显存小的机器跑大模型：先算账，别硬上

最后给一句实在的总结：Ollama 最大的价值，是让“本地跑大模型”从折腾变成了日常。它的坑，大部分不是设计失误，而是“简单”这个定位的另一面——默认配置保守、高级能力要自己调、生产级需求要自己补。知道这条边界的人用它会很顺手，不知道的人会在同一个地方反复撞墙。

求个关注：我是 Joy船长，正在每天认真拆一个 AI、开源或代码安全方面的真实问题。觉得这篇对你有点用，麻烦点一下关注，后面的更新不迷路，下一篇见。