Tiny Transformers for TinyML: A Systematic Review of Deployment Readiness, Trustworthiness, and Benchmarking

Abstract

Tiny Machine Learning (TinyML) is expanding beyond compact convolutional and feed-forward models toward Transformer-family architectures adapted to microcontrollers and extreme-edge systems. This systematic review evaluates the deployment readiness of Tiny Transformers and closely related compact sequence models under severe memory, latency, energy, and runtime constraints, while examining security, privacy, reliability, uncertainty, reproducibility, sustainability, benchmarking, and application maturity. The review followed PRISMA 2020, and its methodological record was retrospectively registered on the Open Science Framework (OSF identifier 7fazq; review period: 2 March–1 June 2026). Searches across major bibliographic databases and supplementary sources identified 355 records; 213 unique records were screened, 87 full texts were assessed, and 81 reports were included in the qualitative synthesis. Direct Tiny Transformer deployment evidence remains limited and heterogeneous but converges on four complementary feasibility pathways: memory-aware scheduling, task-specific architectural downsizing, reduced-precision and runtime co-design, and sparse architecture–deployment co-design. Across the evidence base, support was substantially stronger for real-device execution and resource-aware optimization than for implemented security and privacy mechanisms, uncertainty calibration and out-of-distribution handling, reproducible deployment pipelines, standardized cross-platform benchmarking, system-level sustainability assessment, and longitudinal field validation. The evidence therefore supports a restrained conclusion: Tiny Transformers are becoming technically viable for selected constrained intelligent systems, but trustworthy, reproducible, and operationally validated deployment remains immature. Future research should prioritize cross-platform evaluation, transparent memory and energy reporting, quantified trustworthiness overhead, reproducible deployment artifacts, and field-oriented validation under realistic operational constraints.

1. Introduction

Tiny Machine Learning (TinyML) refers to the design and deployment of machine-learning inference on highly resource-constrained platforms such as microcontrollers and other low-power embedded devices operating close to the data source. By shifting inference toward the sensing endpoint, TinyML can reduce communication dependence, latency, bandwidth consumption, and exposure of raw data in transit. More broadly, TinyML is increasingly understood as a hardware–software co-design problem in which model architecture, memory footprint, execution efficiency, device constraints, and application requirements must be addressed jointly [1,2,3].

This systems perspective is relevant across healthcare and wearables, industrial sensing, environmental monitoring, robotics, smart-city infrastructure, and energy-aware automation, where inference must operate under tight memory, latency, power, communication, and reliability constraints [4,5,6,7,8]. Historically, such environments were dominated by compact convolutional and feed-forward architectures because their computational structure aligned more naturally with MCU memory hierarchies, operator support, and embedded deployment toolchains. However, the TinyML design space is now expanding toward attention-based and Transformer-derived models [1].

Recent primary studies demonstrate that Transformer-family inference is no longer purely speculative on constrained hardware. Instead, current deployment work reveals four complementary feasibility pathways: memory-aware scheduling, task-specific architectural downsizing, reduced-precision and runtime co-design, and sparse architecture–deployment co-design [9,10,11,12]. These studies establish that Tiny Transformers can execute on selected MCU-class and extreme-edge platforms, although the direct evidence base remains small, heterogeneous, and strongly platform-dependent.

The relevance of these models extends beyond language processing. Many constrained workloads involve temporal dependencies, multivariate sensing, operating-state transitions, biosignals, vibration and acoustic patterns, localization streams, environmental measurements, and anomalous events [4,6,13]. Tiny Transformers and related compact sequence models are therefore of interest not because they universally outperform convolutional or recurrent alternatives, but because they may extend TinyML toward more context-aware inference under severe resource constraints.

This architectural transition also changes the evaluation problem. Deployment feasibility can no longer be assessed only by asking whether a model fits in SRAM or Flash. Constrained systems must also be evaluated in terms of security, privacy, reliability, uncertainty, reproducibility, sustainability, and measurement transparency. Trustworthy edge-intelligence research increasingly treats these dimensions as part of the same deployment problem rather than as independent add-ons [14]. Likewise, TinyML reviews emphasize that hardware feasibility and model efficiency must be interpreted together with energy behavior, deployment realism, and reproducible evaluation practice [2,3].

The existing review literature is extensive but fragmented. Broad TinyML surveys synthesize architectures, deployment frameworks, hardware, and applications [1,2,3]; TinyDL and embedded-AI reviews cover richer model families and broader deployment stacks [15,16]; trustworthy edge-intelligence studies address security, reliability, and sustainability [14]; and separate review streams examine federated learning and small or on-device language models [17,18,19]. Application-oriented reviews further address Industrial IoT, smart cities, environmental monitoring, and energy-efficient edge sensing [4,5,6]. However, this literature does not yet provide a focused synthesis of Tiny Transformers under TinyML-class constraints as a joint problem of deployment feasibility, trustworthiness, benchmarking, sustainability, and application maturity.

This gap motivates the present systematic literature review. The objective is to identify, appraise, and synthesize the evidence on Tiny Transformers and closely related compact sequence models for constrained intelligent systems, with emphasis on model design, deployment feasibility, security, privacy, uncertainty, benchmarking, sustainability, and real-device validation. The review is guided by six research questions: which model-design strategies enable Transformer-style inference on TinyML-class hardware; which computational and systems bottlenecks dominate deployment; which security and privacy risks and countermeasures are reported; how uncertainty, calibration, and reliability are handled; how benchmarking and sustainability are measured; and in which application domains real-device evidence and deployment maturity are strongest.

Accordingly, this review makes four specific contributions: First, it defines a constrained-intelligence boundary that separates direct Tiny Transformer deployment evidence from adjacent embedded-AI, edge-AI, Edge GenAI, and small-language-model research. Second, it organizes the literature through a research-question-guided evidence structure covering deployment strategies, systems bottlenecks, trustworthiness, benchmarking, sustainability, and application maturity. Third, it evaluates Tiny Transformer deployment as a deployment-readiness problem rather than only as a model-compression problem, emphasizing hardware validation, resource measurements, reproducibility, and trustworthiness evidence. Fourth, it translates the resulting evidence gaps into a cross-domain research agenda for trustworthy and reproducible constrained intelligence. This review is therefore intended as a focused synthesis of where Transformer-family models currently stand between technical feasibility and deployment-grade maturity in TinyML-class systems.

2. Background and Review Positioning

2.1. Conceptual Boundaries: TinyML, TinyDL, Embedded AI, Edge AI, and Edge GenAI

TinyML refers to machine-learning inference on severely resource-constrained embedded endpoints, particularly MCUs and similarly small devices operating under tight memory, energy, and compute budgets. Recent reviews consistently characterize TinyML as a hardware–software co-design problem in which model architecture, compression, runtime support, and device constraints must be optimized jointly [1,2,3]. This endpoint-oriented definition distinguishes TinyML from broader forms of edge intelligence and is particularly relevant to low-power industrial, energy, environmental, and urban sensing systems [4,5,6].

TinyDL represents the deep-learning-oriented evolution of this constrained-computing space. Rather than being synonymous with TinyML, it emphasizes the deployment of richer neural architectures under similarly restrictive hardware conditions [16]. Embedded AI is broader, encompassing the integration of AI models, hardware, software frameworks, and deployment pipelines across embedded systems [15], while edge AI extends further across endpoints, embedded boards, gateways, and near-device infrastructure [14].

Edge GenAI constitutes a higher-resource adjacent frontier centered on generative and foundation-model capabilities near the edge, typically under deployment assumptions beyond classical MCU-scale TinyML [18,20]. Accordingly, the present review adopts a conservative boundary: evidence is considered to be directly TinyML-relevant only when deployment claims remain materially tied to constrained embedded hardware, local inference, and explicit resource limitations. Table 1 summarizes these operational distinctions and the role assigned to each concept in the review.

Table 1. Operational boundary matrix used to distinguish the core TinyML scope from adjacent embedded-AI, edge-AI, language-model, and application-oriented evidence.

Concept	Operational Meaning in This Review	Typical Hardware Scale	Role in Scope	Representative Refs.
TinyML	Inference on severely resource-constrained embedded endpoints; MCU-class execution is the reference case.	MCUs, low-power sensor nodes, wearables	Core scope	[1,2,3]
TinyDL	Deep-learning-oriented evolution of constrained AI involving richer neural architectures.	MCUs and adjacent constrained hardware	Inside/adjacent scope	[16]
Embedded AI	Broader integration of AI models, runtimes, toolchains, and hardware into embedded systems.	MCUs, MPUs, embedded Linux, mixed accelerators	Contextual umbrella	[15]
Edge AI	Inference and decision-making across endpoints, gateways, embedded boards, and near-device infrastructure.	Endpoints, gateways, embedded boards	Broader context	[14]
Edge GenAI	Generative and foundation-model inference near the edge, generally under higher resource budgets than TinyML.	NPU-equipped and stronger edge devices	Adjacent frontier	[17,18,20]
Tiny Transformers	Compact Transformer-family models redesigned or optimized for constrained deployment.	Low-power MCUs and extreme-edge SoCs	Primary model focus	[9,10,11,12]
TLMs/SLMs	Small or local language-model variants considered only when relevant to severe embedded constraints.	Typically stronger edge devices than classical MCUs	Adjacent, selectively included	[17,18,20]
Application-oriented TinyML	Constrained inference across healthcare/ wearables, localization, industrial/energy, environmental/smart-city, and robotic sensing.	Wearables, sensor nodes, smart meters, environmental stations, embedded platforms	Contextual application scope	[4,5,6]

2.2. Model-Side Distinctions: Tiny Transformers, Tiny Language Models, and Small Language Models

Tiny Transformers are Transformer-family architectures that have been reduced, redesigned, or otherwise optimized for constrained deployment. In this review, the term is not restricted to language processing; it also covers compact attention-based or Transformer-derived models for sequence, signal, sensor, and vision workloads [9,10,11,12]. This interpretation is relevant because many TinyML applications involve biosignals, multivariate time series, vibration, localization, electrical or thermal measurements, acoustic patterns, and operating-state transitions rather than natural language alone.

Tiny Language Models and Small Language Models describe related but less standardized model categories. Recent SLM and on-device language-model reviews span architectures ranging from sub-billion-parameter models to substantially larger local models deployed on phones, laptops, NPUs, and stronger edge devices [17,18]. Consequently, these categories cannot be treated as automatically equivalent to MCU-class TinyML.

The present review therefore treats Tiny Transformers as the core model family, while TLMs, SLMs, Edge GenAI, and on-device language-model studies are used only as adjacent evidence when they clarify model-scaling trajectories, compression strategies, or constrained-deployment challenges. This distinction also recognizes that language-centric edge systems introduce additional reliability concerns, including hallucination and unreliable semantic outputs [21], while recent on-device language-model research provides useful evidence on compression, quantization, distillation, and hardware-aware deployment [17,18,22].

2.3. Application Scope and the Role of Industrial-Energy Evidence

The application scope covers constrained intelligent systems in which sensing and inference occur close to the data source under strict memory, latency, energy, communication, or maintenance constraints. Relevant domains include healthcare and wearables, localization, Industrial Internet of Things (IIoT), predictive maintenance, smart-energy monitoring, environmental sensing, smart-city infrastructure, robotics, and distributed condition monitoring [1,4,7].

