早上打开终端敲下ollama run，看着自己机器上跑起来的模型一个字一个字往外吐，那种感觉很实在——断网也能用，数据不出本地，调试的时候不用心疼 token 账单。这篇内容聊的就是使用 Ollama 部署本地大模型这一整套流程，从硬件怎么算账、装完怎么调、模型怎么挑、Modelfile 怎么捏、接口怎么接，一直到跑不动了怎么排查。它面向的是想在自己电脑或内网服务器上把大模型跑起来的开发者、运维、以及做垂直场景应用的人。如果你是纯小白，跟着走也能出结果；如果你已经跑过几次但总觉得速度不理想、输出不听话、前端接不上，那后半部分的调优和踩坑记录应该更对胃口。

本地部署这件事，到 2026 年已经不算新鲜，但真正落地时会发现坑比想象的多。网上大部分内容停在“装好、跑通、截个图”，而真实项目里你会遇到显存刚好差 1G、上下文一拉长就卡死、模型答非所问、接口调用超时没人管这类问题。下面这些内容都是我反复在不同机器、不同场景下试出来的，参数和步骤可以直接抄，但每一步为什么这么做，我会讲清楚。

1. Ollama 到底帮你省掉了哪些活

1.1 从拿到权重到真正能用，中间隔着六件事

很多人以为本地跑大模型就是“下载一个文件然后运行”，实际从原始权重到能对外提供接口，中间至少有六件事要处理。第一是权重的格式转换，原始发布的权重通常是高精度浮点格式，体积大、加载慢，需要转成适合本地推理的格式；第二是量化，把精度压下来换体积和速度；第三是推理引擎的编译和依赖，涉及显卡驱动、加速库版本、编译参数；第四是显存分配与卸载策略，哪些层放显卡、哪些放内存；第五是对话模板拼接，不同模型的角色标记格式完全不一样，拼错了模型就会答非所问；第六是接口封装，要让它能被别的程序调用。

这六件事单拎出来都不难，难的是它们的版本互相咬合。显卡驱动升一级，加速库要跟着升；加速库升了，推理引擎的编译参数可能要改；改完发现某个模型的对话模板在新版本里解析不出来了。我最早自己搭这套东西的时候，光是把环境调到能跑，前后花了两个周末。

Ollama 的价值就在于把这六件事收进了一个二进制文件里。模型仓库那一条命令就完成下载和格式校验，量化和显存分层它自己判断，对话模板写在模型的配置里自动套用，接口是开箱即用的 HTTP 服务。你付出的代价是灵活性——它不让你细粒度地控制每一层放在哪张卡上，也不支持一些激进的并行策略。但对九成以上的场景来说，这个取舍是划算的。

1.2 三类适合上车的场景，和两类我劝你别碰的

先说适合的。第一类是内网或离线环境，数据不能出局域网，模型必须跑在自己控制的机器上，这类场景没得选，本地部署是唯一路径。第二类是高频调用的开发调试，比如你在做一个基于大模型的应用，一天要跑几千次请求调试提示词，走云端接口既有成本也有速率限制，本地跑一个 7B 或 14B 的模型做快速验证非常舒服。第三类是批量离线任务，比如几千份文档的结构化抽取，一次性跑完就不管了，本地跑不用担心调用配额，也不用担心长文本被截断。

再说两类我劝你别硬上的。第一类是追求顶尖效果，本地能跑的模型规格和云端旗舰模型之间仍然有明显差距，如果你要的是最强的推理和写作质量，本地部署会让你失望。第二类是低配机器硬撑大模型，8G 内存的老笔记本跑 32B 模型，等一个回答要几分钟，体验极差，不如老老实实用小规格模型或者干脆走云端。

提示：判断要不要本地部署，先问自己一个问题——这个任务里，数据敏感性和调用频次哪一个才是主要矛盾。前者决定必须本地，后者决定本地更省钱，两者都不成立的话，就别折腾了。

2. 硬件与模型的账，先算明白再下载

2.1 显存和内存的估算公式，附三个具体算例

这一步是新手最容易翻车的地方——看到一个模型名字里写着 32B，兴冲冲下载，结果加载失败。模型能不能跑起来，取决于三项占用：权重体积 + 上下文缓存 + 计算缓冲。

