FPGA 加速器完全拆解（二）：LLM 推理的前沿技术——FlightLLM、CXL-SpecKV 与 LightMamba

总体架构：任务调度器 + 计算核#

FlightLLM 的硬件架构（论文图 4）很简洁：一个任务调度器、一个内存控制器、若干个计算核（core）。模型并行地把任务分给多个核，核之间做数据同步。

每个计算核由四个部件组成：

• MPE（统一矩阵处理引擎）：处理所有矩阵运算，包括稠密的 GEMM/GEMV 和稀疏的 SpMM/SpMV/SDDMM；
• MMU（内存管理单元）：负责片外内存访问，内置混合精度反量化单元；
• SFU（特殊功能单元）：处理 softmax、LayerNorm、SiLU 等非矩阵运算；
• 指令调度器：解码指令、调度各个硬件单元。

SFU 内部值得一提（论文图 7）：它把一条 MISC 指令拆成微操作，逐个交给 ALU 执行；softmax 和 LayerNorm 这类”两阶段”运算需要先读完整向量算出归约参数、再读一遍算最终输出，而 SiLU 和逐元素加/乘这类”逐元素”运算可以边读边算。多个核的 SFU 之间还有一条共享数据通路——一个核算出的向量结果可以直接广播给其他核的 SFU，不必写回 HBM 再读，这是为解码阶段”多头共享中间结果”定制的。

这个架构看起来平淡，真正的机关在 MPE 内部。

核心创新一：可配置稀疏 DSP 链（CSD-Chain）#

为什么稀疏在 FPGA 上也难算？因为 FPGA 的乘法器是固定级联的 DSP48。为了压榨 DSP 的累加器和进位链，经典做法是把 DSP 首尾相连成一条固定的链（每个 DSP 的输出直接进下一个 DSP 的累加输入），这样乘法累加零开销。但固定的链意味着数据流路径固定——遇到稀疏矩阵，某几个乘数明明是零，链却必须照常跑，算力就浪费了。

FlightLLM 的解法是把固定链改造成可配置的稀疏 DSP 链（CSD-Chain）：把一条长 DSP 链分成若干 DSP 组（DG），每组两个 DSP48（每个 DSP48 打包 2 个 INT8 MAC），组与组之间用可配置路径连接。在这条链上加了三个硬件单元：

1. 稀疏多路选择器（Sparse MUX）：每个 DSP48 同时接收两个激活（A 和 B，权重复用），送入之前先按稀疏索引从多个输入里只挑非零的激活送进去。零激活根本不会进入乘法器。
2. 归约节点（RN）：稠密 GEMM 里每条链只需要一个最终输出，但 SpMM 一个周期可能要产生多个输出。RN 放在 DSP 组末尾，需要时把组间级联路径打断，让当前组直接输出结果，后面的组重新开始一条新的乘法链（通过 Z-MUX 注入零）。
3. 溢出调整单元（OAU）：一个 DSP48 的乘法器是 25×18 bit，当它同时服务两个激活时每个激活只能用 18 bit 的端口，长级联累加容易溢出。OAU 把结果拆成高位部分（MSP）和低位部分（LSP），LSP 继续级联到下一个 DSP48 做累加，MSP 送到下一组的 RN 校准输出。当链上不超过 8 个 DSP48 时，16 bit 整数累加不会溢出，OAU 可以跳过。

这套设计的精妙之处在于：同一套硬件，稠密和稀疏都能全速跑。稠密时链不断开，整条链做一个大累加；稀疏时（以 2:4 为例，每 4 个权重只留 2 个）链被 RN 打断成两条独立链，每周期同时产出 2 个 MAC 结果。论文实测，配合 block 稀疏和 N 稀疏，FlightLLM 的计算效率相对固定 DSP 链提升 1.6×。

N 稀疏为什么好映射？因为 N 模式保证每个矩阵块内非零元的数量和位置规则（如 2:4），不规则的块间稀疏度差异可以靠调度消化。论文把 CSD-Chain 设计成”一个 VPU 支持 N：链分成 N 组，每组 DSP 从 M 个输入里选 1 个，每周期产出 N 个 MAC 输出”。

