端 ML 調(diào)度驗(yàn)證報(bào)告：DVFS 與線程調(diào)度如何讓 Pixel 8 的 Rust 預(yù)處理慢 2.8 倍，以及如何修復(fù)){kind=tracking}
Ente 移動(dòng)端 ML 調(diào)度驗(yàn)證報(bào)告DVFS 與線程調(diào)度如何讓 Pixel 8 的 Rust 預(yù)處理慢 2.8 倍以及如何修復(fù)【免費(fèi)下載鏈接】ente End-to-end encrypted cloud for everything.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/en/ente導(dǎo)讀Ente 的移動(dòng)端 ML 索引管線人臉檢測(cè)、CLIP 圖像嵌入、人臉特征提取在 AndroidONNX Runtime WebGPU與 iOSCoreML之間存在驚人的端到端差距。2026-07-22 的基準(zhǔn)顯示 iPhone 15 Pro 在 Rust 預(yù)處理上快約 12 倍、串行解碼快約 4 倍遠(yuǎn)超兩顆 SoC 之間約 1.62 倍的真實(shí)硅片差距。本文基于倉庫內(nèi)的 Android ML 調(diào)度驗(yàn)證報(bào)告完整復(fù)盤其四個(gè)受控實(shí)驗(yàn)變體、sched_getcpu() DVFS 頻率采樣等新型埋點(diǎn)、假設(shè)驗(yàn)證結(jié)論以及按預(yù)期價(jià)值排序的六條生產(chǎn)落地建議。讀完本文你將掌握如何用頻率采樣與線程集中來診斷突發(fā)型負(fù)載下 CPU 提頻不足這一 Android 移動(dòng)端性能頑疾以及 Ente 計(jì)劃如何通過單線程管線、CPU/GPU 流水線、ADPF 等手段回收 2.8 倍預(yù)處理性能。一、背景07-22 基準(zhǔn)報(bào)告中的異常差距驗(yàn)證實(shí)驗(yàn)的起點(diǎn)是 20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md。該報(bào)告在 Pixel 8Android 17ONNX Runtime WebGPU與 iPhone 15 ProiOS 26.5.2ONNX Runtime CoreML上用同一 14 圖語料測(cè)得如下穩(wěn)定態(tài)數(shù)據(jù)設(shè)備端到端 14 圖每圖Rust 總耗時(shí)Rust 每圖Pixel 8 WebGPU12,994.3 ms928.2 ms7,265.3 ms518.9 msiPhone CoreMLwarm5,022.2 ms358.7 ms1,789.8 ms127.8 ms其中 iPhone 端到端快 2.59 倍Rust 管線內(nèi)快約 4 倍。但分階段看差距分布極不均勻階段Pixel 8iPhone 15 Pro差距Decode2,771.0 ms1,169.6 ms~2.4xRust 預(yù)處理652.8 ms55.1 ms~11.8xInferenceWebGPU vs CoreML3,720.0 ms557.9 ms~6.7xRust 后處理12.7 ms2.3 ms~5.5xRust 其他117.2 ms0.5 ms—預(yù)處理 11.8 倍、后處理 5.5 倍的差距遠(yuǎn)不能由 WebGPU/CoreML 之間的推理引擎差異5.78.8x屬真實(shí)平臺(tái)差距或硅片差異解釋。這構(gòu)成了本次驗(yàn)證實(shí)驗(yàn)的直接動(dòng)機(jī)Pixel 的 CPU 側(cè)慢到底慢在硬件、并行度還是調(diào)度二、實(shí)驗(yàn)設(shè)計(jì)四個(gè)變體與有效性控制驗(yàn)證實(shí)驗(yàn)在ort_opt_ios分支HEAD3c9ee2cb76追加基準(zhǔn)埋點(diǎn)上進(jìn)行設(shè)備為 Google Pixel 8shiba全部變體滿足AOT releaseconnectedIndependentReleaseAndroidTest每輪驗(yàn)證dart.vm.producttrue變體 B 額外通過ML_PARITY_REQUIRE_RELEASEtrue門禁、14 圖語料、每圖 1 次不計(jì)時(shí)預(yù)熱 3 次計(jì)時(shí)采樣、按文件取中位數(shù)。每個(gè)變體前后設(shè)備熱狀態(tài)均為 1輕度跨變體一致因此橫向?qū)Ρ葍?nèi)部自洽。四個(gè)變體的編譯期覆蓋與bench_config確認(rèn)如下變體編譯期覆蓋bench_config確認(rèn)A無基線 放置采樣rayon 池 9 線程無親和性BENTE_ML_BENCHMARK_RAYON_THREADS1池配置為 1 線程CENTE_ML_BENCHMARK_CPU_AFFINITY4-8掩碼0x1f09/9 工作線程釘在 midbigD兩者皆用親和性8僅 Cortex-X3池 1 線程全部工作壓到 cpu8其中 A 為基線B 用于檢驗(yàn) rayon 扇出fan-out是否是預(yù)處理瓶頸C 用于檢驗(yàn)小核放置的影響D 用于檢驗(yàn)線程集中 單大核能否讓 DVFS 持續(xù)提頻。上述ENTE_ML_BENCHMARK_*覆蓋開關(guān)是基準(zhǔn)專用、編譯期可選的能力生產(chǎn)構(gòu)建默認(rèn)不開啟07-22 報(bào)告中明確基準(zhǔn)日志通過ENTE_ML_BENCHMARK_LOGGING編譯期 opt-inAndroid release 埋點(diǎn)通過ENTE_ML_BENCHMARK_RELEASE_TESTS1開啟普通構(gòu)建不受影響。新增的埋點(diǎn)編譯出生產(chǎn)構(gòu)建之外包括在各階段時(shí)鐘之外采樣sched_getcpu()與 DVFS 頻率以及在每次管線之后運(yùn)行一次空broadcast的 rayon 喚醒延遲探針。三、結(jié)果階段到底跑在哪、跑在多少 MHzPixel 8 的集群拓?fù)錇閏pu0-3 Cortex-A510little最高 1.70 GHz、cpu4-7 Cortex-A715mid最高 2.37 GHz、cpu8 Cortex-X3big最高 2.91 GHz。基線 A 下各階段的實(shí)際放置與頻率占總階段時(shí)間的份額階段變體 A放置位置中位頻率decode長(zhǎng)突發(fā)42% mid / 58% bigmid 1,418 MHzbig 2,687 MHz預(yù)處理短突發(fā)3% little / 61% mid / 37% bigmid910 MHzbig 1,557 MHz后處理μs 級(jí)突發(fā)98% mid697 MHz這直接測(cè)量到了 07-22 分析所預(yù)測(cè)的模式只有足夠長(zhǎng)的 decode 突發(fā)能在突發(fā)中途掙到高頻率短促的預(yù)處理/后處理突發(fā)總是冷啟動(dòng)、冷結(jié)束。ML 管線的 CPU 短突發(fā)每次跟隨約 240 ms 的 GPU 推理休眠在約 9 個(gè)工作線程間輪轉(zhuǎn)從未在每個(gè)線程上累積出足夠的利用率讓 Android 調(diào)度器提頻或遷移到大核?；€預(yù)處理大部分時(shí)間跑在 mid 核上中位僅910 MHz只有其 2.37 GHz 上限的 38%。變體 D全部工作集中到一個(gè) big 核的效果持續(xù)頻率升至2,363 MHz語料預(yù)處理總耗時(shí)從596.7 ms 降至 212.4 ms2.8 倍落入硅片應(yīng)有的水平區(qū)間盡管只用 1 個(gè)核而非 9 個(gè)核卻產(chǎn)生了所有變體中最快的端到端運(yùn)行。13 個(gè)共有 fixture 的語料匯總語料總計(jì)msA基線B串行 rayonC無 little 核D串行 1 big 核decode2,772.13,907.52,898.93,194.0Rust 預(yù)處理596.7535.9472.2212.4inferenceWebGPU3,349.53,947.73,622.83,159.8Rust 后處理13.68.511.49.6Rust 其他103.0119.0105.462.7Rust 總計(jì)6,874.58,536.27,073.96,652.6在變體 D 中同一預(yù)處理的每次調(diào)用中位數(shù)從 15.0 ms 降到5.4 msp90 從 30 ms 降到 10 ms最大值從 81 ms 降到 21 ms。rayon 喚醒探針每次 resize 分發(fā)的扇出屏障開銷數(shù)據(jù)顯示變體 A 中位數(shù) 2.2 ms、p90 4.9 ms且 46% 的池工作線程在小核上喚醒即便在 C全部線程釘?shù)?midbig中仍是 2.4 ms 中位數(shù)——說明該開銷本質(zhì)是空閑線程退出延遲而非小核放置問題單線程池D下則驟降至 0.10 ms。四、假設(shè)驗(yàn)證H1 被否決H2 被確認(rèn)H1 — rayon 扇出屏障主導(dǎo)預(yù)處理被否決為主因被確認(rèn)是真實(shí)次要成本將池串行化B只回收了約 597 ms 語料預(yù)處理中的約 60 ms約 10%且呈雙峰分布小圖顯著受益1343.jpg從 39.6 ms 降至 13.0 ms——純屏障開銷而大圖或人臉密集圖反而變差pano39.7 → 59.3 mspeople.jpeg74.2 → 84.8 ms因?yàn)閬G失了真實(shí)的并行計(jì)算。結(jié)論是每次分發(fā)的 25 ms 屏障稅真實(shí)存在但有限。從源碼可以印證該扇出的存在ente-mlcrate 的 Cargo.toml 中fast_image_resize { workspace true, features [rayon] }顯式啟用了 resize 庫的 rayon 并行特性且 crate 直接依賴rayon 1.12.0。實(shí)際 resize 調(diào)用鏈位于 preprocess.rsYOLO 輸入預(yù)處理使用fast_image_resize的Resizer與雙線性插值以及 cv/resize.rs 等模塊。這正是報(bào)告中每次 resize 分發(fā)的 25 ms 屏障稅的代碼出處。H2 — 冷核/DVFS 放置主導(dǎo)確認(rèn)且頻率是決定性杠桿排除 little 核C只讓預(yù)處理改善 21%因?yàn)?mid 核仍以 910 MHz 空轉(zhuǎn)。把工作集中到一個(gè)核D后schedutil得以維持 2,363 MHz帶來 2.8 倍改善。結(jié)論單靠放置affinity不是解藥持續(xù)的利用率sustained utilization才是。解碼并行值得保留串行解碼B在語料范圍內(nèi)多花 1,135 ms幾乎全部來自兩個(gè)大/平鋪 HEICpano714 → 1,426 ms8606239 → 519 ms普通 HEIC 本就接近串行解碼。而在升頻后的核D上串行 JPEG/PNG/WebP 解碼器反而比基線更快astronaut.png11.6 → 5.0 msui_app.webp121.5 → 79.9 ms。與 iPhone 的對(duì)賬在 13 個(gè)共有 fixture 上iPhone 15 Pro 的預(yù)處理總量約 51 ms。變體 D 把 Pixel 從落后 11.7 倍拉近到約 4.2 倍殘余差距來自真實(shí)的硅片差距單核約 23 倍加上 X3 在推理休眠間隙只維持 2,363 MHz而非 2,914 MHz。07-22 報(bào)告中Pixel 處處慢約 10 倍的讀法被證偽——那是在測(cè)量調(diào)度器行為而非硬件。五、異常與注意事項(xiàng)CR2 平臺(tái)回退失敗IMG_8905.CR2在 C、D 變體中其平臺(tái) JPEG 回退失敗在 A、B 及所有 07-22 運(yùn)行中成功。兩次失敗都發(fā)生在測(cè)試框架開始保留已安裝應(yīng)用持久化應(yīng)用數(shù)據(jù)之后因此首要嫌疑是持久化應(yīng)用數(shù)據(jù)而非親和性覆蓋本身。任何親和性相關(guān)改動(dòng)上線前需針對(duì)性重跑。共有文件分析已剔除該 fixture頭條數(shù)字不受影響。WebGPU 推理波動(dòng)各變體間推理耗時(shí) ±9% 波動(dòng)3,1603,948 ms且無明確排序變體間推理差值應(yīng)視為噪聲。熱狀態(tài)差異本次全程熱狀態(tài) 107-22 為 0但基線 A 仍復(fù)現(xiàn)了 07-22 的語料總量decode 2,772 vs 2,771 ms預(yù)處理 597 vs 653 ms證明埋點(diǎn)與熱狀態(tài)沒有扭曲基準(zhǔn)。logcat 環(huán)形緩沖A/B 的 logcat 各有一個(gè) fixture 的事件在緩沖區(qū)擴(kuò)容到 16 MB 前被驅(qū)逐已由共有文件分析處理。變體 D 的診斷性質(zhì)硬釘一個(gè)核是診斷手段而非可上線配置——它獨(dú)占 X3、無視熱余量、與其他負(fù)載沖突。六、生產(chǎn)建議按預(yù)期價(jià)值排序報(bào)告為生產(chǎn) Android 索引給出的建議按預(yù)期價(jià)值排序停止把管線工作輪轉(zhuǎn)在 FRB 工作線程池上改為在單一持久專用線程上運(yùn)行 ML 管線可選第二線程專用于解碼。這是變體 D 結(jié)論的可上線形態(tài)線程集中才能讓schedutil維持高頻第一步無需任何 pinning。CPU 與 GPU 流水線化在圖像 N 處于Session::run內(nèi)時(shí)同步解碼/預(yù)處理圖像 N1。這一舉兩得完全隱藏預(yù)處理延遲同時(shí)保持工作線程高利用率以維持頻率——還能同時(shí)打擊解碼的 24 倍缺口這是單階段修復(fù)做不到的。采用 ADPFPerformanceHintManager為 ML 工作線程設(shè)置每圖目標(biāo)時(shí)長(zhǎng)。這是 Android 官方針對(duì)突發(fā)型負(fù)載 DVFS問題的既定機(jī)制可替代任何親和性 hack。從rust/crates/ml中移除fast_image_resize的rayonfeature保留heic_decoder自身的 rayon 并行用于解碼。resize 扇出從未回本——B 變體在無它時(shí)預(yù)處理凈更快——且每次分發(fā)還要付出 25 ms 屏障稅。小而安全、立即可做。不要上線 CPU 親和性 pinning除非 CR2 異常得到解決并在爭(zhēng)用/熱負(fù)載下測(cè)試僅當(dāng) 13 項(xiàng)不達(dá)預(yù)期時(shí)才重新考慮。修正 07-22 報(bào)告的跨平臺(tái)表述CoreML 對(duì) WebGPU 的推理差距5.78.8 倍是真實(shí)平臺(tái)差距但預(yù)處理/后處理/解碼差距約 1.62 倍硅片差距 Android 調(diào)度債務(wù)后者可由 14 項(xiàng)回收。報(bào)告對(duì) 124 項(xiàng)組合暫不含推理側(cè)工作的穩(wěn)定態(tài)影響預(yù)估端到端約 1020%本語料上預(yù)處理 597 → 約 210 ms其他103 → 約 60 ms串行解碼 fixture 快 1.52 倍大 HEIC 解碼不變更大的戰(zhàn)略價(jià)值在于CPU 成本不再隨調(diào)度器心情波動(dòng)WebGPU 推理差距成為 Android 唯一的剩余短板。七、結(jié)論性能問題的層級(jí)與取證方法本次驗(yàn)證的完整敘事是Pixel 8 的 CPU 側(cè)慢根因不是硬件、也不是主要來自 rayon 扇出而是 DVFS 與調(diào)度。短 CPU 突發(fā)跟隨長(zhǎng) GPU 休眠、跨約 9 個(gè)線程輪轉(zhuǎn)導(dǎo)致每線程利用率不足、調(diào)度器不提頻基線預(yù)處理長(zhǎng)期運(yùn)行在 38% 的峰值頻率上。將工作集中到單一大核后2.8 倍性能被直接解凍。這一結(jié)論對(duì)移動(dòng)端 ML 工程有普遍方法學(xué)意義跨平臺(tái)基準(zhǔn)必須先排除調(diào)度因素才能討論硅片差距——否則會(huì)把調(diào)度器行為誤讀為硬件差距診斷突發(fā)型負(fù)載性能問題時(shí)同時(shí)采樣放置sched_getcpu與頻率DVFS是不可或缺的一對(duì)觀測(cè)手段修復(fù)方向應(yīng)該是線程集中 CPU/GPU 流水線 ADPF 提示而不是盲目堆并行度或依賴親和性硬釘。相關(guān)產(chǎn)物與深入閱讀本次驗(yàn)證的機(jī)器可讀產(chǎn)物與工具位于 infra/ml/test各變體日志、熱快照與結(jié)果載荷infra/ml/test/out/sched_verification_2026-07-23/{A,B,C,D}/device_logcat.txt與.../{A,C,D}/results.jsonB 的載荷因測(cè)試框架測(cè)試后自動(dòng)卸載而丟失其基準(zhǔn)數(shù)據(jù)完整保留在 logcat 中分析腳本python3 infra/ml/test/tools/analyze_ml_sched_verification.py device_logcat.txt輸出放置、頻率、探針與語料匯總過程文檔20260723_ANDROID_SCHED_VERIFICATION_RUNBOOK.md與本文同目錄。與本主題直接相關(guān)的倉庫源碼與配置rust/crates/ml/Cargo.tomlfast_image_resize的 rayon feature、rayon依賴、Android/iOS 的 ORT provider featurerust/crates/ml/src/preprocess.rsYOLO 輸入預(yù)處理resize letterbox 歸一化rust/crates/ml/src/cv/resize.rs通用圖像 resize 路徑infra/ml/playground/optimizations/README.md模型優(yōu)化流水線GELU 融合、PReLU 改寫等保證同一 ONNX 產(chǎn)物可被 CoreML 與 WebGPU 共用infra/ml/playground/optimizations/benchmark_reports/20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md本文的基線報(bào)告如需復(fù)現(xiàn)基準(zhǔn)可參考 infra/ml/test/run_ml_parity_tests.sh 與 infra/ml/test/README.md 了解 14 圖 ML 一致性語料含man.jpeg、people.jpeg、singapore.jpg等 fixture位于 infra/ml/playground/data的構(gòu)成與運(yùn)行方式?！久赓M(fèi)下載鏈接】ente End-to-end encrypted cloud for everything.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/en/ente創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考 Ente 移動(dòng)端 ML 調(diào)度驗(yàn)證報(bào)告：DVFS 與線程調(diào)度如何讓 Pixel 8 的 Rust 預(yù)處理慢 2.8 倍，以及如何修復(fù)
Ente 移動(dòng)端 ML 調(diào)度驗(yàn)證報(bào)告DVFS 與線程調(diào)度如何讓 Pixel 8 的 Rust 預(yù)處理慢 2.8 倍以及如何修復(fù)【免費(fèi)下載鏈接】ente End-to-end encrypted cloud for everything.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/en/ente導(dǎo)讀Ente 的移動(dòng)端 ML 索引管線人臉檢測(cè)、CLIP 圖像嵌入、人臉特征提取在 AndroidONNX Runtime WebGPU與 iOSCoreML之間存在驚人的端到端差距。2026-07-22 的基準(zhǔn)顯示 iPhone 15 Pro 在 Rust 預(yù)處理上快約 12 倍、串行解碼快約 4 倍遠(yuǎn)超兩顆 SoC 之間約 1.62 倍的真實(shí)硅片差距。本文基于倉庫內(nèi)的 Android ML 調(diào)度驗(yàn)證報(bào)告完整復(fù)盤其四個(gè)受控實(shí)驗(yàn)變體、sched_getcpu() DVFS 頻率采樣等新型埋點(diǎn)、假設(shè)驗(yàn)證結(jié)論以及按預(yù)期價(jià)值排序的六條生產(chǎn)落地建議。讀完本文你將掌握如何用頻率采樣與線程集中來診斷突發(fā)型負(fù)載下 CPU 提頻不足這一 Android 移動(dòng)端性能頑疾以及 Ente 計(jì)劃如何通過單線程管線、CPU/GPU 流水線、ADPF 等手段回收 2.8 倍預(yù)處理性能。一、背景07-22 基準(zhǔn)報(bào)告中的異常差距驗(yàn)證實(shí)驗(yàn)的起點(diǎn)是 20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md。該報(bào)告在 Pixel 8Android 17ONNX Runtime WebGPU與 iPhone 15 ProiOS 26.5.2ONNX Runtime CoreML上用同一 14 圖語料測(cè)得如下穩(wěn)定態(tài)數(shù)據(jù)設(shè)備端到端 14 圖每圖Rust 總耗時(shí)Rust 每圖Pixel 8 WebGPU12,994.3 ms928.2 ms7,265.3 ms518.9 msiPhone CoreMLwarm5,022.2 ms358.7 ms1,789.8 ms127.8 ms其中 iPhone 端到端快 2.59 倍Rust 管線內(nèi)快約 4 倍。但分階段看差距分布極不均勻階段Pixel 8iPhone 15 Pro差距Decode2,771.0 ms1,169.6 ms~2.4xRust 預(yù)處理652.8 ms55.1 ms~11.8xInferenceWebGPU vs CoreML3,720.0 ms557.9 ms~6.7xRust 后處理12.7 ms2.3 ms~5.5xRust 其他117.2 ms0.5 ms—預(yù)處理 11.8 倍、后處理 5.5 倍的差距遠(yuǎn)不能由 WebGPU/CoreML 之間的推理引擎差異5.78.8x屬真實(shí)平臺(tái)差距或硅片差異解釋。這構(gòu)成了本次驗(yàn)證實(shí)驗(yàn)的直接動(dòng)機(jī)Pixel 的 CPU 側(cè)慢到底慢在硬件、并行度還是調(diào)度二、實(shí)驗(yàn)設(shè)計(jì)四個(gè)變體與有效性控制驗(yàn)證實(shí)驗(yàn)在ort_opt_ios分支HEAD3c9ee2cb76追加基準(zhǔn)埋點(diǎn)上進(jìn)行設(shè)備為 Google Pixel 8shiba全部變體滿足AOT releaseconnectedIndependentReleaseAndroidTest每輪驗(yàn)證dart.vm.producttrue變體 B 額外通過ML_PARITY_REQUIRE_RELEASEtrue門禁、14 圖語料、每圖 1 次不計(jì)時(shí)預(yù)熱 3 次計(jì)時(shí)采樣、按文件取中位數(shù)。每個(gè)變體前后設(shè)備熱狀態(tài)均為 1輕度跨變體一致因此橫向?qū)Ρ葍?nèi)部自洽。四個(gè)變體的編譯期覆蓋與bench_config確認(rèn)如下變體編譯期覆蓋bench_config確認(rèn)A無基線 放置采樣rayon 池 9 線程無親和性BENTE_ML_BENCHMARK_RAYON_THREADS1池配置為 1 線程CENTE_ML_BENCHMARK_CPU_AFFINITY4-8掩碼0x1f09/9 工作線程釘在 midbigD兩者皆用親和性8僅 Cortex-X3池 1 線程全部工作壓到 cpu8其中 A 為基線B 用于檢驗(yàn) rayon 扇出fan-out是否是預(yù)處理瓶頸C 用于檢驗(yàn)小核放置的影響D 用于檢驗(yàn)線程集中 單大核能否讓 DVFS 持續(xù)提頻。上述ENTE_ML_BENCHMARK_*覆蓋開關(guān)是基準(zhǔn)專用、編譯期可選的能力生產(chǎn)構(gòu)建默認(rèn)不開啟07-22 報(bào)告中明確基準(zhǔn)日志通過ENTE_ML_BENCHMARK_LOGGING編譯期 opt-inAndroid release 埋點(diǎn)通過ENTE_ML_BENCHMARK_RELEASE_TESTS1開啟普通構(gòu)建不受影響。新增的埋點(diǎn)編譯出生產(chǎn)構(gòu)建之外包括在各階段時(shí)鐘之外采樣sched_getcpu()與 DVFS 頻率以及在每次管線之后運(yùn)行一次空broadcast的 rayon 喚醒延遲探針。三、結(jié)果階段到底跑在哪、跑在多少 MHzPixel 8 的集群拓?fù)錇閏pu0-3 Cortex-A510little最高 1.70 GHz、cpu4-7 Cortex-A715mid最高 2.37 GHz、cpu8 Cortex-X3big最高 2.91 GHz。基線 A 下各階段的實(shí)際放置與頻率占總階段時(shí)間的份額階段變體 A放置位置中位頻率decode長(zhǎng)突發(fā)42% mid / 58% bigmid 1,418 MHzbig 2,687 MHz預(yù)處理短突發(fā)3% little / 61% mid / 37% bigmid910 MHzbig 1,557 MHz后處理μs 級(jí)突發(fā)98% mid697 MHz這直接測(cè)量到了 07-22 分析所預(yù)測(cè)的模式只有足夠長(zhǎng)的 decode 突發(fā)能在突發(fā)中途掙到高頻率短促的預(yù)處理/后處理突發(fā)總是冷啟動(dòng)、冷結(jié)束。ML 管線的 CPU 短突發(fā)每次跟隨約 240 ms 的 GPU 推理休眠在約 9 個(gè)工作線程間輪轉(zhuǎn)從未在每個(gè)線程上累積出足夠的利用率讓 Android 調(diào)度器提頻或遷移到大核?；€預(yù)處理大部分時(shí)間跑在 mid 核上中位僅910 MHz只有其 2.37 GHz 上限的 38%。變體 D全部工作集中到一個(gè) big 核的效果持續(xù)頻率升至2,363 MHz語料預(yù)處理總耗時(shí)從596.7 ms 降至 212.4 ms2.8 倍落入硅片應(yīng)有的水平區(qū)間盡管只用 1 個(gè)核而非 9 個(gè)核卻產(chǎn)生了所有變體中最快的端到端運(yùn)行。13 個(gè)共有 fixture 的語料匯總語料總計(jì)msA基線B串行 rayonC無 little 核D串行 1 big 核decode2,772.13,907.52,898.93,194.0Rust 預(yù)處理596.7535.9472.2212.4inferenceWebGPU3,349.53,947.73,622.83,159.8Rust 后處理13.68.511.49.6Rust 其他103.0119.0105.462.7Rust 總計(jì)6,874.58,536.27,073.96,652.6在變體 D 中同一預(yù)處理的每次調(diào)用中位數(shù)從 15.0 ms 降到5.4 msp90 從 30 ms 降到 10 ms最大值從 81 ms 降到 21 ms。rayon 喚醒探針每次 resize 分發(fā)的扇出屏障開銷數(shù)據(jù)顯示變體 A 中位數(shù) 2.2 ms、p90 4.9 ms且 46% 的池工作線程在小核上喚醒即便在 C全部線程釘?shù)?midbig中仍是 2.4 ms 中位數(shù)——說明該開銷本質(zhì)是空閑線程退出延遲而非小核放置問題單線程池D下則驟降至 0.10 ms。四、假設(shè)驗(yàn)證H1 被否決H2 被確認(rèn)H1 — rayon 扇出屏障主導(dǎo)預(yù)處理被否決為主因被確認(rèn)是真實(shí)次要成本將池串行化B只回收了約 597 ms 語料預(yù)處理中的約 60 ms約 10%且呈雙峰分布小圖顯著受益1343.jpg從 39.6 ms 降至 13.0 ms——純屏障開銷而大圖或人臉密集圖反而變差pano39.7 → 59.3 mspeople.jpeg74.2 → 84.8 ms因?yàn)閬G失了真實(shí)的并行計(jì)算。結(jié)論是每次分發(fā)的 25 ms 屏障稅真實(shí)存在但有限。從源碼可以印證該扇出的存在ente-mlcrate 的 Cargo.toml 中fast_image_resize { workspace true, features [rayon] }顯式啟用了 resize 庫的 rayon 并行特性且 crate 直接依賴rayon 1.12.0。實(shí)際 resize 調(diào)用鏈位于 preprocess.rsYOLO 輸入預(yù)處理使用fast_image_resize的Resizer與雙線性插值以及 cv/resize.rs 等模塊。這正是報(bào)告中每次 resize 分發(fā)的 25 ms 屏障稅的代碼出處。H2 — 冷核/DVFS 放置主導(dǎo)確認(rèn)且頻率是決定性杠桿排除 little 核C只讓預(yù)處理改善 21%因?yàn)?mid 核仍以 910 MHz 空轉(zhuǎn)。把工作集中到一個(gè)核D后schedutil得以維持 2,363 MHz帶來 2.8 倍改善。結(jié)論單靠放置affinity不是解藥持續(xù)的利用率sustained utilization才是。解碼并行值得保留串行解碼B在語料范圍內(nèi)多花 1,135 ms幾乎全部來自兩個(gè)大/平鋪 HEICpano714 → 1,426 ms8606239 → 519 ms普通 HEIC 本就接近串行解碼。而在升頻后的核D上串行 JPEG/PNG/WebP 解碼器反而比基線更快astronaut.png11.6 → 5.0 msui_app.webp121.5 → 79.9 ms。與 iPhone 的對(duì)賬在 13 個(gè)共有 fixture 上iPhone 15 Pro 的預(yù)處理總量約 51 ms。變體 D 把 Pixel 從落后 11.7 倍拉近到約 4.2 倍殘余差距來自真實(shí)的硅片差距單核約 23 倍加上 X3 在推理休眠間隙只維持 2,363 MHz而非 2,914 MHz。07-22 報(bào)告中Pixel 處處慢約 10 倍的讀法被證偽——那是在測(cè)量調(diào)度器行為而非硬件。五、異常與注意事項(xiàng)CR2 平臺(tái)回退失敗IMG_8905.CR2在 C、D 變體中其平臺(tái) JPEG 回退失敗在 A、B 及所有 07-22 運(yùn)行中成功。兩次失敗都發(fā)生在測(cè)試框架開始保留已安裝應(yīng)用持久化應(yīng)用數(shù)據(jù)之后因此首要嫌疑是持久化應(yīng)用數(shù)據(jù)而非親和性覆蓋本身。任何親和性相關(guān)改動(dòng)上線前需針對(duì)性重跑。共有文件分析已剔除該 fixture頭條數(shù)字不受影響。WebGPU 推理波動(dòng)各變體間推理耗時(shí) ±9% 波動(dòng)3,1603,948 ms且無明確排序變體間推理差值應(yīng)視為噪聲。熱狀態(tài)差異本次全程熱狀態(tài) 107-22 為 0但基線 A 仍復(fù)現(xiàn)了 07-22 的語料總量decode 2,772 vs 2,771 ms預(yù)處理 597 vs 653 ms證明埋點(diǎn)與熱狀態(tài)沒有扭曲基準(zhǔn)。logcat 環(huán)形緩沖A/B 的 logcat 各有一個(gè) fixture 的事件在緩沖區(qū)擴(kuò)容到 16 MB 前被驅(qū)逐已由共有文件分析處理。變體 D 的診斷性質(zhì)硬釘一個(gè)核是診斷手段而非可上線配置——它獨(dú)占 X3、無視熱余量、與其他負(fù)載沖突。六、生產(chǎn)建議按預(yù)期價(jià)值排序報(bào)告為生產(chǎn) Android 索引給出的建議按預(yù)期價(jià)值排序停止把管線工作輪轉(zhuǎn)在 FRB 工作線程池上改為在單一持久專用線程上運(yùn)行 ML 管線可選第二線程專用于解碼。這是變體 D 結(jié)論的可上線形態(tài)線程集中才能讓schedutil維持高頻第一步無需任何 pinning。CPU 與 GPU 流水線化在圖像 N 處于Session::run內(nèi)時(shí)同步解碼/預(yù)處理圖像 N1。這一舉兩得完全隱藏預(yù)處理延遲同時(shí)保持工作線程高利用率以維持頻率——還能同時(shí)打擊解碼的 24 倍缺口這是單階段修復(fù)做不到的。采用 ADPFPerformanceHintManager為 ML 工作線程設(shè)置每圖目標(biāo)時(shí)長(zhǎng)。這是 Android 官方針對(duì)突發(fā)型負(fù)載 DVFS問題的既定機(jī)制可替代任何親和性 hack。從rust/crates/ml中移除fast_image_resize的rayonfeature保留heic_decoder自身的 rayon 并行用于解碼。resize 扇出從未回本——B 變體在無它時(shí)預(yù)處理凈更快——且每次分發(fā)還要付出 25 ms 屏障稅。小而安全、立即可做。不要上線 CPU 親和性 pinning除非 CR2 異常得到解決并在爭(zhēng)用/熱負(fù)載下測(cè)試僅當(dāng) 13 項(xiàng)不達(dá)預(yù)期時(shí)才重新考慮。修正 07-22 報(bào)告的跨平臺(tái)表述CoreML 對(duì) WebGPU 的推理差距5.78.8 倍是真實(shí)平臺(tái)差距但預(yù)處理/后處理/解碼差距約 1.62 倍硅片差距 Android 調(diào)度債務(wù)后者可由 14 項(xiàng)回收。報(bào)告對(duì) 124 項(xiàng)組合暫不含推理側(cè)工作的穩(wěn)定態(tài)影響預(yù)估端到端約 1020%本語料上預(yù)處理 597 → 約 210 ms其他103 → 約 60 ms串行解碼 fixture 快 1.52 倍大 HEIC 解碼不變更大的戰(zhàn)略價(jià)值在于CPU 成本不再隨調(diào)度器心情波動(dòng)WebGPU 推理差距成為 Android 唯一的剩余短板。七、結(jié)論性能問題的層級(jí)與取證方法本次驗(yàn)證的完整敘事是Pixel 8 的 CPU 側(cè)慢根因不是硬件、也不是主要來自 rayon 扇出而是 DVFS 與調(diào)度。短 CPU 突發(fā)跟隨長(zhǎng) GPU 休眠、跨約 9 個(gè)線程輪轉(zhuǎn)導(dǎo)致每線程利用率不足、調(diào)度器不提頻基線預(yù)處理長(zhǎng)期運(yùn)行在 38% 的峰值頻率上。將工作集中到單一大核后2.8 倍性能被直接解凍。這一結(jié)論對(duì)移動(dòng)端 ML 工程有普遍方法學(xué)意義跨平臺(tái)基準(zhǔn)必須先排除調(diào)度因素才能討論硅片差距——否則會(huì)把調(diào)度器行為誤讀為硬件差距診斷突發(fā)型負(fù)載性能問題時(shí)同時(shí)采樣放置sched_getcpu與頻率DVFS是不可或缺的一對(duì)觀測(cè)手段修復(fù)方向應(yīng)該是線程集中 CPU/GPU 流水線 ADPF 提示而不是盲目堆并行度或依賴親和性硬釘。相關(guān)產(chǎn)物與深入閱讀本次驗(yàn)證的機(jī)器可讀產(chǎn)物與工具位于 infra/ml/test各變體日志、熱快照與結(jié)果載荷infra/ml/test/out/sched_verification_2026-07-23/{A,B,C,D}/device_logcat.txt與.../{A,C,D}/results.jsonB 的載荷因測(cè)試框架測(cè)試后自動(dòng)卸載而丟失其基準(zhǔn)數(shù)據(jù)完整保留在 logcat 中分析腳本python3 infra/ml/test/tools/analyze_ml_sched_verification.py device_logcat.txt輸出放置、頻率、探針與語料匯總過程文檔20260723_ANDROID_SCHED_VERIFICATION_RUNBOOK.md與本文同目錄。與本主題直接相關(guān)的倉庫源碼與配置rust/crates/ml/Cargo.tomlfast_image_resize的 rayon feature、rayon依賴、Android/iOS 的 ORT provider featurerust/crates/ml/src/preprocess.rsYOLO 輸入預(yù)處理resize letterbox 歸一化rust/crates/ml/src/cv/resize.rs通用圖像 resize 路徑infra/ml/playground/optimizations/README.md模型優(yōu)化流水線GELU 融合、PReLU 改寫等保證同一 ONNX 產(chǎn)物可被 CoreML 與 WebGPU 共用infra/ml/playground/optimizations/benchmark_reports/20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md本文的基線報(bào)告如需復(fù)現(xiàn)基準(zhǔn)可參考 infra/ml/test/run_ml_parity_tests.sh 與 infra/ml/test/README.md 了解 14 圖 ML 一致性語料含man.jpeg、people.jpeg、singapore.jpg等 fixture位于 infra/ml/playground/data的構(gòu)成與運(yùn)行方式?！久赓M(fèi)下載鏈接】ente End-to-end encrypted cloud for everything.項(xiàng)目地址: https://gitcode.com/GitHub_Trending/en/ente創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考