1. 项目概述

如果你曾经尝试过用AI翻译一本完整的电子书、一份长篇技术文档，或者一部带时间轴的字幕文件，大概率会遇到几个让人头疼的问题：文件太大，AI的上下文窗口塞不下；翻译到一半网络断了或者程序崩溃，一切得从头再来；最要命的是，辛辛苦苦翻译出来的文档，原来的排版、样式、章节结构全乱了，字幕的时间轴也对不上，简直没法用。这些问题，在我过去几年折腾各种翻译工具时，几乎成了家常便饭。直到我遇到了 TranslateBooksWithLLMs 这个项目，它几乎是为解决这些痛点而生的。

简单来说，这是一个利用大语言模型（LLMs）来翻译书籍、文档和字幕的工具。它的核心魅力在于“无感”和“完整”。所谓“无感”，是它通过智能分块技术，能处理任意长度的内容，你扔给它一本上千页的小说，它也能有条不紊地消化掉，并在分块时保留足够的上下文，避免出现“前言不搭后语”的翻译断层。所谓“完整”，是它近乎偏执地保留了原始文件的一切：EPUB里的字体、样式、目录结构，DOCX里的表格、图片、超链接，SRT字幕里的每一毫秒时间码，都会原封不动地呈现在译文里。这背后是一套对文档结构的深度解析和重建逻辑，而不是粗暴的文本替换。

更让我觉得贴心的是它的“断点续传”机制。翻译一本大部头时，谁还没遇到过断电、断网或者只是想暂停一下的情况？这个工具的检查点系统会自动保存进度，下次打开时，你可以从上次中断的地方无缝继续，之前已经翻译好的部分绝不会浪费。它支持多种主流的LLM服务提供商，从完全本地的Ollama，到简单易用的Poe，再到模型超市OpenRouter，以及OpenAI、Mistral、DeepSeek、Gemini等，你可以根据自己对成本、速度和质量的权衡自由选择。无论是想用家里的显卡跑本地模型追求隐私和零成本，还是调用云端最强模型追求极致质量，它都能满足。

2. 核心设计思路与方案选型

2.1 为何选择“分块翻译”而非“全文翻译”

面对长文档翻译，最直观的想法可能是：“找一个上下文窗口足够大的模型，把整本书塞进去。”但这个思路在实际操作中问题很多。首先，目前绝大多数高性能LLM的上下文窗口仍是有限的（如128K、200K），对于超长篇内容依然不够。其次，即使窗口足够大，将数十万token的文本一次性送入模型，不仅推理速度极慢、成本高昂，而且模型在生成长文本时更容易出现注意力分散、前后矛盾的问题，质量反而可能下降。

因此， 分块翻译（Chunk-based Translation） 是更务实且高效的选择。但分块不是简单地把文本按固定字数切开，那会破坏句子、段落甚至章节的完整性，导致上下文丢失，翻译结果支离破碎。TranslateBooksWithLLMs的智能分块系统，其核心在于 “基于语义和结构的分割” 。

它的工作流程大致是这样的：首先，工具会解析输入文件的原始结构。对于EPUB，它会识别出章节（ <h1> , <h2> ）、段落（ <p> ）、列表等HTML标签；对于DOCX，它会解析段落样式、标题层级；对于SRT，它会严格按时间码和字幕条目来划分。然后，它会以这些自然的结构边界为优先分割点，确保每个“块”都是一个语义相对完整的单元（比如一个完整的章节或一组连续的段落）。只有在单个结构单元本身长度超过预设的token上限（默认约400个token）时，才会在单元内部寻找合适的句子边界进行二次分割。这种策略最大程度地保证了每个翻译任务块拥有自洽的上下文，模型能更好地理解并翻译它。

2.2 格式保真度的实现原理

格式保真是这个工具区别于许多“文本提取-翻译-文本回填”式工具的关键。很多工具翻译后得到的是一个纯文本文件，所有格式信息都丢失了。TranslateBooksWithLLMs采用了 “结构化解析-内容替换-精确重建” 的管道。

以EPUB文件为例，EPUB本质上是一个ZIP压缩包，里面包含XHTML文件（内容）、CSS文件（样式）、OPF文件（元数据）等。工具在解析时，会完整解包并分析整个文档对象模型（DOM）。翻译时，它只针对DOM树中的文本节点（Text Nodes）内容进行提取和替换，而所有标签（Tags）、属性（Attributes）和样式引用（Style References）都保持原样。翻译完成后，它再按照原始的结构和链接关系，将翻译好的文本节点精准地填回原来的位置，最后重新打包成EPUB。这样一来，封面、目录、章节标题、字体加粗、斜体、超链接，甚至内嵌的图片和脚注，都会得到完美保留。

