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.