HN Simulatornew | past | comments | lists | submit | Tuna-Fish's commentslogin

Large data centers are dramatically more efficient at utilizing both the power and the hardware.

At it's core, running a top-tier LLM means linear load of trillion+ weights from RAM for every token. The cost of this operation absolutely dwarfs the cost of doing the actual math. If you are only serving a single user, you can only amortize this over a handful of token streams, times like 2-4 for speculative decoding. If you are running in a datacenter, you can batch thousands of streams, and get correspondingly much more tokens out of the same expenditure of energy and hardware.


Be slightly careful with this. Large datacenters use power to operate the facility (this is measured as PUE > 1). Datacenter-oriented hardware often contains low-diameter, high static pressure fans that consume quite impressive amounts of power that are not counted as overhead in the PUE calculation.

A home- or office-oriented workstation will have much less power-hungry fans (go compare a Noctua datasheet to a server fan datasheet - the Noctua wipes the floor with a server fan if measured by CFM/W, and the internal temperature rise is mostly controlled by airflow and not by static pressure). And in some climates and times of year the marginal facility HVAC cost associated with running a computer may be zero or even negative.

And lower utilization hardware may run in on a more efficient point on the power-vs-performance curve. [0]

That being said, your overall point is correct.

[0] For a dramatic demonstration of how much this curve matters, you can run a non-CPU-saturating, non-latency-sensitive workload on various Intel CPUs with and without turbo on. Seeing a 2x or greater difference in reported power is quite possible. (Intel is terribly at writing platform firmware and the default behavior may be wildly suboptimal.)


None of that matters when there is literally a 100x multiplier on efficiency because of batching. It's all a rounding error.

So much this.

The current-gen hardware is expected to have only 2-3 years of useful life. New tech, and especially new architecture is going to make inference much faster and more efficient in the near future, and the big vendors are going to be more limited by datacenter floor space and power/cooling, so that the hardware will be replaced very quickly by better models.


For the time being this thesis hasn’t worked out though. H100’s are only going up in price and becoming more scarce [1]. At what point would you update if now going on 3 years into H100 lifecycle this doesn’t seem close to happen.

But they are becoming more scarce while staying on Nvidia’s shelves buy-and-hold, or being leased back in some cases. They are not being installed by customers at anything like the rate the sales figures suggest. So yeah, these H100s will last a long time in the packaging.

Meanwhile, Meta is selling their spare AI data centre capacity.


Where are all these unused H100s sitting and where are the people who have been fired for buying them?

Isn’t that what SpaceX is doing too? Selling spare compute while they work on their rocket side hustle.

Jevons' Paradox. If it becomes more efficient, cost goes down, demand goes up, use rises, revenue rises.

Look at DeepSeek! They have done full system optimization on their model, architecting it so that it would be cheap to serve. I am proud to call DeepSeek a world class tech engineering firm in a way that 99% of the tech world is not. They are a 1% company.

no, it's 10y. you just repurpose.

also, power and cooling agreements are usually 10y too.


> The current-gen hardware is expected to have only 2-3 years of useful life.

Expected by whom and why?

Google hasn't retired any of its now ten-year-old TPUs, or any of the subsequent generations. Maybe TPUs are special or Google doesn't understand compute economics but either argument requires data.

If your argument is depreciation, you're confusing a tax concept (depreciation) with useful life. Yes, they're supposedly related, but in practice, the relationship is rather loose. (Residential housing depreciates in 28 years yet typically lasts 2-3x as long and 4x is not rare.) Google's V1 TPUs


The 8-bit ISA bus was theoretically capable of 1.19MB/s. The bus architecture always took 4 cycles per transfer (enforced by the 8288 which had a 4-cycle state machine, iirc one cycle for address, one for data, and two wait states), transferred 8 bits per transfer, and ran at the 4.77MHz frequency.

The actual usable bandwidth was always much lower, somewhere between 80kB/s to a bit over 380kB/s, depending on how you were using the bus, because the cpu needed to fetch its instructions on the same bus. In a way, the bus was usually always running at 1.19MB/s though, because all the basic devices (ROM, RAM, common simple ISA cards) were able to always respond in the basic 4-cycle transfer, it's just that most cycles were spent fetching instructions instead of actual data.

