Inference load follows people, so the racks, the power contract and the cooling were all sized for the busiest hour of a weekday. Work that can wait a day could fill the night, if the scheduler knew how much the facility can admit, on which rows, until when. VARCOTT computes that from the same device limits it computes for capacity, and hands it to the scheduler as a plan for the coming hours. The gain is measured on the racks, group against group. This page is for inference halls; a training hall runs flat and has no night to fill.
Think of the hall's output as a rectangle. The width is how many GPUs are installed; the height is how many hours a day they do paid work. The facility limit, say 20 MW, is not a limit on the area. It is a limit on how much power is drawn at any single instant. Adding racks widens the rectangle; filling the night raises it; and both are held by the same limit at the same instant.
Inference demand follows the working day, falls through the evening and drops to about half on weekends. On the published request logs of two production services, the average hour carried 62 % of the busiest hour for a conversational service and 32 % for a coding service. The ratio of average to peak is the load factor. The hall, the GPUs and the power contract were paid for at the peak, and in Pennsylvania the model tariff for large loads bills at least 80 % of the contracted demand above 50 MW whether it is drawn or not, so the unused part of the rectangle has a cost every night.
There is a second kind of work that does not care what time it is: summarising document sets, computing embeddings, running evaluations, fine-tuning, re-processing the day's data. Customers accept that it returns within a day in exchange for a lower price, and the public batch tiers are priced at about half of interactive. The scheduler already knows how to place that work. What it does not know is how much of it the facility can take tonight, because the scheduler sees GPUs, memory and queues, and at most a hand-set power budget, not the facility's watts or litres per minute.
A hall filled at night stops cooling down. Panels, the UPS and the coolant distribution units that used to recover every evening now run loaded for 24 hours; transformer hot spots keep climbing; on a summer night the water is warm. In a hall that runs more racks than the sum of nameplates, the night is also the hour when every GPU wants to run at once, which is the case the old sum-of-nameplates rule was protecting against.
So each evening the question for the facility is how much batch work each row may take, until when, at this temperature, with the devices in the state they are in. VARCOTT computes that from the same per-device limits it computes for capacity: the continuous limit of each device on each row's path, the thermal state it will reach, the time it could hold if a cap were late, and the hour at which the morning rise will need the room back. The answer is a plan the scheduler can consume: for each row, how many kilowatts of admission tonight and until what hour; for the afternoon, the heat planned for before it arrives.
The plan goes to the people who place the load as a number per row and per hour, in the form their scheduler takes, as labels, quotas or reservations. It does not place anything and it does not cap anything. The gain is measured by comparison: rack groups that follow the plan against groups that run the scheduler as today, on alternating nights, over enough nights for the difference to be a measurement, with the output per group and the p99 time to first token both on the record.
Three things are true before that happens.
Every row's admission carries an until-hour, computed from the hall's own daily shape and the time its devices need to recover. The plan hands the room back before the rise, with the margin the facility sets, so interactive traffic does not meet a row the night has filled as long as the scheduler follows the plan; if it does not, the cap holds.
If demand rises faster than the plan expected, the cap enforced at the GPU by the power controller you already run keeps the real draw under the signed limit of every device, within seconds, whatever the scheduler does. The plan is advisory; the cap is the guarantee. A stale plan admits nothing the cap would not hold.
VARCOTT does not place jobs, move jobs or change priorities. It tells the scheduler how much the facility can take, per row, per hour. Which jobs, on which GPUs, with what priority, remains the scheduler's decision and your team's policy. The measurement keeps p99 time to first token on the record for both groups, so the plan is judged on the service it preserved as much as on the hours it filled.
The plan rests on the same model as the capacity study: the devices of the hall modelled from their makers' data, the power-distribution and cooling-loop limits computed per device and per hour, and the readings checked against what the physics says they should be. The cooling-loop model is verified test by test against the Lawrence Berkeley National Laboratory's Modelica Buildings library. The daily shapes used to size the plan come from the hall's own historian, and the public inference traces are used only to check them.
VARCOTT is founded by David Perez, an electrical engineer who has written power software for mission-critical facilities since 2013: the white-space power management of Fortune 500 data centers, and one of the first live electrical digital twins in data centers.
The plan needs the capacity study first, because it uses the same limits. If the study exists, the plan for one hall is scoped in one call from the historian's daily shape and the scheduler you run. If it does not, we start there.