E2AM: An Open-Source Tool to Quantify AI Training Energy Consumption and Carbon Emissions in Two Lines of Code

The Core Pain Point of Green AI: Just How High Are Training Costs?

As the scale of large model training continues to balloon, a long-overlooked question is coming to the surface: exactly how much energy does training a model consume, and how much carbon does it emit? Most researchers focus on accuracy, loss curves, and convergence speed, yet few systematically quantify the energy bill of the training process.

The urgency of this issue was formally brought into the spotlight in 2019. In the paper Energy and Policy Considerations for Deep Learning in NLP, Emma Strubell and other researchers first systematically quantified the carbon emissions of NLP model training, finding that training a large Transformer model could produce about 284 tons of CO₂ equivalent—equivalent to the total lifetime emissions of five cars. This figure needs context to truly grasp its magnitude: the estimate was based on hardware conditions around 2019 and corresponded to the extreme scenario of performing a full Neural Architecture Search (NAS) in a non-optimized cloud environment. By comparison, a single training run of BERT-base produces about 1,400 pounds of CO₂, while the estimated value for training GPT-3 reaches as high as about 552 tons of CO₂—equivalent to roughly 120 years of electricity consumption for an American household. Notably, as the efficiency of newer hardware generations like the A100 continues to improve (the A100 offers about 3x better energy efficiency than the V100) and the share of renewable energy grows, the actual carbon cost of models of the same scale has decreased. However, the exponential growth in parameter counts has largely offset this progress, keeping overall energy consumption on an upward trajectory.

This figure sent shockwaves through academia and gave rise to the "Green AI" movement. The formal establishment of the Green AI concept owes much to the concentrated emergence of several landmark papers around 2019: beyond Strubell's team's carbon emissions research, Roy Schwartz and colleagues systematized the discussion in their 2020 paper Green AI, pointing out a serious "Red AI" bias in AI research—papers competing to refresh benchmark scores while rarely reporting computational costs. They pushed top conferences like ACL and NeurIPS to begin requiring papers to disclose their computational resource usage. As the opposite of "Red AI" (oriented toward improving performance at any cost), Green AI incorporates computational efficiency and carbon footprint as core dimensions of model evaluation.

A PhD researcher focused on Green AI shared his open-source tool E2AM (Energy Efficient AI Models) on Reddit. He admitted he had long been troubled by the same problem: to measure the true cost of training (energy consumption, carbon emissions, joules per sample), one often had to patch together CodeCarbon, nvidia-smi scripts, profilers, and homemade plotting tools—a cumbersome and error-prone process.

CodeCarbon is currently one of the most widely used Python carbon emissions tracking libraries, jointly developed by institutions including the Mila Montreal AI institute. It estimates CO₂ emissions by tracking GPU/CPU/RAM power consumption combined with regional grid carbon intensity data. However, using CodeCarbon alone has notable limitations: it only provides total emissions and lacks integrated analysis with model performance metrics. Meanwhile, nvidia-smi is a command-line tool provided by NVIDIA that can query GPU status in real time, but it requires users to write their own scripts to parse the output and synchronize it with the training loop. This fragmentation of tools is precisely the core problem E2AM aims to solve.

Two Lines of Code to Get Started: A Minimalist Integration Approach

E2AM's biggest advantage lies in its extremely low barrier to entry. Developers only need to wrap their training code with a context manager to automatically complete the entire suite of energy monitoring:

from e2am import monitor

with monitor(project="ResNet50"):
    train()

E2AM uses a Python context manager as its primary integration interface, a design choice backed by deep engineering considerations. Through the __enter__ and __exit__ protocol, a context manager naturally guarantees that resource acquisition and release form a symmetric structure—even if an exception is thrown during training, the monitoring session can be properly closed and the collected data saved, avoiding data loss. Compared to an API design that requires users to manually call start() and stop(), the context manager significantly reduces the risk of incomplete monitoring data caused by code path branches (such as exceptions or early returns). This pattern has widespread precedent in Python's scientific computing ecosystem: PyTorch's torch.no_grad() and TensorFlow's tf.GradientTape() both use the same paradigm. Researchers can embed E2AM into code blocks of any granularity—from a single epoch to an entire training pipeline—without worrying about the details of lifecycle management.

