Qwen

Alibaba's Qwen family: open releases and iterations, from flagship models to small on-device ones.

205 picksRelated topicsDeepSeek Kimi / Moonshot AI Open source

Latest picks

181–200 of 205

Apr 30Thursday

r/LocalLLaMAApr 30, 03:04

Building a fully local PDF-to-audiobook workflow with Kokoro 82M, Qwen and llama.cpp

Reddit user purellmagents shared a local PDF-to-audiobook workflow using Kokoro 82M, Qwen 3.5 0.8B/2B, and llama.cpp. The Tauri 2.0 app runs on an M1 Mac, reads 15 initial sentences, then prepares the next 15. The hard parts are PDF-text alignment, code snippets, tables, and first-generation latency.

Why it matters: HKR-H/K/R all pass, but this is a Reddit personal workflow, not a model or platform release. Specific components and the 15-sentence pipeline keep it at the low featured band.

Apr 29Wednesday

r/LocalLLaMAApr 29, 16:40

Qwen3.6 27B on Dual RTX 5060 Ti 16GB with vLLM: ~60 tok/s, 204k Context Working

A user ran Qwen3.6 27B with vLLM on dual RTX 5060 Ti 16GB cards, reaching ~62–66 tok/s at 8K. The setup used 32GB VRAM, TP=2, fp8 KV cache, MTP 3 tokens, and a 204800 context window. The tight part is memory: after a 168k prefill, each GPU used ~15.65GiB with max_num_seqs=1.

Why it matters: HKR-H/K/R all pass: the post gives a concrete local-inference benchmark with hardware, vLLM settings, speed, and context limits. Single Reddit sourcing caps it below the 78–84 band.

Take

The title claims Qwen3.6 27B runs on dual RTX 5060 Ti 16GB cards: about 60 tok/s with a 204k context window. Reddit returned a 403, so I only have the title and provided summary. I do not have the original screenshot, command line, exact vLLM build, driver version, quantization details, or reproducible logs. I would treat this as a useful boundary test, not a deployment recipe.

The good part is obvious: this probes the practical ceiling of 32GB consumer VRAM. The reported setup uses TP=2, fp8 KV cache, MTP at 3 tokens, and reaches 62–66 tok/s at 8K. For local LLM users, that crosses the line from “technically runs” to “actually pleasant.” A lot of 27B-class models either need aggressive quantization on a single 24GB card or lose usable context. Here, two lower-end 16GB cards apparently fit a 27B model, vLLM, and a 204800-token window into one machine.

The number that matters most is not 66 tok/s. It is 15.65 GiB per GPU after a 168k prefill. On a 16GB card, that leaves roughly 0.35 GiB of nominal headroom. CUDA allocator fragmentation, driver reservations, vLLM worker overhead, and prompt-shape variance all eat into that. The summary also says max_num_seqs=1. That fixes the use case: one user, one long-context request, one narrow lane. It is fine for a local document session or a single long analysis job. It is not a small team serving setup, and it is not an agent backend handling concurrent tool chains.

The broader read is that vLLM and KV-cache engineering are squeezing the hardware hard. I would not read this as “RTX 5060 Ti is suddenly a serious inference card.” Local users have been running 7B to 34B models on 3090s, 4090s, and 24GB workstation cards for a while. The hard wall has often been KV memory at long context, not only model weights. fp8 KV cache moves that wall. Qwen also has a pattern of landing near sweet spots for open-weight users: models large enough to feel smarter, but still close to consumer hardware limits. A 27B size is shrewd. It feels much more capable than 14B, but avoids some of the pain of 32B and larger models.

I also have a question about the MTP 3-token setting. Multi-token prediction can raise decode tok/s, but the user benefit depends on workload. Short answers, code completion, and structured output benefit more. Long reasoning, self-correction, and tool-heavy agent loops do not always translate linearly. If the 60 tok/s figure leans heavily on MTP, it should not be compared directly with non-MTP runs. The blocked post does not disclose sampling parameters, output length, acceptance behavior, or whether the benchmark counted warmup. Those details change the speed story.

Dual-card tensor parallelism also carries a cost. A 5060 Ti-class consumer setup almost certainly lacks NVLink. TP=2 over PCIe means communication overhead during synchronization, prefill, and some decode paths. The reported 62–66 tok/s at 8K suggests the decode path is tuned well. But the summary gives no prefill latency at 168k. For long-context work, prefill time often hurts more than decode speed. A 168k prompt that takes tens of seconds to ingest creates a very different experience from an 8K chat loop.

My take is conservative. This is quite useful for personal local inference, but weak evidence for production serving. It says the 2026 threshold for a strong local model is drifting toward two midrange 16GB cards, not only 4090s, A6000s, or rented H100s. It also says vLLM’s serving stack is no longer just a data-center-card story. Consumer users are getting real gains from fp8 KV, long-context scheduling, and MTP. But it does not prove 204k context on 32GB VRAM is comfortable. The reported 15.65 GiB per card says the opposite: it works by trading away concurrency and safety margin.

