企业官网建设流程全解析

LibreTranslate离线部署实战：把翻译服务装进没有网的机房

【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate

LibreTranslate 是一个免费开源的机器翻译 API，主打自托管与离线能力，翻译请求可以在完全无网的环境里本地完成。这篇文章记录一次把 LibreTranslate 离线部署进封闭内网的完整过程——没有网线、没有外网依赖，只有一台服务器、一个U盘，和一份 40 页的德文设备手册。

第一幕 · 处境：周四下午，一台没有网的服务器

那天下午三点，小A站在某制造企业的机房里，空调嗡嗡响，空气中有一股机房特有的热塑料味。他面前是一台刚从库房翻出来的旧服务器，客户的要求只有一句话：把这份德文设备手册翻成中文，最好以后每天都能翻，但所有数据不能出这栋楼。

楼里没有外网。办公网是物理隔离的，手机信号进了这栋楼就断断续续，IT 主管很客气地提醒他：这里连 U 盘的拷贝记录都要登记。

小A先试了最直接的办法——用手机热点连在线翻译网页。结果那条 40 页的德文 PDF 刚传上去，网页转了十几秒，弹出一个"网络连接失败"。他又试了公司 OA 里自带的翻译插件，得到的提示是"服务不可用，请检查外网连接"。

那一刻他意识到：不是翻译工具不好用，而是"要联网"这件事本身，在这里就是死路一条。

他蹲在机房门口，翻出一个旧笔记本，写下自己真正需要的三件事：翻译质量要接近主流水平、整个过程不碰外网、以后内网里任何电脑都能调用它。接下来一个小时，他把所有可能的方案在脑子里过了一遍，越列越纠结。

第二幕 · 抉择：四张候选名单，没有一张是完美的

小A先把方案摊开，给自己列了一张对比清单：

第一个被淘汰的是在线方案。理由很朴素：一个需要外网的翻译工具，在物理隔离的环境里等于不存在。这个结论花了他不到五分钟。

第二个被淘汰的是桌面词典。小A自己试过，词对词翻译勉强能用，但德语那种长从句一进来，输出就变成一串让人看不懂的词语堆叠。他要处理的是技术手册，不是单词表。整句翻译质量这一关过不去，方案再多也白搭。

商用离线 SDK 让他犹豫了十分钟。质量确实好，但有两个问题：第一，授权费按年算，客户预算里没这一项；第二，很多 SDK 的首次激活要联网验签，在"所有数据不能出这栋楼"的前提下，这一步就过不去。

最后他锁定了 LibreTranslate。理由其实就三条：它是开源的机器翻译 API，翻译引擎由 Argos Translate 驱动，模型文件下载一次之后可以完全本地运行；项目自带网页界面和 REST 接口，内网里的同事打开浏览器就能用；免费这一点放在最后说，是因为它只是加分项，不是选它的理由。

这里有个关键判断值得说清楚：自托管不等于零成本。你要自己装环境、自己管模型、自己处理报错。对愿意动手的人来说，这通常不是负担，而是可控性的来源。小A的想法是：与其每次被"没网"卡住，不如花一个下午，把翻译能力真正装进这台机器里。

第三幕 · 落地：从U盘到一条可用的翻译接口

小A给自己定的路线很简单：先在能联网的笔记本上把"依赖"和"模型"两样东西备齐，再用 U 盘搬进内网。听起来像搬家打包，实际操作也确实如此。

第一步：在有网的机器上备齐依赖

他先建了一个干净的目录，把项目源码拉下来：

git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate

然后创建虚拟环境，用一条命令把项目连同全部依赖的安装包下载到本地目录：

pip download -d offline_deps .

这句命令的意思是：在当前目录下载项目及其所有依赖的安装包，统一放进 offline_deps 这个文件夹。项目用 pyproject.toml 声明依赖，核心翻译引擎是 argos-translate-lt，Web 框架是 Flask，语言检测用的是 langdetect，缓存机制是 expiringdict。这些名字记不住没关系，只要知道它们会被一起打进 offline_deps 就行。

小A顺手看了一眼文件夹大小：几百 MB，一个 U 盘装得下。

第二步：只下载中英两个方向的翻译模型

这一步是整篇文章里最容易踩坑的地方，小A在这里摔了今天的第一跤。

LibreTranslate 的翻译能力来自一个个独立的模型文件，每个语言对一个文件，默认存放在~/.local/share/argos-translate/packages/目录下。全量下载所有语言模型要占用好几个 GB，而小A只需要德文到中文、英文到中文这几个方向，于是他用了项目自带的脚本：

python scripts/install_models.py --load_only_lang_codes "en,zh"

