ai-saas / saas-search

Name Last Update
..
backends Loading commit data...
README.md Loading commit data...
__init__.py Loading commit data...
cache.py Loading commit data...
client.py Loading commit data...
languages.py Loading commit data...
logging_utils.py Loading commit data...
nllb_flores_short_map.py Loading commit data...
prompts.py Loading commit data...
protocols.py Loading commit data...
scenes.py Loading commit data...
service.py Loading commit data...
settings.py Loading commit data...
text_splitter.py Loading commit data...

README.md

Translation Module

translation/ 是当前项目翻译能力的主目录。
如果要开发、部署、联调、压测翻译服务，优先看这份文档。

对应服务：

相关脚本与报告：

1. 设计目标

翻译模块采用：

  • 一个 translator service
  • 多个 capability backend
  • 一个统一外部接口：model + scene

这套设计的目标是：

  • 翻译能力可以独立扩展、独立启停
  • scene、语言码、prompt 模板、模型方向约束等翻译域知识集中在 translation/
  • 配置尽量集中在 <code>config/config.yaml</code> 的 services.translation
  • 配置错误应尽早报错，不做静默兼容和隐式回退

2. 目录结构

核心文件：

后端实现：

3. 配置约定

翻译的部署配置统一放在：

示例：

services:
  translation:
    service_url: "http://127.0.0.1:6006"
    default_model: "llm"
    default_scene: "general"
    timeout_sec: 10.0
    cache:
      ttl_seconds: 62208000
      sliding_expiration: true
    capabilities:
      qwen-mt:
        enabled: true
        backend: "qwen_mt"
        model: "qwen-mt-flash"
        base_url: "https://dashscope-us.aliyuncs.com/compatible-mode/v1"
        timeout_sec: 10.0
        use_cache: true
      llm:
        enabled: true
        backend: "llm"
        model: "qwen-flash"
        base_url: "https://dashscope-us.aliyuncs.com/compatible-mode/v1"
        timeout_sec: 30.0
        use_cache: true
      deepl:
        enabled: false
        backend: "deepl"
        api_url: "https://api.deepl.com/v2/translate"
        timeout_sec: 10.0
        use_cache: true
      nllb-200-distilled-600m:
        enabled: true
        backend: "local_nllb"
        model_id: "facebook/nllb-200-distilled-600M"
        model_dir: "./models/translation/facebook/nllb-200-distilled-600M"
        ct2_model_dir: "./models/translation/facebook/nllb-200-distilled-600M/ctranslate2-float16"
        ct2_compute_type: "float16"
        ct2_conversion_quantization: "float16"
        ct2_auto_convert: true
        ct2_inter_threads: 4
        ct2_max_queued_batches: 32
        ct2_batch_type: "examples"
        ct2_decoding_length_mode: "source"
        ct2_decoding_length_extra: 8
        ct2_decoding_length_min: 32
        device: "cuda"
        torch_dtype: "float16"
        batch_size: 16
        max_input_length: 256
        max_new_tokens: 64
        num_beams: 1
        use_cache: true
      opus-mt-zh-en:
        enabled: true
        backend: "local_marian"
        model_id: "Helsinki-NLP/opus-mt-zh-en"
        model_dir: "./models/translation/Helsinki-NLP/opus-mt-zh-en"
        ct2_model_dir: "./models/translation/Helsinki-NLP/opus-mt-zh-en/ctranslate2-float16"
        ct2_compute_type: "float16"
        ct2_conversion_quantization: "float16"
        ct2_auto_convert: true
        device: "cuda"
        torch_dtype: "float16"
        batch_size: 16
        max_input_length: 256
        max_new_tokens: 256
        num_beams: 1
        use_cache: true
      opus-mt-en-zh:
        enabled: true
        backend: "local_marian"
        model_id: "Helsinki-NLP/opus-mt-en-zh"
        model_dir: "./models/translation/Helsinki-NLP/opus-mt-en-zh"
        ct2_model_dir: "./models/translation/Helsinki-NLP/opus-mt-en-zh/ctranslate2-float16"
        ct2_compute_type: "float16"
        ct2_conversion_quantization: "float16"
        ct2_auto_convert: true
        device: "cuda"
        torch_dtype: "float16"
        batch_size: 16
        max_input_length: 256
        max_new_tokens: 256
        num_beams: 1
        use_cache: true

