我在之前详细讲过FPGA在AI中的优势，倘若大家要利用它的优势，去优化大模型推理过程，应该有哪些方案（只是理论推导）。下面简单罗列一下：
方案一：OffLoad MoE Expert MLP
MoE的MLP阶段，有一个重要的运算特点。
源于专家多（DeepSeek V3.1 的MoE有 256个专家，每个专家需要运算的batch就相对较小，因为路由后分散了，运算就变成一个细太碎的运算。此时，运算的瓶颈不在计算而在调度，权重读取上。
在这种情况下，如果运用GPU来完成，按GPU运算的特点，它强在并行大资料，多批次的运算。此时，每个运算依赖于SM，而SM可以需要有Kernel的准备，大量的时间会花在kernel的准备上，而好不容易准备好，但要处理的数据量极少，读取权重数据的时间反而显得更长，真正的运算并行很少（可能一个专家就算一个token)，因为数据量小(注意：不同网络层的运算是不能并行的。唯一可以并行的是路由计算得到的N个专家)。 这时，有点象大饭店的大锅炒菜，最合理的方式是，一锅同时炒多份，但现在来的人少，一个大锅每次只能炒一份菜，相比洗锅和一些准备时间，就显得很浪费了。
如果交给FPGA来运算，因为FPGA的运算是定制的硬件电路，所以，不存在Kernel准备的事情，完全是一个固定的数据流处理，需要处理的数据多少，完全不影响运算效率（因为它的并行是靠硬件电路的复制来达成，而GPU并不是，GPU还是靠并行调度来达成高效，如果没有足够多的数据，就只能是高射炮打蚊子，好不容易花代价准备了一个Kernel，一个SM，但只计算很简单的一个权重数据）。当然，权重的读取，仍然需要有足够的空间和带宽。这个对于FPGA，标准做法是需HBM，当然 HBM的存量有限，我们后面也会给出另外的方案（见方案二）。
好了，我们再来强调和总结一下：
激活专家的kernel和读取权重信息上。就是MLP时，是按每个token进行路由，也就是说每个token会落在不同的专家，反过来说，每个专家最终需要处于的token并不会太多。token在做MLP时，任务会分开落在不同专家。也就是说拆出的任务非常的碎（稀疏），大量的处理时间会花在调用不同专家的不同权重上，也就
这里要澄清一个概念，MoE在计算路由专家时，是按单个token来计算的，并不是传统理解的那种行业专家，按一整上下文来计算路由专家。你在读一段话时，遇到数字时调用“算术能力”，遇到代码时调用“语法能力”，遇到人名时调用“实体记忆”。这些能力在 MoE 里就是不同 expert。它们是“技能模块”，不是“行业部门”。专家的能力是一种隐特征，并不是大家常规理解的行业特征。
核心思想：
“调度 + 权重访问 + 任务粒度”就是MoE 的瓶颈不是 FLOPs，而
GPU 为大而生，FPGA 为碎而生。
方案二：访存扩展——数据切片
上面说到，不管你运算有多高效，但权重和中间过程内容是需要内存的，并且应该很高的访问速度。假设我没有很高的HBx，单个芯片的访问DDR的带宽也有限，那怎么办？
缘于我们在使用 FPGA来完成MoE时，为了保证单层网络在进行路由运算时，有足够的并行度。最好是将 所有路由专家的处理都 一次完成，但那样的话，对于FPGA的访存要求会很高，在Prefill阶段，甚至是不可能达成的。比如：有256个专家必须运算，如果一个专家的权重很大（比如：满血DeepSeek 671 / 256 大约会有 2G内存），也就是一个专家的处理得有内容有2G，考虑内存访问的速度是有限的（比如：DDR访问速度是 2400M），如果光是读数据就要1S，那这件事情就没法做了。所以，这块是一定要优化的。
优化的方案很简单，考虑到MLP的运算，素材是可以拆分的（有点象大信息运算的Map Reduce的原理和前提条件），所以，可以将权重内容拆分到多个FPGA芯片负责的内存上（比如：使用DDR），这样，可以将数据分散到多个芯片，分头运算，接着汇总。这完全类似 Map Reduce的原理。这就大大提升了访存的带宽。
具体需要拆分成多少个FPGA芯片，这个障碍较复杂，要考虑你采用的FPGA芯片的DSP能力，配置的是HBM还是普通DDR，以及相应的访存带宽。还有你需要做完的模型的大小，对应单 一专家的模型大小。这些条件综合进考虑，选择合适的芯片和数量，进一步确认，在存储中如何拆分。
核心思想：
权重拆分，将运算分布到多颗FPGA，提升访存吞吐量。
方案三：KV Cache / Memory Offload
FPGA 还许可做 KV Cache 的管理 ，压缩，分层存储。
3.1：KV Cache 优化
：就是从系统视角，KVCache并不是简单的 KV存储和复用，它的实际作用
1：种类繁多，包括不同会话，不同数据批，不同sequence length，动态增长（decode），这是一些碎片。
2：索引复杂，token->layer->head->K/V
3：读写带宽非常紧。Attention每一层都要读，Decode每个token都需要读，Prefill 要写，decode要大量的读。
4：生命周期必须管理 ：及时释放，回收，长对话处理。
5：数据格式需要转换 FP16 -> FP8 -> INT8
6：多层存储之间必须不断迁移处理。HBM-->DDR-->NVMe，热/冷 token 区分切换。
上面的任务都 是控制型的，GPU做不好，FPGA如何做呢?
1: 提供硬件级的控制器，建立分配表，索引，实现sliding window逻辑，提供会话上下文的状态机。
2：提供数据转移支持。
3：给出 KV cache Layout 重排。
3.2：KV Cache压缩
用GPU肯定不行，但采用FPGA，允许做到边读取边解压。因为写的时候很多，主要是读，所以收益是不错的。另外，因为精度有一种容忍度，所以，如果采用有损压缩，压缩比例允许很大。
这里的压缩并不是简单的ZIP压缩，而是结构感知压缩，就是我们讲的量化方案。允许大大降低对内存的需求。
3.3：分层存储
如何分层？
GPU HBM ← 最热 token
FPGA HBM / DDR
Host DDR
NVMe SSD ← 冷 token
通过FPGA能够做啥呢？
1：热度统计。
2：数据自动迁移
3：数据格式统一。
固定延迟的。就是它不但强于GPU，也比cpu能力更强。因为它
核心思想：
算力就是大模型推理真正的瓶颈 是“内存系统”，不
方案四：纯FPA方案用于科研创新
如果一定要用FPGA来独立实现大模型推理，有没有价值呢？
其实有不少大学实验室 都 在采用纯FPGA的方案，目的很明确，关键是做算法研安，前沿框架架构的验证，这样，可以形成专利/论文，为形成专用的AI芯片做实验 。这肯定是可以的。
首先，对于纯的单颗FPGA，倘若不用HBM，基本不可行。因为内存访问带宽严重不足。使用HBM，可以将模型权重，关键内容常驻HBM.
基于上面的前提，FlighLLM论文https://arxiv.org/abs/2401.03868?utm_source=chatgpt.com，提出了几个关键的技术点：
1：模型量化后，会产生大量的稀疏矩阵，如果直接用GPU，种用率比较低。使用FPGA，可以定制DSP链：
定制方式：
* 跳过0
* 重排 乘加
* 保持流水不断
把这种不规则的稀疏变成规则的硬件的路径。
费劲，但确实会有效。最好能够加配置，方便少量的变更。就是感觉这很
2：HBM 是很有限的，为了降低对HBM访问压力，
* 不同场景，使用不同数据精度。提升效率。
* 降低带宽，提升cache命中率，保持数值尽量不变。
3：FPGA的工程化痛点，利用参数调整，在不影响 性能的情况下，减少编译 的次数，提升编写效率。
FlightLLM中并没有实际写出运行 Llama 7B 模型的性能，但肯定是不拥护多并发的，而且，性能应该也不会很好（不然不会不提），只是侧面比较了一下decode阶段的性能与GPU卡的对比，作为研究型论文，也就这样了。
核心思想：
FPGA不能取代GPU来独立完成大模型推理。但可以做一些局部优化，完成一些异构计算上的创新。
优劣分析
，如要推理使用场景，用户的请求量大，并发多，就是就上面的一些分析，行看出。如果要对大的MoE的模型进行推理，FPGA的加入，能够降低推理的门槛，但要特别注意：它只是降低了利用的最低配置的门槛（主导是针对整体调整的成本而言）。但依据工程上的优化（我理解vLLM引擎是可以做到这个的，只要命中的是同一层，同一个expert，就是合并到一起，当然合并也有代价，需要协同处理），全GPU方案是能够将MLP中专家的batch量提升的（进行合批处理），这样，可以充分利用GPU的算力，于是，它的劣势就不存在了。所以，现象就是，当并发提升后，全GPU方案的token产生成本会远远低于 GPU + FPGA的方案。所以，FPGA方案只适用于某一个并发范围，这要特别注意。至少目前是这样的。
FPGA异构优势：
适用于 MoE多专家大模型（越大越好），低并发， 要求稳定输出，需要更低能耗，