If I were reproducing this, I would check four things first: prefill latency at 32k, 128k, and 168k; decode speed with MTP disabled; the OOM boundary at max_num_seqs=2; and long-context accuracy on needle or repository QA tasks. Speed alone is not enough. Long context often degrades into “the tokens fit, but the model did not use them well.” Qwen’s long-context behavior has generally been decent, but the article body does not disclose evaluation conditions for the 204800-token claim. For practitioners, the practical lesson is a capacity tradeoff: 27B plus fp8 KV plus 200k context can fit inside 32GB, but concurrency, headroom, and stability are the bill.

Apr 28Tuesday

Synced · WeChatApr 28, 15:41

Open-source medical video understanding system uAI-NEXUS-MedVLM released

United Imaging Intelligence released uAI-NEXUS-MedVLM for medical video understanding, with a CVPR 2026 paper. MedVidBench has 532k video-instruction pairs across 8 medical sources and 8 tasks. Qwen2.5-VL-7B SFT reached 89.4% CVS accuracy; GPT-5.4 scored 16.4%.

Why it matters: HKR-H/K/R all pass: the story has a real-medical-video open-source hook, concrete 530K+ data scale, 8 tasks, and a 89.4% vs 16.4% result. The medical focus keeps it in the 78–84 band.

r/LocalLLaMAApr 28, 09:32

Local coding models have reached a threshold for real work

Antigma tested 27B–32B open-weight models; Qwen 3.6-27B scored 38.2% on Terminal-Bench 2.0. The run used 89 tasks and the default per-task timeout, while verified SOTA is about 80%. The key claim is deployment lag: offline coding is about 6–8 months behind hosted frontier models.

Why it matters: HKR-H/K/R all pass: the post gives a real-work threshold claim, a 38.2%/89-task Terminal-Bench result, and a 6–8 month offline gap. Reddit single-post sourcing keeps it in the low featured band.

Apr 27Monday

Hacker News front pageApr 27, 21:05

Running Local LLMs Offline on a Ten-Hour Flight

Dmitri Lerko ran Gemma 4 31B and Qwen 4.6 36B locally during a 10-hour flight with no Wi‑Fi. The MacBook Pro M5 Max had 128GB unified memory and a 40-core GPU; sustained load used about 1% battery per minute, and performance degraded past 100k tokens. The sharp finding is instrumentation: an iPhone cable delivered 60W, while a MacBook cable delivered 94W under the same load.

Why it matters: HKR-H/K/R all pass: this is a named first-person local-inference test with concrete hardware, model, battery, and power numbers. Scope stays practical rather than industry-shaking, so it lands in the 72–77 band.

Synced · WeChatApr 27, 08:03

Apple paper asks: What do your logits know?

Apple researchers posted an arXiv paper testing whether VLM top-k logits leak image details. Using CLEVR, MSCOCO, and probes, 30–80 logits recover noise, target traits, and some background attributes. The key risk is gray-box APIs exposing top-k log probabilities.

Why it matters: HKR-H/K/R all pass: the Apple paper turns VLM logit outputs into a concrete privacy risk, with CLEVR/MSCOCO probes and a 30–80 logit range. It is strong research, not a same-day platform event, so it stays in 78–84.

Take

Apple’s sharp point is not that VLMs leak; it is that leakage sits in the logits layer many APIs expose for developer convenience. The summary says probes on CLEVR and MSCOCO recover noise, object traits, and some background attributes from the top 30–80 logits. The WeChat page is gated, so attack details and the tested model list are not verifiable here. Gray-box access has been sold as interpretability, evaluation help, and tuning ergonomics. In multimodal systems, it also hands callers a side channel over the image. OpenAI and Anthropic have narrowed logprob exposure in several product surfaces, while open VLM wrappers often expose richer debug fields. Apple is asking the right security question: the privacy boundary is not just prompt in, answer out; it includes the probability distribution in between.

Apr 24Friday

Synced · WeChatApr 24, 17:06

Remember more, answer faster, use less: HERMES speeds real-time streaming video understanding by 10x

Fudan University, Shanghai Academy of AI for Science, and NUS proposed HERMES, a training-free framework that turns KV cache into hierarchical memory for streaming video understanding and cuts TTFT by up to 10x. The post lists three mechanisms: hierarchical cache management, cross-layer memory smoothing, and position re-indexing; it reports 68% fewer video tokens with comparable or better results, and Qwen2.5-VL-7B on StreamingBench rising from 73.31% to 79.44%. What matters for practitioners: it answers without external retrieval, with TTFT around 27/29/28 ms at 16/64/256 frames.

Why it matters: Strong HKR-H/K/R: the 10x speed claim is a real hook, and the article includes concrete mechanisms and numbers, including 68% fewer video tokens and 27-29 ms TTFT. It stays below major product-news bands because this is an academic research release, not a market-moving launch.

