Thread

Bonsai 2 27B: Near-Lossless Compression in a 9x Smaller Footprint

585 points · 199 comments · JonSchneider

Loading the complete thread in the background. This saved snapshot is available now. Refresh

kamranjon · 1789680375 · focus · HN ↗
Love this for the folks with 16gb graphics cards - 3.8 27b has been incredible but not quite runnable on anything less than 32gb - will try loading this up on my 16gb intel b50 and see how it goes - not sure these quants can be accelerated by the XPU cores yet but maybe in time!
1. kadoban · 1789681996 · focus · HN ↗
  You can run the ~4 bit quant(s) on 24gb, if you're not _too_ picky on context size.
  This will hopefully be better, though it'd be a _very_ surprising increase in performace at the size they say. Would love to see more about how it benchmarks.
  1. spijdar · 1789682410 · focus · HN ↗
    I run Unsloth's UD-Q4_K_S on 20 GB of VRAM (RX 7900 XT) and I get ~90k tokens of context without quantizing KV cache. With 8-bit quantization, I get about a 134k token context window. That's with only one slot, but for me, it works pretty darn well, with 20-35 tok/s depending on how full that window is.
    orsorna · 1789690726 · focus · HN ↗
    7900 XT is a sleeper card. Although I ended up swapping for the XTX because that 4GB means everything in just increasing the context window. At 8bit KV my window is over 200k, and although qwen loves vomiting out tokens as part of its reasoning chain I trust it enough to get assigned tasks done eventually.
    kadoban · 1789702964 · focus · HN ↗
    How has software/driver support been? I got burned hard by AMD last generation or the one before. Things smoother now, or do you have to baby it like hell and pick and choose software that works?
    orsorna · 1789704232 · focus · HN ↗
    I don't do anything fancier than inference, and I only use llama.cpp, which supports rOCM. I've had few issues; most GGUFs I download work right out of the box. Nearly any popular model has a quant that just works. But as you can see I don't use my GPU for anything weird or nonstandard.
  2. lta · 1789695376 · focus · HN ↗
    I'm doing the same with a context of about 128-150k Surprisingly, I get subjectively better results with Unsloth's 3 bit quants (UD-Q3-XL something), than their 4 bit quants (S or M)
  3. redox99 · 1789699167 · focus · HN ↗
    You can trivially run 131k on 24GB 4bit, and there are repos with tweaks that allow you to get the full 262k but idk if there's degradation with their approach.
    Zambyte · 1789734799 · focus · HN ↗
    How? I'm running 4bit with a q8 kv on a 24gb card, and I'm not able to get 100k out of it. I use a context size of 90k.
    kadoban · 1790012305 · focus · HN ↗
    The biggest/easiest tweak is kv quantization. It's not free, but it seems...sometimes worth it? You can quant them down to 8bit (from 16) without it _obviously_ going to hell.
2. djkoolaide · 1789695087 · focus · HN ↗
  Tried it today on a B70 (same family as your B50) and couldn't get anything usable out of it.
  Prism's llama.cpp fork only has the kernels for CUDA, CPU and Vulkan. No SYCL at all :(
3. kennywinker · 1789708968 · focus · HN ↗
  I run qwen 27b on an old-ass 16gb gpu. It’s very possible using unsloth 2bit and 3bit quants, tho there are a bunch of interesting quants that let you run closer to 4bit on 16gb. This article that’s currently also on the front page mentions a bunch of them while discussing their own quant <a href="https://byteshape.com/blogs/Qwen3.8-27B/" rel="nofollow">https://byteshape.com/blogs/Qwen3.8-27B/
abraxas · 1789680452 · focus · HN ↗
I'm not following the local mdoel scene too closely but this seems quite amazing. Is this able to be run on Apple silicon too?
1. kamranjon · 1789680506 · focus · HN ↗
  "Ternary Bonsai 2 27B reaches up to 143 tokens/second on NVIDIA GeForce RTX 5090 and 46.8 tokens/second on M5 Max. On an RTX 4090, Ternary Bonsai 2 27B consumes just 0.714 mWh/token, making it 40% more energy-efficient than an 8B model running in full-precision."
  1. pizza234 · 1789681997 · focus · HN ↗
    Their mention of the 5090 is bit odd, since on 32 GB GPUs, Q6 fits while having better quality. Very interesting model for 16 GB GPUs though!
    sisve · 1789683442 · focus · HN ↗
    They mention 5090 with regards to speed, Q6 will not have that speed?
    And speed matters a lot for many use cases
    selectodude · 1789685848 · focus · HN ↗
    150 tokens per second on a ternary model implies that it’s GPU bound, I’d bet a Q6 model is even faster because it’s existed longer and seen more optimization. You’d have to be insane to not run an NVFP4 quant over a ternary quant on Blackwell if they both fit.
    wincy · 1789706451 · focus · HN ↗
    With Ninfer and Qwen 3.8 27b it uses a groupwise int mixed quant, and it gets 160 tokens/sec. The mixed quant is between 4 and 6 bits.
    Foobar8568 · 1789727696 · focus · HN ↗
    Ninfer is compatible with a nvfp4 model for the 27b. Also nowadays I prefer to use the byteshape one, I get less loops, and I am not sure if I really see a difference in speed or quality. Pure vibe agentic coding on a C++ codebase or ocaml one, ocaml one has codex as reviewer as I am more interested by that project, the other is more for fun.
    pwython · 1789704984 · focus · HN ↗
    Sometimes you want a decent model running in the background that doesn't take up all the VRAM.
    blurbleblurble · 1789705537 · focus · HN ↗
    Or maybe even to run parallel threads of the same model!
  2. azatom · 1789684236 · focus · HN ↗
    it is like "my fridge is 2mkm (millikilometer) from my desk" m=0.001 h=3600 it should be just Ws or just J
    _kulang · 1789684892 · focus · HN ↗
    What’s wrong with milliwatt hours?
    azatom · 1789687578 · focus · HN ↗
    <a href="https://xkcd.com/2946/" rel="nofollow">https://xkcd.com/2946/
    <a href="https://xkcd.com/3038/" rel="nofollow">https://xkcd.com/3038/
2. Havoc · 1789681662 · focus · HN ↗
  Their first 27B bonsai was able to run on an iphone.
Aurornis · 1789682169 · focus · HN ↗
These are small enough that you can run them entirely in the browser <a href="https://huggingface.co/spaces/webml-community/ternary-bonsai-2-webgpu-kernels" rel="nofollow">https://huggingface.co/spaces/webml-community/ternary-bonsai...
Remember to clear the downloaded weights afterward.
Like the last model, it's amazing they work as well as they do. Use it for any longer task and they fall apart spectacularly and in interesting ways.
1. outofpaper · 1789682591 · focus · HN ↗
  So you have some fun examples?
  1. Aurornis · 1789744366 · focus · HN ↗
    Maybe I oversold the fun-ness of it. The most common failure mode is that it goes into loops and you come back to find it exhausted the output length without getting anywhere.