Many of these workloads are temporal, multivariate, and context-dependent. Vibration, acoustic, electrical, thermal, environmental, and operational signals may contain weak fault precursors, state transitions, anomalous patterns, or degradation signatures that must be processed under restricted computational and energy budgets [4,5,6,8,13]. For concision, this review refers to the combination of sensing variability, environmental exposure, intermittent connectivity, maintenance limitations, duty-cycle constraints, and end-to-end energy requirements as the operational envelope of field deployment.

Industrial-energy systems are retained as one demanding application testbed rather than as the dominant empirical basis of the Tiny Transformer literature. Application-oriented studies are interpreted according to deployment maturity, including whether they report local inference, real-device execution, memory, latency, energy or power, hardware context, and operational conditions. Studies centered primarily on cloud, gateway, or high-resource edge execution therefore remain contextual unless their evidence is materially connected to severe embedded constraints [3,4].

This scope does not assume that Transformer-derived models are universally superior to convolutional, recurrent, or lightweight feed-forward alternatives. Instead, it asks whether they can extend TinyML toward context-aware inference while remaining compatible with constrained-device deployment requirements. Likewise, TLM and SLM studies are retained only when their deployment assumptions meaningfully overlap with constrained intelligent systems rather than generic local inference on higher-resource devices [1,17,18].

2.4. Why Tiny Transformers and Language-Centric Compact Models Matter Now

Transformer-style models matter because constrained workloads increasingly involve temporal dependencies, multivariate sensing, and contextual relationships that extend beyond purely local feature extraction. Attention mechanisms are already recognized within contemporary TinyML taxonomies [1], and recent work spans healthcare, localization, Industrial IoT, environmental monitoring, smart-city sensing, embedded vision, and predictive-maintenance applications [4,5,13].

More importantly, primary deployment studies now demonstrate four complementary routes toward constrained Transformer execution: memory-aware scheduling, task-specific architectural downsizing, reduced-precision/runtime co-design, and sparse architecture–deployment co-design [9,10,11,12]. Their detailed quantitative results are compared later in the review rather than repeated here. Collectively, they establish that Tiny Transformer deployment has progressed from architectural possibility to implementable systems research, while still representing a much narrower evidence base than conventional TinyML.

TLMs and SLMs represent an adjacent frontier rather than a mature TinyML core. Their literature demonstrates rapid progress in compression and local inference, but the prevailing hardware context remains substantially less constrained than classical MCU-class deployment [17,18,22]. They are therefore useful for anticipating future constrained-model directions without being interpreted as direct evidence of current Tiny Transformer maturity.

2.5. Why Trustworthiness Is Essential in Constrained TinyML Deployments

Compactness alone is insufficient for deployment-grade constrained intelligence. Trustworthiness must also account for security, reliability, transparency, sustainability, uncertainty, and the practical cost of implementing these mechanisms under resource limitations [14]. TinyML reviews similarly emphasize that privacy and low-latency advantages depend on the interaction among model efficiency, hardware feasibility, energy behavior, and deployment discipline [1,2,3].

These requirements are especially important in safety-, health-, and operations-relevant settings, where incorrect predictions, insecure updates, or poorly calibrated decisions may affect users, equipment, environmental supervision, or resource-management performance [4,5,6]. Benchmark-standardization efforts such as MLPerf Tiny further reinforce the need for transparent reporting of latency, memory, energy or power, hardware configuration, and runtime assumptions [23]. Detailed discussion of benchmarking comparability is reserved for the dedicated benchmarking synthesis later in this review.

Privacy and security must likewise be evaluated as system-level constraints. Federated learning and on-board training can improve data locality but introduce communication, memory, accuracy, and energy trade-offs [19]; similarly, trustworthy-edge research shows that robustness and integrity mechanisms must operate under the same resource ceilings as inference [14]. In this review, the resulting trustworthy deployment envelope therefore combines resource feasibility, security, privacy, uncertainty-aware behavior, reproducibility, and operational robustness.

2.6. Positioning Against Prior Review Literature

The existing review literature addresses several neighboring areas but not the same intersection examined here. Broad TinyML surveys cover hardware, frameworks, compression, and applications [1,2,3]; TinyDL and embedded-AI reviews extend that perspective toward richer models and broader deployment pipelines [15,16]; trustworthy edge-intelligence and on-device AI reviews address reliability and broader edge deployment [14,17]; and separate surveys examine SLMs and federated-learning/TinyML privacy trade-offs [18,19]. Application-oriented reviews additionally cover Industrial IoT, smart cities, environmental monitoring, and sustainable edge sensing [4,5,6].

The remaining gap is therefore not a lack of TinyML or edge-AI surveys but the absence of a focused synthesis that examines Transformer-family models under TinyML-class constraints while jointly considering deployment feasibility, trustworthiness, benchmarking, sustainability, and application maturity [1,2,3]. The distinct contribution of this review is this intersectional perspective: it separates direct Tiny Transformer evidence from supporting TinyML and benchmarking studies and from contextual edge-AI, application, and on-device language-model literature.

This evidence separation is essential because technical feasibility, deployment directness, and trustworthy field maturity are not equivalent. This review therefore evaluates where evidence is deployment-grade, where it remains adjacent or enabling, and where broader claims about trustworthy constrained intelligence would still be premature [14,17,18].

2.7. Expanded Enabling Literature and Adjacent Evidence Base

The direct Tiny Transformer corpus sits within a broader enabling literature that helps explain how constrained deployment is evolving. At the model level, MobileViT, TinyViT, and EfficientFormer demonstrate hardware-aware Transformer simplification for mobile and edge inference [24,25,26], while EfficientViT, FastViT, and RepViT extend this direction through memory-efficient and structurally optimized vision Transformer designs [27,28,29]. TinyFormer occupies the direct core because it explicitly combines Transformer architecture search, sparsity, and MCU deployment under constrained storage and memory budgets [12].

MCU-oriented work such as MCUNet, MCUNetV2, Once-for-All, and MicroNets further demonstrates that model accuracy must be co-optimized with memory footprint, operator structure, kernels, and target hardware rather than treated independently [30,31,32,33]. At the systems level, DORY, PULP-TrainLib, and Deeploy show that compiler support, kernel generation, autotuning, and deployment frameworks strongly influence whether compact models are practically executable on low-cost MCUs and extreme-edge RISC-V systems [34,35,36]. Recent reviews of embedded deployment and mobile/edge vision Transformers reinforce this architecture–runtime–hardware co-design perspective [37,38].

Adjacent architectural directions are also emerging. Linear-time state-space models such as Mamba offer an alternative for sequence modeling where quadratic attention costs are problematic [39]. Recent work on indoor localization, low-power embedded vision, energy-efficient object detection, ECG classification, sign-language recognition, and resource-constrained anomaly detection indicates that compact Transformer-style and related sequence models are spreading across increasingly diverse constrained applications [13,40,41,42,43].

Industrial IoT, environmental monitoring, smart-city, and sustainable edge-sensing studies provide a broader application context in which low-power local inference, anomaly detection, communication reduction, and energy-aware operation are increasingly important [4,5,6]. These adjacent studies do not substitute for direct Tiny Transformer deployment evidence; rather, they show the wider constrained-intelligence ecosystem into which the emerging core may eventually translate.

Figure 1 summarizes this positioning. TinyML occupies the most restrictive MCU- and ultra-low-power endpoint, embedded AI and edge AI represent broader deployment environments, and Edge GenAI represents a higher-resource adjacent frontier. Tiny Transformers remain the primary model focus, whereas TLMs and SLMs are selectively interpreted as adjacent evidence.

Figure 1. Positioning of Tiny Transformers within the constrained-intelligence continuum. TinyML represents the most restrictive endpoint class; embedded AI, edge AI, and Edge GenAI provide progressively broader deployment contexts. Tiny Transformers are the primary model focus, while TinyDL and tiny/small language-model research contribute adjacent evidence when relevant to severe embedded constraints. Solid arrows indicate the primary constrained-intelligence and application relationships considered within the review scope, whereas dashed arrows indicate adjacent or prospective connections that are not treated as direct TinyML deployment evidence.

3. Methodology

3.1. Review Design, Protocol, and Reporting Framework

This study was conducted as a systematic literature review and reported in accordance with PRISMA 2020 [44]. Identification, eligibility screening, data extraction, evidence appraisal, and qualitative synthesis were treated as distinct methodological stages so that evidence-strength judgments did not function as undocumented eligibility criteria. The PRISMA checklist can be found in the Supplementary Material.

The review protocol and methodological record were retrospectively registered on the Open Science Framework (OSF) under the title Trustworthy Tiny Transformers for Constrained Intelligent Systems: A Systematic Review of Deployment Feasibility, Security, and Benchmarking (OSF identifier 7fazq) [45]. The registered review period was 2 March–1 June 2026, and the evidence set was frozen on 1 June 2026. Because the review process had begun before registration, the OSF record is reported as a transparency and methodological-audit record rather than as prospective preregistration.

3.2. Review Objective and Research Questions

This review systematically identifies, evaluates, and synthesizes evidence on Tiny Transformers and closely related compact Transformer-derived sequence models for TinyML-class constrained intelligent systems. The primary focus is deployment feasibility under severe hardware constraints together with security, privacy, uncertainty, benchmarking, sustainability, reproducibility, and application maturity. Adjacent TinyML, embedded-AI, edge-AI, Edge GenAI, and TLM/SLM literature was retained only when it informed interpretation of constrained Tiny Transformer deployment, rather than as an independent review topic.

This review addresses the following research questions:

RQ1.

What model-design strategies are being used to enable Tiny Transformers and related compact sequence models on TinyML-class constrained devices?

RQ2.

What are the principal computational and systems bottlenecks for deploying these models on constrained hardware?

RQ3.

What security and privacy risks are reported for TinyML systems relevant to Tiny Transformer deployment, and what defenses appear feasible under severe resource constraints?

RQ4.

How are uncertainty, calibration, confidence estimation, or reliability-aware mechanisms incorporated, and what practical overhead do they impose?

RQ5.

How are accuracy, latency, memory footprint, energy, and sustainability jointly evaluated, and how mature are current benchmarking practices?

RQ6.

In which application domains—including healthcare and wearables, localization, industrial and energy systems, environmental and smart-city sensing, robotics, and other constrained settings—are Tiny Transformers validated, and how mature is the real-deployment evidence?

3.3. Information Sources and Search Strategy

The primary identification sources were Scopus, Web of Science Core Collection, IEEE Xplore, ACM Digital Library, and PubMed. Supplementary retrieval used ScienceDirect, SpringerLink, MDPI, arXiv, Google Scholar, and backward/forward citation chasing. Searches were conducted between 2 March and 1 June 2026 and were restricted to English-language records published from 2021 to the search cut-off.

A limited number of seminal pre-2021 studies were subsequently recovered through backward citation chasing when they provided indispensable foundations for interpreting benchmarking, deployment frameworks, model compression, uncertainty estimation, reproducibility, or sustainability. These studies were coded as enabling or contextual evidence and were not used to characterize contemporary Tiny Transformer prevalence or maturity.

The strategy combined five concept blocks: constrained-device terminology (C), Transformer/model-family terminology (M), deployment and optimization terminology (D), trustworthiness terminology (T), and application-context terminology (A). Three search families were used: Core ($C\wedge M\wedge D$), Trustworthiness sensitivity ($C\wedge M\wedge D\wedge T$), and Application sensitivity ($C\wedge M\wedge D\wedge A$). Complete database-specific search strings and field syntax are reproduced in Appendix A.

