GGML on kenji.blog

无需Python！仅用C++构建AI推理引擎

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

1. 引言：为什么要抛弃Python，用C++构建AI推理引擎？

在现代AI开发中，Python是事实上的标准。得益于PyTorch和TensorFlow等强大的框架，只需几行代码就能构建、训练和推理复杂的神经网络。然而，在这些框架的背后，是C++和CUDA等底层语言在承担着繁重的计算处理。Python只不过是发挥了“胶水（Glue）”的作用。

那么，为什么非要排除Python，单独使用C++来构建AI推理引擎呢？这有几个强有力的理由。

极致的性能和低延迟: 可以完全消除Python的GIL（全局解释器锁）和动态类型带来的开销。特别是在需要实时性的系统中，毫秒级的延迟是致命的。
部署的便利性: 在最终用户的环境中构建Python环境（庞大的库、依赖地狱）非常困难。如果是C++，只需分发静态链接的单个可执行二进制文件（.exe或ELF二进制）即可。
支持边缘设备: 在智能手机、嵌入式设备、Raspberry Pi等资源受限的环境中，没有余力运行消耗数GB内存的Python运行时。
硬件的直接控制: 内存分配的时机、显式使用SIMD指令、优化与GPU的内存传输等底层控制，在C++中是可以实现的。

本文深受Georgi Gerganov开发的“GGML”库架构的启发，将深入技术深渊，解说如何从零开始仅使用C++构建运行大型语言模型（LLM）等推理引擎的过程。

2. 推理引擎的架构全貌

AI的推理处理本质上是“巨大的矩阵计算的连续”。为了高效执行这一操作，推理引擎需要由以下组件构成。

graph TD A["输入数据 (Tokens/Images)"] --> B["张量管理 (Tensor Management)"] B --> C["计算图 (DAG)"] C --> D["内存分配池与分配器 (Memory Arena & Allocator)"] C --> E["调度器与线程池 (Scheduler & Thread Pool)"] E --> F["CPU后端 (AVX2/ARM NEON)"] E --> G["GPU后端 (CUDA/Metal)"] F --> H["输出结果 (Output Results)"] G --> H

张量（Tensor）管理: 管理多维数组的数据结构和各个维度的步长（Stride）。
计算图（Computation Graph）: 将神经网络各层的运算表示为有向无环图（DAG）。
内存分配池（Memory Arena）: 预先分配型内存管理机制，以避免动态内存分配（malloc或new）的开销。
后端（Backend）: 针对CPU或GPU等特定硬件优化的运算实现（内核）。

我们将利用C++的强大功能（模板、指针运算、RAII等）来组装这些组件。

3. 内存管理的奥秘：内存分配池与SIMD对齐

推理引擎中的内存管理是直接影响性能的最重要因素之一。在推理过程中，特别是在通过Transformer模型的各层时，会生成大量的中间张量。如果每次都使用标准的malloc来分配和释放，堆的碎片化和操作系统的上下文切换将导致致命的速度下降。

因此，我们采用“内存分配池（Memory Arena）”的方法。这是一种在推理开始时计算（或固定）所需的最大内存量并一次性分配，之后仅通过递增指针来切分内存的手法。

3.1 对齐的重要性

现代CPU支持SIMD（单指令多数据流）指令。如Intel/AMD的AVX2/AVX-512，以及ARM的NEON等。这些指令能够一次处理256位（32字节）或512位（64字节）的数据，但处理目标的数据内存必须在特定的字节边界（通常是32字节或64字节）对齐（Alignment）。

以下是考虑了对齐的内存分配池的C++实现示例。

 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) {
 // POSIX系统使用 posix_memalign，Windows使用 _aligned_malloc
#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) {
 // 计算对齐（求填充字节）
 size_t pad = (alignment - (offset % alignment)) % alignment;
 if (offset + pad + bytes > size) {
 throw std::runtime_error("OOM: MemoryArena out of memory");
 }
 offset += pad;
 void* ptr = data + offset;
 offset += bytes;
 return ptr;
 }

 void reset() {
 offset = 0; // 释放内存只需重置指针即可（O(1)）
 }
};

这样，在创建张量时始终通过此内存分配池获取内存。在推理的每个步骤（如每次生成令牌）结束后，只需调用 reset() 就可以瞬间重用内存。

