做本地大模型这件事我从“抱着试试看”到“真当成日常工具用”中间大概折腾了小半年。最开始的想法很朴素写代码时不想把整段业务逻辑贴到网页对话框里翻译合同和文档时也不想一份份往外传。于是我把目光放到能在个人机器上跑起来的中等参数量模型上Qwen2.5-7B 就是在这个背景下进入视野的——7B 级别的体量、官方声明支持 32K 上下文、中英双语底子好、对代码有一定训练投入这几点正好对上我的两个高频场景编程助手和多语言翻译。运行框架选了 Ollama理由很简单一条命令拉模型、自带 REST 接口、Modelfile 能把参数固化下来不用自己去折腾推理引擎的编译。这篇内容就是我这一段时间的实测记录。前半段讲环境怎么搭、参数怎么调、显存怎么算后半段是两组硬碰硬的测评一组拿编程任务去打看它能不能当半个结对伙伴一组拿多语言翻译去打看它在中英日德之间来回倒腾时会不会掉链子。中间会穿插大量我踩过的坑比如上下文长度设大了直接爆显存、温度调高了代码里冒出根本不存在的函数名、批量翻译跑到一半断开重来。适合谁看手上有 8GB 以上显存、想在自己机器上跑一个能干活的中等模型的朋友也适合已经把模型跑起来、但觉得“效果一般般”想找找参数和提示词原因的朋友。全部内容基于我个人环境实测数据仅供参考不同硬件差异会很大。1. 为什么在本地跑一个 7B 模型需求拆解与方案选型1.1 三个真实诉求决定了选型方向我把自己的需求摊开列了一遍其实就三条。第一条是响应速度和隐私的平衡日常写代码时提问频率很高一天几十次每次都走公网接口延迟叠加起来很烦而且贴进去的代码往往带业务字段。第二条是离线可用出差在高铁上、在没网的环境里改脚本我希望工具还在。第三条是可控性我想自己决定上下文多长、温度多少、系统提示词怎么写而不是被网页端固定死。这三条诉求一摆出来选型其实就没什么悬念了。云端 API 在绝对能力上肯定更强但它解决不了“离线”和“参数完全自主”这两点而纯本地跑一个 70B 级别的模型我的硬件又扛不住。7B 这个档位是甜点区——量化之后权重文件 4 到 5GB剩下的显存留给 KV 缓存一张 16GB 显存的消费级显卡能跑得挺舒服8GB 显卡降一档量化也能用。再往上到 14B、32B能力是上去了但要么得双卡要么得接受每秒个位数的出词速度写代码时那种“等它一个字一个字蹦”的体验会直接劝退。提示不要一上来就追求最大参数。编程和翻译这两类任务对模型的要求不同编程更吃“指令遵循 代码语料”翻译更吃“双语对齐质量”参数量不是唯一变量。7B 在这两件事上的性价比实测下来比很多人预期的要好。1.2 为什么是 Qwen2.5-7B 而不是同级的其他选择同档位可选的模型不少我最终留下 Qwen2.5-7B-Instruct 作为主力主要是几个细节打动我。一是上下文官方标注原生 32K配合 YaRN 还能往上扩这对“把一整个源文件丢进去让它找 bug”这种用法是刚需很多同级模型还停在 8K。二是中英双语的实际手感它的中文不是“翻译腔中文”长句的组织方式更接近母语表达这在做中译英和英译中双向任务时体现得很明显。三是结构化输出能力我经常让它输出 JSON它的格式遵循度在 7B 里算比较靠谱的偶尔跑偏但用 few-shot 一压就回来了。四是代码能力有专门投入官方在 7B 这个尺寸上做了代码方向的强化实测下来写中等难度的 Python、Shell、SQL 基本够用复杂的算法题会露怯但日常业务代码的补全、改写、加注释、写单测完成度是可以接受的。另外它还有个 Coder 变体专门偏代码我在第 3 章会顺带提一句两者的差异。需要说清楚的是这些都是“够用”而不是“惊艳”。你要是拿它跟顶级闭源模型比复杂推理那肯定比不过。但作为一个不联网、不出机器、随叫随到的助手它的定位是“把重复劳动吃掉”这个目标它完成得不错。1.3 量化版本怎么选先把显存账算明白这一步很多人跳过直接拉默认标签结果跑起来要么慢要么爆。我先讲算法再讲结论。模型推理占用的显存大致分两块权重和KV 缓存。权重好算7.6B 参数乘以每参数字节数FP16 是 2 字节约 15GBQ8_0 约 8GBQ5_K_M 约 5.4GBQ4_K_M 约 4.7GB。KV 缓存按公式推单 token KV 缓存字节数 2K 和 V× 层数 × KV 头数 × 头维度 × 每元素字节数Qwen2.5-7B 是 28 层、GQA 结构下 KV 头数为 4、头维度 128按 FP16 存2 × 28 × 4 × 128 × 2 57,344 字节 ≈ 56KB/token也就是说 8K 上下文约 0.45GB32K 上下文约 1.8GB。这个数字很关键——很多人以为“支持 32K”就是免费的实际上你把 num_ctx 从 4096 调到 32768光缓存就要多吃 1.4GB 左右8GB 卡直接就顶到墙上了。我的实测结论整理成下面这张表硬件按“16GB 显存 32GB 内存 8 核 CPU”的虚构配置描述tok/s指生成速度量化版本权重占用建议 num_ctx显存总占用估生成速度tok/s适用场景q8_0约 8.0GB8192约 9GB22 - 28显存充裕追求质量上限q5_k_m约 5.4GB16384约 7GB38 - 45质量与速度的平衡点q4_k_m约 4.7GB32768约 6.8GB45 - 55默认首选长上下文场景q4_0约 4.1GB32768约 6GB50 - 608GB 显卡、极限压榨我个人日常用q4_k_m原因是它在质量上的损失我几乎感知不到但换来的是可以把 num_ctx 开到 16K 甚至 32K 而不心疼显存。如果你的任务以短问短答为主、从不塞长文件那q5_k_m或q8_0换来的那点质量提升是划算的。别迷信“量化越低越差”Q4_K_M 这种混合量化对关键层保留了更高精度实际掉点比 Q4_0 小得多两者速度差也就 10% 上下。注意显存账要留余量。Ollama 在加载时会额外占用几百 MB 做图构建和缓冲加上系统桌面本身占的那部分卡着极限设 num_ctx 非常容易在长对话第 N 轮突然崩掉。我的习惯是留 1.5GB 缓冲。2. Ollama 环境落地安装、模型拉取与关键参数2.1 安装与存储目录的规划Ollama 的安装本身没什么门槛各平台都有安装包装完服务默认就在后台跑着监听本地的 11434 端口。真正需要提前想的是模型文件放哪。默认路径在用户主目录下一个 7B 模型的多个量化标签加起来十几 GB 很常见如果你主目录在系统盘上很快就会看到磁盘告警。我的做法是装之前就设好环境变量把模型目录指到一块大容量盘上。Linux 和 macOS 下用OLLAMA_MODELSWindows 则在系统环境变量里加同名项改完要重启 Ollama 服务才生效。这一步顺序别搞反——先设变量再拉模型否则模型已经落到默认目录了改完变量还得手动搬容易搬出权限问题。# Linux / macOS写进 shell 配置文件后重开终端 export OLLAMA_MODELS/data/ollama-models export OLLAMA_HOST127.0.0.1:11434 export OLLAMA_KEEP_ALIVE30m export OLLAMA_NUM_PARALLEL2 export OLLAMA_MAX_LOADED_MODELS1 export OLLAMA_FLASH_ATTENTION1 export OLLAMA_KV_CACHE_TYPEq8_0上面这几个变量是核心逐个解释一下我的取值理由。OLLAMA_KEEP_ALIVE30m让模型在最后一次调用后驻留显存 30 分钟默认值只有 5 分钟写代码时你思考一会儿再问模型已经被卸载了下一次提问要重新加载那个等待感很难受。OLLAMA_NUM_PARALLEL2允许两路请求并发做批量翻译时能吃到并行红利但注意并发会成倍吃 KV 缓存显存紧的话老实设 1。OLLAMA_MAX_LOADED_MODELS1是防止你不小心拉了两个模型把显存撑爆。OLLAMA_FLASH_ATTENTION1开启注意力优化长上下文下显存和速度都有改善。OLLAMA_KV_CACHE_TYPEq8_0把 KV 缓存量化到 8 位能把缓存占用砍掉将近一半质量影响很小长上下文场景强烈建议开。2.2 拉取模型与用 Modelfile 固化参数拉模型就一条命令但标签要写全别只写qwen2.5那是默认标签你不一定知道你拿到的是哪个量化版本。ollama pull qwen2.5:7b-instruct-q4_K_M ollama list # 确认标签和体积 ollama run qwen2.5:7b-instruct-q4_K_M 用一句话说明什么是闭包命令行直接对话适合验证但真正要长期用我建议写一个 Modelfile。原因很实际num_ctx、temperature、系统提示词这些东西如果每次都在 API 请求里传很容易漏固化成自己的模型标签之后一句ollama run my-coder就是全套配置团队里其他人也能一键复现。FROM qwen2.5:7b-instruct-q4_K_M PARAMETER num_ctx 16384 PARAMETER temperature 0.2 PARAMETER top_p 0.8 PARAMETER top_k 20 PARAMETER repeat_penalty 1.05 PARAMETER num_predict 2048 SYSTEM 你是一名严谨的软件工程师助手。回答代码问题时遵循 1. 先给可运行的完整代码再给不超过三行的关键说明 2. 不确定的 API 必须显式标注需核实禁止编造函数名和参数 3. 涉及修改现有代码时只输出改动片段并标注所在位置。 ollama create my-coder -f ./Modelfile.coder ollama run my-coder这套参数是我反复试出来的。temperature 0.2对代码任务是关键我一开始用默认的 0.8它写出来的东西思路天马行空函数名经常是“看起来很像但根本不存在”的组合。降到 0.2 之后幻觉明显收敛。repeat_penalty 1.05是个小值压一下重复输出的倾向设太大反而会让它不敢用重复的语法结构代码会变得别扭。num_predict 2048限制单次输出长度防止它陷入循环时把显存和时间都耗光。翻译场景我会另建一个标签参数不一样temperature 0.1翻译要更确定、top_p 0.9、SYSTEM 里写死“只输出译文不要解释、不要加引号、不要保留原文”。2.3 用兼容接口把它接进自己的脚本Ollama 自带一个与主流接口规范兼容的/v1/chat/completions这意味着你手上大部分现成的客户端代码改个 base_url 就能直接指过来不用重写。import requests, json, time BASE http://127.0.0.1:11434/v1/chat/completions def ask(messages, modelmy-coder, temperature0.2, max_tokens1024, retries3): payload { model: model, messages: messages, temperature: temperature, max_tokens: max_tokens, stream: False, } for i in range(retries): try: r requests.post(BASE, jsonpayload, timeout180) r.raise_for_status() return r.json()[choices][0][message][content] except Exception as e: if i retries - 1: raise time.sleep(2 ** i) # 指数退避别用固定间隔死磕这里有个细节值得说超时要设够。7B 模型在消费级显卡上生成 1000 个 token 大概要 20 到 30 秒如果你按普通 HTTP 接口的习惯设 30 秒超时长回答必然超时。我一开始就吃了这个亏批量任务里一半请求报超时查了半天以为是服务挂了其实是客户端等不及先断了。设 180 秒是保守值实际很少用满。提示/api/chat和/v1/chat/completions两套接口都能用前者是原生格式、能拿到更细的耗时字段比如 prompt 评估耗时、生成耗时后者兼容性好。做性能测量我用前者做业务集成我用后者。3. 编程助手实测从补全到重构3.1 测评任务怎么设计才算公平随便问几道题然后说“感觉还行”没有意义。我设计了五类任务覆盖日常写代码时真正会遇到的场景每类各 5 道题一共 25 道全部在同一个 Modelfile 配置下跑temperature 0.2、num_ctx 16384提示词尽量写得像真人求助而不是考试题。第一类是函数级实现给一段自然语言描述加输入输出约束让它写一个完整函数比如“写一个把嵌套字典拍平成点号路径键的函数要处理列表”。第二类是缺陷定位贴一段有 bug 的代码只问“这段为什么输出不对”不给答案。第三类是单元测试生成给一个已有函数让它补 pytest 用例重点看它会不会只测 happy path。第四类是SQL 改写把一段可读性很差的子查询改成带 CTE 的写法同时保持语义等价。第五类是重构与注释给一段 80 行的老脚本要求拆分函数并补文档字符串。评分我用三档可直接用跑通、边界考虑到了、改改能用思路对小错、不能用逻辑错或幻觉 API。这种粗粒度评分主观性难免但比“感觉”靠谱得多而且我每道题都实际跑了代码。3.2 实测结果与逐项点评25 道题的结果汇总如下这是我这台机器上的实测分布换模型版本或量化档位会有波动任务类型可直接用改改能用不能用主要问题函数级实现320边界条件偶有遗漏缺陷定位410有时只描述现象不给修法单测生成221容易只测正常路径SQL 改写410窗口函数偶有误用重构与注释320拆函数偏保守不敢动结构函数实现这块表现比我预期好。嵌套字典拍平那道题它不但写了递归版本还主动补了一个用栈的迭代版本理由是“深嵌套时递归可能触顶”。这个主动性是加分项。漏掉的地方通常是类型混合的边界比如列表里混了元组它默认按 list 处理。缺陷定位是最让我惊喜的一项。我贴了一段典型的“闭包在循环里捕获变量”的代码它没有泛泛而谈而是直接指出“循环变量在回调执行时已经是最终值需要用默认参数或工厂函数把当前值绑住”并且给了两种改法。这种“指到具体那一行”的能力是它作为结对伙伴最有价值的地方。单测生成是短板。它写的用例大多围绕正常输入异常分支和边界值需要我在提示词里明确点名“必须包含空输入、类型错误、超长输入三种情况”它才会补。解决办法很土但有效在 SYSTEM 里固定一句“生成测试时必须覆盖空值、类型错误、边界值、并发”。加上这句之后可用率明显提升。SQL 改写质量不错把三层嵌套子查询改成 CTE 之后可读性提升明显语义也保住了。唯一一次翻车是它把一个LEFT JOIN顺手改成了INNER JOIN理由是“这样更快”——这就是典型的“不懂业务语义瞎优化”凡是涉及连接类型的改动我都会逐行核对。重构任务它偏保守80 行的脚本它倾向于只加注释、抽两个小函数不太敢大刀阔斧地重划模块边界。这个其实不算缺点改动越小越容易 review但如果你期待它帮你做架构级重排会失望。至于 Coder 变体我对比跑过一轮。纯代码任务上它的代码风格更紧凑、注释更少但在“解释这段代码为什么这样写”这类需要自然语言输出的场景里反而不如通用版顺手。我的选择是写代码用通用版就够了只在纯生成、不需要解释的批量场景才切 Coder。3.3 提示词模板把要求写死比反复纠正省事试了十几版之后我固定下来一个编程场景的模板。核心思路是把“不要做什么”写在前面因为 7B 级别的模型对否定式约束的敏感度不如大模型得反复强调。角色你是我的代码审查搭档不是聊天机器人。 硬性约束 - 只使用标准库和下列已声明的依赖{deps} - 任何你不确定的 API标注 [需核实]不要猜 - 输出代码块后最多三行说明不要长篇解释 任务 {task} 上下文 {code}几个参数上的经验top_k 20配temperature 0.2是我试出来的组合top_k再往上调代码里出现奇怪标识符的概率会上升repeat_penalty别超过 1.1超了之后它连self、return这种必要重复都开始回避写出来的东西很别扭。3.4 编程场景踩过的三个坑坑一上下文塞太满回答被截断。我一开始图省事把整个 600 行的源文件丢进去结果它回答到一半就断了。原因是输入 token 加上num_predict超过了num_ctx。后来我改成两段式先让它只输出“相关函数名和行号范围”我再把那一小段贴进去做第二轮。这个“先定位再处理”的两段式流程比一次性塞全文的成功率高得多也省显存。坑二幻觉出一个看起来特别合理的库函数。有一次它给我写了个dict.flatten(sep.)语法漂亮、命名合理但 Python 根本没有这个方法。这类幻觉最危险的地方在于“太像真的”。我在 SYSTEM 里加了[需核实]标注要求之后好了很多——它不确定的时候会标出来我扫一眼就知道哪里要查文档。坑三中文注释里的全角符号。它写中文注释时偶尔混入全角括号和全角逗号粘进代码里不报错但很难看。解决办法是在 SYSTEM 里加一句“注释内标点一律使用半角”成本极低效果立竿见影。4. 多语言翻译实测中英日德与代码注释本地化4.1 语料选择与评价维度翻译这块我没用通用测试集而是自己攒了三组语料更贴近实际用途。第一组是技术文档包括接口说明、错误码描述、部署手册片段中英各 20 段特点是术语密集、句式偏长。第二组是产品文案中英各 15 段特点是短句多、有营销语气、需要本地化而不是直译。第三组是代码注释与提交信息中英各 30 条特点是极短、有固定格式、经常带变量名。评价维度我定了四个术语一致性同一个词在全文中是否统一译法、语义保真有没有漏译、错译、添加原文没有的信息、母语自然度读起来像不像人写的、格式保持Markdown 标记、占位符、变量名有没有被翻译掉。最后一项特别重要——我见过太多模型把{user_id}翻译成{用户ID}一运行就报错。4.2 实测表现与典型问题整体结论先给中英互译达到“改改就能用”的水平中日、中德属于“能看懂但需要润色”。具体表现语言方向术语一致性语义保真自然度格式保持综合判断英译中技术好好好好基本可直接用中译英技术好好较好好小改可用英译中文案中好较好好需润色语气中译英文案中较好中好建议人工重写中译日中好中好需检查敬语层级中译德中较好中好名词复合词需人工拆英译中技术文档是它的强项。长句拆分做得自然不会出现那种“从句套从句、读到最后忘了主语”的翻译腔。术语方面像idempotent、backoff、race condition这类词它给出的译法和我平时用的基本一致幂等、退避、竞态条件全文也保持了统一不会这一段叫“幂等”下一段叫“幂等性”。中译英技术文档也很能打句式偏简洁没有那种“中式英语的长定语前置”。唯一需要注意的是它有时候会把中文的“我们”直译成we而英文技术文档更习惯用被动或者直接省略主语这个得手工调。文案翻译是明显短板。你给它一句“轻装上阵快人一步”它会老老实实翻成Light equipment, one step faster语义没错但完全没有广告语的味道。这不是模型的问题是这类任务本身就需要人类译者的再创作。我的用法是让它出三个版本的直译我自己挑一个方向再改。中译日这块要重点提敬语。它会默认用比较中性的敬体但商务文档往往需要更谦让的表达而技术文档又不需要那么客气。同一批语料里它给不同段落选的敬语层级不太统一。解决办法是在提示词里明确“读者为外部客户使用敬体”或“内部技术文档使用常体”指定之后一致性就好了。格式保持这一项它做得相当好这是我没预料到的。Markdown 的加粗、代码围栏、列表符号全都保住了{placeholder}和{{var}}这类占位符也没有被翻译变量名user_id保持原样。这一点对批量处理特别关键因为格式一乱后处理脚本就得写一堆补丁。4.3 翻译场景的参数与提示词翻译和编程的参数取向不一样。编程要一点发散来找思路翻译要的是确定性。我的配置是temperature 0.1、top_p 0.9、top_k 10repeat_penalty保持 1.0 不动翻译里重复词很正常压它反而出错。提示词方面我固定用这个结构核心是术语表前置 输出格式锁死你是专业翻译。严格遵守 1. 只输出译文不要解释、不要加引号、不要重复原文 2. 保留所有 Markdown 标记、代码围栏、占位符如 {name}、变量名 3. 术语表必须遵守idempotent幂等; backoff退避; race condition竞态条件 4. 目标读者{audience}语体{style} 待译内容 --- {text}术语表这一条价值最大。7B 模型在没有约束的情况下同一个术语在不同段落可能给出两三种译法尤其是“幂等”这种它可能译成“幂等性”“幂等的”“幂等操作”的词。把术语表写进提示词一致性立刻上来。术语表不用很长二十条以内效果最好太长反而会稀释注意力。注意一定要在提示词里明确“不要输出原文”。不加这句它有很大概率把原文和译文一起吐出来批量处理时你得写正则去剥离很麻烦。4.4 批量翻译脚本断点、重试和限速单段翻译用命令行就够了实际工作中往往是几十上百个文件。我写了个批量脚本核心是三点断点续跑、指数退避重试、按段落切分。import json, os, time, hashlib, requests API http://127.0.0.1:11434/v1/chat/completions CACHE translate_cache.jsonl def key_of(text, style): return hashlib.md5((style || text).encode()).hexdigest() def load_done(): done set() if os.path.exists(CACHE): with open(CACHE, encodingutf-8) as f: for line in f: done.add(json.loads(line)[k]) return done def translate(text, style技术文档, glossary, retries4): prompt f你是专业翻译。严格遵守 1. 只输出译文不要解释、不要加引号、不要重复原文 2. 保留所有 Markdown 标记、占位符、变量名 3. 术语表{glossary} 4. 语体{style} 待译内容 --- {text} payload {model: my-translator, messages: [{role: user, content: prompt}], temperature: 0.1, max_tokens: 2048, stream: False} for i in range(retries): try: r requests.post(API, jsonpayload, timeout240) r.raise_for_status() return r.json()[choices][0][message][content].strip() except Exception: if i retries - 1: return None time.sleep(2 ** i) def run(segments, glossary, style技术文档): done load_done() with open(CACHE, a, encodingutf-8) as f: for seg in segments: k key_of(seg, style) if k in done: continue out translate(seg, style, glossary) if out is None: print([跳过] 连续失败, seg[:40]) continue f.write(json.dumps({k: k, src: seg, dst: out}, ensure_asciiFalse) \n) f.flush() # 关键立刻落盘崩溃不丢进度 time.sleep(0.2)几个设计点解释一下。用内容哈希做缓存键好处是同一段文字重复出现不会重复翻译改稿之后只有变动段会重跑。每写一行就flush因为我被“跑到第 87 段程序崩了、缓存没落盘、从头再来”坑过一次。time.sleep(0.2)是给本地服务的喘息时间看着没必要但连续高压请求时偶发过连接被拒加个间隔就好了。按段落切分而不是按文件切分因为长文档整篇丢进去很容易触发上下文上限切段之后每段都能独立重试一段失败不影响整体。跑完之后我会做一遍机械校验对比原文和译文的占位符数量是否一致、代码围栏数量是否一致、数字是否一致。这三项能拦掉绝大部分低级错误比人眼扫快得多。5. 性能与资源占用速度、并发与优化手段5.1 怎么测才算靠谱测速这件事很容易自欺欺人。第一次跑完看到tok/s挺高实际用起来却觉得慢原因是首次加载没算进去。我的测法是先发一次短请求把模型预热到显存里keep_alive设长保证不被卸载然后连发 5 次同类请求取后 4 次的平均值。两个指标要分开看prefill 速度处理输入的速度单位 token/s通常几百到上千和decode 速度生成输出的速度几十 tok/s。长文档翻译这类任务的瓶颈在 prefill——输入 3000 token、输出 300 token前者的耗时可能占到一半。很多人只盯着生成速度忽略了输入端这一块。5.2 不同配置下的实测数据下面是我这台机器16GB 显存消费级显卡、32GB 内存、8 核 CPU的实测num_ctx和量化的组合如下量化num_ctxprefill (tok/s)decode (tok/s)首 token 延迟显存峰值q4_k_m4096约 620约 52约 0.5s5.6GBq4_k_m16384约 580约 48约 0.8s6.6GBq4_k_m32768约 510约 44约 1.2s8.1GBq5_k_m16384约 540约 41约 0.9s7.4GBq8_08192约 470约 25约 1.4s9.3GB从数据能看出两个规律。一是 num_ctx 拉大decode 速度会掉因为注意力计算量随上下文线性增长从 4K 到 32K生成速度掉了约 15%。这个损失不算大但首 token 延迟翻了一倍多交互式使用时能感觉到。二是量化档次对速度的影响比想象中小q8_0 慢主要是因为权重体积翻倍导致内存带宽压力大而不是计算本身。5.3 几个真正有效的优化手段第一把OLLAMA_KEEP_ALIVE调长。这是我感受最明显的改动。默认 5 分钟卸载你思考一会儿再问就得重新加载 5GB 权重那个 3 到 5 秒的等待非常打断思路。设成 30 分钟之后一天下来几乎感知不到加载过程。代价是显存一直被占着如果你还要跑别的吃显存的程序就按需调短。第二开OLLAMA_FLASH_ATTENTION和 KV 缓存量化。这两个组合起来长上下文场景的显存占用能省下接近 40%。我实测 16K 上下文下不开是 8.2GB开了之后降到 6.6GB 左右。省下来的显存可以拿去把 num_ctx 开更大形成正循环。第三别贪OLLAMA_NUM_PARALLEL。设成 4 看起来很美好实际每个并发槽都要独立分配 KV 缓存显存直接翻几倍。做批量翻译时我用 2日常交互用 1。这个参数不是越大越好是“显存除以单路缓存”算出来的上限。第四GPU 层数能全放就全放。Ollama 会自动判断但在混合配置显存不够全放下剩余的层会落到 CPU 上速度会断崖式下跌——我试过往 CPU 上放 8 层生成速度从 48 掉到 13。宁可降一档量化把全部层塞进显存也别接受混合推理。提示判断有没有落到 CPU看ollama ps输出里 GPU 占用百分比那一列100% 才是全量在显卡上。这个命令我几乎每次启动都会扫一眼。6. 常见问题与排查速查表6.1 我实际遇到过的六类故障模型加载失败或跑到一半崩掉。九成是显存不够。排查顺序先看num_ctx是不是开太大降到 8192 试再看OLLAMA_NUM_PARALLEL是不是大于 1改回 1 试最后看OLLAMA_MAX_LOADED_MODELS如果之前跑过别的模型没卸载显存是被占着的重启服务最干脆。输出突然变成乱码或者重复刷同一句话。温度设太高会这样repeat_penalty设太高也会这样模型为了避开重复而胡乱换词换到最后语义崩了。我的处理是把repeat_penalty拉回 1.0 到 1.05temperature降到 0.2 以下再试。回答总是被截断。检查输入 token 加num_predict有没有超过num_ctx。长文档场景我的做法是分片不要指望一次性塞进去。另外num_predict设得太小比如 256也会表现为“话说一半”。中文输出里全是全角标点粘到代码里很难看。在 SYSTEM 里明确要求半角标点或者在提示词里加一句“代码块内部标点使用半角”。这是最低成本的一处修复。批量任务跑着跑着连接被拒。大概率是并发太高把服务压住了。把NUM_PARALLEL降到 1请求之间加 0.2 到 0.5 秒间隔基本就不出现了。另外记得客户端的timeout要设到 180 秒以上短超时会造成“假故障”。同一个术语在不同段落译法不一致。这是 7B 级别模型的通病。解法是术语表前置并且把temperature压到 0.1。还不行的话就把文档按章节切开每章单独维护术语表。6.2 速查表现象最可能原因快速处理加载超时 / 崩溃显存不足降 num_ctx、NUM_PARALLEL 改 1、重启服务生成速度骤降部分层落到 CPUollama ps看 GPU 占比降一档量化输出循环重复repeat_penalty 过高调回 1.0 - 1.05代码里出现不存在的 API温度过高 / 缺约束temperature ≤ 0.2SYSTEM 加“不确定标注”回答被截断token 预算超限减少输入、提高 num_ctx 或分片占位符被翻译提示词未声明明确“保留 {xxx} 占位符与变量名”术语前后不一致无术语表约束术语表前置 temperature 0.1客户端报超时但模型在跑客户端超时太短timeout 提到 180s 以上6.3 几个我踩过才明白的细节模型标签一定要写全。ollama pull qwen2.5:7b和你以为的qwen2.5:7b-instruct-q4_K_M可能不是一个东西体积和量化档位都不一样。我见过有人抱怨“效果差”最后发现拉的是 base 版本而不是 instruct 版本——base 模型不会遵循指令它只会续写你问它问题它给你续一段问题。改完环境变量必须重启服务。尤其是OLLAMA_MODELS和OLLAMA_KEEP_ALIVE改了不重启等于没改。这个坑我踩了两次第一次还以为变量名写错了。Modelfile 里的 SYSTEM 优先级很高但也别写太长。我一度写了 300 字的系统提示词结果模型对用户实际问题的注意力被稀释了回答开始跑题。后来精简到 80 字以内只保留最硬的三条约束效果好得多。约束越多不等于越听话7B 模型的注意力预算有限。别用同一个模型标签兼顾编程和翻译。我一开始图省事一个标签打天下结果编程场景的temperature 0.2配长 SYSTEM翻译时它老是忍不住加解释。后来分成my-coder和my-translator两个标签各管各的问题消失。定期清理不用的模型标签。ollama list会越积越长每个都是几 GB。我一般保留两个量化档位一个常用、一个备用其余删掉。磁盘满了导致的故障排查起来很绕因为报错信息往往指向别的地方。最后分享一个我最近才用顺手的做法把常问的问题和满意的回答存成一个本地的小样本库每次新任务先检索两三条同类示例塞进提示词里做 few-shot。7B 模型在零样本下的表现有波动但给两三个例子之后输出格式和风格的一致性会明显提升尤其是 JSON 输出和翻译的语气控制这两块。这个改动不需要任何额外依赖就是读写本地文件但对我日常使用的体验提升比换一个更大的模型来得直接。