GGML on kenji.blog

¡No necesitas Python! Construí un motor de inferencia de IA solo con C++

Fri, 11 Sep 2026 17:00:00 +0900

1. Introducción: ¿Por qué dejar Python y crear un motor de inferencia de IA en C++?

En el desarrollo de IA moderno, Python es el estándar de facto. Gracias a la ventaja de frameworks potentes como PyTorch o TensorFlow, puedes construir, entrenar e inferir redes neuronales complejas con unas pocas líneas de código. Sin embargo, detrás de estos frameworks, lenguajes de bajo nivel como C++ y CUDA se encargan del procesamiento computacional pesado. Python simplemente juega el papel de “pegamento” (glue).

Entonces, ¿por qué molestarse en eliminar Python y crear un motor de inferencia de IA usando únicamente C++? Hay varias razones de peso para ello.

Rendimiento extremo y baja latencia: Puedes eliminar por completo la sobrecarga causada por el GIL (Global Interpreter Lock) de Python y su tipado dinámico. Especialmente en sistemas que requieren tiempo real, un retraso de milisegundos puede ser fatal.
Facilidad de implementación (Deployment): Construir un entorno de Python (una enorme colección de bibliotecas, un infierno de dependencias) en el entorno del usuario final es extremadamente difícil. Con C++, solo necesitas distribuir un único binario ejecutable enlazado estáticamente (un .exe o binario ELF).
Compatibilidad con dispositivos Edge: En entornos con recursos estrictamente limitados, como teléfonos inteligentes, dispositivos integrados o Raspberry Pi, no hay margen para ejecutar un entorno de ejecución de Python que consume varios gigabytes de memoria.
Control directo del hardware: C++ permite el control a bajo nivel, como la temporización de la asignación de memoria, el uso explícito de instrucciones SIMD y la optimización de las transferencias de memoria con la GPU.

En este artículo, basándome en gran medida en la arquitectura de la biblioteca “GGML” desarrollada por Georgi Gerganov, explicaré el proceso de construir desde cero un motor de inferencia para ejecutar modelos de lenguaje grande (LLM) usando solo C++, sumergiéndonos en las profundidades técnicas.

2. Visión general de la arquitectura del motor de inferencia

El procesamiento de inferencia de IA es esencialmente una “sucesión de enormes cálculos matriciales”. Para ejecutar esto de manera eficiente, un motor de inferencia debe estar compuesto por los siguientes componentes.

graph TD A["Datos de Entrada (Tokens/Imágenes)"] --> B["Gestión de Tensores"] B --> C["Grafo de Computación (DAG)"] C --> D["Memory Arena y Asignador"] C --> E["Planificador y Pool de Hilos"] E --> F["Backend de CPU (AVX2/ARM NEON)"] E --> G["Backend de GPU (CUDA/Metal)"] F --> H["Resultados de Salida"] G --> H

Gestión de Tensores (Tensor): Gestiona las estructuras de datos de matrices multidimensionales y el stride de cada dimensión.
Grafo de Computación (Computation Graph): Representa las operaciones de cada capa de la red neuronal como un Grafo Acíclico Dirigido (DAG).
Memory Arena (Arena de Memoria): Un mecanismo de gestión de memoria preasignada para evitar la sobrecarga de la asignación de memoria dinámica (malloc o new).
Backend: Implementaciones de cálculos (kernels) optimizadas para hardware específico, como CPU o GPU.

Ensamblaremos estos componentes utilizando las poderosas características de C++ (plantillas, aritmética de punteros, RAII, etc.).

3. El secreto de la gestión de memoria: Memory Arena y Alineación SIMD

La gestión de memoria en un motor de inferencia es uno de los factores más importantes directamente relacionados con el rendimiento. Durante la inferencia, especialmente al pasar a través de cada capa de un modelo Transformer, se genera una enorme cantidad de tensores intermedios. Si se asignan y liberan cada vez con el malloc estándar, la fragmentación del montón (heap) y los cambios de contexto del sistema operativo causarán caídas drásticas y fatales en la velocidad.

Por lo tanto, adoptamos el enfoque de un “Memory Arena”. Este es un método en el que se calcula (o se fija) y se asigna de una sola vez la cantidad máxima de memoria necesaria al inicio de la inferencia, y luego la memoria se extrae simplemente incrementando un puntero.

3.1 La importancia de la alineación

