File size: 1,592 Bytes
11808f8 | 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 | # Core ML is not shipped for this model
The Core ML exporter exists in `export-scripts` and converts successfully, but the
artifact it produces cannot be loaded, so no `.pte` or `config.json` is published
here. Use the XNNPACK or MLX build instead.
## Why
Conversion succeeds (fp16, about 710 MB). Loading it in the ExecuTorch runtime
does not:
```
[tensor_parser_portable.cpp:192] getTensorDataPtr() failed: 0x23
[method.cpp:606] Failed parsing tensor at index 0: 0x23
```
Note what this is **not**. It is not the dynamic-shape crash that disables Core ML
on the other text models in this project (apple/coremltools#2825). That one fails
at execute; this fails at **load**, inside the *portable* tensor parser. Ops the
Core ML partitioner did not claim kept their constants in the ExecuTorch program,
and that data is unreadable. The artifact size or a constant-segment issue is the
plausible cause.
Because it never executed, the dynamic-shape question remains **open** for
LFM2.5-Embedding-350M. It never got far enough to hit it.
Re-tested on 2026-08-20 with the software-mansion-labs fork toolchain, rebuilt and
loaded under the fork runtime: identical `0x23`. So this is not an artifact of the
PyPI wheel, unlike the YOLO fp16 MLX case that the fork did fix.
## Two deliberate differences from the other backends
The Core ML variant loads the model in **float32**, because Core ML has no
bfloat16 input dtype, and does **not** apply `quantize_model_`, which packs
weights for the MLX runtime. So the Core ML build is unquantized, and its size is
not comparable to the MLX one.
|