feat: add DISTILUSE_BASE_MULTILINGUAL_CASED_V2 text embeddings model

[msluszniak]

Description

Addresses the multilingual half of #945 by shipping the first multilingual text embeddings model, distiluse-base-multilingual-cased-v2, covering 50+ languages at 512 embedding dims.

The paraphrase-multilingual-MiniLM-L12-v2 model from the same issue is deferred — its tokenizer pipeline is Unigram + Precompiled normalizer + Metaspace decoder, and executorch/extension/llm/tokenizers (the C++ lib RNE links) only supports BPE + WordPiece + BertNormalizer. Unigram support is in flight upstream; we'll ship paraphrase-multilingual in a follow-up once the runtime picks it up.

What the diff does:

• modelUrls.ts — adds DISTILUSE_BASE_MULTILINGUAL_CASED_V2 (XNNPACK fp32), _8DA4W (XNNPACK 8-bit dynamic-act / 4-bit weight via torchao), _COREML_FP32, and _COREML_FP16 pointing at the new HF repo under NEXT_VERSION_TAG (= resolve/v0.9.0), and registers all four in MODEL_REGISTRY.ALL_MODELS. Files are uploaded under xnnpack/ and coreml/ subfolders following the newer CLIP repo convention.
• types/textEmbeddings.ts — extends TextEmbeddingsModelName with 'distiluse-base-multilingual-cased-v2'.
• apps/text-embeddings/.../index.tsx — adds the model to the playground picker.
• useTextEmbeddings.md — adds a row to the "Supported models" table.
• .cspell-wordlist.txt — adds DISTILUSE, distiluse, Distil for the spell-check hook.

HF repo (live): software-mansion/react-native-executorch-distiluse-base-multilingual-cased-v2, main branch + v0.9.0 tag.

├── README.md
├── config.json
├── tokenizer.json
├── tokenizer_config.json
├── xnnpack/
│   ├── distiluse-base-multilingual-cased-v2_xnnpack_fp32.pte   (541 MB)
│   └── distiluse-base-multilingual-cased-v2_xnnpack_8da4w.pte  (393 MB)
└── coreml/
    ├── distiluse-base-multilingual-cased-v2_coreml_fp32.pte    (541 MB)
    └── distiluse-base-multilingual-cased-v2_coreml_fp16.pte    (271 MB)

Introduces a breaking change?

• Yes
• No

Type of change

• Bug fix (change which fixes an issue)
• New feature (change which adds functionality)
• Documentation update (improves or adds clarity to existing documentation)
• Other (chores, tests, code style improvements etc.)

Tested on

• iOS
• Android

Testing instructions

• 1. Run the text-embeddings playground: cd apps/text-embeddings && yarn ios (or yarn android).
• 2. In the model picker, select "Multilingual DistilUSE".
• 3. Enter any sentence; forward should return a 512-dim Float32Array in ~35 ms.
• 4. Cross-lingual retrieval is the model's strength — try indexing a Polish sentence and querying with an English equivalent (or vice versa); top match should be the aligned pair.
• 5. Short single-word non-English queries over short targets are the weakest case (inherent to the model, not an export issue) — use ≥ 1-sentence inputs for best results.

Screenshots

Related issues

Closes the multilingual-BERT half of #945. The paraphrase-multilingual-MiniLM-L12-v2 half stays open pending Unigram/Precompiled/Metaspace support in ExecuTorch's tokenizer lib.

Checklist

• I have performed a self-review of my code
• I have commented my code, particularly in hard-to-understand areas
• I have updated the documentation accordingly
• My changes generate no new warnings

Additional notes

The exporter wrapper passes attention_mask=None into the underlying transformer even though the RNE runtime always supplies an all-ones mask. This is deliberate: HF's create_bidirectional_mask / masking_utils otherwise emits a chain of where / eq / any / logical_not / expand_copy ops on the mask that XNNPACK can't delegate, costing ~10 ms per forward with no observable effect on the output. With the bypass the .pte is bit-exact with eager PyTorch (RMSE 0.0 on fp32 random input) and XNNPACK delegation stays around 89–91% of graph runtime.

The concrete non-delegated ops that remain (LayerNorm, the residual mask prep inside HF, the explicit expand in mean pooling) are all inside upstream code paths — pushing past ~91% would need either a StaticLayerNormalization match in XNNPACK's partitioner or surgery on HF's mask utils. Out of scope here; worth flagging for a future iteration.

Export of fp16 for XNNPack succeeded but produced NaNs, so not useful.

The exporter script, profiling setup, and the full write-up of the above live in the internal export-scripts repo.

[chmjkb]

I haven't verified the demo apps, but the code looks good. Any idea on how the performance compares to other embedding models? 500mb seems like a lot

[msluszniak]

I haven't verified the demo apps, but the code looks good. Any idea on how the performance compares to other embedding models? 500mb seems like a lot

To be fairly honest more than a half of our text embedding models currently are the same other of magnitude. Look: https://huggingface.co/collections/software-mansion/text-embeddings

[chmjkb]

I haven't verified the demo apps, but the code looks good. Any idea on how the performance compares to other embedding models? 500mb seems like a lot

To be fairly honest more than a half of our text embedding models currently are the same other of magnitude. Look: https://huggingface.co/collections/software-mansion/text-embeddings

ok, I was biased by the minilm, which is super small, fine

[NorbertKlockiewicz]

I think we should ship just 1 version of the model per backend in modelUrls

[msluszniak]

Tested all 4 variants off-device via the executorch Python runtime on Tatoeba bitext-mining (eng↔X for X ∈ {pol, deu, fra, spa, rus, jpn}, 1000 pairs each, 6000 total).

All four land within 0.2 pp R@1 / 0.1 pp R@10 across every language pair. CoreML fp32 is bit-exact with XNNPACK fp32 (cosine 1.0). CoreML fp16 differs only at the 5th decimal. XNNPACK 8da4w drifts ~1% in cosine but retrieval is unaffected (sometimes +0.1 pp R@1, sometimes −0.2 pp — quantization noise either way).

Proposing to drop 2:

• _V2 (XNNPACK fp32) — Pareto-dominated on iPhone by _COREML (15 vs 47 ms, 55 vs 175 MB) and on Android by _8DA4W (15 vs 41 ms, 44 vs 196 MB). The "Android accuracy fallback" rationale doesn't survive the data.
• _COREML_FP16 — quality identical to _COREML fp32, but per the docs benchmarks it's slower on iPhone (19 vs 15 ms) and uses more memory (143 vs 55 MB). Only edge is download size (271 vs 541 MB). That memory delta is surprising — worth one re-measure (cold vs warm) before final delete; if fp16 actually wins on memory, the call flips.

Naming: with no bare _V2 shipped, both surviving variants carry explicit suffixes (_8DA4W, _COREML) — slightly inconsistent with other text-embedding models where bare = default XNNPACK fp32. I'd keep the explicit suffixes (clear > convention-pure). Alternative: rename _8DA4W → bare _V2 since it becomes the canonical Android variant — preserves the convention but redefines "default" as quantized for this one model.