Supernetwork-based efficient mapping of deep learning applications to mixed-precision hardware using model adaptation

Domain: biology
Published: 2026-03-27
Editorial outcome: major_revision

Abstract
The rapid proliferation of Artificial Intelligence applications necessitates scalable solutions that perform efficiently under real-world constraints. Heterogeneous accelerators combining specialized analog and digital units offer localized, energy-efficient neural network computations. However, achieving optimal performance on these platforms requires balancing energy efficiency and model accuracy through optimized neural network layer mapping. To this end, we introduce Mixed-Precision Supernetwork, a unified framework for training mixed-precision supernetworks that seamlessly integrate quantized layers with analog noise-sensitive layers. Mixed-Precision Supernetwork incorporates a mapping-aware adaptation strategy, dynamically optimizing layer assignments while refining the neural network via hardware-aware architecture search. This dual innovation establishes Mixed-Precision Supernetwork as a groundbreaking approach for deploying deep learning models efficiently on heterogeneous accelerators. On average, Mixed-Precision Supernetwork produces mappings ∼ 2.2× faster and achieves a ∼ 3.4% increase in model accuracy over a fully analog approach, while improving energy-efficiency by mapping up to 80% of the model’s weights to analog hardware while maintaining full-precision accuracy.

Introduction
Models across different domains, including Natural Language Processing (NLP)1, Computer Vision (CV)2, and Information Retrieval (IR)3, are exploding in size and complexity. As Neural Networks (NNs) continue to evolve and expand their utility, the demand for computing solutions that are both efficient and scalable has become paramount. This has led to the advent of novel computing paradigms such as In-Memory Computing (IMC), which seamlessly integrates computation and storage within the same physical location, overcoming the traditional Von Neumann bottleneck4.

Analog In-Memory Computing (AIMC), an IMC variant performing Matrix-Vector Multiplication (MVM) with analog processing, is a promising approach for efficient NN inference tasks5,6. AIMC can substantially reduce both data movement overhead and energy consumption, together with significant enhancements in processing speed7. While these attributes make AIMC an appealing solution to the escalating computational demands of contemporary NNs, Non-Volatile Memory (NVM) devices and analog computation introduce distinct challenges due to their inherent characteristics. One notable challenge is the presence of noise associated with analog processing, stemming from factors such as device- and circuit-imperfections4. Effectively managing and mitigating this noise represents a critical facet in the development of robust and dependable AIMC accelerators tailored for NNs8–10. For example, the impact of noise can vary across different layers of NNs, influenced by their varying levels of sensitivity11. Designing noise-resilient AIMC architectures has been a focal point in many previous and ongoing works12.

To address these challenges while maintaining energy efficiency, mixed-precision platforms – which combine the advantages of both analog and digital computing13,14 – have emerged as a compelling solution. Such systems leverage the strengths of analog components for superior energy efficiency and reduced latency, while utilizing digital components for deterministic and higher precision computations15. For example, sensitive layers of NNs can be strategically mapped to digital components, sacrificing some speed and energy efficiency to secure higher model accuracy, a process commonly known as mapping. Such platforms can strike an optimal balance between precision and energy efficiency, facilitating the deployment of NNs with improved performance while satisfying resource and precision constraints. Fig. 1(a) shows how an optimized mapping of a transformer encoder to a heterogeneous mixed-signal accelerator can help maximize resource utilization. An AIMC core, as shown in Fig. 1(b), is a critical component in this architecture, performing analog vector-matrix multiplication directly within a memory array at high speed with high energy efficiency.

Despite their remarkable capabilities, NNs are not universally efficient on all computing platforms, and different NN architectures exhibit varying levels of efficiency when deployed on different hardware. Therefore, it is critical to optimize the mapping of NNs onto heterogeneous accelerators, to ensure that the computational resources are utilized efficiently, with minimal latency and maximal resource utilization. Fig. 1(c) shows that when a model is naively mapped to Full Analog, model accuracy is degraded as compared Full digital more accurate implementation. Ideally, there should be some method for choosing how to assign heterogeneous hardware resources in a way that can optimize model accuracy and resource utilization.

Traditionally, the mapping of NNs onto heterogeneous hardware platforms has relied on heuristic and rule-based strategies. For example, DIANA16 assigns the first and last layers to digital components while placing the remaining layers on analog hardware. These approaches often employ static allocation schemes, which fail to adapt to the varying sensitivity and performance needs of individual layers, leading to suboptimal resource utilization. Recent methods, such as channel-wise mapping17,18, attempt to improve workload distribution by splitting convolutional layers across hardware resources. However, these strategies introduce significant communication overhead, expand the search space, and are limited to convolutional and linear layers, and cannot be readily applied to attention mechanisms or more complex architectural blocks such as those found in Transformers. Advanced techniques such as LionHEART19 incorporate layer-wise mapping with iterative retraining to enhance adaptability, but their high computational cost and time overhead make them impractical for large-scale NNs. Overall, these heuristic methods remain suboptimal, time-intensive, and poorly suited to the complex demands of modern NNs.

In this paper, we propose Mixed-Precision Supernetwork (MPS) – a principled framework designed to overcome these limitations by efficiently optimizing layer mapping in mixed-precision (MP) environments. At the core of our approach is the definition of a novel mixed-precision supernetwork, inspired by neural architecture search (NAS) supernetworks20. Such a supernetwork incorporates both analog and digital layers, allowing for comprehensive exploration of mixed-precision configurations across the network. Unlike traditional NAS approaches, which primarily focus on selecting optimal subarchitectures, our supernetwork introduces additional complexity due to the inclusion of noisy and quantized layers. These layers significantly increase the training difficulty, since they require careful handling of noise, precision loss, and sensitivity across different layers.

To address these challenges, we propose a specialized training mechanism tailored to the unique demands of the mixed-precision supernetwork. This mechanism enables efficient ranking and evaluation of subnetworks by leveraging a multi-objective loss function that optimizes for accuracy, low-energy resource utilization and model-parameter size simultaneously. By overcoming the complexities associated with noisy and quantized layers, our approach facilitates the design and deployment of high-performance mappings that achieve superior accuracy and resource utilization compared to existing methods. Moreover, given the efficiency of our training mechanism, we can further enhance the performance of the mixed-precision supernetwork by incorporating hardware-aware adapted layers. These hardware-aware layers are specifically designed to introduce additional configurations without increasing energy consumption or latency. For example, when mapping a convolutional layer to an analog tile, the entire tile’s resources can be utilized more efficiently by increasing the number of output channels. This approach maximizes the use of available computational capacity within the analog tile, enabling improved accuracy with minimal additional energy cost and no latency overhead. By strategically integrating such adapted layers into the supernetwork, our framework enhances flexibility and accuracy while adhering to strict hardware constraints.

The development of our new MPS framework sets a new benchmark in our ability to systematically identify and address the sensitivity of individual neural network layers, including those in large language model encoders, when mapped onto heterogeneous mixed-precision accelerators. MPS not only enhances model accuracy and resource utilization but also establishes a scalable and practical solution to the challenges of modern AI hardware design.

Results
A. Framework Overview

The proposed MPS framework, illustrated in Fig. 2, begins with the generation of a mixed-precision supernetwork that encapsulates all possible precision choices for each layer. Designed to accommodate any type of network, this framework enables the simultaneous exploration of multiple configurations within a unified structure. By doing so, it eliminates the need for exhaustive evaluations of individual subnetworks, significantly reducing mapping time. To further enhance the utility of the supernetwork, the framework introduces optional hardware-aware adaptations, the supernetwork is then termed Mixed-Precision Architecture Adaptation Supernetwork (MPAAS). These adaptations allow better utilization of the underlying hardware resources without minimal additional energy consumption and no additional latency. The primary adaptation strategies employed in MPAAS – Self-Attention Block Adaptation, Weight-Layer Resizing, and Convolutional Block Adaptation – were pivotal in achieving these results.

Self-Attention Block Adaptation — In Transformer-based architectures, the self-attention block is vital for weighting input elements to enhance the model’s ability to focus on relevant features. Adaptation in these blocks involves increasing the intermediate size – affecting the inner-layers of neurons that process attention scores and context vectors. Expanding the length of these intermediate vectors allows for the full utilization of computational tiles without altering the block’s final output size, thereby improving hardware efficiency and parallel processing capability.

Weight-Layer Resizing — In addition to self-attention block adaptation, the fully-connected layers in Transformer encoder blocks are optimized to better align with the capabilities of mixed-precision hardware. This adaptation strategy focuses on resizing the number of neurons in the intermediate fully-connected layers, thereby maximizing the use of available computational tiles in analog or mixed-signal components. Specifically, the intermediate layer size is increased to fully occupy the available tiles, which enhances parallel computation and minimizes underutilized hardware resources. Despite this adjustment in intermediate dimensionality, the overall architecture preserves the original output size, ensuring that the model maintains its predictive performance and remains compatible with pre-existing model structures.

Convolutional Block Adaptation — In convolutional neural networks, adaptation focuses on adjusting the number of input and output channels within convolutional layers. This strategy is crucial for aligning with the computational capabilities of mixed-precision hardware, ensuring optimal utilization of available analog and digital tiles. Modifying the number of channels enhances the balance between computational load and memory access, leading to increased energy efficiency and reduced latency. While most adaptations target analog-mapped layers to improve tile utilization and robustness, they are also applied in some digital INT8 layers to compensate for reduced precision and to align with vectorized digital hardware (e.g., SIMD units), ensuring efficient execution without added latency. At least one of these adaptation approaches was selected by the optimizer for deployment in 78% of cases, highlighting its practical effectiveness across diverse scenarios. Note that these approaches call for the use of more tile-rows, there are minor but perceptible energy-costs associated with delivering and driving additional excitation-data onto previously-unused rows21. However, the increase in energy is quite low, and the time needed for analog computation remains unchanged.

Once this supernetwork is constructed, the training phase begins. Training the supernetwork focuses on optimizing a ranking mechanism that evaluates and prioritizes configurations based on multi-objective criteria. This ensures that the framework identifies the best-performing mappings while respecting hardware constraints. The final step involves extracting an optimized mapping, resulting in a deployment that balances precision, accuracy, and resource utilization. Although the supernetwork’s accuracy approximation suffices for effective ranking and search, the final extracted mapping and network undergo retraining to achieve optimal performance.

B. Optimal Mapping Results

The results of our full MPAAS framework, and the base MPS framework (without supernetwork adaptations, e.g., without Step 2 of Fig. 2), demonstrate substantial improvements over baseline methods, as presented in Table I. This table captures critical performance metrics: Task-Specific Performance, Analog MAC Ratio, and Weight Memory — the three primary optimization objectives of our framework. We evaluate 3 relevant benchmarks for edge computing, namely image classification on CIFAR-10, object segmentation on COICO, and question answering on SQuaDV1. An extended set of results for multiple networks on those 3 benchmarks can be found in Supplementary Tables I, II and III. For every mapping scenario, we compare it against its full digital and full analog counterparts, alongside mapping state-of-the-art methodologies. The full analog mapping consistently demonstrates the lowest task-specific performance due to the impact of noise and reduced precision inherent to analog computation.

