Qwen3.8-27B on an RTX 3090: results, metrics and limits

We ran Qwen3.8-27B on a home PC with one NVIDIA GeForce RTX 3090 and 24 GB of VRAM. In the main run, Qwen Code repaired two Go paths that ignored json.Marshal errors. The request required preserving successful responses, adding safe behaviour for serialization failure, writing regression tests, updating documentation and keeping the diff within scope.

The run took 502.14 seconds, made 52 tool calls, generated 28,916 tokens, used about 33.88 Wh and peaked at 22,539 MiB of VRAM. After Qwen Code finished, Codex scored the patch 100/100 under the Syntalith rubric. Codex assigned the score; an independent auditor or laboratory did not.

This is one configuration and one run. The server handled one active model request at a time. Download the data: run summary, Go-task metrics and long-context test.

Hardware and serving profile

This describes the complete profile. We also retained an llama.cpp fallback with Unsloth Dynamic V3 Q4_K_M GGUF weights and a 120k limit. The profiles changed weights, cache, server, decoding and context limit together, so timing differences cannot be attributed to one engine or quantisation alone.

Long-context retrieval

The test placed one exact fact near the beginning, one in the middle and one at the end of a synthetic record. The model had to return all three as JSON. Every run returned 3 of 3 checked values.

Prefill is the rate at which the server processes the input before generation. Generation speed measures newly produced answer tokens. Wall time covers the complete run, including input processing. This test checks retrieval of three planted facts. It does not measure comprehension of the whole document or repeatability.

The Go repair and its 100/100 score

The rubric assigned 40 points to error handling, 20 to regression tests, 15 to API compatibility, 10 to scope, 10 to verification and 5 to documentation. Two rerun test suites, go build ./... and a diff-format check passed.

100/100 means that Codex found no deduction against those criteria in this run. It is not a probability of success and does not cover every Go project. For comparison, the same local model with the 120k llama.cpp profile took 1,468.76 seconds, used an estimated 100.36 Wh and received 98/100. That compares complete serving profiles.

Everyday task log

Public tests are visible to the agent. Hidden checks cover conditions that the prompt or visible suite may leave implicit. The import result shows why a green public suite is insufficient for accepting a process.

ATS frontend: failure followed by repair

A one-sentence request from an empty directory produced an ATS panel in 26 minutes 3 seconds. The first version looked ambitious, yet its table virtualisation rendered 8,652 rows, 251,327 DOM elements and a 485,065-pixel document. The run stopped before complete browser QA because the client's heuristic classified progress as a loop.

The main repair took 14 minutes 24 seconds. Visual review and follow-up fixes took another 7 minutes 58 seconds. An independent desktop check measured 722 DOM nodes, 15 visible rows, a 900-pixel document and no horizontal overflow. Mobile had 577 nodes and 10 rows. Screenshot review still found a name/company collision and a clipped stage marker, so the next turn fixed two CSS rules.

Total model time to the accepted variant was 48:25. This is a synthetic test interface rather than a client product.

Same model, different driver programs

We ran Qwen Code, the Codex harness and an experimental Claude Code path around the same local Qwen. Codex as evaluator awarded 100/100, 87/100 and 98/100 respectively. Local Qwen3.8-27B generated the code in every case. The client, repository workflow and context handling changed.

An evaluator is a program or model that applies explicit criteria to the resulting work. Here, Codex checked code, tests, build, scope and documentation. These scores do not compare Qwen with hosted OpenAI or Anthropic models. The Claude Code path used a compatible interface; Anthropic does not support routing Claude Code to non-Claude models.

What this says about deployment

One RTX 3090 may be enough for a pilot, one engineer or a sequential queue. A profile handling one active model request at a time cannot support a claim about simultaneous service for a team. Before deployment, measure peak demand, input and output lengths, queue time, human correction effort and behaviour after restarts or model updates.

The most useful test record contains the request, expected output, hidden checks, model version, serving profile and scoring method. Then compare the local model with a smaller model or an API.

Measurement limits

• Each configuration ran once.
• The long-context check covered three planted facts.
• The experiment used one GPU and handled one active model request at a time.
• The vLLM stack was third-party patched and frozen.
• Codex assigned the 100/100, 98/100 and 87/100 scores under the Syntalith rubric.
• The vLLM and llama.cpp comparison changed weights, cache, engine and limits together.

The experiment summary contains the full data. A free process scan can help define equivalent cases and a quality threshold for your repository.