FPGA实现微型LLM推理加速：低成本硬件上的高性能AI部署实践-开发者社区

这次我们来看一个在硬件加速领域很有意思的项目：一个能在价值约250美元的FPGA开发板上，实现每秒处理21,000个token的微型大语言模型（LLM）。这个项目将高性能、低功耗的FPGA硬件与前沿的AI推理结合，为边缘计算、嵌入式AI和低成本硬件加速提供了一个极具吸引力的技术验证。

对于关注AI模型部署、硬件加速、边缘计算以及FPGA开发的开发者来说，这个项目提供了一个从软件模型到硬件实现的完整视角。它最核心的看点在于，用相对廉价的硬件（如KV260这类开发板）跑出了惊人的推理速度，这挑战了传统上依赖高端GPU进行LLM推理的认知。本文将带你了解这个项目的核心能力、适用场景，并梳理出一套从环境准备到效果验证的通用流程，让你能评估它是否适合你的应用场景。

1. 核心能力速览

能力项	说明
项目类型	基于FPGA的微型LLM推理加速器
核心目标	在低成本FPGA上实现超高速的LLM token生成
宣称性能	约 21,000 tok/s (需注意模型大小、精度和具体硬件)
目标硬件	约250美元级别的FPGA开发板（如Xilinx Kria KV260）
技术栈	FPGA (Verilog/RTL)、LLM推理框架、可能的HLS（高层次综合）
模型特点	“微型”LLM，参数量可能显著小于主流大模型（如GPT-3/4）
启动/部署方式	需将设计比特流（bitstream）烧录至FPGA，并通过主机软件进行交互
接口能力	通常通过PCIe、以太网或UART等接口与主机通信，提供API
适合场景	边缘AI推理、低功耗实时应用、硬件加速研究、嵌入式LLM原型验证

关键解读：21,000 tok/s是一个需要重点审视的指标。这个速度与模型规模（参数量）、计算精度（INT8/INT4）、输入输出长度以及FPGA的时钟频率和资源利用率紧密相关。它很可能是一个高度优化、针对特定小模型的成果，展示了FPGA在定制化计算流水线上的潜力。

2. 适用场景与使用边界

这个项目并非为了替代在云端GPU集群上运行的千亿参数模型，而是开辟了另一条路径。理解其适用与不适用场景，是评估其价值的第一步。

适合谁用？

硬件加速研究者与工程师：希望探索LLM在FPGA/ASIC上部署的极限性能、能效比和实现方法。
边缘计算与嵌入式开发者：需要在资源受限、功耗敏感的设备（如机器人、智能摄像头、工业网关）上集成语言理解或生成能力。
FPGA学习与爱好者：想通过一个完整的、与AI结合的前沿项目，深入学习Verilog/RTL设计、硬件/软件协同设计以及高速接口。
对推理成本敏感的应用原型团队：在概念验证阶段，寻找比GPU云实例更经济、比纯CPU推理更高效的解决方案。

能解决什么问题？

高吞吐、低延迟推理：对于特定的小型化或量化后的LLM，FPGA的并行计算架构可以实现极高的吞吐量，满足实时性要求。
降低部署成本与功耗：一次性硬件成本（开发板）远低于持续租赁高端GPU，且FPGA在执行固定计算任务时能效比可能更高。
硬件定制化：可以根据模型的计算模式（如注意力机制、矩阵乘加）定制硬件电路，消除通用处理器中的冗余开销。

不适合什么场景？

运行超大参数模型：受限于FPGA的片上存储（BRAM）和外部内存带宽，很难直接部署未经裁剪的百亿、千亿参数模型。
频繁更换模型：FPGA的比特流是针对特定计算图编译的，更换模型通常需要重新综合、布局布线并生成新的比特流，周期较长。
需要复杂动态控制流的任务：FPGA擅长规则、并行的数据流处理，对于复杂的条件分支、递归等控制逻辑，实现效率可能不高。
缺乏硬件背景的纯软件开发者：入门门槛较高，涉及硬件描述语言、工具链和底层调试。

合规与安全边界：

模型版权：确保所使用的微型LLM拥有合规的许可协议，允许用于FPGA部署和推理。
数据隐私：在边缘设备上处理数据有助于隐私保护，但仍需确保整个数据处理流程符合相关法规。
技术出口管制：注意高性能计算和特定AI硬件的出口管制条例。