核心创新二：统一矩阵处理引擎（MPE）#

MPE 由若干 MPU（矩阵处理单元）组成，每个 MPU 又由若干 VPU（向量处理单元）组成。VPU 就是上面说的 CSD-Chain 点积单元。通过配置 MPU，MPE 可以切换两种工作模式（论文图 5）：

• MM 模式：矩阵乘矩阵，prefill 阶段用；
• MV 模式：矩阵乘向量，decode 阶段用——此时把并行度参数从 $[p_M, p_K, p_N]$ 调整为 $[1, p_K', p_N']$。

为什么要专门调 MV 模式的并行度？这背后是 FlightLLM 的访存-计算重叠模型。对一次形状为 $M \times K$ 与 $K \times N$ 的矩阵乘法，设 $p_M, p_K, p_N$ 是三个维度的计算并行度、$BW$ 是片外带宽，则访存时间和计算时间分别为：

要隐藏访存延迟（双缓冲），必须满足 $T_{mem} < T_{cmp}$。对 MV 运算，$M = 1$ 且 $p_M = 1$，直接代入会发现计算时间骤减、访存时间不变，条件被打破。论文的做法是在 $[p_K', p_N']$ 的参数空间里搜索一组配置，让 MV 模式下计算资源部分空闲、但带宽仍然打满——牺牲一点算力利用率，换来 decode 阶段不卡在内存上。

此外，MPE 还通过指令调度支持 SDDMM（采样稠密-稠密矩阵乘，稀疏注意力的关键算子）：把块稀疏注意力当作多个块级 GEMM 来处理，零掩码完全覆盖的块直接跳过，部分覆盖的块只算需要的那部分。

核心创新三：全片上解码（always-on-chip decode）#

decode 阶段的主要矛盾不是算力，而是频繁访问片外内存取细粒度数据。FlightLLM 的解法大胆而直接：把整个 decode 迭代的所有层计算全部融合在片上完成，只有最终结果写回片外。

为什么可行？因为 decode 阶段每个 token 的激活是向量（长度等于隐藏维度），不是矩阵，几个 MB 的片上 URAM 完全装得下。具体做法（论文图 8）：

• 激活向量从第一层开始就留在片上缓冲区，MPE 算完当前层的线性/注意力后，输出直接作为下一层输入，不写片外；
• SFU（处理 softmax、LayerNorm、SiLU、逐元素运算）与 MPE 没有硬件资源冲突，两类计算可以时间上重叠：softmax 和 LayerNorm 需要完整向量，必须等 MPE 算完才能开始；而 SiLU 和逐元素加/乘在 MPE 输出一部分时就能立刻算；
• 结果是在一次 decode 迭代内，片外内存访问只剩下”读权重/KV + 写最终结果”，中间结果全部在片上流转。

效果立竿见影：带宽利用率从 35.6% 提升到 65.9%。这种”全片上”策略只在 decode 阶段可行（激活是向量），prefill 阶段激活是矩阵、片上装不下，所以 prefill 的融合只做到”稀疏注意力掩码跳过”的程度（论文图 8c）。

混合精度：3.5-bit 权重的反量化单元#

量化策略上，FlightLLM 用梯度重要性分析给每个权重分配 3、4 或 5 bit，平均 3.5 bit，激活保持 INT8——这就是 GPU 无法高效执行的混合位宽。FPGA 侧怎么处理？论文设计了一个专用反量化单元：把紧凑存储的 2/3/4-bit 数据按控制信号、缩放因子和符号位自动展开成统一的 INT8 再送进 MPE，避免在 LUT 里铺大量乘法器做反量化。这样，混合精度数据的带宽节省是实打实的（数据在内存里就是 3.5 bit），计算侧只多了一点点展开逻辑。

内存延迟优化：HBM + DDR 分工#

Alveo U280 有 8 GB HBM（460 GB/s）和 32 GB DDR（38 GB/s）两类内存。一般直觉是”全放 HBM”，但 FlightLLM 反其道而行：MPE 的大块访问放 HBM（单次访问 ~MB 级），SFU 的小块访问放 DDR（单次访问 ~100 B 级）。原因是 HBM 的访问延迟比 DDR 更高，当数据量小到百字节级时，HBM 的延迟开销反而超过 DDR——小访问走低延迟的 DDR，大访问走高带宽的 HBM，各取所长。这是”异构内存层次”思想在 FPGA 上的典型应用。

