Papers
Topics
Authors
Recent
Search
2000 character limit reached

Efficient On-Device Diffusion LLM Inference with Mobile NPU

Published 11 Jun 2026 in cs.LG | (2606.13740v1)

Abstract: Diffusion LLMs (dLLMs) accelerate generation by denoising multiple tokens in parallel, making them attractive for latency-sensitive mobile inference. However, repeated denoising introduces substantial computation on smartphones. Mobile neural processing units (NPUs) offer high-throughput dense matrix computation, but efficiently exploiting them remains challenging: token commitment shrinks per-block effective workloads, token revision complicates KV cache reuse, and limited NPU-visible address space incurs costly remapping and data transfer overheads. In this paper, we propose llada.cpp, the first NPU-aware inference framework for accelerating dLLMs on smartphones. llada.cpp aligns block-wise dLLM inference with the execution characteristics of mobile NPUs through three techniques. (1) Multi-Block Speculative Decoding fills the shrinking workload in late-stage current-block decoding with speculative future-block tokens. (2) Dual-Path Progressive Revision keeps committed tokens revisable until stable and refreshes unstable tokens through a CPU-side path without stalling dense NPU execution. (3) Swap-Optimized Memory Runtime compacts NPU-visible address layouts and overlaps data staging with NPU computation to reduce remapping and transfer overheads. We implement llada.cpp as an end-to-end framework and evaluate it across diverse hardware platforms and dLLM workloads. llada.cpp reduces LLaDA-8B generation latency by 17x-42x over the CPU baseline with prefix KV cache reuse, while preserving generation quality.

Authors (3)

Summary

  • The paper introduces a framework that leverages multi-block speculative decoding to amortize NPU overhead and reduce latency by 17x–42x compared to CPU baselines.
  • It implements dual-path progressive revision by offloading irregular updates to CPU kernels, ensuring maintained quality while skipping redundant projections.
  • The framework uses a swap-optimized memory runtime to manage buffers dynamically, enabling efficient token processing on memory-constrained mobile NPUs.

Efficient NPU-Aware Diffusion LLM Inference for Mobile Devices

Introduction

The paper "Efficient On-Device Diffusion LLM Inference with Mobile NPU" (2606.13740) systematically tackles the problem of high-latency text generation using diffusion LLMs (dLLMs) on smartphones. While dLLMs enable parallel generation by denoising multiple tokens simultaneously, their iterative nature incurs substantial computational overhead, posing difficulties for mobile platforms limited by memory, bandwidth, and power. The work identifies a critical mismatch between dLLM inference patterns—characterized by dynamic token masking, revision, and variable computation workloads—and the static, regular execution model of modern mobile neural processing units (NPUs). The authors introduce LLADA.CPP, an inference framework that explicitly aligns dLLM decoding with the parallelism and memory semantics available in mobile NPUs, realizing substantial performance improvements for on-device LLM usage.

Technical Contributions of LLADA.CPP

LLADA.CPP embodies three main algorithm-system co-design innovations:

1. Multi-Block Speculative Decoding: Traditional block-wise dLLM decoding suffers from declining hardware utilization in late-stage denoising as uncertain token positions become scarce, leading to short, sub-optimal NPU workloads. LLADA.CPP introduces a speculative execution window that proactively includes tokens from future output blocks during current NPU forward passes. These speculative tokens are used as draft candidates—they neither influence prefix KV cache updates nor affect final commitment order until their proper turn—thereby preserving correctness while amortizing NPU execution overhead across larger batches. The runtime adaptively expands this window based on device-specific latency profiles and remaining masked token thresholds, maximizing throughput without exceeding hardware or memory constraints.

2. Dual-Path Progressive Revision: dLLM block-wise decoding creates the need for both frequent token revision (to guarantee generation quality) and efficient cache reuse. LLADA.CPP implements a three-state token lifecycle (invisible, visible, stable), leveraging two confidence thresholds to incrementally promote tokens. When prefix KV states become revisable but require irregular, sparse updates, LLADA.CPP offloads these to CPU-side, specialized matrix kernels that directly operate on NPU-tiling layouts. This division exploits the NPU’s strength in dense matrix compute and the CPU’s flexibility for sparse updates, avoiding stalling or contention. Delayed merging at denoising step boundaries prevents excessive synchonization cost. Redundant output projection and sampling logic for already-stable tokens is skipped entirely, further accelerating inference.

