如果在 2024 年还有人告诉你他想用 Common Lisp 写一个 LLM 推理引擎不依赖 PyTorch自己读权重文件用 AVX2 指令加速矩阵运算还要手动管理多线程调度你大概率会觉得这是行为艺术。但这个判断值得再想一次。LLM 推理真正吃功夫的地方不在调用现成框架而在搞明白权重从哪里来、矩阵乘怎么才能算得快、KV Cache 怎么存、token 流怎么调度。这些问题的大部分跟用 Python 还是 C 关系不大真正有关系的是你有没有把抽象层降到足够低把所有内存带宽和计算资源握在自己手里。llambda.lisp 正是一个把这两件事同时推到极致的项目用 Common Lisp 作宿主语言直接面对 CPU 指令集和内存布局完成一套 LLM 推理引擎。这篇文章会拆解它到底在做什么也会给出一个最小可运行的技术骨架让普通后端开发者理解这类“裸机推理引擎”的价值以及它能带来哪些可迁移的知识。1. 为什么会有“用 Lisp 写 LLM 推理引擎”这种反主流选择今天的推理引擎生态已经被几个大名字占领Python PyTorch 适合研究和快速验证llama.cpp 是 CPU 推理的事实标准TensorRT-LLM 和 vLLM 则把 GPU 上的吞吐优化做到极致。在这个背景下用 Common Lisp 写推理引擎显得极其另类。但另类不意味着没有价值它背后通常有至少三个动机。第一是理解质量。用 llama.cpp 跑模型时你知道权重是 GGUF 格式但一个 q4_K_M 量化的矩阵在内存里如何排列、如何被反量化、如何参与矩阵乘绝大多数人不会深入研究。一旦你决定自己写推理引擎这些细节就全部变成必须实现的功能。你需要定义权重文件的读取方式、决定张量布局、写算子内核、选择 KV Cache 的分配策略。整个过程会让 LLM 推理从一个“调用链”变成一个完整的知识体系。第二是 Lisp 的宏与交互式开发。Common Lisp 的宏不是简单的字符串替换而是在编译期操作抽象语法树。对推理引擎来说你可以用宏为矩阵分块、循环展开、内存对齐写一套生成器让编译器替你批量生成代码。REPL 则允许你加载模型、跑到某一层、观察中间张量值再改代码再跑调试密度比大型 C 工程高很多。第三是对主流方案的主动反思。很多人觉得“用 Python 调框架”就是大模型开发的全部但实际上 LLM 推理从底向上是一层一层叠加出来的指令集、内存分配、算子内核、模型权重、采样策略、服务调度。每一层都有人替你做了但如果你从未亲手实现过某一层你就很难在性能瓶颈出现时准确定位问题。llambda.lisp 这类项目就是把自己扔到最底层去重新走一遍这条路。当然也必须承认边界。这类项目大概率不会成为生产推理服务的主流它在 GPU 生态、成熟量化算子库、稳定 ABI 方面没有优势。但它的存在意义更接近“CPU 推理引擎的解剖样本”也呼应了最近很多人提倡的“手动实现一遍模型LLM 就祛魅了”的思路。对一个工程师来说读过一次源码和亲手写过一次内核带来的理解深度完全不同。2. 拆解标题里的四个关键词llambda.lisp 这个项目名几乎是把所有技术特征都写进了标题Bare-Metal、Multi-Threaded、AVX2-Accelerated、in CL。逐个拆开看每个词都对应推理引擎中的一类硬问题。关键词技术含义在 LLM 推理中的作用典型工作Bare-Metal不依赖大型框架自行管理权重读取、内存分配和计算流程移除 PyTorch/TensorFlow 等运行时依赖直接操作权重权重加载、内存映射、算子调度Multi-Threaded多线程并发执行并行处理 batch 内多个序列或加速单序列解码线程池、同步原语、批次调度AVX2-Accelerated使用 CPU 的 AVX2 SIMD 指令集矩阵乘、注意力、LayerNorm 获得向量化加速矩阵乘、softmax、向量规约in CL使用 Common Lisp 作为实现语言用 SBCL 编译原生代码通过 FFI 调用底层 C 内核运行时、垃圾回收、FFI 桥接2.1 Bare-Metal 到底意味着什么Bare-Metal 在 LLM 推理语境下通常指“不借助运行时框架直接在 CPU 上执行计算”。一个 PyTorch 推理程序启动时会加载巨大的运行时库完成自动微分图的调度再分派到后端算子库。而 Bare-Metal 推理引擎会直接读取权重文件把参数按照预定布局放到内存里然后用循环和 SIMD 指令逐层执行 Transformer 算子。这中间的差别不是代码量而是控制粒度。Bare-Metal 引擎的作者必须回答这几个问题权重文件是二进制还是文本是否需要字节序转换量化的 scale 和 zero point 存在哪里矩阵是行主序还是列主序这些问题在框架时代都会被隐藏但在裸机引擎里每一个都是绕不过去的设计决策。这里真正容易踩坑的地方是文件格式解析。LLM 权重文件动辄几 GB如果采用基于文本的格式加载时间会非常难看的。合理的做法是使用简单二进制格式甚至直接把权重按内存布局导出加载时用mmap映射到进程地址空间。这样既能降低启动时间也能让后续的 KV Cache 分配和权重读取共用一套内存管理逻辑。2.2 Multi-Threaded 的调度意义LLM 推理在 CPU 上的耗时主要分两段prefill 阶段要处理整段输入计算量大受算力限制decode 阶段一次只生成一个 token权重读取和 KV Cache 访问占主导受内存带宽限制。多线程在这两段中的优化目标完全不同。prefill 阶段通常希望把一个 batch 的序列拼成一个大的矩阵乘让 SIMD 单元满载。decode 阶段则更适合把不同序列分给不同线程让每个线程独立做一个小 batch 的自回归解码。这样一来线程间的同步点需要精心设计否则频繁的锁竞争会把并行收益完全吃掉。越是接近 Bare-Metal 的引擎越需要自己写线程池和任务队列这也正是 Lisp 这类带垃圾回收的语言被质疑的地方GC 带来的暂停和不可预测性在低延迟推理场景里是需要重视的。合理的折中方式是核心循环和矩阵乘放在 C 内核里线程调度和任务编排放在 Lisp 层尽量让 GC 不参与高频路径。这样既保留了 Lisp 的表达力又避开了 GC 对实时性的影响。2.3 AVX2 与精度不是所有加速都等价AVX2 是 CPU 的 256 位 SIMD 指令集一次可以处理 8 个单精度浮点数或 4 个双精度浮点数。对矩阵乘来说AVX2 配合 FMA 指令可以同时完成乘法和加法是 CPU 推理最常用的加速手段之一。同样关键的是AVX2 并不等于模型精度就是 FP16。一个容易被误解的点是AVX2 原生工作精度主要是整数和单精度浮点。FP16 可以通过 F16C 指令在寄存器里转成 FP32 计算BF16 则需要软件模拟或额外的转换逻辑。所以 CPU 推理引擎里常见的策略是权重和 KV Cache 用低精度存储到计算时再转成 FP32 做矩阵乘。存储精度决定内存占用计算精度决定数值结果这两者可以分离。FP32 最准确但最占内存和带宽FP16 能减少一半存储但表示范围小容易出现数值溢出BF16 保留了和 FP32 一样的指数位只截断尾数位在模型推理中更抗数值误差也是很多推理场景的首选中间精度。对 LLM 推理来说decode 阶段往往是内存带宽瓶颈存储精度每降低一档同一带宽能搬更多权重生成延迟通常也会随之改善。写自己的内核时换一次存储精度就能立刻感受到吞吐差异这种体感是看框架文档无法获得的。2.4 为什么偏偏是 Common LispCommon Lisp 在现代工程里确实小众但它有几个不适合营销却很实用的底子。SBCL 编译器会把代码编译成原生机器码不是解释执行类型声明写清楚后局部性能可以接近 C。Lisp 的宏可以在编译期生成代码适合批量展开算子内核。REPL 环境让开发者可以在运行时改函数、查状态这对调试模型加载和数值问题极其友好。但是Common Lisp 的运行时也有自己的问题。默认的垃圾回收器可能带来不可预测的暂停如果你在推理循环里大量生成临时对象GC 压力很快会让性能变得难看。这要求引擎作者在核心路径上有意识地使用固定数组、内存池和declare类型声明把临时分配控制到最低。这样的约束反而逼出了一个推理引擎工程师最应该养成的习惯永远关注内存生命周期。3. LLM 推理引擎到底要做哪些事不管是 C、Rust 还是 Common Lisp一个完整的 LLM 推理引擎都绕不开这几个模块。模块职责最容易出错的地方Tokenizer将文本转成 token id词表加载、特殊 token 处理模型加载读取权重并进行精度转换文件格式、字节序、张量布局Transformer 前向执行 embedding、注意力、FFN、归一化矩阵维度和缓存对齐KV Cache缓存历史 Key/Value避免重复计算内存分配、序列长度管理采样与解码top-k、top-p、temperature逐 token 生成随机数一致性和线程安全3.1 Tokenizer最无聊但必须正确Tokenizer 看上去简单实际是推理链路里最容易被低估的部分。BPE 或 SentencePiece 词表可能包含几万到几十万个 token文本转 token 的规则一大堆特殊 token 的处理也容易出问题。如果你做的是一个研究型推理引擎初期可以用最朴素的字符级 tokenizer 跑通流程把词表相关的复杂度放到后面。这样你能更快进入算子实现等到需要跑真实模型时再补充完整 tokenizer。3.2 模型加载Bare-Metal 的第一道坎模型加载是最典型的 Bare-Metal 问题。框架会替你完成权重读取、逆序列化、量化参数还原但裸机引擎必须自己解析。一个实用做法是先把模型权重导出成自定义二进制格式每个张量记录名称、维度、类型和数据偏移。加载时直接把这些字段映射到内存随后按精度要求做转换将权重搬到计算缓冲区。在这个环节你会遇到两个问题一是字节序权重文件按小端导出的在你的 CPU 上可能没问题但如果以后要跨平台运行字节序检查就不能省二是张量布局Transformer 的权重经常是二维矩阵行主序和列主序会让后续算子全部不同必须在一开始就确定。从设计文档的角度这个模块值得用注释写清楚每个张量的形状如何从 GPT 模型文件映射到内存布局。3.3 Transformer 前向矩阵乘不是全部Transformer 的每一层由多头注意力、FFN、RMSNorm 或 LayerNorm 组成。矩阵乘确实占大头但注意力里的 QK^T 和 softmax、归一化里的均值方差计算也需要高效的向量化实现。AVX2 加速可以在这些算子中同时发挥作用比如用向量指令做exp近似、做批量减法除法。真正困难的不是某个算子的数学公式而是张量如何在内存中连续排列。连续内存可以让 SIMD 满载稀疏跳跃的内存布局则会让向量化效率大幅下降。一个经验是先写出正确但朴素的前向计算再去优化单点的 kernel。不要一开始就钻进 AVX2 细节否则数值错误会和性能问题搅在一起。3.4 KV Cache多线程下的共享难题KV Cache 是推理引擎里最需要提前规划的组件。每个序列都有自己的历史和缓存而多线程并发处理多个序列时每个线程要访问不同的缓存区域。如果 KV Cache 每来一个 token 就动态分配内存垃圾回收和内存碎片会迅速变成瓶颈。更稳妥的做法是预先分配一块连续内存按最大序列长度分成固定槽位再使用 offset 索引访问。这样既能避免重复分配也让线程之间自然隔离。代价是内存利用率不高因为你必须按最坏情况预留空间。后续如果想做连续批处理还需要在 slot 之间迁移 KV Cache这部分工程量和操作系统的内存整理很像。3.5 采样与解码推理最后一步采样器的实现相对简单但要注意随机数生成器的线程安全。如果多个 worker 线程共享同一个 RNG 实例需要加锁或使用线程独立的 RNG。温度、top-k、top-p 这些参数会直接影响生成质量在推理引擎里通常设计成可配置项。从工程角度看采样器应该是纯函数式输入输出便于单测。4. Common Lisp 做高性能计算的三张底牌4.1 SBCL 的类型声明与编译器优化很多对 Lisp 性能的刻板印象来自几十年前的解释器实现。现代 SBCL 会把代码编译成原生机器码并且支持细粒度的优化声明。比如下面的 SAXPY 循环只要写出类型声明SBCL 可以生成接近 C 的本地代码。(declaim (ftype (function ((simple-array single-float (*)) (simple-array single-float (*)) single-float fixnum)) (values)) saxpy)) (defun saxpy (x y a n) (declare (optimize (speed 3) (safety 0) (debug 0))) (loop for i below n do (setf (aref y i) ( (aref y i) (* a (aref x i))))))这里真正关键的是optimize声明。推理引擎里的核心循环通常要设置高速度、低安全检查否则自动生成的边界检查会拖累所有热点函数。但这也意味着你要自己保证索引不越界。对追求性能的裸机引擎来说这种“用安全换速度”的权衡是常见的。4.2 FFI把 SIMD 内核交给 CCommon Lisp 写复杂 SIMD 内核的代价很高更稳妥的路径是用 C 写 AVX2 内核编译成动态库再用 CFFI 绑定。这个组合既保留了性能又保留了 Lisp 在调度、错误处理和数据封装上的表达力。推理引擎的核心算子基本都是这种模式Lisp 负责组织和调度C 负责密集计算。4.3 宏批量生成算子和调度代码宏可以直接生成大量重复代码。比如一个针对不同 tile size 的矩阵乘内核可以用宏根据参数展开成不同版本的循环体一个显式内存对齐的加载函数也可以用宏为 float、double、int 分别生成版本。这让 Lisp 在“用代码生成代码”这条路上比 C 更舒服你不需要写一堆预处理器宏而是用语言原生能力完成编译期生成。5. 环境准备与基础配置无论你打算深入阅读 llambda.lisp还是想自己从零搭一个最小推理引擎环境准备都是第一步。这里给出通用思路具体版本以你的实际系统为准。5.1 安装 SBCL 与 Quicklisp在 Ubuntu/Debian 上可以这样安装sudo apt-get install sbcl然后安装 Quicklisp。进入 SBCL 的 REPL 后执行下载好的quicklisp.lisp安装脚本再执行(load ~/quicklisp/setup.lisp) (ql:quickload :cffi) (ql:quickload :bordeaux-threads)CFFI 是 Common Lisp 外部函数接口库用来加载 C 动态库Bordeaux Threads 是可移植的多线程库用来管理线程和锁。这两个库几乎是我能想到的 Lisp 高性能开发的最小依赖集。5.2 确认 CPU 支持 AVX2如果你的 CPU 不支持 AVX2那么 AVX2 内核会直接触发非法指令错误。在 Linux 上可以用下面命令快速确认grep -o avx2 /proc/cpuinfo | head -n 1如果有输出说明 CPU 支持 AVX2。汇编层面还可以用objdump检查编译产物里是否出现了vfmadd或vmulps等指令这能帮你确认代码真正跑在了向量指令上。6. 完整示例Lisp 调用 C AVX2 向量点积内核这一节用一个最小骨架演示“Lisp 调度 C SIMD 内核”的搭配方式。先写 C 内核实现一个单精度浮点向量的点积用 AVX2 和 FMA 加速。文件路径dot_kernel.c#include immintrin.h float dot_f32(const float *a, const float *b, int n) { __m256 acc _mm256_setzero_ps(); int i 0; for (; i n - 8; i 8) { __m256 va _mm256_loadu_ps(a i); __m256 vb _mm256_loadu_ps(b i); acc _mm256_fmadd_ps(va, vb, acc); } __m128 low _mm256_castps256_ps128(acc); __m128 high _mm256_extractf128_ps(acc, 1); low _mm_add_ps(low, high); __m128 shuf _mm_movehdup_ps(low); __m128 sums _mm_add_ps(low, shuf); shuf _mm_movehl_ps(sums, sums); sums _mm_add_ss(sums, shuf); return _mm_cvtss_f32(sums); }这段代码先对每 8 个 float 做 FMA 累加最后用水平加法把 8 个部分和归约成一个数。编译成动态库时需要开启 AVX2 和 FMA 指令。gcc -O3 -mavx2 -mfma -shared -fPIC -o libdotf32.so dot_kernel.c然后在 Common Lisp 里通过 CFFI 绑定并调用。文件路径ffi-dot.lisp(ql:quickload :cffi) (cffi:define-foreign-library libdotf32 (:unix libdotf32.so)) (cffi:use-foreign-library libdotf32) (cffi:defcfun (dot_f32 dot-f32) :float (a :pointer) (b :pointer) (n :int)) (defun dot-lisp (a-list b-list) (check-type a-list list) (check-type b-list list) (when (/ (length a-list) (length b-list)) (error 两个向量的长度不一致)) (cffi:with-foreign-objects ((a :float (length a-list)) (b :float (length b-list))) (loop for x in a-list for i from 0 do (setf (cffi:mem-aref a :float i) (coerce x single-float))) (loop for x in b-list for i from 0 do (setf (cffi:mem-aref b :float i) (coerce x single-float))) (dot-f32 a b (length a-list))))在 REPL 中运行(dot-lisp (1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0) (1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0))预期输出是36.0。这个例子虽然只是点积但已经包含了推理引擎里最核心的链路把数据从 Lisp 世界拷贝到 C 的连续缓冲区让 CPU 用 FMA 指令完成向量运算再回到 Lisp 世界。真正的矩阵乘无非是把这一步放大 N 倍并处理分块和缓存。7. 多线程推理与 KV Cache 的工程细节7.1 一个简单的任务队列Bare-Metal 推理引擎通常自己管理线程池。下面是一个用 Bordeaux Threads 写的最小任务队列示例多个 worker 从队列取任务执行推理。这个代码强调思路生产环境建议用更成熟的库如chanl或calispel。(ql:quick 
长河君 · 2026/8/31 17:45:35 · 阅读 1.2k 用Common Lisp实现裸机LLM推理引擎：AVX2加速与多线程调度
如果在 2024 年还有人告诉你他想用 Common Lisp 写一个 LLM 推理引擎不依赖 PyTorch自己读权重文件用 AVX2 指令加速矩阵运算还要手动管理多线程调度你大概率会觉得这是行为艺术。但这个判断值得再想一次。LLM 推理真正吃功夫的地方不在调用现成框架而在搞明白权重从哪里来、矩阵乘怎么才能算得快、KV Cache 怎么存、token 流怎么调度。这些问题的大部分跟用 Python 还是 C 关系不大真正有关系的是你有没有把抽象层降到足够低把所有内存带宽和计算资源握在自己手里。llambda.lisp 正是一个把这两件事同时推到极致的项目用 Common Lisp 作宿主语言直接面对 CPU 指令集和内存布局完成一套 LLM 推理引擎。这篇文章会拆解它到底在做什么也会给出一个最小可运行的技术骨架让普通后端开发者理解这类“裸机推理引擎”的价值以及它能带来哪些可迁移的知识。1. 为什么会有“用 Lisp 写 LLM 推理引擎”这种反主流选择今天的推理引擎生态已经被几个大名字占领Python PyTorch 适合研究和快速验证llama.cpp 是 CPU 推理的事实标准TensorRT-LLM 和 vLLM 则把 GPU 上的吞吐优化做到极致。在这个背景下用 Common Lisp 写推理引擎显得极其另类。但另类不意味着没有价值它背后通常有至少三个动机。第一是理解质量。用 llama.cpp 跑模型时你知道权重是 GGUF 格式但一个 q4_K_M 量化的矩阵在内存里如何排列、如何被反量化、如何参与矩阵乘绝大多数人不会深入研究。一旦你决定自己写推理引擎这些细节就全部变成必须实现的功能。你需要定义权重文件的读取方式、决定张量布局、写算子内核、选择 KV Cache 的分配策略。整个过程会让 LLM 推理从一个“调用链”变成一个完整的知识体系。第二是 Lisp 的宏与交互式开发。Common Lisp 的宏不是简单的字符串替换而是在编译期操作抽象语法树。对推理引擎来说你可以用宏为矩阵分块、循环展开、内存对齐写一套生成器让编译器替你批量生成代码。REPL 则允许你加载模型、跑到某一层、观察中间张量值再改代码再跑调试密度比大型 C 工程高很多。第三是对主流方案的主动反思。很多人觉得“用 Python 调框架”就是大模型开发的全部但实际上 LLM 推理从底向上是一层一层叠加出来的指令集、内存分配、算子内核、模型权重、采样策略、服务调度。每一层都有人替你做了但如果你从未亲手实现过某一层你就很难在性能瓶颈出现时准确定位问题。llambda.lisp 这类项目就是把自己扔到最底层去重新走一遍这条路。当然也必须承认边界。这类项目大概率不会成为生产推理服务的主流它在 GPU 生态、成熟量化算子库、稳定 ABI 方面没有优势。但它的存在意义更接近“CPU 推理引擎的解剖样本”也呼应了最近很多人提倡的“手动实现一遍模型LLM 就祛魅了”的思路。对一个工程师来说读过一次源码和亲手写过一次内核带来的理解深度完全不同。2. 拆解标题里的四个关键词llambda.lisp 这个项目名几乎是把所有技术特征都写进了标题Bare-Metal、Multi-Threaded、AVX2-Accelerated、in CL。逐个拆开看每个词都对应推理引擎中的一类硬问题。关键词技术含义在 LLM 推理中的作用典型工作Bare-Metal不依赖大型框架自行管理权重读取、内存分配和计算流程移除 PyTorch/TensorFlow 等运行时依赖直接操作权重权重加载、内存映射、算子调度Multi-Threaded多线程并发执行并行处理 batch 内多个序列或加速单序列解码线程池、同步原语、批次调度AVX2-Accelerated使用 CPU 的 AVX2 SIMD 指令集矩阵乘、注意力、LayerNorm 获得向量化加速矩阵乘、softmax、向量规约in CL使用 Common Lisp 作为实现语言用 SBCL 编译原生代码通过 FFI 调用底层 C 内核运行时、垃圾回收、FFI 桥接2.1 Bare-Metal 到底意味着什么Bare-Metal 在 LLM 推理语境下通常指“不借助运行时框架直接在 CPU 上执行计算”。一个 PyTorch 推理程序启动时会加载巨大的运行时库完成自动微分图的调度再分派到后端算子库。而 Bare-Metal 推理引擎会直接读取权重文件把参数按照预定布局放到内存里然后用循环和 SIMD 指令逐层执行 Transformer 算子。这中间的差别不是代码量而是控制粒度。Bare-Metal 引擎的作者必须回答这几个问题权重文件是二进制还是文本是否需要字节序转换量化的 scale 和 zero point 存在哪里矩阵是行主序还是列主序这些问题在框架时代都会被隐藏但在裸机引擎里每一个都是绕不过去的设计决策。这里真正容易踩坑的地方是文件格式解析。LLM 权重文件动辄几 GB如果采用基于文本的格式加载时间会非常难看的。合理的做法是使用简单二进制格式甚至直接把权重按内存布局导出加载时用mmap映射到进程地址空间。这样既能降低启动时间也能让后续的 KV Cache 分配和权重读取共用一套内存管理逻辑。2.2 Multi-Threaded 的调度意义LLM 推理在 CPU 上的耗时主要分两段prefill 阶段要处理整段输入计算量大受算力限制decode 阶段一次只生成一个 token权重读取和 KV Cache 访问占主导受内存带宽限制。多线程在这两段中的优化目标完全不同。prefill 阶段通常希望把一个 batch 的序列拼成一个大的矩阵乘让 SIMD 单元满载。decode 阶段则更适合把不同序列分给不同线程让每个线程独立做一个小 batch 的自回归解码。这样一来线程间的同步点需要精心设计否则频繁的锁竞争会把并行收益完全吃掉。越是接近 Bare-Metal 的引擎越需要自己写线程池和任务队列这也正是 Lisp 这类带垃圾回收的语言被质疑的地方GC 带来的暂停和不可预测性在低延迟推理场景里是需要重视的。合理的折中方式是核心循环和矩阵乘放在 C 内核里线程调度和任务编排放在 Lisp 层尽量让 GC 不参与高频路径。这样既保留了 Lisp 的表达力又避开了 GC 对实时性的影响。2.3 AVX2 与精度不是所有加速都等价AVX2 是 CPU 的 256 位 SIMD 指令集一次可以处理 8 个单精度浮点数或 4 个双精度浮点数。对矩阵乘来说AVX2 配合 FMA 指令可以同时完成乘法和加法是 CPU 推理最常用的加速手段之一。同样关键的是AVX2 并不等于模型精度就是 FP16。一个容易被误解的点是AVX2 原生工作精度主要是整数和单精度浮点。FP16 可以通过 F16C 指令在寄存器里转成 FP32 计算BF16 则需要软件模拟或额外的转换逻辑。所以 CPU 推理引擎里常见的策略是权重和 KV Cache 用低精度存储到计算时再转成 FP32 做矩阵乘。存储精度决定内存占用计算精度决定数值结果这两者可以分离。FP32 最准确但最占内存和带宽FP16 能减少一半存储但表示范围小容易出现数值溢出BF16 保留了和 FP32 一样的指数位只截断尾数位在模型推理中更抗数值误差也是很多推理场景的首选中间精度。对 LLM 推理来说decode 阶段往往是内存带宽瓶颈存储精度每降低一档同一带宽能搬更多权重生成延迟通常也会随之改善。写自己的内核时换一次存储精度就能立刻感受到吞吐差异这种体感是看框架文档无法获得的。2.4 为什么偏偏是 Common LispCommon Lisp 在现代工程里确实小众但它有几个不适合营销却很实用的底子。SBCL 编译器会把代码编译成原生机器码不是解释执行类型声明写清楚后局部性能可以接近 C。Lisp 的宏可以在编译期生成代码适合批量展开算子内核。REPL 环境让开发者可以在运行时改函数、查状态这对调试模型加载和数值问题极其友好。但是Common Lisp 的运行时也有自己的问题。默认的垃圾回收器可能带来不可预测的暂停如果你在推理循环里大量生成临时对象GC 压力很快会让性能变得难看。这要求引擎作者在核心路径上有意识地使用固定数组、内存池和declare类型声明把临时分配控制到最低。这样的约束反而逼出了一个推理引擎工程师最应该养成的习惯永远关注内存生命周期。3. LLM 推理引擎到底要做哪些事不管是 C、Rust 还是 Common Lisp一个完整的 LLM 推理引擎都绕不开这几个模块。模块职责最容易出错的地方Tokenizer将文本转成 token id词表加载、特殊 token 处理模型加载读取权重并进行精度转换文件格式、字节序、张量布局Transformer 前向执行 embedding、注意力、FFN、归一化矩阵维度和缓存对齐KV Cache缓存历史 Key/Value避免重复计算内存分配、序列长度管理采样与解码top-k、top-p、temperature逐 token 生成随机数一致性和线程安全3.1 Tokenizer最无聊但必须正确Tokenizer 看上去简单实际是推理链路里最容易被低估的部分。BPE 或 SentencePiece 词表可能包含几万到几十万个 token文本转 token 的规则一大堆特殊 token 的处理也容易出问题。如果你做的是一个研究型推理引擎初期可以用最朴素的字符级 tokenizer 跑通流程把词表相关的复杂度放到后面。这样你能更快进入算子实现等到需要跑真实模型时再补充完整 tokenizer。3.2 模型加载Bare-Metal 的第一道坎模型加载是最典型的 Bare-Metal 问题。框架会替你完成权重读取、逆序列化、量化参数还原但裸机引擎必须自己解析。一个实用做法是先把模型权重导出成自定义二进制格式每个张量记录名称、维度、类型和数据偏移。加载时直接把这些字段映射到内存随后按精度要求做转换将权重搬到计算缓冲区。在这个环节你会遇到两个问题一是字节序权重文件按小端导出的在你的 CPU 上可能没问题但如果以后要跨平台运行字节序检查就不能省二是张量布局Transformer 的权重经常是二维矩阵行主序和列主序会让后续算子全部不同必须在一开始就确定。从设计文档的角度这个模块值得用注释写清楚每个张量的形状如何从 GPT 模型文件映射到内存布局。3.3 Transformer 前向矩阵乘不是全部Transformer 的每一层由多头注意力、FFN、RMSNorm 或 LayerNorm 组成。矩阵乘确实占大头但注意力里的 QK^T 和 softmax、归一化里的均值方差计算也需要高效的向量化实现。AVX2 加速可以在这些算子中同时发挥作用比如用向量指令做exp近似、做批量减法除法。真正困难的不是某个算子的数学公式而是张量如何在内存中连续排列。连续内存可以让 SIMD 满载稀疏跳跃的内存布局则会让向量化效率大幅下降。一个经验是先写出正确但朴素的前向计算再去优化单点的 kernel。不要一开始就钻进 AVX2 细节否则数值错误会和性能问题搅在一起。3.4 KV Cache多线程下的共享难题KV Cache 是推理引擎里最需要提前规划的组件。每个序列都有自己的历史和缓存而多线程并发处理多个序列时每个线程要访问不同的缓存区域。如果 KV Cache 每来一个 token 就动态分配内存垃圾回收和内存碎片会迅速变成瓶颈。更稳妥的做法是预先分配一块连续内存按最大序列长度分成固定槽位再使用 offset 索引访问。这样既能避免重复分配也让线程之间自然隔离。代价是内存利用率不高因为你必须按最坏情况预留空间。后续如果想做连续批处理还需要在 slot 之间迁移 KV Cache这部分工程量和操作系统的内存整理很像。3.5 采样与解码推理最后一步采样器的实现相对简单但要注意随机数生成器的线程安全。如果多个 worker 线程共享同一个 RNG 实例需要加锁或使用线程独立的 RNG。温度、top-k、top-p 这些参数会直接影响生成质量在推理引擎里通常设计成可配置项。从工程角度看采样器应该是纯函数式输入输出便于单测。4. Common Lisp 做高性能计算的三张底牌4.1 SBCL 的类型声明与编译器优化很多对 Lisp 性能的刻板印象来自几十年前的解释器实现。现代 SBCL 会把代码编译成原生机器码并且支持细粒度的优化声明。比如下面的 SAXPY 循环只要写出类型声明SBCL 可以生成接近 C 的本地代码。(declaim (ftype (function ((simple-array single-float (*)) (simple-array single-float (*)) single-float fixnum)) (values)) saxpy)) (defun saxpy (x y a n) (declare (optimize (speed 3) (safety 0) (debug 0))) (loop for i below n do (setf (aref y i) ( (aref y i) (* a (aref x i))))))这里真正关键的是optimize声明。推理引擎里的核心循环通常要设置高速度、低安全检查否则自动生成的边界检查会拖累所有热点函数。但这也意味着你要自己保证索引不越界。对追求性能的裸机引擎来说这种“用安全换速度”的权衡是常见的。4.2 FFI把 SIMD 内核交给 CCommon Lisp 写复杂 SIMD 内核的代价很高更稳妥的路径是用 C 写 AVX2 内核编译成动态库再用 CFFI 绑定。这个组合既保留了性能又保留了 Lisp 在调度、错误处理和数据封装上的表达力。推理引擎的核心算子基本都是这种模式Lisp 负责组织和调度C 负责密集计算。4.3 宏批量生成算子和调度代码宏可以直接生成大量重复代码。比如一个针对不同 tile size 的矩阵乘内核可以用宏根据参数展开成不同版本的循环体一个显式内存对齐的加载函数也可以用宏为 float、double、int 分别生成版本。这让 Lisp 在“用代码生成代码”这条路上比 C 更舒服你不需要写一堆预处理器宏而是用语言原生能力完成编译期生成。5. 环境准备与基础配置无论你打算深入阅读 llambda.lisp还是想自己从零搭一个最小推理引擎环境准备都是第一步。这里给出通用思路具体版本以你的实际系统为准。5.1 安装 SBCL 与 Quicklisp在 Ubuntu/Debian 上可以这样安装sudo apt-get install sbcl然后安装 Quicklisp。进入 SBCL 的 REPL 后执行下载好的quicklisp.lisp安装脚本再执行(load ~/quicklisp/setup.lisp) (ql:quickload :cffi) (ql:quickload :bordeaux-threads)CFFI 是 Common Lisp 外部函数接口库用来加载 C 动态库Bordeaux Threads 是可移植的多线程库用来管理线程和锁。这两个库几乎是我能想到的 Lisp 高性能开发的最小依赖集。5.2 确认 CPU 支持 AVX2如果你的 CPU 不支持 AVX2那么 AVX2 内核会直接触发非法指令错误。在 Linux 上可以用下面命令快速确认grep -o avx2 /proc/cpuinfo | head -n 1如果有输出说明 CPU 支持 AVX2。汇编层面还可以用objdump检查编译产物里是否出现了vfmadd或vmulps等指令这能帮你确认代码真正跑在了向量指令上。6. 完整示例Lisp 调用 C AVX2 向量点积内核这一节用一个最小骨架演示“Lisp 调度 C SIMD 内核”的搭配方式。先写 C 内核实现一个单精度浮点向量的点积用 AVX2 和 FMA 加速。文件路径dot_kernel.c#include immintrin.h float dot_f32(const float *a, const float *b, int n) { __m256 acc _mm256_setzero_ps(); int i 0; for (; i n - 8; i 8) { __m256 va _mm256_loadu_ps(a i); __m256 vb _mm256_loadu_ps(b i); acc _mm256_fmadd_ps(va, vb, acc); } __m128 low _mm256_castps256_ps128(acc); __m128 high _mm256_extractf128_ps(acc, 1); low _mm_add_ps(low, high); __m128 shuf _mm_movehdup_ps(low); __m128 sums _mm_add_ps(low, shuf); shuf _mm_movehl_ps(sums, sums); sums _mm_add_ss(sums, shuf); return _mm_cvtss_f32(sums); }这段代码先对每 8 个 float 做 FMA 累加最后用水平加法把 8 个部分和归约成一个数。编译成动态库时需要开启 AVX2 和 FMA 指令。gcc -O3 -mavx2 -mfma -shared -fPIC -o libdotf32.so dot_kernel.c然后在 Common Lisp 里通过 CFFI 绑定并调用。文件路径ffi-dot.lisp(ql:quickload :cffi) (cffi:define-foreign-library libdotf32 (:unix libdotf32.so)) (cffi:use-foreign-library libdotf32) (cffi:defcfun (dot_f32 dot-f32) :float (a :pointer) (b :pointer) (n :int)) (defun dot-lisp (a-list b-list) (check-type a-list list) (check-type b-list list) (when (/ (length a-list) (length b-list)) (error 两个向量的长度不一致)) (cffi:with-foreign-objects ((a :float (length a-list)) (b :float (length b-list))) (loop for x in a-list for i from 0 do (setf (cffi:mem-aref a :float i) (coerce x single-float))) (loop for x in b-list for i from 0 do (setf (cffi:mem-aref b :float i) (coerce x single-float))) (dot-f32 a b (length a-list))))在 REPL 中运行(dot-lisp (1.0 2.0 3.0 4.0 5.0 6.0 7.0 8.0) (1.0 1.0 1.0 1.0 1.0 1.0 1.0 1.0))预期输出是36.0。这个例子虽然只是点积但已经包含了推理引擎里最核心的链路把数据从 Lisp 世界拷贝到 C 的连续缓冲区让 CPU 用 FMA 指令完成向量运算再回到 Lisp 世界。真正的矩阵乘无非是把这一步放大 N 倍并处理分块和缓存。7. 多线程推理与 KV Cache 的工程细节7.1 一个简单的任务队列Bare-Metal 推理引擎通常自己管理线程池。下面是一个用 Bordeaux Threads 写的最小任务队列示例多个 worker 从队列取任务执行推理。这个代码强调思路生产环境建议用更成熟的库如chanl或calispel。(ql:quick