Table 2 summarizes the searched sources, applied limits, role in the review, and records retrieved before deduplication.

Table 2. Information sources, applied limits, role in the review, and records retrieved before deduplication.

Source	Interface/Fields	Applied Limits	Role in the Review	Records
Scopus	Advanced Search; TITLE-ABS-KEY	2021–2026; English; articles, conference papers, and reviews	Primary identification source	62
Web of Science Core Collection	Clarivate Core Collection; TS field	2021–2026; English; articles, reviews, and proceedings papers	Primary identification source	41
IEEE Xplore	Advanced Search; metadata, title, abstract, and keywords	From 2021; journals and conference papers; English where available	Primary engineering source	54
ACM Digital Library	Advanced Search; metadata, title, abstract, and keywords	From 2021; research articles, proceedings papers, and reviews/surveys	Primary computing source	25
PubMed	PubMed.gov; title/abstract fields	From 1 January 2021; English	Primary biomedical source	14
ScienceDirect	Native platform interface	From 2021; eligible English-language records	Supplementary retrieval	28
SpringerLink	Native platform interface	From 2021; eligible English-language records	Supplementary retrieval	21
MDPI	Native platform interface	From 2021; eligible English-language records	Supplementary retrieval	16
arXiv	Native platform interface	From 2021; frontier scanning and archival-version recovery	Supplementary discovery	39
Google Scholar	Sensitivity queries	From 2021; supplementary discovery and citation checking	Sensitivity searching	38
Backward/forward citation chasing	Reference lists, publisher pages, and citation systems	No fixed year limit for narrowly selected seminal evidence	Foundational enabling/ contextual evidence	17
Total records identified before deduplication				355

Note: Searches were conducted between 2 March and 1 June 2026, with the evidence set frozen on 1 June 2026. Separate execution dates for individual databases were not retained. Complete database-specific search strategies are provided in Appendix A.

The search was checked against known relevant sentinel studies before final execution and refined when representative constrained-deployment or benchmarking evidence was not recovered or when retrieval drifted toward generic cloud, smartphone-only, or unconstrained edge-AI literature. Citation chasing and archival-version checking were used to improve recall.

3.4. Eligibility Criteria

Reports were eligible when they (i) were English-language publications from 2021 onward, or seminal pre-2021 studies recovered through citation chasing for a clearly defined foundational role; (ii) provided peer-reviewed empirical, systems, benchmarking, application, or directly relevant review evidence; (iii) were materially connected to TinyML-class or otherwise severely constrained embedded deployment; (iv) involved Transformer-family, compact attention-based, or closely related sequence models relevant to constrained deployment; and (v) addressed at least one review axis: model optimization, deployment feasibility, security, privacy, uncertainty, benchmarking, sustainability, or application validation.

Reports were excluded when they focused only on cloud or high-resource edge AI, smartphone-only deployment without severe-constraint relevance, generic LLM/on-device AI without material connection to constrained embedded execution, purely conceptual discussion without empirical or systems evidence, or non-eligible publication types. Application studies centered exclusively on cloud, gateway, or high-resource edge computation were also excluded from the core constrained-deployment evidence.

Pre-2021 studies were retained only when indispensable to the interpretation of recent evidence and were coded as enabling or contextual rather than contemporary deployment evidence. When preprint and archival versions overlapped, the archival version was retained.

Methodological reporting standards used solely to guide the conduct and reporting of this review, including PRISMA 2020, and registration or methodological records such as the OSF record were treated exclusively as methodological references. They were not eligible for inclusion in the qualitative evidence corpus and were not subjected to the study-level evidence-strength and deployment-readiness appraisal.

For synthesis, direct core Tiny Transformer deployment evidence required three conditions: (i) a Transformer-family or materially Transformer-derived model, (ii) explicit MCU-class or comparably severe embedded constraints, and (iii) an implemented deployment path, named constrained-hardware execution, or an MCU-oriented deployment framework with explicit resource ceilings. Under these criteria, Jung et al., Busia et al., Dequino et al., and Yang et al. (TinyFormer) constitute the direct core evidence used for feasibility claims [9,10,11,12]. Other relevant studies were classified as adjacent, enabling, or contextual evidence according to their role in the synthesis.

3.5. Record Management, Screening, and Data Extraction

Records were merged into a single review library and deduplicated using DOI, PMID, ISBN, title, publication year, author information, and archival-version status. Two reviewers independently screened titles/abstracts and full texts against the predefined criteria, with disagreements resolved by consensus or third-reviewer adjudication. A pilot screening round was used to calibrate eligibility decisions. Cohen’s kappa was calculated for the screening stages, while final inclusion decisions were based on reconciled judgments. Each excluded full-text report was assigned one primary exclusion reason.

Data were collected through a piloted structured extraction matrix and independently verified for deployment-critical fields. Extracted variables included study type; model family and size; hardware and memory/energy constraints; runtime/toolchain; deployment and optimization strategy; task, dataset, and comparator; accuracy or task metrics; latency, throughput, memory, and energy/power; security, privacy, robustness, uncertainty, calibration, and reproducibility; application domain; deployment maturity; and author-reported limitations.

Only explicitly reported values were extracted. Missing values were coded as “not reported” rather than zero, and no unsupported values were imputed. When multiple configurations were available, priority was given to results tied to named hardware, specified precision/runtime settings, and transparent measurement conditions.

3.6. Data Preparation and Evidence Coding

Memory values were normalized to KB or MB when reliable conversion was possible, latency to milliseconds per inference, and energy to microjoules or millijoules per inference. Original values and measurement context were retained alongside normalized fields.

Hardware was coded as MCU, extreme-edge SoC, embedded FPGA, embedded Linux board, or broader edge platform. Deployment maturity was coded as simulation-only, board-level real-device execution, field-like evaluation, or operational deployment. Trustworthiness coverage was coded as absent, conceptual, experimentally measured, or integrated into deployment. Model and deployment strategies were grouped into architecture reduction, quantization, pruning, distillation, efficient or sparse attention, kernel/runtime optimization, and hardware-aware design.

3.7. Evidence-Strength and Deployment-Readiness Appraisal

A review-specific appraisal was conducted separately from eligibility assessment to support evidence weighting without functioning as an additional exclusion criterion. One reviewer performed the initial appraisal, a second independently verified the domain-level judgments against the full texts, and a third adjudicated unresolved discrepancies. Final ratings were established by consensus.

The framework deliberately evaluates two complementary dimensions rather than treating them as equivalent measures of methodological quality. The methodological-reporting dimension comprises methodological clarity, benchmark completeness, and reproducibility (0–6 points), whereas the evidence-directness/deployment-readiness dimension comprises evidence directness, device-validation strength, trustworthiness measurement, and application maturity (0–8 points). Each domain is scored as 0 (absent or insufficient), 1 (partial or moderate), or 2 (clear or strong).

Importantly, the two dimensions are interpreted separately. A rigorous theoretical or review study may exhibit strong methodological reporting while providing little direct deployment evidence, whereas a real-device demonstration may provide strong deployment directness despite incomplete reporting or reproducibility. A combined 0–14 score is retained only as a secondary descriptive summary for narrative weighting and is not interpreted as a validated methodological-quality, study-validity, or risk-of-bias scale.

For descriptive synthesis, combined scores of 0–6, 7–10, and 11–14 were labeled limited, moderate, and strong review-specific evidence, respectively. These categories were used only to moderate RQ-level confidence and never as automatic exclusion criteria.

Table 3 presents the seven appraisal domains and scoring anchors.

Table 3. Evidence-strength and deployment-readiness appraisal domains and scoring anchors.

Domain	0: Absent/Insufficient	1: Partial/Moderate	2: Clear/Strong
Evidence directness	Peripheral to constrained Transformer deployment or weakly connected to the review questions	Relevant through adjacent, enabling, or contextual evidence	Direct Tiny Transformer or closely related constrained- deployment evidence
Methodological clarity	Methods or evaluation procedure cannot be reconstructed	Main methods reported but relevant implementation/evaluation details are missing	Methods and evaluation conditions are sufficiently clear to reproduce in principle
Device-validation strength	Simulation-only, unspecified hardware, or no device-level validation	Board-level, partial-device, or incompletely documented hardware evidence	Named constrained hardware with measured local execution and clear deployment conditions
Benchmark completeness	Isolated metric, unclear measurement procedure, or weak comparator	Multiple metrics reported but baselines or procedures remain incomplete	Task performance, resource metrics, baselines, hardware configuration, and measurement procedures reported
Reproducibility	No accessible artifacts and insufficient implementation detail	Partial code, model, toolchain, configuration, or implementation information	Accessible artifacts and sufficient build, deployment, and evaluation details
Trustworthiness measurement	No consideration of security, privacy, robustness, uncertainty, calibration, reliability, or related mechanisms	Conceptual or indirect consideration without a deployed and measured mechanism	At least one trustworthiness mechanism implemented and measured under explicit deployment conditions
Application maturity	Conceptual application scenario without practical validation	Laboratory, board-level, or proof-of-concept validation	Field-like, longitudinal, operationally grounded, or real- world validation

Study-level domain ratings, dimension-level results, combined descriptive scores, and evidence classifications are reported in Appendix B.

A conventional clinical risk-of-bias instrument was not applied because the corpus combines systems studies, hardware-deployment experiments, benchmarking studies, methodological contributions, applications, and review evidence. The purpose-built framework therefore serves as an evidence-weighting and deployment-readiness tool rather than as a replacement for a validated risk-of-bias instrument.

Separate pre-consensus appraisal ratings were not retained after verification and adjudication; consequently, an appraisal inter-rater coefficient could not be calculated retrospectively without introducing unsupported information.

3.8. Synthesis Strategy and Inference Criteria

A structured qualitative synthesis was used because the studies differed substantially in model family, hardware, task, dataset, runtime, deployment setting, and measurement protocol, making quantitative meta-analysis inappropriate.

Each study was mapped by evidence role (core, adjacent, enabling, or contextual), constrained-system relevance, research-question contribution, and deployment-readiness evidence. The latter included hardware target, runtime, latency, memory, energy or power, benchmark context, reproducibility artifacts, trustworthiness mechanisms, and application maturity. This mapping was used to distinguish direct deployment evidence from the surrounding literature and to prevent adjacent TinyML, edge-AI, or SLM evidence from being interpreted as equivalent proof of Tiny Transformer feasibility.

Real-device feasibility required named constrained hardware and measured or explicitly reported execution results. Energy-efficiency claims required measured or explicitly estimated energy/power values with sufficient context. Trustworthiness maturity required implementation or measurement of a concrete mechanism rather than conceptual mention alone. Benchmark maturity required documented hardware, metrics, baselines, and measurement procedures. Application readiness required constrained local inference together with realistic or field-like deployment evidence.

3.9. Reporting Bias, Robustness, and Confidence in Evidence

Because the evidence was heterogeneous and no meta-analysis was conducted, effect-size-based publication-bias methods were not applicable. Interpretation instead considered positive-results bias, hardware-reporting bias, benchmark-selection bias, incomplete energy reporting, missing security-overhead measurements, and overrepresentation of feasibility demonstrations.

Four qualitative robustness checks were applied: (i) restricting interpretation to peer-reviewed evidence, (ii) restricting deployment conclusions to real-device studies, (iii) excluding adjacent edge-AI or SLM evidence without direct TinyML relevance, and (iv) restricting trustworthiness and sustainability conclusions to studies implementing or measuring concrete mechanisms.

