हर कुछ महीनों में ओपन-सोर्स कम्युनिटी एक और AI फ्रेमवर्क पेश करती है। इनमें से अधिकांश भारी C++ कर्नेल के चारों ओर Python बाइंडिंग्स का उपयोग करते हैं, या वे एब्स्ट्रैक्शन लेयर्स को इतना ऊँचा रखते हैं कि केवल रनटाइम ही उन मॉडल्स से अधिक भारी हो जाता है जिन्हें वे सर्व करते हैं। CatAI इसके विपरीत दिशा में काम करता है। यह पूरी तरह से C++ में लिखा गया एक नेटिव AI इंजन है, जिसे टेंसर मैथ (tensor math) से ऊपर की ओर बनाया गया है। इसका उद्देश्य PyTorch के ऊपर एक और यूजर-फ्रेंडली स्किन बनाना नहीं है। इसका उद्देश्य हार्डवेयर बाउंड्री से शुरू करते हुए मेमोरी के हर बाइट और कंप्यूट के हर साइकिल पर पूर्ण नियंत्रण पाना है।

एक और इंजन की आवश्यकता क्यों?

यदि आपने प्रोडक्शन में कुछ भी शिप किया है, तो आप पहले से ही उस दर्द को जानते हैं। एक स्टैंडर्ड डीप-लर्निंग स्टैक को कंटेनर में डालें और देखें कि कैसे इमेज का आकार बढ़कर कई गीगाबाइट हो जाता है। डिपेंडेंसीज़ आपस में टकराती हैं। Python इंटरप्रेटर लेटेंसी (latency) बढ़ा देता है। वह डिस्पैचर जो ऑप्स (ops) को CUDA या CPU तक पहुँचाता है, एक सूक्ष्म ओवरहेड (overhead) पैदा करता है जो दर्जनों नेस्टेड फ्रेमवर्क्स में खो जाने के बाद प्रोफाइल करना असंभव हो जाता है। एज डिवाइसेस (edge devices), एम्बेडेड रोबोटिक्स, या लेटेंसी-सेंसिटिव बैकएंड्स के लिए, यह नुकसान वास्तविक है। एक शुद्ध C++ इंजन बिचौलियों को खत्म कर देता है। यह बिना किसी गारबेज कलेक्शन (garbage collection), ग्लोबल इंटरप्रेटर लॉक (global interpreter lock) और भाषाओं के बीच सीरियलाइजेशन (serialization) के बिना, सीधे ऑपरेटिंग सिस्टम और सिलिकॉन से बात करता है।

CatAI इसे एक समझौता नहीं, बल्कि एक फीचर के रूप में देखता है। इस प्रोजेक्ट को C++ में स्क्रैच से लिखा जा रहा है क्योंकि लेखक यह तय करना चाहता है कि RAM में टेंसर (tensors) कैसे रहते हैं, वे कैश हायरार्कीज़ (cache hierarchies) के माध्यम से कैसे चलते हैं, और थ्रेड्स के बीच कर्नेल को कैसे शेड्यूल किया जाता है। यह आत्मपीड़न (masochism) नहीं है। सीमित हार्डवेयर से परफॉरमेंस निचोड़ने के लिए व्यवहार को अनुमानित (predictable) सुनिश्चित करने का यही एकमात्र तरीका है।

"स्क्रैच से" का वास्तव में क्या अर्थ है

अधिकांश आधुनिक फ्रेमवर्क्स में, टेंसर मैथ को cuDNN, oneMKL, या MPS जैसी वेंडर लाइब्रेरीज़ में ओपेक कॉल्स (opaque calls) के माध्यम से संभाला जाता है। तेज़ी से शिपिंग करने के लिए यह पूरी तरह से समझदारी भरा है, लेकिन यह ऑपरेशन की कार्यप्रणाली (mechanics) को छिपा देता है। CatAI अपना स्वयं का कोर टेंसर मैथ और मेमोरी लेआउट लिख रहा है। इसका अर्थ है उन मौलिक डेटा स्ट्रक्चर्स को डिजाइन करना जो मल्टी-डायमेंशनल एरेज़ (multi-dimensional arrays) को रखते हैं, स्ट्राइड्स (strides) और ऑफसेट्स (offsets) की गणना कैसे की जाए यह चुनना, और एक्सेस पैटर्न के आधार पर डेटा को row-major, column-major, या कस्टम टाइल्ड फॉर्मेट में स्टोर करने का निर्णय लेना।

