ローカル翻訳AIHy-MT2とDeepL無料版を5テストで比較した結果

TL;DR: 今回のベンチマークでは、総合スコアより用途別の強弱で見るほうが判断しやすい結果でした。

関連記事としては BlogなぜLeCunはMetaを去りAMI Labsを作ったのか——ローカルLLMとオープンウェイト消滅論を15分で把握するLeCunのAMI Labs設立とMollickのオープンウェイト消滅リスクを整理。ローカルLLM運用者が2026年に何を見直すべきかを実務目線で解説します。→ もあわせて読むと、今回の論点とのつながりを把握しやすくなります。

DeepL Proは月額3,500〜7,500円。無料版は文字数制限がきついです。しかも、Markdownのリンクやコードブロックが崩れると、翻訳したいのに逆に手直しが増えます。

そこで気になるのが、ローカルで動く翻訳専用モデルは本当に実務で使えるのか、そしてHy-MT2はDeepL無料版の代わりになるのかです。

結論から言うと、今回は少し意外な結果でした。1.8Bが7Bに勝ちました。 しかも勝ったのは「なんとなく速い」ではなく、Markdown保持・専門用語の安定性・速度・ハルシネーション耐性です。

ただし、話はきれいではありません。Modelfileのonseバグ修正がほぼ必須で、ここを外すと評価が崩れます。ローカルLLMは夢がありますが、設定を1つ落とすだけで平気で足を引っ張ります。

今回の実機テストでは、Tencentのローカル翻訳モデル Hy-MT2-1.8B を Ollama 上で動かし、DeepL無料版と5項目で比較しました。

結論はかなり割り切れています。

• Hy-MT2-1.8Bは実務で使えるレベル
• 7Bは一部で品質が上がるどころか、敬語テストでハルシネーションが出た
• 1.8Bはサイズの割に安定していて、タグ崩れに強い
• DeepL無料版は品質は高いが、実務の運用では文字数制限が痛い

サイズが大きいほうが勝つ、という先入観は翻訳ではそのまま通りません。少なくとも今回の条件では、1.8Bのほうが「翻訳ツールとしての事故率」が低かったです。

今回の比較は「雰囲気」ではなく、実務で困る点に寄せました。

検証した5テスト

1. Markdown保持
2. 専門用語の一貫性
3. 敬語・文体の自然さ
4. ハルシネーション耐性
5. 速度

使ったモデル

• Hy-MT2-1.8B
• Hy-MT2-7B
• DeepL無料版

実行環境

• GPU: RTX 4070 Ti
• 1.8B: 約1.1GB
• 440MB級の軽量運用も視野に入るモデル設計
• Ollamaで実行

この条件なら、少なくとも「PC上で動くか」「遅すぎないか」「実用で崩れないか」は見えます。

1. Markdown保持

ここは Hy-MT2-1.8Bの勝ち でした。

DeepL無料版は、状況によってリンクの位置やコードブロック周辺の整形を直したくなることがあります。もちろん万能に崩れるわけではないのですが、技術文書では「直す前提」が少しでも入ると、地味に効きます。

Hy-MT2-1.8Bは、見出し・箇条書き・コードブロックの形を比較的きれいに保てました。翻訳後にそのままMarkdownとして読ませやすいのは、実務ではかなり大きいです。

2. 専門用語の一貫性

ここも 1.8Bは実用レベル でした。

モデルに「専門用語は固定」「原語を残す」「固有名詞は変えない」といった指示を入れると、翻訳のブレがかなり減りました。DeepLのほうが総合的には自然ですが、ローカル側は辞書的なルールを入れた時の再現性が強いです。

3. 敬語・文体の自然さ

ここは 7Bに期待したくなる気持ちは分かります。普通は大きいほうが自然そうですから。

しかし、実際には 7Bでハルシネーションが出ました。敬語の流れの中で、原文にない補足や言い換えが勝手に乗ってしまうケースがありました。

