我先说明一下这篇要写什么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 --gpusall -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama这条命令里几个参数的作用分别是--gpusall让容器内可以使用宿主机全部 GPU不加这条容器内只能 CPU 跑。-v ollama:/root/.ollama把模型数据放到 Docker 卷里容器删了模型还在。-p 11434:11434把容器内的 11434 端口映射到宿主机方便外部调用 API。容器方式部署后需要进入容器执行模型操作docker exec -it ollama ollama run qwen2.5:7bDocker 方案也有一个需要留意的点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] EnvironmentOLLAMA_BASE_URLhttps://你的加速地址保存后重载配置并重启服务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 的命令行体系可以说是“所见即所得”其中最常用的命令我用一个表格整理出来命令作用示例ollama list查看本地已下载的模型列表ollama listollama pull拉取模型到本地手动提前下载ollama pull qwen2.5:7bollama run拉取并进入交互对话模型不存在时会先拉取ollama run llama3.1:8bollama rm删除本地模型释放空间ollama rm llama2:7bollama show查看模型详情如参数量、量化方式等ollama show qwen2.5:7b --modelfileollama cp复制生成模型的新标签ollama cp qwen2.5:7b my-copyollama stop停止当前正在运行的模型服务持续监听但释放显存ollama stop qwen2.5:7bollama serve手动启动 Ollama 后台服务进程ollama serve模型 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 服务文件 / 环境变量中追加EnvironmentOLLAMA_HOST0.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。排查步骤要按顺序来确认nvidia-smi能正常输出。如果是 Docker 部署检查启动命令里是否加了--gpusall。原生安装的话执行ollama serve手动启动一次在日志里看有没有加载 CUDA 相关的信息。检查驱动版本和 CUDA 版本是否过老Ollama 新版本通常要求 CUDA 11.3 以上。有一种情况特别无语驱动和 CUDA 都正常但 Ollama 服务是在驱动安装之前启动的。这种时候系统里可能有多个 Ollama 进程在跑互相抢占资源。先sudo pkill ollama再重新拉起服务往往就好了。5.3 显存不够怎么硬跑如果你只有 8GB 显存却想跑 14B 模型Ollama 的机制是默认把部分层放 GPU、剩下的放 CPU这叫“部分卸载”。这种模式下模型的加载时间会拉长推理时也会出现 GPU 和 CPU 之间频繁交换数据的情况速度会明显下降。想要手动控制卸载策略可以这样设置OLLAMA_GPU_LAYERS20这个值表示把模型的前 20 层放到 GPU剩下的由 CPU 处理。具体设多少层合适没有标准答案建议从 10 层起步逐步增加观察显存占用和生成速度找到一个平衡点。如果设得太高显存溢出Ollama 反而会直接报错。5.4 磁盘告急模型存储位置怎么迁移模型默认存在~/.ollama/models家目录空间不够用时可以把整个目录迁移到大容量磁盘上。推荐做法是修改环境变量OLLAMA_MODELS指向新路径然后把旧目录的数据同步过去。# 停止服务 sudo systemctl stop ollama # 迁移目录 sudo mv ~/.ollama/models /data/ollama_models # 修改服务文件增加环境变量 # EnvironmentOLLAMA_MODELS/data/ollama_models # 重载并启动 sudo systemctl daemon-reload sudo systemctl start ollama这里有个小坑如果你把目录整体mv走了旧路径没了系统又会自动创建一个空目录。下次再 pull 模型时可能又拉到旧路径去了白白占一份磁盘空间。所以迁移后务必检查环境变量是否真的生效用ollama list确认模型列表还完整。5.5 多模型同时跑还是按需加载Ollama 的机制是一次只能加载“一组”模型进显存如果你用完模型 A 没停掉接着去 run 模型 BOllama 会先把模型 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, jsonpayload) 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_URLhttp://宿主机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( modelqwen2.5:7b, base_urlhttp://localhost:11434, temperature0, num_ctx8192 ) 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 按显存大小分类很多人第一次部署成功后会陷入选择困难到底哪个模型最适合我我的建议很简单先看显存再定档位显存大小推荐参数量推荐模型4GB~6GB7BQ4量化Qwen2.5-7B-Instruct、Phi-3.5-mini8GB7B~9BQwen2.5-7B、Llama 3.1-8B、GLM-4-9B12GB~16GB13B~14BQwen2.5-14B、Yi-1.5-14B24GB32BQ4量化Qwen2.5-32B、GLM-4-32B48GB70BQ4量化Qwen2.5-72B、Llama 3.1-70B这个表格只是一个起点不是硬性规则。不同模型对显存的实际占用差异很大建议选定模型后直接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 调用都正常之后再慢慢升级模型。这个顺序能帮你省掉无数浪费在排错上的时间。