3. 环境准备与前置条件

要复现或基于此类项目进行开发，你需要一个软硬件协同的环境。以下是一个通用的准备清单，具体细节需根据项目开源代码调整。

硬件环境：

FPGA开发板：核心是类似Xilinx Kria KV260（基于Zynq UltraScale+ MPSoC）的板卡。确保板卡功能正常，具备调试接口（如JTAG、USB-UART）。
主机电脑：用于开发、编译和与FPGA通信。推荐使用Linux系统（如Ubuntu 20.04/22.04），对Vivado等FPGA工具链支持更好。
连接线与电源：FPGA开发板的配套电源、JTAG下载器（如Platform Cable USB II）、网线（如果使用以太网通信）、USB线（用于串口调试）。
外设：可能需要的DDR内存、Flash存储等，通常开发板已集成。

软件与工具链：

FPGA开发工具：以Xilinx为例，需要安装Vivado Design Suite或Vitis Unified Software Platform。这是一个庞大的软件，需要申请License（通常有免费WebPack版本用于特定器件）。安装过程耗时较长，需确保磁盘空间充足（>100GB）。
硬件描述语言环境：项目主要使用Verilog或VHDL（RTL级）。你需要熟悉相关语法和仿真工具（如Vivado自带的仿真器，或第三方ModelSim）。
主机端软件开发环境：
- Python 3.8+：用于编写控制脚本、API服务等。
- C/C++编译工具链：用于编译运行在FPGA的ARM处理器（PS端）或主机上的驱动程序。
- 必要的Python库：如numpy,pyserial,requests（用于API调用）等。
模型准备：你需要获取项目指定的“微型LLM”模型文件。这可能是经过特殊量化（如INT4/INT8）、剪枝或结构优化的模型，格式可能是ONNX、TensorFlow Lite或自定义二进制格式。

4. 安装部署与启动方式

这类项目的部署流程与传统软件项目差异很大，核心是将设计“烧录”到硬件中。以下是通用步骤框架。

步骤一：获取项目源码通常项目会托管在GitHub等平台。使用git克隆仓库。

git clone <项目仓库地址> cd <项目目录>

步骤二：检查硬件设计（RTL代码）进入rtl或hdl目录，查看主要的Verilog模块文件（如top.v,llm_engine.v,matrix_multiply.v等）。理解顶层接口定义，这决定了FPGA如何与外部（如DDR内存、主机接口）通信。

步骤三：配置FPGA工具链项目项目通常会提供Tcl脚本或Xilinx Vivado项目文件（.xpr）。

使用Tcl脚本：这是更可复现的方式。
```
# 在Vivado的Tcl控制台或命令行中执行 source ./scripts/build.tcl
```
该脚本会执行一系列操作：添加源文件、设置约束（引脚、时钟）、综合、实现（布局布线）、生成比特流（.bit文件）。
打开Vivado项目：直接双击.xpr文件在Vivado GUI中打开，进行可视化操作。

步骤四：生成比特流文件这是最耗时的步骤，可能需要数小时，取决于设计复杂度和电脑性能。

综合（Synthesis）：将RTL代码转换为门级网表。
实现（Implementation）：包括布局（Place）、布线（Route），将网表映射到FPGA的具体物理资源上。
生成比特流（Generate Bitstream）：生成可以配置FPGA的二进制文件（.bit）。在Vivado中点击“Generate Bitstream”按钮，或通过Tcl命令write_bitstream -force top.bit完成。

步骤五：配置FPGA将生成的.bit文件烧录到FPGA开发板上。

硬件连接：用JTAG电缆连接开发板和主机。
打开硬件管理器：在Vivado中打开Hardware Manager。
识别设备：点击“Open target”，选择“Auto Connect”。
编程器件：右键选中设备，选择“Program Device...”，在弹出的对话框中选择生成的.bit文件，点击“Program”。成功后会提示“Programmed successfully”。

步骤六：部署主机端软件与启动服务FPGA配置好后，它只是一个加速器，还需要运行在主机（或FPGA的ARM处理器）上的软件来驱动它，加载模型数据，并提供API。

