TranslateGemma 對比 ChatGPT Translate：如何選擇？

上週，幾個例行工作讓我重新思考我的翻譯堆棧：一份西班牙客戶便條滿是習語、德文微文案要求正式的「Sie」，還有日文技術支援票證，其中語氣佔了一半的意義。Google Translate 給了我堅實的草稿，但我最後還是改寫了比我想要的更多內容。嘆氣……舊習慣難改。就在那時，我終於決定嘗試兩個我一直在推遲的選項——在本地執行 TranslateGemma 和倚賴 ChatGPT 內建的翻譯模式。

我在 2026 年 1 月的幾個晚上進行了這些測試。沒有什麼花哨的，大約 40 則英文、西班牙文、德文和日文的短文本，加上一個小批次工作（含 HTML 的網站字串）。我不是在尋求完美。我想看看哪個設定讓工作感覺更輕鬆，而不是更吵鬧。

快速比較表

以下是 TranslateGemma、ChatGPT Translate 和 Google Translate 對我的表現簡短版本。

因素	TranslateGemma（本地）	ChatGPT Translate	Google Translate
設定	本地模型：需要一些配置：離線執行	最簡單的開始：網頁/應用/API	立即網頁/應用：無提示
隱私	強（離線，保留在設備上）	良好但基於雲端：資料政策適用	雲端：穩定但預設不是隱私
成本	你的運算時間：本質上每次執行都是免費	按代幣付費或使用 Plus 方案：偶爾使用成本低	免費（消費者）或支付雲端 API 費用
語言涵蓋範圍	良好但小於 Google	廣泛：主要語言穩定	優秀（整體最廣泛）
語氣/風格控制	透過提示強大：一旦調整就一致	強大：在風格細微差別方面最佳	有限：幾乎沒有風格控制
上下文處理	用例子很好：需要謹慎的提示	最擅長推斷上下文	弱：文字和領域無關
格式化/HTML	透過護欄和正規表示式，可靠	良好：如果被要求可以保留標籤	混合：經常更改間距/標籤
批次工作	如果你編寫腳本很好：確定性	透過 API 可以：注意成本	透過雲端 API 很好：最小風格控制
延遲	在良好 GPU/Apple Silicon 上快速：CPU 上較慢	快速：雲端速度	快速

讓我驚訝的是：ChatGPT Translate 以更少的手把手幫助處理了習語和語氣。TranslateGemma 在我設定一些規則後感覺更穩定。Google Translate 始終如一：一個可靠的基準。它快速、方便……但別指望它能理解你的花哨細微差別。

何時使用 TranslateGemma

TranslateGemma 是一個你可以在本地執行的開源模型。我在我的筆記型電腦（Apple Silicon）上用 int8 量化使用了一個小檢查點。前一個小時花在設定和編寫一個小腳本以保持 HTML 完整。之後，它感覺安靜和可預測，這很好。

隱私敏感或離線場景

我測試了兩份內部文件，移除了客戶名稱，只是看看感覺如何。解脫是即時的：沒有上傳，沒有瀏覽器標籤，沒有第二想法。翻譯比 ChatGPT 的要字面一些，但在一句或兩句內我學會了如何引導它。

我的基礎提示看起來像這樣：

保留原始格式化和標點符號。
精確保留 HTML 標籤和屬性。
在德文中使用正式稱呼（Sie），除非原始文本是非正式的。
如果術語出現在詞彙表中，優先使用詞彙表術語。

加入一次，然後通過相同的指令管理每個字串，我得到了一致的輸出。這是那種長期節省心力的控制。即使第一次不完美，它也是可預測地不完美，我可以修復。

令我驚訝的是：在飛機上（無 Wi-Fi），我順利翻譯了一批 120 個 UI 字串。僅 CPU 較慢，但可接受。這種獨立性現在很罕見，令人安心。

成本受控的批次翻譯

對於批次工作，TranslateGemma 很容易推理。我執行了一個產品描述 CSV (~6,800 字)，包含內聯和標籤。該模型尊重了標籤，規則很簡單：僅替換文本，永不標籤：如有疑問，保留代幣不變。輸出需要對德文複合名詞進行輕量校對，但無標籤修復。

成本基本上是我的時間和電池。如果你大量翻譯且不需要完美的習慣表達，那個權衡很友善。我會毫不猶豫地再編寫一次。如果你需要可審計性，本地日誌和輸入/輸出對也很直接。

我遇到的一些限制：

俚語和諷刺需要例子。沒有 1–2 個參考行，它傾向於字面。
日文敬語是安全的但生硬的。一個小風格區塊有所幫助。
領域術語需要詞彙表。一旦添加，一致性非常優秀。

如果你能接受設定，TranslateGemma 獎勵系統思維。一旦設定好欄杆，突然生活感覺容易了一點。

