एक बड़ा एआई अचानक आपके कंप्यूटर पर क्यों चल पाता है: क्वांटाइज़ेशन की व्याख्या

एक विशाल मॉडल फ़ाइल काफ़ी छोटी हो जाती है, और अचानक पहुँच में मौजूद किसी डिवाइस पर स्थानीय एआई संभव लगने लगता है। मेमोरी की बचत दिखाई देती है। जो शुरू में अदृश्य रहता है, वह यह है कि बदले हुए संख्या-निरूपण के कारण कौन-सी जानकारी खो जाती है और क्या यह हानि आपके कार्य के लिए मायने रखती है।

यह llama.cpp क्वांटाइज़ेशन दस्तावेज़ीकरण उन विधियों का वर्णन करता है जिनसे मॉडल वेट्स को कम परिशुद्धता के साथ संग्रहीत किया जाता है। इससे स्थान बच सकता है और प्रोसेसिंग बदल सकती है, लेकिन इससे गुणवत्ता की हानि भी हो सकती है। इसलिए बिट-संख्या एक तकनीकी गुण है, गुणवत्ता की कोई सामान्य मुहर नहीं।

बिना मॉडल के एक संख्या-प्रयोग

इस विचार को समझने के लिए शुरुआत में एक स्वनिर्मित खिलौना-विधि पर्याप्त है। हम संख्याओं को ऋण एक से एक तक की सीमा में सीमित करते हैं और उन्हें समान रूप से वितरित स्तरों पर मैप करते हैं। सैद्धांतिक रूप से, चार स्तर दो बिट में समा जाते हैं, सोलह स्तर चार में। यह उदाहरण किसी विशिष्ट GGUF विधि को पुनः प्रस्तुत नहीं करता।

def runden_auf_stufen(wert, stufen):
    wert = max(-1.0, min(1.0, wert))
    index = round((wert + 1) * (stufen - 1) / 2)
    return 2 * index / (stufen - 1) - 1

werte = [-0.83, -0.12, 0.18, 0.76]
for stufen in (4, 16):
    angenaehert = [runden_auf_stufen(x, stufen) for x in werte]
    fehler = max(abs(a-b) for a, b in zip(werte, angenaehert))
    print(stufen, angenaehert, "largest deviation:", fehler)

छोटा Python उदाहरण चलाइए और फिर किसी स्तर-सीमा के निकट का कोई मान बदलिए। आप सीधे देख सकते हैं कि अलग-अलग इनपुट एक ही संग्रहीत स्तर पर कैसे पहुँच जाते हैं। यह संख्यात्मक विवरण की हानि है, किसी भाषा मॉडल के उत्तर में मापी गई त्रुटि नहीं।

वास्तविक क्वांटाइज़ेशन विधियाँ अधिक जटिल होती हैं। वे वेट्स को ब्लॉकों में संभाल सकती हैं और अतिरिक्त स्केलिंग जानकारी का उपयोग कर सकती हैं। केवल इसी कारण से, किसी मॉडल का आकार किसी एक बिट-आँकड़े से साधारण भंडारण-गणना के रूप में विश्वसनीय ढंग से नहीं निकाला जा सकता।

वास्तविक कार्य ही निर्णय करता है

मॉडल की तुलना से पहले ज्ञात आवश्यकताओं वाले पाँच छोटे कार्य तैयार कीजिए। एक नोट में प्रतिभागियों की संख्या है। दूसरे में एक निषेध है। तीसरा एक अपवाद का नाम लेता है। चौथे में परस्पर-विरोधी विवरण हैं, और पाँचवें में खोजी जा रही एक जानकारी मौजूद नहीं है।

प्रत्येक कार्य के लिए लिखिए कि क्या संरक्षित रहना चाहिए। उदाहरण के लिए: छह प्रतिभागी, सामग्री केवल अनुमोदन के बाद, अज्ञात तिथि अज्ञात ही रहती है। इस तरह आप अपने काम पर पड़ने वाले प्रभावों का मूल्यांकन करते हैं, न कि केवल यह कि उत्तर सुनने में अच्छा लगता है या नहीं।

एक छोटा संस्करण साधारण सारांशों के लिए अच्छा हो सकता है और किसी विशेष सीमांत कार्य में विफल हो सकता है। एक अकेली सफलता गुणवत्ता के बारे में कोई सामान्य कथन नहीं है। न ही हर भाषाई विचलन सार की दृष्टि से महत्वपूर्ण है; मायने रखती हैं पहले से निर्धारित आवश्यकताएँ।

निष्पक्ष तुलना यथासंभव कम बदलाव करती है

एक ही बेस रिविज़न के संस्करण चुनिए और प्रॉम्प्ट, रनटाइम तथा कार्य समान रखिए। यदि कोई भिन्न मॉडल-पीढ़ी शामिल होती है, तो एक भिन्न तुलना शुरू होती है। फ़ाइल नाम, स्रोत और चेकसम बाद में वास्तव में उपयोग किए गए आर्टिफ़ैक्ट्स को पहचानने में आपकी सहायता करते हैं।

सार संबंधी विचलनों के साथ-साथ वास्तव में मापी गई मेमोरी आवश्यकताओं और समय को भी नोट कीजिए। केवल वेट्स फ़ाइल पूरी रनटाइम आवश्यकताओं का वर्णन नहीं करती; आगे की प्रोसेसिंग और उपयोग किए गए संदर्भ को भी संसाधनों की आवश्यकता होती है। इसलिए दूसरों के डिवाइस-आँकड़ों को अपने कंप्यूटर पर लागू न कीजिए।

किसी एक कार्य पर आधारित आभासी रूप से सटीक रैंकिंग से भी बचिए। आपके अपने निर्णय के लिए, कभी-कभार खोया गया कोई प्रतिबंध कुछ सेकंड के अंतर से अधिक महत्वपूर्ण हो सकता है। मूल्यांकन-पत्र को ऐसी त्रुटियों को दृश्यमान रखना चाहिए।

छोटी फ़ाइल वास्तव में क्या संभव बनाती है

क्वांटाइज़ेशन वेट्स के संख्यात्मक निरूपण को बदलकर अतिरिक्त स्थानीय उपयोगों का मार्ग खोलता है। सही चुनाव संसाधनों और आपके कार्यों की वास्तविक सार संबंधी आवश्यकताओं के बीच एक संतुलन बना रहता है।

छोटा स्तर-प्रयोग बिना डाउनलोड, GPU या मॉडल कॉल के मूल सिद्धांत दिखाता है। संस्करणों की बाद की तुलना एक भिन्न स्तर की जाँच करती है: चुना गया निरूपण आपके वास्तविक अनुप्रयोग को कैसे प्रभावित करता है? यदि आप इन स्तरों को अलग रखते हैं, तो प्रभावशाली रूप से छोटी फ़ाइल एक जाँचने योग्य तकनीकी निर्णय बन जाती है।

स्रोत और स्थिति

स्रोत 25 अक्टूबर 2026 की स्थिति के अनुसार। llama.cpp quantize दस्तावेज़ीकरण।