# Index-Translate is a model family, and the 35B-A3B preview is a mixture of experts with an OpenAI compatible endpoint

> Bilibili's Index-Translate ships four related model families on a Qwen3.5 base, from a 2B text model to a 35B-A3B mixture of experts, plus a hosted free API. The naming is the first obstacle: Index-Translate, Index-Echo, Index-Homura and Index-NativeLong are different things with different maturity.

**bilibili/Index-Translate** — A Multilingual, Multimodal Translation Model Family

- Repository: https://github.com/bilibili/Index-Translate
- Website: https://index-translate.bilibili.com
- Stars: 1,973 · Forks: 53
- Language: Python
- License: Apache-2.0
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/bilibili-index-translate

## Four names, four different problems

The repository is a model family rather than a single model, and the four names in it do different jobs.

Index-Translate covers text and multimodal vision. It handles text translation across 150 languages and adds image translation through a native vision encoder with zero external OCR dependency, along with structured content handling, hard and soft instruction following, and what the README calls community expressions.

Index-Echo is audio and speech: end-to-end speech to subtitles, which it calls S2TT, and cross-lingual voice-cloned dubbing, S2ST, which is described as preserving the source speaker's voice characteristics while translating. So the output is a translated voice that still sounds like the original speaker, which is a harder requirement than translating the words.

Index-Homura is controlled dubbing. It dynamically adjusts the translation to fit a specified target syllable budget, which is the mechanism for aligning translated speech to the original timing.

Index-NativeLong is the long document model, supporting long-context input for complete documents while maintaining term and character name consistency across paragraphs.

The TODO section makes the maturity split explicit. Merging audio, video and long document translation into one main model is unchecked. Adding more languages to Index-Echo-S2ST is unchecked. Scaling out to 100B and above is unchecked. Only the quantized builds and the benchmark data are marked done.

## Three text sizes, and one of them is a mixture of experts

The released checkpoints are 2B, 9B and 35B-A3B, with the last one marked as a preview.

The naming A3B in 35B-A3B is the mixture of experts convention: 35B total parameters with about 3B active per token. That matters operationally. Memory footprint tracks the total, while compute per token tracks the active parameters, so a 35B-A3B needs the memory of a 35B model and runs closer to the speed of a much smaller one. If you size a deployment by parameter count alone you will get this wrong in one direction or the other.

All three are published on both Hugging Face and ModelScope under the IndexTeam organisation, with a separate link per size, and the 35B preview has an extra link pointing at the free API section.

The base matters too: the family is built on Qwen3.5, which is why the checkpoints are usable as general models as well, and why the tokenizer and context behaviour are inherited rather than designed here.

The README is explicit that evaluation results for these checkpoints are in the comparison tables in docs/evaluation.md, so the right place to judge a size is that document rather than the model card summary.

## Quantized builds for two different serving stacks

The 2026-10-03 news entry covers the release of official quantized builds across the family on Hugging Face and ModelScope, and the two targets are distinct.

GGUF is for llama.cpp local inference, including visual mmproj weights for the image translation path. So the local path is a single binary runtime with a weight file per model plus a projector for vision.

FP8 at W8A8 is for vLLM serving. NVFP4 at W4A4 is described as Blackwell-optimized, which means the 4-bit path targets that hardware generation specifically rather than being a general low precision format.

That distinction is the practical selection rule. If you are running one model on a workstation or a laptop, GGUF is the route. If you are serving to several concurrent clients, FP8 through vLLM is the route, and NVFP4 is the route only if you have the hardware it was built for.

The GGUF and mmproj point also connects to the image translation announcement: the 2026-10-10 entry states that the free public API, the web demo, the Python script and the GGUF mmproj weights all support image input with no external OCR dependency, so a local image translation path does not need a separate OCR stage.

## The free API is OpenAI compatible, which makes it the fastest way to evaluate

The README leads with a free public API, and the compatibility claim is the useful part.

The endpoint is https://index-translate.bilibili.com/v1, it is described as fully OpenAI compatible, and it serves Index-Translate-35B-A3B with zero GPU setup. That means you can evaluate the largest checkpoint, including the preview, without provisioning anything, which is the opposite of the usual situation where you evaluate the smallest model and discover the big one behaves differently.

The one-line test in the README is:

```bash
python inference/llm/call_api.py "Hello, world!" --target zh
```

The script path tells you it is a Python client checked into the repository under inference/llm/, with its own README, and it now also accepts image input.

Two things to keep separate. The public API serves the 35B-A3B preview, which is the model the README flags as a preview, so it is an evaluation convenience and not a stability guarantee. And a hosted endpoint at a vendor domain is a dependency on someone else's service for anything you build on it.

