ollama 本地运行大模型 llm 完全指南

多半人是这样卡住的：听说 Ollama 一行命令就能在本地跑模型，装完敲了拉取命令，要么下载慢到放弃，要么跑起来风扇狂转、回复慢得没法用，再往下想接到自己的脚本里又不知道从哪下手。这篇按装、配、跑、调、接的顺序把整条路讲一遍，每个环节给判断标准和一个能马上做的动作，参数和价格这类会变的数字都指到站内页面现查，不写死。

多半人是这样卡住的：听说 Ollama 一行命令就能在本地跑模型，装完敲了拉取命令，要么下载慢到放弃，要么跑起来风扇狂转、回复慢得没法用，再往下想接到自己的脚本里又不知道从哪下手。其实整条路就那么几段，卡住的地方来来回回也就那几个。

这篇按装、配、跑、调、接的顺序把整条路讲一遍，每个环节给一个判断标准加一个能马上做的动作。模型版本、参数量档位、价格这类会变的数字，一律不写死，指到站内对应页面现查，你按自己当时看到的数字做决定。

先分清 Ollama 帮你做了什么

Ollama 是本地模型的运行与托管工具，负责下载权重、管显存、起一个本地 HTTP 服务，它不负责模型本身的能力。换句话说，它解决的是「怎么把权重跑起来、怎么让别的程序调它」，模型聪不聪明、中文顺不顺，是权重的事，跟这个工具没关系。

它代你做的事

下载与缓存权重、按机器情况加载、起本地接口、管理已装模型列表

它不管的事

模型能力、输出质量、许可能不能商用、你的业务逻辑

跟直接跑权重的差别

省掉环境依赖和加载代码，代价是参数可调空间小

什么时候该换路

要做线上多人并发、要精细控制显存切分和批处理

判断不适用的场景很明确：看重吞吐或并发，或者需要把显存切分、批处理大小这些参数捏在手里，这条路就不合适，应该转向专门的推理框架。这不是好坏问题，是场景问题，别硬掰。

装完先验证，别急着拉大模型

安装分桌面版和命令行两种形态，按系统选。装完最忌讳的就是直接拉一个大模型，然后不知道是下载慢、加载失败还是服务根本没起。正确顺序是先让服务活过来，再用一个很小的模型走通一遍。

1. 确认服务在跑装完后查看进程或服务状态，确认监听端口已经起来；命令行直接问一次版本或列表，有回应说明服务活着。
2. 用小模型跑通问答挑一个体量最小的模型拉下来，问一句简单的话。观察三段：下载有没有完成、加载有没有报错、生成有没有出字。三段全绿再往下。
3. 排掉三个常见卡点服务没起、端口被别的程序占了、装在另一台机器上却按本机地址调用。这三项排除掉，再怀疑模型本身。

如果你发现拉取动作本身一直失败，先别怀疑自己的机器。到 /ai-status 看当时各类 AI 服务的可用状态，能帮你区分「是你本地的问题」还是「上游本来就抖」——这个区分很省时间，免得你反复重装。

选哪个模型、拉多大档位

选型分两层：先按任务定能力档，再按机器定参数档。顺序不能反。很多人是反过来做的，先看榜单挑一个最强的，拉下来发现自己机器根本跑不动，白折腾一轮。

• 先明确任务：是问答、写代码、做摘要，还是做结构化抽取，不同任务对模型的要求差很远
• 同一模型常有多个体积档位，档位越小越省显存也越快，但复杂推理和长文稳定性掉得快
• 别按「跑分最高的那个」直接拉，榜单测的任务和你手上的活往往不是一回事
• 先在站内模型库里挑两三个候选，各自拉最小可用档位试同一个真实任务，再决定留哪个

榜单的参考口径到 /benchmarks 看，模型资料到 /models 查。站内的数字是跟着时间更新的，你自己去核对当时的排名和评测项，比记住别人转述的一句话靠谱。

判断不适用的边界要说清：如果任务本身是长文档、多步推理或大量结构化输出，小档位基本没戏，别在这上面耗时间，要么换更小的模型族但接受质量下降，要么回去想办法升级硬件。

