The question every buyer of a 128 GB mini PC eventually asks is not “how many tokens per second does it do” — it is “can my team of five share this?” Published benchmarks almost never answer it: they measure a single stream and report decode speed. This is the same box under simultaneous load, measured the way the users experience it.
What was measured
One Beelink GTR9 Pro (Ryzen AI Max+ 395, 128 GB unified) running llama.cpp server with a Vulkan build pinned by image digest, serving Qwen3.6-35B-A3B Q4_K_M pinned by artifact hash. The workload is a frozen corpus of everyday human requests — messages, emails, explanations, plans — not benchmark prompts. Reasoning is off; every request is judged by format, language and repetition gates, and failed requests stay in the denominator.
The only variable changed between the three cells is how many requests are in flight at once: one, four, eight.
The wait, measured
At a single stream the assistant answers in 210msunit_replicated. With four concurrent chats the median wait becomes 338msrepeated, and at eight it is 865msrepeated.
The shape matters more than any single figure: the first token stays sub-second across the whole ladder, but the growth is not free — going from four to eight simultaneous users costs more than going from one to four. A sizing decision made from the single-stream number alone will be wrong in the direction that hurts.
What did not break
Completion held at every step: 100.0% of requestsunit_replicated at one stream, 100.0% of requestsrepeated at four, 100.0% of requestsrepeated at eight. No request was dropped, truncated or returned empty because of the concurrency. Whatever this box does under load, it does not fail silently.
What this does NOT say
- It is not a capacity claim. “Eight concurrent requests” is not “eight employees”: real teams are bursty, idle between messages, and paste long documents. A person is not a request.
- No SLO was agreed in advance, so nothing here is an operating envelope. The honest output is the shape of the wait, not a supported-user count.
- One unit, one artifact, one runtime build, one corpus. A prefill-dominated workload (pasted documents, RAG contexts) behaves differently — that is the long-context and doc-session work, not this.
- Reasoning is off. With the reasoning block on, the wait at a single stream is already two orders of magnitude larger; see the thinking-model report.
How to use this for sizing
Decide the wait your users will tolerate for the first visible word, then read the ladder backwards. If half a second is the limit, this box serves a small team on this workload; if you need it under 250 ms, it serves one or two people at a time. Then measure your own corpus — the harness is public and the run bundles are sealed and downloadable.
Every number above has a permanent page with its scope, limitations and raw evidence: the claim registry.