No formal GRADE or CERQual assessment was applied. Confidence in the qualitative conclusions was instead judged from methodological reporting strength, evidence directness, hardware validation, measurement transparency, reproducibility, consistency across studies, and evidence role. Conclusions were expressed as stronger, moderate, or limited only when these dimensions supported the corresponding level of confidence.

4. Results: Descriptive Overview of the Literature

4.1. Study Selection

The PRISMA 2020 selection process is summarized in Figure 2. A total of 355 records were identified before deduplication, comprising 196 records from primary databases/registers and 159 from supplementary sources and citation chasing. After removal of 142 duplicates, 213 unique records underwent title/abstract screening. Of these, 97 reports were sought for retrieval, 87 full texts were assessed, and 81 reports were included in the qualitative synthesis.

Figure 2. PRISMA 2020 flow diagram of study identification, screening, eligibility assessment, and inclusion. Of the 355 records identified, 81 reports were included in the qualitative synthesis.

Ten reports could not be retrieved, and six were excluded after full-text assessment: two because the hardware scale was not sufficiently constrained, one because the model family was outside the review scope, two because they provided no relevant deployment or benchmarking evidence, and one because it was a non-peer-reviewed preprint without an archival version. The final corpus also contained a limited number of seminal pre-2021 studies recovered through backward citation chasing and retained only as enabling or contextual evidence.

4.2. Corpus Profile and Evidence Structure

The corpus reflects a recent and heterogeneous research area rather than a mature body of directly comparable Tiny Transformer deployments. Broad surveys and reviews provide extensive coverage of TinyML, TinyDL, embedded AI, trustworthiness, Industrial IoT, smart cities, environmental sensing, and related constrained-computing domains [1,2,3], whereas the direct Tiny Transformer deployment evidence remains concentrated in a much smaller group of recent primary studies [9,10,11,12]. MLPerf Tiny provides an important benchmarking reference for ultra-low-power inference [23], while the application-oriented literature continues to broaden toward industrial, environmental, smart-city, and energy-aware sensing [4,5,6].

For synthesis, the literature was organized by evidence role. Core evidence comprises direct Tiny Transformer deployment under MCU-class or comparably severe embedded constraints. Adjacent evidence includes TinyML, runtime, benchmarking, security, uncertainty, and related constrained-AI studies that directly inform deployment interpretation. Enabling evidence captures model, compiler, runtime, and hardware-aware developments that make constrained deployment technically possible, while contextual evidence provides application, edge-AI, or language-model perspectives without being treated as equivalent proof of Tiny Transformer feasibility.

The application evidence is correspondingly broader than the direct deployment core. Healthcare and wearable sensing, indoor localization, industrial monitoring, environmental supervision, energy-efficient object detection, smart-city sensing, and resource-constrained anomaly detection provide important application context [4,5,13]. Adjacent on-device language-model studies likewise contribute evidence on compression, quantization, distillation, and local inference, although much of this literature targets hardware above classical TinyML resource levels [17,18,20]. These surrounding bodies of literature are therefore used to interpret deployment opportunities and gaps, rather than to enlarge the strength of the direct Tiny Transformer evidence.

4.3. Direct Tiny Transformer Deployment Evidence

Four studies satisfied this review’s strict definition of direct Tiny Transformer deployment evidence under MCU-class or comparably severe embedded constraints [9,10,11,12]. Together, they represent four complementary deployment pathways: memory-aware execution and scheduling, task-specific architectural downsizing, reduced-precision/runtime co-design, and sparse architecture–deployment co-design.

Table 4 centralizes the quantitative evidence from these studies. Detailed numerical results are intentionally reported here rather than repeatedly restated throughout the manuscript. Because the studies differ in task, dataset, model family, hardware, precision, runtime, and measurement procedure, their results establish complementary feasibility cases rather than a controlled cross-study ranking.

Table 4. Direct comparison of the core Tiny Transformer deployment studies on constrained hardware.

Study	Model/Precision	Hardware	Task/Benchmark	Task Metric	Latency/Throughput	Memory Evidence	Energy/Power Evidence	Deployment Strategy
Jung et al. [9]	Encoder Tiny Transformers; reduced precision, configuration-dependent	Low-power cache-less MCU-class/GAP9/ PULP-style targets	Multiple encoder– Transformer deployment workloads	Configuration-dependent	Measured real-device execution; no single representative latency retained	Reduced memory traffic and working- memory demand through schedule-level optimization	Not reported as a standardized comparable energy-per-inference value	Fused-weight self-attention, depth-first tiling, optimized attention kernels, and memory-aware scheduling
Busia et al. [10]	Task-specific Tiny Transformer; ∼6k parameters; 8-bit inference	GAP9 microcontroller/ extreme-edge SoC	MIT-BIH Arrhythmia Database; ECG classification	98.97% accuracy	4.28 ms/inference	NR as a directly comparable footprint	0.09 mJ/inference	Task-specific architectural downsizing and embedded inference co-design
Dequino et al. [11]	Reduced MobileBERT-, TinyViT-, and tinyLLAMA- derived workloads; BF16-oriented and pruned configurations	Parallel RISC-V extreme-edge SoCs, including GAP9/ PULP-style systems	Transformer-family language and vision workloads	Configuration-dependent	Up to 1219 tokens/s for the reported tinyLLAMA configuration	Approximately 94% reduction for MobileBERT and 57% for TinyViT in reported configurations	Approximately 57 mW average power for the reported tinyLLAMA configuration	Architectural reduction, pruning, reduced precision, optimized matrix kernels, and runtime/ kernel co-design
Yang et al. (TinyFormer) [12]	Sparse transformer selected through SuperNAS/ SparseNAS; configuration- dependent precision	MCU-class devices under 1 MB storage and 320 KB memory constraints	CIFAR-10 classification	96.1% accuracy	Up to 12.2× speedup relative to CMSIS-NN; absolute latency configuration-dependent	Explicit 1 MB storage and 320 KB memory deployment ceiling	Not reported as a standardized comparable energy-per-inference value	Sparse architecture search and MCU-oriented SparseEngine deployment

Note: NR indicates that a metric was not reported or was not available in a sufficiently comparable form. Energy-per-inference and average-power values are presented as study-specific evidence and must not be compared directly because workload, hardware, operating conditions, runtime, precision, and measurement boundaries differ across studies.

Across these studies, real-device feasibility is supported more consistently than standardized cross-platform comparability. No study reports the complete set of model size, peak SRAM, Flash usage, accuracy, latency, energy per inference, average power, runtime/toolchain configuration, benchmark protocol, and operational conditions under a common reporting framework. Accordingly, the strongest conclusion supported by the direct corpus is feasibility under selected hardware–software configurations, not universal performance superiority.

4.4. Evidence-Strength and Deployment-Readiness Profile

The study-level appraisal produced 3 reports classified as strong, 51 as moderate, and 27 as limited review-specific evidence. As defined in Section 3, these categories derive from a secondary combined descriptive score and must not be interpreted as rankings of absolute methodological quality. Methodological reporting and evidence directness/deployment readiness were evaluated as separate dimensions before the combined classification was used for narrative weighting. Table 5 summarizes this review-specific evidence-strength distribution.

Table 5. Secondary descriptive distribution of the 81 included reports by review-specific evidence-strength classification.

Evidence-Strength Category	Number of Reports
Strong	3
Moderate	51
Limited	27
Total	81

The domain-level appraisal reveals an important asymmetry. Direct deployment studies generally provide stronger evidence for hardware feasibility, measured execution, and resource-aware implementation than for reproducibility, implemented trustworthiness mechanisms, or real-world application maturity. Security, privacy, robustness, uncertainty, calibration, out-of-distribution behavior, and reliability are frequently discussed across the broader literature but are less consistently implemented and measured on constrained Tiny Transformer hardware [14,19].

Application maturity is likewise uneven. Board-level and laboratory demonstrations are available, while field-like and longitudinal validation remain much less common. For long-lived industrial, environmental, healthcare, smart-city, and energy-oriented systems, this distinction is particularly important, because deployment must eventually be evaluated within the operational envelope defined in Section 2 rather than solely through laboratory inference metrics [4,5,6,7].

4.5. Representative Enabling and Adjacent Evidence

The narrow direct-deployment core is supported by a broader literature on model efficiency, MCU specialization, runtimes, benchmarking, and application-oriented TinyML. Table 6 summarizes representative evidence without treating these studies as equivalent to direct Tiny Transformer deployment.

Table 6. Representative enabling and adjacent literature framing the Tiny Transformer deployment problem.

Theme	Contribution to the Evidence Base	Representative Refs.
Deployment frameworks	Compiler/runtime support, kernel optimization, and constrained DNN execution	[34,35]
Mobile/edge Transformer families	Model-side strategies for hardware-aware transformer simplification	[24,25,26]
Tiny-model specialization	Memory-first and hardware-aware specialization for MCU-class inference	[30,31,33]
Direct Tiny Transformer deployment	Memory-aware scheduling, task-specific downsizing, reduced-precision/runtime co-design, and sparse MCU-oriented deployment	[9,10,11,12]
Application-oriented TinyML	Industrial, environmental, smart-city, energy-aware, and other constrained sensing contexts	[4,5,6,13]
Benchmarking	Standardized TinyML benchmarking and reporting discipline	[23]
Language-model frontier	Compression and local inference evidence relevant to future constrained language-centric deployment	[17,18,20]
Baseline tiny architectures	Established lightweight architectures that remain important references for constrained inference	[46]

Taken descriptively, the corpus therefore has a broad enabling and contextual literature but a substantially narrower direct Tiny Transformer deployment core. This distinction provides the basis for the RQ-level synthesis in Section 5, where model-design strategies, deployment bottlenecks, trustworthiness, uncertainty, benchmarking, sustainability, and application maturity are examined without repeating the descriptive corpus overview.

5. RQ-Level Synthesis

The RQ-level synthesis distinguishes direct core evidence from adjacent and contextual evidence, following the hierarchy defined in Section 3 and Section 4. Direct Tiny Transformer feasibility claims are anchored in the four constrained-deployment studies summarized in Table 4, whereas adjacent TinyML, benchmarking, security, uncertainty, language-model, and application studies are used to interpret mechanisms, limitations, and future requirements rather than as equivalent deployment evidence.

Table 7 provides a focused comparison of the four core deployment studies used throughout the RQ-level synthesis.

Table 7. Focused comparison of the core Tiny Transformer deployment evidence used throughout the RQ-level synthesis.

Core Study	Deployment Strategy	Main Evidence	Main limitation for Synthesis
Jung et al. [9]	Memory-aware scheduling and attention-kernel optimization	Demonstrates that Transformer execution on low-power MCU-class platforms can be improved through fused-weight self-attention, optimized kernels, and depth-first tiling	Limited application validation, trustworthiness evaluation, and cross-task generalization
Busia et al. [10]	Task-specific architectural downsizing	Provides a highly compact real-device Tiny Transformer demonstration with deployment-relevant latency and energy evidence for wearable ECG classification	Limited generalizability beyond the specific task, dataset, and application domain
Dequino et al. [11]	Reduced precision, pruning, and runtime/kernel co-design	Shows that Transformer-derived language and vision workloads can be reduced and executed on ultra-low-power extreme-edge platforms through precision and runtime optimization	Platform-specific evidence and incomplete trustworthiness coverage
Yang et al. (TinyFormer) [12]	Sparse architecture– deployment co-design	Demonstrates MCU-oriented Transformer deployment under explicit memory/storage ceilings using architecture search and a specialized sparse inference engine	Limited standardized energy reporting, cross-task replication, and trustworthiness validation