权重体积的估算很直接：参数量乘以每个权重占用的比特数，再除以 8 换成字节。以 4.5 bit 左右的常用量化等级为例，7B 模型大约是 4.1 GB，14B 约 8.5 GB，32B 约 19 GB，70B 约 40 GB。这里的关键是量化等级，后面单独讲。

上下文缓存（KV Cache）是最容易被忽略的变量。它的大小与层数、注意力头数、缓存精度和上下文长度成正比。给一个粗略的工程估算方式：7B 级别的模型，在 8K 上下文、缓存用 8 bit 的情况下，大约需要 1 GB；上下文拉到 32K，这个数字就变成 4 GB 左右。上下文长度是线性增长的，很多人调大上下文之后爆显存，原因就在这里。

计算缓冲通常在 0.5 到 2 GB 之间，取决于批大小和显卡架构。

三个算例看得更清楚：

从表里能看出来，选模型不是看参数量，而是看“权重 + 缓存 + 缓冲”这条总和能不能塞进你的显存。显存塞得下就全放显卡，速度飞快；塞不下就会有一部分层被放到内存里，速度会掉一个数量级。所以 24 GB 显存的卡跑 32B 模型配 4K 上下文很流畅，但配 32K 上下文就开始吃力，配 128K 上下文基本没法用。

注意：很多教程只告诉你“24G 能跑 32B”，但不说上下文长度。同一张卡，4K 上下文和 32K 上下文的速度差距可能有三倍。部署前一定要按你的实际上下文需求去算，而不是按默认值算。

2.2 量化等级怎么挑，为什么 Q4 是默认答案

量化是把权重从高精度压到低位宽的过程，位数越低体积越小、速度越快，但精度损失越大。常见的档位从 Q2 到 Q8，中间还有 K 系列的各种变体。我的经验是这样：

• Q8 及以上：几乎无损，但体积是 Q4 的两倍多，除了做效果对照实验，日常没必要。
• Q6：质量损失极小，体积比 Q4 大约 40%，显存宽裕时可以选。
• Q4_K_M：性价比最高的默认选择。K 表示分块量化，M 表示中等混合精度，关键层保精度、次要层压缩。绝大多数场景下和原始模型的输出差异肉眼难辨。
• Q3 及以下：体积诱人，但复杂推理、代码生成这类任务会明显退化，中文长句也容易出问题。只在显存实在紧张时作为妥协。

有一个反直觉的点：小模型对量化更敏感。7B 模型降到 Q3，能力掉得比 32B 模型降到 Q3 明显得多。因为小模型本身冗余就少，压缩空间有限。所以如果你的机器只能跑 Q3，与其把 14B 压到 Q3，不如老老实实跑 7B 的 Q4 或者 Q5。

2.3 按机器配置反推模型规格

反过来看更实用——手里有什么机器，就该选什么规格。这张表是我按经验整理的，上下文统一按 8K 计算：

纯 CPU 跑模型这件事值得单独说一句。很多人以为没显卡就没戏，其实不然。大内存的服务器用 CPU 跑 32B 的 Q4 模型，每秒出三到五个字，做批量离线任务完全够用——反正你也不需要盯着屏幕看它打字。这类场景的瓶颈不在单次响应速度，而在总吞吐，所以把并发调低、上下文调小，反而整体效率更高。

3. 安装与环境变量：五分钟装完，半小时调对

3.1 三个平台的安装路径差异

安装本身没什么技术含量，但有个细节会影响后面所有操作：服务是怎么启动的。这决定了你改环境变量的方式。

Linux 上一般用一键脚本安装，装完会注册成一个系统服务，用系统服务管理器拉起。这意味着你在 shell 里 export 的环境变量对服务无效，必须写进服务的配置文件里。macOS 上是一个应用包，图形界面启动，环境变量要用系统级的设置命令，写在 shell 配置文件里同样不生效。Windows 上是安装程序，装完托盘里有个图标，环境变量走系统设置面板，改完要重启应用。

这个差异看着琐碎，但它是新手最常卡住的地方——“我明明设了环境变量，怎么不生效”，九成是因为设错了位置。判断方法很简单：用服务方式启动的，改服务配置；用应用方式启动的，改系统环境变量或者应用自己的配置。

