先说清楚：为什么不用通用大模型翻就行

翻译质量分两层。一层是「句子像不像人话」，通用大模型这层已经做得不错；另一层是「术语和格式守不守规矩」，这一层才是企业文档、字幕、游戏本地化真正会出事的地方——同一个术语在第三页叫「调度器」、第九页变成「排程器」，或者一段代码块在翻译里被拆开，人眼很难逐条查出来。

Index-Translate 这类专有翻译模型的价值在后一层：它接受指令，可以把术语表、目标格式、输出长度当成约束一起给进去。所以这篇的目标不是「翻得比大模型好」，而是「把可控的部分自己攥住，并且能验证」。

如果你的文档术语不多、格式也不复杂，通用模型加一段提示词就够用；这篇讲的是「术语多、格式混、还要能验收」的场景。

前提：一张够用的卡，或者先用小模型试流程

Index-Translate 家族有 2B、9B 和 35B-A3B（MoE，每 token 只激活约 3B）几个尺寸。整条流程先用 9B 跑通最省事，确认验收脚本好用之后，再换成 35B-A3B 提升质量——MoE 的好处是激活参数少，但权重还是要装得下，显存预算按权重体积算，别只按激活参数估。

  • 流程验证：任意一张能跑 9B 的卡即可
  • 上生产：按 35B-A3B 的权重体积准备显存，或用官方支持的服务框架做量化部署
  • 别在笔记本上硬扛 35B：先跑通流程，再决定要不要换机器

第一步：把服务跑起来，先translate一句

仓库自带推理脚本，先确认环境能通、模型能加载。这一步不要急着上文档，先用一句带专有名词的短句，看看它默认的输出长什么样。

git clone https://github.com/bilibili/Index-Translate.git
cd Index-Translate
pip install -r inference/llm/requirements.txt

# 先用小尺寸跑通链路
python inference/llm/translate.py \
  "把这条调度指令下发到边缘节点。" --target en \
  --model IndexTeam/Index-Translate-9B

如果这一步报错，先解决环境问题（运行时是否支持 Qwen3.5 的 MoE、权重分片是否下全），别带着环境问题去调提示词——分不清是模型没听懂还是服务没起来，后面全是无用功。

第二步：把术语表和格式要求变成指令

这是整篇最关键的一步。术语表不要写成一段散文，要写成「原文词条 → 目标语言词条」的对照，并且明确它优先级最高、出现时必须照用。格式要求要具体到「保留 Markdown 标题层级」「代码块不翻译」「表格行列不合并」，而不是「保持格式」这种说了等于没说的要求。

术语表（最高优先级，出现必须照用）
- 调度器 -> Scheduler
- 边缘节点 -> edge node
- 灰度发布 -> canary release

格式要求
- 保留 Markdown 标题层级与代码块，代码块内容不翻译
- 表格的行列结构不变
- 段落的编号与项目符号保持一一对应
- 输出长度不超过原文的 1.3 倍

把这段作为「翻译指令」跟正文一起送进去——这正是这类模型与通用模型拉开差距的地方：约束是接口的一部分，而不是靠你在提示词里反复强调。

第三步：处理一整篇文档，按块切而不是整篇灌

长文档不要一次性丢进去。按语义分块（按标题层级切最好），每块单独翻，块与块之间共享同一份术语表与格式要求。这样做的好处是失败可定位：某一块出问题，重跑那一块就行，不用整篇重来。

  • 按标题切块，保留块之间的层级关系，拼接时按原顺序还原
  • 每块记录「输入哈希 → 输出」，重跑时命中缓存直接复用
  • 块大小控制在模型上下文的一小部分，给术语表和格式要求留位置

第四步：用脚本查「术语有没有守住」，而不是人读一遍

验收要自动化，否则「看起来没问题」会一直蒙混过去。最小可用的检查就两条：术语表里的每个词条，在译文里必须出现指定的译法；原文里的代码块、表格、编号，在译文里数量与顺序必须一致。这两条都能用几十行脚本跑出来。

# 伪代码：术语一致性与结构完整性检查
for src, dst in glossary:
    if dst not in translated_text:
        fail("术语缺失或译法不一致", src, dst)

assert count_blocks(original, "code") == count_blocks(translated, "code")
assert count_items(original, "ordered-list") == count_items(translated, "ordered-list")

跑完会得到一张表：哪几个术语没守住、哪一处结构对不上。这张表比「读一遍觉得还行」有用得多——它可复跑、可比较，下一版模型或换一份术语表时能直接对照。

第五步：把检查接进流程，并说清什么时候不该用它

把第四步的检查脚本放进每次翻译之后自动跑，失败就标红、不通过不交付。这样术语表才是活的——它不是因为「写得很认真」而有效，而是因为不通过就发不出去。

也要知道它的边界：涉及法律、医疗、合同这类不能出错的内容，机器翻译只能当草稿；模型报出的「翻译质量分」是它自己尺子量出来的，不能替代你们的验收标准；另外，把术语表喂给一个不在你自己机器上跑的服务之前，先确认术语本身是不是敏感信息——本地部署的价值有一半在这里。

一句话总结：翻译这件事里，「句子通不通」交给模型，「术语与格式守没守住」交给脚本。两件事分开做，你才知道出了问题该改哪一层。