---
title: Hardware-Aware NAS
url: https://www.emergentmind.com/topics/hardware-aware-neural-architecture-search
type: topic
---

# Hardware-Aware NAS

Hardware-aware neural architecture search (HW-NAS) denotes neural architecture search in which task performance is optimized together with hardware metrics such as execution latency, energy consumption, memory footprint, model size, and, in custom-hardware settings, area or hardware configuration variables. In the 2021 survey of the field, HW-NAS is organized along four key dimensions—search space, search strategy, acceleration technique, and hardware cost estimation strategy—and is motivated by the observation that architectures synthesized without hardware constraints are often too complex for IoT, mobile, and embedded deployment [2101.09336]. A representative early formulation extended FBNet-style differentiable NAS by adding an explicit energy term to an accuracy-and-latency loss, producing a Raspberry-Pi-specific child architecture named HANNA and making explicit the multi-objective, device-specific nature of the problem [1906.07214].

## 1. Optimization objectives and formal problem statements

At its most general, HW-NAS is formulated either as constrained optimization or as multi-objective optimization. The survey formalizes the constrained case as
\[
\max_{\alpha \in A} f(\alpha,\delta) \quad \text{s.t.}\quad g_i(\alpha)\leq T_i,\ \forall i\in I,
\]
where \(g_i\) denotes a hardware metric and \(T_i\) its threshold, and the multi-objective case as the simultaneous optimization of accuracy, latency, memory, energy, or related metrics under Pareto optimality rather than scalar accuracy alone [2101.09336]. This distinction is central: many HW-NAS systems either search directly for a Pareto front or scalarize several objectives into one differentiable or evolutionary fitness.

The HANNA formulation exemplifies scalarized differentiable HW-NAS. For architecture \(a\) with weights \(w_a\), the loss is
\[
L(a, w_a) = CE(a, w_a) + \alpha \cdot LAT(a)^\beta + \gamma \cdot ENER(a)^\delta,
\]
and the NAS objective over supernet parameters \(\theta\) is
\[
\min_\theta \mathbb{E}_{a \sim P(\theta)}[L(a, w_a)].
\]
The latency and energy terms are differentiable because they are written as sums of block-level contributions weighted by Gumbel-softmax masks, and the coefficients \((\alpha,\beta,\gamma,\delta)\) act as application-specific “knobs” for latency-dominant, energy-dominant, or balanced search [1906.07214].

Later systems broadened the objective set. MicroNAS introduces latency and peak-memory penalties that are activated only when target constraints are violated, allowing differentiable search for time-series classification on microcontrollers under user-defined latency and memory limits [2310.18384]. HW-NAS for early exiting networks formulates a joint optimization of average accuracy and average energy-delay cost, with explicit constraints on exit overhead and final-exit ratio, thereby making quantization and exit placement part of the hardware-aware design problem rather than post hoc deployment choices [2512.04705]. For co-exploration of network and accelerator design, the optimization target can include both test accuracy and hardware utilization or throughput, again interpreted through a Pareto frontier rather than a single optimum [1907.04650].

## 2. Search spaces: from mobile CNN blocks to heterogeneous transformer layers

Search-space design in HW-NAS is not merely combinatorial bookkeeping; it is a primary mechanism for encoding what hardware efficiency can mean on a given platform. The survey distinguishes global or layer-wise spaces, cell-based spaces, and hierarchical spaces, and also separates architecture search space from hardware search space for accelerators such as FPGAs and ASICs [2101.09336]. In practice, HW-NAS systems often bias or restrict the search space toward hardware-friendly operators before search begins.

In the HANNA system, the macro-architecture is fixed at 24 layers, of which 22 are “To Be Searched” layers, and each searchable layer can instantiate one of 9 candidate MobileNetV2-inspired blocks, including an identity option. This yields a search space of \(9^{22}\) architectures, while keeping latency and energy profiling manageable because every block-layer pair can be pre-measured on the Raspberry Pi 3B [1906.07214]. HURRICANE expands the operator vocabulary substantially further: it builds a hardware-specific operator pool containing up to 32 unique operators, including SEP, MobileNetV2 bottlenecks, ShuffleNetV2 blocks, and SE variants, then selects the top-\(p\) operators for each layer based on real hardware profiling. The resulting per-device space is approximately \(4^{16} \times 5^4 \approx 2 \times 10^{13}\) architectures over 20 learnable layers [1910.11609].

