易翻译开发者平台 Logo 易翻译引擎平台

翻译能力嵌入你的产品

一套引擎、一组API、一条流水线。从架构设计到生产部署,我们为翻译引擎开发者整理了从零到一的完整路径。覆盖Transformer与混合架构,支持180+语种方向的训练数据。

引擎架构全览

接入层
REST / gRPC / WebSocket 三通道接入,统一鉴权与限流
预处理
语种识别、分句、实体识别、格式清洗管线
推理核心
Transformer Encoder-Decoder + MoE 混合专家路由
后处理
标点还原、术语替换、格式回填、质量评估
缓存与加速
翻译记忆库 + KV-Cache + ONNX Runtime 推理优化

Transformer 骨干网络

基于标准 Encoder-Decoder 架构,支持 24/36 层配置。多头注意力头数可根据语种对复杂度动态调整,中英方向默认 16 头,小语种可降至 8 头以降低显存占用。

混合专家 (MoE) 路由

在 30+ 语种混合模型上启用 MoE 层。每个 token 经由门控网络分配给 top-2 专家,总参数量可达 1.2T 但推理时仅激活约 13B 参数,在 BLEU 上比稠密模型提高 2.1 分。

术语干预机制

推理时注入领域术语表,通过 constrained decoding 确保专有名词、产品名称、法律条款的翻译一致性。术语表以 JSON 格式传入,支持正则匹配与大小写敏感控制。

翻译记忆库集成

引擎内置 TM 模糊匹配模块,对输入句子计算 n-gram 指纹,在千万级记忆库中实现 < 5ms 检索。匹配度超过 80% 的结果直接返回,跳过模型推理,降低 40-60% 的 GPU 负载。

API 参考概览

POST

文本翻译

/v2/translate/text

支持单条与批量文本翻译。请求体携带 source_lang、target_lang 和待翻译文本数组,响应返回译文与对齐信息。单次最多 128 条,每条不超过 5000 字符。

POST

文档翻译

/v2/translate/document

上传 PDF、DOCX、PPTX 或 Markdown 文件,异步返回翻译后的文档。保留原始排版、表格结构与图片中的文字也会提取并翻译后回填。

GET

语种检测

/v2/detect/language

传入文本片段,返回 top-3 语种及其置信度分数。基于 fastText 分类器,单次检测延迟 < 3ms,覆盖 200+ 语种与地区变体。

GET

引擎状态

/v2/engine/status

返回当前引擎版本、加载的模型列表、GPU 利用率、请求队列深度与平均延迟。用于运维监控与自动扩缩容决策。

POST

术语库管理

/v2/glossary/manage

创建、更新、删除自定义术语库。支持批量导入 CSV/JSON,单个术语库上限 50 万条。术语在翻译请求中通过 glossary_id 参数关联。

POST

流式翻译

/v2/translate/stream

基于 SSE (Server-Sent Events) 的流式翻译接口,token 级别实时输出。适用于语音同传、实时字幕等低延迟场景,首 token 延迟 < 200ms。

自定义模型训练

1

数据准备

整理平行语料(TMX、CSV 或纯文本格式),清洗噪声句对。内置数据质量检测:长度比异常、语种错配、特殊字符比例过高自动筛除。

2

分词与BPE训练

使用 SentencePiece 在目标语料上训练 BPE 分词器。词汇表大小建议 32k-64k,覆盖 99.5% 以上的 token。支持增量合并已有词表。

3

基座模型微调

在预训练多语种基座上,使用 LoRA 或全参数微调。LoRA rank=64 时可在单张 A100 上完成微调,参数量仅为基座的 0.3%,BLEU 损失 < 0.5。

4

评估与导出

基于 BLEU、COMET、chrF 多指标评估。通过后在 ONNX 或 TensorRT 上导出优化模型,体积压缩 40-60%,推理速度提升 2-4 倍。

5

上线与A/B测试

新模型以影子模式部署,对比生产模型的翻译结果。连续 7 天指标优于基线则自动切流,支持一键回滚至上一版本。

性能调优指南

3.2x

INT8 量化加速

将 FP16 模型量化为 INT8 精度,在 NVIDIA T4 上实测推理吞吐提升 3.2 倍,BLEU 损失控制在 0.3 以内。使用 TensorRT 的 PTQ 校准流程,仅需 500 条校准样本。

< 5ms

KV-Cache 命中延迟

在重复片段场景下,KV-Cache 命中后绕过 encoder 直接输出,延迟降至 5ms 以内。缓存策略支持 LRU 与基于语义相似度的自适应淘汰。

4000+

单卡并发请求

通过 continuous batching 动态合并请求,A100 80GB 上可同时处理 4000+ 请求。batch scheduler 每 10ms 重组一次批次,最大化 GPU 利用率。

60%

TM 命中率提升

翻译记忆库的模糊匹配召回率从 42% 提升至 60% 以上,结合向量检索替代 n-gram 指纹,有效减少 30% 的无效推理调用的同时保持了亚毫秒级检索速度。

集成示例

Python SDK
from traneasy import TranslateClient

client = TranslateClient(api_key="YOUR_API_KEY")

# 文本翻译
result = client.translate(
    text=["Hello, world!", "How are you?"],
    source_lang="en",
    target_lang="zh",
    glossary_id="my_tech_terms"
)

