> For example, when the GPU is fully idle, nvidia-smi tells me that it’s only pulling 88W of power.<p>I haven't used a non-laptop GPU in some time, but that is a crazy amount of "idle" power consumption. Is this normal for cards like this?
Server cards are not optimized for idle power usage. They’re expected to be fully utilized.<p>For server gear it’s more common to have less dynamic power and voltage switching because it produces more predictable performance and latency.
If my gpu is sitting idle, and I mean idle with nothing loaded into its memory, it's sitting at about 18W. If I load in model that uses nearly all of the memory but that model is idle, it's at 36W. If that model is actively thinking, it's like 118W. I think this is likely due to the GPU being aware that there is real data loaded into memory and turning up the DRAM refresh rate whereas when nothing is loaded, the dynamic power is as low as possible.
Yes, I have some of these cards and AFAICT the HBM2e chips just always run at full speed. I have different variants of the pcie cards and while I can get the gpu itself into a lower power state the memory just runs full tilt. Though I see 40w on my “normal” cards and 60w on the Frankenstein card that thinks it’s an sxm4.
I suspect the act of running nvidia-smi itself prevents the GPU from being put into a low-power state.
I'd have guessed multiply-by-0 and multiply-by-1 can be special-cased to run much faster and simpler code paths, like you'd do when writing MUL for a processor that doesn't have it (I <3 z80)
Hardware engineer here. Special casing the multiply by 0 and multiply by 1 paths is harder than it sounds. In software, the cost of adding special cases is simply performance. You're adding more instructions that execute in sequence on a CPU that already physically exists. Doing this for your multiply case is worthwhile because the speedup is large for 0 and 1 while the cost is not that large (relative to the time taken for the whole multiplication operation) for other values.<p>Hardware is different. Every operation that can be performed in hardware by a chip needs dedicated circuitry. Special casing 0 and 1 means adding at least OR reduction on each operand and a dedicated multiplexer for every bit of the output. Those transistors use power even when they're not in use (leakage power is a huge issue on modern semiconductor processes). They also degrade timing by adding more gates on critical paths through the multipliers. (The timing issue here is that all operations that happen between one flip-flop and another flip-flop need to finish within one clock cycle.) And unless there are whole blocks of 0's and 1's (this does happen in certain neural networks), you typically won't see a direct speedup anyway. In software terms, the matrix multiply is scheduled as many parallel operations that cannot be accelerated much overall by skipping a few operations in some "threads."<p>All of this makes zero skipping a nontrivial topic. People do still try to do it but it needs serious consideration as, depending on the application, the case is rarely one-sided.
You didn't touch on the most important aspect for cost: die area!<p>How much die space ($) will that circuitry, that's probably statistically near zero chance for you main customers workload (who has model weight of 0 or 1!?), add. And, if you can stomach the cost, what <i>else</i> could you put there instead?
I went in expecting to find 'branch prediction'[0] as the answer, but apparently things are even more complex nowadays.<p>[0] - <a href="https://stackoverflow.com/questions/11227809/why-is-conditional-processing-of-a-sorted-array-faster-than-of-an-unsorted-array" rel="nofollow">https://stackoverflow.com/questions/11227809/why-is-conditio...</a>
>I went in expecting to find 'branch prediction'[0]<p>GPUs do branch prediction? I thought they didn't bother and try to minimize wasted effort by using high amounts of concurrent threads?
To be fair, the culprit in the article is _less complex_ than branch prediction: "with random data, bits are flipped often, and bit flips in transistors inherently draw power" is less mental gymnastics than "with random data, the cpu fails to predict the future, causing redundant speculative execution"
I expected a “torch is smart enough to keep track of cases where it just initialized the C in C <= A*B+C to zero, avoiding the add” type situation but I was wrong.
That's exactly what I thought.
I feel like many of the comments missed the point or didn't read the article. What I believe this article is stating (and I've read this many times during my PhD for various reasons), is that the input data distributions affect how many transistor state changes there are during multiplication. Since these events are a large portion of energy loss/heat generation, the clocks won't be throttled as much for certain data patterns.<p>There was a workshop paper from SC24 that did more experiments around this I believe. I can't find it now though.
I can't tell from the blog, is this actually verified or is it theory and then numbers showing plausibility?<p>I could certainly come up with alternative theories about memory compression and prefetching if we were talking about texture reads.
Sounds like a side channel attack waiting to happen.
So I guess we'll all be applying a random rotation to our matrices now to obscure their contents, like TurboQuant does. <a href="https://arkaung.github.io/interactive-turboquant/#rotation" rel="nofollow">https://arkaung.github.io/interactive-turboquant/#rotation</a>
People have been noticing the effects of this in local LLM inference. Power limiting seems to improve overall performance!
This is not observable from LLM inference, where you would not encounter uniform matrices.<p>Power limiting does not improve performance but it does improve efficiency. You might be able to get 90% of the performance for only 70% of the power usage, for example. It does not make the card go faster though.
In general, constraints require optimizations and rearchitectures. I'd also expect the ram shortage for instance to have a big impact on the software industry as a whole, specially in games. They will need to make do with what people have, a ps5/pro or similar in PC power.
It wouldn't surprise me to see some ML algorithm <i>in silico</i> somewhere to select faster matmul paths on favorable data. Yo dawg, I heard you like AI, so we put some AI in your AI so you can infer while you're inferring.
Here is one: An adjustment to weight updates, that makes it more likely for weights to stay uniformly distributed.<p>~257.5 teraflops for normal distribution, versus ~268 teraflops uniform, reported on the first graph.<p>I would have liked to see a straight graph of performance vs. clock speed, for each type of data. Pick your data statistics, then pick the peak performance clock speed accordingly.<p>And for actual runs, from a pre-run sampled curve.
And there's at least one more level of inception at the data center level, where they use AI to optimize power usage (particularly by predictively controlling cooling, and adaptively rescheduling tasks).
Designing for predictable execution flow is one of the advantages of Tenstorrent hardware.<p><a href="https://clehaxze.tw/gemlog/2025/04-21-programming-tensotrrent-processors.gmi" rel="nofollow">https://clehaxze.tw/gemlog/2025/04-21-programming-tensotrren...</a><p><a href="https://clehaxze.tw/gemlog/2026/01-22-the-real-tenstorrent-tensix-programming-model.gmi" rel="nofollow">https://clehaxze.tw/gemlog/2026/01-22-the-real-tenstorrent-t...</a><p><a href="https://arxiv.org/html/2604.03279" rel="nofollow">https://arxiv.org/html/2604.03279</a>
[dead]