SLM on ESP32-S3: Training a Small Language Model on an $8 Microcontroller 2026

Introduction — Why Run a Language Model on an $8 Microcontroller?

The idea of running a language model on a microcontroller that costs less than a cup of coffee sounds improbable, but the ESP32-S3 makes it a reality. With dual-core Xtensa LX7 processors running at up to 240 MHz, 512 KB of internal SRAM, and support for up to 8 MB of external octal SPI PSRAM, this $6–8 chip can execute small language models (SLMs) entirely offline — no cloud, no WiFi dependency, no API keys required.

The TinyML market is projected to grow at a compound annual growth rate (CAGR) of 20–25% through 2030, driven by demand for privacy-preserving edge AI. Running SLMs on microcontrollers eliminates the latency, cost, and privacy risks of cloud-based inference. Your data never leaves the device. For applications like voice assistants, industrial control, and autonomous sensor nodes, this is transformative.

This guide walks you through the complete pipeline: selecting a model architecture that fits within the ESP32-S3’s memory constraints, training on a suitable dataset, quantizing weights to INT8 or 4-bit, compiling with tools like SynapEdge or a custom C runtime, and finally flashing and running inference on real hardware. By the end, you will have a working SLM running on a $8 microcontroller.

ESP32-S3 Hardware Overview — What Makes It Suitable for SLM

The ESP32-S3 is not a general-purpose application processor, but it packs surprising capability for neural network inference. Understanding its hardware constraints is the first step to successful SLM deployment.

Processor and Memory Architecture

The ESP32-S3 features a dual-core Xtensa LX7 CPU clocked at up to 240 MHz. Critically, it includes AI acceleration vector instructions — SIMD extensions specifically designed for neural network operations like matrix multiplication and convolution. These instructions can provide 2–4x speedup for inference compared to scalar code.

Memory Budget for SLM

The practical memory constraint is the PSRAM. With 8 MB of PSRAM, you can fit approximately:

• 1M parameters at FP32: ~4 MB — leaves room for runtime buffers
• 1.16M parameters at INT8: ~1.17 MB — the sweet spot for circuitheroesLM
• 312K parameters at FP32: ~1.2 MB — used by esp32-gpio-llm
• 4-bit quantized models: 4x smaller than FP32, enabling ~4M parameters in 2 MB

The flash memory stores the firmware and can also hold model weights that are read in place (memory-mapped flash), which is how many ESP32-S3 SLM deployments work — the model lives in the flash partition and is accessed directly without copying to RAM.

Choosing Your Model Architecture — Parameter Budgets and Trade-offs

Not every language model architecture is suitable for microcontroller deployment. The key constraint is the parameter budget, which directly determines model capacity and inference speed.

Architecture Options

Tiny Transformer (Decoder-only): The most popular choice for microcontroller SLMs. A 2-layer, 4-head transformer with embedding dimension 128 and hidden dimension 256 yields approximately 300K–500K parameters. This is the architecture behind esp32-gpio-llm (312K params).

Engineering State Router (ESR): Used by circuitheroesLM (1.16M params), this architecture is optimized for flash bandwidth. It uses a state-routing mechanism that minimizes random access to model weights, making it ideal for memory-mapped flash storage where sequential reads are much faster than random access.

Per-Layer Embeddings (PLE): Adapted from Google’s Gemma architecture, PLE distributes embedding layers across devices. Used in the distributed 56M-parameter setup across 3 ESP32-S3 boards, this approach scales beyond single-chip limits.

Parameter Budget Guidelines

For a first project, start with the 300K–500K parameter range. It fits comfortably in PSRAM, runs in under a second, and still produces coherent short-form text.

Setting Up the Development Environment (ESP-IDF, SynapEdge, Arduino)

You have three main paths for developing SLM firmware on the ESP32-S3. Each has different trade-offs.

Option 1: ESP-IDF (Recommended for Full Control)

The Espressif IoT Development Framework (ESP-IDF) is the official SDK and gives you the most control over hardware features, including the AI vector instructions.

# Install ESP-IDF on Ubuntu/Debian
sudo apt-get install git wget flex bison gperf python3 python3-pip python3-venv cmake ninja-build ccache libffi-dev libssl-dev dfu-util libusb-1.0-0