4. 张量数据结构与步长的魔法

张量是标量、向量和矩阵的广义概念。在实现中最重要的一点是，虽然实际数据在内存中是作为一维连续数组排列的，但它具有将其解释为多维的“步长（Stride）”概念。

 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, // 用于量化
 INT4 // 用于量化
};

struct Tensor {
 int n_dims; // 维度数
 int64_t ne[4]; // 各维度的元素数 (Number of Elements)
 size_t nb[4]; // 各维度的步长 (Number of Bytes)
 DataType type; // 数据类型
 void* data; // 指向有效载荷的指针

 // 用于计算图
 enum OpType op;
 Tensor* src0;
 Tensor* src1;
};

步长 nb[i] 表示在维度 i 中相邻元素之间在内存上的字节距离。例如，当元素数为 $M \times N$ 的矩阵（FP32，每个元素4字节）按Row-Major（行优先）存储时，步长如下：

nb[0] = 4 (字节) ：列方向的移动
nb[1] = $N \times 4$ (字节) ：行方向的移动

利用这一点，在不伴随内存复制的情况下，只需交换步长的数值就能实现“转置（Transpose）”或“视图（View）”等操作。非常优雅且高速。

5. 计算图（DAG）的构建与延迟评估

与PyTorch等类似，我们的推理引擎也采用接近“Define-by-Run”的延迟评估（Lazy Evaluation）。也就是说，在调用运算函数时并不执行计算，而是仅构建图（节点间的依赖关系）。

 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 通常是已转置的
 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;
}

推理处理的流程如下所示。

graph LR A["定义张量 (Define Tensors)"] --> B["通过运算构建图 (Build Graph via Ops)"] B --> C["拓扑排序 (Topological Sort)"] C --> D["为输出分配内存 (Allocate Memory for Outputs)"] D --> E["按顺序执行节点 (Execute Nodes In Order)"]

在评估图（前向传递）时，使用拓扑排序从没有依赖关系的节点开始依次执行处理。由于仅进行推理，不需要保留用于反向传播的梯度，因此内存管理变得非常简单。

6. 数学与优化的核心：矩阵乘法 (GEMM)

AI推理计算量的90%以上都花费在矩阵乘法（GEMM: General Matrix Multiply）上。Transformer模型核心的注意力机制和前馈网络（FFN），归根结底都是巨大的矩阵乘积。

两个矩阵 $A$ (大小为 $M \times K$) 和 $B$ (大小为 $K \times N$) 的乘积 $C = A B$ (大小为 $M \times N$) 用公式表示如下。

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

如果用朴素的三重循环来实现这个公式，会频繁发生缓存未命中，毫无性能可言。

6.1 CPU上的缓存分块与SIMD优化

在CPU上加速GEMM的基本策略如下：

循环分块（缓存分块）: 将矩阵分割成能够放入L1/L2缓存的小块来进行计算。
数据打包: 内部重新排列数据，使内存访问模式连续。
利用SIMD: 使用AVX-512中如 _mm512_fmadd_ps 这样的FMA（融合乘加）指令，在一个时钟周期内完成大量的乘加运算。

以下是使用C++和SIMD Intrinsics实现的简化向量内积（Dot Product）示例。

 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> // 用于AVX指令

// 使用AVX2的FP32高速内积
float dot_product_avx2(const float* a, const float* b, int n) {
 __m256 sum256 = _mm256_setzero_ps();
 int i = 0;

 // 一次处理8个元素（256位 = 32字节 = 8 * 4字节）
 for (; i <= n - 8; i += 8) {
 __m256 va = _mm256_loadu_ps(a + i);
 __m256 vb = _mm256_loadu_ps(b + i);
 // FMA指令: sum256 = va * vb + sum256
 sum256 = _mm256_fmadd_ps(va, vb, sum256);
 }

 // 将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];

 // 处理剩余部分
 for (; i < n; ++i) {
 dot += a[i] * b[i];
 }
 return dot;
}

仅凭这一点小小的巧思，就能获得比朴素实现快几倍至十几倍的速度提升。

7. 跨越硬件壁垒：CUDA与Metal后端的集成

