ಪ್ರತಿ ಕೆಲವು ತಿಂಗಳಿಗೊಮ್ಮೆ ಓಪನ್-ಸೋರ್ಸ್ ಸಮುದಾಯವು ಮತ್ತೊಂದು AI framework ಅನ್ನು ಬಿಡುಗಡೆ ಮಾಡುತ್ತದೆ. ಇವುಗಳಲ್ಲಿ ಹೆಚ್ಚಿನವು ಭಾರವಾದ C++ kernels ಸುತ್ತ Python bindings ಅನ್ನು ಸುತ್ತುತ್ತವೆ, ಅಥವಾ ಅಬಾಕ್ಷನ್ ಲೇಯರ್‌ಗಳನ್ನು (abstraction layers) ಎಷ್ಟು ಎತ್ತರಕ್ಕೆ ಜೋಡಿಸುತ್ತವೆ ಎಂದರೆ, ಅವುಗಳ runtime ತೂಕವು ಅವು ಸೇವೆ ನೀಡುವ ಮಾಡೆಲ್‌ಗಳಿಗಿಂತ ಹೆಚ್ಚಾಗಿರುತ್ತದೆ. CatAI ಇದಕ್ಕೆ ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಚಲಿಸುತ್ತದೆ. ಇದು ಸಂಪೂರ್ಣವಾಗಿ C++ ನಲ್ಲಿ ಬರೆಯಲಾದ ಒಂದು native AI engine ಆಗಿದ್ದು, tensor math ನಿಂದ ಮೇಲಕ್ಕೆ ನಿರ್ಮಿಸಲಾಗಿದೆ. ಇದರ ಉದ್ದೇಶ PyTorch ಮೇಲೆ ಮತ್ತೊಂದು ಸುಲಭವಾದ skin ಅನ್ನು ಸೃಷ್ಟಿಸುವುದಲ್ಲ. ಇದರ ಉದ್ದೇಶ ಹಾರ್ಡ್‌ವೇರ್ ಬೌಂಡರಿಯಿಂದ ಪ್ರಾರಂಭಿಸಿ, ಮೆಮೊರಿಯ ಪ್ರತಿ ಬೈಟ್ ಮತ್ತು ಕಂಪ್ಯೂಟ್‌ನ ಪ್ರತಿ ಸೈಕಲ್ ಅನ್ನು ನಿಯಂತ್ರಿಸುವುದಾಗಿದೆ.

ಏಕೆ ಮತ್ತೊಂದು engine?

ನೀವು ಯಾವುದನ್ನಾದರೂ production ಗೆ ಕಳುಹಿಸಿದ್ದರೆ, ಆ ನೋವು ನಿಮಗೆ ಈಗಾಗಲೇ ತಿಳಿದಿದೆ. ಒಂದು standard deep-learning stack ಅನ್ನು container ಒಳಗೆ ತಂದು, ಅದರ image ಗಾತ್ರವು ಹಲವಾರು ಗಿಗಾಬೈಟ್‌ಗಳಿಗೆ ಹೇಗೆ ಬೆಳೆಯುತ್ತದೆ ಎಂಬುದನ್ನು ನೋಡಿ. Dependencies ಒಂದಕ್ಕೊಂದು ಹೋರಾಡುತ್ತವೆ. Python interpreter ವಿಳಂಬವನ್ನು (latency) ಉಂಟುಮಾಡುತ್ತದೆ. CUDA ಅಥವಾ CPU ಗೆ ops ಅನ್ನು ರೌಟ್ ಮಾಡುವ dispatcher, ಒಂದು ಡಜನ್ ನೆಸ್ಟೆಡ್ framework ಗಳೊಳಗೆ ಮಾಯವಾದ ನಂತರ profile ಮಾಡಲಾಗದಂತಹ ಸೂಕ್ಷ್ಮವಾದ overhead ಅನ್ನು ಪರಿಚಯಿಸುತ್ತದೆ. Edge devices, embedded robotics ಅಥವಾ latency-sensitive backends ಗಾಗಿ, ಈ ತೆರಿಗೆ (tax) ನಿಜವಾಗಿಯೂ ದೊಡ್ಡದಾಗಿರುತ್ತದೆ. ಒಂದು ಶುದ್ಧ C++ engine ಮಧ್ಯವರ್ತಿಯನ್ನು ತೆಗೆದುಹಾಕುತ್ತದೆ. ಇದು operating system ಮತ್ತು silicon ಜೊತೆಗೆ ನೇರವಾಗಿ ಸಂವಹನ ನಡೆಸುತ್ತದೆ; ಇದರಲ್ಲಿ garbage collection, global interpreter lock ಅಥವಾ ಭಾಷೆಗಳ ನಡುವೆ serialization dance ಇರುವುದಿಲ್ಲ.

