Submission Date
2026-07-14
Status
Open
Area
Fans and Heat / Application Slow/Unresponsive
Operating System Version
macOS 27 Developer Beta 3/4 26A5378n/26A5388g
Type
Incorrect/Unexpected Behavior
Description
Original FB:
Note on category: no Feedback Assistant area matches this report precisely. It concerns GPU power management policy (Automatic vs High Power power modes, thermal-driven clock reduction), not fan noise or heat discomfort. Full engineering evidence is in the attached bundle - please start with REPORT.md.
Under Automatic power mode, sustained GPU workloads on this M5 Max degrade 15-65% while every public counter reports a healthy machine. Measured on macOS 27.0 beta (26A5378n), Metal 32023.918, MLX 0.31.2.
Three observed regimes (IOReport/iStat channel): healthy ~1.62 GHz / ~50 W; intermediate 1.05-1.23 GHz / 21-28 W at Graphics 71-73 C; deep ~0.54 GHz / 7.9 W. Throughout all regimes, powermetrics reports an unchanged 1620 MHz, ~99.9% active residency, and Nominal thermal pressure. Back-to-back identical video-inference runs degrade monotonically (497 -> 565 -> 570 s evening; 517 -> 865 -> 998 s morning) with byte-identical outputs. Manually forcing fans to 100% during a degraded episode recovered the clock (1.05 -> 1.23 GHz in 4 min), with recovery lagging behind die temperature.
Working hypothesis (not measured): a stateful controller regulates toward a ~70-75 C die range by reducing effective GPU clock instead of raising fan speed, with slow relaxation. High Power mode fully suppresses the behavior (two stable pipelines at 460.90/462.34 s, stable 51 TFLOP/s sentinels), even though fans were at maximum in both modes - contradicting the documented cooling-only distinction between Automatic and High Power (Apple HT "About Power Modes", confirmed by public macOS 15 measurements).
Two distinct defects: (1) the silent sustained-performance degradation under Automatic; (2) the observability gap - powermetrics frequency/residency/pressure cannot explain a measured 51 -> 38 TFLOP/s transition, so developers cannot diagnose (1).
Steps to reproduce, full measurement reports (six campaigns), raw 1 Hz powermetrics telemetry, timelines, and a self-contained pure-MLX reproducer (repro_sustained_gpu.py) are in the attached bundle. Start with REPORT.md; ATTACHMENTS.md maps every claim to its evidence file. Trigger is state-dependent: most reliably reproduced with repeated sustained runs, stock fan policy, no cooldown, until Graphics reaches ~72 C.
External corroboration: github.com/jundot/omlx/issues/1835 (separate macOS 27 GPU-side regression, M3 Max/M2 Ultra).
Follow-up 1: High Power mode does not prevent the degradation on sustained sessions (1h+).
GPU power dropped below 15 W under High Power with automatic fan curve; fans did not ramp on their own. Manually forcing fans to 100% (~5,500–5,800 rpm) restored GPU power to ~25 W. The fan ramp — High Power's documented purpose — appears not to engage in either mode.
Follow-up 2: during the latest degraded episode (High Power, 1h+ sustained load), fans plateaued at ~2,200 rpm of 5,800 available while GPU power was already reduced below 15 W.
Note that a third-party fan curve MORE aggressive than stock (ramping from ~1,500 rpm at ~55 °C) was active and never engaged higher speeds — because the clock-reduction loop clamps die temperature below any fan curve's ramp thresholds. The regulation priority appears inverted relative to macOS 26 and earlier: clock is reduced first, at temperatures where ~62% of cooling capacity remains unused, instead of cooling first and clock last. No fan curve, stock or third-party, can compensate, since its input signal (temperature rise) is suppressed by the throttling itself.
Follow-up 3:
Still present in 26A5388g — the sustained-GPU downclock / fan-cap / low-thermal-setpoint regulation reproduces and is marginally worse than 26A5378n. One thing did change: powermetrics is no longer blind — on beta 4 it now reports the true collapsed frequency, whereas on beta 3 it reported a constant 1620 MHz / 100 % residency.
Testing on 26A5388g (M5 Max, 16", 128 GB, AC power, Automatic energy mode, fans on the default auto profile), the behavior described in FB23754032 still reproduces, and the regulation itself appears unchanged — if anything slightly more aggressive than on 26A5378n.
Reproduction: Three identical GPU-sustained pipelines run back-to-back with no cooldown, each producing a bit-identical output (verified by SHA-256), so the two states below run the same computation:
| Run |
Wall time |
vs beta 3 (26A5378n) |
| 1 (from ~warm) |
513 s |
497 s |
| 2 (back-to-back) |
642 s |
565 s (+13.6 %) |
| 3 (back-to-back) |
627 s |
570 s |
| 4 (after ~50 min idle, cold) |
457 s |
— |
Ground-truth telemetry (per-run medians, GPU active > 50 %). During the back-to-back runs the GPU collapses while 100 % active and while ~5800 fan rpm is available:
| Run |
GPU freq |
GPU power |
Fan |
GPU die temp |
| 1 |
1119 MHz |
25 W |
3840 rpm |
77 °C |
| 2 |
840 MHz |
16 W |
2902 rpm |
68.8 °C |
| 3 |
847 MHz |
16 W |
2895 rpm |
68.6 °C |
| 4 (cold) |
1230 MHz |
30 W |
4000 rpm |
78 °C |
Deepest sample during run 2: 534 MHz, 8.6 W, fan 3041 rpm, die 68.7 °C, GPU 100 % active.
The priority inversion, quantified. In the collapsed regime the fans hold ~2900 rpm (of ~5800 available) and the die is pinned at ~68.7 °C by dropping the clock to ~840 MHz. When the machine is cold (run 4) the same regulator lets the fans reach ~4000 rpm and the die rise to ~78 °C while sustaining ~1230 MHz. The clock loop overrides the fan loop only after the sustained-load integrator saturates; a ~50-min idle fully resets it (run 4 is the fastest run of the set). This matches the integrator-dynamics model in the original report, now shown directly by the collapsed-vs-cold contrast rather than inferred from timing.
What changed in 26A5388g — powermetrics is no longer blind. On 26A5378n, sudo powermetrics -s gpu_power reported a constant 1620 MHz / 100 % residency under this load (3082 of 3629 samples). On 26A5388g, under the same collapsed load, powermetrics reports the true frequency — "GPU HW active frequency: 543 MHz", residency 486 MHz: 56 %, 636 MHz: 40 %, 1620 MHz: 0 % — and this now agrees with an independent SMC reader (macmon: 543 MHz, 16 W, fan rpm, die temps). So the throttle is finally visible in the system counters; the regulation that causes it is not fixed.
system_profiler divergence (still present). With pmset -a powermode 2 active, system_profiler SPPowerDataType still returns "High Power Mode: No" on this 16", matching the externally reported divergence. Separately, installing 26A5388g reset the AC energy mode from High Power to Low Power (the power-mode preference was not preserved across the update).
Net: the downclocking/fan-priority defect is unchanged (marginally worse) in 26A5388g; the only improvement is that powermetrics now exposes the collapsed frequency instead of masking it behind 1620 MHz/100 %. Raw powermetrics and macmon captures for all four runs are attached.
Follow-up 4:
Additional Follow-up: reproduced with an industry-standard tool (3DMark Steel Nomad Stress Test, 20 loops), single variable = fan policy, same machine, ~30 min apart. Fans auto: monotonic decline on all 20 loops (41.2 -> 32.7 fps, -21%, 79.3% stability) WHILE GPU die temperature fell from 79 to 72 C and system power decayed from 103 to 93 W - performance and temperature falling together, the inverse of thermal throttling. Fans manually at 100%: 91.6% stability, sustained 41.2 fps at a stable ~73 C / 114 W, with loop times IMPROVING monotonically from loop 2 onward - the sustained-load integrator discharging under surplus cooling even during the stress test. Sustained delta +15%, final-loop delta +27.5%. Converted to Steel Nomad scores, the fans-auto run (3982 first loop / ~3460 sustained) matches the publicly reported 14-inch M5 Max case (3983 / 3432) nearly digit-for-digit - on a 16-inch chassis.
Follow-up 5:
Cross-reference: developer forums thread 835131, where this mechanism is now documented from a second machine.
Follow-up 6:
Final follow-up — mechanism confirmed by remediation; the defect itself remains and needs an OS-side fix.
Steepening the third-party fan curve to reach 100% by ~73-74°C (instead of ~97°C) fully restores healthy sustained behavior in BOTH power modes, with zero manual intervention. 3DMark Steel Nomad Stress Test, 20 loops each:
- High Power + recalibrated curve: 98.05% stability (PASS), sustained ~4325, best loop 4402.
- Automatic + recalibrated curve: 97.96% stability (PASS), sustained ~4372 (within 0.5% of the 4392 launch-review reference), best loop 4453 — exceeding the launch figure. This is the same Automatic mode that produced the monotonic 517 -> 865 -> 998 s degradation and the 0.54 GHz collapse documented in this report.
Dual-channel telemetry attached for both runs. Chronology is identical in both: die crosses 73°C within 3-5 s of load start, fans auto-ramp 2,300 -> 5,800 rpm within ~10 s, die then holds 79-81°C with GPU sustained at ~1.52 GHz / 60 W and total power at 135.5 W for the full 17-minute runs. The clock reduction never engages. Note also that under this curve, Automatic and High Power become indistinguishable again (~1% apart) — the documented historical semantics of the power modes, restored externally.
To be explicit: this is a bypass, not a fix. The defective policy — reducing GPU clock below a die-temperature threshold without ever consulting available fan headroom — remains in the OS, along with its load-integrator behavior.
The bypass merely makes its trigger condition unreachable, at the cost of sustained maximum fan noise and an ambient-temperature-dependent margin, and it does nothing for the broken per-domain power attribution (CPU/ANE still report 0 W under load on 26A5388g). The regulation-priority fix — cooling before clock, as on macOS 26.4 and earlier — has to come from Apple.
Follow-up 7 - final (solution for mitigation)
Pipeline workload under the remediation. With a recalibrated fan curve (100 % at ~73–74 °C) on 26A5388g in Automatic mode, a sustained conv-heavy GPU pipeline (the same back-to-back triple run that previously degraded 497→565→570 s under the stock curve) now holds 431 → 421 → 417 s — grouped and decreasing, no accumulation. Per-phase ground-truth telemetry (macmon) confirms the compute-bound phases hold full frequency (≈1490 MHz / ≈1440 MHz, sustained-min > 1.4 GHz) with fans pinned at max (5777 rpm) and the die at 77–79 °C — i.e. the sustained-load clock collapse is gone once the fan loop is allowed to evacuate heat. Notably, the mean 423 s sits ~1 % above the pre-regression June (macOS 26.4) baseline of 418.7 s, indicating the earlier ~10 % "beta tax" measured under forced
fans-max on the stock curve was thermal-regulation residual, not a Metal/MLX compute regression — the workload returns to baseline throughput at verified-full frequency. This corroborates, from a real application workload, that the defect is a fan/clock-priority regulation issue, not a compute-path change. (Single-day, ambient uncontrolled; indicative pending the September stable re-baseline.)
Keywords
GPU, thermal, regulation, throttling
Prerequisites
Submission Date
2026-07-14
Status
Open
Area
Fans and Heat / Application Slow/Unresponsive
Operating System Version
macOS 27 Developer Beta 3/4 26A5378n/26A5388g
Type
Incorrect/Unexpected Behavior
Description
Original FB:
Note on category: no Feedback Assistant area matches this report precisely. It concerns GPU power management policy (Automatic vs High Power power modes, thermal-driven clock reduction), not fan noise or heat discomfort. Full engineering evidence is in the attached bundle - please start with REPORT.md.
Under Automatic power mode, sustained GPU workloads on this M5 Max degrade 15-65% while every public counter reports a healthy machine. Measured on macOS 27.0 beta (26A5378n), Metal 32023.918, MLX 0.31.2.
Three observed regimes (IOReport/iStat channel): healthy ~1.62 GHz / ~50 W; intermediate 1.05-1.23 GHz / 21-28 W at Graphics 71-73 C; deep ~0.54 GHz / 7.9 W. Throughout all regimes, powermetrics reports an unchanged 1620 MHz, ~99.9% active residency, and Nominal thermal pressure. Back-to-back identical video-inference runs degrade monotonically (497 -> 565 -> 570 s evening; 517 -> 865 -> 998 s morning) with byte-identical outputs. Manually forcing fans to 100% during a degraded episode recovered the clock (1.05 -> 1.23 GHz in 4 min), with recovery lagging behind die temperature.
Working hypothesis (not measured): a stateful controller regulates toward a ~70-75 C die range by reducing effective GPU clock instead of raising fan speed, with slow relaxation. High Power mode fully suppresses the behavior (two stable pipelines at 460.90/462.34 s, stable 51 TFLOP/s sentinels), even though fans were at maximum in both modes - contradicting the documented cooling-only distinction between Automatic and High Power (Apple HT "About Power Modes", confirmed by public macOS 15 measurements).
Two distinct defects: (1) the silent sustained-performance degradation under Automatic; (2) the observability gap - powermetrics frequency/residency/pressure cannot explain a measured 51 -> 38 TFLOP/s transition, so developers cannot diagnose (1).
Steps to reproduce, full measurement reports (six campaigns), raw 1 Hz powermetrics telemetry, timelines, and a self-contained pure-MLX reproducer (repro_sustained_gpu.py) are in the attached bundle. Start with REPORT.md; ATTACHMENTS.md maps every claim to its evidence file. Trigger is state-dependent: most reliably reproduced with repeated sustained runs, stock fan policy, no cooldown, until Graphics reaches ~72 C.
External corroboration: github.com/jundot/omlx/issues/1835 (separate macOS 27 GPU-side regression, M3 Max/M2 Ultra).
Follow-up 1: High Power mode does not prevent the degradation on sustained sessions (1h+).
GPU power dropped below 15 W under High Power with automatic fan curve; fans did not ramp on their own. Manually forcing fans to 100% (~5,500–5,800 rpm) restored GPU power to ~25 W. The fan ramp — High Power's documented purpose — appears not to engage in either mode.
Follow-up 2: during the latest degraded episode (High Power, 1h+ sustained load), fans plateaued at ~2,200 rpm of 5,800 available while GPU power was already reduced below 15 W.
Note that a third-party fan curve MORE aggressive than stock (ramping from ~1,500 rpm at ~55 °C) was active and never engaged higher speeds — because the clock-reduction loop clamps die temperature below any fan curve's ramp thresholds. The regulation priority appears inverted relative to macOS 26 and earlier: clock is reduced first, at temperatures where ~62% of cooling capacity remains unused, instead of cooling first and clock last. No fan curve, stock or third-party, can compensate, since its input signal (temperature rise) is suppressed by the throttling itself.
Follow-up 3:
Still present in 26A5388g — the sustained-GPU downclock / fan-cap / low-thermal-setpoint regulation reproduces and is marginally worse than 26A5378n. One thing did change:
powermetricsis no longer blind — on beta 4 it now reports the true collapsed frequency, whereas on beta 3 it reported a constant 1620 MHz / 100 % residency.Testing on 26A5388g (M5 Max, 16", 128 GB, AC power, Automatic energy mode, fans on the default auto profile), the behavior described in FB23754032 still reproduces, and the regulation itself appears unchanged — if anything slightly more aggressive than on 26A5378n.
Reproduction: Three identical GPU-sustained pipelines run back-to-back with no cooldown, each producing a bit-identical output (verified by SHA-256), so the two states below run the same computation:
Ground-truth telemetry (per-run medians, GPU active > 50 %). During the back-to-back runs the GPU collapses while 100 % active and while ~5800 fan rpm is available:
Deepest sample during run 2: 534 MHz, 8.6 W, fan 3041 rpm, die 68.7 °C, GPU 100 % active.
The priority inversion, quantified. In the collapsed regime the fans hold ~2900 rpm (of ~5800 available) and the die is pinned at ~68.7 °C by dropping the clock to ~840 MHz. When the machine is cold (run 4) the same regulator lets the fans reach ~4000 rpm and the die rise to ~78 °C while sustaining ~1230 MHz. The clock loop overrides the fan loop only after the sustained-load integrator saturates; a ~50-min idle fully resets it (run 4 is the fastest run of the set). This matches the integrator-dynamics model in the original report, now shown directly by the collapsed-vs-cold contrast rather than inferred from timing.
What changed in 26A5388g —
powermetricsis no longer blind. On 26A5378n,sudo powermetrics -s gpu_powerreported a constant 1620 MHz / 100 % residency under this load (3082 of 3629 samples). On 26A5388g, under the same collapsed load,powermetricsreports the true frequency — "GPU HW active frequency: 543 MHz", residency 486 MHz: 56 %, 636 MHz: 40 %, 1620 MHz: 0 % — and this now agrees with an independent SMC reader (macmon: 543 MHz, 16 W, fan rpm, die temps). So the throttle is finally visible in the system counters; the regulation that causes it is not fixed.system_profilerdivergence (still present). Withpmset -a powermode 2active,system_profiler SPPowerDataTypestill returns "High Power Mode: No" on this 16", matching the externally reported divergence. Separately, installing 26A5388g reset the AC energy mode from High Power to Low Power (the power-mode preference was not preserved across the update).Net: the downclocking/fan-priority defect is unchanged (marginally worse) in 26A5388g; the only improvement is that
powermetricsnow exposes the collapsed frequency instead of masking it behind 1620 MHz/100 %. Rawpowermetricsand macmon captures for all four runs are attached.Follow-up 4:
Additional Follow-up: reproduced with an industry-standard tool (3DMark Steel Nomad Stress Test, 20 loops), single variable = fan policy, same machine, ~30 min apart. Fans auto: monotonic decline on all 20 loops (41.2 -> 32.7 fps, -21%, 79.3% stability) WHILE GPU die temperature fell from 79 to 72 C and system power decayed from 103 to 93 W - performance and temperature falling together, the inverse of thermal throttling. Fans manually at 100%: 91.6% stability, sustained 41.2 fps at a stable ~73 C / 114 W, with loop times IMPROVING monotonically from loop 2 onward - the sustained-load integrator discharging under surplus cooling even during the stress test. Sustained delta +15%, final-loop delta +27.5%. Converted to Steel Nomad scores, the fans-auto run (3982 first loop / ~3460 sustained) matches the publicly reported 14-inch M5 Max case (3983 / 3432) nearly digit-for-digit - on a 16-inch chassis.
Follow-up 5:
Cross-reference: developer forums thread 835131, where this mechanism is now documented from a second machine.
Follow-up 6:
Final follow-up — mechanism confirmed by remediation; the defect itself remains and needs an OS-side fix.
Steepening the third-party fan curve to reach 100% by ~73-74°C (instead of ~97°C) fully restores healthy sustained behavior in BOTH power modes, with zero manual intervention. 3DMark Steel Nomad Stress Test, 20 loops each:
Dual-channel telemetry attached for both runs. Chronology is identical in both: die crosses 73°C within 3-5 s of load start, fans auto-ramp 2,300 -> 5,800 rpm within ~10 s, die then holds 79-81°C with GPU sustained at ~1.52 GHz / 60 W and total power at 135.5 W for the full 17-minute runs. The clock reduction never engages. Note also that under this curve, Automatic and High Power become indistinguishable again (~1% apart) — the documented historical semantics of the power modes, restored externally.
To be explicit: this is a bypass, not a fix. The defective policy — reducing GPU clock below a die-temperature threshold without ever consulting available fan headroom — remains in the OS, along with its load-integrator behavior.
The bypass merely makes its trigger condition unreachable, at the cost of sustained maximum fan noise and an ambient-temperature-dependent margin, and it does nothing for the broken per-domain power attribution (CPU/ANE still report 0 W under load on 26A5388g). The regulation-priority fix — cooling before clock, as on macOS 26.4 and earlier — has to come from Apple.
Follow-up 7 - final (solution for mitigation)
Pipeline workload under the remediation. With a recalibrated fan curve (100 % at ~73–74 °C) on 26A5388g in Automatic mode, a sustained conv-heavy GPU pipeline (the same back-to-back triple run that previously degraded 497→565→570 s under the stock curve) now holds 431 → 421 → 417 s — grouped and decreasing, no accumulation. Per-phase ground-truth telemetry (macmon) confirms the compute-bound phases hold full frequency (≈1490 MHz / ≈1440 MHz, sustained-min > 1.4 GHz) with fans pinned at max (5777 rpm) and the die at 77–79 °C — i.e. the sustained-load clock collapse is gone once the fan loop is allowed to evacuate heat. Notably, the mean 423 s sits ~1 % above the pre-regression June (macOS 26.4) baseline of 418.7 s, indicating the earlier ~10 % "beta tax" measured under forced
fans-max on the stock curve was thermal-regulation residual, not a Metal/MLX compute regression — the workload returns to baseline throughput at verified-full frequency. This corroborates, from a real application workload, that the defect is a fan/clock-priority regulation issue, not a compute-path change. (Single-day, ambient uncontrolled; indicative pending the September stable re-baseline.)
Keywords
GPU, thermal, regulation, throttling
Prerequisites
FB<number>: <title>