虽然纯C++实现在CPU上能跑得还凑合，但要在实际可用的速度（例如：每秒生成20个令牌以上）下运行LLM等庞大的模型，GPU的并行计算能力是不可或缺的。因此，我们要在引擎中引入后端抽象层。

7.1 后端抽象

利用C++的多态性，使运算执行器（Executor）可以被切换。

 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;

 // 各类运算的执行
 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 NVIDIA CUDA 后端实现

为了充分利用NVIDIA的GPU，我们使用CUDA C++扩展来实现后端。虽然可以编写自己的内核，但对于矩阵乘法来说，利用NVIDIA提供的顶级库“cuBLAS”是最好的选择。

 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 {
 // CUDA默认是Column-Major，因此参数需要注意
 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]; // 前提是 src1 已转置

 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();
 }
};

由于CUDA内存和主机（CPU）内存之间的数据传输（cudaMemcpy）开销非常大，在推理过程中，尽量将所有的权重（权重张量）和中间张量保留在VRAM上的设计变得至关重要。

7.3 Apple Silicon (Metal) 后端

近年来，Mac的M1/M2/M3芯片（Apple Silicon）作为AI推理机非常优秀。其原因在于“统一内存”。由于CPU和GPU共享同一内存区域，因此完全不需要像前面提到的CUDA那样，通过PCIe总线进行高成本的主机-设备间内存传输。

要从C++调用Metal，可以使用Objective-C++（.mm文件）作为桥梁，或者使用metal-cpp库。利用Metal的Compute Shader（在.metal文件中以类似C++的方式编写）来编写内核。

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


// 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]; // 简化
 }
 C[row * n + col] = sum;
 }
}

在Apple Silicon环境下，还提供了称为MPS（Metal Performance Shaders）的矩阵乘法优化库，在实际运用中通过使用它，可以获得惊人的推理速度。

8. Transformer模型特有的处理：Attention与KV缓存

像LLaMA 2/3或GPT这样最先进的LLM是基于Transformer架构的。要在C++中实现它，必须构建以下公式表示的“缩放点积注意力 (Scaled Dot-Product Attention)”。

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

另外，在自回归（Autoregressive）令牌生成中，必须保留过去令牌的计算结果（Key和Value）。这被称为“KV缓存（Key-Value Cache）”。

graph TD T["当前令牌 (Current Token)"] --> Q["查询 (Query)"] T --> K["键 (Key)"] T --> V["值 (Value)"] K --> KCache["追加到KV缓存 (Append to KV Cache)"] V --> VCache["追加到KV缓存 (Append to KV Cache)"] Q --> Dot1["Q * K_Cache^T"] KCache --> Dot1 Dot1 --> Scale["缩放 (Scale (1/sqrt(d)))"] Scale --> Softmax["Softmax"] Softmax --> Dot2["SoftmaxOut * V_Cache"] VCache --> Dot2 Dot2 --> Out["上下文向量 (Context Vector)"]

在KV缓存的内存分配方面，也要像环形缓冲区一样进行操作，预先在内存分配池中分配最大上下文长度（例如4096或8192个令牌）的内存空间。这可以防止每次生成步骤都进行重新分配。

此外，对于位置编码（Positional Encoding），将实现近年来成为主流的“RoPE（旋转位置嵌入）”。这是一种将位置信息作为复数空间中的旋转向量嵌入的方法，在C++中优化 sin 和 cos 函数的调用（如使用查找表等）是性能的关键。

9. 模型量化（Quantization）带来的极致优化

如果将大型模型（例如70亿参数的LLaMA模型）原封不动地以FP32（32位浮点数）加载，仅权重就会消耗约28GB的内存（VRAM）。再加上KV缓存和推理用的缓冲区，很容易就会超过30GB，一般的消费级GPU根本无法运行。

因此，“量化（Quantization）”就变得不可或缺了。这也是GGML格式的精髓所在。

量化是有意降低权重精度的技术。

FP16 (16位): 大小减半。精度几乎没有衰减。
INT8 (8位): 大小1/4。轻微的衰减。
INT4 (4位): 大小1/8。使用独特的分块和比例因子，可进行实用的推理。

在推理引擎端，从内存中读取被压缩为INT4（或INT8）的权重，在加载到CPU或GPU的寄存器后，立即展开（反量化）为FP16或FP32进行计算。