CatAI ಇದನ್ನು ಒಂದು compromise ಆಗಿ ಅಲ್ಲದೆ, ಒಂದು feature ಆಗಿ ಪರಿಗಣಿಸುತ್ತದೆ. ಈ ಪ್ರಾಜೆಕ್ಟ್ ಅನ್ನು C++ ನಲ್ಲಿ ಮೊದಲಿನಿಂದಲೇ (from scratch) ಬರೆಯಲಾಗುತ್ತಿದೆ, ಏಕೆಂದರೆ tensors RAM ನಲ್ಲಿ ಹೇಗೆ ಇರುತ್ತವೆ, ಅವು cache hierarchies ಮೂಲಕ ಹೇಗೆ ಚಲಿಸುತ್ತವೆ ಮತ್ತು threads across kernels ಹೇಗೆ schedule ಆಗುತ್ತವೆ ಎಂಬುದನ್ನು ಲೇಖಕರು ನಿಖರವಾಗಿ ನಿರ್ಧರಿಸಲು ಬಯಸುತ್ತಾರೆ. ಇದು ಮಸೋಕಿಜಂ ಅಲ್ಲ. ಸೀಮಿತ ಹಾರ್ಡ್‌ವೇರ್‌ನಿಂದ ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು (performance) ಹೊರತೆಗೆಯುವಾಗ, ವರ್ತನೆಯು (behavior) ಮುನ್ಸೂಚನೆ ನೀಡಬಲ್ಲದಾಗಿರುತ್ತದೆ (predictable) ಎಂದು ಖಚಿತಪಡಿಸಿಕೊಳ್ಳಲು ಇದೊಂದೇ ದಾರಿ.

"From Scratch" ಎಂದರೆ ವಾಸ್ತವವಾಗಿ ಏನು?

ಹೆಚ್ಚಿನ ಆಧುನಿಕ framework ಗಳಲ್ಲಿ, tensor math ಅನ್ನು cuDNN, oneMKL ಅಥವಾ MPS ನಂತಹ vendor libraries ಗಳ ಅಸ್ಪಷ್ಟ (opaque) ಕರೆಗಳ ಮೂಲಕ ನಿರ್ವಹಿಸಲಾಗುತ್ತದೆ. ವೇಗವಾಗಿ ಬಿಡುಗಡೆ ಮಾಡಲು ಇದು ಸರಿಯಾಗಿದ್ದರೂ, ಇದು ಕಾರ್ಯಾಚರಣೆಯ ಕಾರ್ಯವಿಧಾನವನ್ನು (mechanics) ಮರೆಮಾಚುತ್ತದೆ. CatAI ತನ್ನದೇ ಆದ core tensor math ಮತ್ತು memory layouts ಅನ್ನು ಬರೆಯುತ್ತಿದೆ. ಅಂದರೆ ಬಹು-ಆಯಾಮದ array ಗಳನ್ನು ಹಿಡಿದಿಟ್ಟುಕೊಳ್ಳುವ ಮೂಲಭೂತ data structures ಗಳನ್ನು ವಿನ್ಯಾಸಗೊಳಿಸುವುದು, strides ಮತ್ತು offsets ಹೇಗೆ ಲೆಕ್ಕಹಾಕಲ್ಪಡುತ್ತವೆ ಎಂಬುದನ್ನು ಆಯ್ಕೆ ಮಾಡುವುದು ಮತ್ತು access pattern ಆಧಾರದೆಯ ಮೇಲೆ ಡೇಟಾವನ್ನು row-major, column-major ಅಥವಾ custom tiled formats ನಲ್ಲಿ ಸಂಗ್ರಹಿಸಬೇಕೆ ಎಂಬುದನ್ನು ನಿರ್ಧರಿಸುವುದು ಎಂದರ್ಥ.