Apr 23Thursday

QbitAI · WeChatApr 23, 20:43

Qwen3.6-27B open-weights, beats its 397B flagship predecessor on agentic coding

Qwen released Qwen3.6-27B and says it beats Qwen3.5-397B on 4 agentic coding benchmarks with about 1/15 the parameters. The post cites SkillsBench rising from 30.0 to 48.2, GPQA Diamond at 87.8, and AIME26 at 94.1; it uses a dense architecture, Thinking Preservation, and Gated DeltaNet, with weights on Hugging Face and ModelScope.

Why it matters: This is a substantive Qwen open-source model release with concrete agent-coding and reasoning scores, so HKR-H/K/R all pass. I keep it at 84, not higher, because the post gives strong benchmarks but no pricing, context window, or independent reproduction yet.

Take

Qwen3.6-27B beat Qwen3.5-397B on four agentic coding benchmarks with roughly 1/15 the parameters. That fact is already strong. My read is stronger: Alibaba is not just shipping a better open-weight model here. It is publicly conceding that, for a lot of coding-agent work in 2026, training recipe, task targeting, and inference-time behavior now matter more than raw parameter mass.

The post gives a few numbers that are concrete enough to take seriously. SkillsBench goes from 30.0 to 48.2, a gain of 18.2 points. GPQA Diamond is 87.8. AIME26 is 94.1. It also says the model was optimized for repository understanding, cross-file edits, frontend generation, and terminal command execution. That all tracks with where coding models have been improving. But I still have some pushback here: the article does not disclose which four agentic coding benchmarks were used, how tool access was configured, whether pass@k was used, what context length was allowed, or whether the comparison controlled for reasoning budget and agent loop depth. Anyone who has run coding evals knows those settings can move a leaderboard a lot. So I do not read “comprehensively surpasses” as settled. I read it as a promising vendor-reported result.

The part I do buy is the dense architecture choice. Qwen3.5-397B as an MoE made for a great flagship narrative, but open deployment of giant MoE models has had the same practical problem for a while: far fewer people can run them cleanly than can praise them online. Once you put a model into an actual coding-agent loop, with long context, repeated tool calls, multiple diffs, retries, and ranking steps, latency variance and memory management start to matter as much as benchmark scores. A dense 27B model is simply easier to operationalize: quantization is easier, KV cache behavior is more predictable, local serving is less painful, and end-to-end agent runs tend to be more stable. In practice, finishing a 30-minute repo task reliably matters more than winning a single-turn benchmark by a few points.

This is not unique to Qwen. Open models over the last year have kept reinforcing the same pattern: smaller, denser, task-shaped models often beat giant generalist bases once you care about actual developer workflows. DeepSeek helped make that obvious when reasoning and distillation gains started compressing capabilities that used to require much larger systems. On the closed side, Anthropic’s coding workflow and OpenAI’s coding stack have also been optimizing for the same thing: fewer failures inside the tool loop, fewer context drops, less wasted iteration. The “Thinking Preservation” term in Qwen’s post fits that direction. I have not seen enough detail to know whether it is meaningfully new or just a branded way of retaining planning state across turns. The article does not say.

I am less convinced by the multimodal pitch in the snippet. It says native text, image, and video support, then gives a children’s picture book example. For a coding model, that is not the test that matters. What matters is whether it can read UI screenshots, stack traces, dashboards, design mocks, and structured documents, then make grounded code changes. The body gives no evals for OCR-heavy tasks, GUI grounding, or code edits from visual inputs, so I would not count multimodality as proven from this write-up.

There is also a basic but important omission: the snippet says weights are on Hugging Face and ModelScope, but it does not disclose license terms, context window, serving recommendations, latency, throughput, or post-quantization performance. For practitioners, those details are often more important than the release itself. If the license is restrictive, this lands differently from what people call “real open.” If the context and tool-call costs are not well controlled, the deployment advantage of 27B shrinks fast once it sits inside an agent runtime.

So my take is pretty simple. Qwen3.6-27B looks like a pragmatic correction. It does not prove that giant models are obsolete. It proves that for coding agents, a model that is easier to deploy, cheaper to run, and less fragile over long tasks can beat a much larger flagship where it counts. The embarrassing part is not that 397B lost to 27B. The embarrassing part is how long the field kept treating raw parameter size as a sufficient story. I would wait for two things before taking the victory lap: public results on SWE-bench Verified or LiveCodeBench-style setups, and community reports from plugging it into real coding agents for long-horizon tasks. Until then, this is a strong self-reported release, not a closed case.

Bloomberg TechnologyApr 23, 10:34

Alibaba Adds China Eastern Flight Booking to Flagship Qwen App

Alibaba added China Eastern flight booking to the Qwen app, letting users book flights directly; the snippet says this is the first time its agentic AI tech has opened to a major commercial partner. The RSS snippet does not disclose launch regions, fare classes, payment flow, or revenue terms. The real signal is Qwen moving from chat entry to transaction flow, not just another assistant feature.