Cell-based regularization becomes especially important in resource-constrained regimes. MicroNAS defines two specialized cell types—Time-Reduce Cells and Sensor-Fusion Cells—and augments them with dynamic convolutions so that channel counts themselves become searchable under MCU latency and memory constraints [2310.18384]. For ultra-low-power microcontrollers, a much more constrained family has been used: a first convolution with \(k\) kernels, followed by \(c\) repeated cells, with \(k\) and \(c\) as the only search variables and the number of kernels in later cells determined recursively. The corresponding constrained optimization includes not only RAM, flash, and MACC limits for the deployment device, but also RAM limits for the machine performing NAS itself [2606.16290]. A related embedded-device formulation imposes an explicit host-side RAM constraint \(\phi_E(x)\le \xi_E\), enabling NAS execution on devices under 512MB of RAM [2606.14824].

The search-space question has also moved beyond CNNs. LLMForge introduces Infinite-Head Attention, which decouples the number of query heads, the number of KV groups, and the per-head query/key and value dimensions. Within its stated search-space ranges, this expands the feasible per-layer attention configuration space by approximately \(400\times\) over grouped-query attention, producing hardware-conditioned transformer architectures that differ across GPUs, systolic accelerators, and ring-dataflow substrates [2605.17653]. At the tooling level, elasticAI.explorer provides a YAML-based specification that supports layer-wise, cell-based, and hierarchical search spaces through a unified interface, with dynamic translation into executable models during sampling [2605.30019].

## 3. Hardware cost estimation: measurement, lookup tables, analytical models, and learned surrogates

Hardware cost estimation is the defining technical bottleneck of HW-NAS. The survey identifies four principal strategies: real-time measurements on target hardware, lookup tables, analytical estimation, and learned prediction models [2101.09336]. The choice among them affects both fidelity and scalability, and much of the field’s methodological development can be read as an attempt to improve this trade-off.

The Raspberry Pi HANNA workflow is a canonical lookup-table system with direct measurement. Latency for each candidate block at each layer is measured on the Raspberry Pi 3B using actual execution time; energy is measured as block execution time multiplied by active current, with current acquired via a PowerJive stick at fixed 5.1V and idle current subtracted. Both latency and energy are then stored as per-block, per-layer lookup tables and summed during differentiable search [1906.07214]. On Intel Movidius VPU, two hardware-cost mechanisms were introduced: direct pre-collected device latency for operators, and VPUNN, a device-specific MLP latency model trained on empirical VPU measurements. The expected block latency during search is expressed as a probability-weighted sum over operator costs, integrating VPU latency directly into a ProxylessNAS-style objective [2305.03739].

Analytical modeling replaces repeated on-device measurement with parameterized latency formulas. HSCoNAS models total runtime as the sum of operator latencies plus a communication-overhead bias term,
\[
LAT(arch) = \sum_{l=1}^{L}\text{latency}(op^l)+\mathcal{B},
\]
with \(\mathcal{B}\) calibrated from measured architectures. The reported estimation errors are RMSE \(0.1\) ms on CPU, \(0.5\) ms on GPU, and \(1.7\) ms on Edge hardware, and the method is used to support dynamic channel scaling and progressive space shrinking during search [2103.08325]. EH-DNAS pushes this idea further by learning a differentiable end-to-end hardware performance model from measured architectures, rather than relying on linear layer-wise aggregation. For customized accelerators, its E2E-Perf benchmarking tool reports estimation error below \(2.2\%\) for pipeline paradigms and below \(8.7\%\) in the worst generic-paradigm case [2111.12299].

Recent work has concentrated specifically on surrogate-model quality. The ESM framework studies dataset generation, sampling policy, encoding choice, and training strategy for hardware-aware latency predictors on GPU-powered devices. It compares one-hot, statistical, feature-based, and proposed Feature Combination Count encodings, and reports, for ResNet on RTX4090, \(97.6\%\) accuracy with FCC encoding using \(8\)k samples and \(97.8\%\) with \(20\)k samples, versus \(83.9\%\) for lookup with bias correction. It also reports that balanced sampling reaches target convergence in \(500\) samples versus \(4000\) for random sampling, after profiling each architecture over \(150\) runs and discarding the top and bottom \(20\%\) outliers under a variance threshold below \(3\%\) [2508.01505].

