Productionizing LLM Gateways: Architecture, Tradeoffs and Hard Lessons — Kanish Manuja, Twilio
AAI Engineer
Computing/SoftwareManagementInternet Technology
Transcript
00:00:00मैं गणेश मनुजा हूँ। मैं ट्वायिलियो में प्रिंसिपल इंजीनियर हूँ। आइए हाथ उठाकर एक छोटी सी गिनती से शुरुआत करते हैं।
00:00:20यहाँ किस-किस ने यह संदेश देखा है, कुछ गलत हो गया है, कृपया पुनः प्रयास करें?
00:00:27खैर, हमारे पास कुछ भाग्यशाली लोग हैं और कुछ ऐसे हैं जिन्होंने अच्छा दोपहर का भोजन किया है।
00:00:33तो, उस साधारण संदेश के पीछे वास्तव में एक बहुत ही जटिल प्रणाली है जो मॉडल प्रदाताओं के बंद होने के बावजूद आपको वह संदेश दिखाती है।
00:00:45और यही वह चीज़ है जिसे आज हम प्रोडक्शन में उतारने जा रहे हैं या आज उस पर चर्चा करने वाले हैं।
00:00:50तो, एलएलएम गेटवे क्या है?
00:00:52एक एलएलएम गेटवे आपके ऐप्स और उनके पीछे के मॉडल प्रदाताओं के बीच एक प्रवेश बिंदु या मिडलवेयर है।
00:00:58यह कई सारे काम करता है, जैसे रूटिंग, प्रमाणीकरण, फ़ॉलबैक, रेट लिमिट, और हर तरह का गवर्नेंस जिसके बारे में आप सोच सकते हैं।
00:01:08और गेटवे के ठीक केंद्र में चार चीज़ों के बीच एक संघर्ष होता है।
00:01:13यह उपलब्धता, विलंबता (लेटेंसी), सुरक्षा उपाय (गार्डरेल्स), और लागत है।
00:01:18प्रणाली के खराब होने की स्थिति में, आप इन चारों को अधिकतम नहीं कर सकते।
00:01:22आपको चुनना होगा कि आप क्या चाहते हैं।
00:01:25इसलिए, इस चर्चा के माध्यम से, यदि आप एलएलएम गेटवे का उपयोग करते हैं, तो मैं आपके उपयोग के मामले के लिए वह ट्रेड-ऑफ करने में आपकी सहायता करना चाहता हूं।
00:01:35और यदि आप एक गेटवे डिज़ाइन करते हैं, तो मैं चाहता हूँ कि आप अपने कॉलर और ग्राहकों को वे विकल्प प्रदान करें ताकि आपके ग्राहक खुश रहें.
00:01:46उपलब्धता से शुरुआत करते हैं.
00:01:50यदि आपके पास एक ही मॉडल प्रदाता है, तो उनकी सीमा ही आपकी सीमा है.
00:01:56उनकी खराबी आपकी खराबी है.
00:02:03तो, सामान्य सॉफ्टवेयर इंजीनियरिंग में, अविश्वसनीय निर्भरता से निपटने का तरीका फिर से प्रयास करना है.
00:02:11घातीय बैकऑफ़ और जिटर के साथ दोबारा प्रयास करना.
00:02:15और जब वह सब विफल हो जाता है, तो आपके पास एक सर्किट ब्रेकर होता है जो पर्याप्त विफलताएँ देखने के बाद ट्रिप हो जाता है, और आप उस चीज़ को कॉल करना बंद कर देते हैं.
00:02:24यह एलएलएम के लिए पर्याप्त नहीं है.
00:02:26एलएलएम आपके तेज़, सस्ते एपीआई की तुलना में बहुत अलग हैं जिन पर आप दोबारा प्रयास करते हैं.
00:02:32एलएलएम एपीआई पर दोबारा प्रयास करने से आपकी विलंबता बजट में तेजी से कमी आती है.
00:02:38और इसके अलावा, जब आपके पास रूट करने के लिए कोई अन्य पूरी तरह से अच्छा मॉडल प्रदाता हो, तो सर्किट ब्रेकर को ट्रिप करना समझ में नहीं आता है.
00:02:47आपको दूसरे मॉडल प्रदाता का उपयोग करना चाहिए.
00:02:48और तीसरा, जैसा कि मैंने कहा, कॉल धीमी और महंगी होती हैं.
00:02:53इसलिए, बिना सोचे-समझे दोबारा प्रयास करने से आपकी लागत और आपकी टेल लेटेंसी कई गुना बढ़ जाती है.
00:02:58तो, यहाँ एक बेहतर विचार क्या है?
00:03:02यह वास्तव में प्रति अनुरोध फ़ॉलबैक है.
00:03:05इसका मतलब यह है कि यदि मॉडल प्रदाता ए के लिए आपका अनुरोध विफल हो जाता है, तो आप वास्तव में मॉडल प्रदाता ए और फिर अनुक्रम में, मॉडल प्रदाता बी को आज़मा सकते हैं.
00:03:14यहाँ विचार करने के लिए एक अन्य विकल्प यह है कि आप दोनों प्रदाताओं को समानांतर में अनुरोध भेज सकते हैं, लेकिन यह तभी है जब आप लेटेंसी को लेकर अत्यधिक जुनूनी हैं, क्योंकि इससे आपकी लागत दोगुनी हो जाएगी.
00:03:26कुछ समान सर्किट ब्रेकिंग पैटर्न यहाँ एलएलएम पर भी लागू होते हैं.
00:03:32यदि आप जानते हैं कि आपका प्राथमिक प्रदाता कुछ समय से विफल हो रहा है, तो इसे फिर से आज़माने का कोई मतलब नहीं है.
00:03:40आप इसे लोड बैलेंसर या अपने अनुरोध पथ से बाहर निकालते हैं और कूल डाउन में रखते हैं और फिर, कुछ मिनट बीत जाने के बाद, इसे वापस लाने का प्रयास करते हैं.
00:03:51एक दिलचस्प विकल्प जो आपको यहाँ चुनना है वह यह है कि आपकी विफलता की गिनती कहाँ रहती है.
00:03:59आप यह तय कर सकते हैं कि विफलता की गिनती आपके ट्रैफ़िक को परोसने वाले इंस्टेंस पर मेमोरी में रहे, या आपके पास साझा जानकारी हो जहाँ आपकी विफलता की गिनती पूरे बेड़े में साझा की जाती है.
00:04:12इसमें कुछ कमियाँ और खूबियाँ हैं.
00:04:14यदि आप त्वरित फ़ैलओवर चाहते हैं, तो फ्लीट-व्यापी मदद करता है.
00:04:19और इंस्टेंस के साथ, स्थानीय स्थिति काउंटर के साथ, जो समस्या आपके सामने आती है वह यह है कि जब भी आप अपने तैनाती का आकार बदलते हैं, तो आपका कॉन्फ़िगरेशन और आपकी अपेक्षाएँ बदल जाती हैं.
00:04:30तो यह विचार करने योग्य बात है.
00:04:34उस साफ आरेख ने वास्तव में आपको वे अन्य कमियाँ नहीं दिखाईं जिन पर मैं चर्चा करने जा रहा हूँ.
00:04:39तो फ़ॉलबैक पारदर्शी नहीं होते हैं.
00:04:41जबकि उद्योग एक ओपनएआई एपीआई-संगत प्रारूप पर अभिसरण कर रहा है, मैं कहूंगा कि अभी भी बारीकियां हैं.
00:04:49इसलिए आपको वास्तव में अपने फ़ॉलबैक का अच्छी तरह से परीक्षण करने की आवश्यकता है.
00:04:52उनमें आपके टूल कॉलिंग स्कीमा, टोकन सीमा, रुकने के कारणों और अन्य चीज़ों में अंतर हो सकता है.
00:04:58तो एलएलएम गेटवे के साथ, आपके पास एक सामान्यीकरण परत हो सकती है जो यह सुनिश्चित कर सकती है कि आप क्रॉस-प्रदाता फ़ॉलबैक भी कर सकें.
00:05:08दूसरी बात स्ट्रीमिंग है.
00:05:15तो अनिवार्य रूप से, कोई भी अपने सामने पाठ की दीवार प्रकट होने के लिए 30 सेकंड तक इंतजार नहीं करना चाहता है.
00:05:22इसलिए ऐसे उपयोग के मामले हैं जहाँ स्ट्रीमिंग की बिल्कुल आवश्यकता होती है.
00:05:26लेकिन यह एक कीमत पर आता है.
00:05:27आप अपने नियंत्रण छोड़ देते हैं.
00:05:29आप ऐसा नहीं कर सकते -- एक बार जब आपने प्रदाता ए के साथ जाने का फैसला कर लिया है, तो आपको प्रदाता ए के साथ जारी रखना होगा.
00:05:36आप स्ट्रीमिंग के बीच में प्रदाताओं को नहीं बदल सकते.
00:05:39जो भी क्लाइंट को भेजा जा चुका है, वह हो चुका है.
00:05:42और यही वह जगह है जहाँ कुछ गलत हो गया संदेश आता है.
00:05:46वह वही है जो आपको दिखाई देता है.
00:05:48यह आलस्य के कारण नहीं है.
00:05:49यह डिज़ाइन के अनुसार है जो आपको दिखाई देता है.
00:05:52और यह उन समझौतों में से एक है.
00:05:54मैं एक और बात बताना चाहूँगा जहाँ मैंने टीमों को बार-बार गलती करते देखा है.
00:06:00वे वास्तव में अपने प्राथमिक प्रदाताओं का प्रावधान करते हैं और उनका अच्छी तरह से परीक्षण करते हैं.
00:06:05लेकिन दूसरे प्रदाता, फ़ॉलबैक प्रदाता को जरूरी नहीं कि उतना ही प्यार मिले.
00:06:11और मैं यह तर्क दूंगा कि आपके थ्रूपुट या आपकी क्षमता या आपका हेडरूम दूसरे प्रदाता या फ़ॉलबैक प्रदाता के लिए और भी अधिक होना चाहिए.
00:06:21क्योंकि यह आपकी रक्षा की अंतिम पंक्ति है.
00:06:23यदि वह नीचे जाता है, तो आपका आवेदन नीचे चला जाता है.
00:06:29आइए लेटेंसी पर चर्चा करें.
00:06:31उपलब्धता विफलताएं आपके सामने होती हैं.
00:06:34वे विफल हो जाती हैं.
00:06:36आप सतर्क हो जाते हैं.
00:06:37आपको पेज किया जाता है.
00:06:38लेकिन उच्च लेटेंसी शांत हो सकती हैं.
00:06:42और उन्हें केवल उपलब्धता के लिए आपकी सेवाओं को ट्यून करने की तुलना में अधिक प्यार मिलने की आवश्यकता है.
00:06:49ध्यान देने योग्य एक बात.
00:06:54एक गेटवे मिश्रित वर्कलोड चला सकता है.
00:06:58और आपके पास एम्बेडिंग अनुरोध हो सकते हैं जिनमें एक सेकंड से भी कम समय लगता है.
00:07:04आपके पास वर्गीकरण अनुरोध हो सकते हैं जिनमें एक सेकंड से कम समय लगता है.
00:07:07आपके पास चैट अनुरोध हैं जिनमें तीन सेकंड लगते हैं.
00:07:10और तर्क अनुरोधों में बहुत समय लगता है.
00:07:13हाथों की एक त्वरित गिनती.
00:07:15यदि आप अपनी पूरी सेवा के लिए अपनी कुल लेटेंसी को मापते हैं, तो हाथों की एक त्वरित गिनती दिखाएं.
00:07:20खैर, वह एक ट्रिक्स प्रश्न था.
00:07:23क्षमा करें.
00:07:24आपको नहीं करना चाहिए.
00:07:25यह समझ में नहीं आता है.
00:07:26यह झूठ है.
00:07:27आपको गेटवे-व्यापी संख्या के बजाय प्रति मॉडल प्रति रूट अपने P99 को ट्रैक करना चाहिए.
00:07:32गेटवे-व्यापी संख्या समझ में नहीं आती है, खासकर यदि आप मिश्रित वर्कलोड चला रहे हैं.
00:07:36और मुझे उम्मीद है कि आप नहीं हैं, उन लोगों के लिए जिन्होंने अपना हाथ उठाया है.
00:07:40एक और चीज़ जो वास्तव में कर सकती है -- मैं इस पर पर्याप्त जोर नहीं दे सकता कि आप प्रति मॉडल क्लास प्रति रूट पर टाइमआउट सेट करें.
00:07:49यहीं पर -- यह आपके साइलेंट आउटेज का नंबर एक मूल कारण है.
00:07:54यदि आपके पास टाइमआउट नहीं है, तो आपका गेटवे सोचता है कि आपके अनुरोध को खुशी से परोसा जा रहा है, जबकि ऐसा नहीं है.
00:08:00और मैं आपको लेटेंसी के लिए विशेष रूप से इस संदेश के साथ छोड़ दूंगा.
00:08:05एक रीज़निंग मॉडल का सामान्य वास्तव में एक चैट मॉडल का आउटेज है.
00:08:09इसलिए आपको निश्चित रूप से प्रति रूट लेटेंसी को ट्रैक करने की आवश्यकता है.
00:08:13ठीक है, यह सबसे दर्दनाक है या वह स्लाइड है जिसने मुझे सबसे ज्यादा डराया है, जो कि रीज़निंग और राउटर मॉडल हैं.
00:08:24तो यहीं पर, वास्तव में, लेटेंसी अप्रत्याशित है.
00:08:29और रीज़निंग मॉडल, वे आपको नहीं देते हैं -- वे अत्यधिक अनिश्चित हैं, आपके सामान्य मॉडल की तुलना में अधिक अनिश्चित हैं.
00:08:40आप कई मामलों में तापमान को शून्य पर सेट नहीं कर सकते हैं.
00:08:43और वही संकेत दो सेकंड से लेकर 60 सेकंड तक कहीं भी ले सकता है.
00:08:48और हमने इसे प्रोडक्शन में देखा है, जहाँ P99 बिना किसी अच्छे कारण के अचानक 60 सेकंड तक पहुँच गया.
00:08:53तो यह है -- हालांकि इसका कोई जादुई समाधान नहीं है, मैं यह अनुशंसा करूंगा कि आप कम से कम प्रति रूट रीज़निंग स्तर को ठीक करने से शुरुआत करें.
00:09:03तो राउटर मॉडल के साथ, वे उस अमूर्तता को आपके पीछे छिपा लेते हैं.
00:09:08जैसे, वे चुनते हैं कि कौन से मॉडल चलाने हैं.
00:09:11और मैं इसकी अत्यधिक अनुशंसा करूंगा कि आप कम से कम उतना ही प्रयास करें -- आप एक अनिश्चित प्रणाली के साथ अनुरोधों को यथासंभव निश्चित बनाते हैं.
00:09:23एक अन्य विचार पूंछ को हेッジ करना है.
00:09:26आप कर सकते हैं -- यदि आपके प्राथमिक अनुरोध ने वास्तव में आपकी लेटेंसी बजट का P90 उपभोग कर लिया है, तो आप दूसरा अनुरोध फायर कर सकते हैं.
00:09:37यह पूंछ को हेッジ कर सकता है -- यह वास्तव में आपकी सेवाओं के लिए P99 पूंछ को हेッジ कर सकता है.
00:09:44ठीक है, यह मेरे पसंदीदा में से एक है.
00:09:47अपने मॉडल को सुरक्षित रखने के लिए, आपको गार्डरेल की आवश्यकता है.
00:09:53और इसके साथ, आपकी सेवाओं को प्रॉम्प्ट इंजेक्शन हमलों से बचाने, PII फ़िल्टर को जगह में रखने, विषाक्तता फ़िल्टर रखने, एलएम को आपके ग्राहकों को गाली देने से रोकने के लिए गार्डरेल आवश्यक हैं.
00:10:08वे सभी अच्छी बातें.
00:10:11लेकिन एक मॉडल प्रदाता की तरह, इसमें भी कुछ कमियाँ हैं.
00:10:15गार्डरेल किसी अन्य सेवा की तरह हैं.
00:10:18जो नीचे जा सकती है.
00:10:19जो अविश्वसनीय हो सकती है.
00:10:21और यहीं पर आपको चुनने की आवश्यकता है.
00:10:24क्या आप ओपन फेल करते हैं या आप क्लोज फेल करते हैं?
00:10:27जब मैं फेल ओपन कहता हूँ, तो आप अभी भी अनुरोध को पूरा कर सकते हैं भले ही आपके गार्डरेल नीचे हों.
00:10:32फेल क्लोज, आप अनुरोध को ब्लॉक करते हैं और कहते हैं, अरे, मैं उपलब्ध नहीं हूँ.
00:10:36एक हद तक यह उपलब्धता और सुरक्षा के बीच का समझौता है।
00:10:41हालाँकि इसका कोई सार्वभौमिक उत्तर नहीं है, यह वास्तव में आपके उपयोग के मामले पर निर्भर करता है।
00:10:45आप तय कर सकते हैं, जैसे कि टॉक्सिसिटी फ़िल्टर, यदि यह चालू नहीं है, तब भी आप उस अनुरोध को पूरा कर सकते हैं।
00:10:53इसलिए डिफ़ॉल्ट विकल्प वह सबसे खराब स्थिति होनी चाहिए जिसके साथ आप काम चला सकें।
00:11:02आप वास्तव में कुछ ऐसी चीजें कर सकते हैं जो गार्डरेल्स के काम न करने और उनकी अविश्वसनीयता को प्रबंधित करने की स्थिति में आपके सिस्टम के व्यवहार को बेहतर बना सकती हैं।
00:11:17तो सबसे पहला है टाइम बजट।
00:11:20आपका अनुरोध कभी भी आपके गार्डरेल के समय से बंधा नहीं होना चाहिए।
00:11:25यह हमेशा LLM होना चाहिए जो गति निर्धारित करने वाला चरण हो।
00:11:29इसलिए सुनिश्चित करें कि आपके पास टाइमआउट मौजूद हैं और वे गार्डरेल एक विशिष्ट समय बजट के साथ चलते हैं।
00:11:38एक अन्य महत्वपूर्ण चीज़ फॉलबैक है।
00:11:40आपने सुना होगा—आप शायद जानते हैं, और मैंने इस बारे में बात की है, हम हमेशा मॉडल प्रदाताओं के संबंध में फॉलबैक पर चर्चा करते हैं।
00:11:47लेकिन गार्डरेल भी महत्वपूर्ण सेवाएं हैं, जहाँ आप फॉलबैक पर विचार कर सकते हैं, माध्यमिक प्रदाता रख सकते हैं, माध्यमिक जाँच कर सकते हैं, जब कोई गार्डरेल प्रदाता डाउन हो तो अपनी सेवा को चालू रखने के लिए निर्णयों को कैश कर सकते हैं।
00:12:03गार्डरेल्स के संबंध में एक और दिलचस्प विकल्प जो सामने आता है वह है गार्डरेल्स की नियुक्ति।
00:12:10आम तौर पर, आप गार्डरेल को तीन तरीकों से रख सकते हैं।
00:12:15आपके पास एक प्रीहुक हो सकता है जो चलता है - जहाँ गार्डरेल वास्तव में इनपुट पर चलता है।
00:12:19आप कर सकते हैं - और यह शायद सबसे सुरक्षित है, लेकिन यह आपके अनुरोधों में क्रमिक विलंबता जोड़ता है।
00:12:26दूसरा समानांतर में है।
00:12:29यह मेरे पसंदीदा में से एक है, लेकिन बस यह बताने के लिए कि स्ट्रीमिंग यहाँ समानांतर के साथ अच्छी तरह से काम नहीं करेगी।
00:12:35इसलिए यदि आप विशेष रूप से संरचित आउटपुट तैयार कर रहे हैं, तो कृपया उन्हें स्ट्रीम न करें।
00:12:40अपनी विलंबता को बचाने की कोशिश करें और अपने संरचित आउटपुट के लिए इन गार्डरेल्स को समवर्ती रूप से चलाएं।
00:12:46एक अन्य पोस्ट हुक है।
00:12:48ये आउटपुट मॉनिटरिंग, आपके आउटपुट की ऑडिटिंग और इसी तरह के अन्य कार्यों के लिए सबसे अच्छे हैं।
00:12:58तो, अब तक, हम सभी ने—मैंने उन सभी चीज़ों पर चर्चा की है जो हमारी निर्भरता के संबंध में गलत हो सकती हैं।
00:13:06हमने इस पर चर्चा नहीं की है कि हम वास्तव में स्वयं अनुरोध पथ में एक और निर्भरता जोड़ रहे हैं, जो कि केंद्रीय है - या जो स्वयं LLM गेटवे है।
00:13:15कुछ ऐसी चीजें हैं जहाँ हमें नुकसान उठाना पड़ा है, और हमने कुछ सबक सीखे हैं जिन्हें मैं आपके साथ साझा करना चाहता हूँ यदि आप LLM गेटवे पर काम कर रहे हैं या उसका उपयोग कर रहे हैं।
00:13:25एक साझा सीमाएँ हैं।
00:13:28सुनिश्चित करें कि आपकी API कुंजियाँ प्रति मार्ग, प्रति उपयोग के मामले के अनुसार अलग की गई हैं, सबसे दानेदार संभव तरीके से - सबसे दानेदार चीज़ तक जिसकी आप कल्पना कर सकते हैं।
00:13:40एक शोरगुल वाले टेनेंट का होना यहाँ सबसे बड़ी समस्याओं में से एक हो सकता है।
00:13:47दूसरी चीज़ लोड शेडिंग है।
00:13:50यह एक ऐसी सुविधा है जिसे आपको अपनी रनबुक, गेम डेज़ के हिस्से के रूप में सुनिश्चित करना चाहिए कि आप जिस गेटवे का उपयोग कर रहे हैं वह लोड शेडिंग का समर्थन करता है।
00:13:59क्योंकि जब आपके पास रीट्राई स्टॉर्म होता है, तो केवल स्केल आउट करना वास्तव में कठिन हो जाता है।
00:14:03आप उन सेवाओं को आसानी से स्केल आउट नहीं कर सकते जो रीट्राई स्टॉर्म के अधीन हैं।
00:14:07और इन सभी वेब सर्वर में एक आंतरिक कतार होती है, और वे कॉन्फ़िगर करने योग्य होते हैं।
00:14:13सुनिश्चित करें कि वे सीमित हैं, और वे ऐसे अनुरोधों को स्वीकार नहीं कर सकते जो असीमित हैं।
00:14:19और यदि आप कुछ कस्टम लॉजिक रखना चाहते हैं, तो आप यहाँ ट्रैफ़िक प्राथमिकता भी रख सकते हैं, यह सुनिश्चित करने के लिए कि लोड के तहत आपके सबसे महत्वपूर्ण उपयोग के मामलों को अच्छी तरह से पूरा किया जाए।
00:14:29अंतिम बात जिस पर मैं चर्चा करना चाहता हूं वह केंद्रीय गेटवे का पूरा विचार है।
00:14:38यह विफलता का एक ही बिंदु है।
00:14:40इसलिए यदि आप दो LLM के लिए अपनी पूरी कंपनी के लिए एक केंद्रीय गेटवे रखने की सोच रहे हैं, तो मैं उस पर पुनर्विचार करने की सलाह दूंगा और देखूंगा कि इसके पीछे आपके क्या कारण हैं।
00:14:52मैंने जो देखा है वह यह है कि अधिकांश परिदृश्यों में, यह केंद्रीय गेटवे नहीं है जो वे चाहते हैं।
00:14:57वे केंद्रीकृत शासन चाहते हैं।
00:15:00और एक ऐसा रास्ता है जिसके माध्यम से आप वास्तव में गेटवे को विकेंद्रीकृत कर सकते हैं और फिर भी शासन को केंद्रीकृत कर सकते हैं।
00:15:07इसलिए अपने ट्रैफ़िक को केंद्रीकृत करने का प्रयास न करें, लेकिन आपके पास प्लगइन्स हो सकते हैं, आपके पास कस्टम कोड हो सकता है जो आपके शासन को केंद्रीकृत कर सकता है।
00:15:17शासन लागत ट्रैकिंग, दर सीमा प्रबंधन के रूप में हो सकता है, और अन्य समाधान भी संभव हैं।
00:15:24इसलिए अपनी पूरी कंपनी के लिए एक केंद्रीय गेटवे होने की योजना बनाने से पहले उनकी खोज करें।
00:15:30इसे एक ही टीम द्वारा प्रबंधित किया जा सकता है, लेकिन मैं इसे पूरी कंपनी के लिए एक एकल तैनाती के रूप में तैनात करने की अनुशंसा नहीं करूंगा, भले ही यह वितरित हो।
00:15:43उस ने कहा, मैं इस बात को व्यक्तिगत नोट पर समाप्त करना चाहता हूँ।
00:15:47तो आज मेरे बेटे का जन्मदिन है, और मैं यहाँ अजनबियों से सर्किट ब्रेकिंग के बारे में बात कर रहा हूँ।
00:15:54तो आप मेरे लिए कम से कम इतना कर सकते हैं कि कृपया जाएं और मेरे लिए और अपने ग्राहकों के लिए एक घटना को रोकें।
00:16:02धन्यवाद।
00:16:03यदि आपके कोई प्रश्न हैं, तो हाँ।
00:16:06.