Top stories

Live mirror
30 storiesupdated just nowView source snapshot
  1. EU chief opens door for Canada to become 'associate member'(bbc.com ↗)
    361comments
  2. The Google Play app review process now regularly takes longer than a week(gultsch.social ↗)
    31comments
  3. Mistral X Mozilla: Private, Multilingual AI Browsing(mistral.ai ↗)
    35comments
  4. Introducing System One Models and Jev(typesafe.ai ↗)
    428comments
  5. Salesforce Global Outage(salesforce.com ↗)
    43comments
  6. Show HN: An e-ink frame that hears birds and draws them as 1800s illustrations(github.com/arnegiacomo ↗)
    213comments
  7. Kyber (YC W23) Is Hiring a Forward Deployed Engineer(ycombinator.com ↗)
    discuss
  8. Learning Programming in an Age of LLMs(ploeh.dk ↗)
    54comments
  9. Apple Reference Image: A New Approach for Verified Photography(security.apple.com ↗)
    222comments
  10. Douglas Adams and the exterminated Doctor Who adventure(bbc.co.uk ↗)
    10comments
  11. An update on Wayback Machine access(blog.archive.org ↗)
    314comments
  12. Doing Everyone Else's Job(yosefk.com ↗)
    49comments
  13. Show HN: I made a flight simulator, except you're just a passenger(inflightsimulator.com ↗)
    129comments
  14. Gemini 3.8 Live and 3.8 Live Extended Thinking(blog.google ↗)
    292comments
  15. Building a Linux GPU Driver for the M4 Mac Mini in One Month(codyho.dev ↗)
    210comments
  16. Negativland, Culture Jamming, and the Art of Making Something New(blog.archive.org ↗)
    23comments
  17. Devastated father says his 9-year-old son spent $118,000 on YouTube ads(tomshardware.com ↗)
    38comments
  18. Intelligence per Watt: Measuring Intelligence Efficiency of Local AI(arxiv.org ↗)
    13comments
  19. German Rheinmetall open-sources its Battlesuite connected weapon system protcol(rheinmetall.github.io ↗)
    90comments
  20. We do modern frequentist statistics: Using fake-data simulation(columbia.edu ↗)
    1comments
  21. A software thing I built: GPS on a 25MHz 486-SX(vcfed.org ↗)
    12comments
  22. Recreating Voodoo Graphics and a Late-1990s Gaming PC on an FPGA(nand2mario.github.io ↗)
    41comments
  23. Why I'm still bearish on LLMs after Navier-Stokes(dank.systems ↗)
    343comments
  24. Original Sony PlayStation 2 security chip 'broken wide open' after 26 years(tomshardware.com ↗)
    1comments
  25. Better routing, probe fixes, plugin updates in Freenet/Hyphanet 0.7.5 build 1507(hyphanet.org ↗)
    discuss
  26. We got admin access to Baseten's production GitHub(strix.ai ↗)
    170comments
  27. Datamimic – don't let your coding agent invent its own test world(github.com/rapiddweller ↗)
    8comments
  28. Let's make quality the norm again(forbrukerradet.no ↗)
    434comments
  29. Show HN: Capsule – Single-file web apps that save their data into SQLite(withcapsule.app ↗)
    144comments
  30. Saving Jet Fuel(marksblogg.com ↗)
    56comments

Intelligence per Watt: Measuring Intelligence Efficiency of Local AI

66 pointsby 2d agoarxiv.org
13 comments
3h agoHN ↗

We propose intelligence per watt (IPW), task accuracy per unit of power

Stupid metric. It's not because a model is better performing that it necessarily requires more energy or compute.

3h agoHN ↗

I don't think that's what they are saying. In fact if they did the metric would be pointless. Rather they are saying by estimating that value on different architectures, one can find more efficient ones. They use open model to be able to remove unknowns. They aren't advocating for one model or another, only more efficient architectures.

1h agoHN ↗

