Thank you! Really appreciate this. I’ll prioritize the citations/ranges table in /methodology to make this properly citable and easier to audit.
2 karma · joined September 3, 2025
The goal of the project is to inform public discussion with sourced, reviewable numbers. The “live counters” are there to make scale/salience tangible, not to be sensational.
I know it’s still imperfect and I’m actively improving it. I’d really appreciate critiques and better sources/datasets: - I’m adding a compact table of constants + ranges + citations in /methodology. - A toggle for location- vs market-based CO2 (PPAs/RECs). - Clearer WUE by cooling type and water intensity by generation tech/region. - Small API/CSV export.
If you spot mistakes or have data I should incorporate, please tell me - corrections are welcome: contact@theaimeters.com
Each of the above pulls from operator sustainability reports, industry surveys/benchmarks, grid datasets (national/regional emission factors), and academic studies for water/energy intensities and inference energy per token. Where multiple ranges exist, we pick a conservative central value and call out the range.
I’ll add a compact table of constants + ranges + citations in the Methodology page so it’s easy to audit and nitpick. If you have a favorite dataset for WUE by cooling type or per-region grid water intensity, I’d love pointers—this is exactly the kind of feedback that improves the baseline.
> CO2 (PPAs/RECs)
- We currently use location-based grid factors (national/regional) and do not net out PPAs/RECs. That is the conservative choice for a public baseline.
- If a workload is known to be contract-matched (hourly/locational), we can apply a market-based view; I plan to expose a toggle (location- vs market-based) so both views are visible.
> Water (WUE & power-generation water)
- DC_water_per_kWh (WUE): when operators publish site/region values we use them. Otherwise we assign a cooling class (evaporative / closed-loop / seawater / air-only) and take a central value from published ranges. That gives order-of-magnitude accuracy without claiming site precision.
- PowerGen_water_intensity: technology-specific consumption factors (not withdrawals) by fuel/tech (gas, coal, nuclear, hydro, etc.), weighted by the grid mix of the region when it’s known; otherwise a conservative aggregate. Hydropower is treated as low consumption, high withdrawal.
> Electricity (IT load, utilization, PUE)
- IT_load / Training: bottom-up from reported compute for frontier runs + known fleet sizes; extrapolated to mid-scale using public training reports.
- IT_load / Inference: top-down from usage volumes (requests/tokens/images) × energy per unit by model class, calibrated from published perf/W measurements and vendor/benchmark data. We don’t simply sum GPU TDP; we use perf/W + utilization.
- utilization: ranges by workload class; we take a conservative central value (higher for sustained training, lower/peaky for inference). These are sensitivity levers and shown in the methodology.
- PUE: operator/region-specific when disclosed; otherwise we apply a conservative default for hyperscale vs. generic DCs (kept distinct). PUE is another sensitivity knob we surface.