fix(deps): update dependency ultralytics ( 8.4.72 → 8.4.75 ) - #425

v8.4.75: - Run CoreML on the Neural Engine (CPU_AND_NE) on macOS hosts (#​24885)

Compare Source

🌟 Summary

Ultralytics v8.4.75 delivers an important CoreML reliability and speed fix for macOS 🍎⚡: CoreML models now run on Apple’s Neural Engine by default instead of using a setting that could crash Python processes on Mac hosts.

📊 Key Changes

• 🚑 Major CoreML backend fix for macOS

  • The CoreML backend now loads models with ComputeUnit.CPU_AND_NE instead of the previous default behavior.
  • This avoids a known macOS coremltools issue where ComputeUnit.ALL or GPU-enabled paths could trigger a hard crash with Error: MLIR pass manager failed.

• ⚡ Neural Engine enabled by default on supported Macs

  • On macOS 13 and newer, CoreML inference now uses the CPU + Neural Engine path automatically.
  • This gives much better performance than CPU-only execution.

• 🛡️ Compatibility fallback for older macOS versions

  • If CPU_AND_NE is not supported, Ultralytics now falls back to CPU_ONLY rather than failing.

• 📝 Documentation updated

  • The CoreML integration docs now explain the new macOS behavior and why avoiding the GPU path currently matters for stability.

🎯 Purpose & Impact

• 🍏 Fixes a serious usability issue for Mac users

  • Before this release, running a CoreML .mlpackage from Python on macOS could crash outright.
  • After this update, CoreML inference should work out of the box on supported Macs.

• 🚀 Improves inference speed

  • The reported result shows about 2.5 ms on the Neural Engine vs 8.5 ms on CPU, roughly a 3× speedup.
  • This is especially valuable for real-time or interactive applications.

• 🔧 Makes CoreML deployment more dependable

  • Users exporting YOLO models to CoreML for local Mac inference should see a much smoother experience with fewer platform-specific failures.

• 👥 Broad impact for Python users on Apple Silicon

  • Anyone using Ultralytics CoreML models from Python on a Mac benefits, especially those working with YOLO26 and other exported .mlpackage models.

• ✅ No major new model architecture changes

  • This release is mainly a backend stability and performance update, not a new model release.
  • The biggest win is that existing CoreML workflows on macOS should now be both faster and far more reliable.

In short: v8.4.75 is a small but high-impact release 🎉—especially for macOS users running CoreML models locally, where it turns a crash-prone path into a fast, working default.

What's Changed

• Run CoreML on the Neural Engine (CPU_AND_NE) on macOS hosts by @​glenn-jocher in #​24885

Full Changelog: ultralytics/ultralytics@v8.4.74...v8.4.75

v8.4.74: - Calibrate INT8 on CPU unconditionally (cuDNN-ABI-safe) (#​24884)

Compare Source

🌟 Summary

Ultralytics v8.4.74 focuses on more reliable model export and quantization 🔧—especially fixing INT8 export stability on affected GPU setups and preventing flaky OpenVINO export failures on NMS-enabled models.

📊 Key Changes

• 🚨 INT8 calibration now always runs on CPU during ModelOpt export

  • In the most important change from PR #​24884 by @​glenn-jocher, INT8 calibration for ONNX export was changed to run unconditionally on the CPU execution provider.
  • This replaces the earlier GPU/RTX detection logic, which was found to be unreliable in real-world use.
  • The previous approach could still trigger core dumps or uncatchable crashes on some systems due to TensorRT execution provider behavior and cuDNN ABI mismatches.

• ✅ Safer INT8 export behavior across hardware environments

  • The update avoids calibration on CUDA/TensorRT during the calibration step.
  • Since calibration scales are execution-provider independent, the final INT8 engine remains effectively the same.
  • The tradeoff is simple: slightly slower one-time calibration, but much better export stability.

• 🛠️ Fixed intermittent OpenVINO export failures for NMS models

  • PR #​24883 by @​glenn-jocher fixes a non-deterministic OpenVINO export issue affecting models exported with nms=True.
  • Previously, OpenVINO could fail during conversion with trace-check errors like “Graphs differed across invocations!”
  • The exporter now pre-traces the model before passing it to OpenVINO, avoiding OpenVINO’s internal retracing behavior that caused random failures.

🎯 Purpose & Impact

• More dependable INT8 exports on RTX and mixed-library environments 💪

  • Users exporting INT8 models should see fewer crashes and failed exports, especially on systems where CUDA, TensorRT, and cuDNN versions interact badly.
  • This is particularly valuable for production pipelines and automated export workflows.

• Better stability is prioritized over calibration speed ⚖️

  • Calibration may take a bit longer because it now runs on CPU only.
  • But this slowdown happens only during the export/calibration step, not during normal model inference.
  • For most users, that is a worthwhile tradeoff for a much more reliable export process.

• OpenVINO exports become more consistent 📦

  • Users working with OpenVINO, especially with NMS-enabled models, should experience fewer random export failures.
  • This helps both local users and teams using the Ultralytics Platform for export and deployment workflows.

• Overall release theme: reliability and smoother deployment 🚀

  • This release does not introduce a major new model, but it meaningfully improves the path from training to deployment.
  • If you export models to INT8 or OpenVINO, v8.4.74 should feel safer, more predictable, and easier to trust.

What's Changed

• Fix non-deterministic OpenVINO export failure on NMS models by @​glenn-jocher in #​24883
• Calibrate INT8 on CPU unconditionally (cuDNN-ABI-safe) by @​glenn-jocher in #​24884

Full Changelog: ultralytics/ultralytics@v8.4.73...v8.4.74

v8.4.73: - Calibrate INT8 on CPU for RTX (NvTensorRTRTX) cards (#​24878)

Compare Source

🌟 Summary

Ultralytics v8.4.73 is a stability-focused release that mainly improves INT8 TensorRT export reliability on RTX GPUs 🛠️⚡, while also fixing a memory issue in predict(), improving input order handling, and polishing examples and docs.

📊 Key Changes

• Major fix: safer INT8 calibration on RTX GPUs 🚀

  • The most important update is from PR #​24878 by @​glenn-jocher.
  • When exporting TensorRT engines with int8=True, RTX cards using the NvTensorRTRTXExecutionProvider now perform calibration on the CPU instead of cuda:0.
  • This avoids crashes caused by execution provider conflicts and cuDNN compatibility mismatches during calibration.
  • Important detail: this does not change the final INT8 engine quality or behavior—only the calibration path is changed to make export more reliable.

• Fix for out-of-memory errors when predicting from large file-path lists 💾

  • PR #​24866 fixes a case where passing a large Python list of image paths to model.predict() could load too much into memory and trigger GPU OOM.
  • Local path lists are now handled lazily, so batching works as expected instead of trying to process everything at once.

• Prediction input order is now preserved 📂

  • File lists passed in by users are no longer auto-sorted before loading.
  • This means results now follow the same order as the input list, which is especially helpful for pipelines that depend on exact input-output alignment.

• Better error handling in the OpenCV ONNX example 🖼️

  • PR #​24872 adds a clear FileNotFoundError if an image path is missing or unreadable.
  • This replaces a more confusing later-stage failure.

• Small documentation and comment cleanups ✍️

  • PR #​24881 improves wording in YOLO-World docs and SAM comments.
  • PR #​24821 fixes the QueueManager doc example so copied code uses the correct region format.
  • These changes do not alter runtime behavior, but they make docs easier to follow.

• CI installation step made more resilient 🔁

  • The release also adds retries to a dependency installation step in CI, helping reduce flaky build failures.

🎯 Purpose & Impact

• More dependable INT8 export on RTX hardware ✅

  • Users exporting TensorRT INT8 models on some RTX GPUs should see fewer crashes and failed exports.
  • This is especially valuable for deployment workflows where export stability matters more than raw calibration speed.

• No model accuracy change from the RTX calibration fix 🎯

  • The calibration now runs on CPU for affected RTX setups, but the resulting INT8 engine should remain effectively the same.
  • In short: same intended output, fewer headaches.

• Better scalability for large inference jobs 📈

  • If you run predict() on long image lists, memory use should be much more manageable.
  • This can prevent unnecessary GPU OOM issues and make large batch workflows more practical.

• More predictable automation workflows 🤖

  • Preserving user-supplied file order helps when mapping predictions back to source files in scripts, apps, and data pipelines.

• Friendlier debugging and onboarding 🙌

  • Clearer example errors and cleaner docs reduce friction for newer users and save time for experienced developers.

Overall, v8.4.73 is less about new models and more about making export, inference, and examples more robust and predictable—with the standout improvement being INT8 TensorRT export stability on RTX cards ⚡

What's Changed

• fix minor typos and clarify comments by @​fbertil in #​24881
• Guard against cv2.imread returning None in OpenCV ONNX example by @​orbisai0security in #​24872
• Fix QueueManager docstring region example by @​raimbekovm in #​24821
• Fix OOM when passing large list of file paths to predict() by @​leeburt in #​24866
• Calibrate INT8 on CPU for RTX (NvTensorRTRTX) cards by @​glenn-jocher in #​24878

New Contributors

• @​fbertil made their first contribution in #​24881
• @​leeburt made their first contribution in #​24866

Full Changelog: ultralytics/ultralytics@v8.4.72...v8.4.73