1. परिचय — लोकल LLM ही क्यों #

BASTION का मर्म है लोकल LLM (Qwen2.5-14B)। GPT-4 या Claude जैसे अत्याधुनिक बाहरी LLM API के बजाय, हमने अपने ही GPU सर्वर पर चलने वाला Qwen2.5 चुना।

स्वाभाविक सवाल यह है: “जब ज़्यादा सटीक विकल्प उपलब्ध है, तो कम परफ़ॉर्मेंस वाला लोकल मॉडल क्यों चुनें?” यह लेख इस निर्णय के पीछे के तर्क और हमारे वास्तविक संचालन के तरीके की व्याख्या करता है।

निष्कर्ष पहले ही बता दें: लोकल LLM के पास “सटीकता” से अलग तीन मज़बूत फ़ायदे हैं, और इंफ्रास्ट्रक्चर ऑपरेशंस के क्षेत्र में वे फ़ायदे कहीं ज़्यादा महत्वपूर्ण हैं।

2. क्लाउड LLM की तीन बाधाएँ #

BASTION के विकास के शुरुआती चरणों में हमने स्वाभाविक रूप से OpenAI API या Anthropic API के उपयोग पर विचार किया। लेकिन हम तीन बाधाओं से टकराए:

2.1 डेटा संप्रभुता (data sovereignty) की बाधा #

BASTION जिन लॉग को हैंडल करता है उनमें ग्राहकों की संवेदनशील जानकारी होती है: अटैक सोर्स IP, आंतरिक सिस्टम आर्किटेक्चर, यूज़रनेम, authentication विफलता के विवरण, और भी बहुत कुछ। इन्हें बाहरी LLM API को भेजना कई ग्राहक अनुबंधों में निषिद्ध है।

विशेष रूप से फाइनेंस, सरकारी और हेल्थकेयर सेक्टर में “लॉग को बाहर भेजना अनुबंध का उल्लंघन है” — यह स्थिति असामान्य नहीं है। ऐसे मामलों में क्लाउड LLM सीधे-सीधे उपयोग योग्य ही नहीं है।

2.2 लागत की अपारदर्शिता #

बाहरी LLM API प्रति-उपयोग के आधार पर शुल्क लेते हैं। AWS DevOps Agent जैसी सेवाएँ सेकंड के हिसाब से शुल्क लेती हैं। BASTION, जो 24/7 लगातार चलता रहता है, के साथ लागत लॉग की मात्रा के अनुपात में रैखिक रूप से बढ़ती है। मासिक बजट अप्रत्याशित हो जाता है।

नतीजा: “जिन महीनों में अटैक ज़्यादा होते हैं, बजट फट जाता है” और “शांत महीनों में आवंटित धन बेकार जाता है” — जिससे लागत का अनुकूलन बेहद कठिन हो जाता है।

2.3 नेटवर्क निर्भरता #

क्लाउड LLM के लिए इंटरनेट कनेक्टिविटी अनिवार्य है। क्लोज़्ड नेटवर्क (डेडिकेटेड लाइनों आदि से अलग-थलग नेटवर्क) में यह सीधे-सीधे उपयोग नहीं हो सकता।

BASTION के कुछ लक्षित ग्राहक चाहते हैं “ऐसा मॉनिटरिंग सिस्टम जो बिना इंटरनेट कनेक्शन वाले एनवायरनमेंट में भी काम करे।” इस सेगमेंट को पकड़ना differentiation की कुंजी थी।

3. BASTION की LLM उपयोग रणनीति — तीन सिद्धांत #

इन कारकों के आधार पर, BASTION LLM उपयोग के लिए तीन सिद्धांतों का पालन करता है:

संक्षेप में, LLM का उपयोग एक “बुद्धिमान सचिव” की तरह करें, और निर्णय deterministic कोड पर छोड़ दें। यह इंडस्ट्री में LLM उपयोग की मुख्यधारा से थोड़ा अलग है।

4. आर्किटेक्चर — GPUStack + Qwen2.5-14B #