编译：1.67 TB 的指令怎么缩到 3.25 GB#

FPGA 加速器一般用静态编译生成指令，但 LLM 解码是逐个 token 生成的，输入长度每增加 1，指令就不同。如果为所有可能长度（prefill 1-2048 + decode 1-2048）分别生成指令，LLaMA2-7B 部署在 U280 上需要约 1.67 TB 的指令存储——远超片外容量。论文提出长度自适应编译，两步压缩：

1. 阈值分组共享：把长度相近的输入用同一套指令。例如输入长度 1-16 的 decode 共用 16 token 的指令（利用 N 稀疏块 16×16 和稀疏注意力块 64×64 的粒度，性能损失可忽略）。decode 是访存瓶颈，指令执行频率高，所以 decode 用更细的阈值避免冗余计算。这一步把指令降到 4.77 GB。
2. HBM 通道指令合并：每个 PE 的缓冲区连了 8 个 HBM 通道，原本每个通道一条 LD/ST 指令，现在合并成一条，硬件解码器展开成 8 条同时发射。指令降到 3.25 GB，DDR 装得下，性能损失可忽略。

部署流程与实测成绩#

完整的映射流程（论文图 9）是：PyTorch 模型 → 稀疏化 + 量化 → 导出中间表示 IR → 优化（消除 view 等无效层、融合 attention+softmax、linear+SiLU）→ 数据分配 HBM/DDR 地址 → 按模板生成指令 → 按平台参数（DSP 数量、HBM/DDR 容量带宽、片上 RAM）自动生成 RTL。也就是说，换一块 FPGA 不需要重新设计硬件，改参数重新综合即可——这正是 FPGA”可重构”价值的工程化。

实测数据（U280，225 MHz）：

• 模型 LLaMA2-7B 和 OPT-6.7B，batch=1（延迟敏感场景）下，端到端延迟相对 V100S（vLLM+SmoothQuant 优化）提升 1.2-1.3×；
• 能效（token/J）相对 V100S 优化方案提升 6.0×、相对 A100 提升 4.2×；成本效率（token/s/$）提升 1.8×（U280 售价约 8000 美元 vs V100S 约 12000 美元）；
• 带宽利用率 65.9%，超过 A100 优化方案的 57.4%；
• 在最新 Versal VHK158（32 GB HBM、819 GB/s）上，吞吐超过 A100 的 1.2×；对比 gpt-fast（PyTorch 官方 INT4 优化方案，A100 上 196.8 token/s），VHK158 上 FlightLLM 达到 92.5 token/s，能效是其 2.9×；
• 对比专用加速器 DFX/CTA/FACT（同参数模拟），端到端延迟几何平均提升 2.7×（U280）/ 4.6×（VHK158）；
• 精度代价：全压缩（稀疏注意力 + N 剪枝 + 3.5-bit 量化）后 LLaMA2-7B 在 WikiText-103 上的困惑度从 8.7 升到 10.2，可接受。

FlightLLM 的意义在于证明了”压缩 + FPGA 完整映射流程”可以端到端打败 GPU：U280 这片 2021 年的 FPGA 卡，在能效上赢了 A100，在最新的 Versal 上吞吐也反超。它把上一篇文章的结论推到了新高度：FPGA 不是”边缘凑合”，而是”数据中心里值得认真对待的推理平台”。

问题：KV 缓存大到 GPU 装不下#

自回归解码时，模型要把每个历史 token 的 K、V 张量存下来供后续 token 查询。这个 KV 缓存的总大小是：

其中 $L$ 是层数、$B$ 是批大小、$S_{max}$ 是最大序列长度、$d_h$ 是隐藏维度、$P_{bits}$ 是精度。代入 LLaMA-2 70B（$L=80$，$d_h=8192$），批大小 32、序列 2048、FP16，得到 640 GB——而 A100 只有 80 GB。KV 缓存直接决定了能同时服务多少个请求：显存放不下，批大小就上不去，吞吐就上不去。

