Edge Deep Learning in Computer Vision and Medical Diagnostics: A Comprehensive Survey

In plain words

Running an image-recognition model on a small device, such as a camera, a phone, a wearable or a scanner, means the answer comes from the place where the data is made. That gives faster responses, uses less network traffic and keeps raw data on site. The difficulty is that the strongest vision models are large and need powerful hardware that small devices do not have.

This survey looks at both sides of that problem. It sorts edge hardware into three rough tiers, from cheap microcontrollers to powerful boards. It then covers the ways a model can be made to fit a small device: cutting out parts that do little (pruning), storing numbers with fewer bits (quantisation), designing small networks from the start, or letting a search procedure design them. It also lists example uses in driving, factories, farms, shops, wildlife, cities, sport and healthcare.

For someone building a medical tool, the medical chapter gives examples in endoscopy, chest imaging, skin conditions, pathology slides and remote care. The survey is a map with pointers to the original papers. It does not give one recipe to copy.

TL;DR

• This is a survey, not a method. It proposes a three-tier split of edge hardware into low-end, medium-range and high-performance devices §3.1 tab. 2.
• It reviews five routes to smaller models: network pruning, sparse representation, quantised networks, efficient lightweight architectures and neural architecture search §4 tab. 4.
• It surveys computer-vision applications §5 and medical applications §6, and lists future directions §7.
• The survey runs no experiments of its own. Its numbers are quoted from cited works and are author-reported, and several of them conflict with each other (see Pitfalls).

Problem

Deep networks are usually trained on large accelerators and then run on devices with limited compute, memory and power §1. Edge devices can have only a few hundred kilobytes to a few megabytes of memory at the low end §3.1, so a large model may not run at all, or may run at a low frame rate §6.1. Sending data to a cloud server adds latency and bandwidth cost and can conflict with privacy rules for medical data §2.2. The survey frames compression and lightweight design as the way to make on-device inference workable §1 §2.3.

Method

The paper has no algorithm of its own. Its method is a taxonomy and a literature review.

Edge device tiers §3.1 fig. 3

• Low-end: low compute and power, memory from a few hundred KB to a few MB in the authors' description. Suited to inference, not training. Examples: Arm Cortex-M or lower-end Cortex-A parts §3.1.
• Medium-range: multicore CPUs, some GPU acceleration, sometimes an AI accelerator; memory from about 1 GB to several GB. Inference only in practice §3.1.
• High-performance: strong CPU and GPU, several GB up to terabytes of memory. Can train or fine-tune models §3.1.

Device examples tab. 2: the table lists 19 boards and phones by tier with CPU, accelerator, memory and approximate price. Operating systems, frameworks and programming languages are listed per device in the same table.

Compression and lightweight design §4

• Network pruning §4.1: remove redundant parts, then fine-tune. Four variants: weight pruning (unstructured, leaves sparse matrices) §4.1.1; neuron pruning (removes neurons with many zero activations, measured by APoZ) §4.1.2; channel pruning (structured, removes feature-map channels) §4.1.3; filter pruning (removes convolution filters, often with L1 regularisation) §4.1.4.
• Sparse representation §4.2: induce many zero weights or activations, for example with L1 regularisation or ReLU.
• Quantised networks §4.3: store weights and activations with fewer bits, down to 8-bit integers, or 1-bit in the extreme. Mixed precision chooses bit width per layer. Quantisation-aware training is advised to limit accuracy loss.
• Efficient lightweight architectures §4.4 tab. 5 tab. 6: MobileNet (depthwise separable convolutions, inverted residuals, h-swish) §4.4.1; EfficientNet (compound scaling of width, depth and resolution) §4.4.2; ShuffleNet, CondenseNet, MixNet, GhostNet, DiCENet, MicroNet §4.4.3 tab. 5; SqueezeNet, SENet, SqueezeNeXt §4.4.4 tab. 6; MobileViT and EdgeViT mobile transformers §4.4.5.
• Neural architecture search §4.5 tab. 7: automated design, with latency-aware variants (MNASNet, ProxylessNAS). The survey notes the search itself is costly.

Pseudocode of the two pruning procedures the survey describes in prose. The paper has no algorithm block and no equations, so these are our restatement of its text, not code from the original papers.

# Weight pruning: train, threshold, retrain  [§4.1.1]
# Input:  network, threshold (pre-set, value not stated)
# Output: sparse weights, stored in compressed sparse row/column form

def prune_weights(network, threshold):
    # Stage 1: train normally to learn which connections matter  [§4.1.1]
    trained = train_dense(network)
    # Stage 2: drop connections whose magnitude is below the threshold  [§4.1.1]
    mask = abs(trained.weights) >= threshold
    # Stage 3: retrain survivors from the stage-1 weights  [§4.1.1]
    sparse = retrain_masked(trained, mask, start=trained.weights)
    # Store the pruned matrix in a compressed sparse format  [§4.1.1]
    return compress_sparse(sparse)

# Inference-based channel pruning  [§4.1.3]
# Input:  feature map of one conv layer
# Output: kept channels and a reconstructed output feature map

