開源翻譯 API LibreTranslate 實測，把整套翻譯引擎裝進自己機器

用 AI 摘要這篇文章：

ChatGPT Claude Perplexity Google Grok

LibreTranslate 給你的東西可以用一句話講完：翻譯基礎設施的完全控制權。自己架一套、完全離線、沒有字數上限、沒有呼叫額度，這些宣稱我在自己機器上全部驗過，都屬實。但它沒有給你的，是商業翻譯 API 的那種品質：引擎換成開源的 Argos 離線模型之後，繁體中文長句會出現簡繁夾雜，技術詞會直接胡謅。把它當「免費的 DeepL」會失望，把它當「自己機器上的翻譯引擎」則非常稱職。

先答三個最常見的問題。自架要錢嗎？不用，軟體與語言模型全部免費下載。官方網站的 API 有免費額度嗎？沒有，2026 年 9 月的定價頁從每月 14 美元起跳，官方問答明講免費方案撐不下去。繁體中文能用嗎？能，它有獨立的繁中模型，但輸出要自己再做一層簡繁校正才能正式上線。

這篇是我把 LibreTranslate 1.9.6 裝在自己機器上實際跑起來的紀錄：從安裝、模型下載、實際翻譯輸出，到定價與授權的逐項查證。想省時間的人，看結尾的分流判斷就夠。

它自我定位的方式值得先知道：官方文件的第一句話就強調，它不依賴 Google 或 Azure 這類專有翻譯服務，引擎換成同樣開源的 Argos Translate 函式庫，模型可以完全下載到自己機器上離線跑。這個定位決定了它的所有優點與所有限制：優點是整條翻譯鏈沒有任何環節需要對外部服務低頭，限制是模型品質就是 Argos 的水準，不會因為你自架而升級。

先看實測：同一句英文，簡中與繁中的輸出各長什麼樣

我用一句技術文件裡常見的英文丟給它：Machine translation is only as good as the model behind it. This sentence is a live test on a self-hosted instance.（機器翻譯的品質取決於背後的模型。這句話是在自架實例上的實測。）

指定目標為簡體中文（語言代碼 zh），輸出的前半句通順，後半句把 self-hosted instance 譯成了「自辦案現場」。這不是打字錯誤，是模型真的這樣認為：它沒有「自架實例」這個概念，就從訓練語料裡挑了發音接近的字拼在一起。同一個錯誤在我兩次不同的安裝環境裡都出現，可以重現。輸出以簡體字形呈現，這裡以繁體轉寫對照。

指定目標為繁體中文（語言代碼 zt），情況更有意思。短語表現不差：free and open source software 譯成「自由和開源軟體」，乾淨的全繁體。但換成上面那個長句，輸出以繁體轉寫是「機器翻譯只和它背後的模型一樣好 這句是自辦案的實驗」：原始輸出裡「機器」與「背後」兩個詞是簡體字形，「翻譯」與「一樣好」是繁體字形，同一句裡兩套字混著出現，句尾還少了句號。這個簡繁夾雜的現象同樣跨環境重現。

Pin

Argos 的繁中模型為什麼會這樣，我沒有去驗它的訓練語料，以下是我的推論：它的候選譯文機制會同時給出繁體與對岸慣用的兩種寫法，顯示模型內部本身就混著兩套中文語料，長句生成時就漏出來了。實務上的結論很單純：短語與日常句可以直接用，長句與技術複合詞要有品質心理準備，正式上線前加一層簡繁轉換校正（例如 OpenCC 這類工具）比指望模型本身可靠。

順帶講一個容易被略過的細節：中文在它內部分成兩個代碼，zh 指簡體、zt 指繁體，介面選單裡的繁中顯示為 Chinese (traditional)，官方文件卻沒有特別張揚這個代碼，很多人就一直以為它只有簡中，原始碼裡還設了互相備援的機制：找不到簡中模型時會嘗試用繁中模型頂上，反之亦然。對接 API 的台灣使用者來說，知道 zt 存在與否，直接決定你拿到的是簡體輸出還是繁體輸出。呼叫 API 時帶上 alternatives 參數可以要求模型多給幾個候選譯文，我實測同一個短語拿到了三種版本，其中兩個是繁體寫法，另一個把「軟體」寫成了對岸慣用詞，揀選空間不小，也再次印證語料混雜的推論。

順帶一提，它的語言偵測端點會直接分辨簡繁：丟一句中文進去，它判定 zh-Hans（簡體）或 zh-Hant（繁體），信心度 90%。方向反過來把中文譯成英文也通，輸出讀得懂但生硬，像考卷上的直譯句。這就是離線模型與商業引擎的差距本體。

從 pip install 到能用的 API，實際花掉的時間與記憶體

