★ FEATURED ARTICLE 早上打开终端敲下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 GB14B 约 8.5 GB32B 约 19 GB70B 约 40 GB。这里的关键是量化等级后面单独讲。上下文缓存KV Cache是最容易被忽略的变量。它的大小与层数、注意力头数、缓存精度和上下文长度成正比。给一个粗略的工程估算方式7B 级别的模型在 8K 上下文、缓存用 8 bit 的情况下大约需要 1 GB上下文拉到 32K这个数字就变成 4 GB 左右。上下文长度是线性增长的很多人调大上下文之后爆显存原因就在这里。计算缓冲通常在 0.5 到 2 GB 之间取决于批大小和显卡架构。三个算例看得更清楚场景模型规格量化上下文权重缓存缓冲合计轻薄本试水7BQ44K4.1 GB0.5 GB0.5 GB约 5.1 GB单卡主力开发14BQ416K8.5 GB2 GB1 GB约 11.5 GB长文档处理32BQ432K19 GB4 GB1.5 GB约 24.5 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 计算机器配置推荐规格量化预期体验16G 内存无独显3B 至 7BQ4能用每秒几个字适合轻量问答8G 显存7BQ4/Q5流畅日常开发调试主力12G 至 16G 显存14BQ4流畅复杂任务明显强于 7B24G 显存14B Q6 或 32B Q4—前者质量优先后者能力优先48G 显存及以上32B Q5 或 70B Q4—接近可用生产力工具的水平纯 CPU 服务器大内存32B 以内Q4慢但适合离线批处理纯 CPU 跑模型这件事值得单独说一句。很多人以为没显卡就没戏其实不然。大内存的服务器用 CPU 跑 32B 的 Q4 模型每秒出三到五个字做批量离线任务完全够用——反正你也不需要盯着屏幕看它打字。这类场景的瓶颈不在单次响应速度而在总吞吐所以把并发调低、上下文调小反而整体效率更高。3. 安装与环境变量五分钟装完半小时调对3.1 三个平台的安装路径差异安装本身没什么技术含量但有个细节会影响后面所有操作服务是怎么启动的。这决定了你改环境变量的方式。Linux 上一般用一键脚本安装装完会注册成一个系统服务用系统服务管理器拉起。这意味着你在 shell 里 export 的环境变量对服务无效必须写进服务的配置文件里。macOS 上是一个应用包图形界面启动环境变量要用系统级的设置命令写在 shell 配置文件里同样不生效。Windows 上是安装程序装完托盘里有个图标环境变量走系统设置面板改完要重启应用。这个差异看着琐碎但它是新手最常卡住的地方——“我明明设了环境变量怎么不生效”九成是因为设错了位置。判断方法很简单用服务方式启动的改服务配置用应用方式启动的改系统环境变量或者应用自己的配置。# Linux通过服务配置注入环境变量 sudo systemctl edit ollama.service # 在打开的编辑器里加入 # [Service] # EnvironmentOLLAMA_HOST0.0.0.0:11434 # EnvironmentOLLAMA_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代价是显存占用翻倍。第五个是模型驻留时间。默认五分钟无请求就卸载模型。做开发调试时这个设定很烦人刚加载完去改了两行代码回来又得等重新加载。调成半小时或者更长会舒服很多反过来如果是多模型共享一张卡就把它调短一点避免模型互相挤占。第六个是注意力加速开关。支持的话打开它长上下文场景下显存占用和速度都有改善配合缓存精度设置一起用效果更好。老显卡可能不支持打开后如果加载报错就关掉。参数作用常见取值踩坑提醒模型目录存放权重文件大容量磁盘路径目录必须预先创建监听地址服务对外暴露本机或局域网地址对外暴露要加访问控制并发数同时处理请求数1 至 4与显存强相关别贪多同时加载模型数常驻显存的模型数量1 至 3每个都要占显存驻留时间空闲多久卸载30m 至 -1-1 表示永不卸载注意力加速长上下文优化开或关老卡可能不支持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退出。这里提醒一下直接按 CtrlC 也能退出但有时候会残留会话用/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, jsonpayload, streamTrue, timeouttimeout) 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, flushTrue) 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 监控三板斧调优不能靠猜要有数据。三个观察手段够用了。第一是模型进程命令看当前加载的模型、显存占用、驻留时间。如果发现显存占用远高于预期八成是上下文设太大了。第二是显卡监控工具看显存利用率和计算利用率。显存快满了但计算利用率很低说明瓶颈在显存带宽或者模型在内存和显存之间搬数据两者都接近满说明已经跑满了该考虑升级硬件或者降配模型。第三是接口响应时间。分别记录首字延迟和总耗时。首字延迟高说明加载慢或者上下文太长总耗时高说明生成速度不够。这两个指标指向的优化方向完全不同。现象可能原因优先调整首字延迟超过 30 秒模型太大部分层在内存降量化、降规格、缩上下文显存占满但速度慢上下文过长导致缓存溢出缩短上下文、压缩缓存精度并发上来就卡并发数与显存不匹配降并发或缩上下文切换模型极慢模型数超过显存容量减少同时加载模型数短请求也要等很久驻留时间过短反复加载调长驻留时间8. 踩坑实录常见故障排查速查8.1 服务起不来与连不上装完发现命令找不到通常是安装路径没进环境变量用绝对路径跑一次确认然后补齐路径配置。服务起了但连不上先确认端口有没有被占用。有些机器上这个端口被别的程序占了服务启动会失败但不一定报错明显。换端口或者关掉占用进程都行。本机能连、局域网连不上九成是监听地址还是默认的本机回环地址。前面说过要用环境变量改成对外地址并且注意防火墙规则。改完环境变量不生效回到第 3 章说的那个问题——环境变量设的位置不对。用服务方式启动的必须改服务配置改 shell 配置文件没用。8.2 加载失败与显存不足最常见的是加载到一半失败提示内存不足。这时候先看模型规格对不对——是不是不小心拉了个大规格的版本。然后看上下文是不是设太大了把num_ctx降到 4096 再试一次。如果能加载但一对话就崩通常是上下文累积到一定程度爆了。多轮对话时历史消息会一直堆着堆到超过上下文上限就出问题。解决办法是在应用层做历史截断只保留最近若干轮或者对早期内容做摘要。还有一种情况是模型能跑但极慢显卡监控显示计算利用率很低。这通常意味着大部分层都在内存里显存不够。可以手动指定放到显卡上的层数牺牲一点速度换取能跑起来但更推荐直接换成小规格模型。注意显卡驱动版本过旧也会导致加载失败或者速度异常但报错信息往往很含糊。遇到“明明配置够却跑不起来”的情况先把驱动升到较新版本再排查其他原因能省很多时间。8.3 输出质量问题答非所问、重复、乱码答非所问最常见的原因是对话模板不匹配。自己导入的权重文件如果没有携带模板元数据服务会用默认模板拼接格式对不上模型就会乱答。解决办法是查一下这个模型系列的标准对话格式手写进配置文件的模板字段。判断方法问一个最简单的“你好”正常模型会自然回应模板错了会输出奇怪的标记符号或者复读你的输入。重复输出同一句话先调重复惩罚从 1.1 提到 1.15 试试。如果还不行检查是不是num_predict设得太小导致生成长度被截断在一个不自然的位置。还有一种情况是上下文几乎占满可用空间很少模型容易陷入循环。输出乱码或夹杂特殊符号通常是编码问题或者模板标记泄漏。检查一下配置文件的模板字段有没有写错特别注意角色标记的位置和格式。中文效果差两个原因模型本身的中文能力弱或者量化等级太低。7B 模型降到 Q3 之后中文长句确实容易出问题升到 Q4 或 Q5 会好很多。另外系统提示词用中文写效果通常比用英文写好。8.4 排查速查表症状第一怀疑对象验证方法处理命令找不到路径未配置绝对路径执行补环境变量端口连不上监听地址或端口占用查看监听状态改地址或换端口环境变量无效设置位置错误查服务配置改服务级配置加载失败规格超显存按公式估算降规格或缩上下文对话中途崩上下文堆积溢出看历史长度应用层截断历史答非所问对话模板不匹配问简单问题观察手写模板字段输出重复惩罚系数偏低调参数对比提到 1.15 左右中文质量差量化过低换 Q5 对比提升量化等级速度突然变慢模型被换出显存查看进程列表调长驻留时间9. 几个我踩过之后才明白的细节最后说几个零散但很值钱的经验。批量任务不要用对话接口。我之前做一批文档抽取图省事用了对话端点每个文件都带上完整的系统提示词结果速度慢得离谱。换成生成端点把系统提示词和内容拼成一个字符串一次发过去速度快了将近一倍。对话端点的额外开销在多轮场景下值得单轮批处理纯属浪费。模型文件不是越多越好。硬盘上堆了十几个模型每个几 G看着很爽实际上常用的就两三个。而且模型多了之后服务在某些配置下会尝试预加载反而拖慢启动。定期清一下不用的。提示词的边际收益递减很快。系统提示词从三行加到三十行效果可能提升 10%再加到三百行开始出现负面效果模型会抓不住重点。真正有效的是示例两三个精心构造的示例胜过一大段规则描述。不要迷信参数规模。一个小规格模型配好提示词和示例在很多垂直任务上能打赢大规格模型的通用表现。特别是格式固定的抽取类任务7B 加三个示例的准确率比 32B 零样本高出不少而且快十倍。留一份可复现的配置。每个调好的模型都对应一份配置文件把它和你的应用代码放在一起版本管理。我吃过亏——某次服务重装模型全没了提示词散落在各个脚本里重新拼回去花了半天。现在我的做法是配置文件进代码仓库模型目录单独备份换机器的时候几条命令就能复原。这套东西跑顺之后本地大模型就不再是个玩具而是能真正嵌进工作流里的工具。真正的门槛不在安装而在你想清楚要用它解决什么具体问题——想清楚了上面这些参数和步骤才有意义。
阅读完成 · 觉得有帮助？
