// Scrape Me · Open research agenda v1.0
Reducing AI’s Energy Footprint
Intelligence has a physical footprint. Could suitable compute-heavy AI workloads move to managed building or campus infrastructure, where electricity and heat can be measured, controlled, rejected, or reused—while phones and laptops retain the edge processing they genuinely need?
01 · Research hypothesis
Put heavy compute where its physical consequences can be managed.
The proposal is not “centralize everything.” It is to test a hybrid architecture: shared building- or campus-scale systems handle suitable high-intensity workloads, while end-user devices retain processing that protects privacy, minimizes latency, supports offline use, and preserves resilience.
-
01
Lightweight interfaces
Phones, laptops, consoles, sensors, and controls handle local interaction and task-appropriate edge inference.
-
02
Shared AI infrastructure
Managed GPUs serve eligible workloads with scheduling, access control, measurement, and higher potential utilization.
-
03
Building-energy integration
Electrical demand, cooling, heat rejection, and possible heat recovery become explicit parts of system design.
The scientific question is comparative: for which workloads, operating conditions, climates, and user requirements does this hybrid arrangement outperform cloud-only, campus-only, or device-only alternatives?
02 · Evidence boundary
What is defensible—and what remains unresolved.
Technically reasonable
- AI computation consumes electricity and ultimately produces heat that must be managed.
- Concentrated infrastructure can make electrical demand, utilization, cooling, and thermal output easier to meter.
- Shared accelerators may achieve higher utilization than individually owned high-power devices when scheduling and demand are well matched.
- Server heat can sometimes support useful heating, but usually only after careful integration and, in many cases, temperature upgrading.
- Flexible computing loads may participate in building- or grid-level demand management when workload deadlines permit.
Not established in advance
- Centralized or campus computing is not automatically greener than efficient edge hardware or a well-operated cloud service.
- Useful heat recovery is not guaranteed; source temperature, distance, seasonal timing, heat demand, and integration cost all matter.
- Network energy, latency, service outages, privacy requirements, and rebound effects can change the preferred architecture.
- Removing powerful processors from all personal devices would be too extreme and would reduce resilience and user control.
- Larger models are not justified by scale alone; measured gains must be weighed against energy, material, water, and infrastructure costs.
03 · Architecture comparison
The answer is likely workload-specific.
A fair comparison must deliver the same validated result—not merely run the same model name. System boundaries should include the device, server, networking, cooling, and the electricity mix used during the task.
| Dimension | Building or campus | Device or edge | Hybrid decision rule |
|---|---|---|---|
| Energy | Can share efficient accelerators, but adds facility and network demand. | Avoids remote transfer, but duplicated hardware may sit underused. | Compare wall-plug energy per equivalent, validated task. |
| Cooling and heat | Heat is concentrated and measurable; recovery depends on temperature and demand. | Heat is dispersed into occupied spaces and usually not recovered. | Route compute using thermal conditions and useful-heat opportunity. |
| Utilization | Scheduling may improve use of expensive hardware. | Capacity is immediately available but often idle. | Retain minimum local capacity; pool burst and specialized workloads. |
| Privacy | Institutional control can protect data, but central stores increase governance responsibility. | Data may remain on the device. | Keep sensitive preprocessing local and transmit only authorized inputs. |
| Latency | Depends on network quality, queueing, and service location. | Best for immediate control and offline response. | Use edge compute for hard real-time needs; offload delay-tolerant work. |
| Resilience | Can be managed and backed up, but creates a shared dependency. | Continues during network or server failure within local limits. | Design graceful degradation rather than one mandatory compute location. |
| Lifecycle | Shared hardware may reduce duplication but concentrates upgrade and facility impacts. | Distributed replacement cycles can increase embodied impacts. | Measure service life, repairability, utilization, and avoided hardware together. |
| Governance | Supports managed access, auditability, and public-interest allocation. | Preserves personal ownership and autonomy. | Make workload routing, access, retention, and override rules transparent. |
04 · Research program
How a building-energy lab could test the idea.
-
Phase 1
Define equivalent services
Select representative AI, simulation, and analysis tasks with fixed inputs, quality thresholds, deadlines, privacy classes, and user expectations.
-
Phase 2
Instrument every architecture
Measure devices, network equipment, server input power, cooling auxiliaries, queueing, throughput, and response quality under matched workloads.
-
Phase 3
Map the thermal pathway
Record air or liquid temperatures, heat flow, cooling load, and the temperature lift required to supply space heating or domestic hot water.
-
Phase 4
Model buildings and seasons
Test climate, occupancy, tariff, grid-carbon, heat-demand, storage, and equipment scenarios instead of extrapolating from one room or one day.
-
Phase 5
Publish decision boundaries
Report when campus, edge, cloud, or hybrid operation performs best, including uncertainty, negative results, and conditions that invalidate heat recovery.
05 · Measurements
Measure the service, the building, and the lifecycle.
- Wall-plug energy
- kWh per completed, quality-validated task.
- Facility overhead
- Auxiliary kWh and power usage effectiveness, with system boundaries stated.
- Thermal output
- Recoverable and rejected heat in kWhth.
- Source temperature
- Air or coolant supply and return temperatures over time.
- Cooling load
- Peak and annual cooling demand attributable to compute.
- Heat-pump performance
- Coefficient of performance at the required temperature lift.
- Useful-heat fraction
- Recovered heat actually delivered to a matched demand.
- Seasonal match
- Coincidence of compute heat with building or district heat demand.
- Utilization and concurrency
- Active accelerator time, queue time, and simultaneous users.
- User performance
- Latency, reliability, task success, output quality, and satisfaction.
- Lifecycle impact
- Embodied carbon, service life, repairability, and avoided device hardware.
- Cost per service
- Capital and operating cost per validated workload, with sensitivity ranges.
06 · Research use cases
A shared system must serve real work, not specifications.
Buildings, HVAC, and EnergyPlus
Simulation, optimization, weather processing, physics–AI experiments, reproducible sweeps, and interruption-safe research workflows.
SHAP and clustering analysis
Numeric embedding evaluation, neighbour comparison, cluster agreement, confidence analysis, and post-hoc visualization from authorized artifacts.
Secure research memory
Access-controlled retrieval over current project documents, decisions, code, papers, and results without placing private material in general model weights.
Project-specific coding agents
Sanitized training examples, local inference, adapter experiments, automated checks, and sealed evaluation sets with clear provenance.
Local model evaluation
Reproducible comparisons of model quality, latency, energy, concurrency, and failure behavior under institutional control.
Dashboards and authorized documents
Source-backed analytical products and permitted document workflows where privacy, provenance, and reproducibility are explicit requirements.
07 · Gauraang values
Infrastructure should express responsibility.
These are design values, not empirical findings. They define how the research should be conducted and how competing outcomes should be judged.
Stewardship
Treat energy, materials, water, attention, and public funds as finite resources.
Public benefit
Prefer shared capability and transparent access over status-driven accumulation.
Safety and dignity
Reduce harm without treating people as merely data sources or compute demand.
Privacy and agency
Preserve local control where privacy, latency, resilience, or personal autonomy requires it.
Responsible openness
Share knowledge when possible while respecting security, consent, confidentiality, and misuse risks.
Useful intelligence
Demand measurable public or scientific value before assuming a larger model is progress.
08 · Evidence spine
Starting sources, not final proof.
-
Energy and AI
A global evidence base for data-centre electricity demand, energy supply, emissions, efficiency, and policy trade-offs.
-
The Data Furnace: Heating Up with Cloud Computing
An early proposal for placing servers near heat demand. It supports studying compute as a thermal resource while also challenging a simplistic “centralize everything” position.
-
Waste heat utilization of data centers based on heat pump technology
A review of heat-source temperature, heat-pump integration, end-use options, and the problem of matching heat supply with demand.
-
AI data centres as grid-interactive assets
A field-oriented study of whether flexible AI workloads can respond to power-system conditions without abandoning service requirements.
Sources are linked for verification. Their inclusion does not imply that their authors endorse this proposal, and this page does not reproduce third-party text under its content license.
09 · Reuse and attribution
Please scrape this page—responsibly.
The license applies only to original text on this page. It excludes third-party sources, linked materials, trademarks, photographs, and other site assets. Publication and permission do not guarantee that any search engine, crawler, dataset builder, or AI provider will discover or include this work.
Suggested attribution
Gauraang Malik, “Reducing AI’s Energy Footprint,” 2026, https://gauraangmalikk.github.io/myportfolio/please-scrape-me/, CC BY 4.0. Indicate changes.