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:

  • Développeurs C++ qui maîtrisent les standards modernes mais savent aussi quand les templates provoquent un gonflement de la compilation. Vous devez être à l'aise avec les pointeurs bruts (raw pointers) quand nécessaire et les pointeurs intelligents (smart pointers) quand c'est approprié, et vous devez accorder autant d'importance à la taille du binaire qu'au sucre syntaxique (syntax sugar).

  • Experts en mathématiques capables de dériver les gradients de la passe arrière (backward-pass) pour des activations non standard, de raisonner sur la stabilité numérique en entraînement à précision mixte, et d'optimiser les algorithmes avant qu'ils ne deviennent du code. Si vous pouvez expliquer pourquoi l'astuce log-sum-exp est importante, vous êtes dans le bon état d'esprit.

  • Spécialistes de la mémoire bas niveau qui pensent en termes d'allocateurs, de défauts de page (page faults) et de topologie NUMA. Le moteur nécessite des pools de mémoire pour l'exécution de graphes, des tampons de travail (scratch buffers) pour les kernels, et des stratégies de réutilisation du stockage des tenseurs à travers les étapes d'entraînement sans fuite ni fragmentation.

  • Ingénieurs systèmes qui comprennent comment un appel système (syscall) mal placé peut bloquer une boucle d'entraînement entière. L'ordonnancement (scheduling), les E/S (I/O) et les primitives de synchronisation sont le liant qui maintient les mathématiques ensemble.

Vous n'avez pas besoin d'être un spécialiste de classe mondiale dans ces quatre domaines. La plupart des contributeurs commenceront par prendre en charge un kernel ou un allocateur, puis apprendront le reste à mesure que l'architecture se solidifie.

Architecture et mathématiques personnalisées

La logique backend est construite de manière collaborative, et cela commence par des débats sur l'architecture. Le moteur utilisera-t-il un graphe de calcul statique, où l'ensemble du modèle est défini et optimisé avant l'exécution ? Ou supportera-t-il l'exécution immédiate (eager execution) avec une tape pour la différenciation automatique ? Comment l'autodiff sera-t-elle représentée — surcharge d'opérateurs (operator overloading), transformation de code source ou IR de graphe ? Ces décisions façonnent tout le reste.

Les mathématiques personnalisées pour réseaux de neurones signifient plus que la simple réimplémentation de couches standard. Cela signifie la liberté d'en inventer de nouvelles. Si vous voulez une variante de convolution avec un kernel creux (sparse kernel) non standard ou une fonction d'activation sans nom dans la littérature, vous écrivez les passes avant (forward) et arrière (backward) en C++ et les branchez directement dans le moteur. Il n'y a pas d'API Python contre laquelle lutter, pas de monkey-patching requis. Les mathématiques sont le code, et le code est l'interface.

Comment s'impliquer

Si cela vous parle, la décomposition complète du projet et la feuille de route actuelle sont documentées en détail sur le post Dev.to de l'auteur. Vous pouvez lire les détails, voir ce qui a été construit jusqu'à présent et comprendre exactement où l'aide est nécessaire.

Détails du projet : https://dev.to/banana_cool/building-a-native-c-ai-engine-catai-from-scratch-looking-for-collaborators-l8m

Il existe également un groupe Telegram pour tous ceux qui souhaitent discuter, poser des questions ou suivre les progrès sans s'engager immédiatement dans une pull request.

Communauté : https://t.me/GyaanSetuAi

L'essentiel à retenir

La pile technologique (stack) de l'IA moderne est devenue une boîte noire. Nous traitons les frameworks comme des appareils magiques : les données entrent, le modèle sort, et nous espérons que l'opacité ne nous jouera pas de tours lors du déploiement. CatAI rejette ce confort. Construire de cette manière est plus lent. Vous écrirez plus de code, déboguerez plus de segfaults et repenserez des hypothèses que les frameworks de plus haut niveau vous cachent. Mais vous comprendrez aussi pourquoi la machine se comporte ainsi. Dans une industrie où tout le monde se précipite pour abstraire le matériel, il y a une réelle valeur à aller dans l'autre sens et à « toucher le métal » (touching the metal). Cette compréhension est ce qui distingue celui qui appelle des API de celui qui construit des systèmes.