To choose an edge AI accelerator for offline crop-disease detection, benchmark the candidate boards on your own detection model. Measure sustained frames per second and power at the power mode and worst-case ambient temperature the machine will actually run at. Datasheet TOPS and detector-only FPS do not settle the choice: a 2026 agricultural Jetson benchmark found that the winning board changed with workload, precision, power mode and measurement boundary, not with board class alone.

TechnoLynx handles the engineering behind that measurement. TechnoLynx sets drone and tractor power and throughput budgets as two separate problems, chooses candidate boards and precision strategies for each power ceiling, and ports and optimises the multispectral detection model for the target hardware (TensorRT on Jetson Orin, for example). TechnoLynx then benchmarks sustained FPS and power under realistic thermal conditions and confirms detection accuracy holds after optimisation. TechnoLynx’s AI engineering work for agriculture starts by defining the minimum real-time frame rate your field operation needs.

How much onboard compute does a disease-detection model need without cloud access?

No board class answers this, because the requirement is the product of two things you own: the frame rate the operation needs and the per-frame cost of your model at your input resolution. Work it out from the machine and the field, not from what a board happens to deliver.

Published crop-disease deployments show how wide the range is. A 2026 deployment-oriented review lists a rice-leaf disease model (DBLA-MobileNetV2, FP16 with TensorRT) at 12.40 FPS on a Jetson Nano. A wheat-rust detector built on a modified YOLO architecture reached 16.8 FPS on a Jetson TX2 and 13.6 FPS on a NavQ Plus, with energy efficiency of up to 2.7 FPS/W. YOLO-PLNet, a peanut leaf-disease model derived from YOLO11n, ran on a Jetson Orin NX fed by a CSI camera at 28.2 FPS in FP16 and 41.3 FPS in INT8.

Input resolution moves the answer too. In the same YOLO-PLNet study, going from 640×640 to 1280×1280 input raised latency from 19.1 ms to 32.6 ms and cut throughput from 28.2 to 13.4 FPS, and the authors settled on 640×640.

The same 2026 review notes that the treatment window for fungicides or bactericides is often only a few hours. A system that hits its frame rate for the first ten minutes and then throttles leaves holes in the map exactly when they matter.

Drone or tractor: how far apart are the power and weight budgets?

The two platforms are budgeted differently, because a drone pays for every watt and gram in flight time.

On a drone, propulsion typically uses 80–85% of the energy budget, and a drone camera-module guide allocates roughly 2–10 W of the remainder to compute. Its worked example fits an RGB camera, gimbal and AI module totalling 8.8 W into the 12 W payload budget of a mid-size 7-inch platform. Weight compounds: every 10% increase in take-off weight typically reduces hover endurance by 8–12% on a fixed battery. A UAV integrator puts the power cost at about 0.5–1.0% of endurance per watt on a typical 6S industrial quadcopter, so a 15 W companion computer on a craft drawing 350 W in hover cuts endurance by 4–7%. On that integrator’s numbers, a 200 g computer takes 13% of a 1.5 kg payload allowance. Converter losses count as well: a Jetson Orin NX at 15 W behind a 90%-efficient DC-DC converter draws 16.7 W from the battery.

An in-vehicle integrator’s guide says vehicle compute draws from the auxiliary supply, sits in a sealed enclosure, and must be sized for sustained load at worst-case ambient, not the lab’s. A tractor relaxes the watt ceiling, but a cab in full sun still caps what the board can sustain.

Decision table: drone versus tractor

Factor	Drone	Tractor
Weight	Every gram costs endurance and payload	Secondary
Selection rule	Highest benchmarked sustained FPS that stays within the total budget	Highest FPS, or lowest cost per required FPS, since power is less constrained
Thermal risk	Sealed avionics bay, sun exposure	Sealed cab enclosure, worst-case ambient
If nothing fits	Quantise, compress or reduce input resolution before changing hardware	Step up a board class or power mode

