Login

u/danielhanchen

Qwen3.6 MTP Unsloth GGUFs now 1.8x faster!
▲ 435 r/unsloth

Qwen3.6 MTP Unsloth GGUFs now 1.8x faster!

Qwen3.6 MTP Unsloth GGUFs now run **1.8x faster, increased from 1.4x just two days ago!**This is due to llama.cpp adding --spec-draft-p-min 0.75!

Args have also changed from
--spec-type mtp
to
--spec-type draft-mtp

Also increase --spec-draft-n-max 2 to 6

We also released Qwen3.5-0.8B, 2B, 4B, 9B MTP GGUFs! We'll be providing more soon!

For folks who find the new updated branch to have some perf regression, set --spec-draft-p-min to 0.0 to get the old behavior - we provided a plot of the old branch (red) vs the new branch (blue / green) as well.

Also you can use 2 speculative decoding algos - you can add ngram via --spec-type ngram-mod,draft-mtp - the perf isn't yet optimized so I'll do more benchmarks to find better numbers - see https://github.com/ggml-org/llama.cpp/pull/22673

Guide for MTP: https://unsloth.ai/docs/models/qwen3.6#mtp-guide

u/danielhanchen — 5 days ago
▲ 73 r/unsloth

Unsloth NOT affected by TanStack compromise - Shai-Hulud worm

Hello everyone - you may have seen https://tanstack.com/blog/npm-supply-chain-compromise-postmortem

Unsloth Core & Unsloth Studio are NOT affected

Our studio/frontend/package-lock.json is pinned to versions OLDER than the malicious publications. Cross-checked against the official advisory table in GHSA-g7cv-rxg3-hmpx:

Package Our lockfile Compromised versions Safe version Status
@tanstack/history 1.161.6 1.161.9, 1.161.12 1.161.13 clean
@tanstack/react-router 1.169.2 1.169.5, 1.169.8 1.169.9 clean
@tanstack/router-core 1.169.2 1.169.5, 1.169.8 1.169.9 clean
@tanstack/react-store 0.9.3 not in advisory -- clean
@tanstack/store 0.9.3 store family not affected -- clean
@tanstack/react-table 8.21.3 table family not affected -- clean
@tanstack/table-core 8.21.3 table family not affected -- clean

Why we weren't exposed:

  1. Our lockfile resolved versions are below the compromise floor. The malicious publications happened on 2026-05-11 19:20-19:26 UTC. Our lockfile was generated against package versions published BEFORE that window, so npm ci only ever pulls our pre-compromise pins.
  2. All Studio CI uses npm ci, not npm install. npm ci is lockfile-strict, refuses to mutate package-lock.json, and validates every downloaded tarball against its integrity SHA. A tampered tarball with a different SHA than the lockfile would be rejected.
  3. No traces of any compromised namespace anywhere. Grepped package-lock.json and confirmed zero matches for @squawk, @uipath, @tallyui, @beproduct, @mistralai, @draftlab, @draftauth, @taskflow-corp, @tolka, router_init.js, tanstack_runner.js, router_runtime.js, @tanstack/setup, the specific worm commit hash, or getsession.org.

This attack is related to https://www.reddit.com/r/unsloth/comments/1s2gxsr/unsloth_studio_not_affected_by_litellm_compromise/ LiteLLM, https://www.reddit.com/r/unsloth/comments/1t06uhk/unsloth_does_not_use_pytorch_lightning/ Lightning AI compromise

Unsloth is NOT affected by LiteLLM, Lightning AI compromises

Going forward, we are further locking down our security scans on our CI to make it even more secure for future proofing:

  • We use lockfiles for ALL packages
  • We auto scan pypi and npm packages in our CI which can detect these issues (AST / regex checks NOT executing code)
  • CI will run on published pypi packages and published npm packages
u/danielhanchen — 8 days ago