The increasing size and complexity of modern deep neural networks (DNNs) pose significant challenges for on-device inference on mobile GPUs, with limited memory and computational resources. Existing DNN acceleration frameworks primarily deploy a weight preloading strategy, where all model parameters are loaded into memory before execution on mobile GPUs. We posit that this approach is not adequate for modern DNN workloads that comprise very large model(s) and possibly execution of several distinct models in succession. In this work, we introduce FlashMem, a memory streaming framework designed to efficiently execute large-scale modern DNNs and multi-DNN workloads while minimizing memory consumption and reducing inference latency. Instead of fully preloading weights, FlashMem statically determines model loading schedules and dynamically streams them on demand, leveraging 2.5D texture memory to minimize data transformations and improve execution efficiency. Experimental results on 11 models demonstrate that FlashMem achieves 2.0x to 8.4x memory reduction and 1.7x to 75.0x speedup compared to existing frameworks, enabling efficient execution of large-scale models and multi-DNN support on resource-constrained mobile GPUs.
Figures & tables
Model
# Parameters (M)
Memory (MB)
Latency (ms)
Peak
Avg.
Load
Trans.
Infer
Whisper ( Radford et al., 2023 )
356
4,077
1,650
2,702
3,441
1,343
GPTNeo ( Black et al., 2021 )
164
1,026
610
631
2,898
337
SD-UNet ( Rombach et al., 2021 )
860
4,858
1,800
4,159
17,588
1,647
Table 1. Memory usage and latency of various models on the OnePlus 12. “Avg.” indicates average memory consumption; “Trans.” represents data transformation latency.
Figure 1. Left (a) shows the hierarchical memory structure and bandwidth on mobile GPUs, highlighting the multi-step weight transfer path from disk to streaming multiprocessors. Right (b and c) depicts two multi-DNN support strategies.
Figure 2. Latency increase (ms) across different operators on mobile GPUs due to additional data transformations. The X-axis shows the ratio of additional data loaded compared to the original kernel input (e.g., 1.0 indicates an equal amount of extra data is streamed alongside computation). Threshold markers show where latency overhead reaches 20% and 30% of the original kernel.
Symbol
Description
W
Weights to preload
zw
Earliest layer loading w to unified memory
xw,ℓ
Chunks of w transformed at layer ℓ
iw
Layer index consuming weight w
Cℓ
Load Capacity (max load at layer ℓ )
Mpeak
Peak memory limit for transformations
Table 2. Summary of the key notations and symbols.
Feature
Google CP-SAT
Our LC-OPG Solver
Memory Constraints
Static limits
A.P.M.C.
Load Capacity Awareness
Not included
P.L.D.S.
Solver Convergence
May fail
Fallback mechanism
Objective Function
Generic
Balances M.O.C.
Table 3. Comparison of Google CP-SAT and Our LC-OPG Solver: “A.P.M.C.” for Adaptive Peak Memory Control, “P.L.D.S.” for Per-Layer Dynamic Scheduling, and “M.O.C.” for Memory, Overlap, and Compute Load.
Model
Process
Build CP-SAT
Solve
Solver
nodes (s)
model (s)
model (s)
Status
GPTN-S
0.010
0.260
45.00
OPTIMAL
GPTN-1.3B
0.020
1.170
121.00
FEASIBLE
GPTN-2.7B
0.050
1.980
121.00
FEASIBLE
ViT-8B
0.001
4.110
121.40
FEASIBLE
Llama2-13B
0.007
3.566
124.80
FEASIBLE
Table 4. Execution time breakdown for the evaluated models (constrained by a 150-second solver limit).
Figure 3. Overview of FlashMem .
Operator Type
M.B.
L.C. Tolerance
C.I.
Elemental ( ReLU , Add )
Low
Medium
Low
Reusable ( Conv , MatMul )
Medium
High
High
Hierarchical ( LayerNorm )
High
Low
Medium
Table 5. Operator classification and load capacity characteristics for representative operators: “M.B.” indicates memory bandwidth, “L.C.” denotes load capacity, and “C.I.” represents computational intensity.
Figure 4. Profiling operators from more than ten models. We systematically adjust key parameters in our framework to measure kernel latency changes. The collected data is then used to train our XGBoost-based regression model for accurate latency prediction. Global Work Size (GWS) and Local Work Size (LWS) determine workload distribution and thread partition, respectively.
Model
Abbr.
Input Type
Model Task
# Params (M)
# MACs (G)
# Layers
GPTNeo-Small ( Black et al., 2021 )
GPTN-S
Text
NLP
164
16
606
GPTNeo-1.3B ( Black et al., 2021 )
GPTN-1.3B
Text
NLP
1,419
170
1,110
GPTNeo-2.7B ( Black et al., 2021 )
GPTN-2.7B
Text
NLP
2,781
342
1,446
ResNet50 ( He et al., 2016 )
ResNet
Image
Classification
25.6
4.1
141
SegmentationAnything-2 ( Ravi et al., 2024 )
SAM-2
Image
Segmentation
215
218
1,668
ViT ( Dosovitskiy et al., 2021 )
ViT
Image
Classification
103
21
819
Table 6. Model characterization for evaluated models across different input types and tasks. “Abbr.” is used to refer to each model in Evaluation sections. “# MACs” represents the number of multiply-accumulate operations. “# Layers” refers to the number of low-level operator nodes (e.g., MatMul , Activation ) after graph lowering, instead of the high-level model blocks.
Figure 5. Comparison of a naive Matrix Multiplication kernel with the rewritten kernel integrated with weight loading.
Model
MNN (ms)
NCNN (ms)
TVM (ms)
LiteRT (ms)
ETorch (ms)
SMem (ms)
Ours (ms)
Speedup †
Speedup ‡
Init
Exec
Init
Exec
Init
Exec
Init
Exec
Init
Exec
Init
Exec
Integrated
GPTN-S
3,529
337
–
–
5,832
621
–
–
277
5,869
4,757
59
577
8.4 ×
9.3 ×
GPTN-1.3B
–
–
–
–
–
–
–
–
5,178
515,291
48,109
501
3,086
15.8 ×
169 ×
GPTN-2.7B
–
–
–
–
–
–
–
–
–
–
–
–
7,567
–
–
ResNet50
1,751
22
1,341
28
524
56
573
34
65
10,302
1,470
33
473
3.2 ×
3.3 ×
SAM-2
–
–
–
–
–
–
–
–
1,178
857,752
9,983
826
1,267
8.5 ×
678 ×
Table 7. Overall latency consumption comparison. “–” means the model is not supported. Speedup refers to the latency ( Init + Exec ) of other frameworks over FlashMem ( Integrated ). Since FlashMem considers the initialization and execution as a whole, we only report integrated latency. Solver is running offline, which is not included here.
Model
Average Memory (MB)
Mem-
MNN
NCNN
TVM
LiteRT
ETorch
SMem
Ours
ReDT
GPTN-S
610
–
2,300
–
702
541
260
2.1 ×
GPTN-1.3B
–
–
–
–
2,600
2,667
554
4.8 ×
GPTN-2.7B
–
–
–
–
–
–
1,132
–
ResNet50
149
165
789
331
129
140
83
1.7 ×
SAM-2
–
–
–
–
–
896
150
6.0 ×
Table 8. Overall memory consumption comparison. “–” means the model is not supported. “Mem-ReDT” refers to the memory reduction over SmartMem.
Figure 6. Multi-model supports on FlashMem (a) and MNN (b), each model runs for 10 iterations interleaved.
Figure 7. Performance breakdown analysis: speedup (a) and memory reduction (b) over baseline (SmartMem).
Figure 8. Trade-off between memory usage and inference latency across different models, showing integrated latency (a) and execution latency (b). As more weights are preloaded before inference, we will have a lower execution latency. However, initialization latency becomes the dominant factor of the integrated latency, which introduces higher total latency.
Figure 9. Latency comparison among Ours ( FlashMem ), Same-Op-Type Prefetching (SameNext), and Always-Next Loading.
Model
Power Consumption
Energy Consumption
DeepViT
SD-UNet
DeepViT
SD-UNet
MNN
6.3W
4.8W
33.1J
95.2J
LiteRT
6.4W
–
51.3J
–
ETorch
3.6W
–
130.5J
–
SmartMem
5.2W
4.5W
41.0J
134.5J
Ours
5.7W
5.6W
4.5J
17.9J
Table 9. Comparison of average power and energy consumption: energy is calculated by multiplying the average power by the latency of each iteration. Power was measured by reading the system power usage over time.
Figure 10. Comparison of memory usage and latency across three devices using SmartMem versus FlashMem . Empty bars indicate the device ran out of memory during initialization.
Deploying large deep neural networks on memory-constrained mobile devices is a central challenge in edge ML. While compression, pruning, and quantization reduce per-parameter cost, transformer-based models remain too large for the 3.3-7.4 GB RAM envelope of commodity Android handsets. We present the DNN pipeline scheduling subsystem of CROWDio, which achieves practical ONNX inference across resource-constrained Android workers without model modification, by distributing memory pressure across devices via five mechanisms: JIT deferred partition loading, a single-partition-resident constraint, a 4-tier affinity scheduler, a zlib-compressed tensor transport, and a streaming 1:1 dependency model. Evaluated on DistilBERT (Sanh et al., 2019) (approximately 67 M parameters, SST-2) across five Android handsets over ten runs, our system holds peak per-device RSS to 43+-2 MB and limits battery draw to 50+-3 mAh per run, while streaming concurrency cuts batch latency 34% below barrier synchronisation.
Standard mixed-precision training of neural networks requires many bytes of accelerator memory for each model parameter. These bytes reflect not just the parameter itself, but also its gradient and one or more optimizer state variables. With each of these values typically requiring 4 bytes, training even a 7 billion parameter model can be impractical for researchers with less than 100GB of accelerator memory. We introduce FlashOptim, a suite of optimizations that reduces per-parameter memory by over 50% while preserving model quality and API compatibility. Our approach introduces two key techniques. First, we improve master weight splitting by finding and exploiting a tight bound on its quantization error. Second, we design companding functions that greatly reduce the error in 8-bit optimizer state quantization. Together with 16-bit gradients, these techniques reduce AdamW memory from 16 bytes to 7 bytes per parameter, or 5 bytes with gradient release. They also cut model checkpoint sizes by more than half. Experiments with FlashOptim applied to SGD, AdamW, and Lion show no measurable quality degradation on any task from a collection of standard vision and language benchmarks, including Llama-3.1-8B finetuning.
Jose Javier Gonzalez Ortiz, Abhay Gupta, Christopher Rinard +1
On-device mobile Large Language Model (LLM) inference is gaining significant attention. However, mobile devices operate in highly dynamic multitasking environments where users frequently switch between applications. This creates memory pressure, forcing LLM memory (model weights and KV cache) to be evicted by the operating system. When a new inference request arrives, the inference system must restore the evicted memory through slow storage reads or recompute the entire KV cache, severely degrading responsiveness. To address this, we present mzCache, an on-device LLM inference system with specialized memory management for multitasking environments. Under unpredictable memory pressure, mzCache elastically evicts LLM memory and leverages the unified memory of mobile SoCs to enable zero-wait inference on the GPU with concurrent CPU-side restoration. mzCache realizes this through restoration-oriented memory management: LLM memory is partitioned into fine-grained shared buffers to enable partial eviction and restoration with concurrent cross-processor access, while hybrid swap and backward-out eviction policies ensure low-latency restoration from any eviction state. Implemented on llama.cpp and deployed as an Android application, mzCache achieves 2.1-5.5× reduction in Time-to-First-Token compared to storage-backed partial offload and demonstrates its effectiveness in real multitasking scenarios.