Feasibility analysisPublished unedited

The F.A.R.C.E. Flash: A Feasibility Analysis of MicroSD-Backed LLM Inference Architectures

This analysis models a 128 GB configuration. Farce Systems ships 1.28 TB. See the campaign page for our position on this.

Independent feasibility analysis. Commissioned and published unedited by Farce Systems.
Prepared with AI research tooling. Reviewed for consistency, not corrected.

Executive Summary and Market Context

In the year 2026, the deployment of large language models (LLMs) has reached a critical inflection point characterized by a severe hardware accessibility crisis. The proliferation of agentic frameworks, multimodal inputs, and long-context reasoning models has driven enterprise and enthusiast demand for high-capacity memory architectures to unprecedented levels. Consequently, manufacturers of dynamic random-access memory (DRAM) and solid-state drives (SSDs) have faced acute supply chain pressures, resulting in a sharp rise in the price per gigabyte of both volatile and non-volatile storage. This economic reality has disproportionately impacted retail consumers, independent machine learning developers, and academic researchers operating under strict budgetary constraints.

The industry benchmark for entry-level, high-capacity local inference in 2026 is the NVIDIA DGX Spark. Retailing for approximately $4,700, the DGX Spark provides 128 GB of unified RAM, offering sufficient memory bandwidth and capacity to comfortably host state-of-the-art models such as the 70-billion parameter Llama 3.3.¹ While the DGX Spark democratizes access relative to hyperscale datacenter clusters, an upfront capital expenditure of nearly five thousand dollars remains a formidable barrier for the broader enthusiast community. This financial exclusion has catalyzed the proposal of an experimental, crowd-funded developer kit designed to emulate the DGX Spark’s memory capacity at a fraction of the cost: the Flash Array for Resource-Constrained Environments (F.A.R.C.E. Flash). The theoretical premise of the F.A.R.C.E. Flash is to substitute advanced unified memory and NVMe hierarchies with a massive, parallel array of the lowest-cost, most widely available flash storage medium on the market: consumer-grade MicroSD cards. By aggregating standard RAM with dozens of MicroSD cards managed by custom firmware, the system aims to host the exact same parameter sizes as the DGX Spark.

The following analysis conducts an exhaustive engineering, economic, and operational review of the F.A.R.C.E. Flash architecture. By examining the underlying requirements of LLM memory bandwidth, the electrical realities of massive printed circuit board (PCB) trace routing, the thermodynamics of plastic-encased flash memory, and the algorithmic constraints of modern inference engines, this report evaluates whether a budget-conscious, highly absurd hardware escalation can successfully disrupt the 2026 machine learning hardware market.

Methodological Framework: The Escalation of Absurd Logic

To understand the engineering architecture of the F.A.R.C.E. Flash, one must first understand the methodology that underpins its design. The development of this system closely mirrors the comedic and analytical structure pioneered by the television series Nathan for You, wherein a genuine, identifiable problem is addressed with a strictly logical, yet exponentially escalating and absurd series of solutions.³

The problem identified by the F.A.R.C.E. Flash developers is genuine: independent researchers require 128 GB of memory to run modern LLMs, but they cannot afford the DGX Spark. The proposed solution follows a rigid, albeit unorthodox, economic logic: if High Bandwidth Memory (HBM) and DDR5 are too expensive, and NVMe SSDs are subject to price premiums, one must utilize the cheapest solid-state storage available per gigabyte. In 2026, high-capacity MicroSD cards represent the absolute floor of NAND flash pricing.

However, standard MicroSD cards are egregiously slow. The logical escalation dictates that to overcome the speed deficit, the system must multiplex dozens of MicroSD cards in parallel, effectively creating a massive Redundant Array of Independent Disks (RAID 0) to aggregate bandwidth. When this parallelization inevitably encounters physical limitations—such as signal crosstalk, operating system page fault limits, and severe thermal throttling—the project does not abandon the core premise. Instead, it commits entirely to the absurdity, proposing custom field-programmable gate array (FPGA) controllers, completely rewritten Linux kernels, and extreme mathematical quantization to force the architecture to function.³

This methodology results in a cascading chain of complex engineering interventions deployed solely to sustain a fundamentally flawed initial premise. The subsequent sections of this report will dissect these interventions, evaluating the viability of each step in the F.A.R.C.E. Flash's escalating architecture.

The LLM Memory Bottleneck: Capacity Versus Bandwidth

To accurately assess the feasibility of substituting MicroSD cards for unified RAM, the fundamental mechanics of transformer-based LLM inference must be established. The execution of an LLM is broadly divided into two phases: the prefill phase (processing the input prompt) and the decode phase (autoregressively generating the output tokens).⁶

The Dominance of Memory Bandwidth in the Decode Phase

During the decode phase, the inference engine is strictly memory-bandwidth bound rather than compute bound. To generate a single new token, the entire model parameter set must be loaded from memory into the compute units (e.g., GPU Streaming Multiprocessors or CPU cores) for a single forward pass.²

For a dense model like Llama 3.3 70B, quantized to 8-bit precision (FP8 or INT8), the parameters occupy approximately 70 GB of memory.² Therefore, generating one token requires moving 70 GB of data. On advanced hardware like the NVIDIA H200, which features 4.8 TB/s of memory bandwidth, this operation occurs in milliseconds, yielding high token-per-second (tok/s) throughput.² If the memory bandwidth is restricted, the compute units sit entirely idle waiting for data to arrive over the bus.⁷

The Exponential Growth of the Key-Value (KV) Cache