Intelligence per Joule would be more appropriate in many cases. If a model can do the same work but takes 10 times as long as a bigger one that can still be useful (e.g. due to memory constraints), but at the same wattage it burns 10 times the energy. Even more so on mobile devices.

52m agoHN ↗

They also define and measure an "IPJ" as well as "IPW"

the NVIDIA B200 achieves 1.6× to 2.3× higher intelligence per joule than the APPLE M4 MAX across QWEN 3 and GPT-OSS model variants

The B200 = "cloud", M4 = "local".

So "cloud" does even better in energy than it does in power compared to "local". Or, to flip it, "local" is both slower and more expensive than "cloud".

3h agoHN ↗

We propose miles per hour (MPH), distance travelled per unit of time

Stupid metric. It‘s not because you spend more time that you travel farther.

s/

2h agoHN ↗

Unless I misread it, are they saying local GPUs use less energy?

That’s surprising, almost unbelievable, due to batching. Local is usually not batched.

1h agoHN ↗

Small models are much smaller than frontier models though, which is how they end up consuming less energy despite low batch count. (Though with local models growing strong agentic capabilities, batching becomes a reality with local models as well).

57m agoHN ↗

Unless I misread it, are they saying local GPUs use less energy?

You misread it. From the abstract:

local accelerators achieve at least 1.4× lower IPW than cloud accelerators running identical models

That's "intelligence per watt". They also have IPJ, per Joule.

So, they find local is 40% "dumber" than cloud for the same power or 40% more power for the same "intelligence".

Tables 13 and 14 summarize their IPW and IPJ metrics.

But, to your actual point, I think the "local is 40% dumber per watt than cloud" message is still an understatement. And maybe this is something I failed to find in the paper but they seem to ignore the "idle baseline" costs and talks about explicitly focusing on the power consumption of just the accelerator under load.

There is a large baseline power consumption just to support the accelerator. CPUs, memory, PS losses, network, fans, general environment cooling. This "cost floor" is different for data centers and a "random local computer" and I think must be in favor of data centers which are designed and built with efficiency in mind.

Idleness should also be considered. My local GPUs at $WORK and home are idle more than they are used. Idle time energy in real world scenarios should be somehow attributed to those brief, punctuated times when LLM functions are actually active on the accelerator. Actual, local LLM usage of a GPU is brief (assuming one user per PC). Even with my heavy usage developing s/w I'd guess I heat up a GPU about one hour per day total, sometimes much less. If that is local then one must pay 23 hours of idleness for that 1 hour of "intelligence". Of course a local PC is used for other things and the idleness penalty must somehow account for that. OTOH, data centers try to maximize utilization so their idle time penalty would be much less, perhaps close to zero, by construction.

1h agoHN ↗

this is the metric i've been waiting for. we run everything local (ollama + neo4j) for compliance reasons, so 'quality per watt' is literally our budget line. one data point from our setup: qwen2.5:3b on an m2 macbook handles nl-to-cypher for simple graph schemas at ~3-5s per answer, and the energy cost is a rounding error compared to shipping the same queries to a frontier api. the hard part was never the model though, it was parsing pdfs locally without a vision model. would love to see parsing/ocr covered in future benchmarks.

1h agoHN ↗

Incredibly important research. We've reached the point where local LLMs are good enough! It takes less time for local model to take the first action on your task than it does for Claude to validate your login, put you into queue and start issuing the commands. Local models are persistent and 100% predictable unlike any cloud offering. It's better for the power system for the demand to be distributed. During the winter time the GPU also doubles as a 300W in-house heater. Not to mention avoiding personal data collection and re-selling.

47m agoHN ↗

It takes less time for local model to take the first action on your task than it does for Claude to validate your login, put you into queue and start issuing the commands.

This is only true if your local model is already resident in RAM / VRAM.

55m agoHN ↗

Saw some measurements on SBC NPUs (3588) and that did seem to have a decent win on power over CPU...but also a perplexity loss relative to CPU so think this will prove quite hard to reliably quantify in practice.