W11 local inference benchmark: five models on a 16 GB Radeon

8 November 2026

Standfirst | Measured: Five models ran on the W11 workstation. Three passed all eight checked tasks. Nemotron recorded the fastest generation, while longer prompts exposed substantial differences in processing time. These results cover one machine and one quantisation per model, not general model capability.

Scope and limitations

Measured | Test design: This benchmark used eight tasks with deterministic pass-or-fail checks. That is a small sample. It was not a human-labelled evaluation. The checks covered specific correctness and output requirements, not a broad assessment of writing, judgement or usefulness.

Measured | Test environment: All results came from one workstation, one runtime version and one quantisation per model. The quantisations were not uniform. These results do not establish how the models perform on other hardware or with other configurations.

Judgement: The results support choosing candidates for further testing on this workstation. They do not establish general model superiority. The three models scoring eight out of eight cannot be separated on these checks alone.

Machine and method

Measured | Source: generated results and producing-session method record.

Measured: Models were unloaded and the graphics card confirmed idle before each measurement block. The record contains five short-prompt throughput results, 15 context runs, 25 latency requests, five multi-turn tool flows and 40 quality-task results.

Measured: Latency tests used repeated streaming requests at temperature zero. Each model received five requests. The first followed an explicit unload; the remaining four supplied the warm latency figures. With four warm repeats, the median is the mean of the two middle values after sorting. Time to first token counted the first non-empty output on either the reasoning channel or the answer channel.

Judgement: That timing definition matters. A first reasoning token is evidence that generation has started, not that the reader has received an answer. Four warm requests per model also provide little evidence about sustained tail latency.

Model sizes and quantisation

Measured | Source: owner-supplied frozen-bundle inventory. Four models used Q4_K_M. Bonsai used Q2_0.

Judgement: Bonsai’s eight-of-eight quality result is therefore not a like-for-like quantisation comparison with the other four models. The table compares the configurations tested, not models held at equal weight precision.

Judgement: Bonsai’s speed figures are a baseline for further testing, not a demonstrated ceiling for a model of this size. Calling them a proven floor would also go beyond the records: no alternative Bonsai quantisation or configuration was timed here.

Short-prompt speed and checked task results

Measured | Source: generated capability, throughput and quality tables. Generation is output speed. Prefill is prompt-processing speed. Memory figures below belong to the short-prompt measurement.

Measured: All five passed the short tool-call, JSON-validity and arithmetic probes. All five also completed the tested two-turn tool exchange: call once, receive the tool result and answer from it without calling again.

Measured: The eight quality tasks covered invoice extraction, ticket classification, rate arithmetic, instruction constraints, summary fidelity, code correctness, table reasoning and recognising missing information. Ornith failed classification and instruction constraints. Qwen failed rate arithmetic, code correctness and table reasoning.

Measured | Stored-answer limitation: The record caps stored answers at 400 characters. Five of the forty reach that cap and are truncated: Ornith’s answers to invoice extraction, ticket classification, instruction constraint, summary fidelity and code correctness. The remaining thirty-five are shorter than the cap and can be inspected in full. The harness script in the package shows that it checks the full response for pass or fail before storing the first 400 characters of that same text. The verdicts for those five truncated answers cannot be independently re-derived from the record because the deciding content may sit beyond the cut. This is a limit of the record, not evidence that the model ended its responses there or that the checks were wrong. The re-scoring described in the corrections section refers to the overtime checker and was applied to stored answers. All five table-reasoning answers involved were shorter than the cap, so none was truncated and that re-score is unaffected.

Measured | Producing-session inspection: Ornith supplied an explanation where only a label was allowed and used numbering where numbering was forbidden. Qwen’s code answer failed on plain integers.

Judgement: Passing a simple capability probe did not guarantee passing the more specific task checks. Output-format failures deserve attention where software consumes the answer, but these few tasks do not measure their frequency in normal use.

Cold starts and warm responses

Measured | Source: generated latency table. Warm figures exclude the first request after unloading. TTFT means time to first token on either output channel.

Measured: Nemotron also recorded the highest median generation rate in the warm latency test, at 99.5 tokens/s. That is a separate measurement from its 90.1 tokens/s short-prompt result.

Judgement: Keeping the selected model loaded is worth testing for an interactive provider. Cold first-token times were much longer than warm ones. These measurements do not establish the memory, power or availability consequences of keeping it resident. The reported p95 values come from only four warm requests per model and should not be treated as dependable estimates of tail latency.