ಇದು ಆಳವಾದ systems work ಆಗಿದೆ. ನೀವು ಒಂದು matrix-multiply kernel ಅನ್ನು ಕೈಯಾರೆ ಬರೆಯುವಾಗ, ನೀವು torch.matmul ಬಗ್ಗೆ ಯೋಚಿಸುವುದನ್ನು ನಿಲ್ಲಿಸಿ L1 cache lines, register pressure ಮತ್ತು loop tiling ಬಗ್ಗೆ ಯೋಚಿಸಲು ಪ್ರಾರಂಭಿಸುತ್ತೀರಿ. target CPU ನ SIMD width ಆಧಾರದ ಮೇಲೆ ನೀವು 32x32 tiles ಅಥವಾ 64x64 tiles ಗಾಗಿ block ಮಾಡಬೇಕೆಂದು ನಿರ್ಧರಿಸುತ್ತೀರಿ. AVX-512 loads ಗಳು cache lines ಗಳನ್ನು ದಾಟದಂತೆ ನೀವು allocations ಅನ್ನು 64-byte boundaries ಗೆ ಜೋಡಿಸುತ್ತೀರಿ. tensor storage ಗಾಗಿ std::vector ಸರಿಯಾದ container ಆಗಿದೆಯೇ ಅಥವಾ custom arena allocator ಇಡೀ inference graph ಉದ್ದಕ್ಕೂ ಉತ್ತಮ locality ಮತ್ತು ಶೂನ್ಯ fragmentation ಅನ್ನು ನೀಡುತ್ತದೆಯೇ ಎಂದು ನೀವು ಪ್ರಶ್ನಿಸುತ್ತೀರಿ.

Memory layout ಕೂಡ ಅಷ್ಟೇ ನಿರ್ಣಾಯಕವಾಗಿದೆ. channels-last image data ಅನ್ನು channels-first pattern ನಲ್ಲಿ ಪ್ರವೇಶಿಸಿದರೆ, ಒಂದು naïve n-dimensional array ಕಾರ್ಯಕ್ಷಮತೆಯನ್ನು ಹಾಳುಮಾಡಬಹುದು. CatAI ನಲ್ಲಿ, ಈ layouts ಗಳು ಪ್ರಥಮ ದರ್ಜೆಯ ಅಂಶಗಳಾಗಿವೆ (first-class citizens), ಇವುಗಳನ್ನು export ಸಮಯದಲ್ಲಿ ರನ್ ಆಗುವ graph optimizer ಮೂಲಕ ನಿರ್ವಹಿಸುವ ನಂತರದ ಆಲೋಚನೆಗಳಾಗಿ (afterthoughts) ನೋಡಲಾಗುವುದಿಲ್ಲ.

Optimization ಮನೋಭಾವ