For a tractor build considering an L4-class data-centre card, LynxBenchAI’s published results indicate how candidate cards run the public PyTorch stack. In the 26Q3 results the NVIDIA L4 scores 150.1 overall and 209.1 in inference on native Linux. On that release’s public PyTorch stack, its int8 inference scores sit below its fp16 scores on every inference model listed, for example 146.7 against 534.9 on MobileNetV3. Those are LynxBenchAI scores rather than frame rates, measured on reference models rather than a crop-disease detector, so they indicate how the card runs PyTorch workloads and do not measure your pipeline. They do show why the precision choice has to be measured on the target, not assumed.

How do I measure the frames per second a board sustains under 25 W?

Measure the whole system for at least a minute of steady inference, with power read at the board input. Also fix and record the timing boundary, batch size, input size, precision and power mode, because each one changes the result.

Scope the 25 W to the whole system

MLPerf Power, the industry methodology published by a consortium of more than 20 organisations, measures full-system power and counts every peripheral that cannot be powered down during operation. For a crop-disease drone, the multispectral camera draws power alongside the board. MicaSense specifies its RedEdge-P multispectral camera at 7 W average and 10 W peak, with 5.5 W on standby.

Worked example: does an Orin Nano Super fit a 25 W drone budget?

The assumptions here are assumptions, not a measurement of any one build.

1. Camera: the RedEdge-P at its 10 W peak, since the supply must cover the peak. That leaves 25 − 10 = 15 W.
2. Compute: a 2026 study of a full detector-tracker-analytics pipeline on a Jetson Orin Nano Super measured 8.41–10.14 W mean module power via tegrastats telemetry.
3. Telemetry bias: AgriJetsonBench found internal Jetson readings averaged 1.988 W below external board-input power. If a similar bias applies here, board-input power is about 10.4–12.1 W (8.41 + 1.99 and 10.14 + 1.99).
4. Radio: the camera-module guide puts a video transmitter at about 1–3 W.
5. Total: 10 + 12.1 + 3 = 25.1 W at the worst end, before any converter loss.

That is already over the 25 W budget. The board alone is not the problem: a multispectral camera at peak plus honest board-input power leaves almost no margin, and a measurement taken only on the compute module would have hidden that.

Fix the measurement boundary before you compare numbers

AgriJetsonBench, a 2026 crop/weed benchmark on the Jetson AGX Orin 64GB and Orin Nano Super, reports its main results at a pure TensorRT engine boundary with batch size 1 and 640×640 input. That timed region excludes image loading, CPU-side preprocessing, resizing, non-maximum suppression and postprocessing. The authors warn that pipeline-level results should not be mixed with pure-engine energy figures. The fruit-detection study on the Orin Nano Super made the same distinction from the other side: detector-level speed says little about a full video system, where decoding, preprocessing, tracking and memory movement run together.

Batch 1 is the right default for a camera on a moving platform, because frames arrive one at a time and per-frame latency is what the deployment feels. One more trap: in a pipelined DeepStream graph, frame latency of 121–156 ms coexisted with throughput above 30 FPS, so latency is not the inverse of throughput.

A sustained-run protocol

The fruit-detection study’s protocol is a sound template:

1. Lock the power mode with nvpmodel and the clocks with jetson_clocks, and keep the cooling configuration identical across runs.
2. Record a 20-second idle-power baseline under the same configuration.
3. Cool the board to about 50 °C before each run.
4. Run 50 warm-up predictions, then 60 seconds of continuous batch-1 inference, synchronising CUDA around each measured call.
5. Log telemetry with tegrastats at 100 ms intervals, recording preprocessing, inference and postprocessing latency separately.
6. Report energy both gross and with idle power subtracted.

Sixty seconds matches MLPerf Power’s minimum measurement duration. AgriJetsonBench adds external board-input logging with an INA260 sensor as the primary energy reference, with internal telemetry kept for diagnostics only. It also runs battery-continuation tests from 100% to 20% power-bank charge.

Datasheet TOPS do not predict delivered frames per second

AGX Orin’s 275 TOPS relies on 2:4 sparsity, and NVIDIA’s dense INT8 figure is 138 TOPS. Peak TOPS are only available in the top power mode with adequate cooling, and memory bandwidth, operator mix, preprocessing and throttling all reduce what reaches the application.

