Every time I read a headline about building cities on Mars, my mind goes somewhere completely different. I start thinking about California’s water system.

That may sound like an odd connection, but the more I think about it, the more the two subjects seem related. Southern California is one of the most technologically advanced and economically productive regions in the world. Millions of people live here, supported by an enormous network of roads, reservoirs, aqueducts, power plants, hospitals, and distribution systems. Yet despite all of that infrastructureThe interconnected systems and facilities that support the operation and sustainability of a community or technology., water remains a constant topic of discussion. Droughts, conservation measures, reservoir levels, and long-term supply planning seem to reappear every few years.

The observation isn’t meant as a criticism. Quite the opposite. Moving and managing water across a large state is an extraordinary engineering achievement. The California Department of Water Resources describes the State Water Project as a water storage and delivery system extending more than 705 miles, serving millions of Californians, farmland, and businesses. That alone should remind us that even on a planet perfectly suited for human life, providing basic necessities at scale is far more complicated than it first appears.

That thought inevitably leads me back to Mars.

Looking Beyond the Rocket

Most public discussions about Mars focus on transportation. The conversation usually revolves around rockets, launch schedules, payload capacity, and how many people might eventually make the journey. Those questions are certainly important, but they may not be the questions that determine whether a permanent settlement succeeds.

Getting people to Mars is a transportation challenge. Keeping them alive there is an infrastructure challenge.

The distinction matters because transportation is only the first step. Once people arrive, every system required to support human life must either be imported, constructed, maintained, repaired, or eventually reproduced using local resources. The challenge shifts from reaching another planet to building an environment capable of sustaining a community for years, decades, and eventually generations.

When viewed through that lens, the discussion becomes less about rockets and more about civilization itself.

The Infrastructure We Rarely Notice

One reason Mars settlement can sound deceptively straightforward is because most of us spend very little time thinking about infrastructure. When it works properly, it fades into the background.

Water appears when a faucet is turned on. Electricity arrives when a switch is flipped. Grocery stores remain stocked. Hospitals operate continuously. Waste is collected, roads are maintained, and communication networks remain available around the clock. These systems are so reliable that it becomes easy to forget they represent the combined effort of millions of workers, thousands of companies, and decades of investment.

The same pattern appears in modern technology. A user sees an answer appear on a screen, but behind that moment sits a massive stack of storage, networking, power, cooling, and memory infrastructure. We touched on a similar idea in our article about KV cache and AI memory infrastructure, where the visible result is only possible because of systems most people never see.

A modern city is not simply a collection of buildings. It is a collection of interconnected systems supporting one another. Water systems depend on power systems. Power systems depend on manufacturing and transportation. Transportation depends on maintenance, fuel, logistics, and labor. Remove enough pieces from the chain and the entire structure begins to struggle.

Mars begins with none of those systems already in place.

Building a habitat is an impressive accomplishment. Building an ecosystem of industries capable of supporting that habitat indefinitely is an entirely different undertaking.

The Replacement Part Problem

One of the simplest ways to think about the challenge is to consider what happens when something breaks.

Imagine a mining machine operating on Mars suffers a mechanical failure. Perhaps a gear wears out or a motor stops functioning. Replacing the damaged component sounds straightforward until you begin tracing backward through the requirements needed to manufacture that replacement.

The replacement part requires machine tools. The machine tools require maintenance. Maintenance requires spare parts, skilled technicians, and a supply chain for raw materials. Those raw materials must be mined, processed, transported, and refined. Each step depends on power generation, industrial equipment, and a workforce capable of operating and repairing the machinery involved.

What initially appears to be a single broken component quickly reveals an entire industrial ecosystem hiding beneath the surface. Even something as small and familiar as flash memory depends on global supply chains, energy markets, fabrication facilities, chemical inputs, logistics, and testing operations. That broader relationship was the point behind our discussion of why NAND chips contain almost no oil, yet oil prices still matter.

Earth possesses that ecosystem because generations of people built it over centuries. Mars would have to develop much of it from scratch.

Earth Is Still the Easier Planet

Occasionally Mars is discussed as a long-term backup plan for humanity, particularly when conversations turn toward climate change or environmental challenges. While the idea is understandable, it often overlooks a simple reality: even a stressed Earth remains vastly more hospitable than Mars.

Earth already provides breathable air, abundant water, natural ecosystems, and biological systems that support life without human intervention. Even regions facing environmental pressures still benefit from the existence of a functioning planet beneath them.

Mars offers none of those advantages. NASA describes Mars as a cold, dusty desert world with a very thin atmosphere, along with polar ice caps, seasons, extinct volcanoes, canyons, and weather. That makes Mars scientifically fascinating, but it does not make it a simple place to live.

This is not an argument against space exploration. It is simply an acknowledgment of scale. If humanity eventually develops the ability to construct a truly self-sustaining city on Mars, that same technological capability would likely be powerful enough to address many of the infrastructure and environmental challenges we face here on Earth.

In other words, the technologies required to make Mars livable may be among the most advanced tools ever developed for improving life on Earth.

Exploration Versus Colonization

None of this should be interpreted as skepticism toward exploration itself. Human progress has often been driven by ambitious goals that initially seemed unrealistic. Space exploration has contributed to advances in computing, communications, materials science, navigation, and countless other fields that now feel commonplace.

A research outpost on Mars is one thing. A permanently occupied settlement is another. A self-sustaining industrial civilization capable of surviving independently from Earth represents yet another level of complexity altogether.

Those distinctions are often blurred in public discussions because they all fall under the broad label of “living on Mars.” In reality, each stage requires a dramatically different level of capability and infrastructure.

The difference between visiting Mars and building a civilization there may be larger than the difference between visiting Antarctica and building a self-sustaining nation on the continent.

A Thought Worth Considering

The next time you encounter a headline predicting future cities on Mars, it may be worth pausing for a moment and considering the systems that already support life around us.

The water arriving at a home in Southern California is backed by reservoirs, pipelines, pumping stations, treatment facilities, engineers, maintenance crews, and decades of planning. That network exists on a planet with rivers, rainfall, oceans, and an atmosphere designed for human life.

Mars offers none of those advantages.