安裝本身就是一行指令：pip install libretranslate。我在乾淨的 Python 3.11 虛擬環境裡裝 1.9.6 版，連同全部依賴花了約 42 秒。啟動時指定只載中英相關模型：libretranslate –load-only en,zh,zt，它會自動下載四個翻譯模型（英譯簡中、簡中譯英、英譯繁中、繁中譯英），每個約 82MB，服務跑起來之後占用約 283MB 記憶體。不裝 Docker、不裝 GPU 驅動，一台普通筆電就能跑。

Pin

跑起來之後有幾個預設值該記住。它只聽本機位址 127.0.0.1，不對外暴露，要開放給區網或對外服務得自己改。它預設不啟用 API 金鑰，本機匿名呼叫直接成功；對照官方託管站，匿名打過去會收到 HTTP 400 與一行錯誤訊息，請你到付費入口申請金鑰。而最實用的一點：自架版本沒有字數上限，我丟了 2,475 字元的長文一次通過。官方託管版每呼叫上限 2,000 字元，官方建議超過就自己切塊分次送，這個困擾在自架環境不存在，翻譯參數的原始碼預設值是負數（不限制），兩者是同一套軟體的不同設定。

翻譯過程它自己也留了紀錄：先把段落斷成句子，再切成詞元，模型生成候選譯文並附上分數。長句被切成兩句後各自翻譯，上面那句錯譯的後半句分數明顯低於前半句（生成分數約 -7 對 -4.9），模型其實「知道」後半句翻得比較沒把握，只是 API 不會主動告訴你。要批次處理的人可以拿這個分數當品質篩選的粗線索。

生產環境的部署路徑官方文件寫得齊全：正式對外服務，官方文件建議改跑 Gunicorn 或官方 Docker 映像檔（官方文件明講是為了避開記憶體流失的問題）；有 NVIDIA 顯卡的機器可以走 CUDA 12.4.1 的加速映像；Kubernetes 環境有現成的 Helm chart。對外開放的自架站，速率限制參數（每分鐘、每小時、每日請求上限與突發門檻）都要自己設好，這些預設全部是關閉的，等於不設限地對全世界敞開。模型更新的參數也一樣，需要排程讓模型維持在最新版本。

自架第一個坑：指定了語言清單，它卻沿用機器上的舊模型

我第一次啟動時遇到一個該寫下來的狀況。指令明確指定 –load-only en,zh,zt，服務起來之後語言清單卻是英、簡中加上法、德、義、日、韓、葡、西九種，繁中不見了，中譯英還直接報錯「English (en) is not available as a target language from Chinese (zh)」。

原因藏在啟動邏輯裡：LibreTranslate 只在已安裝模型少於兩個的時候才執行「下載並安裝指定語言的模型」這段流程，否則整段跳過，直接沿用機器上已有的模型集合。我這台機器先前裝過其他 Argos 翻譯模型，數量超過門檻，於是我指定的語言清單被完整忽略。用一個乾淨的模型目錄重新啟動，同一條指令就正確裝滿四個雙向模型，繁中也出現了。

這對自架新手的意義是：看到「語言清單跟我指定的不一樣」或「某個方向翻不過去」，先檢查模型目錄的存量，清掉舊模型或加上強制更新參數重跑，不要急著懷疑自己指令打錯。模型管理，而不是安裝，才是自架 LibreTranslate 真正的日常工作。Argos 的模型是獨立套件（每個翻譯方向一個包，中英四個方向各約 82MB），升級、清理、指定版本都發生在這一層；LibreTranslate 本體只是包在引擎外面的 API 服務，這條依賴關係想通了，後面的問題都好排查。

官方託管 API 沒有免費額度，每月 14 美元起跳

很多人對 LibreTranslate 的印象停留在「免費翻譯 API」，這裡要修正的是官方託管服務的現況。2026 年 9 月的付費入口列出三個方案：Starter 每月 14 美元、Pro 每月 29 美元、Business 每月 58 美元，差別在每分鐘請求量（瞬間 25、80、200 次；持續使用大約 6、20、50 次），三個方案共用每呼叫 2,000 字元的上限，都有七天無條件退費。沒有免費方案，也沒有試用。

官方問答把話講得很白：過去試過提供低用量的免費金鑰，但流量成本撐不住，做不下去，想要免費就自己架。還有一句該抄下來的自白：跑到與官方同等性能的自架成本，可能超過一把金鑰的月費。這筆帳算得誠實，不是行銷話術，決策時兩邊都要算。需要更高請求量或字元上限的，官方也接受直接聯絡支援談客製方案，這條路藏在問答裡，頁面上不明顯。

定價頁上有個行銷詞要單獨拿出來看：Starter 方案掛了「最高隱私」的標語。它指的是託管服務不把你的譯文拿去另作他用，但文字終究送進了官方伺服器，信任對象是這個專案的開發者本人，入口頁的退費流程裡開發者還署名自我介紹，這是個人品牌小團隊在營運的訊號。對隱私要求到「一個字都不能出機器」的場景，託管再怎麼標榜也替代不了自架，這條線畫在哪裡是使用者的判斷。