Why it matters: Featured on HKR-H/K/R: Qwen moves from answers to booking, a concrete agent-commerce step. Kept at 76 because the brief does not disclose rollout scope, payment flow, rev-share, or fulfillment details.

Take

Qwen adding China Eastern booking is a serious product move because flights are not a toy tool call. Flight booking needs inventory, identity checks, payment, ticketing, changes, and refunds. The title says users can book inside Qwen. The snippet says this is Qwen agentic AI’s first opening to a major commercial partner. Launch region, fare classes, payment flow, and revenue split are not given.

Alibaba’s pattern here looks closer to Taobao than to a chatbot plugin: own the entry point, then keep the transaction inside its app. OpenAI’s shopping and travel flows often hand users back to partner pages. If Qwen can finish ticketing in-app, that is a stronger commercial surface than another assistant answer. The catch is execution data: without fulfillment rates or after-sales handling, this is still an entry-point story, not proof that agents monetize.

Apr 22Wednesday

Hacker News front pageApr 22, 21:19

Qwen3.6-27B: Flagship-Level Coding in a 27B Dense Model

Qwen released the open-weight 27B dense model Qwen3.6-27B and made it available in Qwen Studio. It scores 77.2 on SWE-bench Verified vs. 76.2 for Qwen3.5-397B-A17B, and 59.3 on Terminal-Bench 2.0 under a 256K context and 3-hour timeout. The real takeaway is deployment: this is not a larger MoE, but a denser 27B model with stronger coding results.

Why it matters: Qwen3.6-27B is a substantive flagship-model release with open weights, concrete coding benchmarks, and a practical dense-deployment angle. HKR-H/K/R all pass, and per policy a major Chinese model launch should score on par with an equivalent US-lab release.

Take

Qwen shipped Qwen3.6-27B at 27B dense parameters and posted 77.2 on SWE-bench Verified, beating Qwen3.5-397B-A17B at 76.2. My read is that this is less about one more benchmark win and more about Qwen correcting a structural problem in open models: the field spent a year celebrating total parameters and MoE scale, while deployment teams kept eating the routing, memory, and serving mess.

I’ve felt for a while that open-source coding models did not need another “bigger total parameter” story. They needed a model that keeps agentic coding near the top tier without dragging production into MoE-specific pain. A 27B dense model sits right in that gap. The comparison table makes that pretty clear. Against Gemma4-31B, Qwen3.6-27B is up 25.2 points on SWE-bench Verified and 16.4 on Terminal-Bench 2.0. That is not noise. Against Qwen3.6-35B-A3B, a lighter MoE sibling, it also leads across the core coding-agent rows. That pattern usually means the gain did not come from “more total model” alone. It looks like Qwen put serious work into post-training, tool-use trajectories, and long-horizon agent stability.

That said, I’m not fully buying the packaging yet, because the article gives benchmark scores without giving the deployment bill. SWE-bench uses an internal agent scaffold with bash and file-edit tools at 200K context. Terminal-Bench 2.0 uses 256K context, a 3-hour timeout, 32 CPU cores, 48GB RAM, and averages five runs. Those settings are fine for capability extraction. They are not a normal production profile for most teams. If you are building CI agents, IDE copilots, or repository maintenance bots, you usually do not budget three hours per task, and you do not casually run 256K context as the default. The practical questions are latency per successful patch, cost per resolved issue, retry rate, and degradation over long sessions. The excerpt does not disclose those numbers.

I also want to be picky about the phrase “open source.” The post clearly says open weights and links to Hugging Face and ModelScope, which is good. But in the excerpt provided here, I do not see the license terms, commercial-use restrictions, derivative requirements, or a fuller disclosure of training data boundaries. By 2025 this distinction was already a recurring mess. Plenty of companies called something open source when they really meant downloadable weights under a restrictive license. Until the license is visible, I would not treat this as equivalent to fully permissive open-source distribution.

The bigger significance is where this lands against closed coding agents. Closed models still have an edge, but the gap here is no longer huge. Qwen3.6-27B scores 77.2 on SWE-bench Verified, while the table shows Claude 4.5 Opus at 80.9. That is a 3.7-point gap. On Terminal-Bench 2.0, Qwen matches Opus at 59.3. For many teams, that changes the buying decision. Once the capability gap narrows to a few points, the deciding factors become privacy, self-hosting, customization of the agent scaffold, and whether you want to pay closed-model margins for the last bit of success rate.

There is also some useful context outside the article. Over the last year, a lot of open-model teams leaned into MoE because it looked better in training economics and on marketing slides. But serving is where the pain shows up: expert routing, interconnect traffic, KV-cache behavior, continuous batching, and performance collapse on mixed workloads. I have seen teams get excited in controlled evals, then watch throughput fall apart once real long-tail requests hit production. Dense 27B has a very ordinary virtue: it is easier to make stable. You may not get the absolute cheapest token in every setup, but you are much more likely to get predictable behavior. For most developers who are not hyperscalers, that matters more than a giant total-parameter number.