Beyond the static model weights, the inference engine must manage the Key-Value (KV) cache. The KV cache stores the key and value vectors computed by the attention mechanism during previous steps, preventing the need to recompute the entire sequence history for every new token.⁶

The KV cache grows linearly with both the batch size and the context length. Modern architectures utilize Grouped-Query Attention (GQA) to mitigate this growth; for instance, Llama 3.3 70B utilizes 8 KV heads instead of the standard 64 query heads.⁸ Despite this optimization, the memory requirements remain staggering at long context windows.

If an independent researcher wishes to run a 70B model at 8-bit precision with a 128K context window, the system requires a minimum of 70 GB for weights, 20 GB for the KV cache, and an additional overhead buffer for the runtime and operating system. This pushes the total memory footprint dangerously close to 100 GB, perfectly validating the DGX Spark's 128 GB unified memory design.¹ The F.A.R.C.E. Flash architecture must find a way to accommodate this 100 GB footprint using an array of MicroSD cards.

Theoretical Frameworks for Storage-Backed Inference

The machine learning community has long recognized the capacity limits of traditional VRAM and DRAM. In response, a robust ecosystem of offloading architectures has emerged, seeking to treat non-volatile storage as a functional extension of system memory.

Contextual Sparsity and Weight Preloading

The theoretical foundation that emboldens the F.A.R.C.E. Flash developers is based on Apple's "LLM in a flash" research. This study demonstrated that Large Language Models exhibit a high degree of contextual sparsity.¹² During the generation of any specific token, the Feed Forward Network (FFN) layers—which comprise the bulk of the model's parameters—exhibit sparsity levels exceeding 90%.¹² Consequently, an inference engine does not technically need to load the entire 70 GB model from flash storage for every token; it only needs to load the 2% to 5% of weights that are "active" for that specific forward pass.¹²

Advanced frameworks such as ActiveFlow capitalize on this contextual sparsity by

implementing cross-layer active weight preloading. Because the input activations of attention and MLP blocks exhibit high cross-layer similarity, the framework can predict which weights will be active in subsequent layers.¹⁴ The system loads these predicted active weights from flash storage into DRAM in large, contiguous chunks, overlapping the storage I/O transfers with the ongoing mathematical computations of the current layer.¹⁴

High-Throughput KV Cache Offloading

While weight offloading leverages sparsity, managing the massive KV cache requires a different approach. Systems like FlexGen, DeepSpeed-ZeRO Inference, and vLLM target

throughput-oriented batch processing, where latency (the time it takes to generate a single token) is sacrificed in favor of overall throughput (the total number of tokens processed per hour).¹⁵

The industry standard serving engine, vLLM, has recently integrated sophisticated secondary storage support via the LMCache connector.¹⁸ LMCache enables the offloading of KV cache objects from fast distributed memory down to local NVMe solid-state drives.¹⁰ It operates asynchronously as a background subsystem: as the GPU processes prompts, newly generated KV blocks that exceed VRAM capacity are pushed to CPU memory, and subsequently evicted to the NVMe SSD using Least Recently Used (LRU) eviction policies.²⁰ When a multi-turn conversation resumes, LMCache fetches the "cold" historical KV blocks back from the SSD, bypassing the need to recompute the entire prompt from scratch.²¹

The fatal flaw in adapting these frameworks for the F.A.R.C.E. Flash is that they were explicitly engineered for the performance characteristics of PCIe-attached NVMe SSDs. As

demonstrated in the next section, substituting an NVMe SSD with an array of MicroSD cards introduces mathematical and physical bottlenecks that break the fundamental assumptions of these offloading algorithms.

The Bandwidth and Latency Chasm: NVMe vs. MicroSD

Enterprise-grade NVMe SSDs communicate directly with the host CPU via peripheral component interconnect express (PCIe) lanes. A standard PCIe Gen 4.0 x4 connection provides up to 14 GB/s of theoretical bandwidth.²³ More importantly, the NVMe protocol is designed for massive parallelism, utilizing up to 64,000 submission and completion queues, each capable of holding 64,000 commands.²³ This allows the drive to handle tens of thousands of random 4K read and write operations simultaneously, resulting in random read latencies as low as 20 to 70 microseconds.²³

Conversely, the MicroSD standard was engineered primarily for sequential media writing, such as recording high-definition video.²⁴ MicroSD cards utilize rudimentary, fixed-function controllers that lack onboard DRAM caches and support incredibly shallow command queue depths, often limited to just 1 to 4 commands.²⁵ The controllers operate in a half-duplex configuration, prohibiting simultaneous read and write operations.²⁶

Interface Protocols: SPI and SDIO

MicroSD cards interface with host hardware through two primary protocols: the Serial Peripheral Interface (SPI) and Secure Digital Input Output (SDIO).

SPI is a legacy, synchronous master-slave protocol utilizing four wires: Serial Clock (SCLK), Master Out Slave In (MOSI), Master In Slave Out (MISO), and Chip Select (CS).²⁷ While SPI is ubiquitous in hobbyist hardware because it avoids proprietary licensing fees and

non-disclosure agreements, it is severely bottlenecked.²⁷ Operations are conducted bit-by-bit in a single lane, rendering it entirely unsuitable for gigabyte-scale data transfers.²⁷

To achieve higher speeds, the F.A.R.C.E. Flash must utilize the SDIO protocol, specifically operating in 4-bit mode under the UHS-I (Ultra High Speed Phase I) specification. By utilizing a 208 MHz clock, a UHS-I SDIO bus can achieve theoretical maximum transfer speeds of 104 MB/s per card.²⁹

