LibreTranslate 部署自建翻译 API 实践【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate上个月给产品做多语言功能评审时我把某商业翻译 API 的按量单价拉出来算了一遍——按每月几百万次调用估算账单数字让财务同事皱了下眉而且客户文本要出境合规那边也没点头。于是我转了自建路线最后落在 LibreTranslate 上一个开源翻译服务翻译引擎是 Argos Translate全程离线推理数据不出本地机器部署完调用费用就是零。LibreTranslate 的翻译请求内部链路这一节不介绍它是什么直接说清楚一次请求进来之后发生了什么以及它和调云端 API 的本质区别在哪。请求打到 Flask 应用后先过一遍限流和 API 密钥校验如果启用了的话然后按语言对取出本地加载的模型交给 Argos Translate 做神经推理——本质上就是一个本地跑的 NMT 模型不是词表拼接也不是转发给任何第三方。推理结果封装成 JSON 返回。整个链路不依赖外网断网环境也能翻译没有按量计费因为根本没有调用量这个概念。和常见方案比关键差异只有三点维度LibreTranslate商业云端 API数据流向文本留在本地可跑在纯内网文本上传到服务商服务器调用成本部署后零边际成本按调用量计费可用性依赖不依赖外部网络首次拉模型除外依赖服务商服务状态三种部署路径怎么选先判断你的场景再动手只是快速验证或轻量生产走 Docker ✅要改代码、做定制比如二次开发检测逻辑或限流策略走源码要长期挂着跑且不想依赖容器走 systemd。Docker大多数人的默认选项一条命令搞定生产要点就三个模型持久化到卷不然容器重建又要重新下载、restart 策略、API 密钥开关。docker run -d --name libretranslate \ -p 5000:5000 \ -v lt_data:/home/libretranslate/.local \ -e LT_API_KEYStrue \ -e LT_API_KEYS_DB_PATH/home/libretranslate/.local/api_keys.db \ --restart unless-stopped \ libretranslate/libretranslate:latest适用边界如果你需要改libretranslate/app.py里的业务逻辑Docker 官方镜像不够用下面的源码路线更合适。源码要定制才值得走什么情况下值得你要魔改限流策略、给翻译结果加后处理、或者把翻译能力嵌进自己的 Python 服务里。定制化入口基本都在libretranslate/目录app.py是核心detect.py管语言检测。git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate python -m venv venv source venv/bin/activate pip install -e . python scripts/install_models.py python main.py --host 0.0.0.0 --port 5000systemd长期裸机运行的兜底只贴关键片段完整的.service文件按 systemd 惯例写即可[Service] WorkingDirectory/opt/LibreTranslate ExecStart/opt/LibreTranslate/venv/bin/python /opt/LibreTranslate/main.py \ --host 0.0.0.0 --port 5000 EnvironmentLT_API_KEYStrue Restartalways核心 API 实测翻译、检测、文件我按实际使用频率调了三个端点文本翻译、语言检测、文件翻译。Web 界面不用单独说——浏览器打开默认 5000 端口就能看到翻译页面文本和文件两种模式都有适合快速人工验证翻译质量。/translate单条和批量共用一个入口q传字符串就是单条传 JSON 数组就是批量响应里translatedText的形态跟着变字符串对字符串列表对列表。curl -X POST http://localhost:5000/translate \ -d qHello, world -d sourceen -d targetzh -d formattext{translatedText: 你好世界}注意source传auto可以自动检测源语言出错时返回 400 并带{error: ...}字段限流触发是 429。/detect给一段文本猜语言返回的是一个数组按置信度排序常用的是第一个元素curl -X POST http://localhost:5000/detect -d qHola, mundo[{confidence: 0.9999, language: es}]我在做批量文档预处理时基本只用它先 detect 再翻译省掉人工标注源语言。/translate_filemultipart 上传拿回文件 URL参数是filesourcetarget响应不是文件内容本身而是translatedFileUrl再去 GET 那个路径下载curl -X POST http://localhost:5000/translate_file \ -F filenotes.txt -F sourceen -F targetzh{translatedFileUrl: /translated-files/xxxxxxxx}这个端点可以关掉--disable-files-translation纯文本 API 服务的话建议关少一个攻击面。生产部署安全与性能清单上生产前我逐项核对的清单。每项都给了为什么命令只保留核心一行所有参数既能用命令行传也能用LT_前缀环境变量传。安全启用 API 密钥LT_API_KEYStrue——不加密钥局域网里谁都能白嫖你的推理资源设限流LT_REQ_LIMIT100——防单个客户端用长文本请求打满 CPU前置 Nginx 终止 SSL——API 密钥走明文 HTTP 等于白送应用层自带--ssl参数也可以但反代还能顺带做访问日志和缓冲性能线程数LT_THREADS4——默认 4按 CPU 核心数调直接影响并发推理能力按需加载模型LT_LOAD_ONLYen,zh,fr——全量加载很吃内存只装你真用的语言对开翻译缓存--translation-cache all——重复文本直接命中缓存长尾收益明显生产拓扑我保持得很简单四个节点三个真实场景的实现片段给现有 Web 应用加多语言切换要解决的问题页面上几十条固定文案要跟着用户选的语言实时换。核心就是攒一批q调一次接口批量模式一次换完async function switchLang(target) { const nodes document.querySelectorAll([data-i18n]); const res await fetch(http://localhost:5000/translate, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({q: [...nodes].map(n n.textContent), source: en, target, format: text}) }); const {translatedText} await res.json(); nodes.forEach((n, i) n.textContent translatedText[i]); }注意两点同文本同语言对结果稳定前端可以再挂一层缓存省请求批量条数受--batch-limit约束超长文案记得分批。批量文档翻译小工具要解决的问题一份几百行的文本文件整体翻掉带进度、能扛限流import requests, time API http://localhost:5000/translate texts [l.strip() for l in open(src.txt) if l.strip()] for i, t in enumerate(texts): r requests.post(API, data{q: t, source: auto, target: zh, format: text}) if r.status_code 429: time.sleep(60) # 触发限流等一分钟重试本条 continue print(f[{i1}/{len(texts)}] {r.json()[translatedText]})实测下来这是最容易翻车的场景LT_CHAR_LIMIT和LT_REQ_LIMIT会先于你的耐心生效长文档先按段落切、速率拉低比什么都管用。CI 流水线里的本地化冒烟检测要解决的问题部署流水线里确认翻译服务活着、翻译端点真能出结果而不是只看端口通不通set -e curl -sf http://lt.internal:5000/health /dev/null RESULT$(curl -s -X POST http://lt.internal:5000/translate \ -d qhealth check -d sourceen -d targetzh -d formattext) echo $RESULT | grep -q translatedText echo i18n service OK一句固定文本走完/translate比单独探/health更能覆盖模型加载是否正常开了密钥的话 CI 里记得带上。踩坑记录本地部署容易碰的四个坑模型下载超时。第一次启动卡很久甚至报错/languages返回的语言数偏少——Argos 模型动辄几百 MB网络差时下载容易断。解法配置LT_UPDATE_MODELStrue对应--update-models让它在启动时增量补齐中断重跑即可不必整包重来。内存占用超预期。⚠️ 我一开始按 2GB 规划实际起来后吃了 3G 多——原因是默认会加载全部已安装语言对的模型每个语言对一套。加一个--load-only en,zh,fr把语言对收窄内存立刻降下来这是最立竿见影的一刀。端口冲突。容器反复 restart日志里是 Address already in use——5000 端口被别的占用了。lsof -i :5000找到占用进程或者直接把映射改成-p 5001:5000一行搞定。响应形态变了取到空值。⚠️ 单条调用正常的客户端代码切到批量模式后translatedText变成了 list原来直接当字符串用的地方全崩。我一开始也搞错了后来统一成客户端永远发数组、永远收数组用一个类型判断收口代码反而更简单。另外出错时别硬取translatedText先判状态码和error字段。该不该选它几条判断标准自建翻译 API 不是无条件划算我按这几个标准来分数据合规要求文本不能出内网/出境 → 自建几乎没有替代选项LibreTranslate 合适日均调用量在百万次以内、语言对相对集中 → 自建成本优势明显商业 API 的账单在这里才是大头需要 100 语言覆盖或对标一线云厂商的翻译质量 → 老实选商业 API开源模型的长尾语言质量还有差距它覆盖的 50 种语言够用但别指望面面俱到。项目演进方向上简单提一句更好的 NMT 模型持续集成质量在逐版本改善社区驱动的语言库扩展多模态文档、图片等能力在路线上当前核心仍是文本下一步建议很具体先用 Docker 把最小部署跑起来拿你真业务里的语言对测延迟和准确率——单条几百毫秒级、质量人工抽检能接受再谈生产化的密钥、限流和多实例达不到就先别上别在第一天就把生产架构搭满。【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 
长河君 · 2026/9/16 14:39:53 · 阅读 1.2k LibreTranslate 部署：自建翻译 API 实践
LibreTranslate 部署自建翻译 API 实践【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate上个月给产品做多语言功能评审时我把某商业翻译 API 的按量单价拉出来算了一遍——按每月几百万次调用估算账单数字让财务同事皱了下眉而且客户文本要出境合规那边也没点头。于是我转了自建路线最后落在 LibreTranslate 上一个开源翻译服务翻译引擎是 Argos Translate全程离线推理数据不出本地机器部署完调用费用就是零。LibreTranslate 的翻译请求内部链路这一节不介绍它是什么直接说清楚一次请求进来之后发生了什么以及它和调云端 API 的本质区别在哪。请求打到 Flask 应用后先过一遍限流和 API 密钥校验如果启用了的话然后按语言对取出本地加载的模型交给 Argos Translate 做神经推理——本质上就是一个本地跑的 NMT 模型不是词表拼接也不是转发给任何第三方。推理结果封装成 JSON 返回。整个链路不依赖外网断网环境也能翻译没有按量计费因为根本没有调用量这个概念。和常见方案比关键差异只有三点维度LibreTranslate商业云端 API数据流向文本留在本地可跑在纯内网文本上传到服务商服务器调用成本部署后零边际成本按调用量计费可用性依赖不依赖外部网络首次拉模型除外依赖服务商服务状态三种部署路径怎么选先判断你的场景再动手只是快速验证或轻量生产走 Docker ✅要改代码、做定制比如二次开发检测逻辑或限流策略走源码要长期挂着跑且不想依赖容器走 systemd。Docker大多数人的默认选项一条命令搞定生产要点就三个模型持久化到卷不然容器重建又要重新下载、restart 策略、API 密钥开关。docker run -d --name libretranslate \ -p 5000:5000 \ -v lt_data:/home/libretranslate/.local \ -e LT_API_KEYStrue \ -e LT_API_KEYS_DB_PATH/home/libretranslate/.local/api_keys.db \ --restart unless-stopped \ libretranslate/libretranslate:latest适用边界如果你需要改libretranslate/app.py里的业务逻辑Docker 官方镜像不够用下面的源码路线更合适。源码要定制才值得走什么情况下值得你要魔改限流策略、给翻译结果加后处理、或者把翻译能力嵌进自己的 Python 服务里。定制化入口基本都在libretranslate/目录app.py是核心detect.py管语言检测。git clone https://gitcode.com/GitHub_Trending/li/LibreTranslate cd LibreTranslate python -m venv venv source venv/bin/activate pip install -e . python scripts/install_models.py python main.py --host 0.0.0.0 --port 5000systemd长期裸机运行的兜底只贴关键片段完整的.service文件按 systemd 惯例写即可[Service] WorkingDirectory/opt/LibreTranslate ExecStart/opt/LibreTranslate/venv/bin/python /opt/LibreTranslate/main.py \ --host 0.0.0.0 --port 5000 EnvironmentLT_API_KEYStrue Restartalways核心 API 实测翻译、检测、文件我按实际使用频率调了三个端点文本翻译、语言检测、文件翻译。Web 界面不用单独说——浏览器打开默认 5000 端口就能看到翻译页面文本和文件两种模式都有适合快速人工验证翻译质量。/translate单条和批量共用一个入口q传字符串就是单条传 JSON 数组就是批量响应里translatedText的形态跟着变字符串对字符串列表对列表。curl -X POST http://localhost:5000/translate \ -d qHello, world -d sourceen -d targetzh -d formattext{translatedText: 你好世界}注意source传auto可以自动检测源语言出错时返回 400 并带{error: ...}字段限流触发是 429。/detect给一段文本猜语言返回的是一个数组按置信度排序常用的是第一个元素curl -X POST http://localhost:5000/detect -d qHola, mundo[{confidence: 0.9999, language: es}]我在做批量文档预处理时基本只用它先 detect 再翻译省掉人工标注源语言。/translate_filemultipart 上传拿回文件 URL参数是filesourcetarget响应不是文件内容本身而是translatedFileUrl再去 GET 那个路径下载curl -X POST http://localhost:5000/translate_file \ -F filenotes.txt -F sourceen -F targetzh{translatedFileUrl: /translated-files/xxxxxxxx}这个端点可以关掉--disable-files-translation纯文本 API 服务的话建议关少一个攻击面。生产部署安全与性能清单上生产前我逐项核对的清单。每项都给了为什么命令只保留核心一行所有参数既能用命令行传也能用LT_前缀环境变量传。安全启用 API 密钥LT_API_KEYStrue——不加密钥局域网里谁都能白嫖你的推理资源设限流LT_REQ_LIMIT100——防单个客户端用长文本请求打满 CPU前置 Nginx 终止 SSL——API 密钥走明文 HTTP 等于白送应用层自带--ssl参数也可以但反代还能顺带做访问日志和缓冲性能线程数LT_THREADS4——默认 4按 CPU 核心数调直接影响并发推理能力按需加载模型LT_LOAD_ONLYen,zh,fr——全量加载很吃内存只装你真用的语言对开翻译缓存--translation-cache all——重复文本直接命中缓存长尾收益明显生产拓扑我保持得很简单四个节点三个真实场景的实现片段给现有 Web 应用加多语言切换要解决的问题页面上几十条固定文案要跟着用户选的语言实时换。核心就是攒一批q调一次接口批量模式一次换完async function switchLang(target) { const nodes document.querySelectorAll([data-i18n]); const res await fetch(http://localhost:5000/translate, { method: POST, headers: {Content-Type: application/json}, body: JSON.stringify({q: [...nodes].map(n n.textContent), source: en, target, format: text}) }); const {translatedText} await res.json(); nodes.forEach((n, i) n.textContent translatedText[i]); }注意两点同文本同语言对结果稳定前端可以再挂一层缓存省请求批量条数受--batch-limit约束超长文案记得分批。批量文档翻译小工具要解决的问题一份几百行的文本文件整体翻掉带进度、能扛限流import requests, time API http://localhost:5000/translate texts [l.strip() for l in open(src.txt) if l.strip()] for i, t in enumerate(texts): r requests.post(API, data{q: t, source: auto, target: zh, format: text}) if r.status_code 429: time.sleep(60) # 触发限流等一分钟重试本条 continue print(f[{i1}/{len(texts)}] {r.json()[translatedText]})实测下来这是最容易翻车的场景LT_CHAR_LIMIT和LT_REQ_LIMIT会先于你的耐心生效长文档先按段落切、速率拉低比什么都管用。CI 流水线里的本地化冒烟检测要解决的问题部署流水线里确认翻译服务活着、翻译端点真能出结果而不是只看端口通不通set -e curl -sf http://lt.internal:5000/health /dev/null RESULT$(curl -s -X POST http://lt.internal:5000/translate \ -d qhealth check -d sourceen -d targetzh -d formattext) echo $RESULT | grep -q translatedText echo i18n service OK一句固定文本走完/translate比单独探/health更能覆盖模型加载是否正常开了密钥的话 CI 里记得带上。踩坑记录本地部署容易碰的四个坑模型下载超时。第一次启动卡很久甚至报错/languages返回的语言数偏少——Argos 模型动辄几百 MB网络差时下载容易断。解法配置LT_UPDATE_MODELStrue对应--update-models让它在启动时增量补齐中断重跑即可不必整包重来。内存占用超预期。⚠️ 我一开始按 2GB 规划实际起来后吃了 3G 多——原因是默认会加载全部已安装语言对的模型每个语言对一套。加一个--load-only en,zh,fr把语言对收窄内存立刻降下来这是最立竿见影的一刀。端口冲突。容器反复 restart日志里是 Address already in use——5000 端口被别的占用了。lsof -i :5000找到占用进程或者直接把映射改成-p 5001:5000一行搞定。响应形态变了取到空值。⚠️ 单条调用正常的客户端代码切到批量模式后translatedText变成了 list原来直接当字符串用的地方全崩。我一开始也搞错了后来统一成客户端永远发数组、永远收数组用一个类型判断收口代码反而更简单。另外出错时别硬取translatedText先判状态码和error字段。该不该选它几条判断标准自建翻译 API 不是无条件划算我按这几个标准来分数据合规要求文本不能出内网/出境 → 自建几乎没有替代选项LibreTranslate 合适日均调用量在百万次以内、语言对相对集中 → 自建成本优势明显商业 API 的账单在这里才是大头需要 100 语言覆盖或对标一线云厂商的翻译质量 → 老实选商业 API开源模型的长尾语言质量还有差距它覆盖的 50 种语言够用但别指望面面俱到。项目演进方向上简单提一句更好的 NMT 模型持续集成质量在逐版本改善社区驱动的语言库扩展多模态文档、图片等能力在路线上当前核心仍是文本下一步建议很具体先用 Docker 把最小部署跑起来拿你真业务里的语言对测延迟和准确率——单条几百毫秒级、质量人工抽检能接受再谈生产化的密钥、限流和多实例达不到就先别上别在第一天就把生产架构搭满。【免费下载链接】LibreTranslateFree and Open Source Machine Translation API. Self-hosted, offline capable and easy to setup.项目地址: https://gitcode.com/GitHub_Trending/li/LibreTranslate创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考