令人惊讶的是，即使增加了计算量，减少从内存中读取的数据量反而会更快。这是因为在现代硬件中，推理任务的瓶颈不在于“计算力（Compute Bound）”，而在于“内存带宽（Memory Bandwidth Bound）”。如果是实现了INT4量化的C++引擎，即便是8GB VRAM的MacBook Air等设备也能非常流畅地运行本地LLM。

10. 性能调优：NUMA架构与线程池

在使用CPU进行推理时，多线程化是必须的。但是，如果仅仅启动大量的 std::thread，并不能说是最优的。

在现代的多插槽服务器或如Ryzen Threadripper这样的高端CPU中，采用了**NUMA（非一致性内存访问）**架构。从某个CPU核心访问物理上较近的内存（本地内存）速度很快，但访问绑定到其他处理器的内存时，速度会急剧下降。

在高级C++推理引擎中，会充分运用以下技巧：

线程绑定（Thread Pinning）: 将每个线程固定到特定的CPU核心（设置亲和性），以防止上下文切换导致缓存失效。
感知NUMA的分配: 在处理数据的线程所在的同一NUMA节点上分配内存。
工作窃取型线程池: 将计算图的各个节点分割成细小的任务，实现空闲线程自动夺取并执行任务的高效调度器。

通过运用这些技巧，可以让CPU利用率紧贴100%，爆发出接近理论值的吞吐量。

11. 总结：用C++的“肌肉”驱动AI的乐趣

Python确实很方便。在研究开发和原型制作方面，它的生产力是任何语言都无法比拟的。但是，当我们过渡到将完成的模型“在现实世界中高效地、在各种设备上运行”这一阶段时，C++登场的时刻就到了。

直接操作内存的字节流，用SIMD指令将寄存器压榨到极限，与GPU的VRAM带宽搏斗，最终完成的推理引擎在控制台上源源不断地生成自然语言文本（令牌）——当你看到这一切时所体会到的成就感，是你在Python框架中调用 model.generate() 时绝对无法体验到的“纯粹的工程师之喜悦”。

虽然AI技术很容易成为“黑盒”，但通过用C++亲手从张量运算到内存分配编写一切，可以深刻理解LLM究竟是如何“思考”的，领悟其真正的机制。

如果你具备C++的基础知识，并对当下的AI技术有着浓厚的兴趣，请务必尝试挑战开发自己的推理引擎。GGML和llama.cpp的源代码，绝对是最好的活教材。

现在，让我们抛弃Python沉重的运行时，用C++的肌肉让最前沿的AI跑起来吧！

使用C++开发小规模AI模型（如TinyLLaMA）的步骤

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

使用C++开发小规模AI模型（如TinyLLaMA）的步骤

近年来，在本地环境运行大型语言模型（LLM）的关注度急剧上升。特别是像TinyLLaMA（1.1B参数）这样的小规模模型，即使在资源有限的边缘设备或普通笔记本电脑（包括Windows环境）上，也能以实用的速度进行推理。虽然使用Python和PyTorch进行开发是主流，但在追求极致性能和内存节省时，C++和基于C语言的张量库“ggml”的组合成为了事实上的标准。

本文将非常详细地讲解如何从零开始构建一个使用C++加载TinyLLaMA并进行文本生成的推理引擎（或者说，深入理解现有的llama.cpp内部结构）的开发步骤。

1. 为什么选择C++和ggml？

在AI的训练阶段，具有灵活性和丰富生态系统的Python具有压倒性的优势。然而，在部署和“推理（Inference）”阶段，基于以下理由，C++成为了强大的选择。

减少开销：可以完全消除Python的全局解释器锁（GIL）和运行时的开销。
内存效率和Arena分配：可以手动控制内存的分配和释放，从而防止垃圾回收带来的不可预测的峰值。
直接访问硬件：直接调用AVX-512、AVX2、ARM NEON等SIMD内置函数（Intrinsics），将CPU的运算能力发挥到极致。
零依赖：ggml是一个零依赖（Zero dependencies）的C/C++库，只要有编译器，即使在Windows上的MSVC环境中也很容易编译。

2. 架构全景图

