Bonsai 2 27B: 9 गुना छोटे फ़ुटप्रिंट में लगभग-लॉसलेस संपीड़न

मूल लेख ↗ Hacker News चर्चा ↗

Qwen 3.8 27B भाषा मॉडल का एक नया “Bonsai 2” संस्करण लगभग-लॉसलेस सटीकता का दावा करता है, जबकि weights को 5.9 GB ternary format में संपीड़ित करता है, जो 8–16 GB consumer GPUs, Apple Silicon, और यहाँ तक कि web browser में भी चलाने लायक छोटा है। शुरुआती उपयोगकर्ता छोटे tasks और कम-VRAM setups पर प्रभावशाली throughput की रिपोर्ट करते हैं, लेकिन लंबे, agentic coding jobs में mixed results मिलते हैं, जहाँ बार-बार looping और benchmarks की तुलना में कम real-world performance दिखती है। चर्चा का बड़ा हिस्सा इसे Unsloth और ISTA जैसी मौजूदा quantization schemes से तुलना करने, context length और VRAM की व्यावहारिक सीमाओं, और क्या इतनी आक्रामक compression base model की क्षमताओं को सचमुच बनाए रख सकती है, इस पर केंद्रित है।

हार्डवेयर, VRAM, और प्रदर्शन

  • मुख्य आकर्षण: 27B Qwen 3.8-व्युत्पन्न मॉडल लगभग 5.9 GB में, जिससे 16 GB GPU और मिडरेंज हार्डवेयर व्यवहार्य हो जाते हैं।
  • उपयोगकर्ताओं ने इसे इन पर चलाते हुए रिपोर्ट किया:
    • NVIDIA: 3070 (8 GB, सीमा पर), 3060 (12 GB), 4090, 5090, 6000 Pro Blackwell, पुराने 16 GB कार्ड।
    • AMD: 6700 XT, 7900 XT/XTX; इन्फरेंस काम करता है, लेकिन Prism के fork, HIP-विशिष्ट ट्यूनिंग, और कभी-कभी धीमे paths की आवश्यकता होती है।
    • Apple Silicon: M1/M2/M4/M5 डिवाइस लगभग 7–40 tok/s देखते हैं, वर्तमान fork में Metal “tensor API” समस्याओं के साथ।
    • WebGPU / ब्राउज़र: desktop browsers में चलता है; कुछ फ़ोनों पर (जैसे Pixel 9) विफल या अस्थिर होता है।
  • 6 GB GPUs इसे लोड कर सकते हैं, लेकिन बहुत धीमे होते हैं (~0.7 tok/s)।
  • प्रभावी weight size लगभग 5.9 GB है, लेकिन KV cache के लिए अतिरिक्त VRAM चाहिए; 8 GB केवल छोटे contexts के साथ ही काम कर सकता है।

सेटअप, टूलिंग, और संगतता

  • GGUFs के लिए Prism का llama.cpp fork चाहिए; upstream llama.cpp अभी ternary format का समर्थन नहीं करता।
  • उपयोगकर्ता OOM से बचने और गति सुधारने के लिए build flags, server commands, और quantization/cache settings साझा करते हैं।
  • Bonsai 2 के लिए अभी कोई drafter/speculative-decoding model उपलब्ध नहीं है; Spark/DGX उपयोगकर्ताओं को n-gram speculation से सीमित लाभ मिलता है।

गुणवत्ता, “लगभग-लॉसलेस” दावे, और benchmarks

  • HF card पर benchmarks मजबूत 4-bit quants के करीब प्रदर्शन सुझाते हैं, जिसे कुछ लोग यदि सही हो तो “crazy good” मानते हैं।
  • कई उपयोगकर्ता रिपोर्ट करते हैं:
    • बार-बार looping, खासकर WebGPU और लंबे tasks में।
    • पूर्ण-precision Qwen 3.8 27B की तुलना में long-horizon reasoning, agentic coding, और memorized text recall में स्पष्ट रूप से खराब प्रदर्शन।
    • छोटे free-form outputs अच्छे, लेकिन coding agent के रूप में निराशाजनक।
  • कुछ लोगों को लगता है कि benchmarks cherry-picked हैं (कुछ long-context या multi-step tasks) और “near-lossless” को संदेह की दृष्टि से देखना चाहिए।

अन्य quants और models से तुलना

  • Unsloth quants (UD-Q4, 2–3 bit variants), ISTA के 3-bit Qwen quant, और अन्य उन्नत schemes (जैसे AngelSlim) के साथ तुलना की गई।
  • thread consensus: naive ≤4 bpw quants जल्दी degrade होते हैं, लेकिन sophisticated QAT/PTQ (जैसे Bonsai) 2 bpw से नीचे जा सकते हैं; implementation details proprietary या complex हैं।
  • कुछ उपयोगकर्ता अब quality के लिए alternative 3–4 bit GGUFs (Unsloth, ISTA) को पसंद करते हैं, और Bonsai का उपयोग मुख्यतः तब करते हैं जब VRAM bottleneck हो।

उपयोग के मामले, सीमाएँ, और भविष्य की दिशाएँ

  • इसमें मजबूत रुचि है:
    • Qwen 3.8 पर आधारित phone-friendly 8B-class Bonsai।
    • बहुत बड़े compressed models (100B+ या Flash/Next variants) जो high-end consumer VRAM में फिट हो सकें।
  • कई रिपोर्टों के अनुसार वास्तविक “agentic” coding tasks में मॉडल अटकता है, loop करता है, या किसी approach पर निर्णय नहीं ले पाता, जबकि cloud frontier models वही tasks reliably पूरे कर लेते हैं।

भाषा और metrics पर चर्चा

  • “9x smaller” जैसे वाक्यांशों पर लंबी side debate:
    • कुछ का तर्क है कि यह गणितीय रूप से बेतुका है; दूसरे इसे व्यापक रूप से समझा जाने वाला idiom मानते हैं, जिसका अर्थ “1/9 the size” है।
    • “N× faster” और mWh/token जैसे unit choices के आसपास भी इसी तरह के तर्क दिखाई देते हैं।