mkdir -p ~/esp
cd ~/esp
git clone --recursive https://github.com/espressif/esp-idf.git
cd esp-idf
./install.sh esp32s3
source export.sh

Option 2: SynapEdge Compiler (Simplest Path)

SynapEdge converts ONNX models to portable ANSI C code that runs on any microcontroller. This is the approach used by the asad-shafi project for running a TinyStoriesV2-trained model on ESP32-S3.

# Install SynapEdge
pip install synapedge

# Convert ONNX model to C
synapedge compile model.onnx --target esp32s3 --output ./esp32_model

The SynapEdge approach is hardware-agnostic — the same compiled C code can run on ARM Cortex-M, RISC-V, or Xtensa cores with minimal changes.

Option 3: Arduino ESP32 (Fastest Prototyping)

For rapid prototyping, the Arduino core for ESP32 provides a familiar API with built-in PSRAM support.

# Install via Arduino CLI
arduino-cli core update-index
arduino-cli core install esp32:esp32
arduino-cli board attach esp32:esp32:esp32s3

The Arduino path is best for quick experiments but lacks direct access to the AI vector instructions, which means slower inference.

Step 1 — Preparing and Quantizing Your Model (ONNX Export, INT8/4-bit)

Before you can deploy a model to the ESP32-S3, you need to train it, export it to ONNX, and quantize the weights to fit within the memory budget.

Training a Tiny Transformer

Here is a complete training script for a 312K-parameter transformer suitable for ESP32-S3 deployment:

import torch
import torch.nn as nn
import torch.optim as optim
from torch.utils.data import Dataset, DataLoader

class TinyTransformer(nn.Module):
    def __init__(self, vocab_size=1000, d_model=128, nhead=4, 
                 num_layers=2, dim_feedforward=256, max_len=64):
        super().__init__()
        self.embedding = nn.Embedding(vocab_size, d_model)
        self.pos_encoding = nn.Parameter(torch.randn(1, max_len, d_model))
        encoder_layer = nn.TransformerEncoderLayer(
            d_model=d_model, nhead=nhead, 
            dim_feedforward=dim_feedforward, batch_first=True
        )
        self.transformer = nn.TransformerEncoder(encoder_layer, num_layers=num_layers)
        self.output = nn.Linear(d_model, vocab_size)
        
    def forward(self, x):
        x = self.embedding(x) + self.pos_encoding[:, :x.size(1), :]
        x = self.transformer(x)
        return self.output(x)

# Count parameters
model = TinyTransformer()
params = sum(p.numel() for p in model.parameters())
print(f"Model parameters: {params:,}")  # ~312K

Train this model on a domain-specific dataset. The TinyStoriesV2 dataset (used by the asad-shafi project) works well for general text generation. For domain-specific tasks like GPIO control, create a synthetic dataset of command-description pairs.

Exporting to ONNX

dummy_input = torch.randint(0, 1000, (1, 32))
torch.onnx.export(
    model, dummy_input, "model.onnx",
    input_names=["input_ids"],
    output_names=["logits"],
    dynamic_axes={"input_ids": {0: "batch", 1: "seq_len"}}
)

Quantization Strategies

For most SLM applications on ESP32-S3, INT8 quantization is the sweet spot. It reduces a 1.16M-parameter model from 4.6 MB (FP32) to 1.17 MB while retaining over 97% of accuracy.

import onnx
from onnxruntime.quantization import quantize_dynamic, QuantType

model_fp32 = "model.onnx"
model_int8 = "model_int8.onnx"
quantize_dynamic(model_fp32, model_int8, weight_type=QuantType.QInt8)

Step 2 — Compiling for ESP32-S3 with SynapEdge or Custom C Runtime

Once you have a quantized ONNX model, the next step is compiling it into code that runs on the ESP32-S3.

Method A: SynapEdge Compilation (Recommended for Beginners)

# Compile ONNX to portable C
synapedge compile model_int8.onnx \
    --target esp32s3 \
    --output ./esp32_model \
    --optimize flash_bandwidth \
    --quantize int8

# This generates:
# - esp32_model/model.c       (inference engine)
# - esp32_model/model.h       (API header)
# - esp32_model/weights.bin   (quantized weights)
# - esp32_model/README.md     (integration guide)