配置边界：

  • config.yaml 只放部署和运行参数 例如 service_url、default_model、default_scene、enabled、base_url、api_url、model_dir、device
  • translation 目录内部放翻译静态知识 例如 scene 规则、语言码映射、prompt 模板、Marian 方向约束

说明：

  • service_url、default_model、default_scene 只从 YAML 读取
  • 不再通过环境变量静默覆盖翻译行为配置
  • 密钥仍通过环境变量提供
  • local_nllb / local_marian 当前由 CTranslate2 运行；首次启动时若 ct2_model_dir 不存在，会从 model_dir 自动转换

4. 环境变量

当前翻译模块主要依赖：

# Qwen / LLM
DASHSCOPE_API_KEY=sk-xxx

# DeepL
DEEPL_AUTH_KEY=xxx

服务启动端口仍可以由启动脚本环境控制：

TRANSLATION_HOST=0.0.0.0
TRANSLATION_PORT=6006

5. Scene 规则

当前只支持 3 个标准 scene：

  • general
  • sku_name
  • ecommerce_search_query

定义位置：

约定：

  • scene 是公共接口字段
  • 不再接受旧的 context
  • 不再对外暴露 prompt
  • LLM prompt 在服务内根据 scene 自动生成

6. 对外 HTTP 接口

服务入口在：

默认地址：

  • http://localhost:6006

提供接口：

  • POST /translate
  • GET /health

6.1 POST /translate

请求体：

{
  "text": "商品名称",
  "target_lang": "en",
  "source_lang": "zh",
  "model": "opus-mt-zh-en",
  "scene": "sku_name"
}

字段说明：

  • text 支持 string 或 string[]
  • target_lang 目标语言
  • source_lang 源语言
  • model 已配置的 capability 名称
  • scene 翻译场景

响应体：

{
  "text": "商品名称",
  "target_lang": "en",
  "source_lang": "zh",
  "translated_text": "Product name",
  "status": "success",
  "model": "opus-mt-zh-en",
  "scene": "sku_name"
}

批量时：

  • 返回列表和输入等长
  • 单条失败返回 null

6.2 GET /health

返回示例：

{
 "status": "healthy",
  "service": "translation",
  "default_model": "llm",
  "default_scene": "general",
  "available_models": ["qwen-mt", "llm", "nllb-200-distilled-600m", "opus-mt-zh-en", "opus-mt-en-zh"],
  "enabled_capabilities": ["qwen-mt", "llm", "nllb-200-distilled-600m", "opus-mt-zh-en", "opus-mt-en-zh"],
  "loaded_models": ["qwen-mt", "llm", "nllb-200-distilled-600m", "opus-mt-zh-en", "opus-mt-en-zh"]
}

说明：

  • translator service 进程启动时会一次性初始化全部已启用 capability
  • 因此本地模型加载失败、依赖缺失、配置错误会在启动阶段直接暴露，而不是拖到首个在线请求

7. 代码调用方式

业务侧统一这样调用：

from translation.client import create_translation_client

translator = create_translation_client()
result = translator.translate(
    text="商品名称",
    source_lang="zh",
    target_lang="en",
    model="opus-mt-zh-en",
    scene="sku_name",
)

批量调用：

results = translator.translate(
    text=["商品1", "商品2"],
    source_lang="zh",
    target_lang="en",
    model="opus-mt-zh-en",
    scene="sku_name",
)

接口 shape 约定：

  • translate(text="...") 返回 Optional[str]
  • translate(text=[...]) 返回 List[Optional[str]]
  • 批量模式始终保持“等长、同序返回”；某条失败时对应位置为 None
  • backend/client 可通过 supports_batch 暴露是否支持原生批量；服务端会在必要时自动逐条拆分并保持返回 shape 不变