Perhaps the greatest challenge of Mars is not reaching the planet. Perhaps the greater challenge is recreating enough of Earth’s infrastructure that people no longer need Earth to survive.

Viewed from that perspective, the question becomes less about rockets and more about civilization. And that may be the most fascinating engineering challenge humanity has ever considered.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

When most people think about USB duplication systems, they picture content going outward. A company loads software onto a thousand flash drives. A school distributes coursework to students. A marketing team hands out promotional USB sticks at a trade show.

The workflow is easy to understand because it follows a familiar direction: copy data onto media and distribute it.

What often gets overlooked is the opposite side of the workflow — getting that data back.

For organizations operating in the real world, collecting data from large numbers of USB drives, SD cards, microSD cards, and other removable media has quietly become its own operational challenge. In many cases, the collection process is now more complicated than the original duplication process itself.

The reason is simple. Modern organizations are generating enormous amounts of field data.

Law enforcement agencies collect body camera footage and patrol recordings. News organizations gather photographs and video clips from reporters in the field. Election systems archive data from voting infrastructure. Industrial teams retrieve logs from embedded systems. Drone operators return with memory cards full of aerial footage. Medical and scientific organizations collect portable data from distributed devices operating far away from centralized servers.

At small scale, this kind of work is manageable with a stack of USB hubs and a few employees manually dragging files into folders.

At large scale, the workflow breaks down quickly.

The problem is not simply copying files. The real challenge becomes organization, verification, consistency, and speed.

That is where large-scale removable media data collectionA workflow system for automatically retrieving and centralizing data from multiple removable storage devices. systems enter the picture.

What Is a Removable Media Data Collection Workflow?

A removable media data collection workflow is a system designed to automatically retrieve files from multiple storage devices and centralize the content onto a single destination system.

The storage media may include:

• USB flash drives
• SD memory cards
• microSD cards
• CompactFlash cards
• CFast media
• External SSD devices

The goal is not duplication outward to users. The goal is aggregation inward from distributed devices, cameras, systems, or operators.

This distinction matters because the operational requirements are completely different. In many industries, the process is commonly referred to as media ingestion or removable media ingest workflows. While newcomers may think of the task as simply “copying files,” organizations handling large numbers of storage devices typically view the process as part of a broader ingestion pipeline involving automation, organization, verification, and centralized asset management.

Traditional duplication systems focus on:

• deployment
• replication
• imaging
• write protection
• media preparation

Data collection systems focus on:

• centralized ingest
• file harvesting
• workflow automation
• organization
• verification
• source tracking

The two categories may appear similar from the outside, but in practice they solve very different problems.

The Hidden Bottleneck Most Organizations Eventually Encounter

Most organizations do not initially plan for large-scale media collection workflows.

The process often begins informally.

Someone plugs memory cards into a laptop. Another employee copies files from USB drives into a shared folder. A producer gathers media from photographers after an event. A technician downloads log files from field equipment at the end of a shift.

For a while, manual collection works well enough.

Then scale changes everything.

Ten devices becomes fifty. Fifty becomes several hundred. Suddenly, hours are spent sorting files, renaming folders, checking for duplicates, and trying to determine which files came from which device.

At that point, the bottleneck is no longer storage capacity.

The bottleneck becomes workflow management.

This is where many organizations realize that removable media collection is not simply a copy-and-paste task. It is an operational process that requires structure and automation.

Unified Collection Versus Segmented Collection

One of the more interesting aspects of large-scale data collection is that organizations often need completely different types of workflows depending on the nature of the data being collected.

In general, most collection systems fall into two categories.

Unified Collection

In a unified collection workflow, files from all connected media devices are gathered into a single destination directory.

This method is often used when the origin of the files is less important than the content itself.

Examples include:

• photography teams
• media production crews
• event coverage
• marketing departments
• creative agencies

A newsroom collecting photographs from multiple photographers after a sporting event may simply want all media centralized into one production folder where editors can immediately begin sorting content.

The emphasis is speed and convenience.

Segmented Collection

In a segmented workflow, every memory device receives its own dedicated destination folder during the collection process.

This preserves the relationship between the files and the original storage device.

For many organizations, this distinction is critically important.

Examples include:

• law enforcement evidence collection
• election data archiving
• compliance workflows
• industrial logging systems
• medical data retention

In these environments, preserving chain-of-origin informationData that tracks the source and history of files collected from removable media devices. matters just as much as collecting the files themselves.

A body camera recording may need to remain associated with the original officer device. Election records may need to remain separated according to voting system source. Industrial inspection logs may require device-specific tracking for compliance purposes.

The collection system is no longer acting as a simple file copier. It becomes part of the operational recordkeeping process.

Discussions surrounding removable media evidence handling and forensic recovery continue to evolve across both enterprise and investigative environments. One interesting public discussion about recovering information from damaged USB devices can be found on Reddit’s computer forensics community, where professionals discuss the realities and limitations of data extraction workflowsAutomated processes for collecting, organizing, and verifying data from multiple removable media devices into a centralized system..

Data Collection Is No Longer Just About USB Drives

Although USB flash drives remain one of the most common forms of removable media, many modern workflows now involve multiple storage formats operating side by side.

This is especially true in media production and field operations.

A photography team using SD duplicator systems may return from an assignment carrying:

• SD cards from DSLR cameras
• microSD cards from drones
• USB flash drives containing transfers between teams
• portable SSD devices used for backup recording

Similarly, industrial and embedded systems often generate data across several different removable media standards depending on the age and purpose of the equipment.

As a result, organizations increasingly look for collection systems capable of handling multiple media formats within the same workflow rather than maintaining separate ingestion systems for each media type.

This is one of the reasons removable media collection has evolved into a specialized category rather than simply remaining an accessory feature of duplication equipment.

Real-World Examples of Large-Scale Data Collection

The most interesting thing about removable media collection workflows is how often they operate quietly in the background of industries most people never associate with USB technology.

Election System Data Collection

One example involves election infrastructure.

Various voting systems generate removable media data that must later be collected and archived as part of broader election recordkeeping procedures.

In these environments, the challenge is not merely transferring files. The challenge is collecting data from large numbers of devices while preserving organization and maintaining efficient workflows under strict timelines.