BASTION का LLM फ़ाउंडेशन एक सरल कॉन्फ़िगरेशन पर चलता है:

BASTION Central Server (AI-SLOG)
  │
  ├── rsyslog receives logs from each device
  ├── Shell script group for preprocessing and summarization
  │     │
  │     ↓ HTTP API call (OpenAI-compatible)
  │
  └── GPUStack Cluster
        ├── Qwen2.5-14B (primary model)
        ├── Lightweight model (fallback)
        └── Automatic load balancing + automatic restart

हमने यह सेटअप क्यों चुना, इसके कारण नीचे हैं:

4.1 Qwen2.5-14B ही क्यों #

BASTION में लॉग का सारांशन और प्राकृतिक भाषा में रिपोर्ट जनरेशन ही मुख्य काम हैं। इनके लिए ज़रूरी है:

• स्वाभाविक जापानी आउटपुट — अंग्रेज़ी मिली-जुली ग्राहक रिपोर्ट अनुपयोगी होती हैं
• 14B मॉडल साइज़ — बिना quantization के एक अकेले 24GB GPU पर चलता है
• लॉन्ग-कॉन्टेक्स्ट सपोर्ट — लॉग सारांशन के लिए पर्याप्त context length चाहिए
• ओपन लाइसेंस — व्यावसायिक उपयोग की स्पष्ट अनुमति

हमने Llama 3 सीरीज़ का भी मूल्यांकन किया, लेकिन जापानी की स्वाभाविकता में Qwen2.5 आगे रहा। यह हमारे आंतरिक मूल्यांकन का निष्कर्ष था।

4.2 GPUStack ही क्यों #

GPUStack एक OSS है जो कई GPU सर्वरों को एक क्लस्टर की तरह ट्रीट करता है। BASTION के लिए:

• OpenAI-compatible API से बाहरी एक्सेस
• मॉडल स्विचिंग आसान (प्राइमरी मॉडल फेल होने पर fallback)
• वितरित (distributed) संचालन संभव (कई GPU सर्वरों में समानांतर प्रोसेसिंग)
• ऑपरेशंस डैशबोर्ड शामिल (मॉडल की स्थिति एक नज़र में दिखती है)

इन बातों ने हमारी कमर्शियल एनवायरनमेंट आवश्यकताओं को पूरा किया।

5. पाइपलाइन — लॉग से नोटिफ़िकेशन तक #

BASTION में LLM का उपयोग कई चरणों में फैला है:

1. Receive device logs        (rsyslog)
        ↓
2. Classify and save by device (shell + filesystem)
        ↓