The --optimize flash_bandwidth flag is critical — it restructures memory access patterns for sequential flash reads, which is 10–50x faster than random access on SPI flash.

Method B: Custom C Runtime (Maximum Performance)

For projects that need every cycle of performance, write a custom C inference engine. The circuitheroesLM project uses this approach with its Engineering State Router architecture.

// Simplified inference loop for ESP32-S3
#include "esp32_model.h"

// Model weights stored in flash partition
extern const uint8_t model_weights[];

int32_t slm_infer(int32_t* input_ids, int num_tokens) {
    int32_t hidden[256];  // PSRAM buffer
    int32_t logits[1000]; // output buffer
    
    // Embedding lookup (flash-resident)
    embed_lookup(input_ids, num_tokens, hidden);
    
    // Transformer layers with AI vector instructions
    for (int layer = 0; layer < NUM_LAYERS; layer++) {
        // Use Xtensa LX7 vector SIMD for attention
        xtensa_simd_mul(hidden, model_weights + layer * WEIGHT_OFFSET, 
                       HIDDEN_DIM, HIDDEN_DIM);
        // ReLU activation
        relu_inplace(hidden, HIDDEN_DIM);
    }
    
    // Output projection
    output_proj(hidden, logits);
    return argmax(logits, VOCAB_SIZE);
}

Method C: ESP-NN Library

Espressif provides the ESP-NN library with optimized neural network kernels that leverage the AI vector instructions. It includes optimized implementations for fully connected layers, activation functions, and softmax.

#include "esp_nn.h"

// ESP-NN optimized matrix multiply
void esp_nn_fully_connected_s8(
    const int8_t *input_data,
    const int8_t *weight_data,
    const int32_t *bias_data,
    int8_t *output_data,
    int input_size, int output_size, int batch_size
);

Step 3 — Flashing and Running Inference on the ESP32-S3

With the compiled model and firmware ready, it is time to flash the ESP32-S3 and run your first inference.

Building the Firmware with ESP-IDF

# Create a new ESP-IDF project
cp -r ./esp32_model ~/esp/projects/slm_inference
cd ~/esp/projects/slm_inference

# Configure PSRAM and flash settings
idf.py set-target esp32s3
idf.py menuconfig
# Navigate to:
#   Component config → ESP32S3-specific → Support for external, SPI-connected RAM → Enable
#   Set PSRAM clock to 80 MHz, Quad mode

# Configure flash partition for model weights
# Add to partitions.csv:
# model, data, spi_flash, , 4M,

# Build and flash
idf.py build
idf.py -p /dev/ttyUSB0 flash monitor

Running Inference

Once flashed, the ESP32-S3 runs the SLM inference loop. Here is a minimal main application:

void app_main(void) {
    // Initialize PSRAM
    esp_psram_init();
    
    // Load model weights from flash partition
    const esp_partition_t *model_part = esp_partition_find_first(
        ESP_PARTITION_TYPE_DATA, ESP_PARTITION_SUBTYPE_ANY, "model");
    
    // Allocate input/output buffers in PSRAM
    int32_t *input_ids = heap_caps_malloc(64 * sizeof(int32_t), MALLOC_CAP_SPIRAM);
    int32_t *output = heap_caps_malloc(1000 * sizeof(int32_t), MALLOC_CAP_SPIRAM);
    
    // Tokenize input string
    int num_tokens = tokenize("turn on the light", input_ids, 64);
    
    // Run inference
    uint64_t start = esp_timer_get_time();
    slm_infer(input_ids, num_tokens, output);
    uint64_t elapsed = esp_timer_get_time() - start;
    
    printf("Inference completed in %lld ms\n", elapsed / 1000);
    
    // Decode output token
    char response[64];
    detokenize(output, response, 64);
    printf("Response: %s\n", response);
}

Verifying Inference on Real Hardware

The circuitheroesLM project reports 25.35 model steps per second with 1.16M parameters on an ESP32-S3 N16R8 module. The esp32-gpio-llm project achieves 150ms–1.5s inference latency with 312K parameters. Your results will vary based on model size, quantization, and optimization level.

Performance Benchmarks — Latency, Memory, and Accuracy Results