Because the data may originate from numerous locations and systems, automation becomes extremely valuable.

The process is less about convenience and more about consistency and repeatability.

Law Enforcement Video Archiving

Another example involves law enforcement agencies collecting digital video evidence from patrol operations and body-worn camera systems.

Modern policing generates enormous amounts of digital footage.

At the end of a shift or operational cycle, organizations may need to retrieve and archive content from large numbers of storage devices quickly and consistently.

In many cases, maintaining device separation and preserving folder structures becomes part of the workflow requirement itself.

Again, this moves the process far beyond basic file copying.

News and Photography Workflows

Photography and news organizations provide another excellent example.

Field photographers often return from assignments carrying multiple memory cards filled with RAW images and video footage.

Producers and editors typically need fast centralized access to those assets so content can move into editing pipelines immediately.

The challenge is not whether files can be copied. Any laptop can technically copy files. Even basic USB benchmark testing can demonstrate how modern storage devices are capable of very high read speeds during ingestion workflowsAutomated processes for collecting, organizing, and verifying data from multiple removable media devices into a centralized system..

The challenge is collecting large volumes of media quickly while minimizing confusion, delays, and organizational mistakes.

This is especially true during live event coverage where turnaround times are measured in minutes rather than hours.

Comparison of Removable Media Collection Workflow Capabilities

Feature support based on publicly available product specifications and removable media workflow capabilities at the time of publication.

How this article was created: This editorial was researched and written using a combination of industry experience, technical workflow analysis, publicly available product information, and AI-assisted drafting tools. The final article was reviewed, edited, and fact-checked by the author to ensure technical accuracy and real-world relevance regarding removable media collection workflows, ingestion systems, and flash storage operations.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

One of the stranger structural shifts happening in AI infrastructure right now is that some of the most critical performance gains are no longer coming from raw processor speed. Instead, they are coming from a much more practical engineering discipline: avoiding redundant work.

While optimizing for redundant execution might sound like a minor software tweak, it has quickly become a defining architectural pillar for modern AI inference systems—especially as large language models (LLMs) continue to scale in context window size and structural complexity.

This is where Key-Value Caching (KV Cache) shifts from a niche software optimization into a foundational hardware requirement.

Throughout this ongoing series, we have analyzed how contemporary AI workloads are testing the limits of standard hardware design. We explored why servers can no longer rely on standard NAND flash alone, how High Bandwidth Memory (HBM) keeps data pipelines saturated, and where Storage Class Memory (SCM) bridges the architectural gap between DRAM and persistent storage. We have also covered the rising role of High Bandwidth Flash, the limitations of standalone DRAM, the persistent economic reality of hard drives at scale, and the industry-wide migration toward computational storage.

KV Cache serves as the invisible thread connecting all of these hardware layers. Because once an AI model reaches enterprise scale, the primary operational bottleneck is no longer just generating intelligence—it is remembering what has already been processed without repeatedly paying the massive computational tax of recalculating it.

What KV Cache Actually Is

At its core, KV Cache stands for Key-Value Cache. It is a specialized memory optimization technique designed to eliminate computational redundancy in transformer-based AI models.

To understand its function, consider how an LLM processes text. Every time a model evaluates a sequence, it maps out intricate internal relationships (attention weights) that dictate how words, phrases, and historical prompt context interact. In a standard stateless execution environment, recalculating these mathematical matrices for every single consecutive word would overwhelm both the GPU cores and the system’s available memory bandwidth.

KV Cache solves this by temporarily storing the “Keys” and “Values” of previously processed tokens in fast memory. By keeping these mathematical states intact, the model can instantly reuse them to generate the next token in a sequence rather than building the contextual history from scratch. In short, the system retains its mathematical train of thought as a conversation expands.

Shifting the Bottleneck from Compute to Flow Control

The growing reliance on KV Cache highlights a broader reality: modern AI systems no longer function as isolated, burst-heavy calculators. They operate as continuous data streams.

Every incoming prompt, generated token, and multi-turn agent workflow creates an ongoing fluid dynamic that the underlying hardware must manage in real time. While general tech coverage focuses heavily on the raw teraflops of a GPU, hardware deployment at scale tells a different story. Once inference workloads are distributed across millions of concurrent enterprise users, the engineering challenge shifts away from compute spikes and directly toward maintaining stable, uninterrupted memory flow.

In this environment, KV Cache functions less like static storage and more like an infrastructure traffic controller.

The Hydroelectric Dam Analogy

To visualize this dynamic, imagine a massive hydroelectric dam supplying power to a regional grid. The incoming river represents the continuous stream of user prompts and contextual tokens. The GPU serves as the heavy turbine system, converting that kinetic water flow into usable computational output.

Without a caching mechanism, the system would be forced to pump water all the way back upstream every time the grid requested an additional watt of power. Even with the world’s most efficient turbines, this constant, repetitive round-trip movement would introduce severe operational latency, massive power waste, and systemic instability.

KV Cache restructures this workflow by acting as a highly controlled reservoir positioned directly behind the turbines. Instead of forcing data back through the entire structural loop, the system keeps the most critical, immediate context ready for deployment.

This localized stability is vital because the rate at which data is fed into the compute engine dictates the efficiency of the entire rack. If the reservoir cannot supply data fast enough, expensive GPU architectures sit idle, waiting for memory cycles to catch up. The modern optimization problem is straightforward: AI platforms do not just need to think quickly; they need to remember quickly.

Why Massive Context Windows Strain the Memory Hierarchy

This architectural pressure accelerates dramatically as commercial context windows expand from a few thousand tokens to millions of tokens.

While a brief customer service chatbot interaction requires minimal active memory overhead, deep enterprise reasoning tasks—such as parsing massive legal repositories, analyzing entire software codebases, or running autonomous agents—fundamentally alter the math. Under these conditions, the required memory reservoir becomes immense, demanding that hardware preserve vast arrays of contextual data while maintaining sub-millisecond responses.

This is the exact inflection point where software caching algorithms collide with physical hardware constraints:

• HBM is required because the immediate GPU boundary demands unprecedented memory bandwidth.
• DRAM is deployed because active enterprise workloads require capacity pools larger than what HBM can economically scale to.
• Storage Class Memory (SCM) is introduced to smooth the physical latency gap between system DRAM and persistent flash layers.
• High Bandwidth Flash and high-capacity hard drives manage the underlying multi-terabyte training sets and archival data stores.

Because every single megabyte of cached contextual data introduces a direct trade-off between localized latency, hardware cost, and thermal power draw, the ultimate goal of modern AI engineering is shifting. The most efficient AI infrastructure of the next decade will not necessarily be the one that claims the highest theoretical compute ceiling; it will be the system built to minimize data movement and eliminate redundant calculations entirely.

AI Memory Infrastructure Series

This article is the eighth installment in our deep-dive series analyzing how enterprise AI workloads are reshaping modern memory, storage, and compute architectures. Read our previous installments for foundational context:

• Installment One:
  NAND Isn’t Going Away, But AI Servers Now Depend on More Than Flash
• Installment Two:
  What Is High Bandwidth Memory (HBM) and Why AI Depends on It
• Installment Three:
  Storage Class Memory Explained: The Missing Layer Between DRAM and NAND
• Installment Four:
  High Bandwidth Flash: Can NAND Finally Act Like Memory?
• Installment Five:
  Why DRAM Alone Can’t Keep Up with AI Anymore
• Installment Six:
  Why Hard Drives Are Still Critical for AI Infrastructure
• Installment Seven:
  Why AI Is Moving Compute Closer To Storage
• Installment Eight: KV Cache Explained: Why AI Memory Is Starting To Matter More Than Raw Compute

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

In a building disconnected from every network on Earth, the data still found a way to leak out.

The Air-Gapped Echo

People think disconnected means invisible.

It doesn’t.

It just means the signal has to work harder.

The facility sat beneath the city like a buried mistake.

No windows. No external lines. No wireless infrastructure within three hundred meters. Even maintenance crews worked under rotating identities so nobody stayed long enough to understand what the place actually did.

Officially, the building handled nothing.

Unofficially, it handled everything nobody trusted on a network.

Markets.

Defense simulations.

Predictive governance models.

Identity archives.

The kind of data that stops being information and starts becoming leverage.

They called it air-gapped.

Like the phrase itself was enough to make people relax.

No internet connection.

No cloud exposure.

No outside access.

Safe.

That word always makes me nervous.

I got the contract at 01:42 from a broker who never used names twice.

Physical extraction only.

No uplink.

No relay.

No transmission of any kind.

A target inside the compound needed a storage device moved from the core vault to a secondary dead-drop six districts away before sunrise.

Simple job.

Which usually means someone is lying.

The package was waiting in a locker beneath an abandoned tram station.

Small black case.

Heavy for its size.

Inside sat a matte-gray USB device wrapped in layered shielding foam like it was radioactive.

No branding.

No serials.

Just a stamped symbol near the connector:

ECHO-0

I lifted it carefully.

The thing about sensitive electronics is they all make noise.

Not audible noise.

Electrical noise.

Tiny emissions bleeding off processors, controllers, voltage regulators, memory operations. Every machine whispers while it works. Most people never notice because modern cities are oceans of overlapping signals.

But in the right conditions?

Those whispers become fingerprints.

The note inside the case was short.

DO NOT ACCESS IN TRANSIT.

THEY ARE LISTENING.

No signature.

No instructions beyond the route.

I smiled a little.

Paranoia ages well in this city.

Outside, rain crawled sideways through neon haze while delivery drones drifted overhead like mechanical jellyfish. Traffic systems hummed below the pavement. Advertisements tracked eye movement from cracked building glass.

The whole city vibrated with signals.

Which made the silence around the compound feel unnatural.

That was the first thing I noticed when I arrived.

No commercial frequencies nearby.

No casual wireless chatter.

No device clutter.

The area had been intentionally scrubbed clean.

Which meant any signal inside the perimeter stood out like a scream.

Two security gates.

Three biometric checks.

No armed guards visible.

Places that confident usually hide their weapons in walls.

The contact met me below ground level wearing a gray utility jacket with no insignia.

Thin.

Exhausted.

The kind of face people get after too many weeks spent near systems they no longer trust.

“You’re late,” he said.

“I’m alive,” I answered.

“That’s usually slower.”

He didn’t laugh.

Bad sign.

We moved through concrete corridors lined with acoustic foam and copper mesh layered behind exposed wall panels. Every door sealed magnetically after we passed.

No network terminals.

No wireless devices.

No personal electronics allowed beyond checkpoint four.

The deeper we went, the quieter the world became.

Not peaceful quiet.

Suppressed quiet.

Like the building was holding its breath.

Finally he stopped outside a reinforced access chamber.

“You know why this place exists?” he asked.

“Someone with money got scared.”

“That’s every building in the city.”

He nodded once.

“Fair.”

Then he leaned closer.

“The system inside has no external connection. Physically impossible to reach remotely.”

“But?”

His eyes shifted toward the wall.

“They’re still pulling data out.”

That got my attention.

“How?”

“They don’t breach the network.”

He paused.

“They listen to it.”

Inside the chamber sat rows of isolated compute racks glowing behind transparent shielding panels. Cooling systems pulsed softly overhead. Diagnostic lights blinked in slow patterns across matte-black hardware arrays.

At first glance it looked ordinary.

Then I noticed the walls.

Layered reinforcement.

Wave dampening materials.

Additional shielding retrofitted after construction.

The kind of upgrades you make after discovering your original protection failed.

The engineer pointed toward the cooling systems.

“Fans,” he said quietly.

“What about them?”

“They resonate differently depending on workload.”

I stared at him.

“You’re kidding.”

“I wish I was.”

He moved toward a terminal and brought up a live waveform analysis.

Tiny fluctuations danced across the display.

Frequency spikes.

Power variance.

Electromagnetic leakage.

Not enough to matter to normal equipment.

Enough for specialized receivers.

“Tempest harvesting,” he said. “They park signal arrays in surrounding infrastructure and reconstruct operations from emissions.”

“They can read the data?”

“Not directly.”

He hesitated.