I do have pushback on the benchmark presentation. Qwen mixes public benchmarks with modified and internal ones in the same narrative frame: refined SWE-bench Pro, internal QwenWebBench, and QwenClawBench with a claimed real-user distribution. That is not illegitimate, but those results should not all get the same weight. Publicly reproducible benchmarks deserve more trust than internal task sets and custom harnesses. The hardest evidence here is still the public-facing coding numbers: 77.2 on SWE-bench Verified, 59.3 on Terminal-Bench 2.0, and the fact that it beats Qwen’s own previous 397B total-parameter flagship. The rest needs community reruns.

So my take is simple. This is not a cute “small model punches above its weight” story. It is Qwen shifting the center of gravity from parameter theater back to engineering usability. I buy that direction. I do not yet buy every implication in the blog. Two follow-ups will decide how important this release becomes: real community numbers on throughput, memory, and quantized performance; and a license that does not play word games. If both check out, this becomes one of the most deployable open coding models of the year. If either fails, it stays a very good benchmark post.

Apr 21Tuesday

Synced · WeChatApr 21, 21:09

Monet: Enabling multimodal LLMs to reason in latent visual space

Monet trains Qwen2.5-VL-7B into Monet-7B to reason with continuous latent visual embeddings instead of external tools; the work is accepted by CVPR 2026 and releases paper, code, model, and a 125K SFT dataset. The method uses three-stage SFT plus VLPO reinforcement learning; the post reports 3% to 9.75% gains on in-distribution tasks and 2.31% on out-of-distribution abstract visual reasoning versus the base model. The key detail is the VLPO mechanism and dataset construction; the post does not disclose one unified table of absolute headline scores.

Why it matters: This hits HKR-H and HKR-K: the angle is abstract visual reasoning, and the post includes 125K SFT data, a 3-stage SFT setup, VLPO, and 3%–9.75% / 2.31% gains. HKR-R is weaker because full absolute leaderboard scores and real deployment evidence are not disclosed, so it lands as a

Apr 20Monday

r/LocalLLaMAApr 20, 11:09

Using Qwen3.6 via LM Studio as a Claude Code subagent, saving 30x Opus tokens per task

A Reddit user routed Qwen3.6 through LM Studio as a Claude Code subagent and reported about 30x lower Opus marginal tokens on two audit tasks. In the examples, a 23-file route audit dropped from 13k to 0.4k marginal tokens, and an 18-file Astro site inventory fell from 89k to 3k; the setup used unsloth’s Qwen3.6-35B-A3B-MXFP4_MOE gguf on a 64GB M4 Max with a 64k context window. The key mechanism is offloading extraction and audit work to a local OpenAI-compatible server, while the post also says quality was mixed rather than strictly better than Opus.

Why it matters: A named first-person experiment with 2 clear token comparisons hits HKR-H, HKR-K, and HKR-R: strong hook, concrete setup details, and direct cost relevance for Claude Code users. It stays below p1 because the evidence is a Reddit post with only 2 tasks.

Apr 19Sunday

r/LocalLLaMAApr 19, 22:27

Same 9B Qwen weights: 19.1% in Aider vs 45.6% with a scaffold adapted to small local models

Using the same Qwen3.5-9B Q4 weights on the 225-task Aider Polyglot benchmark, the author changed only the scaffold and raised mean pass@2 from 19.11% to 45.56%. The little-coder setup is not a new model; it uses bounded reasoning, a write guard, explicit workspace discovery, and small per-turn skill injections. The key claim is scaffold-model fit, but the post reports only two full runs and does not disclose ablations, cross-model replications, or a second benchmark.

Why it matters: HKR-H/K/R all pass: the hook is a 2.4x jump on Aider Polyglot 225 with the same 9B Qwen weights, and the post names the scaffold mechanisms. Importance stays low-featured because evidence is thin: two full runs, no ablation, no cross-model rerun, and no second benchmark.

Synced · WeChatApr 19, 12:29

MIA, a next-generation memory agent framework, aims to end agents' "amnesiac" workflows

A Shanghai Institute for Advanced Learning and ECNU team released MIA, a memory agent framework, and said it achieved the best results on 7 datasets. MIA uses a Manager-Planner-Executor design, dual parametric and non-parametric memory, alternating RL, and test-time continual learning; the post does not disclose exact benchmark scores. The key point is memory as capability internalization, not just retrieval, for open-world agents.

Why it matters: HKR-H/K/R all pass: the story targets agent memory, a real deployment pain point, and includes specific mechanisms. It stays below p1 because the article does not disclose per-dataset scores, baseline gaps, or enough reproduction detail.

Apr 17Friday

r/LocalLLaMAApr 17, 03:41

PSA: Qwen3.6 ships with preserve_thinking. Make sure you have it on.

