Ollama本地部署大模型完整实战指南：安装配置到代码调用

为什么需要本地部署大模型

在实际开发中，我们此前调用的大多是第三方厂商提供的模型服务（如OpenAI、DeepSeek等），所有请求都走公有云。但当你进入企业后会发现一个现实问题：很多数据涉及隐私与合规，不方便直接上传到公有云。

数据合规问题在企业AI应用中日益突出。以中国为例，《数据安全法》和《个人信息保护法》对数据跨境传输和第三方处理提出了严格要求；欧盟的GDPR同样对数据处理的地理位置和方式有明确约束。金融、医疗、政务等行业通常有更严格的数据分级保护制度，核心业务数据甚至不允许离开内网。在这种背景下，将大模型部署在企业自有服务器或私有云上，数据全程不出内网，成为满足合规要求的最直接方案。

这时候，把大模型部署到本地就成了刚需。

本地部署需要一个"载体"或"容器"来承载和运行模型，而 Ollama 就是这个角色。用一句话概括：Ollama 就是大模型版的 Docker。

Docker 的核心是三个概念——镜像、仓库、实例。同样地，Ollama 也遵循了类似的设计思路：一份模型（镜像）可以运行出多个实例。Docker是容器化技术的事实标准，其核心理念是通过镜像（Image）封装应用及其依赖，通过容器（Container）实现隔离运行，通过仓库（Registry）实现分发共享。Ollama借鉴了这套完整的生命周期管理思路：模型文件对应镜像，运行中的模型实例对应容器，Ollama Hub对应Docker Hub。这种类比不仅降低了学习成本，更重要的是它引入了版本管理、实例隔离、资源调度等工程化能力，让模型管理从手动拷贝文件的原始状态，进化到了标准化的工具链管理。这种"借鉴成熟框架思想"的做法，正是 Ollama 能快速被开发者接受的原因。

Ollama命令设计的底层逻辑

任何一个工具的命令设计，往往不是凭空创造，而是借鉴以前成熟框架的思想。原因很简单：工具造出来是要有人用的，而推广的关键是简单、方便、符合使用习惯。当一个新工具的用法跟你以前熟悉的东西高度一致，你才愿意去用。

Ollama 正是如此——它的命令与 Docker 几乎一一对应：

DockerHub 玩镜像 → OllamaHub 玩模型
docker run → ollama run
docker pull → ollama pull

只要你会用 Docker，学 Ollama 几乎没有陌生感。

Ollama的羊驼标识

Ollama的架构定位：把一对多变成一对一

在企业级 AI 系统中，通常会用 LangChain 作为业务系统与大模型之间的"胶水框架"。LangChain是目前最流行的大模型应用开发框架之一，由Harrison Chase于2022年创建。它的核心价值在于提供了一套标准化的抽象层，将提示词管理、模型调用、输出解析、链式编排、记忆管理、RAG（检索增强生成）等常见模式封装为统一接口。通过这套抽象，开发者可以用几乎相同的代码逻辑切换不同的底层模型供应商，极大降低了供应商锁定风险。LangChain目前支持Python和JavaScript两种语言，社区生态活跃，已成为企业构建AI应用的主流选择。

理想的架构是：各种业务系统统一通过 LangChain 对接模型，尽量把"一对多"变成"一对一"。

但问题在于，LangChain 若直接对接 N 个大模型供应商，依然是一对多的复杂关系。这时候 Ollama 的价值就体现出来了——把所有大模型都装进 Ollama 这个中介框架里，于是：

LangChain → Ollama（一对一）→ N 个本地模型

Ollama 就像 Docker 上背着一大堆实例的引擎，LangChain 只需找它一个入口，就能触达多个模型。

模型参数与硬件的权衡

下载模型前需要理解一个关键单位：B（Billion，十亿）。例如 7B 就代表 70 亿参数。

参数越大 → 模型效果越精确
参数越大 → 对硬盘空间和带宽要求越高

模型参数量直接决定了推理时所需的计算资源。以常见的FP16（半精度浮点）格式为例，每个参数占2字节，因此7B模型至少需要约14GB显存才能完整加载到GPU中。为了在消费级硬件上运行大模型，社区发展出了量化技术（如GGUF格式的Q4、Q8量化），通过降低每个参数的精度位数来压缩模型体积和显存占用，代价是一定程度的精度损失。例如，7B模型经过4-bit量化后，体积可从14GB压缩到约4GB，使得在8GB显存的普通显卡上也能流畅运行。Ollama内置了对GGUF量化格式的支持，这也是它能在个人电脑上运行大模型的关键技术基础。

对于个人学习或本地测试，建议使用较小的模型（如 1B、2.5B、3.5B），既能跑通流程，又不至于因为下载七八个 G 的大模型而卡在网络上。学习阶段的重点是掌握流程，而非追求满血版模型。

安装Ollama的关键：一定不要装到C盘

这是本文最需要强调的实战细节。Ollama 默认会把所有内容安装到 C 盘，模型文件动辄几个 G，C 盘分分钟就满了。因此必须自定义安装路径。

在指定路径打开命令行窗口

自定义安装路径的完整步骤

第一步：自定义安装目录

先在非 C 盘（如 D 盘、E 盘）建立一个目录，把下载好的 OllamaSetup.exe 放进去。

第二步：用命令行指定安装路径

在该目录下打开 CMD 黑窗口，执行安装命令，指定安装到你的自定义路径，而不是默认的 C 盘。

第三步：配置环境变量

创建大模型的存储目录，并配置环境变量 OLLAMA_MODELS，其 Value 填写你本地的存储路径（建议与安装路径保持一致）。