“Patterns. Access timing. Encryption behavior. Compute states. Sometimes fragments.”

“That’s impossible.”

“So was reading conversations through fiber vibration until someone did it.”

Fair point.

The engineer handed me the drive.

“The extraction package is already loaded.”

“No network transfer?”

He looked offended.

“If we could network-transfer it, you wouldn’t be here.”

Another fair point.

“What’s on it?”

He studied me for a second too long.

“The kind of thing people kill cities over.”

I slid the drive into an interior pocket lined with shielding fabric.

The engineer noticed.

“Good,” he said.

“You expected otherwise?”

“You’d be surprised how many couriers trust pockets.”

“What exactly are they listening for?”

He looked toward the ceiling.

“Not you.”

That answer sat badly.

“They’re listening for the drive.”

I frowned.

“The drive emits?”

“Everything emits.”

He tapped the side of the nearest rack.

“Controller operations. NAND access. Voltage regulation. Even idle states have signatures.”

He swallowed hard.

“Whoever’s outside already knows this dataset exists.”

“And if they detect movement?”

“They’ll know it left the building.”

That changed the job completely.

This wasn’t about stealing data anymore.

It was about crossing a city without creating a detectable change in the signal environment.

Outside the facility, rain hammered the streets harder now.

I kept moving.

No transit systems.

Too trackable.

No autonomous vehicles.

Too connected.

Just sidewalks, alleys, maintenance corridors, and instinct.

The city sounded different carrying that drive.

Every surveillance mast looked hungry.

Every rooftop antenna looked aimed at me.

Twice I spotted vans parked near utility infrastructure with passive receiver arrays hidden beneath fake service panels.

Signal sniffers.

Not watching faces.

Watching frequencies.

I ducked into a flooded market tunnel and cut power through a breaker junction behind a maintenance hatch.

The district went dark instantly.

Advertising walls died.

Storefront projections collapsed.

The city groaned as backup systems kicked in.

And for thirteen beautiful seconds?

Signal noise exploded everywhere.

That was enough.

I moved three blocks during the confusion.

Sometimes stealth isn’t about hiding.

Sometimes it’s about making the world louder than you are.

The dead-drop sat inside an abandoned recording studio above the river sector.

Old acoustic walls.

Analog equipment.

Lead-lined insulation from another era.

Perfect.

A woman waited inside beneath dim emergency lights.

No introductions.

People in my profession avoid unnecessary memory.

“You have it?” she asked.

I handed over the case.

She didn’t open it immediately.

Smart.

Instead she held a small handheld scanner near the shielding shell.

The device chirped softly.

Then stopped.

“Clean,” she whispered.

“For now.”

She finally looked at me directly.

“Do you understand what you carried?”

“Not my hobby.”

“It’s a hardware snapshot of the facility’s governance model.”

That made me pause.

“The predictive engine?”

She nodded.

“Unmodified.”

I laughed once under my breath.

“That explains the panic.”

The city’s economic systems depended on those models now. Infrastructure timing. Utility balancing. Resource allocation. Market stabilization.

Most people thought algorithms advised governments.

Truth was simpler.

Governments stopped making decisions years ago.

The systems just became too efficient to argue with.

“And now?” I asked.

She looked toward the rain-streaked windows.

“Now we find out who’s been listening.”

A low vibration rolled through the building.

Not thunder.

Engines.

Outside, drones drifted silently over the river district.

Search patterns.

Passive scans.

No lights.

No sirens.

Which meant they still weren’t sure where the signal ended up.

Only that it moved.

The woman secured the drive inside a larger shielded container.

“You should go.”

“Already planning to.”

I headed for the stairwell when she stopped me.

“One more thing.”

I looked back.

“The air-gap failed years ago,” she said quietly.

“People just didn’t realize physics was part of the network.”

I stepped back into the rain.

Above me, the city glowed with invisible conversations.

Signals leaking through walls.

Machines whispering to anyone patient enough to listen.

And somewhere beneath the streets, deep inside a building disconnected from the world, systems still hummed quietly to themselves.

Believing silence meant safety.

Read more Mara Vale stories exploring cyberpunk noir themes tied to USB security, electromagnetic surveillance, AI systems, and the growing tension between physical hardware and invisible networks. The Mara Vale series was created to bring a little atmosphere, tension, and cinematic storytelling into a technology journal that occasionally drifts into the dry side of engineering.

Mara Vale is a fictional cyberpunk noir series created by GetUSB to explore real-world technology concepts through storytelling. Topics featured in the series are inspired by legitimate discussions surrounding USB security, air-gapped systems, write protection, electromagnetic leakage, AI infrastructure, and data integrity. Story direction, technical themes, and editorial oversight are developed by the GetUSB team, with AI-assisted support used for structure refinement and visual concept generation.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

There is a moment almost everyone experiences with a modern USB flash drive where reality suddenly interrupts the marketing.

You plug in a brand-new USB stick. The package promises blazing-fast performance. Maybe the website says 300MB/s write speed. Maybe a reviewer showed benchmark screenshots proving how fast it is. Everything looks impressive.

Then you copy a large folder onto the drive.

At first, the transfer screams along exactly as advertised. The progress bar flies. Windows reports incredible write speeds. You start thinking storage technology has finally reached the point where tiny USB drives behave like miniature supercomputers.

Then something strange happens.

The speed falls off a cliff.

What started at 300MB/s suddenly becomes 80MB/s. Then 45MB/s. Sometimes even lower. The progress bar slows to a crawl and now you are staring at “18 minutes remaining” wondering what happened to the miracle drive you just bought.

In our earlier article, Why You Should Ignore Every “Best USB Drive” List, we talked about how most USB benchmark articles focus heavily on short burst speeds while ignoring the deeper behavior of the device itself. That article was the broader argument. This article is the technical explanation underneath it.

Because once you understand how BOT and UASP work, how NAND caching behaves, and how modern USB controllers manage sustained writes, you start to see why many “300MB/s” claims only tell part of the story.

Burst Speed and Sustained Speed Are Not the Same Thing

Most USB flash drives today use some form of caching to make the first part of a write operation look much faster than the drive can actually maintain over a long transfer.