拿數字換個角度算：每月 14 美元買到的持續速率是每分鐘約 6 次呼叫、每次 2,000 字元，照這個速率全天候跑滿，理論月流量可以推到五億字元等級。同樣字元量拿到 Google Cloud 的計價表上是五千到上萬美元的帳單，前提是你能接受 Argos 模型的品質與速率節流。反過來說，用量只有每天幾萬字元的人，14 美元月費絕大部分是在買「免維運」這件事，自架的成本優勢在量大的批次場景才會拉開。

AGPL 授權之外，商標是第二層限制

軟體授權是 AGPL-3.0：你可以自由使用與修改，但把修改後的版本提供成網路服務時，修改的部分也要以同樣條款開源。內部自用不受影響，想基於它做對外服務的人要先想清楚這條。

比較少人注意到的是商標層。專案有獨立的商標政策文件，LibreTranslate 與 LTEngine 是它的商標，而且政策明確把「打包成容器或雲端服務提供的版本」視為修改版：修改版可以用文字誠實說明「基於 LibreTranslate」，但不能把商標放進你自己的產品名稱、網域名稱或商業服務名稱裡，除非取得書面許可。開源授權給你程式碼的自由，商標政策保留名稱的控制，兩層分開看，商用前都要過一遍。

隱私邊界：譯文不出機器是真的，細節要跟著版本更新

自架的隱私宣稱經得起檢驗。服務預設只聽本機，翻譯在機器上完成，使用者提交的譯文建議也存在本機的 SQLite 資料庫（欄位就是原文、譯文、來源語言、目標語言四項），原始碼裡翻不到遙測或統計上報的程式碼，對大多數自用場景足夠。

不過「自架等於隱私」不能推得太滿。2026 年 9 月底官方才合併一個修復：網頁介面原本會把待譯文字寫進網址的查詢字串，重新整理時這段文字會送到伺服器、留在請求日誌裡；修復把它改放到網址的片段部分，瀏覽器不會送出。也就是說，自架後一直沒有升級的舊版本，帶著一個把譯文寫進自己日誌的小洞。這個案例通用的地方在於：隱私工具也要跟著版本升級，部署完就不管它，等於把邊界交給舊程式碼。

想直接用公共實例的人也要認清現況。官方文件列的公共站只剩三個：官方主站要金鑰，另一個在我實測時連不上，第三個擋了我的請求；許多舊教學文指路的 libretranslate.de，現在整個網域重導向到官方網域的德文站。公共免費實例在這個專案的生態裡已經式微，文件裡反而留著洋蔥網路與 i2p 的鏡像位址，算是這類隱私工具的社群註腳。結論：要穩定，要嘛自架，要嘛付費。

誰該自架、誰該付月費、誰該直接走商業 API

自架適合三種情境：隱私敏感的文件批次處理（合約、內部文件、客戶資料，一個字都不能出機器）；離線或內網環境（斷網的產線、研究環境）；以及需要無限額程式化呼叫的工程場景（爬蟲結果後處理、資料清洗、接到自己的翻譯工具鏈）。如果你已經在用 MTranServer 這類自架離線翻譯伺服器，LibreTranslate 是同一個賽道的另一個選擇，走的是更完整的開源生態與多語言模型管理。瀏覽器翻譯那一側的 FluentRead 與 Read Frog 負責前台呈現，自架翻譯 API 負責後端引擎，兩側本來就可以互補搭配。

官方託管適合不想維運、用量中小、要的是穩定端點的人，14 美元的月費換免維運與更高的單機性能，官方那句自架成本自白記得納入試算。追求翻譯品質的對外產品、公開場合的即時翻譯，直接看商業 API：Argos 離線模型的繁中輸出品質，不適合放上台面。文件翻譯量大的人則介於兩者之間，先算字元量再決定。

專案本身的健康度不用擔心：GitHub 上接近一萬七千顆星，2026 年 9 月主分支仍有新的提交紀錄，最新正式版 1.9.6 於 2026 年 5 月發布，開立的議題一百多個、處理節奏正常。它不是新鮮玩意：2020 年底就開始累積的老專案，自架的投資短期內不會變成孤兒。想先試水溫的人成本極低：建個虛擬環境、一行安裝、一行啟動指定 en,zh,zt，再拿 curl 打本機埠就是完整的翻譯 API，十分鐘內可以親眼看到自己的譯文長什麼樣，值不值得繼續投入當場就有答案。

我的總結判斷：它把「引擎裝進自己機器」這件事做到確實可用，品質上限也標得清清楚楚。能讓你一分錢不花就把整套翻譯引擎收進自己機器，這件事在 2026 年依然稀奇；但花錢也買不到的，是 Argos 模型天生離線、語料規模有限的品質上限。先想清楚自己要的是控制權還是譯文品質，答案就自動分流出來了。