Even if the F.A.R.C.E. Flash were to utilize the bleeding-edge "MicroSD Express"

standard—which forces a single-lane PCIe Gen 3 interface onto the MicroSD form factor—the random input/output operations per second (IOPS) remain crippled by the lack of an advanced SSD controller and DRAM buffer.²⁵ The fastest MicroSD Express cards deliver only 0.3% of the random I/O performance of a mid-tier NVMe SSD.²⁵

Because LLM offloading algorithms like ActiveFlow and LMCache rely heavily on fetching small, fragmented blocks of KV cache and sparse weights (essentially random read operations), the abysmal IOPS and high latency of the MicroSD architecture will introduce catastrophic pipeline stalls, halting the GPU compute cores for hundreds of milliseconds while waiting for data.²⁶ The F.A.R.C.E. Flash must attempt to overcome this by scaling horizontally, networking dozens of MicroSD cards in parallel to aggregate their bandwidth.

Hardware Architecture: Designing the MicroSD Array

To mimic the memory bandwidth required to sustain inference, the F.A.R.C.E. Flash design calls for a custom PCB featuring a massive array of 40 to 50 MicroSD card sockets, all operating in parallel. This hardware escalation introduces physical and electrical challenges that push the boundaries of conventional PCB design.

Signal Integrity and Electromagnetic Crosstalk

Routing 40 parallel SDIO buses across a single PCB is an exercise in extreme signal integrity management. Each SDIO interface requires a clock line (CLK), a command line (CMD), and four data lines (DAT0-DAT3).³² If 40 cards are utilized, the board must route 240 high-speed, high-frequency traces simultaneously.

Crosstalk is the unwanted transfer of electromagnetic energy from one trace (the aggressor) to an adjacent trace (the victim).³³ Because the F.A.R.C.E. Flash must route these traces in parallel over relatively long distances from a central FPGA or PCIe switch to the card sockets, it maximizes the parallel run length, which exponentially increases both near-end crosstalk (NEXT) and far-end crosstalk (FEXT).³⁴

High-speed clock signals toggling at 208 MHz will inevitably induce noise into adjacent data lines.³⁰ This interference distorts the clean square waves of the digital signals, partially or completely closing the "eye diagram" at the receiver end, leading to data corruption and bit errors.³⁴ When a MicroSD controller detects a cyclic redundancy check (CRC) error due to crosstalk, it forces the host to retransmit the block. In an array highly dependent on maintaining maximum throughput, frequent retransmissions will obliterate the aggregated bandwidth, defeating the entire purpose of the parallel architecture.³³

To mitigate these effects, the PCB designers must adhere to stringent layout rules. The primary defense is the "3W rule," which mandates that the separation distance between adjacent traces must be at least three times the width of a single trace.³⁵ Furthermore, routing must utilize a multi-layer stack-up where signal layers are separated by solid, unbroken ground planes located exactly one dielectric layer away.³⁴ These ground planes provide a low-impedance return path for the high-frequency signals, tightly containing the electromagnetic fields and preventing them from coupling into neighboring traces.³⁵ If traces must transition between layers, ground transition vias must be placed immediately adjacent to the signal vias to maintain the integrity of the return path.³⁴

Power Integrity: VRM Droop and Inrush Current

The assumption that MicroSD cards are inherently low-power devices is a fatal miscalculation when scaling to massive arrays. While a card idling may draw only a fraction of a milliamp (mA), active read and write operations require significant energy to power the flash controller and generate the high programming voltages required to inject electrons into the NAND cells.³⁷ A standard UHS-I MicroSD card actively writing data can consume between 100 mA and 150 mA at 3.3 Volts.³⁷ If the F.A.R.C.E. Flash inference engine attempts to flush a massive block of newly generated KV cache across the 40-card array simultaneously, the aggregate current draw on the 3.3V rail will instantaneously spike to 6 Amps (nearly 20 Watts of power

consumption solely for the storage media).³⁸

This abrupt transition from an idle state to a 6-Amp load represents a severe transient load step.⁴¹ If the onboard Voltage Regulator Module (VRM) cannot respond fast enough to this sudden demand, the board will experience voltage droop—a momentary sag in the supply voltage.⁴² MicroSD controllers are highly sensitive to voltage fluctuations; if the 3.3V supply droops below the operational minimum (typically around 2.7V), the internal controllers will trigger a brown-out reset.²⁹ A synchronized reset across the array during an active write cycle will irreversibly corrupt the file systems and crash the inference runtime.³⁸

To ensure stability, the F.A.R.C.E. Flash cannot rely on a simple linear regulator or a basic buck converter. The system requires a sophisticated, multiphase DC-DC buck converter.⁴² A multiphase VRM divides the current load across several distinct power stages (inductors and MOSFETs) operating with timed offsets, dramatically improving the transient response speed and lowering the current stress on individual components.⁴²

Furthermore, to manage the immediate inrush current during load steps before the VRM can react, the PCB must feature extensive bulk capacitance.⁴¹ Designers must place banks of Multi-Layer Ceramic Capacitors (MLCCs) physically adjacent to every single MicroSD socket.⁴³ MLCCs possess incredibly low Equivalent Series Resistance (ESR) and Equivalent Series Inductance (ESL), allowing them to discharge energy instantaneously, filling in the voltage droop and stabilizing the rail during the critical microseconds of the load transient.⁴³

Thermodynamic Realities of Plastic Media

Even if the power delivery and signal integrity challenges are perfectly solved, the F.A.R.C.E. Flash cannot escape the laws of thermodynamics. Advanced enterprise NVMe SSDs dissipate the massive heat generated by their multi-core controllers and NAND flash through direct contact with large copper planes and finned aluminum heatsinks.⁴⁴