3. Swap-Optimized Memory Runtime: Mobile NPUs have restrictive device-visible address space with tight allocation and mapping requirements. LLADA.CPP constructs a graph-guided buffer management and staging system: long-lived tensors (weights, KV cache) are prioritized for residency while short-lived or demoted data are staged via pipelined, double-buffered transfer overlap. Tensors are packed in virtual address space based on operator scheduling and live range analysis, minimizing fragmentation and remapping events. By pipelining data transfer and operator execution, LLADA.CPP hides unavoidable latency, thereby keeping buffer management off the critical path even under memory pressure or long-context outputs.

Empirical Evaluation

Comprehensive experiments were conducted on three generations of Qualcomm Snapdragon smartphones, leveraging LLaDA-8B-Instruct and Dream-7B as primary dLLM workloads, both with low-bit quantization for memory efficiency. Tasks included GSM8K, BoolQ, ARC-C, and HellaSwag, with quality measured in token-level accuracy, while performance was tracked via end-to-end latency, power, and energy consumption.

Latency and Quality

  • LLADA.CPP achieves 17x-42x generation latency reduction for LLaDA-8B over an optimized CPU baseline (with prefix KV cache reuse) across diverse datasets and devices, with no material degradation in output quality.
  • Speedup over autoregressive Llama-3-8B-Instruct is up to 3.9x on recent NPUs, directly highlighting the advantage of sequence-parallel denoising when mapped properly to NPU workloads.
  • Ablation studies isolate the effects of speculative decoding and dual-path revision. Speculative decoding alone may modestly decrease quality due to draft token uncertainty, but the dual-path mechanism recovers quality by maintaining revisable context and selective refresh.
  • Token-level skipping for logits projection further brings an average 10%+ latency reduction, especially on longer outputs.

Memory and Energy Efficiency

  • Without swap-optimized memory runtime, NPU-based systems fail to run large microbatches (e.g., 256/512 tokens), stressing the necessity of tight buffer management.
  • The framework remains operational at the memory boundary by combining graph-guided mapping and pipelined staging, whereas naive approaches fail due to mapping overflows.
  • In energy measurements, LLADA.CPP consistently lowers both instantaneous power and total energy-per-request compared to CPU-only or naive NPU offloads—demonstrating that effective NPU utilization is a function of adequate workload parallelism.

Implications and Future Outlook

This work demonstrates that on-device dLLM inference can achieve latency parity or superiority over autoregressive LLMs on modern mobile hardware, provided careful co-design with NPU execution semantics. The findings directly challenge the conventional wisdom that parallel denoising is prohibitively expensive for resource-constrained devices. With robust buffer management and speculative decoding aligned to hardware topologies, mobile LLM applications—including personal assistants, multimodal dialogue, and offline task automation—stand to benefit in interactivity, privacy, and accessibility.

In the medium term, LLADA.CPP’s principal methods (windowed speculative scheduling, decoupled sparse-dense compute, runtime-guided staging) are likely extensible to other high-parallelism networks such as Vision Transformers or multimodal diffusion models designed for local inference. As NPUs scale in capability and memory, the balance between on-device and cloud LLM deployment models may shift further toward ubiquitous, privacy-preserving edge AI.

Conclusion

LLADA.CPP operationalizes the core idea that non-autoregressive diffusion decoding, when meticulously engineered for mobile NPU architectures, offers a competitive and practical approach for on-device LLM inference (2606.13740). Through multi-block speculative decoding, dual-path progressive revision, and swap-optimized memory management, the framework translates sequence-level parallelism into significant latency, memory, and energy advantages without compromising generation quality. This advances the feasibility of interactive, secure, and efficient LLM applications on mobile and embedded devices, and provides a template for further system-algorithm co-design in neural inference at the edge.

Paper to Video (Beta)

No one has generated a video about this paper yet.

Whiteboard

No one has generated a whiteboard explanation for this paper yet.

Explain it Like I'm 14

What is this paper about?

This paper looks at how to make a new kind of LLM run fast on smartphones. These models, called diffusion LLMs (dLLMs), don’t write one word at a time like most chatbots. Instead, they start with a rough, “noisy” version of the whole sentence and clean it up step by step, fixing many words in parallel. That’s great for speed, but it still takes a lot of computing power. The authors created a system called llada.cpp that uses the phone’s special AI chip (the NPU) to do this cleaning much more efficiently, so replies come quicker without using too much battery or lowering quality.

What questions did the researchers ask?

In simple terms, they asked:

  • Can we make diffusion-style LLMs run fast enough on phones to be useful for real-time tasks?
  • How can we best use a phone’s NPU (a chip designed for fast math on big grids of numbers) to speed up this kind of model?
  • What new tricks are needed to handle the parts that don’t fit well on the NPU, like constantly revising words or juggling memory?