Task-Specific Performance evaluates the network’s effectiveness on its designated task, such as accuracy for image classification, mIoU (mean Intersection over Union) for object segmentation, or F1 score (harmonic mean of precision and recall) for question answering. Our MPAAS framework achieved significant gains, demonstrating up to a ∼ 3.4% increase in task-specific performance over baseline methods. For example, on CIFAR-10, MPAAS showed a substantial improvement, while MPS also delivered competitive results, albeit slightly lower for models like ResNet20, indicating areas where further architectural tuning could enhance performance. In the case of ResNet20, MPAAS exhibits an increase in total parameters (from 0.26M to 0.86M) due to hardware-aware layer adaptations. These include resizing fully-connected or convolutional layers to align with analog tile constraints, thereby improving analog utilization. Importantly, these changes do not alter the model’s output dimensions and are designed to maintain compatibility with original task specifications. In transformer-based models, our strategic mapping was particularly impactful. Noise-sensitive layers, such as the first and last linear layers, were consistently mapped to digital components, while the more robust intermediate layers were assigned to analog units. This decision preserved task-specific performance, as in the case of Bert-base, where larger blocks were mapped to analog except for the final encoder, which required higher precision. In some cases, MPAAS achieves slightly higher accuracy than the full digital FP32 baseline. This is not due to increased training time, as all models were trained under the same epoch budget with early stopping. Instead, the accuracy gain is attributed to hardware-aware adaptations that expand layer widths to better utilize analog tile dimensions, thereby increasing model capacity while maintaining efficiency constraints.

Analog MAC Ratio represents the proportion of Multiply-Accumulate (MAC) operations executed in analog, contributing to the overall energy efficiency. A higher ratio signifies better utilization of energy-efficient analog computations. Both MPAAS and MPS consistently achieved high Analog MAC Ratios, especially in convolutional architectures, demonstrating the effectiveness of our mixed-precision mapping strategy, even compared to ODiMO18 which performs a channel-wise convolution mapping. This is due to the large channel-wise search space in ODiMO, which increases complexity and often leads to suboptimal utilization of analog resources. Supplementary Figure 4 shows the motivation behind our layer-wise approach. Notably, our frameworks maximize the use of analog computation without sacrificing task-specific performance.

Digital Weight Size measures the digital memory footprint imposed by the network’s weights, crucial for deploying models on memory-constrained hardware. By strategically minimizing the reliance on high-precision digital computations, our frameworks demonstrated efficient use of digital weight-memory. MPAAS reduced the digital memory footprint to 9.8 MB on ResNet18 for COCO, in Supplementary Table III, compared to ODiMO’s18 14.6 MB. Similarly, on MobileBert for SQuaD v1, MPAAS managed to maintain a competitive F1 score of 92.1% while optimizing memory usage efficiently.

C. Search Time and Multi-objective Efficiency

Our MPS framework evaluates the architectural configurations that it generates using various metrics that are independent of specific model architectures or hardware platforms. Fig. 3 illustrates the comparison of search time, and portion of hypervolume covered, across various models. The search time refers to the total end-to-end time required to arrive at the optimal mapping. The hypervolume represents the region in the objective space, i.e., task-specific performance, Analog MAC ratio and Digital weight size, that is dominated by the Pareto front discovered by the framework, serving as a comprehensive indicator of its optimization capability.

In terms of search time, MPAAS and MPS consistently outperformed ODiMO18, showcasing superior efficiency in the search process. Heuristic-based methods, such as LionHeart19 become impractical when the model size increases, exceeding 16 hours to complete ResNet-50, VIT-Adapter and BERT-base. This increased efficiency can be attributed to the unified training and search approach of our framework, which streamlines mapping optimization. This advantage is particularly pronounced in models such as MobileNetV2-10 and Bert-base, where MPAAS and MPS achieved significantly shorter search times because the extensive channel-wise search space presents significant challenges for gradient-based methods like ODiMO.

In terms of the portion of hypervolume covered, due to the breadth and effectiveness of the Pareto front approximations, MPAAS consistently secured the highest scores. Normalization against the MPAAS hypervolume further highlighted the comparative lag of other methodologies. MPS also demonstrate robust performance, closely following MPAAS, particularly in more complex models such as ResNet50 and Bert-base.

Moreover, the experiment illustrated in Supplementary Fig. 3 studies the Pareto front obtained by MPAAS under a resource constrained platform. Here, we specify the number of analog components, commonly termed as tiles, and observe our adaptation mechanism which searches for network modification that will enhance the utilization of the full hardware platform. Each subfigure highlight show the Analog MAC Ratio and memory requirements evolve with varying 1-day accuracy (or F1 score) across the three architectures: ResNet20 (CIFAR-10), Adapter-VIT (COCO), and MobileBert (SQuADv1). The comparison between MPS, MPAAS without tile limits, and MPAAS with a tile limit of 20 demonstrates the adaptability of MPAAS in optimizing network performance under resource constraints. Notably, MPAAS configurations maintain high Analog MAC Ratios, indicating efficient utilization of analog computation, even when limited tile resources are available. For example, in the ResNet20 experiment, MPAAS with a tile limit of 20 still achieves competitive accuracy while efficiently balancing memory and analog resource utilization. Similarly, in the Adapter-VIT and MobileBert cases, the full MPAAS configuration achieves superior task-specific performance without significant memory overhead. These results emphasize the robustness of MPAAS in adapting to hardware limitations while maximizing energy-efficient computation and overall model performance.

D. Ablation Study

Supplementary Table IV presents a detailed ablation study that evaluates the impact of various adaptation strategies on three diverse architectures: ResNet20 for CIFAR-10 (image classification), ResNet50 for COCO (object segmentation), and MobileBert for SQuADv1 (question answering). The table compares six configurations. (1) MPS, The baseline configuration, which uses static quantization without additional adaptations. No specific training is used, the validation is using the quantized and noisy FP weights directly. (2) MPS-QAT, extends MPS by employing quantization-aware training (QAT), where the effects of reduced precision are simulated during training to minimize quantization error on the quantized layers only. (3) MPS-QAT-HWA, Builds upon MPS-QAT by incorporating hardware-aware training, introducing noise modeling to simulate imperfections for the analog layers. (4) MPS-NSHWA, includes skip connections to reduce model size. (5) MPS-QAT-NSHWA, Integrates QAT, network sparsity, and hardware-aware training for a more comprehensive adaptation strategy. (6) MPAAS, The full configuration that employs all three strategies—quantization-aware training, skiping layers, and hardware-aware adaptations—to achieve maximum performance.

These configurations were evaluated based on task-specific metrics: classification accuracy for CIFAR-10 (ResNet20), mean Intersection-over-Union (mIoU) for COCO segmentation (ResNet50), and F1-score for SQuADv1 (MobileBert), highlighting the incremental benefits of each added strategy.

For example, as shown in the table, the addition of QAT (MPS-QAT) improves performance across all models compared to the baseline MPS. Specifically, ResNet20 achieves an accuracy of 84.5% compared to 81.9% for MPS. Introducing hardware-aware training (MPS-QAT-HWA) further enhances accuracy to 87.3%, while incorporating network sparsity (MPS-NSHWA) increases it to 88.7%. The most significant gains are observed with MPS-QAT-NSHWA, which achieves 90.8% for ResNet20, 56.4% mIoU for ResNet50, and 89.3% F1-score for MobileBert. These results illustrate the synergistic benefits of combining QAT, hardware-aware training, and network sparsity.

Finally, the full MPAAS configuration demonstrates the highest performance across all models, achieving 92.4% accuracy on ResNet20, 58.7% mIoU on ResNet50, and 91.6% F1-score on MobileBert. These adaptations induce an increase in the total number of parameters. For example, in ResNet20, the fully connected layer width is increased in some blocks to match analog tile sizes (e.g., 256 rows), which lead to the increase from 0.26M to 0.86M parameters. This leads to a minor increase in the total number of tiles and a better tile utilization. This underscores the importance of a comprehensive optimization strategy that integrates all three techniques to maximize performance across diverse architectures and tasks. The results validate the ability of MPAAS to address the unique challenges of mixed-precision computation while delivering superior task-specific performance.

Methods
A. Comparison Setup

We validate our framework through extensive experiments on benchmark tasks, including CIFAR-10, COCO, and SQuADv1, comparing it against State-of-the-Art (SOTA) baselines such as ODiMO, LionHEART, and Harmonica. The optimal models for our framework and LionHEART are selected using the elbow method on the Pareto front, while Harmonica is evaluated with a layer-wise split. DIANA is excluded due to its suboptimal performance relative to these methods18,19. Our tests involve diverse models from MLPerf edge use cases22 across CIFAR-10 (ResNet8, ResNet20, MobileNetV2), COCO (ResNet18, ResNet50, Adapter-VIT), and SQuADv1 (MobileBert, Bert) to demonstrate the framework’s versatility. Simulated mixed-precision hardware supporting FP16, INT8, and analog precision is used. Specifically, FP16 operations are handled using PyTorch’s Automatic Mixed Precision (AMP) to ensure numerical stability during training, while inputs and models are cast to FP16 during inference for computational efficiency. AIHWKit23 models analog noise, and PyTorch dynamic quantization handles INT8 layers. Each final architecture is retrained with hyperparameter optimization via Optuna24, with detailed training parameters in Supplementary Table V. Supplementary material include hardware simulation configurations in Table V and random search comparisons, in Fig. 5, with all results obtained using an 8 V100 GPU cluster. Conforming to optimization best practices, we benchmark our methodology against random search, as shown in Supplementary Fig. 5. The results highlight the complexity of the mapping problem and underscore the critical need for an efficient and systematic approach to achieve optimal performance. For each model, we perform a single supernetwork search to construct a Pareto front that jointly optimizes task performance, analog utilization, and digital memory. A selected point from this front is extracted based on the elbow method and retrained five times to report task-specific performance variability (mean ± std). The digital weight size and parameter count remain fixed for the selected architecture and are reported without uncertainty.

To maintain generality, we do not model hardware-specific dataflow constraints, such as spatial or temporal tiling, nor assume a fixed architecture type (e.g., SIMD or systolic). Our framework is intentionally hardware-agnostic and abstracts the hardware platform as one that supports analog, INT8, and FP16 computations. The reported “Number of Analog Tiles” corresponds to the cumulative number of analog compute units needed to support the selected analog-mapped layers under a layer-wise spatial allocation model. These values may vary across mapping strategies depending on how many layers are mapped to analog. We assume sufficient hardware availability for the mapped configuration, and leave detailed hardware scheduling or temporal reuse modeling to future work.

B. Hardware Simulation and Latency–Energy Modeling

To complement the hardware-agnostic optimization metrics presented earlier, we evaluated the latency and energy characteristics of the resulting architectures using the open-source 3DCiM-LLM-Inference Simulator25. The simulator models realistic in-memory compute arrays and peripheral subsystems derived from the HERMES architecture15.

For all simulations, a single-tier heterogeneous system was assumed, consisting of up to 64 analog tiles of 512×512 dimension. Each tile performed analog matrix–vector multiplications at 0.65 ns per MAC with an average energy cost of 0.35 pJ per MAC, consistent with HERMES measurements. Digital tiles operated at 1.6 ns/MAC and 1.4 pJ/MAC. Peripheral energy (ADC/DAC, data movement, and control) was included following the simulator defaults.

Each network’s analog/digital partition was imported directly from the mappings discovered by the respective methods. The simulator provided end-to-end inference latency (batch=1) and total energy per sample. The results are summarized in Table I.

C. Mixed-Precision Supernetwork Design

The training of mixed-precision supernetworks (MPS) involves distinct phases that cater to the nuances of working with multiple precision levels within a single network architecture. This approach is particularly designed to manage the inherent challenges of quantization errors and the variability introduced by analog computations. Algorithm 1 outlines the steps in this training methodology, which can be broken down into three main phases:

a. Quantized Layers Quantized layers in the supernetwork are designed to operate at various precision levels. The quantization function, denoted as Q(x,p), is applied to adjust the layer’s weights according to the desired precision level p (e.g., 8-bit, 16-bit). For the i-th quantized layer, the adjusted weight matrix is represented as W p,i ∈ d × m. The output of this layer, denoted as a p,i ∈ m, is calculated through the forward propagation process described by the equation a p,i+1 = φ(Q(W p,i ,p) · a p,i ), where φ represents the activation function. In this formulation, the bias is not considered for simplification.

b. Analog Layers Analog layers introduce computational noise, mimicking the characteristics of analog hardware. In these layers, digital-to-analog conversion (DAC) and analog-to-digital conversion (ADC) processes are integral. The DAC function, denoted as f DAC(x), converts the digital input x into an analog signal. Conversely, the ADC function, denoted as f ADC(x), converts the analog output back to a digital form. The noise function N(µ,σ2) introduces Gaussian-distributed noise to the analog output. For the i-th analog layer, the weights and activations are denoted as W analog,i ∈ d × m and a analog,i ∈ m, respectively. The forward propagation in this layer, incorporating both DAC and ADC processes, is expressed as a analog,i+1 = f ADC(φ(W analog,i · f DAC(a analog,i ) + N(µ,σ2))). Here, the noise is added to the analog product of the weights and activations, and the final output is converted back to a digital form.

c. Supernetwork Forward Propagation The general forward equation for the supernetwork, integrating both quantized and analog layers, is formulated as follows. Let a 0 be the input to the supernetwork. For each layer i, the supernetwork contains a set of possible operations O, which includes high precision, quantized and analog operations. The output of each layer i is a weighted sum of all possible operations in O, computed as follows:

a i+1 = ∑ o∈Oi α o,i · o(a i),

where α o,i are the learnable weights associated with each operation o in layer i, indicating the importance or contribution of that operation in the current architecture. o(a i) represents the output of applying operation o to the input a i. Each operation o could be a digital (quantized) operation, an analog operation, or any other type of operation included in the supernetwork. a i+1 is the output of layer i, which serves as the input to the next layer. Beyond the available options for precision levels, the supernetwork incorporates pass-through layers, which facilitate the complete pruning of a layer.

D. Mixed-Precision Supernetwork Training

The training of the MPS addresses the unique challenges posed by mixed-precision computations, specifically the quantization error induced in quantized layers and the noisy analog computations. Our training methodology is structured into distinct phases, each with specific objectives. Algorithm 1 presents the comprehensive steps involved in training MPS. It consists of three main phases:

a. Fairness Training In the first phase, selection parameters α o,i are initialized to ensure an unbiased beginning, each set to 1 / |O|, where |O| is the size of the vector O representing the number of candidate operations (e.g., analog, INT8, FP16, or skip) for layer i. This phase, dedicated to training the shared weights, emphasizes equitable resource distribution via strict fairness sampling26. The weights are initialized using the given pre-trained network, and quantization-aware training is applied at the highest precision level (e.g., FP16). Adapted layers (e.g., with resized dimensions) are initialized via weight replication.

To sample among the candidate operations for each layer during training, we employ a Gumbel-Softmax relaxation. This technique enables differentiable sampling from a categorical distribution, allowing gradient-based updates to the α parameters while approximating hard architectural choices. The temperature of the Gumbel-Softmax distribution is annealed throughout training to encourage increasingly discrete selections as optimization progresses.

Although all operators are set to FP16 in this phase and no precision sampling occurs, this step serves to warm-start the network weights under stable numerical conditions. It ensures that the shared parameters converge before branching, and allows us to initialize lower-precision paths via weight replication in later phases, supporting more stable training under quantization and noise.

b. Progressive Noise Scaling and Quantization-Aware Training In its second phase, the algorithm adapts to the varying precision levels of different network layers. Quantization-aware training27 is applied to quantized layers for reduced-precision levels such as INT8. For analog precision layers, the algorithm assesses noise resilience by contrasting the task loss incurred when operating in high-precision (FP16) versus analog-mode simulation. This is done by isolating each precision level—turning off all others except the highest and analog precision—and computing the relative increase in loss. If a given layer exhibits minimal degradation (i.e., the increase is below a defined threshold), it is deemed resilient to analog noise.

For such layers, we progressively increase the injected analog noise during training, in increments of 0.1 applied to the standard deviation of the Gaussian noise model in AIHWKit. This strategy gradually exposes the network to realistic analog noise conditions, which helps improve robustness without destabilizing early training. Importantly, this progressive scaling mechanism also facilitates convergence of the supernetwork by allowing sensitive layers to train under more stable conditions initially, while enabling noise-resilient layers to regularize more aggressively over time. The 0.1 step size is empirically chosen as a balance between training stability and robustness, and does not correspond to a fixed hardware-level quantity.

c. Rank-Preserving Fine-Tuning This phase is critical for enhancing the overall performance and robustness of the supernetwork. It involves training the selection parameters by sampling a diverse set of sub-networks and computing their Pareto ranks to understand their efficiency and efficacy. The algorithm calculates a specialized loss function, Loss PR, which is based on the discrepancies between the performance scores of the subnetworks and their Pareto ranks28,29. The primary goal of this phase is not only to fine-tune the network by updating the fairness parameters α using gradients derived from Loss PR, but also to significantly increase the hypervolume of the solution space.

Hypervolume measures the multi-dimensional space covered by the set of solutions on the Pareto front, where each solution represents a trade-off between objectives such as accuracy and energy efficiency. Maximizing hypervolume ensures that the Pareto front encompasses a broad range of optimal solutions, improving the diversity and quality of trade-offs. This is achieved by independently training a substantial number of architectures, as dictated by the nb sample networks hyperparameter (ranging from 50 to 100, Extended DataTable V). This extensive training approach ensures that the supernetwork is optimized across a wide range of possible configurations, leading to a more robust and versatile model.

To address the balance between energy efficiency and accuracy, the framework uses the reference point to prioritize configurations that maximize analog computation for energy savings while maintaining sufficient accuracy in critical layers. For instance, a first layer that is highly susceptible to noise will be driven towards a digital implementation to preserve accuracy. In contrast, an intermediate layer with inherent high noise tolerance can be mapped to analog resources to leverage energy efficiency. The training process dynamically adjusts these mappings based on the observed impact of noise and quantization on performance, ensuring that layers are allocated in a way that optimizes the overall trade-off between energy efficiency and model accuracy.

The culmination of this training process is the extraction of the final mapping parameters for each layer, achieved by applying a softmax to each layer’s selection parameters.