Qwen3.6 adds a preserve_thinking flag to keep prior reasoning in context and address the KV cache invalidation issue seen with the Qwen3.5 template. The post cites the Qwen3.6-35B-A3B model page and gives a two-turn 20-digit-number test: with preserve_thinking on, the model can return the second number from its earlier reasoning. The practical point is cross-turn reasoning retention for agent and tool workflows; LM Studio does not support it yet, and an oMLX PR is open.

Why it matters: HKR-H, K, and R all pass: the story has a strong hidden-setting hook, a concrete two-turn repro, and a clear nerve for local-model and agent users. I keep it in the low 70s because this is a Reddit PSA rather than a primary release note, and the impact is concentrated in Qwen/OSS

Hacker News front pageApr 17, 01:37

Qwen3.6-35B-A3B on my laptop drew me a better pelican than Claude Opus 4.7

Simon Willison ran a 20.9GB quantized Qwen3.6-35B-A3B on a MacBook Pro M5 and judged its SVG pelican output better than Claude Opus 4.7. He used LM Studio with an Unsloth Q4_K_S GGUF, then repeated the test with “a flamingo riding a unicycle” and again scored Qwen higher. This is not a general capability result; the author says this joke benchmark no longer tracks overall model usefulness in this comparison.

Why it matters: A named first-person experiment with reproducible setup gives this strong HKR-H/K/R: the headline has a sharp contrast, the post includes a 20.9GB GGUF on an M5 MacBook Pro via LM Studio, and it hits the open-local-vs-closed-frontier debate. It stays in featured, not higher, لأن/

Take

Simon ran a 20.9GB quantized Qwen3.6-35B-A3B on a MacBook Pro M5, and it beat Claude Opus 4.7 in two SVG drawing prompts. The interesting part is not “Qwen is smarter than Opus.” The interesting part is that this test keeps exposing a split people still blur together: structured code-like rendering is not the same thing as general model quality.

I mostly agree with Simon’s own read. Qwen won here because SVG generation rewards a narrow cluster of skills: local structure control, shape consistency, willingness to commit to decorative details, and clean token-by-token execution inside a markup format. A bicycle frame is a constraint satisfaction problem expressed as code. Claude Opus 4.7 messing that up tells you something real about its behavior on this task. It does not tell you that a laptop Qwen is broadly better than Anthropic’s flagship across reasoning, tool use, long-horizon agents, or enterprise reliability.

That context matters because local models have been closing fastest on exactly these “visible artifact” tasks over the last year: SVG, small front-end apps, component rewrites, JSON-heavy transforms, short code edits, constrained generation. Qwen and DeepSeek have been especially strong there. Closed models still tend to win on messy multi-step work and production stability, but if the task can be compressed into a short context with an objectively inspectable output, mid-sized open or open-weight models are now regularly good enough. Sometimes they’re more pleasing because they commit harder to style.

I do have some pushback on how far to take this result. First, the article shows examples and links transcripts, but it does not summarize the full experimental controls in the post itself: sampling settings, temperature, whether seeds were fixed, whether any retries were discarded, whether the “best of N” effect crept in. For a blog post, that’s fine. For a capability claim, it’s thin. Human-scored one-off generations are great for intuition and terrible for ranking.

Second, Opus 4.7 is carrying the burden of “flagship model” expectations. People see a premium proprietary model and assume it should dominate every small task. I don’t buy that assumption. Frontier closed models are increasingly optimized as compromise machines: safety tuning, refusal behavior, long-context coherence, tool calling, enterprise controls, latency tiers, and cost discipline all pull in different directions. A tightly constrained SVG illustration prompt may simply sit lower in Anthropic’s optimization stack than users assume.

The backup test matters, though. Simon swapped “pelican riding a bicycle” for “flamingo riding a unicycle,” and Qwen still won in his judgment. That weakens the joke theory that labs are secretly training on his exact pelican benchmark. It does not eliminate a broader explanation: Qwen may just be very well tuned for SVG-ish and front-end-ish generations. I haven’t verified their latest training mix, and the article does not disclose it, so I wouldn’t invent a story about deliberate benchmark targeting. But I would absolutely read this as evidence of model-family bias toward structured visual code outputs.

There’s also a deployment angle people should care about more than the pelican itself. A 20.9GB GGUF running through LM Studio on a laptop is not a lab-only setup. That is close enough to commodity for a lot of individual developers and small teams. If your product needs rough icons, diagrams, mascots, landing-page sketches, or editable vector placeholders, the workflow implication is pretty direct: generate drafts locally, keep expensive API calls for planning, review, orchestration, and high-stakes tasks. That is a more useful conclusion than debating who “won” the meme benchmark.

So my read is simple. Qwen did not prove that a 35B local model has overtaken Opus in general intelligence. It did prove, again, that a growing slice of creative output generation has become cheap, local, and inspectable. If Anthropic keeps missing on deterministic short-form artifact tasks like this, users will start asking an uncomfortable pricing question: what exact capability premium are they still paying for?