How did they study it?

First, some quick background in everyday language:

  • Tokens: Think of tokens as the “words” or pieces of words the model uses.
  • Denoising: Imagine you have a blurry sentence. The model “cleans” many parts at once, several times, until the sentence becomes clear.
  • Blocks: The model splits a long sentence into smaller chunks (like pages in a book) to make the process easier and reuse past work.
  • KV cache: This is like keeping notes about the parts you’ve already figured out, so the model doesn’t have to re-think everything from scratch.
  • NPU: A phone’s Neural Processing Unit is a special engine that’s very good at doing the same kind of math over and over on big tables of numbers. It’s fast and power-efficient, but it works best when the job is regular and doesn’t change shape a lot.

The authors found three big issues when trying to run dLLMs on the NPU:

  1. As a block gets cleaned, fewer words remain messy, so the NPU has less to do and becomes underused.
  2. Some “finished” words still need revision later, which makes reusing the KV cache tricky.
  3. The NPU can only “see” a limited slice of memory at once, so moving data in and out costs time.

To solve these, llada.cpp combines three techniques. Here is a short, plain-language summary:

  • Multi-Block Speculative Decoding: When a current block is almost clean (and the NPU would be idle), the system brings in some future words from the next block for “practice cleaning.” It doesn’t finalise them yet; it just gets a head start so the NPU stays busy and productive.
  • Dual-Path Progressive Revision: Words that look good but might still change are kept “revisable.” The heavy, regular math stays on the NPU, while small, scattered fixes (like updating a few words and their notes) happen on the CPU. This split keeps the NPU speeding through the big jobs and lets the CPU handle the fiddly edits.
  • Swap-Optimized Memory Runtime: Think of the NPU’s memory like a small workbench. The system carefully packs tools and parts, reuses space, and preloads the next items while the NPU is busy, so swapping things in and out wastes less time.

What did they find and why does it matter?

The main results:

  • Big speedups: On several smartphones, llada.cpp made the diffusion model (LLaDA-8B) respond 17× to 42× faster than a CPU-only version that reuses some past work.
  • Better than normal (autoregressive) models in many cases: On newer phones with stronger NPUs, llada.cpp made the diffusion model up to 3.9× faster than a similarly sized standard model that writes one word at a time.
  • Quality preserved: Even with the extra tricks (speculative decoding and progressive revision), the system kept answers accurate by revising uncertain words and carefully managing the cache.

Why it matters: Faster responses mean better user experiences for on-device assistants, games, study tools, and accessibility apps—without needing cloud servers. Doing it efficiently on the NPU also helps with battery life and makes real-time features more practical.

What’s the bigger impact?

This work shows that diffusion-style generation, which fixes many words in parallel, fits the strengths of phone NPUs very well. By designing the software around the hardware—keeping the NPU busy with big, regular math and letting the CPU handle small, irregular fixes—smartphones can run powerful LLMs quickly and locally. That could lead to:

  • More private, on-device AI (no need to send data to the cloud)
  • Faster and more interactive apps (voice assistants, tutoring, and multimodal tools)
  • Better use of the hardware people already have in their pockets

In short, llada.cpp is a practical step toward making advanced AI feel fast and responsive on everyday phones.

Knowledge Gaps

Knowledge gaps, limitations, and open questions