编译主机驱动/运行时：进入项目的host或software目录，按照README编译。
```
cd host mkdir build && cd build cmake .. make -j$(nproc)
```
准备模型数据：将微型LLM模型文件（可能是权重和词汇表）转换成项目所需的二进制格式，并放置到指定目录。
启动服务：运行编译好的主机程序。这个程序可能会：
- 初始化FPGA的PCIe或AXI接口。
- 将模型权重加载到FPGA的DDR内存中。
- 启动一个本地的HTTP/GRPC API服务，监听特定端口（如7860,8000）。
```
# 示例启动命令 ./llm_fpga_server --model_path ./models/mini-llm.bin --port 8000
```
验证服务：服务启动后，你可以通过curl或编写简单的Python脚本测试接口是否就绪。
```
curl http://127.0.0.1:8000/health # 期望返回 {"status": "ok"}
```

5. 功能测试与效果验证

当FPGA加速器和主机服务都运行起来后，就可以进行功能与性能测试了。

5.1 基础文本生成测试

这是最核心的功能验证。目标是确认FPGA加速的LLM能够正确理解输入并生成连贯的文本。

测试目的：验证端到端的文本生成流程是否正常工作。操作步骤：

使用curl或Python脚本向API发送一个文本生成请求。

import requests import json url = "http://127.0.0.1:8000/generate" headers = {"Content-Type": "application/json"} payload = { "prompt": "请用一句话解释什么是FPGA。", "max_new_tokens": 50, "temperature": 0.7, } response = requests.post(url, json=payload, headers=headers, timeout=30) if response.status_code == 200: result = response.json() print("生成的文本：", result.get("text")) print("消耗的token数：", result.get("usage")) print("推理耗时：", result.get("inference_time_ms"), "ms") else: print("请求失败：", response.status_code, response.text)

观察返回结果。检查生成文本是否相关、语法是否基本正确。预期结果：API返回JSON格式的响应，包含生成的文本、使用的token数量以及推理时间。判断成功：能返回非乱码的文本，且内容与提示词有一定相关性。常见失败原因：
- API服务未启动或端口错误。
- 模型权重未正确加载。
- FPGA硬件初始化失败（检查服务日志）。
- 输入格式不符合API要求。

5.2 性能基准测试

这是项目的亮点，需要验证其宣称的高吞吐量。

测试目的：测量实际的token生成速度（tok/s）。操作步骤：

准备一个包含多个不同长度提示词的测试集（benchmark）。

编写脚本，连续或并发地向API发送大量生成请求。确保请求是串行的，以测量FPGA引擎的持续吞吐量，而不是客户端的并发能力。

import time # ... (省略requests导入和URL定义) prompts = ["写一首关于春天的诗。", "解释牛顿第一定律。", "将'Hello, world!'翻译成中文。"] * 10 # 重复多次 total_tokens_generated = 0 total_time = 0 for prompt in prompts: payload = {"prompt": prompt, "max_new_tokens": 30} start = time.time() response = requests.post(url, json=payload, timeout=10) end = time.time() if response.status_code == 200: result = response.json() total_tokens_generated += result.get("usage", {}).get("completion_tokens", 0) total_time += (end - start) else: print(f"请求失败: {prompt}") if total_time > 0: throughput = total_tokens_generated / total_time print(f"总生成token数: {total_tokens_generated}") print(f"总耗时: {total_time:.2f} 秒") print(f"平均吞吐量: {throughput:.2f} tok/s")

同时，可以通过主机命令（如htop,nvidia-smi的FPGA对应工具）或服务日志，观察FPGA的利用率、功耗和温度。预期结果：测得的吞吐量应在一个合理的量级。21,000 tok/s是在特定最优条件下的峰值，实际测试可能因提示词长度、生成长度、系统开销而略低。判断成功：吞吐量显著高于同级别CPU推理速度，并且系统运行稳定。常见失败原因：
- 测试请求间隔太短，未考虑FPGA流水线填满时间。
- 主机-FPGA通信接口（如PCIe）成为瓶颈。
- 模型权重从DDR读取速度受限。

5.3 多轮对话与上下文测试

测试模型是否能维护对话历史（上下文窗口）。

测试目的：验证FPGA上的推理引擎是否支持KV Cache等优化，以及上下文长度。操作步骤：

模拟一个多轮对话，将历史对话作为上下文传入。

