# CoreML-Models file sizes are comparable; the performance claims next to them are not The CoreML-Models repo lists file sizes that are directly comparable across models, but the speed and parameter claims embedded in the same README… Canonical page: https://makerportal.ai/blog/on-device-ai-github-286898814 Author: Joshua Hrisko, Principal Engineer — MakerPortal Published: 2026-09-10 Section: Comparison / On-Device AI · 6 min read Tags: on-device-ai, local-llm, ios-craft --- The file sizes in this repository are comparable to each other. The performance claims embedded in the same document are not comparable to the file sizes, and not comparable to each other. ## What it is [CoreML-Models](https://github.com/john-rocky/CoreML-Models) is a model zoo index maintained by Daisuke Majima. It catalogs pre-converted `.mlpackage` files for on-device inference on iOS and macOS, each with a download link, file size, output format, and a link to the original project. The document contains no latency measurements, no throughput numbers, and no benchmark protocol — it is a catalog, not an evaluation. ## Object detection: file sizes and the claims attached to them The object detection section is where the performance claims cluster, so it is the most useful place to look at what is and isn't comparable. | Model | File size | NMS included | Output format | Performance claim in README | Claim conditions stated | |---|---|---|---|---|---| | D-FINE (dfine-n-coco) | 13 MB | Not stated | Confidence (Float32 300×80), Coordinates | None | — | | YOLOv5s | 29.3 MB | Yes | Confidence (Double 0×80), Coordinates | None | — | | YOLOv8s | 45.1 MB | Yes | Confidence (Double 0×80), Coordinates | None | — | | YOLOv9s | 14 MB | Yes | Confidence (MultiArray) | None | — | | YOLOv10s | 14 MB | No (NMS-free) | MultiArray (1×300×…) | None | — | | YOLO11s | 18 MB | Yes | Confidence (MultiArray) | "22% fewer parameters than YOLOv8 with higher mAP" | No hardware, no benchmark, no input size | | YOLO26s | 18 MB | No (NMS-free) | MultiArray (1×300×6…) | "Up to 43% faster CPU inference vs YOLO11" | No hardware, no input size, no benchmark protocol | | RF-DETR (rfdetr-n-coco) | 95 MB | Not stated | Confidence (Float32 300×91) | None | — | All file sizes in this table are `.mlpackage` sizes as listed in the README. They are directly comparable: same unit, same container format, same repository. The performance claims are a different matter. The YOLO11 claim ("22% fewer parameters than YOLOv8") is a parameter count comparison. The YOLO26 claim ("up to 43% faster CPU inference vs YOLO11") is a relative speed comparison. Neither is a file size statement, and neither can be verified from the numbers in this table.

Reported by john-rocky/CoreML-Models MB· scroll →

Conditions around the comparison

scroll →

16.5 MB
regnet_y_400mf file size: 13 MB
D-FINE file size: 95 MB
RF-DETR file size: 29.3 MB
YOLOv5s file size

Figure: values as john-rocky/CoreML-Models reports them, drawn from quantities extracted and quote-verified for this post. Bars are proportional within their shared unit; condition cells are exact values and are not scaled against one another. The studio has not re-measured them.