The paper proposes llada.cpp for NPU‑aware dLLM inference on smartphones and demonstrates substantial speedups on selected devices and models. The following concrete gaps and open questions remain for future work:

  • Hardware portability: Only Qualcomm Hexagon NPUs are evaluated; it is unclear how the approach transfers to other NPUs (e.g., MediaTek APU, Samsung NPU, Apple ANE) with different tile sizes, memory layouts, compilers, and VA models.
  • GPU baseline omission: The study lacks a mobile GPU offloading baseline, leaving the relative merits of NPU vs. GPU (or combined NPU+GPU) for dLLM inference unquantified.
  • FlashAttention support gaps: On SM8850, FlashAttention falls back to CPU; the performance/energy impact, mitigation strategies, and generalization to devices without NPU-side attention kernels are not addressed.
  • Scalability to larger models and contexts: Experiments are limited to 7–8B models and ≤128 generated tokens; behavior for larger models (e.g., 30B–70B) and long contexts (e.g., ≥4k–32k tokens) under tight NPU VA constraints is unexplored.
  • Generality across dLLM architectures: Results cover LLaDA-8B and Dream-7B; applicability to broader diffusion-style LLMs (e.g., different noise schedules, mask/commit rules, hybrid non‑AR methods) is not established.
  • Quality–latency trade-offs beyond small sets: Accuracy is reported on 200-sample subsets at temperature 0; broader benchmarks, diverse tasks/languages, varied temperatures, and human-eval metrics (e.g., coherence, factuality) are not studied.
  • Block size and step schedule sensitivity: The block size (32) and denoising steps (set equal to target tokens) are fixed; the impact of alternative block sizes, step counts, and adaptive schedules on NPU utilization, latency, and quality is not quantified.
  • Policy robustness for speculative decoding: Multi-Block Speculative Decoding relies on an offline‑profiled latency table and a late‑stage threshold; how to auto‑tune or adapt these policies online across datasets, firmware updates, and workload shifts is not discussed.
  • Threshold selection for staged stabilization: Visibility/stability thresholds (0.7/0.9) are fixed; the sensitivity of quality and speed to these thresholds and principled ways to set them (e.g., calibration, risk‑aware tuning) are not analyzed.
  • Consistency of CPU–NPU KV refresh: The delayed‑merge CPU refresh introduces windows of staleness by design; quantitative analysis of its impact on attention correctness, convergence, and worst‑case errors is missing.
  • Worst-case memory behavior: The Swap‑Optimized Memory Runtime is evaluated in typical runs; worst-case VA fragmentation, mapping failure handling, and behavior under OS memory pressure or concurrent app loads are not evaluated.
  • Long‑run energy and thermal stability: Energy is measured per request; sustained usage effects (thermal throttling, performance drift, battery drain profiles) and QoS under thermal limits remain uncharacterized.
  • Quantization breadth and impact: Only Q4_0 weight quantization is used; support for and impact of alternative schemes (INT8/FP8/mixed‑precision, per‑channel/groupwise quantization) on accuracy and NPU efficiency are not evaluated.
  • Accuracy preservation details: The paper claims quality preservation but shows only partial results; a comprehensive breakdown of where speculative decoding hurts/helps, and how Dual‑Path Progressive Revision recovers accuracy, is incomplete.
  • Sparse update acceleration: Unstable‑token revision is offloaded to CPU due to weak NPU vector support; whether emerging NPUs (with better general compute) could accelerate sparse updates, and how to schedule them without harming dense throughput, is open.
  • Interaction with other decoding optimizations: Synergies/conflicts with techniques like early exiting, adaptive denoising step control, error‑aware masking, or speculative verification policies are not explored.
  • Multi‑tenant and system integration: Scheduling contention between CPU refresh threads and other system tasks, priority/QoS management, and isolation on shared memory (RPCMEM/DMABUF) in real apps are not discussed.
  • Compiler/runtime variability: Sensitivity of gains to NPU compiler versions, driver updates, and tile‑mapping changes is unexamined; the stability of offline latency tables across firmware revisions is unclear.
  • Pipeline overlap limits: The extent to which mapping/transfer prefetching overlaps with compute (and when overlap breaks due to dependencies) is not quantified; guidance for tuning staging buffers and overlap depth is absent.
  • Failure modes and fallbacks: Strategies for handling VA mapping failures, NPU kernel launch errors, or missing operator support at runtime (automatic demotion, graceful degradation) are not specified.
  • Broader workloads: The approach’s applicability to multimodal diffusion LLMs/VLMs (with cross‑attention and larger KV footprints) and code or non‑Latin tokenizers is not evaluated.
  • Security and correctness of shared buffers: Potential risks and correctness guarantees when using shared memory mappings across CPU and NPU (e.g., aliasing, lifetime bugs) are not analyzed.

These gaps suggest concrete next steps: port and validate on multiple NPUs/GPUs, expand benchmarks and model scales, develop online auto‑tuning for windows/thresholds, analyze worst‑case memory and consistency properties, and explore sustained, multi‑tenant, and multimodal scenarios.

Practical Applications

Immediate Applications

