The Horace experiment: the same matmul draws 38 to 63 W depending on the data

20–22 September 2026, checked on three cards on 26 September · aifoundry2 (sections 1–9); aifoundry3 and card 1 of aifoundry1 (aifoundry1-c1) in section 10 and beside the claims the check re-measured · fp32 TensorFMA on all 1,024 minions · workloads/sparsity, tools/ettelem, rtl-sim/fma_toggle · part of the ET-SoC-1 measurement reports

Horace He's post "Strangely, Matrix Multiplications on GPUs Run Faster When Given 'Predictable' Data!" (April 2024) found that an A100 multiplies matrices of zeros about 15% faster than random ones (295 against 257 TFLOPS): predictable data flips fewer transistors, draws less power, and a power-limited GPU then clocks higher. On this chip the whole chain can be taken apart, because the RTL (the Verilog source) of its core family's multiply-add unit is open. At the same clock and the same 9.2 TFLOPS, a matmul on aifoundry2's card draws 38 W on zeros, 47 W on ones and 63 W on random values (the other cards' watts are in the figures below). It heats the die roughly in proportion to the watts above idle (12 and 30 W): 27 and 76 thousandths of a degree per trillion FLOPs on ones and random values. Zeros, 2 W above idle, move the whole-degree reading by at most one step, so their rise is not resolved (section 1). It follows the sparse compute report, whose first two runs, on aifoundry3, found that zeros save most of the tensor unit's power but no cycles.

