Ultralytics 8.4.162 加入影像批次預取，讓載入與 CUDA 推論重疊

Ultralytics 於9月24日發布8.4.162，讓CUDA影像推論能在處理目前批次時，預先載入下一批影像；PyPI也已提供對應套件。這次改動切入資料供應流程，適合關注大量圖片離線分析的團隊。[版本說明](https://github.com/ultralytics/ultralytics/releases/tag/v8.4.162)、[PyPI套件](https://pypi.org/project/ultralytics/8.4.162/)

原本迭代器須先完成下一批圖片的讀取與解碼，GPU才有資料可算。新流程以單一背景工作執行緒預取，讓載入與目前批次的處理重疊。主分支程式的啟用條件是CUDA裝置、LoadImagesAndVideos來源、全部檔案皆為影像，且超過一個批次；影片與單批次不走這條路徑。從流程判斷，收益取決於讀檔時間能否被運算掩蓋，無法直接推論單張模型前向運算會變快。[程式碼](https://raw.githubusercontent.com/ultralytics/ultralytics/main/ultralytics/engine/predictor.py)

開發者在PR中的測試使用YOLO26n、640像素輸入，每組配置跑五對獨立程序。L4以batch=1處理1,000張COCO影像，中位耗時從23.012秒降至19.521秒；batch=16處理5,000張則從31.224秒降至27.608秒。計時包含模型建立、結果收集、輸出雜湊及CUDA同步，因此屬完整測試流程的成績。這些數字來自合併前指定提交，仍須以正式套件重測。[測試條件](https://github.com/ultralytics/ultralytics/pull/26319)

適用範圍有一項文件落差：發布摘要仍寫成PyTorch偵測限定，但PR最後的提交已標示擴及其他任務與後端，現行主分支也沒有這兩項限制。工程師應核對安裝版本的條件判斷，不能把早期測速外推到所有受影響路徑。[合併紀錄](https://github.com/ultralytics/ultralytics/pull/26319)

預取會額外保留已解碼圖片，應把主記憶體峰值納入評估。大量結果另可用stream=True逐筆消費，但仍須檢查應用程式是否自行累積結果。[推論介面](https://docs.ultralytics.com/reference/engine/predictor/)

依管線設計推論，若圖片位於網路磁碟，背景載入仍可能受頻寬與尾端延遲限制；若主要時間花在結果寫檔，收益也可能縮小。實際驗收宜固定影像順序、批次大小與輸出設定，同時量測完整耗時、結果一致性，以及提前關閉串流後的資源釋放。比較時也應區分首次建立模型與後續重複執行，避免把初始化差異混入預取收益。