Here is a consolidated benchmark table based on real ESP32-S3 deployments:

Key Performance Factors

1. Flash bandwidth is the bottleneck: SPI flash reads at 40–80 MB/s, but random access adds significant overhead. Models optimized for sequential flash reads (like ESR) perform 3–5x faster than naive implementations.

2. PSRAM vs. Flash for weights: Reading weights from PSRAM is faster but consumes precious RAM. Most deployments read weights directly from flash (memory-mapped) and only keep the current layer’s activations in PSRAM.

3. AI vector instructions: Using the Xtensa LX7 SIMD instructions for matrix multiplication provides 2–4x speedup over scalar code. Enable them in ESP-IDF with CONFIG_ESP32S3_AI_VECTOR=y.

Advanced: Distributed Inference Across Multiple ESP32-S3 Boards

When a single ESP32-S3 cannot fit your model, you can distribute inference across multiple boards using ESP-NOW, Espressif’s connectionless wireless protocol.

Architecture

The wladimiravila project demonstrates a 56M-parameter model distributed across 3 ESP32-S3 boards:

• Board 0 (Coordinator): Input tokenization, first embedding layers, output decoding
• Board 1 (Worker): Middle transformer layers (layers 2–4)
• Board 2 (Worker): Final transformer layers (layers 5–6), output projection

Each board holds a portion of the model weights in its 16 MB flash. Intermediate activations are transmitted via ESP-NOW, which has a typical latency of 2–5ms per packet.

Implementation Sketch

// Coordinator board
void coordinator_infer(int32_t* input_ids) {
    int32_t embeddings[256];
    embed_lookup(input_ids, 4, embeddings);
    
    // Send embeddings to Board 1 via ESP-NOW
    esp_now_send(board1_mac, (uint8_t*)embeddings, sizeof(embeddings));
    
    // Wait for final logits from Board 2
    int32_t logits[1000];
    esp_now_receive(board2_mac, (uint8_t*)logits, sizeof(logits));
    
    int token = argmax(logits, 1000);
    printf("Generated: %s\n", detokenize(token));
}

This approach scales to much larger models but introduces wireless latency. The distributed setup achieves approximately 5 seconds per token for the 56M-parameter model, which is usable for non-real-time applications like autonomous agents.

Real-World Applications — GPIO Control, Voice Assistants, Autonomous Agents

The ESP32-S3 SLM ecosystem has produced several compelling real-world applications.

Natural Language GPIO Control

The esp32-gpio-llm project translates natural language commands directly to GPIO actions. A user says “turn on the light and set fan to medium speed,” and the SLM outputs the corresponding GPIO register values. With 84.4% exact-match accuracy, this is already practical for home automation.

// GPIO command from SLM output
void execute_gpio_command(const char* command) {
    if (strcmp(command, "GPIO_SET_2_HIGH") == 0) {
        gpio_set_level(GPIO_NUM_2, 1);
    } else if (strcmp(command, "GPIO_SET_2_LOW") == 0) {
        gpio_set_level(GPIO_NUM_2, 0);
    }
    // ... additional commands
}

Voice-Activated Local AI Assistant

The xiaoclaw project combines SLM inference with voice I/O on a single ESP32-S3 board. It runs a ReAct (Reasoning + Acting) agent loop entirely on-device, with a self-learning system that crystallizes multi-step tasks into reusable skills stored in a memory hierarchy (L0–L4).

This requires the larger 32 MB Flash + 8 MB PSRAM configuration but demonstrates the full potential of on-device AI agents.

Autonomous Sensor Nodes

ESP32-S3 SLMs can act as autonomous decision-makers in sensor networks. Instead of sending raw sensor data to the cloud for processing, the microcontroller runs local inference to classify events, generate alerts, or trigger actuators — all while consuming milliwatts of power.

Troubleshooting Common Issues (PSRAM, Flash Size, Inference Speed)

PSRAM Not Detected

Symptom: esp_psram_init() returns ESP_FAIL or the system crashes when allocating PSRAM.

Solution: Ensure your board has PSRAM populated (N16R8 variant has 8 MB PSRAM, N16R2 has 2 MB). Verify the PSRAM configuration in menuconfig:

• Enable SPIRAM and set to Octal SPI PSRAM
• Set PSRAM clock to 80 MHz (not 120 MHz, which can cause instability)
• Enable SPIRAM_USE_CAPS_ALLOC for dynamic allocation

Model Too Large for Flash

Symptom: Build fails with partition overflow, or the device crashes during model loading.

Solution:

• Reduce model size with more aggressive quantization (4-bit instead of INT8)
• Prune less important weights (structured pruning can remove 30–50% of parameters with minimal accuracy loss)
• Use a larger flash module (N16R8 has 16 MB flash; custom boards can use up to 64 MB)

Slow Inference Speed

Symptom: Inference takes 5+ seconds per token.

Solution:

• Enable AI vector instructions in ESP-IDF (CONFIG_ESP32S3_AI_VECTOR=y)
• Optimize for sequential flash reads (restructure weight access patterns)
• Reduce sequence length (shorter context = faster inference)
• Use INT8 or 4-bit quantization (smaller weights = less flash bandwidth)
• Consider distributed inference for models over 2M parameters

Random Crashes During Inference

Symptom: ESP32-S3 resets or throws a panic during model inference.

Solution:

• Check stack size: increase CONFIG_ESP_MAIN_TASK_STACK_SIZE to 8192 or higher
• Ensure all large buffers are allocated in PSRAM, not internal SRAM
• Verify flash timing: reduce SPI flash frequency if using long PCB traces
• Add cache prefetch hints for sequential weight access

Conclusion — The Future of Edge AI with ESP32-S3

Training and deploying a small language model on an $8 ESP32-S3 microcontroller is not just possible — it is practical today. With model sizes ranging from 312K to 1.16M parameters fitting comfortably in PSRAM, inference times under 1.5 seconds, and accuracy exceeding 84% for domain-specific tasks, the ESP32-S3 has become the most accessible platform for on-device language AI.

The ecosystem is growing rapidly. Tools like SynapEdge simplify the ONNX-to-firmware pipeline. Open-source projects like circuitheroesLM, esp32-gpio-llm, and xiaoclaw provide complete reference implementations. Distributed inference across multiple boards pushes the parameter ceiling to 56M and beyond.

For developers, the path is clear: start with a 300K-parameter transformer on a single ESP32-S3, quantize to INT8, optimize for flash bandwidth, and expand from there. The $8 microcontroller is no longer just for blinking LEDs — it is running language models, and the technology is only getting better.

FAQ

What is the smallest language model that can run on ESP32-S3?

The smallest practical SLM for ESP32-S3 has around 100K–312K parameters. The esp32-gpio-llm project runs a 312K-parameter model in 1.2 MB of FP32 weights, achieving 150ms–1.5s inference latency. Even smaller models (50K–100K parameters) are possible for highly constrained tasks like binary classification or keyword spotting.

Do I need external PSRAM to run an SLM on ESP32-S3?

Yes, for any model larger than about 50K parameters. The ESP32-S3 has only 512 KB of internal SRAM, and the operating system and runtime consume roughly 100 KB of that. External PSRAM (2–8 MB) is required for model weights and activation buffers. Use the N16R8 module variant which includes 8 MB PSRAM and 16 MB flash.

Can I train the model directly on the ESP32-S3?

No — the ESP32-S3 lacks the memory and compute to train even a small language model. Training is done on a PC or cloud GPU using PyTorch or TensorFlow, then the trained model is exported to ONNX, quantized, and compiled for the ESP32-S3. The microcontroller handles inference only.

How does distributed inference work across multiple ESP32-S3 boards?

Distributed inference splits the model layers across multiple ESP32-S3 boards connected via ESP-NOW (Espressif’s wireless protocol). Each board holds a portion of the model weights in its flash. Intermediate activations are transmitted wirelessly between boards. The wladimiravila project demonstrates a 56M-parameter model across 3 boards with ~5s per token latency.

What is the power consumption of an ESP32-S3 running SLM inference?

An ESP32-S3 running SLM inference consumes approximately 80–160 mA at 3.3V (264–528 mW) during active inference, and can drop to deep sleep mode at ~10 µA between inference events. This makes battery-powered SLM deployments feasible for applications that run inference intermittently, such as sensor nodes or voice-triggered assistants.