8. 具体实现说明

8.1 Qwen-MT

实现文件：

特点：

  • 云端机翻
  • 支持 Redis 翻译缓存
  • 适合质量优先、非超高并发场景

注意：

  • 当前默认 qwen-mt-flash 限速较低
  • 大量重复请求应依赖缓存

8.2 LLM Translation

实现文件：

特点：

  • 通用大模型翻译
  • 根据 scene 生成内部 prompt
  • 更灵活，但成本和稳定性取决于上游模型
  • 支持 Redis 翻译缓存

8.3 DeepL

实现文件：

特点：

  • 商业翻译 API
  • scene 会映射到内部上下文
  • 当前默认关闭
  • 支持 Redis 翻译缓存

8.4 facebook/nllb-200-distilled-600M

实现文件：

模型信息：

  • Hugging Face 名称：facebook/nllb-200-distilled-600M
  • 简介：多语种翻译：覆盖约 200 种语言。作为NLLB-200系列的蒸馏版本，该模型通过知识蒸馏技术将原130亿参数模型压缩至600M，同时保持了80%以上的翻译质量。
  • 本地目录：models/translation/facebook/nllb-200-distilled-600M
  • 当前磁盘占用：约 2.4G
  • 支持 Redis 翻译缓存
  • 模型类型：多语种 Seq2Seq 机器翻译模型
  • 来源：Meta NLLB（No Language Left Behind）系列的 600M 蒸馏版
  • 结构特点：
    • Transformer encoder-decoder 架构
    • 12 层 encoder + 12 层 decoder
    • d_model=1024
    • 通过 source_lang + forced_bos_token_id 控制翻译方向
    • 语言标识采用 language_script 形式，例如 eng_Latn、zho_Hans
    • 改良 encoder-decoder（含嵌入层缩放 scale_embedding、相对位置等）

核心配置如下：

配置项 参数值 备注
隐藏层维度（d_model） 1024
编码器 / 解码器层数 12 / 12
注意力头数 16
FFN 维度 4096
词表大小 256,206 多语统一词表
最大序列长度 1024 tokens 满足长文本翻译

config.json 片段（示意）：

{
  "d_model": 1024,
  "encoder_layers": 12,
  "decoder_layers": 12,
  "attention_dropout": 0.1,
  "use_cache": true,
  "torch_dtype": "float32",
  "max_length": 200
}

模型定位：

  • 优势是多语覆盖面广，一个模型可以支撑很多语言方向
  • 劣势是相较于 Marian 这种双语专用模型，推理更重、延迟更高
  • 更适合做索引翻译（离线 / 批量），不建议作为在线 query 翻译的默认方案

显存占用情况：

  • 600M 模型半精度（float16）权重约 ~1.25G；推理还会叠加 CUDA context、allocator reserve、激活张量、batch、输入/生成长度等开销
  • 当前这台 Tesla T4 上，优化后的实际运行峰值大约在 2.8-3.0 GiB

当前实现特点：

  • backend 类型：local_nllb
  • 运行时：CTranslate2 Translator
  • 支持多语
  • 调用时必须显式传 source_lang
  • 语言码映射定义在 <code>translation/languages.py</code>
  • 当前 T4 推荐配置：device=cuda、ct2_compute_type=float16、ct2_inter_threads=4、ct2_max_queued_batches=32、ct2_batch_type=examples、ct2_decoding_length_mode=source(+8,min=32)、batch_size=16、max_new_tokens=64

当前实现已经利用的优化：

  • 已做批量分块：translate() 会按 capability 的 batch_size 分批进入模型
  • 已切换到 CTranslate2 推理引擎：不再依赖 PyTorch generate()
  • 已设置方向控制：NLLB 通过 target prefix 指定目标语言
  • 已启用半精度：当前配置为 float16
  • 已关闭高开销搜索：默认 num_beams=1，更接近线上低延迟设置