ನೀವು ನಾನೋಸೆಕೆಂಡ್‌ಗಳನ್ನು ಎಣಿಸಲು ಪ್ರಾರಂಭಿಸುವವರೆಗೆ bare-metal optimization ಎಂಬುದು ಕೇವಲ ಒಂದು buzzword ನಂತೆ ಕೇಳಿಸುತ್ತದೆ. ಮಧ್ಯಂತರ ಫಲಿತಾಂಶಗಳು (intermediate results) ಎಂದಿಗೂ CPU registers ಅಥವಾ L1 cache ಅನ್ನು ಬಿಟ್ಟು ಹೊರಗೆ ಹೋಗದಂತೆ ಕಾರ್ಯಾಚರಣೆಗಳನ್ನು (operations) ವಿಲೀನಗೊಳಿಸುವುದು (fusing) ಎಂದರ್ಥ. layer-norm ನಂತರ GELU ಅನ್ನು ಒಂದೇ kernel ಆಗಿ ಅನುಷ್ಠಾನಗೊಳಿಸುವುದು ಎಂದರ್ಥ, ಇದು DRAM ಗೆ ಹೋಗುವ ಇಡೀ round-trip ಅನ್ನು ಉಳಿಸುತ್ತದೆ. OpenMP defaults ಮೇಲೆ ಅವಲಂಬಿತವಾಗುವ ಬದಲು ನಿಮ್ಮದೇ ಆದ thread pool ಅನ್ನು ಬರೆಯುವುದು ಎಂದರ್ಥ, ಏಕೆಂದರೆ ನಿಮ್ಮ workload ಏರಿಳಿತಗಳಿಂದ ಕೂಡಿದೆ (bursty) ಮತ್ತು ಪ್ರತಿ forward pass ನಲ್ಲಿ runtime threads ಅನ್ನುបង្កើតಿಸುವುದು (spawning) ಮತ್ತು ಸೇರಿಸುವುದು (joining) ನಿಮಗೆ ಇಷ್ಟವಿಲ್ಲ ಎಂದು ನಿಮಗೆ ತಿಳಿದಿದೆ.

assembly ಅನ್ನು ಯಾವಾಗ ಬರೆಯಬಾರದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುವುದು ಕೂಡ ಇದರರ್ಥ. ಕೆಲವೊಮ್ಮೆ ಕೈಯಾರೆ ಬರೆದ intrinsics ಗಿಂತ compiler ಒಂದು loop ಅನ್ನು ಉತ್ತಮವಾಗಿ vectorize ಮಾಡುತ್ತದೆ. ಇಲ್ಲಿ ಶಿಸ್ತು ಎಂದರೆ ಅಳತೆ ಮಾಡುವುದು: profile ಮಾಡಿ, ಕಲ್ಪನೆ ಮಾಡಿಕೊಳ್ಳಿ (hypothesize), ಒಂದು variable ಅನ್ನು ಬದಲಾಯಿಸಿ, ಮತ್ತು ಮತ್ತೆ profile ಮಾಡಿ. ಈ engine ಅನ್ನು ಆ ಕಠಿಣ ಪರಿಶ್ರಮವನ್ನು (grind) ಆನಂದಿಸುವ ಜನರಿಂದ ನಿರ್ಮಿಸಲಾಗುತ್ತಿದೆ. ಒಂದು batch ನಿಂದ ಎರಡು ಮಿಲಿಸೆಕೆಂಡ್‌ಗಳನ್ನು ಕಡಿಮೆ ಮಾಡಲು ನೀವು ಎಂದಾದರೂ ಒಂದು ಮಧ್ಯಾಹ್ನವನ್ನು convolution loop ಅನ್ನು ಮರುಬರೆಯಲು ಕಳೆದಿದ್ದರೆ, ಆ ಸಂಸ್ಕೃತಿಯನ್ನು ನೀವು ಈಗಾಗಲೇ ಅರ್ಥಮಾಡಿಕೊಂಡಿದ್ದೀರಿ ಎಂದರ್ಥ.

ನಮಗೆ ಯಾರು ಬೇಕು