对于SRT字幕，时间码行（如 00:01:02,345 --> 00:01:04,678 ）和序号行会被严格识别为非翻译内容，只有真正的字幕文本行会被送入模型。翻译后，时间码和序号与新的字幕文本精确配对，确保了视频播放时字幕的同步性。

2.3 多提供商架构的设计考量

支持从本地到云端的多家LLM提供商，极大地提升了工具的灵活性和可用性。这种设计主要基于以下几点考量：

1. 成本与隐私的平衡 ：本地运行（如通过Ollama）完全免费且数据不出本地，适合翻译敏感或版权严格的材料。云端服务（如OpenAI GPT-4o）虽然产生费用，但通常质量更高、速度更快，适合对质量有极致要求的任务。
2. 模型选择的多样性 ：不同的模型在不同语言对和文体上的表现差异很大。OpenRouter聚合了超过200个模型，为用户提供了“模型超市”，可以方便地测试和选择最适合当前翻译任务的模型。例如，翻译文学小说可能用Claude系列更优，而翻译技术手册可能GPT-4 Turbo更合适。
3. 服务稳定性与降级方案 ：不过度依赖单一服务商。当某个API出现故障或限流时，用户可以快速切换到另一个提供商，保证翻译任务不中断。
4. 标准化接口（OpenAI Compatibility） ：工具将许多本地推理服务器（如LM Studio, llama.cpp, vLLM, LocalAI）都视为“OpenAI兼容”的提供商。这是因为这些服务器大多实现了与OpenAI Chat Completions API相似的接口。通过一个统一的 --provider openai 参数，配合自定义的 --api_endpoint ，就能轻松接入，这大大降低了集成复杂度。

这种架构要求工具内部有一个统一的“适配器（Adapter）”层，将不同提供商的API调用细节（如请求头、参数命名、响应格式）抽象成一套内部接口，从而让核心的翻译逻辑与具体的模型服务解耦。

3. 详细实操流程与配置解析

3.1 环境准备与快速启动

对于大多数用户，最快捷的方式是使用预编译的可执行文件，完全无需接触Python环境。

Windows用户：

1. 从项目GitHub Release页面下载 TranslateBook-Windows.zip 。
2. 解压到任意目录，例如 D:\Tools\TranslateBook 。
3. 如果你打算使用本地模型，需要安装 Ollama 。下载安装后，在命令行运行 ollama pull qwen2.5:14b 来拉取一个推荐的中等规模模型（约14B参数）。
4. 双击运行解压目录下的 TranslateBook.exe 。
5. 首次运行会在同目录下创建 TranslateBook_Data 文件夹，用于存放配置和缓存。随后，默认的Web浏览器会自动打开 http://localhost:5000 。如果没有自动打开，请手动在浏览器地址栏输入。

macOS用户（Apple Silicon芯片）：

1. 下载 TranslateBook-macOS-AppleSilicon.zip 。
2. 解压后，你可能会得到一个名为 TranslateBook 的可执行文件。
3. 首次在macOS上运行未签名的开发者应用时，系统会阻止。你需要前往 系统设置 > 隐私与安全性 ，在底部通常会看到关于“已阻止”应用的提示，点击 “仍要打开” 。有时可能需要右键点击应用，选择“打开”，然后在弹出的对话框中确认。
4. 同样，安装Ollama并拉取模型后，运行应用，访问 http://localhost:5000 。

注意： Web界面是工具的主要操作入口，它提供了文件上传、模型选择、参数调整等可视化操作，比命令行更友好。但命令行在批量处理和自动化集成方面更有优势。

3.2 核心配置详解（.env文件）

对于进阶用户，或者需要自定义默认行为的情况，配置 .env 文件是关键。在可执行文件同级目录，或源码的根目录下，复制 .env.example 文件并重命名为 .env 。

# .env 配置文件示例与解读

# 1. 选择默认的LLM提供商
# 可选: ollama, poe, openrouter, openai, mistral, deepseek, gemini
LLM_PROVIDER=ollama

# 2. Ollama 配置（当LLM_PROVIDER=ollama时生效）
# Ollama本地服务的API地址，通常不需要修改
API_ENDPOINT=http://localhost:11434/api/generate
# 默认使用的模型名称。确保你已通过 `ollama pull <模型名>` 下载了该模型。
DEFAULT_MODEL=qwen2.5:14b