和你给出的批处理示例对照：

  • 核心思路已经覆盖，现有实现与 tokenizer(batch) -> model.generate(...) -> batch_decode(...) 一致
  • 差异在于服务端额外做了语言校验、统一 chunking、输入长度约束和单条/批量 shape 保持
  • “预计算 attention mask” 目前没有单独缓存层；现状是每个 batch 在 tokenizer 阶段实时生成 attention_mask，这也是 HF 常规推理路径

优化空间（按场景）：

  • 线上 query：优先补测 batch_size=1 的真实延迟与 tail latency，而不是继续拉大 batch。
  • 离线批量：可再尝试更激进的 batching / 长度分桶 / 独立批处理队列（吞吐更高，但会增加在线尾延迟风险）。
  • 进一步降显存 / 提速：可在当前 CT2 方案上继续评估 int8_float16。

8.5 opus-mt-zh-en

实现文件：

模型信息：

  • Hugging Face 名称：Helsinki-NLP/opus-mt-zh-en
  • 本地目录：models/translation/Helsinki-NLP/opus-mt-zh-en
  • 当前磁盘占用：约 1.2G
  • 模型类型：Marian / OPUS MT 专用双语翻译模型
  • 方向约束：只支持 zh -> en

结构特点：

  • encoder-decoder Seq2Seq
  • 聚焦特定语言对
  • 模型更小、加载更轻、吞吐更高
  • 支持 Redis 翻译缓存

8.6 opus-mt-en-zh

实现文件：

模型信息：

  • Hugging Face 名称：Helsinki-NLP/opus-mt-en-zh
  • 本地目录：models/translation/Helsinki-NLP/opus-mt-en-zh
  • 当前磁盘占用：约 1.5G
  • 模型类型：Marian / OPUS MT 专用双语翻译模型
  • 方向约束：只支持 en -> zh

结构特点：

  • encoder-decoder Seq2Seq
  • 双语定向模型
  • 更适合中英双向拆分部署
  • 支持 Redis 翻译缓存

8.7 翻译缓存

  • 所有 translation capability 都使用统一的 Redis 缓存层
  • 每个 capability 通过各自的 use_cache 控制是否启用缓存
  • 缓存 key 格式固定为 trans:{model}:{target_lang}:{source_text[:4]}{sha256}

9. 本地模型安装与部署

9.1 准备环境

cd /data/saas-search
./scripts/setup_translator_venv.sh

9.2 下载模型

下载全部本地模型：

./.venv-translator/bin/python scripts/translation/download_translation_models.py --all-local

下载完成后，默认目录应存在：

models/translation/facebook/nllb-200-distilled-600M
models/translation/Helsinki-NLP/opus-mt-zh-en
models/translation/Helsinki-NLP/opus-mt-en-zh

9.3 打开能力

编辑 <code>config/config.yaml</code>，把对应模型的 enabled 改成 true。

9.4 启动服务

./scripts/start_translator.sh

建议：

  • 本地模型服务使用单 worker
  • 避免多 worker 重复加载模型
  • GPU 机器上优先使用 cuda + float16
  • CPU 只建议用于功能验证或离线低频任务
  • 对 NLLB，T4 上优先采用 batch_size=16 + max_new_tokens=64 + ct2_compute_type=float16 + ct2_inter_threads=4 + ct2_max_queued_batches=32 + ct2_batch_type=examples + ct2_decoding_length_mode=source(+8,min=32)

9.5 验证

健康检查：

curl http://127.0.0.1:6006/health

翻译测试：

curl -X POST http://127.0.0.1:6006/translate \
  -H 'Content-Type: application/json' \
  -d '{
    "text": "男士偏光飞行员太阳镜",
    "source_lang": "zh",
    "target_lang": "en",
    "model": "opus-mt-zh-en",
    "scene": "sku_name"
  }'

10. 性能测试与复现

说明：

  • 本节现有数值是 2026-03-18 的 Hugging Face / PyTorch 基线结果。
  • 切换到 CTranslate2 后需要重新跑一轮基准，尤其关注 nllb-200-distilled-600m 的单条延迟、并发 tail latency 和 opus-mt-* 的 batch throughput。

