| # 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. |
|
|