These results reinforce a persistent HW-NAS lesson: hardware proxies such as FLOPs or parameter count are often insufficient. HSCoNAS explicitly states that PARAMs and FLOPs are hardware-agnostic and do not correlate well with real latency, and MicroNAS quantifies this on MCUs by comparing a latency lookup-table estimator with MAE around \(1.59\) ms against FLOPs-based proxies above \(15\) ms [2103.08325; 2310.18384].

## 4. Search algorithms and the shift from fixed-hardware NAS to co-design

HW-NAS has adopted the full range of NAS algorithms—reinforcement learning, evolutionary algorithms, gradient-based supernet methods, Bayesian optimization, and random search—but hardware awareness changes the role each method plays. The survey notes that weight-sharing supernets, early stopping, proxy datasets, and performance predictors are common acceleration mechanisms precisely because direct hardware-aware evaluation is expensive [2101.09336].

Differentiable search remains important where block-level cost is compositional. HANNA inherits FBNet-style DNAS and Gumbel-softmax relaxation to optimize accuracy, latency, and energy jointly over a stochastic supernet [1906.07214]. MicroNAS uses alternating optimization of architecture parameters and weights under latency and memory penalties, while EH-DNAS replaces linear hardware surrogates with a learned differentiable end-to-end model so that gradient-based search can target complex hardware platforms, including Edge GPUs, Edge TPUs, Mobile CPUs, and customized accelerators [2310.18384; 2111.12299].

Evolutionary search dominates in settings where objectives are highly non-linear or multi-objective. HSCoNAS combines analytical latency prediction with dynamic channel scaling, progressive space shrinking, and an evolutionary algorithm, searching a space of approximately \(9.5\times10^{33}\) architectures [2103.08325]. SONATA augments NSGA-II with tree-based surrogate models for parameter importance and an RL agent that adapts mutation and crossover probabilities; on ImageNet-1k across several search spaces and NVIDIA edge GPUs, it reports up to \(0.25\%\) improvement in accuracy, up to \(2.42\times\) gains in latency and energy, and up to approximately \(93.6\%\) Pareto dominance over native NSGA-II [2402.13204]. MO-HDNAS adds a third objective—hardware cost diversity—to the usual pair of performance proxy and hardware cost, arguing that naive two-objective search under-explores the high-cost, high-performance region. It reports a \(32\times\) lower search cost than repeated single-objective runs while producing a trade-off set in a single run across six edge devices [2404.12403].

Reinforcement learning persists primarily where architecture generation and hardware decisions are tightly coupled. Hardware/software co-exploration samples architectures with an RNN controller, uses a fast exploration stage to prune hardware-inefficient candidates without lengthy training, then performs a slow exploration stage with validation accuracy and hardware utilization rewards. On ImageNet, it reports the same accuracy with \(35.24\%\) higher throughput, \(54.05\%\) higher energy efficiency, and \(136\times\) reduced search time compared with state-of-the-art hardware-aware NAS that assumes fixed hardware [1907.04650]. This is a substantive conceptual move: the hardware design itself becomes part of the search space, rather than a fixed constraint boundary.

Several methods explicitly target scalability across diverse devices. “One Proxy Device Is Enough for Hardware-Aware Neural Architecture Search” formalizes latency monotonicity between devices,
\[
\text{if }\text{latency}(x_1; d_1)\ge \text{latency}(x_2; d_1),\ \text{then }\text{latency}(x_1; d_2)\ge \text{latency}(x_2; d_2),
\]
and argues that when Spearman’s rank correlation is strong, one proxy device can replace per-device NAS. When monotonicity is weak, a sparse adaptation model is fitted from a small number of target-device samples, reducing total latency-evaluation cost from \(O(n)\) over \(n\) devices to effectively \(O(1)\) [2111.01203]. HURRICANE addresses a related hardware-diversity problem through a two-stage one-shot search over later and earlier layers, reducing training time by \(30.4\%\) compared with SPOS [1910.11609]. HW-EvRSNAS attacks search cost even more aggressively by replacing full training with Representation Mutual Information computed from a single training batch and reports speedups up to \(8000\times\) over MnasNet, \(40\times\) over ProxylessNAS, and \(8\times\) over OFA, together with lower CO\(_2\) emissions [2311.03923].

