ब्याच र एसिन्क्रोनस वर्कलोडहरू

लाभ:

• कुन वर्कलोड ब्याच प्रशोधनका लागि उपयुक्त छ भनेर निर्धारण गर्दछ
• सिंक्रोनस, एसिन्क्रोनस र ब्याच प्रशोधन बीचको लागत/विलम्बता ट्रेडअफ बुझ्छ
• परिणामहरूसँग custom_id मिल्ने बलियो ब्याच कार्यप्रवाह डिजाइन गर्दछ

धेरै जसो LLM एकीकरणहरू "लाइभ" परिदृश्यहरूमा केन्द्रित हुन्छन् जहाँ प्रयोगकर्ताले स्क्रिनको अगाडि प्रतिक्रियाको लागि पर्खिरहेका हुन्छन्। तर अधिकांश व्यावसायिक कार्यभारहरू वास्तवमा प्रत्यक्ष हुँदैनन्: हजारौं कागजातहरू रातारात ट्याग गर्ने, सम्पूर्ण डेटासेटलाई संक्षेप गर्ने, अभिलेखमा सम्पूर्ण कल रेकर्डिङहरू वर्गीकरण गर्ने। यी मामिलाहरूमा, कसैले तत्काल जवाफको अपेक्षा गर्दैन। महत्त्वपूर्ण कुरा सस्तो र भरपर्दो रूपमा काम समाप्त गर्न हो। ब्याच यी वर्कलोडहरूको लागि ठीक छ। यो एकाइमा, तपाईले सिंक्रोनस, एसिन्क्रोनस, र ब्याच प्रशोधन बीचको भिन्नता सिक्नुहुनेछ, जब ब्याच सही छनोट हो, र एक बलियो प्रवाह जसले आत्मविश्वाससँग custom_id र परिणामहरूसँग मेल खान्छ।

तीन कार्य मोडहरू

मोड

यसले कसरी काम गर्छ

ढिलाइ

सामान्य लागत

उपयुक्त काम

सिंक्रोनस

तपाईंले अनुरोध गर्नुभयो र प्रतिक्रियाको लागि पर्खनुहोस्

सेकेन्ड

मानक

प्रत्यक्ष कुराकानी, तत्काल सहायक

एसिन्क्रोनस

तपाईंले कामलाई लामबद्ध गर्नुहुन्छ र यो समाप्त भएपछि सूचित गर्नुहोस्।

सेकेन्ड - मिनेट

मानक

पृष्ठभूमि कार्यहरू, स्वचालन चरणहरू

ब्याच

एक प्याकेजमा हजारौं अनुरोधहरू पठाउँछ, त्यसपछि परिणामहरू प्राप्त गर्दछ

मिनेट-घन्टा

सामान्यतया छुट

उच्च मात्रा, ढिलाइ-सहिष्णु कार्यहरू

ब्याच प्रशोधन यो हो: तपाईंले प्रदायकलाई एकल "काम" को रूपमा सयौं/हजार अनुरोधहरू पठाउनुहुन्छ; प्रदायकले तिनीहरूलाई आफ्नै गतिमा प्रशोधन गर्छ र एक पटक पूरा भएपछि सबै परिणामहरू थोकमा फर्काउँछ। बदलामा तपाईले दुई चीजहरू पाउनु हुन्छ: (१) सामान्यतया कम एकाइ लागत, (२) गति सीमाहरूसँग सम्झौता नगरी उच्च भोल्युम सार्न सक्ने क्षमता। मूल्य यो छ कि परिणाम तुरुन्तै आउँदैन, तर केहि समय पछि।

कहिले ब्याच गर्ने, कहिले होइन?

निर्णय एउटा प्रश्नमा तल आउँछ: के प्रयोगकर्ता अब परिणामको लागि पर्खिरहेका छन्?

• होइन, म यसलाई समात्न सक्छु → ब्याच उम्मेदवार। नाइट ट्यागिङ, ब्याच सारांश, अभिलेख वर्गीकरण, डाटा संवर्धन, मूल्याङ्कन (eval) कार्यान्वयन।
• हो, स्क्रिनमा प्रतिक्षा गर्दै → सिंक। प्रत्यक्ष कुराकानी, तत्काल सल्लाह, फारम भर्दा मद्दत।

सुझाव: एउटै उत्पादनमा दुई मोडहरू सँगै रहन सक्छन्। प्रयोगकर्ता प्रत्यक्ष च्याटमा सिंक्रोनस रूपमा काम गर्दछ; राती, तपाईले त्यस दिनको सबै कुराकानीहरू ब्याचलाई गुणस्तर विश्लेषणको लागि दिनुहुन्छ। "सामूहिक आवश्यकता" बाट "जीवित आवश्यकता" अलग गर्नु वास्तुकलाको पहिलो निर्णय हो।

