כל כמה חודשים קהילת הקוד הפתוח משיקה framework AI חדש. רובם עוטפים Python bindings סביב kernels כבדים ב-C++, או שצורמים שכבות הפשטה כל כך גבוהות שזמן הריצה (runtime) לבדו שוקל יותר מהמודלים שהם משרתים. CatAI פועלת בכיוון ההפוך. זהו מנוע AI native שנכתב כולו ב-C++, ונבנה מלמטה למעלה, החל ממתמטיקת ה-tensors. המטרה היא לא ליצור עוד מעטפת ידידותית מעל PyTorch. המטרה היא לשלוט בכל בייט של זיכרון ובכל מחזור חישוב (compute cycle), החל מגבולות החומרה.

למה עוד מנוע?

אם העליתם משהו לסביבת ייצור (production), אתם כבר מכירים את הכאב. קחו stack סטנדרטי של למידה עמוקה לתוך container וצפו באימג' מתנפח למספר ג'יגה-בייטים. תלויות (dependencies) נלחמות זו בזו. ה-interpreter של Python מוסיף latency. ה-dispatcher שמנתב פעולות (ops) ל-CUDA או ל-CPU מכניס overhead דק שאי אפשר לבצע לו profiling ברגע שהוא נעלם בתוך תריסר frameworks מקוננים. עבור מכשירי edge, רובוטיקה משובצת (embedded robotics) או backends רגישים ל-latency, המס שמשלמים הוא אמיתי. מנוע C++ טהור מבטל את המתווך. הוא מדבר ישירות עם מערכת ההפעלה והסיליקון, ללא garbage collection, ללא global interpreter lock, וללא "ריקוד" ה-serialization בין שפות.

CatAI מתייחסת לכך כאל תכונה (feature), ולא כאל פשרה. הפרויקט נכתב מאפס ב-C++ כי המחבר רוצה להחליט בדיוק איך tensors חיים ב-RAM, איך הם נעים דרך היררכיות ה-cache, ואיך kernels מתוזמנים (scheduled) בין threads. זה לא מסוכנות. זו הדרך היחידה להבטיח שההתנהגות תהיה צפויה כשמנסים לסחוט ביצועים מחומרה מוגבלת.

מה המשמעות האמיתית של "מאפס"

ברוב ה-frameworks המודרניים, מתמטיקת ה-tensor מטופלת על ידי קריאות אטומיות (opaque) לספריות של יצרנים כמו cuDNN, oneMKL, או MPS. זה הגיוני לחלוטין כדי לשחרר מוצר מהר, אבל זה מסתיר את המכניקה של הפעולה. CatAI כותבת את מתמטיקת ה-tensor הליבתית ואת פריסות הזיכרון (memory layouts) שלה. זה אומר לתכנן את מבני הנתונים הבסיסיים שמחזיקים מערכים רב-ממדיים, לבחור כיצד מחושבים strides ו-offsets, ולהחליט אם לאחסן נתונים בפורמט row-major, column-major, או tiled מותאם אישית, בהתאם לדפוס הגישה (access pattern).

זו עבודת מערכות עמוקה (deep systems work). כשכותבים kernel של כפל מטריצות ביד, מפסיקים לחשוב במונחים של torch.matmul ומתחילים לחשוב על L1 cache lines, register pressure ו-loop tiling. מחליטים אם לבצע blocking עבור tiles של 32x32 או 64x64 בהתאם לרוחב ה-SIMD של ה-CPU היעד. מבצעים alignment להקצאות (allocations) לגבולות של 64-bytes כדי שטעינות AVX-512 לא יחצו cache lines. שואלים את עצמכם אם std::vector הוא ה-container הנכון לאחסון tensors, או האם custom arena allocator ייתן לכם locality טובה יותר ואפס fragmentation לאורך כל ה-inference graph.

פריסת הזיכרון (Memory layout) קריטית באותה מידה. מערך n-ממדי נאיבי יכול להרוס ביצועים אם ניגשים לנתוני תמונה בפורמט channels-last בתבנית של channels-first. ב-CatAI, הפריסות הללו הן "אזרחים מסדר ראשון" (first-class citizens), ולא מחשבה בדיעבד שמטופלת על ידי graph optimizer שרץ בזמן ה-export.