# Linux：通过服务配置注入环境变量 sudo systemctl edit ollama.service # 在打开的编辑器里加入： # [Service] # Environment="OLLAMA_HOST=0.0.0.0:11434" # Environment="OLLAMA_MODELS=/data/models" sudo systemctl daemon-reload sudo systemctl restart ollama

# macOS：图形应用需要系统级环境变量 launchctl setenv OLLAMA_MODELS /Volumes/Data/models # 设置后需要退出并重新打开应用

3.2 六个必须知道的启动参数

环境变量有不少，但真正影响日常使用的就六个，我按重要性排序。

第一个是模型目录。默认位置在用户主目录下，模型动辄几个 G，很快就把系统盘塞满。装完第一件事就该把它挪到大容量磁盘上，用OLLAMA_MODELS指定。注意这个目录必须存在且有写权限，否则服务会起不来。

第二个是监听地址。默认只监听本机回环地址，也就是只有本机能访问。如果你想让局域网里其他机器用，需要设成对外地址。这里要提醒一句：改成对外监听之后，任何能访问这个端口的人都能调用你的模型，内网环境还好，如果机器直接暴露在公网，务必加上访问控制。

第三个是并发数。默认值比较保守，一次只能处理一个请求，第二个请求会排队。如果你的卡显存有余量，把它调到 2 或 4，能显著提升多用户场景下的吞吐。但要注意，并发数增加会让显存占用成倍增长，因为每个并发请求都有自己的上下文缓存。

第四个是同时加载的模型数。默认一次只保留一个模型在显存里，切换模型时要重新加载，大模型加载要十几秒。如果你经常在几个模型之间来回切，把这个值调到 2，代价是显存占用翻倍。

第五个是模型驻留时间。默认五分钟无请求就卸载模型。做开发调试时这个设定很烦人，刚加载完去改了两行代码，回来又得等重新加载。调成半小时或者更长会舒服很多；反过来，如果是多模型共享一张卡，就把它调短一点，避免模型互相挤占。

第六个是注意力加速开关。支持的话打开它，长上下文场景下显存占用和速度都有改善，配合缓存精度设置一起用效果更好。老显卡可能不支持，打开后如果加载报错就关掉。

3.3 把模型目录挪到大盘的完整操作

这一步值得单独写，因为顺序错了会丢模型。正确顺序是：先停服务，再创建目标目录，再设置环境变量，再启动服务，最后验证。如果先设变量后停服务，重启时可能出现目录冲突；如果目标目录没建好就设变量，服务会直接启动失败。

挪完之后用ollama list验证一下，如果列表是空的，说明新目录没生效，或者旧模型没搬过去。旧目录里的文件可以直接移动过去，注意保持目录结构一致。

4. 拉模型、跑模型、管模型

4.1 日常五个命令的实际用法

命令不多，但每个都有几个细节值得说。

拉取命令负责下载，注意它既是下载也是更新，同名模型再拉一次会检查是否有新版本。下载过程中断了会续传，不用从头再来。模型名后面跟的标签就是版本标识，不写标签默认拿最新版——这里有个隐患，最新版可能是刚推上去的，效果未必好，生产环境建议用固定的版本标签。

运行命令会自动拉取并启动对话，退出对话界面后模型仍然在内存里驻留一段时间。第一次运行会做一次加载，之后同样参数的启动会快很多。

列表命令不光列名字，还会显示体积和修改时间，体积那一列可以用来核对量化等级是否符合预期。

进程命令显示当前加载在内存里的模型、占用的显存、以及驻留剩余时间。这个命令在排查“为什么显存被占了但没请求”时非常好用。

删除命令只删模型，不删你的其他数据。但要注意，如果模型被某个自定义配置引用着，删掉之后那个配置就跑不起来了。

ollama pull 模型名:版本标签 # 拉取或更新 ollama run 模型名 # 启动对话 ollama list # 查看已有模型 ollama ps # 查看运行中的模型与显存占用 ollama rm 模型名 # 删除模型 ollama show 模型名 # 查看模型参数与模板

最后那个查看命令容易被忽略，但它非常有用。它会显示模型的上下文长度上限、参数量、量化方式、对话模板。当你怀疑“是不是上下文被截断了”或者“是不是模板不匹配”的时候，先看这个输出。

4.2 对话界面里的临时参数调整

