AI capital is moving to power and racks

What changed on 28 August 2026

On 28 August 2026, Andreessen Horowitz announced a $1.1 billion Machine Age fund aimed at the physical buildout of AI. The mandate is not only models or applications. It covers chips, memory, data centers, robotics and the hardware layer that has become a constraint on AI deployment.

In the same period, Dealroom highlighted several related capital moves: Nvidia taking a minority stake, described as several hundred million dollars, in Cloverleaf Infrastructure, a data center power company working with major asset managers to direct at least $500 billion into AI infrastructure; Quantum Solutions raising up to ¥3.28 billion for Japan AI data centers; VNET raising $5 billion for AI infrastructure expansion; and Lumilens raising $700 million to replace data center wiring with optical links.

The common signal is simple: capital is moving down the stack. It is going into power access, land, cooling, interconnect, memory, chips and the operating systems that make scarce accelerators usable. The market is no longer treating AI infrastructure as a pure cloud procurement problem. It is treating it as a physical asset problem.

For hyperscalers, that means campuses, grid queues, long-lead electrical equipment and custom silicon supply chains. For operators with a quarter rack to a few racks, including sovereign, enterprise, university, telecom and government estates in the GCC and MENA, the same pressure arrives in a smaller form. The bottleneck is not only how many GPUs can be bought. It is whether the owned hardware can be kept allocated, measured, governed and monetised without turning every tenant request into a manual ticket.

That is the practical reading of the capital wave. If money is chasing megawatts, each megawatt has to carry more useful GPU work. If money is chasing data center power companies, the operator who already has power and racks should ask whether their cluster control plane is good enough to turn those assets into accountable GPU-hours.

The bottleneck for a small GPU estate

A small-to-mid GPU estate does not fail like a hyperscale region. It usually fails through operational fragmentation.

One team receives bare-metal nodes for training. Another wants Kubernetes for inference. A third needs VMs because its software stack is not container-ready. A research group asks for fractional GPUs. A government tenant requires data locality and a separate administrative boundary. Finance asks for cost allocation by department. Facilities asks why peak power is rising while the GPU dashboards show idle devices. Security asks whether an air-gapped environment can be patched without breaking the cluster.

At this size, the operator rarely has a large platform engineering department. The same people are handling firmware, imaging, Kubernetes upgrades, storage, quotas, tenant onboarding, power incidents and billing disputes. The result is usually one of three patterns:

1. GPUs are allocated as whole nodes even when jobs need smaller slices.
2. Kubernetes, VM and bare-metal users are placed on separate pools, reducing utilisation.
3. Metering is added later, after political expectations about free GPU usage are already set.

The capital wave makes these patterns more expensive. A GPU that sits idle at night is no longer just an engineering inefficiency. It is stranded electrical capacity, stranded cooling capacity and stranded debt service. In GCC and MENA markets, where sovereign AI programs, Arabic language workloads, public-sector controls and local hosting requirements are often part of the business case, poor utilisation also weakens the argument for building local AI capacity instead of buying remote cloud access.

What an operator needs to control

The operator-grade requirement is not a single scheduler. It is an operating model across the fleet.

The fleet needs bare-metal provisioning so a failed or repurposed node can be rebuilt without hand work. It needs Kubernetes for container-native training and inference. It needs VM tenancy for workloads that still depend on VM images, licensed software or stricter tenant isolation. It needs GPU partitioning, including MIG where available and time-slicing where appropriate, so that inference, notebooks and development jobs do not consume whole high-end accelerators. It needs storage that survives tenant churn, such as Ceph-backed volumes and object services. It needs quota, policy and chargeback from the first day of service, not as a spreadsheet afterthought.

A platform such as ClastIQ is designed around that operating model on hardware owned by the operator. It uses bare-metal provisioning with MAAS and Juju, supports Kubernetes and VM tenancy on the same fleet, handles GPU partitioning policies, integrates Ceph storage, and provides per-tenant metering and chargeback. It is hardware-agnostic across NVIDIA, AMD and mixed CPU/GPU estates. It also supports air-gap and sovereign deployments, which matters when the operator is running local infrastructure for regulated or national workloads.

The important point is not that every tenant gets every feature. The important point is that the operator does not have to choose between separate islands. A GPU estate should be one governed asset base with multiple consumption models.

Worked example: the economics of utilisation

Consider a local operator running eight GPU servers, each with eight accelerators. That is 64 GPUs. Assume the rack group draws 75 kW at the IT load when active, including GPUs, CPUs, memory, networking and storage overhead. A 30-day month has 720 hours, so the theoretical monthly capacity is:

64 GPUs × 720 hours = 46,080 GPU-hours.