Apr 16Thursday

Hacker News front pageApr 16, 21:36

Qwen3.6-35B-A3B: Agentic coding power, now open to all

Qwen released Qwen3.6-35B-A3B as open weights, with 35B total parameters and 3B active parameters. The post reports 73.4 on SWE-bench Verified, 51.5 on Terminal-Bench 2.0, and 92.0 on RefCOCO. The key point is agentic coding and multimodal performance at a 3B active-parameter budget, with weights, Qwen Studio, and API access available.

Take

Qwen shipped an open-weight 35B MoE with only 3B active parameters, and it posted 73.4 on SWE-bench Verified plus 51.5 on Terminal-Bench 2.0. My read is simple: this is less about another benchmark climb and more about staking a claim on the default open agent stack. The 3B-active budget is the key fact here. That is the range where inference cost, concurrency, and retry-heavy agent workflows stop being a research demo and start looking operational.

The headline numbers are solid, and the deltas matter. Against its own predecessor, Qwen3.5-35B-A3B, it moves from 70.0 to 73.4 on SWE-bench Verified and from 40.5 to 51.5 on Terminal-Bench 2.0. That 11-point jump on Terminal-Bench is the bigger story to me. Static code generation gains are common. Multi-step terminal execution gains are harder, because they usually reflect fewer collapses across tool use, state tracking, and long-horizon recovery. Against peers, it beats Gemma4-31B on SWE-bench Verified, 73.4 versus 52.0, and lands close to Qwen3.5-27B dense at 75.0. A 3B-active model hanging that close to a 27B dense model on coding-agent work is exactly the kind of efficiency curve open-source teams have been chasing.

I also give Qwen some credit for publishing more of the evaluation setup than many model launches do. SWE-bench is run with an internal bash plus file-edit scaffold and a 200K context window. Terminal-Bench 2.0 includes a 3-hour timeout, 32 CPU, 48 GB RAM, 256K context, and a 5-run average. That does not make the claims automatically true, but it does move them from vague marketing into something closer to inspectable engineering. Too many model posts over the last year published agent scores with no harness details, no sampling setup, and no clue whether they took best-of-many. You then try to reproduce them and lose a full tier of performance.

That said, I still have two pushbacks. First, some of the strongest-looking wins sit on internal benchmarks. QwenClawBench is internal and only “open-sourcing soon.” QwenWebBench is also internal, using auto-render plus a multimodal judge with Elo-style scoring. I actually like the direction. Front-end coding should be judged on rendered output, not token overlap. But internal benchmarks always weaken the portability of the headline. They can support a claim that the new model is better than the old one. They do not fully support a claim of broad market leadership.

Second, Qwen says it corrected problematic tasks in the public SWE-bench Pro set and reevaluated baselines on the refined benchmark. That may be defensible; public eval sets do contain junk. But once a team modifies the benchmark variant, even for good reasons, comparisons become harder to map onto the shared community scoreboard. That does not kill the result. It does mean people should read “strong evidence of progress” rather than “case closed.”

The more interesting strategic signal is that Qwen is framing this model around agentic coding and multimodality together. That is smarter than building a code-only identity. The industry learned the hard way that many coding agents fail outside the editor. They break when they need to inspect a UI, read a screenshot, verify a rendered page, or reconcile visual state with file changes. Qwen cites 92.0 on RefCOCO, and while the article does not fully unpack the multimodal stack in the section provided, the positioning is clear: this is meant to be a tool-using model that can cross terminal, code, web, and vision tasks. If that works in practice, the gain is not just a benchmark gain. It lowers system complexity. Teams need fewer stitched-together models to ship one coding agent product.

The outside context here matters. Over the last year, open models got much better at one-shot coding, but the real pain point remained the economics of long-running agent loops. Once you add repeated tool calls, context accumulation, retries, and rollback, dense models get expensive fast. Closed products like Claude Code and OpenAI’s coding workflows have stayed ahead partly because they combine strong models with polished scaffolding. Most open teams can imitate the scaffold. They struggle to afford the model behavior at scale. Qwen’s 3B-active design goes directly at that bottleneck. You may not get the absolute best single-run solve rate in every setting, but you can afford more attempts and more parallel sessions.

I would not oversell this into a general-purpose crown. The table itself says not to. On TAU3-Bench and VITA-Bench, the model is not sweeping. MMLU-Pro is 85.2. HLE is 21.4. Even on SWE-bench Verified, it still trails Qwen3.5-27B dense at 75.0. So this looks like a deliberately shaped model, not a universal one: very strong on coding-agent work, competent elsewhere, and optimized around active-parameter efficiency rather than broad frontier bragging rights. I buy that trade.

One thing the post does not disclose is crucial for production judgment: API pricing, throughput, latency, and long-context stability. Without those, the story stops half a step before operational proof. Open weights help, but many teams will still use the hosted API for deployment speed. If Alibaba prices this aggressively, the release becomes much more threatening to closed coding stacks. If the price is soft or the latency is rough, the headline weakens.

