Mobile Devices practice questions

Implement an asynchronous processing queue for all user requests

Why it fails: An asynchronous queue decouples request handling from processing; it provides no natural-language model, hosting, or assistant integration. It suits bursty, latency-tolerant workloads needing backpressure. The scenario demands a managed prebuilt conversational service, not a messaging pattern.

Train and deploy a custom model on an on-premises server

Why it fails: On-premises training and hosting demands GPU hardware, MLOps, and model maintenance the startup cannot staff, and delays integration. It is the right choice when data residency or strict control forbids third-party hosting. The stem instead requires minimal infrastructure management and fast delivery.

Deploy the model on edge devices for offline inference

Why it fails: Edge deployment requires exporting, optimising, and shipping models to devices, plus update and telemetry pipelines — heavy engineering for a team with no AI expertise. It is correct when offline inference and low latency are mandatory. Here connectivity and rapid managed integration are the priorities.

Use pruning to remove less important weights

Why it fails: Pruning removes weights, reducing capacity further; it does not restore the precision lost on the affected classes, so accuracy on those subsets stays degraded. It is tempting because pruning is a real compression technique, and it would be correct when the goal is shrinking an already-accurate model rather than recovering quantisation accuracy.

Increase the model architecture size

Why it fails: Enlarging the architecture increases parameter count and model size, contradicting the constraint, and does not target quantisation error. Bigger models help when underfitting. Quantisation-aware training simulates INT8 rounding during training so weights adapt, recovering accuracy at the same size.

Switch to FP16 quantization

Why it fails: FP16 doubles the bit-width of INT8, so the model's memory footprint and size grow, breaching the no-increase constraint. It is tempting because FP16 is a genuine post-training quantization format that recovers accuracy, and it would be the right choice when the target hardware supports half-precision and size is not restricted.

Distill the model into a smaller architecture without quantization or pruning

Why it fails: Distillation alone yields a smaller architecture but typically falls short of a guaranteed 50% reduction, and omitting pruning and quantization forfeits further compression. Distillation suits producing a compact student model when accuracy retention matters more than a hard size target.

Use FP32 precision and increase batch size

Why it fails: FP32 is full precision, so weights stay at four bytes each and no size reduction occurs; larger batches also raise activation memory. FP32 training suits servers with ample memory, where numerical fidelity matters more than footprint, not edge deployment.

Use FP16 quantization and add more layers

Why it fails: FP16 halves weight storage but adding layers increases parameter count and memory, so the 50% reduction is not achieved. FP16 alone suits GPU inference where memory is adequate; adding layers targets accuracy, not compression, and works against the stated constraint.

Increase batch size

Why it fails: Increasing batch size amortises weight loading across samples, improving throughput, yet a single mobile inference request still waits for the whole batch and per-request latency does not fall. It is tempting because batching speeds server-side processing, but that scenario involves high-volume offline or server inference, not one-at-a-time mobile prediction.

Add more layers

Why it fails: Adding layers increases parameter count and sequential computation, raising inference latency further on constrained mobile hardware. It is tempting because extra depth can improve accuracy on complex tasks, but that is a training-capacity concern, not a latency-reduction one; pruning or quantisation shrinks the existing network instead.

Use a larger model

Why it fails: A larger model multiplies weights and floating-point operations, so each forward pass takes longer and consumes more memory than the current network. It is tempting because bigger architectures raise accuracy on difficult datasets, but that is a modelling-quality goal; the stem demands lower inference time on limited mobile resources.

Use FP32 precision

Why it fails: Using FP32 precision requires 32-bit floating-point arithmetic, which demands significantly higher memory bandwidth and computational throughput than lower-precision formats. On resource-constrained edge devices with minimal power budgets, this precision level directly increases energy consumption and may exceed available RAM or processor capabilities, making real-time inference infeasible. It is tempting because FP32 offers maximum numerical accuracy and is the default for training models, so developers often assume it preserves model fidelity. In a cloud-based deployment with ample power and cooling, FP32 would be the correct choice to avoid any accuracy degradation from quantisation.