Simulating that RTL (core-et's Erbium branch: the same Minion core lineage in a later configuration, not the taped-out netlist) on the operands the card ran explains the watts: register bits clocked and nets toggled predict the board power of 14 patterns to 0.5 W rms in aifoundry2's session of 21 September, each predicted by a fit that left it out (0.9 to 1.0 W on each card's patterns of 26 September). A thermal network fitted to the same session then turns watts into the temperature curve to about 0.3 °C rms, which is what the sensor's rounding to whole degrees alone would leave. Horace's speed effect itself needs a die cool enough for the governor to raise the clock; section 6 shows it in a demonstration of seven runs on aifoundry2, the only card measured here whose governor raised the clock.

Run for minutes instead of seconds, only zeros hold a steady temperature at full load (aifoundry2, one four-hour session): random data takes the die from 80 to 90 °C in 19 to 26 s (four runs), ones in about two minutes (three runs). A three-line model (flip rates to watts, leakage that grows with temperature, a thermal network) predicts those times from the flip counts, on runs it was not fitted to, to within a quarter; at ten minutes it runs a few degrees hot near the card's flip budget. It priced 14 structured matrices, from Hadamard to kaleidoscope, before they ran. On two more cards the power model needs at most one scale factor, which a random-data run calibrates: 0.88 to 0.99 as registered, 0.93 to 1.00 at the same die temperature; whether aifoundry3's is the card or its cooler die the check could not say (section 10). The thermal network is aifoundry2's alone: no other card's cooling over minutes was measured.

1. Same FLOPs, different heat

All 1,024 minions (the chip's compute cores, 32 to a shire; the chip has 1,088 in 34 shires, and the two not used here are the master and spare shires) each run one 16×16×16 fp32 TensorFMA (the tensor unit's matrix multiply-add) over and over, on operands held in the L1 scratchpad (3 KB of each minion's 4 KB data cache). Every pattern takes 546.0 cycles per op at 600 MHz, so every run does the same 9.18 × 10¹² FLOPs per second, 6.7 × 10¹³ in its 7.3 s. Only the values in A and B differ. Six patterns ran five times each; eight more ran twice each for the model in section 3. Sections 1 to 9 are aifoundry2's card; section 10 repeats these 7 s runs on aifoundry3 and aifoundry1-c1, and where another card's values differ the text gives them.

2. Strict temperature control

Two things make temperature a confound on this card. Power at the same work rises with die temperature through leakage: about 0.8 W per °C on the board while a hot pattern runs, measured from the drift of power within the hot 7 s runs (82–86 °C; measured the same way on 26 September, 0.80 W/°C [0.59, 1.00] on aifoundry2 and 0.80 [0.75, 0.85] on aifoundry1-c1, but 0.38 [0.29, 0.48] on aifoundry3, whose runs start at 57 °C; over minutes of a long matmul the check's busy slope is steeper, 1.0 [0.7, 1.4] W/°C on aifoundry2 at 81 to 97 °C, 1.1 [1.0, 1.2] on aifoundry1-c1 and 0.6 [0.5, 0.7] on aifoundry3); the idle law's slope is 0.65 W/°C at 80 °C (section 8). And on aifoundry2 the firmware's clock governor has a 65 °C threshold: below it a busy card is clocked up to 800 MHz at 0.62 V, above it the card is held at 600 MHz and 0.52 V (section 6). So every run starts from the same thermal state, well above that threshold:

3. From flips to watts

The power differences come mostly from the fused multiply-add units, eight per minion, one per vector lane: the minion rail carries 73% of the difference between random data and zeros on aifoundry2 and 79% on aifoundry3. The open RTL of this core family (core-et, Erbium branch at b38a1a3, a later configuration of the same Minion core lineage) includes that unit (txfma_top, seven pipeline stages) and the control around it. rtl-sim/fma_toggle runs eight copies under Verilator on the exact operand tiles the card ran (the host dumps them), in the order the tensor state machine issues them: for each row of B, for each row of A, two micro-ops of eight c = a·b + c; 512 micro-ops per op. Every result is checked: all 8,192 multiply-adds of two random-data ops match software bit for bit. Three things in the RTL decide the activity:

• Zero gating. On an accumulate pass, vpu_ctrl.v withholds the valid bit from a lane whose A or B operand word is zero (ex_fma_gate_mask; the manual's pseudo-code says the same, if (a != 0 && b != 0)). The unit's pipeline registers are enabled by their stage's valid bit, so a gated lane clocks no register and flips no net. That is the zeros case: in the simulation nothing in the unit moves, and a zeros matmul costs only about 2 W over idle (aifoundry2 and aifoundry3, 20–22 September; 1.9, 0.8 and 1.2 W on aifoundry2, aifoundry3 and aifoundry1-c1 on 26 September).
• Clocked registers. A valid multiply-add clocks about 600 register bits per lane on its way down the pipe, whether or not the data changed. That is what a constant costs: ones and π clock the registers and toggle almost nothing. (The checkerboard keeps a quarter of its lanes: a product needs both operands nonzero.)
• Data toggles. Random operands flip about 87 million counted nets per op, 85% of them in the multiplier tree (Booth encoders, carry-save adders, 4:2 compressors). Sign-only or exponent-only randomness leaves that tree still and moves only the exponent path, the aligner and the adder.

4. From watts to degrees

The die's temperature follows power through a thermal network. A Foster chain (RC stages in series) with time constants fixed on a grid from 1.5 s to 1,000 s was fitted to the whole hour: board power in, sensor reading out, resistances held non-negative. On aifoundry2 two stages carry everything this session can see.

With both steps in hand, the chain runs from the RTL to the thermometer with no measurement of the run in between. For each run the network starts from the state the hour's measured power had left it in at launch. From there it is driven by the activity model's power for that pattern (from the fit that left that pattern out), plus 0.81 W for every degree the simulated die has gained: leakage, measured from the drift of power within the hot runs.

5. Where the model is off, and why

1. Most of the power is not flips of this computation. Of random normal's 63.4 W, 38.6 W is the model's constant: what the card draws at 80 °C with every multiply-add gated (each card's refit of 26 September puts it at 38.3 W on aifoundry2, 51.3 W on aifoundry1-c1 at the same temperature and 26.6 W on aifoundry3 at 55.8 °C). Idle is 36.3 W of it: leakage, always-on clocks, DDR, PCIe and regulator losses. The other 2 W is what a fully gated tensor op costs (the zeros of section 3); by the RTL, it is the 1,024 tensor state machines stepping through gated micro-ops.
2. Register clocking is switching that the data does not control, except by being zero (section 3's constant). "Proportional to flips" holds only once clock edges delivered to registers count as flips.
3. A counted toggle is not a fixed charge. The fitted energies differ 25-fold between the multiplier tree and the rest of the unit. RTL net counts stand in for capacitance only within blocks of similar structure; a netlist with extracted capacitances would replace three fitted numbers with none. The zero-delay simulation also has no glitches. Real carry-save trees glitch, more so on random data, and the fitted energies absorb the average.
4. Leakage feeds back. On aifoundry2 (21 September) random normal reads 65.8 W in seconds 1 to 3 and 68.0 W in the last two seconds of the same run: + W as its own heating lifts the reading another °C between those windows ( °C over the whole run). The model's watts are at the launch temperature, and the chain adds 0.81 W per simulated degree. Without that term it would under-predict the hot patterns' rise by about a tenth.
5. The sensor. One whole-degree number stands for the mean of 34 sensors. The launch temperature is known to a few tenths of a degree in absolute terms, the same for every run, which matters only for the three coolest patterns. The hot spots are the multiply-add units, not the sensors, so the junctions that leak are presumably hotter than the reading. The sensors' peak-hold high puts the hottest of the 34 at 2–4 °C above their mean at each rise (the spatial brief), but nothing on the card measures a junction inside a shire.
6. Board power is not die power. Of the 7 W of random normal's excess that is on no rail sensor (section 1), by the later attribution (Limits of observability, §4.2) about 4.4 W of that is consistent with regulator delivery loss, which would never reach the die, and the rest is not attributed. The network was fitted to board power, so it absorbs whatever does not heat the die as fewer °C per W. It would not transfer to a workload that loads a different rail.
7. What is left, on aifoundry2. Power: 0.5 W rms out of sample, 0.9 W at worst (section 3). Rise: 0.33 °C rms from the RTL alone against 0.30 °C from the measured power, both fit residuals of this session (aifoundry3, with its own refit and network: 0.35 against 0.32 °C). So almost all of the temperature error belongs to the thermal step and the sensor, not to the flips.

6. The speed effect on a cool die: a demonstration

This section is one card, aifoundry2, and seven runs on the morning of 21 September: two of zeros, two of ones and three of random normal, in two short sessions. On aifoundry2 the firmware's governor steps the clock down while the whole-degree die reading is above 65 °C or board power is above 65 W (its TDP setting, the board power limit), so it holds 600 MHz at 0.52 V on a hot die and lifts a cooler busy card to 700–800 MHz (The DVFS loop and its leakage, §1–§2). Every run on 20 September started above 72 °C, so the thermal test held 600 MHz throughout, even at 70 W. After the night of 20–21 September idle the die read 62 °C, and the same kernels behaved differently:

So in these seven runs predictable data did run faster: 25% for zeros against random values, where Horace measured 15% on an A100. With two zeros runs against three random ones that is a demonstration, not an established effect, though the clock record shows the mechanism in every run. The reason is the one he gave: fewer flips, less power, and a governor that then allows a higher clock. Here the limit that bites first is thermal rather than electrical, and it only applies to a die that starts below 65 °C. A card that has been busy idles above that (72 °C on 20 September; the runs of section 1 were held at 80 °C), runs everything at 600 MHz, and shows the effect as heat instead of speed. Nor are the seven runs a controlled experiment: their start temperatures differ by up to 2 °C, and a die that has just run does not return to 62 °C for hours. aifoundry3 cannot show the effect at all (its clock is pinned: section 10). Nor can aifoundry1-c1, although it has aifoundry2's governor settings (65 W, 65 °C): its governor does not raise the clock. The three-card check ran it cool, busy and under 65 W in 9,461 samples (die at 64 °C or less, board at 45–65 W), where aifoundry2's governor steps up, and it read 600 MHz in all 318,667, as did the service processor's own minimum and maximum of the clock, which a statistics reset does not clear.

7. Minutes instead of seconds

Seven seconds show the first two stages of the heating. To see the rest, the same patterns ran on aifoundry2 as single processes for up to ten minutes each, in one session on 21 September, from the same start: heat to 84 °C if below, idle until the sensor first reads 80 °C, launch. Most configurations ran once; the counts are given below. A run ends early when the die's mean reading reaches 90 °C, which keeps it inside what this card had already seen (on 20 September the mean reading had reached 90 °C and the hottest sensor 93 °C, at up to 70 W; the three-card check of 26 September later held it at a mean of up to 103 °C with nothing on the card acting: Power and temperature, §2). 29 runs took four hours, because after a hot run the die needs up to seven minutes to get back to 80 °C. Some runs used fewer minions per shire, which scales the flip rate without changing the flips themselves (and the switching power only roughly in proportion: per active minion it is about 5% higher on 1,024 minions than on 256 in the ablation session of 21 September, and 9, 24 and 25% higher on aifoundry2, aifoundry3 and aifoundry1-c1 in the three-card check of 26 September).

8. A model from flips to temperature

With the long runs the chain of sections 3 and 4 closes into one model that needs only the flip schedule. It is aifoundry2's model, fitted to that card's sessions of 21 September, and it has three lines:

The flip budget of this card. Setting the heat line to its steady state gives the curve above: for each switching power, the temperature at which the die would settle (solid) and the temperature above which it runs away (dashed). The two meet at +3.1 W of switching (2.6 W by the model fitted to the first half of the session), with the die at 82 °C: beyond that there is no equilibrium on this card's cooling, only a time to 90 °C. Single long runs agree: 2.7 W (ones on 256 minions) cooled, 3.4 W (random on 128 minions) sat at 81 to 82 °C for ten minutes, 4.2 W (the checkerboard) crept to 87 °C. In flips, 3.1 W is about 10¹⁵ clocked register bits per second, or a full-load random matmul 11% of the time.

The budget belongs to this card, this desktop chassis and that day's room. The model's ambient is 22.8 °C, and every degree warmer takes 0.68 W off the budget. On 22 September the same card idled at 73 °C instead. By these equations that is a room about 3.5 °C warmer, or airflow worse by the same measure, and a budget of 0.3 to 0.7 W; the ambient slider of the pricer in section 9 redraws the chart above for any room. Whether the flip energies belong to the chip design is the question of section 10: on three cards they carry over up to one scale factor per card, which the check could not separate from the die temperature. The idle law does not carry over: aifoundry1-c1 idles 7.6 to 13.4 W above it.

9. Custom workloads: structured matrices

A predictor for custom workloads. tools/ettelem/predict_heat.py wraps the three lines of section 8: give it the A and B tiles of a workload (or a pattern name), the number of active minions and a start temperature, and it replays the tiles through the RTL, counts the flips, and prints the switching watts by kind of flip, the board power, the temperature after 10 s, 1 min and 10 min, the time to a cap, and the duty cycle that would hold the start temperature. The matrices below test it.

• Predicted to 0.9 W rms over a 25 W range, and ten of the fourteen to within 0.6 W (eleven within 0.75 W), from the tiles alone (aifoundry2, 21 September, two runs each). The three-card check re-ran six of them on 26 September, four runs each. On aifoundry2 Hadamard, butterfly and kaleidoscope came within 0.5 W of their first values (−0.1, 0.0 and −0.5 W), though four runs are too few to confirm Hadamard and kaleidoscope to the registered ±1 W; on aifoundry3 they read 0.6 to 1.2 W below the model scaled by 0.924, that card's factor of 22 September (the registered test).
• Structure in the values buys nothing. Kaleidoscope products, the DCT, circulant and rank-1 matrices are dense, and they cost what random normal costs (63 to 64 W): their mantissa bits are just as busy. Re-run on three cards, kaleidoscope products again cost what random normal costs: 63.5 against 63.6 W on aifoundry2, 50.3 against 50.4 W on aifoundry3 and 77.8 against 77.9 W on aifoundry1-c1. The Hadamard matrix costs 50 W, close to random signs (1.8 to 2.1 W below them on each of the three cards): only the sign and the adder move.
• Structure in the zeros buys a lot. A pair of butterfly factors (two nonzeros per row, so 64 of 4,096 products survive the gating) costs 39.3 W, the identity 38.5 W, tridiagonal 40.2 W, 4×4 blocks 41.1 W, upper-triangular 44.4 W (the butterfly pair, re-run on three cards, costs 1.0, 0.9 and 1.0 W more than zeros on aifoundry2, aifoundry3 and aifoundry1-c1). The ReLU pair, random weights times half-zero activations, gates half its products and saves 11 of random data's 27.6 W over idle (random normal was rerun in the same 7 s session as the structured matrices; re-run on three cards, it saves 10.9 of 27.2 W on aifoundry2, 10.4 of 24.7 W on aifoundry3 and 11.5 of 27.8 W on aifoundry1-c1).
• Negative zero is not zero. The gating looks for the all-zero bit pattern, so a matrix of −0.0 clocks every register: 46.7 W, the same as ones, against 38.2 W for +0.0 (also rerun in that session). The model said 47.2 W. On 26 September −0.0 cost 8.4, 8.1 and 8.9 W more than +0.0 on aifoundry2, aifoundry3 and aifoundry1-c1, and within 0.2 W of ones on each; four runs confirm the equality with ones to ±1 W on aifoundry2 only (the intervals on the other two reach −1.1 and −1.4 W). In practice: mask with a select, not by multiplying by zero, because x · 0 is −0.0 for every negative x.
• The worst miss is the DFT pair, 2.8 W low, and it repeats: re-run on 26 September it read 2.7 W above the model on aifoundry2, 2.5 W above it on aifoundry1-c1 and 1.7 W above the model scaled by that 0.924 on aifoundry3. Its products cancel almost exactly; why that costs more than the counted toggles say is not known (glitching in near-cancelling sums, which a zero-delay simulation cannot see, is one candidate).

And the heat, not just the watts. Six of the structured matrices, with ones and random normal as references, then ran as long runs, one run each, in a separate afternoon session on aifoundry2 (section 7's protocol), with the model frozen as fitted that morning, before they existed on the card. Nothing was fitted on that session: the thermal state at each launch comes from the observer of section 8, from telemetry before the launch only. (The ones run opened the session, so the observer had fewer than three minutes of telemetry before it; it is not in the table.)

Four of the six times to 90 °C are within 3%, and the five-minute run's end temperature is off by 0.2 °C. The DFT pair is wrong by two thirds, because its watts are: 2.8 W missing out of 13 W of switching costs 47 s on a die this close to runaway. The ReLU pair is a third slow for a 1.2 W miss. Near the card's flip budget the time to a cap is a sensitive function of power, so a watt of model error matters; at full random load it does not (19.5 s predicted, 19.1 s measured). With the first-half model of section 8 instead, the same six come out at 7% in the median and 65% for the DFT pair.

10. Other cards, and what transfers

Everything to this point is aifoundry2's card. Two more cards have run the same 7 s protocol. aifoundry3's ran it on 22 September, in one 13-minute session; on 26 September the three-card check re-ran eight of the operand patterns, four runs each, on aifoundry2, aifoundry3 and card 1 of aifoundry1 (aifoundry1-c1; card 0 was left out because its cooling could not hold a load then; its broken fan was replaced on 2 October). The two newcomers differ from aifoundry2 in useful ways. aifoundry3 idles cool (51 °C before its first session, against aifoundry2's 62 to 73 °C), too cool to hold at 80 °C between runs, so its runs launch at 55 to 58 °C; and it stays pinned at 600 MHz, because a boot service sets its TDP to 0 W at every boot, so the governor can only step down (The ET-SoC-1's DVFS loop, and the leakage). aifoundry1-c1 launches at aifoundry2's 80 °C, but runs older firmware (1.2.0 against 1.3.1), holds its minions at 498 mV under load against aifoundry2's 517 mV, and idles at 50 W against 36 W. Different silicon, heatsinks and firmware, with coefficients fitted entirely on aifoundry2, make this the strongest out-of-sample test of the power model.

The card, or its temperature? aifoundry3's factor could come from its silicon, package or regulator, or from the 23 °C cooler die its runs start from. The check tested this directly (V3-X5): each card ran fp32 uniform and random data at two launch temperatures about 7 °C apart (aifoundry2 at 83 and 77 °C, aifoundry1-c1 at 83 and 76 °C, aifoundry3 at 65 and 58 °C), three runs of each, and asked whether the switching power is the same at both, within ±0.5 W. On none of the three cards could that be shown, and the test did not find the cause either. On random normal the hotter launch switched more on aifoundry2, +1.2 W [+0.3, +2.1], and on aifoundry3, +2.0 W [+1.5, +2.5], as a temperature effect would; computed with each run's own launch temperature instead of the arm's registered one (a check that was not registered), both shrink to +0.7 W, with intervals that include zero. Uniform data could not be read on any card, nor anything on aifoundry1-c1: the idle power measured in the two seconds before a run, which is subtracted from it, moved. Uniform data ran first in every arm, straight after the preheat, and in the hot arms the preheat inflated the idle reading before it: 41 to 51 W on aifoundry2 and 37 to 39 W on aifoundry3, against 38 to 39 W and 29 to 34 W before their other hot runs. Hot uniform data therefore read 7 W lower than cool on both cards, which says nothing about the data; this, not the physics, is what failed the uniform half of the test. On aifoundry1-c1 the idle before a run ranged from 46 to 69 W over both arms, and its switching values scatter by up to 11 W, some below zero. The registered verdict is "not separated". A second test of the same question, on the energy catalogue (V3-CAT), found per-event energies rising with die temperature on both cards it was registered for, 0.48 %/°C [0.07, 0.90] on aifoundry2 and 0.30 %/°C [0.18, 0.42] on aifoundry3; and aifoundry1-c1, at aifoundry2's temperature, needs almost no factor. Temperature contributes, but how much of aifoundry3's deficit (10% below aifoundry2 in the same check) it accounts for is not established. Most of that 10% is the reduction, not the card (post-data note C2): the registered values move each run's power to a fixed reference (80.9 °C; 55.8 °C for aifoundry3) but subtract idle read at the run's actual launch (whole-degree readings averaging 80.2, 57.4 and 80.0 °C on these patterns). The references are thermal-model temperatures at launches made on a downward step of the reading, so the die at these launches was at the reading or up to 0.96 °C above it, and the reading cannot say which; over that range, at the same die temperature aifoundry3 switches 0.958–0.969 of aifoundry2 (3–4% less; aifoundry1-c1 1.004 against 1.009 registered), as the energy catalogue's independent ratio, 0.972, found.

The two-temperature test, drawn. Each card launched the same patterns at two temperatures about 7 °C apart.

The operating point does not explain aifoundry3's factor, and points the other way: under load it holds its minions at 522 mV against aifoundry2's 517 mV at the same 600 MHz, which by predicts about 2% more switching power than aifoundry2's, not the 10% less it switched in the same check (3–4% less at the same die temperature). aifoundry1-c1 shows the converse: at 498 mV, predicts 7% less switching power than aifoundry2's, and it switched 1% more (0.4% at the same die temperature). Whatever aifoundry3's factor is — silicon, package, the board regulator's efficiency at that load, or its cooler die — one number captures it at one temperature, to 0.6 W rms (0.5 W at the same die temperature).

The idle law transfers only in part. Fitted to aifoundry2's idle readings (section 8) and extrapolated 7 to 14 °C below that onto aifoundry3, which idled at 50 to 57 °C in its first session, it predicted that card's idle power to (the mean of the four temperature bins below) out of 25 W; over that card's 16 sessions the offset was +0.6 W on average (the DVFS report, §5). The offset depends on the split between fixed power and leakage, which the idle data leave open (section 8): across the splits that fit, that session's is 0.2 to 1.2 W.

The check's idle cycles of 26 September (V3-IDLE: each card heated, then left to cool, three times) do not bear out a constant offset. aifoundry3 idles 0.7 to 0.8 W above the law from 54 to 67 °C and 1.8 W above it at 84 °C, 1.01 W [0.95, 1.07] over its bins, so the +0.6 W does not hold over that range. aifoundry1-c1, on its older firmware, idles 7.6 to 13.4 W above the law from 56 to 81 °C: the law does not describe it at all. aifoundry2 itself stayed within 0.1 W of its law from 68 to 82 °C.

Idle power minus aifoundry2's idle law, W, at every fifth whole degree each card visited (and its coolest and hottest), the mean over its cycles (the count in brackets); the last row is each card's mean over all its bins with its 99% interval. 26 September, three cycles per card (V3-IDLE items IDLE-a and IDLE-b).

What this means if you have more than one of these cards. The shape of the data-dependence — which operand patterns cost what, relative to each other — held on all three cards: the check's registered steps (ones over zeros, random over zeros, section 1's bit-field ladder and operand order) held on aifoundry2 and aifoundry3 and read within 1.4 W of aifoundry2's on aifoundry1-c1. The absolute scale (0.88 to 0.99 here as registered, 0.93 to 1.00 at the same die temperature over both readings above) and the idle power (25.8 to 50.1 W under these runs) belong to the card at its temperature. A single random-data matmul on a new card, at the temperature it will run at, calibrates the scale (to 0.8 W rms on the other patterns here), and its idle must be measured, because the idle law does not transfer; after that the power predictions of sections 3 and 9 apply to it. The heat predictions also need that card's own thermal network, fitted from long runs on it: aifoundry2's comes from one card in one chassis, and aifoundry3's own fit to its 13-minute session already needs more stages; no other card's cooling over minutes was measured.

11. Method

tools/ettelem/finish_horace.sh   # every analysis, the model, the GIFs and both pages from the committed data; no card;
                                 # needs node and mathjax-full (npm ci at the repo root)
python3 tools/ettelem/predict_heat.py --model docs/reports/data/2026-09-21-horace-aifoundry2/model.json \
    --toggles docs/reports/data/2026-09-21-horace-aifoundry2/toggles_all.json --pattern randn

12. Related reports

• Why is the ET-SoC-1 low power? — uses this model to split the card's watts term by term, and compares the energy per FLOP with an A100's.
• Sparsity on the ET-SoC-1 — the first sign, in two runs on 18 September on aifoundry3: power above idle falling from 17.3 to 2.4 W as A goes to zeros, with no cycles saved (re-measured on three cards on 26 September: 17.5 to 2.5 W on aifoundry2, 15.5 to 1.0 W on aifoundry3 and 17.3 to 1.4 W on aifoundry1-c1, savings of 86, 93 and 92%).
• The ET-SoC-1 energy manual — the flip energies of section 8 (its §3.2) and the idle law (§1) as tables, beside every other event energy.
• The DVFS loop and its leakage — the governor behind section 6, and why aifoundry3 never leaves 600 MHz.
• Power and temperature on the ET-SoC-1 card — the telemetry client used here, and the first thermal measurements.

← All ET-SoC-1 measurement reports