for item in result.translations:
    print(f"{item.source} -> {item.target}")
cURL
curl -X POST "https://api.traneasy-translate.dev/v2/translate/text" \
  -H "Authorization: Bearer $API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "source_lang": "en",
    "target_lang": "ja",
    "text": ["Machine translation has come a long way."],
    "options": {"formality": "formal"}
  }'
Node.js SDK
import { TranslateClient } from "@traneasy/translate-sdk";

const client = new TranslateClient({ apiKey: process.env.TRANEASY_KEY });

const { translations } = await client.translateText({
  sourceLang: "zh",
  targetLang: "en",
  text: ["请将这份合同翻译成英文。"],
});

console.log(translations[0].target);

部署指南

🐋

Docker 容器部署

提供预构建 Docker 镜像,基础镜像基于 nvidia/cuda:12.4.0-runtime-ubuntu22.04。一键拉取并启动翻译服务。

  • GPU 与 CPU 两套镜像可选
  • 支持 docker-compose 一键编排
  • 环境变量注入模型路径与 API Key
  • 健康检查端点自动注册

Kubernetes 集群部署

完整的 Helm Chart 包,包含 Deployment、HPA、Service、Ingress 配置。适配 AWS EKS、GCP GKE、阿里云 ACK。

  • HPA 基于 GPU 利用率自动扩缩
  • NVIDIA Device Plugin 集成
  • 多可用区反亲和调度
  • Prometheus 指标 + Grafana 面板

无服务器 (Serverless) 部署

将翻译引擎封装为云函数,适用于非持续高负载场景。支持 AWS Lambda(容器镜像模式)、阿里云函数计算。

  • 冷启动优化:模型预加载至 /tmp
  • 按调用次数计费,闲置零成本
  • 最大并发 1000,自动弹性伸缩
  • 适用于内部工具与低频场景

常见问题

翻译引擎支持哪些语种方向?

引擎预置了 180+ 语种方向,涵盖中、英、日、韩、法、德、西、阿、俄等主流语种,以及泰语、越南语、印尼语、马来语等东南亚语种。部分低资源语种对(如芬兰语-日语)需要额外训练自定义模型才能达到可用精度,默认模型在这些方向上的 BLEU 通常在 15-20 之间。你可以在/v2/engine/languages 接口获取当前实例已加载的完整语种列表。

自定义模型训练需要多少训练数据?

这取决于你的起点。如果使用我们提供的多语种预训练基座做 LoRA 微调,10 万高质量句对就可以在特定领域(如医药、法律)上看到明显的 BLEU 提升。全参数微调建议至少 100 万句对。从头训练一个双语模型的话,500 万句对是门槛,1000 万以上才算充裕。语料质量比数量重要得多——100 万条经过人工校对的对齐语料,效果好于 500 万条从网上爬下来的噪声数据。

API 的并发限制和计费方式是怎样的?

免费开发 Key 限 10 QPS,付费版按实际用量阶梯计价。标准版的起步额度是 100 QPS,可以按需购买并发扩容包。计费维度是源文本字符数(含空格与标点),不是翻译后的字符数。流式翻译按实际生成的 token 数计费。每月前 50 万字符免费,适合开发调试。详细价格表见控制台 Billing 页面。

私有化部署对硬件有什么要求?

最小配置是一张 NVIDIA T4 (16GB),可以加载 INT8 量化后的中英模型,并发约 20-30 个请求。推荐配置是 A100 80GB 或 H100,能够承载多语种混合模型并实现 4000+ 并发。CPU 部署仅适用于离线批量翻译场景——在 64 核 Xeon 上翻译 1000 字大约需要 3-5 秒,延迟不适合在线服务。

如何评估翻译质量——除了 BLEU 还有什么指标?

BLEU 是工业界标配但对中文不够友好——它不懂同义词替换。我们强烈建议搭配 COMET (神经网络评估模型) 和 chrF (字符级 F-score)。COMET 在 WMT 评测中与人工评估的 Spearman 相关系数达到 0.45+,是目前最接近人类判断的自动指标。生产环境中我们还会追踪"译后编辑距离"——翻译结果被人工修改的比例,这个数字低说明翻译真的能直接用。

术语干预功能怎么保证专有名词不被错误翻译?

术语干预在解码阶段起作用。你通过 glossary_id 传入一个术语表(比如 "碳捕集" -> "carbon capture"),引擎在 beam search 过程中检测到源端术语出现时,会约束目标端的候选 token 必须生成你指定的译文。这个约束是硬性的——它不会"忘了"用。如果术语表有歧义(同一源端术语对应多个译法),可以通过 `context` 字段提供上下文句子来消歧。

从旧版 API(v1)迁移到 v2 需要注意什么?

最大的变化是鉴权方式从 API Key Header 改为 Bearer Token,HTTP Header 从 `X-API-Key` 改为 `Authorization: Bearer `。响应结构也有调整:v1 的 `data.translatedText` 扁平结构变成了 v2 的 `translations[].target` 数组格式,同时增加了 `alignments` 字段返回源文与译文的词对齐信息。v1 会继续维护到 2027 年 6 月,但新功能不会再往回移植。