Ente 移动端 ML 调度验证报告DVFS 与线程调度如何让 Pixel 8 的 Rust 预处理慢 2.8 倍以及如何修复【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente导读Ente 的移动端 ML 索引管线人脸检测、CLIP 图像嵌入、人脸特征提取在 AndroidONNX Runtime WebGPU与 iOSCoreML之间存在惊人的端到端差距。2026-07-22 的基准显示 iPhone 15 Pro 在 Rust 预处理上快约 12 倍、串行解码快约 4 倍远超两颗 SoC 之间约 1.62 倍的真实硅片差距。本文基于仓库内的 Android ML 调度验证报告完整复盘其四个受控实验变体、sched_getcpu() DVFS 频率采样等新型埋点、假设验证结论以及按预期价值排序的六条生产落地建议。读完本文你将掌握如何用频率采样与线程集中来诊断突发型负载下 CPU 提频不足这一 Android 移动端性能顽疾以及 Ente 计划如何通过单线程管线、CPU/GPU 流水线、ADPF 等手段回收 2.8 倍预处理性能。一、背景07-22 基准报告中的异常差距验证实验的起点是 20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md。该报告在 Pixel 8Android 17ONNX Runtime WebGPU与 iPhone 15 ProiOS 26.5.2ONNX Runtime CoreML上用同一 14 图语料测得如下稳定态数据设备端到端 14 图每图Rust 总耗时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 管线内快约 4 倍。但分阶段看差距分布极不均匀阶段Pixel 8iPhone 15 Pro差距Decode2,771.0 ms1,169.6 ms~2.4xRust 预处理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—预处理 11.8 倍、后处理 5.5 倍的差距远不能由 WebGPU/CoreML 之间的推理引擎差异5.78.8x属真实平台差距或硅片差异解释。这构成了本次验证实验的直接动机Pixel 的 CPU 侧慢到底慢在硬件、并行度还是调度二、实验设计四个变体与有效性控制验证实验在ort_opt_ios分支HEAD3c9ee2cb76追加基准埋点上进行设备为 Google Pixel 8shiba全部变体满足AOT releaseconnectedIndependentReleaseAndroidTest每轮验证dart.vm.producttrue变体 B 额外通过ML_PARITY_REQUIRE_RELEASEtrue门禁、14 图语料、每图 1 次不计时预热 3 次计时采样、按文件取中位数。每个变体前后设备热状态均为 1轻度跨变体一致因此横向对比内部自洽。四个变体的编译期覆盖与bench_config确认如下变体编译期覆盖bench_config确认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 用于检验 rayon 扇出fan-out是否是预处理瓶颈C 用于检验小核放置的影响D 用于检验线程集中 单大核能否让 DVFS 持续提频。上述ENTE_ML_BENCHMARK_*覆盖开关是基准专用、编译期可选的能力生产构建默认不开启07-22 报告中明确基准日志通过ENTE_ML_BENCHMARK_LOGGING编译期 opt-inAndroid release 埋点通过ENTE_ML_BENCHMARK_RELEASE_TESTS1开启普通构建不受影响。新增的埋点编译出生产构建之外包括在各阶段时钟之外采样sched_getcpu()与 DVFS 频率以及在每次管线之后运行一次空broadcast的 rayon 唤醒延迟探针。三、结果阶段到底跑在哪、跑在多少 MHzPixel 8 的集群拓扑为cpu0-3 Cortex-A510little最高 1.70 GHz、cpu4-7 Cortex-A715mid最高 2.37 GHz、cpu8 Cortex-X3big最高 2.91 GHz。基线 A 下各阶段的实际放置与频率占总阶段时间的份额阶段变体 A放置位置中位频率decode长突发42% mid / 58% bigmid 1,418 MHzbig 2,687 MHz预处理短突发3% little / 61% mid / 37% bigmid910 MHzbig 1,557 MHz后处理µs 级突发98% mid697 MHz这直接测量到了 07-22 分析所预测的模式只有足够长的 decode 突发能在突发中途挣到高频率短促的预处理/后处理突发总是冷启动、冷结束。ML 管线的 CPU 短突发每次跟随约 240 ms 的 GPU 推理休眠在约 9 个工作线程间轮转从未在每个线程上累积出足够的利用率让 Android 调度器提频或迁移到大核。基线预处理大部分时间跑在 mid 核上中位仅910 MHz只有其 2.37 GHz 上限的 38%。变体 D全部工作集中到一个 big 核的效果持续频率升至2,363 MHz语料预处理总耗时从596.7 ms 降至 212.4 ms2.8 倍落入硅片应有的水平区间尽管只用 1 个核而非 9 个核却产生了所有变体中最快的端到端运行。13 个共有 fixture 的语料汇总语料总计msA基线B串行 rayonC无 little 核D串行 1 big 核decode2,772.13,907.52,898.93,194.0Rust 预处理596.7535.9472.2212.4inferenceWebGPU3,349.53,947.73,622.83,159.8Rust 后处理13.68.511.49.6Rust 其他103.0119.0105.462.7Rust 总计6,874.58,536.27,073.96,652.6在变体 D 中同一预处理的每次调用中位数从 15.0 ms 降到5.4 msp90 从 30 ms 降到 10 ms最大值从 81 ms 降到 21 ms。rayon 唤醒探针每次 resize 分发的扇出屏障开销数据显示变体 A 中位数 2.2 ms、p90 4.9 ms且 46% 的池工作线程在小核上唤醒即便在 C全部线程钉到 midbig中仍是 2.4 ms 中位数——说明该开销本质是空闲线程退出延迟而非小核放置问题单线程池D下则骤降至 0.10 ms。四、假设验证H1 被否决H2 被确认H1 — rayon 扇出屏障主导预处理被否决为主因被确认是真实次要成本将池串行化B只回收了约 597 ms 语料预处理中的约 60 ms约 10%且呈双峰分布小图显著受益1343.jpg从 39.6 ms 降至 13.0 ms——纯屏障开销而大图或人脸密集图反而变差pano39.7 → 59.3 mspeople.jpeg74.2 → 84.8 ms因为丢失了真实的并行计算。结论是每次分发的 25 ms 屏障税真实存在但有限。从源码可以印证该扇出的存在ente-mlcrate 的 Cargo.toml 中fast_image_resize { workspace true, features [rayon] }显式启用了 resize 库的 rayon 并行特性且 crate 直接依赖rayon 1.12.0。实际 resize 调用链位于 preprocess.rsYOLO 输入预处理使用fast_image_resize的Resizer与双线性插值以及 cv/resize.rs 等模块。这正是报告中每次 resize 分发的 25 ms 屏障税的代码出处。H2 — 冷核/DVFS 放置主导确认且频率是决定性杠杆排除 little 核C只让预处理改善 21%因为 mid 核仍以 910 MHz 空转。把工作集中到一个核D后schedutil得以维持 2,363 MHz带来 2.8 倍改善。结论单靠放置affinity不是解药持续的利用率sustained utilization才是。解码并行值得保留串行解码B在语料范围内多花 1,135 ms几乎全部来自两个大/平铺 HEICpano714 → 1,426 ms8606239 → 519 ms普通 HEIC 本就接近串行解码。而在升频后的核D上串行 JPEG/PNG/WebP 解码器反而比基线更快astronaut.png11.6 → 5.0 msui_app.webp121.5 → 79.9 ms。与 iPhone 的对账在 13 个共有 fixture 上iPhone 15 Pro 的预处理总量约 51 ms。变体 D 把 Pixel 从落后 11.7 倍拉近到约 4.2 倍残余差距来自真实的硅片差距单核约 23 倍加上 X3 在推理休眠间隙只维持 2,363 MHz而非 2,914 MHz。07-22 报告中Pixel 处处慢约 10 倍的读法被证伪——那是在测量调度器行为而非硬件。五、异常与注意事项CR2 平台回退失败IMG_8905.CR2在 C、D 变体中其平台 JPEG 回退失败在 A、B 及所有 07-22 运行中成功。两次失败都发生在测试框架开始保留已安装应用持久化应用数据之后因此首要嫌疑是持久化应用数据而非亲和性覆盖本身。任何亲和性相关改动上线前需针对性重跑。共有文件分析已剔除该 fixture头条数字不受影响。WebGPU 推理波动各变体间推理耗时 ±9% 波动3,1603,948 ms且无明确排序变体间推理差值应视为噪声。热状态差异本次全程热状态 107-22 为 0但基线 A 仍复现了 07-22 的语料总量decode 2,772 vs 2,771 ms预处理 597 vs 653 ms证明埋点与热状态没有扭曲基准。logcat 环形缓冲A/B 的 logcat 各有一个 fixture 的事件在缓冲区扩容到 16 MB 前被驱逐已由共有文件分析处理。变体 D 的诊断性质硬钉一个核是诊断手段而非可上线配置——它独占 X3、无视热余量、与其他负载冲突。六、生产建议按预期价值排序报告为生产 Android 索引给出的建议按预期价值排序停止把管线工作轮转在 FRB 工作线程池上改为在单一持久专用线程上运行 ML 管线可选第二线程专用于解码。这是变体 D 结论的可上线形态线程集中才能让schedutil维持高频第一步无需任何 pinning。CPU 与 GPU 流水线化在图像 N 处于Session::run内时同步解码/预处理图像 N1。这一举两得完全隐藏预处理延迟同时保持工作线程高利用率以维持频率——还能同时打击解码的 24 倍缺口这是单阶段修复做不到的。采用 ADPFPerformanceHintManager为 ML 工作线程设置每图目标时长。这是 Android 官方针对突发型负载 DVFS问题的既定机制可替代任何亲和性 hack。从rust/crates/ml中移除fast_image_resize的rayonfeature保留heic_decoder自身的 rayon 并行用于解码。resize 扇出从未回本——B 变体在无它时预处理净更快——且每次分发还要付出 25 ms 屏障税。小而安全、立即可做。不要上线 CPU 亲和性 pinning除非 CR2 异常得到解决并在争用/热负载下测试仅当 13 项不达预期时才重新考虑。修正 07-22 报告的跨平台表述CoreML 对 WebGPU 的推理差距5.78.8 倍是真实平台差距但预处理/后处理/解码差距约 1.62 倍硅片差距 Android 调度债务后者可由 14 项回收。报告对 124 项组合暂不含推理侧工作的稳定态影响预估端到端约 1020%本语料上预处理 597 → 约 210 ms其他103 → 约 60 ms串行解码 fixture 快 1.52 倍大 HEIC 解码不变更大的战略价值在于CPU 成本不再随调度器心情波动WebGPU 推理差距成为 Android 唯一的剩余短板。七、结论性能问题的层级与取证方法本次验证的完整叙事是Pixel 8 的 CPU 侧慢根因不是硬件、也不是主要来自 rayon 扇出而是 DVFS 与调度。短 CPU 突发跟随长 GPU 休眠、跨约 9 个线程轮转导致每线程利用率不足、调度器不提频基线预处理长期运行在 38% 的峰值频率上。将工作集中到单一大核后2.8 倍性能被直接解冻。这一结论对移动端 ML 工程有普遍方法学意义跨平台基准必须先排除调度因素才能讨论硅片差距——否则会把调度器行为误读为硬件差距诊断突发型负载性能问题时同时采样放置sched_getcpu与频率DVFS是不可或缺的一对观测手段修复方向应该是线程集中 CPU/GPU 流水线 ADPF 提示而不是盲目堆并行度或依赖亲和性硬钉。相关产物与深入阅读本次验证的机器可读产物与工具位于 infra/ml/test各变体日志、热快照与结果载荷infra/ml/test/out/sched_verification_2026-07-23/{A,B,C,D}/device_logcat.txt与.../{A,C,D}/results.jsonB 的载荷因测试框架测试后自动卸载而丢失其基准数据完整保留在 logcat 中分析脚本python3 infra/ml/test/tools/analyze_ml_sched_verification.py device_logcat.txt输出放置、频率、探针与语料汇总过程文档20260723_ANDROID_SCHED_VERIFICATION_RUNBOOK.md与本文同目录。与本主题直接相关的仓库源码与配置rust/crates/ml/Cargo.tomlfast_image_resize的 rayon feature、rayon依赖、Android/iOS 的 ORT provider featurerust/crates/ml/src/preprocess.rsYOLO 输入预处理resize letterbox 归一化rust/crates/ml/src/cv/resize.rs通用图像 resize 路径infra/ml/playground/optimizations/README.md模型优化流水线GELU 融合、PReLU 改写等保证同一 ONNX 产物可被 CoreML 与 WebGPU 共用infra/ml/playground/optimizations/benchmark_reports/20260722_FINAL_MOBILE_ML_BENCHMARK_REPORT.md本文的基线报告如需复现基准可参考 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的构成与运行方式。【免费下载链接】ente End-to-end encrypted cloud for everything.项目地址: https://gitcode.com/GitHub_Trending/en/ente创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考