A MicroSD card forces an entire memory controller and multiple stacked NAND dies into a microscopic 15mm x 11mm x 1mm package encased in plastic.⁴⁵ Plastic is a thermal insulator. When an LLM inference engine continually hammers the MicroSD array with read and write requests to swap KV cache blocks, the internal controller operates at a 100% duty cycle, rapidly generating localized heat.⁴⁵

Because the plastic casing prevents rapid heat dissipation, the internal temperature of the die escalates almost immediately. Once the die temperature reaches a pre-programmed threshold (usually between 70°C and 85°C), the flash controller implements a self-preservation protocol known as thermal throttling.⁴⁵ To prevent the silicon from literally melting, the controller drastically reduces its clock speed, forcing artificial wait states.⁴⁵

Under severe thermal throttling, a MicroSD card that theoretically supports 104 MB/s can plummet to sustained transfer speeds of less than 10 MB/s.⁴⁷ In a parallel array environment, thermal throttling is fatal to performance. Because LLM offloading algorithms operate synchronously—waiting for a complete tensor or KV block to be assembled in RAM before the GPU can execute the matrix multiplication—a single thermally throttled MicroSD card will stall the entire 40-card array.³¹

To counteract this, the F.A.R.C.E. Flash kit must require end-users to physically modify the MicroSD cards. Users would likely need to sand down the plastic casing to expose the silicon die, apply thermal interface material, and clamp the entire array under a massive custom aluminum heatsink equipped with high-static-pressure server fans.⁴⁴ This extreme,

void-of-warranty hardware modification aligns perfectly with the escalating absurdity of the project's foundational methodology.

The Endurance Crisis: FTL, Write Amplification, and Certain Death

If the F.A.R.C.E. Flash array manages to remain powered, cooled, and communicating clearly, it will immediately run headfirst into a mathematical certainty: the rapid, irreversible destruction of the storage media.

NAND flash memory is a consumable resource. The physical process of writing data involves applying high voltage to force electrons through an insulating tunnel oxide layer.⁴⁹ This process inherently degrades the oxide layer. Eventually, the insulation fails, the cell can no longer hold a reliable charge, and data is lost.⁴⁹

The lifespan of flash memory is strictly quantified by Program/Erase (P/E) cycles.⁵¹ While an enterprise NVMe SSD utilizes premium 3D TLC or MLC NAND rated for over 10,000 P/E cycles alongside heavy over-provisioning, consumer MicroSD cards utilize highly dense,

cost-optimized TLC or QLC NAND that degrades after just 1,000 to 3,000 P/E cycles.⁵¹

The Flash Translation Layer and the Erase-Before-Write Penalty

The core problem stems from a physical asymmetry in NAND flash architecture. Data can be read and written at a granular "page" level (typically 4 KB to 16 KB), but it can only be erased at a massive "block" level (typically 1 MB to 4 MB).⁵⁰ Furthermore, flash memory does not support "in-place" updates. If the host system wants to alter a single 4 KB KV cache entry, the drive cannot simply overwrite that 4 KB space. It must write the new data to a completely different, pre-erased page.⁵³

To hide this complexity from the host operating system, the MicroSD card runs a sophisticated software layer on its internal controller called the Flash Translation Layer (FTL).⁵⁵ The FTL maintains a mapping table that translates the Logical Block Addresses (LBAs) requested by the host into the actual Physical Page Numbers (PPNs) inside the flash array.⁵⁵

When the LLM inference engine updates KV cache blocks, it frequently evicts small, random chunks of data.²¹ The FTL writes these new chunks to fresh pages and marks the old pages as "stale" or invalid.⁵⁴ Over time, the MicroSD card fills up with scattered valid pages mixed among thousands of stale pages.

Garbage Collection and Write Amplification

When the card runs low on fully erased blocks, the FTL must perform Garbage Collection.⁵⁵ The controller identifies a block containing a mix of valid and stale data. It reads the valid pages into a tiny internal RAM buffer, issues a high-voltage command to erase the entire 4 MB block, and then writes the valid data back into the block alongside new incoming data.⁴⁹

This background data movement triggers a phenomenon known as Write Amplification (WA).⁵⁰ Write Amplification dictates that the actual amount of data physically programmed into the NAND cells is significantly larger than the logical amount of data the host requested to save.⁵¹ The ratio is expressed as the Write Amplification Factor (WAF).

In enterprise SSDs utilizing large DRAM caches, sequential writes, and the TRIM command (which allows the OS to explicitly tell the drive which pages are garbage), the WAF can be kept near an ideal ratio of 1.1 to 1.5.⁴⁹ However, consumer MicroSD cards lack DRAM, often lack TRIM support, and possess primitive FTLs.²⁵ When subjected to the highly random, fragmented write patterns of a constantly swapping LLM inference engine, the MicroSD card’s WAF can easily skyrocket to 10.0 or higher.⁵⁰

This means that for every 1 GB of KV cache data the F.A.R.C.E. Flash offloads to the array, the internal MicroSD controllers are physically burning 10 GB worth of P/E cycles into the NAND.⁵⁰

The Lifespan Calculation

The math governing the lifespan of the F.A.R.C.E. Flash array is catastrophic. Consider a scenario where the array utilizes sixty-four 128 GB MicroSD cards to create a massive 8 TB pool for KV cache storage. A high-concurrency LLM serving session might generate and offload 50 GB of logical KV cache writes per hour.

