如何用本機 LLM 翻譯長文件：分塊與檢查

人們使用本機 LLM 翻譯文件只有一個原因：檔案不能離開自己的機器。本機模型可以完成這項工作，但它給你的是純文字，而不是翻譯後的檔案，而且它最嚴重的錯誤往往是無聲的。在我們的測試中，一次針對 3,179 個單詞摘錄的單一請求回傳了正確的段落數量和乾淨的結束訊號，但其中一個段落遺失了超過三分之一的內容，還多出了原始文本中沒有的句子。

簡短回答： 在段落邊界將文字分割成約 600 個單詞的區塊，將人名和重複出現的術語詞彙表放入系統指令中，關閉模型的思考模式，並在信任它之前，將每個區塊與其來源逐段比較。我們執行測試的三種方式都在某處失敗了，而且沒有任何失敗產生錯誤訊息。預期筆記型電腦上的中型模型處理一整本書需要數小時，並計劃自行重建格式。

以下所有內容來自 2026 年 10 月 23 日的一次執行：在 Apple M4 Max（64 GB 記憶體）上的 LM Studio 0.4.8 中使用 Qwen 3.6 27B（Q4_K_M GGUF），將卡夫卡《變形記》的開頭從德文翻譯成英文。測試腳本、結果和原始失敗範例可免費下載，以便您用自己的模型重複測試。

何時本機 LLM 是正確的工具

當文件的規定（而非便利性）決定選擇時，就在本機執行翻譯：

• 客戶合約、研究協議或雇主政策禁止將檔案上傳到外部服務；
• 文字是個人或機密資料，且您無法事先移除敏感部分；或者
• 您需要處理許多檔案，沒有按文件計費的成本，而且您已經擁有合適的硬體。

如果這些都不適用，本機模型通常是通往更差結果的較慢路徑。您放棄了文件翻譯服務提供的三樣東西：原始格式的翻譯檔案、比您的機器能容納的更大的模型，以及為整本書的一致性而建構的工作流程。在選擇任一途徑之前，請先閱讀文件翻譯隱私檢查清單。它涵蓋了處理檔案的權限、最小工作副本，以及服務如何處理上傳的內容。

「本機」也需要一個精確的定義。模型在您的電腦上執行，在我們的測試中，請求只傳送到 localhost。這並不告訴您模型周圍的應用程式記錄、更新或回報了什麼。如果您的規定要求證明沒有任何東西離開裝置，請檢查執行階段本身的設定和政策，或在沒有網路連線的機器上執行它。

我們測試了什麼

我們翻譯了《變形記》的前 19 段（3,179 個德文單詞），來源是公共領域的古騰堡計劃版本。文學德文是一個公平的壓力測試：段落很長，句子層層嵌套，相同的人物和職稱反覆出現。

三次執行都使用相同的模型和設定：溫度 0.2、最大輸出 12,000 個 token，以及 16,384 個 token 的上下文視窗。指令要求每個德文段落對應一個英文段落，別無其他。

每次執行都以正常的停止訊號結束，而每次執行都包含不同的無聲錯誤。執行 C 遺漏並憑空生成了文字。執行 B 翻譯了它被告知要跳過的文字。執行 A 最為乾淨，但在最後一個分段中給某個角色安錯了職位。

失敗案例 1：單次大型請求遺漏了部分段落

執行 C 正常結束，並準確回傳了 19 個段落。段落數量檢查本會讓它通過。然而，第 6 段在原文為 260 個詞的情況下，回傳時只有 214 個詞。

在原文中，葛雷戈看著時鐘，意識到自己錯過了火車，接著考慮打電話請病假：他的老闆會帶著健康保險醫生一起來，而那位醫生認為每個人都是健康的，只是不願工作，葛雷戈則承認自己除了昏昏欲睡和異常的食慾之外，其實感覺良好。執行 C 翻譯了前半部分，然後遺漏了整個請病假的段落，也就是該段 260 個德文詞中的 98 個詞。取而代之的是，它寫道葛雷戈「會當場被解僱」、辦公室助理「傾向於把向他報告的一切都視為展現自己的機會」，以及這個念頭「讓他嘴角上揚」。這些內容在德文原文中都不存在。

分段執行則完整翻譯了同一段落，共 267 個詞。

單一樣本並不能證明長請求總是失敗。它確實顯示了該檢查什麼：一個長的單次請求可能會無聲地壓縮或憑空生成文字，同時在結構上仍看似完整。不懂德文的讀者根本沒有理由會注意到。