Before a proper tenancy and metering model, the estate reaches only 35% billable utilisation. Some GPUs are genuinely idle. Some are reserved but unused. Some are blocked by environment mismatch: a Kubernetes user cannot use a VM pool, or a VM user cannot use a bare-metal training pool.

Billable GPU-hours are therefore:

46,080 × 0.35 = 16,128 GPU-hours per month.

Assume the operator’s monthly cost for the estate is $60,000, including depreciation, support contracts, data center allocation, power, cooling and operations. The effective cost per billable GPU-hour is:

$60,000 ÷ 16,128 = $3.72 per billable GPU-hour.

Now assume the operator introduces three controls: fractional GPU profiles for smaller jobs, a shared fleet that can serve Kubernetes and VM tenants, and quotas with metering. Billable utilisation rises to 65%. The hardware has not changed.

46,080 × 0.65 = 29,952 GPU-hours per month.

The effective cost per billable GPU-hour becomes:

$60,000 ÷ 29,952 = $2.00 per billable GPU-hour.

If internal chargeback or external resale is set at $3.00 per GPU-hour, monthly recognised revenue or cost recovery changes from:

16,128 × $3.00 = $48,384

to:

29,952 × $3.00 = $89,856.

The same 75 kW IT load also produces a different revenue-per-megawatt figure. At 35% utilisation, monthly revenue per MW is:

$48,384 ÷ 0.075 MW = $645,120 per MW-month.

At 65% utilisation, it becomes:

$89,856 ÷ 0.075 MW = $1,198,080 per MW-month.

Annualised, that is about $7.74 million per MW-year versus $14.38 million per MW-year. The exact numbers will vary by hardware class, tariff, depreciation policy and local pricing. The lesson does not change: when power and racks are constrained, the control plane is part of the financial model.

Partitioning is an economic tool, not only a scheduler feature

GPU partitioning often enters the conversation as a technical feature. For operators, it is also an allocation and pricing mechanism.

Training jobs may need full GPUs connected by high-bandwidth links. Inference endpoints may need predictable slices. Notebook users may need short bursts. Evaluation jobs may need a GPU for 20 minutes, not a week. Without profiles, the smallest unit of allocation becomes the whole device or the whole node. That creates artificial scarcity.

A governed cluster should expose named profiles that match local demand. For example: full-GPU training, half-GPU development, small inference slice, CPU-only VM, and storage-heavy analytics. The operator can then attach quota, priority and pricing to each profile.

A simple operating view might look like this:

kubectl get nodes -L accelerator.vendor,accelerator.profile,power.zone
kubectl get resourcequota -A
kubectl top pods -A --containers
clastiq meter usage --tenant finance-ai --from 2026-08-01 --to 2026-08-31

The exact commands will depend on the local deployment and integrations, but the principle is consistent. Operators need to see which tenants are using which profiles, where those workloads sit, and how usage maps to quotas and chargeback.

Partitioning must also respect hardware differences. NVIDIA MIG is relevant on supported NVIDIA GPUs. Time-slicing can be suitable for less sensitive or bursty workloads. AMD and mixed GPU estates require policy that does not assume a single vendor. CPU-only and memory-heavy workloads should not be forced through a GPU queue at all. A hardware-agnostic orchestration layer matters because many real estates are mixed by procurement cycle, donation, grant, tender or expansion phase.

Tenancy must cover Kubernetes and VMs

Many GPU platforms are designed as if every workload can be containerised immediately. Operators know otherwise.

A tenant may bring a VM image with licensed simulation software. A research group may require a specific kernel module. A public-sector team may insist on VM boundaries because that is how its security process is written. Another team may run inference services best deployed on Kubernetes with autoscaling and service discovery. A startup tenant may want bare-metal access for performance testing.

If each mode gets a separate hardware pool, utilisation drops. A few racks are not enough to hide fragmentation. The better model is to provision the same physical fleet into the right consumption mode under policy: bare metal when needed, Kubernetes when appropriate, VMs where they fit. MAAS and Juju are useful here because they support repeatable bare-metal lifecycle management and service orchestration rather than one-off installation.

For the operator, tenancy should answer five questions:

• Who is allowed to request which class of GPU or CPU resource?
• How much can they reserve at once?
• How long can the reservation run before review or preemption?
• Which storage pools and networks are they allowed to reach?
• How will usage appear on a bill, internal ledger or grant report?

Without those answers, the cluster becomes a queue of exceptions.

Storage and data gravity are part of GPU utilisation

A GPU can be idle because no job is scheduled. It can also be idle because data is in the wrong place.

Small estates often underestimate storage operations. Training data, model checkpoints, container registries, VM images, logs and tenant exports compete for capacity and throughput. If storage is local to a node, jobs become pinned to specific machines. If storage is an external appliance with limited integration into tenant policy, chargeback and access control become manual.

