断网也能用的翻译服务LibreTranslate 离线部署一揽子实操记录【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslateLibreTranslate 是一款免费开源的机器翻译 API 服务支持自托管部署在没有外网的内网环境中也能提供稳定翻译能力本文围绕 LibreTranslate 离线部署、内网使用与性能调优展开用一次真实的项目交付经历把无网络环境下翻译系统的落地全过程讲透适合第一次接触自托管翻译服务的新手参考。一次差点让项目黄掉的断网现场去年秋天我接了一个部队背景的客户需求一套内部知识库系统需要嵌入翻译功能但要命的是整个机房只有内网物理隔离连 DNS 都不通。客户的要求很直接——翻译必须在服务器本地完成数据不能出这台机器。一开始我下意识想到的是接云翻译 API结果被当场否决外网不通密钥没法激活更别说按量计费了。那天下午我抱着笔记本在客户机房的角落里坐了两个小时翻遍开源社区最后锁定了一个叫 LibreTranslate 的项目——免费、开源、自带 Web 界面而且宣传语里就写着Self-hosted, offline capable。后来的事情证明这两个单词offline capable救了我一整个项目。这篇文章不是官方文档的复述而是我把那次从零到上线的过程连同后来踩过的坑全部整理成了一份可复用的操作笔记。你不需要懂深度学习也不需要会编译 C跟着这篇记录走一台 8G 内存的普通服务器就能把翻译服务跑起来。断网翻译是怎么实现的先搞懂它的工作台很多人一听离线翻译脑子里浮现的是动辄几个 G 的本地大模型。LibreTranslate 的思路不太一样它更像一个流水线车间翻译引擎本体Argos Translate负责把文字从一种语言搬运到另一种语言它不依赖任何云端接口语言模型是单独存放的语言包文件每个语言对比如英→中、中→英对应一个独立文件就像车间里每个工位单独放的工具箱Web 服务层Flask负责把翻译能力包装成 HTTP 接口给网页或程序调用在项目的 pyproject.toml 里可以看到它的关键拼图argos-translate-lt是翻译核心Flask是 Web 框架langdetect负责语言识别expiringdict给翻译结果做缓存。这些组件全是开源库装好后各自在本地运行没有任何一个环节需要打电话问外面的服务器。一句话总结离线翻译 翻译程序 语言包 网络外壳三者齐备断网照常干活。语言包放在用户目录的argos-translate文件夹下Linux 是~/.local/share/argos-translate/packages/en_zh.argosmodel 就是英译中的模型文件。想支持几种语言就准备几个这样的文件不用全装这也是后面控制磁盘占用空间的关键。开工之前先把这三件事盘清楚真正动手之前别急着敲命令。以我的经验离线部署 80% 的返工都出在准备阶段没想明白。请先回答自己三个问题① 到底需要哪些语言对客户说支持中文但中→英和英→中是两个不同的模型文件。先列一张语言需求表再决定下载哪些。只做英中互译两个文件加起来大概 600MB要覆盖英、法、西、德、意五个方向量级会到 1GB 以上。② 服务器什么配置语言模型是加载进内存运行的。我用过的经验值大致如下服务规模语言覆盖模型文件占用建议内存适用场景入门级中英互译约 300-600MB4GB个人、内部小工具常规级5-8 种主流语言1-1.5GB8GB团队协作、知识库高配级数十种语言3GB 以上16GB多语言平台、研究机构③ 是全新部署还是已有机器如果目标服务器上已经装了 Python 环境先确认版本。LibreTranslate 要求 Python 3.8 以上版本不一致是最常见的安装即报错源头建议在有网环境提前用同样版本做一次演练。在有网的地方把干粮备齐依赖缓存与模型打包离线部署的本质是把下载这件事提前做完。我把这个过程叫备干粮——所有需要外网的资源都在有网的开发机上先拉下来再一起带进内网。第一步克隆代码并准备依赖缓存git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate pip download -r requirements.txt -d offline_deps/ --no-cache-dirpip download会把所有依赖的安装包下载到offline_deps目录这样到了内网就不需要再访问 PyPI。如果目标机是纯内网 x86 Linux还可以加上--platform manylinux2014_x86_64 --only-binary:all:之类的参数锁定平台减少兼容性问题——不过前提是你已经确定了目标机的系统架构别在 ARM 机器上准备 x86 的包。第二步只下载需要的语言模型python scripts/install_models.py --load_only_lang_codes en,zh这条命令会去下载并安装英中互译所需的模型文件。执行完之后把用户目录下argos-translate整个文件夹复制出来和offline_deps放在一起就凑齐了程序 依赖 模型三件套。把这三样打成一个压缩包用 U 盘也好、内网共享盘也好拷进目标环境。检查点拷贝前确认模型目录里能看到.argosmodel结尾的文件并且记录下它们的完整路径内网部署时要放回同样的位置。在内网安家安装、放模型、启动服务到了目标机器上把压缩包解压到约定目录然后按顺序做三件事1. 离线安装依赖pip install --no-index --find-links./offline_deps/ -r requirements.txt--no-index告诉 pip 别去网上找只用本地目录里的包。2. 把模型文件放回正确位置把之前打包的argos-translate文件夹原样放回用户的~/.local/share/目录下Windows 则是C:\Users\用户名\AppData\Roaming\。这一步最容易出错路径差一个字母服务就找不到模型。放好后可以检查一下ls ~/.local/share/argos-translate/packages/应该能看到模型文件。3. 启动服务python main.py --host 0.0.0.0 --port 5000 --load-only en,zh--load-only参数告诉服务只加载哪些语言既省内存又加快启动速度。看到日志里出现类似 Loaded support for X languages 的字样就说明模型加载成功了。如果启动时日志里出现Cannot update models (normal if youre offline)之类的提示不用担心——这是服务尝试联网检查更新没成功属于内网环境的正常现象翻译功能不受影响。想彻底安静的话项目配置里UPDATE_MODELS默认就是关闭的对应的启动参数--update-models不传即可。点火之后怎么确认它真的在干活服务跑起来不等于万事大吉我习惯按网页 → 接口 → 数据三层做验收网页层浏览器打开http://服务器IP:5000能看到一个翻译输入框选好语言对随便打一句话点翻译页面出现译文说明前端、后端、模型全链路通了接口层用命令行模拟程序调用验证 API 是否正常响应curl -X POST http://localhost:5000/translate \ -H Content-Type: application/x-www-form-urlencoded \ -d qHello worldsourceentargetzh数据层翻译结果正常返回后把网线拔了再测一次——没错真正的内网验证就该这么干。确认拔网线后翻译依然秒回离线能力才算真正成立如果这台服务器后续要接入其他系统翻译 API 的请求格式字段名q、source、target值得提前写进对接文档让开发同事照着调。三份真实翻车记录这些坑我替你踩过了翻车记录一模型文件放错位置服务报找不到语言包症状启动后日志提示找不到模型网页打开没有可用的语言选项。 原因我把模型解压到了自定义目录但服务只认默认路径。 解法把模型放回~/.local/share/argos-translate/packages/或者用环境变量显式指定模型目录指向你的自定义位置二选一别两个都做。翻车记录二内网装依赖报版本冲突症状pip install时提示某个库找不到匹配版本。 原因有网环境用的 Python 版本和内网机器不一致pip 解析出的依赖树对不上。 解法两台机器用同一个 Python 版本写进项目交接文档里有网时在同样的版本下重新pip download一遍依赖。翻车记录三翻译请求多了服务明显变慢症状并发一上来响应时间从几百毫秒飙升到几十秒。 原因默认线程数是 4机器内存又不宽裕模型反复加载。 解法按机器配置调大线程数启动参数--threads同时用--load-only收紧语言范围翻译缓存TRANSLATION_CACHE也可以按需开启重复内容直接命中缓存不重新计算。让内网服务跑得更省更稳的几个旋钮服务上线只是开始运营阶段有几个旋钮值得你花十分钟调一调只加载需要的语言--load-only en,zh这种写法让内存占用和启动速度都友好不少按需调线程8 核 16G 的机器--threads 8起步小内存机器别硬堆内存不足比 CPU 慢更致命给程序接口加把锁内网不等于绝对安全项目支持 API 密钥机制--api-keys及相关参数给不同部门发不同密钥谁在用、用了多少一目了然数据不出门的安全承诺翻译内容全程在本地处理缓存也默认存在内存里敏感文本不会留下磁盘痕迹如果需要落盘缓存留意定期清理策略日志留痕服务日志记录访问来源和请求时间配合密钥使用出了问题能倒查长期维护离线系统也得定期体检离线部署做完最容易被忽略的是后续更新。我的做法是每季度安排一次有网体检在有网环境更新代码和依赖重新pip download用python scripts/install_models.py --update拉取模型更新把更新的依赖目录和模型目录重新打包走一遍最初的拷贝流程这样虽然麻烦但保证了翻译质量和安全补丁不会永久停更。另一个建议是给模型目录和数据库文件项目用 SQLite 存储 API 密钥等数据默认在db/目录下做定时备份服务器故障时能快速还原。从一台机器到一套服务接下来你可以这样做如果你看完这篇记录决定在自己的环境里也搭一套离线翻译我的建议是别贪多先只装中英互译两个模型把流程完整跑通确认网页能用、接口能调、拔网线还能翻再根据实际需求扩充语言对。整个上手过程一个下午足够。离线部署翻译服务真正难的不是技术而是想清楚要什么、备齐所有干粮、按顺序执行这三件事。LibreTranslate 把最复杂的模型部分封装成了简单的命令行参数剩下的就是用你的项目需求去驾驭它。现在去找一台能联网的机器克隆代码把模型和依赖打包好——你的第一套离线翻译服务已经在路上了。【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