性能脚本：

数据集：

最新报告：

10.1 先看哪组数据

这里把 3 类结果分开看，不再混在一张表里：

  • batch_sweep 固定 concurrency=1，只比较不同 batch_size 的单流批处理性能
  • concurrency_sweep 固定 batch_size=1，看“单条请求”在不同并发下的延迟和吞吐
  • batch x concurrency matrix 同时看 batch_size 和 concurrency 的交互效应；本轮限制为 batch_size * concurrency <= 128

建议：

  • 看线上 query 翻译延迟：优先看 concurrency_sweep
  • 看离线批量翻译吞吐：优先看 batch_sweep
  • 看单 worker 服务容量边界：再看 batch x concurrency matrix

10.2 本轮补测参数

测试时间：2026-03-18

环境：

  • GPU：Tesla T4 16GB
  • Python env：.venv-translator
  • Torch / Transformers：2.10.0+cu128 / 5.3.0

统一参数：

  • cache：关闭（--disable-cache），避免缓存命中干扰性能结果
  • batch_sweep：每档 256 items
  • concurrency_sweep：固定 batch_size=1，每档 32 requests
  • batch x concurrency matrix：每档 32 requests，且只保留 batch_size * concurrency <= 128
  • 预热：1 batch

复现命令：

cd /data/saas-search
./.venv-translator/bin/python benchmarks/translation/benchmark_translation_local_models.py

本轮扩展压测复现命令：

cd /data/saas-search
./.venv-translator/bin/python benchmarks/translation/benchmark_translation_local_models.py \
  --suite extended \
  --disable-cache \
  --serial-items-per-case 256 \
  --concurrency-requests-per-case 32 \
  --concurrency-batch-size 1 \
  --output-dir perf_reports/20260318/translation_local_models

单模型扩展压测示例：

./.venv-translator/bin/python benchmarks/translation/benchmark_translation_local_models.py \
  --single \
  --suite extended \
  --model opus-mt-zh-en \
  --source-lang zh \
  --target-lang en \
  --column title_cn \
  --scene sku_name \
  --disable-cache \
  --batch-size-list 1,4,8,16,32,64 \
  --concurrency-list 1,2,4,8,16,64 \
  --serial-items-per-case 256 \
  --concurrency-requests-per-case 32 \
  --concurrency-batch-size 1

单条请求延迟复现：

./.venv-translator/bin/python benchmarks/translation/benchmark_translation_local_models.py \
  --single \
  --suite extended \
  --model nllb-200-distilled-600m \
  --source-lang zh \
  --target-lang en \
  --column title_cn \
  --scene sku_name \
  --disable-cache \
  --batch-size-list 1 \
  --concurrency-list 1,2,4,8,16,64 \
  --serial-items-per-case 256 \
  --concurrency-requests-per-case 32 \
  --concurrency-batch-size 1

10.3 单流 batch 结果

这组只看 concurrency=1，不要把这里的 request p95 当作线上并发请求的 p95。

nllb-200-distilled-600m zh -> en

Batch Items/s Avg item ms Req p95 ms
1 2.91 343.488 616.27
4 8.44 118.545 722.95
8 14.85 67.335 728.47
16 27.28 36.662 769.18
32 38.6 25.908 1369.88
64 58.3 17.152 1659.9

nllb-200-distilled-600m en -> zh

Batch Items/s Avg item ms Req p95 ms
1 1.91 524.917 866.33
4 4.94 202.473 1599.74
8 8.25 121.188 1632.29
16 13.52 73.956 1649.65
32 21.27 47.017 1827.16
64 32.64 30.641 2031.25

opus-mt-zh-en zh -> en

Batch Items/s Avg item ms Req p95 ms
1 6.15 162.536 274.74
4 15.34 65.192 356.0
8 25.51 39.202 379.84
16 41.44 24.129 797.93
32 54.36 18.397 1693.31
64 70.15 14.255 2161.59