これは翻訳ではかなり厄介です。訳文が美しいかどうかより、原文にないものを足していないかのほうが大事だからです。

4. ハルシネーション耐性

ここで1.8Bが7Bに勝ちました。

特に C1テスト で差がはっきり出ました。敬語を含むやや長めの文を与えたとき、7Bは文意を整えようとして、原文にない主語や補足を混ぜました。

一方で1.8Bは、派手ではないけれど、余計なことをしない。翻訳ではこの地味さが正義です。

これは予想通りの結果でした、と言いたいところですが、正直、7Bがここまで不安定だったのは意外でした。サイズを上げれば安全、とは限りません。

5. 速度

速度は、ローカル翻訳を続けられるかに直結します。

この差は、実際に触ると地味に効きます。

7Bは遅いだけでなく、文章が長くなるほど「待つストレス」が出ます。翻訳は一回で終わらないので、速度差は体感差になります。

ここが今回いちばん大事です。

翻訳用途では、モデルの能力そのものよりも、余計な生成をしないことが強く効きます。

7Bは、自然な日本語に寄せようとして、原文にない要素を足しやすい場面がありました。いわゆるハルシネーションです。

1.8Bはそこまで器用ではないぶん、元の意味を崩しにくい。翻訳ではこの「少し不器用だが、勝手に盛らない」性質が武器になります。

つまり、今回の勝敗はこう整理できます。

• 7B: 文章をきれいに見せようとして事故ることがある
• 1.8B: そこそこ素直で、実務では安定しやすい

翻訳は創作ではありません。ここを取り違えると、サイズ神話に引っ張られます。

今回のハマりどころが Modelfile の onse バグ です。

結論だけ先に書くと、stop トークン指定が onse になっていた箇所を修正する必要がありました。

これはモデル本体の性能というより、Ollama の Modelfile 側の設定ミスで出力制御が崩れる問題です。

何が起きるのか

stop 指定が正しく効かないと、以下のような症状が出ます。

• 出力が余計に続く
• 終端が揃わない
• 翻訳後に補足文が混ざる
• 比較テストで7Bの不安定さが増幅される

つまり、モデル比較の前に、土台の設定が正しいかを疑うべきです。ここを飛ばすと、性能差ではなく設定差を測ってしまいます。

正しいModelfileの書き方

Hunyuanアーキテクチャ固有の特殊トークンをTEMPLATEに明示する必要があります。

FROM hf.co/tencent/Hy-MT2-1.8B-GGUF:latest

TEMPLATE """<｜hy_begin▁of▁sentence｜><｜hy_User｜>{{ .Prompt }}<｜hy_EOT｜><｜hy_Assistant｜>"""

PARAMETER stop "<｜hy_EOT｜>"
PARAMETER stop "<｜hy_place▁holder▁no▁8｜>"
PARAMETER temperature 0.7
PARAMETER top_p 0.6
PARAMETER top_k 20
PARAMETER repeat_penalty 1.05
PARAMETER num_predict 4096

7B版は 1.8B-GGUF を 7B-GGUF に変えるだけです。この Modelfile を使って ollama create hy-mt2-1.8b -f ./Modelfile で登録します。

Modelfileでは、少なくとも以下を確認します。

• TEMPLATE にHunyuan独自トークン（<｜hy_User｜> など）が含まれているか
• stop が2種類（hy_EOT と place▁holder▁no▁8）設定されているか
• temperature 0.7 / top_p 0.6 / top_k 20 の推奨パラメータを使っているか

特殊トークンの注意点

翻訳モデルは、会話モデルと違って「勝手に続けない」ことが重要です。

そのため、特殊トークンや停止条件は単なるおまけではありません。訳文の切れ方そのものを決める設定です。

もし訳文が妙に伸びる、末尾に説明がつく、原文にない締めが入るなら、まず Modelfile を疑ってください。