Taken together, the core studies establish four complementary feasibility pathways—memory-aware scheduling, task-specific architectural downsizing, reduced-precision/runtime co-design, and sparse architecture–deployment co-design—but they remain heterogeneous in hardware, task, precision, runtime, and evaluation protocol [9,10,11,12]. Consequently, the synthesis supports feasibility more strongly than standardized performance ranking or deployment-grade trustworthiness.

5.1. RQ1: Model-Design Strategies for Constrained Tiny Transformers

The central design challenge is to preserve useful Transformer-style sequence modeling while reducing the memory, computation, and runtime demands that make conventional attention architectures difficult to deploy on TinyML-class systems. The literature does not identify a single dominant solution; instead, several complementary design families have emerged.

Direct deployment evidence supports four principal strategies: task-specific redesign [10], memory-aware execution and scheduling [9], structural reduction combined with reduced-precision/runtime optimization [11], and sparse architecture-search/deployment co-design [12]. These approaches show that parameter-count reduction alone is insufficient; memory traffic, activation peaks, operator scheduling, numerical precision, runtime support, and task specificity must also be considered.

Adjacent work expands this design space. Quantized fine-tuning, dynamic BERT compression, and small-model emulation approaches illustrate how language-centric models can be compressed or adapted under tighter resource budgets [47,48,49]. Broader SLM/on-device LM studies likewise document active work in quantization, pruning, distillation, and hardware-aware deployment, although most of this evidence still targets stronger devices than classical MCU endpoints [17,18].

For constrained sensing and monitoring, these strategies are particularly relevant because many workloads involve temporal signals, anomaly precursors, operating-state transitions, and multivariate streams [4,5,6]. The evidence therefore suggests that Tiny Transformers are most likely to mature first in focused, task-specific applications rather than as general-purpose language or reasoning models.

Overall, RQ1 is supported with moderate confidence. Tiny Transformer feasibility is demonstrated across several design pathways, but independent replication across tasks, model families, and MCU platforms remains limited. The principal unresolved question is whether these strategies generalize beyond carefully engineered demonstrations without large accuracy losses or excessive system-specific optimization.

5.2. RQ2: Deployment Bottlenecks and Hardware Feasibility

Transformer deployment on constrained hardware is governed by more than model size. Major bottlenecks include activation-memory peaks, attention-map materialization, matrix-multiplication cost, nonlinear operations, embedding overhead, data movement, and mismatch between Transformer execution patterns and scratchpad- or cache-limited memory systems [9,11].

The broader TinyML literature confirms that hardware heterogeneity further complicates deployment. SRAM and Flash capacity, processor architecture, multicore support, vector extensions, accelerator availability, memory organization, compiler maturity, and optimized kernels vary substantially across embedded platforms [1,2,3]. The resulting problem is therefore a hardware–software co-design problem rather than a model-export problem.

The direct evidence shows that different bottlenecks are addressed by different mechanisms: Jung et al. target memory scheduling and attention execution [9]; Busia et al. use extreme task-specific compactness [10]; Dequino et al. combine pruning, reduced precision, and optimized kernels [11]; and TinyFormer couples sparse architecture search with an MCU-oriented inference engine [12]. Their detailed quantitative results are centralized in Table 4 rather than repeated here.

Several conclusions are consistent across the evidence: First, parameter-count reduction does not guarantee deployability unless activation memory and data movement are also controlled [9,11]. Second, matrix operations remain the dominant optimization target, motivating tiling, fusion, vectorization, reduced precision, and specialized kernels. Third, feasibility is strongly platform-dependent—results achieved on parallel GAP9/PULP-style or RISC-V extreme-edge systems cannot automatically be transferred to simpler MCU architectures [9,11].

For application-oriented systems, board-level execution must also remain feasible within the complete sensing, preprocessing, communication, storage, and power-management pipeline [4,6,7]. These system-level requirements are summarized by the operational-envelope concept introduced in Section 2.

RQ2 is therefore supported with moderate confidence. Transformer deployment is feasible on selected constrained platforms, but portability across hardware, runtimes, compilers, precision regimes, and operational settings remains insufficiently studied. Cross-platform experiments that hold model and task constant while varying the deployment stack are a major unmet need.

5.3. RQ3: Security and Privacy Under Extreme Resource Constraints

Security and privacy evidence is substantially weaker than feasibility evidence. Constrained devices are physically exposed, computationally limited, and frequently connected through distributed or low-power infrastructure, making conventional defenses potentially expensive in memory, latency, communication, or energy [2,14,19]. Industrial-energy cybersecurity studies further illustrate why security mechanisms must be evaluated together with implementation overhead rather than treated only as conceptual requirements [50].

Three evidence strands are visible: First, local inference is frequently treated as a privacy advantage because raw data can remain on the endpoint [2,3,15]. Second, federated and distributed learning can preserve data locality but introduce communication, coordination, memory, and energy trade-offs [19]. Third, broader trustworthy-edge research identifies adversarial manipulation, model extraction, side channels, insecure updates, provenance, and physically exposed-device risks [14,51].

The direct Tiny Transformer core, however, provides little implementation-level security evidence. Busia et al. report robustness to motion-artifact noise, but this represents task robustness rather than a complete security mechanism [10]. The remaining core studies focus primarily on deployment feasibility, memory, runtime, and performance rather than quantified defensive overhead [9,10,11,12].

Consequently, privacy has somewhat stronger systems-level support than security, but Transformer-specific implementation evidence remains limited for both. Direct studies are still needed on secure updates, integrity verification, attack resilience, privacy-preserving inference, and the latency/memory/energy cost of these mechanisms under true TinyML constraints [9,10,14].

RQ3 is therefore assigned limited confidence. The field clearly recognizes the problem, but most conclusions rely on the adjacent TinyML and trustworthy-edge literature rather than on direct Tiny Transformer security experiments.

5.4. RQ4: Uncertainty, Calibration, and Reliability

Reliable constrained inference requires more than task accuracy. Deployed models may encounter sensor drift, anomalous conditions, distribution shift, or unseen operating states, making confidence estimation, calibration, selective prediction, and out-of-distribution (OOD) detection increasingly important [4,5,6].

The general uncertainty literature provides mature methodological foundations for epistemic and aleatoric uncertainty, calibration, deep ensembles, and OOD detection [52,53,54,55]. However, many of these approaches incur repeated inference, additional models, memory overhead, or monitoring cost that can conflict with TinyML resource budgets.

Adjacent constrained-AI studies show that lightweight reliability mechanisms are possible. TinyOOD demonstrates MCU-oriented OOD detection using cascading early exits and neural mean discrepancy while reducing computational demand [56]. Huber et al. show that embedded deployment choices and TensorFlow Lite conversion can affect calibration behavior across embedded systems [57]. Timing-aware and additional OOD studies further reinforce the need to treat reliability as a deployment property rather than only as a model-level statistic [58,59,60].

The direct Tiny Transformer corpus remains much weaker in this area. None of the four core studies provides a mature framework for calibration, Bayesian uncertainty, selective prediction, or streaming trust monitoring [9,10,11,12]. Busia et al. provide limited robustness evidence under sensor disturbance, but not a complete calibration or OOD pipeline [10].

Accordingly, RQ4 has limited confidence. The broader TinyML literature shows that low-overhead reliability mechanisms are technically possible, but uncertainty-aware Tiny Transformer deployment remains an open research area. Future work should report confidence calibration, OOD behavior, abstention or fallback mechanisms, and their memory, latency, and energy overhead on constrained hardware.

5.5. RQ5: Benchmarking, Reproducibility, and Sustainability

Benchmarking is one of the clearest areas in which the field has established expectations but has not yet achieved Transformer-specific standardization. MLPerf Tiny provides an important benchmark anchor for ultra-low-power inference and demonstrates the value of jointly reporting task performance, latency, and energy-related measurements [23]. Broader TinyML and trustworthy-edge reviews likewise identify hardware heterogeneity, inconsistent metric definitions, incomplete measurement disclosure, and platform-specific optimization as persistent obstacles to cumulative comparison [2,3,14].

The direct Tiny Transformer studies provide meaningful quantitative evidence but do not share a common benchmark suite, task, hardware target, precision regime, runtime stack, or measurement protocol [9,10,11,12]. Table 4 therefore supports comparison of deployment strategies, not direct numerical ranking.

Table 8 summarizes the principal sources of incompatibility and the minimum reporting required for cumulative comparison.

Table 8. Principal sources of benchmark incompatibility across direct Tiny Transformer deployment studies.

Comparison Axis	Observed Variation	Why Comparison Is Difficult	Minimum Reporting Required
Latency/ throughput	Milliseconds per inference, tokens/s, configuration-specific execution time, and relative speedup	Different computational units, input sizes, sequence lengths, hardware clocks, and execution conditions prevent direct ranking	Input/task unit, sequence/input size, batch size, clock, active cores, repetition count, preprocessing boundary, summary statistic
Memory	Parameter count, model size, Flash, SRAM, activation memory, memory traffic, and relative reductions	These metrics describe different resource dimensions and cannot be normalized without explicit definitions and baselines	Parameters, model binary, Flash, static/peak SRAM, activation memory, baseline, allocation method, measured/profiled status
Energy/power	Energy per inference, average power, peak power, or unreported standardized values	Power and energy are not interchangeable without execution time, duty cycle, and measurement boundary	Instrumentation, sampling, voltage, clock, idle treatment, execution duration, energy/inference, average and peak power, measurement boundary
Numerical precision	INT8, BF16, FP16, mixed or configuration-dependent precision	Storage, operator support, accumulation, calibration, and accuracy effects vary across formats	Weight/activation/accumulator precision, quantization method, calibration data, mixed-precision operators, task impact
Hardware	Different MCU and extreme-edge architectures, memory systems, multicore support, and accelerators	Hardware capability directly affects latency, memory behavior, and energy	Device/board, architecture, core count, clock, voltage, SRAM/Flash, memory hierarchy, accelerator use
Runtime/ toolchain	Different compilers, kernels, runtimes, fusion strategies, and code-generation paths	Performance gains may originate from software-stack optimization rather than model architecture alone	Framework, runtime/compiler versions, kernels, flags, allocator, threading/core configuration, artifacts
Task/ benchmark	Different datasets, modalities, sequence lengths, class counts, and output units	Task complexity directly affects accuracy, latency, memory, and energy	Dataset, split, input dimensions, sequence length, task metric, preprocessing, baseline, benchmark membership
Measurement boundary	Kernel-only, processor-level, board-level, or partial-system measurements	Efficient inference does not necessarily imply efficient full-system operation	State measurement boundary and include sensing, preprocessing, communication, storage, duty cycle, and operational duration where relevant

Energy and sustainability require particular care. Energy per inference and average power answer different questions and cannot be directly compared without execution time, duty cycle, and measurement context. Similarly, lower latency, reduced memory traffic, or smaller model footprint may support efficiency but do not by themselves establish sustainable system operation [11,14]. The sustainable-AI literature emphasizes the need to distinguish AI used for sustainability from the environmental impact of the AI system itself [61,62,63].

