4B模型打赢27B基线，谷歌把翻译模型塞进笔记本

把用户文本发到别人的服务器上，按字符付费，一直付下去——这是几乎所有翻译API的共同形状。账单随业务增长而增长，而对内部HR工具、医疗问诊表单、法律聊天记录这类产品来说，把文本送出去本身就是一场合规对话的开端。

TranslateGemma 是谷歌给出的一个替代方案：一组开放权重的翻译模型，能在笔记本上跑，覆盖 55 种经过基准测试的语言（包括孟加拉语），按字符计费为零。它在 2026 年 1 月发布，本周重新回到 Hacker News 首页，正好值得把"自己跑起来到底要做什么"拆一遍。

先说明一点：下面的质量数字来自谷歌的技术报告和发布博客，不是我自己跑出来的基准测试。代码改编自谷歌官方模型卡。

它到底是什么

谷歌把 Gemini 模型蒸馏成三个开放权重的翻译器，基于 Gemma 3 架构，参数规模分别是 4B、12B、27B。训练分两阶段：先用平行数据做监督微调，数据混合了人工翻译文本和 Gemini 生成的合成翻译，以覆盖包括低资源语言在内的广泛语种；再用一组奖励模型做强化学习，把翻译推向语境准确，而不是逐词对应。

谷歌在 WMT24++ 基准上用 MetricX 评测，结论有三条：

• 12B 模型超过 Gemma 3 27B 基线，用不到一半的参数打赢了两倍体量的模型。
• 4B 模型逼近更大的 12B 基线，所以谷歌把它定位给手机和边缘设备。
• 27B 是质量天花板，单张 H100 或 TPU 就能装下。

55 种语言是严格基准测试的那一档，孟加拉语在其中（bn 和 bn-IN 都支持）。聊天模板实际带了大约 160 种语言，发布报道也提到训练覆盖了基准集之外的数百个语言对，所以 55 这个数字是质量保证，不是硬墙。

还有一个能力值得知道：模型保留了 Gemma 3 的视觉输入。你可以给它一张路牌或表单的照片，直接拿到提取并翻译后的文本，不需要单独的 OCR 步骤。

装之前：许可证不是纯开源

TranslateGemma 按 Gemma 使用条款分发。它允许商用、修改和再分发，但不是 OSI 认可的开源许可证。你需要把条款传递给用户，部分应用在谷歌的禁止使用政策下不被允许。

实操上：必须在登录状态下于 Hugging Face 接受许可，权重才能下载。如果 CI 匿名拉模型，会因 gated-repo 报错失败。生成一个 token，接受一次许可，导出 HF_TOKEN。

路径一：用 transformers 快速试

在有 GPU 的机器上看输出，这是最快的方式。image-text-to-text 管道同时处理文本和图像输入。消息结构看起来有点怪，而且是故意怪的：只支持 user 和 assistant 两种角色，content 列表必须恰好一项，这一项要同时带 source_lang_code 和 target_lang_code。语言码用 ISO 639-1，可选加 ISO 3166-1 国家码，en、en-US、bn、bn-IN 都能用。

严格的地方在于：传入不支持的代码，应用模板会直接报错而不是猜。开发时烦人，生产里有用——API 层可以接住它，返回干净的 400，而不是悄悄翻成错误的语言。

路径二：用 vLLM 起服务

真实负载需要带批处理的常驻服务，vLLM 两条命令就能给出一个 OpenAI 兼容端点：pip install vllm，然后 vllm serve google/translategemma-4b-it。之后任何 HTTP 客户端都能打。注意请求体仍然用模型自己的消息结构，不是纯文本提示。SGLang 和 Docker Model Runner 同样支持，想用托管基础设施也可以部署到 Vertex AI。在 vLLM 前面套一个小的 FastAPI 包装层，把 {"text": "...", "to": "bn"} 映射进消息结构、并按模板校验语言码，大约五十行就能变成一个可替换的内部翻译服务。

