u/the_616

• Role: Primary local AI inference server
• CPU: Intel Core i7-12700 (12 cores / 20 threads)
• Memory: 64 GB RAM
• Primary GPU: AMD Radeon AI PRO R9700 (32 GB VRAM) for large-model inference
• Secondary GPU: RTX 3060 Ti (8 GB) for lighter CUDA work and fallback tasks
• Storage: 2 TB NVMe SSDs for models, caches, and the working environment; 4 TB HDD for datasets and archives

Fun value unlimited *

I have been testing local coding models on an AMD Radeon AI PRO R9700 with 32 GB VRAM. Instead of comparing only tokens per second or asking the models to generate isolated functions, I ran two of my daily Pi coding profiles through the same repository-level workflows.

The short version: Qwen3.8 caught every requirement, while my Qwen3.6 "precise" profile finished 3.12x faster but missed one CLI requirement that was not covered by the visible tests.

Models and profiles

Qwen3.8 profile

• Unsloth Qwen3.8 27B UD-Q6_K_XL GGUF
• 65,536-token Pi context
• 2,048-token maximum response
• Native Qwen3.8 developer/tool template
• Low reasoning effort with a 1,024-token server reasoning budget
• Temperature 1.0, top-p 0.95, top-k 20, min-p 0
• Embedded MTP enabled with two draft tokens
• Q8 target and draft KV caches
• About 28.78 GB VRAM allocated

Qwen3.6 precise profile

• Unsloth Qwen3.6 27B MTP Q6_K GGUF
• Qwen Sharp chat template
• 65,536-token logical Pi context
• Temperature 0.1, top-p 0.95, top-k 40, min-p 0.05
• 128-token reasoning budget
• MTP enabled with three draft tokens

Both were served through the same llama.cpp Vulkan router with one model loaded at a time. Pi ran offline with its read, edit, write, grep, find, ls, and shell tools enabled.

What I tested

I used four fresh Git repositories created from identical broken baselines:

1. Fix a stale cache after JSON persistence.
2. Add task priorities across the model, service, JSON compatibility, CLI, and README.
3. Refactor dependency ordering to include dependency-only nodes, remain deterministic, and reject cycles.
4. Make batch persistence atomic across validation and filesystem replacement failures.

Each model received the same prompt and repository. Every workflow used a new Pi session. The agents could inspect the repository, edit files, and run the five visible unittests. I did not send any repair prompts after Pi exited.

I then ran one external grader per workflow. These checks were outside the working repositories and were never shown to the models. They covered cases such as CLI filtering, duplicate dependency edges, generator validation, injected os.replace failure, cache preservation, and temporary-file cleanup.

Results

Metric	Qwen3.8 27B	Qwen3.6 precise
Visible tests	20/20	20/20
External checks	4/4	3/4
Combined checks	24/24	23/24
Workflows completed	4/4	4/4
Total wall time	12:05.10	3:52.41
Model turns	53	39
Tool calls	78	58
Generated tokens	24,941	8,326
Non-cached input tokens	27,604	21,382
Cache-read tokens	385,983	186,383
Changed lines	182	115

Per workflow:

Workflow	Qwen3.8	Qwen3.6 precise
Cache invalidation	6/6, 1:38	6/6, 1:00
Priority feature	6/6, 3:46	5/6, 1:08
Dependency refactor	6/6, 1:41	6/6, 0:55
Atomic batch persistence	6/6, 5:00	6/6, 0:49

The server stayed healthy throughout the run: zero service restarts and no OOM, Vulkan device-loss, segmentation-fault, or fatal events.

The interesting failure

Both models passed every visible test. The difference appeared only in the external priority grader.

The prompt explicitly required --priority support on both the create and list CLI commands. Qwen3.8 implemented both. The precise profile added priority support to the data model, persistence, service filtering, and create --priority, but it forgot list --priority.

That is exactly the kind of omission that a normal green test suite can hide. Qwen3.8's extra reasoning and repository exploration were expensive, but in this run they bought a real requirement-coverage win.

Patch quality

Both models handled the cache and dependency tasks correctly. Both atomic implementations validated the full batch before mutation, preserved disk and cache state after an injected replacement failure, and cleaned temporary files. Qwen3.8 additionally flushed and called fsync before the atomic replacement.

Qwen3.8 was less economical overall. It changed 182 lines versus 115, used 36% more model turns, made 34% more tool calls, and generated almost exactly 3x as many output tokens. The priority documentation and public exports were useful, but the model's native reasoning style is undeniably verbose.

My takeaway

I am not replacing the precise profile outright.

• Qwen3.6 precise remains my choice for fast edits with a strong existing test suite. It completed this benchmark 3.12x faster and used one-third of the output tokens.
• Qwen3.8 is the better choice for underspecified, cross-layer, or agentic work where missing one requirement is more expensive than waiting longer. It was the only profile to satisfy every visible and hidden check.
• A useful two-model workflow may be Qwen3.6 precise for implementation and iteration, followed by Qwen3.8 for requirement review—or Qwen3.8 for the initial complex implementation and precise for fast follow-up fixes.

This is only four Python workflows with one stochastic run per model. It does not establish universal model rankings, and the profiles are not architecture-normalized: they use the settings I actually run in Pi. Still, I found the result more useful than another isolated HumanEval-style score because it exposed a genuine repository-level omission.

Model source:

• Qwen3.8 GGUF
• Qwen3.8 local guide

I can share the exact prompts, external grader, Pi JSON event transcripts, and patches if people are interested.

Got this baby for a local ai coding setup. It's a beast.

Local ollama setup with qwen 3.6 35b 5k runs like a charm with 128k context .

I get 69 - 71 token/ sec with rocm pipeline.

If you want something tested regarding ai performance of this card , write it down in the comments.

Got it for nearly 1400 usd in india.