白话解释：只安装英文和中文之间的翻译模型，其他语言一个都不碰。这一步把模型占用从几个 GB 压到了几百 MB，启动时也不用把几十种语言全部加载进内存。

然后报错来了。日志里出现一行红字：

Unavailable language codes: cn.

小A愣了一下，他明明写的是"cn"。查了项目里的语言代码表才发现，中文在 LibreTranslate 里的代码是zh，不是cn。这个校验逻辑写得很严格，代码不存在就直接拒绝，不会静默跳过。改回zh重新执行，模型开始正常下载。

这个坑给所有准备离线部署的人提了个醒：语言代码不能靠猜，动手前先查一遍项目支持的语言代码列表。

第三步：把模型和依赖搬进内网

模型下载完成后，~/.local/share/argos-translate/packages/目录里多出了几个.argosmodel文件，每个文件对应一个语言方向。小A把整个 packages 目录和 offline_deps 文件夹一起拷进 U 盘，走进了那间机房的登记台。

内网服务器上没有 Python 环境，他用系统自带的 Python 装了虚拟环境，然后执行离线安装：

pip install --no-index --find-links=offline_deps .

这句命令的意思是：不访问外网，只从本地 offline_deps 目录里找安装包。几分钟后依赖安装完成，没有任何报错。到这里，他以为自己可以启动了。

第四步：第一次启动，第二个报错

小A直接敲了启动命令：

python main.py --host 0.0.0.0 --port 5000 --load-only en,zh

参数说明：--host 0.0.0.0让服务监听所有网卡，内网其他电脑才能访问；--load-only en,zh只加载中英模型，省内存也省启动时间。

启动日志里出现一行提示：

Cannot update models (normal if you're offline): ...

这行字不是致命错误。项目里写得很直白——"如果你离线，这是正常现象"。意思是服务启动时默认尝试联网更新模型索引，连不上就跳过。真正的问题在后面：他打开浏览器访问http://内网IP:5000，页面能打开，但翻译一提交就报错，语言列表也是空的。

小A排查了二十分钟，最后发现模型文件根本没被读到。原因很简单：他把 .argosmodel 文件拷到了用户主目录下的临时文件夹，而不是 argos-translate 默认读取的~/.local/share/argos-translate/packages/路径。把文件挪到正确位置，重启服务，日志里出现了这行：

Loaded support for 2 languages (2 models total)!

翻译立刻正常了。这个报错前后花了他半小时，但后来他反而觉得值——因为他彻底搞清楚了"模型该放哪里"这个离线部署的核心问题。

第五步：验证与收尾

小A用一条命令做了最终的接口验证：

curl -X POST http://127.0.0.1:5000/translate -d "q=Hello world&source=en&target=zh"

返回结果是中文译文，请求耗时在几百毫秒以内，全程没有碰过外网。同事在隔壁工位打开浏览器访问内网 IP，也能看到翻译网页界面，输入即译。

最后他做了一组配置核对，这里直接给出他最终留下的清单：

验证清单他也抄了一份给客户：启动后日志出现 Loaded support for N languages；浏览器能打开 5000 端口页面；翻译接口返回正常结果；关掉外网交换机，服务照常运行。四条全过。

尾声 · 复盘：那台服务器后来的故事

一个月后，小A再进那间机房，服务器已经在角落安静跑了四个星期，日志里没有一条翻译失败记录。他把这次经历总结成三句话：

第一，离线部署 90% 的工作发生在有网的那台机器上。依赖打包、模型下载、语言代码核对，全部提前做掉，内网里的操作只剩拷贝和启动。

第二，报错不可怕，可怕的是看不懂报错。那次Unavailable language codes和Cannot update models，一个教他查语言代码，一个教他认清模型路径，都是白纸黑字写在日志里的提示。

第三，默认配置是为"在线"设计的，离线要主动改。默认只监听本机、默认尝试联网更新模型，这些都要靠--host 0.0.0.0和LT_UPDATE_MODELS=False手动纠正。

往后还有几条可以深挖的路：如果团队变大，可以打开--api-keys给不同部门分配独立密钥；如果以后要加别的语言，在有网的机器上重新跑一次install_models.py，把新模型拷进来就行；如果想把整套环境固化成镜像，项目仓库里的 Dockerfile 可以直接作为起点。

客户后来问小A：这套东西还能撑多久？小A想了想说，只要模型文件还在，它就能一直跑下去。翻译模型就像一本本随用随取的字典，放对位置，就不需要再问网络要答案。

那天下午他走出机房的时候，手机终于有了信号。他看着屏幕上跳出来的未读消息，忽然觉得，真正让他安心的不是手机那格信号，而是身后那台机器里，刚刚装好的翻译能力，已经不再需要它了。

【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate