2026年FPGA大赛企业命题要求做「端侧大模型推理」，队伍里没人懂Transformer结构，论文和代码该从哪篇开始啃？

先说结论：三个月的时间，别去啃原始论文，直接找现成工程改，但理论不能一点不补，只是补法要换。

你们三个都做过CNN，其实起点不算差。注意力机制你完全可以先理解成一个「加权平均」——Query去和所有Key算相似度，softmax之后拿去加权Value。这个直觉建立起来只要半天，不要一上来就死磕《Attention is All You Need》那种满篇矩阵符号的原文，那篇是给已经懂的人做索引用的，不是入门教材。想快速建立结构感，先看带图解的中文博客或李沐那套讲解，把Encoder/Decoder、多头、位置编码这几块在脑子里画出数据流，就够了。KV Cache更简单：自回归生成时每步只需要算一个新token的K和V，前面算过的缓存起来别重算，本质是拿显存换计算。

真正决定你们能不能交卷的，是工程路径。端侧推理加速这个题目，核心工作量不在「懂Transformer」，而在「把某个已经能跑的模型，在高云GW5A上跑得比CPU或某个baseline快」。所以第一步是先找到一个能在板子上跑通的最小闭环：模型选小一点，比如几千万参数级别的开源小模型，用现成的推理框架或量化工具链先跑起来，哪怕慢得离谱都行。跑通之后再谈加速。

分工上建议别按「理论组/工程组」分，那样容易脱节。更实际的是：一个人专门负责跑通和调工具链（编译、量化、部署），一个人负责性能分析和优化点定位（哪里是瓶颈，是访存还是算力），第三个人负责写文档、做baseline对比和答辩材料。理论补课三个人一起，每天固定半小时看同一份材料再互相讲一遍，比各自啃效率高得多。

至于评委问「加速比怎么算」，这个其实好回答：你必须有明确的baseline，比如同一模型在板子CPU上、或在PC上、或未量化版本上的延迟，然后加速比就是两者延迟之比。关键是baseline要公平、要写清楚测的是什么（首token延迟还是每token延迟、batch是多少、精度有没有掉）。这些从第一天就要开始记录，别等答辩前补。

最后提醒一句：企业命题往往更看重「你真的把东西跑在指定板子上」而不是理论多深。你们现在的短板不是不懂Transformer，而是没跑通链路。先让灯亮起来，再谈优化。你们板子的工具链版本定了吗？高云那套环境版本差异挺影响部署路线的。

直接改开源工程，理论边做边补。你们缺的不是Transformer知识，是时间。找个能在边缘设备跑的小模型推理demo，先把链路跑通，再回头补attention和KV Cache，那时候看论文会有感觉。分工就一人环境部署、一人性能分析、一人文档答辩。加速比必须有baseline，从第一天记录。

先说个反常识的：你们最该补的不是Transformer，是「怎么把一个计算图拆成能塞进GW5A的算子」。CNN背景其实不算白纸，卷积那套数据复用、流水线、乒乓缓冲的思路，换成注意力一样用，只是复用的对象从滑窗变成了K和V。

理论要从哪篇开始？我的建议是别从《Attention is All You Need》起，那篇是给已经懂的人做索引的。先花半天把「Q乘K转置、softmax、再乘V」这条数据流在纸上画一遍，用一个4×4的小矩阵手算一遍，比看十篇博客都管用。位置编码和LayerNorm先当黑盒，知道它们是逐元素操作、不构成加速瓶颈就行。KV Cache的本质是自回归解码时前面token的K、V不会变，算过一次就存下来，拿显存换计算——这个概念你理解了，后面做cache量化、分页管理才有根。

但真正决定你们三个月能不能交卷的，是选题边界。端侧大模型推理这个题目太大，你们必须自己砍一刀：是只做prefill阶段，还是只做decode阶段的单token延迟？是跑一个几亿参数的小模型，还是拿一个1B级模型做量化后跑？这两个选择直接决定工作量差三倍。常见做法是选一个小参数量的开源模型，先把它量化到int8或int4，再针对decode阶段做加速，因为decode是访存瓶颈，正好能塞进FPGA的片上带宽优势里讲故事。

至于「加速比怎么算」，评委真正想听的是你有没有一个干净的baseline。第一天就要定死：同一个模型、同一组输入、同一个精度标准，对比对象可以是纯CPU、也可以是同一块板子上的ARM核，但必须写清楚测量的是端到端延迟还是单层延迟、有没有算预处理和后处理。把测量脚本和原始数据留着，答辩时能翻出来，比嘴上说快多少倍可信得多。

