Article reader Listen + reading controls
Article reader
Preparing the reader…
Reading settings
At the edge, every joule is a model requirement¶
The Defense Advanced Research Projects Agency's (DARPA) September 24 update describes its Mapping Machine Learning to Physics (ML2P) program. The program aims to relate machine-learning performance to physical electrical characteristics so designers can optimize not only for accuracy, but also for the useful performance returned by each joule.
At the tactical edge, that is not an efficiency exercise. It is mission engineering.
Artificial intelligence (AI) development often begins with a dataset, a model family, and a target accuracy. Energy enters later as a deployment problem. That sequence is tolerable in a data center with abundant power and cooling. It fails quickly on an unmanned platform, a wearable system, a remote sensor, or a vehicle supporting multiple competing loads.
The energy constraint changes which capability exists at all.
Accuracy is only one axis of utility¶
A model that scores highest in a laboratory may be less useful if it drains a battery, produces an answer after the decision window, requires a network connection, or displaces another critical function.
Edge requirements should describe a performance envelope:
- accuracy and uncertainty for mission-relevant conditions;
- energy per inference or useful decision;
- latency, throughput, memory, and thermal load;
- behavior during degraded power or communications;
- hardware and software dependencies;
- and the value of the resulting action to the operator.
Those measures expose tradeoffs that one aggregate benchmark conceals. A smaller model operating continuously may outperform a more capable model that can only be invoked occasionally.
Hardware, software, and mission must be co-designed¶
ML2P's premise connects model construction to the physical behavior of computing systems. That connection should extend to the mission workflow.
Systems engineers, machine-learning researchers, hardware engineers, cyber professionals, maintainers, and operators need to make decisions together. Quantization, sensing frequency, batching, model routing, and duty cycles affect not only energy use but also what the operator sees and when. Cyber controls and encryption consume resources too. So do displays, radios, and recovery mechanisms.
Optimizing one component in isolation can move the burden somewhere less visible.
Test the whole energy story¶
Representative evaluation should measure energy on target hardware under realistic temperatures, data rates, network conditions, and concurrent loads. It should include startup, idle, peak processing, model updates, storage, and communications—not just the central inference.
The test should also examine failure behavior. What happens when the power budget shrinks? Can the system degrade gracefully to a smaller model, lower sampling rate, or advisory mode? Does the operator know that performance has changed?
This is where human-centered design and resource engineering meet. A quiet reduction in system capability can produce misplaced confidence. An explicit change in mode gives the operator a chance to adapt.
Make energy visible in portfolio decisions¶
Program managers should ask for energy evidence at the same reviews that consider performance, security, and readiness. Common measures can help compare architectures and reveal when a capability depends on unrealistic logistics.
At the edge, compute is never disembodied. Every model competes for power, space, heat, attention, maintenance, and time. Designing with the joule from the beginning makes AI less magical and more useful—which is exactly what a mission system needs.
Sources and research trail¶
- Defense Advanced Research Projects Agency, “Energy-Aware Machine Learning” (September 24, 2025).
- National Institute of Standards and Technology, Artificial Intelligence Risk Management Framework 1.0 (2023).
- National Research Council, Human-System Integration in the System Development Process (2007).
- Endsley, “Toward a Theory of Situation Awareness in Dynamic Systems” (1995).