a16z puts $1.1bn into the hardware its software portfolio is waiting on

a16z's post carries the numbers that make its own case, and they are electrical. A rack that used to draw roughly 5 to 10 kW now draws 100 to 250 kW for current systems, and the firm expects 1 MW per rack within three years ^[4]. That projection is a hundred times the top of the old range, dividing 1,000 kW by 10 kW ^[14], and the 250 kW ceiling deployed today is already 25 times it ^[15].

Put that beside the compute figure in the same list: 28X density per rack from an H100 rack to a Rubin rack ^[3]. The post does not tie the two figures to a common window, so the comparison is rough, but on a16z's own numbers the density arrived with power draw moving in rough proportion ^[3][4]. Which is why the rest of the argument reads like an electrical plan rather than a software thesis. Copper cabling inside the rack is at its limit ^[5]. The firm calls the buildout a social and national imperative ^[13], and underneath that framing sits the wiring that has to carry it.

The planning number is the supply one. a16z says the hardware industry is used to growing 20% to 30% a year at most, and that catching up with demand needs triple-digit growth ^[8]. Compound the generous end of that habit and capacity doubles in about two years and eight months, from ln 2 divided by ln 1.3; triple-digit growth doubles it annually ^[16]. The distance between those two doubling times is the queue an inference-heavy feature sits in.

Teams tell themselves the constraint is model quality, and that next quarter's release moves the roadmap. But the calendar of the person who has to answer for the date runs on allocation, and on lead times for parts nobody in the product review can name.

a16z's reason for expecting demand to outrun supply is worth borrowing even if you never take its money. As work moves from chat to reasoning to coding, the firm says both the volume of work and its token intensity rise by orders of magnitude ^[12]. That yields a two-by-two you can fill in tomorrow. First axis: when you make the feature better, does cost per user action stay flat or climb? Second axis: is your capacity contracted, or bought on your vendor's goodwill? Flat cost on contracted capacity ships on the date you wrote, while climbing cost on uncontracted capacity ships only when someone else's rack lands. For anything in that last cell, the roadmap line needs a second column naming the dependency and whoever owns the queue, because that is the thing being done, whatever the deck says is being pitched.