Red Banana Lab · Field notes No. 1

Three Brains, One Laptop: Serving 80B to 235B Models on AMD Strix Halo

Red Banana Lab, New Delhi · 19 August 2026 · measurements from a production workload, not a synthetic benchmark suite

We run a real business workload on local models: document digestion, code review, report drafting, agent-style task planning . Our machine is a single ASUS ProArt PX13 laptop with AMD's Strix Halo APU (Ryzen AI Max), 128 GB of unified memory of which ~119 GB is addressable, and a Radeon 8060S iGPU that Vulkan reports with a 132 GB window. Everything below was measured on this box, on one day, under llama.cpp with the Vulkan backend, identical 40,960-token context, identical five-question gauntlet with planted verifiable answers.

The contenders

ModelQuantDiskArchitecture notes
Qwen3-Next-80B-A3BUnsloth UD-Q6_K_XL69 GBMoE, 3B active, GatedDeltaNet hybrid attention
gpt-oss-120bMXFP461 GBMoE, harmony format with a separate reasoning channel
Qwen3-235B-A22BUnsloth UD-Q3_K_XL98 GBMoE, 22B active

Headline numbers

Metric80B-A3Bgpt-oss-120b235B-A22B
Generation, tok/s445117
Prompt ingest at ~6.3k tokens, tok/s530644108
Time to first token, short prompt0.5 s0.8 s2.1 s
Time to first token, 6.3k prompt12.2 s9.6 s60.1 s
RAM while resident~76 GB~70 GB~90 GB
Peak thermal under sustained load74 °Csimilar
Quality gauntlet (5 planted-answer tasks)5/54/5*5/5

* The asterisk is the most interesting finding in this report.

Finding 1: the fastest model returned an empty answer

The reasoning-channel budget trap gpt-oss-120b was the fastest model in every speed metric. It was also the only one to fail a question outright: on our hardest reasoning task it consumed the entire 700-token completion budget inside its private reasoning_content channel and returned an empty content string. For an interactive chat this is a retry; for an unattended worker pipeline that parses content, it is a silent no-op that looks like success. If you orchestrate agents over harmony-format models, either grant generous budgets, cap reasoning effort, or treat empty content as a hard failure.

Finding 2: honesty survived quantisation, in all three models

By accident, one of our gauntlet questions contained inconsistent numbers (a linear system whose solution was non-integer for an integer-only quantity). All three models detected the inconsistency and said so rather than fabricating a plausible integer. We had planted facts to catch retrieval hallucination; we ended up with an unplanned honesty test, and a 3/3 pass. Worth knowing: at Q3–Q6 quantisation on consumer hardware, refusal-to-fabricate behaviour held.

Finding 3: MoE changes which speed you should care about

The 235B's 17 tok/s generation is usable. Its 108 tok/s prompt ingest is what actually throttled our workday: feeding it a 90 KB dashboard file meant a half-hour of reading before the first output token. The A3B-active 80B reads the same material five times faster. If your workload is "read a lot, write a little" (summarisation, code review, log digestion), prompt throughput dominates wall-clock and active-parameter count is the number to shop by.

Finding 4: two boot-time traps on Strix Halo + Vulkan

Silent CPU fallback A systemd user service that starts llama.cpp at login can race the graphics session. When it wins the race, llama-server comes up CPU-only with no error, at a quarter of the speed. Our fix: an ExecStartPre loop that waits for /dev/dri/renderD128 before launch. If your tokens-per-second dropped 4x after a reboot, check this before blaming the model.
GatedDeltaNet micro-batch collapse Qwen3-Next's hybrid attention has a Vulkan pathology on this hardware: micro-batch sizes (-ub) between 65 and 256 collapse performance. We run -ub 2048. The model is then fully stable on GPU.

Finding 5: 98 GB models load in 15 seconds, and that is a lie you can use

With mmap loading, "server healthy" arrives in ~15 seconds for every model, because the weights page in lazily during the first requests. First-prompt latency after a cold start is therefore the real load time. For a resident service this is a feature: restarts are cheap and the page cache does the rest.

What we deployed

The everyday seat went to the 80B, not the fastest model: 90% of gpt-oss's speed, a perfect gauntlet, and no empty-answer channel risk. We now run a three-tier auto-router: task keywords select FAST (80B, resident), DEEP (gpt-oss, deliberately large budgets), or MAX (235B, final reviews), the switch is a systemd drop-in swap that announces itself and is verified by an independent truth-checker that compares what our dashboard claims against what the inference server actually serves. That last habit, instruments that can disagree with reality, caught more defects this week than any code review.