ಇದು ಒಬ್ಬ ವ್ಯಕ್ತಿಯ ಪ್ರದರ್ಶನವಲ್ಲ. ಶೂನ್ಯದಿಂದ backend ಅನ್ನು ನಿರ್ಮಿಸಲು ವಿಭಿನ್ನ ಕೌಶಲಗಳ ಅಗತ್ಯವಿದೆ, ಇವುಗಳು ಒಂದೇ ಮೆದುಳಿನಲ್ಲಿ ಅಪರೂಪವಾಗಿ ಒಂದಕ್ಕೊಂದು ಹೊಂದಿಕೆಯಾಗುತ್ತವೆ. ನೀವು ಇದನ್ನು ಓದುತ್ತಾ ಇದರಲ್ಲಿ ಭಾಗವಹಿಸಬೇಕೇ ಎಂದು ಯೋಚಿಸುತ್ತಿದ್ದರೆ, ನೀವು ಇಲ್ಲಿ ಹೊಂದಿಕೆಯಾಗಬಹುದು:

  • C++ ಡೆವಲಪರ್‌ಗಳು ಯಾರು ಆಧುನಿಕ ಮಾನದಂಡಗಳನ್ನು ತಿಳಿದಿದ್ದಾರೆ ಮತ್ತು ಟೆಂಪ್ಲೇಟ್‌ಗಳು ಯಾವಾಗ ಕಾಂಪೈಲೇಶನ್ ಬ್ಲೋಟ್ (compilation bloat) ಉಂಟುಮಾಡುತ್ತವೆ ಎಂಬುದು ಅವರಿಗೆ ತಿಳಿದಿದೆ. ಅಗತ್ಯವಿದ್ದಾಗ ರಾ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು (raw pointers) ಮತ್ತು ಸೂಕ್ತವಾದಾಗ ಸ್ಮಾರ್ಟ್ ಪಾಯಿಂಟರ್‌ಗಳನ್ನು (smart pointers) ಬಳಸಲು ನೀವು ನಿಪುಣರಾಗಿರಬೇಕು, ಮತ್ತು ಸಿಂಟ್ಯಾಕ್ಸ್ ಶುಗರ್ (syntax sugar) ಅಷ್ಟೇ ಬೈನರಿ ಗಾತ್ರದ ಬಗ್ಗೆಯೂ ನೀವು ಕಾಳಜಿ ವಹಿಸಬೇಕು.

  • ಗಣಿತ ತಜ್ಞರು (Math experts) ಯಾರು ಅಸಂಪ್ರದಾಯಿಕ ಆಕ್ಟಿವೇಷನ್‌ಗಳಿಗಾಗಿ (non-standard activations) ಬ್ಯಾಕ್‌ವರ್ಡ್-ಪಾಸ್ ಗ್ರೇಡಿಯಂಟ್‌ಗಳನ್ನು (backward-pass gradients) ಪಡೆಯಬಲ್ಲರು, ಮಿಕ್ಸ್ಡ್-ಪ್ರಿಸಿಸನ್ ಟ್ರೈನಿಂಗ್‌ನಲ್ಲಿ ನಂಬರಿಕಲ್ ಸ್ಟೆಬಿಲಿಟಿ (numerical stability) ಬಗ್ಗೆ ವಿಶ್ಲೇಷಿಸಬಲ್ಲರು ಮತ್ತು ಅಲ್ಗಾರಿದಮ್‌ಗಳು ಕೋಡ್ ಆಗುವ ಮೊದಲೇ ಅವುಗಳನ್ನು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಬಲ್ಲರು. ನಿಮಗೆ log-sum-exp ಟ್ರಿಕ್ ಏಕೆ ಮುಖ್ಯ ಎಂದು ವಿವರಿಸಲು ಸಾಧ್ಯವಾದರೆ, ನೀವು ಸರಿಯಾದ ಮಾನಸಿಕ ಸ್ಥಿತಿಯಲ್ಲಿದ್ದೀರಿ ಎಂದರ್ಥ.

  • ಲೋ-ಲೆವೆಲ್ ಮೆಮೊರಿ ತಜ್ಞರು (Low-level memory specialists) ಯಾರು ಅಲೋಕೇಟರ್‌ಗಳು (allocators), ಪೇಜ್ ಫಾಲ್ಟ್‌ಗಳು (page faults) ಮತ್ತು NUMA ಟೋಪೋಲಜಿ (NUMA topology) ಬಗ್ಗೆ ಯೋಚಿಸುತ್ತಾರೆ. ಗ್ರಾಫ್ ಎಕ್ಸಿಕ್ಯೂಷನ್‌ಗಾಗಿ ಇಂಜಿನ್‌ಗೆ ಮೆಮೊರಿ ಪೂಲ್‌ಗಳು, ಕರ್ನೆಲ್‌ಗಳಿಗಾಗಿ ಸ್ಕ್ರ್ಯಾಚ್ ಬಫರ್‌ಗಳು ಮತ್ತು ಮೆಮೊರಿ ಸೋರಿಕೆ (leaking) ಅಥವಾ ಫ್ರಾಗ್ಮೆಂಟೇಶನ್ ಇಲ್ಲದೆ ಟ್ರೈನಿಂಗ್ ಹಂತಗಳಾದ್ಯಂತ ಟೆನ್ಸರ್ ಸ್ಟೋರೇಜ್ ಅನ್ನು ಮರುಬಳಕೆ ಮಾಡುವ ತಂತ್ರಗಳು ಬೇಕಾಗುತ್ತವೆ.

  • ಸಿಸ್ಟಮ್ಸ್ ಇಂಜಿನಿಯರ್‌ಗಳು (Systems engineers) ಯಾರು ಒಂದು ತಪ್ಪಾದ ಸಿಸ್ಟಮ್ ಕಾಲ್ (syscall) ಇಡೀ ಟ್ರೈನಿಂಗ್ ಲೂಪ್ ಅನ್ನು ಹೇಗೆ ಸ್ಥಗಿತಗೊಳಿಸಬಹುದು ಎಂಬುದನ್ನು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತಾರೆ. ಶೆಡ್ಯೂಲಿಂಗ್, I/O ಮತ್ತು ಸಿಂಕ್ರೊನೈಸೇಶನ್ ಪ್ರಿಮಿಟಿವ್ಸ್ (synchronization primitives) ಗಣಿತವನ್ನು ಒಟ್ಟಿಗೆ ಹಿಡಿದಿಡುವ ಅಂಟಿನಂತೆ ಕೆಲಸ ಮಾಡುತ್ತವೆ.

