AI में optimization वास्तव में तीन अलग-अलग disciplines हैं जो एक नाम साझा करते हैं। प्रशिक्षण optimization सीखने की प्रक्रिया को तेज़ और सस्ता बनाने के बारे में है। Inference optimization प्रशिक्षित मॉडल को तेज़ी से प्रतिक्रिया देने और कम हार्डवेयर का उपयोग करने के बारे में है। Serving optimization कई समवर्ती उपयोगकर्ताओं को कुशलता से संभालने के बारे में है। अधिकांश लोग इन्हें मिला देते हैं क्योंकि तकनीकें कभी-कभी overlap होती हैं, लेकिन लक्ष्य और बाधाएँ अलग हैं। gradient checkpointing जैसा एक प्रशिक्षण optimization मेमोरी के लिए compute समय का व्यापार करता है — आप उन्हें संग्रहीत करने के बजाय backward pass के दौरान activations को फिर से गणना करते हैं। यह तब समझ में आता है जब आप एक बहु-दिवसीय प्रशिक्षण रन के दौरान GPU-मेमोरी-बाध्य होते हैं। यह inference के दौरान कोई समझ नहीं देगा, जहाँ कोई backward pass नहीं है। यह समझना कि आप किस चरण के लिए optimize कर रहे हैं, और आप क्या के लिए क्या व्यापार कर रहे हैं, यहाँ अच्छे निर्णय लेने का आधार है।
यदि आप केवल एक optimization तकनीक सीख सकते थे, तो quantization चुनने वाली होगी। विचार सरल है: मॉडलों को उच्च-परिशुद्धता floating point (आम तौर पर bfloat16, जो प्रति parameter 16 bits का उपयोग करता है) में प्रशिक्षित किया जाता है, लेकिन वे catastrophic गुणवत्ता हानि के बिना बहुत कम परिशुद्धता में चल सकते हैं। bfloat16 में एक 14-अरब-parameter मॉडल लगभग 28 GB VRAM लेता है। इसे 4-bit में quantize करें (llama.cpp के notation में Q4_K_M) और यह 9 GB से कम में फ़िट हो जाता है — अचानक यह एक एकल उपभोक्ता GPU पर चलता है। गुणवत्ता का व्यापार-बंद मौजूद है लेकिन आपकी अपेक्षा से छोटा है। GPTQ, AWQ, और GGUF जैसी आधुनिक quantization विधियाँ वास्तविक डेटा के विरुद्ध calibrated हैं इसलिए सबसे महत्वपूर्ण weights उच्च परिशुद्धता रखते हैं। blind tests में, अधिकांश उपयोगकर्ता रोज़मर्रा के कार्यों के लिए एक पूर्ण-परिशुद्धता मॉडल और इसके 4-bit quantized संस्करण के बीच अंतर नहीं बता सकते। अंतर edge cases पर दिखाई देता है — जटिल reasoning chains, niche तथ्यात्मक ज्ञान, बहुभाषी कार्य — लेकिन अधिकांश production use cases के लिए, quantization मुफ़्त प्रदर्शन है।
Quantization से परे, सबसे बड़े inference speedups इस बात से आते हैं कि आप मॉडल को कैसे shrink करते हैं उसके बजाय कि आप अनुरोधों का प्रबंधन कैसे करते हैं। Continuous batching — vLLM और TensorRT-LLM द्वारा उपयोग किया गया दृष्टिकोण — server को एक साथ कई अनुरोधों को प्रोसेस करने देता है, GPU idle cycles को भरता है जो अन्यथा बर्बाद होते जब एक अनुरोध अपने अगले token के लिए प्रतीक्षा करता है। KV-cache optimization (जैसे PagedAttention) key-value cache के मेमोरी overhead को sequence लंबाई के साथ रैखिक रूप से बढ़ने से रोकता है, जो लंबे-context applications के लिए महत्वपूर्ण है। Speculative decoding कई candidate tokens उत्पन्न करने के लिए एक छोटे, तेज़ "draft" मॉडल का उपयोग करता है, फिर बड़ा मॉडल उन्हें एक एकल forward pass में verify करता है — यदि draft मॉडल सही अनुमान लगाता है (जो यह अक्सर पूर्वानुमेय टेक्स्ट के लिए करता है), तो आपको एक बड़े-मॉडल call की लागत पर कई tokens मिलते हैं। ये तकनीकें संयुक्त होती हैं। continuous batching, quantization, और speculative decoding का उपयोग करने वाला एक well-tuned serving stack एक naive कार्यान्वयन के पाँच से दस गुना throughput पर वही मॉडल serve कर सकता है।
अधिकांश टीमों के लिए, optimization अंततः प्रति query लागत के बारे में है। A100s के एक cluster पर 70B मॉडल चलाना गंभीर पैसा खर्च करता है — cloud क़ीमतों पर लगभग $8–$15 प्रति GPU प्रति घंटा। Optimization यह निर्धारित करता है कि वह cluster प्रति सेकंड 50 अनुरोध संभालता है या 500। Distillation एक और lever है: आप अपने विशिष्ट कार्य पर एक बड़े "teacher" मॉडल के आउटपुट की नक़ल करने के लिए एक छोटे "student" मॉडल को प्रशिक्षित करते हैं। एक distilled 8B मॉडल जो आपके विशेष use case पर 70B मॉडल की 90% गुणवत्ता से मेल खाता है, चलाने में एक अंश की लागत लेता है। कई टीमें जो व्यावहारिक workflow का पालन करती हैं वह है: API के माध्यम से उपलब्ध सबसे बड़े मॉडल के साथ prototype करें, मापें कि आपको वास्तव में किस गुणवत्ता स्तर की आवश्यकता है, फिर पीछे की ओर काम करें — quantize करें, distill करें, या एक छोटे मॉडल पर स्विच करें जब तक कि आप उस मधुर बिंदु तक नहीं पहुँचते जहाँ गुणवत्ता स्वीकार्य है और लागत टिकाऊ है। वे टीमें जो इस प्रक्रिया को छोड़ देती हैं और सीधे production में सबसे बड़े मॉडल पर कूद जाती हैं, लगभग हमेशा अधिक खर्च कर रही हैं।