已有的解法各有各的痛：KV 量化（INT8/INT4）能压缩 2-4 倍但有精度损失；CPU/磁盘 offload（如 FlexGen）带宽太低（PCIe 8-12 GB/s vs HBM 2 TB/s 以上）；投机解码（speculative decoding）加速的是”算”，反而因为要维护多条候选序列的 KV 而增加内存压力。

CXL-SpecKV 的思路：把 KV 缓存整体搬到 FPGA 挂载的 CXL 内存池里，GPU 只留一小块热缓存，再用 FPGA 硬件把”远端的慢”藏起来。CXL（Compute Express Link）是 2022 年之后兴起的互连标准，基于 PCIe 物理层，提供缓存一致的共享内存访问，延迟亚微秒级（200-400 ns）、带宽 64 GB/s（x16 链路）。相比 PCIe offload 的 8-12 GB/s 和 3-5 μs 延迟，CXL 把”内存解聚”（memory disaggregation）从理论变成了工程现实。

前提：KV 缓存的六个可利用特征#

论文先对 KV 缓存的访问模式做了 profiling，发现六个可被利用的特征：

1. 顺序时间局部性：生成第 $t$ 个 token 时，要访问位置 $[0, t-1]$ 的全部 KV——访问序列是确定的、可预测的，这为”预取”提供了可能；
2. 层间独立：不同层的 KV 互不依赖，可以按层流水线化处理；
3. 读多写少：读写比约为 $S:1$（序列长度比 1），缓存友好；
4. 值聚集在零附近：KV 张量的值高度集中在零附近，INT8 量化精度损失小于 1%（>99% 精度保持），单这一项就有 2× 压缩；
5. 头间空间相关：相邻注意力头的值高度相关，差分编码 $\delta_i = x_i - x_{i-1}$ 能进一步压缩；
6. 层间可压缩性不同：前 1/3 层压缩比可达 3-4×，后 1/3 层只有 2.5-3×——需要按层选择算法。

系统架构：四组件 + 三层内存#

CXL-SpecKV 由四个组件构成：

• GPU 推理引擎：跑模型前向，维护最近 128-256 个 token 的本地 KV 小缓存；
• CXL 内存池：FPGA 挂载的大容量内存（每设备 64-256 GB），主 KV 存储；
• FPGA 缓存引擎：实现压缩/解压流水线、地址翻译、缓存管理，800 MHz、吞吐 1.6 TB/s；
• 投机预取器：预测未来 token 序列、提前把对应 KV 条目搬到 GPU 侧，128 KB 的 LSTM 模型，预测延迟 <10 μs。

内存组织成三层层次：L1 GPU 本地缓存（8-16 GB，LRU）；L2 预取缓冲（2-4 GB，双缓冲重叠数据传输与计算）；L3 CXL 内存池（64-256 GB，按 4 KB 页组织以匹配 CXL 事务粒度）。一致性靠 CXL 2.0 的 CXL.cache/CXL.mem 协议，而预取路径绕开一致性协议直接只读访问 CXL 内存，减少协议开销；预取错了直接丢弃，不产生一致性操作。

投机预取器：95% 准确率的 LSTM#

投机预取是整套系统最关键的创新——它猜测的不是下一个 token 是什么，而是下一个 token 需要哪些 KV 条目。预取器是一个极轻量的 LSTM：输入最近 16 个 token ID 的 64 维嵌入（共 1024 维），经过 2 层各 128 隐单元的 LSTM，输出 top-k 预测（beam search 宽度 4）。整个模型只有 128K 参数（FP16 下 512 KB），在 FPGA 上推理不到 10 μs。

预取流水线端到端延迟：

其中 LSTM 推理占 64 个周期，地址翻译 4 个周期，DMA 12 个周期。CXL 控制器支持最多 16 个并发未完成请求（$\Omega_{max}=16$），有效吞吐由内存带宽和并发度共同决定。系统稳定的条件是预取流量不超过 CXL 链路带宽：

其中 $\lambda_{req}$ 是请求到达率、$k$ 是预取深度、$S_{entry}$ 是条目大小（4 KB）、$H_{pred}$ 是预测命中率（0.95）。

预取错了怎么办？三个机制兜底：惰性失效（预取缓冲里的错数据不立即清，被新预取自然覆盖）；回退路径（真 token 不在预测里时，同步从 CXL 取，延迟惩罚但保证正确）；自适应深度（预测准确率高的请求加大 $k$，低的减小 $k$）。此外还有多层预取：处理第 $l$ 层时同时预取第 $l+1$、$l+2$ 层的 KV，有效延迟变为：

对多数模型，$T_{prefetch} < 2 \times T_{layer}$，有效延迟开销趋近于零。

FPGA 缓存引擎：压缩就是省带宽#

FPGA 缓存引擎（跑在 Intel Agilex-7 上）包含五个模块：ATU（地址翻译单元，TLB 命中率 >92%）、压缩引擎、解压引擎、内存控制器（16 个 HBM 通道，合计 1.6 TB/s）和 DMA 引擎。压缩流水线分三步（论文算法 2）：

1. 按页缩放量化：$s = \max(|\mathbf{X}|) / 127$，把 FP16 数据按页统一缩放成 INT8；
2. 差分编码：利用头内空间相关性，$\delta_{j,i} = x_{j,i}^{int8} - x_{j,i-1}^{int8}$；
3. 游程编码（RLE）：压缩差分后的长零串。

平均压缩比 3.2×（各层 2.5-4.0×），以 1.2% 困惑度损失为代价。每个压缩实例 20 级全流水、发射间隔为 1，吞吐 51.2 GB/s（512 bit × 800 MHz）；解压关键路径 25 个周期，另有”早退旁路”（约 30% 的流量是未压缩的直接通过，5 个周期），加权平均约 19 个周期。整引擎在 Agilex-7 上只占 30.5% ALM、25.9% DSP、15.8% M20K，频率 812 MHz——留了足够的余量在同一片 FPGA 上放最多 3 个额外引擎。

实测成绩#

系统在 8×A100 + 4×Agilex-7 + CXL 2.0 平台上评测（vLLM/TensorRT-LLM 通过自定义内存分配器插件接入），模型覆盖 LLaMA-2/3、Qwen、Mixtral、Gemma 等 22 种配置：

• 吞吐提升 2.1-3.2×（平均 2.4×）：LLaMA-2 70B 聊天负载从 GPU-only 的 487 token/s（批大小 16）升到 1549 token/s（批大小 64）——因为 CXL 内存池让批大小从 16 涨到 128（配合压缩可到 384）；
• 对比 CPU offload 提升 3.8-5.2×、对比仅压缩提升 1.8-2.3×；对比”无预取的 CXL 解聚”提升 1.6-2.1×——证明预取是整套系统的胜负手；
• 延迟代价可控：TTFT +4.2%、每 token 解码延迟 +8.2%、P99 +12.3%；
• 预取：top-4 准确率 94-97%，命中率 94.7%；有效平均访存延迟 383 ns vs 同步 CXL 的 1850 ns（4.8× 降低）；内存访问时间占总延迟比例从无预取时的 37% 降到 10.6%，隐藏了 76% 的解聚延迟；
• 成本：A100 80GB 记 1.0×、FPGA 记 0.18×，用 1.37× 的硬件成本换 2.4× 吞吐，性价比提升 1.75×；8 GPU 规模下性价比优势扩大到 2.2×；
• 能效：0.340 vs 0.647 J/token，1.90× 提升（FPGA 4 块共 184 W，吞吐翻三倍后单位 token 能耗反而减半）；
• 扩展性：4 GPU 时 95% 并行效率，8 GPU 时 87%。

CXL-SpecKV 的故事告诉我们：FPGA 在 LLM 时代的另一个高价值角色是”内存管理引擎”而非”算力引擎”。它不碰矩阵乘，靠的是把 KV 缓存的压缩、地址翻译、预取调度做成定制流水线——这类”有明确数据结构、需要确定性延迟、要绕过通用 CPU 栈”的工作，正是 GPU 和 CPU 都做不好、而 FPGA 最擅长的。与上一篇的 Blink（SmartNIC 直通）和 DualPath（KV-Cache 直读）放在一起看，一条清晰的趋势浮现：FPGA 正在成为 GPU 的”内存外设”和”数据通道”。

为什么 Mamba 难加速#

Mamba 类模型（如 Mamba2）相比 Transformer 的优势是线性复杂度：不需要随序列增长的 KV 缓存，只维护一个固定大小的隐藏状态 $h_t$，解码时每个 token 的增量计算是常数。这天然解决了上一个案例的内存墙问题。但 Mamba 在 FPGA 上也不好算，论文总结了三个挑战：

先看清 Mamba 块的组成（上图）：输入 token 先经过输入投影生成 $X, B, C, \Delta, Z$ 五个张量，$X$ 经过 conv1d 后进入 SSM 层，SSM 维护隐藏状态 $h_t$ 并输出 $Y$，最后与 $Z$ 逐元素相乘、经输出投影还原维度。其中 $B, C$ 是类似注意力里的选择向量，$\Delta$ 控制状态更新的步长——这些逐元素运算和隐藏状态递推正是 FPGA 加速的难点所在。

挑战一：散落的激活离群值。 量化 LLM 的关键障碍是激活里的离群值（绝对值远大于均值的元素）。Transformer 的离群值固定在少数几个通道上，所以 SmoothQuant 可以按通道缩放；但 Mamba 的离群值随 token 变化出现在不同通道（论文图 2 实测），SmoothQuant 和 OutlierSuppression+ 统统失效——后者 4-bit 量化误差高达 309.8，比不做任何处理的 RTN（19.5）还差一个数量级。

挑战二：SSM 层量化贵。 SSM 层全是逐元素乘（EM），没有矩阵乘那样的归约。量化后每算一步都要把中间结果”重量化”回低精度——矩阵乘有归约可以摊销，EM 没有，重量化开销巨大。论文实测（图 3），SSM 层的重量化硬件成本比非逐元素运算高一个数量级。

挑战三：计算依赖复杂。 SSM 的输入 $X, B, C, \Delta$ 全部由输入投影层生成，导致输入投影和 SSM 必须串行执行，硬件利用率不到 60%；而且 SSM 的中间激活（$\bar{B}X$、$\bar{A}h_{t-1}$、$h_t$ 等）占了片上 URAM 的 70% 以上。

旋转辅助量化：把离群值”摊平”#

量化算法层面，LightMamba 用旋转辅助量化解决挑战一。核心思想来自 QuaRot/SpinQuant：给激活和权重乘一个正交矩阵（这里用 Hadamard 矩阵 $H$，元素只有 ±1、无需乘法器），利用 $XW = XHH^T W$ 的恒等关系，在不改变结果的前提下把离群值”摊”到其他元素上——离群值被均摊后，4-bit 量化的误差大幅下降。

但关键问题是：SSM 层不满足旋转等价。看隐藏状态递推：

两边同乘 $H$ 得到 $(h_{t-1}H)$ 吗？验证一下：

由于逐元素乘不满足结合律（$\bar{A} \odot (h_{t-1}H) \neq (\bar{A} \odot h_{t-1}) H$），上式无法变成 $\bar{A} \odot (h_{t-1}H) + \bar{B} \odot (X_t H)$。也就是说，把旋转穿进 SSM 的递推会被逐元素乘挡住，SSM 不能像线性层那样直接旋转。

所以 LightMamba 的策略是：只旋转线性层，且把旋转尽量融合进相邻算子，让大部分旋转零成本（论文图 4）。全模型的旋转点有五个：① 嵌入表（融合进 embedding 权重）；② 第一个 RMSNorm 之后（先把 RMSNorm 的缩放因子 $D$ 拆出来融合进输入投影权重）；③ 第二个 RMSNorm 之后（这是唯一需要在线计算的旋转，论文验证了把缩放因子也融合会增大量化误差，所以不融合）；④ 输出投影两侧（一侧融合权重、另一侧与 ③ 合并）；⑤ LM head（融合进输出权重）。最终只有旋转 ③ 在运行时用硬件执行，代价很小。

SSM 层则改用 PoT（2 的幂次）量化：把量化步长限制为 2 的幂，于是”反量化 + 重量化”从乘法变成移位操作，硬件开销骤降（论文图 3 中 PoT 的重量化成本曲线远低于普通量化）。

硬件架构：部分展开的空间架构 + 三个专用单元#

硬件层面，LightMamba 采用部分展开的空间架构：把单个 Mamba 块在 FPGA 上展开成流水线，而不是像 FlightLLM 那样用指令驱动的时间复用架构。理由很实在：SSM 的逐元素运算种类多、依赖复杂，时间复用架构（一个 PE 串行做所有事）处理不了；而完全展开的空间架构（每个算子一个专用 PE）矩阵并行度又太低。部分展开是两者的折中：矩阵乘用 MMU 时间复用（一个块的所有线性层共用），SSM 内部全展开成流水（算子级并行）。

三个核心单元：

• MMU（矩阵乘法单元）：树形 MAC 阵列，一周期完成 $d_{in} \times d_{out}$ 次 MAC；利用 DSP 打包技术（一个 DSP48 做两个低比特 MAC）只需 $d_{in} \times d_{out} / 2$ 个 DSP。输入投影和输出投影按时间复用共享 MMU；
• SSMU（SSM 单元）：把 SSM 计算图全展开，每个算子一个专用 EMU（逐元素乘单元），算子之间用 FIFO 连接，各算子并行度单独调优以平衡流水；
• HTU（Hadamard 变换单元）：支持在线旋转 ③。128 点 Hadamard 变换用 FHT（快速 Hadamard 变换）蝶形算法实现：7 级蝶形，每级一个蝶形核 + 两个 FIFO，相比直接用 MMU 乘 Hadamard 矩阵延迟降低 72%；40 点的小变换直接复用 MMU（Hadamard 矩阵只有 ±1，不需要真乘法）。

计算重排序与细粒度分块融合#

SSM 与输入投影的强依赖导致利用率低（挑战三）。LightMamba 的计算重排序很聪明：输入投影原来按顺序生成 $X, B, C, \Delta, Z$；现在改为先生成 $\Delta, B, C$ 存进片上缓冲，再按头交替生成 $X$ 和 $Z$。这样 SSM 在 $\Delta, B, C$ 就绪后立即开始，与输入投影流水重叠：

效果：总计算时间减少 32%，硬件利用率从 58% 提升到 96%。

接着是细粒度分块与融合：SSMU 需要存大量中间激活（占 URAM 70% 以上），论文沿 head 和隐藏状态维度把 SSM 计算切成 $n_p \times p_p$ 的小块，逐块流水执行，同时把相邻算子融合（前一个算子的输出直接喂给下一个，不经过片上缓冲）。URAM 占用从 246 块降到 61 块（4× 减少），流水气泡也被消除。

实测成绩#

LightMamba 在 Xilinx Versal VCK190（400 MHz）上实际部署，Alveo U280 用经 HLS 仿真验证的周期级模拟器评估：

• 精度：W4A4（权重激活各 4 bit）下 LAMBADA 困惑度 6.35（全模型量化 LightMamba*），优于 SmoothQuant 的 8.26、RTN 的 17.46，而 OutlierSuppression+ 直接崩掉（>100）；相比 FP16 基线仅损失约 2 个点；
• 吞吐：VCK190 上 W4A4 达到 7.21 token/s（W8A8 为 3.61）；U280 模拟达到 93 token/s，是 RTX 2070 GPU 基线的 1.43×；
• 能效：VCK190 相对 RTX 2070 平均提升 6.06×、相对 RTX 4090 提升 4.65×（2.25 vs 0.371/0.484 token/J）；
• 资源：VCK190 W4A4 仅用 107K LUT、228 DSP、912 BRAM、61 URAM，频率 400 MHz；
• 消融：量化带来 2.23→5.32 token/s；旋转量化 + HTU 把精度提升 4.3% 且吞吐几乎不变；计算重排序把吞吐推到 7.21；分块融合把 URAM 从 246 降到 61。

LightMamba 的启示：算法和硬件必须一起设计。旋转量化不是白送的——它要求硬件里有 HTU，要求知道哪些旋转能融合、哪些必须在线算；计算重排序也不是调度优化——它要求输入投影的数据生成顺序可编程。这就是为什么论文题目叫”quantization and hardware co-design”。