System-level energy may also include sensing, preprocessing, communication, storage, orchestration, offloading, and long-duration operation [64,65,66]. This is particularly relevant in industrial, environmental, and smart-energy applications, where the complete sensing–processing–communication pipeline may dominate operational energy [4,6,7].

Reproducibility is likewise uneven. Runtime descriptions and artifacts are available in some studies, but compiler versions, build configurations, memory placement, clock/voltage conditions, measurement scripts, and deployment settings are not consistently reported [9,11]. Reproducibility should therefore mean reconstructing the complete deployment configuration rather than only accessing source code.

RQ5 is assigned h. Benchmarking principles are well established, but Transformer-specific cross-study comparability, reproducibility, and lifecycle-oriented sustainability evidence remain incomplete. A common reporting framework should combine task performance, parameter count, numerical precision, hardware, peak memory, latency/throughput, energy/power, runtime/toolchain, measurement boundary, artifacts, and deployment context [23,57].

5.6. RQ6: Application Maturity and Deployment Readiness

Application maturity is broader in TinyML generally than in Tiny Transformer research specifically. Surveys document constrained-AI applications across healthcare, wearables, ecology, Industrial IoT, environmental sensing, robotics, and smart cities [3,15,67]. Recent studies further extend this landscape toward indoor localization, industrial monitoring, resource-constrained anomaly detection, low-power embedded vision, energy-efficient object detection, and related field applications [4,5,13,40,41].

The direct Tiny Transformer application core is considerably narrower. Busia et al. provide the clearest domain-specific real-device case through wearable ECG classification [10]; TinyFormer provides image-classification evidence under explicit MCU resource ceilings [12]; Jung et al. and Dequino et al. primarily demonstrate deployment methods and systems feasibility rather than broad application maturity [9,11].

The adjacent SLM/TLM literature indicates possible future directions for local language-centric intelligence, but the current TinyML-grounded evidence remains much stronger for specialized sensing and classification than for general embedded language-model deployment [17,18].

Additional biomedical evidence further illustrates the growing application ecosystem. PTB-XL and PTB-XL+ provide important ECG datasets for sequence-model benchmarking [68,69], while recent ECG studies span deep baselines, few-shot settings, feature-based evaluation, and Transformer-based classification [70,71,72,73]. Edge medical-vision studies likewise demonstrate application-specific ViT deployment on embedded platforms [74,75]. These works strengthen domain realism but remain adjacent to the narrow Tiny Transformer MCU-class core.

Security- and anomaly-oriented studies add further context for industrial applications [76,77], while edge–cloud collaborative architectures illustrate how constrained endpoints may increasingly participate in broader distributed-intelligence pipelines [78].

Application breadth is therefore increasing faster than deployment standardization. Field readiness still requires validation under the operational envelope defined in Section 2, including distribution shift, sensing variability, communication limitations, maintenance constraints, and long-duration energy behavior [4,5,6].

RQ6 is assigned limited confidence. Tiny Transformers are demonstrably deployable in selected applications, but the evidence does not yet support broad claims of cross-domain operational maturity. Longitudinal and field-like studies across industrial, environmental, smart-city, smart-energy, healthcare, and other constrained domains remain a priority [3,8,67].

5.7. Cross-RQ Evidence Summary

The six RQs reveal a consistent asymmetry in the evidence base. Model-design strategies and hardware feasibility are supported by direct deployment studies, whereas security, privacy, uncertainty, reproducibility, sustainability, and field maturity rely more heavily on adjacent or contextual literature. Table 9 summarizes the resulting confidence judgments.

Table 9. Narrative confidence in the six RQ-level conclusions.

RQ	Synthesis Domain	Confidence	Basis
RQ1	Model-design strategies	Moderate	Multiple complementary deployment pathways are demonstrated, but cross-task and cross-platform replication remains limited.
RQ2	Deployment bottlenecks and feasibility	Moderate	Named-device deployment confirms feasibility, although hardware and runtime heterogeneity limit generalization.
RQ3	Security and privacy	Limited	Most evidence is adjacent or conceptual; Transformer-specific defensive mechanisms and overhead measurements are sparse.
RQ4	Uncertainty and reliability	Limited	Calibration and OOD methods exist in adjacent TinyML research but are rarely integrated into Tiny Transformer deployments.
RQ5	Benchmarking, reproducibility, and sustainability	Moderate–limited	Benchmark principles are established, but Transformer-specific measurement, reproducibility, and lifecycle evidence remain inconsistent.
RQ6	Application maturity	Limited	Real-device demonstrations exist, but longitudinal and cross-domain field validation remains uncommon.

The expanded literature supports the same interpretation. Compression and optimization studies continue to strengthen the technical foundation for constrained inference [40,41,79], reliability and OOD studies provide mechanisms that could be transferred into future Tiny Transformer systems [56,57,58,59,60], and application evidence continues to expand across ECG, medical vision, localization, low-power vision, sign-language recognition, anomaly detection, Industrial IoT, and distributed edge systems [13,40,41,42,43,68,69,70,71,72,73,74,75,76,77,78].

However, these developments remain distributed across partially separate sub-literatures. The strongest current conclusion is therefore not that Tiny Transformers have already reached mature trustworthy deployment but that the technical ingredients for such systems are increasingly available, while evidence integration, standardization, and field validation remain incomplete.

6. Cross-Cutting Discussion

The main implication of this review is that the architectural frontier of TinyML is advancing faster than the evidence needed to establish trustworthy deployment. Transformer-family models can now be executed on selected MCU-class and extreme-edge platforms through memory-aware scheduling, task-specific redesign, reduced-precision/runtime co-design, and sparse architecture–deployment co-design [9,10,11,12]. The important field-level question is therefore no longer simply whether a Transformer can be made to fit on constrained hardware but whether that feasibility can be accompanied by reliability, security, reproducibility, sustainability, and credible application readiness.

The first major tension is compactness versus trustworthiness. The current deployment evidence remains strongest for measurable engineering objectives such as memory reduction, latency, precision, and runtime efficiency [9,10,11,12]. However, a model that fits within SRAM and Flash limits may still be operationally weak if its confidence is poorly calibrated, its behavior degrades under distribution shift, its security posture is unclear, or its reported performance depends on implementation assumptions that cannot be reproduced [14,51,57]. Compactness should therefore be interpreted as a necessary deployment condition rather than as evidence of deployment-grade trustworthiness.

A closely related tension is reliability and protection versus resource budgets. Uncertainty-aware inference, OOD detection, secure updating, privacy-preserving mechanisms, and runtime monitoring all consume resources that are already scarce in TinyML systems. Adjacent evidence nevertheless shows that lightweight reliability mechanisms are possible: TinyOOD demonstrates that MCU-oriented OOD handling can be implemented without assuming heavyweight inference pipelines [56], while embedded calibration studies show that model structure and deployment choices can affect confidence quality [57]. Likewise, local inference and federated approaches can improve data locality, but privacy and security are not automatic consequences of on-device execution; they introduce their own communication, synchronization, implementation, and mitigation costs [2,19,51]. Security and privacy in constrained intelligence must therefore be treated as engineering trade-offs whose protection benefit and resource overhead are measured together.

These issues become particularly important within the operational envelope defined in Section 2. Wearable, industrial, energy, environmental, and robotic systems may experience sensor drift, changing loads, environmental variability, intermittent connectivity, and restricted maintenance access [4,5,6]. Under such conditions, a slightly less accurate but calibrated model with explicit fallback behavior may be operationally preferable to a higher-accuracy model that remains confidently wrong when conditions depart from its training distribution. Trustworthiness is therefore a runtime property of the deployed system, not merely a characteristic of the trained model.

A second field-level tension concerns deployment claims versus benchmark rigor. MLPerf Tiny provides an important standardization reference because it demonstrates the value of reproducible measurement across constrained hardware [23]. However, Transformer-specific studies still differ substantially in task, hardware, runtime, precision, memory accounting, and measurement boundary [9,10,11,12]. Real-device measurement strengthens the evidence, but it does not by itself make results directly comparable. A latency value measured for one sensor-classification workload, for example, is not commensurable with token throughput or relative acceleration on another architecture. Consequently, deployment claims should be interpreted within the complete hardware–software–measurement configuration rather than as architecture-only performance statements.

This observation also changes how sustainability should be interpreted. Reduced model size, memory traffic, or inference latency can improve efficiency, but such improvements do not establish sustainable field operation unless the relevant measurement boundary is explicit. For long-lived systems, the operational cost may also include sensing, preprocessing, communication, storage, maintenance, and duty-cycle behavior. This distinction is particularly important in industrial and environmental applications, where an efficient neural-network kernel may represent only a fraction of the complete energy budget [4,5,6]. Sustainability claims should therefore move from model-level proxies toward system-level evidence.

A third tension is application enthusiasm versus deployment maturity. The broader TinyML literature already spans healthcare, industrial monitoring, smart cities, wearables, environmental sensing, and other constrained domains [3,15,67], with recent studies extending toward Industrial IoT, environmental monitoring, low-power vision, and energy-aware sensing [4,5,13]. The direct Tiny Transformer evidence, however, remains much narrower. Busia et al. provide convincing domain-specific real-device validation for wearable arrhythmia classification [10], but such evidence should not be generalized into broad cross-domain deployment readiness. An MCU demonstration establishes feasibility under a defined configuration; operational maturity additionally requires evidence on robustness over time, monitoring, maintainability, failure behavior, and field variability.

The same discipline is needed when interpreting the relationship between Tiny Transformers and language-centric compact models. On-device LM and SLM research provides important adjacent evidence on compression and local inference, but much of that literature assumes device classes substantially more capable than classical MCUs [17,18,20]. Treating “on-device” as synonymous with “TinyML” therefore risks overstating the current maturity of language-centric constrained intelligence. TinyML, embedded AI, edge AI, and Edge GenAI should remain distinct deployment categories because their memory, compute, and energy assumptions differ materially.

Taken together, these tensions suggest a practical definition of trustworthy TinyML. A deployment should not be considered trustworthy merely because a compact model executes locally with acceptable accuracy. At minimum, it should demonstrate the following: resource feasibility on named constrained hardware; sufficiently transparent and reproducible measurement; reliability behavior through calibration, OOD handling, abstention, fallback, or equivalent mechanisms when relevant; a deployment-specific security and privacy posture with measurable overhead; and a clear distinction between proof-of-concept execution and application readiness. For field-oriented systems, these requirements should additionally be evaluated within the operational envelope rather than under inference-only laboratory conditions.

This interpretation provides the main theoretical contribution of the present review. The evidence does not support the claim that Tiny Transformers have already reached a mature trustworthy deployment ecosystem. It supports a narrower but more consequential conclusion: Transformer-style TinyML has crossed the threshold of technical feasibility, while the evidence culture required for trustworthy, comparable, sustainable, and field-ready deployment remains incomplete. The next stage of the field should therefore be judged not only by whether richer models can be compressed further, but by whether their deployment claims can be reproduced, trusted, compared, and sustained under realistic constrained-system conditions.

7. Open Challenges and Future Research Agenda

The preceding synthesis shows that the central challenge is no longer demonstrating isolated Tiny Transformer feasibility but, rather, building a reproducible and trustworthy deployment ecosystem around it. The research priorities below therefore focus on the evidence needed to move from platform-specific demonstrations toward portable, measurable, and operationally credible constrained intelligence.

7.1. Model Architecture and Compression