Ceph gives operators a way to provide block, file and object storage from the same general storage foundation, with policies suited to the estate. The value is not only redundancy. It is the ability to attach storage consumption to tenants and workload types. A tenant that stores 200 TB of checkpoints for six months is consuming an asset, even if its GPU jobs run only occasionally.

For GCC and MENA operators, storage design also intersects with sovereignty. Data may need to remain in-country, inside a government boundary, or within a specific facility. The cluster control plane should make those boundaries operational, not just contractual. That means tenant-aware placement, restricted networks, local registries, controlled update paths and audit-friendly metering.

Power becomes a scheduling input

The Nvidia-linked Cloverleaf story is relevant because it treats power as a first-class AI infrastructure asset. Small operators should do the same.

At a few racks, the issue may not be a 500 MW campus. It may be a room with 120 kW available, a cooling limit in summer, or a breaker that cannot support simultaneous burn-in across all nodes. If the scheduler ignores power, the operator learns about limits from alarms instead of plans.

Power-aware operations do not require every site to build a hyperscale telemetry stack. They do require a current inventory: per-node power envelope, rack power budget, circuit mapping, cooling constraints, and workload profiles. Training jobs, inference services and CPU-heavy preprocessing have different power shapes. Maintenance tasks such as firmware updates and stress tests also have power impact.

When metering, quota and placement are connected, the operator can make policy decisions. A tenant with low-priority batch work may run overnight. A revenue-generating inference service may receive reserved capacity. A training job may be placed where cooling margin is available. A new GPU purchase can be evaluated against power and utilisation, not only against headline FLOPS.

This is where revenue per megawatt becomes useful. It forces the operator to compare workloads against the limiting asset. If the limiting asset is power, a full rack of underused GPUs is not better than a half rack that is well governed.

Governance before the queue gets political

The hardest moment to introduce chargeback is after users have learned that GPU capacity is free. The second hardest is after executives have been promised that a local AI cluster will behave like a public cloud region.

Operators should set policy before demand peaks. That does not mean every user must pay external-market prices. It means every tenant should see usage. Internal departments can receive budgets. Researchers can receive grant allocations. Commercial tenants can receive invoices. Government users can receive reports by project, agency or classification.

A practical chargeback record should include at least:

• tenant and project;
• accelerator type or profile;
• GPU-hours consumed;
• CPU, memory and storage consumption;
• reservation versus actual usage;
• priority class or service level;
• data locality or sovereign policy tags.

This is also a fairness mechanism. A tenant that reserves 16 GPUs for a month but uses them for 80 hours should not block another tenant without the cost being visible. Quotas turn that conversation from personal negotiation into policy.

What this means for GCC and MENA operators

The global capital wave will influence local procurement. Hardware lead times, data center power access, sovereign cloud programs and AI factory narratives will all shape budgets. But the operational advantage for GCC and MENA estates will come from running owned infrastructure with discipline.

Many local operators have reasons to own hardware: data sovereignty, latency to local users, Arabic and regional model development, public-sector control, predictable spending, or the desire to sell local AI capacity. Ownership only works if the estate is operated as a governed platform rather than as a collection of expensive servers.

For a quarter rack to a few racks, the practical target is not to copy a hyperscaler. It is to copy the useful properties: self-service within quota, measured consumption, repeatable provisioning, tenant isolation, storage policy, and high utilisation per kilowatt. That is the gap a system like ClastIQ is meant to close on the operator’s own hardware.

What to do this week

1. Build a single inventory of GPU nodes, CPU nodes, storage, rack position, circuit, firmware level and current tenant owner.
2. Calculate last month’s billable GPU-hours and divide by theoretical capacity. Do this before buying more hardware.
3. Define three to five accelerator profiles, including full GPU, fractional or time-sliced GPU, and CPU-only, then map each to quotas.
4. Decide which workloads must run as Kubernetes, VMs or bare metal, and identify where separate pools are wasting capacity.
5. Create a first chargeback model with GPU-hours, storage TB-months and reservation waste, even if prices are internal transfer prices.
6. Review sovereignty and air-gap requirements before deployment design, not after the first regulated tenant arrives.

ClastIQ runs this on the operator’s own hardware: request a demo.

Sources

• a16z creates a $1.1B Machine Age fund to accelerate the physical buildout of AI
• Quantum Solutions raises up to ¥3.28B for Japan AI data centre business
• VNET raises $5B at $190B valuation to expand AI infrastructure
• Lumilens raises $700M Series C to swap data center wires for light
• Liner raises $50B Series C to expand its AI search agents
• Nvidia takes minority stake in power firm Cloverleaf to fuel AI data centers