ollama 翻译模型推荐

用 Ollama 跑翻译，卡点通常不在「哪个模型最强」，而在这段文本该配多大的模型、量化选哪档、中文和日韩小语种要不要分开对待。这篇不讲榜单排名，给的是按语言方向、体量和内存三件事排列的选型顺序，以及上线前用几十句真实句对验证的固定动作。

用 Ollama 跑翻译，卡点通常不在「哪个模型最强」，而在这段文本该配多大的模型、量化选哪档、中文和日韩小语种要不要分开对待。很多人一上来就找榜单，结果装了个大模型，显存刚好卡住，跑一条翻半天，反而不如小模型顺手。

这篇不讲排名，给的是按语言方向、体量和内存三件事排列的选型顺序，以及上线前用几十句真实句对验证的固定动作。下面的判断标准都能直接拿去用，但具体数字请到站内对应页面看当时的记录，别照搬别人截图里的参数。

先定语言方向，再谈模型大小

中英互译和「中译小语种」其实是两条不同的路。前者主流通用对话模型基本都能干，差别主要在语气和术语；后者就得优先找训练语料里该语种占比高的模型家族，否则翻出来像机翻加生硬润色。

• 对语言方向的方法是：先列出你实际要翻的语种对，再看每个语种对上候选模型在语料上的专精度，而不是看综合能力。
• 多语言覆盖广不等于每个语种都好，覆盖语种多的模型往往在单个小语种上不如专精的那个。
• 什么情况下不适用：如果只是偶尔翻几句、能接受人工顺一遍，直接用手上已有的通用模型就够了，不必为语种专门挑。

按体量和量化档位挑：三档够用

体量大致可以分三档来用，不必纠结每个数字的细微差别。小体量档适合术语固定、句式简单的批量文本，比如商品标题、字段名，速度快、显存占用低，质量波动也大，适合先跑通流程。

1. 小体量档用在术语表可控、句式短的批量场景；做法是先跑两百条看错误率，能接受就继续，错了就整体升级一档。
2. 中等体量档大多数人的默认选择。长句和技术文档用它，错误类型从「整句崩」变成「个别词不准」，好校对，性价比最稳。
3. 大体量档留给法律、合同、论文这类需要长上下文和术语一致性的文本，代价是显存和等待时间都明显上升，先确认机器扛得住再上。

量化档位的选择思路是：显存紧张时先降量化再考虑降参数量，因为降参数量往往直接把语言能力砍掉一截。具体每档的显存取舍到 /tools 里的换算工具算一遍，别凭感觉估，也别直接抄别人的配置单。

对一遍显存和并发，别等跑起来才发现放不下

选好模型后先做一次落位检查，不然装好了发现放不下，或者勉强放下但一并发就 OOM，白折腾一轮。先用站内部署测算页把「模型体量 + 量化档位 + 上下文长度」三项填进去，得到占用估算，再决定能不能常驻在显存里。

上下文长度

翻译任务的输入输出通常都比闲聊长，按「原文 + 译文」两边一起留，别只按一边算。

并发数

要并发处理多条文本时，KV 缓存会随并发数线性上涨，具体倍数关系和排查顺序看 /compute/sizing。

常驻与否

如果显存放不下常驻，每次请求都要重新加载，延迟会明显变差，这类场景宁可换小一档模型。

什么情况下不适用：单机单人、一次翻一段的场景不用算并发，把单条跑通就行，把注意力放在验证句对上更有价值。

上线前用固定句对跑一轮验证

选型最后一步不是看评测页，而是自己跑一批真实句子。准备三十到五十句真实业务句对，覆盖最长句、术语密集句、数字与单位混排句，三类各占一部分，长度从短到长都要有。

1. 准备句对从历史工单或真实文档里摘，别用网上通用例句，否则验证结果和你的实际场景对不上。
2. 同參数对比同一批句子在同一温度设置下跑两三个候选模型，人工只标「可用 / 需小改 / 重译」三档，别打细分数，细分数结果不稳定也不好比较。
3. 看错误类型重点看错误类型而不是错误数量：术语错可以加词典修，语序乱和漏译属模型能力问题，加提示词救不回来。
4. 记录存档把验证结果连同当时的模型名和参数记下来，之后换版本时同一批句子再跑一遍，差异一眼可见，参考 /tools/quality-check 的做法。

换模型、换版本前的检查动作

上线一段时间后总会遇到换模型或换版本的情况，这时候最怕的是「悄悄变了」。下面这几步是固定动作，做一遍能把大部分意外挡在切换之前。

• 模型仓库里的同名条目会随上游更新替换，之前跑通的版本过一阵可能行为变了，条件允许就锁定具体 tag 而不是沿用默认最新。
• 换模型前先确认量化格式和你的运行时是否兼容，格式不匹配时表现是加载失败或速度骤降，不是翻译变差，别误判成模型不行。
• 许可证要单独看一眼：商用与否、是否需要署名，不能从「能下载」推断，判断方法参考站内开源权重许可相关内容。
• 迁移顺序建议：先跑验证句对 → 再切线上 → 保留回退用的旧 tag，一次只动一个变量。

换模型前先跑固定句对，比换完之后再回头找问题省事得多。