छोटे और ऑन-डिवाइस मॉडल्सएडवांस्डपाठ 2336 मिनट का पाठ

छोटे मॉडल्स को सस्ते में सर्व करना

कई यूज़र्स को मॉडल सर्व करने में हर घंटे पैसे खर्च होते हैं। बैचिंग, कैशिंग, CPU इन्फेरेंस और ऑटोस्केलिंग सीखें, और यह पहचानना सीखें कि कब कोई होस्टेड API इस्तेमाल करना वाकई सस्ता पड़ता है।

✦ ट्यूटर से पूछें🧪 लैब · 35 min📝 पाठ का टेस्ट
पाठ वीडियो में

60 सेकंड में

छोटे मॉडल्स को सस्ते में सर्व करना

कई यूज़र्स को मॉडल सर्व करने में हर घंटे पैसे खर्च होते हैं। बैचिंग, कैशिंग, CPU इन्फेरेंस और ऑटोस्केलिंग सीखें, और यह पहचानना सीखें कि कब कोई होस्टेड API इस्तेमाल करना वाकई सस्ता…

1/5
आसान शब्दों में
चाय की टपरी पर एक बार में एक कप चाय नहीं उबाली जाती। वहाँ एक बड़ा पतीला चढ़ाया जाता है और एक साथ कई कप चाय डाली जाती है। जब कम लोग आते हैं, तो छोटा पतीला चढ़ाया जाता है। AI को सस्ते में सर्व करना भी इसी तरह काम करता है।
लैपटॉप पर एक व्यक्ति के लिए मॉडल चलाना आसान है। कई यूज़र्स के लिए इसे सर्व करना एक अलग समस्या है: सर्वर चाहे व्यस्त हो या खाली, आपको हर घंटे का पैसा देना पड़ता है। मकसद यह है कि हार्डवेयर के हर रुपये का ज़्यादा से ज़्यादा फ़ायदा उठाया जाए, और इसकी निष्पक्ष तुलना प्रति टोकन पैसे लेने वाले होस्टेड API से की जाए।

लागत घटाने के चार तरीके

तरीकायह क्या करता हैयह कब काम आता है
बैचिंगकई रिक्वेस्ट्स को एक साथ प्रोसेस करता है, ताकि हार्डवेयर लगातार व्यस्त रहेएक साथ कई यूज़र्स होने पर; कॉन्टिन्युअस बैचिंग के बारे में स्टेप 17 में बताया गया है
कैशिंगबार-बार आने वाले जवाबों या काम को सेव कर लेता है, ताकि उन्हें दोबारा प्रोसेस न करना पड़ेआम सवाल; हर रिक्वेस्ट पर वही लंबा सिस्टम प्रॉम्प्ट होना
CPU इन्फेरेंससाधारण CPU सर्वर्स पर छोटा क्वांटाइज़्ड मॉडल चलाता हैकम या स्थिर ट्रैफ़िक, छोटे मॉडल्स, ऐसे काम जहाँ थोड़ा धीमा जवाब भी चल जाए
ऑटोस्केलिंगव्यस्त होने पर सर्वर जोड़ता है और काम कम होने पर उन्हें हटा देता है, कभी-कभी शून्य तक भी ले जाता हैऐसा ट्रैफ़िक जो घटता-बढ़ता रहता है, जैसे परीक्षा का समय या त्योहारों की सेल

कैशिंग, दो तरह की

  • रिस्पॉन्स कैश: अगर वही सवाल दोबारा आता है (जैसे "लाइब्रेरी का समय क्या है?"), तो सेव किया हुआ जवाब लौटा दें। ऐसा सिर्फ़ उन्हीं जवाबों के लिए करें जो यूज़र पर निर्भर नहीं करते और अक्सर नहीं बदलते।
  • प्रीफ़िक्स या प्रॉम्प्ट कैश: कई रनटाइम्स प्रॉम्प्ट की लंबी, दोहराई जाने वाली शुरुआत (जैसे कि सिस्टम प्रॉम्प्ट) पर किए गए काम का दोबारा इस्तेमाल कर सकते हैं। इससे हर रिक्वेस्ट पर समय और कंप्यूट दोनों की बचत होती है। देखें कि आपका रनटाइम क्या सपोर्ट करता है।
सावधान रहें
रिस्पॉन्स कैश से कभी भी एक यूज़र का निजी जवाब किसी दूसरे यूज़र को न जाने दें। कैश की (key) में यूज़र या परमिशन लेवल शामिल करें, या फिर निजी जवाबों को बिल्कुल भी कैश न करें।

सेल्फ़-होस्टेड या होस्टेड API? हिसाब लगाएँ