There is a web demo linked at the same domain, and the release history shows the API going live on 2026-10-04, four days before the image translation support was added to it.

## Instruction following is treated as a first class capability

Translation quality is the obvious axis, and the README spends its evaluation section on a different one.

The models follow translation instructions covering terminology, formatting and content-preservation requirements, and the description distinguishes hard from soft instruction following. A hard instruction is one where violating it makes the output wrong, such as keeping a term untranslated or preserving a given format. A soft one is a preference.

The benchmark picture follows from that. The radar chart in the README compares 35B-A3B preview, 9B and 2B across seven axes: WMT, FLORES, instruction following, low-resource translation, subtitles, MEME, and books/fiction. Instruction following is scored by averaging instTrans and the IFMTBench IFscore.

Two cautions about the chart are stated in the README and worth repeating. The normalized scale is not an accuracy percentage, so an axis position does not mean a percentage of correct translations. And the gray dashed line combines the best non-Index score on each axis, which means it does not represent one model and cannot be compared to a single series.

The low-resource axis is the one to look at if you work outside high-resource language pairs, since that is where a general purpose model tends to fall apart and where a dedicated translation family has a reason to exist.

## Benchmarks, papers and the rest of the repository

The project publishes its evaluation artefacts rather than only its conclusions, which is unusual and useful.

Four Index-Translate benchmarks were released on 2026-10-04, with datasets and metadata on Hugging Face and the evaluation scripts and guides on GitHub. The benchmarks directory and the benchmarks section of the README name instTrans, MEME, SandGlass and NAtIveLong as released data with evaluation code. Raw per-category scores are published as a CSV alongside the figure, and the README links figure notes and individual benchmark results in docs/.

Papers are published too: a technical report, an arXiv entry, and separate Hugging Face collections for papers and for benchmarks.

The repository layout is small. There is a docs/ directory holding evaluation results and the image translation tutorial, inference/ for the API script and the LLM inference guide, benchmarks/, an extension/ directory, a video-dub/ directory, a run_proxy_windows.bat file for the local proxy path, and README.md alongside README_zh.md for the Chinese version of the same document.

Licence is Apache-2.0 in the LICENSE file. The default branch is main, the last push was on 2026-10-14, the repository is not archived, and there are no GitHub releases, so the version record is the news list in the README and the checkpoints themselves. The homepage is index-translate.bilibili.com.

## Conclusion

Adopt the 2B or 9B Index-Translate checkpoints when you need translation that follows terminology and formatting instructions across many languages and you want to run it locally through GGUF or vLLM. Do not adopt the 35B-A3B as a stable base, since the README marks it a preview. Verify first which release you are downloading, because the family's own naming gives no hint that a checkpoint is a preview, and check the quantization you need against your hardware, since FP8 W8A8 and NVFP4 W4A4 are aimed at different serving stacks.

## FAQ

### How many languages does Index-Translate support?

The text models cover 150 languages, and follow translation instructions covering terminology, formatting and content preservation requirements. Index-Echo-S2ST has a packaged script for zh to en, ja and es, and the README lists adding more languages to it as unfinished work.

### What is the difference between Index-Translate, Index-Echo, Index-Homura and Index-NativeLong?

Index-Translate covers text and image translation across 150 languages, Index-Echo covers speech to subtitles and voice-cloned dubbing, Index-Homura adjusts translations to a target syllable budget for timing, and Index-NativeLong handles long documents with consistent terms and character names.

### How do I run Index-Translate locally?

Use the official quantized builds on Hugging Face or ModelScope. GGUF is for llama.cpp local inference including visual mmproj weights, FP8 W8A8 is for vLLM serving, and NVFP4 W4A4 is described as Blackwell-optimized.

### What is the free API endpoint for Index-Translate?

https://index-translate.bilibili.com/v1, described as fully OpenAI compatible, serving Index-Translate-35B-A3B with zero GPU setup. The repository ships a Python client at inference/llm/call_api.py, and image input is supported through the API, the web demo and the GGUF mmproj weights.

### Does Index-Translate need OCR for image translation?

No. The README states native support for multimodal image translation through a vision encoder with zero OCR dependency, across the 2B, 9B and 35B-A3B models, and that support was added to the family on 2026-10-10.

## Sources

- [bilibili/Index-Translate on GitHub](https://github.com/bilibili/Index-Translate)
- [Issues](https://github.com/bilibili/Index-Translate/issues)
- [License: Apache-2.0](https://github.com/bilibili/Index-Translate/blob/main/LICENSE)
- [Project website](https://index-translate.bilibili.com)
- [README](https://github.com/bilibili/Index-Translate/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/bilibili-index-translate