Zeus: Measuring and Optimizing Energy Consumption in Deep Learning Workloads

The gap Zeus fills between FLOPs and joules

Most deep learning tooling reports time, throughput or memory. Energy is usually inferred from a thermal design power figure multiplied by wall-clock time, which assumes the accelerator runs at its rated ceiling for the whole job. That assumption is wrong often enough to matter, because real training and inference workloads spend time waiting on data loaders, synchronizing across ranks, or running at reduced clock rates. Zeus exists to replace that inference with measurement. The README describes it as a library for measuring the energy consumption of deep learning workloads and for optimizing it. The intended audience is engineers and researchers who need to compare two configurations, two batch sizes, or two model variants on an energy axis rather than a latency axis. The project is a product of The ML.ENERGY Initiative and sits alongside the ML.ENERGY Benchmark and leaderboard, which suggests the library is built to feed a measurement pipeline rather than to be an end in itself.

How Zeus is organized and where measurement happens

The repository layout in the README shows a Python package with a monitor subpackage for energy and power measurement, exposed both programmatically and through a CLI. A separate optimizer subpackage holds a collection of time and energy optimizers. A device subpackage provides an abstraction layer over CPU and GPU devices, which is the piece that lets the same measurement call work across vendors. The README states that Zeus supports CPU, DRAM, AMD GPU, Apple Silicon and NVIDIA Jetson platform energy measurement as of May 2025, in addition to NVIDIA GPUs. Alongside the Python package sits zeusd, the Zeus daemon, a separate component released on its own version cadence and published to crates.io. That split matters: the daemon is a long-running process that the Python client talks to for GPU power readings, while the Python package handles the rest of the measurement and optimization surface. There is also metric.py for Prometheus metric export, show_env.py for installation and device detection verification, and callback.py as a base class for callbacks during training. The callback base class is how energy measurement gets attached to an existing training loop without rewriting it.

Getting it installed and confirming the devices it can see

The README points to a Getting Started page rather than embedding install commands, so the exact pip invocation is not in the supplied material and should be read from that page. What the material does give is the verification step: zeus/show_env.py is described as an installation and device detection verification script. That script is the first thing to run after installation, because every later measurement depends on the device abstraction correctly identifying what is present. For GPU measurement you also need the daemon. The README notes that zeusd is released separately, with a zeusd-v* tag publishing to crates.io, and that recent releases pair a Python version with a daemon version, for example zeus-v0.16.0 alongside Zeus Daemon v0.5.0. Docker is offered as the path of least resistance: the README references a Docker Hub repository and a Dockerfile under docker/, and says the image is fully equipped with all dependencies and environments. If you want an agent to drive measurements, skills/measuring-energy/SKILL.md is a portable Agent Skill that the README says teaches coding agents to measure energy and power with Zeus, installable from the ML.ENERGY plugin marketplace for Claude Code and Codex users.

The optimizer side is research-backed but narrower than the measurement side

Zeus is not only a measurement library. The optimizer subpackage collects time and energy optimizers, and the README ties the most prominent one to a specific paper: Perseus, described as an optimizer for large model training, appeared at SOSP 2024, with a blog post and a link to the pipeline frequency optimizer documentation. That is a concrete mechanism with a published evaluation behind it, and the README also credits the original Zeus paper at NSDI 2023 as the foundation. The honest reading is that measurement is the broad, general-purpose part of the project, while optimization is a smaller set of techniques tied to particular research results. If you arrive expecting a general autotuner that will reduce the energy of an arbitrary model, the README does not promise that. It promises a collection of optimizers, and the one it names by name targets large model training pipelines. The _legacy subpackage is explicitly there to keep research papers reproducible, which tells you the project carries older code forward rather than deleting it, and that some paths in the tree are not the current recommended interface.

Where Zeus is the wrong tool

Measurement tools fail quietly, and that is the main risk here. Zeus reads power from hardware counters and platform interfaces. The README lists supported platforms, and anything outside that list is not covered. If you are on an accelerator the device abstraction does not recognize, you will either get an error from show_env.py or, worse, a reading that does not correspond to the device you care about. The daemon requirement is a second constraint: GPU measurement depends on a separate process with its own version number, and the README pairs specific Python and daemon releases, which means a version mismatch between the two is a real failure mode to plan for. A third limitation is scope. Zeus measures energy consumption of deep learning workloads. It is not a cluster scheduler, not a carbon-aware job placement system, and not a cost accounting tool. If your actual question is which region to run a job in, or how to shift load to hours when the grid is cleaner, Zeus gives you the energy number but not the decision layer. Finally, the README does not describe the sampling rate or the accuracy of the readings relative to an external power meter, so any claim that a Zeus number is ground truth should be treated as unverified until you check it yourself.

How Zeus differs from CodeCarbon and from reading nvidia-smi yourself

CodeCarbon is the obvious alternative for teams that want an emissions estimate attached to a training run. The difference in approach is what gets measured. CodeCarbon is built around estimating carbon intensity and converting energy into CO2 equivalent, with regional grid data as a first-class input. Zeus is built around the energy and power measurement itself, per device, with no carbon accounting layer described in the README. If your deliverable is a sustainability report, CodeCarbon's framing fits better. If your deliverable is a comparison between two kernel implementations on the same machine, Zeus is closer to the question. The other alternative is not a library at all: polling nvidia-smi and integrating the power draw over time. That works on NVIDIA hardware and costs nothing to set up, but it gives you one vendor, no CPU or DRAM coverage, no callback integration into a training loop, and no optimizer collection. Zeus wraps that same class of hardware counter behind a device abstraction and adds the training callback and the daemon, which is the actual value over a shell script. Whether that value justifies a daemon deployment depends on how many machines you need to instrument.

Release cadence, licence and the cost of staying current

The README states that Zeus follows semantic versioning, that pushing a zeus-v* tag releases the Python package to PyPI and a zeusd-v* tag releases the daemon to crates.io, and that releases are cut when meaningful changes land, which has meant roughly every one to three months. The recent release list is consistent with that: v0.14.0 in February 2026, v0.15.0 later the same month, and v0.16.0 in July 2026, each pairing a Python version with a daemon version. Every release requires green CI on master, and breaking changes are called out in the release notes. The practical cost is that you are tracking a pre-1.0 library on both the Python and daemon sides, so upgrades are a real maintenance item rather than a background concern, and the paired versioning means you cannot upgrade one half without checking the other. The licence is Apache-2.0, which is permissive and includes an explicit patent grant, and the README links the LICENSE file at the repository root. That is a standard choice for a research-derived tool and does not impose copyleft obligations on your own code, but as always the licence text governs and this is not legal advice. Fixes that affect measurement correctness are stated to ship as soon as they are ready, which is the right policy for a tool whose output is a number people will cite.

Editorial conclusion

Adopt Zeus if you run deep learning training or inference on supported hardware and need programmatic energy and power numbers rather than estimates from TDP tables, and if you are willing to deploy the Zeus daemon for GPU measurement. Do not adopt it if your accelerators fall outside the documented support list, or if you need a single number you can trust without validating it against an external power meter. Before committing, run the package's own environment verification script (zeus/show_env.py) on the target machine and confirm that device detection matches the hardware you actually intend to measure.

Official sources

1. License: Apache-2.0
2. ml-energy/zeus on GitHub
3. Project website
4. README
5. Releases