Modern NAND flash memory is often based on TLC or QLC technology. Those memory types are excellent for capacity and cost, but they are not always great at writing large amounts of data continuously. To work around that limitation, many drives use a temporary high-speed area often called pseudo-SLC cache.

Think of that cache like the front counter at a busy shipping office. At first, packages are dropped quickly onto the counter and everything feels fast. But if the back room cannot process those packages at the same pace, the counter eventually fills up. Once that happens, the whole operation slows down to the speed of the back room.

That is what happens inside many USB flash drives. The first part of the transfer goes into fast cache. Once the cache fills, the controller must write directly into slower NAND or begin folding cached data into long-term storage while still accepting new data from the computer.

That is when the real sustained write speed appears.

The USB Protocol Also Matters

Now let’s add another layer, because the flash memory is not the only thing controlling performance.

The way the USB device communicates with the computer also matters. Two common transport methods are BOT and UASP. The names are not friendly, but the difference is important.

BOT stands for Bulk-Only TransportAn older USB data transfer protocol where commands are processed sequentially, limiting efficiency.. It is the older method used by many traditional USB flash drives. BOT works in a very straightforward way: the computer sends one command, waits for that command to finish, then sends the next command.

That is simple and compatible, but not very efficient.

UASP stands for USB Attached SCSI ProtocolA modern USB data transfer protocol that improves efficiency by supporting command queuing and parallel processing.. UASP is newer and more efficient because it supports command queuing and parallel command handling. Instead of waiting for one task to fully complete before starting another, UASP keeps the storage pipeline moving more smoothly.

If BOT is a single-lane road with stop signs, UASP is closer to a multi-lane road with better traffic flow. Both roads may lead to the same destination, but one wastes less time between movements.

BOT Can Hold Back Performance

With BOT, the storage device spends more time waiting between commands. That extra waiting may not matter much for a cheap USB 2.0 drive moving small files, but it becomes more noticeable as the storage media gets faster.

This is especially true with mixed workloads, random file transfers, and larger sustained operations where the controller needs to manage many requests efficiently. BOT does not handle that style of traffic particularly well because it was built for an older storage world.

That does not mean BOT is broken. It simply means BOT is limited. It works, but it is not the most efficient way to move data through a modern high-speed USB storage device.

UASP Helps, But It Does Not Fix Everything

UASP improves the communication side of the equation. It lowers latency, supports better command handling, and can reduce overhead between the computer and the storage device. This is one reason many external USB SSDs feel much faster and smoother than ordinary flash drives.

But UASP is not magic.

If the NAND inside the drive is slow, if the controller is weak, if the cache is small, or if the device overheats quickly, UASP cannot turn that hardware into something it is not.

A better transport protocol helps data reach the controller more efficiently. It does not change the physical limits of the NAND memory once the controller has to write data for real.

That is the subtle point many speed claims miss. A drive can support a fast interface and still have poor sustained write behavior after the cache is exhausted.

Why the First 20 Seconds Can Be Misleading

A short benchmark often shows the drive at its best possible moment. The drive is empty. The cache is available. The controller is cool. Garbage collection has not yet become aggressive. The test may use large sequential blocks that make the device look clean and efficient.

That is not the same as copying 80GB of video files, a folder full of mixed documents, or a complete software image onto the drive.

During a long transfer, several things begin happening at the same time. The cache fills up. The controller starts reorganizing data internally. The NAND write speed becomes the real limit. Heat can build. Firmware decisions become more visible. If the drive is built around cost rather than sustained performance, the drop becomes obvious.

This is why a “300MB/s” flash drive may technically hit that speed and still not behave like a 300MB/s drive during a real workload.

Why This Matters More Than Benchmark Screenshots

For casual use, the difference may only be annoying. A person copies vacation photos or a few PDFs, waits a little longer, and moves on.

In professional environments, the difference matters more. If you are duplicating USB drivesThe process of copying data from one USB flash drive to multiple USB drives simultaneously or sequentially., distributing software, preparing field update media, recording data, or moving large image files, sustained write performance becomes the real measure of the device.

A drive that looks impressive in a short benchmark may perform poorly when asked to repeat the same write process hundreds of times. That is where weak NAND, small cache, poor controller design, and thermal limitations become impossible to hide.

This is also why professional USB workflows tend to care about the full behavior of the device, not just the number printed on the package. Speed is part of the story, but it is not the whole story.

The Better Question to Ask

The better question is not simply, “How fast is this USB drive?”

The better question is, “How long can this USB drive maintain that speed?”

That one change in wording moves the discussion from marketing into engineering. It forces you to think about NAND type, controller design, cache size, thermal behavior, transport protocol, firmware quality, and the workload being tested.

Burst speedThe initial high data transfer rate a storage device achieves before slowing down during sustained use. shows what the drive can do under easy conditions. Sustained speed shows what the drive is actually made of.

Did You Notice?

The image used for this article quietly proves the entire point.

The USB flash drive packaging advertises write speeds up to 400MB/s, yet the actual sustained transfer shown during the large file copy operation is closer to 125MB/s. That difference is not necessarily fraud or fake advertising. It is the gap between burst performance and sustained real-world behavior.

USB flash drive marketing still leans heavily on simple speed numbers because simple numbers are easy to print, easy to compare, and easy to sell.

But real USB performance is more layered than that.

BOT versus UASP matters. Cache behavior matters. NAND quality matters. Controller design matters. Sustained write testing matters.

Once you understand those layers, a single “300MB/s” claim starts to look less like a final answer and more like the beginning of a better question.

Because in modern USB storage, the real difference between products is not always how fast they perform for ten seconds. It is how intelligently they behave once the easy conditions disappear.

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.

If you’ve followed the earlier installments in this series, you’ve probably noticed a pattern beginning to emerge.

In the first article, we discussed how NAND flash isn’t disappearing, but instead becoming part of a much larger AI memory hierarchy. After that, we looked at High Bandwidth Memory (HBM) and why modern GPUs depend on having data physically closer to the processor. Then we moved into Storage Class Memory, High Bandwidth Flash, the limitations of DRAM scaling, and finally why even traditional hard drives still remain critical because AI infrastructure operates at a scale that most people dramatically underestimate.