Las CPU modernas admiten instrucciones SIMD (Single Instruction, Multiple Data). Ejemplos son AVX2/AVX-512 de Intel/AMD y NEON de ARM. Estas instrucciones procesan datos de 256 bits (32 bytes) o 512 bits (64 bytes) a la vez, pero la memoria de datos objetivo debe estar alineada (alineación) a un límite de bytes específico (generalmente 32 o 64 bytes).

A continuación se muestra un ejemplo de implementación en C++ de un Memory Arena considerando la alineación.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45


#include <cstdint>
#include <cstddef>
#include <stdexcept>
#include <iostream>

struct MemoryArena {
 size_t size;
 size_t offset;
 uint8_t* data;

 MemoryArena(size_t size) : size(size), offset(0) {
 // Usa posix_memalign en sistemas POSIX, o _aligned_malloc en Windows
#ifdef _WIN32
 data = static_cast<uint8_t*>(_aligned_malloc(size, 64));
#else
 if (posix_memalign(reinterpret_cast<void**>(&data), 64, size) != 0) {
 throw std::bad_alloc();
 }
#endif
 }

 ~MemoryArena() {
#ifdef _WIN32
 _aligned_free(data);
#else
 free(data);
#endif
 }

 void* allocate(size_t bytes, size_t alignment = 64) {
 // Cálculo de alineación (buscar el padding)
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena se quedó sin memoria");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // Liberar memoria es tan simple como reiniciar el puntero (O(1))
 }
};

De esta manera, al crear un tensor, siempre se obtiene memoria a través de esta arena. Al final de cada paso de inferencia (por ejemplo, después de generar un token), simplemente llamando a reset(), la memoria se puede reutilizar instantáneamente.

4. Estructura de datos de tensores y la magia de los Strides

Un tensor es un concepto que generaliza escalares, vectores y matrices. Lo importante en la implementación es que, mientras los datos reales se ubican en la memoria como un arreglo unidimensional contiguo, tiene el concepto de un “Stride” para interpretarlo como multidimensional.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19


enum class DataType {
 FP32,
 FP16,
 INT8, // Para cuantización
 INT4 // Para cuantización
};

struct Tensor {
 int n_dims; // Número de dimensiones
 int64_t ne[4]; // Número de elementos en cada dimensión (Number of Elements)
 size_t nb[4]; // Stride en cada dimensión (Number of Bytes)
 DataType type; // Tipo de dato
 void* data; // Puntero al payload