# 3. 云端提供商API密钥（按需填写）
# OpenRouter的API密钥，格式通常为 sk-or-v1-...
OPENROUTER_API_KEY=your_openrouter_key_here
# OpenAI的API密钥
OPENAI_API_KEY=sk-your_openai_key_here
# Google Gemini的API密钥
GEMINI_API_KEY=your_gemini_key_here

# 4. 性能与流程控制
# 单个翻译请求的超时时间（秒），对于长响应或慢模型可以调高
REQUEST_TIMEOUT=900
# 智能分块时，每个块允许的最大token数。这是平衡上下文完整性和模型性能的关键参数。
# 值太小（如200）会割裂上下文；值太大（如1000）可能超出某些模型的单次处理能力，或导致速度变慢。
# 400是一个对大多数模型和任务都较为均衡的默认值。
MAX_TOKENS_PER_CHUNK=400

配置心得：

• MAX_TOKENS_PER_CHUNK 是最值得微调的参数之一。如果你翻译的是技术文档，句子结构清晰，可以尝试降低到300-350，让分块更细，翻译可能更准确。如果翻译的是文学性很强、段落间关联紧密的小说，可以适当提高到450-500，给模型更多的上下文来理解文风和伏笔。
• 使用云端API时，务必保管好你的 .env 文件，不要将其上传到公开的代码仓库。 .env 文件通常已被项目 .gitignore 排除。

3.3 通过Web界面进行翻译

访问 http://localhost:5000 后，你会看到一个简洁的界面。

1. 上传文件 ：点击上传区域，选择你的EPUB、DOCX、TXT或SRT文件。
2. 选择提供商与模型 ：
   • 如果使用本地Ollama，在“Provider”下拉框选择“Ollama”，然后在“Model”框中输入你已拉取的模型名，如 qwen2.5:14b 。
   • 如果使用Poe，选择“Poe”，并需要在“API Key”框中填入你的Poe API密钥。模型列表会自动加载。
   • 如果使用OpenRouter/OpenAI等，选择对应提供商并填入API密钥，然后选择模型。
3. 设置语言 ：指定源语言（Source Language）和目标语言（Target Language）。工具支持的语言很全，包括简体中文（Chinese）、英语（English）、日语（Japanese）、法语（French）等。
4. 高级选项（Advanced Options） ：
   • Text Cleanup ：如果源文件来自扫描版PDF转换（OCR）或排版混乱，开启此选项可以尝试修复常见的印刷错误、多余空格和乱码。
   • Refine ：启用“两阶段翻译”。第一阶段生成初稿，第二阶段让模型（可以是同一个，也可以是另一个更强的模型）对初稿进行润色、优化，使其更符合目标语言的文学表达习惯。这能显著提升译文质量，但耗时和成本（如果使用付费API）会翻倍。
   • TTS (Experimental) ：一个实验性功能，利用Edge-TTS服务为翻译后的文本生成语音。可以指定语音角色、语速等。
5. 开始翻译 ：点击“Translate”按钮。界面会显示进度条、当前正在处理的块（Chunk）以及预估剩余时间。

实操现场记录 ：我曾用它将一份300页的英文技术PDF（先转换为DOCX）翻译成中文。选择Ollama + qwen2.5:14b 模型，开启 Refine 选项（第二阶段用了 qwen2.5:72b 模型进行润色）。整个过程在RTX 4070显卡上耗时约4小时。最终得到的DOCX文件，所有图表、公式、标题编号、页眉页脚都完美保留，翻译质量远超我之前用其他工具得到的生硬机翻结果。

3.4 通过命令行进行高效批量处理

对于需要定期、批量翻译文档的用户，命令行（CLI）是更高效的选择。它便于脚本化、自动化，并且资源消耗通常比Web界面略低。

基础命令示例：

# 最基本用法：翻译一个EPUB，从英文到中文，使用默认的Ollama和模型
python translate.py -i ./books/my_novel.epub -sl English -tl Chinese

# 指定输出文件名和路径
python translate.py -i input.docx -o ./translated/手册_中文版.docx -sl en -tl zh

# 使用OpenRouter的Claude 3.5 Sonnet模型翻译成法语
python translate.py -i document.txt --provider openrouter \
    --openrouter_api_key sk-or-v1-xxx... -m anthropic/claude-3.5-sonnet:20241022 -tl French

