A cada poucos meses, a comunidade de código aberto lança um novo framework de IA. A maioria deles envolve bindings de Python em torno de kernels pesados de C++, ou empilha camadas de abstração tão altas que apenas o runtime pesa mais do que os modelos que eles atendem. O CatAI segue a direção oposta. É um motor de IA nativo escrito inteiramente em C++, construído a partir da matemática de tensores para cima. O objetivo não é criar apenas mais uma interface amigável sobre o PyTorch. O objetivo é controlar cada byte de memória e cada ciclo de computação, começando na fronteira do hardware.

Por que outro motor?

Se você já colocou algo em produção, já conhece a dor. Coloque uma stack padrão de deep learning em um container e veja a imagem inflar para vários gigabytes. As dependências lutam entre si. O interpretador Python adiciona latência. O dispatcher que roteia as operações para CUDA ou CPU introduz um overhead sutil que se torna impossível de perfilar assim que desaparece em uma dúzia de frameworks aninhados. Para dispositivos edge, robótica embarcada ou backends sensíveis à latência, esse custo é real. Um motor puramente em C++ elimina o intermediário. Ele fala diretamente com o sistema operacional e o silício, sem garbage collection, sem global interpreter lock e sem a dança de serialização entre linguagens.

O CatAI trata isso como um recurso, não como uma concessão. O projeto está sendo escrito do zero em C++ porque o autor quer decidir exatamente como os tensores vivem na RAM, como eles se movem pelas hierarquias de cache e como os kernels são escalonados entre threads. Isso não é masoquismo. É a única maneira de garantir que o comportamento seja previsível quando você está extraindo o máximo de performance de um hardware limitado.

O que "do zero" realmente significa

Na maioria dos frameworks modernos, a matemática de tensores é tratada por chamadas opacas para bibliotecas de fornecedores como cuDNN, oneMKL ou MPS. Isso é perfeitamente sensato para entregas rápidas, mas esconde a mecânica da operação. O CatAI está escrevendo sua própria matemática de tensores central e layouts de memória. Isso significa projetar as estruturas de dados fundamentais que contêm arrays multidimensionais, escolher como strides e offsets são calculados e decidir se os dados serão armazenados em formatos row-major, column-major ou tiled customizados, dependendo do padrão de acesso.

Este é um trabalho profundo de sistemas. Quando você escreve um kernel de multiplicação de matrizes à mão, você para de pensar em termos de torch.matmul e começa a pensar em linhas de cache L1, pressão de registradores e loop tiling. Você decide se faz o bloqueio para tiles de 32x32 ou 64x64 com base na largura SIMD da CPU de destino. Você alinha as alocações a limites de 64 bytes para que os carregamentos AVX-512 não cruzem as linhas de cache. Você questiona se o std::vector é o container correto para o armazenamento de tensores, ou se um arena allocator customizado oferece melhor localidade e zero fragmentação em todo um grafo de inferência.

O layout de memória é igualmente crítico. Um array n-dimensional ingênuo pode destruir a performance se os dados de imagem em channels-last forem acessados em um padrão channels-first. No CatAI, esses layouts são cidadãos de primeira classe, não pensamentos tardios tratados por um otimizador de grafo executado no momento da exportação.

A mentalidade de otimização

Otimização bare-metal soa como um termo da moda até que você comece a contar nanossegundos. Significa fundir operações para que os resultados intermediários nunca saiam dos registradores da CPU ou do cache L1. Significa implementar uma layer-norm seguida por uma GELU como um único kernel, economizando uma viagem inteira de ida e volta à DRAM. Significa escrever seu próprio thread pool em vez de depender dos padrões do OpenMP, porque você sabe que sua carga de trabalho é intermitente e você não quer que o runtime crie e junte threads a cada forward pass.

Também significa entender quando não escrever assembly. Às vezes, o compilador vetoriza um loop melhor do que intrinsics escritos à mão. A disciplina é a medição: perfilar, hipotetizar, mudar uma variável e perfilar novamente. Este motor está sendo construído por pessoas que gostam desse trabalho árduo. Se você já passou uma tarde reescrevendo um loop de convolução para economizar dois milissegundos de um batch, você já entende a cultura.

Quem precisamos

Isso não é um show de uma pessoa só. Construir um backend do zero requer habilidades distintas que raramente se sobrepõem em um único cérebro. Se você está lendo isso e considerando se deve entrar, aqui está onde você pode se encaixar:

  • 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.