2. SXX · 1789692885 · focus · HN ↗
  Sadly crashing on Pixel 9 Pro, but I guess phone GPU with 16GB RAM total wouldnt be enough anyway.
  1. trvz · 1789693218 · focus · HN ↗
    It should be though.
    SXX · 1789693454 · focus · HN ↗
    Even native AI gallery uses smaller Gemma models. I guess whatever Chrome is using for WebGPU compute on Android is just adding too much overhead.
  2. 14u2c · 1789695335 · focus · HN ↗
    Runs on my 16GB M2 Air (firefox). ~7 tok/s
  3. jeroenhd · 1789727369 · focus · HN ↗
    3/16 GiB of RAM on the P9Pro is dedicated towards on-device AI models, which WebGPU probably can't access.
  4. throwa356262 · 1789729645 · focus · HN ↗
    To be fair, the GPU in pixel 9 and 10 is pretty bad.
    I really hope they stop using PowerVR in pixel 11.
3. aschobel · 1789755921 · focus · HN ↗
  40 tokens a second on my M4 Max (Safari). Wild times.
z2 · 1789682446 · focus · HN ↗
I'd love to see a Bonsai model start with a 100B+ parameter model and get that down to ~30 GB. But maybe at that point we call it Topiary?
1. all2 · 1789687610 · focus · HN ↗
  Other names that occur to me: Orchard, Forest, Stand (of trees).
2. codebje · 1789710994 · focus · HN ↗
  Bonsai Dai ?
JonSchneider · 1789683062 · focus · HN ↗
I'm hoping they release an 8B v2 based on the Qwen 3.8 series in the near future - that would give us a really powerful model that could be run directly on users phones.
1. sroussey · 1789684528 · focus · HN ↗
  Yes! And maybe get a hf fused webgpu runner for that model so it’s fast!
2. verdverm · 1789687320 · focus · HN ↗
  That would require Alibaba releasing a Qwen 3.8 8B first
simonw · 1789683185 · focus · HN ↗
If you want to try out out the GGUFs from <a href="https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf#these-files-need-our-llamacpp-build" rel="nofollow">https://huggingface.co/prism-ml/Ternary-Bonsai-2-27B-gguf#th... be aware that you need Prism's llama.cpp fork to get them to work, from <a href="https://github.com/PrismML-Eng/llama.cpp/releases/tag/prism-b10685-7dffb15" rel="nofollow">https://github.com/PrismML-Eng/llama.cpp/releases/tag/prism-...
This should work:
```
  cd &#x2F;tmp

  # Get the Prism macOS runtime
  curl -fL https:&#x2F;&#x2F;github.com&#x2F;PrismML-Eng&#x2F;llama.cpp&#x2F;releases&#x2F;download&#x2F;prism-b10685-7dffb15&#x2F;llama-prism-b10685-7dffb15-bin-macos-arm64.tar.gz -o bonsai-runtime.tar.gz
  tar -xzf bonsai-runtime.tar.gz

  # Get the ~5.95 GB GGUF model:
  curl -fL https:&#x2F;&#x2F;huggingface.co&#x2F;prism-ml&#x2F;Ternary-Bonsai-2-27B-gguf&#x2F;resolve&#x2F;main&#x2F;Ternary-Bonsai-2-27B-PTQ1_0.gguf -o Ternary-Bonsai-2-27B-PTQ1_0.gguf

  # Run the server, I used port 8331
  .&#x2F;llama-prism-b10685-7dffb15&#x2F;llama-server \
    -m Ternary-Bonsai-2-27B-PTQ1_0.gguf \
    --port 8331 -ngl 99 -fa on -c 32768
```
Then open http://localhost:8331 for the (very good) baked in llama-server web UI... or run a prompt via the API like this:
```
  uvx llm openai endpoint http:&#x2F;&#x2F;127.0.0.1:8331&#x2F;v1 \
    --model bonsai-2-27b --responses hi
```
That's running at ~20 token/second for me on an M5 Pro (after a server restart I got 44 token/second, not sure why), but I'm pretty sure something isn't working right, on startup the server said "ggml_metal_device_init: - the tensor API is not supported in this environment - disabling".
1. OutOfHere · 1789685497 · focus · HN ↗
  Could you also note all this in a Discussion message at <a href="https://github.com/PrismML-Eng/llama.cpp/discussions" rel="nofollow">https://github.com/PrismML-Eng/llama.cpp/discussions so it's not forgotten?
2. simonw · 1789685606 · focus · HN ↗
  I used that to Generate an SVG of a pelican riding a bicycle:
  <a href="https://tools.simonwillison.net/markdown-svg-renderer?url=https%3A%2F%2Fgist.github.com%2Fsimonw%2Fba4cf3a88f4e7dc32994f2672150f770" rel="nofollow">https://tools.simonwillison.net/markdown-svg-renderer?url=ht...
  It took 18 minutes 20 seconds. Pretty decent for a 5.5GB model file.
  1. kadoban · 1789685934 · focus · HN ↗
    Honestly looks pretty good except whatever is going on with its booty. Is that an ass helmet? I cannot parse what's going on there.
    Forgeties79 · 1789686366 · focus · HN ↗
    I think it’s supposed to be a wing
    bigwheels · 1789689444 · focus · HN ↗
    I like the lens effect behind the rear tire.
    tomcam · 1789697694 · focus · HN ↗
    Like you've never worn an ass helmet
    kadoban · 1789710837 · focus · HN ↗
    Only because I hadn't previously thought of it xD Step up from the standard ass-hat for sure.
  2. rahimnathwani · 1789692067 · focus · HN ↗
    On M1 Max I'm getting just over 16 tokens per second (~1000 tokens per minute).
    After 12 minutes and 12,000 output tokens, it's just finished its overall plan and is writing some of the code it will use later...
  3. rahimnathwani · 1789704066 · focus · HN ↗
    M1 Pro, same prompt, same cli options:
    32,706 tokens 38min 19s 14.22 t/s
  4. raylad · 1789720800 · focus · HN ↗
    How does that compare with the bf16 version?
    For my "Please recite Jabberwocky" test the bf16 almost passes but the ternary and even fp8 versions fail badly.
    ctolsen · 1789734384 · focus · HN ↗
    Definitely a little better.
    <a href="https://gist.github.com/ctolsen/b2883e7cbf5e4357fa04366019e60bfe" rel="nofollow">https://gist.github.com/ctolsen/b2883e7cbf5e4357fa04366019e6...
  5. shmoil · 1789739706 · focus · HN ↗
    Can you ask it for an SVG of a bicycle riding a pelican? Thanks.
