Measured on this box · not vendor claims

How it works

Why a model this size runs at all on an integrated GPU, what the binding constraint actually is, and what the machine gives up to do it.

The hardware

The same for every model on this box, and the reason any of the rest follows.

Radeon 890Mno discrete GPU.
64GB DDR5both channels full. More RAM would buy nothing.
60–70GB/sthe bus, in practice. This is the ceiling.

Why a 21B model fits at all

Measured on this box. Not vendor claims.

Generating a token means reading the active weights, and that read is the whole cost. A dense 32B reads ~19GB per token against a 60–70GB/s bus, and crawls. A mixture of experts reads only the parameters it routes to, which is why a 21B model can be quick and a smaller dense one slow.

The chain, for both models. The loaded one is highlighted.
Per token	Qwen3-30B-A3B	gpt-oss-20b
Total parameters	30B	21B
Active per token	~3B	~3.6B
Read per token	~1.5–2GB	not measured
Read per token, derived	—	at least ~1.9GB
Generation	32 tok/s	25 tok/s

The smaller model is the slower one. It activates more parameters per token, and that is the number the bus has to move — so model size is the wrong metric here and active parameters are the right one.

The derived row is arithmetic, not a reading: active parameters times bits-per-weight for the quantisation. A dash means the row above it carries a real measurement, so no estimate is needed. The method is checkable against the model that has been measured — it derives Qwen to ~1.7GB, inside the ~1.5–2GB actually observed.

Both language models, measured here

The loaded one is highlighted.
Measured here	Qwen3-30B-A3B	gpt-oss-20b
Generation	32 tok/s	25 tok/s
First word, warm	0.7s	under 1s
Cold start	79s	~27s
Cold start survives the tunnel	not always	yes
Prompt it is primed with	9,574 tokens	~9,200 tokens
Total parameters	30B	21B
Active per token	~3B	~3.6B
Quantisation	Q4	MXFP4

The smaller model is the slower one at generating, and the faster one at starting. Generation reads only the active parameters, so fewer is better; a cold start touches far more of the model at once, so a smaller total wins. Same box, opposite winners, which is why one number was never going to describe this machine.

What it does, and what that costs

Every capability here has a matching limit. They are usually the same fact seen from two sides.

Answers at conversational speed. About 25 tok/s from gpt-oss-20b MXFP4 on an iGPU, once it is warm.
It will not beat a free cloud chat. Faster, stronger models exist with no queue. Capability is not the pitch.
Starts answering almost immediately. A primed prefix puts the first word at under 1s instead of ~27s cold, on a ~9,200-token prompt.
Long-context interactive work is out. A ~16,000-token prompt takes minutes. Prefill is compute-bound, and a mixture of experts does not help it — that is a generation trick.
Serves about four people at once. Four concurrent requests is where this box still feels responsive.
It does not scale past that. Five people chatting is unusable. Ten is down. One machine, no autoscale.
Tells the truth about itself. The status line is live: primed, priming, drawing, or off. No fake “online.”
And gets out of the way when it cannot. Sites that call it fail open to a cloud model and tag the reply. Nobody waits on a cold box.

The other workload

The same integrated GPU also draws pictures. It is one machine doing one thing at a time, so a render and an answer are genuinely in competition — ask a question mid-render and the reply may come from the cloud instead.

~22stypical 1024² render, SDXL Lightning.
8 stepseuler, CFG 2.0. ComfyUI. About 1.86s/step, and you can watch them.
~7GB checkpoint~20s to load cold. Unloaded after 2 minutes idle.
One at a time10/day per IP. A render owns the GPU while it runs.