The following applications can be deployed now using the techniques and implementation described in the paper (llada.cpp), especially on recent Qualcomm-based Android devices with Hexagon NPUs.

  • On-device mobile AI assistants (chat, summarization, translation)
    • Sectors: software, consumer electronics, telecom
    • Enablers: Multi-Block Speculative Decoding (MBSD) for higher NPU utilization; Dual-Path Progressive Revision (DPPR) to preserve quality; Swap-Optimized Memory Runtime for latency consistency
    • Potential tools/products/workflows: Android SDK/library integrating llada.cpp; pre-quantized dLLM packages (e.g., LLaDA-8B Q4_0); per-device latency bucket profiles; fallback to autoregressive models when NPU is unavailable
    • Assumptions/dependencies: Availability of supported Qualcomm devices (SM8650/8750/8850 or newer), access to dLLM weights (e.g., LLaDA-8B), adequate RAM for KV cache and tiles, adherence to app store and device power/thermal limits
  • Privacy-preserving mobile productivity in regulated domains (healthcare, finance, legal)
    • Sectors: healthcare, finance, legal, enterprise IT
    • Enablers: On-device inference avoids cloud transmission; DPPR maintains accuracy by revising unstable tokens off the critical path
    • Potential tools/products/workflows: Secure enterprise apps for summarizing sensitive notes or reports; offline Q&A; MDM-managed deployment bundling llada.cpp and approved models; audit logging of on-device inference
    • Assumptions/dependencies: Organizational policies allowing on-device AI; certification that no sensitive text leaves device; model quality for domain-specific tasks; local quantization and memory constraints
  • Interactive mobile app agents and UI automation
    • Sectors: mobile software, RPA, accessibility
    • Enablers: Reduced token latency via MBSD makes event-driven agents responsive; CPU–NPU split keeps control logic light while dense layers run fast
    • Potential tools/products/workflows: Android accessibility services or “app agents” (e.g., task planners, UI scripting) powered by dLLMs; integration with existing agent frameworks
    • Assumptions/dependencies: Access to OS automation APIs; guardrails for action reliability; potential need for multimodal models (vision) beyond text-only dLLMs
  • On-device NPC dialogue and content generation for mobile games
    • Sectors: gaming, media/entertainment
    • Enablers: Sustained NPU throughput on dense layers; Swap-Optimized Memory Runtime avoids frame-time spikes from memory remapping
    • Potential tools/products/workflows: Unity/Unreal Android plugins bundling llada.cpp; offline story or dialogue generation; dynamic quest or hint systems
    • Assumptions/dependencies: Integration with game loops and frame budgets; thermal limits during gameplay; content filtering
  • OEM and silicon vendor demos and benchmarks for NPUs
    • Sectors: semiconductor, mobile OEMs
    • Enablers: Demonstrates large speedups (17×–42× vs CPU baseline; up to 3.9× vs equal-size autoregressive) by aligning dLLM workloads with NPU tile engines
    • Potential tools/products/workflows: Preinstalled demo apps; internal benchmarking suites showcasing NPU utilization; firmware or SDK examples
    • Assumptions/dependencies: Stable access to Hexagon SDK/HMX/HVX; consistent NPU VA management across device SKUs
  • Developer toolchain for mobile LLMs
    • Sectors: developer tooling, ML ops
    • Enablers: Model converter to HMX tiles and quantized layouts; runtime that splits dense vs. sparse work across NPU and CPU
    • Potential tools/products/workflows: CLI tools to convert GGUF models to NPU-ready layouts; per-device profiling to build NPU latency tables; API for token-state tracking (visible/stable)
    • Assumptions/dependencies: Licensing for model distribution; maintenance of device-specific profiles; compatibility with app build systems and FastRPC/DMABUF
  • Energy-efficient on-device AI usage strategies
    • Sectors: mobile OS, device management, sustainability
    • Enablers: NPU’s higher TOPS/W and llada.cpp’s scheduling reduce average power and request energy for short to medium outputs
    • Potential tools/products/workflows: OS-level policy to choose dLLM vs. autoregressive decoding based on power/latency targets; dynamic window expansion policies from llada.cpp exposed as system settings
    • Assumptions/dependencies: Access to power telemetry; OS hooks for adaptive model selection; variability across SoC generations
  • Academic benchmarking and reproducible education labs
    • Sectors: academia, ML systems research
    • Enablers: Open-ish implementation path (llama.cpp-based), clear algorithmic components (MBSD, DPPR, Swap-Optimized Runtime)
    • Potential tools/products/workflows: Course labs comparing autoregressive vs. diffusion decoding on mobile; datasets (GSM8K, BoolQ, ARC-C, HellaSwag) with provided scripts; ablations per component
    • Assumptions/dependencies: Access to compatible smartphones; reproducible model weights and quantization

Long-Term Applications

