Home โ€บ Guides โ€บ Hardware, power and cost

Jetson AGX Orin Battery Runtime: Power Modes, Losses and a Worked Estimate

Updated October 21, 2026 ยท By the Xingyu Zhitong editors

Putting an NVIDIA Jetson AGX Orin on a robot, drone or vehicle raises one question quickly: how long will the battery last? The answer is a division of watt-hours by watts, but both numbers hide traps. The watt-hours on the label are not what you can use, and the watts are not the module's power budget alone. This article builds an estimate step by step and shows where field results usually differ from the first calculation.

What NVIDIA publishes for the module

NVIDIA's Jetson Orin page lists the AGX Orin 64GB at 275 TOPS with 64 GB of 256-bit LPDDR5 at 204.8 GB/s, and the AGX Orin 32GB at 200 sparse INT8 TOPS with 32 GB at the same bandwidth. Both are listed with a configurable power range of 15 W to 60 W. (The product page's tables are laid out in a way that makes per-model reading error-prone, so confirm against the official data sheet when precision matters.) The unified memory is shared between CPU and GPU, which affects capacity planning for models, a topic touched on in GPU memory estimation.

NVIDIA's Jetson Linux developer guide documents power modes for the AGX Orin 64GB. The modes are MAXN, with no power budget limit, and three budgeted modes of 15 W, 30 W (the default) and 50 W. Each mode sets how many CPU cores are online, the maximum CPU, GPU and memory clocks, and the deep-learning accelerator settings, so a lower mode runs the same code more slowly. On the device you select a mode with the nvpmodel tool and can watch real-time power and utilization with tegrastats. Use the documentation for your Jetson Linux release because available modes can differ between releases and module variants.

Step 1: Know what the power number covers

A power mode budget describes the module's own consumption target. Your system draws more: the carrier board or developer kit, cameras, any LiDAR, radios, USB devices, NVMe storage, fans, and the converter losses between battery and everything else. As a planning habit, take the module's measured average, then add each peripheral's published power, then divide by converter efficiency.

Two points about measuring. First, the mode's name is a budget, not a measurement. A 30 W mode running a light workload may average well under 30 W, and a heavy mixed CPU and GPU workload can hit the limit and throttle. Second, power is workload-dependent: a model running at a fixed 30 frames per second draws less than the same model running as fast as possible. Measure with the actual model, resolution, batch size and frame rate with tegrastats, or better, with an inline power meter between the battery and the system, because the meter includes the losses.

Step 2: Get usable energy from the battery

Battery capacity is quoted in amp-hours at a nominal voltage, so energy in watt-hours is Wh = V ร— Ah. A pack labeled 5,000 mAh at 14.8 V nominal holds 14.8 ร— 5 = 74 Wh. Usable energy is lower for several reasons:

Power banks add one more twist: the capacity printed on the box is usually the energy of the internal cells at their nominal voltage, while the energy delivered at the output port, after step-up conversion, is lower, often around 60 to 85 percent of the label depending on design. Treat the label as an upper bound and look for a tested figure if possible.

For travel, most airlines restrict spare lithium batteries above a certain watt-hour rating (a commonly cited threshold is 100 Wh); confirm your airline's current rules before flying with a large pack.

Step 3: Do the arithmetic

Use this formula:

runtime (hours) = battery Wh ร— usable fraction ร— converter efficiency รท total system watts

Worked example, all values assumptions for illustration. A 99 Wh pack, 85 percent usable after reserve and cold derating, 90 percent converter efficiency, powering an AGX Orin 64GB in the 30 W mode running a vision model:

Now see how much the module mode matters. If a lighter model lets the 15 W mode hold your frame rate and the module averages 12 W, the load is 12 + 9 = 21 W and runtime becomes 75.7 รท 21 โ‰ˆ 3.6 hours, a gain of about 64 percent. If instead you run MAXN with a heavy pipeline averaging 50 W, the load is 59 W and runtime is 75.7 รท 59 โ‰ˆ 1.3 hours. Peripherals are a significant fraction at low power, so optimizing them (turning off unused cameras, lowering fan speed when cool) matters more at 15 W than at 50 W. The Jetson AGX Orin YOLO battery endurance calculator lets you vary these inputs.

Step 4: Tune the workload before you buy a bigger battery

Battery weight and cost scale linearly with capacity, while software optimization is often free. Options in rough order of payoff:

  1. Run a lower power mode that still meets your frame-rate target. Real-time does not mean maximum speed. If a detector must produce 30 frames per second and finishes in 12 ms, the GPU is idle most of each frame, and a mode with lower clocks may still meet the deadline at much lower power.
  2. Use a smaller or more efficient model. Compare model sizes (for example a nano or small variant of a YOLO family model against a large one) on accuracy you need rather than accuracy you might want.
  3. Use reduced precision. INT8 and FP16 inference engines compiled with TensorRT run faster per watt than FP32; our quantization guide discusses the trade-offs, and the same logic applies to vision models, though accuracy must be validated on your own data.
  4. Use the deep-learning accelerators (DLA) where your layers are supported; they are designed to be more energy-efficient than the GPU for supported operations. Support depends on the network.
  5. Reduce input rate and resolution. Processing every second frame, or cropping to a region of interest, cuts work proportionally.
  6. Skip work when nothing changes. Trigger heavy inference with a cheap motion detector.

Why the first field test disappoints

Real runs usually come in below the spreadsheet for predictable reasons. Boot and model-loading phases draw more than steady state. Engines built by TensorRT on first launch take minutes of full-power compilation, so build them ahead of time and store them. Wireless transmission of video or results can add several watts. Sensor warm-up, logging to storage and a display attached for debugging all add up, and the display is often forgotten. Voltage sag under load can trigger the pack's protection circuit early, ending the run before the nominal energy is used, especially with small packs and cold weather. Keep a log of battery voltage and module power over the whole run, then adjust the usable fraction and the peripheral estimate to match the log rather than tuning the formula to hide the gap.

Thermal considerations

At 30 W and above the module needs real cooling. A sealed enclosure with no airflow can overheat, forcing the module to throttle clocks, which reduces frame rate and defeats the point of the chosen mode. In a drone, propeller wash may provide airflow in flight but not on the ground. The cooling arguments at server scale in air versus liquid cooling apply in miniature: heat leaving the enclosure must equal heat produced, so a 35 W load needs a path for 35 W at the temperature your enclosure can tolerate. Fan power counts against the battery too.

Large language models on a Jetson

Running a small language model on AGX Orin is feasible, and the memory bandwidth of 204.8 GB/s sets the ceiling for token generation, in the same way discussed in tokens per second. A 4-bit 7B model has weights near 4 GB, so a bandwidth-only upper bound is about 204.8 รท 4 โ‰ˆ 50 tokens per second, and real results are lower. Sustained generation keeps the GPU busy and draws more power than a periodic vision workload, so battery estimates for language models should use measured power during generation, not the vision-workload figure. See running 7B models on one GPU for sizing logic.

Checklist

This article offers general engineering guidance, not safety certification for any product. For products carrying people or operating near people, follow applicable safety standards and consult a qualified engineer.

Sources

Figures are estimates based on published model configurations and vendor specifications. Real memory use, speed and power draw depend on the software stack, drivers, settings and workload, so test on your own hardware before you buy. Spotted a mistake? Email huhuwen09@gmail.com with the page address and we will check and correct it.