My vibe-selling rig is a 13-inch tablet

I sell AI infrastructure for a living. The kind I quote arrives in racks. The kind on my desk weighs 1.2 kg, costs a fraction of a single B300, and spent the weekend running models north of 100 billion parameters at ten times my reading speed.

Everyone has been vibe-coding for some time now. Vibe-selling is the same wager applied to my job: local RAG pipelines, browser automation over CDP, vision models reading documents and screenshots, Whisper on the NPU, cron jobs running while I sleep, agents drafting on top of all of it. The difference is that the entire loop runs on hardware I own.

Why local

The material is the reason. Enterprise selling runs on architecture documents under NDA, pricing, competitive intelligence, things a customer said in a room on the understanding that they stayed in the room. None of it is mine to paste into a third-party endpoint, and it’s exactly the work worth handing to an agent. So the models come to the desk.

The kit

• ASUS ROG Flow Z13 (GZ302EA): AMD Ryzen AI Max+ 395 “Strix Halo”, 128 GB of unified memory at roughly 256 GB/s
• Arch Linux on the CachyOS kernel, with Hyprland
• Lemonade as the model server, driving llama.cpp underneath
• FastFlowLM on the NPU for the always-on tier (embeddings, Whisper v3 Turbo for speech, a small Gemma for quick looks), with the fans off. The GPU only spins up when something heavy is asked for
• Hermes Agent from Nous Research as the harness: browser, files, memory, cron, code execution, ~30 tools and 70 skills

Capacity sells, throughput delivers

Storage vendors spent twenty years teaching customers the difference between capacity and throughput, and I spent those twenty years in the room. Capacity is what you buy; throughput is what you feel. Nobody sizes an array off the brochure number.

LLM marketing has rebuilt the old confusion with new units. A parameter count is a capacity figure. What decides how a model feels is how many bytes must cross the memory bus for every token, and on a Mixture-of-Experts model the two have almost nothing to do with each other. This machine holds 122 billion parameters in RAM and streams 10 billion of them per token.

I benchmarked everything I keep on the box, on both AMD backends. The goal is picking the most efficient, balanced daily driver for this specific machine, not lab science.

Tested on: ASUS ROG Flow Z13, Ryzen AI Max+ 395, 128 GB unified @ ~256 GB/s · Arch Linux (CachyOS kernel) · llama.cpp b9747 via Lemonade (Laguna section: b10142) · 32K context · 5 runs × 2 warmups per scenario, model pinned between runs · 2026-07-25

Tokens per second of generation:

The column that matters is Vulkan long, sustained generation on the faster backend. Three things fall out of that table.

The smallest model is the slowest. The 27B runs at 22.7 tok/s while the 122B does 32.3, because the 27B is dense and reads all of itself for every token, while the 122B only touches 10B of itself. When a model name carries A3B or A10B, that’s the active count. It’s the first spec I read now, and a big dense model on a unified-memory box is a trap.

Active parameters aren’t destiny. Qwen3-Coder-Next has the fewest active parameters of the four and still loses to gpt-oss by nine tokens a second. The reason is code, not silicon: Qwen3-Next interleaves linear attention (Gated DeltaNet) with conventional layers, and those kernels are still far from optimized, while gpt-oss runs classic GQA down a well-travelled path and shipped natively in MXFP4, so llama.cpp has kernels for its exact format. Three of the four files here are community conversions; the one that isn’t (gpt-oss, published by the llama.cpp project itself) is the fastest. Two models can move the same bytes and land far apart on how well-tuned the code moving them is.

Two of the four had help. Both Qwen builds carry an MTP head, which drafts several tokens per forward pass and verifies them in a batch. A controlled study would switch that off; a daily-driver hunt runs every model the way it ships. The server logs put the mean accepted draft length at 3.05 tokens per pass on the 27B and 3.47 on the 122B. The dense 27B, with the most bandwidth pain to relieve, would be far uglier without it.