整个推理流水线的流程如以下Mermaid图表所示。这是一系列从用户输入文本开始，到最终生成下一个Token为止的过程。

graph TD A["用户输入文本"] --> B["BPE 分词器"] B --> C["Token ID 数组"] C --> D["嵌入层查找"] D --> E["Transformer 块"] E --> F["RMSNorm"] F --> G["LM Head 层"] G --> H["Logits 数组"] H --> I["采样器模块"] I --> J["下一个 Token ID"] J --> K["去分词器"] K --> L["输出文本块"] J -.-> |"追加到上下文"| C

由于它是自回归模型，输出的Token会再次被添加到上下文中，作为预测下一个Token的输入进行循环（图中虚线部分）。

3. 模型格式与内存映射 (mmap)

处理庞大的神经网络权重时，最大的障碍是磁盘I/O和内存消耗。在C++实现中，通过**内存映射（mmap）**来解决这个问题。

3.1 内存映射的原理及在Windows中的实现

使用mmap，可以将文件的内容直接映射到进程的虚拟内存空间中。

零拷贝（Zero-copy）：数据直接从磁盘加载到内核的页面缓存中，不会发生向用户空间的多余拷贝。
按需加载（Page Fault）：只有当CPU实际访问该内存地址的瞬间，才会发生缺页中断（Page Fault），并且仅将需要的块（通常为4KB）加载到物理内存中。

在Windows环境中，不使用POSIX的 mmap，而是使用Win32 API的 CreateFileMapping 和 MapViewOfFile。

sequenceDiagram participant OS["Windows 操作系统"] participant RAM["物理内存"] participant App["C++ 应用程序"] App->>OS: "CreateFileMapping / MapViewOfFile" OS-->>App: "虚拟内存地址指针" App->>App: "在指针处读取张量数据" OS->>RAM: "缺页中断 / 从磁盘加载页面" RAM-->>App: "数据已准备好进行 SIMD 计算"

3.2 GGUF 格式的二进制结构

从Hugging Face等的 .safetensors 格式转换而来的 GGUF (GPT-Generated Unified Format) 是用于推理的终极格式。它具有以下严格的二进制布局：

Magic Bytes: 0x46554747 (GGUF)。
Version: 格式的版本号。
Tensor Count & Metadata Count: 张量数量和元数据的键值对数量。
Metadata (Key-Value Pairs): 带有字符串长度前缀的键和带有类型的值。
Tensor Info: 每个张量的名称、维度数、数据类型（如FP16，Q4_K等），以及在文件中的偏移位置。
Padding: 插入的填充物，用于将张量数据对齐到特定边界（通常为32字节或64字节）。这对使用SIMD指令（特别是AVX）进行高速内存访问至关重要。
Tensor Data: 已对齐的实际权重数据数组。

4. TinyLLaMA的数学基础与C++算法

TinyLLaMA为了提高效率，引入了一些高级的架构设计。为了在C++中正确实现这些，以下是它们的数学公式表示。

4.1 RMSNorm (Root Mean Square Normalization)

省略了LayerNorm中的均值中心化，仅进行方差的缩放，从而降低了计算成本。

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

其中 $d$ 是维度数，$\gamma$ 是训练好的缩放张量。在C++中实现时，首先使用AVX2的 _mm256_fmadd_ps 等快速计算数组的平方和，然后乘以平方根的倒数（如 _mm256_rsqrt_ps 指令）来进行优化。

4.2 RoPE (Rotary Position Embedding)

这是一种将Token的位置信息作为张量空间中的旋转（Rotate）来应用的技术。可以将其视为复平面上的旋转，对向量 $x$ 的相邻维度对 $(x_1, x_2)$ 应用以下旋转：

$$ \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} $$

在这里，$m$ 是Token的绝对位置索引，$\theta$ 是预先计算好的基频。在ggml中，只需在构建推理图时添加 ggml_rope 算子即可并行执行。

4.3 Grouped-Query Attention (GQA)

在常规的多头注意力机制（MHA）中，Query、Key和Value各具有相同数量的头。然而，TinyLLaMA为了大幅减少内存带宽和KV缓存的消耗，采用了 Grouped-Query Attention (GQA)。

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