यह गहरा सिस्टम्स वर्क (systems work) है। जब आप हाथ से एक मैट्रिक्स-मल्टीप्लाई कर्नेल लिखते हैं, तो आप torch.matmul के बारे में सोचना बंद कर देते हैं और L1 कैश लाइन्स, रजिस्टर प्रेशर (register pressure), और लूप टाइलिंग (loop tiling) के बारे में सोचना शुरू कर देते हैं। आप टारगेट CPU की SIMD चौड़ाई के आधार पर तय करते हैं कि 32x32 टाइल्स के लिए ब्लॉक करना है या 64x64 के लिए। आप एलोकेशन्स (allocations) को 64-बाइट बाउंड्रीज़ पर अलाइन करते हैं ताकि AVX-512 लोड कैश लाइन्स को पार न करें। आप सवाल करते हैं कि क्या टेंसर स्टोरेज के लिए std::vector सही कंटेनर है, या क्या एक कस्टम एरिना एलोकेटर (custom arena allocator) आपको पूरे इन्फरेंस ग्राफ (inference graph) में बेहतर लोकैलिटी (locality) और शून्य विखंडन (zero fragmentation) प्रदान करता है।

मेमोरी लेआउट भी उतना ही महत्वपूर्ण है। एक साधारण n-डायमेंशनल एरे परफॉरमेंस को खत्म कर सकता है यदि channels-last इमेज डेटा को channels-first पैटर्न में एक्सेस किया जाता है। CatAI में, ये लेआउट 'फर्स्ट-क्लास सिटीजन' हैं, न कि एक्सपोर्ट के समय चलने वाले ग्राफ ऑप्टिमाइज़र द्वारा संभाले जाने वाले बाद के विचार।

ऑप्टिमाइज़ेशन की मानसिकता

बेयर-मेटल ऑप्टिमाइज़ेशन (Bare-metal optimization) एक बज़वर्ड जैसा लगता है जब तक कि आप नैनोसेकंड गिनना शुरू नहीं कर देते। इसका अर्थ है ऑपरेशन्स को फ्यूज (fuse) करना ताकि इंटरमीडिएट परिणाम कभी भी CPU रजिस्टर्स या L1 कैश से बाहर न निकलें। इसका अर्थ है layer-norm के बाद GELU को एक सिंगल कर्नेल के रूप में लागू करना, जिससे DRAM तक का पूरा राउंड-ट्रिप बच जाता है। इसका अर्थ है OpenMP डिफॉल्ट्स पर निर्भर रहने के बजाय अपना स्वयं का थ्रेड पूल लिखना, क्योंकि आप जानते हैं कि आपका वर्कलोड बर्स्टी (bursty) है और आप नहीं चाहते कि रनटाइम हर फॉरवर्ड पास में थ्रेड्स को स्पॉन (spawn) और जॉइन (join) करे।

इसका अर्थ यह भी है कि यह समझना कि असेंबली (assembly) कब नहीं लिखनी है। कभी-कभी कंपाइलर हाथ से लिखे गए इंट्रिंसिक्स (intrinsics) की तुलना में लूप को बेहतर तरीके से वेक्टरइज़ (vectorize) करता है। अनुशासन है मापन: प्रोफाइल करें, परिकल्पना करें, एक वेरिएबल बदलें, और फिर से प्रोफाइल करें। यह इंजन उन लोगों द्वारा बनाया जा रहा है जो इस कड़ी मेहनत का आनंद लेते हैं। यदि आपने कभी किसी बैच से दो मिलीसेकंड कम करने के लिए कन्वेल्शन लूप (convolution loop) को फिर से लिखने में दोपहर बिताई है, तो आप पहले से ही इस संस्कृति को समझते हैं।

हमें किसकी आवश्यकता है

यह कोई एक व्यक्ति का शो नहीं है। शून्य से बैकएंड बनाने के लिए विशिष्ट कौशल की आवश्यकता होती है जो शायद ही कभी एक ही मस्तिष्क में मिलते हैं। यदि आप इसे पढ़ रहे हैं और इसमें शामिल होने पर विचार कर रहे हैं, तो यहाँ बताया गया है कि आप कहाँ फिट हो सकते हैं:

  • C++ डेवलपर्स जो आधुनिक मानकों (modern standards) को जानते हैं, लेकिन यह भी जानते हैं कि कब टेम्पलेट्स के कारण compilation bloat होता है। आपको आवश्यकतानुसार raw pointers और उचित होने पर smart pointers के साथ सहज होना चाहिए, और आपको syntax sugar की तरह ही binary size की भी उतनी ही चिंता होनी चाहिए।

  • गणित विशेषज्ञ (Math experts) जो गैर-मानक activations के लिए backward-pass gradients निकाल सकें, mixed-precision training में numerical stability के बारे में तर्क कर सकें, और एल्गोरिदम को कोड बनने से पहले ही ऑप्टिमाइज़ कर सकें। यदि आप समझा सकते हैं कि log-sum-exp trick क्यों महत्वपूर्ण है, तो आप सही मानसिक स्थिति में हैं।

  • लो-लेवल मेमोरी विशेषज्ञ (Low-level memory specialists) जो allocators, page faults, और NUMA topology के बारे में सोचते हैं। इंजन को ग्राफ निष्पादन (graph execution) के लिए memory pools, kernels के लिए scratch buffers, और बिना मेमोरी लीक या फ्रैगमेंटेशन के ट्रेनिंग स्टेप्स के दौरान tensor storage को पुन: उपयोग करने की रणनीतियों की आवश्यकता होती है।

  • सिस्टम इंजीनियर्स (Systems engineers) जो समझते हैं कि कैसे एक गलत syscall पूरे ट्रेनिंग लूप को रोक सकता है। Scheduling, I/O, और synchronization primitives वह गोंद हैं जो गणित को एक साथ जोड़कर रखते हैं।