# 使用本地运行的LM Studio服务器（OpenAI兼容接口）
python translate.py -i subtitles.srt --provider openai \
    --api_endpoint http://localhost:1234/v1/chat/completions \
    -m my-fine-tuned-model -sl English -tl Spanish

关键参数解析表：

参数	全称	作用与示例	注意事项
-i	--input	必需 。指定输入文件路径。 -i ./data/book.epub	支持相对或绝对路径。
-o	--output	指定输出文件路径。不指定则自动生成，格式为 原文件名 (目标语言).原后缀 。	自动生成规则清晰，通常无需手动指定。
-sl	--source_lang	源语言。 -sl English 或 -sl en 。	尽量使用工具支持的语言全称，避免歧义。
-tl	--target_lang	目标语言。 -tl Chinese 或 -tl zh 。	同上。
-m	--model	指定使用的模型名称。 -m gpt-4o 或 -m qwen2.5:14b 。	必须与所选Provider支持的模型列表匹配。
--provider	-	指定LLM提供商。 --provider gemini	如果使用 .env 配置了默认值，可省略。
--api_endpoint	-	自定义API端点。主要用于本地OpenAI兼容服务器。	格式必须完整，如 http://主机:端口/v1/chat/completions 。
--text-cleanup	-	启用文本清理，修复OCR错误等。无需赋值，直接添加即可。	对干净的电子书可能无必要，甚至可能误删有效内容。
--refine	-	启用两阶段润色翻译。直接添加。	大幅提升质量，但时间/成本翻倍。
--tts	-	启用文本转语音（实验性）。直接添加。	会额外生成音频文件，目前仅支持Edge TTS引擎。

命令行实战心得：

• 结合任务调度器（如Linux的cron，Windows的任务计划程序），可以轻松实现夜间自动翻译下载好的文档。
• 在翻译大量小文件时，可以写一个简单的Shell脚本或Python脚本，遍历目录下的所有特定格式文件，循环调用 translate.py 。
• 使用 --refine 时，可以考虑第一阶段用速度快、成本低的模型（如 qwen2.5:7b ），第二阶段用更强但更慢的模型（如 qwen2.5:72b 或 gpt-4o ）进行润色，在质量和效率间取得平衡。

4. 各提供商接入深度指南与避坑

4.1 本地王者：Ollama 配置详解

Ollama是运行本地模型的绝佳工具，它简化了模型的下载、加载和服务化过程。

安装与模型拉取：

1. 从官网下载Ollama并安装。
2. 打开终端（命令行），使用 ollama pull <模型名> 拉取模型。对于翻译任务，推荐以下模型：
   • 平衡之选： qwen2.5:14b - 通义千问2.5的140亿参数版本，在多语言理解和生成上表现均衡，资源消耗适中。
   • 质量优先： qwen2.5:72b - 720亿参数版本，质量显著提升，但需要至少40GB以上显存或大量内存。
   • 轻量快速： llama3.2:3b 或 gemma2:2b - 参数量小，速度极快，在消费级显卡上也能流畅运行，适合对质量要求不高或快速预览的场景。

常见问题与排查：

• 问题： Web工具或CLI提示无法连接到Ollama。
  • 解决： 首先确保Ollama服务正在运行。在终端输入 ollama serve 查看是否有错误。然后另开一个终端，用 curl http://localhost:11434/api/tags 测试API是否可访问。如果返回模型列表JSON，则服务正常。
• 问题： 翻译时提示“Model not found”。
  • 解决： 运行 ollama list 确认模型已成功下载并存在于列表中。模型名必须完全匹配，注意大小写和版本标签（如 qwen2.5:14b 不是 qwen2.5:14b-instruct ）。

4.2 云端推荐：Poe 与 OpenRouter

Poe：简单易用的首选 Poe的优势在于一个API密钥可以访问多个顶级模型（如ChatGPT、Claude、Gemini等），且设置非常简单。

1. 访问 poe.com/api_key 登录后获取API Key。
2. 在Web界面或 .env 文件中，设置 LLM_PROVIDER=poe 并填入密钥。
3. 模型名称可以直接使用 chatgpt-4o-latest 、 claude-3-5-sonnet 等。Poe的模型列表是动态加载的，在Web界面上可以看到下拉选项。

OpenRouter：模型超市 OpenRouter聚合了众多模型，是寻找性价比最高或特定领域最强模型的好地方。

