CoreML-Models file sizes are comparable; the performance claims next to them are not

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

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

---

Method: this note was drafted by qwen/qwen3.8-27b from a single source — the published README of 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.

FAQ

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.