显存、内存和量化档位怎么对

决定能不能跑起来的是显存加系统内存的总盘子。权重、上下文缓存、运行时开销都要占位，很多人只算了权重那一块，跑起来才发现差一点。量化档位本质是显存和质量的交换：档位越低越省，但低到一定程度会出现答非所问、输出格式崩坏这类问题。

拿你机器上的卡去 /models/deploy 做一次部署测算，比凭感觉猜准得多；加速卡的规格在 /compute/gpus 核对。这两个页面是配套用的：一个告诉你这张卡能跑到什么程度，一个告诉你这张卡的底子。

动作建议：按测算结果先选一个留有余量的档位，跑通之后再往上加。这个顺序比先冲大模型再往下退省事，因为你至少有一个能用的基线，退的时候知道退到哪。

判断不适用：机器是集成显卡或显存很小的情况，别在大模型上纠缠，直接选更小的模型族，把期望值调整到「能跑通、能做简单活」就行，硬撑只会浪费时间。

第一次跑起来之后调什么

第一次跑通之后，先别急着改参数。你需要一个基线：同一个提示词、同一个模型，记录两件事——第一次出字要等多久，整段生成完花多久。后面所有调整都跟这个基线比，不然你根本不知道改动有没有用。

• 影响体感最大的通常是上下文长度：给得越长，占用越高、首字越慢
• 其次是输出长度，回答啰嗦本身就是慢的来源
• 随机性相关的参数决定输出是稳定还是发散，按任务选，别乱调
• 其余参数保持默认，一次只改一个，改完再跟基线比

想先量出你这台机器的延迟基线，用 /tools/speed-test，这样「是机器慢还是设置不对」就能分开。分不开这两个原因，调参就是瞎调。

判断不适用：如果你只是偶尔问一两个问题，调参收益很低，直接用默认设置更省心。调参这件事的投入产出比，跟你的使用频率强相关。

怎么从代码和工具里调用

本地服务起来后会监听一个本机地址，脚本、客户端、桌面工具都按这个地址连。连不上的第一件事是查地址和端口，不是查代码。接口大概分两类：一类是工具原生的接口，另一类是兼容常见云端接口格式的入口，后者能让现成的 SDK 少改代码，迁移成本低不少。

# 先用命令行确认通路，再写代码
curl http://本机地址:端口/api/tags
# 有返回说明服务和模型列表都正常，再去接 Python 或客户端

配置项里最容易漏的是环境变量：监听地址、模型存放路径这类变量改错了，表现就是「服务起了但外部连不上」或者「模型找不到」。这两个症状长得像，但原因完全不同，先看日志确认是哪一个。

1. 命令行打通用最简单的请求问一次话，确认服务、网络、模型三样都对。
2. 接脚本换成本机地址调用，先发一个最小请求，别一上来就塞完整业务逻辑。
3. 接客户端工具在工具的设置里填本机地址，保存后发一条消息验证，不通就回头查地址和端口。

模型文件和数据放哪、许可怎么看

模型文件默认落在一个固定目录，多盘机器上要提前改路径，否则系统盘很容易被撑满。这是个可以提前花五分钟避免的问题，等到满了再迁就要动手搬几十个文件。

动作很简单：拉模型之前先确认目标盘剩余空间够不够放下你所有候选模型，再决定要不要迁移目录。许可边界要单独看——权重能下载不等于能商用、能改名分发，具体条款以模型自带声明为准，站内 /safety 有合规侧的对照可以一起看。

判断不适用：公司内网环境要按内部规定走，别拿公开说明当结论。这是最容易出事的一块，宁可多问一轮。

建议把模型目录和许可结论一起记在项目文档里，换机器和对外交付的时候能省一轮返工。这件事没有技术难度，纯粹是习惯问题。

出问题按这个顺序排

下载慢、拉不下来这类问题，换镜像源、错峰、手动导入文件都能绕，别反复重试同一招。同一招试过两次没变化，就换思路，重复试只是消耗耐心。