With a conservative WAF of 5.0, the array is physically enduring 250 GB of writes per hour. A standard 128 GB card with 3,000 P/E cycles possesses a theoretical maximum endurance of roughly 384 Terabytes Written (TBW) before absolute failure.⁵²

However, cheap MicroSD cards employ only basic dynamic wear leveling, meaning they only rotate writes across empty space, leaving static data untouched.⁵⁰ Without global wear leveling, the active portion of the card dedicated to the LLM swap space will burn through its P/E cycles exponentially faster than the rest of the card.⁵⁸ Even assuming perfect wear leveling, 250 GB/hour equates to 6 Terabytes of physical wear per day. The entire array would completely exhaust its silicon endurance and permanently brick itself in approximately 64 days of continuous operation.⁵⁹

The only viable hardware solution is to mandate the use of industrial-grade pseudo-Single Level Cell (pSLC) MicroSD cards, which offer up to 60,000 P/E cycles and enterprise-class FTLs.⁵⁸ However, these cards retail at a massive price premium, often costing hundreds of dollars for a mere 32 GB of capacity.⁵⁷ Requiring users to populate a 40-slot array with premium pSLC media instantly destroys the core financial premise of the F.A.R.C.E. Flash, making the final kit significantly more expensive than the DGX Spark it was designed to undercut.

Operating System Hostilities: Defeating the Linux Kernel

If the user accepts that their hardware will immolate itself within two months, the software stack must still be entirely re-engineered. The Linux kernel, and the Virtual File System (VFS) by extension, is not designed to treat an array of removable SD cards as a functional extension of host memory.⁶³

The Perils of Standard mmap and Swap

The default inference approach utilized by popular frameworks like llama.cpp maps model weights directly into the virtual address space using the POSIX mmap() system call.³¹ The OS kernel assumes responsibility for managing the physical memory, relying on page faults. When the GPU requests a tensor that is not currently resident in RAM, a hardware interrupt occurs, and the kernel pauses execution to fetch the 4KB memory page from the storage device.⁶⁵ If the system lacks sufficient RAM—which is the fundamental premise of the F.A.R.C.E. Flash—the kernel will attempt to free up space by evicting older pages back to the storage array via the Linux swap partition.⁶³ Standard Linux swap relies heavily on the performance of the underlying block device. When swap is forced onto a slow, high-latency medium like a MicroSD array, the system enters a state of "swap thrashing." The kernel spends the majority of its CPU cycles desperately shuffling small 4KB pages in and out of the high-latency storage, causing the entire operating system to freeze and bringing token generation to an absolute standstill.⁶³

Furthermore, llama.cpp's default mmap implementation attempts to aggressively commit large portions of the file to memory. When the F.A.R.C.E. Flash exhausts its physical RAM, the kernel's Out of Memory (OOM) killer will frequently terminate the inference process before the token generation can even begin.⁶³

Bypassing the Kernel: Custom Asynchronous IO

To force the F.A.R.C.E. Flash to function, the developers must abandon the standard Linux memory management hierarchy. They cannot rely on reactive page faults or the OS swap file. Instead, they must implement a custom, highly aggressive user-space offloading framework. Drawing inspiration from optimized frameworks like FlexInfer and LMCache, the system must utilize asynchronous prefetching and balanced memory locking.⁶⁸ The model must be locked into physical RAM using the --mlock flag to explicitly prevent the Linux kernel from attempting to swap it out.³¹

To move KV cache blocks and sparse weights in and out of the MicroSD array, the inference engine must bypass the VFS overhead by writing directly to the raw block devices using asynchronous I/O APIs (such as Linux libaio).⁷¹ By analyzing the transformer attention patterns, the custom software must pre-calculate which specific expert layers or KV blocks will be required for the next token generation step.¹⁴ While the GPU is computing the current token, the CPU dispatches massive, highly concurrent scatter-gather read commands directly to the FPGA controlling the MicroSD array, attempting to saturate the deep queues that the software must artificially maintain.⁷³

This represents the ultimate escalation in the "Nathan for You" methodology: because the operating system correctly identifies the hardware as too slow to function as memory, the software developers must spend thousands of hours writing a custom storage driver to blind the operating system to that fact, brute-forcing the data transfers through sheer algorithmic complexity.

Algorithmic Salvation: 1.58-Bit Ternary Quantization

Given the severe constraints in IOPS, the fragile electrical routing, the catastrophic write amplification, and the hostile operating system environment, it is physically impossible for the F.A.R.C.E. Flash to support standard 8-bit or 16-bit LLM inference. The bandwidth required to stream 70 GB of weights from the array during every forward pass would result in token generation speeds measured in minutes per token.⁹

To prevent the architecture from failing on boot, the underlying LLM must be subjected to extreme, bleeding-edge compression. The deployment of BitNet b=1.58 and similar ternary quantization architectures provides the necessary paradigm shift to salvage the project.⁷⁶ Recent breakthroughs have demonstrated that massive transformer models can be

post-trained or trained from scratch with weights restricted to just three discrete values: {−1, 0, +1}..⁷⁶ This 1.58-bit representation defines an entirely new scaling law. It drastically reduces the memory footprint of the weights while maintaining near-parity with full-precision FP16 models on perplexity and complex reasoning benchmarks.⁷⁶

By implementing ternary quantization, a massive 70-billion parameter model is compressed from its native ~140 GB footprint down to approximately 13.8 GB.⁷⁷ This mathematical compression rescues the F.A.R.C.E. Flash. The 13.8 GB parameter set easily fits within the limited system DRAM or VRAM available on a budget developer board, completely negating the need to stream the weights from the MicroSD array during the highly sensitive decode phase.⁷