The current evidence supports several viable deployment pathways, including task-specific downsizing, memory-aware scheduling, reduced-precision/runtime co-design, and sparse architecture–deployment co-design [9,10,11,12]. The remaining architectural challenge is not the absence of TinyML-native Transformer design but the limited replication of these approaches across tasks, MCU classes, runtimes, and trustworthiness requirements.

Future architecture studies should therefore optimize more than parameter count. Relevant objectives include peak SRAM, activation memory, operator mix, attention scheduling, precision strategy, energy behavior, calibration stability, and the overhead introduced by reliability or security mechanisms. This is particularly important for constrained temporal and multivariate workloads in condition monitoring, anomaly detection, environmental supervision, smart-energy sensing, predictive maintenance, and energy-aware automation [4,5,6]. Cross-task and cross-platform experiments are needed to establish whether current design strategies generalize beyond individually engineered demonstrations.

7.2. Runtimes, Toolchains, and Hardware-Aware Deployment

Tiny Transformer’s feasibility remains closely coupled to runtime and hardware assumptions. Memory-aware scheduling and optimized attention kernels contribute substantially to MCU deployment [9], while reduced-precision kernels and runtime co-design enable larger Transformer-derived workloads on ultra-low-power RISC-V platforms [11]. The broader TinyML literature likewise treats constrained deployment as a hardware–software co-design problem rather than a simple model-export process [1,2,3].

The main missing evidence is portability. Future studies should hold model and task constant while varying runtimes, compilers, instruction sets, memory hierarchies, and device classes. Such evaluations should release reproducible build and configuration artifacts and, for field-oriented systems, document the relevant sensing, preprocessing, communication, and power-management assumptions [4,5,6]. This would separate improvements that generalize across deployment stacks from those that depend on a particular kernel, board, or software configuration.

7.3. Security and Privacy Under Tight Budgets

Security and privacy remain substantially less mature than deployment feasibility. Privacy-preserving TinyML is increasingly associated with local or federated processing, but these approaches introduce communication, coordination, memory, and energy trade-offs [19]. The security literature additionally highlights physically exposed devices, side-channel leakage, limited isolation, and vulnerable update or query interfaces [51].

Future work should therefore move beyond generic threat enumeration toward embedded attack-and-defense experiments that quantify protection benefit together with resource overhead. Priorities include adversarial robustness under compressed inference, poisoning and backdoor resilience, secure OTA updates, model-extraction resistance, provenance or attestation, and the latency, memory, and energy cost of each defense. For physically exposed and long-lived deployments, these mechanisms should be evaluated under realistic operational conditions in industrial, energy, environmental, and other constrained systems [4,5,6].

The relevant standard should be straightforward: a security mechanism for TinyML is deployment-relevant only if the defense remains viable under the same resource ceilings as the model that it protects.

7.4. Uncertainty and Reliability Reporting

Reliability mechanisms are recognized more often than they are integrated into constrained deployment. Embedded calibration results show that confidence quality can change with model and deployment choices [57], while TinyOOD demonstrates that MCU-oriented OOD detection can be implemented without assuming heavyweight inference pipelines [56]. The broader TinyML evidence nevertheless remains sparse relative to conventional accuracy-centered evaluation [2].

Future studies should connect uncertainty estimates to actionable runtime behavior. Relevant mechanisms include abstention, re-sensing, model switching, gateway verification, hierarchical offloading, and safe fallback under explicit latency, memory, and energy budgets. These capabilities are particularly important within the operational envelope defined in Section 2, where drift, changing operating conditions, and abnormal events may invalidate assumptions made during training [4,5,6].

Reliability overhead should also be reported explicitly, including additional memory state, extra inference passes, calibration cost, latency, and energy impact. This would move uncertainty from a post hoc diagnostic metric toward an operational property of trustworthy constrained intelligence.

7.5. Benchmarking and Standardization

MLPerf Tiny provides an established methodological foundation for reproducible ultra-low-power benchmarking [23], but Tiny Transformer evaluation remains fragmented across models, workloads, platforms, numerical formats, runtimes, and measurement boundaries [9,10,11,12]. As shown in Section 5 and Table 8, similarly named metrics may represent fundamentally different quantities and, therefore, cannot be treated as directly comparable.

The next step should be a Transformer-oriented reporting discipline rather than another collection of isolated benchmark scores. At minimum, studies should report task and dataset, input dimensions or sequence length, parameter count, model storage, peak SRAM, Flash usage, precision mode, latency or throughput, energy and/or power with an explicit measurement boundary, target hardware, clock/voltage conditions, runtime/compiler configuration, and artifact availability.

Where reliability or security mechanisms are evaluated, calibration, OOD, robustness, or defensive-overhead metrics should be reported alongside inference performance. For field-oriented studies, measurement should additionally specify whether sensing, preprocessing, communication, storage, duty cycle, and long-duration operation are included [4,6,7].

Future benchmark efforts should therefore prioritize shared workloads, common reporting fields, reproducible measurement harnesses, configuration files, build instructions, model artifacts, and raw outputs. The goal is not to force heterogeneous constrained systems into a single performance ranking, but to make differences explicit enough for cumulative comparison.

7.6. Application Translation and Field Validation

Application breadth is increasing, but longitudinal and operational evidence remains limited. Reviews already document meaningful TinyML activity in healthcare, industrial monitoring, smart cities, environmental sensing, and wearables [3,15,67]. Emerging work on renewable-energy SLM benchmarking and autonomous or multi-agent language-model systems also suggests adjacent directions for industrial and energy orchestration [80,81,82]. Routing approaches such as RouteLLM provide another relevant systems concept for deciding between local and remote models, although they remain adjacent to strict MCU-class TinyML until validated under comparable constraints [83].

The priority for future research is therefore translation-oriented study design. Field-like and longitudinal pilots should distinguish clearly among hardware feasibility, application validation, and operational readiness. Relevant studies should evaluate systems such as industrial monitoring nodes, smart meters, environmental stations, smart-city sensing units, predictive-maintenance platforms, and energy-aware automation devices under realistic sensing, communication, power, maintenance, and update conditions [4,5,6].

Operational validation should also address drift, user or site heterogeneity, intermittent connectivity or power, OTA updates, monitoring requirements, failure recovery, and long-duration behavior. Such evidence is necessary to determine whether a technically successful embedded model remains dependable outside the controlled laboratory environment.

7.7. Reproducibility and Open Science

Reproducibility remains a cross-cutting requirement rather than a separate documentation issue. MLPerf Tiny demonstrates the importance of reproducible benchmark procedures, while some direct deployment studies already provide structured implementation evidence or accessible artifacts [9,11,23]. Nevertheless, deployment-critical details such as runtime configuration, preprocessing, memory accounting, power measurement, calibration procedures, and post-training optimization are still inconsistently reported [2,3,57].

Future work should therefore publish complete deployment artifacts where possible: model files, preprocessing code, build scripts, compiler and runtime versions, board configurations, optimization flags, measurement scripts, and standardized result records. For field studies, reproducibility metadata should additionally include sensor configuration, sampling strategy, communication protocol, duty cycle, power source, environmental conditions, maintenance assumptions, and the measurement boundary used for energy reporting [4,5,6].

Re-execution studies and artifact audits across laboratories and hardware platforms would be especially valuable because they could establish whether reported gains survive changes in toolchain, device, and experimental environment, rather than depending on an originating laboratory’s specific stack.

7.8. Actionable Research Agenda

Taken together, the evidence calls for a different type of TinyML research rather than simply a larger number of studies. Tiny Transformers and related compact sequence models are now technically feasible under selected constrained configurations [9,10,11,12], but portable deployment, quantified trustworthiness overhead, runtime reliability, benchmark standardization, field validation, and reproducibility remain substantially less mature [14,23,57].

Table 10 translates these gaps into an actionable research agenda.

Table 10. Actionable research agenda for trustworthy and deployment-ready Tiny Transformer systems.

Agenda Axis	Why It Remains Unresolved	Study Designs Now Needed
Model design	TinyML-native Transformer architectures remain insufficiently replicated across tasks and hardware while jointly optimizing accuracy, memory, reliability, and energy.	Cross-task and cross-platform architecture studies reporting peak SRAM, precision, energy, calibration, and operator/runtime behavior.
Runtimes and toolchains	Reported gains remain closely coupled to specific kernels, runtimes, compilers, and platform assumptions.	Multi-platform re-execution studies holding model/task constant while varying the deployment stack and releasing reproducible artifacts.
Security and privacy	Transformer-specific defenses and their resource overhead are rarely measured on true TinyML- class hardware.	Embedded attack-and-defense studies jointly reporting protection benefit and latency, memory, communication, and energy overhead.
Uncertainty and reliability	Calibration, OOD detection, and fallback behavior are not yet routine components of constrained deployment.	Runtime-oriented studies integrating calibration, abstention, re-sensing, fallback, or hierarchical offloading under explicit budgets.
Benchmarking and sustainability	Transformer-specific evaluation remains fragmented across workloads, hardware, metrics, and measurement boundaries.	Shared workloads and reporting templates covering memory, precision, latency, energy/power, hardware, toolchain, measurement boundary, and artifacts.
Field validation	Most application evidence remains laboratory- or board-centered rather than longitudinally validated.	Field-like and longitudinal pilots evaluating drift, communication, OTA updates, maintenance, failures, and long-duration operation.
Reproducibility	Critical implementation and measurement details remain inconsistently available.	Artifact audits, cross-device re-execution studies, and constrained-AI reporting checklists covering complete deployment configurations.

The resulting agenda shifts the evaluation criterion for next-generation TinyML. Progress should no longer be measured only by whether a richer model can be made smaller or faster, but by whether the resulting constrained system can be reproduced, compared, protected, monitored, and sustained under realistic deployment conditions.

8. Limitations

This review has several limitations that should be considered when interpreting its findings. First, the direct Tiny Transformer deployment literature for TinyML-class systems remains recent, small, and heterogeneous. The corpus therefore combines a narrow core of direct deployment evidence with adjacent, enabling, and contextual literature on TinyML, embedded AI, trustworthy edge intelligence, on-device language models, benchmarking, and application domains. This broader evidence base improves conceptual coverage, but some conclusions necessarily reflect convergent field-level patterns rather than large homogeneous groups of directly comparable Tiny Transformer deployments. Accordingly, claims of real-device feasibility are supported more strongly than conclusions concerning security, privacy, uncertainty, sustainability, reproducibility, and operational maturity.

Second, the included studies differ substantially in task, dataset, model family, hardware, runtime, numerical precision, optimization objective, and measurement procedure. This heterogeneity made quantitative meta-analysis inappropriate and required structured qualitative synthesis. This review therefore identifies recurring deployment mechanisms, evidence gaps, and relative maturity patterns, but it does not provide pooled effect sizes or statistical rankings of architectures, hardware platforms, or optimization strategies.

Third, quantitative comparison remains limited by inconsistent benchmark and reporting practices. Latency, throughput, memory, energy, and power are frequently measured under different hardware, runtime, precision, and measurement boundaries, while custom kernels and device-specific toolchains may strongly influence reported performance. Consequently, the numerical evidence summarized in this review should be interpreted within each study’s experimental configuration rather than as a direct cross-study leaderboard.

Fourth, trustworthiness evidence remains substantially less mature than deployment-feasibility evidence. Security, privacy, calibration, OOD detection, reliability monitoring, secure updating, provenance, and attestation are often recognized conceptually but are less frequently implemented and measured on constrained Tiny Transformer hardware. This review can therefore characterize this maturity gap and identify promising mechanisms, but it cannot establish a universally superior trustworthiness strategy or quantify standardized protection overhead across MCU-class deployments.