Beyond the context manager, E2AM also provides a drop-in Trainer wrapper as well as a TrainerCallback for Hugging Face users. Hugging Face's Trainer class is currently the de facto standard wrapper for NLP/multimodal model training, offering out-of-the-box functionality such as training loops, mixed precision, and distributed training. It is widely adopted in the fine-tuning workflows of mainstream models like Llama, BERT, and Stable Diffusion. TrainerCallback is a hook mechanism provided by Trainer that allows developers to inject custom logic at various lifecycle points during training (such as epoch start/end or logging) without modifying the core Trainer code. By implementing the TrainerCallback interface, E2AM can seamlessly integrate into any Hugging Face-based training pipeline with zero intrusion into the original code structure.

Whether you use native PyTorch or the Hugging Face ecosystem, you can integrate AI training energy monitoring at near-zero cost. For researchers accustomed to manually inserting various monitoring code into their training scripts, this "one line to import, one line to wrap" design significantly lowers the barrier to use.

What Gets Monitored: From Energy Consumption to "Accuracy-per-Joule"

Each E2AM run outputs a complete set of metrics, going far beyond simple power figures.

Basic Physical Metrics

Energy consumption (Wh, watt-hours)
Carbon emissions (gCO₂eq, region-aware, dynamically calculated based on different countries/regions)
GPU utilization
FLOPs/MACs (compute volume)
Latency

Regarding compute metrics: FLOPs (floating-point operations) and MACs (multiply-accumulate operations) are two common units for measuring the computational complexity of neural networks. MACs are usually half of FLOPs, because one multiply-accumulate operation contains two floating-point operations—a multiplication and an addition. Notably, FLOPs are not directly equivalent to actual energy consumption—operations with the same number of FLOPs may have actual power consumption that differs by several times across different hardware and memory access patterns. This is an important reason why E2AM includes both theoretical compute volume and measured energy consumption in its reports: combining the two provides a true reflection of a model's energy efficiency characteristics.

Regarding region-aware carbon emission calculation: Carbon intensity refers to the grams of CO₂ equivalent emitted per kilowatt-hour of electricity produced (gCO₂eq/kWh). This value varies enormously by region—Iceland relies on geothermal and hydroelectric power with a carbon intensity of about 18 gCO₂eq/kWh, while coal-dependent regions may exceed 800 gCO₂eq/kWh. Training the same model in different data centers can result in carbon emissions differing by more than 40 times. E2AM currently uses static national average data, ensuring offline availability while also planning to integrate real-time grid data in its roadmap.

Green AI-Specific Metrics

This is where E2AM's true differentiated value lies:

Energy per sample
Accuracy-per-joule—measuring the model performance gained per unit of energy
EAG (the discrete gradient of accuracy with respect to cumulative energy consumption)

Among these, EAG is a particularly clever design. The design inspiration for EAG (Energy-Accuracy Gradient) comes from the law of diminishing marginal utility in economics, and mapping it onto deep learning training dynamics is naturally reasonable. A classic phenomenon in neural network training is that the loss drops dramatically in the early epochs (corresponding to high EAG). As training progresses, the performance gain from each additional epoch decays exponentially until it approaches zero (EAG ≈ 0). Mathematically, EAG is essentially the first-order difference derivative of accuracy with respect to cumulative energy consumption, with units of "accuracy percentage points per watt-hour."

The traditional Early Stopping mechanism monitors validation set loss and terminates training if the loss does not decrease over several consecutive epochs—this mechanism has now become a standard means of preventing overfitting. However, Early Stopping's decision basis is limited to model performance itself and completely ignores the computational resources already consumed. EAG extends this logic into the energy efficiency dimension: when the number of model parameters far exceeds the data volume, the energy consumed in the later stages of training is often just optimizing noise. EAG reaches zero earlier, naturally forming a training stop signal based on energy cost-effectiveness. Notably, EAG can also be analyzed in conjunction with existing learning rate scheduling strategies, providing an energy-efficiency reference signal for hyperparameter selection—extremely practical for cost-sensitive training scenarios.

Engineering Honesty: The Transparent Boundary Between Measurement and Estimation

E2AM demonstrates rare engineering honesty in its design, which is also key to distinguishing it from many similar carbon emission measurement tools.

Clearly Labeling Data Sources

The tool always indicates whether each value is "measured" or "estimated." This involves an important hardware-level detail: NVML (NVIDIA Management Library) is a C-language API provided by NVIDIA that allows developers to directly query the GPU's real-time power consumption, temperature, utilization, and other hardware sensor data. nvidia-smi itself is a command-line frontend built on top of NVML.