何時使用 ChatGPT Translate

我在網頁應用和透過 API 測試了 ChatGPT 的翻譯模式（GPT-4 等級）用於一個小腳本。頭條新聞：它感覺像一個恰好會翻譯的好編輯。

它對我閃耀的地方：

語氣和暫存器：在正式和非正式德文之間切換，只需一句指令就能完成。它也在日文支援回覆中軟化了，沒有失去清晰度。
習語和上下文：短行銷文案回來聽起來像是在目標語言中首先編寫的。我不必喂食上下文：它從幾句話推斷了足夠的信息。
混合輸入：它處理帶有表情符號、價格和括號的句子，沒有破壞它們。老實說，我半期望某處出現問題。

我為小批次使用了簡單的模式：帶有語氣規則的系統提示、用戶內容作為清單，然後要求 JSON 輸出，其中包含來源、翻譯和筆記的欄位。「筆記」行變成了一個安靜的 QA 步驟。當它標記不明確的短語時，它通常是對的。

摩擦：

成本注意：偶爾使用，它很小。對於日常管道，你需要速率限制、快取，也許還有一個較小的模型變體，其中語氣不重要。這不昂貴，但它是你必須監視的米尺。
HTML 保留：比我預期的更好，但我仍然用標記包裹了內容並在之後驗證了標籤。它遵循指令，只是不完美。
一致性：如果你每次都需要相同的措辭（風格指南、合規性），你仍然需要詞彙表，也許還有幾次射擊例子。它擅長多樣性，這並不總是你想要的。

當我選擇它時：任何涉及細微差別、幫助中心文章、行銷文案、跨團隊筆記的事物，其中語氣的權重可能與術語一樣多。如果你不想設定本地堆棧，它也是從「粗略想法」到「可用草稿」的最快路徑。

如果你很好奇，OpenAI 的文件解釋了翻譯提示基礎和 JSON 格式模式。我依賴那些來保持輸出清潔。

何時使用 Google Translate

我仍然首先打開 Google Translate 進行快速檢查。這就像肌肉記憶。優點很清楚：

涵蓋範圍：我放入了一些我不經常接觸的邊緣語言對。它快速給了我一些合理的。
速度：它是即時的。對於一次性句子，等待別處的模型微調感覺很傻。
基準真實：當我不確定習語是否倖存於花哨的翻譯時，我在這裡交叉檢查。如果兩者都同意，我就繼續。

在我一週的測試中它在哪裡掙扎：

風格：我無法將它推向品牌聲音或暫存器，我也不期望。那不是它的工作。
格式化：它有時會重新間距標點符號或移動表情符號。不是危機，但它增加了檢查。
領域語言：它在整個段落中不會堅持一個術語。足以理解，不足以運送複製。

如果你住在 Google 的雲端翻譯 API 內，那是另一個故事，你會得到詞彙表和批次端點。但在消費者應用中，將其視為快速鏡頭，而不是最後通過。

選擇前的限制

在你選擇一個方向之前，我會記住一些事情：

詞彙表和術語控制：如果你的工作取決於確切的術語（法律、醫療、產品字串），設定詞彙表並強制執行。TranslateGemma 在我的腳本中很好地配合了 CSV 查詢。ChatGPT 在我將詞彙表規則放入系統提示並要求筆記欄標記衝突時遵循了詞彙表規則。Google Translate（消費者）不支持：雲端 API 支持。
從右到左和標點符號：我的問題比預期的少，但我仍然在其最終 UI 中呈現輸出以捕捉間距和鏡像標點符號。所有三個都可能在這裡滑倒。
HTML 和程式碼：沒有人值得盲目信任。我用標記包裹了文本節點並在之後驗證了 DOM。TranslateGemma 對嚴格指令最服從，然後是 ChatGPT，然後是 Google Translate。
隨時間的一致性：ChatGPT 很擅長「聽起來自然」，不太擅長「每次聽起來相同」。TranslateGemma 一旦被引導，保持一致。Google Translate 對字面理解是一致的。
批次經濟學：本地模型是可預測的，你的時間，你的機器。雲端是彈性的、快速的，但計量的。如果你每週翻譯數千行，請提前進行數學計算並建立快取。
評估漂移：很容易將流暢度誤認為準確性。我從 ChatGPT 那裡發現了兩個自信但錯誤的習語，讀起來很漂亮，還有三行來自 TranslateGemma 太字面，錯過了潛台詞。我現在並排保留輸出和短檢查清單（語氣、術語、數字、標籤、日期）。

需要處理批次翻譯，而不是設定本地機器或與 GPU 基礎設施搏鬥？我依賴 WaveSpeed——我們自己的 API——所以我可以一次處理多個翻譯，可預測且快速 → WaveSpeed