进到对话界面之后，可以通过斜杠命令临时调整参数，这些调整只对当前会话有效，退出就恢复默认。常用的几个：

/set parameter后面跟参数名和值，可以临时改采样温度、上下文长度、生成上限。/show info查看当前模型的详细信息，/show parameters看当前生效的参数值。/clear清空对话上下文重新开始——这个命令在测试提示词时用得最多，因为上下文会一直累积，不清空的话后面的测试会受到前面内容的干扰。

还有一个/bye退出。这里提醒一下：直接按 Ctrl+C 也能退出，但有时候会残留会话，用/bye更干净。

4.3 离线导入本地权重文件的完整流程

企业环境经常拿不到网络，或者模型是自己微调过的，需要手动导入。流程分三步。

第一步，准备一个权重文件和一份配置文件。配置文件的语法很简单，第一行指定权重文件路径，后面可以跟系统提示词和参数。

第二步，执行创建命令，指定新模型的名字和配置文件路径。这一步会做格式校验和元数据解析，如果权重文件损坏或者格式不兼容，这里就会报错。

第三步，运行验证。

# Modelfile 示例 FROM ./你的模型文件.gguf # 上下文长度 PARAMETER num_ctx 8192 # 采样温度 PARAMETER temperature 0.7 SYSTEM """ 你是一个严谨的技术助手，回答简洁，不编造事实。 """

ollama create my-model -f ./Modelfile ollama run my-model

有个细节要注意：FROM后面跟相对路径时，基准目录是执行命令时的工作目录，不是配置文件所在目录。我在别的机器上复现别人配置时踩过这个坑，报错提示找不到文件，改绝对路径就好了。另外权重文件的格式必须匹配，不同格式的权重混着用会直接失败。

5. 用 Modelfile 把通用模型捏成专用助手

5.1 五个指令的语义与生效顺序

Modelfile 的语法不复杂，但要知道各指令的优先级，否则会出现“我明明写了提示词，怎么没生效”的情况。

FROM是基础，指定从哪个模型继承。可以是仓库里的模型名，也可以是本地权重文件路径。这一行必须有。

SYSTEM是系统提示词，定义模型的角色和行为边界。它被拼在每次对话的最前面。注意这里是“每次”，意味着它会占用上下文额度，写太长会挤掉真正的对话内容。

TEMPLATE是对话模板，定义用户消息、助手消息、系统消息怎么拼接成模型认识的格式。这一行是坑最多的地方。大多数时候不用自己写，从基础模型继承就行。但如果你用的是一个自定义微调的权重文件，它可能没有携带模板信息，这时候就必须手写，写错了模型会胡言乱语。判断方法：导入后先问一个简单问题，如果回答完全不搭边或者格式错乱，八成是模板问题。

PARAMETER定义推理参数，可以写多行。它会覆盖基础模型的默认值。

MESSAGE用来预置对话示例，也就是少样本提示，让模型学习输出格式。写两三个示例比写一大段规则描述管用得多，这一点后面细说。

优先级上，配置文件里的PARAMETER覆盖基础模型的默认值，运行时命令行传入的参数又覆盖配置文件，对话界面里的/set再覆盖上一层。记住这个链，调参时就不会混乱。

5.2 两个实操案例：结构化抽取与代码助手

案例一：把自由文本抽成固定结构的 JSON。

这类需求在企业里特别多。直接在提示词里写“请输出 JSON”，模型经常会加一句“好的，以下是结果”，导致解析失败。稳妥的做法是三层叠加。

第一层在系统提示词里明确角色和约束，说清楚“只输出 JSON，不要任何解释文字”。第二层用PARAMETER把采样温度压到很低，减少随机性。第三层，也是最关键的一层，加两三个MESSAGE示例，一个用户输入配一个标准输出。示例的力量远大于规则描述，实测下来加了示例之后格式合规率能从七成提到九成五以上。

FROM 某个7B通用模型:q4 PARAMETER temperature 0.1 PARAMETER top_p 0.8 PARAMETER num_ctx 8192 SYSTEM """ 你是信息抽取引擎。用户给一段文本，你输出一个 JSON 对象。 只输出 JSON，不要输出任何解释、前后缀、代码块标记。 字段固定为：name、date、amount、category。 信息缺失时该字段填空字符串。 """ MESSAGE user """ 采购部于三月十二日签订合同，金额 12.6 万元，属于办公设备类。 """ MESSAGE assistant """ {"name":"办公设备采购合同","date":"03-12","amount":"126000","category":"办公设备"} """