失敗案例 2：模型翻譯了它被告知要跳過的「上下文」

一個常見的技巧是隨每個分段附上前一段落，讓模型保持連貫。在執行 B 中，我們將其加入訊息中，標籤為「上下文（已翻譯，請勿翻譯）」。

在第 4 個分段中，模型還是翻譯了它。該分段為三個原文段落回傳了四個段落，而第一個是第 3 個分段最後一段的第二次翻譯。若合併在一起，這本書將會包含該段落兩次，且每次措辭不同。

實用規則：如果你傳送上下文，請將其排除在要求模型翻譯的文字之外，保持簡短，並檢查每個分段的段落數量。如果你無法檢查，就不要傳送。

失敗案例 3：單獨傳送的分段給角色安錯了職位

執行 A 在傳送每個分段時沒有詞彙表，也沒有上下文。前五個分段運作良好：Prokurist 在其出現的全部 16 個地方都譯為「chief clerk」。第六個分段是單一段落，內容是 chief clerk 隔著門斥責葛雷戈。單獨來看，模型將 der Prokurist 譯為「the traveling salesman」，也就是葛雷戈自己的工作。段落數量相符，長度比為 1.00，因此兩項結構檢查都沒有察覺。

在執行 B 中，系統指令包含了詞彙表，並以上一段落作為上下文，同一段落正確使用了「chief clerk」。這個測試無法判定是哪一項修正了問題。由於上下文也導致了失敗案例 2，詞彙表是跨分段傳遞名稱和角色的更安全位置：它簡短、位於指令中，而且你可以機械化地檢查它。

經得起考驗的工作流程

1. 先從檔案中取出純文字

本地 LLM 翻譯的是文字，不是檔案。開始前先轉換文件：

• DOCX 或 EPUB： 匯出為純文字或 Markdown，每個區塊一個段落，並將標題保留為獨立行。
• 含文字層的 PDF： 擷取文字，然後修復斷行和連字號。我們關於修復 OCR 斷行與連字號的指南涵蓋了相同的清理工作。Docling 這類轉換工具可以從 PDF 和 Office 檔案產生 Markdown。
• 掃描版 PDF： 先執行 OCR。如果你不確定 PDF 是否有可用的文字，請參閱PDF 文字擷取與 OCR 的比較。

保持段落結構完整。後續每一項檢查都依賴原文與譯文段落之間的一對一對應。

2. 關閉思考模式並確認已關閉

目前許多開放模型在回答前會先進行推理。就翻譯而言，這會浪費時間與輸出 token。在我們的設定中，一個 200 token 的測試請求花了 199 個 token 在推理上，最後回傳空白答案。

我們試了三種常見的切換方式。在提示中加入 /no_think 沒有任何效果，使用 chat_template_kwargs 搭配 enable_thinking: false 也沒有任何效果。在請求中送出 "reasoning_effort": "none" 則關閉了推理：回應回報 0 個推理 token，並直接回傳譯文。這個參數並未列在 LM Studio 的對話補全頁面上，因此請將其視為我們在 0.4.8 版搭配此模型時觀察到的行為。請檢查你自己回應中的 reasoning_tokens 數量，而不要信任任何切換開關。

3. 在切分區塊前先設定好上下文視窗大小

上下文視窗必須容納指令、區塊和完整譯文。在我們的分塊執行中，一個 500 到 670 字的德文區塊依詞彙表和上下文不同，約使用 800 到 1,500 個輸入 token，以及 640 到 870 個輸出 token，因此幾千個 token 就足夠了。單一 3,179 字的請求則需要 4,953 個輸入 token 和 3,930 個輸出 token。

根據我們於 2026 年 10 月 23 日查閱的 Ollama 上下文長度文件，Ollama 會依可用記憶體設定預設上下文長度：VRAM 低於 24 GiB 時為 4k token，24 到 48 GiB 時為 32k，48 GiB 以上則為 256k。你可以用 OLLAMA_CONTEXT_LENGTH 調高。在 LM Studio 中，載入模型時設定上下文長度。如果區塊加上其譯文無法容納，輸出可能會被截斷。

4. 以段落邊界切分區塊，每塊約 600 字