Later machines made the bus faster by increasing width, increasing clocks, and dropping one mandatory wait state at AT for 5.55MB/s theoretical, and dropping the last wait state in the fast clones for 8.33MB/s theoretical.


Thank you; I didn't even realize that the RAM chips on the motherboard were physically connected to the actual ISA bus! It sounds like you know a lot more than I do about it.

This is interesting, thanks! Just wondering if the REP and REPcc prefixes with LODSW/STOSW/MOVSW would have allowed higher transfer rates due to there being no need to decode instructions after the first loop cycle?

No, for a dollar of inference sold, (as an average of all the different inference tiers and plans), it cost them 15c to provide it.

This excludes the R&D costs, including training, where most of their costs lie.

The basic truth of LLM economics is that inference is cheap. The NRE cost to get where you can get premium prices for inference is sky-high. This is part of why the AI companies want to drive the scale up so much.


No, inference as whole, including all the subscriptions.

The API Gross margin is even higher.


Fair. Perhaps it would be better to say a fully utilized subscription is a loss leader

It's not clear at all that subscription was ever a loss leader.

The purpose of the high API prices is, in addition to trying to get more money, to anchor the high price, and then make the subscriptions seem like a great deal. But inference is just not that expensive, not when provided at scale and with huge batches.

You can see this with the various Chinese providers doing inference on open models, which are unlikely to cost less to run than the models at the frontier AI labs. A single 8-GPU GB300 cluster doing high-throughput batch inference on Kimi K3.1 Pro, which is the largest open weights model available, can do something like 300 000 tokens per second, that is, 10T tokens per year. That cluster, with current insane inflated prices, costs something like $1M to buy, and $50k to run per year in electricity. At $10/Mtok, that pays itself back in 4 days. Do you think that that's a reasonable price?

The subscriptions were probably priced with reasonable positive margins.

The huge expenses are in training and pushing the models forwards, with the gigantic RLAIF runs we know they are doing. Then once you got the model, you can scale up inference at low cost and want to serve as many people as possible.


They have thrusters and do controlled re-entry, at a location of their choosing.

The uppermost parts of the atmosphere are very dynamic, with changes in solar activity causing them to contract and expand on a scale of hours. And this is very significant for the amount of drag felt by re-entering objects. Because of this, if you slowly deorbit something naturally through drag, you are not going to be able to pick the destination, or even know where it ends up until very close to it falling down. So instead you intentionally lower the perigee so that it deorbits in a controlled manner.


Didn't know that, shouldn't have assumed. Wish I could fix my third sentence...

Thanks for the correction!


It wasn't just that. Intel could have survived a failed node, or a few of them. Certainly wouldn't be their first.

Krzanich "optimized" the company for profit, by cutting out things he considered to be excess. Including a lot of their irreplaceable validation & verification talent, that AMD instantly snapped up. The lack of validation resources is directly responsible for the failures of many key Intel products during his tenure and later, because major bugs that could have been spotted earlier slipped through, and then resulted in horrible delays and even cancellations. He then spent the surplus of the company on 30 major acquisitions, of which only two were in any reasonable degree successful.

There are CEOs who have destroyed more value than Krzanich, but not many.


As someone who was working in validation around 2012 or so you would be hard pressed to think of Intel treating them as "talent"

Cheating on his wife with one of his subordinates probably didn't help sharpen his focus.

A lot of these bugs are in rarely exercised code paths that probably shouldn't have been written into the software in the first place.

What exactly do you expect them to do? Publish the exploit that can root a huge proportion of all linux servers?

Presumably they will publish it with sufficient fanfare once patches are applied widely enough.


There will be a company using Intel's fabs to make chips 5, 10 or 20 years from now. Because it is in the national interest of US to make sure that happens.

It is not in the national interest to make sure that the Intel common stock remains valued above 0. Plenty of companies that are of national interest were saved directly from bankruptcy, by nationalizing them in a way that wipes out the common stock.


The US government owns the stock.

> US government owns the stock

Depending on how this was done and for what quid pro quo, this could wind up being a liability for Intel. (It also trashes its image abroad.)


Guidelines | FAQ | Lists | API | Security | DMCA | Apply to YC | Contact

Search: