ms-marco-MiniLM-L6-v2 — ExecuTorch
A cross-encoder reranker: a query and one document in, one relevance score out. The second
stage of on-device retrieval — an embedding model fetches candidates cheaply, this reads
each candidate together with the query and scores it properly.
- Source: cross-encoder/ms-marco-MiniLM-L6-v2 — 22.7M parameters, 6 BERT layers, hidden 384
- License: Apache-2.0
- Input:
input_ids, attention_mask and token_type_ids, each [1, 512] int64
- Output:
[1, 1] fp32 — the raw logit. sigmoid(x) maps it to 0..1 and does not
change the ordering.
Variants
| build | file | size (MB) | worst score error vs eager | Mac median (ms)* | backend takes |
|---|
| fp32 | rerank_ms_marco_minilm_l6_xnnpack_fp32.pte | 90.9 | 0.0000 logits | 16.7 | 76.0% |
| fp16 | rerank_ms_marco_minilm_l6_xnnpack_fp16.pte | 45.6 | 0.0062 logits | 26.4 | 65.8% |
| Core ML (fp16, iOS) | rerank_ms_marco_minilm_l6_coreml_all.pte | 46.8 | 0.0194 logits | 6.7 | 100.0% |
*Mac arm64, one query-document pair at 512 tokens, fastest of five medians of ten — a
reference point for relative cost, not a device number. The host shares its cores with
other work, and a single median does not survive that; contention only ever adds time, so
the fastest repetition is the one that means something. PyTorch eager fp32, measured the
same way: 17.3 ms.
Correlation is not reported because it cannot be: the output is a single number, and the
correlation of a one-element vector is undefined. The column above is the error in the
units the model is used in — logits — over 6 real query-document pairs, and every build
listed reproduces eager's ranking order exactly.
What it does, on the shipped fp32 build
Query: "How many people live in Berlin?"
| rank | score | document |
|---|
| 1 | +8.816 | Berlin has a population of 3,520,031 registered inhabitants in an area of 891.82 km². |
| 2 | +1.973 | In 2019 the city recorded 3.7 million residents within its metropolitan area. |
| 3 | -3.636 | Berlin is well known for its museums, its nightlife and its history. |
| 4 | -4.487 | The capital of France is Paris, a city of about 2.1 million people. |
| 5 | -10.962 | ベルリンの人口はおよそ350万人です。 |
| 6 | -11.162 | Water boils at 100 degrees Celsius at sea level. |
The narrowest gap between adjacent ranks here is 0.2007 logits.
token_type_ids is not optional
A BERT cross-encoder marks the document half of the pair with segment id 1, and the segment
embedding is doing real work. Measured on this model with the query above and the passage
that answers it, feeding zeros instead of the real segment ids moves the score from
+8.82 to -2.54, a drop of 11.35 logits — the best document in the list crosses into negative territory, where any threshold rejects it.
The graph therefore takes three inputs. XLM-R rerankers (type_vocab_size: 1) have no
second segment and take two; the signature follows the model rather than being made uniform.
The attention is eager, and that is the faster export
F.scaled_dot_product_attention does not survive export as one operation. The edge
dialect lowers it through _safe_softmax, whose guard against a row with no unmasked key
at all leaves 11 operations XNNPACK cannot take, in every attention
block — scalar_tensor, where, mul.Scalar, logical_not, eq, full_like, any.dim. Each one cuts the subgraph in two.
The switch is attn_implementation="eager": transformers then builds the mask
itself, as torch.finfo(dtype).min, instead of handing F.sdpa a boolean mask
for PyTorch to fill with -inf.
The guard is emitted whether or not it can ever fire, and here it cannot: it triggers only
on -inf, and this arm never produces one. So the two differ only about rows that have no
unmasked key at all — sdpa zeroes them, this one gives them a uniform row — and those are
padding rows, which the pooling discards and which every real query row masks out anyway.
Measured with all but eight positions masked, as adversarial as this shape gets, the two
graphs agree to 1.1e-05.
XNNPACK fp32 goes from 61.4% to 76.0% delegated.
Not shipped
- int8 (dynamic) is not shipped: at 58.7 MB it is larger than the fp16 build's 45.6 MB. Dynamic int8 quantizes the linear weights and leaves the token embedding table in fp32, while fp16 halves that table too. The table here is 47 MB of a 91 MB model, and the arithmetic says int8 only comes out smaller when the table is under a third of the weights (30 MB) — measured on ten models on this shelf, the rule called all ten correctly.
Verification
1python convert/export_rerank.py ms_marco_minilm_l6
2python convert/check_rerank.py ms_marco_minilm_l6 fp32
The check has two halves. One is agreement with the model run in eager, in logits and in
ranking order. The other is that the ranking is useful at all: the passage that answers the
question has to outscore a passage about the same subject that does not — agreement alone
would pass a build that ranked by document length in both arms.
(conversion scripts:
executorch-models)