Repurposing the Array for Pure KV Cache

With the model weights safely resident in fast, volatile RAM, the F.A.R.C.E. Flash array can be repurposed exclusively as a massive sink for KV cache offloading.⁷⁴

This shift alters the I/O profile from highly destructive to marginally viable. Because the KV cache is generated sequentially as the user prompt is processed during the prefill phase, the data can be written to the MicroSD array in large, contiguous blocks.²¹ Grouping the data into 256-token chunks (the default strategy for engines like LMCache) maximizes the sequential write capabilities of the UHS-I bus and minimizes the highly fragmented, small block writes that trigger severe Write Amplification.¹⁹

During the decode phase, the asynchronous prefetcher retrieves only the specific historical KV blocks required for the current attention window.¹⁹ While this still strains the low IOPS limits of the SDIO controllers, it operates within the boundaries of possibility.

While ternary quantization avoids immediate hardware failure, the user experience remains heavily compromised. The Time-To-First-Token (TTFT) latency for processing a 32K context window—assuming the prompt must be ingested and the resulting 5 GB KV cache streamed entirely to the SD array—would exceed 45 to 60 seconds.⁷⁹ If the user engages in an iterative, multi-turn conversation, the system will continuously pause to shuffle massive context blocks between DRAM and the MicroSD array, inducing severe UI stuttering and rendering the system entirely unsuitable for real-time interactive agents.²⁵

Performance Projections and the DGX Spark Reality

The final evaluation of the F.A.R.C.E. Flash must compare its projected performance and total cost of ownership against its stated benchmark: the NVIDIA DGX Spark.

The DGX Spark, equipped with 128 GB of unified memory, is purposefully engineered to eliminate internal data transfer bottlenecks. A 70B model running at 8-bit precision on the Spark achieves a fluid decode throughput of roughly 40 to 60 tokens per second, constrained only by its massive internal memory bandwidth of over 500 GB/s.¹

By contrast, the F.A.R.C.E. Flash relies on an array of 40 MicroSD cards. Even assuming the custom FPGA controller achieves perfect linear scaling with zero overhead (a physical impossibility), the aggregate sequential read bandwidth peaks at roughly 4.1 GB/s. Assuming the deployment of a ternary 1.58-bit 70B model and a heavily quantized 4-bit KV cache, the mathematics of the latency pipeline yield an estimated decode speed of 1.5 to 3.0 tokens per second. It is functionally the equivalent of watching a human type.

More critically, the economic premise of the F.A.R.C.E. Flash collapses under the weight of its own escalating complexity. The "cheap" solution of using consumer MicroSD cards necessitates massive downstream expenditures. The custom 8-layer PCB required to manage signal integrity, the multiphase VRM components, the high-performance FPGA required to bypass the Linux kernel, the CNC-machined aluminum active cooling assembly, and the inevitable requirement to purchase premium, high-endurance pSLC MicroSD cards to prevent the array from dying in 60 days, will inflate the Bill of Materials astronomically.

By the time the Kickstarter campaign is fulfilled, the final retail cost of the F.A.R.C.E. Flash kit will easily rival or exceed the $4,700 price tag of the DGX Spark.¹

Conclusion

The F.A.R.C.E. Flash project represents a masterclass in absurd engineering. It correctly identifies the core bottleneck of modern LLM inference—the cost and capacity of memory bandwidth⁸¹ —and applies a rigorously logical, yet completely unhinged solution.

To make consumer MicroSD cards function as extended memory for a 70B language model, developers must engineer a custom multi-channel host board, mitigate high-frequency EMI crosstalk, design a multiphase VRM to handle massive inrush currents, attach active cooling to plastic cards to prevent thermal throttling, rewrite the Linux page fault handler to bypass the VFS, and compress the neural network down to ternary logic to circumvent the physical limitations of the SDIO bus protocol.²²

The result is a device that achieves less than 5% of the performance of the hardware it sought to disrupt, housed in an architecture that guarantees the physical immolation of its own storage media via write amplification.⁵⁰ It stands as a monument to the lengths to which engineers will go to avoid purchasing enterprise hardware, proving conclusively that while machine learning can indeed run in a flash, the financial and thermodynamic costs of doing so are ultimately inescapable.

Works cited

