Singapore AI Data Centres: Power, Cooling, GPUs, Capacity and Regulation

Singapore's AI strategy eventually becomes a facilities question. A model may be bought from a cloud provider, deployed through an application vendor and governed by a risk committee, but it still consumes a physical allocation of power, cooling, network capacity and engineering attention. That makes data-centre procurement an operating decision, not a property transaction. The practical objective is not to secure the largest theoretical GPU cluster. It is to obtain a workload design that can be powered, cooled, connected, governed and expanded without turning an experiment into an availability or cost incident.

The island's constraints are unusually visible. Singapore has limited land, a tropical climate and a grid that must balance security, affordability and decarbonisation. Its policy response is deliberate rather than unlimited expansion. IMDA's Green Data Centre Roadmap frames additional capacity alongside energy efficiency, green-energy deployment and technology innovation. For a buyer, that means capacity is never simply a vacant rack. It is an allocation with conditions: power density, cooling method, fit-out timetable, network paths, sustainability requirements, contractual term and the operator's credible expansion headroom.

Start with the workload, not the rack

An AI infrastructure brief should begin with a workload inventory. Training, fine-tuning, batch inference, real-time inference, retrieval, vector search, observability and backup do not impose the same physical requirements. A small internal assistant may be served economically through a managed API and a regional cloud service. A sensitive, steady high-volume workload may justify dedicated capacity or a reserved managed platform. A company that has not measured data locality, peak concurrency, latency tolerance, model size, duty cycle and recovery objectives cannot tell whether it needs an accelerator cluster, a cloud commitment or better application design.

The distinction matters because a GPU is not an interchangeable utility. Its useful throughput depends on memory capacity, interconnect, storage, model software, scheduling and how frequently it sits idle waiting for data or human approval. Procurement that treats a headline accelerator count as the outcome risks buying power and cooling for utilisation that never arrives. Ask the proposed operator or cloud provider to show the measurable service boundary: what model or instance type is committed, where it runs, what bandwidth is included, how capacity is reserved, what happens during maintenance and how a workload leaves if the design no longer fits.

Power is a capacity and resilience problem

Power is the first hard constraint. A conventional enterprise rack can be modest in density; an AI rack can concentrate far more compute into the same footprint. IMDA's roadmap notes that AI racks can range from 20 kW to above 100 kW per rack. Those figures are not a licence to specify the maximum. They are a prompt to model the whole electrical path: utility feed, substations, generators, UPS topology, power-distribution units, busways, rack-level delivery and the fault domains between them. Every layer affects both usable capacity and the maintenance plan.

Enterprise teams should request a power schedule rather than a vague promise of 'AI-ready' space. It should state the reserved kW or MW, the committed date, permitted rack density, redundancy configuration, any step-up rights, curtailment conditions, generator testing arrangement and who pays for a later density change. The schedule must also separate IT load from facility load. Power Usage Effectiveness is useful as an efficiency indicator, but it is not an availability guarantee and it does not say whether a particular workload can be accommodated at a particular density.

The broader grid context deserves a board-level conversation. Data centres support digital services, but they are one claim among many on Singapore's energy system. A sustainable design should ask about renewable-energy instruments, energy reporting boundaries, heat-reuse feasibility where relevant, hardware refresh policy and workload scheduling. These do not replace a resilient electrical design. They make it easier to explain how a new AI programme fits the enterprise's climate and continuity commitments instead of becoming an unmeasured exception.

Cooling determines the usable GPU envelope

Cooling is where a rack specification turns into an engineering design. Air cooling can support many workloads, but high-density accelerators increasingly require direct-to-chip liquid cooling, rear-door heat exchangers or another liquid-assisted approach. A supplier claiming liquid-cooling readiness should identify the exact facility-water loop, coolant distribution unit, leak detection, maintenance isolation, water-quality responsibility, controls integration and the temperature envelope it supports. 'Liquid ready' is not a substitute for an installed and commissioned cooling path.

The buyer's responsibility is to link cooling to workload policy. High-density equipment may need a different placement zone, an earlier fit-out date, a longer commissioning window or limits on where future racks can be placed. Redundancy is also more complicated than a single N+1 label: a design can have spare pumps yet retain a common-mode risk in controls, pipework, heat rejection or maintenance access. Ask for the failure-mode analysis, the commissioning evidence and the operating procedure for a cooling alarm during a production AI run. A transparent operator will distinguish what is designed, what is built and what is merely possible after a capital project.

GPU architecture changes network and storage requirements

Dense AI systems also change the rest of the data centre. Model training and distributed inference can produce east-west network traffic that is more material than the north-south internet connection. Accelerator fabrics, storage tiers, checkpoint traffic, data ingestion and backup must be sized together. An enterprise cannot compensate for an undersized data path by ordering faster GPUs. The symptom will be expensive accelerators waiting on storage, retraining jobs missing their window or model-serving latency that looks inexplicable from an application dashboard.

This is why architecture reviews should include the cloud, colocation and application teams together. The questions are concrete: which data crosses the site boundary; which paths are encrypted; how are cross-connects diversified; how are credentials and keys managed; what latency is expected to a cloud region or corporate site; what is the restoration order after a fibre fault; and how are logs retained without quietly becoming the largest storage workload. The right design may span Singapore and nearby regional locations, but that should follow an explicit data, latency and resilience rationale rather than a search for cheaper land alone.

Regulation and governance belong in the architecture

Singapore's data-centre policy is not a single permission slip. Projects may touch electricity supply, building and fire requirements, environmental obligations, communications connectivity, cybersecurity duties and sector-specific data controls. The precise legal and contractual obligations depend on the service model and the enterprise's industry. A buyer should therefore use the provider's claims as inputs to due diligence, not as compliance conclusions. Cloud or colocation in Singapore does not automatically resolve PDPA obligations, banking technology-risk controls, healthcare duties, export restrictions or customer contractual requirements.

A useful governance pack links the physical and logical layers. It records the data classification, system owner, locations, vendors, access model, network diagrams, encryption and key responsibilities, incident interfaces, audit evidence, retention period and exit plan. For agentic AI, add tool permissions, model logs, human-approval points and cost controls. The point is not to burden a small pilot with enterprise bureaucracy. It is to ensure the pilot produces the evidence needed before it receives a production power and capacity commitment.

What should be in a Singapore AI data-centre RFP?

The commercial model should be evaluated as total operating cost per successful workload, not price per rack or price per GPU hour alone. Include hardware or service charges, reserved power, cooling and fit-out, network commits, support, data transfer, storage, engineering labour, observability, evaluation and human review. Then compare a conservative utilisation case with the business case. This is particularly important for short-lived model experiments: a reserved footprint can be sensible for a durable service, but a poor substitute for capacity planning when usage is volatile.

Singapore can remain an excellent place to run critical AI workloads precisely because its infrastructure is governed and its constraints are visible. The advantage is not infinite capacity. It is the opportunity to make disciplined choices about capacity, energy, network design and operational control. Treat the data centre as part of the product architecture and the procurement will be sharper: fewer unsupported density assumptions, a clearer exit path and a workload that can grow without outrunning the machinery that keeps it alive.