分工上，三个人别都去啃论文。一个负责工程链路（模型导出、量化、板上部署），一个负责性能剖析（哪一层是瓶颈、带宽利用率多少），第三个专门写文档和准备答辩材料，顺带补理论。理论是答辩时用的，工程是交卷时用的，两条线并行才不崩。你们板子的DDR带宽和片上BRAM容量摸清了吗？这个数会直接决定你们能跑多大的模型。

别一上来就啃论文，找个小模型推理demo先跑通。选一个带KV Cache实现的端侧推理工程，把模型换成你们能量化到板子上的小模型，先让链路出结果。理论补在跑通之后，重点只看三块：QKV是怎么算的、softmax为什么是瓶颈、KV Cache省了什么。加速比就老老实实做对照实验，同一输入同一精度，比CPU或者比不做优化的版本，把测量方法写进报告。评委不怕你慢，怕你说不清怎么测的。

先别急着找论文，去找一个能在你们板子上跑起来的最小工程，这是三个月里最该做的第一件事。你们三个都是CNN背景，其实起点不算差——卷积里的数据复用、流水线、乒乓缓冲，换成注意力机制照样能用，只是复用的对象从滑窗变成了K和V。所以补课的重点不是「Transformer是什么」，而是「一个计算图怎么拆成能塞进GW5A的算子」。

理论补法我建议跳过原始论文。那篇《Attention is All You Need》是给已经懂的人做索引的，不是入门教材。先花半天，把Q乘K转置、softmax、再乘V这条数据流在纸上画一遍，拿一个4×4的小矩阵手算一次，比看十篇博客管用。位置编码和LayerNorm先当黑盒，知道它们是逐元素操作、不构成加速瓶颈就行。KV Cache的本质是自回归解码时前面token的K、V不会变，算过一次就存下来，拿显存换计算——这个概念理解了，后面做cache量化、分页管理才有根。

这里有个容易被忽略的风险：你们很可能花一个月把理论啃明白了，结果发现板子上的工具链根本跑不通某个算子，时间全砸在补课上。所以正确的顺序是工程先行、理论随做随补。第一周目标就一个：找到带KV Cache实现的端侧推理demo，换成你们能量化到板子上的小模型，先让链路出结果，哪怕慢得离谱。

至于评委问「加速比怎么算」，这个从第一天就要记录。同一输入、同一精度，跟CPU比、跟不做优化的版本比，把测量方法写进报告。评委不怕你慢，怕你说不清怎么测的。你们现在的模型大概是什么量级，打算从哪个开源工程入手？

三个月的时间，我建议你们把顺序倒过来：先决定「要跑什么」，再决定「学什么」。很多队伍崩掉不是因为理论不懂，而是开题时选了个自己根本复现不了的模型，比如上来就要跑7B、要支持长上下文，结果光是把权重搬上板子就耗掉两个月。

对GW5A这种资源，你们应该先问自己：这块板子的片上存储和带宽，到底能舒服地承载多大参数量的模型？这个答案会直接决定你们后面所有理论补课的范围。如果只能跑几千万参数量级的小模型，那你根本不需要搞懂完整的多头注意力工程实现细节，你只需要搞懂「单头、小维度」的注意力怎么在硬件上排流水。这是取舍的起点。

具体路径我倾向于这样：第一周别碰论文，先找一个小到能在PC上秒级跑通的Transformer推理脚本，最好是纯numpy或者极简PyTorch实现的那种，把token逐个喂进去，打印出每一步QKV的形状。你会亲眼看到KV Cache就是在第二步开始复用第一步的K和V。这个「看见」比读十篇讲解都值。

第二周开始补理论，但只补三块：QK^T的矩阵乘为什么访存密集、softmax在数值上为什么要减最大值、KV Cache省的是哪一维的计算。原始论文可以先放着，那篇是给已经懂的人做索引的。你们真正要读的是带硬件视角的综述，比如讲Transformer推理加速的survey，重点看别人怎么把算子映射到FPGA上的。

分工上，三个人不要都去学理论。一个人负责把参考工程跑起来并记录环境，一个人负责性能剖析和baseline测量，一个人负责把每一步的决策写成文档。加速比答不上来，本质是baseline没从第一天就固定。你们要从第一次跑通开始，就用同一输入、同一精度、同一测量方法记录延迟。评委问的时候，你只要说清楚「慢的那个版本是什么、快的那个版本改了什么、测量工具是什么」，就够了。

先想清楚你们这块板子到底要跑多大的模型，再决定补课深度——这一步定了吗？