Hy-MT2：模型调研与 macOS 本地实测¶

结论：Hy-MT2-1.8B-Q4_K_M 适合本机常驻使用。7 个翻译样例的中位端到端耗时为 232 ms，生成速度中位数约 107 token/s，进程常驻内存约 1.74 GiB。Hy-MT2-7B-Q4_K_M 的文字更自然，但中位耗时约 727 ms，内存约 5.52 GiB。1.25-bit 版本依赖尚未合并的 STQ 内核，当前稳定版 llama.cpp 无法加载。

0. 调研摘要¶

1. 模型概览¶

Hy-MT2 于 2026-05-21 开源。腾讯将它定位为“快思考”翻译模型，面向通用翻译、真实业务、专业领域和翻译指令遵循。

官方说明支持 33 种语言。语言表列出 38 个语言或变体标识，包括繁体中文、粤语等。论文和模型卡没有解释两个数字的口径差异。选型时应以具体源语言和目标语言实测为准。

1.1 技术路线¶

论文给出的训练流程分为三个阶段：

1. 用约 1T 与翻译相关的 token 做面向机器翻译的中训练。
2. 按语言族执行 Family-Centric Post-training。
3. 用量化降低部署成本。

Family-Centric Post-training 包含三步：

1.2 翻译指令能力¶

模型卡给出七类指令：

• 默认翻译。
• 术语约束。
• 风格控制。
• 个性化偏好。
• 分隔符保持。
• JSON 等结构化数据翻译。
• 背景信息辅助翻译。

默认提示词要求模型只输出译文，不输出解释。模型没有默认 system prompt。

2. 官方评测¶

官方报告使用 XCOMET-XXL、CometKiwi 和 GEMBA 评测通用翻译。专业领域和真实业务场景分别使用 DomainMTBench 和 WildMTBench。翻译指令能力使用 IFMTBench。

这些结果由腾讯发布，本次没有复现论文中的完整基准集。不能将官方分数直接等同于独立评测。

2.1 Q4 量化质量¶

下表来自论文 Table 5。分数均为百分制。

2.2 数据解读¶

1. Q4 对 1.8B 的通用翻译损失较小，但 IFMTBench 下降 5.89 分。
2. Q4 对 7B 的通用和质量基准影响较小，但 IFMTBench 下降 8.03 分。
3. Q4 7B 的 IFMTBench 仍高于 Q4 1.8B。
4. 对术语、格式和复杂约束敏感的业务，应增加指令遵循回归测试。
5. 论文报告的是腾讯自有评测结果，需要独立评测验证。

3. 部署方式¶

llama.cpp 仓库的官方 Q4_K_M、Q6_K 和 Q8_0 GGUF 可以直接用于常规量化推理。模型卡明确提示，低比特 GGUF 依赖 STQ 内核；相关 PR 在测试日仍处于打开状态。

4. 本机测试环境¶

4.1 模型文件¶

模型通过 ModelScope 下载。SHA-256 与模型仓库公布值一致。

5. 测试方法¶

5.1 测试项目¶

1. 中文到英文。
2. 英文到中文。
3. 中文到日语。
4. 术语约束。
5. JSON 结构保持。
6. 分隔符与风格控制。
7. 约 250 字的中文长段落。

5.2 固定参数¶

每个模型先执行一次不计入结果的预热请求。每个模型使用相同的 7 个请求。端到端耗时在客户端计时，生成速度取服务端 timings。

5.3 合成吞吐基准¶

命令使用 llama-bench，输入 128 token，生成 64 token，每种配置重复 3 次。

Metal 对 1.8B 的提示处理提升约 5.5 倍，生成速度提升约 1.5 倍。7B 的 Metal 提示处理约为 CPU 的 5.2 倍，生成速度约为 CPU 的 2.0 倍。

6. 本机实测结果¶

6.1 汇总¶

在这个样本集里，1.8B 的中位耗时约为 7B 的 32%。1.8B 的内存占用约为 7B 的 32%。

6.2 分项耗时¶

下表中的 token 数格式为“输入 + 输出”。

6.3 质量检查¶

两个模型都将“校验值”译成了 validation values 或 verification values。在软件语境中，checksums 更准确。正式业务应提供术语表。

6.4 输出对比¶

两套模型都保持以下 JSON 结构：

{"title":"Project Status","description":"Model testing has been completed.","count":3,"status":"active"}

分隔符样例都保留了 [[...]]、{name} 和 {date}。7B 将 开场 译为 Introduction，1.8B 译为 Opening。两种译文都能通过结构检查。

7. 1.25-bit 兼容性¶

测试使用同一个 Homebrew llama.cpp 运行时。

因此，当前 macOS 用户不能仅通过 Homebrew 稳定版直接使用 1.25-bit GGUF。需要使用包含 STQ 内核的分支，或在其他受支持运行时中重新验证。

8. 选型建议¶

8.1 使用 1.8B 的理由¶

• 启动和响应快。
• 内存占用低。
• 适合短句、字幕和交互式翻译。
• 中文、英文、日文和格式约束样例均通过。
• Q4 下仍保留较好的通用翻译质量。

8.2 使用 7B 的理由¶

• 中文表达更自然。
• 多语言输出更完整。
• Q4 的官方通用基准更接近 BF16。
• 代价是约 3 倍延迟和约 3 倍内存占用。

9. 复现命令¶

llama-server \
  -m /path/to/Hy-MT2-1.8B-Q4_K_M.gguf \
  --alias Hy-MT2-1.8B-Q4_K_M \
  --jinja \
  -ngl 99 \
  -c 8192 \
  -t 8 \
  --host 127.0.0.1 \
  --port 8080 \
  --no-webui

请求示例：

curl -sS http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  --data-binary '{
    "model": "Hy-MT2-1.8B-Q4_K_M",
    "messages": [{
      "role": "user",
      "content": "将以下文本翻译成英语，注意只需要输出翻译后的结果，不要额外解释：\n\n今天天气真好。"
    }],
    "temperature": 0.7,
    "top_p": 0.6,
    "top_k": 20,
    "repeat_penalty": 1.05,
    "seed": 42,
    "stream": false
  }'

合成吞吐测试：

llama-bench \
  -m /path/to/Hy-MT2-1.8B-Q4_K_M.gguf \
  -p 128 \
  -n 64 \
  -r 3 \
  -ngl 99 \
  -t 8 \
  -o json

10. 限制¶

1. 本次只测试了 Q4_K_M 的实际翻译质量。
2. 本次只使用 7 个固定样例。样例覆盖短句、长文、术语、JSON 和分隔符，不代表全部 33 种语言。
3. 质量检查是人工阅读，没有计算 COMET、XCOMET 或人工评分。
4. 官方评测来自腾讯论文，本次没有重跑 FLORES-200、WMT25、DomainMTBench、WildMTBench 和 IFMTBench。
5. 没有测量功耗、芯片温度、热降频和持续并发吞吐。
6. llama-server 默认创建 4 个 slot。内存数据包含此配置。
7. 30B-A3B、FP8、BF16、Q6_K、Q8_0 和 2-bit 没有在本机测试。
8. 模型输出可能出现术语偏差。高风险内容必须人工复核。

11. 参考资料¶

• Hy-MT2 GitHub 仓库
• Hy-MT2 中文模型卡
• Hy-MT2-1.8B-GGUF
• Hy-MT2-7B-GGUF
• Hy-MT2 论文
• ModelScope 1.8B GGUF
• ModelScope 7B GGUF
• llama.cpp STQ PR #22836

12. 版本记录¶