KVSplit - Apple Silicon पर 2-3 गुना लंबा context चलाना

 (github.com/dipampaul17)
1 पॉइंट द्वारा GN⁺ 2025-05-18 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • KVSplit एक open source प्रोजेक्ट है जो Apple Silicon पर बड़े LLM और लंबे context window चलाने में सक्षम बनाता है
  • keys और values के लिए अलग precision allocation के जरिए अधिकतम 72% memory reduction और 1% से कम quality drop हासिल करता है
  • M1/M2/M3 chips और Metal framework के लिए optimized है
  • run speed improvement और memory savings को measured benchmarks और visualization tools से साबित करता है
  • आसान installation, one-command comparison, और कई तरह के benchmarking और analysis tools देता है

परिचय: KVSplit क्यों महत्वपूर्ण है

KVSplit एक open source tool है जो KV cache के अंदर keys और values पर अलग-अलग precision quantization लागू करके Apple Silicon (M1/M2/M3) वातावरण में बड़े LLM और बहुत लंबे context window चलाना संभव बनाता है। यह उन मौजूदा projects की सीमा को पार करता है जो keys और values दोनों को एक जैसी quantization देते हैं, और memory usage को नाटकीय रूप से कम करते हुए quality drop को लगभग महसूस न होने वाले स्तर पर रोकता है। वास्तविक benchmarks, speed, और quality metrics सभी सार्वजनिक हैं, इसलिए इस पर भरोसा किया जा सकता है, और Metal support के साथ intuitive comparison और visualization tools developer efficiency बढ़ाते हैं।

समान projects की तुलना में इसके मुख्य फायदे ये हैं:

  • key-value precision separation से अधिक efficient memory management
  • Apple Silicon-specialized और full Metal framework optimization support
  • benchmark, perplexity, memory/speed/quality measurement और visualization एकीकृत रूप में उपलब्ध
  • one-command installation, model compatibility, llama.cpp integration
  • real-time memory saving visualization और कई comparison test tools

मुख्य विशेषताएँ और कोर बातें

ओवरव्यू

  • KVSplit की मदद से पहले की तुलना में काफी बड़े LLM और लंबे context length को Apple Silicon पर चलाया जा सकता है
  • keys और values को अलग-अलग quantization precision देकर memory savings और speed improvement दोनों हासिल होते हैं
  • अधिकतम 72% memory saving और speed improvement (5-15%↑) के साथ quality drop 1% से कम पाया गया
  • Metal का पूरा support, और बेहतर Apple Silicon acceleration

मुख्य benchmark नतीजे

  • K8V4 (key 8-bit, value 4-bit) configuration में
    • 59% memory saving और 0.86% quality drop (perplexity आधार पर)
    • FP16 की तुलना में 5.7% speed improvement
  • K4V4 (key/value दोनों 4-bit) configuration में
    • अधिकतम 72% memory saving
    • लगभग 6% quality loss। कम quality-sensitive उपयोगों के लिए recommended

memory saving effect comparison

  • FP16 baseline 176MB (8K tokens) से
    • K8V8 (8-bit key/value) : 93.5MB (47%)
    • K8V4 (8-bit key, 4-bit value) : 71.5MB (41%)
    • K4V4 (4-bit key/value) : 49.5MB (28%)

प्रमुख फीचर्स

  • KV cache keys/values की individual quantization
  • Apple Silicon·Metal पूर्ण optimization
  • benchmark/quality (perplexity)/memory usage analysis scripts
  • visualization tools और publication-quality graphs generation
  • one-command setup और real-time comparison feature

project folder structure

  • llama.cpp: Metal-optimized build शामिल
  • models: model files storage
  • scripts: benchmark/installation/comparison/visualization scripts शामिल
  • results, plots: benchmark results और visualization files storage
  • README.md

वैज्ञानिक insight और experiment results

