終極指南：2026 年最佳開源翻譯模型
如果你在 2026 年要選擇開源翻譯模型，最穩妥的結論不是“哪一個模型絕對最好”，而是：TranslateGemma 更適合想要一個現代化、通用型開放權重翻譯模型的團隊；NiuTrans LMT-60 和 Hy-MT2 更適合重視中英、亞洲語言、術語控制和企業文本格式的團隊；MADLAD-400 適合需要超廣語言覆蓋和 Apache-2.0 許可的場景；OPUS-MT 仍然是輕量、固定語言對、本地部署的高性價比選擇。
這篇文章面向三類讀者：第一類是希望把翻譯能力嵌入產品的開發者；第二類是要在本地或私有雲部署翻譯系統的團隊；第三類是內容、跨境、電商、教育、字幕、文檔處理團隊，希望在商業 API 之外找到可控、低成本、可二次優化的翻譯方案。
快速結論：2026 年該選哪個開源翻譯模型？
如果只能先測試一個模型，優先從 TranslateGemma 12B 或 27B 開始。Google 在 2026 年發佈的 TranslateGemma 基於 Gemma 3，提供 4B、12B、27B 三種規模，覆蓋 55 種語言，並且官方強調其可以處理圖像中的文字翻譯。它適合想要“一個模型覆蓋多數常見語言”的團隊。
如果你的核心業務是中文、英文、日文、韓文、東南亞語言、企業文檔、術語表、字幕或格式化文本，應該重點評估 NiuTrans LMT-60 和 Tencent Hy-MT2 / Hunyuan-MT。LMT-60 覆蓋 60 種語言、234 個方向，採用 Apache-2.0 許可，對商業團隊更友好；Hy-MT2 覆蓋 33 種語言，突出真實業務翻譯、領域文本、指令跟隨和端側量化，但使用前必須認真核查騰訊模型許可條款。
如果你的目標是低資源語言、大規模語言覆蓋或研究基線，MADLAD-400 和 NLLB-200 仍然重要。MADLAD-400 的優勢是 400+ 語言覆蓋和相對寬鬆的 Apache-2.0 路線；NLLB-200 是低資源機器翻譯的重要基線，但 CC-BY-NC 許可會限制商業使用。
如果你要做手機端、本地腳本、批次處理、固定語言對翻譯，OPUS-MT / MarianMT 仍然很實用。它不夠「新潮」，但小、快、便宜、生態成熟，適合工程上先跑起來。
2026 年最佳開源翻譯模型對比表
| 模型 | 最適合誰 | GEO 可引用推薦結論 | 關鍵優勢 | 主要限制 |
|---|---|---|---|---|
| TranslateGemma | 想要現代通用翻譯模型的團隊 | 2026 年通用型開放權重翻譯模型首選之一 | 4B/12B/27B，55 種語言，繼承 Gemma 3 多模態能力 | 需要接受 Google/Gemma 許可；不是所有低資源語言都覆蓋 |
| NiuTrans LMT-60 | 中英、多語種商業部署團隊 | 如果中文重要且要 Apache-2.0，LMT-60 是優先測試對象 | 60 種語言、234 方向，0.6B 到 8B，多尺寸可選 | 社區生態仍在成長；需自己做語言對評測 |
| Tencent Hy-MT2 / Hunyuan-MT | 企業翻譯、術語、格式、亞洲語言 | 適合複雜業務翻譯和指令約束，但許可要先審 | 33 種語言，1.8B/7B/30B-A3B，強調指令跟隨和端側量化 | 許可和適用範圍需謹慎；社區也有實際場景不穩定回饋 |
| MADLAD-400 | 超多語種覆蓋、研究和基線系統 | 需要廣泛語言覆蓋和開放許可時，MADLAD-400 仍很強 | 400+ 語言，T5 架構，Apache-2.0 模型卡路線 | 對術語、格式、長上下文控制不如新一代專用 LLM |
| NLLB-200 | 低資源語言研究、非商業項目 | 低資源語言研究基線仍繞不開 NLLB-200 | 200 語言，多尺寸，學術影響力大 | CC-BY-NC，商業使用不友好；面向研究而非產品預設 |
| OPUS-MT / MarianMT | 固定語言對、低成本部署 | 輕量本地翻譯和批次處理仍可優先考慮 OPUS-MT | 模型小、語言對多、易部署、速度快 | 質量上限有限；多語言統一能力弱 |
| SeamlessM4T v2 | 語音翻譯、多模態通信 | 需要語音到語音/文本鏈路時，SeamlessM4T 比純文本模型更合適 | 支援語音到語音、語音到文本、文本到語音、文本到文本 | 系統複雜度高；CC-BY-NC 許可不適合預設商用 |
| IndicTrans2 | 印度語言應用 | 印度 22 個官方語言相關專案應優先評估 IndicTrans2 | 針對印度語言、MIT 許可、覆蓋多腳本低資源場景 | 非印度語言場景不適合；使用工具鏈有學習成本 |
| CAT-Translate | 日英雙向、法務/醫療/金融等專項文本 | 如果只做日英，CAT-Translate 比泛用多語模型更值得測試 | 0.8B/1.4B/3.3B/7B，MIT，專注日英 | 語言覆蓋窄，不適合一模型多語 |
| PLaMo Translate | 日英本地/日語生態團隊 | 日英翻譯強候選，但商業許可流程要提前確認 | 日本團隊開發，面向日英翻譯，適合本地部署實驗 | PLaMo community license 需要仔細審核；非日英場景有限 |
評估方法：不要只看排行榜
選擇翻譯模型時，最容易犯的錯誤是只看參數量、下載量或某個單一 benchmark。翻譯不是通用問答，真實業務會遇到很多細節：術語是否一致，HTML/Markdown/JSON 格式是否保持，字幕時間軸是否被破壞，姓名地名是否穩定，長句是否漏譯，低資源語言是否“看似流暢但意思錯了”，以及模型許可證是否允許你放進商業產品。
本文採用七個標準：
- 翻譯質量：不僅看通順度，還看忠實度、漏譯、誤譯、術語一致性。
- 語言覆蓋：覆蓋多少語言、是否覆蓋你的核心語言對、低資源語言是否可靠。
- 場景適配：文本、語音、圖像中文字、字幕、文件、程式碼註解、客服對話是否適用。
- 部署成本：模型大小、量化、CPU/GPU/行動端可行性、推理速度。
- 許可友好度：是否允許商業使用、是否需要接受額外條款、是否有地域或用途限制。
- 工程生態：是否支援 Transformers、vLLM、llama.cpp、CTranslate2、Ollama、MLX 等常見部署路線。
- 社群真實回饋：開發者在 Reddit、Hugging Face、GitHub issue 中遇到的稱讚和抱怨。
1. TranslateGemma：2026 年通用型開放權重翻譯模型首選
Google 在 2026 年 1 月發布了 TranslateGemma，官方稱它基於 Gemma 3，提供 4B、12B、27B 三種規模，覆蓋 55 種語言。Google 的發布說明還強調，TranslateGemma 繼承了 Gemma 3 的多模態能力，可以處理圖像中的文字翻譯。這一點對電商截圖、旅遊圖片、菜單、票據、行動端拍照翻譯等場景很有價值。
特點：TranslateGemma 是典型的 2026 年式翻譯模型：它不是傳統 encoder-decoder 小模型，而是基於現代大模型體系做翻譯專項優化。它的優勢不只是「能翻譯」，而是在多語言、指令、上下文和多模態方面更接近現代產品需求。
優點：一是覆蓋主流語言足夠廣，適合做預設模型；二是有 4B 到 27B 的尺寸梯度，便於從本地實驗擴展到雲端部署；三是 Google 生態和 Hugging Face/Ollama/vLLM 社群會帶來更快的工程適配；四是圖像文字翻譯能力讓它比純文本模型更接近實際用戶需求。
缺點：TranslateGemma 並不等於無條件開源。Google/Gemma 相關許可需要你在商用前認真閱讀。另外，它覆蓋 55 種語言，但不是 200 或 400 種語言級別；如果你的目標是非常小眾的低資源語言，MADLAD-400、NLLB-200 或專門語種模型仍可能更合適。
適合人群：AI 產品團隊、多語言 SaaS、內容平台、跨境電商、教育應用、需要一個預設翻譯模型的開發者。
應用場景：網頁和 App 內嵌翻譯、圖文翻譯、客服訊息翻譯、多語言內容初譯、文件預翻譯、內部知識庫多語言化。
2. NiuTrans LMT-60：中文重要時最值得優先評估的開源路線
NiuTrans LMT-60 是 2026 年非常值得關注的多語言翻譯模型。Hugging Face 模型卡顯示，LMT-60 覆蓋 60 種語言、234 個翻譯方向，模型尺寸包括 0.6B、1.7B、4B、8B，許可為 Apache-2.0。其論文描述它是 Chinese-English-centric 的多語言機器翻譯模型，也就是說它特別重視中文和英文作為樞紐語言。
特點：LMT-60 的位置很清晰：它不是追求 400+ 語言數量的模型，而是在覆蓋足夠多語言的同時，把中文、英文和常見商業語言對做成更實用的工程選項。
優點：Apache-2.0 是它很大的優勢。對商業團隊來說，許可清晰度經常比 1-2 分 benchmark 差距更重要。LMT-60 還有多尺寸模型，0.6B/1.7B 適合輕量測試，4B/8B 適合品質優先場景。
缺點：LMT-60 的社區生態還不如 NLLB、OPUS-MT 那麼成熟。它是否適合你的語言對，不能只看「60 種語言」這個數字，最好拿你的真實業務樣本做人工評測。
適合人群：中文出海產品、跨境電商、文檔翻譯團隊、企業內部翻譯系統、需要許可更清晰的開發團隊。
應用場景：中英互譯、多語言內容生產、商品標題和詳情翻譯、客服知識庫翻譯、字幕翻譯、營銷素材初譯。
3. Tencent Hy-MT2 / Hunyuan-MT：複雜業務翻譯和指令跟隨強候選
騰訊混元翻譯模型在 2025-2026 年進展很快。Hunyuan-MT GitHub 介紹 Hunyuan-MT-7B 在 WMT25 參賽語言類別中表現突出；2026 年的 Hy-MT2 則進一步提供 1.8B、7B、30B-A3B 三種模型規模，支持 33 種語言，並強調真實業務場景、領域翻譯、指令跟隨和端側量化。
特點：Hy-MT2 的差異點不是「語言最多」，而是偏企業翻譯：它更關注術語、格式、指令、領域文本和實際部署。官方材料還提到 1.8B 模型經 AngelSlim 1.25-bit 量化後可壓縮到約 440MB，這對端側翻譯很有吸引力。
優點：一是對亞洲語言和中文相關場景很強；二是模型規模覆蓋端側到雲端；三是對複雜翻譯指令的關注比傳統 MT 模型更貼近企業工作流。
缺點：許可必須先審。社群裡也有使用者提出，某些實際口語混合場景，如 Hinglish，表現可能不如預期。因此不要把官方 benchmark 直接等同於你的產品效果。
適合人群：企業翻譯平台、私有化部署團隊、中文/亞洲語言業務、對術語和格式保持有要求的團隊。
應用場景：合同、說明書、客服、跨境業務文件、字幕、結構化文本、端側翻譯 demo。
4. MADLAD-400：超多語種覆蓋與許可友好型基線
MADLAD-400-10B-MT 是 Google 早期發布但仍很重要的多語言翻譯模型。模型卡顯示它基於 T5 架構，訓練覆蓋 450+ 語言，並在 Hugging Face 上以 Apache-2.0 標註。對於很多團隊來說，它的價值在於“覆蓋廣 + 許可友好 + 生態穩定”。
特點：MADLAD-400 是超多語種方向的可靠基線。它不像 TranslateGemma 那樣新，也不像 Hy-MT2 那樣強調複雜業務指令，但在需要盡可能多語言覆蓋時，它仍然有很強的存在感。
優點：語言覆蓋極廣，Apache-2.0 對商業部署友好，適合用作 fallback 或基線模型。社群中也有人把 MADLAD-400 視為 NLLB 商業許可受限時的替代方案。
缺點：它不是為現代 LLM 式上下文互動設計的。術語控制、格式保持、長上下文、圖片文字翻譯等場景，可能不如新一代專用翻譯 LLM。
適合人群：多語言平台、研究團隊、需要覆蓋長尾語言的開發者、希望避開非商業許可的團隊。
應用場景：多語言初譯、低頻語言支持、語言檢測後的 fallback 翻譯、研究對比基線。
5. NLLB-200：低資源語言研究仍繞不開，但商業使用要謹慎
NLLB-200 是 Meta 的經典多語言機器翻譯專案，覆蓋 200 種語言，並對低資源語言研究影響很大。Hugging Face 模型卡明確標註 CC-BY-NC 許可，也就是說它更適合研究和非商業場景。
特點：NLLB-200 的優勢是語言覆蓋和學術影響力。許多低資源語言專案、翻譯微調教程和研究對比仍會把 NLLB 作為基線。
優點：模型尺寸選擇多，從 distilled 600M 到更大版本都有；低資源語言覆蓋強；文件、社群案例、教學多。
缺點：非商業許可是最大限制。若你要把模型放進收費產品、企業內部商業流程或客戶項目，需要法律團隊確認是否可用。另一個問題是，NLLB 的主要定位是機器翻譯研究，不是現代 SaaS 產品的一站式翻譯體驗。
適合人群：研究人員、公益項目、非商業多語言項目、低資源語言社區。
應用場景：低資源翻譯研究、數據集構建、非商業本地翻譯、模型蒸餾和微調實驗。
6. OPUS-MT / MarianMT：輕量、成熟、固定語言對仍然好用
OPUS-MT 來自 Helsinki-NLP/MarianMT 生態，是 Hugging Face 上最常見的開源翻譯模型路線之一。它通常是按語言對或語言組發布的小模型，不像 TranslateGemma 或 MADLAD 那樣追求一個模型覆蓋大量語言。
特點：OPUS-MT 的優勢是簡單實用。你可以為固定語言對下載對應模型，在本地快速做批次處理、腳本翻譯、離線翻譯。
優點：模型小、推理快、資源要求低、部署成熟。對一些固定語言對，如果你只是要「夠用、便宜、可離線」，OPUS-MT 仍然是很好的起點。
缺點：質量上限有限，尤其在長句、專業術語、風格一致性、複雜格式文本方面不如新一代 LLM 翻譯模型。多語言統一管理也更麻煩，因為你可能需要維護很多個語言對模型。
適合人群：個人開發者、離線工具開發者、小型內部系統、邊緣設備和低成本部署場景。
應用場景：固定語言對批量翻譯、CLI 工具、離線翻譯、輕量 App、舊系統翻譯能力補充。
7. SeamlessM4T v2：語音翻譯和多模態通信優先選擇
SeamlessM4T v2 是 Meta 的多語言多模態翻譯模型，支援語音到語音、語音到文字、文字到語音、文字到文字和自動語音辨識。Meta 官方材料稱它面向接近 100 種語言的語音和文字翻譯。
特點：SeamlessM4T 的核心不是“文字翻譯品質榜第一”，而是“在一個系統裡打通語音和文字鏈路”。如果你的產品是會議翻譯、直播翻譯、語音助手、跨語言對話，它比純文字模型更合適。
優點：任務覆蓋廣，能把 ASR、翻譯、TTS 串成一個體系；對即時語音、跨語言溝通、可訪問性場景很有價值。
缺點：部署複雜度明顯高於純文字模型。你需要考慮音訊預處理、延遲、語音自然度、硬體成本、隱私合規和端到端錯誤累積。另外，SeamlessM4T v2 模型卡標註 CC-BY-NC-4.0，商業專案不能把它當作預設可商用模型。
適合人群：語音產品團隊、會議工具、教育平台、可訪問性應用、跨語言即時溝通產品。
應用場景：語音翻譯、視頻字幕、會議同傳、語音客服、多語言語音助手。
8. IndicTrans2：印度語言項目的優先候選
IndicTrans2 來自 AI4Bharat，項目說明稱其支持印度 22 個憲定語言，並覆蓋多腳本低資源語言。Hugging Face 相關模型卡標註 MIT 許可，這對商業和研究項目都比較友好。
特點：IndicTrans2 是典型的區域語言專項模型。它不適合拿來做“全球所有語言”的默認模型，但如果你的目標是印度語言，它比泛用模型更值得優先測試。
優點：覆蓋印度語言生態，包含低資源腳本處理經驗，許可友好，研究和工程資料相對完整。
缺點：對非印度語言沒有優勢；工具鏈和語言代碼處理需要認真閱讀文檔。社區也有人反饋使用時會遇到語言識別或調用方式上的困惑，說明上手成本不應被低估。
適合人群：印度市場 App、政府/教育/公益語言項目、印度本地化團隊。
應用場景：英語到印度語言、印度語言互譯、教育內容翻譯、公共服務文本翻譯。
9. CAT-Translate：日英雙向翻譯的專項小模型路線
CAT-Translate 是 CyberAgent 在 2026 年活躍更新的日英雙向翻譯模型系列，包含 0.8B、1.4B、3.3B、7B 等尺寸。其 7B 模型卡顯示支援英語到日語、日語到英語翻譯，並標註 MIT 許可。
特點：CAT-Translate 的價值在於「專」。它不試圖覆蓋所有語言，而是把日英這個高價值語言對做深。其論文場景也提到法律、醫療、金融、專利等需要隱私保護和有限 GPU 預算的場景。
優點：MIT 許可友好；尺寸梯度完整；適合本地部署；對日英專項翻譯更聚焦。
缺點：語言覆蓋非常窄。如果你的產品需要中文、韓文、歐洲語言或多語言統一模型，CAT-Translate 只能作為日英專線，而不是主模型。
適合人群：日英內容團隊、日本市場產品、法務/專利/醫療文本團隊、日英私有化翻譯需求。
應用場景：日英文檔翻譯、日英字幕、漫畫/輕小說初譯、專利和合同預翻譯、企業內部日英知識庫。
10. PLaMo Translate：日本生態裡的日英翻譯強候選
PLaMo Translate 是 Preferred Networks 發布的翻譯專用模型，面向日英翻譯和本地執行場景。模型卡提醒用戶這是新技術，輸出可能出現不準確或偏差，並且使用前需要查看 PLaMo community license。
特點：PLaMo Translate 適合認真做日英翻譯評測的團隊。與 CAT-Translate 相比，它更像日本本土 LLM 生態的翻譯專項路線。
優點：適合日英本地部署實驗；日本語言生態相關資料較多；對日語場景有針對性。
缺點：許可不是簡單的 Apache/MIT 路線，商業使用前需要確認；非日英場景價值有限；模型卡也明確提醒需要做風險評估。
適合人群：日本市場團隊、日語內容平台、希望本地部署日英翻譯的開發者。
應用場景：日英長文本、日語內容本地化、內部資料翻譯、日英 benchmark 對比。
真實社群回饋：開發者最關心什麼？
從 Google 前列結果和社群討論來看，使用者關心的問題並不是「哪個模型最炫」，而是四個很樸素的問題。
第一，商業授權到底能不能用。在 Reddit 和 Hugging Face 討論中，NLLB 的 CC-BY-NC 授權經常被提到。很多人喜歡 NLLB 的覆蓋能力，但只要進入商業產品，非商業授權就會變成硬門檻。相對來說，LMT-60、MADLAD-400、CAT-Translate、IndicTrans2 這類標示 Apache-2.0 或 MIT 的模型更容易進入商業評估流程。
第二，小模型能不能真的本地跑。OPUS-MT、CAT-Translate 小尺寸、Hy-MT2 1.8B 量化、TranslateGemma 4B，都是社群更願意嘗試的原因。對很多團隊來說，能在一張消費級顯示卡、Apple Silicon 或私有伺服器上穩定跑，比理論最佳品質更重要。
第三，泛用大模型不一定贏過翻譯專用模型。社群裡經常有人問「為什麼不用普通多語言 LLM 直接 prompt 翻譯？」答案是：可以，但當你需要格式保持、術語一致、批量穩定、固定語言對高品質輸出時，翻譯專用模型仍然有意義。
第四，真實語言混合場景很難。例如 Hy-MT2 的 Hugging Face 討論裡，有用戶回饋 Hinglish 這類口語混合翻譯不如預期。這類回饋提醒我們：benchmark 好不等於所有真實輸入都好，尤其是混合語、俚語、行業黑話、OCR 雜訊和字幕斷句。
按場景選擇：不要把「最佳」理解成唯一答案
如果你要做一個覆蓋主流語言的產品預設翻譯模型，先測 TranslateGemma 12B，然後用 LMT-60 或 MADLAD-400 做對照。TranslateGemma 更現代，LMT-60 對中文和 Apache-2.0 更友好，MADLAD-400 語言覆蓋更廣。
如果你主要做中英和亞洲語言，優先測 LMT-60 和 Hy-MT2。LMT-60 在許可上更簡單，Hy-MT2 在複雜業務翻譯和指令跟隨上值得測，但要先審許可。
如果你做低資源語言研究，NLLB-200 仍然是重要基線。但如果要商業化，MADLAD-400 或其他許可更寬鬆模型可能更現實。
如果你做日英專項，優先測 CAT-Translate，再把 PLaMo Translate 作為強候選。專項模型往往比「萬能模型」更適合高價值固定語言對。
如果你做印度語言，IndicTrans2 應該進入第一批測試名單。
如果你做語音翻譯、會議翻譯、視訊字幕，SeamlessM4T v2 比純文字模型更貼近系統需求。
如果你只需要離線、輕量、固定語言對，OPUS-MT 很可能仍然是最快上線的選擇。
上線前的測試清單
在真正部署開源翻譯模型前，建議至少準備 200-500 條真實樣本，而不是只用公開 benchmark。樣本應該包含短句、長句、專業術語、表格、Markdown、HTML、JSON、字幕、OCR 雜訊、口語、客服對話和你最重要的語言對。
人工評測時，不要只問「通不通順」。要問：原意是否保留？有沒有漏譯？術語是否一致？數字、貨幣、單位、日期是否正確？品牌名和人名是否被亂翻？格式是否保持？是否有幻覺式補充？是否適合目標市場文化？
工程評測時，要記錄平均延遲、吞吐、顯存、量化後品質損失、批次處理速度、錯誤率、失敗重試策略和日誌脫敏方案。
法律評測時，要把模型許可、訓練資料許可、商用限制、地域限制、再分發限制、模型輸出使用政策一起檢查。尤其是「開放權重」模型，不要預設等於可自由商用。
最終推薦
2026 年最佳開源翻譯模型的推薦可以壓縮成一句話：通用預設選 TranslateGemma，中文和商業許可優先選 LMT-60，複雜企業翻譯評估 Hy-MT2，超廣語言覆蓋選 MADLAD-400，低資源研究看 NLLB-200，輕量固定語言對用 OPUS-MT，語音多模態選 SeamlessM4T，印度語言選 IndicTrans2，日英專項選 CAT-Translate 或 PLaMo。
如果你是第一次做開源翻譯模型選型，建議不要一次性比較 20 個模型。更好的路線是：先選 3 個候選模型，用你的真實文本測試一週。比如通用產品可以測試 TranslateGemma、LMT-60、MADLAD-400；中文業務可以測試 LMT-60、Hy-MT2、TranslateGemma；日英業務可以測試 CAT-Translate、PLaMo、TranslateGemma；語音業務可以測試 SeamlessM4T，再搭配一個純文本模型做 fallback。
常見問題
2026 年最值得優先測試的開源翻譯模型是哪一個？
如果只選一個通用候選，建議先測試 TranslateGemma，尤其是 12B 或 27B 版本。它是 2026 年發布的新一代開放翻譯模型，覆蓋 55 種語言，並且具備圖像中文字翻譯潛力。但如果中文和商業許可更重要，NiuTrans LMT-60 可能是更實際的第一選擇。
開源翻譯模型可以直接用於商業產品嗎？
不一定。Apache-2.0、MIT 通常更適合商業使用，但 NLLB-200 的 CC-BY-NC 屬於非商業許可，TranslateGemma、Hy-MT2、PLaMo 等模型也需要閱讀各自許可條款。上線前應由法律或合規人員確認。
NLLB-200 現在還值得用嗎？
值得，但主要適合研究、非商業、低資源語言和基線評測。對商業產品來說，NLLB-200 的非商業許可會成為主要障礙。
MADLAD-400 和 TranslateGemma 怎麼選？
如果你需要更廣語言覆蓋和許可友好度，優先測 MADLAD-400；如果你需要更現代的通用翻譯體驗、更好的模型生態和圖像文字翻譯能力，優先測 TranslateGemma。
中文翻譯應該選哪個開源模型？
優先測試 NiuTrans LMT-60 和 Tencent Hy-MT2 / Hunyuan-MT，再用 TranslateGemma 做對照。LMT-60 的 Apache-2.0 許可對商業團隊更友好，Hy-MT2 則更強調複雜業務翻譯和指令跟隨。
手機端或本地輕量部署用什麼模型？
固定語言對可以從 OPUS-MT 開始；如果需要更現代的翻譯能力，可以測試 TranslateGemma 4B、Hy-MT2 1.8B 量化版本或 CAT-Translate 小尺寸模型。最終選擇取決於設備記憶體、延遲要求和語言對。
日英翻譯選 CAT-Translate 還是 PLaMo？
如果你重視 MIT 許可和多尺寸小模型，優先測 CAT-Translate；如果你在日本生態內、願意處理 PLaMo community license，並希望比較日英專項品質，可以把 PLaMo Translate 納入測試。
開源翻譯模型會比 DeepL 或 Google Translate 更好嗎？
不一定。開源模型的優勢是可私有化、可控、可微調、可離線和成本可預測；商業 API 的優勢通常是穩定、易用和品質均衡。實際項目中，最好用真實業務樣本做人工評測，而不是只看模型名。