opus-mt-en-zh en -> zh

Batch Items/s Avg item ms Req p95 ms
1 4.53 220.598 411.57
4 10.12 98.844 761.49
8 14.63 68.361 1930.85
16 24.33 41.1 2098.54
32 33.91 29.487 2152.28
64 42.47 23.547 2371.85

批处理结论：

  • 纯吞吐看，4 个方向的最佳 raw throughput 都出现在 batch_size=64
  • 如果还要兼顾单个 batch 的尾延迟，batch_size=16 往往更均衡
  • opus-mt-zh-en 是本轮 bulk 场景最快模型，nllb en->zh 最慢

10.4 单条请求并发结果

这组固定 batch_size=1，可以直接理解成“单条请求在不同并发下的表现”。

nllb-200-distilled-600m zh -> en

Concurrency Items/s Avg req ms Req p50 ms Req p95 ms
1 4.17 239.99 226.34 373.27
2 4.1 477.99 459.36 703.96
4 4.1 910.74 884.71 1227.01
8 4.04 1697.73 1818.48 2383.8
16 4.07 2801.91 3473.63 4145.92
64 4.04 3714.49 3610.08 7337.3

nllb-200-distilled-600m en -> zh

Concurrency Items/s Avg req ms Req p50 ms Req p95 ms
1 2.16 463.18 439.54 670.78
2 2.15 920.48 908.27 1213.3
4 2.16 1759.87 1771.58 2158.04
8 2.15 3284.44 3658.45 3971.01
16 2.14 5669.15 7117.7 7522.48
64 2.14 7631.14 7510.97 14139.03

opus-mt-zh-en zh -> en

Concurrency Items/s Avg req ms Req p50 ms Req p95 ms
1 9.21 108.53 91.7 179.12
2 8.92 219.19 212.29 305.34
4 9.09 411.76 420.08 583.97
8 8.85 784.14 835.73 1043.06
16 9.01 1278.4 1483.34 1994.56
64 8.82 1687.08 1563.48 3381.58

opus-mt-en-zh en -> zh

Concurrency Items/s Avg req ms Req p50 ms Req p95 ms
1 3.6 277.73 145.85 1180.37
2 3.55 559.38 346.71 1916.96
4 3.53 997.71 721.04 2944.17
8 3.51 1644.28 1590.93 3632.99
16 3.5 2600.18 2586.34 5554.04
64 3.52 3366.52 2780.0 7950.41

并发结论：

  • 当前本地 seq2seq backend 内部是单模型锁，单 worker 下提高客户端并发基本不会提升吞吐，主要会把等待时间堆到请求延迟上
  • 线上 query 翻译如果追求稳定延迟，应优先控制在低并发；8+ 并发后，4 个方向的 p95 都明显恶化
  • 在线场景里，opus-mt-zh-en 延迟最稳；nllb en->zh 最慢，且并发放大后尾延迟最明显

10.5 batch x concurrency 怎么看

完整矩阵见：

这张表主要回答两个问题：

  • 如果已经知道自己要跑离线批处理，batch_size 拉大后，在不同并发下吞吐会不会继续涨
  • 如果要拿单 worker 服务扛请求，在哪个 batch_size x concurrency 组合下开始明显排队

本轮矩阵的共同特征：

  • 吞吐主要由 batch_size 决定，concurrency 不是主要增益来源
  • 在 batch_size 固定时，concurrency 从 1 升到 2/4/8/...，items/s 变化很小，但 avg req ms / p95 会持续抬升
  • 因此当前实现更像“单 worker + 内部串行 GPU 推理服务”，不是一个靠客户端并发放大吞吐的服务

