机器翻译的痛点从来不是"能不能翻"，而是"翻得准不准、听不听指令"。术语要锁定、风格要切换、方言要识别——这些需求在大模型时代反而更突出了。腾讯混元团队刚开源了 Hy-MT2 翻译模型家族，三个尺寸覆盖从轻量部署到高精度场景，还带了一个专门测"翻译模型到底听不听话"的 IFMTBench。值得认真看看。
三个尺寸，各有定位
Hy-MT2 这次开源了三个模型：
| 模型 | 参数量 | 适用场景 |
|---|---|---|
| Hy-MT2-1.8B | 1.8B 全参数 | 边缘设备、移动端、低延迟在线服务 |
| Hy-MT2-7B | 7B 全参数 | 通用翻译、性价比主力 |
| Hy-MT2-30B-A3B | 30B 总参数 / 3B 激活参数 | MoE 架构，高精度 + 推理成本可控 |
三个模型统一支持 33 个语种互译，外加 5 种民汉/方言（粤语、闽南语等和标准中文之间的翻译）。这意味着你不用为"粤语→英文"这种组合单独找模型了，一个模型直接覆盖。
30B-A3B 这个 MoE 设计值得注意：总参数 30B 保证知识容量，但每次推理只激活 3B，实际推理成本接近 7B 级别。对需要高质量又不想扛 30B 全量推理开销的团队来说，这是个务实选择。
IFMTBench：翻译模型的"听话程度"测试
翻译不只是逐字转换。实际业务里常见这些要求：
- 术语锁定：公司产品名必须翻成指定词，不能自由发挥
- 风格切换：同一句话，正式公文版和社交媒体版完全不同
- 格式保留：翻译后保持原文的 Markdown 结构、代码块边界
- 局部翻译：只翻某一段，其余保持原文不动
IFMTBench 就是针对这类需求设计的测试集。指令和待翻译文本覆盖多个语种，评测维度聚焦在"模型是否准确遵循了翻译相关的指令"，而不是泛泛的通用能力。
这个测试集的实用价值在于：它给了你一个筛选标准。如果你在评估多个翻译模型，跑一遍 IFMTBench 就能看出谁在"听指令"这件事上更靠谱，而不是只看 BLEU 分数。
实践：用 Transformers 加载 Hy-MT2-7B 做翻译
模型已开源，假设发布在 HuggingFace 上（实际仓库名以官方发布为准），以下是一个可直接运行的推理脚本：
# 安装依赖
# pip install transformers accelerate sentencepiece
import torch
from transformers import AutoModelForCausalLM, AutoTokenizer
# 模型仓库名以腾讯混元官方发布为准，此处为示例
MODEL_ID = "tencent/Hy-MT2-7B"
tokenizer = AutoTokenizer.from_pretrained(MODEL_ID, trust_remote_code=True)
model = AutoModelForCausalLM.from_pretrained(
MODEL_ID,
torch_dtype=torch.bfloat16,
device_map="auto",
trust_remote_code=True,
)
def translate(text: str, src_lang: str, tgt_lang: str, style: str = None) -> str:
"""通用翻译函数，支持可选的风格指令"""
prompt = f"将以下{src_lang}文本翻译为{tgt_lang}，保持原文语义准确。"
if style:
prompt += f" 翻译风格要求：{style}。"
inputs = tokenizer(prompt, return_tensors="pt").to(model.device)
outputs = model.generate(
**inputs,
max_new_tokens=512,
temperature=0.3, # 翻译任务用低温度，减少随机性
top_p=0.85,
do_sample=True,
repetition_penalty=1.1,
)
# 只取生成部分，去掉 prompt
generated = outputs[0][inputs["input_ids"].shape[-1]:]
return tokenizer.decode(generated, skip_special_tokens=True).strip()
# 基础翻译：粤语 → 英文
result = translate(
text="佢今日好开心，因为买到心仪嘅礼物。",
src_lang="粤语",
tgt_lang="英文",
)
print(result)
# 带风格指令的翻译：中文 → 日文，要求商务正式风格
result = translate(
text="我们希望在本季度完成合作协议的签署。",
src_lang="中文",
tgt_lang="日文",
style="商务正式用语，使用敬语形式",
)
print(result)
# 术语锁定翻译：指定产品名不翻译
result = translate(
text="腾讯混元大模型在多语种翻译任务上表现优异。",
src_lang="中文",
tgt_lang="英文",
style="术语'腾讯混元'保持原文不翻译，翻译为 Tencent Hunyuan",
)
print(result)
运行前注意：修改 MODEL_ID 为腾讯混元官方公布的实际仓库路径。7B 模型 bfloat16 加载约需 14GB 显存，单卡 A10/3090 即可运行。1.8B 模型更轻，甚至可以 CPU 推理（速度慢但可行）。
MoE 模型的部署差异
如果你选 Hy-MT2-30B-A3B，推理框架的选择会影响实际体验：
# 方案一：Transformers 直接加载（适合调试和低并发）
python -c "
from transformers import AutoModelForCausalLM
model = AutoModelForCausalLM.from_pretrained(
'tencent/Hy-MT2-30B-A3B',
torch_dtype=torch.bfloat16,
device_map='auto',
trust_remote_code=True,
)
print(f'模型参数量: {model.num_parameters():,}')
"
# 方案二：vLLM 部署（适合生产环境高并发）
# pip install vllm
python -m vllm.entrypoints.openai.api_server \
--model tencent/Hy-MT2-30B-A3B \
--trust-remote-code \
--dtype bfloat16 \
--max-model-len 4096 \
--gpu-memory-utilization 0.9 \
--port 8000
# 然后用 OpenAI 兼容接口调用
curl http://localhost:8000/v1/chat/completions \
-H "Content-Type: application/json" \
-d '{
"model": "tencent/Hy-MT2-30B-A3B",
"messages": [
{"role": "user", "content": "将以下中文翻译为法文：人工智能正在改变翻译行业的格局。"}
],
"temperature": 0.3,
"max_tokens": 256
}'
MoE 模型在 vLLM 下需要注意显存分配：30B 总参数需要约 60GB 显存存储权重（bfloat16），但推理时每个 token 只激活 3B 参数的计算量，吞吐量接近 7B 密集模型。双卡 A100（80GB×2）是稳妥配置。
选型建议和注意事项
选哪个尺寸？
- 1.8B：适合嵌入 App、浏览器插件、实时对话翻译。精度够用但不适合长文和复杂指令。
- 7B：大多数团队的首选。单卡部署，33 语种覆盖，指令遵循能力够强。
- 30B-A3B：对翻译质量有硬性要求的场景——法律合同、医学文献、多语种内容运营。推理成本比密集 30B 低得多，但部署门槛更高。
风险和边界：
- 方言翻译的数据覆盖可能不均匀，粤语资源多，其他方言可能偏少，实际效果需要在你自己的语料上验证。
- MoE 模型的推理框架兼容性还在快速迭代，vLLM 对 MoE 的支持需要确认版本匹配。
- IFMTBench 是翻译指令遵循的专项测试，不代表通用 NLU 能力，选模型时别只看这一个分数。
落地检查清单：
- 确认你的高频语种组合在 33 语种列表里
- 用 IFMTBench 跑一遍你关注的指令类型（术语、风格、格式）
- 在自有业务数据上做小规模对比测试，不要只看官方 benchmark
- 根据并发和延迟需求选尺寸，7B 是稳妥起点
- MoE 部署前确认 GPU 显存和推理框架版本
Hy-MT2 的开源让"多语种 + 方言 + 指令遵循"这条翻译路线有了可直接调用的模型，不用再自己从通用大模型上微调。下一步值得关注的是社区在 IFMTBench 上的评测结果——那才是判断"听不听话"的硬数据。