These applications require further research, scaling, cross-vendor support, or ecosystem development before broad deployment.

  • Cross-vendor, cross-OS portability (Apple, MediaTek, Samsung, Windows-on-ARM)
    • Sectors: semiconductor, mobile OS, developer tooling
    • Enablers: Generalization of memory runtime (VA constraints, tile layouts) and CPU–accelerator splits to diverse NPUs/NPAs
    • Potential tools/products/workflows: Vendor-agnostic inference runtime with per-backend tile decoders and memory managers; auto-profiling to build latency buckets on new hardware
    • Assumptions/dependencies: SDK and driver access; standardized shared-memory primitives; differences in tile sizes, vector units, and VA quotas
  • Multimodal on-device diffusion assistants (text + vision/audio)
    • Sectors: healthcare (clinical note + image), education, accessibility, AR
    • Enablers: MBSD/DPPR concepts extended to attention+convolution stacks; memory runtime scaled to larger multimodal tensors
    • Potential tools/products/workflows: On-device captioning + reasoning; AR glasses companion apps; photo-based tutoring/explanations
    • Assumptions/dependencies: Additional operators on NPUs (e.g., conv, vision attention, audio encoders); larger memory budgets; quality validation for multimodal tasks
  • OS-level NPU memory and scheduling APIs for third-party apps
    • Sectors: policy, mobile OS, developer ecosystems
    • Enablers: Insights from Swap-Optimized Memory Runtime motivate APIs for buffer residency hints, mapping reuse, and prefetch
    • Potential tools/products/workflows: Android/iOS APIs exposing NPU VA budgets and residency controls; scheduler that respects latency buckets and background tasks
    • Assumptions/dependencies: Vendor cooperation, security review of shared buffer exposure, backwards compatibility
  • Hybrid on-device/cloud diffusion decoding with SLA-aware scheduling
    • Sectors: telecom, enterprise SaaS
    • Enablers: Decoding window/step adaptivity (MBSD) used to partition steps between device and edge/cloud under latency/energy budgets
    • Potential tools/products/workflows: Runtime that predicts stepwise latency buckets and decides offload points; privacy-preserving partial offload for non-sensitive fragments
    • Assumptions/dependencies: Reliable low-latency connectivity; clear privacy boundaries; cost-benefit vs. fully on-device
  • Edge robotics/IoT planners using compact dLLMs
    • Sectors: robotics, industrial IoT
    • Enablers: CPU–accelerator split (DPPR) for sparse updates; dense attention/FFN on embedded NPUs
    • Potential tools/products/workflows: Onboard task decomposition and plan repair on drones/robots; human-robot dialog offline
    • Assumptions/dependencies: Availability of NPUs in embedded devices; tighter power/thermal constraints; task-specific model adaptation
  • Automotive infotainment and offline copilots
    • Sectors: automotive
    • Enablers: Stable latency via memory runtime; high-throughput NPU utilization for voice/chat assistants without connectivity
    • Potential tools/products/workflows: In-vehicle assistants for trip planning, manual lookup, service Q&A; data residency in-car
    • Assumptions/dependencies: Automotive-grade SoCs and SDKs; harsh thermal environments; integration with car HMI
  • On-device adaptation and light fine-tuning (e.g., LoRA) for dLLMs
    • Sectors: enterprise, prosumer apps
    • Enablers: Memory/runtime mechanisms reused for limited training updates; potential CPU–NPU division for gradients vs. activations
    • Potential tools/products/workflows: Personalization workflows (vocabulary, style); enterprise domain adapters distributed to devices
    • Assumptions/dependencies: Training kernels and optimizer support not in current scope; risk of increased power and wear; catastrophic forgetting safeguards
  • Integration with ML compilers/runtimes (TVM, IREE) for automated scheduling
    • Sectors: ML infrastructure, developer tooling
    • Enablers: Formalizing MBSD and DPPR as schedule passes; memory runtime as a placement pass with lifetime analysis
    • Potential tools/products/workflows: Auto-tuning of decoding windows and thresholds per device; declarative policies for residency and prefetch
    • Assumptions/dependencies: Compiler support for dynamic shapes and control flow; accurate cost models for stage-like NPU latency
  • Security-hardening and standardization of shared-memory inference paths
    • Sectors: mobile OS, security, policy
    • Enablers: Use of DMABUF/RPCMEM highlights need for robust isolation and permissioning when sharing buffers with NPUs
    • Potential tools/products/workflows: OS sandboxing for NPU sessions; permission models for VA mapping; verifiable zero-copy pathways
    • Assumptions/dependencies: OS vendor participation; potential performance trade-offs with stronger isolation
  • Benchmark suites and standards for mobile dLLM evaluation
    • Sectors: academia, standards bodies
    • Enablers: Paper’s methodology across datasets and SoCs; ablation of algorithmic/system components
    • Potential tools/products/workflows: Open benchmarks capturing latency/energy/quality for diffusion vs. autoregressive on mobile; device capability databases
    • Assumptions/dependencies: Community adoption; consistent access to models; fair-use datasets
  • Policy shifts toward on-device AI for data residency and sustainability
    • Sectors: government, regulators, public sector IT
    • Enablers: Demonstrated latency/energy viability for on-device inference reduces need for cloud processing of sensitive data
    • Potential tools/products/workflows: Procurement templates preferring on-device inference; guidance for citizen data privacy; carbon-aware AI policies
    • Assumptions/dependencies: Model quality parity for target tasks; oversight of on-device updates and incident response
  • Wearables and AR devices with ultra-low-power dLLMs
    • Sectors: wearables, AR/VR
    • Enablers: Scheduling and memory insights applied to constrained form factors with tethered or integrated NPUs
    • Potential tools/products/workflows: On-glasses micro-assistants for writing prompts, notifications triage; offline voice-to-text planning paired with phone NPU
    • Assumptions/dependencies: Much smaller memory and power budgets; aggressive quantization/pruning; ergonomic thermal design