conversation = [ {"role": "user", "content": "你好，你是谁？"}, {"role": "assistant", "content": "我是一个运行在FPGA上的微型AI助手。"}, {"role": "user", "content": "你的速度有多快？"} ] # 需要根据API格式构造包含历史的prompt formatted_prompt = "\n".join([f"{msg['role']}: {msg['content']}" for msg in conversation]) + "\nassistant:" payload = {"prompt": formatted_prompt, "max_new_tokens": 50} # ... 发送请求

观察模型在后续回答中是否引用了之前的对话内容。预期结果：模型能基于上下文给出连贯的回答。判断成功：回答与对话历史相关。常见失败原因：项目实现的引擎可能不支持长上下文，或者上下文管理逻辑在主机端而非FPGA上。

6. 接口API与批量任务

一个实用的FPGA LLM加速系统需要提供稳定的软件接口。

API服务设计（典型示例）：主机端服务通常会提供一个RESTful API或gRPC接口。

健康检查：GET /health
文本生成：POST /generate
批量生成：POST /batch_generate（可能通过队列实现）
模型信息：GET /model_info

批量任务处理：由于FPGA是固定流水线，处理单个请求和批量请求在效率上可能不同。批量处理能更好地隐藏数据加载延迟，提升整体吞吐。

客户端批量：客户端收集多个请求，一次性发送到/batch_generate端点。
服务端队列：服务端维护一个请求队列，FPGA引擎从队列中按顺序或某种调度策略取出请求处理。这需要更复杂的宿主软件设计。
实现建议：对于初期测试，可以先实现简单的串行处理。在验证功能稳定后，再考虑实现一个生产者-消费者队列，由主机软件管理请求，并一批一批地提交给FPGA处理。

Python调用示例（高级）：

import requests import threading import queue class FPGA_LLM_Client: def __init__(self, base_url="http://127.0.0.1:8000"): self.base_url = base_url self.session = requests.Session() def generate(self, prompt, **kwargs): """单次生成""" url = f"{self.base_url}/generate" payload = {"prompt": prompt, **kwargs} resp = self.session.post(url, json=payload) resp.raise_for_status() return resp.json() def batch_generate(self, prompts, max_workers=2): """简单的多线程批量生成（注意：可能给服务端造成压力）""" results = [] def worker(prompt_q, result_list): while not prompt_q.empty(): try: idx, prompt = prompt_q.get_nowait() result = self.generate(prompt) result_list.append((idx, result)) except queue.Empty: break except Exception as e: result_list.append((idx, {"error": str(e)})) q = queue.Queue() for i, p in enumerate(prompts): q.put((i, p)) threads = [] for _ in range(min(max_workers, len(prompts))): t = threading.Thread(target=worker, args=(q, results)) t.start() threads.append(t) for t in threads: t.join() # 按原始顺序返回结果 results.sort(key=lambda x: x[0]) return [r for _, r in results] # 使用示例 client = FPGA_LLM_Client() # 单次调用 print(client.generate("FPGA的优势是什么？")) # 批量调用 batch_results = client.batch_generate(["问题1", "问题2", "问题3"]) for res in batch_results: print(res)

7. 资源占用与性能观察

在FPGA上观察资源占用与在GPU上使用nvidia-smi不同，需要使用FPGA厂商提供的工具和方法。

1. 资源利用率报告（静态）在Vivado实现（Implementation）完成后，工具会生成详细的资源利用率报告。

查看方式：在Vivado中，打开实现后的设计，点击“Report Utilization”。
关键指标：
- LUT（查找表）：用于实现组合逻辑和部分存储。利用率超过80%可能影响时序收敛。
- FF（触发器）：用于存储状态。高利用率通常与流水线深度相关。
- BRAM（块RAM）：片上存储，用于缓存权重、中间结果。这是LLM加速的关键资源，很容易成为瓶颈。
- DSP（数字信号处理器）：用于实现乘法、乘加运算。矩阵计算的核心。
- 时序（Timing）：检查WNS (Worst Negative Slack)。必须为正，否则设计无法在目标时钟频率下稳定运行。

2. 动态功耗与温度监测

Xilinx工具：可以使用xbutil（Xilinx Board Utility）命令来查询板卡状态。

# 查询板卡信息 xbutil examine # 查询功耗（部分板卡支持） xbutil query -d <device_id> -r power # 查询温度 xbutil query -d <device_id> -r thermal

