LibreTranslate 离线部署实操从零搭建一台永不联网的翻译服务器【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate2024 年的一项数据显示企业内部有超过 60% 的翻译需求集中在合同、技术文档与客服话术上而其中相当一部分明文内容根本不适合送往云端 API。如果你正在评估 LibreTranslate 离线部署方案想把翻译能力完整收进自己的机房这篇文章就是为你写的。作为一款完全自托管的开源机器翻译 APILibreTranslate 内置的 Argos Translate 引擎不依赖任何商业云服务具备天然的离线基因。下面我从最终成果倒推带你一步步还原这台离线翻译服务器的完整搭建链路。一、先看终点一台断网可用的翻译服务器长什么样在动手之前先明确我们要交付的成果。假设你面前有一台完全没有任何外网连接的 Linux 服务器完成本文全部步骤后它应该具备以下能力能力项具体表现翻译接口支持中英互译等预装语言对的 HTTP API 调用语言检测自动识别输入文本属于哪种语言批量翻译一次请求可提交多条文本界面服务自带一个简单的 Web 翻译页面运行环境全程无任何外部网络请求依赖全部来自本地验收标准很简单拔掉网线服务照样能启动、能翻译、能返回 JSON。这正是离线部署与内网部署的本质区别——内网部署可能还依赖局域网内的包源而离线部署要求连包安装阶段都完全脱离网络。在达成这个终点的过程中你需要依次攻克三关翻译能力从哪来、依赖怎么带进去、服务如何配置成纯离线模式。下面逐层倒推。二、第一层倒推翻译能力藏在哪——语言模型即大脑服务器本身不会翻译翻译能力来自预训练的神经机器翻译模型文件。LibreTranslate 的底层引擎 Argos Translate 会把每个语言对打包成一个独立的.argosmodel文件例如en_zh.argosmodel负责英文到中文zh_en.argosmodel负责中文到英文。这些模型默认存放在用户数据目录下Linux / macOS~/.local/share/argos-translate/packages/WindowsC:\Users\你的用户名\AppData\Roaming\argos-translate\packages\模型是按语言对隔离的这意味着你完全不需要下载全部模型。一个中英互译的模型包大约在 200MB 量级而全量模型可能占用 3–4GB。对于大多数场景只装你真正需要的语言对是把离线包体积从灾难级降到可控级的关键一步。获取模型有两种途径在线下载或者在有网机器上提前下载后拷贝。推荐后者因为目标服务器全程断网。模型文件本身就是普通文件拷进指定目录即可被识别。三、第二层倒推依赖怎么离线安装——用 pip 做一次搬砖LibreTranslate 是 Python 项目其核心依赖在pyproject.toml中声明。以当前版本为例关键组件包括argos-translate-lt 1.12.1 # 核心翻译引擎 Flask 2.2.5 # Web 服务框架 langdetect1.0.9 # 语言检测 expiringdict 1.2.2 # 缓存机制离线安装的标准做法是在有网络的机器上把依赖全部下载成 wheel 文件再整体搬运到离线环境。这一过程叫依赖离线缓存执行一次即可# 克隆项目源码在有网络的环境执行 git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate # 创建依赖缓存目录 mkdir -p offline_deps # 将全部依赖下载为本地文件 pip download -r requirements.txt -d offline_deps/ \ --no-cache-dir \ --only-binary:all:这里有两个细节值得注意--only-binary:all:只下载编译好的二进制包避免在离线环境现场编译源码包而缺少编译器Python 版本必须一致。wheel 包通常绑定特定 Python 大版本如 cp311 表示 CPython 3.11离线环境请使用与下载环境相同的 Python 版本否则会出现找不到可用包的报错。搬运完成后在离线服务器上执行pip install --no-index --find-links./offline_deps/ -r requirements.txt--no-index明确禁止访问 PyPI--find-links告诉 pip 只从本地目录查找。至此依赖层面的断网已达成。四、第三层倒推服务如何配置成纯离线——读懂 LT_ 环境变量依赖装好了、模型放进去了但还有一个隐患LibreTranslate 默认在启动时检查并尝试更新模型。如果目标机器断网启动过程可能卡在超时等待上。答案藏在libretranslate/default_values.py中。项目用LT_前缀的环境变量统一管理所有运行参数其中三个与离线模式直接相关# 关闭启动时的模型自动更新最关键的一步 export LT_UPDATE_MODELSfalse # 只加载指定的语言不扫描全部模型目录 export LT_LOAD_ONLYen,zh # 明确使用内存存储避免连接外部 Redis export LT_SHARED_STORAGEmemory://逐条解释一下LT_UPDATE_MODELSfalse告诉服务不要联网更新模型。对应的命令行参数是--update-models默认就是关闭的但显式声明更稳妥LT_LOAD_ONLYen,zh只加载英文和中文模型。这个参数有双重收益——既减少内存占用也避免启动时去枚举那些你可能并不需要的语言对LT_SHARED_STORAGEmemory://libretranslate/storage.py中实现了两种存储后端memory://用进程内字典redis://需要外部 Redis 服务。单机离线场景选memory://零依赖即可。完成配置后启动服务python main.py --host 0.0.0.0 --port 5000看到日志输出类似Loaded support for 2 languages (2 models total)!时说明模型加载成功。此时整台翻译服务器已经不再触碰任何外部网络。五、成果回验离线能力的三层体检清单搭建完成不等于万事大吉用下面这份清单逐项验证缺一项都算不上真正离线。体检一启动阶段无网络请求启动时观察日志不应出现Updating language models或任何连接超时的报错。如果出现检查LT_UPDATE_MODELS是否为 false。体检二核心接口可用# 翻译接口 curl -X POST http://localhost:5000/translate \ -H Content-Type: application/x-www-form-urlencoded \ -d qHello%20worldsourceentargetzh # 语言检测接口 curl -X POST http://localhost:5000/detect \ -H Content-Type: application/x-www-form-urlencoded \ -d qBonjour%20le%20monde体检三彻底断网复测直接拔掉网线或关闭对外网络重启服务再执行上面的 curl 命令。如果一切正常恭喜——你的离线翻译堡垒已经建成。顺带一提首次翻译通常需要几百毫秒到数秒取决于 CPU 和模型大小后续翻译因为结果缓存在内存中会明显加快。libretranslate/cache.py中实现了基于 expiringdict 的翻译缓存这也是它越用越快的原因。六、翻车现场四个高频故障与对症下药离线部署最怕的就是装完起不来下面四个问题是我在实践中最常遇到的故障 1启动报No installed packages found模型没被识别。检查模型文件是否放在正确的目录以及LT_LOAD_ONLY指定的语言代码是否与模型实际语言对一致。注意中文的特殊性LibreTranslate 内部用zh-Hans简体、zh-Hant繁体作为模型代码而对外接口接受zh别名两者映射关系在libretranslate/language.py中定义。故障 2pip 安装时报No matching distribution found大概率是 Python 版本不一致。用python --version核对离线环境与下载环境的 Python 大版本务必一致。故障 3服务启动极慢或卡死模型加载是内存密集型操作。LT_LOAD_ONLY尽量精简语言列表如果内存确实紧张可考虑减小LT_THREADS默认 4降低并发线程的内存开销。故障 4翻译结果标点或大小写异常这不是部署问题而是模型行为。libretranslate/language.py中的improve_translation_formatting函数会自动修正首字母大小写和尾部标点属于正常后处理无需干预。七、向团队交付从单机到多人使用的两个加分项单人使用已经达标但如果你要把它开放给团队还有两件值得做的事。加分项一加一层访问控制离线不等于免登录。在main.py启动参数中启用 API 密钥机制避免内网任意机器直接调用python main.py --api-keys --req-limit 100 --char-limit 500--req-limit限制每客户端每分钟请求数--char-limit限制单次翻译字符数这两个参数可以有效防止某个调用方把服务资源打满。加分项二用 Docker 固化环境如果你希望团队环境一次构建、处处一致可以基于项目自带的docker-compose.yml定制离线镜像把模型目录和依赖缓存目录通过 volume 挂载进容器镜像内不再执行任何网络安装操作。这样做的好处是新同事拿到镜像就能跑不需要重复经历依赖搬运的过程。八、写在最后离线不是终点而是起点回顾整条链路你会发现 LibreTranslate 离线部署的每一步都遵循同一个原则把依赖外部变成自带干粮——模型文件自带、Python 依赖自带、存储后端内置。这套思路不仅适用于翻译服务也是任何自托管软件离线化的通用方法论。如果你的场景只是个人偶尔翻译几段文字最小化配置中英互译 200MB 模型就足够了如果面向团队加上 API 密钥和限流参数即可上线未来模型更新时也只需在有网机器上重新下载模型包拷入离线环境覆盖即可服务无需停机重构。最后留一道思考题给你当你真的把这台服务器部署到断网环境中你会优先保障哪几个语言对答案或许能帮你进一步压缩模型体积——而这也正是离线部署最迷人的地方一切由你掌控一分不多一分不少。【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
LibreTranslate 离线部署实操从零搭建一台永不联网的翻译服务器【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate2024 年的一项数据显示企业内部有超过 60% 的翻译需求集中在合同、技术文档与客服话术上而其中相当一部分明文内容根本不适合送往云端 API。如果你正在评估 LibreTranslate 离线部署方案想把翻译能力完整收进自己的机房这篇文章就是为你写的。作为一款完全自托管的开源机器翻译 APILibreTranslate 内置的 Argos Translate 引擎不依赖任何商业云服务具备天然的离线基因。下面我从最终成果倒推带你一步步还原这台离线翻译服务器的完整搭建链路。一、先看终点一台断网可用的翻译服务器长什么样在动手之前先明确我们要交付的成果。假设你面前有一台完全没有任何外网连接的 Linux 服务器完成本文全部步骤后它应该具备以下能力能力项具体表现翻译接口支持中英互译等预装语言对的 HTTP API 调用语言检测自动识别输入文本属于哪种语言批量翻译一次请求可提交多条文本界面服务自带一个简单的 Web 翻译页面运行环境全程无任何外部网络请求依赖全部来自本地验收标准很简单拔掉网线服务照样能启动、能翻译、能返回 JSON。这正是离线部署与内网部署的本质区别——内网部署可能还依赖局域网内的包源而离线部署要求连包安装阶段都完全脱离网络。在达成这个终点的过程中你需要依次攻克三关翻译能力从哪来、依赖怎么带进去、服务如何配置成纯离线模式。下面逐层倒推。二、第一层倒推翻译能力藏在哪——语言模型即大脑服务器本身不会翻译翻译能力来自预训练的神经机器翻译模型文件。LibreTranslate 的底层引擎 Argos Translate 会把每个语言对打包成一个独立的.argosmodel文件例如en_zh.argosmodel负责英文到中文zh_en.argosmodel负责中文到英文。这些模型默认存放在用户数据目录下Linux / macOS~/.local/share/argos-translate/packages/WindowsC:\Users\你的用户名\AppData\Roaming\argos-translate\packages\模型是按语言对隔离的这意味着你完全不需要下载全部模型。一个中英互译的模型包大约在 200MB 量级而全量模型可能占用 3–4GB。对于大多数场景只装你真正需要的语言对是把离线包体积从灾难级降到可控级的关键一步。获取模型有两种途径在线下载或者在有网机器上提前下载后拷贝。推荐后者因为目标服务器全程断网。模型文件本身就是普通文件拷进指定目录即可被识别。三、第二层倒推依赖怎么离线安装——用 pip 做一次搬砖LibreTranslate 是 Python 项目其核心依赖在pyproject.toml中声明。以当前版本为例关键组件包括argos-translate-lt 1.12.1 # 核心翻译引擎 Flask 2.2.5 # Web 服务框架 langdetect1.0.9 # 语言检测 expiringdict 1.2.2 # 缓存机制离线安装的标准做法是在有网络的机器上把依赖全部下载成 wheel 文件再整体搬运到离线环境。这一过程叫依赖离线缓存执行一次即可# 克隆项目源码在有网络的环境执行 git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate # 创建依赖缓存目录 mkdir -p offline_deps # 将全部依赖下载为本地文件 pip download -r requirements.txt -d offline_deps/ \ --no-cache-dir \ --only-binary:all:这里有两个细节值得注意--only-binary:all:只下载编译好的二进制包避免在离线环境现场编译源码包而缺少编译器Python 版本必须一致。wheel 包通常绑定特定 Python 大版本如 cp311 表示 CPython 3.11离线环境请使用与下载环境相同的 Python 版本否则会出现找不到可用包的报错。搬运完成后在离线服务器上执行pip install --no-index --find-links./offline_deps/ -r requirements.txt--no-index明确禁止访问 PyPI--find-links告诉 pip 只从本地目录查找。至此依赖层面的断网已达成。四、第三层倒推服务如何配置成纯离线——读懂 LT_ 环境变量依赖装好了、模型放进去了但还有一个隐患LibreTranslate 默认在启动时检查并尝试更新模型。如果目标机器断网启动过程可能卡在超时等待上。答案藏在libretranslate/default_values.py中。项目用LT_前缀的环境变量统一管理所有运行参数其中三个与离线模式直接相关# 关闭启动时的模型自动更新最关键的一步 export LT_UPDATE_MODELSfalse # 只加载指定的语言不扫描全部模型目录 export LT_LOAD_ONLYen,zh # 明确使用内存存储避免连接外部 Redis export LT_SHARED_STORAGEmemory://逐条解释一下LT_UPDATE_MODELSfalse告诉服务不要联网更新模型。对应的命令行参数是--update-models默认就是关闭的但显式声明更稳妥LT_LOAD_ONLYen,zh只加载英文和中文模型。这个参数有双重收益——既减少内存占用也避免启动时去枚举那些你可能并不需要的语言对LT_SHARED_STORAGEmemory://libretranslate/storage.py中实现了两种存储后端memory://用进程内字典redis://需要外部 Redis 服务。单机离线场景选memory://零依赖即可。完成配置后启动服务python main.py --host 0.0.0.0 --port 5000看到日志输出类似Loaded support for 2 languages (2 models total)!时说明模型加载成功。此时整台翻译服务器已经不再触碰任何外部网络。五、成果回验离线能力的三层体检清单搭建完成不等于万事大吉用下面这份清单逐项验证缺一项都算不上真正离线。体检一启动阶段无网络请求启动时观察日志不应出现Updating language models或任何连接超时的报错。如果出现检查LT_UPDATE_MODELS是否为 false。体检二核心接口可用# 翻译接口 curl -X POST http://localhost:5000/translate \ -H Content-Type: application/x-www-form-urlencoded \ -d qHello%20worldsourceentargetzh # 语言检测接口 curl -X POST http://localhost:5000/detect \ -H Content-Type: application/x-www-form-urlencoded \ -d qBonjour%20le%20monde体检三彻底断网复测直接拔掉网线或关闭对外网络重启服务再执行上面的 curl 命令。如果一切正常恭喜——你的离线翻译堡垒已经建成。顺带一提首次翻译通常需要几百毫秒到数秒取决于 CPU 和模型大小后续翻译因为结果缓存在内存中会明显加快。libretranslate/cache.py中实现了基于 expiringdict 的翻译缓存这也是它越用越快的原因。六、翻车现场四个高频故障与对症下药离线部署最怕的就是装完起不来下面四个问题是我在实践中最常遇到的故障 1启动报No installed packages found模型没被识别。检查模型文件是否放在正确的目录以及LT_LOAD_ONLY指定的语言代码是否与模型实际语言对一致。注意中文的特殊性LibreTranslate 内部用zh-Hans简体、zh-Hant繁体作为模型代码而对外接口接受zh别名两者映射关系在libretranslate/language.py中定义。故障 2pip 安装时报No matching distribution found大概率是 Python 版本不一致。用python --version核对离线环境与下载环境的 Python 大版本务必一致。故障 3服务启动极慢或卡死模型加载是内存密集型操作。LT_LOAD_ONLY尽量精简语言列表如果内存确实紧张可考虑减小LT_THREADS默认 4降低并发线程的内存开销。故障 4翻译结果标点或大小写异常这不是部署问题而是模型行为。libretranslate/language.py中的improve_translation_formatting函数会自动修正首字母大小写和尾部标点属于正常后处理无需干预。七、向团队交付从单机到多人使用的两个加分项单人使用已经达标但如果你要把它开放给团队还有两件值得做的事。加分项一加一层访问控制离线不等于免登录。在main.py启动参数中启用 API 密钥机制避免内网任意机器直接调用python main.py --api-keys --req-limit 100 --char-limit 500--req-limit限制每客户端每分钟请求数--char-limit限制单次翻译字符数这两个参数可以有效防止某个调用方把服务资源打满。加分项二用 Docker 固化环境如果你希望团队环境一次构建、处处一致可以基于项目自带的docker-compose.yml定制离线镜像把模型目录和依赖缓存目录通过 volume 挂载进容器镜像内不再执行任何网络安装操作。这样做的好处是新同事拿到镜像就能跑不需要重复经历依赖搬运的过程。八、写在最后离线不是终点而是起点回顾整条链路你会发现 LibreTranslate 离线部署的每一步都遵循同一个原则把依赖外部变成自带干粮——模型文件自带、Python 依赖自带、存储后端内置。这套思路不仅适用于翻译服务也是任何自托管软件离线化的通用方法论。如果你的场景只是个人偶尔翻译几段文字最小化配置中英互译 200MB 模型就足够了如果面向团队加上 API 密钥和限流参数即可上线未来模型更新时也只需在有网机器上重新下载模型包拷入离线环境覆盖即可服务无需停机重构。最后留一道思考题给你当你真的把这台服务器部署到断网环境中你会优先保障哪几个语言对答案或许能帮你进一步压缩模型体积——而这也正是离线部署最迷人的地方一切由你掌控一分不多一分不少。【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