## Where the comparison holds File sizes are comparable across the entire zoo. If your constraint is app bundle size or download payload, you can rank these models against each other directly. For object detection, the range spans from 13 MB (D-FINE) to 95 MB (RF-DETR). For image classification, it spans from 16.5 MB (regnet_y_400mf) to 350.5 MB (DeiT-base384). For super-resolution, it spans from 628 KB (Fast-SRGAN) to 420 MB (SinSR Denoiser, one of three packages totaling 517 MB). Within the detection table, one observation is immediate: YOLO26s and YOLO11s are both 18 MB. The README's claim that YOLO26 is "up to 43% faster" therefore does not come from a size reduction. It comes from architectural changes the README names: DFL removal and ProgLoss, plus the switch from NMS-based to NMS-free detection. Same storage footprint, claimed speed gain from a different computation graph. ## Where the comparison stops **File size vs. parameter count.** The YOLO11 README entry says "22% fewer parameters than YOLOv8." The file sizes are 18 MB (YOLO11s) and 45.1 MB (YOLOv8s), a 60.1% reduction in file size. These two numbers measure different things. Parameter count is a property of the model architecture. File size in a `.mlpackage` depends on weight precision, packing, and whether auxiliary components (like NMS) are included. The README does not state the weight precision for either model. A 22% parameter reduction producing a 60% file size reduction is plausible if the conversion applied different quantization, but the README does not say it did. You cannot derive one from the other using only what is in this document. **The 43% speedup claim.** "Up to 43% faster CPU inference vs YOLO11" has no hardware specified, no input resolution, no thermal state, no number of inference iterations, and no definition of "up to." It is a relative claim with an unstated ceiling. You cannot place it on the same axis as a file size, and you cannot compare it to the MobileSAM claim (next) because the baselines differ. **The MobileSAM claims.** The README states MobileSAM is "~60x smaller and ~40x faster than the original SAM." The original SAM (ViT-H encoder) is not in this repository. There is no file size for it here, no CoreML conversion, no benchmark. The 60x and 40x figures are unverifiable from this document. They are also not comparable to the YOLO26 43% figure: different model family, different baseline, different metric (size vs. speed), different unstated conditions. **INT8 and FP16 annotations.** RMBG1.4 is listed as "42 MB (INT8)." FastSAM-s is "~23 MB FP16." MatAnyone is "~111 MB FP16 total." For most other models, precision is not stated. This means a 42 MB INT8 model and a 45 MB FP32 model (if one exists unlabelled) occupy different memory at runtime even though their file sizes are nearly identical. The file size comparison holds for storage; it does not hold for runtime memory unless precision is known. ## What cannot be concluded You cannot rank these models by inference speed from this document. The only speed claims present are relative, reference different baselines, and omit the conditions under which they were measured. You cannot verify them without running the `.mlpackage` on a specific device with a specific input. The document supports size-based decisions only. ## Who this lands on An iOS engineer with a bundle size budget and a detection or segmentation requirement. The decision this supports is: which model fits in the payload, and what are the tradeoffs between the options that do. The file sizes are the only axis on which you can make that decision from this document alone. The speed claims should be treated as unverified until you run the model on your target hardware with your input resolution. If you need a second opinion on whether a given `.mlpackage` will fit your memory budget at runtime, the [CoreML Model Size Calculator](/lab/coreml-model-size-calculator) is useful for converting file size to expected memory footprint given the precision. The broader pattern — numbers that sit next to each other in the same document but measure different things under different conditions — is the same one we flagged in [AutoSubs star ratings hiding different training setups](/blog/on-device-ai-github-614149835). --- *Method: this note was drafted by qwen/qwen3.8-27b from a single source — the published README of [john-rocky/CoreML-Models](https://github.com/john-rocky/CoreML-Models). Before publication an automated gate re-checked every extracted claim against the source document (68 claim(s) and 67 quantity(ies) verified) and every claim-shaped number in the draft against that evidence (3 derived from it, no rows from our own tables were supplied to the draft). The studio has not re-run john-rocky/CoreML-Models's benchmarks; figures attributed to it are its own.* ## Questions this note answers ### Can I use the file size to estimate runtime memory? Not reliably from this document alone. File size in a `.mlpackage` includes weight storage, which maps roughly to runtime memory for the weight tensors, but the README does not state precision for most entries. An INT8 model and an FP32 model of similar file size will have very different runtime memory footprints. Where precision is stated (RMBG1.4 INT8, FastSAM FP16, MatAnyone FP16), you can make a better estimate. Where it is not stated, assume FP32 as a worst case. ### Why are YOLOv9s and YOLOv10s both 14 MB but have different output formats? YOLOv9s outputs "Confidence (MultiArray)" with NMS added. YOLOv10s outputs "MultiArray (1×300×…)" with NMS-free end-to-end detection. The NMS post-processing step is a separate computation that YOLOv10 eliminates by design. The file sizes being identical is a coincidence of architecture and conversion, not evidence that the models are equivalent. The output format difference means your Swift code will parse the results differently. ### Is the SinSR 517 MB total (39 + 420 + 58) comparable to a single 420 MB model? No. SinSR is a three-stage pipeline: encoder, denoiser, decoder. All three must be loaded and executed in sequence. The 420 MB denoiser is the dominant component, but the total memory and compute cost is the sum of all three stages, not just the largest one. Comparing "420 MB" from SinSR to "420 MB" from a hypothetical single-model entry would be misleading because the SinSR figure is one component of a pipeline, not the whole system. ### Does "up to 43% faster" mean I should expect 43% speedup in my app? No. "Up to" is a ceiling, not a median. The README does not state the hardware, input size, or benchmark protocol under which this ceiling was achieved. Your actual speedup will depend on your device, your input resolution, thermal throttling, and whether the ANE is available. Treat it as an upper bound under ideal conditions and plan for less.