3. refibrillator · 1789685765 · focus · HN ↗
  Where did you get these instructions?
  They have a demo repo with a setup.sh script:
  <a href="https://github.com/PrismML-Eng/Bonsai-demo" rel="nofollow">https://github.com/PrismML-Eng/Bonsai-demo
  The release tag and weight file you suggest doesn’t match what you wrote.
  1. simonw · 1789686424 · focus · HN ↗
    I figured them out, starting from the GGUF on Hugging Face.
    If you have found better instructions and they work then use those instead!
    Personally I prefer to download models directly rather than running some `./setup.sh` script where I need to then review what it does first.
    refibrillator · 1789687285 · focus · HN ↗
    Yeah just wanted to mention in case it explains the 2x lower throughout you are seeing on M5. To be fair their documentation is a bit inconsistent in some spots.
    Would be good to know if the release and weights from their demo repo work better. I’m trying on a 4090 and will report back.
    fnordpiglet · 1789750719 · focus · HN ↗
    They’re fairly useful as constrain domain classifiers due to the low memory requirements means you can stuff a lot of them into a less expensive GPU farm and get really decent throughout with pretty good results over all. At least that’s my experience. I wouldn’t bother using a tiny model for coding - but the world is full of abductive reasoning tasks that don’t involve coding.
4. nikwen · 1789688312 · focus · HN ↗
  It would be great to have upstream llama.cpp support for this!
  1. iJohnDoe · 1789694179 · focus · HN ↗
    Agreed. They always sound exciting to try out but are such a pain to get working.
    Zetaphor · 1789700467 · focus · HN ↗
    I always just throw an agent at it. Is this the RSI I keep hearing about
    hedgehog · 1789705690 · focus · HN ↗
    RSI saves you from RSI
  2. xlazom00 · 1789852532 · focus · HN ↗
    They opened some pull requests and some of them are already merged
5. rahimnathwani · 1789690580 · focus · HN ↗
  If you want to download the gguf to your regular huggingface cache directory instead of to /tmp, you can download the model and run the server in one step:
  export HF_TOKEN=xxx # optional, speeds up the download ./llama-prism-b10685-7dffb15/llama serve \ -hf prism-ml/Ternary-Bonsai-2-27B-gguf:PTQ1_0 \ --port 8331 -ngl 99 -fa on -c 32768
6. francisjp · 1789695743 · focus · HN ↗
  Thanks for all of your exploration in public Simon.
  Commenting because the fix I proposed was merged in roughly 49 commits after the PrismML Fork. The “tensor API is not supported” warning occurred because llama.cpp’s startup probe fails to compile a matmul2d kernel: Metal’s tensor headers require language version 4.0, but ggml-metal-device.m previously omitted MTLCompileOptions.languageVersion, disabling the API universally.
  Here’s a link to the diff if you want to try and update that fork to take advantage of the prefill gains afforded by the hardware: <a href="https://github.com/ggml-org/llama.cpp/pull/27461/changes" rel="nofollow">https://github.com/ggml-org/llama.cpp/pull/27461/changes
  1. jb_briant · 1789721285 · focus · HN ↗
    That kind of issue is exactly why Im so happy to have LLMs, let it take one hour or trial and error instead of me spending a day digging traces
7. wombat23 · 1789725211 · focus · HN ↗
  I managed to run it with RTX 3070 (8GB VRAM) following the "Quickstart" on HF model card with minor modifications (modify the architecture 86 for your own hardware):
  git clone https://github.com/PrismML-Eng/llama.cpp && cd llama.cpp cmake -B build -DGGML_CUDA=ON -DCMAKE_CUDA_ARCHITECTURES=86 && cmake --build build -j
  Then downloaded & verified `Ternary-Bonsai-2-27B-PTQ1_0.gguf` from HF and ran
  ./llama.cpp/build/bin/llama-cli -m Ternary-Bonsai-2-27B-PTQ1_0.gguf -ngl 99 -fa on -c 32768 -b 256 -ub 64 --temp 1.0 --top-p 0.95 --top-k 20 -ctk q8_0 -ctv q8_0 -p "hello world in x86 assembler" -n 256
  the parameters were suggested by gpt-5.6-luna to reduce memory footprint, as the defaults ran OOM on my gpu. result looks good:
  [ Prompt: 165.6 t/s | Generation: 40.6 t/s ]
  would be nice if they upstreamed their changes so that it runs with the original llama.cpp
  1. aktenlage · 1789730671 · focus · HN ↗
    Would it speed up prompt processing if you increased the -ub (and -b) parameters.
    wombat23 · 1789742572 · focus · HN ↗
    I don't see any significant speed up. also with defaults according to --help
    -b, --batch-size N logical maximum batch size (default: 2048) -ub, --ubatch-size N physical maximum batch size (default: 512)
    I also tried double the default. that also means that they can be left to default settings, apparently.
  2. ekianjo · 1789742782 · focus · HN ↗
    wow why is prompt processing so slow?
  3. zepearl · 1789743082 · focus · HN ↗
    [delayed]
  4. jimmySixDOF · 1789743350 · focus · HN ↗
    hummm wonder what the context length limit will be like this
  5. wombat23 · 1789761845 · focus · HN ↗
    UPDATE: I did more experiments - this time with llama-server and pi harness. i'll leave the results here for posteriority:
    ./llama.cpp/build/bin/llama-server \ -c "$context_size" \ -ctk q4_0 \ -ctv q4_0 \ --no-models-autoload \ --models-dir ~/bonsai \ --reasoning-preserve \ -ngl 99
    the max context size i could serve is 64K on GPU only (the -ngl 99 setting). tested with pi harness and it is very fast. the /thinking level always gets reset to off though and it is not very smart like this. haven't figure out a way to fix that.
  6. ranger_danger · 1790308912 · focus · HN ↗
    It's being worked on for upstream: <a href="https://github.com/ggml-org/llama.cpp/issues/29058" rel="nofollow">https://github.com/ggml-org/llama.cpp/issues/29058
8. ricardobayes · 1789736171 · focus · HN ↗
  Thanks for this, I never knew llama-server has a web ui until now.
  1. jakswa · 1789738404 · focus · HN ↗
    I love their web UI so much that I had AI slop all over it in a fit of fanboy-ism <a href="https://inkcap.click" rel="nofollow">https://inkcap.click
9. ithkai92 · 1789804522 · focus · HN ↗
  Thanks for the headstart, I saw hf also has PQ2_0 and able to finetune the command and in a MBA M4 24GB averages around 10t/s with the command.
  ./llama-prism-b10685-7dffb15/llama-server \ -m Ternary-Bonsai-2-27B-PQ2_0.gguf \ --port 8331 -ngl 99 -fa on -c 65536 --jinja \ --temp 1.0 --top-p 0.95 --top-k 20 --min-p 0.0