My bottom-line take is that Qwen is pushing the competitive unit away from raw parameter count and toward effective cost per completed agent task. That is the right battleground. If this model holds up outside Qwen’s harnesses, it belongs in the first tier of open coding-agent bases right now.

r/LocalLLaMAApr 16, 21:27

Qwen3.6-35B-A3B released

Qwen released Qwen3.6-35B-A3B as open source under Apache 2.0; it is a sparse MoE with 35B total parameters and 3B active. The post also claims agentic coding, strong multimodal perception and reasoning, plus thinking and non-thinking modes; the post does not disclose benchmarks, context length, or latency.

Why it matters: HKR-H/K/R all pass: a new open Qwen model is timely, and the post confirms 35B total, 3B active, and Apache 2.0. The score stays at 82 because this is still a launch post; benchmarks, context window, latency, and multimodal details are not disclosed here.

Take

Qwen has released a 35B-total, 3B-active Apache 2.0 MoE, but right now this reads more like a distribution move than a capability conclusion. The Reddit post lists agentic coding, multimodal reasoning, and thinking/non-thinking modes, yet it omits the three numbers that decide whether practitioners should care: benchmarks, context length, and latency. Without those, “on par with models 10x its active size” is marketing copy, not evidence.

My take is that Qwen is still pushing for default-open-model status, not trying to prove it has surpassed the closed frontier. The 35B/3B recipe already tells you the target: practical deployment envelopes, not giant clusters. This is aimed at teams that want something deployable, commercially usable, and flexible enough for code plus multimodal workloads. The Apache 2.0 license matters more than the Reddit post makes explicit. Over the last year, plenty of “open” models still created legal friction for commercial teams. Qwen at least removes that excuse.

There’s also a clear market pattern here. The open ecosystem has already learned from the DeepSeek-style MoE wave that total parameters are a weak proxy for real usability. Active parameters, KV-cache growth, context length, quantized memory footprint, and tokens per second matter more once a model leaves the benchmark slide and lands on an actual GPU box. If Qwen wants the “agentic coding” claim to stick, it should publish reproducible results on SWE-bench, Aider, LiveCodeBench, or at least a clearly scoped internal eval. If the multimodal claim is serious, I’d expect MMMU, MathVista, maybe VideoMME, plus hardware conditions. None of that is in the post.

I also have some doubts about the product packaging. “Multimodal perception and reasoning” sounds clean in a launch graphic, but in deployment those capabilities often pull in different directions. A model can be strong in text reasoning and still become awkward once vision is attached: latency rises, memory use changes, and tool-use stability gets worse. The thinking/non-thinking split raises the same question. That design is popular because it lets one model chase both responsiveness and long-chain reasoning scores, but the key issue is whether this is genuine controllable inference on one base model or just prompt-layer mode management. The post doesn’t say.

So I’m interested, but not persuaded yet. Qwen needs to publish three things before this becomes a serious practitioner story: public benchmark tables, real inference speed on named hardware, and context/quantization guidance. If those numbers land well, this can become one of the stronger local-first open releases of the year. If they don’t, this was mainly a well-timed attention grab.

Apr 7Tuesday

Latent SpaceApr 7, 08:17

[AINews] Gemma 4 crosses 2 million downloads

Google’s Gemma 4 reached about 2 million downloads in its first week. The post compares that with Gemma 3 at 6.7 million over the past year, Gemma 2 at 1.4 million since June 2024, and Qwen 3.5 at about 27 million in roughly 1.5 months. The signal for practitioners is local deployment: one iPhone 17 Pro demo ran Gemma 4 E2B at about 40 tok/s via MLX, with support across Hugging Face, vLLM, llama.cpp, Ollama, and NVIDIA.

Why it matters: HKR-H/K/R all pass: the story has a clean hook, concrete comparative download data, and a real open-model adoption nerve. It stays low-featured because this is a secondary-source uptake snapshot, not a primary Google release or a substantive capability update.

Mar 17Tuesday

NVIDIA BlogMar 17, 21:00

GTC spotlights NVIDIA RTX PCs and DGX Spark running latest open models and AI agents locally

NVIDIA used GTC to showcase RTX PCs and DGX Spark for running local AI agents, and announced Nemotron 3 Nano 4B, Nemotron 3 Super 120B, and the open source NemoClaw stack. The post says DGX Spark has 128GB unified memory for models above 120B parameters; Nemotron 3 Super scored 85.6% on PinchBench, and Qwen 3.5 supports a 262,000-token context window. The key signal is local inference for privacy and zero token cost, while the full “latest open models” lineup and pricing are not disclosed in the post.

Why it matters: HKR-H/K/R all pass: the local-agent hook is strong, and the post includes concrete specs and benchmark numbers. I keep it in featured, not higher, because the full model list and pricing are not disclosed and the source is still a vendor launch post.