在GQA中，多个Query头共享一个Key/Value头。在C++实现中，在执行矩阵乘法 ggml_mul_mat 之前，需要根据Query的数量将KV张量进行广播（Broadcast）操作。

4.4 SwiGLU 激活函数

在前馈网络（FFN）层中，使用SwiGLU代替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}} $$

在计算图中，通过组合 ggml_silu 算子和 ggml_mul 来表示。

5. 使用ggml构建计算图与内存管理

ggml采用“Define-and-Run”的方法，先构建用于推理的静态计算图，然后再进行评估（evaluate）。

5.1 ggml_context 与 Arena 分配器

ggml最独特的地方在于，推理循环内完全不进行动态内存分配（如 malloc 或 new）的“Arena 分配（Arena Allocation）”。初始化时分配一大块连续的内存区域（Arena），每次调用 ggml_new_tensor 等函数时，都会递增这个区域的指针。当完成一个推理步骤后，只需将分配指针重置到初始位置，即可立即完成下一个推理步骤的内存分配。

5.2 构建图的具体示例

在每个推理步骤中，会在内存中组装如下的计算图。

graph TD A["Token 输入 ID"] --> B["嵌入查找"] B --> C["ggml_rms_norm"] C --> D["Q / K / V 投影"] D --> E["ggml_rope 位置编码"] E --> F["KV 缓存存储"] E --> G["KV 缓存加载"] G --> H["自注意力机制"] H --> I["缩放与 Softmax"] I --> J["注意力输出"] J --> K["输出投影"] K --> L["残差连接相加"]

6. 量化 (Quantization) 与 Windows / SIMD 优化

如果用FP16处理TinyLLaMA (1.1B)，大约需要2.2GB的内存，但通过4位量化（如Q4_K），可以将其大幅压缩至约600MB左右。

6.1 块量化架构

ggml并不是对整个张量进行统一量化，而是以“块（Block）”为单位进行的。在 Q4_0 格式中，将32个FP16值组合成一个块。

缩悉因子（Scale factor）：1个FP16值（2字节）
量化数据：32个4位值（16字节）通过这种方式，将局部异常值的影响降至最低。

6.2 利用AVX2加速点积运算

当在Windows环境中为最新的x86 CPU进行编译时，可以利用 /arch:AVX2 等编译器标志，SIMD处理流程如下：

加载：将4位量化数据从内存加载到256位的AVX寄存器中。
展开与解包：通过位掩码和移位运算，将4位值展开为Int8或Int16。
反量化：乘以缩放因子，转换为浮点数。
FMA运算：使用激活值和 _mm256_fmadd_ps（融合乘加）并行执行乘累加运算。

7. KV缓存的实现细节

在自回归生成中，为了省略计算过去Token的Key和Value，必须使用“KV缓存（KV Cache）”。

在C++中实现时的要点如下：

预先分配张量：为KV缓存初始化一个能够容纳最大上下文长度（例如：2048个Token）的巨大张量（推荐使用FP16）。
偏移复制：当执行针对Token位置 $N$ 的计算时，将该步骤中得到的K和V向量使用 ggml_cpy 等方法存储到KV缓存张量的第 $N$ 行。
注意力计算时的视图（View）创建：在计算注意力时，创建一个仅指向从第0个到第 $N$ 个Token部分的“视图”，并将其传递给矩阵乘法。

8. BPE 分词器与解码

将输入字符串视为UTF-8的字节流，并与预先定义的词汇表进行匹配。在C++中，为了加速词汇表的搜索，通常会实现 Trie树（前缀树） 或使用优先队列的算法。

从LM Head输出的Logits，使用Temperature参数缩放概率，通过Top-K提取或Top-P（Nucleus Sampling）方法缩小候选范围，并使用随机数决定最终的下一个Token。

9. 搭建C++项目（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)

# 面向 Windows (MSVC) 的优化和 AVX2 标志的设置
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)

PowerShell 中的构建命令示例：

1
2
3
4


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

10. 总结

使用C++和ggml从零开始实现像TinyLLaMA这样的小规模AI模型的推理引擎，是揭开深度学习黑盒、学习底层硬件控制之美的绝佳机会。在充分体会利用内存映射进行零拷贝加载、SIMD优化、KV缓存构建等系统编程精髓的同时，让我们共同开拓边缘AI的未来。