板载传感器：一些开发板通过I2C接口提供了传感器，可以通过读取特定寄存器获取电压、电流、温度信息。这通常需要自己编写或使用厂商提供的PS端（ARM处理器）软件来读取。

3. 性能剖析（Profiling）为了理解瓶颈，需要在硬件设计中插入性能计数器（Performance Counters）。

常见计数点：
- 从DDR读取权重的次数和带宽。
- 计算单元（如矩阵乘加模块）的激活周期。
- 输入/输出FIFO的空/满状态时间。
实现方法：在Verilog代码中添加计数器，通过AXI-Lite或UART等接口将计数器的值读出到主机。这属于高级调试技巧。

性能影响因素分析：

模型大小与精度：INT4模型比INT8模型速度快、占用资源少，但可能损失精度。
批处理大小（Batch Size）：增大批处理能提升计算单元利用率，但会增加延迟和片上存储压力。
输入/输出序列长度：长序列需要更多的KV Cache存储，可能受限于BRAM。
时钟频率：更高的时钟频率能直接提升性能，但受限于时序收敛和功耗。
主机-FPGA数据传输：如果采用PCIe，其带宽和延迟会影响端到端性能。

8. 常见问题与排查方法

在FPGA LLM项目开发与部署中，你会遇到从工具链到硬件的一系列问题。

问题现象	可能原因	排查方式	解决方案
Vivado综合/实现失败	RTL代码语法错误、逻辑错误、约束文件（XDC）错误、资源不足。	1. 查看Vivado Console和Log中的ERROR和CRITICAL WARNING信息。 2. 检查时序报告，看是否有违例。	1. 根据错误信息修改RTL代码。 2. 优化设计，减少资源消耗（如复用逻辑）。 3. 放松时序约束或优化关键路径。
比特流编程失败	JTAG连接不稳定、板卡未上电、FPGA型号不匹配、比特流文件损坏。	1. 检查JTAG电缆连接和板卡电源指示灯。 2. 在Vivado Hardware Manager中尝试“Refresh Device”。 3. 确认生成的比特流目标器件与板卡一致。	1. 重新插拔JTAG和电源。 2. 重启Vivado和电脑。 3. 重新生成比特流。
主机服务启动失败，报错“FPGA初始化失败”	FPGA比特流未加载、PCIe驱动未安装、DDR内存初始化失败、硬件设计有缺陷。	1. 确认比特流已成功编程。 2. 检查`dmesg`或系统日志，查看PCIe设备是否被识别。 3. 查看主机服务程序的详细日志。	1. 重新编程FPGA。 2. 安装正确的板卡驱动（如Xilinx Runtime, XRT）。 3. 检查硬件设计中DDR控制器的配置。
API请求返回错误或超时	服务未监听对应端口、模型文件路径错误、FPGA计算引擎挂起、输入数据格式错误。	1. 用`netstat -tlnp`检查服务端口是否在监听。 2. 查看服务进程的stdout/stderr输出日志。 3. 使用简单的测试请求（如`/health`）验证服务基础功能。	1. 检查启动命令中的端口号。 2. 确认模型文件存在且可读。 3. 重启主机服务，查看是否有更详细的错误。
推理结果完全错误或乱码	模型权重加载地址错误、数据位宽不匹配、预处理/后处理逻辑错误、FPGA计算核心有设计缺陷。	1. 对比FPGA输出和CPU软件模拟的输出（使用相同的权重和输入）。 2. 在RTL仿真中，对小型测试向量进行逐层对比验证。 3. 检查主机端将浮点权重转换为定点数（量化）的代码。	1. 这是最复杂的调试阶段，需要硬件/软件协同调试。从最小测试案例开始，逐步扩大。 2. 使用Vivado的ILA（集成逻辑分析仪）抓取FPGA内部信号波形。
吞吐量远低于预期	主机-FPGA通信带宽瓶颈（如PCIe）、DDR访问效率低、FPGA计算单元利用率不足、批处理大小太小。	1. 使用性能计数器或软件时间戳，测量数据传输和计算各自的时间。 2. 使用`xbutil`或类似工具监测PCIe带宽。 3. 分析设计报告，看计算单元是否大部分时间处于空闲。	1. 优化主机端数据搬运，使用DMA或零拷贝技术。 2. 调整FPGA设计的内存访问模式（如突发传输、缓存）。 3. 增加批处理大小以提高计算单元利用率。
FPGA板卡运行一段时间后异常或宕机	散热不良导致温度过高、电源不稳定、设计存在时序违例（亚稳态）。	1. 监测FPGA核心温度。 2. 检查电源电压是否在正常范围内。 3. 回顾时序报告，确保在高温低压（最差情况）下时序仍收敛。	1. 改善散热（加装散热片、风扇）。 2. 使用更稳定的电源。 3. 重新进行时序约束与优化，增加时序余量。

