尝试使用Index翻译模型
内容提要
作者测试了B站Index翻译模型（2B/9B量化版及官方35B-A3B API），发现模型对提示词高度敏感，中文及Hy风格提示词得分更高，9B效果有时反低于2B。vLLM部署需设temperature=0并加frequency_penalty以防重复死循环，输出超1k易丢失换行。官方API速度快，但日文小说翻译仍不及Hy-MT2-30B-A3B。作者据此选择：沉浸式翻译用Index官方API，小说翻译继续用Hy-MT2。
延伸解读
提示词敏感性与模型规模的反常
作者测试发现，Index模型对提示词高度敏感：中文提示词得分远高于英文，且Hy风格提示词优于Index官方示例。更反常的是，9B量化模型在多个测试中BLEU分数低于2B模型，说明模型规模增大未必带来更好效果，提示词适配可能比参数量更关键。
部署参数对稳定性的影响
使用vLLM部署时，未设temperature=0会导致BLEU分数剧烈波动，甚至低至12.95；而模型可能陷入“啊啊啊”的死循环。开启frequency_penalty=0.4可解决该问题，0.1~0.8区间均有效。LM Studio因默认repetition_penalty=1.1而未暴露此问题，提示部署工具默认参数差异需留意。
输出长度与模型退化风险
作者实测发现，2B级别模型输出超过1k tokens后常丢失换行，内容挤成一段；超过2k后，即使换用其他模型也易在连续拟声词处陷入死循环。官方API的35B-A3B模型同样无法避免拟声词退化。这提示长文本翻译需控制输出长度，或对拟声词密集内容保持警惕。
官方API的速度与效果权衡
官方API初期速度达120 tokens/s，远快于本地小模型，但限制调整后速度降至40 tokens/s。效果上，沉浸式翻译场景优于Hy-MT2-7B但不及Hy-MT2-30B-A3B；日文小说翻译仍不如后者。作者据此分场景选用：沉浸式翻译用Index官方API兼顾速度与资源，小说翻译继续用Hy-MT2-30B-A3B。
Q&A
Index翻译模型对提示词敏感吗？用哪种提示词效果更好？
非常敏感。测试显示，使用中文提示词的BLEU分数远高于英文提示词；使用Hy风格示例的提示词分数也高于Index官方示例的提示词。
用vLLM部署Index-2B模型时，如何避免翻译陷入死循环？
需要设置temperature=0，并开启frequency_penalty（0.1~0.8均可，推荐0.4）或repetition_penalty=1.1，以防止模型在翻译时陷入“啊啊啊”的死循环。
Index-9B模型的效果一定比2B好吗？
不一定。测试中9B模型的BLEU分数经常低于2B模型，作者也感到奇怪，说明模型大小与效果并非简单正相关。
Index官方API的速度和限制如何？
官方API速度很快，可达120 tokens/s，但限制经过调整：最初max_tokens=4096，后来output_tokens=2048，写稿时为4096但速度降至40 tokens/s。
Index模型在翻译长文本时有什么问题？
官方建议输出tokens控制在1k以内，超出后经常无法保持换行，后续内容挤到一段；即使35B模型也避免不了连续拟声词退化的情况。
作者最终如何选择Index和Hy-MT2模型？
沉浸式翻译使用Index官方API（速度快、不占本地资源）；小说翻译继续使用Hy-MT2-30B-A3B模型（效果更好），通过LM Studio自动加载和卸载。
