很多人第一次在本地部署模型，都会经历同一个心理转弯：先是被参数量的数字唬住，觉得 7B 这种东西只能当玩具，跑两轮对话就露怯；然后真把它接进工作流跑了几天，又反过来觉得在线服务好像也没那么不可替代。我在过去两周里把 Qwen2.5-7B 的指令版按几种量化档位分别部署，在编程辅助和多语言翻译两个场景里做了相对系统的对比测试，顺手把 Ollama 的配置细节也一起摸了一遍。这篇就是完整的测评记录，包含规格解读、参数陷阱、真实样本、失败案例和可直接复用的配置。适合三类人看：想在本地跑一个能真正干活的模型的、正在纠结 7B 和 14B 怎么选的、以及已经把模型拉起来但觉得"效果好像不太对"的。

1. 把评测靶心定在 7B 档位的现实理由

1.1 参数量、显存占用与"能不能天天用"之间那条硬线

选模型这件事，最容易被忽略的约束不是效果上限，而是"你愿不愿意每天都打开它"。14B 级别的模型在不少任务上确实比 7B 稳，但它对硬件的胃口会直接改变你的使用习惯：加载慢、显存吃紧、一个长上下文请求就让整机卡顿，用不了三天你就会退回到浏览器标签页里去。我自己的判断标准很简单——如果一个模型在启动到出第一个 token 之间超过 8 秒，或者跑起来之后我不能同时开着编辑器做别的事，那它的实际使用频率一定会掉到每周一次以下。

7B 这个档位正好卡在"能干活"和"随手就能用"的交界线上。以 Qwen2.5-7B 为例，参数量 7.61B，其中非嵌入参数约 6.53B，28 层结构，注意力采用分组查询机制，28 个查询头配 4 个 KV 头。这套结构对显存特别友好，因为 KV 缓存的大小直接跟 KV 头数挂钩，4 个头意味着缓存膨胀速度只有常规多头注意力的几分之一。

具体到量化档位，我实测过的一组数据如下（同一台机器，空载启动完毕后立即测试）：

提示：上表的显存占用已经包含 KV 缓存，但没有包含运行时的计算缓冲。如果你的显卡是 8GB 且要开 16K 以上上下文，Q4_K_M 会非常勉强，建议退到 8K 或者换 Q4_0。

KV 缓存这块值得单独算一笔账，因为它是很多人显存溢出却找不到原因的地方。Qwen2.5-7B 的隐藏维度是 3584，28 个查询头意味着每个头的维度是 128。在 FP16 精度下，每个 token 在每一层需要的缓存是 2（K 和 V）× 4（KV 头数）× 128（头维度）× 2 字节 = 2048 字节，也就是每层 2KB。乘以 28 层，每 token 约 56KB。8192 个 token 就是约 458MB，16384 个 token 约 917MB，32768 个 token 直接飙到 1.8GB。这个增长速度意味着：你在 Ollama 里把 num_ctx 从 4096 改成 32768，显存会凭空多出一点三四个 G，8GB 卡当场就撑不住。

1.2 Qwen2.5-7B 的规格底牌，以及它明确不擅长的部分

先把它能做的事摆清楚。原生上下文窗口 32768 token，单次生成上限 8192 token，词表规模 151936，官方宣称支持约 29 种语言，指令版在训练中加入了结构化输出能力，能比较稳定地吐 JSON 和表格。这些规格里，真正影响日常使用的是两条：一是 32K 的上下文足以塞进一整个中等规模的源文件或者一份二三十页的文档；二是结构化输出能力让它可以被程序直接消费，不用每次都写正则去抠。

它明确不擅长的部分同样要说清楚，否则期望管理会出问题。第一是超长链路的逻辑推理，那种需要连续七八步推导、每步都不能错的题，7B 会在中途悄悄丢掉某个前提，最后给出一个看起来很合理但完全错误的结论。第二是需要外部事实支撑的问题，训练截止之后发生的事情它一概不知，问到就会开始编造，而且编造得很像真的。第三是多文件、跨模块的大规模重构，它可以处理单个函数甚至单个文件的改造，但你让它同时盯着五个文件保持接口一致，它会漏。第四是复杂数学推导，简单公式没问题，多步计算容易算错，这点在做算法题时特别明显。

2. Ollama 部署里那些默认参数会悄悄拖垮输出质量

2.1 拉取和首次启动，先建立一个基线再动手改