Increase the number of layers

Why it fails: Adding layers increases parameters, computation and memory, directly raising power consumption and latency on constrained devices. It is tempting because deeper networks can improve accuracy, but that suits powerful servers, not edge hardware where the goal is reducing model size and energy use.

Use a larger batch size

Why it fails: Larger batches raise peak memory and buffer requirements, worsening latency and power draw on constrained edge devices. It is tempting because large batches improve throughput on datacentre GPUs, but that scenario targets server-side inference, not battery-powered sensors needing per-sample, low-power execution.

Use a high-core-count CPU with large RAM

Why it fails: CPUs execute transformer matrix multiplications serially across few vector units, so training time barely improves regardless of core count or RAM. High-core CPUs suit data preprocessing, feature engineering or small classical models, not the massively parallel tensor operations a large transformer requires.

Use a single GPU with model parallelism

Why it fails: Model parallelism on a single GPU fails to reduce training time because it partitions the model across the device’s own memory, introducing sequential computation and communication overhead that does not scale throughput. It is tempting because it enables fitting a transformer that exceeds a single GPU’s VRAM, but the correct approach for speed is data parallelism across multiple GPUs, which processes distinct micro-batches concurrently.

Use a single TPU with model parallelism

Why it fails: A single TPU cannot hold a large transformer's parameters and optimiser states, so model parallelism across one device yields no throughput gain. TPUs excel when sharded across many chips via data and model parallelism together, which is the configuration this scenario actually demands.

Model pruning

Why it fails: Model pruning removes redundant weights to shrink the network and speed inference; it operates on learned parameters, leaving training data and outputs untouched, so no privacy guarantee is added. Pruning suits deployment efficiency on constrained hardware, not privacy-preserving machine learning.

Data augmentation

Why it fails: Data augmentation generates additional synthetic training samples to improve generalisation; it neither encrypts, perturbs nor anonymises the underlying transaction data, so raw records remain exposed. It belongs in model accuracy and class-imbalance work, not privacy preservation.

Apply model distillation to create a smaller student model

Why it fails: Model distillation reduces model size but still requires a neural network inference pipeline, which on severely resource-constrained IoT devices may exceed available compute cycles and battery budget; the scenario demands a model that runs locally with minimal latency, and distillation alone does not guarantee the student model meets the strict memory or energy limits of the hardware. This technique is tempting because it is a standard approach for deploying deep learning on edge devices when the target platform has moderate resources, such as a smartphone or a Raspberry Pi, where a distilled model can achieve acceptable speed and accuracy trade-offs.

Deploy the model on a cloud server and stream data

Why it fails: Cloud deployment introduces network latency and requires constant connectivity, unsuitable for real-time patient monitoring on IoT devices.

Use ONNX Runtime with a GPU backend

Why it fails: ONNX Runtime with GPU backend is designed for server-class hardware, not for low-power IoT devices.

Differential privacy

Why it fails: Differential privacy adds calibrated noise to outputs or gradients, but training still requires data or updates to reach a central aggregator, so raw records leave the source. It suits publishing statistics or query results with formal privacy guarantees, not keeping training data on-device.

Data minimisation

Why it fails: Data minimisation reduces how much personal data is collected or retained, yet the remaining records must still be transferred to the training server. It suits limiting collection scope under privacy principles, not enabling local training where raw data never leaves its origin.

Anonymisation

Why it fails: Anonymisation strips or masks identifiers before processing, so the raw records still leave each site for central training; it cannot keep data local. It suits publishing or sharing datasets where re-identification risk is acceptable, not federated training that never moves raw data.

Use FP16 inference and deploy via Docker containers

Why it fails: FP16 reduces precision but not as aggressively as INT8; Docker adds overhead and requires an OS, which may be too heavy for IoT devices.