NVIDIA’s Jetson Linux guide states that MAXN is not the maximum-performance mode, because hardware throttling engages once total module power exceeds the TDP budget. The same guide says the 25 W and 40 W module TDP budgets for Orin Nano and NX apply only with the Super flash configurations. A “25 W” board can therefore be a different machine depending on how it was flashed.

AgriJetsonBench shows the consequence. At a matched 15 W in INT8, the Orin Nano Super beat the AGX Orin on YOLO11s, with 145.82 FPS and 0.0767 J per inference against 80.90 FPS and 0.1814 J. It also won on SegFormer-B0, with 47.18 FPS against 31.95 FPS. In each board’s native mode on SegFormer-B0 FP16 the result flipped: AGX Orin at 50 W reached 103.61 FPS against 67.47 FPS for the Nano Super at 25 W, with energy per inference nearly tied at 0.3205 and 0.3229 J. The larger board won one comparison and lost the other. Which one applies to a drone depends entirely on the power mode the airframe can afford.

Host-side overhead is the other gap. The EdgeFirst Perception Index write-up, a vendor-adjacent source, reports that preprocessing, memory copies and postprocessing often dominate real-world throughput. That is why it publishes realised throughput next to core accelerator throughput.

FP16 or INT8 on your own model

Among the deployments the 2026 review tabulates, quantisation is the most common optimisation, used in more than half of them. Its payoff is not uniform. On the Orin NX, INT8 raised YOLO-PLNet’s frame rate by 46.45% over FP16 and cut latency by 38.21%, while detection accuracy slightly decreased to 97.5%. On the Orin Nano Super, the fruit-detection study found INT8 gave only a modest additional energy reduction and no throughput gain. On edge NPUs running full-integer INT8, the EdgeFirst write-up puts the accuracy cost at typically three to five percentage points of detection accuracy.

Three studies, three different answers. TechnoLynx benchmarks FP16 and INT8 for each candidate board on the actual model, confirms detection accuracy holds after optimisation, and lets that table decide.

What a field-realistic benchmark measures besides throughput

A survey of edge performance benchmarking found that most benchmarks do not use data from a real edge test bed and that energy is often left out. The 2026 agricultural review finds latency and energy metrics not well documented in the agricultural studies it covers. A field-realistic benchmark should cover these items:

• Tail latency over a long run. One integrator’s protocol runs 30 minutes sustained and records 99th-percentile latency to catch throttling events.
• Throughput at worst-case ambient. The same integrator illustrates a platform dropping from 4×30 FPS to 4×22 FPS once throttling begins at 65 °C ambient. A UAV integrator reports an Orin NX in a sealed bay at 50 °C throttling its GPU from 918 MHz to 600–700 MHz, a 25–35% loss in throughput.
• Enclosure behaviour. In a climate-chamber test of a Jetson device at +40 °C, YOLOv8s FP16 inference held 108.8 FPS at 19.1 W with chip temperatures well below the throttling threshold, while a synthetic stress test triggered throttling at a GPU temperature of 95.6 °C.
• External board-input power and energy per inference, not internal telemetry alone.
• Accuracy after optimisation, evaluated together with latency, power and energy per inference.
• Mass and installed volume for drones, since avionics-bay space and payload weight are constrained.
• Run validity: confirmed power mode, no failed inferences, no reboot, out-of-memory or overtemperature event, and no logger gaps.

For the thermal part, a separate guide covers validating edge GPU throughput and latency under worst-case field conditions, including the step from bench to vehicle. The UAV integrator recommends a two-hour thermal-chamber test at worst-case ambient with the bay sealed, accepting no more than 10% throughput loss.

The multispectral numbers nobody has published

No source cited here measures a multispectral crop-disease model on candidate boards, so the published numbers above stand in for that measurement; they are not a forecast. For this page’s decision, the practical point is that the first trustworthy multispectral figure for your machine will be the one you measure on it, at its power mode, in its enclosure, with the camera drawing power alongside it.