部署这件事本身没什么门槛，真正麻烦的是后面调参。我的习惯是先建立一个未经任何修改的基线，跑三到五个固定测试用例，把结果记下来，再去改配置。这样后面每一次调整都有对照，不至于改到最后连"是不是改坏了"都判断不了。

# 拉取指令版，通用对话和翻译用这个 ollama pull qwen2.5:7b-instruct # 如果你主要做代码，可以额外拉一个编码专用版本做对比 ollama pull qwen2.5-coder:7b # 启动并确认服务状态 ollama serve

启动之后先跑一个最简单的对话确认链路通畅，然后立刻用ollama ps看一眼实际加载情况。这个命令会告诉你当前加载了哪些模型、占用了多少显存、是跑在 GPU 上还是被降级到了 CPU。我见过不止一次"明明装了显卡但推理慢得像蜗牛"的情况，一查ollama ps发现 PROCESSOR 那一列写着 100% CPU，原因是显存不够，运行时自动回退到了内存。

关于版本选择，这里有个容易被混淆的点：qwen2.5:7b-instruct是通用指令模型，qwen2.5-coder:7b是单独训练的编码模型。两者在代码任务上的差距相当明显——编码版在补全、单测生成、跨语言转换上更准，但它的通用对话和翻译能力反而不如指令版。所以如果你的需求是"一个模型全包"，选指令版；如果代码是主战场，就装两个，按任务路由。我在测试里就是两个都装着，用 Modelfile 分别固化成不同的配置。

2.2 num_ctx 是最容易被忽略的一刀

这是我在整个测试里踩得最狠的一个坑。Ollama 在相当长的一段时间里，默认的上下文窗口只有 2048 token，即便模型本身支持 32K。这个默认值配合上某些前端工具，会导致一个非常诡异的现象：你贴进去一段三百行的代码，问它"这个函数有什么问题"，它回答得头头是道，但说的全是文件开头那几十行的内容，后面的一概不提。你以为它能力不行，实际上是它根本没看到。

判断自己有没有中招，最简单的办法是让它复述输入的最后一段。如果它复述不出来，或者复述的内容和你给的对不上，那基本就是被截断了。新版 Ollama 对这个默认值做过调整，但不同版本行为不一致，所以我现在的做法是一律显式指定，不依赖默认值。

设置方式有两种。临时测试用命令行参数：

ollama run qwen2.5:7b-instruct --parameter num_ctx 16384

长期使用就写进 Modelfile，这样每次调用都是同一套配置，不会因为忘了加参数而出现行为漂移。

num_ctx 设多大合适，取决于你的显存和任务类型。我的经验区间是这样的：

不要盲目往大了设。num_ctx 越大，预填充阶段的耗时越长，同样是问一句话，32K 上下文配置下即使输入只有几百 token，首 token 延迟也会有可感知的增加，因为运行时需要为整个窗口预留缓存空间。我一般按任务类型准备两套配置，而不是一套通吃。

2.3 用 Modelfile 固化"编程"和"翻译"两套人格

Modelfile 的价值在于把系统提示词、采样参数、上下文长度打包成一个命名模型，调用的时候只需要写模型名。这是我用下来最省心的做法，尤其是当你要在两个截然不同的任务之间来回切换时。

编程助手的配置：

FROM qwen2.5-coder:7b PARAMETER num_ctx 16384 PARAMETER temperature 0.2 PARAMETER top_p 0.85 PARAMETER repeat_penalty 1.05 PARAMETER num_predict 2048 SYSTEM """ 你是一名严谨的软件工程师。回答代码问题时遵循以下要求： 1. 先指出问题所在的行或函数，再给修改方案。 2. 给出的代码必须完整可运行，不要用省略号代替实现。 3. 如果信息不足以判断，直接说明缺少什么，不要猜测。 4. 涉及修改的，说明修改理由以及可能引入的副作用。 """

翻译任务的配置：

FROM qwen2.5:7b-instruct PARAMETER num_ctx 16384 PARAMETER temperature 0.3 PARAMETER top_p 0.9 PARAMETER repeat_penalty 1.02 PARAMETER num_predict 4096 SYSTEM """ 你是一名技术文档译员。翻译时遵守： 1. 保持原文的段落结构和代码块、命令、变量名不变。 2. 术语按用户提供的术语表执行，术语表未覆盖的，首次出现时给出原文。 3. 译文使用中文技术文档的惯用表达，不要逐字直译。 4. 只输出译文，不要添加解释或前后缀。 """