絕不要在段落或句子內部切分。我們的區塊以 700 字為目標，並在最接近的段落邊界結束，結果產生六個 243 到 667 字的區塊。較小的區塊成本不高：執行 A 花了 10.4 分鐘，而單一請求花了 9.5 分鐘，而且失敗的區塊重新執行成本很低。

指令要簡短，且每個區塊都完全相同。我們的指令是：翻譯成英文，每個輸入段落恰好保留一個輸出段落並以空行分隔，且只輸出譯文。在同一指令中加入詞彙表：每個名稱、職稱或重複出現的術語一行，格式為 Prokurist = chief clerk。我們的建立翻譯詞彙表指南說明了應包含哪些內容。較短的區塊會失去周圍的故事脈絡，而詞彙表正是承載脈絡的關鍵。

5. 在合併前檢查每個區塊

對每個區塊執行三項檢查：

1. 段落數。 輸出的段落數必須與輸入相同。這項檢查抓到了失敗 2。
2. 每段長度比例。 比較每個譯文段落與其原文的字數。這項檢查抓到了段落數檢查漏掉的失敗 1。
3. 每段詞彙表術語。 原文術語出現的地方，其指定譯文應出現相同次數。這項檢查抓到了另外兩項檢查都漏掉的失敗 3。有詞形變化的語言在這裡需要一些判斷，因為德文或俄文術語會改變形式。

就德文到英文的散文而言，執行 A 的段落維持在每輸入一字對應 0.98 到 1.17 個輸出字之間。執行 C 的受損段落則是 0.82。請檢查幾個在你語言組合中你信賴的段落，據此設定你自己的範圍；我們腳本中的預設值只是起點，不是標準。

被標記的段落是優先閱讀的地方，而不是錯誤的證明。接著閱讀譯文本身，尤其是名稱、數字、否定詞，以及任何讀者會據以行動的內容。書籍翻譯品管檢查清單涵蓋了那項審閱。

6. 重建文件

模型回傳的是文字。標題、註腳、表格、圖片、頁面版面與樣式必須手動或透過轉換工具放回。對簡短報告而言這是小事。對有註腳和表格的書籍而言，這可能比翻譯本身更耗時。

整本書要花多久時間

我們的分塊執行在 10.4 分鐘內翻譯了 3,179 字，在這台機器上約每分鐘 300 字。以這個速度，一本 90,000 字的小說大約需要五小時的生成時間，還不包括檢查與重新執行。這只是從一次執行得出的簡單算術，不是基準測試。速度會隨模型大小、量化、硬體、語言組合，以及機器同時還在做多少事而改變。

模型檔案在磁碟上為 17.5 GB，而上下文快取與執行時期緩衝區還需要額外記憶體，因此機器需要的可用記憶體會明顯多於檔案大小。較小的模型執行更快、所需記憶體更少，通常會在品質上付出一些代價。在投入整本書之前，先用具代表性的樣本測試。我們的最佳翻譯 LLM指南說明了如何建立該樣本並公平比較模型。

本機 LLM 還是文件翻譯服務

若你的規定允許上傳檔案，文件翻譯服務能省去上述大部分工作。BookTranslator 可翻譯完整的 PDF、EPUB 與 DOCX 檔案並回傳翻譯後的檔案，其常見問題說明上傳的檔案與翻譯輸出不會用於訓練 AI 模型。它是雲端服務，因此當檔案必須留在你的電腦上時便不適用。若你正在自行執行模型與付費使用服務之間做決定，LLM 翻譯的實際成本 說明了如何規劃 token 方面的預算。

取得測試檔案

所有檔案都位於 /files/blog/translate-with-local-llm/ 資料夾中：

• local_llm_translation_test.py：針對 LM Studio 本機 API 的完整測試，包含全部三次執行。將其指向其他模型或來源文字即可重複測試。
• check_translation.py：逐段比對來源文字與譯文，並輸出段落數不符、長度比例超出範圍以及缺少術語表詞彙的情形（使用 --term "Prokurist=chief clerk"）。它可搭配任何工具的輸出使用。
• results.csv：每一次請求及其段落數、字數、token 數與時間。
• failure-examples.txt：全部三次失敗的德文原文與模型原始輸出。

在依賴任何長篇譯文之前，先以你的詞彙表詞條執行 check_translation.py。這只需幾秒鐘，而它在這次測試中標記出了全部三項失敗。它無法告訴你一個流暢的句子是否譯錯，因此被標記的段落是你閱讀的起點，而非終點。