案例二：代码助手。

代码场景和文本场景的参数取向完全相反。温度要更低，接近 0，因为代码需要确定性；上下文要给足，因为要看懂整个文件；停止词要加上，避免它在生成完函数后继续瞎编。

还有一个技巧：在系统提示词里限定回答的语言和风格，比如“只回答代码和必要的注释，不要复述问题，不要给多种方案”。不加这句，模型特别喜欢先复述一遍你的问题，再给三个方案，最后加一段总结，非常占篇幅。

FROM 某个14B模型:q4 PARAMETER temperature 0.05 PARAMETER num_ctx 16384 PARAMETER num_predict 2048 PARAMETER repeat_penalty 1.05 PARAMETER stop "```" SYSTEM """ 你是资深工程师。只输出可运行代码和必要的行内注释。 不复述问题，不解释思路，不给备选方案。 涉及依赖时在代码首行注释说明。 """

5.3 采样参数怎么调才不“抽风”

参数不多，但每个的方向性要搞清楚，否则调起来像玄学。

温度控制随机性。抽取类任务压到 0.1 以下，创意写作用 0.7 到 0.9，代码用 0.05 左右。温度调到 0 也不是完全确定，底层实现仍有微小随机性，但对绝大多数任务够用了。

top_p是另一种截断方式，和温度二选一调就行，同时调容易互相抵消。默认 0.9 附近比较稳。

repeat_penalty控制重复惩罚。模型陷入循环输出同一句话时，把它从 1.1 提到 1.15 到 1.2 通常能缓解。但别调太高，超过 1.3 容易出现语句不通顺、词汇贫乏的问题。

num_predict是单次生成的最大长度。不设的话可能一直生成到上下文上限，白白浪费时间。按任务类型给个合理值：短问答 512，代码 2048，长文摘要 4096。

num_ctx是上下文窗口。这个值设大了吃显存、拖速度，设小了长文档被截断。原则是按你的实际输入长度加生成长度再留 20% 余量，不要无脑拉满。

提示：调参的顺序应该是先固定其他参数、只动一个，观察变化。同时改三个参数，你永远不知道是哪个起了作用。我一般先定温度，再调上下文，最后看要不要动重复惩罚。

6. 接口对接：让模型接进你自己的程序

6.1 两个核心端点的区别

服务起来之后自带 HTTP 接口，默认端口是 11434。核心端点有两个，理解它们的区别很重要。

生成端点接收一个提示词字符串，返回补全结果。它适合单轮任务，比如文本分类、翻译、摘要。它不管对话历史，你传什么它就基于什么生成。

对话端点接收的是一个消息数组，每条消息带角色标记，返回助手回复。它适合多轮对话，服务端会按模型的对话模板自动拼接。做聊天应用必须用这个，否则角色标记要你自己拼，拼错了模型就懵了。

两个端点都支持流式返回，也就是逐块推送。做前端界面时一定要用流式，否则用户要盯着空白屏幕等十几秒，体验很差。

6.2 兼容式接口与前端界面的接入

除了原生接口，服务还提供了一套兼容主流接口规范的端点。这意味着市面上大量现成的工具、SDK、前端界面可以直接对接，只需要把接口地址改成你的服务地址，密钥随便填一个非空字符串。

这一点价值很大。你在网上能找到的大部分聊天前端、知识库工具、工作流平台，都支持配置自定义接口地址。改个地址就能用上本地模型，不用改一行代码。

这里有个细节要注意：兼容接口的地址前缀不一样，原生接口是根路径加端点名，兼容接口是/v1前缀加端点名。配置的时候别写错，写错了会返回 404，很多人以为是服务没起来。

6.3 Python 端的完整调用示例

下面这段是我常用的模板，包含了流式处理、超时控制和异常兜底，可以直接改成自己的。