Longer prompts changed the comparison

Measured: The context tests allocated 8,192, 16,384 and 32,768 tokens. Actual prompts occupied about 5,700, 11,500 and 22,900 tokens respectively. Allocating a context is not the same as filling it.

Measured | Source: generated context table.

Measured: Every model remained fully resident on the graphics card at the 32,768-token allocation. Nemotron’s reported footprint in these context tests was 5.76 GiB, rather than the 0.97 GiB recorded in its short-prompt test.

Judgement: Fitting in memory was not enough to ensure a short wait. Qwen remained resident but had the lowest prompt-processing rate at every tested context size. The wall-time column reports whole-run time, not isolated prefill duration.

Why a reasoning model can return an empty answer

Measured | Producing-session correction record: On the coding task, MiMo exhausted a 700-token budget on reasoning without returning an answer. A 1,500-token budget also produced no answer. A direct probe recorded 2,204 tokens on that task before a correct answer was obtained. The final quality run allowed all five models 2,500 tokens.

Measured: Across the eight final tasks, mean reasoning output was 1,584 characters for MiMo, 832 for Nemotron and 642 for Bonsai. Ornith and Qwen recorded none. All five returned answers on all eight final tasks.

Judgement: Reasoning can consume the output budget before an answer appears. A small limit can therefore produce an empty answer even when the model is generating. When testing locally, inspect the reasoning field and finish reason before diagnosing a model failure. Allow enough budget to test answer completion, then measure the resulting wait.

Corrections made during the benchmark

Measured | Producing-session method record: The session documented five corrections:

• Cold requests were removed from warm latency summaries.
• First-token timing was changed to inspect reasoning as well as answer output.
• An overtime checker that rejected a correct answer containing intermediate working was fixed, then stored answers were re-scored.
• The final quality budget was raised to 2,500 tokens for every model.
• The summariser was corrected to read the actual record keys for tools, JSON and arithmetic.

Measured | Provenance limitation: The generated results describe checkers defined before the first run. The producing-session record documents a later checker correction. The final scores are results after documented corrections, not an entirely unchanged evaluation.

Evidence and reproducibility

Measured | Source: public-package figures and inventory supplied by the owner. The public evidence package contains the run records, scripts, per-model digests and quantisations, superseded runs with their reasons, correction history, result documents and a README. It contains no human-labelled evaluation. Three internal drafting files, listed in the package README, are excluded from the public package. They comprise an internal draft of this article and a commissioning source pack.

Measured | Package inventory: The manifest lists every file except itself. Its own hash is quoted separately above for that reason. These figures describe the public package, not the internal bundle.

Measured | Verification boundary: At the moment of writing, the download URL does not yet resolve because publication has not happened. The packaging figures were supplied by the owner; the public download, archive contents and hashes were not independently verified here. The reported benchmark results were not independently rerun for this article.

Judgement: The bundle provides the material needed to inspect the runs and their corrections. It does not turn eight checked tasks into a broad quality evaluation. Reproduction would still require checking the recorded environment, request settings and scripts, then running them again.

Candidate for further testing, not a production release

Judgement: Nemotron is the first candidate I would test against this workstation’s intended workload. It combined eight passed checks, the highest measured generation rates, the shortest median warm total response and the highest prefill rate at the largest tested prompt. That recommendation remains specific to this configuration and these tasks.

Measured: Qwen had the lowest checked-task score and the largest short-prompt memory footprint. It was not slowest on every measure: Bonsai generated more slowly, and Qwen had the lowest median warm first-token time.

Judgement: The evidence warrants reviewing Qwen as the installed default. It does not justify describing it as worst on every axis.

Measured | Producing-session operational findings, retained as open work by the owner: Two provider gaps remained:

1. No server autostart. The producing session reported that Ollama ran from a held session, with no service, scheduled task or startup entry, and that endpoint availability depended on that session: the endpoint disappears when the session ends. This was the session’s account of the dependency, not a directly observed shutdown.
2. No endpoint authentication. The session reported a firewall rule allowing any address on any profile, with the wired interface categorised Public.

Judgement: These are availability and access-control gaps, separate from model selection. The benchmark does not establish a dependable endpoint. Treat it as a test deployment until both gaps are addressed and verified.