KV cache का मुख्य अवलोकन

  • key vectors की quantization sensitivity, value vectors की तुलना में कहीं अधिक है → quality बनाए रखने के लिए keys को अधिक precision देनी चाहिए
  • K8V4 sweet spot है: key 8-bit / value 4-bit distribution quality-memory tradeoff के लिए सबसे अच्छा है
    • 59% memory saving, perplexity सिर्फ 0.86% खराब, speed भी FP16 से तेज
  • K4V8 में K8V4 जितने ही कुल bits होने के बावजूद 7 गुना से अधिक quality degradation होता है → इससे key-side precision के महत्व की पुष्टि होती है

समग्र संकेत

  • memory efficiency और model quality preservation दोनों साथ में संभव → consumer hardware पर बहुत लंबे context और बड़े models चलाना संभव

उपयोग उदाहरण और configuration recommendations

अलग-अलग quantization precision के साथ run examples

  • basic (FP16): ./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "प्रॉम्प्ट" -t 8 --flash-attn
  • K8V4 recommended: --kvq 8
  • K4V8 (DEMO): --kvq-key 4 --kvq-val 8
  • K4V4 (maximum saving): --kvq 4

long context example

  • 32K context: FP16 को ~1.4GB चाहिए, लेकिन K8V4 ~400MB में चल सकता है

command-line flags explanation

  • -t 8: threads की संख्या, M1/M2/M3 के लिए 8 recommended
  • --flash-attn: Apple Silicon optimization
  • --kvq N: key/value दोनों को N-bit पर सेट करता है
  • --kvq-key, --kvq-val: individual setting support
  • -c N: context tokens की संख्या (जितना लंबा, उतना KVSplit प्रभाव अधिक)
  • -n N: generated tokens की संख्या
  • -f FILE: document input file
  • -m MODEL: model path

advanced benchmarking और visualization

  • benchmark_kvsplit.py से configuration, sequence length, memory/speed/perplexity/scale characteristics की माप
  • visualize_results.py से paper-level graphs generate किए जा सकते हैं
  • results CSV/JSON में auto-save होते हैं और summary भी मिलती है

Apple Silicon optimization और memory visualization

  • Metal framework का पूरा उपयोग
  • memory-constrained M1/M2/M3 devices पर निर्णायक प्रभाव
  • capture_memory.sh से real-time memory saving visualization संभव
  • custom page alignment के कारण वास्तविक saving theoretical value से थोड़ा अलग हो सकती है

summary फीचर सूची

  • independent key/value bit precision और custom quantization
  • Apple Silicon और Metal के लिए पूर्ण optimization
  • memory/speed/quality comprehensive benchmarks उपलब्ध
  • paper-quality visualization और real-time comparison, memory capture support
  • बेहद आसान installation/use interface

citation और reference research

  • "More for Keys, Less for Values: Adaptive KV Cache Quantization" (2024)
  • "Unifying KV Cache Compression for Large Language Models with LeanKV" (2025)
  • base implementation: [llama.cpp], test model: [TinyLlama]

configuration recommendations और future plans

  • K8V4 (key 8-bit / value 4-bit) : 0.86% quality loss, 59% memory saving, speed +5.7% के साथ सबसे अच्छा संतुलन
  • K4V4: अधिकतम memory saving (72%), quality लगभग 6% कम। memory-first उपयोगों के लिए उपयुक्त
  • long context execution में खास मजबूती, 2-3 गुना लंबे context चलाना संभव

future roadmap

  • token importance-based adaptive precision
  • layer-wise individual quantization
  • model-specific custom optimization (Mistral, Phi-3 आदि)
  • web demo और mobile (iOS/iPadOS) support planned

