What was announced
On October 21, 2026, at GTC Berlin, NVIDIA introduced DSX POD, a reference design for complete Vera Rubin AI factories that partners build inside modular containers and validate before shipping. The published claim is a deployment window at a prepared site of as little as 14 days, against six months for a conventional on-site build. Named partners are Bull, Dell Technologies, HPE, Lenovo, Schneider Electric and Vertiv. Units are expected in early 2027.
The work that moves to the factory is specific: rack-to-rack cabling, wiring, piping, rack-level power, liquid cooling, and functional validation before transport. What does not move is the site itself. The units arrive ready to connect to power, cooling, networking and other supporting infrastructure that must already exist.
NVIDIA’s own framing of the metric is worth keeping. The company describes the benefit as time to first production tokens, not time to completion of construction. Jensen Huang’s statement in the release is the whole argument in one line: an AI factory creates value when it starts producing tokens, not when construction is complete.
What the 14 days does not cover
Channel Insider’s coverage of the announcement is explicit that the 14-day window excludes the work needed to prepare the site. That is the part that has historically taken longer than the hardware. A pod that arrives in a container still needs a feeder, a heat path, a network route to customers, and an acceptance test before it serves anything.
The grid side of that problem is measurable. Lawrence Berkeley National Laboratory’s Queued Up 2026 edition, which aggregates interconnection data from more than 50 transmission operators through the end of 2025, reports roughly 8,200 projects actively seeking grid interconnection, 1,312 GW of generation and 749 GW of storage in active queues. For regions with timing data, the median duration from interconnection request to commercial operation for projects that came online in 2025 was over five years. More than 70 percent of interconnection requests are withdrawn. A further 549 GW holds a draft or executed interconnection agreement without reaching commercial operation.
One boundary matters for reading that number honestly. The LBNL dataset covers transmission-connected generation and storage. Large loads, which is what a data center is, sit in separate queues that this report does not include. So the five-year median is not the wait for a data center interconnection. It is the wait for the generation that has to exist for the data center to be fed, and it is the reason a containerized pod can be delivered in two weeks while the site it plugs into is not ready for years.
Price is the second half of the same picture. The Bureau of Labor Statistics put the US city average retail price of electricity at 19.6 cents per kilowatt-hour in September 2026, up 4.3 percent from 18.8 cents a year earlier. The Energy Information Administration’s September 2026 outlook projects an average residential price of 18.2 cents for 2026 and 18.6 cents for 2027. A factory-built pod shortens the time before a site earns revenue. It does not change what a kilowatt-hour costs once the site is running.
At rack scale the power path is also a thermal problem. The 120 kW rack and the move to 800V DC is what made a rack-level power budget a design constraint instead of an electrical one, and that shift is covered in its own write-up on how 120 kW racks rewrote data center power. A containerized pod carries the plumbing for that load. It does not carry the capacity to supply it.
The same constraint at desk scale
A single machine does not have an interconnection queue. It has a breaker, a meter, and a room that gets warm. The structure of the problem is identical, and at this scale it can be measured directly rather than estimated. The power-capping side of this was worked out earlier in tokens per watt; what follows is a fresh measurement on the machine that serves this site, because a per-token energy figure is only worth anything when someone actually put a meter on the card.
I ran a real decode pass against the local endpoint on the box that serves the model: a Ryzen 9 5900X with 64 GB DDR4 and an RTX 3090, with the model split across GPU memory, system RAM and the model drive. Power draw was sampled through nvidia-smi during the request.
| State | Measured draw | Throughput | Energy per token |
|---|---|---|---|
| Settled idle, no request | 81 W | 0 | not applicable |
| Decode pass, 98 to 99 percent utilization | 340.6 W average across five samples | 103.9 tokens/s wall-clock through the API | 3.28 W per token |
| Same pass, engine-reported | same | 106.2 tokens/s | 3.21 W per token |
The 2.2 percent gap between the engine number and the wall-clock number is request and tokenization overhead. It is small here because the prompt was short. It is the number an agent loop actually experiences, which is why the wall-clock figure is the one that should be used for any cost calculation.
At 19.6 cents per kilowatt-hour, the arithmetic is small and unambiguous. A million tokens at the measured rate takes 2.7 hours of decode and 0.91 kWh, which is about 18 cents. An eight-hour working day of decode is 2.72 kWh, about 53 cents, and produces roughly 3 million tokens. The idle machine burns 1.94 kWh a day on its own, about 38 cents a day, or roughly 139 dollars a year, before a single token is generated.
Two things follow from that. First, prefill is not where the money is for a chat or agent workload. A 76-token prompt took 533 milliseconds. The decode pass is where the energy goes, and it is where the cost is. Second, speculative decoding changes the energy per token because it changes how many tokens come out of one pass. In the run I measured, 1,478 of 2,116 drafted tokens were accepted, about 70 percent. Drafting does not change which tokens are produced. It changes how many full passes are needed to produce them, and a pass that yields three accepted tokens costs one pass of memory traffic.
What a prepared site means for one machine
The factory cannot preassemble the circuit. A 15 amp, 120 volt branch circuit is 1,800 watts, and continuous load is derated to 80 percent, which leaves 1,440 watts. The measured 340 watts is comfortably inside that on its own. The failure mode is not the draw of the machine. It is everything else already on the breaker, and the fact that nobody measured it before the load was added.
That is the desk-scale version of the DSX problem. The hardware is the fast part. The path the power takes to reach it is the slow part, and it is the part nobody can validate in a factory because it does not exist yet.
What to actually buy, in the order that matters
The cheapest instrument in the build is the one that tells you what the build consumes. Without a meter, every cost figure in this article is an assumption.
For a single machine, a plug-in watt meter is enough. The Upgraded watt meter plug reads the outlet the box sits on and reports draw directly, which is the number nvidia-smi does not give you, since it reports the card and not the wall. It is around 10 dollars as of October 8, 2026, on a third-party listing; Amazon’s own stock is out.
For a whole room or a house, a panel-mounted monitor is the right instrument, because it shows which circuit the load actually landed on. The Emporia Vue 3 is around 100 dollars as of October 22, 2026, and takes per-circuit current with clamp-on sensors. That is what turns a breaker question into a measurement.
For a rack, metering belongs at the distribution point rather than at each machine. A StarTech 8-outlet 1U metered PDU is around 130 dollars as of today. It is the same idea as the rack-level power work DSX moves to the factory, at a scale one person can install.
None of these change throughput. They change what you can prove about it. If the machine is the decision, the hardware ladder from budget to enterprise is the place to start, and the power figures above are what make that ladder honest: a card’s price is not its cost, and the difference between the two is a number you can only get from a meter.
The decision this actually forces
For a buyer at rack scale, DSX POD is a real reduction in one category of risk: factory validation before shipment removes error-prone on-site work, and a shorter integration window means revenue starts earlier. It does not remove the site. The 14 days is a floor that assumes power, cooling and networking are already there, and those are the items with multi-year lead times.
For anyone running a model on one machine, the equivalent decision is smaller and fully within your control. Put a meter on the circuit before you add the load. Know the continuous rating of the breaker. Measure the idle draw, because it is the part that runs when nothing is happening. Then compute cost per token from the wall-clock rate, not from the engine’s own number.
The pattern is the same at both scales. Integration work can be moved to a factory. Site readiness cannot. The 14-day claim is honest about that, and it is the reason the interesting number is not the delivery window. It is the time between plugging in and producing something.