Fifth, application maturity remains uneven. Industrial-energy systems are used as a demanding translation and stress-test context rather than as the dominant empirical basis of the direct Tiny Transformer corpus. Most of the available evidence remains laboratory- or board-centered, and only limited longitudinal or field-oriented validation is available. Claims of application readiness were therefore interpreted more conservatively than claims of hardware feasibility, particularly when the operational envelope defined in Section 2 was not evaluated explicitly.

Sixth, the boundary around Tiny Language Models, Small Language Models, and broader on-device language models was intentionally restrictive. Studies targeting smartphones, laptops, NPUs, or higher-resource edge platforms were treated as adjacent rather than direct TinyML evidence unless severe embedded constraints were central to the contribution. This decision preserves the MCU-oriented scope of the review but may exclude techniques that could become relevant as constrained hardware and runtimes continue to evolve.

Seventh, terminology and indexing remain inconsistent across the field. Relevant studies may appear under labels such as TinyML, TinyDL, embedded AI, efficient Transformers, on-device AI, edge intelligence, or application-specific terminology. The multi-family search strategy, supplementary-source searching, sentinel-study checking, and backward/forward citation chasing were used to reduce this risk, but exhaustive retrieval cannot be guaranteed in a rapidly evolving and terminologically fragmented research area.

Finally, the OSF registration was retrospective rather than prospective. It therefore serves as a transparency and methodological-audit record, not as preregistration that constrained decisions made before the review process began. To mitigate this limitation, this manuscript aligns the reported methodology with the registered record, preserves the documented eligibility and synthesis logic, and reports a reconciled PRISMA selection trail.

9. Conclusions

This systematic review shows that Tiny Transformer deployment has progressed from conceptual possibility to demonstrated technical feasibility on selected MCU-class and extreme-edge platforms. The available evidence indicates that Transformer-family models can be adapted to severe embedded constraints through complementary strategies, including memory-aware scheduling and execution, task-specific architectural downsizing, reduced-precision and runtime co-design, and sparse architecture–deployment co-design. However, the substantial heterogeneity in tasks, hardware platforms, numerical formats, runtimes, and measurement procedures prevents direct cross-study performance ranking and limits the extent to which the current results can be generalized across constrained-device ecosystems.

The evidence is notably asymmetric across the dimensions examined in this review. Model-design strategies and hardware feasibility are supported more consistently than security, privacy, uncertainty handling, reliability, application maturity, and field-oriented validation. Benchmarking, reproducibility, and sustainability occupy an intermediate position: relevant methodological foundations and reporting practices exist, but Transformer-specific evaluation remains fragmented across platforms and measurement protocols. In particular, the current deployment evidence is substantially stronger for real-device execution and resource-aware optimization than for implemented security and privacy mechanisms, uncertainty calibration, out-of-distribution detection, reproducible deployment pipelines, standardized cross-platform benchmarking, system-level sustainability assessment, and longitudinal operational validation.

Accordingly, the current literature supports a restrained interpretation. Tiny Transformers are becoming technically viable for selected constrained intelligent systems, but trustworthy, reproducible, and operationally validated deployment remains immature. Real-device execution should therefore be interpreted primarily as evidence of feasibility rather than, by itself, as evidence of deployment readiness. Broader claims of maturity require additional evidence showing that these systems remain reliable, secure, measurable, and maintainable under realistic deployment conditions.

Future research should consequently extend beyond model compression and isolated inference performance. Studies should evaluate models across multiple constrained hardware platforms and deployment stacks; report peak memory, model storage, latency or throughput, numerical precision, energy or power, runtime and toolchain configurations, and measurement boundaries transparently; quantify the resource overhead introduced by security, privacy, calibration, out-of-distribution detection, and other reliability mechanisms; and improve reproducibility through accessible deployment artifacts and sufficiently detailed experimental configurations. Application-oriented studies should additionally progress from board-level demonstrations toward field-like and longitudinal evaluation under realistic sensing, communication, maintenance, energy, and environmental constraints.

The next phase of Tiny Transformer research is therefore not defined solely by making Transformer-family models smaller or faster. The more consequential challenge is to establish whether these models can be deployed in ways that are comparable, reproducible, reliability-aware, secure, energy-transparent, and robust within the operational constraints of real embedded systems. Advancing these dimensions is necessary to move Tiny Transformers from demonstrated constrained-device feasibility toward trustworthy and deployment-ready TinyML systems.

Appendix A.1. Scopus

TITLE-ABS-KEY(

  (‘‘tinyml’’ OR ‘‘tiny machine learning’’ OR tinydl OR

   ‘‘microcontroller-class’’ OR MCU OR ‘‘resource-constrained’’ OR

   ‘‘low-power embedded’’)

  AND

  (transformer* OR attention OR ‘‘vision transformer’’ OR

   ‘‘tiny transformer*’’ OR ‘‘small language model*’’ OR

   ‘‘tiny language model*’’ OR mobilebert OR tinyvit OR efficientformer OR

   efficientvit OR fastvit OR repvit OR tinyllama OR mamba)

  AND

  (deploy* OR inference OR runtime OR compiler OR kernel OR quantiz* OR

   pruning OR compression OR latency OR energy OR memory OR benchmark*)

)

AND PUBYEAR > 2020

AND LIMIT-TO(LANGUAGE, ‘‘English’’)

AND (LIMIT-TO(DOCTYPE, ‘‘ar’’) OR LIMIT-TO(DOCTYPE, ‘‘cp’’) OR

     LIMIT-TO(DOCTYPE, ‘‘re’’))

For the trustworthiness and application sensitivity searches, the T and A blocks, respectively, were appended inside TITLE-ABS-KEY.

Appendix A.2. Web of Science Core Collection

TS = (

  (‘‘tinyml’’ OR ‘‘tiny machine learning’’ OR tinydl OR

   ‘‘microcontroller-class’’ OR MCU OR ‘‘resource-constrained’’ OR

   ‘‘low-power embedded’’)

  AND

  (transformer* OR attention OR ‘‘vision transformer’’ OR

   ‘‘tiny transformer*’’ OR ‘‘small language model*’’ OR

   ‘‘tiny language model*’’ OR mobilebert OR tinyvit OR efficientformer OR

   efficientvit OR fastvit OR repvit OR tinyllama OR mamba)

  AND

  (deploy* OR inference OR runtime OR compiler OR kernel OR quantiz* OR

   pruning OR compression OR latency OR energy OR memory OR benchmark*)

)

AND PY = (2021--2026)

AND LA = (English)

AND DT = (Article OR Review OR Proceedings Paper)

The T and A blocks were appended as additional TS fields for the sensitivity searches.

Appendix A.3. IEEE Xplore and ACM Digital Library

(‘‘tinyml’’ OR ‘‘tiny machine learning’’ OR tinydl OR

 ‘‘microcontroller-class’’ OR MCU OR ‘‘resource-constrained’’ OR

 ‘‘low-power embedded’’)

AND

(transformer* OR attention OR ‘‘vision transformer’’ OR

 ‘‘tiny transformer*’’ OR ‘‘small language model*’’ OR

 ‘‘tiny language model*’’ OR mobilebert OR tinyvit OR efficientformer OR

 efficientvit OR fastvit OR repvit OR tinyllama OR mamba)

AND

(deploy* OR inference OR runtime OR compiler OR kernel OR quantiz* OR

 pruning OR compression OR latency OR energy OR memory OR benchmark*)

IEEE Xplore filters were 2021 onward, journals, conferences, and English where available. ACM Digital Library filters were 2021 onward and research articles, proceedings papers, and reviews/surveys. The T and A blocks were appended for sensitivity searches.

Appendix A.4. PubMed

(

  (‘‘tinyml’’[tiab] OR ‘‘tiny machine learning’’[tiab] OR tinydl[tiab] OR

   ‘‘microcontroller-class’’[tiab] OR MCU[tiab] OR

   ‘‘resource-constrained’’[tiab] OR ‘‘low-power embedded’’[tiab])

  AND

  (transformer*[tiab] OR attention[tiab] OR ‘‘vision transformer’’[tiab] OR

   ‘‘tiny transformer*’’[tiab] OR ‘‘small language model*’’[tiab] OR

   ‘‘tiny language model*’’[tiab] OR mobilebert[tiab] OR tinyvit[tiab] OR

   efficientformer[tiab] OR efficientvit[tiab] OR fastvit[tiab] OR

   repvit[tiab] OR tinyllama[tiab] OR mamba[tiab])

  AND

  (deploy*[tiab] OR inference[tiab] OR runtime[tiab] OR compiler[tiab] OR

   kernel[tiab] OR quantiz*[tiab] OR pruning[tiab] OR compression[tiab] OR

   latency[tiab] OR energy[tiab] OR memory[tiab] OR benchmark*[tiab])

)

AND 2021/01/01:3000[dp]

AND english[la]

The T and A terms were appended with the [tiab] field for the sensitivity searches.

Appendix A.5. ScienceDirect, SpringerLink, and MDPI

(‘‘tinyml’’ OR ‘‘tiny machine learning’’ OR tinydl OR

 ‘‘microcontroller-class’’ OR MCU OR ‘‘resource-constrained’’ OR

 ‘‘low-power embedded’’)

AND

(transformer* OR attention OR ‘‘vision transformer’’ OR

 ‘‘tiny transformer*’’ OR ‘‘small language model*’’ OR

 ‘‘tiny language model*’’ OR mobilebert OR tinyvit OR efficientformer OR

 efficientvit OR fastvit OR repvit OR tinyllama OR mamba)

AND

(deploy* OR inference OR runtime OR compiler OR kernel OR quantiz* OR

 pruning OR compression OR latency OR energy OR memory OR benchmark*)

Platform filters were 2021 onward, English, and articles, reviews, or conference papers where the interface permitted. The T and A blocks were appended for sensitivity searches.

Appendix A.6. arXiv

(‘‘tinyml’’ OR ‘‘tiny machine learning’’ OR MCU OR ‘‘resource-constrained’’

 OR  ‘‘low-power embedded’’)

AND

(transformer OR attention OR ‘‘tiny transformer’’ OR mobilebert OR tinyvit

 OR efficientformer OR efficientvit OR fastvit OR repvit OR tinyllama OR

 mamba)

AND

(deployment OR inference OR runtime OR compiler OR quantization OR pruning

 OR compression OR latency OR energy OR memory OR benchmark)

arXiv was used for horizon scanning and recovery of archival versions, rather than as the primary empirical foundation.

Appendix A.7. Google Scholar and Citation Chasing

The reproducible Google Scholar sensitivity queries recorded in the retrospective OSF methodological record were as follows:

‘‘tinyml’’ transformer deployment inference MCU

‘‘tiny machine learning’’ attention quantization pruning memory energy

(‘‘tiny transformer’’ OR mobilebert OR tinyvit OR efficientformer OR

 efficientvit OR fastvit OR repvit OR tinyllama OR mamba)

(MCU OR microcontroller OR ‘‘resource-constrained’’ OR ‘‘low-power

 embedded’’)

Backward and forward citation chasing used retained reviews and sentinel studies, Google Scholar, Crossref-style citation systems, publisher pages, and reference lists. Preprint/journal duplicates were manually reconciled in favor of the archival version.