在 LLM 推理引擎领域，C++ 长期占据主导地位。从 llama.cpp 到 Google 的 gemma.cpp，开发者习惯性地依赖 STL 容器、标准算法库以及现代语言特性。然而，一个名为 gemma3 的开源项目选择了一条截然不同的道路：用纯 C 语言实现 Gemma 3 的完整推理流程，且不依赖任何标准库。这一选择并非怀旧或炫技，而是针对特定部署场景的务实考量。本文将从内存管理、计算优化和移植策略三个维度，解析这种实现的工程意义与可落地参数。
为什么在 2026 年还有人用纯 C 写 LLM 推理
现代 LLM 推理引擎的依赖树通常复杂而沉重。以 gemma.cpp 为例，它需要 C++ 标准库、Googletest 测试框架、Bazel 构建系统，以及可选的 Highway 库用于 SIMD 优化。这些依赖在桌面或服务器环境中不成问题，但当目标平台是资源受限的嵌入式系统时，情况完全不同。
裸机环境下的微控制器往往没有完整的 C 运行时支持。ESP32、ARM Cortex-M 系列芯片可能只有几十 KB 的 RAM，没有任何堆内存分配能力，也无法调用 malloc 或 free。在这样的约束下，一个「零标准库依赖」的推理引擎可以直接编译链接为机器码，无需运行时初始化代码。纯 C 实现的另一个优势是可预测性。由于没有隐藏的内存分配、没有模板实例化膨胀、没有虚函数表查找，开发者可以精确控制每一字节的内存布局和每一次函数调用的开销。这种透明性在实时系统中至关重要 —— 任何意外的缓存失效或内存分配延迟都可能导致任务超时。
手动内存管理：从堆到池的范式转换
脱离 stdlib 意味着必须自己实现内存管理子系统。在纯 C 实现中，常见的做法是使用内存池（Memory Pool）模式。推理过程可以分为几个阶段：Tokenization、Embedding、Attention 计算、前馈网络计算、Logits 输出。每个阶段所需的内存大小是可预测的：模型参数可以预先加载到只读区域，KV Cache 需要按序列长度动态分配，而激活值则是一次性分配的临时缓冲区。
一种经过验证的参数配置方案是将内存池划分为三个区域。参数区占用最大空间，以 Gemma 3 2B 模型为例，FP16 量化后约占用 4GB，INT4 量化后可压缩至 1GB 左右。KV Cache 区的大小与序列长度和批次大小成正比，计算公式为 2 * num_layers * num_heads * head_dim * seq_len * batch_size * sizeof(half)。激活区则根据 batch size 和最大序列长度动态计算，通常取 batch size 为 1 时，激活峰值约为 100-200MB。
在裸机环境中，内存池的实现必须避免碎片化。固定大小的内存块分配策略（Fixed-size Block Allocation）是一种常用方案：将内存池划分为多个预设大小的块，分配时直接返回对应大小的块指针。这种方式的分配复杂度为 O (1)，且完全避免了外部碎片。实现时需要注意对齐问题，确保 SIMD 指令或向量操作能够正确访问内存。ARM 平台建议 16 字节对齐，x86 平台建议 32 字节对齐以获得最佳的 AVX-512 性能。
矩阵乘法优化：缓存友好的分块策略
矩阵乘法是 Transformer 模型的核心计算瓶颈。在没有 SIMD 指令集的纯 C 实现中，软件层面的优化主要依赖缓存友好的分块（Tiling）策略。现代 CPU 的缓存层次结构使得顺序访问内存的效率远高于随机访问。通过将大矩阵划分为适应当前缓存大小的子块，可以显著提高数据复用率。
一种实用的分块参数配置如下：对于 L2 缓存约为 256KB 的中端 CPU，块大小可设为 64×64 的 float 矩阵块。每个线程负责一个块的处理，主循环遍历 A 的行和 B 的列，内层循环执行块内的乘法累加操作。这种配置下，A 的块可以被加载到 L1 缓存并复用 64 次，B 的元素在 L2 缓存中保持较长时间，总体缓存命中率可达 85% 以上。
对于无 SIMD 的纯 C 实现，还需要考虑编译器优化。GCC 和 Clang 在开启 -O3 优化后，能够自动将内层循环展开并应用循环不变式外提等优化。关键是在源代码层面提供足够的类型信息和 restrict 关键字，帮助编译器理解指针不重叠的情况，从而生成更高效的代码。实测表明，在 ARM Cortex-A72 处理器上，经过优化的纯 C 矩阵乘法性能可以达到手工汇编版本的 60-70%，而开发成本和维护难度大幅降低。
Tokenizer 实现：从字节到整数的映射
Tokenizer 是 LLM 推理流程中常被忽视的组件。SentencePiece 或 Tiktoken 等流行实现依赖复杂的哈希表和动态内存分配，在纯 C 环境中移植难度较高。纯 C 实现通常采用查表法或有限状态机来处理 UTF-8 编码的输入文本。
一种简化的实现方案是构建一个静态的词表数组，按 token ID 排序并预先计算每个 token 的 UTF-8 长度。编码时，扫描输入字符串，尝试匹配最长可能的前缀。为了加速匹配，可以使用双数组 Trie（Double Array Trie）结构，其构建过程一次性完成，后续查找复杂度为 O (m)，其中 m 为 token 的平均字节数。实测表明，这种实现在处理英文文本时可达每秒数万字的编码速度，完全满足交互式推理的需求。
量化策略与精度权衡
纯 C 实现对量化格式的选择更加灵活。FP32 推理在计算精度上最优，但内存带宽压力也最大。INT8 量化将权重和激活值压缩为 8 位整数，内存占用减少 75%，但需要额外的量化 / 反量化步骤。INT4 量化进一步压缩至 4 位，内存占用仅为 FP32 的 12.5%，但精度损失显著。
对于嵌入式部署，推荐采用混合量化策略：Attention 的 Query 和 Value 层使用 INT8 以保证关键计算路径的精度，前馈网络层可使用 INT4 以节省内存。Gemma 3 模型架构中，隐藏层维度为 16384，FFN 扩展维度为 65536，这一层的参数量占模型总量的三分之二以上，是量化收益最大的部分。实现时需要注意量化参数的预处理，建议在模型转换阶段预先计算并存储每个 tensor 的 scale 和 zero-point 值，避免运行时的动态计算开销。
跨平台移植：构建系统的抽象
纯 C 实现的另一个优势是构建系统的简洁性。一个标准的 Makefile 可以在几乎任何平台上工作，只需调整编译器标志和链接选项。对于嵌入式平台，通常需要重写或封装以下几个系统调用：内存分配使用平台特定的 heap API 或静态池；文件 I/O 在有文件系统的平台上使用标准 C 的 fread/fwrite，在裸机上则需要直接操作 Flash 存储；计时函数使用平台的高精度定时器或 cycle counter。
一种推荐的抽象方式是定义平台适配层（Platform Adaptation Layer），将所有与操作系统相关的代码集中到少数几个文件中。推理引擎的核心逻辑保持平台无关，通过函数指针或配置结构注入平台相关实现。这种设计使得同一套推理代码可以同时运行在 Linux 桌面、RTOS 和裸机上，只需替换几百行平台适配代码。
工程实践参数清单
在将纯 C 推理引擎部署到生产环境时，以下参数需要重点关注。内存方面，建议预留模型参数体积的 1.5 倍作为安全工作空间，预留 KV Cache 体积的 2 倍以应对峰值需求。性能方面，单 token 生成延迟目标应控制在 50ms 以内以获得流畅的交互体验，首 token 延迟目标应控制在 200ms 以内。量化方面，推荐 INT8 量化作为生产环境的默认配置，在内存严重受限时才考虑 INT4。兼容性方面，建议支持 FP16 和 BF16 两种输入格式以覆盖主流模型导出需求。
纯 C 语言实现 Gemma 3 推理引擎的意义，不仅在于它能够在极端受限的环境中运行 LLM，更在于它揭示了推理系统设计的本质：内存布局、计算调度和精度权衡。这些底层问题在任何平台上都存在，纯 C 实现只是迫使开发者直面这些问题。当工程目标从「快速开发」转向「极致可控」时，这种看似「原始」的技术选择反而成为最务实的答案。
参考资料
- GitHub - robitec97/gemma3: https://github.com/robitec97/gemma3
- Google Gemma.cpp 官方仓库: https://github.com/google/gemma.cpp