रोबस्ट ब्याच फ्लो को एनाटॉमी

ब्याच प्रशोधनको सबैभन्दा महत्त्वपूर्ण प्राविधिक नियम परिणाम मिलान हो।

1. प्रत्येक अनुरोधलाई एक अद्वितीय `custom_id` दिनुहोस्। यो तपाईंको उत्पन्न ID हो जसले अनुरोध पहिचान गर्दछ (जस्तै इनभ्वाइस-2026-07-18-000431)।
2. काम पेश गर्नुहोस्। सबै अनुरोधहरू एक प्याकेजमा जान्छन्; प्रत्येकको आफ्नै custom_id संग।
3. स्थिति सर्वेक्षण गर्नुहोस्। तपाईंले काम "सम्पन्न" नभएसम्म अन्तरालहरूमा स्थितिको लागि सोध्नुहुन्छ।
4. परिणामहरूलाई `custom_id` सँग मिलाउनुहोस्। नतिजा सबमिशन अर्डर भन्दा फरक क्रममा फर्काउन सकिन्छ; त्यसैले स्थिति अनुसार कहिल्यै मिल्दैन तर custom_id द्वारा प्रत्येक परिणाम बोक्छ।
5. प्रत्येक परिणाम को प्रकार जाँच गर्नुहोस्। एउटा अनुरोध सफल हुन सक्छ, एक असफल हुन सक्छ, एक समाप्त हुन सक्छ। सफलता/असफलतामा आधारित प्रक्रिया।

{ "अनुरोधहरू": [ { "custom_id": "invoice-000431", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "वर्गीकरण इनभ्वाइस। JSON मात्र फर्काउनुहोस्।", "messages": "": "conleter": [{userrouter': "{{invoice_text}}" }] } }, { "custom_id": "invoice-000432", "params": { "model": "claude-haiku-4-5", "max_tokens": 128, "system": "Classify invoice। "[Return's:"{JSON:": "JSONSroages मात्र।" "सामग्री": "{{invoice_text_2}}" }] } } ]}

सावधान: सबमिशन अर्डरमा आधारित नतिजाहरू मिलाउनु ब्याचिङमा नम्बर एक गल्ती हो। लाइन सुरक्षित छैन। कस्टम_आईडी बिना तपाईले कुन नतिजा कुन कागजातको हो भनेर निर्धक्क भई थाहा पाउन सक्नुहुन्न — गलत मिल्दोले चुपचाप गलत डेटा निम्त्याउँछ।

प्रतिलिपि गर्न मिल्ने टेम्प्लेटहरू

# अनुकूलन_आईडी जेनेरेसन नियम (अद्वितीय र ट्रेस योग्य) ढाँचा: <isture>-<date>-<sequence>। उदाहरण: request-20260718-000431Rule: काममा कहिल्यै नदोहोर्याउनुहोस्; यसमा स्रोत रेकर्ड आईडी इम्बेड गर्नुहोस्।

# ब्याच कार्य कार्ड (तालिका टेम्प्लेट) जागिरको नाम: ............. रेकर्डहरूको संख्या: ............. मोडेल: ............. (सरल काम → द्रुत मोडेल) अधिकतम_टोकन्स प्रति अनुरोध: ............. अपेक्षित डेलिभरी समय सहिष्णुता: .. घण्टा परिणाम मिल्दो कुञ्जी: custom_id त्रुटिको अवस्थामा: पुन: प्रयास / लाम / रिपोर्ट

# ब्याचमा एकल अनुरोध प्रम्प्ट (छोटो र योजनाबद्ध) यस कागजातलाई वर्गीकृत गर्नुहोस्। यो JSON फिर्ता गर्नुहोस्, टिप्पणी गर्दै:{"category":"...","urgency":"low|medium|high"}कागजात: """{{document}}"""

# प्रत्येक नतिजाको लागि नतिजा प्रशोधन स्यूडो-कोड: यदि result.status == "success": record = find(custom_id) save(record, result.output) अन्यथा: add_to_fail(custom_id, result.error) # त्यसपछि फेरि प्रयास गर्नुहोस्

कमजोर प्रम्प्ट / बलियो प्रम्प्ट (ब्याच कार्य डिजाइन)

# कमजोर (नाजुक डिजाइन) बलियो मोडेलको साथ 10,000 कागजातहरू पठाउनुहोस्, फिर्ता परिणामहरू तिनीहरू आइपुगेको क्रममा बचत गर्नुहोस्।

