很多人第一次听说本地跑大模型，第一反应是这事跟普通人有关系吗？老实说，我开始也是这么想的。直到我下决心在自己电脑上跑通一次 Ollama，才发现把一个大模型装进本地环境，已经在不知不觉中变得很像装一个普通应用——下载、安装、执行，三句话能说清楚。特意写这篇，是想把我从环境准备到模型跑通的完整过程拆开来讲，让还没试过的朋友少走弯路。这篇文章适合谁？手头有一台配置还行的 Windows、macOS 或 Linux 电脑，想体验在本地跑大模型，但不想一上来就碰复杂的训练、微调流程的人。或者你是做开发、写脚本的，想把一个大模型当成一个本地服务来调用，这篇文章同样能帮你把底子打好。我会从设计思路上讲清楚为什么选 Ollama，再给一套可以直接照抄的安装、配置、验证流程，最后把常见的坑挨个列出来。1. Ollama 解决了什么问题，为什么值得本地部署1.1 本地部署和在线 API 之间的本质区别在详细讲安装之前，得先聊清楚一个核心问题：为什么要在本地跑模型。很多人习惯了直接打开网页对话框，或者注册各种在线 API 来调用大模型，这两种方式各有各的好处，但本地部署解决的恰好是在线方案做不到的几件事。首先是数据隐私。本地部署的整个过程完全发生在你自己的设备里，输入什么、输出什么，不需要经过任何外部服务。对医疗记录、合同条款、未公开代码这类敏感内容来说，这一点非常重要。在很多实际项目里，数据根本不允许离开本机网络，本地推理就成了唯一选择。其次是成本。在线 API 通常按 token 计费，日常简单用用可能没什么感觉，一旦批量处理文本，费用就会以肉眼可见的速度涨。本地部署只需要一次性付硬件成本，后续跑多久都不产生额外费用。对个人开发者或者小团队来讲，本地推理在长期批量任务上有很明显的经济优势。第三是稳定性。本地服务不依赖外部网络状态，不依赖别人的服务器是否可用，也不存在某个热门模型突然调整访问策略导致你服务中断的问题。只要机器开着，服务就在。1.2 Ollama 在设计上的几个关键取舍市面上能让大模型在本地跑起来的工具其实不少，但我最后长期使用的是 Ollama，原因是它在设计上做了几个非常符合实际使用习惯的取舍。最直观的一点是命令行极简。对一个用户来说，第一步只需要一条安装命令，之后拉取模型、运行模型、查看模型列表，都是几个单词的事，学习成本低到几乎可以忽略。项目本身内置了模型下载和版本管理，不需要手动去各个模型仓库找权重文件，也不需要自己处理模型格式转换。它把服务端和客户端做成了同一套体系。命令行工具负责发起请求，后台服务负责加载模型、处理推理。这意味着你不但能在终端里交互式聊天，还能直接向本地服务发 HTTP 请求，把它当成一个 API 服务来用。很多后续的二次开发、自动化脚本，都可以直接基于这个服务来做，不需要引入额外框架。它内置了针对不同硬件环境的优化。你在安装时不需要做复杂的编译配置，它会自动检测当前机器的硬件情况，选择合适的计算路径来跑推理。对普通用户来说，省掉这些配置时间，体验完全不一样。2. 部署前的必读清单：环境评估与版本选择2.1 硬件与系统要求Ollama 官方对操作系统的支持范围覆盖了 macOS、Windows 和主流的 Linux 发行版。如果用的是 Windows，建议使用 64 位的 Windows 10 或更新版本，旧系统有时会遇到缺少新版运行库的问题。macOS 方面，建议使用较新版本的系统，因为旧系统可能会因为缺少系统组件而无法启动服务。Linux 端则没有什么特殊限制，主流发行版都可以。硬件方面很多人以为必须有一张昂贵的独立显卡，其实不是。模型能不能跑起来，核心看内存和磁盘空间。纯 CPU 推理是可行的，代价只是速度慢。我在没有独显的笔记本上实测过，跑一个参数量在 7B 左右的量化模型，处理简单的中英文对话完全可用，只是生成速度不如带独显的机器流畅。内存方面，不同的模型差别很大。一个 7B 参数的量化模型，在加载进内存后大概会占用 5GB 到 6GB 左右的空间，所以整机 8GB 内存是个起点。如果是 13B 参数模型，内存占用通常超过 10GB，建议整机内存至少 16GB。选模型之前先查清楚自己有多少可用内存，这能帮你避免运行到一半进程被杀掉的尴尬。磁盘空间同样重要。模型文件很大，7B 模型量化后常见体积在 4GB 到 5GB 之间，13B 模型普遍在 8GB 以上。安装完 Ollama 程序本身只占很小的空间，大头全在模型文件上。给数据盘留出至少 20GB 的余量是一个比较稳健的做法。2.2 安装包版本与分发渠道安装 Ollama 时的版本来源需要特别注意。我个人的建议是只从官方发布渠道获取安装包。第三方整合包虽然偶尔会附带一些模型或者一键脚本，但来源不明，安全上不可控，而且一旦出问题很难排查。官方渠道针对不同系统提供了对应的安装形式：macOS 可以直接下载安装包，Windows 下载安装程序，Linux 则有打包好的安装包和直接解压的二进制文件。有人可能更喜欢用包管理器来安装，这也是可行的，但要注意不同包管理器里的版本未必同步更新，可能出现命令行提示版本过旧的情况。更新版本这件事常常被忽略。Ollama 的更新频率不低，新版通常会修复旧版本的崩溃问题、优化推理速度、增加新的模型支持。不过我的建议是：不要在大模型跑到一半、或者有重要工作正在进行时随手升级。选一个空闲的时间窗口，升级完成后先跑一次冒烟测试，确认服务能正常起来，再继续使用。2.3 先想清楚模型存放位置这是很多人一开始没注意，后来不得不返工的问题。Ollama 默认把模型文件存放在系统盘的用户目录下，Windows 上默认在用户的 .ollama 文件夹里，macOS 和 Linux 也类似。问题在于，很多人的系统盘本来就不宽裕，而模型文件动辄几 GB、十几 GB，很快会把 C 盘塞满。最稳妥的做法是在安装完成后、拉取任何模型之前，先规划好模型的存放位置。如果打算把模型放在独立的机械硬盘、第二块 SSD 或者其他数据目录里，提前用环境变量把模型路径指过去，可以避免后面搬运数据带来的麻烦。这一步设计得好，后面长期使用会很省心。3. 三平台安装实操：从下载到跑通第一个模型3.1 macOS 安装步骤macOS 上的安装有两种常见路径。第一种是直接下载官方安装包，双击安装，然后把应用拖进应用程序目录。安装完成后，打开终端执行ollama --version，如果能看到版本号，说明安装成功。第二种是通过包管理器安装，在终端里执行包管理器提供的安装命令，比如常见的brew install ollama。两条路都能用，主要看个人习惯。如果你选择官方安装包，可能会遇到一个情况：打开时被系统拦截，提示来源不明。这不是程序有问题，而是系统的安全策略。你需要打开系统设置，找到隐私与安全性相关选项，允许该应用运行。处理完之后再打开一次就正常了。安装完成后，在终端输入ollama run 模型名，系统会自动开始拉取模型，拉取完成后会直接进入交互对话界面。第一次运行会等待模型下载，耗时取决于模型大小和网络状况。这个过程中终端会显示进度条。3.2 Windows 安装步骤Windows 端的安装流程相对直观。从官方渠道下载安装程序，常见的文件名是 OllamaSetup.exe。运行安装程序后，一路确认默认选项即可，安装过程中不需要设置额外的参数。装完以后系统可能会出现一个托盘图标，不用管它，这表示后台服务已经在运行了。安装完成后重启一次终端窗口，这一点很多人会忽略。安装程序虽然会写入环境变量，但是已经打开的终端窗口不会自动刷新环境变量，直接在新终端里执行ollama --version验证。如果提示找不到命令，先确认当前终端窗口是否是在安装完成之后新开的。Windows 上有个值得留意的细节：安装完成后，默认模型目录会落在系统盘用户目录下。如果你的 C 盘空间紧张，建议在安装之前或者刚装完还没拉模型时，先去设置一个环境变量OLLAMA_MODELS，把模型目录指到其他盘符，一劳永逸。3.3 Linux 安装步骤Linux 端安装方式比较多样，我个人的偏好是使用官方提供的自动安装脚本。在终端里执行脚本命令后，脚本会自动下载对应系统的安装包并完成安装。这种方式对新手最友好，不需要自己处理发行版差异。如果你更想手动控制，也可以去官方发布页面手动下载安装包。下载 deb 或 rpm 格式的安装包，然后用系统对应的包管理器命令安装，比如 Debian 系可以使用 dpkg 或 apt 来安装，RHEL 系可以使用 rpm 或 yum。手动安装的好处是版本完全可控，并且卸载时更清晰。另一种方式是直接下载二进制压缩包，解压后把主程序放到 /usr/local/bin 或者你自己的可执行路径下。这种方式的优点是干净，不依赖系统包管理器的状态，缺点是后续更新需要自己重新下载覆盖。Linux 上安装完成之后，还需要考虑服务运行方式。最省心的做法是让系统服务管理器接管 Ollama 进程，这样重启机器之后它会自动启动。用官方脚本安装的版本一般会自动配置好服务。如果用的是手动解压方式，可以自己创建一个服务文件，也可以简单地在启动脚本里写上ollama serve，开机自启即可。3.4 安装之后的必要检查程序装上之后，不要急着去拉模型。先做三个检查，能帮你后面省很多事。第一个检查安装是否可用。执行ollama --version，能输出版本号即可。第二个检查服务是否运行。执行ollama list，如果服务正常运行，会输出一个空列表或者已有的模型列表。如果提示无法连接，说明服务还没起来，Windows 上检查托盘图标，Linux 上检查服务状态，macOS 上用进程查看命令确认进程是否在。第三个检查端口监听。Ollama 服务默认监听本机的 11434 端口，如果你系统里有其他程序占用了这个端口，后续运行模型会失败。可以用系统自带的方式查看端口占用情况，确认 11434 没有被占用。4. 模型下载与本地运行的核心操作4.1 拉取模型前先搞清楚标签Ollama 里的模型通过标签来区分不同版本。同一个模型会有多个标签：不同参数量的，比如 7B、13B、30B；不同量化格式的，比如常见的一些带有精度标识的格式，还有常见的 q4、q8 这类量化档位。标签的选择直接影响两个东西：一个是模型的体积，一个是输出质量。量化位数越低，文件越小，内存占用越少，但输出质量的损失也越明显；量化位数越高，文件越大，内存占用越多，输出质量越接近原始模型。对大多日常对话场景，默认下发的量化版本是个不错的平衡点，体积和速度都合适，质量也基本够用。我见过有人强制拉了一个满精度的版本，结果一张普通显卡根本塞不下，内存吃紧，最后还得重新换。拉取模型的命令很简单，格式是ollama pull 模型名:标签。ollama run 模型名:标签其实会自动完成拉取，如果本地没有这个模型，它会先下载再进入对话。所以很多人的第一个模型其实是靠 run 拉下来的，不需要单独 pull。4.2 用命令行与模型交互当模型第一次下载完成后，终端会直接进入交互模式，你可以像聊天一样输入问题，模型实时生成回答。这个模式是快速验证模型效果最直接的方式。交互模式里有一些内置命令需要知道：退出对话是/bye；查看当前模型配置可以用/set，比如设置上下文长度、系统提示词之类。这些命令都以斜杠开头，和聊天的正文区分开。我建议刚上手的人先试一次/set，把默认参数过一遍，再决定要不要调整。除了交互模式，更常用的是把命令作为参数直接运行。比如写脚本的时候，可以用一条命令让模型处理单次输入，执行完就退出，非常适合批量任务。命令行工具的输出结果可以被脚本捕获，变量提取、文本处理都不成问题。4.3 模型存储目录的迁移与软链接方案如果你已经发现系统盘满了，或者一开始没规划好模型目录，就面临迁移问题。迁移时机越早越好，但已经下载了模型也能迁，只是步骤多几步。整体思路是：先停止正在运行的服务，然后把整个模型目录移动到新位置，再修改环境变量OLLAMA_MODELS指向新目录，最后重新启动服务。具体操作上，Windows 是在系统设置里修改用户环境变量，macOS 和 Linux 则是在 shell 配置文件中设置导出语句，或者直接在服务管理配置里写入环境变量。这里有一个容易踩的坑：如果模型文件体积大，移动过程中千万不要中断。我建议先复制过去，确认新目录里的文件数量和老目录一致，再把老目录改名保留而不是直接删除。等到服务能正常从新目录加载模型了，再删除旧目录。这个过程虽然保守了一些，但不会出现迁移到一半发现新位置缺文件的情况。还有一种组件方式是使用软链接。如果你不打算改服务配置，可以把默认目录里的模型文件保持不变，在默认位置创建一个软链接，指向实际存放模型的外部路径。这样做的好处是对程序透明，缺点是一旦弄错链接，服务可能不认。我的建议是直接改环境变量，语义更清晰，排查也容易。5. 实战中常见的坑与排除方法5.1 端口被占用之后怎么办Ollama 默认服务端口是 11434。有时这个端口会被别的程序占用，结果是命令行能正常执行，但任何需要访问后台服务的操作都会报错，错误信息通常比较模糊，只说无法连接。排查方式不复杂：先看 11434 端口上目前是谁在监听。如果你发现确实有别的程序占用了这个端口，有两个选择：关掉占用程序，或者给 Ollama 换端口。换端口的方式是设置OLLAMA_HOST环境变量，改成新的监听地址和端口。需要注意，改完之后服务必须重启，环境变量才会生效。5.2 模型下载卡住或速度很慢模型下载是很多人第一次使用时会遇到的问题。进度条长时间不动，或者下载到一半提示失败，确实很折磨人。这个问题并不神秘，大模型文件体积都是 GB 级别，质量再好的网络也需要一定时间。如果频繁失败，先别怀疑工具本身。检查一下磁盘空间，模型下载是边下边写，空间不足会导致下载过程突然终止。再检查网络稳定性，有时候是网络环境波动导致连接断开，服务端的下载机制会自动重试，但重试太频繁会让人感觉卡在某个百分比。另一个思路是换个更小的模型。同一个模型家族的量化版本之间体积差别很大，选择一个文件体积更小的版本，下载时间会明显缩短。对于一些只做简单测试的场景，先用小模型验证流程没问题了，再决定要不要下载大模型，这是一个很实用的策略。5.3 内存不足导致进程被杀模型运行到一半进程突然消失，最常见的原因是内存不够。大模型推理时不仅要把模型权重加载进内存，还要留出上下文计算的临时空间，所以实际内存占用通常会超过模型文件本身的体积。遇到这个问题，第一选择是换小模型。如果必须用当前模型，可以调整并发请求数量，限制同一时间处理的任务数。Ollama 提供了一个环境变量OLLAMA_NUM_PARALLEL，把它显式设为 1，让系统同一时间只处理一个请求，这样可以把内存峰值压到最低。同时关闭浏览器里大量占内存的标签页也能腾出不少空间。Windows 上还可以通过调整虚拟内存大小来缓解，但虚拟内存本质上是磁盘充当内存，速度会慢很多，只能拿来应急，不能当长期方案。5.4 卸载不干净的问题如果你已经试过跑某个模型，决定暂时不用 Ollama，或者换一台机器重新部署，卸载这件事也需要处理干净。很多人的印象里，卸载程序删掉就行，但实际上 Ollama 会把模型目录、配置文件和后台服务散落在不同位置，手动删不干净会导致以后重装时出现各种奇怪的冲突。Windows 上推荐用系统自带的卸载程序来卸载主程序，然后进入默认模型目录把所有内容删除，同时把环境变量里与 Ollama 相关的项目清理干净。macOS 和 Linux 类似，除了删除二进制文件之外，还要检查模型默认目录、配置文件、服务管理文件，全部手动清理一次。判断是否清理干净有一个简单粗暴的标准：卸载后重启系统，再执行一次ollama --version，如果系统提示找不到命令，说明主程序已经清理干净了。6. 部署之后还能怎么玩模型跑通之后，整个本地环境就算正式可用了。我的一个常用玩法是把它当成一个本地后台服务，写一些自动化脚本来调用。比如批量整理文档、批量处理文本摘要、统一改写一批文案。只要把文本内容和提示词组装好，用脚本向本地服务的接口发请求，就能在无人值守的情况下跑完整个批次。这种方法不依赖公网服务，跑多少都免费，数据也完全在自己手里。还有一个比较实用的思路：如果机器资源有限，平时只跑一个小模型满足日常问答，遇到复杂任务时再临时切换到更大模型。Ollama 可以同时管理多个模型，切换时不用反复安装卸载，只是换一个命令的问题。这样既能保证大部分场景的响应速度，又能在需要的时候提供更强的生成能力。我个人在实际操作中的体会是：本地部署这件事，真正的门槛从来不在安装这一步，而在于你是否愿意先花十几分钟把环境规划好。提前想清楚模型放哪、内存够不够、遇到端口冲突怎么处理，往往能避免后面一连串的折腾。如果你正准备在自己电脑上跑一个本地模型，按这篇的顺序走一遍，应该能比较顺畅地跑到跟你交互的第一句话。
很多人第一次听说本地跑大模型，第一反应是这事跟普通人有关系吗？老实说，我开始也是这么想的。直到我下决心在自己电脑上跑通一次 Ollama，才发现把一个大模型装进本地环境，已经在不知不觉中变得很像装一个普通应用——下载、安装、执行，三句话能说清楚。特意写这篇，是想把我从环境准备到模型跑通的完整过程拆开来讲，让还没试过的朋友少走弯路。这篇文章适合谁？手头有一台配置还行的 Windows、macOS 或 Linux 电脑，想体验在本地跑大模型，但不想一上来就碰复杂的训练、微调流程的人。或者你是做开发、写脚本的，想把一个大模型当成一个本地服务来调用，这篇文章同样能帮你把底子打好。我会从设计思路上讲清楚为什么选 Ollama，再给一套可以直接照抄的安装、配置、验证流程，最后把常见的坑挨个列出来。1. Ollama 解决了什么问题，为什么值得本地部署1.1 本地部署和在线 API 之间的本质区别在详细讲安装之前，得先聊清楚一个核心问题：为什么要在本地跑模型。很多人习惯了直接打开网页对话框，或者注册各种在线 API 来调用大模型，这两种方式各有各的好处，但本地部署解决的恰好是在线方案做不到的几件事。首先是数据隐私。本地部署的整个过程完全发生在你自己的设备里，输入什么、输出什么，不需要经过任何外部服务。对医疗记录、合同条款、未公开代码这类敏感内容来说，这一点非常重要。在很多实际项目里，数据根本不允许离开本机网络，本地推理就成了唯一选择。其次是成本。在线 API 通常按 token 计费，日常简单用用可能没什么感觉，一旦批量处理文本，费用就会以肉眼可见的速度涨。本地部署只需要一次性付硬件成本，后续跑多久都不产生额外费用。对个人开发者或者小团队来讲，本地推理在长期批量任务上有很明显的经济优势。第三是稳定性。本地服务不依赖外部网络状态，不依赖别人的服务器是否可用，也不存在某个热门模型突然调整访问策略导致你服务中断的问题。只要机器开着，服务就在。1.2 Ollama 在设计上的几个关键取舍市面上能让大模型在本地跑起来的工具其实不少，但我最后长期使用的是 Ollama，原因是它在设计上做了几个非常符合实际使用习惯的取舍。最直观的一点是命令行极简。对一个用户来说，第一步只需要一条安装命令，之后拉取模型、运行模型、查看模型列表，都是几个单词的事，学习成本低到几乎可以忽略。项目本身内置了模型下载和版本管理，不需要手动去各个模型仓库找权重文件，也不需要自己处理模型格式转换。它把服务端和客户端做成了同一套体系。命令行工具负责发起请求，后台服务负责加载模型、处理推理。这意味着你不但能在终端里交互式聊天，还能直接向本地服务发 HTTP 请求，把它当成一个 API 服务来用。很多后续的二次开发、自动化脚本，都可以直接基于这个服务来做，不需要引入额外框架。它内置了针对不同硬件环境的优化。你在安装时不需要做复杂的编译配置，它会自动检测当前机器的硬件情况，选择合适的计算路径来跑推理。对普通用户来说，省掉这些配置时间，体验完全不一样。2. 部署前的必读清单：环境评估与版本选择2.1 硬件与系统要求Ollama 官方对操作系统的支持范围覆盖了 macOS、Windows 和主流的 Linux 发行版。如果用的是 Windows，建议使用 64 位的 Windows 10 或更新版本，旧系统有时会遇到缺少新版运行库的问题。macOS 方面，建议使用较新版本的系统，因为旧系统可能会因为缺少系统组件而无法启动服务。Linux 端则没有什么特殊限制，主流发行版都可以。硬件方面很多人以为必须有一张昂贵的独立显卡，其实不是。模型能不能跑起来，核心看内存和磁盘空间。纯 CPU 推理是可行的，代价只是速度慢。我在没有独显的笔记本上实测过，跑一个参数量在 7B 左右的量化模型，处理简单的中英文对话完全可用，只是生成速度不如带独显的机器流畅。内存方面，不同的模型差别很大。一个 7B 参数的量化模型，在加载进内存后大概会占用 5GB 到 6GB 左右的空间，所以整机 8GB 内存是个起点。如果是 13B 参数模型，内存占用通常超过 10GB，建议整机内存至少 16GB。选模型之前先查清楚自己有多少可用内存，这能帮你避免运行到一半进程被杀掉的尴尬。磁盘空间同样重要。模型文件很大，7B 模型量化后常见体积在 4GB 到 5GB 之间，13B 模型普遍在 8GB 以上。安装完 Ollama 程序本身只占很小的空间，大头全在模型文件上。给数据盘留出至少 20GB 的余量是一个比较稳健的做法。2.2 安装包版本与分发渠道安装 Ollama 时的版本来源需要特别注意。我个人的建议是只从官方发布渠道获取安装包。第三方整合包虽然偶尔会附带一些模型或者一键脚本，但来源不明，安全上不可控，而且一旦出问题很难排查。官方渠道针对不同系统提供了对应的安装形式：macOS 可以直接下载安装包，Windows 下载安装程序，Linux 则有打包好的安装包和直接解压的二进制文件。有人可能更喜欢用包管理器来安装，这也是可行的，但要注意不同包管理器里的版本未必同步更新，可能出现命令行提示版本过旧的情况。更新版本这件事常常被忽略。Ollama 的更新频率不低，新版通常会修复旧版本的崩溃问题、优化推理速度、增加新的模型支持。不过我的建议是：不要在大模型跑到一半、或者有重要工作正在进行时随手升级。选一个空闲的时间窗口，升级完成后先跑一次冒烟测试，确认服务能正常起来，再继续使用。2.3 先想清楚模型存放位置这是很多人一开始没注意，后来不得不返工的问题。Ollama 默认把模型文件存放在系统盘的用户目录下，Windows 上默认在用户的 .ollama 文件夹里，macOS 和 Linux 也类似。问题在于，很多人的系统盘本来就不宽裕，而模型文件动辄几 GB、十几 GB，很快会把 C 盘塞满。最稳妥的做法是在安装完成后、拉取任何模型之前，先规划好模型的存放位置。如果打算把模型放在独立的机械硬盘、第二块 SSD 或者其他数据目录里，提前用环境变量把模型路径指过去，可以避免后面搬运数据带来的麻烦。这一步设计得好，后面长期使用会很省心。3. 三平台安装实操：从下载到跑通第一个模型3.1 macOS 安装步骤macOS 上的安装有两种常见路径。第一种是直接下载官方安装包，双击安装，然后把应用拖进应用程序目录。安装完成后，打开终端执行ollama --version，如果能看到版本号，说明安装成功。第二种是通过包管理器安装，在终端里执行包管理器提供的安装命令，比如常见的brew install ollama。两条路都能用，主要看个人习惯。如果你选择官方安装包，可能会遇到一个情况：打开时被系统拦截，提示来源不明。这不是程序有问题，而是系统的安全策略。你需要打开系统设置，找到隐私与安全性相关选项，允许该应用运行。处理完之后再打开一次就正常了。安装完成后，在终端输入ollama run 模型名，系统会自动开始拉取模型，拉取完成后会直接进入交互对话界面。第一次运行会等待模型下载，耗时取决于模型大小和网络状况。这个过程中终端会显示进度条。3.2 Windows 安装步骤Windows 端的安装流程相对直观。从官方渠道下载安装程序，常见的文件名是 OllamaSetup.exe。运行安装程序后，一路确认默认选项即可，安装过程中不需要设置额外的参数。装完以后系统可能会出现一个托盘图标，不用管它，这表示后台服务已经在运行了。安装完成后重启一次终端窗口，这一点很多人会忽略。安装程序虽然会写入环境变量，但是已经打开的终端窗口不会自动刷新环境变量，直接在新终端里执行ollama --version验证。如果提示找不到命令，先确认当前终端窗口是否是在安装完成之后新开的。Windows 上有个值得留意的细节：安装完成后，默认模型目录会落在系统盘用户目录下。如果你的 C 盘空间紧张，建议在安装之前或者刚装完还没拉模型时，先去设置一个环境变量OLLAMA_MODELS，把模型目录指到其他盘符，一劳永逸。3.3 Linux 安装步骤Linux 端安装方式比较多样，我个人的偏好是使用官方提供的自动安装脚本。在终端里执行脚本命令后，脚本会自动下载对应系统的安装包并完成安装。这种方式对新手最友好，不需要自己处理发行版差异。如果你更想手动控制，也可以去官方发布页面手动下载安装包。下载 deb 或 rpm 格式的安装包，然后用系统对应的包管理器命令安装，比如 Debian 系可以使用 dpkg 或 apt 来安装，RHEL 系可以使用 rpm 或 yum。手动安装的好处是版本完全可控，并且卸载时更清晰。另一种方式是直接下载二进制压缩包，解压后把主程序放到 /usr/local/bin 或者你自己的可执行路径下。这种方式的优点是干净，不依赖系统包管理器的状态，缺点是后续更新需要自己重新下载覆盖。Linux 上安装完成之后，还需要考虑服务运行方式。最省心的做法是让系统服务管理器接管 Ollama 进程，这样重启机器之后它会自动启动。用官方脚本安装的版本一般会自动配置好服务。如果用的是手动解压方式，可以自己创建一个服务文件，也可以简单地在启动脚本里写上ollama serve，开机自启即可。3.4 安装之后的必要检查程序装上之后，不要急着去拉模型。先做三个检查，能帮你后面省很多事。第一个检查安装是否可用。执行ollama --version，能输出版本号即可。第二个检查服务是否运行。执行ollama list，如果服务正常运行，会输出一个空列表或者已有的模型列表。如果提示无法连接，说明服务还没起来，Windows 上检查托盘图标，Linux 上检查服务状态，macOS 上用进程查看命令确认进程是否在。第三个检查端口监听。Ollama 服务默认监听本机的 11434 端口，如果你系统里有其他程序占用了这个端口，后续运行模型会失败。可以用系统自带的方式查看端口占用情况，确认 11434 没有被占用。4. 模型下载与本地运行的核心操作4.1 拉取模型前先搞清楚标签Ollama 里的模型通过标签来区分不同版本。同一个模型会有多个标签：不同参数量的，比如 7B、13B、30B；不同量化格式的，比如常见的一些带有精度标识的格式，还有常见的 q4、q8 这类量化档位。标签的选择直接影响两个东西：一个是模型的体积，一个是输出质量。量化位数越低，文件越小，内存占用越少，但输出质量的损失也越明显；量化位数越高，文件越大，内存占用越多，输出质量越接近原始模型。对大多日常对话场景，默认下发的量化版本是个不错的平衡点，体积和速度都合适，质量也基本够用。我见过有人强制拉了一个满精度的版本，结果一张普通显卡根本塞不下，内存吃紧，最后还得重新换。拉取模型的命令很简单，格式是ollama pull 模型名:标签。ollama run 模型名:标签其实会自动完成拉取，如果本地没有这个模型，它会先下载再进入对话。所以很多人的第一个模型其实是靠 run 拉下来的，不需要单独 pull。4.2 用命令行与模型交互当模型第一次下载完成后，终端会直接进入交互模式，你可以像聊天一样输入问题，模型实时生成回答。这个模式是快速验证模型效果最直接的方式。交互模式里有一些内置命令需要知道：退出对话是/bye；查看当前模型配置可以用/set，比如设置上下文长度、系统提示词之类。这些命令都以斜杠开头，和聊天的正文区分开。我建议刚上手的人先试一次/set，把默认参数过一遍，再决定要不要调整。除了交互模式，更常用的是把命令作为参数直接运行。比如写脚本的时候，可以用一条命令让模型处理单次输入，执行完就退出，非常适合批量任务。命令行工具的输出结果可以被脚本捕获，变量提取、文本处理都不成问题。4.3 模型存储目录的迁移与软链接方案如果你已经发现系统盘满了，或者一开始没规划好模型目录，就面临迁移问题。迁移时机越早越好，但已经下载了模型也能迁，只是步骤多几步。整体思路是：先停止正在运行的服务，然后把整个模型目录移动到新位置，再修改环境变量OLLAMA_MODELS指向新目录，最后重新启动服务。具体操作上，Windows 是在系统设置里修改用户环境变量，macOS 和 Linux 则是在 shell 配置文件中设置导出语句，或者直接在服务管理配置里写入环境变量。这里有一个容易踩的坑：如果模型文件体积大，移动过程中千万不要中断。我建议先复制过去，确认新目录里的文件数量和老目录一致，再把老目录改名保留而不是直接删除。等到服务能正常从新目录加载模型了，再删除旧目录。这个过程虽然保守了一些，但不会出现迁移到一半发现新位置缺文件的情况。还有一种组件方式是使用软链接。如果你不打算改服务配置，可以把默认目录里的模型文件保持不变，在默认位置创建一个软链接，指向实际存放模型的外部路径。这样做的好处是对程序透明，缺点是一旦弄错链接，服务可能不认。我的建议是直接改环境变量，语义更清晰，排查也容易。5. 实战中常见的坑与排除方法5.1 端口被占用之后怎么办Ollama 默认服务端口是 11434。有时这个端口会被别的程序占用，结果是命令行能正常执行，但任何需要访问后台服务的操作都会报错，错误信息通常比较模糊，只说无法连接。排查方式不复杂：先看 11434 端口上目前是谁在监听。如果你发现确实有别的程序占用了这个端口，有两个选择：关掉占用程序，或者给 Ollama 换端口。换端口的方式是设置OLLAMA_HOST环境变量，改成新的监听地址和端口。需要注意，改完之后服务必须重启，环境变量才会生效。5.2 模型下载卡住或速度很慢模型下载是很多人第一次使用时会遇到的问题。进度条长时间不动，或者下载到一半提示失败，确实很折磨人。这个问题并不神秘，大模型文件体积都是 GB 级别，质量再好的网络也需要一定时间。如果频繁失败，先别怀疑工具本身。检查一下磁盘空间，模型下载是边下边写，空间不足会导致下载过程突然终止。再检查网络稳定性，有时候是网络环境波动导致连接断开，服务端的下载机制会自动重试，但重试太频繁会让人感觉卡在某个百分比。另一个思路是换个更小的模型。同一个模型家族的量化版本之间体积差别很大，选择一个文件体积更小的版本，下载时间会明显缩短。对于一些只做简单测试的场景，先用小模型验证流程没问题了，再决定要不要下载大模型，这是一个很实用的策略。5.3 内存不足导致进程被杀模型运行到一半进程突然消失，最常见的原因是内存不够。大模型推理时不仅要把模型权重加载进内存，还要留出上下文计算的临时空间，所以实际内存占用通常会超过模型文件本身的体积。遇到这个问题，第一选择是换小模型。如果必须用当前模型，可以调整并发请求数量，限制同一时间处理的任务数。Ollama 提供了一个环境变量OLLAMA_NUM_PARALLEL，把它显式设为 1，让系统同一时间只处理一个请求，这样可以把内存峰值压到最低。同时关闭浏览器里大量占内存的标签页也能腾出不少空间。Windows 上还可以通过调整虚拟内存大小来缓解，但虚拟内存本质上是磁盘充当内存，速度会慢很多，只能拿来应急，不能当长期方案。5.4 卸载不干净的问题如果你已经试过跑某个模型，决定暂时不用 Ollama，或者换一台机器重新部署，卸载这件事也需要处理干净。很多人的印象里，卸载程序删掉就行，但实际上 Ollama 会把模型目录、配置文件和后台服务散落在不同位置，手动删不干净会导致以后重装时出现各种奇怪的冲突。Windows 上推荐用系统自带的卸载程序来卸载主程序，然后进入默认模型目录把所有内容删除，同时把环境变量里与 Ollama 相关的项目清理干净。macOS 和 Linux 类似，除了删除二进制文件之外，还要检查模型默认目录、配置文件、服务管理文件，全部手动清理一次。判断是否清理干净有一个简单粗暴的标准：卸载后重启系统，再执行一次ollama --version，如果系统提示找不到命令，说明主程序已经清理干净了。6. 部署之后还能怎么玩模型跑通之后，整个本地环境就算正式可用了。我的一个常用玩法是把它当成一个本地后台服务，写一些自动化脚本来调用。比如批量整理文档、批量处理文本摘要、统一改写一批文案。只要把文本内容和提示词组装好，用脚本向本地服务的接口发请求，就能在无人值守的情况下跑完整个批次。这种方法不依赖公网服务，跑多少都免费，数据也完全在自己手里。还有一个比较实用的思路：如果机器资源有限，平时只跑一个小模型满足日常问答，遇到复杂任务时再临时切换到更大模型。Ollama 可以同时管理多个模型，切换时不用反复安装卸载，只是换一个命令的问题。这样既能保证大部分场景的响应速度，又能在需要的时候提供更强的生成能力。我个人在实际操作中的体会是：本地部署这件事，真正的门槛从来不在安装这一步，而在于你是否愿意先花十几分钟把环境规划好。提前想清楚模型放哪、内存够不够、遇到端口冲突怎么处理，往往能避免后面一连串的折腾。如果你正准备在自己电脑上跑一个本地模型，按这篇的顺序走一遍，应该能比较顺畅地跑到跟你交互的第一句话。