1. 访问 openrouter.ai/keys 获取API Key。
2. 设置 LLM_PROVIDER=openrouter 并填入密钥。
3. 模型名称格式为 提供商/模型名 ，例如 anthropic/claude-3-5-sonnet 、 google/gemini-2.0-flash 、 meta-llama/llama-3-3-70b-instruct 。你可以在OpenRouter的模型页面上查看完整列表和实时价格。

避坑技巧：

• 成本控制： 使用云端API前，务必了解模型的每百万token输入/输出价格。翻译长文档是一笔不小的开销。可以在OpenRouter上设置使用限额（Spending Limit）。
• 速率限制： 免费或低阶API密钥有调用频率限制。翻译长文档时，工具内置的请求队列和延迟重试机制能缓解一部分问题，但如果频繁遇到429错误，可能需要升级账户或降低并发请求数（在高级配置中调整）。
• 模型选择： 不要盲目追求最大参数模型。对于翻译任务， claude-3-haiku 、 gemini-2.0-flash 这类“快思维”模型在速度、成本和质量的综合表现上往往优于庞大的“慢思维”模型。项目Wiki页面的“Translation Quality Benchmarks”提供了不同语言对的模型质量基准，是极佳的参考。

4.3 OpenAI兼容本地服务器

这是为高阶玩家准备的方案，让你能利用llama.cpp、LM Studio、vLLM等工具部署高性能本地模型，并享受与OpenAI API相同的调用方式。

以LM Studio为例：

1. 下载LM Studio，下载你想要的GGUF格式模型文件。
2. 在LM Studio中加载模型，并启动本地服务器。通常服务器会运行在 http://localhost:1234 。
3. 确保服务器提供了 /v1/chat/completions 这个端点。
4. 在TranslateBooksWithLLMs中，使用以下配置：

   --provider openai
   --api_endpoint http://localhost:1234/v1/chat/completions
   -m your-model-name # 这里模型名可以任意填写，但需与LM Studio加载的模型对应，或留空
   

5. 关键点在于，工具会向 http://localhost:1234/v1/chat/completions 发送标准的OpenAI API格式请求，而LM Studio会处理这些请求。

踩坑记录：

• 确保本地服务器确实实现了OpenAI兼容的API。llama.cpp的server示例和LM Studio是没问题的，但一些其他工具的API格式可能有细微差别，需要调整。
• 本地服务器的上下文长度（context length）设置必须足够大，至少要大于你设置的 MAX_TOKENS_PER_CHUNK ，否则会报错。

5. 高级功能与疑难问题排查

5.1 两阶段润色翻译（Refine）实战

--refine 选项是提升文学类、营销类文档翻译质量的利器。其工作原理并非简单的“翻译两次”，而是一个“初翻-审校”的管道。

1. 第一阶段（Translation） ：模型A接收源文本块，生成目标语言的初稿。这个阶段侧重于“准确性”和“完整性”，即把原文意思正确、完整地转换过去。
2. 第二阶段（Refinement） ：工具将 源文本 和 初稿译文 一起发送给模型B（可以与A相同），并给出类似这样的指令：“你是一位专业的翻译审校。请对照源文，优化以下译文，使其更符合目标语言的母语表达习惯，行文更流畅、优美，但务必忠实于原意。” 模型B会输出优化后的最终译文。

配置示例（命令行）：

# 使用同一个模型进行两阶段工作
python translate.py -i novel.epub --provider ollama -m qwen2.5:14b --refine

# 使用不同模型：第一阶段快速初翻，第二阶段精细润色（需在Web界面或修改代码实现模型指定）
# 这是一个更高级的策略，通常需要你稍微修改工具的翻译流水线脚本。
# 思路是：在refine阶段，将请求发送到另一个provider/model端点。

使用心得：

• 对于技术文档、说明书， --refine 的提升可能不明显，甚至可能因为过度“文学化”而偏离技术术语的准确性。
• 对于小说、散文、宣传文案， --refine 效果显著，能有效消除机翻感，让译文更自然。
• 这会使得总翻译时间增加约70%-100%，API调用成本（如果使用付费模型）也近乎翻倍。

5.2 文本清理与音频生成

文本清理（--text-cleanup） ： 这个功能主要针对从扫描版PDF或老旧文档转换而来的文本，它们常包含：

• 错误的断行（一个句子在行末被硬切断）。
• 多余的空白字符（空格、制表符）。
• 常见的OCR错误（如将“1”识别为“l”，将“rn”识别为“m”）。 开启后，工具会在翻译前对文本进行预处理。 但请注意 ：对于本身排版干净、格式复杂的文档（如包含代码段的编程书籍），此功能可能会误伤，破坏原有的缩进或特殊格式。我的建议是：先在不开启此功能的情况下翻译一小段，如果发现译文中有明显的乱码或拼接错误，再启用它重试。