ನೀವು ಈ ನಾಲ್ಕೂ ಕ್ಷೇತ್ರಗಳಲ್ಲಿ ವಿಶ್ವದರ್ಜೆಯ ತಜ್ಞರಾಗಿರಬೇಕಾಗಿಲ್ಲ. ಹೆಚ್ಚಿನ ಕೊಡುಗೆದಾರರು ಒಂದು ಕರ್ನೆಲ್ ಅಥವಾ ಒಂದು ಅಲೋಕೇಟರ್ ಅನ್ನು ಹೊತ್ತುಕೊಂಡು ಪ್ರಾರಂಭಿಸುತ್ತಾರೆ ಮತ್ತು ಆರ್ಕಿಟೆಕ್ಚರ್ ಸ್ಥಿರವಾಗುತ್ತಿದ್ದಂತೆ ಉಳಿದವುಗಳನ್ನು ಕಲಿಯುತ್ತಾರೆ.

ಆರ್ಕಿಟೆಕ್ಚರ್ ಮತ್ತು ಕಸ್ಟಮ್ ಮ್ಯಾಥ್ (Architecture and Custom Math)

ಬ್ಯಾಕೆಂಡ್ ಲಾಜಿಕ್ ಅನ್ನು ಸಹಯೋಗದ ಮೂಲಕ ನಿರ್ಮಿಸಲಾಗುತ್ತಿದೆ ಮತ್ತು ಅದು ಆರ್ಕಿಟೆಕ್ಚರ್ ಚರ್ಚೆಗಳೊಂದಿಗೆ ಪ್ರಾರಂಭವಾಗುತ್ತದೆ. ಇಂಜಿನ್ ಸ್ಟ್ಯಾಟಿಕ್ ಕಂಪ್ಯೂಟೇಶನ್ ಗ್ರಾಫ್ ಅನ್ನು ಬಳಸುತ್ತದೆಯೇ, ಅಲ್ಲಿ ಇಡೀ ಮಾಡೆಲ್ ಅನ್ನು ರನ್‌ಟೈಮ್‌ಗಿಂತ ಮೊದಲು ವ್ಯಾಖ್ಯಾನಿಸಿ ಮತ್ತು ಆಪ್ಟಿಮೈಸ್ ಮಾಡಲಾಗುತ್ತದೆ? ಅಥವಾ ಆಟೋಮ್ಯಾಟಿಕ್ ಡಿಫರೆನ್ಸಿಯೇಷನ್‌ಗಾಗಿ ಟೇಪ್‌ನೊಂದಿಗೆ ಈಗರ್ ಎಕ್ಸಿಕ್ಯೂಷನ್ (eager execution) ಅನ್ನು ಬೆಂಬಲಿಸುತ್ತದೆಯೇ? ಆಟೋಡಿಫ್ (autodiff) ಅನ್ನು ಹೇಗೆ ಪ್ರತಿನಿಧಿಸಲಾಗುತ್ತದೆ—ಆಪರೇಟರ್ ಓವರ್‌ಲೋಡಿಂಗ್, ಸೋರ್ಸ್ ಟ್ರಾನ್ಸ್‌ಫರ್ಮೇಷನ್ ಅಥವಾ ಗ್ರಾಫ್ IR? ಈ ನಿರ್ಧಾರಗಳು ಉಳಿದೆಲ್ಲವನ್ನೂ ರೂಪಿಸುತ್ತವೆ.