miffy900 · 1789683723 · focus · HN ↗
I really wish people would stop saying N times smaller than something when making a comparison; that makes no sense - it's 1/9th (11.11%) the size. You don't get a smaller quantity by multiplying by a number greater than 1.0. You could instead reverse the subjects being compared - "the original model is 9x bigger than this new smaller, efficient model" or some such. That makes sense.
I keep seeing this being used when people talk about efficiency or performance gains and it's just very unintuitive language.
1. hamandcheese · 1789684149 · focus · HN ↗
  If we were talking about speed instead of size, i think it would be perfectly reasonable to say 9x faster. I'm not sure I agree that 9x smaller is unintuitive. It makes sense to me.
  1. simondotau · 1789687982 · focus · HN ↗
    "Nine times" literally means multiplied by nine, but here we're dividing by nine. It's not unintelligible (because the corrupted verbiage is so commonplace) but it is needlessly awkward. Like saying "resulted in a size reduction increase of 10 megabytes."
    D-Machine · 1789710503 · focus · HN ↗
    > "Nine times" literally means multiplied by nine
    Rather, "nine times larger" means multiplied by nine, and "nine times smaller" means divided by nine. This is basic and not particularly awkward, certainly not more so than e.g. positive/negative correlation, or many much more awkward and more common linguistic constructions, IMO.
    If you have to edit out words (i.e. context) to argue a phrase doesn't make sense... I am not sure what mental model you have for natural language, exactly, but it certainly isn't a very robust one.
    simondotau · 1789743678 · focus · HN ↗
    [dead]
    dools · 1789730446 · focus · HN ↗
    Saying something is 9 times bigger is also a shorthand because “times” is a shorthand for repeated addition. You are adding a number “9 times” to make it “9 times larger”. But we don’t say the “adding” part.
    Likewise if I repeatedly subtract a number 9 times to make it “9 times smaller” I can omit the subtracted bit.
    simondotau · 1789743977 · focus · HN ↗
    Repeated subtraction does not correspond to division in the way repeated addition corresponds to multiplication.
    dools · 1789762569 · focus · HN ↗
    Que? Division is the opposite of multiplication of course it does.
    If you divide 81 by 9 you subtract 9 from 81 until you get to 0. The number of TIMES you do that is the result “81 divided by 9”.
    simondotau · 1789770573 · focus · HN ↗
    This isn’t analogous to repeated addition giving multiplication. You’ve switched from applying an operation nine times to counting how many times an operation can be applied.
    You chose 81 because it’s the one number that makes your argument appear to work. Try the same reasoning with 80 ÷ 9.
    dools · 1789775503 · focus · HN ↗
    [dead]
  2. _carbyau_ · 1789687989 · focus · HN ↗
    "faster" relates to speed. Speed is related to time and speed of a thing is usually defined by time. 9x faster speed translates to time/9. There is an extra step of related conversion there.
    Conversely, 9x [filesize/natural number] is bigger. Every time. At least in the basic maths used by most people. There is no conversion into other units.
    Therefore "9x smaller" when talking about a natural number like filesize is a nonsense statement in logic terms. If you strive for unambiguous phrasing - which is a significant part of the programming experience - this logical nonsense might well perturb you.
    But english language is a flexible thing and if the phrase communicates your intent to your audience then that's fine by me.
    dimes · 1789699981 · focus · HN ↗
    It’s not nonsense at all. If X is N times larger than Y, then YN=X. If X is N times smaller than Y, then Y/N=X. I honestly don’t see why people complain about this. It’s just a way an expressing the multiplicative inverse which we colloquially call division.
    jonhohle · 1789706623 · focus · HN ↗
    I think more intuitively for speed - you are multiplying the things per period. If I’m making widgets 9x faster I have 9 x the previous number of units per period of time. To get the amount of time, you invert the ratio to period over units.
    Multiplying some scale by units per period makes sense and is both linguistically and mathematically sound.
    D-Machine · 1789710236 · focus · HN ↗
    > Conversely, 9x [filesize/natural number] is bigger. Every time.
    Notice how you had to remove the word "smaller" to come to this reading. So "9x smaller" is, by one argument, perfectly logical, and you arguing that the "larger" is always implied in "9x" is not logical at all.
2. UI_at_80x24 · 1789684179 · focus · HN ↗
  Me too!! It's a huge pet peeve. And it's so hard to get people to see how it's linguistically AND mathematically WRONG.
  1. Kinrany · 1789703489 · focus · HN ↗
    I disagree comoletely and I'd be happy to be convinced otherwise
  2. Taek · 1789733224 · focus · HN ↗
    I wrote this elsewhere but I felt it was worth saying again. "9x smaller" is an idiom, much like "spill the beans" or "it costs an arm and a leg".
    Idioms don't have to make literal sense or being linguistically/mathematically correct to be useful. All that matters is that other people know exactly what you mean when you say it.
    And, pretty much universally, if I tell someone "the compressed file is 10x smaller than the original", they are going to know what I mean is that the byte size is 10% of the size of the original.
    That makes it an idiom that is perfectly okay for everyday use.
3. zamadatix · 1789688697 · focus · HN ↗
  I agree it makes little sense in a literal mathematical take but "it's 9x smaller" or is too much of linguistic advantage compared to "the original is 9x larger" or "it's 1/9th as large" to expect a change with. You don't have to invoke fractions, it keeps the thing in focus as the first subject, it matches the pattern of the inverse statement, and it's just plain short... so that's what people will adapt and interpret the meaning to be.
  One other way to map both types of linguistic statement consistently to math is to interpret "9x" as "there is a 9 times difference between these two things" and then "smaller"/"larger" tells you which end of that separation the subject is (rather than specifying whether the multiplication builds up or down).
  1. kevinwang · 1789697846 · focus · HN ↗
    "it's 11% as large" avoids fractions but is much more clear (IMO) than "9x smaller" which my brain doesn't understand.
    zamadatix · 1789698431 · focus · HN ↗
    11% is also a fraction, 11 per 100 or 11/100, but there's nothing wrong with that feeling more natural to some.
    Taek · 1789732865 · focus · HN ↗
    It's an idiom, much like "you are pulling my hair". Are you actually pulling my hair? Of course not, taken literally, many English phrases make no sense. But they are common elements of the language and everyone understands them, so they aren't problematic.
    This is the same. Taken literally, "9x smaller" is nonsense, but everyone who hears that phrase knows exactly what mathematical operation you are referring to, thus it's a totally acceptable way to express that you mean to say 11.11% as large.
    asterix_pano · 1789751608 · focus · HN ↗
    When I hear 9x smaller, I visualize 9 small items taken as much space as the big one, I find it quite clear.
    DoctorOetker · 1789843316 · focus · HN ↗
    I don't see the issue at all, consider whatever as a fraction, or just add a denominator of 1:
    "9 times larger" => multiply the numerator of the fraction with 9
    "9 times smaller" => multiply the denominator of the fraction with 9
    Consider a bag of identical resistors with resistance R
    Add 9 of them in series: the resistance is 9 times larger.
    Add 9 of them in parallel: the resistance is 9 times smaller.
    Its the series vs parallel dictionary wars all over again...
    Check my other comment.
  2. fwip · 1789746124 · focus · HN ↗
    "The original is 9x larger"
    This is another pet peeve that I have with the way we phrase these things: It should be 9x "as large" and 8x "larger."
    The way I'd usually phrase this, to avoid ambiguity, is "this new model is 11% the size (of the original)." Or, the other way, "the old model is 9x the size".
