2026 年 9 月 30 日，B站（哔哩哔哩）Index LLM 团队正式开源 Index-Translate 系列翻译模型：权重挂在 Hugging Face 的 IndexTeam 组织下，同步上架 ModelScope，GitHub 仓库为 bilibili/Index-Translate，附带技术报告与在线 demo。许可证是 Apache-2.0，由 Hugging Face 模型卡的 license 标签直接确认——权重可自由下载、修改、商用。一个以弹幕和字幕起家的视频平台下场做翻译模型，乍听像跨界，但把场景逻辑拆开看相当顺：视频平台每天都在处理海量跨语言内容分发，字幕、标题、评论、配音，哪一环都绕不开翻译。本文把家族构成、三分支能力、受控翻译机制、官方自报分数怎么读、本地怎么跑一次讲清。想横向了解另一类开放权重模型的资源帖，可参考 DeepSeek-V4-Flash-Vision-Exp 开源发布。
一、先说结论：它是什么、有多大、怎么拿
先把最关键的事实摆在最前面。
Index-Translate 家族目前有三个尺寸的文本模型：2B、9B 和 35B-A3B-preview，基于阿里 Qwen3.5 构建，官方自报支持 150 种语言。主力是 35B-A3B-preview：MoE 架构，总参数 35B，每次推理只激活约 3B，上下文窗口 262,144 token。三个尺寸覆盖了从端侧小任务到服务器级批量处理的完整区间，按硬件条件选档即可，不是「要么顶配要么不玩」。
获取路径有三条：Hugging Face（IndexTeam）、ModelScope、GitHub（bilibili/Index-Translate）。仓库里除了权重，还有技术报告和在线 demo，想先验效果再决定下载的，直接用 demo 试。许可证 Apache-2.0，对想做商用产品的团队，这是比「能不能跑」更重要的信息：没有授权费和许可条款的坑。
需要提前打好的预防针是：本文引用的所有基准分数都来自官方自报，暂无第三方独立复现。这不代表数字有问题，而是读法问题，第六节专门讲。
二、视频平台做翻译模型，场景上说得通吗
翻译赛道上已有通用大模型，B站为什么还要自己做一个？答案藏在它自己的业务里。
视频平台的翻译需求有几个和通用对话模型不同的特点。第一是量大且碎片化：一个热门视频的字幕动辄几千条，标题、简介、评论区加起来是持续不断的长尾流量，用通用旗舰模型逐句处理，成本结构撑不住。第二是对格式纪律要求极高：字幕文件、游戏公告、结构化数据，翻译时格式坏一个字段就是事故。第三是配音这个特殊场景：不是把文字翻对就行，还要念出来，要卡时长、保音色。这三件事恰好都不是通用模型的强项，而是需要专门调教的方向。
所以 B站做翻译模型不是猎奇，而是把自家最日常的痛点抽出来做成产品。而这些痛点也是内容平台、出海团队、游戏厂商共同拥有的——这正是开源的价值：把复现成本几乎归零地交给所有有同样需求的人。
三、家族三分支：Echo、Homura、NativeLong 各管一段
除了 2B / 9B / 35B 的尺寸线，家族还有三个能力分支，对应三类真实场景。
Index-Echo 管配音链路。它做语音到语音的翻译（speech-to-text-to-speech），支持中文与英语、西班牙语、日语互译，最大卖点是保留说话人音色——一个 UP 主的视频译成西班牙语后，听起来还是他本人的声音。对做出海频道的创作者，这直接省掉找配音演员或做声音克隆的工序。
Index-Homura 管音节数控制。配音和字幕最难缠的问题是对轨：译文念出来的时长必须和原音频对得上。Index-Homura 能控制译文音节数，官方数字是：9B 版本在 SandGlass 测试里，81.92% 的输出落在目标音节的 ±10% 区间内。这个数字同样是官方自报，但它指向的能力——译文长度可控——是配音流水线上实打实的刚需。
Index-NativeLong 管长文档一致性，社区昵称 Index-Nailong。官方展示的例子：一篇 3.2 万 token 的幻想文本，人名、王衔双关从头到尾翻译一致；作为对照，逐块翻译的 9B 版本会出现漂移。长篇翻译最容易翻车的是前后不一致——同一个专有名词第三章换了译法，读者立刻出戏。
三个分支加三个尺寸，产品思路很清晰：通用翻译交给文本模型，配音、对轨、长文档这些专项活儿由分支接手。
四、35B-A3B：MoE 与 262K 上下文意味着什么
35B-A3B-preview 的架构值得单独讲，因为它的数字组合对部署成本影响很大。
MoE（混合专家）的直觉是「总参数管知识量，激活参数管算力账单」。35B 的总参数给它足够容量装下 150 种语言的语言学知识，而每次推理只激活约 3B，意味着推理速度和显存占用更接近 3B 模型而非 35B 全量模型。翻译这种高频、批量、逐条处理的任务，恰恰最吃「单条成本低」——一天翻几十万条字幕的场景里，激活参数的差异会直接换算成电费和卡时。
262,144 token 的上下文窗口则对着长文档场景去。配合 NativeLong 的一致性能力，整本轻小说、整季字幕一次性喂进去成为可能，不需要人为切块再拼接——切块翻译正是漂移的来源之一，上下文越长，模型看到的前文越完整，一致性越有保障。
长上下文和输出容量的对比可参考站内的 百万 token 输出横评，那里从「一次能吐多少」的角度评测了几款模型，和本文「一次能读多少」正好互补。
五、受控翻译：硬约束与软约束
这是这套模型最有工程味道的部分，官方叫 instTrans（受控翻译），分硬约束和软约束两层。
硬约束是必须遵守、违反即失败的要求，两类：一是术语表强制，比如约束里写「碳纤维:carbon fiber」，译文就必须用 carbon fiber，不允许模型自作主张换同义词——这对游戏本地化、医疗、法律文书是生死线；二是结构保留，JSON、CSV、代码、占位符翻译后必须原样保住。官方项目页的例子很直观：9B 模型把一份 JSON 格式的游戏维护公告译成韩语，字段结构和一个 hashtag 都完好无损。做过本地化的都知道，传统机翻在这类任务上最常翻车的就是格式：一个引号配错，整份文件就废了。
软约束是风格层面尽量满足的要求：语气风格匹配、领域消歧、跨句一致性、LaTeX 保留。领域消歧的典型是 plant——农业语境是「植物」，工业语境是「工厂」，按上下文选对。跨句一致指同一术语在相邻句子里保持同一译法，不出现前文「缓存」后文「快取」式的漂移。
硬软分层的工程价值在于可验收：硬约束可以写成自动化断言测试，软约束人工抽检。把「翻译质量」从玄学变成一组可检查的条目，这比单纯刷分实用。
六、分数怎么看：官方自报，以及那个更高的 83.55
官方公布的基准数字包括：FLORES COMET-22 得分 0.8794，WMT26 Judge 得分 76.76，受控翻译 instTrans 的 IFscore 0.8336，低资源语言的 FLORES COMET-22 得分 0.8168，低资源 off-target 率 2.4%；9B 版本低资源指令跟随 0.7725，off-target 率 3.47% 是对比模型中最低。
读这些数字前先立规矩：全部是官方自报，暂无第三方独立复现。测试集、解码参数、判分口径都出自发布方自己，读者要清楚分量——它证明的是「官方认为这个模型达到了什么水平」，而不是「独立实验室验证它达到了什么水平」。
更要诚实指出：在官方自己给出的同一张表格里，DeepSeek-V4.1-Flash 的 WMT26 Judge 分数是 83.55，高于 Index-Translate 的 76.76。也就是说单看这一项，它不是全表第一。这不是挑刺，而是官方表格里白纸黑字的对照。正确读法是：翻译质量这一项它还没登顶，但卖点是组合拳——受控翻译、音节控制、音色保留、MoE 低成本推理、Apache-2.0 商用自由度，加在一起构成性价比而非单项碾压。如果你的场景就是纯文本翻译的极限质量，DeepSeek 那条线值得同时纳入对比，可参考站内的 DeepSeek V4.1 开源热点解读。
一句话总结：把自报分数当量级参考，把组合能力当决策依据，等第三方复现出来再回填结论。
七、本地跑起来：GGUF 与一行命令
官方已放出 GGUF 量化版，仓库为 IndexTeam/Index-Translate-35B-A3B-preview-GGUF，推荐档位 Q4_K_M，文件大小 21.71GB。官方还做了量化质量校验：在 A100 上对 F16 权重做 KL 散度比对，说明这个档位不是拍脑袋给的。
跑起来只需一行命令（前提是装好 llama.cpp）：
llama serve -hf IndexTeam/Index-Translate-35B-A3B-preview-GGUF:Q4_K_M这条命令会自动从 Hugging Face 拉取 Q4_K_M 量化权重并起本地服务。21.71GB 的体积意味着一张 24GB 显存的消费级显卡能轻松装下，甚至纯 CPU 加大内存也能跑，只是慢一些——这正是「35B 只激活 3B」在部署侧兑现的红利。
调用提示词模板很简单：「请将以下文本翻译为{目标语言}，直接输出翻译结果，不要进行任何解释」，同时把 chat template 里的 enable_thinking 设为 false，temperature 设为 0。三件事要配套：不开思考保证响应速度，温度为零保证同一输入得到稳定译文，批量生产场景里「稳定」比「偶尔惊艳」重要。
接入自己应用的过程与接入其他 OpenAI 兼容本地模型一致，套路可参考站内的 DeepSeek V4.1 接入 SOP，把端点换成 llama.cpp 本地地址即可。
八、浏览器扩展与配音 pipeline
除了命令行，官方还配套了两个面向真实使用姿势的工具。
一个是浏览器扩展：把本地模型接进浏览器，网页内容直接用你自己的权重翻译，不经过任何第三方 API。对在意数据隐私的团队和不想为翻译量付费的个人用户，这是能立刻用起来的形态。
另一个是视频配音 pipeline：把 Echo 的音色保留、Homura 的音节对轨串成完整流水线，输入一条原始视频，输出带目标语言配音的字幕成品。对出海创作者，这基本等于把「翻译组 + 配音棚」压缩成一段脚本。
官方还公布了后续计划：35B-A3B 正式版（目前的 preview 只是开胃菜）、开源基准、Echo 加语言、更大模型。preview 版就已把工具链铺到这个程度，正式版值得持续观察。
主攻搜索词
围绕这篇内容，读者最常搜的三个问题在这里集中回答。
b站开源翻译模型怎么本地跑：装好 llama.cpp 后执行 llama serve -hf IndexTeam/Index-Translate-35B-A3B-preview-GGUF:Q4_K_M，自动下载 21.71GB 的 Q4_K_M 量化权重并启动本地服务；调用时用官方提示词模板并关闭 thinking、温度设 0。详见第七节。
开源翻译模型能替代商用api吗：分场景。批量、结构化、对成本敏感的翻译（字幕、公告、文档），Apache-2.0 本地部署在成本和隐私上有明显优势；但纯文本翻译质量的榜单分数上，官方表格里 DeepSeek-V4.1-Flash 更高，且官方自报分数暂无第三方复现。稳妥结论：高频量产场景可以替代，极限质量场景两条线都测。
index-translate 怎么下载：三条路——Hugging Face 的 IndexTeam 组织、ModelScope、GitHub 的 bilibili/Index-Translate 仓库。GGUF 量化版在 Hugging Face 仓库的 Q4_K_M 档位，下载后用 llama.cpp 直接加载。
FAQ
Q1： Index-Translate 是什么许可证，能商用吗？ A1： Apache-2.0，由 Hugging Face 模型卡的 license 标签确认。这是最宽松的主流开源许可证之一，允许下载、修改、商用，只需保留许可声明，对接入自家产品没有授权费障碍。注意目前 35B 版本还是 preview，正式版在官方后续计划里，商用落地前建议关注版本状态。
Q2： 「只激活 3B」对实际使用意味着什么？ A2： MoE 架构下总参数 35B 决定知识容量，每次推理激活约 3B 决定推理成本。效果是：推理速度和显存压力接近 3B 级小模型，却保有 150 种语言的语言学知识。落到部署上，Q4_K_M 量化后 21.71GB，一张 24GB 显卡就能装下；落到生产上，批量翻译场景的单条成本优势会被规模放大。
Q3： 三个分支 Index-Echo、Index-Homura、Index-NativeLong 分别解决什么问题？ A3： Echo 管配音，语音到语音翻译且保留说话人音色，支持中英、中西、中日互译；Homura 管对轨，控制译文音节数，官方自报 9B 版本在 SandGlass 测试中 81.92% 的输出落在目标音节 ±10%；NativeLong（又名 Index-Nailong）管长文档一致性，官方展示的 3.2 万 token 幻想文本中人名与王衔双关全程统一，逐块翻译的普通 9B 会漂移。
Q4： 官方公布的分数可信吗？它是不是翻译质量第一？ A4： 所有分数（FLORES COMET-22 0.8794、WMT26 Judge 76.76、instTrans IFscore 0.8336 等）都是官方自报，暂无第三方独立复现，当量级参考看即可。另外要如实说明：同一张官方表格里，DeepSeek-V4.1-Flash 的 WMT26 Judge 83.55 高于它的 76.76，纯文本翻译质量它并非全表第一。竞争力在组合拳：受控翻译、音节控制、音色保留、低成本推理加 Apache-2.0 商用自由。
Q5： 硬约束和软约束在受控翻译里怎么用？ A5： 硬约束是违反即失败的规则，包括术语表强制（如「碳纤维:carbon fiber」必须译作指定词）和 JSON、CSV、代码、占位符等结构原样保留，可写自动化测试验收；软约束是风格层要求，包括语气匹配、领域消歧（plant 在工业语境译「工厂」）、跨句一致、LaTeX 保留，靠人工抽检。生产环境建议两层都配：硬约束兜住格式底线，软约束管阅读体验。
参考来源
- Hugging Face 模型卡 IndexTeam/Index-Translate-35B-A3B-preview-GGUF——GGUF 量化档位、Q4_K_M 21.71GB 推荐与 A100 上对 F16 的 KL 散度校验。
- Hugging Face Index-Translate 系列模型卡 license 标签——Apache-2.0 许可证的确认来源。
- GitHub 仓库 bilibili/Index-Translate 与官方技术报告——家族构成（2B / 9B / 35B-A3B-preview）、150 种语言口径、三分支说明、受控翻译 instTrans 的硬软约束定义、浏览器扩展与配音 pipeline、后续计划。
- 官方公布的基准表——FLORES COMET-22 0.8794、WMT26 Judge 76.76、instTrans IFscore 0.8336、低资源 FLORES COMET-22 0.8168、低资源 off-target 2.4%、9B 低资源指令跟随 0.7725 与 off-target 3.47%，以及同表 DeepSeek-V4.1-Flash 的 WMT26 Judge 83.55 对照；全部为官方自报口径，暂无第三方独立复现。
- 官方项目页示例——9B 译 JSON 游戏维护公告保留结构与 hashtag；Index-NativeLong 的 3.2 万 token 长文一致性演示；Index-Homura 在 SandGlass 测试 81.92% 落于目标音节 ±10%。
- 本文关于场景合理性的分析与选型建议为编者推断，已在正文标注，不属于官方来源。
本文由 AI 辅助生成，经人工审核编辑。