文本转语音（--tts，实验性） ： 这是一个边翻译边生成有声书的功能。它使用微软Edge浏览器的在线TTS服务，支持多种语言和音色。

python translate.py -i short_story.txt --tts --tts_voice zh-CN-XiaoxiaoNeural --tts_rate 1.2

• --tts_voice : 指定语音，如 zh-CN-XiaoxiaoNeural （晓晓，年轻女声）， en-US-GuyNeural （男声）。
• --tts_rate : 语速，1.0为正常，>1.0加快，<1.0减慢。 目前该功能是实验性的，生成的是独立的音频文件（如MP3），并未嵌入回EPUB或SRT中。适合用于制作独立的音频内容，或辅助校对（听译对照）。

5.3 常见问题排查速查表

在实际使用中，你可能会遇到以下问题。这里提供一个快速排查指南：

问题现象	可能原因	排查步骤与解决方案
启动Web服务后，浏览器无法访问 localhost:5000	端口被占用或防火墙阻止。	1. 检查是否有其他程序占用了5000端口（如 netstat -ano | findstr :5000 ）。 2. 尝试修改启动端口（源码启动方式可修改 app.py 中的 port 参数）。 3. 暂时关闭防火墙或添加出入站规则。
翻译过程中途失败，报网络错误或超时	1. API密钥失效或额度不足。 2. 网络不稳定。 3. 模型服务崩溃（本地Ollama）。 4. 单次请求内容过长超时。	1. 检查API密钥有效性及余额。 2. 检查网络连接。 3. 重启Ollama服务 ( ollama serve )。 4. 在 .env 中增加 REQUEST_TIMEOUT 值（如设为1200）。 5. 最关键：利用检查点功能！ 工具失败后，重新运行相同的命令，它会自动从最后一个成功保存的检查点继续，无需从头开始。
翻译后的文件格式混乱（如EPUB无法打开）	文件在解析或重建过程中出现结构性错误。	1. 确保源文件本身是完好的。可以用其他阅读器测试。 2. 尝试关闭 --text-cleanup 选项，它有时会干扰标签。 3. 对于特别复杂或非标准的EPUB，可以尝试先将其转换为TXT进行翻译，再手动处理格式（这是下策）。 4. 在项目GitHub Issues中搜索是否有类似案例。
翻译质量不佳，出现胡言乱语或严重偏离原意	1. 模型选择不当。 2. 分块过大导致上下文丢失。 3. 提示词（Prompt）对当前模型不优化。	1. 更换模型 ：尝试更强的模型（如从7B换到14B或70B），或换一个提供商（如从本地模型换到GPT-4o）。 2. 调整分块大小 ：在 .env 中降低 MAX_TOKENS_PER_CHUNK （如从400调到300），让每个块的上下文更聚焦。 3. 启用Refine ：两阶段润色能有效改善语言流畅度。 4. 检查源语言设置 ：确认 -sl 参数设置正确，特别是当文档中包含多语言时。
使用本地模型时速度极慢	1. 硬件资源不足（显存/内存）。 2. 模型参数过大。 3. 未使用GPU加速。	1. 运行 ollama ps 查看模型是否在GPU上运行。确保已安装正确的GPU驱动和Ollama版本。 2. 换用更小的模型（如从14B换到7B或3B）。 3. 对于llama.cpp，确保编译时启用了GPU支持（如CUDA）。

个人避坑经验：

• 翻译前先试读一小段 ：在正式翻译整本大部头前，先用第一章或随机抽取几段进行试翻译。这能帮你快速验证模型选择、参数设置是否合适，避免浪费大量时间后才发现问题。
• 善用 .processing 临时文件 ：工具在翻译时会生成一个同名的 .processing 文件，里面保存了检查点信息。如果翻译异常中断，不要删除这个文件，它是“断点续传”的关键。只有确认翻译完全成功后，再清理它们。
• 关注控制台/日志输出 ：无论是Web后台还是命令行，工具都会输出详细的日志，包括当前进度、遇到的警告等。遇到问题时，第一手日志信息是诊断的关键。
• 复杂文档分批处理 ：对于极其复杂、包含大量非文本元素（如图表、公式、特殊符号）的文档，如果整体翻译效果不好，可以尝试先将文档按章节拆分成多个小文件，分别翻译后再合并。虽然麻烦，但有时能解决一些棘手的格式问题。