Use model distillation to create a smaller model and deploy via ONNX Runtime

Why it fails: Distillation can create a smaller model, but ONNX Runtime may not be as lightweight as TensorFlow Lite for specific IoT hardware.

Deploy on a GPU-based edge server with a full PyTorch model

Why it fails: GPUs may not be available on low-power IoT cameras; the full model is too large and consumes too much power.

Perform additional feature engineering

Why it fails: Feature engineering alters input representation, not the model's parameter count or arithmetic, so inference cost on constrained hardware is unchanged. It is tempting because better features can let a smaller model reach the same accuracy, but that requires retraining a new model; the question asks for an optimisation technique applied to the existing model.

Use an ensemble of models

Why it fails: Ensembling combines multiple models' predictions, multiplying memory footprint and inference latency, which directly worsens the constraint. It is tempting because ensembles raise accuracy, and would be correct where compute is plentiful and accuracy is the priority, but edge devices with limited resources cannot absorb the added cost.

Increase the training dataset size

Why it fails: Adding training data changes neither the model's architecture nor its inference cost, so runtime resource consumption on the device is untouched. It is tempting because more data often improves generalisation, and would be right when accuracy is limited by data volume, but the scenario constrains computation, not training-set adequacy.

Model parallelism and distributed inference

Why it fails: Model parallelism splits one model across multiple devices and distributed inference spreads requests across a cluster, both targeting throughput and large-model capacity, not single-device latency or footprint. They suit data-centre serving of models too large for one accelerator, whereas this scenario needs compression and quantisation on one constrained device.

Increase batch size and use FP16 precision

Why it fails: Larger batches raise throughput but increase per-request latency, and FP16 halves weight size without shrinking the architecture enough to meet 50MB. Batching and half precision belong in server-side throughput tuning; the edge constraint demands pruning, distillation or quantisation to cut parameters and memory.

Train a larger model and use distillation to transfer knowledge

Why it fails: Distillation compresses a trained model, but the stem demands under 10ms inference within 50MB; distillation alone does not guarantee that footprint or latency, since the student model's size and speed depend on architecture choices. It is tempting because distillation genuinely transfers knowledge from a large teacher to a smaller student, and would be correct when accuracy must be preserved while shrinking an already-trained model.

Use a larger batch size during inference

Why it fails: Batching raises peak memory and does not reduce per-inference latency on a single edge request; it improves throughput on server GPUs where requests queue. Edge real-time inference processes one sample at a time, so quantisation or pruning shrinks the model itself. Larger batches also add buffering delay.

Train the model for more epochs to improve convergence

Why it fails: Extra epochs alter training convergence only; the deployed model's parameter count, memory footprint and inference latency stay identical. Longer training suits improving accuracy when underfitting, not meeting edge resource limits. The stem asks for optimisation of the deployed artefact, so quantisation or pruning applies.

Increase the number of layers to improve feature extraction

Why it fails: Adding layers increases parameter count, memory footprint and inference latency, directly worsening the edge constraints. Depth is chosen when accuracy on complex features is the priority and compute is plentiful, such as server-side training. The scenario demands pruning, quantisation or distillation instead.

Switching the training optimizer from SGD to AdamW

Why it fails: The optimizer affects how weights are updated during training and can influence convergence speed and final accuracy, but it does not change the deployed model's size, memory footprint, or inference cost. Once training finishes, the optimizer state is discarded. Changing optimizers therefore does nothing to help the model fit on battery-powered cameras with limited RAM.

Training with a larger batch size on the same dataset

Why it fails: Batch size influences gradient noise and training throughput, not the architecture or numerical precision of the exported model. A model trained with a larger batch has essentially the same parameter count and inference cost as one trained with a smaller batch. It does not reduce memory footprint or energy use on the cameras and is irrelevant to the deployment constraint.