def prune_channels(feature_map):
    # Stage 1: pick the most representative channels; drop the rest  [§4.1.3]
    # The survey does not name the selection criterion.
    kept = select_channels(feature_map)
    # Stage 2: rebuild the output from the pruned map by least squares  [§4.1.3]
    rebuilt = least_squares_reconstruct(feature_map, kept)
    return kept, rebuilt

Application chapters: computer vision §5 covers autonomous driving §5.1, manufacturing §5.2, agriculture §5.3, retail §5.4, environmental monitoring §5.5, smart cities §5.6 and sport §5.7. Medical applications §6 cover gastrointestinal §6.1, pulmonary and thoracic §6.2, dermatological §6.3, pathology §6.4 and telemedicine §6.5. Figures fig. 9 to fig. 12 show example applications; their captions credit the cited works. They are described in words only here.

Hyperparameters

The survey runs no experiments and gives no training recipes. The table lists every numeric setting the text states, plus the gaps.

Results

Author-reported. The survey runs no experiments of its own: every number below is quoted from a cited work, with the dataset and setup the survey states. Compare numbers only within a row; they come from different datasets, input sizes and hardware.

YOLOv3 on three edge platforms tab. 3 (the caption credits the benchmark to another work)

Headline figures quoted in the survey

Paper vs code

No official code.

Searched: (1) links in the paper, abstract and arXiv metadata. The arXiv record carries no comments field and no project page is linked. The only repositories linked in the text are third-party (SparkFun Edge hardware repository in §3.2, and the Ultralytics YOLOv5 repository in §5.1). (2) Project pages: none. (3) GitHub repository search for "edge deep learning computer vision medical diagnostics survey" returned no results. A survey has no training code, so code is omitted.

Pitfalls

• No method to implement. This is a survey. An agent cannot reproduce "the method" from this card; implement from the cited original papers, which are not in this wiki unless they have their own cards (see Lineage).
• Conflicting accuracy for MobileNetV2. §4.4.1 gives 72.0% top-1 for MobileNetV2, but §4.4.4 uses 70.6% as the MobileNetV2 baseline when reporting the SENet gain to 74.7%. 70.6% is also the MobileNetV1 figure in §4.4.1.
• Conflicting PNASNet numbers. §4.5 gives a CIFAR-10 top-1 error of 3.41% (about 96.6% accuracy) and, in the same section, a CIFAR-10 top-1 accuracy of 82.9%. Both cannot hold for the same setup. Do not use either without the original paper.
• Implausible MNASNet compute. §4.5 reports "312 billion MAdds" for MNASNet. For a mobile model this is far outside the usual range, and it is probably a unit error. Not checked against the cited paper.
• Table 3 does not add up. Frame count divided by FPS gives roughly 638 s for the Raspberry Pi row (stated 690 s), 939 s for Jetson Nano (stated 967 s) and 262 s for Xavier NX (stated 256 s), over 1,596 frames. The source of the benchmark is credited to another paper, so the mismatch may come from a different measurement. Treat the timing column as indicative only.
• Ambiguous channel-pruning result. §4.1.3 says a YOLOv3 pruning method keeps "39.8% of the original mean average precision" on COCO. This could mean the mAP is 39.8% of the original, or that 39.8% is the mAP. Check the cited work.
• Device tiers do not match the memory ranges. §3.1 gives low-end memory as "a few hundred kilobytes to a few megabytes", but Table 2 places boards with 1 GB and 4 GB in the low-end tier. Jetson Nano is also called "base" in §3.2 yet listed as medium-range in Table 2. Two rows of Table 2 (Jetson NX Xavier and Dell Precision 3660) have no tier label in the source. Prices are approximate and region-dependent, as the table caption says.
• Cross-paper numbers are not comparable. Accuracy, latency and energy figures come from different datasets, input sizes, hardware and software stacks. Only compare within a row of a cited study.
• Clinical and market claims are quoted, not checked. Examples: a 25% polyp miss rate in colonoscopy, a 20% mortality reduction from low-dose CT screening, and the market-size figures in §1. The card does not verify them.
• Publication status. The title page of the source states "Published in Artificial Intelligence Review 58(3):93 March 2025" and "updated version with corrections". The arXiv record for this card is v1, dated 2026-05-07; the card uses that version.
• Speculative sections. §7.7 (quantum-inspired computing) and parts of §7.8 (human-centric applications) describe possibilities without reported results. Treat them as directions, not findings.
• Figures are not reproduced. Twelve figures are described in the text only. Fig. 12 is credited in its caption to another work §6.2; it is not used here.

Lineage

• Builds on: none stated. The survey positions itself against seven prior surveys of edge computing and deep learning, compared in Table 1 tab. 1.
• Compared against: the seven related surveys in tab. 1, which the survey judges by hardware, lightweight models, compression, vision and medical scope.
• Surveyed works with a card in this wiki: ProxylessNAS (hardware-aware NAS), cited in §7.3 as an example of hardware-aware search: /papers/1812.00332.
• Superseded by: not known from content in this wiki.