Notes on feasibility across applications:

  • Quality depends on the maturity of diffusion LLMs for the targeted tasks and languages; thresholds for token visibility/stability may need tuning per domain.
  • The current implementation is Qualcomm-centric; porting to other NPUs requires re-implementing tile-aware kernels and VA management.
  • Memory budgets (KV cache, weights, activations) and NPU VA limits can be binding; the swap-optimized runtime mitigates but does not eliminate these constraints.
  • Thermal throttling and OS background task policies can affect sustained performance on consumer devices.

Glossary

  • Adaptive Lookahead: A strategy that proactively extends the decoding window to include tokens from future blocks to maintain NPU utilization with limited marginal latency. "Strategy #2: Adaptive Lookahead."
  • Autoregressive decoding: A generation paradigm that produces tokens strictly left-to-right, predicting one token at a time conditioned on the prefix. "LLM inference remains dominated by autoregressive decoding~\cite{attention}"
  • Block-wise decoding: A diffusion decoding scheme that partitions the output into consecutive blocks and denoises tokens within each block in parallel while reusing prefix KV cache across blocks. "Block-wise decoding addresses this issue and makes dLLM generation more practical for long sequences."
  • Continuous Sliding: A windowing strategy that slides the decoding window along the left-to-right commit frontier to focus computation on actively denoised tokens. "Strategy #1: Continuous Sliding."
  • Delayed-merge policy: A method to merge CPU-refreshed KV entries back into the prefix cache only at step boundaries to avoid fine-grained CPU-NPU synchronization. "llada.cpp adopts a delayed-merge policy to keep CPU refreshes off the critical path."
  • Dense tensor operations: High-throughput computations on large, regular tensors (e.g., matrix multiplications) that NPUs are optimized to execute efficiently. "Mobile NPUs are designed to execute dense tensor operations with high throughput and energy efficiency."
  • Diffusion LLMs (dLLMs): Models that generate text by iteratively denoising masked token sequences, updating multiple positions in parallel rather than one-by-one. "Diffusion LLMs (dLLMs) provide an alternative to autoregressive generation."
  • Double-buffered staging: A memory-transfer technique that alternates two staging slots so data preparation overlaps with NPU execution, hiding transfer latency. "llada.cpp uses double-buffered staging to hide transfer latency."
  • Dual-Path Progressive Revision: A mechanism that keeps committed tokens revisable and offloads sparse KV refreshes and logits computation to CPU, preserving dense NPU execution. "Dual-Path Progressive Revision enables efficient token revision without disrupting dense NPU execution."
  • FastRPC: Qualcomm’s remote procedure call mechanism used to invoke device libraries from the Android host runtime. "It invokes the device library through FastRPC and uses RPCMEM shared memory~\cite{qcom-fastrpc}"
  • Feed-forward network (FFN): The Transformer’s per-layer non-attention component, typically comprising linear projections and activations. "Per-layer FFN operator latency, showing spikes when buffer mappings are triggered to make weights visible in the NPU address space."
  • FlashAttention: An optimized attention algorithm/operator that accelerates attention by reducing memory reads/writes. "We enable the NPU FlashAttention~\cite{flashattention} operator on SM8650 and SM8750"
  • GGML: A lightweight tensor and computation library used as the host backend for model execution. "which adds a GGML Hexagon backend~\cite{ggml}"
  • GGUF: A model file format/pipeline extended here with layout passes for NPU-tiled weights. "The model converter extends the GGUF pipeline~\cite{gguf} with a layout pass that rearranges FP16 weights into 32-by-32 HMX tiles"
  • Graph-Guided Buffer Mapping: A memory-management approach that uses the computational graph’s execution order and tensor lifetimes to minimize virtual-address swaps. "Graph-Guided Buffer Mapping."
  • Grouped-query attention: An attention variant with fewer KV heads that changes the attention computation pattern. "another dLLM whose most notable architectural difference from LLaDA is its grouped-query attention with fewer KV heads"
  • Hexagon NPU: Qualcomm’s neural processing unit architecture used to accelerate dense tensor workloads on-device. "Qualcomm reports that the Hexagon NPU in Snapdragon X Elite delivers up to 45 TOPS INT8 performance~\cite{snapdragon-x-elite}."
  • Hexagon SDK: The software development kit used to build Hexagon DSP/NPU operator libraries. "compiled as a Hexagon DSP shared object using the Hexagon SDK~\cite{qcom-hexagon-sdk}"
  • HMX: A Hexagon matrix engine optimized for tiled FP16 operations and specialized data layouts. "It targets the DSP-coupled HMX~\cite{qcom-hmx} and HVX~\cite{qcom-hvx} engines"
  • HVX: Hexagon Vector eXtensions used for vector-style and quantization/dequantization kernels. "It targets the DSP-coupled HMX~\cite{qcom-hmx} and HVX~\cite{qcom-hvx} engines"
  • KV cache: Stored key/value attention states reused to avoid recomputation across steps or blocks. "token revision complicates KV cache reuse"
  • Logits: The pre-softmax output scores over the vocabulary used for confidence estimation and token selection. "and offloads the corresponding updates and logits computation to specialized CPU-side kernels."
  • Multi-Block Speculative Decoding: A technique to fill shrinking workloads by including future-block tokens speculatively, preserving commitment order. "Multi-Block Speculative Decoding improves NPU utilization during the later stages of denoising."
  • NPU virtual address space: The constrained address space into which host buffers must be mapped for NPU kernels to access them. "it must be registered and mapped into the NPU virtual address space."
  • Pipeline-Based Data Transfer: A runtime method that prefetches mapping metadata and stages data guided by the computational graph to overlap with NPU execution. "Pipeline-Based Data Transfer."
  • Prefix KV cache reuse: Reusing cached attention states from completed blocks to avoid recomputation in later blocks. "CPU baseline with prefix KV cache reuse"
  • Producer-consumer relationships: Graph-derived tensor dependencies that guide buffer placement and mapping decisions. "which provides the execution order of NPU operators and the producer-consumer relationships of tensors."
  • Q4_0 quantization: A 4-bit low-precision weight format used to fit models on mobile devices and accelerate inference. "All models use Q4_0 low-bit weight quantization to enable LLaDA and Llama inference on smartphones."
  • RPCMEM: A shared-memory mechanism (backed by DMABUF) enabling zero-copy CPU–NPU buffer sharing. "and uses RPCMEM shared memory~\cite{qcom-fastrpc}, backed by Linux DMABUF~\cite{linux-dmabuf}"
  • RMSNorm: Root Mean Square Layer Normalization variant used in Transformers. "RMSNorm, elementwise operators, shared-memory mapping, and a device-side worker pool."
  • Staged Token Stabilization: A three-state token lifecycle (invisible, visible, stable) separating short-term visibility from long-term stability for KV reuse. "Staged Token Stabilization."
  • Swap-Optimized Memory Runtime: A memory runtime that compacts VA layouts and overlaps data staging with NPU computation to reduce mapping and transfer overhead. "Swap-Optimized Memory Runtime compacts NPU-visible address layouts and overlaps data staging with NPU computation to reduce remapping and transfer overheads."
  • Systolic arrays: Fixed-size tiled matrix engines that deliver high throughput but require tile-aligned tensor shapes. "fixed-size tiled matrix engines, such as systolic arrays, which operate on hardware-preferred tile shapes."
  • Token-commit frontier: The moving boundary in a block where tokens transition from masked to committed, guiding window sliding. "llada.cpp slides the decoding window along the token-commit frontier to focus computation on tokens that remain actively denoised."
  • TOPS (INT8): Tera operations per second metric for integer (8-bit) performance used to characterize NPU throughput. "delivers up to 45 TOPS INT8 performance~\cite{snapdragon-x-elite}."
  • Weak Vector Support: An NPU characteristic where irregular or vector-style ops have much lower throughput than dense matrix kernels. "Weak Vector Support."
  • Visibility threshold: The confidence threshold used to promote tokens into the visible state for participation in subsequent denoising. "tokens that satisfy the visibility threshold $\theta_{\text{visible}$ are promoted to the visible state"

Open Problems

We haven't generated a list of open problems mentioned in this paper yet.

Collections

Sign up for free to add this paper to one or more collections.

Tweets

Sign up for free to view the 1 tweet with 89 likes about this paper.