4. rpdillon · 1789691891 · focus · HN ↗
  Eh, when I read smaller with an integer multiplier, I mentally switch to the reciprocal. Easier than convincing the world not to use "9x smaller". Do you feel the same way about "9x faster"? What you're actually measuring is time, and "faster" is the reciprocal of time, similarly to "smaller" being the reciprocal of size.
  1. miffy900 · 1789695272 · focus · HN ↗
    yes, actually I do think the phrase 'N times faster' is sensible and logical
    if I say 'this Apple M5 chip is 3x faster' than this intel chip, it implies two things:
    - the run time of most operations that runs on it is now reduced (so one quantity is smaller)
    - but also: MORE WORK is being completed per unit of time compared to the intel chip (so this quantity is greater)
    So yes, a greater quantity is being measured in the apple chip compared to the intel when you say apple is N times faster. i guess this a quirk with the word 'faster' - it actually measures two things, time and work performed per unit of time. the word smaller just measures size.
    like, if I give a customer a cup of coffee one day, then give them a SMALLER cup of coffee the next day, for the same price, but declare "It's now 2X more space efficient!" i.e. it's now half the size, I'm certain the customer is gonna be pissed.
    rpdillon · 1789698574 · focus · HN ↗
    Ah, but in this case the customer is buying the coffee for the caffeine content. And you've doubled the caffeine content per volume! Twice as efficient a delivery mechanism, similar to this model!
    atiedebee · 1789732458 · focus · HN ↗
    I feel like this becomes less clear if you're talking about "one-time" events. "Our website loads 2x faster now" doesn't mean that they are sending more data per second, and the user won't be doing more website loads. The website load time going from 1 second to 0.5 seconds is "2x faster" and I think that that is a very common way of communicating such performance increases too.
    fwip · 1789746234 · focus · HN ↗
    [delayed]
5. comradesmith · 1789697752 · focus · HN ↗
  I completely agree and this is a pet peeve of mine so it's nice to be validated :]
6. foobarbecue · 1789698420 · focus · HN ↗
  But we're cutting drug prices 500, 800, 1700%!
  1. dofm · 1789710522 · focus · HN ↗
    It was hilarious that this is the only time his, er, meta-imaginary-gains intensifier made the statement literally true.
7. peey · 1789698697 · focus · HN ↗
  It's simple
  If 9 is "9 times greater" than 1 then 1 must be "9 times smaller" than 9
  It'd help if you read "9 times" with the operator which is what's being flipped instead of with the number
  1. a3w · 1789737111 · focus · HN ↗
    Its complicated:
    50 percent smaller means two-thirds the size. 0.999 times smaller means size is nearly zero. 9 times smaller means you get negative memory from loading it.
8. derefr · 1789702715 · focus · HN ↗
  They probably rephrased it from some more technical form like "we compressed the model by a factor of 9" or "we've improved the packing efficiency of the model by 9x".
9. Kinrany · 1789703393 · focus · HN ↗
  This sounds like the same kind of error as writing "0.10 cents" because it's less than a dollar when the number is in dollars regardless of how big or small it is
10. nicbor · 1789703613 · focus · HN ↗
  This is widespread usage.
  I don't see what makes it hard to understand.
11. stkdump · 1789720553 · focus · HN ↗
  Also, X is 9 times larger than Y and X is 9 times as large as Y are two different statements.
  1. so-cal-schemer · 1789763244 · focus · HN ↗
    to spell it out..
    200% as large as 1 is 2.
    200% larger than 1 is 3.
    so-cal-schemer · 1789767630 · focus · HN ↗
    200% (or 2x) smaller than 3 is.. ?
    stkdump · 1789970470 · focus · HN ↗
    10% smaller is 30.1=0.3 smaller than 3, which is 3-0.3=2.7
    So 200% smaller is 32=6 smaller than 3, which is 3-6=-3
    Which is why these kinds of statements usually don't make any sense at all. Usually something can't be more than 100% smaller, at which point it is completely gone.
12. trentor · 1789721132 · focus · HN ↗
  [dead]
13. a3w · 1789737053 · focus · HN ↗
  yes, 50 percent smaller means two-thirds the size. 1 times smaller means size zero, so nine times smaller is impossible.