9. 最佳实践与使用建议

基于此类项目的探索性质，遵循一些最佳实践可以大幅提升成功率和开发效率。

从仿真开始，切勿直接上板：在Vivado中编写完善的测试平台（Testbench），对每个RTL模块进行充分的仿真验证。使用脚本自动化仿真，确保功能正确后再进行耗时的综合实现。
建立黄金参考模型：在Python（使用PyTorch/TensorFlow）或C++中实现一个功能完全相同的、浮点精度的软件模型。这个“黄金模型”用于验证FPGA输出的正确性，是调试的基石。
采用增量式开发流程：
- 阶段一：在FPGA上实现一个最简单的操作，如矩阵向量乘，并验证正确性。
- 阶段二：实现单个Transformer层的计算。
- 阶段三：将多层串联，并加入KV Cache管理等控制逻辑。
- 每个阶段都确保功能正确和性能达标后再进入下一阶段。
重视约束文件（XDC）：正确的时钟、引脚和时序约束是设计稳定工作的前提。仔细阅读开发板手册，确保约束与实际硬件匹配。
资源与性能的权衡：FPGA资源有限。明确你的优先级是速度、精度还是能效。使用量化（INT8/INT4）、权重共享、低秩分解等技术来压缩模型，以适应有限的BRAM和DSP资源。
完善的日志系统：在主机端软件和FPGA设计（通过UART打印或内存映射寄存器）中加入多级日志（DEBUG, INFO, ERROR）。这对定位跨硬件/软件的问题至关重要。
版本控制一切：不仅对RTL代码，对Tcl构建脚本、约束文件、软件驱动、测试用例、甚至Vivado工程设置（如果可以）都进行版本控制。
性能分析驱动优化：不要盲目优化。先用性能计数器或软件剖析工具找到热点（是计算慢还是数据搬运慢），再针对性地优化。
合规与伦理考量：明确你的微型LLM的用途。如果涉及用户数据，确保在设备端处理。了解模型训练数据的版权和许可，避免侵权风险。

10. 总结与下一步

这个在250美元FPGA上实现21,000 tok/s的项目，更像一个技术宣言和探索的起点。它有力地证明了，通过定制化硬件，我们可以在极低成本下为特定的小型LLM提供惊人的推理速度。这对于边缘AI、实时交互和成本敏感的应用具有启发性。

对于想要动手的开发者，最先应该验证的是工具链的完整性：从克隆代码、安装Vivado、成功编译一个示例设计并烧录到板卡，这第一步往往就能筛掉大部分环境问题。接着，重点测试基础的数据通路：确保主机能正确读写FPGA上的寄存器或内存，这是所有高级功能的基础。

最容易踩的坑集中在硬件/软件协同调试和时序收敛上。一个在仿真中完美的设计，上板后可能因为时钟偏移、信号完整性或电源噪声而行为异常。学会使用ILA进行在线调试是必备技能。

下一步，你可以沿着多个方向深入：

模型探索：尝试将不同的开源微型LLM（如TinyLlama, Phi-2, Qwen1.5-0.5B）适配到此硬件架构上，比较它们的性能/精度/资源消耗。
架构优化：研究更高效的计算单元设计、内存层次结构（利用HBM如果板卡支持）以及稀疏计算。
软件栈完善：构建一个更友好的运行时和API层，甚至尝试兼容类似OpenAI API的接口，降低应用开发门槛。
系统集成：将整个FPGA加速卡作为一个模块，集成到更大的边缘计算系统中去。

这个项目打开了软硬件协同设计优化LLM推理的一扇窗。虽然前路充满挑战，但对于有志于深耕AI基础设施和硬件加速的开发者而言，其中的每一处细节都值得深入研究。建议收藏本文，作为你开启FPGA LLM之旅的实践备忘录。