license और contribution guide

  • MIT license
  • developer/AI researcher कोई भी Issue और PR के जरिए योगदान कर सकता है

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2025-05-18
Hacker News टिप्पणियाँ

  • दिलचस्प लगने की प्रतिक्रिया, यह घटना क्यों दिखाई देती है इस पर सहज व्याख्या और खोज तक पहुँचने की प्रक्रिया के बारे में सवाल, install script में patch apply चरण अधूरा होने और git submodule इस्तेमाल जैसे user-friendly सुधारों के सुझाव, और अलग-अलग Python environments को देखते हुए llama.cpp और Python dependencies को अलग करने की ज़रूरत का सुझाव

    • अच्छे सवाल कहकर प्रतिक्रिया, मुख्य अंतर attention की core role से जुड़ा है ऐसा स्पष्टीकरण, key यह तय करती है कि किन tokens पर ध्यान देना है और attention pattern बनाती है, जबकि value केवल दी गई जानकारी पहुँचाती है इस पर ज़ोर, key vectors की quantization बहुत aggressive हो तो सभी token interactions में distortion बढ़ जाता है, जबकि value vector की error केवल उस token की जानकारी को प्रभावित करती है, इस तुलना के साथ पुस्तकालय की shelf number (key) गलत हो तो पूरी तरह गलत किताब मिलती है वाली उपमा, गणितीय रूप से भी key softmax में जाती है इसलिए छोटी error भी बहुत बढ़ सकती है, जबकि value linear average होने से error कुछ हद तक cancel हो सकती है, यह asymmetry खुद भी paper में देखी थी और Apple Silicon पर इसके प्रभाव को quantitative रूप से verify करना चाहा था ऐसा अनुभव, installation feedback और Python dependency सुधार का वादा
    • यह patch वास्तव में llama.cpp पर apply ही नहीं होता, argument parsing code पहले ही arg.cpp में move हो चुका है इसलिए इसका कोई मतलब नहीं, K/V quantization options भी 2023 में ही llama.cpp में जुड़ चुके थे यह स्पष्टीकरण, patch की मौजूदगी का औचित्य संदिग्ध बताते हुए यह राय कि बस command-line arguments ही अलग बनाए गए हैं, और इतने साधारण patch file को apply करने के लिए किसी नए repository की install.sh file चलाने से बचना चाहिए ऐसी कड़ी चेतावनी

  • सवाल कि क्या यह patch MLX में भी संभव होगा, MLX में speed बेहतर मिलती है और यह approach Mac users के लिए real-world speed पर long conversation support में मदद कर सकती है ऐसी उम्मीद

    • शायद संभव हो सकता है, लेकिन खुद MLX को गहराई से देख रहे हैं, framework खुद अच्छी तरह designed है पर example code और benchmarking जानकारी कम होने से अभी कुछ immature सा लगता है ऐसा impression, बल्कि Haskell bindings सबसे ज़्यादा रोमांचक लगती हैं ऐसा निजी मत, lazy evaluation की विशेषता यहाँ fit हो सकती है और pure functional compile graph structure भी अच्छी तरह match कर सकती है, Haskell में ML देखना भी दिलचस्प होगा ऐसी इच्छा

  • सवाल कि --cache-type-k, --cache-type-v options से इसका कोई वास्तविक अंतर है या नहीं

    • कड़ा मत कि यह LLM बस GitHub stars बटोरने की कोशिश जैसा लगता है और वास्तव में यह existing feature से अलग नहीं है
    • याद है कि MLX/MPS में 4-bit support नहीं था, या 8-bit भी पर्याप्त नहीं था, bf16 support भी हाल में जोड़ा गया, पहले Apple GPU पर type_k/v तरीके से न्यूनतम 16-bit (f16/bf16) तक ही संभव था इसलिए llama.cpp के अंदरूनी implementation का स्पष्ट ज्ञान तो नहीं, पर यह थोड़ा अलग approach हो सकता है ऐसी अटकल
    • संक्षिप्त सहमति कि उन्हें भी यही अंतर जानने की जिज्ञासा है

  • कोड पढ़ने के बाद निष्कर्ष कि patch अनावश्यक है, 2023 में ही यह feature llama.cpp में आ चुका था यह PR link से पुष्टि, forked repository की जगह patch apply शैली में install.sh चलाने को प्रेरित करना सावधानी की बात, repository में कई patch files, duplicate code, patch files को overwrite करना आदि जैसी उलझी हुई संरचना की ओर इशारा, वास्तव में सिर्फ --kvq option जोड़ता है जबकि separate K/V quantization options पहले से मौजूद हैं, लेखक को इस existing feature का पता नहीं था ऐसा मानना कठिन है, जटिल scripts देने वाले repository की scripts चलाने की सिफारिश नहीं, HN post और GitHub stars ऊँचे हैं पर सामग्री misleading है ऐसी आलोचना, लेखक लगातार सवाल टाल रहा है यह भी चिंता, साथ में निष्कर्ष कि repository और scripts दोनों पुराने llama.cpp codebase के साथ मिले-जुले हैं और current structure से मेल नहीं खाते इसलिए भ्रम बढ़ता है

    • खुद को भी कई संदिग्ध बातें लगीं, लेकिन शायद कहीं कुछ छूट न गया हो इस कारण लेखक की व्याख्या का इंतज़ार किया था ऐसा उल्लेख, लेकिन कई red flags हैं और GitHub activity history देखने पर Popular projects को LLM-generated code से भरने की मंशा संदिग्ध लगती है ऐसा इशारा
    • राय कि आखिर किसी ने समझदारी की बात कही, patch apply करने के बजाय original project को fork करने वाली संरचना होनी चाहिए और केवल इसी बात से trust risk पैदा होता है, लेखक की GitHub presence भी संदिग्ध है, लोकप्रिय projects में LLM residue वाले PRs बड़े पैमाने पर भेजकर खुद को contributor दिखाने की प्रवृत्ति, information pollution या AI के कारण trust collapse की शुरुआत जैसी चिंता

  • सवाल कि क्या पहले से converted .gguf format models पर भी differential KV quantization (K8V4 आदि) लागू किया जा सकता है, और model type या tokenizer settings पर कोई सीमा है या नहीं

    • KVSplit का मुख्य लाभ यही है कि यह existing .gguf models पर बिना किसी special conversion के सीधे इस्तेमाल किया जा सकता है, quantization सिर्फ runtime के KV cache पर लागू होती है और model weights से इसका संबंध नहीं, --kvq-key और --kvq-val flags से केवल memory storage format तय किया जाता है, LLama-3, Mistral, Phi-2/Phi-3, TinyLlama, Qwen आदि कई models पर सफल परीक्षण का उल्लेख, हालांकि यह llama.cpp Metal backend तक सीमित है और Flash Attention अभी custom KV cache format को bypass करता है इसलिए -fa 0 option चाहिए, इसके अलावा attention इस्तेमाल करने वाली transformer architecture हो तो सब पर लागू हो सकता है

  • सवाल कि 64GB, 128GB जैसे high-memory Apple Silicon पर यह patch ज़्यादा तेज़ या बेहतर है या नहीं, Apple Silicon पर context window बढ़ाने का काम वास्तव में धीमा होता है ऐसी अफ़वाह, बड़े memory systems में इसका व्यावहारिक महत्व है या नहीं इस पर जिज्ञासा

    • KVSplit की memory savings context length के अनुपात में बढ़ती है इसलिए high-memory Mac में इसका absolute फायदा और बड़ा हो जाता है, 128GB Mac Studio पर सैकड़ों हज़ार tokens context संभाले जा सकते हैं, हालांकि यह मूल गणना speed को तेज़ नहीं करता बल्कि memory efficiency सुधारता है, benchmark में K8V4 setting पर 14.5% throughput increase देखा गया पर यह memory access efficiency का असर है, बड़े models में 'धीमी speed' की समस्या मुख्यतः compute performance limit के कारण होती है इसलिए RAM या KV cache optimization से सीधा संबंध नहीं, यानी KVSplit उन स्थितियों में उपयोगी है जहाँ memory limit महसूस हो, और व्यावहारिक उपयोग में 7B~13B जैसे छोटे models को बड़ा context window देना अधिक उपयुक्त है, अगर बड़े model और ultra-long window दोनों चाहिएँ तो server-grade GPU अब भी बेहतर हैं, लेकिन Apple hardware की सीमा को आगे बढ़ाने के लिहाज़ से इसका महत्व है

  • दिलचस्पी और थोड़ी higher-level व्याख्या की माँग, क्या 2048 token model को 4~6k तक बढ़ाकर इस्तेमाल किया जा सकता है, क्या 128k context model को 256k+ window तक चलाया जा सकता है, और local models के ideal use cases क्या हैं इस पर सवाल

    • K8V4 configuration में 59% memory savings संभव है इसलिए maximum context length 2.4x तक बढ़ सकती है, यानी 2048 token model को लगभग 5000 tokens तक, 8K model को लगभग 19.5K तक बढ़ाया जा सकता है, व्यावहारिक उपयोग के रूप में MacBook पर एक बार में पूरी किताब प्रोसेस करना, बड़े codebase का analysis, या conversational apps में लंबा chat history बनाए रखना, memory savings context length के साथ linearly बढ़ती है, निजी अनुभव में 8K context पर KV cache 176MB से 72MB हुआ और 128k पर बचत gigabytes में पहुँचती है, input length limit के कारण OOM होने पर यह सबसे प्रभावी समाधान
    • यह memory savings किसी खास model की resource जरूरत कम कर देती है, इसलिए उपयोग-उद्देश्य के हिसाब से किसी न किसी रूप में लागू किया जा सकता है, हालांकि context window को खुद बढ़ाना non-experts के लिए आसान नहीं, इसलिए बड़े window के लिए trained model इस्तेमाल करना बेहतर, local models को offline/security/experimentation जैसे कई उद्देश्यों के लिए इस्तेमाल किया जा सकता है, और अधिकांश उपयोग model tuning experiments के लिए हैं

  • इसे सचमुच अच्छा idea और प्रयास बताते हुए प्रशंसा, क्या यह GPU पर भी लागू हो सकता है, और क्या इसे अन्य quantization techniques के साथ मिलाकर इस्तेमाल किया जा सकता है ऐसे अतिरिक्त सवाल

    • यह तरीका शायद NVIDIA/AMD GPU पर भी लगभग वैसे ही लागू हो सकता है, क्योंकि key को value से अधिक precision चाहिए यह सिद्धांत hardware-independent है, llama.cpp का CUDA backend भी पहले से --cache-type-k, --cache-type-v options के जरिए separate settings support करता है, मौजूदा patch Metal के लिए optimized है लेकिन सिद्धांत सीधा port किया जा सकता है, अन्य quantization techniques के साथ भी इसे मिलाया जा सकता है और KV cache quantization केवल runtime में लागू होती है इसलिए weight quantization से टकराव नहीं, यह conversion pipeline का अलग चरण है, हालांकि vLLM, TensorRT-LLM जैसे अलग cache structure वाले engines में अलग implementation चाहिए, GPU पर सबसे बड़ा असर FlashAttention structure में सीधे integrate करने पर होगा, जहाँ memory savings speed gains में बदल सकती है

  • कुछ हिस्से समझ नहीं आए और अजीब लगे, इस script को चलाने से बचने की सलाह, और report कर दिया गया है ऐसी सूचना

  • सवाल कि performance कैसे बदलती है, memory में लंबा context डालने पर भी अंततः computation speed तो वैसी ही नहीं रहेगी?

    • अनुभव कि एक ही model, एक ही prompt पर fp16, q8, q4 जैसे अलग cache types आज़माने पर iteration speed लगभग समान लगी, अंदरूनी कामकाज की पुष्टि नहीं की लेकिन उम्मीद थी कि 4~8-bit SIMD batch processing के साथ vectors pack होंगे, पर लगता है कि वास्तविकता में packing नहीं हो रही