14. DoctorOetker · 1789744278 · focus · HN ↗
  Define the "parallel sum"
  a∥b=((a*b)/(a+b)
  A normal sum has the associative property:
  a+(b+c)=(a+b)+c which justifies dropping the parentheses
  a+(b+c)=a+b+c=(a+b)+c
  It is just an exercise for the reader that the parallel sum ∥ operation is associative:
  a∥(b∥c) = (a∥b)∥c
  multiplication is typically defined as repeatedly adding:
  a x b = b+b+...+b+b (a times b)
  similarily one can define parallel multiplication xx :
  a xx b = b∥b∥...∥b∥b (a parallel-times b)
  The reader can verify that 9 parallel-times size
  9 xx size = size∥size∥size∥size∥size∥size∥size∥size∥size = size / 9
  So I just think the Bonsai designers meant it was 9 parallel-times smaller, which checks out...
2001zhaozhao · 1789684336 · focus · HN ↗
I think if they made this for Qwen3.8-Next it could fit in a single 5090?
1. kennywinker · 1789709226 · focus · HN ↗
  180b * 1.76 bits per weight = 39.6 gigabytes.
  1. jokethrowaway · 1789721294 · focus · HN ↗
    Qwen3.8-Next, thanks to its new architecture, is quite fast even if part of it is streaming from disk
    kennywinker · 1789755996 · focus · HN ↗
    Totally. Any MoE model can have experts swapped in and out from disk or system ram. I only framed it this way because the question was about the model fitting in vram.
danbrooks · 1789684929 · focus · HN ↗
Nice! Does anyone know how this compares to the Unsloth quantizations of this model? <a href="https://unsloth.ai/docs/models/qwen3.8#run-qwen3.8-guide">https://unsloth.ai/docs/models/qwen3.8#run-qwen3.8-guide
1. 0xbadcafebee · 1789689422 · focus · HN ↗
  [delayed]
2. nulld3v · 1789693465 · focus · HN ↗
  [delayed]
  1. kadoban · 1789698822 · focus · HN ↗
    Oh, wow, they think it's just a smidge below the q4? That's crazy good if true.
    anana_ · 1789700591 · focus · HN ↗
    The benchmarks they chose are rather cherry picked to not include long context or difficult ones that involve long horizon work or many agent turns, as I suspect this is where the model shows more differences compared to the full fat one
    SillyUsername · 1789712098 · focus · HN ↗
    Yep more hops from the lower Q is likely going to skew the vectors further over time.
    I wonder if there's a way to mitigate this by running it through an original Q8 draft model, attuned somehow for the PTQ1 quant, but giving it a higher threshold for the acceptance linear with the context length itself?
    The longer the context, the higher the multiplier on the threshold, and more likely the draft result is used. Not ideal but it may extend the usable max context.
    This model might, even without this, be amazing for short lived agents that work via generations / have changing tasks.
3. [deleted] · 1789698305 · focus · HN ↗
  [deleted]
4. WithinReason · 1789713854 · focus · HN ↗
  Unsloth has been dethroned by ISTA:
  <a href="https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF" rel="nofollow">https://huggingface.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF
  The 3-bit quant is lossless based on benchmarks.
  1. raylad · 1789725475 · focus · HN ↗
    I just checked that model (ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF:IQ3_S) and it does much much worse on the "Please recite Jabberwocky" test than the original bf16 does.
    The bf16 only misses "snicker-snack" and this quantization becomes confused after the first stanza.
    sorenjan · 1789734089 · focus · HN ↗
    I think it should be expected that a smaller model is worse at reciting memorized data than a big one. I also don't think it's a good use case of small local models. Can it find and recite Jabberwocky if given access to a web search tool?
    0xbadcafebee · 1789755878 · focus · HN ↗
    [delayed]
    sorenjan · 1789828554 · focus · HN ↗
    It depends on what you mean by lossless. If both models can perform the same tasks it can be considered lossless for those tasks. That task might be more related to language understanding rather than memorizing, they have several benchmarks in the article.
    WithinReason · 1789737626 · focus · HN ↗
    [dead]
adrian17 · 1789685186 · focus · HN ↗
> Ternary Bonsai 2 27B uses ternary {−1, 0, +1} weights with FP16 group-wise scaling, for 1.76 effective bits per weight
If I recall correctly, a recent post [1] has shown that Q2 quants (with like 2.6 bpw) sit at the edge between "noticeably worse" and Q1's "useless". I took a quick glance at Bonsai's blog posts, and don't really see them comparing themselves to "typical" quants or explaining what makes them better?
<a href="https://news.ycombinator.com/item?id=49611128">https://news.ycombinator.com/item?id=49611128
1. edflsafoiewq · 1789685632 · focus · HN ↗
  I think the general idea is naive quantization falls apart below 4bpw but you can go lower with more sophisticated QAT-adjacent methods. Bonsai's quantization method is proprietary though.
  1. yowlingcat · 1789689412 · focus · HN ↗
    [delayed]
  2. om8 · 1789692235 · focus · HN ↗
    Could've been better if GGUF implemented QTIP format. GGUF representation is a major limitation for llama.cpp quantization performance
    edflsafoiewq · 1789692534 · focus · HN ↗
    They use their own llama fork anyway, so that shouldn't matter.
2. 0x457 · 1789686625 · focus · HN ↗
  [dead]
  1. smallerize · 1789736149 · focus · HN ↗
    I think the 1.76 includes that. Plain ternary packed into bytes would be around 1.58.
3. nulld3v · 1789689642 · focus · HN ↗
  [delayed]
  1. Balinares · 1789721688 · focus · HN ↗
    I wonder how well it performs in practice, because I can't help seriously doubting those benchmarks. That would put this 6GB model in Opus 4.6+ ballpark. Granted, that's mostly to Qwen 3.8's credit, but it's hard to believe that Qwen's already unbelievable capability density can still be compressed this much more.
logicallee · 1789685886 · focus · HN ↗
(In case anyone remembers the compression post from yesterday[1], I checked and this one doesn't qualify for further compression - it's not zero-biased at all.)
[1] <a href="https://news.ycombinator.com/item?id=49732931">https://news.ycombinator.com/item?id=49732931
Havoc · 1789687456 · focus · HN ↗
Cautiously optimistic. The V1 was noticeably weak on world knowledge but here the 3.8 base model is geared more towards reasoning than world knowledge anyway so might not matter as much
jedbrooke · 1789687817 · focus · HN ↗
Running at about 7-8 tok/s (~60 tok/s prefill) on a Mac Mini M2 16GB.
So far feels smarter than Bonsai 1 27B, it’s slightly larger than the Q1_0 quant. Super exciting stuff :)
flutetornado · 1789688738 · focus · HN ↗
GPT Astra did some benchmarking on the DGX Spark. Speed: 34.38 tokens/sec for generation.
Seems like we don't have a drafter model yet so it could not test with speculative decoding on. ngram speculative decoding did not help too much either - not enough accepted tokens.
Smaller size I suppose does not mean better performance in this case - we maybe limited by Spark's low memory bandwidth.
1. cmrdporcupine · 1789689521 · focus · HN ↗
  What are you getting for prefill?
  1. flutetornado · 1789692113 · focus · HN ↗
    450 with PTQ_01 and 900 with the other PQ2_0.
2. mmastrac · 1789698494 · focus · HN ↗
  That's a rough place to land on a spark. It seems unlikely to be memory bandwidth at this model size, but maybe just lack of tuned kernels? The chip is missing some CUDA features but with tuning you should be able to hit way more than that even without a drafter.
  1. flutetornado · 1789717887 · focus · HN ↗
    I was wondering if those ternary bits get expanded into full floats internally in the kernels - you’re probably right about lack of tuned kernels. I’m not sure you could just tune your way out of that easily though. Any suggestions on trying particular solutions?
ipoole_dev0 · 1789689328 · focus · HN ↗
[dead]
circularfoyers · 1789689367 · focus · HN ↗
I wonder how their talks with Apple went. Having this run on the TPU opposed to just the GPU, which drains a significant amount of battery life by comparison, is what I'm really interested in.
1. bigyabai · 1789692205 · focus · HN ↗
  If you're talking about onboard NPUs like the Apple Neural Engine, they are orders of magnitude too weak to perform inference for models at this scale.
