Every few months the open-source community mints another AI framework. Most of them wrap Python bindings around heavy C++ kernels, or they stack abstraction layers so high that the runtime alone weighs more than the models they serve. CatAI moves in the opposite direction. It is a native AI engine written entirely in C++, built from the tensor math upward. The point is not to create yet another friendly skin over PyTorch. The point is to own every byte of memory and every cycle of compute, starting at the hardware boundary.

Why Another Engine?

If you have shipped anything to production, you already know the pain. Pull a standard deep-learning stack into a container and watch the image bloat to multiple gigabytes. Dependencies fight each other. The Python interpreter adds latency. The dispatcher that routes ops to CUDA or CPU introduces subtle overhead that becomes impossible to profile once it disappears into a dozen nested frameworks. For edge devices, embedded robotics, or latency-sensitive backends, that tax is real. A pure C++ engine eliminates the middleman. It talks to the operating system and the silicon directly, with no garbage collection, no global interpreter lock, and no serialization dance between languages.

CatAI treats this as a feature, not a compromise. The project is being written from scratch in C++ because the author wants to decide exactly how tensors live in RAM, how they move through cache hierarchies, and how kernels are scheduled across threads. That is not masochism. It is the only way to guarantee that behavior is predictable when you are squeezing performance out of limited hardware.

What “From Scratch” Actually Means

In most modern frameworks, tensor math is handled by opaque calls into vendor libraries like cuDNN, oneMKL, or MPS. That is perfectly sensible for shipping fast, but it hides the mechanics of the operation. CatAI is writing its own core tensor math and memory layouts. That means designing the fundamental data structures that hold multi-dimensional arrays, choosing how strides and offsets are calculated, and deciding whether to store data in row-major, column-major, or custom tiled formats depending on the access pattern.

This is deep systems work. When you write a matrix-multiply kernel by hand, you stop thinking in terms of torch.matmul and start thinking about L1 cache lines, register pressure, and loop tiling. You decide whether to block for 32x32 tiles or 64x64 based on the SIMD width of the target CPU. You align allocations to 64-byte boundaries so AVX-512 loads do not cross cache lines. You question whether std::vector is the right container for tensor storage, or whether a custom arena allocator gives you better locality and zero fragmentation across an entire inference graph.

Memory layout is equally critical. A naive naïve n-dimensional array can kill performance if the channels-last image data is accessed in a channels-first pattern. In CatAI, these layouts are first-class citizens, not afterthoughts handled by a graph optimizer running at export time.

The Optimization Mindset

Bare-metal optimization sounds like a buzzword until you start counting nanoseconds. It means fusing operations so intermediate results never leave the CPU registers or L1 cache. It means implementing a layer-norm followed by a GELU as a single kernel, saving an entire round-trip to DRAM. It means writing your own thread pool instead of leaning on OpenMP defaults, because you know your workload is bursty and you do not want the runtime spawning and joining threads every forward pass.

It also means understanding when not to write assembly. Sometimes the compiler vectorizes a loop better than hand-written intrinsics. The discipline ismeasurement: profile, hypothesize, change one variable, and profile again. This engine is being built by people who enjoy that grind. If you have ever spent an afternoon rewriting a convolution loop to shave two milliseconds off a batch, you already understand the culture.

Who We Need

This is not a one-person show. Building a backend from zero requires distinct skills that rarely overlap in a single brain. If you are reading this and considering whether to jump in, here is where you might fit:

  • توسعه‌دهندگان C++ که با استانداردهای مدرن آشنا هستند اما می‌دانند چه زمانی استفاده از قالب‌ها (templates) باعث حجیم شدن فرآیند کامپایل می‌شود. شما باید در صورت نیاز با اشاره‌گرهای خام (raw pointers) و در صورت لزوم با اشاره‌گرهای هوشمند (smart pointers) راحت باشید و اندازه باینری را به اندازه امکانات تسهیل‌کننده سینتکس (syntax sugar) مهم بدانید.

  • متخصصان ریاضی که می‌توانند گرادیان‌های پس‌گذر (backward-pass) را برای توابع فعال‌ساز غیر استاندارد استخراج کنند، درباره پایداری عددی در آموزش با دقت ترکیبی (mixed-precision training) استدلال کنند و الگوریتم‌ها را پیش از تبدیل شدن به کد، بهینه کنند. اگر می‌توانید توضیح دهید که چرا ترفند log-sum-exp اهمیت دارد، در فضای ذهنی درستی هستید.

  • متخصصان حافظه در سطح پایین (low-level) که به تخصیص‌دهنده‌ها (allocators)، خطاهای صفحه (page faults) و توپولوژی NUMA فکر می‌کنند. این موتور برای اجرای گراف به استخرهای حافظه (memory pools)، برای کرنل‌ها به بافرهای موقت (scratch buffers) و برای استراتژی‌های بازاستفاده از ذخیره‌سازی تنسور در مراحل مختلف آموزش (بدون نشت یا تکه‌تکه شدن حافظه) نیاز دارد.

  • مهندسان سیستم که درک می‌کنند چگونه یک فراخوانی سیستم (syscall) اشتباه می‌تواند کل حلقه آموزش را متوقف کند. زمان‌بندی (scheduling)، ورودی/خروجی (I/O) و پرایمت‌های همگام‌سازی (synchronization primitives)، چسبی هستند که ریاضیات را در کنار هم نگه می‌دارند.

