Upload README.md with huggingface_hub

README.md

@@ -24,19 +24,21 @@ never leaves the device.
 
 ## Two parts of the recipe, and only one of them is in the graph
 
-**The pooling is in.** sentence-transformers keeps it per model, and the four small
-embedding models on this shelf do not agree:
+**The pooling is in.** sentence-transformers keeps it per model, and the six embedding
+models on this shelf do not agree:
 
 | | pooling | normalised |
 |---|---|---|
-| **multilingual-e5-large** | **mean** | **yes** |
-| all-MiniLM-L6-v2 / L12-v2 | mean | yes |
+| all-MiniLM-L6-v2 | mean | yes |
+| all-MiniLM-L12-v2 | mean | yes |
 | bge-small-en-v1.5 | **CLS** | yes |
+| multilingual-e5-base | mean | yes |
+| **multilingual-e5-large** | **mean** | **yes** |
 | paraphrase-multilingual-L12 | mean | **no** |
 
 Read off `modules.json` and `1_Pooling/config.json` rather than assumed from the family
-name — the other multilingual model on this shelf uses the same pooling and does *not*
-normalise.
+name — paraphrase-multilingual is the same architecture family with the same pooling, and
+it does *not* normalise.
 
 **The prefix is not.** E5 is trained with `"query: "` in front of a search query and
 `"passage: "` in front of a document, and it expects them at inference:
@@ -56,7 +58,7 @@ numbers below are for the recipe as the model intends it.
 | build | file | size | latency | worst cosine vs eager |
 |---|---|---|---|---|
 | XNNPACK fp32 | `embed_multilingual_e5_large_xnnpack_fp32.pte` | 2235.7 MB | 106.5 ms | 1.000000 |
-| XNNPACK fp16 | `embed_multilingual_e5_large_xnnpack_fp16.pte` | 1118.3 MB | 221.2 ms | 1.000000 |
+| XNNPACK fp16 | `embed_multilingual_e5_large_xnnpack_fp16.pte` | 1118.3 MB | 221.2 ms | 0.999999 |
 | Core ML fp32 | `embed_multilingual_e5_large_coreml_all.pte` | 1119.3 MB | **27.2 ms** | 0.999993 |
 
 Mac arm64, median of 10, one 256-token sequence — a reference point for relative cost,
@@ -100,8 +102,8 @@ the weights — holds at both points, and large is closer to the crossing.
 XNNPACK fp32 is level with PyTorch eager here (106.5 ms against 101.1), and fp16 is
 twice as slow while halving the file — XNNPACK has no fp16 kernels for this graph and
 inserts casts instead. Core ML is the one that pays: **27.2 ms**, roughly four times
-eager, 100% delegated in a single subgraph. On iOS take the Core ML build; on Android the choice is fp32 for
-speed or fp16 for half the disk.
+eager, 100% delegated in a single subgraph. On iOS take the Core ML build; on Android the choice is
+fp32 for speed or fp16 for half the disk.
 
 torch.export -> to_edge_transform_and_lower(partitioner) -> .pte
 (conversion scripts: [executorch-models](https://github.com/john-rocky/executorch-models))