cmrdporcupine · 1789689484 · focus · HN ↗
What I'd love to see is this done for DS4.1 Flash.
That would bring it down to the point where it can fit in 128GB on things like the Spark or Strix Halo.
redlimetea · 1789690521 · focus · HN ↗
[dead]
hedora · 1789691625 · focus · HN ↗
RAM requirements? My current rule of thumb is “a byte per parameter”, but I doubt this runs in 1/9th that (~ 3GiB).
Also, perf speedup?
1. jjcm · 1789691726 · focus · HN ↗
  I'm seeing around 7.9GB of ram, 120 tokens/s on a 6000 pro blackwell.
2. kennywinker · 1789710366 · focus · HN ↗
  Without context, it should be number of params * 1.76 (the “effective bits per weight”) / 8
  So for this one, 27B * 1.76 / 8 = 5.94 GB
  For speed, far as I can tell it depends if your gpu is memory bandwidth bound or (mostly older gpus) processing bound. If it’s memory bandwidth bound, and your gpu gets 300GB/s, that’s:
  300GB/s / 5.98 GB = 50.5t/s.
  Realistically it’s probably a bit slower, but that is your theoretical maximum.
  1. Dwedit · 1789741404 · focus · HN ↗
    It needs breathing room in addition to just the model weights. With 6GB of actual VRAM, you get 44/65 layers loaded into VRAM.
    kennywinker · 1789755914 · focus · HN ↗
    “Without context” was me gesturing at that. Interesting you can’t fit the whole model tho - why is beyond my current understanding :)
    Dwedit · 1789756700 · focus · HN ↗
    Even with a small context size (4096 at 64KB per token), that's like 256MB for the context. It's more than just the context that's eating up VRAM.
g023 · 1789692787 · focus · HN ↗
They need to make a Big Bonsai, something at the enterprise levels that can compete with DSV4 Flash etc.
1. Fordec · 1789692943 · focus · HN ↗
  A Tree if you will
  1. ncr100 · 1789702862 · focus · HN ↗
    Or Grove
blactuary · 1789694903 · focus · HN ↗
What is never totally clear with a lot of these releases is the scope of what it's good at. Models that can run with good speed on affordable consumer hardware for coding only is the dream. I am never going to use this for writing, images, or "general knowledge". Coding only
1. nullbio · 1789725839 · focus · HN ↗
  Any time I'm doing frontend work it involves images. I think images are important.
redox99 · 1789696459 · focus · HN ↗
I tried their WebGPU version and it immediately started looping. Yeah "near lossless" my ass.
respectattentio · 1789697833 · focus · HN ↗
Never heard of Bonsai before, but that looks great and promising for local on-device inference.
Yet, seems like there is still another year for improvements.
I like local models (but not mainly using them) for offline needs.
jocelyner · 1789698681 · focus · HN ↗
[dead]
avaer · 1789701040 · focus · HN ↗
LLM quants seem to eerily converge to modern/not so modern graphics techniques. You wouldn't think it would apply but it's obvious in hindsight. In fact mining graphics ideas is probably a good inspiration for efficient LLM architecture.
For example, the Hadamard activation transform used here feels a lot like multiplying Fourier basis ala DFT; strong parallels to how image codecs work to make the residuals more compressible (especially discrete block codecs like are used in GPU compressed textures).
I thought I was being clever suggesting that you could even abuse texture decode units to efficiently sample compressed LLMs with hardware; turns out Apple foundation models are already doing this [1].
[1] <a href="https://arxiv.org/abs/2507.13575" rel="nofollow">https://arxiv.org/abs/2507.13575
sb057 · 1789701247 · focus · HN ↗
[dead]
Dwedit · 1789701381 · focus · HN ↗
I tried it on my 6GB GPU and got 0.67 tokens per second. Need more than 6GB to run it well.
huseyinkeles · 1789704082 · focus · HN ↗
Testing on a MBP m4 pro 24gb
~100t/s prefill, ~15t/s, dropping to ~10t/s later with 64k context.
The issue is I have yet to find a useful agentic local llm that I can run on this machine.
Just given a relatively simple task on a swift app, took 25 minutes, brainstorming like crazy but can not decide on what to do. Eventually I killed it. GPT 5.6 sol-medium took 3 minutes to complete the same task for reference.
1. aetherspawn · 1789705238 · focus · HN ↗
  Gemma 30B with 256K context runs at 20 tok/sec on my M3 Max with 128GB RAM so I think there’s something wrong with your setup. This should run at ~30-40 toks. Maybe your inference engine is not optimised for Mac.
  1. huseyinkeles · 1789705853 · focus · HN ↗
    I just used their `Bonsai-demo` repo like this;
    `cd ~/Code/Bonsai-demo && BONSAI_CTX=65536 ./scripts/start_llama_server.sh`
    then used it in a very minimalistic pi with a very small system prompt.
    Didn't spend much time to try to optimize it tbh, but my issue was not the speed. it just could not make a decision on how to implement the task, kept going on an on.
    yearolinuxdsktp · 1789771592 · focus · HN ↗
    Maybe you have to set reasoning effort to low. 3.8 27B on x-high (default) reasons forever on anything complex. I asked it to write down the answer plan so far leaving open questions as open and it wrote the plan twice in reasoning (and more times partially) while it dilly-dallied about open questions before realizing “ok the user just asked to leave questions open.” That was a Q6o quant with unquantized KV cache.
    aetherspawn · 1789875250 · focus · HN ↗
    Yes, I use LM Studio with MLX support, which is specifically faster on M series Macs. I am not sure if llama is the same, but I guess what I’m saying is if you want the performance to be good on M series you have to use models packaged in the right format.
  2. piyh · 1789706433 · focus · HN ↗
    30B is useless on 24 gigs of ram as there's ~4 gigs of ram left for everything else even with unsloth quants
  3. BoredomIsFun · 1789832753 · focus · HN ↗
    31B
2. sean_pedersen · 1789705396 · focus · HN ↗
  Try a MoE model like Qwen3.6 35B-A3B for better tok/s
  1. huseyinkeles · 1789705632 · focus · HN ↗
    I tried this one, but I found Ornith to be a better MoE model, also very fast. But I still couldn't make it implement a real task on a real repo :(
zhiyan · 1789705382 · focus · HN ↗
Awesome results. Opens up doors for a lot of people.
throwaway_5753 · 1789709024 · focus · HN ↗
very cool
hilti · 1789714409 · focus · HN ↗
[dead]
nilsherzig · 1789715828 · focus · HN ↗
Fyi, if you're trying to run this under AMD/HIP:
PTQ1_0 has no optimized MMQ-Path in their llama-cpp fork, try running PTQ2_0 (needs a bit more vram, but is about 2x faster on my 6700 XT)
1. jakswa · 1789739163 · focus · HN ↗
  what kinda speeds do you see on 6700 XT? i'm always conflicted on investing time chasing speed-vs-quality tradeoffs. I've got a 7900 XT (about double the IO throughput). I'll probably end up giving it a go when I find time.