## 5. Representative deployment regimes and empirical outcomes

The empirical literature on HW-NAS is unusually heterogeneous because “hardware-aware” means different things on Raspberry Pi boards, VPUs, mobile CPUs, FPGAs, microcontrollers, and edge accelerators for language models. Nevertheless, several benchmarked results have become reference points for the field.

On Raspberry Pi 3B, HANNA was benchmarked against MobileNetv2 and CondenseNet on CIFAR-10. HANNA reached \(87.7\%\) accuracy, \(2.88\) s latency, and \(4.79\) J energy, compared with \(92.4\%\), \(7.1\) s, and \(18.24\) J for MobileNetv2 and \(91.1\%\), \(4.83\) s, and \(9.28\) J for CondenseNet. The reported effect is about \(2.5\times\) and \(1.7\times\) speedup, and \(3.8\times\) and \(2\times\) lower energy consumption, respectively, at the cost of a \(4\)–\(5\%\) drop in accuracy [1906.07214].

On programmable hardware, co-exploration shows that relaxing the fixed-hardware assumption can materially shift the Pareto frontier. On ImageNet, the co-exploration framework reports a hardware-aware NAS baseline at \(68.40\%\) top-1 accuracy, \(6.8\) FPS, and \(0.34\) GOPS/W, while its OptSW configuration reaches \(70.24\%\), \(10.5\) FPS, and \(0.74\) GOPS/W and its OptHW configuration reaches \(68.00\%\), \(12.1\) FPS, and \(1.01\) GOPS/W [1907.04650]. HSCoNAS, evaluated on ImageNet under platform-specific latency constraints, reports models such as HSCoNet-GPU-A at \(25.1\%\) top-1 error and \(9.0\) ms GPU latency, and HSCoNet-CPU-B at \(23.5\%\) top-1 error, \(6.8\%\) top-5 error, and \(26.4\) ms CPU latency, outperforming several manually designed and NAS baselines on GPU, CPU, and edge targets [2103.08325].

For VPU deployment, NAS has been explicitly adapted to Intel Movidius. On ImageNet classification on KeemBay, the searched model achieves \(1162\) fps at \(74.1\%\) top-1 accuracy versus MobileNet-v2-1.4 at \(870\) fps with the same \(74.1\%\) accuracy, and \(684\) fps at \(77.71\%\) top-1 versus ResNet50 at \(320\) fps and \(77\%\) top-1. For super-resolution, the searched EDSR variant reaches PSNR \(32.65\) with \(6\times\) higher fps than EDSR3 at PSNR \(30.16\) [2305.03739].

Microcontroller deployment has generated a distinct branch of HW-NAS. MicroNAS targets time-series classification on Nucleo-F446RE and Nucleo-L552ZE-Q and reports MCU-tailored architectures with quantized F1-scores around \(92\)–\(95\) and memory footprints between approximately \(11\)K and \(35\)K bytes, while adhering to latency and memory constraints more effectively than DARTS [2310.18384]. For ultra-low-power vision, an affordable HW-NAS for MCUs with \(20\)–\(40\) kB RAM reports tiny models under \(30\) kB RAM, under \(54\) kB flash, and under \(1.6\) million MAC/call, with VWW accuracy up to \(77\%\), CIFAR-10 accuracy up to \(72.6\%\), melanoma accuracy up to \(91.8\%\), and search cost typically \(7\)–\(197\) minutes, median approximately \(2\) hours, on CPU-class devices [2606.16290]. A closely related method constraining both the deployment MCU and the machine running NAS reports VWW results on several embedded devices, including \(77.6\%\) accuracy, \(33.5\) KB RAM, \(32.8\) KB flash, and \(2.07\)M MACC when the search is run on Raspberry Pi 4, and \(75.1\%\) accuracy, \(25\) KB RAM, \(13.95\) KB flash, and \(0.91\)M MACC on Raspberry Pi Zero 2 W [2606.14824].