用ollama create coder-local -f ./Modelfile.coder就能生成一个固定配置的模型。之后调用coder-local就等于带上了全部参数和系统提示词，不用每次重复。这个做法在多脚本、多语言混用的环境里特别省事。

2.4 并发的代价：把 num_parallel 当成显存预算来管

Ollama 支持并发处理多个请求，默认并发数不算低。问题在于，每个并发槽位都要独立占用一份 KV 缓存。你设了 16K 上下文、开了 4 路并发，理论上缓存占用就是单路的四倍，原本 12GB 卡刚好够用的配置会瞬间溢出。

控制并发靠环境变量：

# 限制同时处理的请求数，批处理时建议先设成 1，确认稳定后再加 export OLLAMA_NUM_PARALLEL=1 # 限制同时驻留内存的模型数量 export OLLAMA_MAX_LOADED_MODELS=1 # 控制模型空闲多久后卸载，默认 5 分钟，批量任务可以调长 export OLLAMA_KEEP_ALIVE=30m

keep_alive这个参数在批量处理场景里价值很高。默认情况下模型空闲五分钟就会被卸载，下一次请求到来时要重新加载，而 7B 模型从磁盘加载进显存通常需要三到八秒，如果你的批处理是"调用一次、处理一会儿、再调用一次"的节奏，频繁加载卸载会把整体耗时拉得很高。设成 30 分钟甚至更长，代价是显存被长期占用，收益是响应速度稳定。

3. 编程助手实测：它能接手哪一半活，哪一半别指望

3.1 样板代码与补全：速度本身就是生产力

先说结论：在样板代码生成这个场景里，7B 的表现完全够用，而且本地部署的延迟优势被彻底释放。我拿三个典型任务做了对比：写一个带超时和重试的 HTTP 客户端封装、写一个带分页的列表查询接口、写一个基于信号量的并发限流器。这三个任务都有明确的结构范式，模型不需要"创造"，只需要把正确的模式填进去。

实测下来，Qwen2.5-Coder-7B 在 Q4_K_M 量化、16GB 显存、8K 上下文的配置下，输出速度稳定在每秒 45 到 55 个 token。生成一个六十行左右、带完整错误处理的类，大约四到五秒出完。这个速度带来的体验变化很微妙：当生成一段代码要等二十秒的时候，你会下意识地先自己想清楚再问；当它只要四秒，你就会像用一个非常快的自动补全一样，一边写一边让它填。

质量上，这三个任务一次通过率大概是这样的：HTTP 客户端封装需要我手动改一处（重试次数的边界判断写成了>而不是>=），列表查询接口一次通过，并发限流器把信号量的释放放在了错误的分支里，漏了一种异常情况。也就是说，样板代码大约需要一次轻量修正，修正成本远低于自己从零写。

有一点必须强调：这类任务的正确用法是"给范式"而不是"给需求"。你只说"写一个限流器"，它给你的可能是最简单的计数版本；你如果是贴一段现有的代码风格，说"按这个风格写一个限流器，要求支持突发流量"，它会老老实实按你项目里的命名习惯、日志格式、异常处理方式来写。7B 模型的指令跟随能力不错，但它不会猜你项目的隐性约定。

3.2 缺陷定位与重构：上下文给不够就是白问

这一块是分水岭。同一个 bug，我给三种不同粒度的输入，得到的结果差异大得像是换了三个模型。

第一组测试：一个 Python 脚本，功能是批量处理目录下的文件，但跑起来会漏掉部分文件。第一种输入方式我只贴了报错的函数，大概二十行，模型指出了可能的路径拼接问题，方向对但没命中真正的 bug（真正的原因是遍历时修改了正在迭代的列表）。第二种输入方式我把整个文件（一百四十行）贴进去，模型直接定位到了那个在for循环里对列表做remove的位置，并给出了改成倒序遍历或者生成新列表的两种方案。第三种输入方式我只说"这个脚本会漏文件"，不贴代码——它给的是一堆通用排查建议，基本没用。

这三组结果说明一件事：7B 的缺陷定位能力高度依赖输入完整度，它对局部片段的推理能力有限，但对整段代码的模式识别能力相当好。所以我的实操建议是，分析类请求一律给完整文件，两百行以内直接贴，超过两百行就贴相关函数加上调用链，别只给报错的那几行。