 // Para el grafo de computación
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

El stride nb[i] representa la distancia en bytes en la memoria entre elementos adyacentes en la dimensión i. Por ejemplo, si una matriz con un número de elementos $M \times N$ (FP32, 4 bytes por elemento) se almacena en orden Row-Major (prioridad de fila), los strides serían los siguientes:

nb[0] = 4 (bytes) : Movimiento en dirección de las columnas
nb[1] = $N \times 4$ (bytes) : Movimiento en dirección de las filas

Aprovechando esto, puedes lograr operaciones como “Transposición (Transpose)” y “Vista (View)” simplemente intercambiando los valores de los strides, sin implicar copias de memoria. Es sumamente elegante y rápido.

5. Construcción del Grafo de Computación (DAG) y Evaluación Perezosa

Al igual que PyTorch, nuestro motor de inferencia también adopta una Evaluación Perezosa (Lazy Evaluation), similar a “Define-by-Run”. Es decir, cuando se llama a una función de cálculo, no realiza el cálculo en ese momento, sino que solo construye un grafo (dependencias entre nodos).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


Tensor* tensor_add(MemoryArena& arena, Tensor* a, Tensor* b) {
 Tensor* out = create_tensor(arena, a->type, a->n_dims, a->ne);
 out->op = OpType::ADD;
 out->src0 = a;
 out->src1 = b;
 return out;
}

Tensor* tensor_mul_mat(MemoryArena& arena, Tensor* a, Tensor* b) {
 // b a menudo está transpuesta
 int64_t ne[2] = { a->ne[0], b->ne[1] };
 Tensor* out = create_tensor(arena, a->type, 2, ne);
 out->op = OpType::MUL_MAT;
 out->src0 = a;
 out->src1 = b;
 return out;
}

El flujo del proceso de inferencia es el siguiente.

graph LR A["Definir Tensores"] --> B["Construir Grafo mediante Operaciones"] B --> C["Ordenamiento Topológico"] C --> D["Asignar Memoria para Salidas"] D --> E["Ejecutar Nodos en Orden"]

Al evaluar el grafo (forward pass), se utiliza el ordenamiento topológico para procesar los nodos en orden comenzando por aquellos sin dependencias. Si es solo inferencia, no es necesario mantener gradientes para backpropagation, por lo que la gestión de memoria es muy sencilla.

6. El núcleo de las matemáticas y la optimización: Producto de Matrices (GEMM)

Más del 90% de la carga computacional de la inferencia de IA se gasta en la multiplicación general de matrices (GEMM: General Matrix Multiply). Tanto el mecanismo de atención, que es el núcleo del modelo Transformer, como las redes feed-forward (FFN), son en última instancia enormes multiplicaciones de matrices.

El producto $C = A B$ (de tamaño $M \times N$) de dos matrices $A$ (tamaño $M \times K$) y $B$ (tamaño $K \times N$) se expresa matemáticamente de la siguiente manera.

$$ C_{i,j} = \sum_{k=0}^{K-1} A_{i,k} \cdot B_{k,j} $$

Si se implementa ingenuamente usando un triple bucle, habrá frecuentes fallos de caché y no se logrará rendimiento.

6.1 Bloqueo de caché y optimización SIMD en la CPU

La estrategia básica para acelerar GEMM en la CPU es la siguiente:

Loop Tiling (Bloqueo de Caché): Divide las matrices en pequeños bloques que caben en las cachés L1/L2 para el cálculo.
Empaquetado de Datos: Reorganiza internamente los datos para que el patrón de acceso a la memoria sea contiguo.
Uso de SIMD: Usa comandos FMA (Fused Multiply-Add) como _mm512_fmadd_ps en AVX-512, manejando múltiples cálculos de multiplicación y suma en un solo ciclo de reloj.

A continuación se muestra un ejemplo de un Producto Punto (Dot Product) de vectores simplificado, utilizando C++ y SIMD Intrinsics.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


#include <immintrin.h> // Para instrucciones AVX

// Producto punto rápido FP32 usando AVX2
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // Procesar 8 elementos a la vez (256 bits = 32 bytes = 8 * 4 bytes)
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // Instrucción FMA: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // Suma horizontal de los valores en el registro SIMD
 float result[8];
 _mm256_storeu_ps(result, sum256);
 float dot = result[0] + result[1] + result[2] + result[3] +
 result[4] + result[5] + result[6] + result[7];

 // Procesamiento del resto
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

Incluso con este pequeño ajuste, puedes obtener un aumento de velocidad de varias a decenas de veces en comparación con una implementación ingenua.

7. Superando la barrera del hardware: Integración de Backends CUDA y Metal

Aunque solo con la implementación pura en C++ funcionará de manera decente en la CPU, para ejecutar modelos enormes como LLMs a una velocidad práctica (por ejemplo: generar 20 tokens o más por segundo), la capacidad de cálculo en paralelo de la GPU es indispensable. Por lo tanto, introducimos una capa de abstracción de backend en nuestro motor.

7.1 Abstracción del Backend

Usamos el polimorfismo de C++ para permitir el intercambio del ejecutor (Executor) de las operaciones.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class Backend {
public:
 virtual ~Backend() = default;
 virtual void alloc_buffer(Tensor* t) = 0;
 virtual void free_buffer(Tensor* t) = 0;
 virtual void copy_to_device(Tensor* t) = 0;
 virtual void copy_to_host(Tensor* t) = 0;

 // Ejecución de diversas operaciones
 virtual void compute_add(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
 virtual void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) = 0;
};

7.2 Implementación del Backend de NVIDIA CUDA

Para aprovechar la GPU de NVIDIA, implementamos un backend usando la extensión C++ de CUDA. Aunque es posible escribir tus propios kernels, para la multiplicación de matrices, la mejor opción es usar “cuBLAS”, la mejor biblioteca proporcionada por NVIDIA.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35


#include <cublas_v2.h>
#include <cuda_runtime.h>

class CUDABackend : public Backend {
private:
 cublasHandle_t handle;

public:
 CUDABackend() {
 cublasCreate(&handle);
 }

 ~CUDABackend() {
 cublasDestroy(handle);
 }