आपको चारों क्षेत्रों में विश्व स्तरीय विशेषज्ञ होने की आवश्यकता नहीं है। अधिकांश योगदानकर्ता एक kernel या एक allocator से शुरुआत करेंगे और जैसे-जैसे आर्किटेक्चर मजबूत होगा, बाकी चीजें सीखते जाएंगे।

आर्किटेक्चर और कस्टम मैथ (Architecture and Custom Math)

बैकएंड लॉजिक सहयोगात्मक रूप से बनाया जा रहा है, और इसकी शुरुआत आर्किटेक्चर संबंधी बहसों से होती है। क्या इंजन एक static computation graph का उपयोग करेगा, जहाँ रनटाइम से पहले पूरे मॉडल को परिभाषित और ऑप्टिमाइज़ किया जाता है? या यह automatic differentiation के लिए tape के साथ eager execution का समर्थन करेगा? autodiff को कैसे दर्शाया जाएगा—operator overloading, source transformation, या एक graph IR के रूप में? ये निर्णय बाकी सब कुछ तय करते हैं।

कस्टम न्यूरल नेट मैथ का मतलब केवल मानक लेयर्स (standard layers) को फिर से लागू करना नहीं है। इसका अर्थ है नए लेयर्स का आविष्कार करने की स्वतंत्रता। यदि आप एक गैर-मानक sparse kernel के साथ convolution variant या ऐसा activation function चाहते हैं जिसका साहित्य (literature) में कोई नाम नहीं है, तो आप C++ forward और backward passes लिखते हैं और उन्हें सीधे इंजन में प्लग कर देते हैं। यहाँ लड़ने के लिए कोई Python API नहीं है, और न ही किसी monkey-patching की आवश्यकता है। गणित ही कोड है, और कोड ही इंटरफ़ेस है।

कैसे शामिल हों (How to Get Involved)

यदि यह आपको प्रभावित करता है, तो प्रोजेक्ट का पूरा विवरण और वर्तमान रोडमैप लेखक के Dev.to पोस्ट पर विस्तार से दस्तावेज़ित हैं। आप विशिष्टताओं को पढ़ सकते हैं, देख सकते हैं कि अब तक क्या बनाया गया है, और समझ सकते हैं कि वास्तव में कहाँ मदद की आवश्यकता है।

प्रोजेक्ट विवरण: https://dev.to/banana_cool/building-a-native-c-ai-engine-catai-from-scratch-looking-for-collaborators-l8m

उन लोगों के लिए एक Telegram समूह भी है जो तुरंत pull request के लिए प्रतिबद्ध हुए बिना जुड़ना, प्रश्न पूछना या प्रगति का अनुसरण करना चाहते हैं।

कम्युनिटी: https://t.me/GyaanSetuAi

असली निष्कर्ष (The Real Takeaway)

आधुनिक AI स्टैक एक ब्लैक बॉक्स बन गया है। हम फ्रेमवर्क को जादुई उपकरणों की तरह मानते हैं: डेटा अंदर जाता है, मॉडल बाहर आता है, और हम उम्मीद करते हैं कि परदे के पीछे की यह अस्पष्टता (opacity) डिप्लॉयमेंट के समय हमें नुकसान न पहुँचाए। CatAI उस सुविधा को नकारता है। इस तरह से बनाना धीमा है। आप अधिक कोड लिखेंगे, अधिक segfaults को डीबग करेंगे, और उन धारणाओं पर फिर से विचार करेंगे जिन्हें उच्च-स्तरीय फ्रेमवर्क आपसे छिपाते हैं। लेकिन आप यह भी समझेंगे कि मशीन इसी तरह व्यवहार क्यों करती है। एक ऐसे उद्योग में जहाँ हर कोई हार्डवेयर को अमूर्त (abstract) करने की दौड़ में है, विपरीत दिशा में जाने और 'टचिंग द मेटल' (touching the metal) में वास्तविक मूल्य है। यही वह समझ है जो किसी API को कॉल करने वाले व्यक्ति और सिस्टम बनाने वाले व्यक्ति के बीच अंतर पैदा करती है।