Written with AI assistance from the source video. The video is the authority.
Log in to leave a comment
No posts yet
DeepSeek Chat, GPT-4o-mini, और Gemini 2.5 Flash जैसे कम लागत वाले मॉडल का उपयोग करने से API लागत निश्चित रूप से कम हो जाती है। समस्या यह है कि जैसे ही ट्रैफ़िक थोड़ा बढ़ता है, प्रतिक्रिया का समय 10 सेकंड से बढ़कर 60 सेकंड हो जाता है। जब एक मानक सिंक्रोनस HTTP अनुरोध संरचना में इस तरह की देरी होती है, तो सर्वर वर्कर प्रक्रियाएं प्रतीक्षा समय में बंध कर ब्लॉक हो जाती हैं, और फ्रंटएंड टाइमआउट त्रुटियों के साथ क्रैश हो जाता है।
अकेले साइड प्रोजेक्ट बनाने वाले या सीमित बजट वाले एकल डेवलपर के लिए सर्वर क्रैश होना घातक है। हालाँकि, आप महंगे मॉडल पर वापस नहीं लौट सकते। आपको एक एसिंक्रोनस डीकपलिंग आर्किटेक्चर खुद बनाना होगा जो क्लाइंट और LLM के बीच सीधे सिंक्रोनस कनेक्शन को काट दे और मॉडल के खराब आउटपुट को फ्रंटएंड तक सुरक्षित रूप से पहुंचाए।
वेब सर्वर को LLM के अनुमान (inference) के पूरा होने का सीधे इंतजार नहीं करना चाहिए। FastAPI को API गेटवे के रूप में उपयोग किया जाना चाहिए, और अनुरोध स्वीकृति और वास्तविक अनुमान संचालन को पूरी तरह से अलग करने के लिए Redis मैसेज ब्रोकर और Celery वितरित वर्कर को जोड़ा जाना चाहिए। जब कोई उपयोगकर्ता अनुरोध भेजता है, तो सर्वर तुरंत केवल जॉब ID लौटाता है और कनेक्शन काट देता है।
यदि आप डिफ़ॉल्ट सेटिंग्स के साथ Celery चलाते हैं, तो वर्कर के क्रैश होने पर नौकरियां खो सकती हैं या डुप्लिकेट रूप से निष्पादित हो सकती हैं। LLM अनुमान की लंबी कार्य अवधि को संभालने के लिए, visibility_timeout को 3600 सेकंड तक बढ़ाना और task_acks_late = True निर्दिष्ट करना आवश्यक है ताकि केवल तभी पावती (acknowledgment) भेजी जाए जब कार्य सामान्य रूप से समाप्त हो जाए। यह सेट करना भी अनिवार्य है कि worker_prefetch_multiplier = 1 ताकि एक अकेला वर्कर एक साथ कई भारी कार्यों को पकड़कर बॉటిलनेक न बनाए।