At first glance, those may seem like separate topics.

They aren’t.

They are all symptoms of the same underlying pressure: AI systems are no longer struggling primarily with compute power. They are struggling with how efficiently they can move data.

That shift changes almost everything about how infrastructure gets designed.

For decades, computing followed a fairly stable model. Storage held the data, memory staged it, and processors fetched what they needed. As processors became faster, the system simply tried to feed them more efficiently using better buses, larger caches, and faster memory technologies.

AI changed the scale of the problem.

Modern GPU clustersA group of interconnected GPUs working together to perform parallel processing tasks. can process information at such a massive rate that the act of moving data around the system has started becoming one of the largest bottlenecks in the entire architecture. In some environments, the processor itself is no longer the slow part. The delay comes from getting the right data to the processor quickly enough and consistently enough to keep it fully utilized.

That realization is quietly forcing the industry into a new direction.

Instead of continuously moving larger amounts of data back and forth across the system, AI infrastructure is starting to move portions of compute closer to where the data already lives.

And once you understand why that is happening, many of the earlier articles in this series begin fitting together much more clearly.

AI Is Starting To Hit a Data Movement Wall

One of the most important ideas from the earlier HBM article was that modern AI systems often slow down not because the processor lacks compute capability, but because the system cannot deliver data fast enough to keep the processor busy.

That issue becomes much more serious once AI workloads scale outward across entire racks and clusters.

A modern AI accelerator can consume astonishing amounts of information in parallel. The problem is that datasets are no longer small enough to sit entirely inside the fastest memory tiers. Even with HBM and large pools of DRAM, enormous amounts of data still need to travel across interconnects, buses, fabrics, storage layers, and network infrastructure.

That movement has a cost.

It shows up as latency, but that is only part of the story. It also shows up as power draw, heat, cooling demand, congestion, synchronization delays, and idle compute cycles. As we discussed in the DRAM installment, even tiny delays become surprisingly expensive once thousands of GPUs are operating at the same time. A small pause multiplied across a large AI cluster can represent an enormous amount of lost utilization.

That changes the engineering priorities.

For years, infrastructure was largely designed around maximizing compute performance. AI systems are now forcing engineers to think just as heavily about data locality, meaning where information physically sits relative to the processor trying to use it.

Put simply, distance now matters far more than it used to.

GPUs Became So Fast That The Rest Of The System Started Falling Behind

One of the strange things about AI infrastructure is that progress in one area tends to expose weaknesses somewhere else.

As GPUs became faster, memory bandwidth became the bottleneck. That led to HBMHigh Bandwidth Memory (HBM) is a type of fast, stacked memory used to increase data transfer rates between memory and processors, especially in GPUs.. As HBM capacity limitations became more obvious, the industry started introducing intermediary layers like Storage Class Memory. As DRAM scaling became expensive and physically difficult, systems started leaning more heavily on NAND while also exploring concepts like High Bandwidth Flash.

And as AI datasets continued expanding into the petabyte and exabyte range, hard drives quietly remained essential because the economics of storing that much information simply could not work any other way.

Each article in this series has really been pointing toward the same conclusion from a different angle.

The old assumption that compute sits here while storage sits over there is beginning to break apart. The reason is fairly simple: GPUs can now process data faster than traditional architectures can comfortably deliver it.

That creates a situation where enormous amounts of system activity are spent simply transporting information from one place to another. In practical terms, some AI environments are starting to look less like pure compute problems and more like logistics problems.

The Industry Started Asking A Different Question

For a long time, storage innovation focused mostly on making storage devices faster. Faster SSDs, faster interfaces, faster NAND, and faster controllers all mattered, and they still matter today.

But AI workloads started exposing a deeper issue underneath all of that.

At some point, engineers began realizing the problem was not always the speed of the storage device itself. The problem was the repeated movement of massive amounts of data back and forth across the entire system.

That subtle distinction matters because once the problem becomes data movement rather than simple storage speed, the solution starts changing too.

Instead of endlessly asking how storage can be made faster, the industry started asking how far the data needs to travel in the first place.

That question is now influencing nearly every part of modern AI infrastructure design.

Moving Compute Closer To Where Data Already Lives

This is where the architecture starts to shift.

Rather than treating storage as a completely passive layer that simply waits for requests, newer systems are beginning to perform certain tasks closer to the data itself. Not necessarily full-scale GPU processing, but localized operations that reduce unnecessary movement throughout the rest of the system.

Some systems now perform filtering, indexing, search operations, compression, retrieval preparation, and data organization closer to the storage layer before the information ever reaches the primary compute engines.

The goal is not to eliminate GPUs or replace fast memory. The goal is to reduce waste.

If the system can avoid transporting enormous amounts of unnecessary data across the infrastructure, the entire platform becomes more efficient. This is one of the reasons the line between compute and storage is starting to blur.

Storage is no longer behaving like a completely inactive destination sitting at the bottom of the hierarchy. It is becoming more involved in how data is prepared, staged, filtered, and delivered upstream.

If you think back to the earlier article on High Bandwidth Flash, this direction makes a great deal of sense. That article showed how NAND itself was being pushed toward more memory-like behavior. This article extends the same idea one step further by showing how the surrounding architecture is also adapting around the cost of data movement.

The Warehouse Analogy Starts Looking Different

The warehouse analogy we’ve used throughout this series still works here, but the warehouse itself has started evolving because the workload inside it has changed.

In the earlier installments, the layout was fairly straightforward. HBM represented the loading dock where the next pallet was already waiting beside the workers. DRAMA type of fast, volatile memory used to store active data for quick access by the processor. acted as the active floor space where the immediate sorting and handling took place. Storage Class Memory became the staging area sitting just behind the dock, while NAND represented the primary warehouse shelving further back. Hard drives handled the deeper bulk storage where long-term inventory lived because capacity mattered more than immediate access speed.

That model still generally holds together, but AI systems are beginning to expose inefficiencies in how much movement happens between those areas.

Imagine a warehouse where workers spend more time driving forklifts back and forth across the building than actually processing inventory. At first, management responds by buying faster forklifts, widening the aisles, and improving the loading docks. Those upgrades help for a while, but eventually the operation reaches a point where transportation itself becomes the problem. The delays are no longer caused by slow workers or inadequate equipment. The delays come from the sheer amount of movement required to keep the workflow operating.