 void compute_mul_mat(Tensor* src0, Tensor* src1, Tensor* dst) override {
 // En CUDA, el orden por defecto es Column-Major, por lo que hay que tener cuidado con los parámetros
 const float alpha = 1.0f;
 const float beta = 0.0f;

 int m = src0->ne[0];
 int k = src0->ne[1];
 int n = src1->ne[1]; // Se asume que src1 está transpuesta

 cublasSgemm(handle, CUBLAS_OP_T, CUBLAS_OP_N,
 m, n, k,
 &alpha,
 (const float*)src0->data, k,
 (const float*)src1->data, k,
 &beta,
 (float*)dst->data, m);
 cudaDeviceSynchronize();
 }
};

Como las transferencias de datos (cudaMemcpy) entre la memoria de CUDA y la del host (CPU) son muy costosas, es vital diseñar un sistema que mantenga todos los pesos y tensores intermedios en la VRAM el mayor tiempo posible durante la inferencia.

7.3 Backend de Apple Silicon (Metal)

Recientemente, los chips M1/M2/M3 (Apple Silicon) de Mac son excelentes máquinas de inferencia de IA. La razón radica en su “Memoria Unificada”. Como la CPU y la GPU comparten la misma área de memoria, las transferencias de memoria de alto costo entre el host y el dispositivo a través de un bus PCIe, como en el caso de CUDA mencionado antes, son completamente innecesarias.

Para llamar a Metal desde C++, se usa Objective-C++ (archivos .mm) como puente, o la biblioteca metal-cpp. Escribiremos el kernel usando Compute Shaders de Metal (descrito en un archivo .metal de forma similar a C++).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


// Shader de Metal (kernel.metal)
#include <metal_stdlib>
using namespace metal;

kernel void mul_mat_kernel(
 device const float* A [[buffer(0)]],
 device const float* B [[buffer(1)]],
 device float* C [[buffer(2)]],
 constant uint3& dims [[buffer(3)]],
 uint2 gid [[thread_position_in_grid]]
) {
 uint m = dims.x; uint k = dims.y; uint n = dims.z;
 uint row = gid.y; uint col = gid.x;

 if (row < m && col < n) {
 float sum = 0.0;
 for (uint i = 0; i < k; ++i) {
 sum += A[row * k + i] * B[i * n + col]; // Simplificado
 }
 C[row * n + col] = sum;
 }
}

En el entorno de Apple Silicon, también se proporciona una biblioteca optimizada para multiplicación de matrices llamada MPS (Metal Performance Shaders), por lo que usarla en un entorno de producción puede lograr velocidades de inferencia asombrosas.

8. Procesamiento específico del modelo Transformer: Attention y Caché KV

Los LLM de vanguardia, como LLaMA 2/3 y GPT, se basan en la arquitectura Transformer. Para implementar esto en C++, la construcción del “Scaled Dot-Product Attention” expresado en la siguiente fórmula es indispensable.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{QK^T}{\sqrt{d_k}}\right)V $$

Además, en la generación de tokens autorregresiva (Autoregressive), es necesario mantener los resultados de cálculos de los tokens pasados (Key y Value). Esto se denomina “Caché KV (Key-Value Cache)”.

