Phison and Intel Take Aim at Local AI's Memory Wall with aiDAPTIV

Introduction & The Memory Wall

When it comes to running on-device AI, the biggest hurdle is usually the amount of memory the system has available. While the specifics of where that memory is coming from, whether it be CPU RAM or video card memory, have implications for the size and speed of any model you can run on a given device, the general assumption has always been that running a local AI model means using one or the other, or both, of these two types of memory together.

Part of what makes this moment interesting is that the demands on local AI are growing faster than the hardware underneath it. Not long ago, running AI on your own machine mostly meant a small, offline chatbot. Now, AI PCs are being asked to handle private document analysis, local RAG over your own files, coding assistance, multimodal work across text and images, and, increasingly, multi-step agentic workflows. Agentic apps like OpenClaw, which I have spent a good deal of hands-on time with recently, are a big part of that shift: they need a model that can reason through a task, make a plan, call tools, hold onto context, and act on the results, not just generate a one-off answer. Those jobs demand two things at once: more capable models, and more working memory to run them in.

This is where Phison's aiDAPTIV approach to extending effective AI working memory comes into play. At Computex 2026, Phison announced a collaboration with Intel to bring Pascari aiDAPTIV memory-extension technology to Intel AI PC platforms, including Core Ultra Series 3 systems, with support for OpenVINO and joint work on ISV validation, technical demonstrations, and optimized workloads. The aim is to let these AI PCs run larger models, hold longer conversations, and handle more complex agentic tasks than their installed DRAM would normally allow on its own. The headline number from Phison's own testing: with aiDAPTIV, a 26-billion-parameter model ran on a system with just 16GB of DRAM, where the same setup required 32GB without it.

What's notable is that aiDAPTIV expands the effective memory pool available to AI workloads beyond system DRAM and into a dedicated flash tier: Phison's Pascari aiDAPTIV Cache Memory. Historically, leaning on flash storage to stand in for RAM has been technically possible but painfully slow, the digital equivalent of sending a runner down the hall to a filing cabinet every single time you need a fact, rather than glancing at the notes already open on your desk. It works, but you feel every single trip, especially once the system needs to make that trip thousands of times a second. What makes aiDAPTIV different is that it's purpose-built for exactly this job, engineered specifically to accelerate and extend a system's ability to handle local AI workloads, rather than general-purpose flash storage pressed into service as a memory substitute.

How aiDAPTIV Works

Intelligent Middleware Plus Purpose-Built Flash

Under the hood, aiDAPTIV is really two pieces working together: software and flash. The software half is the aiDAPTIV Middleware, an intelligent orchestrator that manages eligible AI data across system DRAM and the flash tier, keeping the data the compute actively needs close at hand while retaining, offloading, recalling, and prefetching everything else as the workload's needs change. The hardware half is the aiDAPTIV Cache Memory, the purpose-built, high-endurance flash tier that makes the whole arrangement practical, with its hardware, controller, and firmware all tuned for the kind of sustained memory and cache activity that AI workloads generate. Together, the two extend a system's effective AI working memory beyond its installed DRAM.

5

The instinctive comparison here is the page file your operating system has used for decades to stretch RAM, but that comparison actually undersells what's happening. Ordinary swap is a blunt instrument; it has no idea what an AI model is doing or what it will need next. One of the most important data types here is the KV, the model's working short-term memory, which grows steadily as prompts, documents, tool outputs, and the prior steps of a task accumulate. Rather than forcing the runtime to discard that cache and burn compute recalculating it later, the aiDAPTIV Middleware can retain eligible cache data in the flash tier and bring it back when a later step needs it. For long sessions and multi-step agentic work, that difference between recalling and recomputing is exactly where the value lives.

Also on Display: Hybrid Routing

Separate from the Intel collaboration itself, Phison also showed a hybrid LLM router at Computex, built on OpenClaw, the open-source AI agent framework I put through its paces recently. The router's job is deciding whether a given request stays local or gets sent out to a cloud-hosted, state-of-the-art model, delegating to bigger, pricier resources only when a task truly calls for it. aiDAPTIV's role in that picture is indirect but meaningful: the more capable the model you can run locally, the more work a router like that can justify keeping on-device. It's a side quest rather than the main story here, but it's a decent preview of how these pieces might fit together.

Mixture-of-Experts & The Memory Math

Why Gemma 4 Fits the Demo

The local model in Phison's demonstrations was Google's Gemma 4 26B A4B, and it's worth sitting with why that specific model is such a fitting pick. The first reason is capability: Gemma 4 is built for exactly the kind of agentic work I mentioned earlier, with reasoning and planning through multi-step tasks, coding, tool and function calling, and multimodal understanding across text and images. It's the sort of model a local agent app actually needs if it's going to do more than chat. The second reason is the math behind its design, which is a neat piece of engineering. It's a Mixture-of-Experts (MoE) model, meaning it carries 26 billion total parameters but only activates a fraction of them, around 4 billion, for any given token, which keeps its compute demands down. Under the hood, a small router network looks at each token and picks 8 of 128 available experts to do the work, alongside one always-on shared expert that contributes to each token. The A4B label refers to the model's approximate active parameter count per token.