# बलियो (टिकाउ डिजाइन) द्रुत मोडेलको साथ एक ब्याचमा 10,000 कागजातहरू पठाउनुहोस्। प्रत्येक कागजातलाई स्रोत-रेकर्ड ID समावेश भएको एउटा अद्वितीय custom_id दिनुहोस्। custom_id सँग परिणामहरू मिलाउनुहोस्; असफल भएकाहरूलाई लामबद्ध गर्नुहोस् र फेरि प्रयास गर्नुहोस्।रातको झ्यालमा दौडनुहोस्; वितरण सहिष्णुता 6 घण्टा।

शक्तिशाली संस्करण; यसले मोडेल चयन, मिल्दो कुञ्जी, त्रुटि ह्यान्डलिंग र समयलाई पूर्व-परिभाषित गर्दछ। यो हजारौं रेकर्डहरू सुरक्षित रूपमा प्रशोधन गर्ने भिन्नता हो।

तीन मिनी केसहरू

केस 1 - रात ट्यागिङ। एक ई-वाणिज्य टोलीले 200,000 उत्पादन समीक्षाहरू भावना ट्यागहरूमा क्रमबद्ध गर्नेछ। लाइभ सिंक्रोनस स्ट्रिमिङ गति सीमाको अधीनमा थियो र महँगो थियो। तिनीहरूले कामलाई रातीमा छिटो मोडेलको साथ एक ब्याचको रूपमा बोके। एकाइ लागत घट्यो, सम्पूर्ण सेट बिहान तयार थियो, र कुनै गति सीमा समस्याहरू थिएनन्।

केस 2 - अर्डर भ्रम। एक अनुसन्धान टोली ब्याचले 5,000 लेखहरू सार गर्यो, तर परिणामहरू फाइलहरूमा तिनीहरू आइपुगेको क्रममा लेखे। परिणामहरू फरक क्रममा फर्काइएको हुनाले, 5,000 सारहरू मध्ये 900 वटा गलत लेखमा जोडिएका थिए। तिनीहरूले यसलाई custom_id मा पुन: म्याप गरे; समस्या हल भयो र यो अनुभव स्थायी नियम बन्यो: "सधैं ब्याचमा custom_id।"

केस ३ - गलत मोडमा लाइभ स्ट्यान्डबाइ। एक समर्थन टोलीले स्क्रिनमा प्रयोगकर्ताले अपेक्षा गरेको लाइभ प्रतिक्रियाहरू ब्याच दिने प्रयास गर्यो; परिणामहरू मिनेट पछि आइपुगेकोले प्रयोगकर्ताहरूले त्यागे। तिनीहरूले ब्याचमा रातको गुणस्तर विश्लेषण मात्र छोडेर, सिंक्रोनाइजेसनमा प्रत्यक्ष कार्यलाई फिर्ता सारियो। पाठ: ब्याच लाइभ स्ट्यान्डबाइको लागि होइन।

सामान्य गल्तीहरू

• स्थिति द्वारा मिल्दो परिणाम: अर्डर सुरक्षित छैन; custom_id प्रयोग गर्नुहोस्।
• ब्याचमा प्रत्यक्ष कार्य स्थानान्तरण गर्दै: प्रयोगकर्ताले मिनेट पर्खन सक्दैन; ब्याच ढिलाइ सहनशील कामहरूको लागि हो।
• त्रुटि केसहरू ह्यान्डल गर्दैन: केही अनुरोधहरू असफल/समय समाप्त हुन सक्छ; यसलाई छुट्टै लाममा राख्नुहोस् र फेरि प्रयास गर्नुहोस्।
• ब्याचमा बलियो मोडेल प्रयोग रिफ्लेक्स: द्रुत मोडेल + ब्याच साधारण कार्यहरूमा सस्तो संयोजन हो।
• Custom_id ट्रेस गर्न मिल्दैन: यदि कुनै स्रोत रेकर्ड ID मा इम्बेड गरिएको छैन भने, परिणामलाई फिर्ता लिङ्क गर्न गाह्रो हुन्छ।
• स्थिति जाँच्न बिर्सनु: काम समाप्त हुनु अघि परिणामको आशा गर्दै; पूरा स्थिति जाँच गर्नुहोस्।

गहिरो: निगरानी ब्याच र आंशिक विफलता व्यवस्थापन

ब्याच प्रशोधनको सबैभन्दा परिपक्व पक्ष यो हो कि यसलाई व्यक्तिगत कलहरू भन्दा फरक मानसिकता चाहिन्छ: ब्याच कार्य "प्रक्रिया" हो, "घटना" होइन। दशौं हजार अनुरोधहरू सबै सफल हुनेछन् भनी मान्नु कमजोर छ; यथार्थवादी डिजाइन सुरु देखि आंशिक विफलता स्वीकार गर्दछ। प्रत्येक परिणामको स्थिति फरक हुन सक्छ: सफल, असफल (जस्तै अमान्य इनपुट), रद्द वा म्याद सकियो। एक बलियो प्रवाहले प्रत्येक परिणामको स्थितिलाई अलग-अलग प्रशोधन गर्दछ जब यो यसको माध्यमबाट यात्रा गर्दछ, असफलहरूलाई छुट्टै "पुनः प्रयास लाम" मा राख्छ र त्यो लामलाई छुट्टै चलाउँछ।