重构任务的表现类似。我测试了把一个两百行的过程式函数拆成四个职责清晰的辅助函数，要求保持外部行为不变。模型给出的拆分方案整体合理，但有两处值得说：一是它把副作用操作（写日志）和纯计算混在了一个函数里，这点需要人工干预；二是它在拆完之后很贴心地补了一段说明，指出哪几个中间变量的作用域发生了变化。这个"主动说明风险"的行为让我有点意外，因为在更小的模型上通常只会闷头给代码。

3.3 正则、SQL 和配置转换这类窄问题

窄问题是最能体现 7B 性价比的地方。这类任务的特点是：领域知识密集、验证成本低、写起来烦。

正则表达式我给了一个真实需求：匹配日志行里的时间戳、级别、线程 ID 和消息体，要求兼容两种不同的日志格式。模型第一次给的方案用了一个非常长的表达式，能匹配但可读性极差。我追问"拆成两步，先用一个表达式判断格式，再分别提取"，它给出了两个短得多的表达式，效果更好。这个交互过程本身说明，7B 在被指出方向后能有效修正，但它倾向于一次给一个"能用但不够优雅"的答案。

SQL 优化是我比较看重的一项。我给了一段带三个子查询和两个LEFT JOIN的语句，让它分析性能瓶颈。它准确地指出了其中一个子查询在WHERE里做聚合会导致无法走索引，建议改写成先聚合再 join 的形式。这个建议是对的。但它同时也给了一个"添加复合索引"的建议，字段顺序排错了，如果照做反而会失效。所以这类建议必须自己过一遍，不能直接采纳。

配置转换我测试了三种：YAML 转 JSON、一段 Shell 脚本转成 Python、一份 Nginx 风格的配置转成另一种等价写法。前两个基本一次通过，第三个在嵌套层级的处理上出了错，把某个继承来的默认值写成了显式值。这类任务里，结构化程度越高的转换越可靠，涉及隐式语义继承的越容易翻车。

3.4 失败样本复盘：它在什么地方必然翻车

不聊失败案例的测评没有参考价值。我记录了几个稳定复现的翻车场景。

第一个是"假装自己读完了"。当我给它一个超过上下文窗口的输入时，它不会报错说"太长了"，而是会安静地只处理前半部分，然后给出一个看起来完整的答案。如果没有显式设置 num_ctx，这个行为会非常隐蔽。我的应对办法是在提示词里明确要求"复述输入的最后一行"，如果不一致就说明被截断了。

第二个是"编造不存在的 API"。当它不确定某个库的具体方法名时，会生成一个命名风格极其合理但根本不存在的方法。这个在测试里出现了至少五次，而且每次的编造都符合该库的命名惯例，看上去毫无破绽。防不住，只能跑一遍。

第三个是"过度自信的错误解释"。问它某段代码为什么慢，如果我给的代码里恰好有一个显眼的循环，它会斩钉截铁地说瓶颈在循环里，即使真正的瓶颈在循环外面的某个 IO 调用上。它倾向于抓住输入里最显眼的特征，而不是做真正的性能分析。

第四个是"多文件一致性"。让它同时改两个互相调用的文件，保持接口签名一致，它经常只改一边。这个能力缺口在 7B 这个量级上基本无法弥补，我的做法是把接口定义单独抽出来作为约束条件贴在提示词里，仍然不能保证。

4. 多语言翻译实测：术语一致性和长文断点才是真正的难点

4.1 中英技术文档：术语稳定性是分水岭

先给一个整体判断：Qwen2.5-7B 的中英互译水平，在技术类文本上明显好于通用翻译工具，但在文学性文本上反而不如。原因在于它的训练数据里技术内容占比高，对技术表达的惯用语掌握得更自然。

我用了三份材料做测试：一份约两千字的产品说明文档、一份带大量代码片段的接口文档、一份偏营销风格的宣传稿。

产品说明文档的翻译结果相当可用。句式自然，没有明显的翻译腔，专业术语的处理也基本正确。但有一个问题浮现了：同一个概念在文档里出现了七次，模型用了四种不同的中文表达。这在单段翻译里看不出来，整篇读下来会很别扭。技术文档最忌讳的就是术语飘移。

接口文档的表现更好，因为代码块、命令、字段名这些它基本都能原样保留不动。唯一出错的地方是一段注释里的缩写，它把cfg展开成了完整单词再翻译，导致译文和代码里的实际变量名对不上。