HW-NAS has also extended beyond CNN vision models. A hardware-aware framework across modalities pairs evolutionary algorithms with lightly trained objective predictors to search subnetworks from a once-for-all or one-shot super-network for image classification and machine translation under multiple objectives such as accuracy, latency, and memory [2205.10358]. LLMForge transfers the paradigm to sub-billion-parameter transformers for edge deployment: on a multi-chip ring substrate, its \(347\)M-parameter accuracy-optimized model reaches validation loss \(2.798\), its \(294\)M-parameter energy-optimized model lowers energy per token by \(40\%\), and its \(365\)M-parameter latency-optimized model reduces TTFT and TPOT by \(43\%\), all relative to matched baselines such as SmolLM2-360M and Qwen-0.5B [2605.17653]. PlatformX, targeting mobile platforms with an energy-driven search space and transferable kernel-level energy predictor, reports models with up to \(0.94\) accuracy or as little as \(0.16\) mJ per inference, both outperforming MobileNet-V2 in accuracy and efficiency [2510.08993].

## 6. Misconceptions, unresolved issues, and current directions

A recurring misconception in HW-NAS is that hardware awareness can be reduced to FLOPs or parameter count. Multiple studies explicitly reject this. HSCoNAS states that PARAMs and FLOPs are hardware-agnostic and do not correlate well with real latency; MicroNAS reports an MCU latency-estimation MAE around \(1.59\) ms for empirical lookup tables versus above \(15\) ms for FLOPs-based proxies; HURRICANE constructs per-hardware operator pools precisely because operator rankings differ across DSP, VPU, and CPU targets [2103.08325; 2310.18384; 1910.11609]. The practical consequence is that HW-NAS remains tightly coupled to profiling fidelity, whether through lookup tables, analytical calibration, or learned surrogates.

A second misconception is that “hardware-aware” necessarily means optimizing for a fixed device. The co-exploration literature shows that this is only one regime. Joint search over neural architectures and hardware configurations can produce architecture-hardware pairs that surpass the Pareto frontier available to fixed-hardware NAS, especially on programmable substrates such as FPGAs [1907.04650]. Conversely, the proxy-device literature argues that per-device search is often unnecessarily expensive because architecture latency rankings can be strongly correlated across devices and adapted with sparse target measurements [2111.01203]. These two lines point in different operational directions—co-design for customizable hardware, transfer for hardware fleets—but both challenge the fixed-device assumption.

Search cost has become a first-class concern. HW-EvRSNAS reports up to \(8000\times\) search speedups and lower CO\(_2\) emissions by replacing training-heavy evaluation with representation similarity [2311.03923]. MO-HDNAS reports a \(32\times\) reduction in search cost relative to repeated single-objective runs by obtaining a full trade-off set in one multi-objective run [2404.12403]. SONATA and ESM both treat information gathered during search as reusable structure—either for self-adaptive variation operators or for better hardware surrogates—rather than as disposable evaluation traces [2402.13204; 2508.01505]. This suggests that future HW-NAS systems may increasingly optimize not only architecture quality but also search-time energy, calibration burden, and measurement reuse.

Finally, engineering and reproducibility remain central unresolved issues. The survey highlights benchmarking difficulty, lack of standardization, transferability problems across tasks and hardware, and the concentration of the literature on image classification [2101.09336]. Recent frameworks respond by expanding end-to-end support rather than only proposing new search algorithms. elasticAI.explorer unifies YAML-based search-space definition, dynamic model instantiation, hardware-specific code generation, Docker-based cross-compilation, and hardware-in-the-loop benchmarking binaries for heterogeneous platforms [2605.30019]. Embedded-device NAS under 512MB RAM emphasizes privacy-preserving on-device search, arguing that a gateway can tailor CNN architectures to acquired data without external servers [2606.14824]. Taken together, these developments indicate that HW-NAS is evolving from a narrow NAS subtopic into a broader systems problem involving measurement infrastructure, deployment pipelines, and portability across both hardware and application modalities.

Source: https://www.emergentmind.com/topics/hardware-aware-neural-architecture-search