import json import requests def chat_stream(prompt: str, model: str = "my-model", timeout: int = 120): url = "http://127.0.0.1:11434/api/chat" payload = { "model": model, "messages": [ {"role": "system", "content": "你是一个严谨的技术助手。"}, {"role": "user", "content": prompt}, ], "stream": True, "options": { "temperature": 0.3, "num_ctx": 8192, "num_predict": 1024, }, } buffer = [] try: with requests.post(url, json=payload, stream=True, timeout=timeout) as resp: resp.raise_for_status() for line in resp.iter_lines(): if not line: continue chunk = json.loads(line.decode("utf-8")) piece = chunk.get("message", {}).get("content", "") if piece: buffer.append(piece) print(piece, end="", flush=True) if chunk.get("done"): break except requests.exceptions.Timeout: print("\n[超时] 模型响应超时，考虑缩短上下文或降低生成长度") except requests.exceptions.ConnectionError: print("\n[连接失败] 检查服务是否在运行、地址端口是否正确") return "".join(buffer) if __name__ == "__main__": chat_stream("用三句话解释什么是上下文窗口")

几个实战经验。第一，options里的参数会覆盖模型配置文件的默认值，做多场景应用时可以在代码里动态传，不用为每个场景建一个模型。第二，超时时间要给足，大模型首字延迟可能十几秒，超时设太短会频繁报错。第三，一定要处理连接异常，服务重启或者显存爆了的时候，接口会直接连不上，没有兜底的话整个程序会崩。第四，流式返回的每一行是独立的 JSON，要按行解析，不要当成一个完整 JSON 处理。

7. 性能调优：同样的卡，为什么别人跑得快

7.1 上下文长度是显存的最大变量

前面提过上下文缓存，这里展开讲，因为它是调优里收益最大也最容易被忽视的一项。

上下文缓存的大小和上下文长度是线性关系。你把上下文从 4K 调到 32K，缓存占用直接涨八倍。一张 24G 的卡跑 32B 模型，权重已经占了 19G，剩 5G 给缓存和缓冲，上下文最多也就撑到 8K 左右，再往上就要往内存里溢出，速度立刻掉档。

所以调优的第一个动作不是换模型，是看你的真实需求需要多长上下文。很多应用其实只需要 4K——一轮问答、一段代码、一篇短文。把上下文从 32K 砍到 8K，速度提升可能超过一倍。我见过不少人为了“以防万一”把上下文拉满，结果白白浪费了性能。

第二个动作是压缩缓存精度。缓存从 16 bit 降到 8 bit，占用减半，质量影响很小，长上下文场景收益明显。

第三个动作才是考虑降量化等级或者换小规格模型。

7.2 并发、排队与驻留时间的取舍

单用户场景性能调优空间有限，多用户场景才是重头戏，核心是并发和排队的平衡。

并发数决定了同时能处理几个请求。设成 1 的时候，第二个请求会一直等第一个处理完。设成 4，四个请求并行处理，但每个请求都有自己的上下文缓存，显存占用变成四倍。所以在显存固定的前提下，并发数和上下文长度是互相制约的——想提高并发，就得砍上下文。

有个实用的判断方法：看你的业务是“长请求少并发”还是“短请求多并发”。长文档处理属于前者，并发设 1 到 2，上下文给足；在线客服属于后者，并发设 4，上下文压到 4K 或 8K。

驻留时间这个参数在混合场景下很有用。如果你有多个模型，一个用于对话、一个用于向量化，把驻留时间调短（比如五分钟），让不活跃的模型自动让出显存，避免两个模型争抢导致频繁换入换出。反过来，如果你就一个模型高频用，设成永不卸载，省掉反复加载的时间。

7.3 监控三板斧

调优不能靠猜，要有数据。三个观察手段够用了。

第一是模型进程命令，看当前加载的模型、显存占用、驻留时间。如果发现显存占用远高于预期，八成是上下文设太大了。

第二是显卡监控工具，看显存利用率和计算利用率。显存快满了但计算利用率很低，说明瓶颈在显存带宽或者模型在内存和显存之间搬数据；两者都接近满，说明已经跑满了，该考虑升级硬件或者降配模型。

第三是接口响应时间。分别记录首字延迟和总耗时。首字延迟高说明加载慢或者上下文太长，总耗时高说明生成速度不够。这两个指标指向的优化方向完全不同。

8. 踩坑实录：常见故障排查速查

8.1 服务起不来与连不上

装完发现命令找不到，通常是安装路径没进环境变量，用绝对路径跑一次确认，然后补齐路径配置。