दोस्रो अभ्यास भनेको इडम्पोटेन्सीको लागि डिजाइन गर्नु हो (एउटै काम दुई पटक चलाउँदा कुनै हानि हुँदैन)। यदि ब्याच बाधित भयो र तपाईंले यसलाई पुन: सुरु गर्नुभयो भने, तपाईंले पहिले नै प्रशोधित रेकर्डहरू दुई पटक पुन: प्रशोधन र लेख्नु हुँदैन। तपाइँको स्रोत रेकर्डमा custom_id लाई बाइन्ड गर्नाले यहाँ पनि काम गर्दछ: "के यो रेकर्ड पहिले नै प्रशोधन गरिएको छ?" परिणाम बचत गर्नु अघि। जाँचले डबल टाइपिङलाई रोक्छ।

तेस्रो बिन्दु भनेको ब्याचको साथ लाइभ स्ट्रिमहरू स्तब्ध पार्नु हो। केही कामहरूमा प्रत्यक्ष र ब्याच दुवै आयामहरू हुन्छन्: प्रयोगकर्ताले कागजात लोड गर्दा, तपाईंले तिनीहरूलाई द्रुत प्रारम्भिक सारांश (सिंक्रोनस) दिनुहुन्छ, र रातमा गहिरो विश्लेषणको लागि उही कागजात पुन: प्रशोधन गर्नुहुन्छ (ब्याच)। सचेत रूपमा दुई मोडहरू अलग गर्नाले प्रयोगकर्ता अनुभव र लागत दुवैलाई अनुकूलन गर्दछ।

अन्तमा, ब्याचिङ पनि गति सीमा (इकाई 8) सँग सम्झौता गर्ने तरिका हो। प्रत्यक्ष सिंक्रोनस प्रवाहमा उच्च भोल्युम पठाउँदा स्थिर 429 उत्पादन हुन्छ, जबकि ब्याच स्थानान्तरणमा उही भोल्युम पठाउँदा प्रदायकको आफ्नै समयतालिकामा दबाब सीमित हुन्छ र कामलाई थप अनुमानित बनाउँछ।

संक्षेपमा

ब्याच प्रशोधन सामान्यतया विलम्बता-सहिष्णु र उच्च-भोल्युम वर्कलोडहरूको लागि सस्तो र थप बलियो मोड हो। उनको निर्णय थियो "के प्रयोगकर्ता अब नतिजा पर्खिरहेका छन्?" प्रश्न निर्धारण गर्दछ। सबैभन्दा महत्त्वपूर्ण प्राविधिक नियम भनेको प्रत्येक अनुरोधलाई एक अद्वितीय custom_id दिनु, स्थानको सट्टा ID द्वारा परिणामहरू मिलाउनु, र प्रत्येक परिणामको सफलता/असफलतालाई छुट्टै व्यवहार गर्नु हो।

आवेदन कार्य

उच्च मात्राको काम छान्नुहोस् (जस्तै अभिलेख वर्गीकरण)। (१) यो कार्य प्रत्यक्ष हो कि सामूहिक हो भन्ने निर्णय गर्नुहोस् र यसलाई जायज ठहराउनुहोस्। (२) कस्टम_आईडी ढाँचा डिजाइन गर्नुहोस् (स्रोत रेकर्ड समावेश गर्नुहोस्)। (३) ब्याच कार्य कार्ड भर्नुहोस् (मोडेल, अधिकतम_टोकन्स, सहिष्णुता, त्रुटि नीति)। (4) असफल अनुरोधहरू समावेश गर्न परिणाम प्रशोधन स्यूडोकोड लेख्नुहोस्।

चेकलिस्ट

• [] म लागत/ढिलाइ अक्षमा सिंक्रोनस, एसिन्क्रोनस र ब्याच मोडहरू छुट्याउन सक्छु।
• [ ] म सही प्रश्न सोधेर ब्याचको लागि उपयुक्त छ वा छैन भनेर निर्णय गर्न सक्छु।
• [ ] म प्रत्येक अनुरोधलाई एक अद्वितीय custom_id दिन्छु र ID द्वारा परिणामहरू मिलाउँछु।
• [] म असफल/समय समाप्त नतिजाहरू छुट्टै ह्यान्डल गर्न सक्छु।
• [ ] मलाई साधारण ब्याच कार्यहरूमा द्रुत मोडेल छनौट गर्ने फाइदाहरू थाहा छ।