被低估的功能：翻译图片里的文字

视觉输入在微调后活了下来，尽管谷歌并没有专门针对图像训练翻译。这意味着你可以喂一张照片，一次调用拿回提取并翻译好的文本。消息结构和文本翻译一样，只是把 text 字段换成 url。

想想它替代了什么：传统流水线是 OCR 引擎、版面解析、句子切分、再调一次翻译，四个阶段各有各的失败方式。一次调用在密集文档的准确率上打不过这套栈，但对用户拍路牌、药品标签、水电账单这类场景，它省掉了整个集成。图像会被归一化到 896x896、切成 256 个 token，所以整页小字扫描会丢细节，发送前裁到关键区域。

按硬件选型

粗略显存参考（bfloat16 权重的估算，不是谷歌公布的数字）：

• 4B：约 8 GB 显存，消费级笔记本 GPU 上很舒服，能忍慢速的话 CPU 也能用。这是谷歌为手机做的那个。
• 12B：全精度约 24 GB。在 24 GB 统一内存的笔记本上，量化版本更从容。这是甜点位——它就是评测里打赢 27B 基线的那个尺寸。
• 27B：全精度约 54 GB，现实点说就是单张 H100、TPU，或者激进量化。

总输入上下文是 2K token，图像归一化到 896x896、每张占 256 token。这意味着长文档必须在客户端切块后再进模型。从第一天就把切块写进包装层，这是 demo 和可用服务之间最常见的那个缺口。

动手前要知道的坑

• 它只翻译，不聊天。微调把模型 specialization 得很彻底，用目标语言做通用对话或摘要不在设计范围内，超出翻译之外的事情配一个通用模型是更稳的架构。
• 正式度和方言是弱项，要测。孟加拉语、日语、韩语都编码了礼貌层级，一个 2K token、句子尺度的模型可能把它们压平。这正是你自己的评测集在铺开前该探的地方。
• 数字、人名、代码需要保护。和任何神经机器翻译系统一样，文本里的产品名、标识符、代码片段可能被弄坏。翻译前遮罩、翻译后还原，这是值得写进包装层的标准前后处理。
• 基准档是英语中心的。WMT24++ 评的是英语到 X 和 X 到英语。两个非英语语言之间的直接语言对在模板里存在，但不在最强的公开保证范围内；质量下降时，在包装层里绕道英语。

决策矩阵：什么时候自托管赢

在拆掉云 API 之前，诚实给自己的情况打分：

• 高而稳定的量：自托管。按谷歌云翻译每百万字符约 20 美元的标价，一个持续翻译用户内容的产品几个月就能把一张 GPU 的钱省回来。偶发低量调用还是云 API 划算。
• 敏感文本：自托管。医疗、法律、HR 或不该离开你基础设施的内部文本，没有替代品。
• 离线或边缘部署：自托管。4B 模型能在设备上跑，断网时没有任何 API 调用能活下来。
• 难语言对的峰值质量：云大概率还是赢。谷歌报告显示 TranslateGemma 超过了自己的基线，但完整的 Gemini 级系统在最难的低资源语言对上仍然领先。承诺之前先用自己的数据验证。
• 零运维能力：云。托管 API 从不需要在凌晨两点更新 CUDA 驱动。

建议的起点：本地跑 4B 做原型和冒烟测试，用你领域里几百句真实句子把 12B 和云端输出对比评测，只有 12B 明显不够时才上 27B。验证很便宜，生产里发现选错了不便宜。

如果你要评它，就量它。谷歌的数字是 MetricX 和 WMT24++ 产出的，你不需要他们的测试框架，但你需要比"读三个输出然后点头"更诚实的东西。回译一个样本（译到目标语言再译回来，比较语义保留），或者用开放的质量评估指标打分，并保持测试集固定，这样未来的模型升级才可比较。