A “rate card” for liquid‑cooled AI/HPC colocation isn’t just a price list. It’s a liquid cooling colocation pricing model that makes three hard things contractable:
How you recover facility CAPEX over time (without surprise amendments).
How you charge for density (without incentivizing unsafe or unmaintainable deployments).
Who owns the liquid loop, and what happens during maintenance (without finger‑pointing when something trips).
This guide gives you a stepwise process plus a copy/paste template you can use to build a procurement‑ready rate card.
Key Takeaway: The best rate cards price risk and responsibility boundaries as explicitly as they price kW and racks.
At minimum, a liquid‑cooled AI/HPC colo rate card needs to price and define:
Capacity unit: per rack, per kW (IT load), or hybrid.
Density definitions: the exact kW thresholds that trigger surcharges.
Cooling scope: air + liquid hybrid vs liquid‑only at the rack.
Loop ownership model: facility‑owned loop vs tenant‑owned loop.
Commissioning and acceptance: what “ready for service” means.
O&M and downtime: maintenance windows, emergency response, and who pays for incremental PM.
Integration boundaries: standard rack fit, piping approach, leak detection, and monitoring.
If your document doesn’t explicitly state these, it’s not a rate card—it’s an invitation to renegotiate later.
Prerequisites (gather these inputs before you price anything)
Input checklist (you’ll use these in Steps 2–6):
Planned rack count and rack type (standard 19” vs specialty)
Contract term assumptions (months)
Target IT load per rack (kW) and power redundancy (A/B feeds, N+1, etc.)
Cooling architecture: RDHx / direct‑to‑chip / immersion / hybrid
Loop concept: facility‑owned secondary loop vs tenant‑owned rack loop
CDU placement: in‑rack, in‑row, or centralized
Utility model: who pays power, how metering is handled
Operational targets: SLAs, maintenance windows, permitted downtime
⚠️ Warning: Don’t price “100 kW/rack” until you define the measurement point. “IT load at the server” and “rack PDU draw” can drive different commercial outcomes.
Step 1 — Choose the billing unit (and lock the definition)
Input: Your go‑to commercial model (per rack, per kW, or hybrid).
Action: Pick one of these models and write the definition into the rate card:
Per rack: simple, but can hide density and loop cost differences.
Per kW (IT load): scales with power; must define measurement and rounding.
Hybrid: base per rack + metered kW + density surcharges (most flexible for AI/HPC).
Output: A one‑paragraph “Billing Unit & Metering Definition” section.
Done when: A procurement reviewer can answer “what exactly is being billed?” in 30 seconds.
Step 2 — Build your CAPEX recovery timeline (the non-negotiable backbone)
Input: A list of CAPEX items you expect to recover and your term options.
Action: Separate CAPEX into two buckets:
Facility CAPEX (shared) — items that benefit multiple tenants over time.
Tenant‑specific CAPEX — items driven by one tenant’s density, loop needs, or integration.
Then implement a timeline model:
One‑time NRC (non‑recurring charge) for tenant‑specific build
Monthly MRC uplift for shared facility upgrades amortized over term
Optional: term‑based price curves (shorter term → higher recovery rate)
Where you can, use a formula instead of a hard number so the template can be reused across sites.
Output: A CAPEX recovery section with a table of CAPEX items + recovery method.
Done when: You can explain how each major cost is recovered without referencing spreadsheets.
Coolnetpower example inputs (for the template): Liquid cooling can include CDUs and rack‑level heat rejection (e.g., RDHx, immersion). See Coolnetpower’s liquid cooling product categories and solution overview pages for category terminology.
Step 3 — Define density tiers and surcharges (high-density rack surcharge)
Input: Your supported density envelope and the point where standard operations break.
Action: Create 3–5 density tiers. Use threshold logic that’s unambiguous.
A practical pattern:
Tier A: baseline density (no surcharge)
Tier B: enhanced airflow / containment requirements
Tier C: hybrid liquid cooling required
Tier D: liquid‑first architecture (CDU + strict commissioning)
Then price surcharges based on what changes operationally, not what sounds impressive:
additional cooling distribution hardware (CDU capacity)
higher‑grade leak detection and isolation
commissioning complexity
stricter maintenance constraints
incremental spares / on‑call requirements
Output: A density tier table with tier thresholds and surcharge logic.
Done when: A sales engineer and an ops lead both agree the tiers are operationally real.
Pro Tip: Include a “density audit clause”: if measured steady‑state draw exceeds the declared tier for a defined period, the contract automatically moves to the correct tier.
Step 4 — Decide facility loop vs tenant loop (and write the responsibility boundary)
Input: The loop ownership model you want to support.
Action: Pick one of these models (or explicitly offer both):
Model 1: Facility‑owned loop (operator provides liquid as a service)
Facility provides:
secondary loop to rack/row boundary
CDU operations (if centralized)
monitoring at facility boundary
Tenant provides:
within‑rack plumbing (depending on architecture)
server cold plates / immersion tanks (as applicable)
Model 2: Tenant‑owned loop (tenant brings the liquid system)
Facility provides:
space, power, and defined tie‑in points
monitoring and access rules
Tenant provides:
CDU and all rack‑side plumbing
coolant selection, maintenance, spares
Why this matters: If you don’t define loop ownership, you can’t define what “maintenance” or “fault” even means.
To sanity‑check your responsibility section, compare it to real‑world infrastructure lease language that explicitly assigns liquid cooling maintenance to the landlord while excluding tenant property (see the “liquid cooling systems serving the Premises” language in this SEC lease exhibit).
Output: A “Scope & Responsibility Matrix” section.
Done when: A lawyer can turn it into contract language with minimal back‑and‑forth.
Step 5 — Write maintenance and downtime policy (maintenance window policy)
Input: Your operational reality: maintenance cadence, spares strategy, escalation model.
Action: Define these policy blocks:
Planned maintenance windows: frequency, duration, and notice period
Emergency maintenance: what triggers it and how notice is handled
Incremental preventative maintenance: how a tenant can request changes and how incremental costs are billed
Failure domain: what is considered “facility incident” vs “tenant incident”
Service credits / abatements: if applicable, define conditions and exclusions
If you want a reference for how some operators structure PM schedule change requests and incremental PM costs, review the “PM Change Request” and incremental cost approach described in that same lease exhibit.
Output: A maintenance policy section with definitions and notice requirements.
Done when: Your on‑call lead says “this won’t get us trapped into impossible promises.”
Step 6 — Standard rack integration: write the “how it fits” section
Input: Your rack standards and the liquid cooling architectures you accept.
Action: Add an “Integration & Acceptance” block that covers:
Rack footprint, weight limits, and RU clearance assumptions
Allowed rack‑side components (e.g., rear door heat exchanger, in‑rack CDU, immersion enclosure)
Piping approach (overhead vs underfloor), isolation valves, drip trays, leak detection
Commissioning checklist and acceptance criteria (pressure testing, alarms, sensor validation)
Monitoring handoff: what telemetry you require and what you provide
You can reference common category terms (CDU, immersion, RDHx) using Coolnetpower’s liquid cooling product category page so readers have an internal glossary anchor.
Output: A rack integration and commissioning section.
Done when: A tenant engineer can map their design to your tie‑in points without guessing.
Standard line items to include in your liquid‑cooled colo rate card
Use these as your “library” of billable components (you’ll see them in the template below):
Base colocation (space + baseline cooling) — per rack or per kW
Metered power — per kWh (or per kW reserved, depending on model)
Density surcharge — per rack, by tier (the high-density rack surcharge)
Liquid cooling service fee — per rack or per kW of heat rejected
CDU fee — per CDU (capex recovery) + optional O&M fee (your CDU pricing)
Commissioning & acceptance — one‑time NRC
Redundancy premium — N+1 pumps/CDU, redundant supply/return lines (if offered)
Monitoring & leak detection add‑on — one‑time and/or monthly
Maintenance window customization — monthly premium
Smart hands / on‑site support — hourly
Downloadable (copy/paste) rate card template — with Coolnetpower example rows
Copy this Markdown table into your doc, wiki, or proposal. Replace the example values with your site‑specific numbers.
How to use: Fill in the “Unit”, “How priced”, and “Notes/definitions” columns first. Only then fill in prices.
Section | Line item | Unit | How priced (formula or rule) | What triggers it | Notes / definitions | Example (Coolnetpower co‑branded) |
|---|---|---|---|---|---|---|
Commercial | Contract term options | months | {36, 60, 84} | Proposal | Define which CAPEX items amortize over term | Example: offer 36/60/84-month curves |
Base | Colocation base (space + baseline cooling) | per rack / mo | Base_MRC | Each rack | Define rack size, power feed assumptions | Example: baseline tier supports mixed densities |
Power | Reserved capacity | kW / mo | Reserved_kW × Rate | At contract | Define measurement point, rounding, overage policy | Example: clarify “rack PDU draw” vs “IT load” |
Power | Metered energy | kWh | Metered_kWh × Pass-through + markup? | Monthly | Define metering interval, billing cycle | Example: publish metering method + dispute window |
Density | Density tier definition | tier | Tier thresholds (kW/rack) | Design approval | Unambiguous thresholds prevent disputes | Example: align tiers to operational constraints |
Density | Density surcharge | per rack / mo | Tier_Surcharge[Tier] | Tier B+ | Explain what changes operationally | Example: higher tiers may require liquid-first architecture |
Liquid | Liquid loop model | N/A | Facility-owned vs tenant-owned | Deal structure | Define responsibility boundary | Example: facility provides tie-in + monitoring boundary |
Liquid | Liquid cooling service fee | per rack / mo | Liquid_Service_Fee(Tier, LoopModel) | Tier C+ | Define included services (monitoring, valves, etc.) | Example: reference terms CDU / RDHx / immersion for clarity |
Liquid | CDU (capex recovery) | per CDU / mo | CDU_CAPEX / Term + margin | CDU required | Define CDU location (in-rack/in-row/central) | Example: “CDU” category per Coolnetpower liquid cooling page |
Liquid | CDU O&M | per CDU / mo | Fixed_O&M + parts pass-through | Tier C+ | Define spares ownership, response times | Example: include redundancy option (dual pumps) where applicable |
Build | Commissioning & acceptance | one-time | NRC_commissioning | New install / change | Define acceptance tests, alarms, leak checks | Example: include pressure test + sensor validation checklist |
Policy | Planned maintenance window | N/A | Defined schedule | Included | Frequency, notice, expected impact | Example: publish “maintenance calendar” practice |
Policy | Custom maintenance window | per mo | Premium_MRC | Tenant request | How tenant requests schedule changes; incremental cost | Example: define request lead time + cost estimate cycle |
Support | Smart hands (standard) | per hour | Hourly_rate | As used | Define response SLA and exclusions | Example: optional 24/7 on-call tier |
Risk | Incident classification | N/A | Facility vs tenant fault tree | Incident | Define failure domain and escalation | Example: tie to responsibility matrix |
Common failure modes (and how to prevent them)
Vague density definitions → Use tiers with explicit thresholds and a measurement point.
Loop ownership ambiguity → Put a responsibility matrix in the rate card, not just in the MSA.
Unpriced commissioning → Commissioning isn’t overhead; price it as a line item.
Maintenance promises that ops can’t keep → Define windows, notice, and emergency rules in plain language.
Rack integration surprises → Publish acceptance criteria and tie-in constraints.
Next steps
If you want, you can treat this template as the starting point for a contractable “rate card + SOW addendum” package.
Request a commissioning checklist for your liquid loop + standard rack integration.
Ask for a sample SOW addendum that defines loop ownership, acceptance criteria, and maintenance windows.
To align terminology with high‑density AI/HPC liquid cooling architectures (CDU, immersion, rear‑door heat exchangers), reference Coolnetpower’s solution overview.