Peer review rounds
[{"round": 1, "reviewer_comments": {"reviewer_1": "The paper describes a SuperNet-based method to efficiently map Deep Neural Network layers onto multi-accelerator systems, in particular equipped with both digital and AIMC accelerators. The proposed approach has several interesting elements, such as the modelling of AIMC noise and the hardware-aware adaptation of DNN layers' shapes based on each accelerator's parallelism. The experiments performed are extensive and detailed, and the results achieved quite promising. However, there are several aspects of the manuscript's presentation that require improvement. Mainly, the paper lacks details on several aspects of the methodology as well as on the hardware target on which results are evaluated. While it is understood that the journal's characters limits do not allow for too many details, at least these key aspects should be clarified more in detail.\n\nMajor Comments:\n1. The code uploaded with the submission is incomplete and insufficient to understand the methodology in detail, and even less to reproduce it. For instance, it imports from the `mps_resnet` module, which has not been shared. Moreover, the function `train_phase` seems to contain only two of the 3 phases mentioned in the manuscript (phases 1 and 2). If the authors cannot/do not want to share the full code, the journal should allow it, but at that point it is probably better not to share any code at all, than an incomplete version.\n2. The hardware target is not described in detail, and the authors only point to a previous paper (23) for the modelling of analog noise. No information is given on:\n- The actual spatial parallelism of AIMC and Digital accelerators used in the experiments.\n- Their dataflow constraints, if any.\n- The type of architecture (e.g. systolic/SIMD) of the digital accelerators, and that of the AIMC ones.\n- etc.\nLinked to this point, the results of Table I include a \"Number of Tiles\" column, which according to the text seems to refer to spatial tiles, i.e., copies of the same accelerator. Why is this value different for all compared methods? Is it assumed that a number of accelerators sufficient to run the entire layer in parallel is always allocated? This ignores the possibility of tiling the layer TEMPORALLY. Why so?\n3. The entire method is aimed at improving energy efficiency but no information is given on the considered energy model. For example, is it assumed that when a certain accelerator is not active, its consumption is 0? This is a strong assumption, and may bias the results, since some of the baselines, like ODiMO, enable parallel usage of multiple accelerators (for the same layer) which maximizes utilization and reduces dark silicon consumption. Also, no comment on the impact of the proposed method vs the baselines in terms of latency is provided.\n4. Some aspects of the methodology are quite unclear.\n- The procedure called \"Progressive Noise Scaling\" (lines 10:12 of Algorithm 1) is not clearly explained. It is hard to grasp why if a certain layer is resilient to noise, then its noise scale is increased. What is the rationale? And why are the increases in steps of 0.1? Does this value have a specific meaning?\n- The authors mention setting the alpha parameters to 1/|O| during fairness training. However, it is not clear what is the sampling method (e.g., Gumbel Softmax, Argmax, etc) used in the following phases.\n5. As partially already mentioned, Table I includes several columns that are not discussed in the text. Besides the \"Number of Tiles\", the others are \"Parameters\" and \"Digital Weight Size\". Namely,\n- The former may refer to the fact that the proposed approach sometimes increases the layer size, through what the authors call hardware-aware adaptation. However, the increase seems extreme in the ResNet20 case (from 0.26M to 0.86M). This point should be discussed.\n- The latter refers to the total bits occupied by digital weights, but it's not clear why the values in this column do not have an uncertainty interval. If the Analog Utilization changes, how can the Digital Weight Size remain fixed?\n- More in general, are the results in Table I obtained from a single Pareto front (in which each point has an uncertainty interval) or is each run extracted from a separate Pareto front?\n6. Also, in Table I, the authors sometimes report accuracies higher than those of a \"full digital\" approach using their proposed mapping. While this can sometimes happen due to noise, I wonder if it could be due to a higher training budget for the proposed approach. In other words, are all baselines allowed to train for the same number of epochs? (maximum, except early-stopping)\n7. A similar question on the comparison fairness concerns the hyper-parameters used for baselines ODiMO and LionHEART. Line 262 mentions that the proposed approach's hyper-parameters are optimized with Optuna. Has the same procedure been applied also to the baselines, or have the default hyper-parameters been used from the original papers?\n8. Extended data Fig. 3 mentions \"1-day accuracy\" as a metric, probably hinting to the fact that AIMC accuracy tends to drift over time. However, it is not clear if this aspect has been modelled and how the accuracy of the proposed mapping could evolve over time.\n\nMinor Comments:\n9. In the abstract, the last sentence mentions \"assigning 80% of those weights\" but it is not clear what weights are being referred to.\n10. Line 57 mentions that ODiMO is only applicable to convolutional layers. This is not completely correct, as it can also be applied to linear layers (e.g., within Transformers), although not to attention layers.\n11. \"Odimo\" and \"ODiMo\" should be \"ODiMO\".\n12. The ODiMO method has recently been extended in this paper: https://doi.org/10.1109/TCAD.2025.3543715, probably not cited in the manuscript beacuse it was not available at the time of submission. The authors are suggested to replace their reference with this new one.\n13. Figure 1 (c): the meaning of colors is not clear (e.g., two Conv layers are yellow, what changes with respect to the blue ones)? Add a legend.\n14. Line 111 there's a typo: \"A least one\" --> \"At least one\".\n15. In lines 193-194, it is imprecise to associate metrics to models, instead of tasks/datasets.\n16. Wrong hyperlinks: Extended Data Table I (line 127), Extended Figure 3 (line 169)\n17. In Extended Data Fig. 1, skip connections are marked as red arrows. However, from Fig. 2, it seems that skip connections are one of the branches of the SuperNet. So why aren't they associated with a probability bar like the other three branches? Also, the x axis has no label.\n18. In Extended Data Fig. 4:\n- What is ODiMO-HWA exactly and how does it differ from ODiMO-QAT?\n- Is the y axis of panel (b) \"energy\" or \"energy efficiency\"? If it is Energy, it seems that ODiMO outperforms the proposed method.\n19. In Extended Data Fig. 5, RS stands for Random Search, but what is \"RS-WS\"?\n20. In Extended Data Table I, MobileNetV2 overlaps with other text.\n21. In Extended Data Fig. 3, the x-axis labels are wrong (they show F1 score for COCO and Accuracy for SQuAD, instead of mIoU and F1 respectively).\n22. In Extended Data Table IV, HWA is expanded as \"hardware acceleration\" instead of \"hardware-aware training\" as in the rest of the paper.\n\n(Remarks on code availability)\nAs mentioned in the Comments to the Author, the code is insufficient to understand and/or reproduce the methodology. I suggest sharing a more complete version fo the code, if possible.", "reviewer_2": "I co-reviewed this manuscript with one of the reviewers who provided the listed reports. This is part of the Nature Communications initiative to facilitate training in peer review and to provide appropriate recognition for Early Career Researchers who co-review manuscripts.", "reviewer_3": "The manuscript is inspired by Neural Architecture Search (NAS) and introduces a neural network deployment framework specifically designed for digital-analog architecture chips. The framework is shown to achieve superior task performance compared to purely digital or purely analog approaches on benchmarks such as CIFAR-10 and COCO. Additionally, the proposed method significantly enhances the tile utilization of the analog component while reducing the computational and storage requirements of the digital part. In the current landscape, where digital-analog architecture chips are emerging as a promising technology, the method offers an interesting perspective on balancing heterogeneous computing resources.\n\nHowever, several issues and limitations remain:\n1. Insufficient Details on Architectural Setup: Although the research is motivated by digital-analog computing architectures, the paper does not provide a detailed description of the chip architecture. Essential information regarding the digital and analog components, such as computing power, bandwidth, and other configuration parameters, is missing.\n2. Evaluation Metrics and Their Interpretability: The paper employs three evaluation metrics: Task-Specific Performance, Analog MAC Ratio, and Digital Weight Size. While Task-Specific Performance directly reflects the benefits of the deployment scheme, the latter two metrics are not intuitive. The assumption that a higher Analog MAC Ratio and a lower Digital Weight Size are inherently better might not hold in all scenarios. For example, in image processing (without considering weight replication), analog computation can only reduce the computational complexity from O(NK) to O(N), where N represents the number of pixels and K denotes the total convolution kernel size. Since N and K vary across different network layers—and given that in AIMC the network weights are physically bound to the device—the digital cores might actually be more advantageous for layers with lower memory access demands (typically when N is significantly larger than K). Therefore, simply offloading computation to the analog cores may not fully leverage the potential of a digital-analog architecture. The authors should consider incorporating additional metrics (e.g., computational latency, energy efficiency, and chip area requirements) to demonstrate the benefits of the proposed framework more directly.\n3. Increased Network Size and Potential Hardware Overhead: In Extended Tables I, II, and III, the results obtained by the proposed MPAAS approach even surpass those of the pure digital deployment scheme. However, it is noteworthy that the networks generated by MPAAS are consistently larger than the original networks. The paper does not adequately discuss whether the increased network size incurs additional hardware overhead. For instance, Extended Table I shows that the MPAAS-derived ResNet8 (CIFAR-10) network is 2.7 times larger than the original, a factor that could have significant implications for hardware cost and efficiency.\n4. Unclear Description of the Adaptation Process: The manuscript’s explanation of the adaptation mechanism is vague and lacks concrete details regarding the hardware parameters and corresponding algorithmic modifications. For example, Figure 2 (2) indicates that adaptation is also applied for computations on digital cores operating in INT8 format, yet the rationale behind this adaptation remains unexplained. A more detailed discussion is necessary to clarify the underlying motivations and implementation details.\n5. Inconsistent Section Titles in the Methodology: In the Method section, sections B and C share identical titles, which leads to confusion.\n6. Ambiguity in the Training Process Description: The Method section outlines a three-phase training process, with the second phase introducing quantization and noise constraints. The manuscript states that training in the first phase begins with FP16, raising the question: Are the candidate operators for each layer identical during this phase? If so, this phase may not contribute meaningful differentiation.\n7. Discrepancy in Propagation Paths: In Figure 2 (3), the diagram shows an inconsistency between the backpropagation update paths and the forward propagation paths. Specifically, the illustration suggests that a fair selection process involves all candidate operators, which appears to contradict the intended design. The authors should either provide an explanation for this discrepancy or revise the figure for clarity.\n\n(Remarks on code availability)\nThe code provided by the authors is missing a README file that outlines usage instructions and lacks an environment configuration file."}, "author_response": "Response to Reviewers for Manuscript ID: NCOMMS-24-28357A\nChanges to the manuscript are highlighted in blue.\nReviewer 1\nComment 1\nThe hardware target is not described in detail, and the authors only point to a previous paper\n(23) for the modelling of analog noise. No information is given on: - The actual spatial\nparallelism of AIMC and Digital accelerators used in the experiments.\n- Their dataflow constraints, if any.\n- The type of architecture (e.g. systolic/SIMD) of the digital accelerators, and that of the\nAIMC ones.\n- etc. Linked to this point, the results of Table I include a \"Number of Tiles\"\ncolumn, which according to the text seems to refer to spatial tiles, i.e., copies of the same\naccelerator. Why is this value different for all compared methods? Is it assumed that a\nnumber of accelerators sufficient to run the entire layer in parallel is always allocated?\nThis ignores the possibility of tiling the layer TEMPORALLY. Why so?\nDiscussion/Revision:\nWe thank the reviewer for this insightful comment regarding hardware characterization and resource\nmodeling. Our methodology is designed to be hardware-agnostic, focusing on identifying optimal layer-\nwise precision mappings rather than targeting a fixed hardware configuration. As such, we do not model\nspatial or temporal parallelism, specific dataflow schemes, or architectural microdetails (e.g., SIMD vs.\nsystolic) in our experiments. Doing so would require hardcoding hardware-specific assumptions, which\nwould undermine the generality and reusability of our framework. Instead, our framework assumes an\nabstract mixed-precision hardware platform that supports analog and digital execution with sufficient\nresources to accommodate any mapping derived from the supernetwork, shown in figure 1 of the paper.\nAnalog computation is modeled using AIHWKit [Ref. 23], which accurately simulates device-level noise\nand nonidealities.\nWe appreciate the reviewer’s attention to the ”Number of Tiles” column. This value refers to the number\nof analog tiles required to host the layers mapped to analog execution under the assumption of full layer-\nwise mapping without temporal tiling. We do not consider temporal tiling due to high energy and time\nconsumption of reprogramming during inference. We assume a hardware infrastructure that contains at\nleast the maximum number of tiles required, i.e., multiple accelerators can be used to achieve this. The\nvariation in this number across methods stems from their differing choices on which layers to map to\nanalog hardware. If a layer is deemed too sensitive to noise, it is mapped to digital, thus not requiring\nanalog tile allocation.\nThis paragraph is added to section: Methods.A Comparison Setup:\nTo maintain generality, we do not model hardware-specific dataflow constraints, such as spatial or temporal\ntiling, nor assume a fixed architecture type (e.g., SIMD or systolic). Our framework is intentionally\nhardware-agnostic and abstracts the hardware platform as one that supports analog, INT8, and FP16\ncomputations. The reported “Number of Analog Tiles” corresponds to the cumulative number of analog\ncompute units needed to support the selected analog-mapped layers under a layer-wise spatial allocation\nmodel. These values may vary across mapping strategies depending on how many layers are mapped\nto analog. We assume sufficient hardware availability for the mapped configuration, and leave detailed\nhardware scheduling or temporal reuse modeling to future work.\nFurthermore, to prevent ambiguity, we have renamed the column to “Number of Analog Tiles.”\nThe entire method is aimed at improving energy efficiency but no information is given on\nthe considered energy model. For example, is it assumed that when a certain accelerator is\nnot active, its consumption is 0? This is a strong assumption, and may bias the results,\nsince some of the baselines, like ODiMO, enable parallel usage of multiple accelerators (for\nthe same layer) which maximizes utilization and reduces dark silicon consumption. Also, no\ncomment on the impact of the proposed method vs the baselines in terms of latency is provided.\nDiscussion/Revision:\nWe thank the reviewer for highlighting the need for clarity around the energy model and latency as-\nsumptions.\nOur method focuses on optimizing mapping decisions that trade off accuracy, digital memory footprint,\nand analog compute utilization. We do not model absolute energy consumption or latency directly, but\ninstead use proxy metrics that correlate strongly with energy efficiency, such as:\n• Analog MAC Ratio: proportion of MACs executed in energy-efficient analog tiles.\n• Digital Weight Size: representing memory footprint and digital compute load.\nThese metrics are relative, architecture-agnostic indicators rather than precise physical energy or latency\nmodels. The assumption that idle accelerators consume zero energy is implicit in these proxy-based\ncomparisons, and we agree that this may lead to optimistic projections for sparse analog utilization in\nsome cases.\nRegarding latency, we do not explicitly simulate end-to-end inference delay. However, since analog tiles\ntypically offer lower per-operation latency, our mapping strategies–which assign high-computation, noise-\ntolerant layers to analog–are generally aligned with low-latency execution.\nImportantly, in terms of search time (i.e., the time required to identify an optimal mapping configuration),\nwe do provide direct experimental evidence. As shown in Fig. 3 and Extended Data Fig. 5, both MPS and\nMPAAS significantly outperform baselines such as ODiMo and LionHEART in search time across multiple\nmodels. This highlights the practical efficiency of our approach in identifying high-quality mappings under\nmulti-objective constraints.\nWe agree that integrating cycle-accurate energy and latency models would be a valuable extension and\nwill consider this for future work. In the revised manuscript, we now explicitly clarify the modeling\nassumptions and limitations around energy and latency.\nThese paragraphs are added to the discussion to clarify our proxies and comparison:\nAlthough our framework aims to improve energy efficiency, we do not simulate absolute energy or latency\nvalues. Instead, we rely on proxy objectives—namely, Analog MAC Ratio and Digital Weight Size—which\nreflect analog compute utilization and memory footprint, respectively. This abstraction allows the method-\nology to remain hardware-agnostic, but it implicitly assumes that inactive compute units do not consume\npower, which may result in optimistic estimates in low-utilization scenarios. We also do not explicitly\nmodel end-to-end inference latency; however, our strategy tends to assign high-compute, noise-tolerant\nlayers to analog units, which are typically lower-latency in practice.\nImportantly, we do provide a detailed evaluation of search time—the time required to discover an optimal\nmapping. As shown in Fig. 3, both MPS and MPAAS significantly outperform baseline methods such\nas ODiMo and LionHEART. This demonstrates that our framework not only enables energy-efficient\nmappings, but also discovers them with substantially greater efficiency. Future work may incorporate\ncycle-accurate energy and latency models to further enrich the analysis.\nSome aspects of the methodology are quite unclear. - The procedure called \"Progressive Noise\nScaling\" (lines 10:12 of Algorithm 1) is not clearly explained. It is hard to grasp why if a\ncertain layer is resilient to noise, then its noise scale is increased. What is the rationale?\nAnd why are the increases in steps of 0.1? Does this value have a specific meaning?\n- The authors mention setting the alpha parameters to 1/|O| during fairness training. However,\nit is not clear what is the sampling method (e.g., Gumbel Softmax, Argmax, etc) used in the\nfollowing phases.\nDiscussion/Revision:\nThe rationale behind Progressive Noise Scaling is to simulate increasingly realistic hardware conditions\nduring training, while avoiding destabilizing early training dynamics. In practice, analog hardware noise is\nlayer-dependent and nonuniform. Therefore, we evaluate each analog candidate layer’s resilience to noise\nby comparing its loss degradation when switching from high-precision (FP16) to analog-mode simulation.\nIf a layer shows minimal accuracy degradation in analog mode, it is marked as resilient, and we pro-\ngressively increase its noise level during training—up to a practical bound—to improve robustness to\nreal-world non-idealities. The incremental step of 0.1 is empirically chosen to balance stability and con-\nvergence speed. It does not have a hardware-specific physical interpretation, but reflects the scaling factor\nin the noise distribution as modeled by AIHWKit.\nDuring fairness training, the architecture path weights (α) are initialized uniformly as 1/—O—. In\nsubsequent phases (including fine-tuning and ranking), we use a Gumbel-Softmax sampling technique with\ntemperature annealing to enable differentiable, yet sharp, sampling over architectural choices. This allows\nfor gradient-based updates of the α parameters while enabling the network to converge toward discrete\nchoices. We now explicitly mention this in the Methods section.\nIn Methods, we extended the rationale behind the progressive noise scaling:\nFor such layers, we progressively increase the injected analog noise during training, in increments of 0.1\napplied to the standard deviation of the Gaussian noise model in AIHWKit. This strategy gradually\nexposes the network to realistic analog noise conditions, which helps improve robustness without desta-\nbilizing early training. Importantly, this progressive scaling mechanism also facilitates convergence of the\nsupernetwork by allowing sensitive layers to train under more stable conditions initially, while enabling\nnoise-resilient layers to regularize more aggressively over time. The 0.1 step size is empirically chosen as\na balance between training stability and robustness, and does not correspond to a fixed hardware-level\nquantity.\nIn Methods, we also clearly mention how the relaxation is done:\nTo sample among the candidate operations for each layer during training, we employ a Gumbel-Softmax re-\nlaxation. This technique enables differentiable sampling from a categorical distribution, allowing gradient-\nbased updates to the α parameters while approximating hard architectural choices. The temperature\nof the Gumbel-Softmax distribution is annealed throughout training to encourage increasingly discrete\nselections as optimization progresses.\nComment 4\nAs partially already mentioned, Table I includes several columns that are not discussed in the\ntext. Besides the \"Number of Tiles\", the others are \"Parameters\" and \"Digital Weight Size\".\nNamely, - The former may refer to the fact that the proposed approach sometimes increases the\nlayer size, through what the authors call hardware-aware adaptation. However, the increase\nseems extreme in the ResNet20 case (from 0.26M to 0.86M). This point should be discussed.\n- The latter refers to the total bits occupied by digital weights, but it’s not clear why the\nvalues in this column do not have an uncertainty interval. If the Analog Utilization changes,\nhow can the Digital Weight Size remain fixed?\n3\n- More in general, are the results in Table I obtained from a single Pareto front (in which\neach point has an uncertainty interval) or is each run extracted from a separate Pareto front?\nDiscussion/Revision:\n1. Parameters Increase (e.g., ResNet20): The increase in parameter count for MPAAS reflects\nthe use of hardware-aware layer adaptations, such as resizing intermediate layers or expanding\nconvolutional channels to better utilize analog tile dimensions. For example, in ResNet20, the\nfully connected layer width is increased in some blocks to match analog tile sizes (e.g., 256 rows),\nwhich leads to the increase from 0.26M to 0.86M parameters. These modifications are performed\nwithout changing the final output shape of the model and are essential to maximize analog resource\nutilization. We have now explicitly discussed this in the Results section: These adaptations induce\nan increase in the total number of parameters. For example, in ResNet20, the fully connected layer\nwidth is increased in some blocks to match analog tile sizes (e.g., 256 rows), which leads to the\nincrease from 0.26M to 0.86M parameters. This leads to a minor increase in the total number of\ntiles and a better tile utilization.\n2. Digital Weight Size Consistency: The Digital Weight Size reflects the final extracted architecture\nafter ranking and retraining, not the variability during search. Since the selected architecture has\na fixed digital mapping, the digital weight size remains constant across retraining replicates, unlike\ntask-specific performance, which has stochastic elements (e.g., weight initialization). This is why\nwe do not report uncertainty for digital memory size. We have clarified this point in to the table\ncaption.\n3. Pareto Front and Replicates: Each reported result corresponds to a point extracted from a\nshared Pareto front built during one supernetwork search per model. This is consistent across MPS\nand MPAAS. We now explicitly mention this in the Methods section: For each model, we perform\na single supernetwork search to construct a Pareto front that jointly optimizes task performance,\nanalog utilization, and digital memory. A selected point from this front is extracted based on\nthe elbow method and retrained five times to report task-specific performance variability (mean ±\nstd). The digital weight size and parameter count remain fixed for the selected architecture and are\nreported without uncertainty.\nComment 5\nAlso, in Table I, the authors sometimes report accuracies higher than those of a \"full digital\"\napproach using their proposed mapping. While this can sometimes happen due to noise, I wonder\nif it could be due to a higher training budget for the proposed approach. In other words, are\nall baselines allowed to train for the same number of epochs? (maximum, except early-stopping)\nDiscussion/Revision:\nWe confirm that all models and baselines were trained under identical training budgets, using the same\nnumber of epochs and early stopping criteria. The higher performance observed in MPAAS arises not\nfrom longer training, but from the hardware-aware layer adaptations applied in this configuration. These\nadaptations — such as widening fully connected or convolutional layers — increase the representational\ncapacity of the model (i.e., total parameters), which can lead to better accuracy compared to the original\nfull digital baseline. Importantly, these adaptations are constrained to ensure no additional inference\nlatency or energy overhead beyond what the analog tile size allows.\nThis clarification has been added to the Results section:\nto increased training time, as all models were trained under the same epoch budget with early stopping.\nInstead, the accuracy gain is attributed to hardware-aware adaptations that expand layer widths to better\nutilize analog tile dimensions, thereby increasing model capacity while maintaining efficiency constraints.\nComment 6\nA similar question on the comparison fairness concerns the hyper-parameters used for baselines\nODiMO and LionHEART. Line 262 mentions that the proposed approach’s hyper-parameters are\noptimized with Optuna. Has the same procedure been applied also to the baselines, or have the\ndefault hyper-parameters been used from the original papers?\nDiscussion/Revision:\nWe confirm that hyperparameter optimization was performed consistently across all evaluated methods,\nincluding ODiMO and LionHEART. Specifically, each method (including the proposed MPS/MPAAS and\nall baselines) underwent tuning using the Optuna optimization framework, with consistent search spaces\nand stopping criteria. The best-performing configurations–based on validation performance–were then used\nto report the results in Table I and Extended Data Tables I–III. This clarification has now been added\nto the Comparison Setup section of the Methods.\nComment 7\nExtended data Fig. 3 mentions \"1-day accuracy\" as a metric, probably hinting to the fact that\nAIMC accuracy tends to drift over time. However, it is not clear if this aspect has been\nmodelled and how the accuracy of the proposed mapping could evolve over time.\nDiscussion/Revision:\nTo clarify, the “1-day accuracy” metric refers to inference accuracy after one day of simulated analog\nweight drift, modeled using AIHWKit’s temporal noise and drift simulation modules. AIHWKit simu-\nlates realistic device-level degradation over time, including retention loss and conductance drift, based on\nempirical models of analog memory behavior.\nThis metric is not used during the main search or training process but is computed post hoc to evaluate\nthe long-term robustness of the selected analog mappings. This clarification has been added to the figure\ncaption.\nComment 8\nIn the abstract, the last sentence mentions \"assigning 80% of those weights\" but it is not\nclear what weights are being referred to.\nDiscussion/Revision:\nThe phrase “assigning 80% of those weights” refers to the total network weights (i.e., parameters) that\nare mapped to analog hardware. We agree that this could be clearer, and we have revised the sentence in\nthe abstract to explicitly state that it refers to the percentage of total model weights mapped to analog.\nmaintaining full-precision accuracy.\nComment 9\nLine 57 mentions that ODiMO is only applicable to convolutional layers. This is not completely\ncorrect, as it can also be applied to linear layers (e.g., within Transformers), although not\nto attention layers.\nDiscussion/Revision:\nIt is correct that ODiMO can be extended to linear layers (such as those found in the feedforward com-\nponents of Transformer models), although it is not directly applicable to attention mechanisms or more\ncomplex architectural components. We have revised the sentence to accurately reflect this distinction.\nRevised sentence: are limited to convolutional and linear layers, and cannot be readily applied to attention\nmechanisms or more complex architectural blocks.\nComment 10\n\"Odimo\" and \"ODiMo\" should be \"ODiMO\".\nDiscussion/Revision:\nThank you, fixed.\nComment 11\nThe ODiMO method has recently been extended in this paper: https://doi.org/10.1109/TCAD.2025.3543715,\nprobably not cited in the manuscript beacuse it was not available at the time of submission.\nThe authors are suggested to replace their reference with this new one.\nDiscussion/Revision:\nThank you, fixed.\nComment 12\nFigure 1 (c): the meaning of colors is not clear (e.g., two Conv layers are yellow, what\nchanges with respect to the blue ones)? Add a legend.\nDiscussion/Revision:\nThank you, fixed.\nLine 111 there’s a typo: \"A least one\" --> \"At least one\".\nDiscussion/Revision:\nThank you, fixed.\nComment 14\nIn lines 193-194, it is imprecise to associate metrics to models, instead of tasks/datasets.\nDiscussion/Revision:\nThank you for this observation. We changed it to:\nThese configurations were evaluated based on task-specific metrics: classification accuracy for CIFAR-10\n(ResNet20), mean Intersection-over-Union (mIoU) for COCO segmentation (ResNet50), and F1-score for\nSQuADv1 (MobileBert), highlighting the incremental benefits of each added strategy.\nComment 15\nWrong hyperlinks: Extended Data Table I (line 127), Extended Figure 3 (line 169)\nDiscussion/Revision:\nThank you for this observation. Fixed.\nComment 16\nIn Extended Data Fig. 1, skip connections are marked as red arrows. However, from Fig. 2,\nit seems that skip connections are one of the branches of the SuperNet. So why aren’t they\nassociated with a probability bar like the other three branches? Also, the x axis has no\nlabel.\nDiscussion/Revision:\nIn these architectures, the skip connections often include a projection convolution (e.g., 1×1 conv),\nespecially when input and output dimensions differ. This convolution is treated as an independent layer\nin the SuperNet and is associated with a probability bar like all other operations. The red arrows in the\nfigure are used solely for visual clarity to indicate that these convolutional blocks are functionally part of\nthe skip connection pathway.\nWe have clarified this in the figure caption and added an x-axis label for completeness.\nIn Extended Data Fig. 4: - What is ODiMO-HWA exactly and how does it differ from ODiMO-QAT?\n- Is the y axis of panel (b) \"energy\" or \"energy efficiency\"? If it is Energy, it seems that\nODiMO outperforms the proposed method.\nDiscussion/Revision:\nODiMO-QAT refers to the baseline ODiMO method trained with quantization-aware training only, while\nODiMO-HWA combines QAT with hardware-aware training, which includes analog noise injection and\ndrift modeling. Both variants use channel-wise precision granularity during search.\nOur proposed method (MPS), in contrast, uses a layer-wise SuperNet formulation with progressive noise\nscaling, which enables more stable convergence under hardware noise and better adaptation to analog\nconstraints.\nIn panel (b), we clarify that the y-axis represents absolute energy consumption, not energy efficiency.\nComment 18\nIn Extended Data Fig. 5, RS stands for Random Search, but what is \"RS-WS\"?\nDiscussion/Revision:\nRS-WS stands for random search with weight sharing, i.e., on top of the supernetwork.\nComment 19\nIn Extended Data Table I, MobileNetV2 overlaps with other text.\nDiscussion/Revision:\nThank you, fixed.\nComment 20\nIn Extended Data Fig. 3, the x-axis labels are wrong (they show F1 score for COCO and Accuracy\nfor SQuAD, instead of mIoU and F1 respectively).\nDiscussion/Revision:\nThank you, fixed.\nIn Extended Data Table IV, HWA is expanded as \"hardware acceleration\" instead of \"hardware-\naware training\" as in the rest of the paper.\nDiscussion/Revision:\nThank you, fixed.\nComment 1\nInsufficient Details on Architectural Setup: Although the research is motivated by digital-\nanalog computing architectures, the paper does not provide a detailed description of the chip\narchitecture. Essential information regarding the digital and analog components, such as\ncomputing power, bandwidth, and other configuration parameters, is missing.\nDiscussion/Revision:\nWe thank the reviewer for this observation. Our methodology is designed to be hardware-agnostic to\nenable broad applicability across different analog-digital systems. As such, we intentionally do not fix\nspecific chip-level configuration parameters such as compute power, bandwidth, or tile dimensions during\nthe mapping and search process.\nInstead, our evaluation relies on proxy metrics that are generally aligned with hardware efficiency: -\nAnalog MAC Ratio (representing analog compute utilization), and - Digital Weight Size (reflecting digital\nmemory footprint).\nWe simulate analog noise and drift using AIHWKit and use FP16 and INT8 for digital layers via PyTorch\nAMP and dynamic quantization, respectively. The goal is to evaluate trade-offs under varying levels of\nanalog use, not to optimize for a fixed hardware target.\nWe acknowledge that detailed architectural modeling—including spatial parallelism, memory bandwidth,\nand compute throughput—would further improve system-level accuracy but this would too specific with\nthe number of heterogeneous platforms out there. We have now clarified this modeling scope and limitation\nin the Comparison Setup and Discussion sections of the manuscript.\nComment 2\nEvaluation Metrics and Their Interpretability: The paper employs three evaluation metrics:\nTask-Specific Performance, Analog MAC Ratio, and Digital Weight Size. While Task-Specific\nPerformance directly reflects the benefits of the deployment scheme, the latter two metrics\nare not intuitive. The assumption that a higher Analog MAC Ratio and a lower Digital Weight\nSize are inherently better might not hold in all scenarios. For example, in image processing\n(without considering weight replication), analog computation can only reduce the computational\ncomplexity from O(NK) to O(N), where N represents the number of pixels and K denotes the\ntotal convolution kernel size. Since N and K vary across different network layers|and\ngiven that in AIMC the network weights are physically bound to the device|the digital cores\nmight actually be more advantageous for layers with lower memory access demands (typically\nwhen N is significantly larger than K). Therefore, simply offloading computation to the ana-\nlog cores may not fully leverage the potential of a digital-analog architecture. The authors\nshould consider incorporating additional metrics (e.g., computational latency, energy effi-\nciency, and chip area requirements) to demonstrate the benefits of the proposed framework\nmore directly.\nDiscussion/Revision:\nWe thank the reviewer for this insightful observation on the limitations of our proxy metrics and their\nhardware implications.\nAnalog MAC Ratio and Digital Weight Size serve as hardware-agnostic proxies that reflect trends in\ncompute and memory distribution across digital and analog domains. These metrics were chosen to\ncapture analog utilization and digital footprint in the absence of a fixed hardware platform.\nWe fully agree that the assumption that ”higher analog MAC ratio is always better” does not universally\nhold—particularly in scenarios where compute-to-memory ratios vary across layers, as in image processing\ntasks with small kernel sizes or high spatial redundancy. Additionally, weight replication in AIMC and\nphysical binding of weights to crossbar arrays may alter the energy or latency cost-benefit trade-off.\nTo maintain generality, our current framework does not incorporate explicit hardware parameters such\nas area, energy, or latency. However, we recognize the value of such modeling for evaluating deployment\nefficiency in real-world architectures. As such, we now explicitly acknowledge this limitation in the\nDiscussion section and outline it as a direction for future work. Our proposed methodology could be\nextended to support chip-specific constraints by integrating cycle-accurate models (e.g., from NeuroSim or\nCompass) to better capture latency, energy, and area efficiency.\nWe have added this paragraph to the discussion:\nWhile Analog MAC Ratio and Digital Weight Size provide general indications of analog utilization and\nmemory cost, they do not fully capture the nuanced trade-offs present in heterogeneous hardware. For\nexample, in image processing tasks, analog acceleration may offer limited benefits for layers with small\nkernel sizes and high spatial dimensionality, where memory access patterns may favor digital execution.\nFurthermore, AIMC weight replication and non-negligible peripheral overheads may shift the energy or\nlatency balance toward digital cores in specific configurations. Future work may incorporate architecture-\nspecific modeling—e.g., via NeuroSim or Compass—to support more precise evaluation of energy, latency,\nand chip area, thereby enabling the framework to optimize not only precision and task accuracy but also\nsystem-level deployment efficiency.\nComment 3\nIncreased Network Size and Potential Hardware Overhead: In Extended Tables I, II, and III,\nthe results obtained by the proposed MPAAS approach even surpass those of the pure digital\ndeployment scheme. However, it is noteworthy that the networks generated by MPAAS are consis-\ntently larger than the original networks. The paper does not adequately discuss whether the\nincreased network size incurs additional hardware overhead. For instance, Extended Table I\nshows that the MPAAS-derived ResNet8 (CIFAR-10) network is 2.7 times larger than the original,\na factor that could have significant implications for hardware cost and efficiency.\nDiscussion/Revision:\nWe thank the reviewer for this important observation regarding increased network size under MPAAS.\nIt is correct that MPAAS occasionally produces networks larger than the original models, as shown\nin Extended Tables I–III. This is a result of the hardware-aware adaptation strategy, where layers are\nexpanded (e.g., by increasing channel widths) to better match analog tile dimensions or to improve\nrobustness under analog noise. For example, in ResNet8 (CIFAR-10), the network size increases by 2.7×\nto improve analog utilization and recover accuracy lost due to precision noise.\nHowever, we acknowledge that this increase in parameters could incur additional hardware overhead,\nespecially in terms of memory usage. For example, MPAAS resnet20 uses 31 tiles instead of 28 for\nthe conventional one. But this means that more layers are able to run in analog which makes the full\nrun more energy-efficient under our assumptions. While our current evaluation focuses on energy and\naccuracy trade-offs, we agree that parameter growth should be considered explicitly in future hardware-\naware deployment studies. We have now added a discussion on this trade-off to the manuscript.\nWe note that MPAAS achieves higher accuracy than the original full-digital baseline in some cases,\npartially due to its ability to adapt the network structure. This includes expanding certain layers to\n11\nbetter align with analog tile dimensions, which increases total parameter count. For instance, in CIFAR-\n10 (ResNet8), the adapted network is 2.7× larger than the original. While this improves analog utilization\nand robustness, it also increases potential hardware overhead in terms of area and memory. In future\nwork, we plan to include chip-specific area constraints and evaluate trade-offs between adaptation-based\naccuracy gains and deployment cost.\nComment 4\nUnclear Description of the Adaptation Process: The manuscript’s explanation of the adap-\ntation mechanism is vague and lacks concrete details regarding the hardware parameters and\ncorresponding algorithmic modifications. For example, Figure 2 (2) indicates that adaptation\nis also applied for computations on digital cores operating in INT8 format, yet the ratio-\nnale behind this adaptation remains unexplained. A more detailed discussion is necessary to\nclarify the underlying motivations and implementation details.\nDiscussion/Revision:\nThe adaptation procedure is primarily motivated by hardware-alignment constraints—for example, match-\ning layer shapes to analog tile dimensions (e.g., 128×128 or 256×256 crossbar arrays), minimizing write\namplification, and improving compute utilization. This includes resizing certain layers, such as widening\nfully connected or convolutional blocks, and merging small layers where needed.\nAlthough adaptation is more impactful for analog layers, we also apply it to digital INT8 layers for\nconsistency and to account for alignment or quantization effects, especially when input/output channel\nsizes are not naturally compatible with INT8 vectorization or memory access granularity. Additionally,\nadapted digital layers can help balance precision-accuracy trade-offs, where an INT8 layer with more\nchannels may better preserve representational capacity compared to an unadapted counterpart.\nWe have revised the Results section to better explain the rationale and implementation of adaptation for\nboth analog and digital cores.\nWhile most adaptations target analog-mapped layers to improve tile utilization and robustness, they are\nalso applied in some digital INT8 layers to compensate for reduced precision and to align with vectorized\ndigital hardware (e.g., SIMD units), ensuring efficient execution without added latency.\nComment 5\nInconsistent Section Titles in the Methodology: In the Method section, sections B and C share\nidentical titles, which leads to confusion.\nDiscussion/Revision:\nThank you for the observation, we fixed it.\nComment 6\nAmbiguity in the Training Process Description: The Method section outlines a three-phase\ntraining process, with the second phase introducing quantization and noise constraints. The\nmanuscript states that training in the first phase begins with FP16, raising the question:\nnot contribute meaningful differentiation.\nDiscussion/Revision:\nIndeed, during the first phase, all candidate operators are initialized with the same FP16 configura-\ntion, and no sampling across precision choices occurs yet. The purpose of this phase is to warm-start the\nsupernetwork weights under high numerical precision, leveraging pretrained weights (when available) and\nallowing stable convergence before introducing mixed-precision constraints.\nWhile all operators are initially equivalent, this phase still plays a critical role by preparing the network\nto support future specialization in later phases. Importantly, we use weight replication across branches\nto initialize lower-precision operators after this phase, which helps ensure stability and avoids cold starts\nwhen quantization and analog noise are introduced in phase two.\nThis paragraph has been added to the Fairness training section in Methods.C:\nAlthough all operators are set to FP16 in this phase and no precision sampling occurs, this step serves to\nwarm-start the network weights under stable numerical conditions. It ensures that the shared parameters\nconverge before branching, and allows us to initialize lower-precision paths via weight replication in later\nphases, supporting more stable training under quantization and noise.\nComment 7\nDiscrepancy in Propagation Paths: In Figure 2 (3), the diagram shows an inconsistency between\nthe backpropagation update paths and the forward propagation paths. Specifically, the\nillustration suggests that a fair selection process involves all candidate operators, which\nappears to contradict the intended design. The authors should either provide an explanation\nfor this discrepancy or revise the figure for clarity.\nDiscussion/Revision:\nTo clarify: during the fairness training phase, we employ a strictly fair sampling scheme (as described in\nFairNAS), where each candidate operator for a given layer is sampled uniformly across training iterations.\nThe figure illustrates this sampling process over time — not a single forward/backward pass. That is,\nalthough only one operator is active per path in each forward pass, all paths are trained across batches\ndue to fair sampling.\nThe arrows in the figure highlight which operators receive gradient updates during the sampled pass —\nbut all candidate paths are updated over the course of training. We have now revised the figure caption\nand added a brief note in the Methods section to clarify this behavior.\nWe added a clarification to the figure’s caption: A fairness sampling strategy is used, where only one\ncandidate path per layer is activated per training step, but all paths are updated uniformly over time\nthrough repeated sampling.\n13"}, {"round": 2, "reviewer_comments": {"reviewer_1": "The authors have addressed many of our comments (mine and of the supporting early career researcher) from the first review, especially those related to missing details or explanations, and the manuscript clarity has improved significantly.\nHowever, three major concerns remain:\n1. Lack of latency and energy results, at least simulated.\nWhile it is clear and appreciated that the authors prefer to utilize hardware-agnostic and thus general cost models and metrics during the optimization phase, it would be still very relevant to see how the found architectures perform on real hardware, or at least on an accurate simulator.\nSecondary aspects and non-idealities are often very relevant in hardware mapping (e.g., data transfer overheads between accelerators, dark silicon energy, etc.). For a high-level journal like Nature Communications, it would be important to show that the proposed approach can lead to real-world performance/energy improvements.\nNote that we are not suggesting that the entire optimization should be redone with more accurate models, but rather that the authors should provide some results on how the currently found architectures perform once deployed on real hardware or a simulator.\n2. Not entirely fair comparison with the baselines.\nIn their response to our Comment #4, the authors have clarified the reason behind the increase in the number of parameters in their proposed method, which is their adaptation pass. However, since this increase is sometimes extreme (e.g. 3x for ResNet20 in Table 1), it makes the comparison with the baselines not entirely fair. The authors claim that these adaptations are essentially at zero-cost, but without proper energy and latency results, this is a claim that cannot be verified (see point #1 above).\nAdditionally, in their answer to Comment #1, the authors have clarified that the \"number of analog tiles\" is a physical number of distinct acceleration tiles that needs to be allocated for the task (i.e., no temporal tiling is applied). In this case, the comparisons in Table 1 are even less fair. For instance, for ResNet20, ODiMO uses 9 tiles while the proposed MPAAS uses 31. This means that a fixed-size accelerator of, say, 100 tiles, could run 10+ ODiMO-sized networks in parallel (e.g. for different tasks), while only 3 MPAAS-sized networks.\nThis is not to say that MPAAS isn't superior to ODiMO in the Pareto sense, but rather that the method used for selecting the compared networks in Table 1 (a not better specified form of the elbow method) is not entirely fair, as the compared models are completely different in terms of hardware cost and capacity.\n3. Unclear uncertainty intervals in Table 1.\nThe authors have clarified in their response to our Comment #4 that the \"Digital Weight Size\" in Table 1 does not have an uncertainty interval because: \"the selected architecture has a fixed digital mapping, the digital weight size remains constant across retraining replicates, unlike task-specific performance, which has stochastic elements\".\nHowever, it is not clear why, instead, the Analog MAC Ratio has an uncertainty interval, since the Analog MAC Ratio also depends solely on the architecture mapping. This point should be clarified in the text.\nAs an additional minor comment:\nThe caption of the supplementary note fig. 4 is not fully clear. In particular:\nYou mention that the subplot (a) shows the \"Test accuracy over training epochs\", but the barplot does not report any epoch.\nGiven that you have clarifies that the subplot (b) reports indeed energy estimates, how did you exactly obtain them?\nFurthermore, how do you justify why your method has a higher energy consumption than the other considered baseline, i.e. ODiMO?\nThe caption does not include any reference to subplot (c).\n\n(Remarks on code availability)\nThe code included in the original submission has now been removed.", "reviewer_2": "I co-reviewed this manuscript with one of the reviewers who provided the listed reports. This is part of the Nature Communications initiative to facilitate training in peer review and to provide appropriate recognition for Early Career Researchers who co-review manuscripts.", "reviewer_3": "We are glad to see that the authors have provided more explanations and made the paper clearer. However, there are still major issues that make the current version not ready for acceptance.\nFrom the Introduction, we understand that the paper proposes a general framework for network search and mapping on hybrid architectures that combine Analog In-Memory Computing (AIMC) and digital computing. For the paper’s idea to be convincing, two conditions must be met:\n(1) Hybrid AIMC-digital architectures should bring clear advantages;\n(2) The proposed framework (MPS & MPAAS) should be able to make good use of such architectures and achieve better results.\nTo prove these points, it is important to evaluate both hardware performance and task performance.\nFor hardware performance, the most straightforward way is to report real metrics, such as inference time, power, energy efficiency, and chip area. In the reply, the authors mentioned they did not evaluate specific chips to keep the method general, and instead used Analog MAC Ratio and Digital Weight Size. I think this is not reasonable. This concern was already explained in Comment 2 of the first review. The authors also admitted in the reply that these two indicators do not fully reflect hardware performance. Even if the framework is meant to be general, I believe the authors still need to show results on a few typical hardware settings to prove that the framework is truly effective.\nFor task performance, from both Table II and the supplementary tables, we can see that compared with the full-digital FP32 baseline, the task accuracy is improved when using MPAAS. However, the number of model parameters also increases, sometimes a lot—especially for small networks. This makes us wonder whether the accuracy gain really comes from the design of the framework, or simply from having a larger model. In the reply, the authors said “more layers are able to run in analog which makes the full run more energy-efficient under our assumptions.” But we have already discussed that running more in analog does not always lead to better hardware performance. So this assumption may not hold.\nIn short, unless the authors can provide real hardware performance results (e.g., latency, power, area, etc.) under some example architectures, the claimed benefits are not convincing.\n\n(Remarks on code availability)\nThe code provided by the authors is missing a README file that outlines usage instructions and lacks an environment configuration file."}, "author_response": "Response to Reviewers for Manuscript ID: NCOMMS-25-17053A\nChanges to the manuscript are highlighted in blue.\nReviewer 1\nComment 1\nLack of latency and energy results, at least simulated.\nWhile it is clear and appreciated that the authors prefer to utilize hardware-agnostic and\nthus general cost models and metrics during the optimization phase, it would be still very\nrelevant to see how the found architectures perform on real hardware, or at least on an\naccurate simulator.\nSecondary aspects and non-idealities are often very relevant in hardware mapping (e.g., data\ntransfer overheads between accelerators, dark silicon energy, etc.). For a high-level journal\nlike Nature Communications, it would be important to show that the proposed approach can lead\nto real-world performance/energy improvements.\nNote that we are not suggesting that the entire optimization should be redone with more\naccurate models, but rather that the authors should provide some results on how the currently\nfound architectures perform once deployed on real hardware or a simulator.\nDiscussion/Revision:\nWe thank the reviewer for this insightful comment. To address it, we extended our study with hardware-\nlevel latency and energy simulations using the open-source 3DCiM-LLM-Inference Simulator [1].\nThis simulator provides event-driven array-level estimates for analog/digital hybrid compute-in-memory\narchitectures based on the IBM HERMES project chip [2] energy and latency models. While not\ncycle-accurate, it captures realistic peripheral and communication overheads representative of AIMC-based\naccelerators.\nAll networks were simulated under a single-tier heterogeneous architecture comprising up to 64 analog\ntiles, each of 512×512 dimension. Each tile’s compute energy (per MAC) and latency were modeled\nfollowing IBM HERMES project chip experimentally calibrated parameters (0.65 ns/MAC, 0.35 pJ/MAC).\nPeripheral and data-movement costs were included based on simulator defaults. The simulated results are\nnow presented in Table I in the main text, and extended results are available in the Supplementary\nMaterial.\nFor comparison, we ensured that competing frameworks were modeled consistently. Harmonica and\nODiMo employ a channel-wise partitioning strategy, in which each convolutional layer is divided along\nthe output-channel dimension between analog and digital accelerators. To reproduce this setup, we im-\nplemented two parallel convolutions per affected layer—one on analog tiles and one on digital tiles—with\noutput-channel counts matching the original ODiMo allocation. This faithfully emulates the hybrid\ndataflow used in these frameworks while enabling a direct comparison with our layer-wise mapping ap-\nproach.\nAs an additional validation exercise, we evaluated our optimized MPS mappings using the ODiMo\nlatency and energy models reported in [?]. Under these assumptions, using the ResNet20 architecture\non CIFAR-10, MPS achieved a task accuracy of 91.2%, with a simulated latency of 0.74 ms and total\nenergy of 14.02 µJ/sample. In ODiMo’s own study (CIFAR-10, “Min-Cost” configuration), the reported\nresults were 90.06% accuracy, 0.47 ms latency, and 13.57 µJ/sample. While the absolute latency is slightly,\nMPS achieves comparable energy efficiency with +1.1 % higher accuracy and better analog-resource\nutilization (analog-channel ratio = 83.4 %). When compared to the ODiMo “Small-En” configuration\n1\n(90.17% / 0.80 ms / 25.94 µJ), MPS shows both lower latency and nearly 1.9x lower energy. These\nresults confirm that MPS retains its efficiency advantage even under ODiMo’s cost model and mapping\nassumptions, demonstrating that our framework generalizes across heterogeneous architectural conditions.\nFor completeness, we also compared against the ODiMo Large–Lat configuration, which matches our\naccuracy most closely (91.24% vs. 91.2%). Under ODiMo’s cost model, ODiMo Large–Lat achieves 1.55\nms latency and 43.20 µJ/sample energy. Under identical assumptions, MPS achieves 0.74 ms and\n14.02 µJ/sample, providing a 2.1x latency speedup and 3.1x energy reduction at essentially the\nsame accuracy.\nAcross all benchmarks, MPS and MPAAS deliver 1.7–2.4× latency speedup and 1.9–2.6× energy\nefficiency over full-precision digital baselines, while maintaining competitive task-specific performance.\nImportantly, these gains confirm that the energy–accuracy trade-offs observed in our abstract cost models\n(Analog MAC ratio) translate directly to realistic hardware behavior.\nComment 2\nNot entirely fair comparison with the baselines. In their response to our Comment #4, the\nauthors have clarified the reason behind the increase in the number of parameters in their\nproposed method, which is their adaptation pass. However, since this increase is sometimes\nextreme (e.g. 3x for ResNet20 in Table 1), it makes the comparison with the baselines not\nentirely fair. The authors claim that these adaptations are essentially at zero-cost, but\nwithout proper energy and latency results, this is a claim that cannot be verified (see point\n#1 above). Additionally, in their answer to Comment #1, the authors have clarified that the\n\"number of analog tiles\" is a physical number of distinct acceleration tiles that needs to be\nallocated for the task (i.e., no temporal tiling is applied). In this case, the comparisons\nin Table 1 are even less fair. For instance, for ResNet20, ODiMO uses 9 tiles while the\nproposed MPAAS uses 31. This means that a fixed-size accelerator of, say, 100 tiles, could\nrun 10+ ODiMO-sized networks in parallel (e.g. for different tasks), while only 3 MPAAS-sized\nnetworks. This is not to say that MPAAS isn’t superior to ODiMO in the Pareto sense, but rather\nthat the method used for selecting the compared networks in Table 1 (a not better specified\nform of the elbow method) is not entirely fair, as the compared models are completely different\nin terms of hardware cost and capacity.\nDiscussion/Revision:\nWe thank the reviewer for raising this important point. We agree that a fair comparison must con-\nsider both model capacity and hardware allocation. Our framework includes two variants precisely to\nseparate these aspects: the base MPS, which does not increase parameter count, and the MPAAS vari-\nant, which introduces lightweight hardware-aligned adaptations (e.g., layer resizing to match analog tile\ndimensions). As shown in Table I, even the MPS configuration, without any parameter increase, already\noutperforms state-of-the-art baselines such as ODiMo and LionHEART in both task-specific accuracy and\nanalog utilization, demonstrating that the improvement is not dependent on parameter count.\nThe goal of the MPAAS extension is to study the upper bound of achievable efficiency when small\narchitectural adaptations are permitted to better exploit analog hardware parallelism. These adaptations\nincrease the number of intermediate channels or neurons so that each analog tile (of fixed 512×512\ndimension) is fully utilized, minimizing unused compute rows. While this does raise the total parameter\ncount, it does not proportionally increase latency or energy, as confirmed by the 3DCiM-based simulations\nadded in Table I. For instance, on ResNet20, MPAAS increases parameters by ∼ 3× yet exhibits only a\nmarginal latency increase (1.32 ms vs. 1.05 ms for MPS) while improving accuracy from 90.8% to 94.2%.\nThis confirms that the adaptation cost is small relative to the accuracy benefit.\nRegarding the reviewer’s point on the number of analog tiles, we emphasize that tile count in Table I\nreflects *theoretical allocation* for single-network deployment without temporal multiplexing. Our choice\nto report physical tile counts is consistent across all methods and does not affect relative comparisons. To\n2\naddress the reviewer’s concern, we now explicitly include latency and energy per sample, which naturally\nnormalize for tile usage and show that MPS and MPAAS retain higher efficiency under identical resource\nmodels.\nOn model selection fairness: The elbow-based Pareto ranking was used only to choose representative\noperating points on the accuracy–efficiency curve. We have now added a methodological note stating that\nTable 1 corresponds to the best accuracy–analog mac ratio trade-off found under a shared 64-tile hardware\nconstraint. This is what is meant by the Pareto trade-off in the caption.\nThese clarifications and the newly added simulated latency/energy data establish that the comparisons are\nperformed under equal hardware conditions, and that the proposed architectures retain their advantages\nin both performance and efficiency.\nFurthermore, fixing the number of tiles also solves the high number of tiles used from ViT-adapter, which\nwe agree is not practical.\nComment 3\nUnclear uncertainty intervals in Table 1.\nThe authors have clarified in their response to our Comment #4 that the \"Digital Weight Size\"\nin Table 1 does not have an uncertainty interval because: \"the selected architecture has a\nfixed digital mapping, the digital weight size remains constant across retraining replicates,\nunlike task-specific performance, which has stochastic elements\".\nHowever, it is not clear why, instead, the Analog MAC Ratio has an uncertainty interval, since\nthe Analog MAC Ratio also depends solely on the architecture mapping. This point should be\nclarified in the text.\nDiscussion/Revision:\nWe thank the reviewer for pointing out this inconsistency. Following the reviewer’s observation, we\nre-ran all experiments and verified that in several cases—particularly for methods that rely on stochastic\nsampling during supernetwork training or that include multiple near-optimal mappings—the final selected\narchitectures exhibit small variations in both the Analog MAC Ratio and the Digital Weight Size across\nretraining replicates. These variations arise because the ranking stage may select slightly different Pareto-\noptimal mappings when the supernetwork is retrained, even though the differences in accuracy are small.\nTo ensure a fair and internally consistent comparison across all methods, we have updated Table 1 to\nreport standard deviations for all architecture-dependent quantities, including Analog MAC Ratio and\nDigital Weight Size. While these variations are typically very small for our method, we agree that\nreporting them explicitly improves clarity and avoids any ambiguity regarding how uncertainty is handled.\nComment 4\nThe caption of the supplementary note fig. 4 is not fully clear. In particular: You mention\nthat the subplot (a) shows the \"Test accuracy over training epochs\", but the barplot does not\nreport any epoch.\nDiscussion/Revision:\nCorrected. Subplot (a) reports Test accuracy on channel-wise vs layer-wise results.\nGiven that you have clarifies that the subplot (b) reports indeed energy estimates, how did\nyou exactly obtain them? Furthermore, how do you justify why your method has a higher energy\nconsumption than the other considered baseline, i.e. ODiMO?\nDiscussion/Revision:\nWe thank the reviewer for this question. Subplot (b) provides high-level energy estimates derived ex-\nclusively from the proportion of MAC operations assigned to analog vs. digital units. These values\nare computed as a linear combination of analog and digital MAC counts multiplied by their respective\nnormalized per-MAC costs. This proxy intentionally ignores peripheral effects, communication overhead,\nactivation movement, and tile-level utilization. Its purpose is only to illustrate how the analog/digital\nallocation shifts across methods, not to approximate hardware-level energy.\nSubplot (c) in the same figure highlights the increased complexity of training ODiMO’s channel-wise\nsupernetwork under analog non-idealities, where the search becomes significantly slower and more unstable\nthan our layer-wise approach.\nWhen realistic hardware behavior is considered—including ADC/DAC overhead, data movement, tile\nparallelism, and analog-tile underutilization—the trend reverses. Table I reports the latency and energy\nobtained from the 3DCiM-LLM-Inference simulator, which models these effects. Under this accurate\nsimulation, our mappings consistently outperform ODiMO in both latency and energy.\nComment 6\nThe caption does not include any reference to subplot (c).\nDiscussion/Revision:\nAdded: “(c) Supernetwork training loss over epochs. ODiMO-QAT refers to the baseline ODiMO method\ntrained with quantization-aware training only, while ODiMO-HWA combines QAT with hardware-aware\ntraining, including analog noise injection and drift modeling. Both ODiMO variants operate at channel-\nwise precision granularity. In contrast, MPS employs layer-wise precision choices and progressive noise\nscaling. The results show that ODiMO-HWA suffers from unstable convergence under noise, highlighting\nthe need for a layer-wise approach that can robustly adapt to analog hardware constraints.”\nComment 1\nFor hardware performance, the most straightforward way is to report real metrics, such as\ninference time, power, energy efficiency, and chip area. In the reply, the authors mentioned\nthey did not evaluate specific chips to keep the method general, and instead used Analog MAC\nRatio and Digital Weight Size. I think this is not reasonable. This concern was already\nexplained in Comment 2 of the first review. The authors also admitted in the reply that these\ntwo indicators do not fully reflect hardware performance. Even if the framework is meant to be\ngeneral, I believe the authors still need to show results on a few typical hardware settings\nto prove that the framework is truly effective.\nDiscussion/Revision:\nWe thank the reviewer for raising this important point. In response to this concern, we have now added\nhardware-level latency and energy results obtained using a fixed heterogeneous AIMC architecture modeled\nin the open-source 3DCiM-LLM-Inference simulator. The corresponding results—summarized in Table I\nand detailed in the Supplementary Material—provide concrete latency (ms) and energy (µJ/sample) num-\nbers for all evaluated methods on the same hardware setting.\nComment 2\nFor task performance, from both Table II and the supplementary tables, we can see that compared\nwith the full-digital FP32 baseline, the task accuracy is improved when using MPAAS. However,\nthe number of model parameters also increases, sometimes a lot|especially for small networks.\nThis makes us wonder whether the accuracy gain really comes from the design of the framework,\nor simply from having a larger model. In the reply, the authors said \\more layers are able\nto run in analog which makes the full run more energy-efficient under our assumptions.\" But\nwe have already discussed that running more in analog does not always lead to better hardware\nperformance. So this assumption may not hold.\nDiscussion/Revision:\nWe thank the reviewer for this comment. We agree that parameter count can influence task accuracy,\nand we have carefully examined this aspect. The purpose of the hardware-aware adaptations in MPAAS is\nnot to increase model capacity arbitrarily, but to reshape specific layers so that they align with the fixed\ndimensions of analog tiles. This results in modest width expansions in a subset of intermediate layers,\nparticularly in small models where tile dimensions are relatively large. Importantly: - The parameter\nincrease is strictly constrained by hardware structure. - The accuracy improvements persist even without\nthese adaptations: when we compare MPS against state-of-the-art methods. - The energy/latency results\nvalidate the utility of these adapted layers. - Increased parameters occur mostly in small networks where\ntile granularity is coarse.\nReferences\n[1] Julian Bu¨chel, Athanasios Vasilopoulos, William Andrew Simon, Irem Boybat, HsinYu Tsai, Geof-\nfrey W Burr, Hernan Castro, Bill Filipiak, Manuel Le Gallo, Abbas Rahimi, et al. Efficient scaling of\nlarge language models with mixture of experts and 3d analog in-memory computing. Nature Compu-\ntational Science, 5(1):13–26, 2025.\n[2] M. Le Gallo, R. Khaddam-Aljameh, M. Stanisavljevic, A. Vasilopoulos, B. Kersting, M. Dazzi,\nG. Karunaratne, M. Br¨andli, A. Singh, S. M. Mu¨ller, et al. A 64-core mixed-signal in-memory\ncompute chip based on phase-change memory for deep neural network inference. Nature Electronics,\n6(9):680–693, 2023.\n6"}, {"round": 3, "reviewer_comments": {"reviewer_1": "The authors have addressed all my remarks. I have no further comments.", "reviewer_2": "I co-reviewed this manuscript with one of the reviewers who provided the listed reports. This is part of the Nature Communications initiative to facilitate training in peer review and to provide appropriate recognition for Early Career Researchers who co-review manuscripts.", "reviewer_3": "We are glad to see that the authors added hardware performance comparisons under the open-source hardware framework. The results show their method against other baselines. These hardware results, together with the software task performance, give clear evidence of the method’s effectiveness.\nWith these additions, I believe the manuscript meets the requirements for publication and can be accepted."}, "author_response": "Response to Reviewers for Manuscript ID: NCOMMS-25-17053A\nWe sincerely thank all reviewers for their careful evaluation of the manuscript and for their constructive\nfeedback, which helped improve the clarity and quality of this work.\nReviewer 1\nComment 1\nThe authors have addressed all my remarks. I have no further comments.\nDiscussion/Revision:\nWe thank the reviewer for their positive assessment and for taking the time to review our manuscript.\nReviewer 2\nComment 1\nI co-reviewed this manuscript with one of the reviewers who provided the listed reports. This\nis part of the Nature Communications initiative to facilitate training in peer review and to\nprovide appropriate recognition for Early Career Researchers who co-review manuscripts.\nDiscussion/Revision:\nWe acknowledge this statement and thank the reviewer for their contribution to the peer-review process.\nReviewer 3\nComment 1\nWe are glad to see that the authors added hardware performance comparisons under the open-\nsource hardware framework. The results show their method against other baselines. These\nhardware results, together with the software task performance, give clear evidence of the\nmethod’s effectiveness. With these additions, I believe the manuscript meets the requirements\nfor publication and can be accepted.\nWe thank the reviewer for their positive evaluation and for recognizing the added hardware performance\ncomparisons. We are pleased that these results clarify the effectiveness of our method.\n2"}]

Decision letter