That is increasingly what large AI systems are running into.

The issue is no longer just how quickly data can be processed once it reaches the GPU. The issue is how much infrastructure effort is spent repeatedly transporting that data across the system in the first place.

So instead of endlessly optimizing transportation, the layout begins to change. Small workstations start appearing closer to the shelves themselves. Certain sorting tasks happen locally. Filtering happens locally. Data preparation begins happening nearer to where the information already resides, reducing how often the system has to move massive amounts of material back and forth across the entire operation.

That shift is essentially what AI infrastructure is starting to do at the architectural level. The goal is not to turn storage into a processor or eliminate centralized compute altogether. The goal is to reduce unnecessary movement because at AI scale, even small inefficiencies become surprisingly expensive once they are multiplied across thousands of accelerators operating simultaneously.

AI Infrastructure Is Becoming More Distributed By Necessity

One of the more interesting consequences of this shift is that AI infrastructure is starting to become far more distributed than traditional computing environments ever needed to be.

Older architectures assumed most of the important work would happen in centralized compute locations while storage remained largely passive and separated from the processing layer. That model worked reasonably well for decades because the amount of data moving through the system was still manageable relative to the speed of the processors consuming it.

AI changes the scale of the equation entirely.

The amount of information being processed, revisited, staged, cached, indexed, and retrieved is now so large that centralized movement itself begins creating inefficiencies. Instead of compute simply reaching downward into storage whenever it needs something, systems are increasingly trying to keep useful data positioned closer to where it will likely be used next.

That is part of the reason technologies like vector databases, distributed inference systems, retrieval layers, localized caching, and near-data processing have started receiving so much attention. On the surface, these may appear like separate technologies solving unrelated problems, but underneath they are all responding to the same pressure. The industry is trying to reduce how often enormous amounts of information must travel long distances across the infrastructure before meaningful work can begin.

As you’ve probably noticed throughout this series, the memory hierarchy itself is gradually becoming less rigid than it used to be. The clean separation between “compute over here” and “storage over there” is starting to soften because AI workloads reward systems that keep data physically closer to where processing occurs.

That trend is likely to continue because the economics of large-scale AI increasingly favor efficiency in movement just as much as raw compute capability.

The Memory Hierarchy Is Starting To Blur Together

One of the quieter themes running underneath every installment in this series has been the gradual erosion of the old boundaries between memory, storage, and compute.

In the HBM article, we looked at how memory was physically moved closer to the processor itself because even traditional DRAM placement began introducing delays large enough to matter at AI scale. In the Storage Class Memory installment, the focus shifted toward reducing the sharp transition between fast memory and slower persistent storage. High Bandwidth Flash pushed NAND into a more active role inside the working data path, while the DRAM article showed why simply scaling traditional memory upward indefinitely becomes difficult both economically and physically.

Now this article pushes that same progression one step further by showing how the architecture itself is adapting around the cost of moving data.

What makes this particularly interesting is that none of these technologies are truly replacing one another. The industry did not abandon NAND once HBM arrived. It did not replace DRAM simply because Storage Class Memory appeared. Hard drives also remain deeply relevant despite decades of predictions claiming solid-state storage would eliminate them entirely.

Instead, the system is becoming more layered, more specialized, and more aware of where data physically exists relative to the compute resources trying to consume it.

That distinction matters because it changes how we should think about the future of AI infrastructure. The evolution is not happening because one breakthrough technology suddenly solved everything. The evolution is happening because the workload itself forced the industry to reorganize how every layer participates in feeding information to the compute side efficiently.

Once you step back and look at the broader picture, the pattern becomes much easier to see. Every major shift we’ve discussed throughout this series ultimately points toward the same objective: reducing how much time, energy, and infrastructure overhead is spent simply moving information from place to place.

The Future May Depend More On Data Placement Than Raw Compute

For a very long time, the technology industry largely measured progress through raw compute capability. Faster processors, larger accelerators, more cores, and greater parallelism were treated as the primary indicators of advancement because, for most traditional workloads, improving compute performance generally improved the system as a whole.

AI is forcing a more nuanced conversation.

Once processors become fast enough, the larger challenge stops being the ability to execute operations and starts becoming the ability to keep those processors supplied with useful data consistently enough to avoid expensive idle time. That subtle change is now influencing nearly every major architectural decision happening inside modern AI infrastructure.

The interesting part is that the solution is no longer simply building faster storage devices or larger pools of memory in isolation. Instead, the industry is increasingly focused on where data lives throughout the system, how often it moves, and how intelligently the architecture can minimize unnecessary transportation before compute resources ever become involved.

That is why proximity has become such a recurring theme across every article in this series. HBM moved memory physically closer to the GPU. Storage Class Memory reduced the gap between memory and storage. High Bandwidth Flash attempted to make NAND participate more actively in the memory hierarchy. Distributed storage systems and near-data processing architectures are now trying to reduce how much movement happens across the infrastructure itself.

All of these developments are responding to the same realization.

At AI scale, moving data efficiently is becoming almost as important as processing the data once it arrives.

And that may ultimately become one of the defining architectural shifts of the entire AI era.

AI Memory Infrastructure Series

This article is part of our ongoing series on how AI infrastructure is reshaping the relationship between memory, storage, and compute. If you are joining the discussion here, the earlier installments provide the foundation for why this shift is happening.

Installment One:
NAND Isn’t Going Away, But AI Servers Now Depend on More Than Flash

Installment Two:
What Is High Bandwidth Memory (HBM) and Why AI Depends on It

Installment Three:
Storage Class Memory Explained: The Missing Layer Between DRAM and NAND

Installment Four:
High Bandwidth Flash: Can NAND Finally Act Like Memory?

Installment Five:
Why DRAM Alone Can’t Keep Up with AI Anymore

Installment Six:
Why Hard Drives Are Still Critical for AI Infrastructure

Installment Seven:
Why AI Is Moving Compute Closer To Storage

This article originally appeared on GetUSB.info. Subscribe to GetUSB updates.