本地部署大模型ollama

你搜「本地部署大模型ollama」，多半是想先在自己电脑上把模型跑起来，结果卡在第一步：装是装上了，命令敲下去没反应，或者跑起来慢得像幻灯片，不知道是配置问题还是模型选大了。这篇不讲概念史，只给你一条从准备到验证的路径，以及跑不动时的排查顺序。

你搜「本地部署大模型ollama」，多半不是想听概念，而是想赶紧在自己电脑上把模型跑起来，结果卡在第一步：程序装上了，命令敲下去没反应，或者跑起来慢得像幻灯片，分不清是机器不行还是模型选大了。这篇不讲历史不讲原理，只给一条从准备到验证的路径，外加跑不动时的排查顺序。你照着走一遍，至少能知道问题出在哪一层。

先说清一个前提：本地跑模型不是装个软件就完事，它更像开一个常驻的小服务，吃的是内存、显存和磁盘三样东西。这三样里哪一项先到顶，就决定了你能跑多大的模型。所以顺序是：先看机器底子，再动手装，装完立刻验证，验证不过按固定顺序往下查。跳步的结果就是装完不知道下一步干什么。

装之前先确认三件事

第一件看机器底子。内存、显卡显存、可用磁盘空间三项，缺一项都会卡住。具体某个参数量、某个量化档位需要多少资源，别凭感觉估，到 /models/deploy 按参数量和量化档位算一遍，再对着 /compute/gpus 看自己那张卡落在哪一档。算出来是刚好够还是有富余，直接决定你首跑挑多大的模型。

第二件看用途。只是试试问答、写点小脚本，还是想接进项目当接口用，这两类对速度的要求差很远。前者偶尔等几秒无所谓，后者要提前想清楚并发和常驻内存。场景怎么划分，参考 /local-llm-deploy-basics 里的说法，别拿试玩的心态去做常驻服务。

第三件看是不是压根不该本地跑。纯办公本、没独显、内存紧张，或者公司机器不允许装外部程序，这些情况下本地部署不是「慢一点」，而是根本跑不起来。这时候更现实的做法是先用 /official-api 里按量计费的接口顶上，把流程跑通，等有合适机器再迁回本地。

安装到跑通一条命令的顺序

1. 确认程序本身能响应按官方渠道装完后，先在终端敲版本查询命令。只要能打印出版本信息，就说明程序装好了、环境变量没毛病。这一步不过关，后面全是白费，先回去看安装步骤。
2. 拉一个小模型做首跑别一上来挑大的。选参数量小、量化档位低的模型拉下来，目的是先确认整条链路是通的，不是先看效果好不好。拉的时候留意下载速度，太慢就换网络或换时段。
3. 观察首跑的三种表现一看模型能不能正常加载，二看首次回答的等待时间，三看回答是否完整不截断。三项都正常，才算这条链路跑通；只是「有输出」还不算。
4. 记下命令和文件位置把跑通的命令和模型名记在便签里，顺手确认模型文件落在哪个目录、占了多少磁盘。后面换模型、清旧文件时，这份记录能省你不少时间。

这四步里最容易跳过的是第四步。很多人跑通就关终端，过几天想换模型，发现磁盘被旧模型占满，又得从头查文件在哪。花一分钟记下来，比事后排查划算。

怎么算「验证通过」，怎么留基线

验证不看回答聪不聪明，看的是稳定性：能稳定出结果、连续问几轮不崩、关掉再开还能用同一个模型复现。这三条都过，才算你这台机器真的把它跑起来了。只跑通一次、换个提示词就掉线，那不叫通过。

接着留一个基线。用一条固定提示词跑一遍，记下从敲回车到出第一个字的时间，以及整段输出的时长。这就是你这台机器的起点，之后换模型、调参数都跟它比，不用凭「感觉变快了」下结论。如果模型同时提供接口服务，可以到 /tools/speed-test 量一下本机延迟，把本地基线和线上接口的延迟放一起看，方便判断哪些活适合放本地、哪些放线上更省事。

跑不动时的排查顺序

跑不动别乱试，按下面这个顺序往下走，每一步都能排掉一类原因。顺序跳着来，很容易在错误的方向上耗半天。

• 第一步查资源：显存和内存占用是不是打满了。打满就先降模型规模或量化档位，档位怎么选看 /quantization-tier-choice，别硬扛。
• 第二步查驱动与运行环境：显卡驱动、运行时版本不匹配，常见表现是程序能起但用不到显卡，全靠 CPU 硬扛，速度自然上不去。
• 第三步查模型文件：拉取不完整、存放目录权限不对，会导致加载失败或反复重下。把不完整的文件清掉重来，比反复重试快。
• 第四步才怀疑模型本身：换一个更小的模型做同样的操作。小的能跑、大的不能，基本可以确定是配置撑不住，不是程序坏了。

走到第四步你会发现，大部分「跑不动」其实落在前两步：资源不够或环境没对。模型本身出问题的概率反而低。所以排查时别先怀疑模型，先看自己的机器和驱动。

本地部署的第一目标不是跑得大，而是跑得稳；先跑通最小档，再往上加。