断网也能用的翻译服务LibreTranslate 离线部署完整实战从 0 到内网可用的 3 个关卡【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate如果有一天领导把一台不能连外网的服务器交给你说在这上面装一个翻译系统你可能会先愣住翻译不是都要联网调 API 吗别急着慌这就是本文要带你解决的问题。LibreTranslate 是一款免费开源的机器翻译 API它的最大特点就是完全自托管、断网可跑、部署简单翻译数据全部留在你自己的机器上。今天我不按官方文档念经而是用闯关的方式带你从零把一套LibreTranslate 离线部署方案真正跑起来最后一关还要顺带解决内网依赖安装、性能调优和访问控制。先搞清楚一件事它凭什么能离线很多人以为机器翻译把文字发到云端等结果回来。但 LibreTranslate 不是这个思路它更像一台印刷好的离线词典机。你可以把它想象成这样Argos TranslateLibreTranslate 底层的开源翻译引擎不是现场查网络词典而是提前把词典整本印好、搬回你家。每一本词典就是一个语言模型文件比如英语→中文一本、中文→英语一本。翻译的时候机器只是在自己的仓库里翻书全程不碰外网。这个设计带来的连锁好处是数据主权你的文本不出本机适合涉密或合规场景零延迟波动没有网络往返响应速度只取决于本机性能成本可控没有按字符计费的 API 账单一次部署长期使用。在项目源码里翻译引擎、Web 框架、语言检测各管一摊核心翻译由argos-translate-lt负责Web 服务是 Flask语言检测用langdetect还带了一个内存缓存expiringdict。这些依赖在pyproject.toml里都能找到。说白了每个零件都能在本地独立运转这正是离线部署能成立的前提。第一关先让翻译服务在有网的机器上活起来目标很单纯先把最小可用版本跑通。别一上来就惦记断网先在有网络的环境把整套流程走一遍把标准答案拿到手后面断网才有底气。为什么先做这一步因为离线部署的本质是把联网状态下准备好的东西原样搬到内网。如果联网时都跑不通断网后只会更抓瞎。这一关你只需要三个动作拿代码、装依赖、装模型。步骤 1获取源码并安装依赖用虚拟环境隔离依赖是个好习惯避免污染系统 Pythongit clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate python -m venv venv source venv/bin/activate # Windows 用 venv\Scripts\activate pip install -r requirements.txt预期结果依赖装完无报错。项目根目录下的main.py就是启动入口。步骤 2下载语言模型模型是翻译的大脑不装模型服务也能启动但翻不了任何东西。项目提供了现成的下载脚本scripts/install_models.py支持只下载你需要的语言对避免把磁盘塞爆# 只要中英互译相关的模型 python scripts/install_models.py --load_only_lang_codes en,zh # 想要欧洲常用语种再加几个代码即可 python scripts/install_models.py --load_only_lang_codes en,fr,es,de,it模型默认装在你的用户目录下具体路径可以在启动日志里看到大致是~/.local/share/argos-translate/packages/。这一步会联网因为模型文件需要从远程索引下载。步骤 3启动服务并用 curl 验收python main.py --host 0.0.0.0 --port 5000看到日志里出现类似 Loaded support for X languages 就说明模型加载成功。然后在另一个终端验证# 翻译英语 - 中文 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预期结果第一条请求返回翻译后的中文第二条返回fr法语。到这里你的最小可用版本已经上线浏览器打开http://localhost:5000还能看到自带的网页界面。第二关把网络依赖拆干净实现真正的离线运行第一关跑通后重点来了服务启动时会不会偷偷联网模型从哪来依赖怎么在没网的机器上装这一关逐个解决。关闭模型自动更新其实它默认就是关的在libretranslate/default_values.py里UPDATE_MODELS的默认值是False也就是说服务默认不会在启动时去更新模型。这一点很关键——很多翻译工具启动时都要联网检查更新而 LibreTranslate 不需要这也是它能离线运行的前提之一。如果你之前手动加过--update-models启动参数离线部署时务必去掉。真到了没网的环境init.py里的模型更新逻辑会失败但项目很贴心会打印一句 Cannot update models (normal if youre offline) 然后继续用本地已有的模型启动——这条日志不是错误而是离线模式已就绪的信号。把 Python 依赖打包成离线安装包在断网机器上pip install是装不了东西的所以要在联网机器上提前把依赖囤好# 在联网机器上把全部依赖下载成 wheel 文件 pip download -r requirements.txt -d offline_deps/ \ --no-cache-dir \ --only-binary:all: # 把整个 offline_deps 目录连同项目源码一起拷到内网机器到了内网机器用本地目录作为安装源即可pip install --no-index --find-links./offline_deps/ -r requirements.txt--no-index的意思是不要连 PyPI--find-links指定去本地目录找包。这样整个安装过程全程无外网。拷贝模型离线部署的灵魂依赖能离线装了模型也得跟着走。把第一步下载好的模型目录整个拷贝到内网机器对应的用户目录下保持目录结构一致即可。拷贝时注意两点目录路径要对模型装在哪个用户目录下启动服务就用哪个用户别拷到 A 用户却用 B 用户启动权限要够确认该用户对模型目录有读写权限。启动断网版服务export LT_LOAD_ONLYen,zh # 只加载需要的语言加快启动 python main.py --host 0.0.0.0 --port 5000然后把网线拔了或者在内网机器上直接跑再用第一关的 curl 命令测一遍——翻译和检测照常工作这就说明离线部署真正成立了。第三关按场景增强从小玩具变成生产服务服务能离线跑只是及格线。接下来按需加点料让它配得上生产可用四个字。增强 1按需加载语言控制内存与启动时间语言模型全量加载会占不少内存。用--load-only参数或环境变量LT_LOAD_ONLY只加载你实际用到的语言python main.py --load-only en,zh,fr,de --host 0.0.0.0 --port 5000这会显著缩短启动时间也减少内存占用。代价是没在列表里的语言将不可用所以加载前先想清楚业务需要哪些语种。增强 2调线程、开缓存、量指标翻译是 CPU 密集活多线程能提升吞吐python main.py --threads 8 --req-limit 100 --char-limit 1000--threads工作线程数按 CPU 核数调整--req-limit每客户端每分钟请求上限防止被滥用--char-limit单次请求字符上限还可以加--metrics开启 Prometheus 监控端点配个看板就能盯着服务健康度。增强 3Docker 化一条命令部署如果你所在团队习惯容器化项目自带的docker-compose.yml可以直接用。核心思路是在联网机器上把镜像和模型准备好导出后导入内网 Docker 环境保持模型目录用 volume 挂载避免每次启动重复下载。这样内网部署就变成一句docker compose up -d。三个方案怎么选一张表说清楚场景推荐做法理由个人电脑 / 临时演示源码 最小语言集启动快、改配置方便、占空间小公司内网正式服务源码 systemd 离线依赖包便于精细控制线程、限流与日志多台机器 / 团队交付Docker 镜像 模型卷环境一致、迁移方便、一键扩容选型的核心就一句话要控制力和灵活度选源码要省心和一致性选容器。真实避坑记录三个我踩过的坑理论讲完分享几次真实翻车经历希望你不用再走一遍。坑一模型路径对不上报 Model not found。我曾在 A 用户下下载模型用 B 用户启动服务结果死活找不到模型。排查了半小时才发现是用户目录不一致。解决启动前先确认模型目录里真的有.argosmodel文件并确认启动用户能读到它。坑二内网装依赖时版本冲突。离线机器上的 Python 版本和打包依赖时用的不一致导致某些 wheel 装不上。解决打包和安装尽量用完全相同的 Python 版本最好在打包机上先python --version记录版本号内网装之前先核对。坑三离线启动时日志里出现报错以为失败了。第一次断网启动看到 Cannot update models 吓得以为装错了。其实这是项目在告诉你联网更新失败正在用本地模型继续属于正常输出。别看到异常日志就 CtrlC等几秒看有没有 Loaded support for X languages 再下结论。别忘了安全离线不等于裸奔内网不等于绝对安全该做的防护一样不能少开 API Key启动加--api-keys配合db/api_keys.db做密钥管理给不同团队发不同 Key谁滥用一目了然限制入口--req-limit、--char-limit都配上防止单次大文本拖垮服务内网也设白名单在防火墙层只放行需要访问翻译服务的 IP。相关安全逻辑可以在libretranslate/security.py和libretranslate/api_keys.py里翻到想深入了解源码的可以从这两个文件入手。写在最后你的翻译能力从此自己说了算回顾一下这趟闯关路第一关我们在联网环境把最小可用版本跑通第二关把依赖、模型、配置三样东西全部离线化实现了拔网线照常翻译第三关按场景做了加载控制、性能调优和容器化。中间还顺手排掉了三个真实踩过的坑。一句话总结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），仅供参考
