在实际工程里一个名为llambda.lisp的项目标题往往比一篇几百行的 README 能传达更多信息。它同时包含Bare-Metal、Multi-Threaded、AVX2-Accelerated和CL四个关键词说明这个项目不是调用 PyTorch 或 TensorFlow 高层封装而是试图用 Common Lisp 直接面对 CPU 指令集、内存布局和线程调度构建一个 LLM 推理引擎。对很多只会“import torch”的开发者来说这条路离日常开发很远但如果你有模型部署、算子优化、嵌入式推理或性能调优经历就会意识到这条路线指向的问题很具体模型推理的真正瓶颈在哪里框架能不能帮你解决一切。这篇文章以llambda.lisp这类项目为背景拆解一个 Common Lisp 实现的 LLM 推理引擎需要面对的核心问题。你会理解“裸金属”在这里意味着什么为什么矩阵乘法是绕不开的计算中心AVX2 指令集在推理时到底加速什么以及多线程应该切在哪个粒度。文章不会给出现成的完整引擎代码而是提供足够可复现的模块结构、示例代码、验证方法和排查路径。学完以后你可以在自己的机器上按相同思路搭一个最小推理引擎骨架也可以把这个思路迁移到 C、Rust 或 Zig 项目里解决同样类型的性能问题。1. 先理解llambda.lisp要解决的问题1.1 为什么“LLM 推理”不能只用高层框架大多数开发者在本地跑 LLM 时第一反应是安装 transformers、llama.cpp 或 vLLM。这些工具能跑通是因为它们已经把模型加载、张量计算、KV Cache、采样逻辑封装好了。问题是封装层越厚你离性能和可控性越远。生产环境里经常遇到这样的情况模型能跑但吞吐不够推理流程正常但某一层算子耗时异常换了一台只有 AVX2 的 CPU跑出来的性能和官方基准差距很大。llambda.lisp这类项目选择走另一条路不依赖重型训练框架而是在语言运行时里直接实现推理所需的最小子集。这里的“Bare-Metal”不是指没有操作系统而是指尽可能少地依赖外部计算库把张量存储、矩阵乘、注意力计算、线程调度都掌握在自己手里。Common Lisp 在这里的优势不是性能本身而是交互式开发能力。你可以一边修改算子实现一边在同一次会话里重新编译并立刻测性能这对算子调优非常有利。1.2 “Bare-Metal”这个描述实际指向什么Bare-Metal 在推理引擎语境里容易让人误会。它不是说要用裸机部署或绕过操作系统而是强调两层意思。第一层是计算栈很薄。项目不依赖 BLAS 库、不依赖 PyTorch甚至不依赖 OpenBLAS矩阵乘和激活函数都由自己的代码完成。这样做的代价是实现量大但换来的是可控性。在开发机上你可以精确知道自己写的矩阵乘占了多少时间而不需要去猜测 MKL 或 OpenBLAS 的内部调度。第二层是能直接操作内存和指令。Common Lisp 标准本身没有 SIMD 接口但可以通过 CFFI 调用 C 函数或者使用 SBCL 的 VOP 机制在 Lisp 代码里直接生成 AVX2 指令。这个层面做的事和 C/C 里写_mm256_fmadd_ps本质一样。1.3 为什么“多线程”和“AVX2”会同时出现LLM 推理的瓶颈集中在计算密集和访存密集两类操作上。矩阵乘、卷积是计算密集KV Cache 读写、激活值搬运是访存密集。AVX2 解决的是单核计算效率多线程解决的是多核吞吐。两者不是替代关系而是叠加关系。举个例子一个 2048 维的矩阵乘单核用两路 FMA 指令每时钟周期能处理 8 个浮点运算四核并行时理论上可以达到 32 个浮点运算每周期。前提是内存带宽没有成为瓶颈。所以llambda.lisp同时强调这两个关键字说明它至少在设计层面同时考虑了指令级并行和线程级并行。2. 构建推理引擎前先把架构和运行环境对齐2.1 推理引擎的最小架构张量、算子、调度、后端一个可以被称为“引擎”而不是“脚本”的推理程序至少要分成四层。第一层是张量层。它负责管理数据的内存布局、形状、步长和对齐方式。第二层是算子层。线性层、LayerNorm、Softmax、注意力这些计算都在这层实现。第三层是调度层。它决定一个推理请求如何在多线程上切分什么时候创建线程什么时候合并结果。第四层是后端层。它把算子的计算请求映射到具体指令集比如 AVX2、AVX-512或者之后的 GPU offload。llambda.lisp的粒度大概就是这样。标题里没有提“推理的全部流程”但一个能实际跑的 LLM 推理引擎至少要把这四层都打通。下面的章节会按这个顺序展开。2.2 环境准备SBCL、Quicklisp、系统依赖和 CPU 检查为了复现下面的示例建议准备一个 64 位 Linux 环境。Common Lisp 实现选择 SBCL因为它性能好而且提供了比较方便的调用外部 C 函数的通道。理论上 CCL 也可以但 SBCL 的资料和生态更齐全。需要安装的组件如下表组件用途常见版本或要求SBCLCommon Lisp 运行时2.x 以上64 位Quicklisp管理项目依赖最新版即可CFFI调用 C 函数通过 Quicklisp 安装bordeaux-threads多线程封装通过 Quicklisp 安装build-essential编译 C 代码gcc、make 等CPU 指令集运行 AVX2 指令支持avx2和fma先确认 CPU 是否支持 AVX2。Linux 下执行grep avx2 /proc/cpuinfo如果有输出说明当前 CPU 支持 AVX2。还要确认是否有 FMA 指令因为很多矩阵乘优化会用到_mm256_fmadd_ps。grep fma /proc/cpuinfo没有 AVX2 的机器也能跑代码但会退回普通 C 实现性能差异会很大。2.3 项目结构llambda.lisp的模块划分一个最小项目可以按下面的结构组织llambda.lisp/ ├── llambda.asd ├── src/ │ ├── package.lisp │ ├── tensor.lisp │ ├── avx2-backend.lisp │ ├── ops.lisp │ ├── threads.lisp │ └── model.lisp └── tests/ └── test-core.lisppackage.lisp定义包和导出符号tensor.lisp定义张量结构avx2-backend.lisp封装 C 函数调用ops.lisp实现矩阵乘、点乘、激活函数threads.lisp实现线程池和并行调度model.lisp把算子组装成 Transformer 层。这个结构把计算后端和模型逻辑分开后续想替换成 AVX-512 或 GPU 后端时不需要重写模型层。3. 张量设计与内存布局AVX2 加速的第一步不是指令3.1 张量对象如何组织形状和步长在 Python 里NumPy 和 PyTorch 已经替你把张量布局做好了。在 Common Lisp 里要自己定义。最简单的二维张量结构可以这样写(defstruct (tensor (:constructor make-tensor (shape data))) (shape nil :type (simple-array (unsigned-byte 64) (*))) (data nil :type (simple-array single-float (*)))) (defun create-tensor (rows cols) (make-tensor (make-array 2 :initial-contents (list rows cols)) (make-array (* rows cols) :element-type single-float :initial-element 0.0)))这里使用single-float数组也就是 32 位浮点。FP32是 LLM 推理里最常用于数值校验的精度。用一位数组保存连续内存二维形状通过shape记录。访问(i j)位置的元素时索引是( (* i cols) j)。这个设计保留了行优先布局。行优先意味着同一行的数据在内存里连续遍历一行时缓存命中率更高。3.2 为什么 SIMD 对对齐有要求AVX2 一次可以处理 8 个单精度浮点也就是 32 字节。如果数据首地址是 32 字节对齐的_mm256_load_ps可以直接加载不对齐时虽然可以用_mm256_loadu_ps但性能有损耗。矩阵乘和向量点乘会频繁把数组当成 8 个一组加载所以张量数据缓冲区最好按 32 字节对齐分配。在 C 里可以用aligned_alloc或posix_memalign。Common Lisp 的标准数组不保证对齐所以通常由 C 层分配缓冲区再把指针传给 Lisp。下面是一个简单的 C 函数#include stdlib.h #include stdint.h float* llambda_alloc_aligned(size_t n) { float* ptr NULL; if (posix_memalign((void**)ptr, 32, n * sizeof(float)) ! 0) { return NULL; } return ptr; } void llambda_free_aligned(void* ptr) { free(ptr); }然后用 CFFI 在 Lisp 里调用(cffi:defcfun llambda_alloc_aligned :pointer (n :size)) (defun allocate-aligned-tensor (rows cols) (let* ((ptr (llambda-alloc-aligned (* rows cols)))) (make-tensor (vector rows cols) ptr)))注意如果直接用 Lisp 的simple-array存储张量很多实现不保证 32 字节对齐。调试时看不出问题但性能测试时会出现波动。最稳妥的方式是把热点数据放在 C 层分配的内存中由 C 算子读取。3.3 校验张量创建和访存逻辑创建张量后可以写一个简单校验函数确认写入和读取一致(defun check-tensor-io () (let ((tensor (create-tensor 4 8))) (setf (tensor-value tensor 2 3) 1.0) (assert ( (tensor-value tensor 2 3) 1.0)) t))这里tensor-value是自己定义的 accessor(defun tensor-value (tensor i j) (let ((cols (aref (tensor-shape tensor) 1))) (aref (tensor-data tensor) ( (* i cols) j))))这一步看起来简单但提前验证访问方式可以避免后续矩阵乘因为行列索引反了查半天。4. AVX2 加速的核心算子从矩阵乘开始4.1 矩阵乘为什么是 LLM 推理的计算中心Transformer 结构里QKV投影、注意力分数、注意力输出投影、FFN 第一个线性层、FFN 第二个线性层全部是矩阵乘。一个 7B 参数模型在一次 token 推理中绝大多数时间花在矩阵乘和 LayerNorm 上。所以llambda.lisp这类项目首先要优化的是矩阵乘。最简单的矩阵乘三层循环(defun matmul-naive (a b rows inner cols) (let ((result (create-tensor rows cols))) (dotimes (i rows) (dotimes (j cols) (let ((sum 0.0)) (dotimes (k inner) (incf sum (* (tensor-value a i k) (tensor-value b k j)))) (setf (tensor-value result i j) sum)))) result))这段代码能跑但性能很差。原因有两个每次访问张量都做一次索引计算而且二层循环的访存模式对缓存不友好。计算c(i,j)时内层循环访问a(i,k)b(k,j)其中b(k,j)每次跳跃一列导致缓存频繁失效。4.2 用 C 和 AVX2 实现 FMA 矩阵乘流程Common Lisp 层面不适合逐元素写 SIMD 指令一般方式是用 CFFI 调用 C 函数。C 函数里使用 AVX2 的 FMA 指令。为了简化这里展示一个计算 8 个输出元素的核函数#include immintrin.h void llambda_gemm_8x8(const float* a, const float* b, float* c, int inner, int lda, int ldb, int ldc) { __m256 c0 _mm256_setzero_ps(); __m256 c1 _mm256_setzero_ps(); __m256 c2 _mm256_setzero_ps(); __m256 c3 _mm256_setzero_ps(); __m256 c4 _mm256_setzero_ps(); __m256 c5 _mm256_setzero_ps(); __m256 c6 _mm256_setzero_ps(); __m256 c7 _mm256_setzero_ps(); for (int k 0; k inner; k) { __m256 a0 _mm256_set1_ps(a[0 * lda k]); __m256 a1 _mm256_set1_ps(a[1 * lda k]); __m256 a2 _mm256_set1_ps(a[2 * lda k]); __m256 a3 _mm256_set1_ps(a[3 * lda k]); __m256 a4 _mm256_set1_ps(a[4 * lda k]); __m256 a5 _mm256_set1_ps(a[5 * lda k]); __m256 a6 _mm256_set1_ps(a[6 * lda k]); __m256 a7 _mm256_set1_ps(a[7 * lda k]); __m256 bv _mm256_loadu_ps(b[k * ldb]); c0 _mm256_fmadd_ps(a0, bv, c0); c1 _mm256_fmadd_ps(a1, bv, c1); c2 _mm256_fmadd_ps(a2, bv, c2); c3 _mm256_fmadd_ps(a3, bv, c3); c4 _mm256_fmadd_ps(a4, bv, c4); c5 _mm256_fmadd_ps(a5, bv, c5); c6 _mm256_fmadd_ps(a6, bv, c6); c7 _mm256_fmadd_ps(a7, bv, c7); } _mm256_storeu_ps(c[0 * ldc], c0); _mm256_storeu_ps(c[1 * ldc], c1); _mm256_storeu_ps(c[2 * ldc], c2); _mm256_storeu_ps(c[3 * ldc], c3); _mm256_storeu_ps(c[4 * ldc], c4); _mm256_storeu_ps(c[5 * ldc], c5); _mm256_storeu_ps(c[6 * ldc], c6); _mm256_storeu_ps(c[7 * ldc], c7); }这段代码一次计算 8 行结果每行结果是一个 256 位向量覆盖 8 列。内层循环中a的每个值通过_mm256_set1_ps广播到 8 个通道b的一行加载为 8 个浮点两者做 FMA。调用时需要考虑维度。完整版还需要处理 inner 维度不是 8 倍数的情况或者用边界循环补齐。这里先聚焦 8 的倍数场景。4.3 分块和布局选择为什么B矩阵要提前转置或重排上面的核函数里b的访存是b[k * ldb]等于按行读取。如果b按行主序存储一次访问b[k][0..7]是连续的对缓存友好。但矩阵乘的定义里内层k循环同时遍历a的行和b的列。如果b保持列主序每次访问b[k][j]跳跃很大性能会下降。常见优化是提前把B重排成按块组织的格式例如把 8 列变成一组连续内存。这不是 AVX2 指令本身能解决的而是数据布局问题。llambda.lisp这类项目通常会在权重加载阶段就完成重排避免在推理热路径里反复做格式转换。4.4 用 Common Lisp 调用上面的核函数CFFI 定义如下(cffi:defcfun llambda_gemm_8x8 :void (a :pointer) (b :pointer) (c :pointer) (inner :int) (lda :int) (ldb :int) (ldc :int))在 Lisp 里封装一个矩阵乘函数(defun matmul-avx2 (a b rows inner cols) (let ((c (allocate-aligned-tensor rows cols))) (loop for i from 0 below rows by 8 do (loop for j from 0 below cols by 8 do (llambda-gemm-8x8 (tensor-data-pointer a) (tensor-data-pointer b) (tensor-data-pointer c) inner rows inner cols))) c))这里的参数还没有做边界检查也没有处理rows或cols不是 8 倍数的情况。真实项目需要补齐。建议没有 AVX2 环境时先写一个纯 C 的标量矩阵乘作为 baseline再和 AVX2 版本对比。这样能区分“SIMD 带来的提升”和“C 语言比 Lisp 快”这两个因素。5. 多线程调度切在哪个维度性能差别很大5.1 LLM 推理中的并行切分维度矩阵乘和多头注意力都可以并行。并行切在哪一层直接影响负载均衡和通信开销。并行维度适用场景优点缺点Batch 维度多个请求同时推理简单无数据竞争需要并发请求才能填满线程Head 维度单请求多头注意力天然独立易于并行Head 数有限Layer 维度多层 Transformer流水线化层间有依赖需要同步GEMM 分块单个矩阵乘内部线程利用率高实现复杂需要处理边角对于单请求推理场景第一批主流 LLM 推理引擎通常先在 Head 维度和矩阵乘输出列维度上切分。llambda.lisp作为学习项目可以先用 Head 维度并行因为多头注意力的每个 head 在计算注意力分数时互不依赖。5.2 用 bordeaux-threads 建立简单线程池每次推理都创建新线程并不可取。更合理的做法是启动一个固定大小的线程池把任务分配给工作线程。下面是一个最小线程池骨架(defclass thread-pool () ((workers :initarg :workers :accessor workers) (queue :initarg :queue :accessor queue))) (defun start-thread-pool (n) (let* ((queue (make-instance concurrent-queue)) (pool (make-instance thread-pool :workers nil :queue queue))) (setf (workers pool) (loop repeat n collect (bt:make-thread (lambda () (loop (let ((task (dequeue queue))) (when (null task) (return)) (funcall task))))))) pool))这里concurrent-queue和dequeue是示意接口实际可以用safe-queue或自己加锁。生产环境还要考虑任务如何结束这里先忽略。5.3 并行计算多头注意力的多个分数假设Q是(seq-len, head-dim)每个 head 有自己的Q、K、V。现在要计算 8 个 head 的注意力分数。可以这样切分(defun parallel-attention-scores (q-array k-array head-count) (let ((results (make-array head-count)) (tasks (loop for h below head-count collect (lambda () (setf (aref results h) (dot-product-batch (aref q-array h) (aref k-array h))))))) (submit-tasks *global-pool* tasks) results))这里的关键是每个任务只操作自己的 head 数据没有共享写冲突所以不需要加锁。results的每个位置由不同线程写天然隔离。5.4 多线程的常见坑假共享、任务切分不均、锁竞争并行注意力看似简单实际跑起来会遇到几个问题。第一个是任务切分粒度过粗。如果只有 8 个 head线程池有 16 个线程会有 8 个线程空转。处理办法是把单个矩阵乘也切成多块这样更容易填满线程池。第二个是假共享。多个线程写同一缓存行的不同位置时虽然逻辑上没有数据竞争但 CPU 缓存一致性协议会让写性能大幅下降。比如results数组如果用(simple-array double-float)相邻元素可能在同一缓存行。每个线程写不同位置仍然会导致缓存行频繁失效。解决方式是给每个线程单独一块输出缓冲最后合并。第三个是任务队列锁竞争。每次提交任务都加锁线程多时锁会成为瓶颈。可以用无锁队列或批量提交降低竞争。6. 把算子串成推理流程一个最小 Transformer 层骨架6.1 从算子到模型线性层、激活、注意力、LayerNorm有了矩阵乘就能实现 Transformer 的关键结构。一个最小 block 包括QKV 投影、多头注意力、残差连接、LayerNorm、FFN 线性层、FFN 激活。这里不追求完整复现 LLaMA 或 GPT 的结构而是展示如何把已实现的张量和算子拼起来。每个小函数只做一件事。(defun linear-forward (input weight bias) (let* ((m (tensor-rows input)) (n (tensor-cols weight)) (out (matmul-avx2 input weight m (tensor-rows weight) n))) (when bias (add-bias-in-place out bias)) out)) (defun gelu-forward (x) (let ((out (copy-tensor x))) (dotimes (i (tensor-size out)) (setf (tensor-data-value out i) (gelu-scalar (tensor-data-value out i)))) out))6.2 最小 Transformer block 伪代码(defun transformer-block (x attn-weights ffn-weights norm-weights) (let* ((residual x) (normed (layer-norm x norm-weights)) (attn-out (multi-head-attention normed attn-weights)) (hidden (add-tensors x attn-out)) (normed2 (layer-norm hidden ffn-weights)) (ffn-out (ffn-forward normed2 ffn-weights))) (add-tensors hidden ffn-out)))实际模型还需要处理 RoPE、KV Cache、因果掩码等。这里只是把主流程写清楚。6.3 精度和权重加载FP32、FP16、BF16 怎么选LLM 推理里不能只用 FP32。模型权重体积大FP32 会带来很高的内存带宽压力。常见选项如下精度表示方式优点缺点FP3232 位浮点精度高便于 debug内存占用大FP1616 位浮点指数 5 位体积减半范围小容易溢出BF1616 位浮点指数 8 位范围接近 FP32尾数精度低在llambda.lisp这类纯 CPU 推理引擎里可以先以 FP32 跑通流程再引入 FP16/BF16 作为优化。如果标题里提到“AVX2-Accelerated”要特别注意 FP16 的处理。AVX2 没有原生 FP16 点乘指令通常需要先把 FP16 转成 FP32 计算再用_mm256_cvtph_ps等指令做转换。AVX2 支持 FP16 存储和加载但计算常在 FP32 域完成。6.4 常见坑维度错误、形状不一致、数值溢出把算子串起来后报错会从index out of range变成更隐蔽的形状不匹配。矩阵乘时A的列数必须等于B的行数否则越界。LayerNorm 要按最后一维归一化不要按整个张量归一化。多头注意力拼接时head-dim和num-heads的顺序容易写反。FP16/FP32 混合计算时没有统一转换类型会导致精度异常。7. 验证与排查跑起来不等于跑对了7.1 数值一致性验证AVX2 指令本身不会改变数学结果但 FMA 的中间舍入和普通乘加不同结果会和标量实现有微小差异。验证时使用相对误差而不是完全相等。(defun assert-close (a b tol) (let ((diff (abs (- a b))) (scale (max (abs a) (abs b) 1.0))) (assert ( (/ diff scale) tol))))矩阵乘测试可以先用小矩阵对照朴素实现输入规模期望输出实际输出相对误差8x8 * 8x8朴素矩阵乘结果AVX2 矩阵乘结果小于1e-5视为通过7.2 性能测量只看总耗时是不够的测量推理性能时要把加载权重、填充张量、计算、写回结果分开计时。比如(time (matmul-avx2 a b 512 512 512))用time宏可以看实时时间和 GC 时间。如果 GC 时间占比高说明热点路径上产生了大量临时数组。这是 Common Lisp 推理引擎最容易出现的问题之一解决方法是复用缓冲区。也可以对比实现方式耗时说明朴素三重循环 Lisp200ms最差基线Lisp 调用标量 C80msC 编译优化收益Lisp 调用 AVX2 C35msSIMD 收益8 线程并行 AVX28ms多线程收益这个表只是示例真实数据会因 CPU 和问题规模变化。7.3 性能瓶颈排查链路遇到性能不达标时不要直接怀疑 AVX2 代码。按下面的顺序排查先确认是否真的在跑 AVX2 分支。检查 C 函数编译时是否加了-mavx2 -mfma。再确认数据是否对齐。未对齐的_mm256_load_ps会崩溃使用_mm256_loadu_ps能跑但性能下降。确认线程数量是否超过 CPU 物理核数。超线程带来的收益在纯计算任务中可能很小。确认是否出现 GC。Common Lisp 里大量分配临时张量会产生 GC 压力。用perf stat看 CPU 利用率、缓存未命中和内存带宽。7.4 常见错误现象与处理方案问题现象常见原因检查方式处理建议运行时 SIGSEGV指针越界或未对齐加载检查 CFFI 参数维度用valgrind或 ASAN 编译 C 代码结果与朴素实现差异大行列索引顺序写反打印中间张量形状编写形状断言函数多线程后变慢锁竞争或任务切分太碎查看线程数和耗时分布增大任务粒度减少锁次数GC 时间占比高每步都创建新张量time观察 GC复用输出缓冲区编译 C 扩展失败头文件缺失或编译器不支持运行gcc -mavx2 -mfma安装 build-essential升级 gcc8. 从学习原型到可用引擎最佳实践与扩展方向8.1 学习环境和生产环境的差异在开发机上跑通llambda.lisp只是一小步。真正生产部署还需要额外考虑模型格式转换、权重文件读取、在线更新、崩溃恢复、日志监控等。学习环境的重点是快速验证算子正确性和并行策略。生产环境至少还要关注配置外置化模型路径、线程数、精度选项不能硬编码在 Lisp 源码里。异常处理算子出现的每个错误都应该带出张量形状和算子名称。日志监控记录每层耗时、token 生成耗时、内存占用。回滚方案如果模型权重更新后出现质量下降要能快速切回旧权重。8.2 可复用清单部署和检查项在把推理引擎集成到业务系统前可以逐项确认目标 CPU 是否支持 AVX2是否需要在运行时检测回退。张量缓冲区是否在 C 层分配并通过 CFFI 传递。矩阵乘核函数是否处理了 not-multiple-of-8 的边界。线程池初始化是否只启动一次而不是每请求创建。是否有统一的数值验证测试覆盖小矩阵、大矩阵、边界矩阵。是否能观察单算子耗时而不是只有总体耗时。FP16/BF16 是否在加载阶段完成转换而不是推理时反复转换。是否把 Lisp 对象和 C 指针的生命周期管理清楚避免悬空指针。8.3 项目可以继续扩展的方向llambda.lisp的价值不仅是跑通一个 Transformer block。它下一步可以做三件事。第一加入量化支持。INT8 量化可以显著降低内存占用和带宽压力AVX2 里可以用_mm256_maddubs_epi16等指令处理 INT8 矩阵乘。这是 CPU 推理引擎真正进入实用领域的必要条件。第二完善算子融合。把 LayerNorm 和激活函数融合到矩阵乘后的写回流程中减少内存往返。很多推理引擎的优化不是把矩阵乘本身改快而是减少读写内存的次数。第三支持非 Transformer 结构。Mamba、RWKV 这类线性注意力模型的推理流程和 Transformer 不同但张量、算子、后端分层设计仍然适用。扩展引擎时模型层和算子层的隔离边界会显得非常重要。8.4 对这个技术方向的总体判断从工程角度看用 Common Lisp 写 LLM 推理引擎不是最高效的选择也不是生态最成熟的选择。但如果把llambda.lisp当作一个学习平台它能让你真正理解推理引擎的每一层。你不再把torch.matmul当作黑盒而是会主动问矩阵乘在哪一层执行数据在内存里怎么排线程怎么协作指令集如何影响最终耗时。这些问题在用高层框架时很难被触发但在自己动手实现时每一步都必须给出明确答案。对新手来说最好的练习路径是从一个很小的矩阵乘开始先在 Lisp 里完成朴素实现再通过 CFFI 调用 C 版本最后加入 AVX2 和线程。每增加一层性能优化都保留一个可运行的 baseline用数据而不是感觉判断优化是否有效。这条路走通之后再看llambda.lisp这类项目源码就不会觉得无从下手了。