verytrivial · 1789718608 · focus · HN ↗
There's a chap called Bijian Bowen who does very quick agentic coding challenges for new models (very soon after release!) mainly for toy games or websites. He just did one for this model and included a comparison with the base model Qwen 3.8 which shows the "near-lossless" claim should be taken with a grain of salt. It is an interesting model if you are GPU starved and want local, but you might have trouble finding things it is good at.
1. Aurornis · 1789743928 · focus · HN ↗
  > which shows the "near-lossless" claim should be taken with a grain of salt
  I agree. I don’t know how they get such good results on these benchmarks because using them gives a very different experience. They’re kind of cool for doing short free form outputs in memory constrained systems, but I don’t think they’re useful as coding agents.
  1. UrineSqueegee · 1789751790 · focus · HN ↗
    these are very saturated benchmarks
2. qingcharles · 1789789513 · focus · HN ↗
  The only two I trust are Bijan and simonw.
mpweiher · 1789720005 · focus · HN ↗
Is it just me or are local models getting better (catching up) a lot faster than the frontier models are getting better (creating distance)?
If true, that would be a very welcome development.
hvhvubufyvycjcx · 1789721526 · focus · HN ↗
Hello! May I ask, is Bonsai 2 27B compatible with my RX 9070 on Linux
hvhvubufyvycjcx · 1789721564 · focus · HN ↗
Hello! May I ask, is this model compatible with my RX 9070 on Linux?
1. hvhvubufyvycjcx · 1789721902 · focus · HN ↗
  The dev didn’t list AMD Radeon support, and I couldn’t get it to work
Chance-Device · 1789723250 · focus · HN ↗
Let’s see, so if you get the same 1/9th the size compression ratio with GLM-5.3-Flash, then you’d end up with a ~72GB model that’s about as good as GPT-5.6 Sol (high), according to artificialanalysis.ai
Which is within reach of some higher end consumer hardware, especially with layer offloading.
You have to wonder what kind of trouble the “labs” are in when this is becoming possible. Lots of money, where’s the moat?
1. indy · 1789725627 · focus · HN ↗
  They're trying to build a moat with legislation, using fear over 'safety' as an excuse to ban these open models
  1. DoctorOetker · 1789859822 · focus · HN ↗
    A gentleman's agreement between the western bloc, China, India, Russia, ... ?
    It would be a lip service agreement, and all would continue the machine learning race...
    The mere suggestion of slowing down AI progress signals to adversaries that there is some novel power just identified: do you think adversaries would agree and slow down, or calculate a little harder and longer in order to also figure out what it unlocks?
    indy · 1789894438 · focus · HN ↗
    Do you ever wonder how Anthropic or OpenAI can release a new state of the art model and then a few months later there's a Chinese open model that's nearly as good?
2. kllrnohj · 1789731586 · focus · HN ↗
  The labs still have performance as a differentiator for coding usages and similar, and for other things there's still all the same reasons people switched cloud hosted stuff in the first place. AWS & friends didn't get popular because the hardware was out of reach, after all.
  1. Chance-Device · 1789732546 · focus · HN ↗
    That’s an argument for a cloud LLM service, sure, but the hyperscalers can do that by themselves with the weights.
    What’s the moat for trillion dollar AI companies? Access-anywhere convenience to models as good as everyone else’s?
    kllrnohj · 1789750802 · focus · HN ↗
    the trillion dollar AI companies will be the chip designers for the hyperscalers, and probably not worth a trillion dollars as a result
3. ctolsen · 1789733738 · focus · HN ↗
  If we go with AA's benchmarks Qwen 3.8 27B is already slightly below Luna level which is in itself impressive, but with this compression it should be just slightly more below Luna level and could run on my old GTX 1070 that I'm now tempted to fire up. That's kinda nuts even allowing for small-model problems that I'm sure I'd see quite clearly.
claud_ia · 1789725734 · focus · HN ↗
[dead]
nullbio · 1789725749 · focus · HN ↗
Well this is quite impressive!
cregy · 1789726079 · focus · HN ↗
On openrouter I had to filter out glm 5.3 flash instances running fp4 - making sure it only ran fp8 - as the quantized models kept going crazy / off track.
Assume bonsai has the same ticks
thway15269037 · 1789734717 · focus · HN ↗
I wonder if they could apply the same to Qwen3.8-Flash-Next.
If they did 60gb -> 6gb to Qwen-27B, could they possibly do the same to the MoE model. 36gb lossless 126B model seems like an impossible task.
v3ss0n · 1789735177 · focus · HN ↗
On actual agentic task , it just fail.
antonly · 1789737160 · focus · HN ↗
What did they do with their benchmarks? I've never seen Qwen3.6 27B this close to Qwen3.8 27B in any aggregated summary... Makes one questions the entire accuracy section.
petrenk0n · 1789738224 · focus · HN ↗
Anyone who wants to try Bonsai 2 without setting up runtimes etc, try here - <a href="https://triangllabs.ai/otis" rel="nofollow">https://triangllabs.ai/otis
itsmeduncan · 1789738571 · focus · HN ↗
[dead]
euroderf · 1789742062 · focus · HN ↗
Stupid question: Does "total model footprint of 5.9GB" mean it will run in 8GB of RAM ? Or is that the size on disk ?
1. Aurornis · 1789743799 · focus · HN ↗
  That’s the size of the model. Running it requires additional space for the KV cache depending on how much context you use. You can probably get it running in 8GB of RAM for short outputs but to get okay context length you’d want more.
jakswa · 1789760036 · focus · HN ↗
Bonsai 2 27B · Radeon RX 7900 XTX
- 89 tokens/sec generation with speculative decoding - 81 tokens/sec at 20k context - 474 tokens/sec ingestion at 20k — about 42 seconds - 10.1 GiB peak VRAM with a 24k context window
ROCm 7.2.3 · PQ2_0 · Qwen Q4 MTP, draft length 2
---- versus ----
Qwen3.8-27B IQ3_S · Radeon RX 7900 XTX
- 79 tokens/sec generation on a short coding prompt - 61 tokens/sec at 60k context - 53 tokens/sec at 95k context - 558 tokens/sec ingestion at 60k — about 108 seconds - 19.9 GiB peak VRAM during coding tests with a 100k context window
Vulkan · GSQ-RCO IQ3_S · MTP, draft length 2 · vision projector loaded
imagetic · 1789855188 · focus · HN ↗
Has the hype fizzled out yet? Can anyone post a link to something they've done with success?

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.