I have been running the slightly larger 31B model for local coding:
ollama launch claude --model qwen3.6:35b-a3b-nvfp4
This has been optimized for Apple Silicon and runs well on a 32G ram system. Local models are getting better!
Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
151–160 of 482 posts
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#152Generate an SVG of a pelican riding a bicycle: https://codepen.io/chdskndyq11546/pen/yyaWGJx Generate an SVG of a dragon eating a hotdog while driving a car: https://codepen.io/chdskndyq11546/pen/xbENmgK Far from perfect, but it really shows how powerful these models can get
The dragon image has issues like one eye, weird tail etc, but the pelican is imo perfect -- the best I've seen!
Yeah the dragon one is just a complete mess. The car is sideways but the WHEEL is oriented in a first-person perspective.
Seems like a case of overfitting with regard to the thousands of pelican bike SVG samples on the internet already.
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#153The pelican is excellent for a 16.8GB quantized local model: https://simonwillison.net/2026/Apr/22/qwen36-27b/ I ran it on an M5 Pro with 128GB of RAM, but it only needs ~20GB of that. I expect it will run OK on a 32GB machine. Performance numbers: Reading: 20 tokens, 0.4s, 54.32 tokens/s Generation: 4,444 tokens, 2min 53s, 25.57 tokens/s I like it better than the pelican I got from Opus 4.7 the other day: https://si…
I feel like this time it is indeed in the training set, because it is too good to be true. Can you run your other tests and see the difference?
if they cook these in, i wonder what else was cooked in there to make it look good.
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#154Earlier quoted context omitted.
every model release Simon comes with his Pelican and then this comment follows. Can we stop both? its so boring
I really appreciate you speaking up. Happened yesterday on GPT Image 2, bit my tongue b/c people would see it as fun policing, and same thing today. And it happens on every. single. LLM. release. thread. It's disruptive to the commons, doesn't add anything to knowledge of a model at this point, and it's way out of hand when people are not only engaging with the original and creating screenfuls to wade through before…
No more disruptive than this comment. If you don't like it, downvote and move on. It's on topic and doesn't contradict the rules. The reason you see Simon's comment on the top is because people like it and upvote it.
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#155Earlier quoted context omitted.
You can collapse the pelican thread with the little [-] toggle at the top.
Why would you though? And by the way: Thanks for relentlessly holding new models’ feet to the pelican SVG fire.
Because I want to read about Qwen, not someone's one-off vibe test followed by 1:1 conversations. (case in miniature here: which is the last comment in this thread that says something about Qwen? The root post. Is that fun policing? Yes, apologies.)
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#156Are there any "optimized" models, that have lesser hardware requirements and are specialised in single programming language, e.g. C# ?
LLMs need diverse and extensive training data to be good at a specific thing. We don't (yet?) know how to train a small model that is really good at one programming language. Just big models that are good at a variety of languages (plus lots of other things).
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#157I wish that all announcements of models would show what (consumer) hardware you can run this on today, costs and tok/s.
this is what the unsloth post is for
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#158Earlier quoted context omitted.
I really appreciate you speaking up. Happened yesterday on GPT Image 2, bit my tongue b/c people would see it as fun policing, and same thing today. And it happens on every. single. LLM. release. thread. It's disruptive to the commons, doesn't add anything to knowledge of a model at this point, and it's way out of hand when people are not only engaging with the original and creating screenfuls to wade through before…
No more disruptive than this comment. If you don't like it, downvote and move on. It's on topic and doesn't contradict the rules. The reason you see Simon's comment on the top is because people like it and upvote it.
Our comments are no more disruptive, so we shouldn't write them.
The other comments are at most as disruptive & fine.
Something seems off when I combine those premises.
You also make a key observation here: the root comment is fine and on-topic. The the replies spin off into nothing to do with the headline, but the example in the comment. Makes it really hard to critique with coming across as fun police.
Also, worth noting there's a distinction here, we're not in simonw's thread: we're in a brand new account's imitation of it.
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#159Earlier quoted context omitted.
The 27B model they release directly would require significant hardware to run natively at 16-bit: A Mac or Strix Halo 128GB system, multiple high memory consumer GPUs, or an RTX 6000 workstation card. This is why they don’t advertise which consumer hardware it can run on: Their direct release that delivers these results cannot fit on your average consumer system. Most consumers don’t run the model they release direct…
You absolutely do not need to run at full BF16. The quality loss between BF16 (55.65 GB in GGUF) and Q8_0 (30.44 GB in GGUF) is essentially zero - think on the order of magnitude of +0.01-0.03 perplexity, or ~0.1-0.3% relative PPL increase. The quality loss between BF16 and Q4_K_M (18.66 GB in GGUF) is close to imperceptible, with perplexity changes in the +0.1-0.3 ballpark, or ~1-3% relative PPL increase. This would…
tbh ~1-3% PPL hit from Q4_K_M stopped being the bottleneck a while ago. the bottleneck is the 48 hours of guessing llama.cpp flags and chat template bugs before the ecosystem catches up. you are doing unpaid QA.
Re: Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model
#160Earlier quoted context omitted.
When you say tok/s here are you describing the prefill (prompt eval) token/s or the output generation tok/s? (Btw I believe the "--jinja" flag is by default true since sometime late 2025, so not needed anymore)
If someone doesn't specifically say prefill then they always mean decode speed. I have never seen an exception. Most people just ignore prefill.
But isn't the prefill speed the bottleneck in some systems* ?
Sure it's order of magnitude faster (10x on Apple Metal?) but there's also order of magnitude more tokens to process, especially for tasks involving summarization of some sort.
But point taken that the parent numbers are probably decode
* Specifically, Mac metal, which is what parent numbers are about