3. Summarize per device       (LLM call #1)
        ↓
4. Full correlation analysis  (LLM call #2)
        ↓
5. Severity determination     (deterministic logic)
        ↓
6. Slack notification         (auto-post only if CRITICAL)
        ↓
7. Detailed analysis          (operator calls on mention)

अहम बात यह है कि हर चरण में LLM की ज़िम्मेदारियाँ स्पष्ट रूप से परिभाषित हैं।

“LLM को निर्णय न लेने दें, केवल फ़ॉर्मैटिंग सौंपें” — यह सिद्धांत पूरे सिस्टम में सुसंगत है।

6. LLM को क्या सौंपें, क्या नहीं #

यह BASTION के डिज़ाइन दर्शन का मर्म है, इसलिए विस्तार से बताता हूँ:

BASTION डिज़ाइन चरण से ही यह अलग करता है कि किन परिदृश्यों में LLM आउटपुट पर भरोसा किया जाए और किनमें नहीं:

6.1 जो हम LLM को सौंप सकते हैं #

• प्राकृतिक भाषा में लॉग सारांशन — शब्दों में मामूली भिन्नताएँ स्वीकार्य हैं
• कई डिवाइसों की स्थितियों को एक पैराग्राफ़ में समेकित करना — मानव के पढ़ने के लिए
• Slack नोटिफ़िकेशन टेक्स्ट की फ़ॉर्मैटिंग — severity के अनुसार इमोजी और ज़ोर देना LLM पर छोड़ा गया है
• पिछली मिलती-जुलती घटनाओं का संदर्भ — “यह पिछले हफ़्ते भी हुआ था” प्रस्तुत करना

6.2 जो हम LLM को नहीं सौंप सकते #

• कोई IP दुर्भावनापूर्ण है या नहीं, इसका अंतिम निर्धारण — गणितीय रूप से तय होता है
• ब्लॉक निष्पादित करने के निर्णय — शर्तें कोड में स्पष्ट हैं
• अनब्लॉक करने के निर्णय — केवल 24-घंटे की स्वतः-समाप्ति या ऑपरेटर की कार्रवाई
• प्रोडक्शन कॉन्फ़िग में बदलाव — केवल ऑपरेटर की मैन्युअल कार्रवाई
• सिक्योरिटी severity की अंतिम रेटिंग — रूल-आधारित निर्धारण

हालाँकि ऑपरेटर अक्सर LLM आउटपुट पढ़कर निर्णय लेते हैं, लेकिन BASTION में LLM आउटपुट लगभग कभी भी सीधे सिस्टम के व्यवहार को नियंत्रित नहीं करता।

7. हाइब्रिड LLM रणनीति — लोकल + बाहरी API का परस्पर सहयोग #

मई 2026 की स्थिति के अनुसार, BASTION केवल लोकल LLM का ही लाभ नहीं उठा रहा, बल्कि Claude और GPT जैसे उच्च-प्रदर्शन बाहरी LLM API के साथ एकीकरण को प्रयोगात्मक चरण में परख रहा है।

हालाँकि, यह “लोकल LLM को छोड़कर बाहरी में माइग्रेशन” नहीं है। हम यूज़-केस के आधार पर चयन करने वाला हार्नेस बना रहे हैं।

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

8. महत्वपूर्ण डिज़ाइन निर्णय #

लोकल LLM के संचालन से कई महत्वपूर्ण निर्णय सामने आए:

1. प्रॉम्प्ट का वर्ज़न-कंट्रोल: LLM प्रॉम्प्ट (क्वेरी) को कोड की तरह ही वर्ज़न-कंट्रोल किया जाता है। प्रॉम्प्ट बदलने से आउटपुट की क्वालिटी काफ़ी बदल जाती है, इसलिए हम इतिहास बनाए रखते हैं।

2. JSON आउटपुट का प्रवर्तन: फ़्रीफ़ॉर्म LLM आउटपुट को डाउनस्ट्रीम कोड पार्स नहीं कर सकता। BASTION JSON फ़ॉर्मैट में आउटपुट अनिवार्य करता है और parse error पर retry करता है।

3. Temperature को कम रखना: समान इनपुट से स्थिर आउटपुट के लिए temperature को कम (0.0–0.3) रखा जाता है। रचनात्मकता अनावश्यक है; निर्धारकता महत्वपूर्ण है।

4. प्रॉम्प्ट में “कोई मनगढ़ंत बात नहीं” के निर्देश: “लॉग में मौजूद न होने वाली जानकारी कभी न बनाएँ” और “अनिश्चित होने पर स्पष्ट रूप से ‘unknown’ लौटाएँ” जैसे निर्देश हमेशा शामिल किए जाते हैं। इससे hallucination पूरी तरह ख़त्म नहीं होंगे, इसलिए हम डाउनस्ट्रीम में hallucination ऑडिट करते हैं (विवरण भविष्य के लेख में)।

5. मॉडल विफलता पर fallback: यदि प्राइमरी मॉडल (Qwen2.5-14B) अनुत्तरदायी हो जाए, तो हम एक हल्के मॉडल पर fallback करते हैं। पूरी तरह ठप हो जाने से बेहतर है कि बुनियादी सारांशन चलता रहे।

9. परिचालन परिणाम — नॉइज़ में कमी और निर्धारकता #

BASTION के लगभग एक महीने के प्रोडक्शन संचालन के बाद LLM का परिचालन रिकॉर्ड यह रहा:

• लॉग एनालिसिस ऑटोमेशन दर: ~95% (ऑपरेटर के log tail की जगह LLM सारांशों ने ले ली)
• Slack नोटिफ़िकेशन नॉइज़ में कमी: केवल CRITICAL-ओनली नोटिफ़िकेशन पर स्विच करने से रूटीन नोटिफ़िकेशन की फ़्रीक्वेंसी ~8 गुना घट गई
• निर्णय की निर्धारकता: समान इनपुट से हमेशा समान निर्णय मिलता है (LLM का प्रोबैबिलिस्टिक आउटपुट हटा दिया गया है)
• False positive दर: 0% (आंतरिक/पार्टनर IP को ब्लॉक करने की शून्य घटनाएँ)
• Hallucination डिटेक्शन: ऑडिट लॉजिक लगातार hallucination का पता लगाता रहता है; पकड़ी गई घटनाओं को त्यागकर पुनः विश्लेषण किया जाता है

“100% निर्धारकता” विशेष रूप से महत्वपूर्ण है। LLM-आधारित निर्णय समान इनपुट के लिए अलग-अलग परिणाम दे सकता है। BASTION निर्णय के लिए LLM का उपयोग नहीं करता, इसलिए इस तरह का “अपुनरुत्पादनीय दुर्व्यवहार” कभी नहीं होता।

10. डिज़ाइन ट्रेडऑफ़ #

ईमानदारी से कहें तो लोकल LLM संचालन की अपनी सीमाएँ हैं:

1. प्रारंभिक GPU लागत: Qwen2.5-14B को आराम से चलाने के लिए 24GB-क्लास GPU चाहिए। न्यूनतम कॉन्फ़िगरेशन की लागत भी दसियों हज़ार डॉलर होती है। क्लाउड API के विपरीत, यहाँ कोई “free tier” विकल्प नहीं है।

2. इंफ़रेंस परफ़ॉर्मेंस की सीमा: 14B मॉडल GPT-4 या Claude 3.5 Sonnet की रीज़निंग क्षमता की बराबरी नहीं करते। जटिल multi-step रीज़निंग के लिए बाहरी API fallback की ज़रूरत पड़ सकती है।

3. मॉडल अपडेट को ट्रैक करना: नए मॉडलों के लिए मूल्यांकन और स्विचिंग के निर्णय चाहिए। इसके लिए इन-हाउस तकनीकी निर्णय क्षमता ज़रूरी है (BASTION मेंटेनेंस अनुबंध द्वारा कवर)।

4. प्रॉम्प्ट का निरंतर परिशोधन: हर एनवायरनमेंट के लिए इष्टतम प्रॉम्प्ट अलग होता है। प्रारंभिक ट्यूनिंग और निरंतर परिचालन सुधार अनिवार्य हैं।

ये “लोकल LLM चुनने के अपरिहार्य ट्रेडऑफ़” हैं। डेटा संप्रभुता, लागत की पूर्वानुमेयता और क्लोज़्ड-नेटवर्क क्षमता के बदले हम इन्हें स्वीकार करते हैं।

11. भविष्य का विकास #

LLM फ़ाउंडेशन आगे भी विकसित होता रहेगा:

• नई पीढ़ी के मॉडलों को ट्रैक करना: Qwen3 और अगली पीढ़ी के मॉडलों का मूल्यांकन और माइग्रेशन
• हाइब्रिड LLM रणनीति का परिचालनीकरण: यूज़-केस-आधारित स्वचालित रूटिंग का मानकीकरण
• मल्टीमोडल सपोर्ट: नेटवर्क डायग्राम और ट्रैफ़िक ग्राफ़ को LLM में फ़ीड करना
• प्रति-ग्राहक एनवायरनमेंट ट्यूनिंग: हर ग्राहक के लॉग की विशेषताओं के अनुरूप प्रॉम्प्ट अनुकूलन का ऑटोमेशन

हम इन पर चरणबद्ध ढंग से काम करेंगे।