1. Dgx Workstation - eBay https://www.ebay.com/shop/dgx-workstation?_nkw=dgx+workstation
2. Best Llama 3.3 H200 Inference Platforms for AI Teams 2026 https://www.gmicloud.ai/ja/blog/best-platforms-to-run-llama-3-3-inference-on-nvidia-h200-gpus
3. Nathan Fielder: An Exhaustive Character study : r/TheRehearsal https://www.reddit.com/r/TheRehearsal/comments/1kwzzni/nathan_fielder_an_exhaustive_character_study/
4. Nathan for You - Wikipedia https://en.wikipedia.org/wiki/Nathan_for_You
5. Spring in Review: Nathan Fielder & Narrative Control https://clereviewofbooks.com/spring-in-review-nathan-fielder-narrative-control/
6. High-Throughput Generative Inference of Large Language Models https://arxiv.org/html/2502.09921v1
7. On-Device LLMs: State of the Union, 2026 - Vikas Chandra https://v-chandra.github.io/on-device-llms/
8. Serving LLaMA 3-70B on TPUs | How To Scale Your Model https://jax-ml.github.io/scaling-book/applied-inference/
9. Local LLM Performance: What Tokens-Per-Second to Expect From https://inventivehq.com/blog/local-llm-performance-what-to-expect
10. SSD Offload Design — Mooncake - GitHub Pages https://kvcache-ai.github.io/Mooncake/design/ssd-offload.html
11. Llama 3.1 70B on RTX 4090 24GB? Reduced Quality Only https://willitrunai.com/can-run/llama-3.1-70b-on-rtx-4090-24gb
12. Efficient Large Language Model Inference with Limited Memory - arXiv https://arxiv.org/html/2312.11514v2
13. Scaling Up On-Device LLMs via Active-Weight Swapping Between https://www.alphaxiv.org/abs/2504.08378
14. Scaling Up On-Device LLMs via Active-Weight Swapping ... - arXiv https://arxiv.org/html/2504.08378v1
15. flexgen · PyPI https://pypi.org/project/flexgen/
16. ZeRO-Inference: Democratizing massive model inference https://www.deepspeed.ai/2022/09/09/zero-inference.html
17. Cooperative CPU-GPU Transformer Inference - Emergent Mind https://www.emergentmind.com/topics/cooperative-cpu-gpu-transformer-inference
18. Optimize LLM Inference with vLLM KV Cache Offloading on Amazon https://builder.aws.com/content/3ADRXvEt2iAjcMcs2TZotAEMXOu/optimize-llm-inference-with-vllm-kv-cache-offloading-on-amazon-sagemaker-ai
19. KV Caching with vLLM, LMCache, and Ceph https://ceph.io/en/news/blog/2025/vllm-kv-caching/
20. Architecture Overview | LMCache https://docs.lmcache.ai/developer_guide/architecture.html
21. NVMe KV Cache Offloading for LLM Inference: Serve 10x More https://www.spheron.network/blog/nvme-kv-cache-offloading-llm-inference/
22. KV Cache NVMe Offload, 5x Inference Gains, and Setup Guide (2026) https://www.spheron.network/blog/nvidia-icmsp-kv-cache-nvme-inference-guide/
23. NVMe Latency: Typical Numbers and What Drives Them | simplyblock https://simplyblock.io/glossary/nvme-latency/
24. SD Card vs SSD: Best Storage Choice - Memory Tech https://www.memorytech.com.au/blogs/memory-tech-insights/sd-card-vs-ssd-best-storage-choice-memory-tech
25. What Is the Difference Between a Memory Card and an SSD? https://electronics.alibaba.com/question/memory-card-vs-ssd-key-differences-when-to-use-which
26. eMMC vs SSD: Which Storage Is Best for Your Device? - Fly-Wing https://www.flywing-tech.com/blog/emmc-vs-ssd-which-storage-is-best-for-your-device/
27. Arduino Micro SD Card Module Guide | PDF | Computer File - Scribd https://www.scribd.com/document/731847538/Interfacing-Micro-SD-Card-Module-with-Arduino
28. Serial Peripheral Interface SPI · CPOL/CPHA · Verilog Master https://ecrionix.org/serial-protocols/spi/
29. SD Standard Overview - SD Association https://www.sdcard.org/developers/sd-standard-overview/
30. (PDF) IoT on an ESP32: Optimization Methods Regarding Battery https://www.researchgate.net/publication/369763204_IoT_on_an_ESP32_Optimization_Methods_Regarding_Battery_Life_and_Write_Speed_to_an_SD-Card
31. Tune llama.cpp on Apple Silicon: 7 Flags - Medium https://medium.com/@michael.hannecke/tuning-llama-cpp-on-apple-silicon-843f37a6c3dc
32. Video Streaming using DMA | Embedded systems - DESE Labs https://labs.dese.iisc.ac.in/embeddedlab/video-streaming-using-dma/
33. Crosstalk Basics in PCB Design - Altium | Learning Hub https://resources.altium.com/p/crosstalk-basics-pcb-design
34. Handling Crosstalk in High-Speed PCB Design - Sierra Circuits https://www.protoexpress.com/blog/crosstalk-high-speed-pcb-design/
35. Crosstalk in High-Speed PCB Design: Causes & Solutions https://blindburiedcircuits.com/crosstalk-in-high-speed-pcb-design-causes-and-solutions/
36. PCB Trace Spacing: Balancing Density, Crosstalk, and ... - ALLPCB https://www.allpcb.com/allelectrohub/pcb-trace-spacing-balancing-density-crosstalk-and-manufacturing-constraints
37. sdcard - What determines the actual power consumption of writing to https://electronics.stackexchange.com/questions/247734/what-determines-the-actual-power-consumption-of-writing-to-a-microsd-card
38. typical SD card power consumption? - NXP Community https://community.nxp.com/t5/LPCXpresso-IDE/typical-SD-card-power-consumption/m-p/528444
39. SD card current consumption - EEVblog https://www.eevblog.com/forum/beginners/sd-card-current-consumption/
40. Power consumption to write to SD card? - Storage - Arduino Forum https://forum.arduino.cc/t/power-consumption-to-write-to-sd-card/129434
41. Powering FPGAs with Dual-Output Modules | Article | MPS http://www.monolithicpower.com/learning/resources/powering-fpgas-with-dual-output-modules
42. Voltage Regulator Module Guide: VRM Basics, Types & Selection https://mozelectronics.com/tutorials/voltage-regulator-module-guide/
43. Samsung MLCC Replacing Aluminum Polymer Capacitors in AI https://passive-components.eu/samsung-mlcc-replacing-aluminum-polymer-capacitors-in-ai-systems/
44. Preventing Thermal Throttling: What it is and How to Stop it - MSI https://www.msi.com/blog/preventing-thermal-throttling-what-it-is-and-how-to-stop-it
45. Why Do Memory Cards & SSDs Generate So Much Heat? https://progradedigital.com/why-do-memory-cards-and-ssds-generate-so-much-heat/
46. SD card - Wikipedia https://en.wikipedia.org/wiki/SD_card
47. PSA: SD Cards thermal throttle during downloads and restrict speed. https://steamcommunity.com/app/1675200/discussions/0/3490878556683974233/?l=french
48. Card is getting hot during file transfer | DPReview Forums https://www.dpreview.com/forums/threads/card-is-getting-hot-during-file-transfer.4775836/
49. Understanding SSD endurance : Garbage Collection to TRIM https://www.atpinc.com/blog/trim-garbage-collection-ssd-endurance-wai-waf
50. How SSD Wear Leveling Works - Rossmann Repair Group https://rossmanngroup.com/technical-reference/how-ssd-wear-leveling-works
51. Write amplification - Wikipedia https://en.wikipedia.org/wiki/Write_amplification
52. Synology MicroSD Card https://www.synology.com/products/microSD-card
53. HybridLog: an Efficient Hybrid-Mapped Flash Translation Layer for https://www.inase.org/library/2014/santorini/bypaper/COMPUTERS/COMPUTERS2-31.pdf
54. GeckoFTL: Scalable Flash Translation Techniques For Very Large https://nivdayan.github.io/GeckoFTLPaper.pdf
55. Research and Summary on Various Mapping Methods in FTL https://openreview.net/pdf?id=LuMmCAw6AQ
56. Crash Recovery Techniques for Flash Storage Devices Leveraging https://www.mdpi.com/2079-9292/12/6/1422
57. Industrial SD, eMMC, and USB Flash: A Selection Guide - Flexxon https://www.flexxon.com/industrial-flash-selection-guide/amp/
58. The Effect of Wear Leveling on SSD Lifetime - ATP Electronics https://www.atpinc.com/blog/how-SSD-wear-leveling-works
59. Wearout Prevention of SD card memory - Raspberry Pi Forums https://forums.raspberrypi.com/viewtopic.php?t=20505
60. Does bad blocks get flagged on the microSD? : r/raspberry_pi - Reddit https://www.reddit.com/r/raspberry_pi/comments/s2b4l7/does_bad_blocks_get_flagged_on_the_microsd/
61. Which is the Right Industrial Flashcard for Long-Term Use? - DigiKey https://www.digikey.com/en/blog/which-is-the-right-industrial-flashcard-for-long-term-use
62. Why Choose Industrial Micro SD Cards? - Indilinx https://indilinxtech.com/micro-sd-solutions/industrial-micro-sd-cards/
63. Here's the Easy Way to Add Virtual Memory (Swap) to ... - MakeUseOf https://www.makeuseof.com/easy-way-to-add-virtual-memory-swap-to-raspberry-pi/
64. Why MMAP in llama.cpp hides true memory usage - Hacker News https://news.ycombinator.com/item?id=35426679
65. Page Fault Handler - Linux Kernel Internals https://kernel-internals.org/mm/page-fault/
66. OS-Level Challenges in LLM Inference and Optimizations | daily.dev https://daily.dev/posts/os-level-challenges-in-llm-inference-and-optimizations-wjigscqig
67. Llama.cpp Out of memory exception? Is there a way to completely https://www.reddit.com/r/LocalLLaMA/comments/1myuvjo/llamacpp_out_of_memory_exception_is_there_a_way/
68. FlexInfer: Breaking Memory Constraint via Flexible and Efficient https://euromlsys.eu/pdf/euromlsys25-38.pdf
69. Arina Kharlamova - CatalyzeX https://www.catalyzex.com/author/Arina%20Kharlamova
70. nous-llama.cpp/examples/main/README.md at master ... - GitHub https://github.com/NousResearch/nous-llama.cpp/blob/master/examples/main/README.md
71. 라이브러리 deepspeed | Claude Skills & Agent Skills https://mcpservers.org/ko/agent-skills/firecrawl/deepspeed
72. Unleashing the Power of Prefetching for Resource-Constrained MoE https://arxiv.org/html/2509.23638v1
73. Native KV Cache Offloading to Any Filesystem with llm-d https://llm-d.ai/blog/native-kv-cache-offloading-to-any-file-system-with-llm-d
74. KV Offloading Usage Guide - vLLM https://docs.vllm.ai/en/stable/features/kv_offloading_usage/
75. Tutti: Making SSD-Backed KV Cache Practical for Long-Context LLM https://arxiv.org/html/2605.03375
76. TeLLMe: An Energy-Efficient Ternary LLM Accelerator for Prefill and https://arxiv.org/html/2504.16266v1
77. TOM: A Ternary Read-only Memory Accelerator for LLM-powered https://arxiv.org/html/2602.20662v1
78. Daily Papers - Hugging Face https://huggingface.co/papers?q=4-bit%20elements
79. KV Cache Offload to NVMe SSD for 512K Context on M5 Max https://contracollective.com/blog/kv-cache-nvme-offload-512k-context-m5-max-mlx-2026
80. Accelerating Inference - VAST Data https://www.vastdata.com/blog/accelerating-inference
81. H2O: Heterogeneity-Aware Hierarchical Orchestration for Memory https://www.computer.org/csdl/journal/tm/2026/04/11224632/2blzXdOPEpG
82. (PDF) A Survey: Collaborative Hardware and Software Design in the https://www.researchgate.net/publication/384811186_A_Survey_Collaborative_Hardware_and_Software_Design_in_the_Era_of_Large_Language_Models