होस्टेड API प्रति टोकन चार्ज करता है, इसलिए इस्तेमाल बढ़ने पर ही खर्च बढ़ता है और खाली रहने पर खर्च लगभग शून्य होता है। सेल्फ़-होस्टेड सर्वर पर हर घंटे लगभग उतना ही खर्च आता है चाहे वह व्यस्त हो या खाली, साथ ही आपकी टीम का समय भी लगता है। इसलिए कम ट्रैफ़िक में आमतौर पर API बेहतर होता है, और लगातार ज़्यादा ट्रैफ़िक में सेल्फ़-होस्टिंग फ़ायदेमंद हो सकती है।
Python: break-even between a hosted API and a self-hosted server (made-up numbers)python
# All prices below are MADE-UP examples for practice. Use real quotes for real decisions.
api_price_per_million_tokens = 50.0      # rupees, input and output combined, example only
server_cost_per_month = 20_000.0         # rupees, including storage and bandwidth, example only
ops_hours_per_month = 10                 # your team's time to run and update it
ops_cost_per_hour = 800.0                # rupees, example only

tokens_per_request = 1_500
self_hosted_monthly = server_cost_per_month + ops_hours_per_month * ops_cost_per_hour

for requests_per_day in (500, 5_000, 50_000):
    monthly_tokens = requests_per_day * 30 * tokens_per_request
    api_monthly = monthly_tokens / 1_000_000 * api_price_per_million_tokens
    cheaper = "API" if api_monthly < self_hosted_monthly else "self-hosted"
    print(f"{requests_per_day:>6} req/day: API Rs {api_monthly:,.0f} vs self-hosted Rs {self_hosted_monthly:,.0f} -> {cheaper}")
असली तुलना में कई और पहलू भी हैं: क्या एक सर्वर आपके पीक ट्रैफ़िक को संभाल सकता है, आपके टेस्ट सेट पर हर विकल्प से कैसी क्वालिटी मिलती है, और प्राइवेसी व डेटा रखने की जगह से जुड़ी क्या ज़रूरतें हैं? लेकिन यह सीधा-सा हिसाब भी कई गलत फ़ैसलों से बचा लेता है।

सस्ते में सर्व करने की चेकलिस्ट

  1. 1

    अपना ट्रैफ़िक मापें

    प्रति दिन रिक्वेस्ट्स, पीक पर प्रति मिनट रिक्वेस्ट्स, अंदर आने वाले और बाहर जाने वाले औसत टोकन।
  2. 2

    काम चला सकने वाला सबसे छोटा मॉडल चुनें

    पिछले पाठों के अपने टेस्ट सेट का इस्तेमाल करें।
  3. 3

    क्वांटाइज़ और कैश करें

    कम-बिट वाले वेट्स, प्रॉम्प्ट कैशिंग, और सुरक्षित दोहराए जाने वाले सवालों के लिए रिस्पॉन्स कैश।
  4. 4

    सीमाएँ तय करें

    अधिकतम इनपुट लंबाई, अधिकतम आउटपुट लंबाई, और प्रति-यूज़र रेट लिमिट।
  5. 5

    ज़रूरत के हिसाब से स्केल करें

    ऑटोस्केल करें, और अगर पहली रिक्वेस्ट में थोड़ी देरी स्वीकार्य हो, तो स्केल टू ज़ीरो पर विचार करें।
  6. 6

    हर कुछ महीनों में दोबारा जाँचें

    कीमतें, मॉडल्स और ट्रैफ़िक सब बदलते रहते हैं।
फ़िज़ूलखर्ची
  • दस यूज़र्स के लिए पूरी रात चलने वाला बड़ा GPU सर्वर
  • जवाब की लंबाई पर कोई सीमा न होना
  • बिना हिसाब लगाए "क्योंकि API महंगे हैं" सोचकर सेल्फ़-होस्टिंग चुन लेना
सस्ता और समझदारी भरा
  • कम ट्रैफ़िक होने पर होस्टेड API, और जब आँकड़े कहें तब सेल्फ़-होस्टिंग
  • छोटे, सीमित जवाब और बार-बार आने वाले सवालों को कैश करना
  • लिखित में लागत की तुलना, जिसे कीमतें बदलने पर अपडेट किया जाता रहे
नोट
स्केल टू ज़ीरो से पैसे बचते हैं, लेकिन शांत समय के बाद आने वाली पहली रिक्वेस्ट को मॉडल लोड होने तक इंतज़ार करना पड़ता है (एक "कोल्ड स्टार्ट")। ऐसे चैटबॉट के लिए जहाँ यूज़र्स तुरंत जवाब की उम्मीद करते हैं, व्यस्त घंटों के दौरान कम से कम एक छोटा सर्वर चालू (warm) रखें।
इसे आज़माएँ। कोड में दिए गए काल्पनिक नंबरों को किसी ऐसे प्रोजेक्ट के हिसाब से बदलें जिसे आप जानते हों। रोज़ाना कितनी रिक्वेस्ट्स पर सेल्फ़-होस्टिंग सस्ती पड़ने लगती है?