graph TD T["Token Actual"] --> Q["Consulta (Query)"] T --> K["Clave (Key)"] T --> V["Valor (Value)"] K --> KCache["Añadir a la Caché KV"] V --> VCache["Añadir a la Caché KV"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["Escalar (1/sqrt(d))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["Vector de Contexto"]

Para asignar memoria de la caché KV, asignamos en la arena de memoria por adelantado espacio suficiente para la longitud máxima de contexto (por ejemplo, 4096 u 8192 tokens) y lo operamos como un búfer circular (ring buffer). Esto evita las reasignaciones en cada paso de generación.

También, implementamos para la Codificación Posicional (Positional Encoding) el método “RoPE (Rotary Position Embedding)” que es el principal estándar reciente. Este es un método para incrustar información de posición como un vector de rotación en el espacio complejo, y la optimización de las llamadas a las funciones sin y cos en C++ (por ejemplo, mediante el uso de tablas de búsqueda) es clave para el rendimiento.

9. Optimización extrema mediante Cuantización de Modelos (Quantization)

Si cargas un modelo de gran escala (por ejemplo, un modelo LLaMA de 7 mil millones de parámetros) en FP32 (punto flotante de 32 bits), consumirá aproximadamente 28 GB de memoria (VRAM) solo para sus pesos. Además, al incluir la caché KV y los buffers de inferencia, puede sobrepasar fácilmente los 30 GB, haciendo que sea imposible de ejecutar en una GPU convencional de consumo.

Aquí es donde entra en juego la “Cuantización (Quantization)”. También es el verdadero valor del formato GGML.

La cuantización es una técnica que reduce intencionalmente la precisión de los pesos.

FP16 (16-bit): Reduce el tamaño a la mitad. Casi sin pérdida de precisión.
INT8 (8-bit): Un cuarto del tamaño. Pérdida menor de precisión.
INT4 (4-bit): Un octavo del tamaño. Usando técnicas propias de bloqueo y factores de escala, es posible hacer inferencias prácticas.

En el lado del motor de inferencia, se leen los pesos comprimidos como INT4 (o INT8) de la memoria, y justo después de cargarlos en los registros de la CPU o GPU, se descomprimen (Dequantize) a FP16 o FP32 para realizar los cálculos.

Sorprendentemente, resulta más rápido reducir la cantidad de datos que se leen desde la memoria, incluso si esto significa aumentar la cantidad de cálculos. Esto se debe a que, en el hardware moderno, el cuello de botella de la tarea de inferencia no es la “Capacidad de Cálculo (Compute Bound)” sino el “Ancho de Banda de la Memoria (Memory Bandwidth Bound)”. Con un motor implementado en C++ utilizando la cuantización INT4, es posible ejecutar localmente LLMs de manera fluida incluso en dispositivos como un MacBook Air con 8 GB de RAM unificada.

10. Ajuste de rendimiento: Arquitectura NUMA y Pool de Hilos

Cuando se realiza inferencia utilizando la CPU, el multiprocesamiento (multithreading) es obligatorio. Sin embargo, no es óptimo simplemente instanciar y lanzar muchas std::thread.

En los servidores multisocket modernos o en las CPU de gama alta como los Ryzen Threadripper, se adopta la arquitectura NUMA (Non-Uniform Memory Access). Acceder a la memoria que está físicamente cerca de un determinado núcleo de CPU (memoria local) es rápido, pero acceder a la memoria vinculada a otro procesador es extremadamente lento.

En un motor de inferencia avanzado en C++, se utilizan las siguientes técnicas:

Thread Pinning: Se fija cada hilo a un núcleo de CPU específico (configuración de Affinity) para evitar la pérdida de caché debido a los cambios de contexto.
Asignación consciente de NUMA: Asegura la memoria en el mismo nodo NUMA donde se encuentra el hilo que procesará los datos.
Pool de Hilos con Work-Stealing: Implementa un planificador eficiente que divide cada nodo del grafo de computación en pequeñas tareas, de manera que los hilos inactivos roben automáticamente tareas de otros para ejecutarlas.

Al dominar esto, es posible mantener el uso de la CPU pegado a cerca del 100% y lograr un rendimiento cercano al máximo teórico.

11. Conclusión: El placer de impulsar la IA con el “músculo” de C++

Python, sin duda, es conveniente. En investigación, desarrollo o creación de prototipos, no hay lenguaje que se le iguale en productividad. Sin embargo, en el momento en que se pasa a la fase de “hacer que el modelo ya construido funcione en el mundo real, de manera eficiente, en cualquier dispositivo”, es ahí donde C++ brilla.

Manipular los bytes de memoria directamente, presionar los registros al límite con instrucciones SIMD, luchar contra el ancho de banda de la VRAM de la GPU y ver cómo el motor de inferencia que has creado escupe textos (tokens) en un español natural en la consola, otorga un sentido de logro y una “alegría pura como ingeniero” que jamás obtendrías al solo llamar a model.generate() en un framework de Python.

Aunque la tecnología de la IA a menudo se considera una “Caja Negra” (Black Box), el simple hecho de programar cada detalle con tus propias manos en C++, desde los cálculos de tensores hasta la asignación de la memoria, te permite comprender profundamente los verdaderos mecanismos detrás de cómo los LLMs “piensan”.

Si tienes conocimientos básicos de C++ y un fuerte interés en la tecnología de IA actual, definitivamente deberías intentar construir tu propio motor de inferencia desde cero. El código fuente de GGML o llama.cpp será el mejor libro de texto en vivo que puedas tener.

¡Vamos, deshazte del pesado entorno de ejecución de Python y ejecuta la IA de vanguardia con los músculos de C++!

Guía de desarrollo de modelos de IA a pequeña escala (como TinyLLaMA) con C++

Fri, 11 Sep 2026 14:00:00 +0900

Guía de desarrollo de modelos de IA a pequeña escala (como TinyLLaMA) con C++

En los últimos años, el interés por ejecutar grandes modelos de lenguaje (LLM) en entornos locales ha crecido rápidamente. Especialmente, los modelos pequeños como TinyLLaMA (1.1B parámetros) pueden realizar inferencias a velocidades prácticas incluso en dispositivos periféricos (edge devices) con recursos limitados o computadoras portátiles comunes (incluyendo entornos Windows). Mientras que el desarrollo con Python y PyTorch es la corriente principal, cuando se busca el rendimiento máximo y la eficiencia de memoria, la combinación de C++ y “ggml”, una biblioteca de tensores basada en C, se ha convertido en el estándar de facto.

En este artículo, explicaremos en gran detalle el proceso de desarrollo para construir un motor de inferencia desde cero (o comprender profundamente la estructura interna del existente llama.cpp) para cargar TinyLLaMA y generar texto usando C++.

1. ¿Por qué C++ y ggml?

En la fase de entrenamiento de IA, Python tiene una ventaja abrumadora debido a su flexibilidad y rico ecosistema. Sin embargo, en las fases de despliegue e “Inferencia”, C++ se convierte en una opción poderosa por las siguientes razones:

Reducción de sobrecarga: Se puede eliminar por completo la sobrecarga del entorno de ejecución y del Global Interpreter Lock (GIL) de Python.
Eficiencia de memoria y asignación por arenas: Al poder controlar manualmente la asignación y liberación de memoria, se evitan los picos impredecibles causados por el recolector de basura.
Acceso directo al hardware: Se pueden invocar directamente funciones intrínsecas SIMD como AVX-512, AVX2 y ARM NEON para maximizar la capacidad de procesamiento de la CPU.
Eliminación de dependencias: ggml es una biblioteca C/C++ sin dependencias (Zero dependencies), y se puede compilar fácilmente incluso en un entorno MSVC en Windows siempre que haya un compilador.

2. Visión general de la arquitectura

El flujo completo del pipeline de inferencia se muestra en el siguiente diagrama Mermaid. Es un proceso continuo que comienza con el texto de entrada del usuario hasta que se genera el siguiente token final.

graph TD A["Texto de entrada del usuario"] --> B["Tokenizador BPE"] B --> C["Matriz de IDs de tokens"] C --> D["Búsqueda en la capa de incrustación"] D --> E["Bloques Transformer"] E --> F["RMSNorm"] F --> G["Capa LM Head"] G --> H["Matriz de Logits"] H --> I["Módulo muestreador"] I --> J["Siguiente token ID"] J --> K["Detokenizador"] K --> L["Fragmento de texto de salida"] J -.-> |"Añadir al contexto"| C

Al ser un modelo autorregresivo, el token de salida se añade de nuevo al contexto y circula como entrada para la predicción del siguiente token (la parte punteada del diagrama).

3. Formato del modelo y mapeo de memoria (mmap)

La mayor barrera al manejar los pesos de una red neuronal gigante es la E/S del disco y el consumo de memoria. En la implementación de C++, esto se resuelve mediante el mapeo de memoria (mmap).

3.1 Cómo funciona el mapeo de memoria y su implementación en Windows

Al utilizar mmap, el contenido del archivo se puede mapear directamente en el espacio de memoria virtual del proceso.

Copia cero (Zero-copy): Los datos se cargan directamente desde el disco a la caché de páginas del kernel, sin que ocurran copias adicionales al espacio de usuario.
Carga bajo demanda (Page Fault): En el instante exacto en que la CPU accede a esa dirección de memoria, se produce un fallo de página y solo el fragmento necesario (típicamente 4KB) se carga en la memoria física.

En un entorno Windows, en lugar del mmap de POSIX, se utilizan las API Win32 CreateFileMapping y MapViewOfFile.

sequenceDiagram participant OS["Sistema Operativo Windows"] participant RAM["Memoria Física"] participant App["Aplicación C++"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "Puntero de dirección de memoria virtual" App->>App: "Leer datos del tensor en el puntero" OS->>RAM: "Fallo de página / Cargar página desde el disco" RAM-->>App: "Datos listos para cálculo SIMD"

3.2 Estructura binaria del formato GGUF

GGUF (GPT-Generated Unified Format), convertido a partir de formatos como .safetensors de Hugging Face, es el formato definitivo para la inferencia. Tiene un diseño binario estricto como el siguiente:

Bytes Mágicos: 0x46554747 (GGUF).
Versión: Número de versión del formato.
Conteo de tensores y metadatos: Número de tensores y pares clave-valor de metadatos.
Metadatos (Pares clave-valor): Claves con prefijo de longitud de cadena y valores tipados.
Información del tensor: Nombre de cada tensor, número de dimensiones, tipo de datos (FP16, Q4_K, etc.) y posición de desplazamiento (offset) en el archivo.
Relleno (Padding): Relleno insertado para que los datos del tensor se alineen en límites específicos (generalmente 32 o 64 bytes). Es indispensable para un acceso a memoria rápido con instrucciones SIMD (especialmente AVX).
Datos del tensor: Matriz de datos de pesos reales alineados.

4. Base matemática de TinyLLaMA y algoritmos en C++

TinyLLaMA incorpora varios ingenios arquitectónicos avanzados para mejorar la eficiencia. Explicaremos las representaciones matemáticas para implementarlos correctamente en C++.

4.1 RMSNorm (Root Mean Square Normalization)

Reduce el costo computacional omitiendo el centrado de la media de LayerNorm y realizando solo el escalado de la varianza.

$$ \text{RMSNorm}(x) = \frac{x}{\sqrt{\frac{1}{d}\sum_{i=1}^{d} x_i^2 + \epsilon}} \odot \gamma $$

$d$ es el número de dimensiones y $\gamma$ es el tensor de escalado entrenado. Al implementar en C++, se optimiza calculando primero rápidamente la suma de los cuadrados de la matriz usando _mm256_fmadd_ps de AVX2, y multiplicando por la raíz cuadrada inversa (por ejemplo, con la instrucción _mm256_rsqrt_ps).

4.2 RoPE (Rotary Position Embedding)

Es una técnica para aplicar la información de posición de los tokens como una rotación en el espacio del tensor. Se puede ver como una rotación en el plano complejo, y aplica la siguiente rotación a los pares de dimensiones adyacentes $(x_1, x_2)$ del vector $x$.

$$ \text{RoPE}(x, m) = \begin{pmatrix} x_{1} \cos(m\theta) - x_{2} \sin(m\theta) \\ x_{1} \sin(m\theta) + x_{2} \cos(m\theta) \end{pmatrix} $$

Aquí, $m$ es el índice de posición absoluta del token y $\theta$ es la frecuencia base precalculada. En ggml, se ejecuta en paralelo simplemente añadiendo el operador ggml_rope durante la construcción del grafo de inferencia.

4.3 Grouped-Query Attention (GQA)

En la Atención Multicabezal normal (Multi-Head Attention, MHA), se tiene el mismo número de cabezas para Query, Key y Value. Sin embargo, TinyLLaMA adopta Grouped-Query Attention (GQA) para reducir drásticamente el ancho de banda de la memoria y el consumo de caché KV.

$$ \text{Attention}(Q, K, V) = \text{softmax}\left(\frac{Q K^T}{\sqrt{d_k}}\right) V $$

En GQA, múltiples cabezas de Query comparten una sola cabeza de Key/Value. En la implementación de C++, antes de ejecutar el producto matricial ggml_mul_mat, se requiere una operación para transmitir (broadcast) los tensores KV de acuerdo con el número de Queries.

4.4 Función de activación SwiGLU

En la capa de la Red Feed-Forward (FFN), se utiliza SwiGLU en lugar de GELU.

$$ \text{SwiGLU}(x) = \text{Swish}(x W_{\text{gate}}) \otimes (x W_{\text{up}}) $$ $$ \text{Swish}(z) = z \cdot \sigma(z) = z \cdot \frac{1}{1 + e^{-z}} $$

En el grafo computacional, se expresa combinando el operador ggml_silu y ggml_mul.

5. Construcción del grafo computacional y gestión de memoria con ggml

ggml adopta un enfoque de “Definir y Ejecutar” (Define-and-Run), donde construye un grafo computacional estático para la inferencia y luego lo evalúa.

5.1 ggml_context y el asignador de arena

La característica más singular de ggml es la “asignación por arena”, que no realiza ninguna asignación dinámica de memoria (malloc o new) dentro del bucle de inferencia. Al inicializar, se reserva una gran área de memoria contigua (arena), y cada vez que se llama a funciones como ggml_new_tensor, el puntero de esta área se incrementa. Cuando se completa un paso de inferencia, simplemente se restablece el puntero de asignación a su posición inicial, completando instantáneamente la asignación de memoria para el siguiente paso de inferencia.

5.2 Ejemplo concreto de construcción de grafo

En cada paso de inferencia, se construye un grafo computacional en memoria como el siguiente:

graph TD A["ID de Entrada de Tokens"] --> B["Búsqueda de Embedding"] B --> C["ggml_rms_norm"] C --> D["Proyecciones Q / K / V"] D --> E["Posicional ggml_rope"] E --> F["Almacenar Caché KV"] E --> G["Cargar Caché KV"] G --> H["Autoatención"] H --> I["Escala y Softmax"] I --> J["Salida de Atención"] J --> K["Proyección de Salida"] K --> L["Añadir Residual"]

6. Cuantización y optimización para Windows / SIMD

Manejar TinyLLaMA (1.1B) en FP16 requiere aproximadamente 2.2GB de memoria, pero mediante cuantización de 4 bits (como Q4_K), se puede comprimir drásticamente a unos 600MB.

6.1 Arquitectura de cuantización por bloques

ggml no cuantiza todo el tensor uniformemente, sino en unidades de “bloques”. En el formato Q4_0, 32 valores FP16 se agrupan en un bloque.

Factor de escala: 1 valor FP16 (2 bytes)
Datos cuantizados: 32 valores de 4 bits (16 bytes) Esto minimiza el impacto de los valores atípicos (outliers) locales.

6.2 Aceleración del producto punto con AVX2

Al compilar para las CPU x86 más recientes en entornos Windows, se utilizan banderas del compilador como /arch:AVX2 y el procesamiento SIMD se realiza con el siguiente flujo:

Carga: Cargar datos cuantizados de 4 bits desde la memoria a registros AVX de 256 bits.
Expansión y desempaquetado: Expandir los valores de 4 bits a Int8 o Int16 usando máscaras de bits y operaciones de desplazamiento.
Descuantización: Multiplicar por el factor de escala para convertir a punto flotante.
Operación FMA: Ejecutar en paralelo la operación de multiplicación y suma (multiply-add) con los valores de activación y _mm256_fmadd_ps (Fused Multiply-Add).

7. Detalles de implementación de la caché KV

En la generación autorregresiva, la “caché KV” para omitir el cálculo de las Keys y Values de los tokens pasados es una función esencial.

Los puntos clave para la implementación en C++ son los siguientes:

Reserva previa del tensor: Se inicializa un enorme tensor para la caché KV con la longitud máxima del contexto (ej: 2048 tokens) (se recomienda FP16).
Copia por desplazamiento: Cuando se realiza el cálculo para la posición del token $N$, los vectores K y V obtenidos en ese paso se almacenan en la fila $N$ del tensor de la caché KV usando ggml_cpy u otras funciones.
Creación de vista durante la atención: Al calcular la atención, se crea una “vista” que apunta solo a la parte de los tokens del 0 al $N$-ésimo y se pasa al producto matricial.

8. Tokenizador BPE y decodificación

La cadena de entrada se trata como una secuencia de bytes UTF-8 y se compara con un vocabulario predefinido. En C++, para acelerar la búsqueda en el vocabulario, se implementa un árbol Trie (árbol de prefijos) o algoritmos que utilizan colas de prioridad.

A partir de los logits generados por el LM Head, se escalan las probabilidades usando el parámetro Temperature, los candidatos se filtran usando métodos Top-K o Top-P (Nucleus Sampling), y se utiliza un número aleatorio para determinar el siguiente token final.

9. Inicio del proyecto en C++ (Entorno Windows / PowerShell)

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


cmake_minimum_required(VERSION 3.14)
project(TinyLLaMACpp)

set(CMAKE_CXX_STANDARD 17)

# Configuración de banderas de optimización y AVX2 para Windows (MSVC)
if(MSVC)
 add_compile_options(/O2 /arch:AVX2 /fp:fast)
 add_link_options(/STACK:8388608)
else()
 add_compile_options(-O3 -march=native -ffast-math)
endif()

add_library(ggml OBJECT ggml/ggml.c ggml/ggml-alloc.c)
target_compile_definitions(ggml PRIVATE GGML_USE_AVX2 GGML_USE_F16C GGML_USE_FMA)

add_executable(main main.cpp)
target_link_libraries(main ggml)

Ejemplo de comando de compilación en PowerShell:

1
2
3
4


mkdir build
cd build
cmake .. -G "Visual Studio 17 2022" -A x64
cmake --build . --config Release

10. Resumen

Implementar desde cero un motor de inferencia para modelos de IA pequeños como TinyLLaMA usando C++ y ggml es una excelente oportunidad para descubrir la caja negra del aprendizaje profundo y aprender la belleza del control de hardware de bajo nivel. Disfrutemos plenamente de la esencia de la programación de sistemas, como la carga con copia cero mediante mapeo de memoria, la optimización SIMD y la construcción de la caché KV, mientras abrimos camino hacia el futuro de la IA periférica (Edge AI).