A hands-on evaluation of Qwen3.6 27B argues that the dense open-weight model has reached a useful balance for local software development, although the reported setup used unusually capable consumer hardware. The Quesma blog test compared the 27-billion-parameter model with Qwen3.6’s 35B A3B mixture-of-experts variant and other locally runnable models.
The evaluator used llama.cpp and an eight-bit GGUF quantization with multi-token prediction. On a MacBook M5 Max with 128GB of unified memory, the model generated about 30 tokens per second and drove GPU use to roughly 95%, according to the post. Both Qwen3.6 variants fit within 48GB of Apple silicon shared memory. A four-bit version was said to occupy less than 18GB, making a 32GB machine a possible target, though lower precision can trade quality for size and speed.
In qualitative trials, the 27B model produced a working hexagonal Minesweeper project from one prompt, including the requested Node package structure. The faster 35B A3B variant created a single HTML file instead and missed that packaging instruction. Another prompt produced a responsive landing page. These examples demonstrate capability on specific tasks, not a controlled measure of general coding quality.
The author preferred the slower dense model because its outputs appeared better in manual review. The mixture-of-experts model ran about three times faster in the reported comparison. That tradeoff matters for interactive development: generation speed can determine whether a tool feels usable, but adherence to requirements determines how much correction follows.
The post also described options for different hardware. Aggressive quantization may let the model run on consumer Nvidia cards; a cited user report claimed 50 tokens per second on an RTX 5090 using a six-bit model and a 123,000-token context while consuming about 28GB of 32GB VRAM. That figure is a third-party result included in the blog, not an independently reproduced benchmark.
Local execution offers practical privacy and availability advantages because code and prompts can remain on the user’s machine and access does not depend on a hosted service. It also shifts costs and operational work to the developer, including model downloads, memory requirements, heat and power use. Quesma’s result supports Qwen3.6 27B as a credible option for well-equipped machines, but it does not establish a universal “sweet spot” across devices, workloads or competing models. Developers considering it would also need to test their own repositories, context lengths and agent tools. A successful one-prompt demo cannot show reliability over long editing sessions, where accumulated context, build feedback and repeated tool calls may change both speed and output quality.
