Self-hosted या API: adult image generation चलाने की असली लागत

Image generation में build-versus-buy की बात आम तौर पर GPU के प्रति घंटा दाम से शुरू होकर वहीं ख़त्म हो जाती है। वह संख्या असली है, और बजट की सबसे छोटी लाइन भी है। self-hosted pipeline में जो कुछ महँगा है वह ठीक वही हिस्सा है जो किराए के इनवॉइस पर दिखता ही नहीं।

Self-hosting में सचमुच क्या-क्या शामिल है

एक चलता हुआ pipeline models, custom nodes और weights का ग्राफ़ है — और इनमें से हर एक एक version है जो आपके नीचे से खिसक सकता है। एक node pack अपडेट होता है और किसी parameter का मतलब बदल जाता है। base model बदलता है और आपके सावधानी से ट्यून किए presets का चरित्र बदल जाता है। इसमें कुछ भी असाधारण नहीं; यह रोज़मर्रा है। इंजीनियरिंग की लागत pipeline एक बार बनाने में नहीं है, बल्कि नीचे का ecosystem हिलते रहने के बावजूद output को स्थिर रखने में है।

फिर capacity का सवाल है। जनरेशन स्वभाव से झटकेदार है: शाम और वीकेंड पर उछाल, कामकाजी दिनों की सुबह सुनसान। पीक के हिसाब से साइज़ करना यानी हफ़्ते के ज़्यादातर हिस्से में बेकार पड़े सिलिकॉन का भुगतान। औसत के हिसाब से साइज़ करना यानी यूज़र ठीक उसी समय क़तार में लगेंगे जब उन्हें सबसे ज़्यादा परवाह है। GPU autoscaling संभव है, पर एक ठंडे worker को कुछ भी परोसने से पहले दसियों गीगाबाइट weights लोड करने पड़ते हैं, इसलिए scale-up सेकंडों में नहीं, मिनटों में नापा जाता है।

वे लागतें जो कभी स्प्रेडशीट में नहीं आतीं

• On-call. शनिवार रात 3 बजे मरा हुआ GPU बॉक्स किसी की रातभर की ड्यूटी है, और image generation स्वभाव से रात और वीकेंड का workload है।
• Storage और retention. Inputs और outputs डिस्क पर जमा होते जाते हैं और चुपचाप ऐसी देनदारी बन जाते हैं जिसे कोई डिलीट नहीं कर रहा।
• Model drift. अपग्रेड के बाद presets की regression testing असली काम है, और हर अपग्रेड पर दोहराना पड़ता है।
• Queue engineering. Backpressure, retries, deduplication और crash के बाद रिकवरी — ये वही समस्याएँ हैं, चाहे GPU किराए पर लें या नहीं।
• सुरक्षा. खुला inference port वाला GPU host आकर्षक निशाना है, और इसमें लगा सॉफ़्टवेयर खुले इंटरनेट के शत्रुतापूर्ण माहौल को ध्यान में रखकर नहीं लिखा गया।

Self-hosting सचमुच कहाँ जीतता है

यह एकतरफ़ा बहस नहीं है। अपना pipeline तब चलाइए जब pipeline ही प्रोडक्ट है — जब आप अपने models ट्रेन या fine-tune कर रहे हों, जब वह ख़ास ग्राफ़ ही आपका अंतर हो, या जब नियमन आपको प्रोसेसिंग अपनी नियंत्रित इंफ़्रा के भीतर रखने को बाध्य करता हो। स्थिर, ऊँचा, अनुमानित वॉल्यूम भी गणित बदल देता है: चौबीसों घंटे संतृप्त चलती GPU प्रति इमेज per-call दाम से सस्ती पड़ती है।

जिस स्थिति से सावधान रहना चाहिए वह बीच की है: मध्यम वॉल्यूम, झटकेदार माँग, छोटी टीम, और ऐसा pipeline जो साधन है, साध्य नहीं। यह संयोजन self-hosting की पूरी परिचालन लागत चुकाता है और उसका लगभग कोई फ़ायदा नहीं पाता।

API कहाँ जीतती है

API capacity की समस्या को बजट की एक लाइन में बदल देती है। न बेकार पड़ा सिलिकॉन, न cold-start की इंजीनियरिंग, न अपग्रेड वाला वीकेंड, न हार्डवेयर के लिए on-call रोटेशन। आपका इंटीग्रेशन चार HTTP कॉल बन जाता है, और वॉल्यूम का सवाल किसी और की परिचालन समस्या।

यह time to market को भी हफ़्तों से घटाकर एक दोपहर कर देता है। जिस फ़ीचर को आप अभी validate ही कर रहे हैं, उसके लिए यह unit economics से ज़्यादा मायने रखता है: एक दिन में लॉन्च करके यह जान लेना कि यूज़र इसे नहीं चाहते, GPU fleet खड़ा करने के बाद वही बात जानने से कहीं सस्ता नतीजा है।

पाँच मिनट में लिया जाने वाला निर्णय

1. क्या pipeline ख़ुद आपका प्रोडक्ट है? अगर हाँ, तो बनाइए।
2. क्या आपका वॉल्यूम इतना ऊँचा, स्थिर और अनुमानित है कि GPU सचमुच संतृप्त रहे? अगर हाँ, तो बनाना फ़ायदे में आने लगता है।
3. क्या कोई है जो GPU on-call की ज़िम्मेदारी लेगा, और क्या उसे यह पता है? अगर नहीं, तो ख़रीदिए।
4. क्या आप अब भी फ़ीचर validate कर रहे हैं? अभी ख़रीदिए, माँग का वक्र असली होने पर दोबारा सोचिए।

वह hybrid जिसका कोई ज़िक्र नहीं करता

ये विकल्प परस्पर अनन्य नहीं हैं। एक आम और समझदार व्यवस्था यह है: अनुमान से बाहर के सार्वजनिक ट्रैफ़िक के लिए API, और स्थिर आंतरिक baseline सोखने के लिए अपना हार्डवेयर। इससे migration की खाई भी मिट जाती है: इंटीग्रेशन को एक ही HTTP सीमा के पीछे रखने का मतलब है कि बाद में दोनों के बीच जाना configuration बदलना है, rewrite नहीं।

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