宣传稿的表现最差。原文里有大量修辞和双关，模型的翻译变成了平铺直叙的说明文，信息传达没错，但语气全丢了。这是 7B 量级的固有限制，它的中文表达能力不足以在保持含义的同时复现修辞效果。

所以中英翻译的正确姿势是：技术文档直接上，营销文案不要指望。

4.2 日语、韩语和小语种的真实水位

官方宣称支持约 29 种语言，但"支持"和"可用"是两回事。我按可用程度做了个粗略分级：

日语这块我特意测了敬语。同样是"请确认附件"，给不同的上下文（对客户、对同事、对下属），模型确实能切换不同的敬语等级，但切换的准确率大概在七成左右，商务场景直接交付有风险。韩语的敬语体系问题类似。

小语种的问题不在词汇，在句法结构。像泰语、越南语这种语序和中文差异较大的语言，模型经常出现半句中文语序、半句目标语序的混搭，读起来能懂但不地道。这类语言建议只用来做"看懂大意"的草稿，正式交付还是得找母语校对。

4.3 术语表注入和回译校验的工程做法

术语一致性这个问题的解法很直接：把术语表塞进提示词，然后强制它在译文里使用指定译法。

具体做法是在系统提示词里加一段结构化的术语约束：

术语表（必须严格遵守，左侧为原文，右侧为指定译文）： - throughput → 吞吐量 - backpressure → 背压 - idempotent → 幂等 - eventual consistency → 最终一致性 - circuit breaker → 熔断器

实测下来，只要术语表长度控制在三十条以内，遵守率接近百分之百；超过五十条之后开始出现遗漏，通常是排在中间位置的条目被跳过。所以术语表要分批注入，或者按段落相关性动态筛选——只把当前段落涉及的术语放进提示词。

回译校验是我更推荐的工程化手段，尤其在没有人工校对资源的时候。流程是：原文 → 译文 → 把译文再翻回原文语言 → 对比两次原文的语义差异。如果回译结果和原始文本在关键信息上出现偏离，说明中间那一跳出了问题。

这个流程可以直接用脚本自动化：

import requests, json def chat(model, system, user, num_ctx=8192): payload = { "model": model, "messages": [ {"role": "system", "content": system}, {"role": "user", "content": user}, ], "stream": False, "options": { "num_ctx": num_ctx, "temperature": 0.2, "top_p": 0.9, "repeat_penalty": 1.02, }, } r = requests.post("http://127.0.0.1:11434/api/chat", json=payload, timeout=300) r.raise_for_status() return r.json()["message"]["content"] src = "系统在流量突增时会触发熔断器，将请求快速失败..." trans_sys = "你是技术文档译员，严格按术语表翻译，只输出译文。" back_sys = "你是技术文档译员，将英文技术文档翻译为中文，只输出译文。" en = chat("translator-local", trans_sys, src) back = chat("translator-local", back_sys, en) print("译文:", en) print("回译:", back)

回译不需要人工逐字比对，用一个简单的相似度过滤就行：看着差异明显的段落，人工过一眼。我的实际经验是，这个流程能筛出大约八成五的严重错译，剩下的漏网之鱼主要是一些"翻译得很通顺但语义微妙偏移"的情况，这类只能靠人。

4.4 长文档的切分与上下文锚定

一份两万字的文档肯定塞不进 16K 上下文，必须切。但切分方式对译文质量影响极大，这点很多人没意识到。

最差的切法是按固定字数切，切点经常落在句子中间，模型拿到一个半截句子，会自行脑补开头或者结尾，导致译文出现原文里根本没有的内容。稍好一点的是按段落切，但相邻段落之间的指代关系会断掉——上一段说"该模块"，下一段开头说"它"，模型就不知道"它"是什么了。

我现在的做法是三层锚定：

第一层是术语锚定，每段都带上筛选后的相关术语表，保证跨段一致性。

第二层是上下文锚定，切分时保留前一段的最后两三句话作为前情，标记为"仅供理解上下文，不要翻译"，然后接上当前段落。这样指代关系能接上，又不会重复翻译。

第三层是结构锚定，在提示词里告知当前段落在全文中的位置，比如"这是第 4 节，前面讲了架构设计，后面会讲部署"，模型对语气的把握会更连贯。

