The laptop form factor just crossed a line worth caring about. AMD's Ryzen AI Max PRO 390 in the HP ZBook Ultra G1a 14 takes a 32-billion-parameter model and runs it at a usable speed without any discrete GPU. That's the headline. The caveats are worth the rest of the column.
The architecture shift
The ZBook pairs a 12-core / 24-thread CPU with an integrated AMD Radeon 8050S and a 50 TOPS NPU, all drawing from the same 64GB pool of LPDDR5X unified memory. There's no 16GB GDDR7 VRAM brick stuck inside. One pool, three accelerators, no dedicated graphics.
What matters is what that does to model selection. The review benchmarks, run via Ollama 0.32.14 at 16K context, with the laptop plugged in, are clear:
| Model | Substantive avg (t/s) | vs. OMEN (RTX 5080) |
|---|---|---|
| Llama 3.1 8B | 37.43 | 120.16 — 3.2× slower |
| Qwen 2.5 14B | 19.95 | 66.10 — 3.3× slower |
| Qwen 2.5 32B | 8.63 | 8.19 — practical parity |
The crossover is the story. The OMEN's 16GB of GDDR7 is 3× faster for models that fit entirely inside VRAM. For a 32B model, the ZBook's large shared pool erases that advantage — the OMEN's once-dedicated VRAM becomes the bottleneck as spillover hits the bus, while the unified memory absorbs the entire working set.
The 16GB dedicated GPU memory BIOS setting is just a reservation, showing up as a separate 31.8GB "shared" pool. Change it to 32 or 48GB, and you swap GPU allocation for system-RAM headroom. That flexibility isn't free.
The NPU was the easy part
Having an NPU is not the same as using it. The review found the integrated XDNA2 NPU idling through most LLM work because Ollama runs CPU or GPU paths via ROCm/Vulkan. An unrelated background process kept showing 60% NPU utilization — a mystery never solved, and likely a lucky coincidence.
When it does run, the NPU is a distinct tool. Qwen3.6 35B-A3B FastFlowLM hit 13.63 t/s at ~96-100% NPU use with a ~5.25s TTFT. That's a subjectively different speed than the 32B via ROCm, but the two runtimes are not the same benchmark. The 35B FLM output, however, was the same story: the model got the question differently, not better. Running on the NPU proved processor attribution, not answer quality.
The biggest trade-off: software giveth, software taketh away
The 32B parity tailspin has a dark side. The current Ollama stack — 0.32.14/0.32.15 — couldn't initialize a 70B model at all. A March rollback to 0.17.7 did, at 1.90 t/s, with a 66% CPU / 34% GPU split and a system-RAM wall hitting ~99%. The Mac-silicon-style flexibility this architecture promises is gated by software. The NPU does not just work today with every model.
The hardware in practice
For practical local AI, the 64GB pool gives you mid-size models plus a running Windows environment. 32B class fits and leaves room for a browser. The RAG bundle (AnythingLLM) with a 1706-page manual had success: Qwen3.6 recognized incomplete context and returned the literal "NOT FOUND" instead of inventing an answer.
The trade-offs outside benchmarks: one USB-A port, no Ethernet, so a dock is likely. Light (1.57kg) and quiet — no jet-engine fans. An 85-minute Teams meeting dropped battery from 78% to 40%, so hold a charger for a heavy meeting day. And while the 8050S usually stays in the deck, that mid-40s to high-50s reading spiked to 92°C briefly during a 32B RAG run on a lap.
Who should buy
If your primary workflow fits in under 16GB of dedicated VRAM and you want max speed, the discrete-GPU OMEN wins clearly. If you need to step up to composed 32B-class models and want to run that alongside a browser for private document work, the ZBook's unified pool is the practical answer.
I treat the NPU as a capability, not a reason. The model and runtime both need to support it. The 14-inch chassis and the 64GB pool are the actual buying reasons — for real LLM workloads that exceed 16GB, this machine is the sweet spot. I'd not buy it solely for 8B speed; I'd buy it to keep a 32B running without a weight-some backend.