תפיסת עולם של אופטימיזציה

אופטימיזציית bare-metal נשמעת כמו מילת באזז (buzzword) עד שמתחילים לספור ננו-שניות. זה אומר לבצע fusion של פעולות כך שתוצאות ביניים לעולם לא יעזבו את ה-CPU registers או את ה-L1 cache. זה אומר לממש layer-norm ואחריו GELU כ-kernel יחיד, מה שחוסך round-trip שלם ל-DRAM. זה אומר לכתוב thread pool משלך במקום להסתמך על ברירות המחדל של OpenMP, כי אתה יודע שהעומס שלך הוא bursty ואתה לא רוצה שה-runtime יצור (spawning) ויחבר (joining) threads בכל forward pass.

זה גם אומר להבין מתי לא לכתוב assembly. לפעמים הקומפיילר מבצע vectorization ללולאה טוב יותר מאשר intrinsics שנכתבו ביד. המשמעת היא מדידה: profile, השערה, שינוי משתנה אחד, ו-profile שוב. המנוע הזה נבנה על ידי אנשים שנהנים מהעבודה הקשה הזו (grind). אם אי פעם בילית אחר צהריים בכתיבה מחדש של convolution loop כדי לחסוך שני מילי-שניות מ-batch, אתה כבר מבין את התרבות.

מי אנחנו צריכים

זה לא מופע של אדם אחד. בניית backend מאפס דורשת מיומנויות מובחנות שרק לעיתים רחוקות מצטלבות במוח אחד. אם אתם קוראים את זה ושוקלים להצטרף, הנה המקומות שבהם אתם עשויים להתאים:

  • C++ developers who know modern standards but also know when templates cause compilation bloat. You should be comfortable with raw pointers when necessary and smart pointers when appropriate, and you should care about binary size as much as syntax sugar.

  • Math experts who can derive backward-pass gradients for non-standard activations, reason about numerical stability in mixed-precision training, and optimize algorithms before they become code. If you can explain why a log-sum-exp trick matters, you are in the right mental space.

  • Low-level memory specialists who think about allocators, page faults, and NUMA topology. The engine needs memory pools for graph execution, scratch buffers for kernels, and strategies for reusing tensor storage across training steps without leaking or fragmenting.

  • Systems engineers who understand how a misplaced syscall can stall an entire training loop. Scheduling, I/O, and synchronization primitives are the glue that holds the math together.

You do not need to be a world-class specialist in all four areas. Most contributors will start by owning one kernel or one allocator and learning the rest as the architecture solidifies.

Architecture and Custom Math

The backend logic is being built collaboratively, and that starts with architecture debates. Will the engine use a static computation graph, where the entire model is defined and optimized before runtime? Or will it support eager execution with a tape for automatic differentiation? How will autodiff be represented—operator overloading, source transformation, or a graph IR? These decisions shape everything else.

Custom neural net math means more than reimplementing standard layers. It means the freedom to invent new ones. If you want a convolution variant with a non-standard sparse kernel or an activation function that has no name in the literature, you write the C++ forward and backward passes and plug them directly into the engine. There is no Python API to fight, no monkey-patching required. The math is the code, and the code is the interface.

How to Get Involved

If this resonates, the full project breakdown and current roadmap are documented in detail on the author’s Dev.to post. You can read the specifics, see what has been built so far, and understand exactly where help is needed.

Project details: https://dev.to/banana_cool/building-a-native-c-ai-engine-catai-from-scratch-looking-for-collaborators-l8m

There is also a Telegram group for anyone who wants to hang out, ask questions, or follow progress without committing to a pull request immediately.

Community: https://t.me/GyaanSetuAi

The Real Takeaway

The modern AI stack has become a black box. We treat frameworks like magic appliances: data goes in, model comes out, and we hope the opacity does not bite us at deployment. CatAI rejects that comfort. It is slower to build this way. You will write more code, debug more segfaults, and rethink assumptions that higher-level frameworks hide from you. But you will also understand why the machine behaves the way it does. In an industry where everyone is racing to abstract away the hardware, there is real value in going the other direction and touching the metal. That understanding is what separates someone who calls APIs from someone who builds systems.