翻译模型这三年出了太多，多到没人再为一次「效果提升」发新闻。真正稀罕的是另一种消息：一家把翻译当正经生意做的公司，把自己在服务里用的模型权重，原样放了出来。PLaMo 3 Translate 这次上架 Hugging Face，给了 0.8B、2B、8B、31B 四个尺寸——注意，是四个一起给，不是先放个大的刷榜、再挤牙膏似的补小的。
这件事的看点不在参数量，在于它把「翻译模型该放在哪里跑」这个问题，从工程细节变成了公开选项。一个 0.8B 的翻译模型意味着什么？意味着断网的设备也能翻。这一句话，抵得上十篇技术报告。
四个尺寸摆上桌，本质是一道部署选择题
大多数团队发布模型，习惯给一个大而全的旗舰，顶多再配个小的当赠品。PFN 这次的做法不太一样，四个尺寸跨度接近 40 倍，摆明了不是让你挑最好的那个，而是让你挑最合适的那个。
0.8B 和 2B 不是缩水版
很多人看到小参数，第一反应是「效果打折的替代品」。这个判断在通用对话模型上也许成立，放到翻译任务上就要重新算。翻译是一个输入输出高度对齐、任务边界相当收敛的场景，模型不需要同时会写代码、会做数学、会编故事。参数里省下来的空间，本来就有相当一部分是通用能力，砍掉不心疼。
0.8B 落在什么位置？大概是一部中端手机、一台平板、一个嵌入式盒子能够安放的范围。量化之后，内存占用可以压到相当克制的水平，不联网、不上传、不依赖任何服务端。2B 则给了笔记本和一些边缘设备更宽裕的余量，质量和小尺寸之间取一个中间点。这两个尺寸的真正价值，是让「本地翻译」从演示变成了可交付的产品形态。
8B 与 31B 守的是质量上限
8B 是这两年最舒服的一档，单卡能跑，吞吐够用，质量已经能覆盖绝大多数日常翻译需求。它适合那些有服务器、但对成本敏感的团队——比如做跨境电商详情页、客服工单、内部文档流转的公司。31B 则是给质量优先的场景准备的，长文档、专业领域、术语密集的材料，参数量带来的上下文稳定性和表达一致性，是很难用提示词补回来的。
值得注意的是，翻译任务对「大」的回报不像推理任务那么陡峭。8B 到 31B 之间，提升往往是细节层面的：术语前后一致、长句断句更自然、罕见语言对不至于崩。这些细节对 C 端用户可能是「感觉好一点」，对 B 端交付却是「能不能验收」的分界线。
尺寸跨度本身就是一套产品矩阵
把四个尺寸连起来看，会发现它覆盖的是一条完整的部署曲线：离线耳机和手持设备用 0.8B，端侧应用和隐私敏感场景用 2B，私有化部署用 8B，云端服务用 31B。同一套模型家族、同一套接口约定、同一套评测口径，迁移成本被压得很低。
这比单纯放出一个最强模型要聪明。开发者的真实困境从来不是「找不到好模型」，而是「找到好模型之后发现它跑不起来」。
翻译特化，特化的到底是什么
通用大模型做翻译，问题不在效果
拿一个通用大模型去翻译，随手写个提示词，效果往往出人意料地好。那为什么还要专门做翻译模型？答案不在峰值质量，在稳定性。
通用模型的输出是发散的。同一段话译两遍，格式可能不一样；加上一句「请只输出译文」，它偶尔还是会先来一段「好的，以下是翻译」。翻译产品的下游通常是一条流水线，格式一旦漂移，解析就崩。更麻烦的是术语：一个产品名、一个法律概念，前面译成 A，后面译成 B，用户立刻能感觉到不专业。
翻译特化模型要解决的正是这些「不上台面但致命」的问题：输出格式严格可控、术语表可注入、长文档分段后上下文不断裂、低资源语言对不至于胡编。这些能力靠提示词调不出来，只能靠训练阶段的取舍。
专用模型的取舍更难
把通用模型改造成翻译专用，听起来像是个数据工程问题——多喂点平行语料就行。实际情况要复杂。语料的质量分布、语言对的配比、领域覆盖的偏斜，每一项都会在最终模型上放大成明显的行为差异。
还有一个绕不开的取舍：小模型在多语言对上的容量分配。0.8B 的模型不可能把上百个语言对都做得一样好，必然要在高频语言对上集中火力，对低频语言对做妥协。这种妥协是否合理，取决于发布方对使用场景的判断——而 PFN 自己运营翻译服务，它对这个判断有真实的数据支撑，这大概也是它敢一次性放四个尺寸的底气。
端侧翻译这事，卡点从来不在模型
为什么本地翻译一直被搁置
离线翻译不是新概念。十年前的手机里就装着统计机器翻译的小引擎，效果勉强能看菜单。深度学习上来之后，模型变大，端侧这条路反而断了几年。
真正的障碍有几个：内存不够，模型加载不进去；功耗太高，跑几分钟手机发烫；量化之后质量掉得厉害，尤其小模型对量化误差更敏感；多语言切换需要反复加载不同模型，体验割裂。所以端侧翻译的突破，从来不是「把模型做小」一件事，而是整条链路都要重新设计。
0.8B 能做什么、不能做什么
用现实的眼光看：短句翻译、菜单路牌、即时对话、常见语言对，0.8B 完全够用，而且响应速度比走网络快得多。但别指望它处理几十页的合同、满是缩写的技术手册，或者特别冷门的语言组合。它的定位是「随手可用的翻译」，不是「替代专业译员」。
这个定位其实很健康。翻译需求里，高频的、短平快的部分占了绝大多数，而这部分恰好是最不该付网络延迟和隐私代价的。
本地化部署的另一重意义
数据不出设备，这句话在消费场景是隐私，在行业场景是合规。医院里的病历、律所的案卷、工厂里的工艺文档，很多根本不允许上传到外部服务。以前这些场景要么人工翻译，要么放弃。一个能本地运行的翻译模型，打开的是之前被合规挡住的市场。
再往远一点看，网络不稳定的环境——远洋、野外、灾后现场——本地翻译是刚需而不是优化项。
开放权重是策略，不是情怀
PFN 在赌什么
把服务里正在用的模型权重放出来，听起来像是自断财路。但仔细想想这笔账：权重免费，服务收费；模型开源，推理基础设施和行业方案仍然是生意。开放权重换来的是生态、反馈和标准话语权——当一堆团队基于 PLaMo 3 Translate 搭产品时，PFN 就成了这个细分领域默认定点。
还有一层：它自己做 AI 芯片和算力平台。模型越多人用，对高效推理的需求越大，这条链路的想象空间比卖 API 大得多。
开发者该关注什么
别急着下载。先看三件事：许可证条款对商用是否友好，这决定了能不能进产品；官方是否提供量化版本和常见推理框架的适配，这决定了落地要花多少功夫；语言对的实际覆盖和质量分布，这决定了它是否匹配你的场景。
然后做一件最朴素的事：拿你自己的真实语料跑一遍，别看榜单。翻译模型的榜单分数和实际体感之间，隔着术语、格式、领域偏斜三座山。跑通了，再谈集成。
四个尺寸摆在那里，选哪个不是技术问题，是你打算把翻译放在离用户多近的地方。