ಕಸ್ಟಮ್ ನ್ಯೂರಲ್ ನೆಟ್ ಮ್ಯಾಥ್ ಎಂದರೆ ಕೇವಲ ಸ್ಟ್ಯಾಂಡರ್ಡ್ ಲೇಯರ್‌ಗಳನ್ನು ಮರು-ಅನುಷ್ಠಾನ ಮಾಡುವುದು ಮಾತ್ರವಲ್ಲ. ಇದರರ್ಥ ಹೊಸ ಲೇಯರ್‌ಗಳನ್ನು ಕಂಡುಹಿಡಿಯುವ ಸ್ವಾತಂತ್ರ್ಯ ಎಂದರ್ಥ. ನಿಮಗೆ ಅಸಂಪ್ರದಾಯಿಕ ಸ್ಪಾರ್ಸ್ ಕರ್ನೆಲ್ (non-standard sparse kernel) ಹೊಂದಿರುವ ಕನ್ವಲ್ಯೂಷನ್ ವೇರಿಯಂಟ್ ಬೇಕಿದ್ದರೆ ಅಥವಾ ಸಾಹಿತ್ಯದಲ್ಲಿ ಹೆಸರೇ ಇಲ್ಲದ ಆಕ್ಟಿವೇಷನ್ ಫಂಕ್ಷನ್ ಬೇಕಿದ್ದರೆ, ನೀವು C++ ಫಾರ್ವರ್ಡ್ ಮತ್ತು ಬ್ಯಾಕ್‌ವರ್ಡ್ ಪಾಸ್‌ಗಳನ್ನು ಬರೆದು ಅವುಗಳನ್ನು ನೇರವಾಗಿ ಇಂಜಿನ್‌ಗೆ ಪ್ಲಗ್ ಮಾಡಬಹುದು. ಇಲ್ಲಿ ಹೋರಾಡಲು ಯಾವುದೇ 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

