这篇文章我写了一个多月，从最初只是想在自己的电脑上跑一个能用的对话模型开始，到后来接了公司一个“文档校对不能出内网”的活儿，前前后后把三种主流本地部署方案都试了一遍。踩了不少坑，也积累了一些实战经验。这篇把整个过程完整记录下来，从零基础到进阶，按方案讲清楚怎么做，以及为什么这样做。看完你会发现，本地跑AI大模型这件事，没有想象中那么神秘。
1. 动手之前先想明白：硬件门槛与模型选型
1.1 一张表看懂跑大模型的最低配置要求
很多人一听到“AI大模型”，第一反应就是“没有十万块显卡跑不了”。这个认知在我真正实践之前也是这样，但跑起来之后发现完全不是一回事。本地部署AI大模型的硬件门槛，核心看两个东西：内存（或者显存）容量能装下多大的模型文件，以及算力能不能在可接受的时间内给出回复。
先给一张我实测过的配置对照表，覆盖大多数普通用户和开发者的机器：
| 配置情况 | 可以流畅运行的模型范围 | 实际体感 |
|---|---|---|
| 16GB内存，无独立显卡 | 7B参数 + Q4量化 | 能跑，速度偏慢，大约每秒几到十几个token |
| 16GB内存 + 8GB显存 | 7B~13B + Q4/Q5量化 | 7B很流畅，13B可以接受 |
| 32GB内存 + 12GB~16GB显存 | 13B~32B + 量化 | 13B毫无压力，32B需要低量化 |
| 64GB内存 + 24GB以上显存 | 70B量化模型 | CPU和GPU混合可跑，速度慢但能用 |
这里的“7B”“13B”指的是模型的参数数量，B是英文Billion（十亿）的缩写。7B就是70亿参数，13B是130亿参数。参数越多，模型理论上越聪明，但需要的存储和计算资源也越大。
我自己主力机器是一台32GB内存加一张12GB显存显卡的Windows电脑，这个配置基本是本地部署的“甜点位”：既能跑舒服7B和13B级别的模型，又不至于需要专门配一台服务器。
1.2 模型参数、显存与内存的换算逻辑，不用死记公式
刚开始接触本地部署时最懵的，就是别人说“需要多少G显存”时完全没概念。后来摸清楚了一个很简单的换算逻辑，想明白之后选配置心里就有底了。
以7B模型为例，如果模型权重用FP16（即每个数字占2字节）存储，那么权重文件大小大概是：70亿参数 x 2字节，约等于14GB。这在一台普通电脑上跑起来很吃力，因为除了模型文件本身，运行时还需要额外的缓存空间来保存“推理过程中间结果”（专业术语叫KV Cache），这部分又要吃掉2到4GB。
所以就有了量化（Quantization）这个东西。量化简单说就是把模型里每个数字从2字节压缩到更小，比如Q4量化后每个数字只占约0.5字节。同样一个7B模型，量化后权重文件只有4GB左右，这样8GB显存就能轻松装下，CPU也能勉强跑动。
实际选型时，不需要死记公式，记住这个经验值就行：
- 7B模型量化后约4~5GB，适合8GB显存或16GB内存的设备
- 13B模型量化后约8~10GB，适合12GB以上显存或32GB内存的设备
- 32B模型量化后约20GB上下，基本要32GB以上内存或24GB以上显存
1.3 量化等级是什么，Q4和Q8怎么选
量化等级这个概念，第一次看到GGUF、Q4_K_M、Q5_K_M、Q8_0这类名词时完全一头雾水。用个生活化的类比：
想象一张高清照片，原始文件是几十MB的RAW格式。你可以把它压缩成高质量JPEG（相当于Q8，画质接近原图），也可以压缩成普通JPEG（相当于Q5），或者压成小尺寸的模糊图（相当于Q2）。压缩比例越大，文件越小，画质损失越多。
模型的道理完全一样。Q4就是4bit量化，Q8是8bit量化。Q8保留的精度更高，但文件体积几乎是Q4的两倍；Q4体积小、速度快，但能力会有小幅下降。
对于绝大多数本地部署场景，我的选择很固定：无脑选Q4_K_M。这个等级是社区里公认的“性价比之王”，体积和速度优势明显，能力损失基本在可接受范围内。Q8适合显存充足（或纯追求回复质量）的情况。量化等级直接影响模型文件大小和推理速度，这是选模型时最先要确定的一件事。
2. 方案一：Ollama + Open WebUI，配置最少的上手路线
2.1 装Ollama：三分钟跑起第一个本地对话
我试过的三种方案里，Ollama是上手最快、最适合零基础入门的。它把模型下载、加载、调用做了一个非常统一的管理，要装的东西只有一个，后续所有模型都用命令行一条命令搞定。
安装过程没有任何值得犹豫的地方：到Ollama官网下载对应系统的安装包，Windows用户直接双击安装，Mac和Linux也都有对应版本。装完之后打开终端（Windows下是CMD或PowerShell），输入：
ollama --version能输出版本号就说明装好了。我最初装的时候没看任何教程，到这里大概花了不到两分钟。
接下来拉取模型。以目前本地部署圈子里最热门的Qwen2.5系列为例，先拉一个7B的：
ollama pull qwen2.5:7b这条命令会自动从模型源下载模型文件到本地。7B模型文件大概4.7GB，取决于网速要等几分钟到几十分钟。如果你内存比较紧张，可以换成更小的：
ollama pull qwen2.5:3b下载完成后，直接对话：
ollama run qwen2.5:7b出现一个命令行对话界面，这时候你就已经在本地跑起来一个大模型了。
2.2 模型文件放哪最合适：改环境变量防C盘爆满
这个坑我踩得最痛。默认情况下，Ollama会把所有模型文件下载到C盘的用户目录下。最初我在Windows上拉了一个7B模型还没什么感觉，后来为了测试下载了3个模型，C盘瞬间掉了二十多G，最后系统直接弹“磁盘空间不足”警告，赶紧把模型全删了换盘符。
正确做法是在安装完成后、拉取模型之前，先修改模型存储路径。Windows下的操作是：
- 打开“设置” -> “系统” -> “高级系统设置” -> “环境变量”
- 在“用户变量”下新建一个变量
- 变量名填
OLLAMA_MODELS - 变量值填你希望存模型的位置，比如
D:\ollama_models
修改完之后，需要让配置生效：
- Windows右下角托盘找到Ollama图标，先退出再重新打开
- Linux执行
systemctl restart ollama
生效后再执行ollama pull，模型文件就会下载到D盘了。如果已经下载了模型再改环境变量，记得把旧目录下models文件夹里的文件复制到新目录，否则重新识别不到已有的模型。
Ollama的模型管理命令不多，高频用到就这几个：
| 命令 | 作用 |
|---|---|
ollama list | 查看已下载的模型 |
ollama rm 模型名 | 删除指定模型 |
ollama run 模型名 | 直接对话 |
ollama pull 模型名 | 下载模型 |
2.3 Open WebUI：给Ollama加个浏览器版聊天界面
命令行对话适合自己测试，但真要给同事用、或者日常频繁使用，一个可视化界面会顺手很多。Open WebUI是目前最主流的Ollama前端，也是我测试下来最推荐的。
安装方式有两种。最简单的是用Docker启动一个容器，命令行直接执行：
docker run -d -p 3000:8080 --add-host=host.docker.internal:host-gateway -v open-webui:/app/backend/data --name open-webui --restart always ghcr.io/open-webui/open-webui:main这里稍微解释一下为什么要加--add-host=host.docker.internal:host-gateway。Open WebUI运行在容器里，它要访问宿主机上运行的Ollama服务（地址是localhost:11434或127.0.0.1:11434），但容器内部访问不到宿主的localhost。这个参数把host.docker.internal这个特殊域名指向宿主机，Open WebUI就能通过这个地址连上Ollama了。
没有Docker也可以直接用Python安装：
pip install open-webui open-webui serve建议用Python 3.11以上版本。第一次启动后，浏览器访问http://localhost:3000，注册一个账号（账号密码保存在本地数据库，不用联网）。进入主界面后在模型列表里选择已经下载好的模型，就可以像ChatGPT一样在网页里和本地模型对话了。
2.4 验证离线可用：断开网络跑一遍全流程
既然目标是“离线部署”，装完之后必须做的一件事就是验证断网能不能用。我的实测经验是：
Ollama本身一旦模型下载完成，完全离线可以正常对话，这是确定无疑的。因为模型文件都在本地，推理过程不需要联网。Open WebUI也一样，前端资源打包在本地镜像里，第一次打开注册账号后，断网刷新页面依然能正常使用。
不过有个细节：如果你需要在完全没有网络的物理隔离环境使用，建议先在联网环境下把模型拉取好、把Open WebUI完整跑通一遍。这样后续拷贝到离线环境时，目录结构已经完整，避免因为缺文件导致启动失败。
Ollama方案的整体评价：安装包一键搞定，命令极简单，API兼容性好，对显卡和CPU自适应能力强。零基础用户首选，开发者也够用。
3. 方案二：LM Studio，纯图形化操作的省心路线
3.1 下载与安装：和装普通软件没有任何区别
第二种方案严格来说不是传统意义的“部署”，因为它从头到尾都是图形界面。如果你完全不想碰命令行，或者要给一个不懂技术的同事用，LM Studio是我最推荐的。
去官网下载安装包，安装过程跟装微信、QQ一模一样，没有任何需要设置的选项。装完打开，就是一个干净清爽的图形界面。它底层实际上是调用了llama.cpp的推理引擎（后面第三种方案会讲），但对用户的封装做得非常好。
3.2 模型下载与加载：全程鼠标点击
LM Studio的模型下载逻辑设计得很友好。左侧边栏有一个放大镜图标，点进去就是模型搜索页。在搜索框里输入“Qwen2.5-7B-Instruct GGUF”，会列出所有相关模型文件。点击下载，它就开始拉了，进度条显示得很清楚。
如果搜索不到或者速度不理想，可以手动从HuggingFace或者ModelScope魔搭社区把GGUF格式的模型文件下载下来，然后通过LM Studio的“打开模型文件”功能直接加载。它支持的文件格式是GGUF，这也是它和Ollama都能跑的通用格式。
下载完成后，回到左侧模型栏，点击要使用的模型，右侧会显示模型详细信息，包括量化等级、文件大小。选择对应的量化版本，点一下“Load Model”（加载模型），下面就可以直接对话了。
这里有一个LM Studio做得特别好的功能：在加载模型时，可以把“GPU Offload”（GPU卸载）滑块拖到某个层数，设置模型有多少层交给显卡计算。如果你显卡只有8GB显存，跑7B模型时可以把层数调到8到12层左右，其他层让CPU计算，既能利用显卡加速，又不会爆显存。这个参数Ollama里默认自动最优，但LM Studio给了手动控制的自由度。
3.3 本地API服务：给别的软件提供接口
LM Studio不只是个聊天界面，它也内置了一个和Ollama兼容的本地API服务。点击界面上方的开发者（Developer）标签，在“Local Server”区域点击“Start Server”，端口默认是1234。
启动之后，其他软件可以通过标准API接口访问你本地的模型，比如：
curl http://localhost:1234/v1/chat/completions -H "Content-Type: application/json" -d '{"model":"qwen2.5-7b","messages":[{"role":"user","content":"你好"}],"stream":false}'这意味着你可以在一个内部工具、脚本或者自建应用里，用标准的HTTP请求调用本地模型，而不需要用户去点击LM Studio界面。我实际做离线文档校对脚本时，就是通过这个API把一段文本发给模型，然后拿到校对结果。曲线很直接，事半功倍。
LM Studio方案的整体评价：零命令行、界面友好、手动控制参数灵活。缺点是它本身是一个桌面GUI程序，不适合作为后台服务长期运行，更适合单机使用或给同事做演示。
4. 方案三：llama.cpp手动部署，进阶玩家的掌控感
4.1 编译还是直接下载release包
第三种方案，也是所有方案的基础——llama.cpp。Ollama和LM Studio的底层推理引擎本质上都是源自这个开源项目，只不过它们做了更高层的封装。之所以还专门讲llama.cpp，是因为它是可控性最强、最透明的方式，适合想要深入理解原理、或者有特殊性能需求的开发者。
第一步是获取llama.cpp。两条路：
- 直接下载官网GitHub仓库releases里的预编译包。Windows下解压就能用，里面有
llama-cli.exe和llama-server.exe等可执行文件。这是最稳妥的方式。 - 自己编译源码，适合想要开启特定指令集加速（比如AVX512、AMX）或者查问题的人。
自己编译的流程也不复杂，以Windows为例，需要先装好支持C++的开发环境，然后在项目根目录执行：
git clone https://github.com/ggml-org/llama.cpp.git cd llama.cpp cmake -B build -DGGML_CUDA=ON cmake --build build --config Release -j这里-DGGML_CUDA=ON是开启NVIDIA显卡加速的关键开关。如果没有这个开关，编译出来的版本只用CPU跑，速度会慢很多。很多在llama.cpp上踩坑的人，都是编译时没开CUDA，结果发现跑得极慢，还以为是模型问题。
4.2 GGUF模型文件的手工准备
llama.cpp能运行的模型格式是GGUF，和前面LM Studio用的格式一致。获取方式有两种：
第一种是直接下载现成的GGUF文件。到HuggingFace或者ModelScope搜“Qwen2.5-7B-Instruct-GGUF”，里面通常会有多个量化版本，下载qwen2.5-7b-instruct-q4_k_m.gguf这个就够用了（前面的Q4_K_M就是我们推崇的性价比之王）。下载后放到llama.cpp项目的models目录下。
第二种是从原始模型权重转换。如果你从其他渠道拿到了一个safetensors格式的模型（比如某个微调模型），就需要先转换。llama.cpp提供了一个转换脚本：
python convert_hf_to_gguf.py /path/to/model -o /output/path/model.gguf --outfile-type q8_0这个转换过程会读取原模型权重，重新保存为GGUF格式。注意转换脚本依赖Python环境，所以在这一步，会用到Python和Git基础（热词里搜索量很高的Python安装教程、Git安装配置教程，到了这一步就派上用场了）。
4.3 命令行的日常使用与server模式，配合内部工具
模型文件就位后，llama.cpp的使用方式分两种场景。
场景一：快速对话测试，直接在终端执行：
./build/bin/llama-cli -m models/qwen2.5-7b-instruct-q4_k_m.gguf -p "你好，介绍一下你自己" -n 256-m指定模型路径，-p是提示词，-n是生成的最大token数。这种方式适合快速验证模型能否正常运行。
场景二：和Ollama类似的本地服务模式，用于给其他程序调用：
./build/bin/llama-server -m models/qwen2.5-7b-instruct-q4_k_m.gguf --host 0.0.0.0 --port 8080启动后，这个服务默认绑定了8080端口，并且API接口格式和Ollama、LM Studio保持兼容，也就是说，你之前写的调用Ollama的代码，只需要改一下接口地址，就能直接切换到llama.cpp上。
比如我的离线校对脚本，最开始用Ollama，测试没问题后，生产环境改用了llama.cpp的server模式，代码端只需要把请求地址http://localhost:11434替换成http://localhost:8080，其他都不用改。
4.4 GPU加速开启检查：怎么看模型到底用没用显卡
这个问题是我在帮好几个朋友排查时发现的通病：部署完之后，问一句“我GPU加速开成功了吗”，得到的回答往往是“不知道啊，反正能出结果”。
这里给一个很简单的检查方法。llama-server启动时，日志里会打印类似这样的信息：
ggml_cuda_init: found 1 CUDA devices如果看到这行，说明CUDA已经正常初始化。运行一个推理请求后，同时打开任务管理器（Windows）或者执行nvidia-smi，看里边的显存占用。如果在推理过程中显存占用从几百MB涨到了几GB，说明模型确实加载到了显卡上。如果显存全程只有几百MB，那就说明模型还跑在CPU上，你需要回头检查编译参数或者加载参数。
llama.cpp方案的整体评价：可控性最强、启动最快、对硬件的利用效率最高，但需要用户具备一定动手能力。适合开发者、进阶玩家，或者需要把模型作为后台服务长期跑的生产环境。
5. 三种方案实测对比：性能、门槛与适用人群
5.1 一份真实对比数据
三种方案我都跑了相同的模型（Qwen2.5-7B-Instruct Q4_K_M），在同一台机器上做了实测对比：
| 对比维度 | Ollama + Open WebUI | LM Studio | llama.cpp |
|---|---|---|---|
| 安装复杂度 | 极低，一条命令 | 极低，图形安装 | 较高，需编译或下载release包 |
| 界面体验 | 网页版，支持多轮对话、模型切换 | 桌面GUI，依赖本地窗口 | 命令行或裸API，无前端 |
| 首次启动模型速度 | 快（约1~2秒） | 略慢（加载时有进度条） | 快（约1秒） |
| 是否适合长期后台服务 | 适合，Windows/Linux均可 | 不适合，需开着界面 | 最适合，可注册为系统服务 |
| 手动控制GPU层数 | 自动，不开放手动调节 | 支持手动调节GPU Offload | 支持参数细粒度控制 |
| 模型文件通用性 | 只认Ollama目录格式 | 可直接加载GGUF | 直接用GGUF |
| 对非技术用户友好度 | 有Web UI后较高 | 最高 | 低 |
实际推理速度方面，三种方案在同样的模型和量化等级下基本一致，因为底层都是同一个推理内核。差距主要来自前端调用和内存占用的细微差别，日常使用很难感知到。
5.2 我给你的选择建议
如果一个朋友让我推荐方案，我会先反问三个问题：
第一，你只是想在自己电脑上体验一下本地大模型，还是要把这个能力做成内部工具给别人用？
第二，你愿不愿意用命令行？
第三，这个模型是要单机跑，还是要做成一个始终在线的服务？
基于我自己的使用经验，推荐逻辑是这样的：
纯体验、零技术基础选LM Studio。下载安装、下载模型、加载聊天，全程鼠标点完，没有环境变量、没有网络端口、没有命令行，零门槛中的零门槛。
日常开发测试、个人长期使用选Ollama + Open WebUI。命令行操作简洁，API和Open WebUI配合也好，跑通之后体验非常接近在线ChatGPT，同时完全离线。
生产环境、服务化部署、API集成选llama.cpp。启动快、负载低、可控性最强，可以做成Windows服务或Linux systemd服务，长期稳定不折腾。
6. 整个部署过程我踩过的坑，不希望你重蹈覆辙
6.1 硬盘空间被模型文件吃干
文章前面提过，Ollama默认把模型放在C盘用户目录下，这是我踩过的第一个大坑。教训就一句话：装好之后第一件事，把模型目录改到数据盘。
而且不光Ollama有这个坑，llama.cpp和LM Studio同样存在类似问题。llama.cpp的模型文件默认放在项目目录下，如果你把项目放在了C盘，模型下载多了同样是个负担。LM Studio的模型也有默认下载路径，在设置里可以改。
推荐做法是给磁盘分区留至少50GB以上可用空间，专门存放模型文件。一般建议把所有模型统一放到一个目录，比如D:\AI_Models，这样管理和清理都方便。
6.2 回复很慢或直接OOM（内存耗尽）
16GB内存跑7B Q4模型是可以跑的，但如果你同时打开了浏览器二三十个标签、微信、IDE、文档软件，内存很可能会爆。Windows的解决办法是加大虚拟内存：右键“此电脑” -> “属性” -> “高级系统设置” -> “性能设置” -> “高级” -> “虚拟内存”，把C盘或D盘的虚拟内存设成自动管理或手动设为32GB以上。Linux下则是检查swap分区大小。
物理内存确实不够时，优先换更小的模型（从7B换成3B），或者降低量化等级（从Q8降到Q4）。别硬扛。
6.3 下载模型文件时网络经常断流
这个坑在中英文模型源之间切换时体会最深。直接从某些海外源拉取几个GB的模型文件，中途断线或者速度掉到几十KB是家常便饭。
我的解决办法是两种：
- 优先使用ModelScope魔搭社区下载GGUF文件，国内服务器速度快且稳定，上面也有Qwen、Llama等主流模型的GGUF版本
- HuggingFace官方源如果太慢，可以把HuggingFace的下载代理前缀配置为
https://hf-mirror.com，实测速度快好几个量级
模型下载下来后，本地的部署和推理是纯离线的，所以网络问题只在模型准备阶段存在，不影响的离线部署本身。
6.4 模型幻觉导致校对结果不可用
最后这个是使用层面的坑，但比前面所有技术坑都致命。大模型在无人监督的情况下会“一本正经地胡说八道”，学术上叫幻觉。做离线文档校对、合同审核这类严肃应用时，模型可能会在原文没有错误的地方“改”出一个错误，或者凭空补充不存在的内容。
这个问题没有一劳永逸的解决办法，但有几个有效的缓解手段：
- 降低温度参数（temperature）到0.1或0，让模型尽量不要自由发挥
- 在提示词里明确要求“只做修改，不做补充”，“没有把握处保持原文”
- 用更强的基础模型（比如用13B替代7B，用指令优化模型替代基础模型）
- 最终结果必须有人工复核环节，尤其涉及合同、公文的场景
我在做文档校对工具时，就是前两条加第四条组合使用，准确率才达到可以交付的程度。这条经验也提醒大家：本地部署跑通只是开始，真正落地到业务里，还要花时间在应用层做约束和校验。
6.5 Windows路径和客户端工具的小坑
还有个容易忽略的小问题：模型文件路径中不要出现中文和空格。我在一台Windows电脑上把模型放到了D:\我的模型\目录，llama.cpp直接找不到文件。改成英文路径后一切正常。这个现象在大部分开源工具里普遍存在，不只是llama.cpp，建议所有涉及AI的工具链都使用纯英文路径，少给自己添堵。
最后分享一件小事。之前一个完全不熟悉技术的同事，我用LM Studio给他装好之后，他自己下载了一个模型，玩了一个下午，还总结出一个心得：同一个模型用不同的提问方式，回复质量差别很大。这说明本地部署的门槛已经被这些工具压得很低了。三套方案，对应三种不同层级的用户需求：想要省心体验的，用LM Studio；想要长期自用和快速开发的，用Ollama加Web UI；想要最大化掌控性能的，直接上llama.cpp。核心是明确自己的需求，然后选对方案。我现在的日常做法是：自己开发测试用Ollama，给同事演示用LM Studio，公司内部服务用llama.cpp的server模式通过API接入业务系统。几套方案并存，各司其职。你也完全可以从一套方案开始，跑起来第一个对话，再根据体感逐步调整。