Data center-grade graphics cards (such as the A100, H100, and V100) typically have precise built-in power sensors, and NVML can read factory-calibrated real wattage with an error usually within ±2%. However, the power reading accuracy of consumer-grade graphics cards (such as the GeForce RTX series) varies by model, with errors reaching ±10-15%, and some models can only return estimated values. If the GPU exposes an NVML power sensor, you get real power readings; if not, the tool falls back to an estimation method of "power cap × utilization" and clearly notes this in every report. This transparency is crucial for scientific credibility, ensuring users don't mistake estimated values for precise measurements.

Automatically Quantifying Training "Waste"

The e2am optimize command can read telemetry data from completed runs and quantify the ineffective consumption within them. For example, it might point out: "Validation accuracy had already converged by epoch 6; the last 4 epochs consumed 38 Wh, accounting for 41% of the entire run." This post-hoc analysis can directly guide researchers in optimizing training configurations, reducing unnecessary compute and carbon emissions.

Inference Energy Benchmarking

The e2am benchmark command reports the joules per inference, rather than a mere latency metric. During the model deployment phase, this data is crucial for evaluating actual operating costs.

Local-First: Your Data Never Leaves Your Machine

E2AM generates self-contained HTML/PDF reports, a leaderboard CSV for cross-run comparisons, and a local dashboard. The entire process requires no account, no server, and processes all data locally. For research teams that prioritize data privacy or work in isolated network environments, this local-first architecture is a significant plus.

An Objective Look at the Tool's Limitations

The author does not shy away from the tool's current boundaries:

GPU power reading only supports NVIDIA/NVML; AMD and Apple devices can only fall back to estimation mode;
CPU/RAM power consumption is based on TDP and heuristic estimation, as there is currently no portable, OS-level precise interface;
Only single-node is supported for now; distributed multi-machine training scenarios are not yet supported;
Carbon intensity uses a static national data table; real-time grid data is still on the roadmap.

These limitations reflect common technical challenges in the field of energy measurement, which are shared across the entire industry. Take cross-hardware support as an example: AMD provides the ROCm SMI interface, but it covers a narrower range of GPU models and its API has historically undergone multiple breaking changes. Apple Silicon's powermetrics tool can output chip-level (CPU+GPU+Neural Engine) integrated power consumption, but it requires root privileges and its interface is an informal protocol, making it difficult to integrate into cross-platform tools. All three major platforms lack a unified cross-platform energy API—this hardware ecosystem fragmentation problem is far from being a limitation of E2AM alone.

Take CPU/RAM power consumption as an example: TDP (Thermal Design Power) is the maximum cooling requirement labeled by processor manufacturers and is the most commonly used estimation baseline when sensors cannot be read directly. However, actual power consumption under different workloads can range from just 30% to 120% of TDP. CPU utilization is also a coarse-grained metric that cannot reflect the actual power consumption differences of different instruction sets. These technical details explain why precise full-stack energy measurement remains an open challenge to this day.

Making Energy Consumption a First-Class Citizen in Model Evaluation

E2AM can be installed via pip install e2am, with the code open-sourced under the MIT license on GitHub (Shanmuk4622/e2am). Its significance lies not just in the convenience of the tool itself, but in promoting a shift in mindset: when evaluating AI models, energy consumption and carbon emissions should become first-class citizen metrics, just like accuracy.

As regulatory pressure, computational costs, and sustainability requirements continue to increase, green metrics like "accuracy-per-joule" are likely to become standard dimensions of model evaluation. This trend has a clear historical thread to follow: when AlexNet burst onto the scene in 2012, the sole core metric of the ImageNet competition was Top-5 accuracy—model parameter count and inference speed were not considerations. With the rise of efficiency-oriented architectures like MobileNet (2017) and EfficientNet (2019), the research community gradually formed a "Pareto frontier" analysis paradigm—evaluating models in the two-dimensional coordinate systems of accuracy-vs-parameters and accuracy-vs-inference-latency, rather than simply pursuing the highest score. The rise of Green AI foreshadows that energy consumption will become the third core dimension of this Pareto analysis framework.

This evolution also has strong backing at the regulatory level: the EU AI Act has explicitly required high-risk AI systems to disclose energy consumption, and the U.S. National Institute of Standards and Technology (NIST) AI Risk Management Framework also incorporates sustainability considerations. Regulatory drivers will accelerate this transition from an academic initiative to an engineering practice standard. E2AM provides a usable, transparent, and open-source practical starting point for this direction, and the author especially welcomes community feedback on the Green Score metric formula, as well as suggestions on future integration directions.