और देखें और पढ़ें

llama.cpp server (llama-server)ggml-org · reading

लैब

एक वास्तविक ऐप के लिए होस्टेड API और सेल्फ़-होस्टेड छोटे मॉडल के बीच लागत की तुलना।

~35 min

समस्या

ऐप: "एक कोचिंग संस्थान के लिए सवाल-जवाब करने वाला बॉट, जिसे छात्र ज़्यादातर शाम को और परीक्षा के दिनों में बहुत ज़्यादा इस्तेमाल करते हैं।"

  1. एक सामान्य महीने और परीक्षा वाले महीने के ट्रैफ़िक का अंदाज़ा लगाएँ: रोज़ाना रिक्वेस्ट्स, प्रति रिक्वेस्ट औसत टोकन, और पीक पर प्रति मिनट रिक्वेस्ट्स।
  2. एक होस्टेड API विकल्प और एक सर्वर विकल्प (क्लाउड CPU या GPU सर्वर) के लिए मौजूदा सार्वजनिक कीमतें पता करें। जिस तारीख को आपने चेक किया, वह तारीख लिखें। अगर कीमतें न मिलें, तो साफ़ तौर पर लेबल किए गए काल्पनिक नंबरों का इस्तेमाल करें।
  3. पाठ में दिए गए ब्रेक-ईवन स्क्रिप्ट को अपनी ज़रूरत के हिसाब से बदलें। अपनी टीम का समय जोड़ें। दोनों महीनों का हिसाब लगाएँ।
  4. लिखें कि आप किन तकनीकों का इस्तेमाल करेंगे: बैचिंग, कैशिंग, CPU इन्फेरेंस, ऑटोस्केलिंग, सीमाएँ। हर एक की वजह बताएँ।
  5. तीन वाक्यों में अपनी सलाह दें, जिसमें वह ट्रैफ़िक स्तर भी शामिल हो जिस पर आप विकल्प बदलेंगे।

प्रैक्टिस लैब

कोड में बदलाव करें और इसे रन करें। Python आपके ब्राउज़र में चलता है — हमारे सर्वर पर कुछ नहीं भेजा जाता।

आउटपुट

कोई आउटपुट नहीं। वैल्यूज़ देखने के लिए print(...) जोड़ें।

आपका काम तब पूरा होगा जब

कठिन सवाल

उत्तर देखने से पहले ख़ुद जवाब देने की कोशिश करें। अगर आप इनके जवाब दे सकते हैं, तो आप पाठ समझ गए हैं।

Q1परीक्षा के महीने में सेल्फ़-होस्टिंग सस्ती लगती है लेकिन सामान्य महीनों में ज़्यादा महंगी। कौन-से डिज़ाइन दोनों का सबसे अच्छा फ़ायदा दिला सकते हैं?दिखाएं

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

Q2बैच साइज़ दोगुना करने से हर रिक्वेस्ट सस्ती तो हो सकती है, लेकिन कुछ यूज़र्स को ज़्यादा इंतज़ार क्यों करना पड़ सकता है?दिखाएं

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

जारी रखने के लिए कृपया साइन इन करें।

अक्सर पूछे जाने वाले सवाल

क्या असली यूज़र्स के लिए CPU सर्विंग काफी है?

छोटे क्वांटाइज़्ड मॉडल्स, छोटे जवाबों और सीमित ट्रैफ़िक के लिए यह काफी हो सकती है। लंबे जवाबों या एक साथ कई यूज़र्स के लिए, प्रति रिक्वेस्ट के हिसाब से आमतौर पर GPU ज़्यादा किफ़ायती होता है। फ़ैसला लेने से पहले असली सर्वर पर स्पीड ज़रूर मापें।

"स्केल टू ज़ीरो" का क्या मतलब है?

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

लागत में अपनी टीम का समय क्यों शामिल करें?

किसी न किसी को सर्वर अपडेट करना होता है, सिक्योरिटी से जुड़ी कमियों को ठीक करना होता है, दिक्कतों पर नज़र रखनी होती है और मॉडल को अपग्रेड करना होता है। उस समय की अपनी एक असली लागत होती है, और API से तुलना करते समय अक्सर लोग इसी हिस्से को भूल जाते हैं।

क्या होस्टेड API की कीमतें स्थिर रहती हैं?

नहीं। कीमतें बदलती रहती हैं, अक्सर कम होती हैं, और नए सस्ते मॉडल्स आते रहते हैं। अपनी तुलना को एक छोटे स्क्रिप्ट या स्प्रेडशीट में रखें ताकि आप मौजूदा कीमतों के साथ इसे दोबारा चला सकें।

पाठ का टेस्ट

5 सवाल। पास होने और इस पाठ को पूरा करने के लिए 3 सही होने चाहिए (60%)।

टेस्ट देने और अपनी प्रोग्रेस सेव करने के लिए साइन इन करें