نیازی نیست در هر چهار حوزه یک متخصص تراز اول جهانی باشید. اکثر مشارکت‌کنندگان با مالکیت یک کرنل یا یک تخصیص‌دهنده شروع می‌کنند و با تثبیت معماری، بقیه موارد را می‌آموزند.

معماری و ریاضیات سفارشی

منطق بک‌اند (backend) به صورت مشارکتی در حال ساخته شدن است و این کار با بحث‌های معماری شروع می‌شود. آیا موتور از یک گراف محاسباتی ایستا (static computation graph) استفاده خواهد کرد که در آن کل مدل قبل از زمان اجرا تعریف و بهینه می‌شود؟ یا از اجرای فوری (eager execution) همراه با یک نوار (tape) برای مشتق‌گیری خودکار (automatic differentiation) پشتیبانی خواهد کرد؟ روش نمایش autodiff چگونه خواهد بود—سربارگذاری عملگر (operator overloading)، تبدیل منبع (source transformation) یا یک IR گراف؟ این تصمیمات همه چیز را شکل می‌دهند.

ریاضیات سفارشی شبکه‌های عصبی چیزی فراتر از پیاده‌سازی مجدد لایه‌های استاندارد است. این یعنی آزادی برای اختراع لایه‌های جدید. اگر یک گونه از کانولوشن (convolution) با یک کرنل پراکنده (sparse kernel) غیر استاندارد یا یک تابع فعال‌ساز (activation function) که در ادبیات علمی نامی ندارد می‌خواهید، پاس‌های رفت (forward) و برگشت (backward) را به زبان C++ می‌نویسید و آن‌ها را مستقیماً در موتور جایگذاری می‌کنید. هیچ API پایتونی برای جنگیدن با آن وجود ندارد و نیازی به monkey-patching نیست. ریاضیات همان کد است و کد همان رابط (interface) است.

چگونه مشارکت کنیم

اگر این موضوع برای شما ملموس است، شرح کامل پروژه و نقشه راه فعلی با جزئیات در پست 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

نتیجه‌گیری اصلی

پشته (stack) مدرن هوش مصنوعی به یک جعبه سیاه تبدیل شده است. ما با فریم‌ورک‌ها مانند ابزارهای جادویی برخورد می‌کنیم: داده وارد می‌شود، مدل خارج می‌شود و امیدواریم که این ابهام در زمان استقرار (deployment) به ضرر ما نباشد. CatAI این راحتی را رد می‌کند. ساختن پروژه به این روش کندتر است. شما کد بیشتری خواهید نوشت، خطاهای segfault بیشتری را عیب‌یابی خواهید کرد و پیش‌فرض‌هایی را که فریم‌ورک‌های سطح بالاتر از شما پنهان می‌کنند، دوباره بازنگری خواهید کرد. اما همچنین درک خواهید کرد که چرا ماشین به این شکل رفتار می‌کند. در صنعتی که همه برای انتزاع سخت‌افزار (abstract away the hardware) در حال رقابت هستند، ارزش واقعی در حرکت در جهت مخالف و تعامل مستقیم با سخت‌افزار (touching the metal) نهفته است. این درک همان چیزی است که یک فرد را از کسی که فقط APIها را فراخوانی می‌کند، به کسی که سیستم‌ها را می‌سازد، تبدیل می‌کند.