Increasing the number of convolutional filters in each layer

Why it fails: Adding filters increases the parameter count and the number of multiply-accumulate operations, which raises memory use and inference energy rather than reducing them. This direction improves representational capacity, which might raise accuracy, but it directly conflicts with the goal of shrinking the model for low-power cameras. It is the opposite of what constrained deployment requires.

Increase the IoT Hub tier to S3 and enable message routing to a Service Bus queue to guarantee delivery during outages.

Why it fails: Scaling the IoT Hub tier improves throughput and message retention in the cloud, but it does nothing for a device that has lost its network link. The device cannot reach IoT Hub during an outage regardless of tier, so routing rules never trigger. This option addresses cloud-side capacity rather than local resilience, leaving the edge device unable to run or report during connectivity loss.

Deploy the model to an Azure Kubernetes Service cluster in the cloud and expose it through a private endpoint to each warehouse.

Why it fails: Azure Kubernetes Service is a cloud-hosted orchestrator, so inference still depends on network connectivity from the warehouse to the cluster. A private endpoint improves security but does not provide local compute during an outage. This option moves inference away from the edge, directly conflicting with the requirement that detection continue when the warehouse loses connectivity.

Configure the model to call the Azure Machine Learning online endpoint for every frame and cache the responses on the device.

Why it fails: Calling a cloud endpoint per frame requires continuous connectivity and introduces latency that is unacceptable on a fast-moving conveyor belt. Caching responses cannot help when the network is down because the initial call will fail. This design contradicts the requirement to operate during outages, so it is not a valid approach for the edge deployment.

The edge devices have less RAM and slower CPUs than the cloud inference servers used during evaluation.

Why it fails: Hardware differences affect latency and throughput, not the mathematical result of a forward pass, as long as the same numeric format is used. Slower processors do not silently change class probabilities. Since the question describes a consistent accuracy difference rather than timeouts or dropped frames, resource constraints are not the explanation.

The test images were captured with a different camera model than the ones mounted on the conveyor belts.

Why it fails: A camera mismatch would also hurt accuracy, but it would affect cloud evaluation equally if the same test images were used in both environments, so it cannot explain a gap between cloud and edge results on identical inputs. Domain shift is a real concern, yet it does not produce an environment-specific delta; it produces a uniform drop everywhere the model runs.

The cloud evaluation used a batch size of 32 while the edge device processes one image at a time.

Why it fails: Batch size changes how inputs are grouped during inference but each sample's forward computation is independent, so predictions for a given image are essentially unchanged apart from floating-point summation order. It cannot account for a several-point accuracy drop. Batch size matters for throughput and memory, not for the classification quality of individual packages.

Data augmentation

Why it fails: Data augmentation synthesises extra training samples to improve generalisation and class balance; it neither anonymises records nor adds noise to outputs. It suits boosting model accuracy on scarce datasets, not meeting privacy regulations, which require techniques such as differential privacy or federated learning.

Model quantization

Why it fails: Quantization compresses weights to lower-precision formats, reducing model size and inference latency; it does not obscure patient data or prevent memorisation. It suits deployment on resource-constrained hardware, whereas privacy preservation requires mechanisms like differential privacy or secure multi-party computation.

Dropout regularization

Why it fails: Dropout randomly deactivates neurons during training to curb overfitting; it provides no formal privacy guarantee and leaves patient data exposed in training sets and outputs. It suits improving generalisation, not regulatory compliance, which needs differential privacy or data anonymisation instead.

Apply weight pruning to remove 50% of parameters

Why it fails: Pruning reduces model size but may not yield 4x latency improvement; speedup depends on sparsity support.

Switch from TensorFlow Lite to Core ML

Why it fails: Changing runtime helps but does not reduce model computation; quantization is more impactful.

Distill the model into a smaller architecture

Why it fails: Distillation can reduce size but may require retraining and may not achieve the exact speedup.