服务起了但连不上，先确认端口有没有被占用。有些机器上这个端口被别的程序占了，服务启动会失败但不一定报错明显。换端口或者关掉占用进程都行。

本机能连、局域网连不上，九成是监听地址还是默认的本机回环地址。前面说过，要用环境变量改成对外地址，并且注意防火墙规则。

改完环境变量不生效，回到第 3 章说的那个问题——环境变量设的位置不对。用服务方式启动的必须改服务配置，改 shell 配置文件没用。

8.2 加载失败与显存不足

最常见的是加载到一半失败，提示内存不足。这时候先看模型规格对不对——是不是不小心拉了个大规格的版本。然后看上下文是不是设太大了，把num_ctx降到 4096 再试一次。

如果能加载但一对话就崩，通常是上下文累积到一定程度爆了。多轮对话时历史消息会一直堆着，堆到超过上下文上限就出问题。解决办法是在应用层做历史截断，只保留最近若干轮，或者对早期内容做摘要。

还有一种情况是模型能跑但极慢，显卡监控显示计算利用率很低。这通常意味着大部分层都在内存里，显存不够。可以手动指定放到显卡上的层数，牺牲一点速度换取能跑起来，但更推荐直接换成小规格模型。

注意：显卡驱动版本过旧也会导致加载失败或者速度异常，但报错信息往往很含糊。遇到“明明配置够却跑不起来”的情况，先把驱动升到较新版本再排查其他原因，能省很多时间。

8.3 输出质量问题：答非所问、重复、乱码

答非所问最常见的原因是对话模板不匹配。自己导入的权重文件如果没有携带模板元数据，服务会用默认模板拼接，格式对不上模型就会乱答。解决办法是查一下这个模型系列的标准对话格式，手写进配置文件的模板字段。判断方法：问一个最简单的“你好”，正常模型会自然回应，模板错了会输出奇怪的标记符号或者复读你的输入。

重复输出同一句话，先调重复惩罚，从 1.1 提到 1.15 试试。如果还不行，检查是不是num_predict设得太小导致生成长度被截断在一个不自然的位置。还有一种情况是上下文几乎占满，可用空间很少，模型容易陷入循环。

输出乱码或夹杂特殊符号，通常是编码问题或者模板标记泄漏。检查一下配置文件的模板字段有没有写错，特别注意角色标记的位置和格式。

中文效果差，两个原因：模型本身的中文能力弱，或者量化等级太低。7B 模型降到 Q3 之后中文长句确实容易出问题，升到 Q4 或 Q5 会好很多。另外系统提示词用中文写，效果通常比用英文写好。

8.4 排查速查表

9. 几个我踩过之后才明白的细节

最后说几个零散但很值钱的经验。

批量任务不要用对话接口。我之前做一批文档抽取，图省事用了对话端点，每个文件都带上完整的系统提示词，结果速度慢得离谱。换成生成端点，把系统提示词和内容拼成一个字符串一次发过去，速度快了将近一倍。对话端点的额外开销在多轮场景下值得，单轮批处理纯属浪费。

模型文件不是越多越好。硬盘上堆了十几个模型，每个几 G，看着很爽，实际上常用的就两三个。而且模型多了之后，服务在某些配置下会尝试预加载，反而拖慢启动。定期清一下不用的。

提示词的边际收益递减很快。系统提示词从三行加到三十行，效果可能提升 10%；再加到三百行，开始出现负面效果，模型会抓不住重点。真正有效的是示例，两三个精心构造的示例胜过一大段规则描述。

不要迷信参数规模。一个小规格模型配好提示词和示例，在很多垂直任务上能打赢大规格模型的通用表现。特别是格式固定的抽取类任务，7B 加三个示例的准确率比 32B 零样本高出不少，而且快十倍。

留一份可复现的配置。每个调好的模型都对应一份配置文件，把它和你的应用代码放在一起版本管理。我吃过亏——某次服务重装，模型全没了，提示词散落在各个脚本里，重新拼回去花了半天。现在我的做法是配置文件进代码仓库，模型目录单独备份，换机器的时候几条命令就能复原。

这套东西跑顺之后，本地大模型就不再是个玩具，而是能真正嵌进工作流里的工具。真正的门槛不在安装，而在你想清楚要用它解决什么具体问题——想清楚了，上面这些参数和步骤才有意义。