Representation and memory · Evidence comparison
Could memristors be the way forward for efficient AI?
Across my four-part series and the energy-and-water recap, I have been working toward one question: can we build AI that carries useful state forward, processes incoming information directly, and spends less effort repeatedly reconstructing and explaining the same context?
I believe memristor-based computing is worth pursuing because it brings memory and computation closer together. That could reduce the movement of data that consumes energy in conventional systems. My preference is a research direction, not a claim that memristors already outperform every alternative.
Here I compare all five articles, connect them to my BrainAi software emulator, and separate public hardware demonstrations from simulations and ideas I still need to test. This is a selected evidence review as of September 10, 2026, rather than an exhaustive ranking of every AI processor.
11 min read
Practical Takeaway
A promising route is a hybrid system
I would combine efficient feature extraction, retained evidence, selective state updates, and language output when useful. Physical memristor hardware could accelerate suitable operations within that system. Its value must be demonstrated at matched quality with the complete workload measured.
Evidence comparison · 01
How my five articles fit together
These articles describe different layers of a possible system. Neuralese is about representation; ECI organizes observations and history; memristor-inspired state changes what persists inside a computation. Physical memristor hardware is a further implementation choice. They are complementary ideas, so I would not rank their names as if they were interchangeable products.
I published this comparison on September 10. Part 3 is scheduled for September 13; its link leads to the preview until release.
| Article | Question I explored | Possible efficiency contribution | What it does not establish |
|---|---|---|---|
| Part 1 — Neuralese | How should a machine represent information? | Avoid unnecessary conversion of intermediate results into prose | Vectors still require computation; Neuralese is not a standard protocol |
| Part 2 — Memristor-inspired state | How can prior activity change persistent state? | Reuse context and study selective adaptation | Software state does not prove hardware energy savings |
| Part 3 — ECI | How do repeated observations reveal change? | Compare with retained evidence instead of starting over | Field validation and efficiency measurements remain necessary |
| Part 4 — Comparison | How do representation, history and state differ? | Choose only the mechanisms a task needs | Combining mechanisms is not automatically more efficient |
| Recap — Beyond tokens | Could reduced computation lower energy and water use? | Connect architecture choices to measurable resource demand | Token counts cannot be converted directly into water savings |
Evidence comparison · 02
Why I think memristors could help
In suitable analog compute-in-memory arrays, device conductances encode weights, applied voltages represent inputs, and accumulated currents implement weighted sums. Computing near stored weights can reduce repeated transfers between memory and a separate processor. This is the hardware opportunity that interests me.
That mechanism is distinct from adaptive conversational memory. A device may hold an inference weight without updating it during a conversation. Building my proposed assistant also requires rules for what to retain, when to update, how to correct mistakes, and when to speak. Persistent hardware alone does not supply those behaviors.
I also separate avoiding unnecessary language generation from accelerating a model that still uses tokens. Compute-in-memory can potentially serve either design. Replacing a processor does not automatically change a model’s input representation or its reasoning method.
Evidence comparison · 03
What public research actually demonstrates
I find the strongest case in demonstrated components and explicit limits. The examples below support continued research, but they do not provide a matched benchmark of my proposed assistant. Hardware measurements, architectural simulations, and software tests answer different questions.
| Public work | Type of evidence | What was demonstrated or explored | Limit on the conclusion |
|---|---|---|---|
| Yu et al., Nature Communications, March 2025 | Physical system plus software/hardware optimization | Six neural-network models across four tasks on a memristor-based system | Model mapping and noise management still matter; not a BrainAi benchmark |
| Fault-free analogue computing, Nature Electronics, 2026 | Research hardware and fault-compensation method | A method addressing faulty and variable memristor devices in analogue computation | Progress on reliability is not a universal end-to-end efficiency result |
| IBM Research, January 2025 transformer work | Architectural simulations described by the research team | 3D analog in-memory designs for transformer and mixture-of-experts workloads | Projected improvements are not measurements of a deployed general-purpose assistant |
| Luccioni et al., FAccT 2024 | Measured model-inference comparisons | Task-specific models were more efficient than general-purpose generators on several evaluated tasks | A strong simple baseline is still needed; results do not rank memristor hardware |
| Coconut latent reasoning research | Model experiments | Intermediate reasoning through continuous representations | Fewer generated text tokens do not establish whole-system energy or water savings |
Why I am not showing a single efficiency winner
A chip’s operations per watt cannot be fairly compared with an application’s observations per second without matching task, accuracy, precision, utilization, and measurement boundary. I would rather show what each result supports than manufacture a ranking.
Evidence comparison · 04
My local BrainAi prototype and test results
My BrainAi v0.7.0 prototype includes a CPU-based BindsNET memristor emulator. Its core receives seven normalized visual and audio features, connects them to four output neurons, and maintains 28 adaptive connection-state values. It models bounded resistance and maps conductance to synaptic weights.
I ran these tests locally on my own computer on September 10, 2026. In that local run, all 34 automated tests passed, including six memristor-model tests. They cover input handling, output behavior, inference without changing adaptive state, and rebuilding from retained history, alongside application tests. This is an author-reported local functional result, not an independently reproduced benchmark.
That gives me a concrete software starting point. It does not show lower energy consumption or model a particular manufactured device with calibrated physical accuracy. The wider application also runs speech, vision, and storage components; its total cost is larger than the small state matrix.
BrainAi also does not yet implement the complete language-understanding and conversational-memory design I described. I would use it to test state behavior and controlled workloads before making claims about a full assistant.
A small state is not the whole memory footprint
Twenty-eight float32 values occupy 112 bytes of numerical storage. That excludes tensor metadata, copies, other weights, neuron state, model parameters, runtime memory, and the knowledge ledger. I would measure the actual process and retained data separately.
Evidence comparison · 05
Payload size, throughput, latency and energy
For packet size, I would begin with application payload size: the bytes we serialize per observation. Seven float32 features would occupy 28 bytes in a packed binary representation. That is a calculated representation size, not a measurement of BrainAi’s current JSON requests or their network packets. JSON keys, numeric formatting, HTTP, transport headers, and any media uploads add overhead.
Throughput tells me how many observations the system handles per second. Latency tells me how long one observation waits for a result. Neither metric tells me whether the answer is useful, and neither proves lower energy consumption. I would measure them at the same quality threshold and include idle listening time.
| Metric | Unit | Measurement boundary | Comparison requirement |
|---|---|---|---|
| Application payload | Bytes per observation | Serialized request; report network bytes separately | Same information and observation rate |
| Memory footprint | Bytes / peak resident memory | Adaptive state, history, model and runtime separately | Same retention policy and model task |
| Throughput | Accepted observations per second | Core processing and full application separately | Same quality, concurrency and warm-up |
| Latency | Median and 95th-percentile milliseconds | Input arrival to usable result, including queues | Same hardware, workload and response policy |
| Learning overhead | Time and energy per update | Learning enabled versus disabled | Repeatable initial state and identical input sequence |
| Energy | Joules per accepted result; total kWh | Measured device/system power over the run | Include idle loads and all required processing |
| Water impact | Liters over a defined interval | Facility use and electricity-supply use separately | Use measured or documented site-specific factors |
# Calculated representation sizes, not network measurements:
feature_bytes = 7 * 4 # 28 bytes if packed as float32
adaptive_state_bytes = 28 * 4 # 112 bytes, excluding overhead
# Measurements still to collect:
throughput = accepted_results / elapsed_seconds
joules_per_result = measured_joules / accepted_results
# Also report quality, rejected results, total energy and p95 latency.
Evidence comparison · 06
The architecture I would try first
I would use a small causal filter or encoder to detect useful patterns in the incoming stream, feed those features into persistent context, and apply a response policy. Saved evidence would remain available for review. I would generate language when a person needs an explanation, rather than narrating every intermediate operation.
A hybrid implementation could put suitable matrix operations on memristor hardware while keeping control, retrieval, updates that require higher precision, and other unsuitable operations on digital hardware. For now, the software version lets me examine behavior before committing to a physical design.
Text filters can flag local cues but still need broader context for negation, references, and intent. Continuous listening would be opt-in, with clear mute and memory-reset controls. I would compare whole-day energy and unwanted interruptions against a push-to-talk baseline.
Evidence comparison · 07
What could prevent memristors from being the best choice
I would count the cost of analog-to-digital and digital-to-analog conversion, control circuitry, calibration, device variability, write endurance, and work that remains on a host processor. A fast weighted sum is not enough if the surrounding system dominates energy or delays.
Keeping state also creates software questions: drift, stale preferences, conflicting observations, and reproducible deletion or correction. Frequent learning may have a different cost profile from inference with stable weights. I would test both explicitly.
If a compact digital model or ordinary rolling statistic meets the same quality requirements with lower total cost, I would use it. My interest in memristors is a reason to test them carefully, not a reason to skip a simpler baseline.
Evidence comparison · 08
When efficiency becomes an environmental benefit
If we reduce total IT energy, we generally reduce the heat that must be removed. DOE connects cooling-tower water demand to heat load and cooling efficiency. Actual water savings depend on the facility’s cooling design and operating conditions; there is no universal liters-per-token conversion.
I would report energy and water at clearly defined boundaries and distinguish water withdrawn from water consumed. Reducing resource use per query is useful, but if query volume grows faster, the total footprint can still increase. Hardware manufacturing and replacement also belong in a broader environmental assessment.
My conclusion today is that memristor-based computing could be part of the way forward, especially where moving weights is expensive and the workload maps well to the hardware. The next convincing step is a matched experiment showing useful results with less total energy. BrainAi gives me somewhere to start that work.
The claim I am prepared to make
I have a working software emulator and public research showing real progress in compute-in-memory hardware. Together they justify an experiment. They do not yet establish that my proposed system is the most efficient—or that it saves a measured amount of cooling water.