实测下来，这套做法比裸切段的译文一致性提升非常明显，尤其是那种大量使用代词的文档。代价是每次请求的 token 数增加，处理速度慢一些，但这个交换是值得的。

5. 参数与提示词的调优配方

5.1 温度、top_p、重复惩罚的组合边界

这三个参数在不同任务上的最优区间差别很大，我把自己试出来的组合整理成了一张对照表：

一个容易踩的坑是把 repeat_penalty 设太高。这个参数的本意是压制重复生成，但设到 1.2 以上之后，模型会把正常的重复也当成问题规避，表现出来就是专业术语被换成同义词，代码里该复用的变量名被强行改掉。我在测试里设过 1.3，结果一段代码里同一个变量被改了四次名字，直接不可用。经验值是不超过 1.15。

另一个坑是 temperature 设 0 不等于完全确定性。受浮点运算和批处理顺序影响，同一个提示词两次调用仍可能给出不同结果，只是差异很小。如果你需要严格可复现的输出，得靠固定随机种子，而 Ollama 在这方面给的接口比较有限，稳妥做法是把结果缓存下来。

5.2 两套系统提示词的实际写法

系统提示词的写法比参数影响更大。我在测试里对比过三种风格：没有任何系统提示词、简短一句话、详细列表约束。结果差异非常直观——第三种在格式遵循度上比第一种高出一大截，尤其是在"只输出译文不要解释"这类要求上。

有效的系统提示词有几个共同点。第一是用肯定句描述期望行为，而不是用否定句列举禁止行为。说"给出的代码必须完整可运行"，效果好于"不要用省略号"。

第二是约束要可检验。"保持专业性"这种无法检验，"代码块保持原样，不翻译"就可以检验。

第三是数量控制在五条以内。超过五条之后，模型对前面条目的注意力会下降，表现出来就是后面的规则被遵守、前面的被忽略。我试过写十二条，结果最关键的"只输出译文"这条被完全无视了，前面加了半天解释。

还有一个细节值得说：系统提示词里的示例极具影响力。给它一个输入输出的标准示例，比写三段规则都管用。比如在翻译任务里加一组"输入：xxx / 输出：yyy"的示例，格式遵循度会立刻稳定下来。

5.3 批量调用时的并发与限流

批量处理最容易出的事不是模型能力问题，是资源调度问题。我最初的脚本用八个线程并发调用，跑了两百条就崩了，日志里全是超时和连接重置。

原因是每个请求都要预填充上下文，八路并发瞬间吃掉的显存远超单路，运行时开始不断换入换出，速度崩到每秒两三个 token，然后就是超时。

解决办法是控制并发数。在显存不变的前提下，并发数大致可以参考这个经验公式：可用显存减去模型权重和单路 KV 缓存之后，剩余的余量除以单路 KV 缓存大小。比如 12GB 卡上跑 Q4_K_M（5.5GB，含 8K 缓存），余量约 6GB，单路缓存约 0.46GB，理论上能开十路以上，但实际上要留足计算缓冲，我一般开两到三路。

另一个优化点是合并请求。如果一批文本都不长，与其一条一条发，不如把五条拼成一个请求，用明确的分隔符隔开，让模型逐条输出。这样能省掉大量重复的预填充开销，整体吞吐量能提升两三倍。代价是输出格式可能不稳定，需要更严格的提示词约束和结果解析。

import requests, time def batch_translate(lines, model="translator-local", batch_size=5): results = [] for i in range(0, len(lines), batch_size): chunk = lines[i:i + batch_size] numbered = "\n".join(f"[{j+1}] {t}" for j, t in enumerate(chunk)) prompt = ( "将下列编号条目逐条翻译为中文，保持编号格式，" "每条独占一行，不要合并，不要添加说明：\n" + numbered ) payload = { "model": model, "messages": [{"role": "user", "content": prompt}], "stream": False, "options": {"num_ctx": 8192, "temperature": 0.25, "top_p": 0.9}, "keep_alive": "30m", } r = requests.post("http://127.0.0.1:11434/api/chat", json=payload, timeout=300) results.append(r.json()["message"]["content"]) time.sleep(0.2) # 给运行时留出回收显存的间隙 return results

sleep那一行看着多余，实际上很有必要。连续高压请求时，运行时的显存回收可能滞后于请求下发速度，加一个短暂间隔能显著降低 OOM 概率。

6. 我踩过的坑和对应的处置方式