1.8Bは 約1.1GB で、動かしやすさのハードルが低いです。

GPUを強く使える環境ならもちろん余裕がありますし、ローカルで「ちょっと翻訳したい」が積み重なる人にはかなり合います。

一方で7Bは、翻訳品質を少しでも上げたい期待はあるものの、今回の条件では 速度・安定性・手戻り の総合点で1.8Bに負けました。

ローカル翻訳は「最高精度を一発で狙う」より、日々の面倒を減らすほうが価値になりやすいです。

この表の見方は単純です。

• まず動かしたい → 1.8B
• ローカルで毎日使いたい → 1.8B
• 7Bで上積みを狙いたい → ただしハルシネーションを自分で検証する前提

サイズで選ぶより、出力の事故率で選ぶほうが翻訳では外しにくいです。

Hy-MT2がかなり良かったとはいえ、DeepLを完全に置き換えた、とは言いません。

DeepLがまだ強いのは、たとえばこういう場面です。

• 一般文の自然さ
• 迷いの少ない読みやすさ
• ローカル環境構築なしで即使える手軽さ

ただし、実務でマークダウンや技術文書を扱うなら話は変わります。

• 無料版の文字数制限 が面倒
• タグやコードブロックが崩れると手戻りが発生する
• 社外に出せない文書 はそもそもクラウド翻訳に載せにくい

この条件では、Hy-MT2の価値が急に上がります。

つまり、DeepLが優秀でも、運用の都合まで含めるとローカル翻訳の意味は十分あるということです。

今回の検証で言えるのは、翻訳用途では「大きいモデルが勝つ」とは限らないということです。

むしろ、

• Markdownを壊さない
• 専門用語を崩しにくい
• 速度が出る
• ハルシネーションが少ない

この4つが揃った Hy-MT2-1.8B のほうが、日常の翻訳には向いていました。

7Bは、期待する気持ちは分かります。でも今回は、安定性で1.8Bに負けました。

なので、判断はこうで十分です。

1. まずは 1.8B を動かす
2. Modelfile の onse バグを直す
3. Markdownと専門用語のサンプルで自分の文書を試す
4. それでも物足りなければ、7Bを比較する

順番を逆にすると、たぶん疲れます。私は何度もその手の遠回りを見てきました。

ローカル翻訳AIは、派手さよりも 自分の手元で事故らないこと が価値です。Hy-MT2は、その条件にかなり近いところまで来ていました。

• スコアはテスト設計と採点基準に依存します。他のベンチマークと単純比較はできません。
• 推論速度はGPU・量子化・同時実行数で大きく変わります。
• 実機で試すまで、スコアだけで用途を決めないほうが安全です。

翻訳品質テストは以下5種を実施しました（2026-05-25 / AIサーバー RTX 4070 Ti）。DeepL無料版はWebブラウザで同一テキストを入力し、出力を目視比較しました。

Test A: Markdown保持テスト（EN→JA）

入力:

Use `git clone` to fetch the [repository](https://github.com/example/repo).
**Note:** This requires Node.js >= 18.
Run the following command:
```bash
npm install && npm run dev
```

Hy-MT2-1.8B 出力（197 tok/s）: → バッククォート・リンク・太字・コードブロックすべて完全保持 ✅

[リポジトリ](https://github.com/example/repo)を取得するには `git clone` を使用してください。
**注意：** Node.js のバージョンが >= 18 でなければなりません。
以下のコマンドを実行してください：
```bash
npm install && npm run dev
```

Hy-MT2-7B 出力（33 tok/s）: → 「【日本語訳】」という余分なプレフィックスが付く ⚠️

【日本語訳】
[リポジトリ](https://github.com/example/repo)を取得するには、`git clone`を使用してください。
**注意:** これを実行するにはNode.js 18以上が必要です。

Test C: 敬語・ビジネス翻訳テスト（JA→EN）

入力（4文）:

1. お世話になっております。
2. よろしくお願いいたします。
3. ご確認のほど、よろしくお願い申し上げます。
4. お手数をおかけして申し訳ございません。

Hy-MT2-1.8B 出力（167 tok/s）: → 4文すべて適切な丁寧語で翻訳 ✅

1. Thank you for your assistance.
2. I would appreciate your support.
3. Please confirm this at your earliest convenience.
4. I am sorry to cause you any inconvenience.

Hy-MT2-7B 出力（ハルシネーション発生）: → 原文4文のはずが5・6番が突然出現。しかも日本語が崩壊 ❌

I hope this message finds you well. Thank you for your continued support.
5. 今後とも変わらずご支援を賜りますようお願い申しょう。
6. これからも変わらむずくご協力をお願いい...

Test D: 専門用語辞書指示テスト（EN→JA）

入力（辞書指示付き）:

Reference: "repository"→"リポジトリ" / "branch"→"ブランチ" / "merge"→"マージ"

Create a new branch from the main repository, make your changes,
and submit a pull request. After review, the changes will be merged into the main branch.

両モデル出力（1.8B / 7B ともに合格）: → リポジトリ・ブランチ・マージ すべて辞書通りに翻訳 ✅

メインリポジトリから新しいブランチを作成し、変更を加えてからプルリクエストを
送信します。レビューが終わった後、その変更内容はメインブランチにマージされます。

NLLBやDeepLでは「リポジトリ→貯蔵庫」のような誤訳が起きやすいが、Hy-MT2はプロンプトで制御可能。

DeepL無料版はWebブラウザで同一テキストを入力し、出力を目視比較しました。

Ollama以外でも動かせますか？

llama.cpp経由（GGUFファイル直接）でも動きます。Ollamaは管理が楽なので推奨ですが、llama-serverやLM Studioでも同じGGUFが使えます。

自分の環境でも同じ速度になりますか？

GPU・VRAM・量子化によって変わります。RTX 4070 Ti（12GB）での実測なので、GTX 1660（6GB）ではより遅くなります。CPU onlyでの速度は本記事では未測定です。

DeepL APIの代替として使えますか？

Ollama REST API（/api/generate）をDeepL APIのように叩く方法は別記事で詳しく紹介しています。

• Hy-MT2 GitHub公式リポジトリ
• Hy-MT2-1.8B-GGUF HuggingFace
• META-MARK: ローカルLLM速度比較

HW系エンジニアとして20年以上、10,000件を超える顧客訪問と2,000件を超える単独ソリューション実績。AIツールを使った個人開発やIoT農園など、Raspberry Piを使ったオートメーション化なども実践中です。エンジニア専門結婚相談所も運営中です。

• BlogなぜLeCunはMetaを去りAMI Labsを作ったのか——ローカルLLMとオープンウェイト消滅論を15分で把握するLeCunのAMI Labs設立とMollickのオープンウェイト消滅リスクを整理。ローカルLLM運用者が2026年に何を見直すべきかを実務目線で解説します。→
• Bloggemma4:12bがollamaで直った — 0.30.5で3層バグ全解消を実測確認【回避策は不要に】gemma4:12bのSIGFPE、macOS専用配布、日本語崩れを同一環境で実測。ollama 0.30.5で何が直り、何を捨ててよいかを整理します。→
• Blog推論に特化したモデルが39%しか取れない理由——deepseek-r1で何が起きたかRTX 4070 Ti + Ollamaでdeepseek-r1:7bを24問テスト。94/240点（39.2%）ランクDの背景を掘る。6問タイムアウト・日中混合テキスト・論理は強い、という複雑な姿を正直に記録。→

• 実際の構成を探すなら、GPU 比較ページやローカルLLM向け構成記事もあわせて見ると判断しやすいです。
• ハードウェア候補は用途別の AI 構成ガイドからたどると、単体製品より違和感なく検討できます。