The AMD software question

Every conversation about AMD in AI lands, sooner or later, on whether the software is ready. Measured from this desk, it is, with an asterisk that moves monthly.

The reason to tolerate the asterisk is the price of admission. To run a 100B-class model at interactive speed on hardware you can buy at retail, you need either a stack of GPUs or unified memory. The GPU route means a wall of flagship cards before you’ve bought the workstation around them. Apple sells 128 GB of unified memory with roughly twice this machine’s bandwidth, at a premium. If you don’t need the tablet part, mini-PCs carry this exact chip with the same 128 GB for even less. Strix Halo is the cheapest ticket into the 100-billion-parameter club; it just rides the slowest bus of the three.

Now the asterisk, measured. To be clear, this is AMD versus AMD: the same chip, driven by its two software backends. Vulkan won sustained generation on all four models: by 10% on gpt-oss, 18% on the 122B, 19% on Coder-Next, 36% on the dense 27B. ROCm answered with a lower time-to-first-token in seven of the eight scenarios. Decode to Vulkan, prefill to ROCm, holding across two architectures.

The upstream story is the better one. In March 2026, the llama.cpp guidance for this exact chip was a ROCm/HIP build with carefully chosen flags. By July the same thread had reversed itself: Vulkan/RADV for decode, HIP for prompt processing. RADV, for the record, is the community Vulkan driver, the one the Steam Deck ships. The fastest way to run AMD’s flagship AI APU in July 2026 is, in effect, the games driver. The official compute stack wins the metric it doesn’t advertise and loses the one it does.

That’s the asterisk in motion, not a complaint. The software floor under this hardware shifts monthly, which is worth knowing before anyone extrapolates a benchmark — mine included — more than a few weeks out.

A model three days old

Poolside’s Laguna S 2.1 shipped in GGUF and I wanted it on the machine: 118B MoE with 8B active, built for agentic coding, thinks between tool calls, 262K context out of the box and a 1M ceiling on the spec sheet. The download is 68 GB. The first load attempt returned:

llama_model_load: error loading model: unknown model architecture: 'laguna'

My llama.cpp build dated from June 21. Laguna support merged upstream on July 22, and the release carrying it was cut nine minutes after the merge. I was a month and one merge behind.

The fix was pleasingly boring. Lemonade pins its backend builds in a JSON file whose own comment invites you to edit it; vulkan went from b9747 to b10142, and one install command later the loader knew the word “laguna”. ROCm was less obliging: Lemonade compiles its own ROCm binaries, and the newest one it has published predates the Laguna merge by six days. This time the asterisk moved against me.

First clean numbers on Vulkan, 32K context: 30.4 tok/s on short exchanges, 28.7 sustained.

That is slower than the 122B, on fewer active parameters. Kernels are the suspect again, as with Coder-Next. The difference is age. Laguna’s architecture is three days into llama.cpp, so it may well get faster as the code matures. Then again, Coder-Next’s hybrid attention has been in the tree for months and still trails the old GQA path.

Two footnotes for honesty. The Laguna numbers come from b10142 while the table above is b9747, so it stays out of the table. And the 1M context window is spec-sheet territory for now: the KV cache at that length would eat deep into what 128 GB leaves free after 68 GB of weights, and I haven’t measured where it breaks.

The daily driver

For now the harness runs Qwen3-Coder-Next, on three grounds: 262K of context where gpt-oss stops at 128K, and an agent fills a window fast; the second-fastest sustained generation on the box; and an aptitude for tool calling that weeks of agent work keep confirming. That last one is field experience, not measurement, and tokens per second don’t pick an agent. That benchmark is the next post.

The whole loop runs without an API bill, a data processing agreement, or a pause mid-thought to wonder whether a prompt is safe to send.

Appendix: the raw runs

Same conditions as the table. Each model appears twice: Vulkan first, then ROCm.