A computer with 128GB of memory sounds like it should handle local AI without much trouble. Put one on a desk, load a large language model, type your question, and wait for the reply. That’s the idea behind the growing market for mini PCs built around AMD’s Ryzen AI Max chips. They’re small enough to sit next to a monitor, yet some have more shared memory than a typical gaming desktop has RAM and VRAM combined.
Then GEEKOM published a number that makes you look at those memory specifications differently. On October 24, 2026, the company released 72 local AI benchmark records from two A9 Mega mini PCs. One run on its 128GB system took 720.61 seconds to produce the first token after receiving a 128,000-token input. That’s 12 minutes and 0.61 seconds before the model even began its answer. The model was Qwen3.8-Flash-Next, running in a large quantized configuration. This wasn’t a failed boot or a machine that had frozen. It was a completed benchmark with a very long prompt.
The odd part is that the same machine, with the same model and a short 128-token input, produced its first token in 0.97 seconds. The difference was the amount of text it had to read first. If you’re thinking of buying a high-memory mini PC to run AI privately, these two results tell you more than a glossy specification sheet ever could.
Access without medium partner: A 128GB AI Mini Hookup Explained
The 12-minute result has a lot hiding behind it
The machine in question is the GEEKOM A9 Mega 395. It uses AMD’s Ryzen AI Max+ 395 processor, with 16 CPU cores, 32 threads, integrated Radeon 8060S graphics, and 128GB of unified memory. GEEKOM lists memory bandwidth at 256GB/s. Its smaller A9 Mega 388 has a Ryzen AI Max+ 388, eight CPU cores and 64GB of unified memory, with the same listed Radeon graphics and memory bandwidth. Both were tested with Ubuntu 26.04, ROCm 10.0.0, and llama.cpp, although the exact llama.cpp builds varied among the test groups.
This wasn’t one quick demonstration selected for a launch video. GEEKOM’s October 24 benchmark publication contains 72 recorded test points across 12 model-and-deployment combinations. The company published short and long inputs, single-machine runs, some two- and three-machine arrangements, and one test that failed. Its public GitHub repository includes setup details and commands for checking the results.
For the headline test, GEEKOM loaded a 111.4GB Qwen3.8-Flash-Next model file in the UD-Q4_K_XL quantization, alongside a 2.8GB draft model used for multi-token prediction. The machine generated 32.43 tokens per second when the input was just 128 tokens. At 128K input tokens, its generation rate dropped to 15.45 tokens per second. Neither figure sounds like a twelve-minute wait until you notice the other measurement: time to first token, often shortened to TTFT.
TTFT is the gap between submitting a request and receiving the beginning of the answer. It’s different from the speed at which words appear once the answer starts. That distinction matters more than most local AI buying guides admit. A model can produce an acceptable 15 tokens per second after its first token and still feel unusable if it has to spend 720 seconds reading everything you sent.
A 128,000-token input is huge. It’s closer to supplying a large collection of documents or a very long history of code and logs than asking a chatbot what to cook for dinner. Most local AI users won’t send that much text in every request. But developers are increasingly sold on long-context models for searching repositories, processing reports, and maintaining lengthy agent sessions. That’s why this is a useful test rather than a silly worst-case number somebody invented to make a machine look bad.
Why the first token can take longer than the entire answer
An AI model handles a prompt in two broad phases. First comes prefill, when it processes the input tokens and builds the internal information it needs to respond. Then comes decode, when it generates the answer token by token. The second phase gets most of the attention because it’s easy to film a terminal producing text and show a tokens-per-second counter in the corner.
Prefill is less photogenic. The screen sits there, sometimes with nothing moving, until the first word appears. And processing a 128K-token prompt involves far more work than processing 128 tokens. How much extra work depends on the model design, the attention method, memory use, the runtime, and the hardware. Doubling the number of input tokens does not guarantee a neatly doubled wait. The performance curve can get messy when memory pressure and other overhead enter the picture.
So when a computer advertises support for a 256K context window, you need to ask what that promise means. Usually it means the software can accept a sequence up to that size under the stated conditions. It doesn’t promise that every request using all that context will feel like a normal conversation. A model may technically accept an entire book and then spend an uncomfortable amount of time processing it.
There is a second issue. As a conversation grows, the runtime must keep track of information from earlier tokens. Depending on the architecture, that can involve a growing KV cache, which needs memory and adds work. Qwen3.8-Flash-Next uses a more specialized mixture-of-experts and hybrid-attention design, so its exact costs aren’t the same as those of a conventional dense transformer. NVIDIA’s technical model coverage describes a 125-billion-parameter backbone, a separate 51.2-billion-parameter Engram table, and other features that make a simple parameter count a poor guide to performance.
And then there’s bandwidth. The A9 Mega’s quoted 256GB/s of memory bandwidth is a lot for such a compact system, but a large AI model keeps asking the computer to move and process substantial amounts of data. Bandwidth isn’t the only limit, and the benchmark doesn’t prove which part caused each second of delay. It does show why putting an enormous model into shared memory doesn’t automatically turn a compact PC into a responsive long-context server.
The draft model adds another wrinkle. GEEKOM used multi-token prediction, or MTP, for this Qwen configuration. A smaller helper predicts possible future tokens and the main model checks them, which can improve text generation speed when the setup works well. It isn’t a magic button that eliminates the cost of reading a huge prompt first. The same benchmark can therefore look quite good in a short generation-speed screenshot and quite bad in a long-context TTFT chart.
The 128GB memory claim needs a footnote
There’s a detail in GEEKOM’s report that I think deserves more attention than the product’s TOPS figure. The Qwen model file alone was 111.4GB, and the draft file added 2.8GB. You might assume the entire job was contained inside the advertised 128GB of physical unified memory. GEEKOM’s own limitation notes say otherwise.
The reported combined memory footprint for the single-device Qwen3.8-Flash-Next run reached approximately 131.78GB to 135.06GB when memory reported on the graphics side and the offloaded portion were counted together. Part of the model’s data, including its N-gram embedding component, was offloaded into system memory that could use virtual-memory swap pages. That means this is evidence that the model ran with offloading, not proof that all of it sat comfortably inside 128GB of physical RAM.
Those are very different experiences. Swap can allow software to keep going when its memory needs go past the comfortable physical limit, but getting data from storage is much slower than keeping it in fast memory. The benchmark does not isolate swap overhead as the cause of the 720.61-second wait, so blaming the whole delay on swap would be guesswork. Still, the memory note changes how you should read the result. The model was pushing the machine close to, and in reported combined usage beyond, its physical capacity.
That’s the part I find frustrating with local AI specifications. A model page may show a file size of 111GB. A PC page may show 128GB of RAM. It looks like a clear match until you add the draft model, runtime buffers, context storage, operating system, and other overhead. Suddenly the arithmetic isn’t so comfortable. The difference between ‘can load’ and ‘runs well’ is where a buyer can lose a lot of money.
This doesn’t make unified memory a bad design. It’s the reason these mini PCs can attempt workloads that would never fit into the dedicated VRAM of an ordinary consumer graphics card. But the amount of usable memory is smaller than the number on the box, and the cost of approaching the limit needs to be measured rather than assumed away.
The smaller mini PC produced some of the better results
The most useful counterexample in GEEKOM’s data came from its 64GB machine, not the flagship 128GB model. A Qwen3.6–35B-A3B model in UD-Q4_K_M quantization used a 22.7GB file and reached 68.03 generated tokens per second with a 128-token input. Even at a 256K-token input, the recorded generation rate was 21.66 tokens per second, with a TTFT of 645.04 seconds.
That 256K wait is still roughly ten minutes and forty-five seconds, so I wouldn’t call the very long input interactive. But the short-prompt result is instructive. A smaller mixture-of-experts model that fits with plenty of memory to spare can make a much cheaper configuration feel more responsive for everyday requests. Its file isn’t battling for almost every available gigabyte.
The same 64GB mini PC produced 103.10 tokens per second on MiniCPM5–2B with a 128-token input. The model file was just 1.56GB, and the 128K-input generation rate was 29.03 tokens per second. That’s the fastest short-input generation figure in this set. Of course, a 2B model isn’t a drop-in replacement for a much larger model on every reasoning or coding task. GEEKOM’s benchmarks measure runtime performance, not whether the answers are equally good.
This is why I’d be careful with headlines that say a 35B model is faster than a 125B model, so you should always buy the smaller one. Model architecture, quantization, active parameters, runtime choices, and task quality all differ. What the results support is simpler: a machine with less RAM can give a better response-time experience when it’s matched with a model that fits its resources and the job you want done.
For a local document-search assistant or a coding helper that mostly sees a few thousand tokens per request, a quick first answer often matters more than the ability to accept an enormous context window. Keeping a giant model available just because your PC can start it may be the expensive way to solve a modest problem.
Buying a second mini PC doesn’t automatically fix the wait
GEEKOM also tested what it calls cascades: two or three A9 Mega computers cooperating on one model. The attraction is easy to understand. If a 64GB machine cannot hold a 111.4GB model file, perhaps two machines can share the load. The test results show that this approach can make a model runnable by distributing its memory requirements.
They don’t show that adding boxes is an easy shortcut to faster single-user text generation. For Qwen3.8-Flash-Next, two 64GB A9 Mega 388 units produced 30.76 tokens per second at a 128-token input. Three units produced 28.00. Those results are from different runs, and the report warns against treating every row as a controlled comparison. But neither number suggests a clean speed multiplier as more computers join the setup.
The clearer example is DeepSeek-V4-Flash on the 128GB A9 Mega 395. With a short 128-token input, one machine generated 14.71 tokens per second. Two machines generated 14.21. Three generated 13.40. At the longest 256K input, the three recorded decode rates were almost identical: 7.16, 7.21, and 7.06 tokens per second.
What improved was the memory distribution. The single-node DeepSeek run reported about 112.96GB of memory usage at the short input length. Across two machines, the memory load was split into approximately 60.72GB and 56.98GB. Across three, it was divided into smaller portions. This can be a sensible way to run something you couldn’t otherwise fit. It adds more hardware to buy, connect, cool, and maintain, though, and there is communication overhead between nodes.
The long-context results also show how extreme these workloads become. GEEKOM recorded 7,237.55 seconds before the first token for the single-machine DeepSeek-V4-Flash run at 256K input. That’s just over two hours. The dual-node TTFT was lower at 4,940.52 seconds, but still more than 82 minutes. Those numbers shouldn’t be used as universal DeepSeek performance claims. They describe this particular quantization and software setup under an exceptionally large input.
One test failed, and that’s useful information too
GEEKOM also reported a failed 256K-input test for Gemma-4–31B on the 64GB A9 Mega 388. The failed point has no usable performance measurement, rather than a zero inserted into the results. At 128K input, the same model’s TTFT was 10,312.51 seconds, which is nearly two hours and fifty-two minutes. Its 128-token generation rate was 11.28 tokens per second, and at 128K input it was down to 5.0.
It’s a rough result. I wouldn’t conclude from this one test that Gemma is broken or that the A9 Mega can’t be used with it. GEEKOM used the q4_0 quantization and ran it without speculative decoding. Other runtime builds, cache settings, model formats, and prompt patterns could behave differently. The published failure is valuable because it tells prospective buyers what happened under at least one configuration instead of leaving a blank space that looks suspiciously like a missing chart.
There are wider gaps in the study as well. Not every model was tested at every context length. Some two- and three-node runs stop at 128K, and MiniCPM5–2B wasn’t tested at 256K. GEEKOM also states that its BIOS version, NPU driver, and power profile were still to be confirmed in the source records. These details matter if you want to reproduce a long run closely enough to compare results.
And this is a manufacturer testing its own products. Credit is due for publishing slow results, command lines, and failures, but these are still company-generated numbers, not independent lab measurements repeated across several hardware samples. The benchmark dataset and source repository give other developers a way to challenge or reproduce them. More community reproductions would be useful before anyone treats these curves as settled limits of AMD’s platform.
What I would measure before buying a 128GB AI box
GEEKOM’s US product range lists A9 Mega configurations between $2,499 and $3,799 as of October 28, 2026. The price depends on the processor, memory, and storage option, so the lower figure shouldn’t be mistaken for the tested 128GB configuration. At those prices, deciding based on a maximum context number is a poor way to shop.
I’d start with the work you actually need to do. For a developer asking a local assistant to summarize a 20-page specification, a test with a few thousand tokens is more relevant than a 256K stress test. For someone planning to feed entire repositories or long transcripts into a single request, the 32K, 64K, and 128K points become far more useful. The same computer may feel fast in one situation and painfully slow in the other.
Record two numbers separately: how many seconds pass before the first token, and how many tokens per second arrive afterward. Add the total time to finish the response. Then repeat the test at different input lengths with the same model, quantization, runtime, and output target. That gives you a performance curve instead of one flattering screenshot. A 10-second TTFT and a 120-second TTFT might produce the same text-generation speed afterward, but nobody using the machine would mistake those experiences for being equal.
Check memory at the same time. A model file that is 90GB doesn’t mean the workload needs only 90GB. The context cache and other memory allocations can grow as you increase the prompt. Watch for swap usage and any part of the model that falls back to slower paths. Check whether the runtime is using the Radeon GPU as expected. And if a guide turns on speculative decoding, test the setup both with and without it, because those results aren’t automatically comparable.
Power use deserves attention too. A mini PC that runs a model continuously has a different electricity and cooling cost from one that you start for a couple of questions per day. The 72-record publication doesn’t provide a full comparison of energy per completed task across all configurations. Without that, it’s hard to make a fair cost comparison against renting a cloud GPU or using a paid AI API.
You might also discover that a smaller model with retrieval works better for your project than pasting everything into a very large context. Search the documents first, send the most relevant passages, and let the model work on a smaller prompt. This takes some application design, and the retrieval step can miss information, so it needs checking. But if reducing the prompt from 128K to a few thousand tokens avoids minutes of waiting, it’s worth testing before ordering another memory-heavy PC.
The question I’d ask before spending the money
This is a strange moment for personal AI hardware. The A9 Mega can run a model file weighing more than 100GB on a compact computer, something that was awkward and expensive only a short time ago. That is a real capability. GEEKOM’s own tests also show how easily that capability can turn into a frustrating wait when you push the model and context toward their limits.
The 720.61-second result isn’t proof that local AI mini PCs are useless. In the same dataset, a short prompt gets a first token in under a second, and smaller models can generate text at dozens of tokens per second. A machine can perform well at one job and badly at another. The mistake is buying it for a headline memory number without checking the workload behind that number.
If I’m choosing a local AI computer in 2026, I want to know how it behaves at the context length I’ll use on an ordinary Tuesday, not only the longest prompt it can technically accept. Show me the first-token delay, whether the model spills into swap, and what happens on the second or third request. A spec sheet that says 128GB is useful. A benchmark that says twelve minutes tells me what to investigate before handing over my money.