NLLB 性能优化经验：

  • 起作用的优化点 1：float16 + cuda
    • 当前本地 NLLB 由 CTranslate2 在 cuda:0 以 float16 运行
    • 优化后在 T4 上的峰值显存约 2.8-3.0 GiB
  • 起作用的优化点 2：batch_size=16
    • 相比 batch_size=8，吞吐提升明显
    • 继续提升到 32 虽然还能增吞吐，但 batch p95 和 batch max 会恶化很多
  • 起作用的优化点 3：ct2_inter_threads=4 + ct2_max_queued_batches=32
    • 对 batch=1 高并发商品标题场景收益最直接
    • 相比默认 CT2 配置，zh->en 和 en->zh 的在线吞吐都能稳定提升
  • 起作用的优化点 4：动态解码上限
    • 推荐 ct2_decoding_length_mode=source
    • 推荐 ct2_decoding_length_extra=8
    • 推荐 ct2_decoding_length_min=32
    • 这样可以保留 max_new_tokens=64 的安全上限，同时让短标题不再为长标题上限付费
  • 起作用的优化点 5：ct2_batch_type=examples
    • 在当前数据和 T4 上，比 tokens 更稳
    • 更适合作为线上默认
  • 不建议直接作为默认的实验：
    • max_new_tokens=48
    • 大 batch 和在线吞吐都会继续变好
    • 但商品标题 spot-check 已看到明显截断，尤其 en->zh
  • 收益有限或不稳定的实验：
    • ct2_batch_type=tokens
    • ct2_max_queued_batches 从 16 再继续拉高，收益很小
    • ct2_decoding_length_mode=source(+4,min=24) 更快，但仍有少量长标题截断风险

为什么最终没有采用其它方案：

  • 当前本地最优路径已经切到 CTranslate2 + float16
  • 对这个 600M 级 encoder-decoder 模型，T4 上最有效的是把 CT2 的并行和解码策略调对
  • 因此这轮没有继续引入更重的服务化栈
  • 如果未来目标变成“继续压缩显存”或“进一步追求更低延迟”，再评估 int8_float16 或服务级微批处理队列会更合适

关键结论：

  • 当前机器上，opus-mt-zh-en 是三个新增本地模型里最快的
  • opus-mt-en-zh 大约是 opus-mt-zh-en 吞吐的一半
  • nllb-200-distilled-600M 在 T4 上推荐 cuda + CTranslate2 float16 + batch_size=16 + ct2_inter_threads=4 + ct2_max_queued_batches=32 + dynamic decoding
  • nllb 最终可用，但吞吐仍明显低于两个 Marian 模型，更适合多语覆盖或独立资源环境

最终推荐部署方案：

  • 模型：facebook/nllb-200-distilled-600M
  • 设备：cuda
  • 精度：float16
  • 推荐卡型：至少 Tesla T4 16GB 这一级别
  • 推荐 batch：16
  • 推荐 max_input_length：256
  • 推荐 max_new_tokens：64
  • 推荐 num_beams：1
  • 推荐 CT2 并行：ct2_inter_threads=4
  • 推荐 CT2 队列：ct2_max_queued_batches=32
  • 推荐 CT2 batch 类型：examples
  • 推荐动态解码：ct2_decoding_length_mode=source、ct2_decoding_length_extra=8、ct2_decoding_length_min=32
  • 运行方式：单 worker，避免重复加载

更详细的性能说明见：

11. 开发说明

如果要新增翻译 backend，最少需要做这些事：

  1. 在 <code>translation/backends/</code> 下新增实现
  2. 在 <code>translation/service.py</code> 注册 backend 创建逻辑
  3. 在 <code>config/config.yaml</code> 的 services.translation.capabilities 中新增 capability 配置
  4. 如果有新的静态规则：

原则：

  • 不要再引入 translation provider 兼容层
  • 不要把 scene / prompt / 语言方向规则重新散落到别的目录
  • 不要在代码里写隐式默认和静默兼容

12. 常见建议

  • 中英商品标题双向场景，优先考虑 opus-mt-zh-en 和 opus-mt-en-zh
  • 多语种统一方案，可以考虑 nllb-200-distilled-600M
  • 但 nllb 更适合独占资源环境
  • 如果追求更高质量或更复杂语义处理，可使用 qwen-mt 或 llm
  • 如果追求稳定商业 API，可考虑 deepl

13. 相关文档