ತಕ್ಷಣವೇ ಪಲ್ (pull request) ನೀಡಲು ಸಿದ್ಧರಿಲ್ಲದಿದ್ದರೂ, ಕೇವಲ ಚರ್ಚಿಸಲು, ಪ್ರಶ್ನೆಗಳನ್ನು ಕೇಳಲು ಅಥವಾ ಪ್ರಗತಿಯನ್ನು ಅನುಸರಿಸಲು ಬಯಸುವವರಿಗಾಗಿ ಟೆಲಿಗ್ರಾಮ್ ಗ್ರೂಪ್ ಕೂಡ ಇದೆ.

ಕಮ್ಯುನಿಟಿ: https://t.me/GyaanSetuAi

ನಿಜವಾದ ಸಾರಾಂಶ (The Real Takeaway)

ಆಧುನಿಕ AI ಸ್ಟ್ಯಾಕ್ ಒಂದು 'ಬ್ಲಾಕ್ ಬಾಕ್ಸ್' ಆಗಿಬಿಟ್ಟಿದೆ. ನಾವು ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳನ್ನು ಮ್ಯಾಜಿಕ್ ಉಪಕರಣಗಳಂತೆ ಪರಿಗಣಿಸುತ್ತೇವೆ: ಡೇಟಾ ಒಳಗೆ ಹೋಗುತ್ತದೆ, ಮಾಡೆಲ್ ಹೊರಗೆ ಬರುತ್ತದೆ ಮತ್ತು ಡಿಪ್ಲಾಯ್ಮೆಂಟ್ ಸಮಯದಲ್ಲಿ ಈ ಅಸ್ಪಷ್ಟತೆ ನಮಗೆ ತೊಂದರೆ ನೀಡದಿರಲಿ ಎಂದು ನಾವು ಆಶಿಸುತ್ತೇವೆ. CatAI ಆ ಸೌಕರ್ಯವನ್ನು ತಿರಸ್ಕರಿಸುತ್ತದೆ. ಈ ರೀತಿಯಾಗಿ ನಿರ್ಮಿಸುವುದು ನಿಧಾನವಾಗಬಹುದು. ನೀವು ಹೆಚ್ಚು ಕೋಡ್ ಬರೆಯುತ್ತೀರಿ, ಹೆಚ್ಚು segfaults ಅನ್ನು ಡಿಬಗ್ ಮಾಡುತ್ತೀರಿ ಮತ್ತು ಹೈ-ಲೆವೆಲ್ ಫ್ರೇಮ್‌ವರ್ಕ್‌ಗಳು ನಿಮ್ಮಿಂದ ಮರೆಮಾಚುವ ಕಲ್ಪನೆಗಳನ್ನು ಮರುಪರಿಶೀಲಿಸುತ್ತೀರಿ. ಆದರೆ ಯಂತ್ರವು ಏಕೆ ಹಾಗೆ ವರ್ತಿಸುತ್ತದೆ ಎಂಬುದನ್ನು ನೀವು ಅರ್ಥಮಾಡಿಕೊಳ್ಳುತ್ತೀರಿ. ಎಲ್ಲರೂ ಹಾರ್ಡ್‌ವೇರ್ ಅನ್ನು ಮರೆಮಾಚಲು (abstract away) ಪೈಪೋಟಿ ನಡೆಸುತ್ತಿರುವ ಈ ಉದ್ಯಮದಲ್ಲಿ, ವಿರುದ್ಧ ದಿಕ್ಕಿನಲ್ಲಿ ಹೋಗಿ ಹಾರ್ಡ್‌ವೇರ್‌ನೊಂದಿಗೆ ನೇರವಾಗಿ ಕೆಲಸ ಮಾಡುವುದು (touching the metal) ನಿಜವಾದ ಮೌಲ್ಯವನ್ನು ನೀಡುತ್ತದೆ. ಕೇವಲ APIಗಳನ್ನು ಕರೆಯುವವರಿಂದ ಸಿಸ್ಟಮ್‌ಗಳನ್ನು ನಿರ್ಮಿಸುವವರನ್ನು ಪ್ರತ್ಯೇಕಿಸುವುದು ಈ ತಿಳುವಳಿಕೆಯೇ.