5

Here's the catch that actually explains Phison's benchmark number: Mixture-of-Experts may require less compute per token, but they do not normally require less memory. In a conventional setup, all 128 experts, the full 26 billion parameters, are loaded into memory and kept accessible regardless of which ones get picked for a given token, so the model's memory footprint looks a lot more like a dense 26B model than a 4B one. At 4-bit quantization, the weights alone for Gemma 4 26B A4B come in right around 15GB. On a 16GB system, that's essentially the entire budget spent before you've accounted for any KV cache or the operating system itself, which is exactly why the 'would normally need 32GB' framing in Phison's announcement checks out.

aiDAPTIV changes that equation by spreading the model's expert pool across two memory tiers: system DRAM, the active memory shared by the CPU and integrated GPU, and dedicated aiDAPTIV Cache Memory, a high-endurance flash tier. It keeps the experts most likely to be selected in system DRAM while retaining less-active experts in aiDAPTIV Cache Memory. When the router calls for an expert that is not already in DRAM, aiDAPTIV recalls it from Cache Memory and moves less-active data out as needed. That can add latency when the active expert set changes, but it allows a system with limited DRAM to run an MoE model whose full expert pool would not otherwise fit.

To be clear about what that result means: the point isn't that 16GB suddenly performs identically to 32GB in every situation. It's that aiDAPTIV can make a larger, more capable model viable on a machine whose DRAM alone would simply be insufficient to run it, and that's the more interesting claim anyway. It's also a fitting model to demo for another reason: Gemma 4 is the first Gemma generation Google released under a standard Apache 2.0 license, rather than the more restrictive custom terms earlier versions shipped under, which makes it an easy, unencumbered pick for the type of business and consumer systems that aiDAPTIV is built into.

The Memory Crunch & Final Thoughts

The Memory Shortage Backdrop

None of this is happening in a vacuum, either. This announcement arrives during a period of sustained pressure across both DRAM and NAND markets. DRAM contract prices rose significantly quarter-over-quarter in the first quarter of this year, with another projected increase for the second, while NAND flash pricing has also been moving higher.

5

AI infrastructure demand is tightening both sides of the memory market, though in different ways. DRAM makers are prioritizing high-bandwidth memory and high-density server DRAM for AI data centers, while NAND suppliers are seeing sustained demand for enterprise SSDs. Phison CEO K.S. Pua has described the NAND situation bluntly, saying that every NAND manufacturer had told him its 2026 capacity was already sold out. The result is continued pressure on supply and pricing across both DRAM and NAND, with little near-term relief expected.

To be clear, the takeaway isn't that NAND is cheap or unconstrained while DRAM struggles; both memory markets are under real pressure right now. The practical point is that DRAM is the pricier of the two per gigabyte, and relying on ever-larger DRAM configurations alone is an expensive way to chase larger local AI workloads. What aiDAPTIV gives OEMs is another lever to pull: pair a more modest DRAM configuration with purpose-built Cache Memory and intelligent middleware, and you end up with a more efficient, AI-centric memory mix for bigger models, longer context, and agentic workloads. That's not free memory, and it's not a universal lower-cost claim, but it is a genuinely different way to spend a memory budget, and right now, that flexibility matters.

Final Thoughts

It would be remiss not to keep the practical realities in view. What Phison and Intel showed at Computex is a technical demonstration of a collaboration still progressing toward broader product availability, and real-world results will naturally vary by model, system configuration, workload, and software environment. The 16GB-versus-32GB result comes from Phison's own testing, so it is best viewed as a proof of the capability aiDAPTIV is designed to unlock rather than a universal performance guarantee.

5

DRAM remains the fastest tier of system memory, while aiDAPTIV's role is to intelligently extend effective AI working memory by managing eligible data across DRAM and purpose-built, high-endurance Cache Memory. A key measure as this technology reaches more systems will be how effectively that middleware maintains responsiveness across longer contexts, larger models, and increasingly complex agentic workloads. Based on the Computex demonstration, it is a promising approach to making more capable local AI practical on systems where installed DRAM alone would otherwise be a limiting factor.

Still, I've spent enough time watching a promising local model choke because it was a few gigabytes short of fitting on whatever hardware I happened to be testing that I can't help but be interested in where this goes. The through line is simple: more useful local AI needs more capable models, and more capable models, longer context, and agentic workflows all need more memory. Between tools like OpenClaw pushing more people toward wanting a real, always-on local AI agent, and a memory market that isn't loosening up any time soon, a technology that meaningfully raises the ceiling on what local hardware can run feels less like a nice-to-have and more like the direction this has to head. I'll be eagerly awaiting more details and purchase info as this moves past the show floor and into the next generation of computers.