环境变量是操作系统级别的全局配置机制，程序在启动时会读取相关环境变量来确定运行参数。OLLAMA_MODELS这个环境变量告诉Ollama进程去哪个磁盘路径存取模型文件。在Windows上，可通过"系统属性→高级→环境变量"来设置系统级环境变量，设置后需要重启Ollama服务才能生效。类似地，Ollama还支持OLLAMA_HOST（指定监听地址和端口）、OLLAMA_NUM_PARALLEL（并行请求数）等环境变量，这种通过环境变量进行配置的模式在服务端软件中非常常见，也便于在Docker容器或CI/CD流水线中进行自动化配置。

第四步：迁移已有模型文件

停掉 Ollama 服务
找到 C 盘用户目录下的 .ollama 文件夹
全部复制到新创建的存储目录
删掉 C 盘下的 models 文件夹

这样处理后，Ollama 就无法再往 C 盘下载模型了。最后重启，执行 ollama list 查看是否正常显示，能正常运行即代表配置成功。

磁盘分区建议：至少分三个盘——C 系统盘、D 工作盘、E 资料备份盘。若目前只有一个 C 盘，可暂时装在 C 盘，后续用分区软件从 C 盘分出独立分区。

Ollama常用命令实战

Ollama 的命令与 Docker 一脉相承，掌握起来非常快：

# 列出本地已下载的模型
ollama list

# 运行模型（本地有则直接运行，没有则远程拉取）
ollama run qwen2.5

# 拉取模型到本地
ollama pull llama3

# 查看当前活动的模型实例
ollama ps

# 删除模型
ollama rm <模型名>

建议的操作习惯是先 pull 拉取，再 run 运行，当然两步并作一步也可以。

模型完全运行在本地

配置成功后，即使断开外网，本地模型也能独立跑起来。比如询问"2+3"，模型会直接在本地给出结果——这就是本地私域模型的核心价值。

验证Ollama是否启动成功

这里涉及一个跨平台的基本功。在 Linux 下，查看后台进程和端口占用用：

ps -ef | grep 11434

但大多数同学本地开发用的是 Windows，命令完全不同：

netstat -ano | findstr 11434

11434 是 Ollama 的默认端口。如果这个端口正在被监听，就说明 Ollama 成功启动了。

端口监听检查是运维和开发中的基础操作。Linux系统中，除了ps命令外，还常用lsof -i :11434或ss -tlnp | grep 11434来查看端口占用情况。Windows系统中netstat -ano会显示所有网络连接和对应的进程PID，通过findstr过滤特定端口后，可以进一步用tasklist /fi "pid eq <PID>"确认是哪个程序在监听。在macOS上，命令则是lsof -i :11434。掌握这些跨平台的等价命令，不仅在排查Ollama启动问题时有用，更是日常后端开发中诊断端口冲突、服务异常等问题的必备技能。

掌握基础命令是面试基本功

这类命令看似琐碎，却是工作和面试中的高频考点。面试时被问到"说出五个常用 Linux 命令"或"说出五个常见 Python 异常"，如果答不上来，说明基本功还需打磨。这些正是日常开发中天天要用的东西。

用LangChain对接本地Ollama模型

打通本地部署后，最后一步是让代码调用本地模型。安装方式延续了熟悉的模式：

# 此前对接 OpenAI
pip install langchain-openai

# 此前对接 DeepSeek
pip install langchain-deepseek

# 现在对接 Ollama
pip install langchain-ollama

这就是 LangChain 与 Ollama 的官方合作包。理解了这个规律你会发现：无论对接哪家模型，套路都是一致的。LangChain通过其Provider机制，为每个模型供应商提供独立的集成包，包内实现了统一的ChatModel或LLM接口。这意味着你的业务代码只依赖抽象接口，切换底层模型时只需更换Provider包和配置参数，核心逻辑无需改动——这正是面向接口编程在AI应用开发中的体现。

在代码中，把请求地址指向 http://localhost:11434（Ollama 默认端口），调用本机部署的 qwen2.5 模型即可打出效果。

本地与外网调用的一致性

一个重要认知：如果你本地能调通，那么这个程序一定也能调外网调通。二者只是端点地址的差异。这意味着你在本地部署的私域模型开发经验，可以无缝迁移到调用云端模型的场景。从技术角度看，无论是本地Ollama还是云端API，底层都遵循相同的HTTP协议和类OpenAI的接口规范。Ollama本身就暴露了与OpenAI API兼容的/v1/chat/completions端点，因此许多原本为OpenAI编写的客户端代码，只需将base_url改为http://localhost:11434/v1，即可直接对接本地模型，无需任何代码改动。

总结

Ollama 本地部署的核心逻辑，本质上是"大模型版 Docker"的思路复用。掌握它并不难，关键要抓住几个要点：

理解 Ollama 作为模型容器的定位，配合 LangChain 实现"一对一"的清爽架构；
安装时务必自定义路径，坚决不要装 C 盘；
熟练掌握 ollama list / run / pull / ps 等命令，以及跨平台的端口检查方法；
通过 langchain-ollama 包实现代码调用，本地与云端调用逻辑一致。

本地部署大模型是进入企业做 AI 开发的必备技能。照着流程动手做一遍，你就能拥有一个完全离线运行的私域模型。值得一提的是，Ollama并非本地部署的唯一选择——vLLM专注于高吞吐量的生产级推理，LocalAI提供了更广泛的模型格式兼容性，llama.cpp则是底层C++推理引擎。但Ollama凭借其极简的使用体验和Docker式的管理范式，成为了个人开发者和中小团队入门本地部署的最佳起点。