6.1 输出突然变短、变蠢、变成重复的废话

这个现象我遇到过三次，每次原因都不一样。

第一次是 num_ctx 设得太小，长输入被截断，模型只看到了半截提示词，输出自然莫名其妙。判断方法是让它复述输入结尾。

第二次是 num_predict 设得太小。这个参数限制的是输出长度，默认值在某些版本里并不大，一旦你的任务是"翻译一份长文档"，模型会在写到一半时戛然而止，而且不报错。改成 4096 之后问题消失。

第三次是模型被频繁加载卸载导致的状态异常。keep_alive太短，模型刚热起来就被卸载，下一次请求重新加载，第一次输出质量明显偏低。这个现象很隐蔽，因为后续请求会恢复正常，容易让人以为是提示词的问题。把keep_alive调长之后就再也没出现过。

还有一种"变蠢"是上下文污染。同一个会话里聊了十几轮之后，早期的无关内容会持续占据上下文，稀释掉当前任务的信息密度。7B 模型在这种情况下的表现退化比大模型更明显。我的做法是任务切换时一定新开会话，不复用。

6.2 代码块包裹异常和中文标点混乱

这两个是输出格式层面的问题，不致命但很烦。

代码块包裹异常的表现是：让它输出一段代码，它给你包了三层反引号，或者开头有反引号结尾没有。批量处理时这会直接导致解析失败。解决方案是在系统提示词里明确"代码块使用三反引号包裹，并标注语言类型"，同时在解析端做容错——用正则匹配所有反引号块，取最长的那一段作为代码内容，比严格匹配可靠得多。

中文标点混乱主要出现在中英混排的场景。模型会在中文句子里用英文逗号，或者在代码注释里用全角括号。这类问题靠提示词约束效果有限，我一般在后处理阶段做统一替换：非代码区域的全角标点统一转半角，代码块内部的保持原样。判断代码区域的方法很简单，按三反引号切分，奇数段是代码，偶数段是正文。

6.3 显存溢出的三个真实诱因

OOM 是最常见的崩溃原因，我整理了自己遇到的三个诱因，按出现频率排序。

诱因一：上下文长度和并发数叠加。这是最常见的。单独跑 16K 上下文没事，单独开四路并发也没事，两个一起就崩。处置方式是先用单路跑通，再逐步加并发，每加一路用ollama ps确认显存占用。

诱因二：短时间内的连续大请求。显存释放有延迟，前一个请求结束之后缓存不会立刻回收，如果下一个请求紧接着到来，峰值占用是两个请求的叠加。处置方式是加请求间隔，或者显式设置OLLAMA_NUM_PARALLEL=1让请求排队。

诱因三：其他程序占用显存。这个最容易被忽略。浏览器开着硬件加速、编辑器开了 GPU 渲染、系统里还挂着别的推理进程，这些都会吃掉几百兆到一两 G。我现在的习惯是跑批量任务之前先看一眼显存占用基线，留出至少 1.5GB 的余量再决定用哪个量化档位。

注意：显存不够时 Ollama 会自动把部分层卸载到 CPU 上运行，表现为速度暴跌但不报错。如果你发现生成速度突然从每秒四五十 token 掉到个位数，先查ollama ps里的 PROCESSOR 那一列，而不是怀疑模型。

关于量化档位的选择，我最后补一个实战建议：如果你只有 8GB 显存，就用 Q4_K_M 配 8K 上下文，别贪心去开 16K；如果你有 12GB，Q5_K_M 配 16K 是我试过的最舒服的组合，质量和速度都够；如果有 16GB 以上，Q6_K 配 32K 能覆盖绝大多数日常任务。Q8_0 和 FP16 除非你要做量化损失对照实验，否则没必要——多出来的显存换来的质量提升，在实际任务里基本感知不到，但上下文窗口翻倍带来的收益是实实在在的。

我个人在实际使用中的体会是，7B 这个档位的模型最适合的定位不是"替代在线服务"，而是"承担那些不值得调用在线服务的活"。写样板代码、翻译技术文档、解释一段看不懂的代码、把一份配置转成另一种格式——这些任务本身不复杂，但量大、琐碎、随时会发生。把它们交给一个本地跑着、响应只要几秒、不消耗额度、内容不出本机的模型，整个工作流的节奏会顺很多。至于那些真正需要思考的难题，该用更大的模型还是用更大的模型，7B 顶不上。