2026年FPGA校招简历上写"基于FPGA的CNN加速器"，面试官追问吞吐量怎么算，答不上来是不是项目白做了？

先说结论：不是项目白做了，是你把项目的「故事」讲错了层次。面试官问吞吐量，本质不是考你背没背过某个公式，而是想确认你在做这个加速器时，脑子里有没有一张「性能从哪里来、又漏到哪里去」的账。很多人做课设/竞赛项目的路径是：找个开源工程改一改，跑通 MNIST，精度还行，就写进简历。这条路没问题，问题在于你只经历了「跑通」这个阶段，没经历「算账」这个阶段。

那账怎么算？从最粗的一层往下推。先算峰值：你的 MAC 阵列是几乘几，比如 16×16 就是每周期 256 次乘加，乘加算两次操作，所以每周期 512 OP；再乘时钟频率，比如 200MHz，得到约 102GOP/s，也就是 0.1TOPS 量级。这是理论上限，谁也超不过。然后算实际：一帧推理用了多少周期、跑了多少 MAC，两者一比就是利用率。比如峰值 512 OP/周期，实测平均只有 120，利用率大概 23%。

接下来才是面试官真正想听的：为什么只有 23%？常见瓶颈就那么几个——数据没喂饱（DDR 带宽或片上缓存带宽不够，PE 在等数据）、DSP 用不满（位宽、流水线、控制开销）、层与层之间串行等待、卷积边界和 padding 造成的空转。你要能指着自己项目说「我卡在哪个」，哪怕答案是「我当时没测，但我现在知道该测哪些计数器」，都比硬编一个数字强。

所以包装的核心不是把数字吹大，而是把「取舍」讲清楚。你可以这样组织回答：峰值算力多少，实测利用率多少，主要瓶颈是片上缓存带宽而不是 DSP，因为每读一个激活值要复用给它对应的多个权重，复用度不够时 BRAM 带宽先饱和。哪怕这个结论是你面试前补算出来的，只要逻辑自洽、你讲得明白，面试官会认为你具备工程思维。

反过来，最忌讳的是只报一个漂亮的 GOPS 却说不出来源。面试官一般会顺着追问两三层：这个数怎么来的、利用率怎么测的、瓶颈怎么定位的、如果让你优化下一步做什么。答不上第一层，后面就全塌了。

给你一条可执行的补课路线：第一步，把你项目里 MAC 阵列规模和频率写清楚，手算峰值；第二步，加几个性能计数器（总周期、有效 MAC 数、DDR 读写量），跑一次实测；第三步，用 roofline 的思路判断是算力受限还是带宽受限；第四步，想一个具体的优化点，比如提高输入复用、做双缓冲、改数据流。这四步做完，你就能把「跑通 MNIST」翻译成一段有工程含量的叙述。

顺便说一句，被追问是好事，说明面试官对你的项目有兴趣。真正白做的项目，是面试官连问都不想问的那种。你现在缺的不是新项目，是把已有项目重新算一遍账。你手头这个加速器，MAC 阵列大概是什么规模，跑在什么频率上？知道这两个数我就能帮你估个峰值。

其实面试官要的不是精确数字，是看你有没有「性能意识」。你只要能把峰值算力怎么来、实测为什么低这两件事讲顺，项目就不算白做。峰值 = MAC 阵列规模 × 2 × 频率，这个先背熟；利用率 = 实测有效运算量 ÷ 峰值，哪怕你事后补测一次也行。瓶颈无非 DSP 打满、BRAM 带宽不够、DDR 供不上这三类，能说出自己卡在哪一类就及格了。最怕的是只讲「跑通了 MNIST」，那在面试官眼里等于没做过性能相关的设计。建议你回去把项目加几个计数器重新跑一遍，把数字补上再投。

先别急着否定自己，项目没白做，是你只做了项目的前半段。我给你捋一条主线，你顺着走一遍就明白了。

做加速器这件事，本质是把一个算法映射到硬件资源上，然后回答三个问题：算力够不够、带宽够不够、面积（DSP/BRAM/LUT）够不够。面试官问吞吐量，其实是在检验你有没有走完这条映射链，而不是背数字。

第一步，算峰值。你的MAC阵列是几乘几，比如16×16，那每周期就是256次乘加，一次乘加算两个操作，所以每周期512 OP。再乘频率，200MHz就是约102GOP每秒。这个数字是你硬件的天花板，先把它算出来，写在纸上。

第二步，算实际。MNIST一帧推理跑了多少周期，或者你测到的帧率乘上每帧的运算量，得到实测有效算力。峰值除以实测，就是利用率。别怕数字难看，百分之十几二十都很正常，关键是你知道为什么低。

第三步，找瓶颈。一般是三类：DSP打满、片上BRAM带宽不够喂数据、DDR/外部存储供不上。你要能说出自己卡在哪一类。比如卷积层数据复用做得差，每个周期都在从BRAM重复读，那瓶颈就是带宽不是算力。

这条线走完，你简历上那句话就从「跑通了MNIST」变成了「峰值XX GOPS，实测利用率XX%，瓶颈在片上带宽」。面试官立刻知道你是有性能意识的人。

回去建议你加几个计数器重新跑一遍，把真实数字补上，再投简历。你这套阵列规模和时钟频率大概是多少？

先给你一个反向的例子，可能比讲道理有用。我认识一个同学，简历上也写了CNN加速器，面试被问吞吐量，他直接说：我峰值算下来大概一百多个GOPS，实测跑MNIST一帧利用率只有百分之十几，因为我的全连接层权重没做片上复用，每算一次都要从DDR搬数据，带宽先卡死了。面试官当场就笑了，说你这项目至少是亲手做过的。后来他过了。

你看，他答的不是漂亮数字，是「我知道自己烂在哪」。这就是关键。

所以别把这件事想成「我要包装到不被问穿」，而是「我要留一个诚实的短板，并且能解释它」。风险在于，如果你硬凑一个漂亮的利用率，面试官往下追问「那你怎么测的、计数器加在哪、突发长度多少」，你马上就崩，比一开始承认低利用率还难看。

替代做法其实很简单：回去把项目补两个计数器，一个数总周期，一个数有效MAC次数，算出真实利用率。哪怕只有15%，把它写进简历的括号里，比如「实测利用率约15%，瓶颈为全连接层DDR带宽」。这一句比「完成CNN加速器」值钱十倍。

顺便说，你现在这个阶段被追问是好事，说明简历过了初筛。真正危险的是没人问你。你项目里那个卷积层和全连接层，分别用的是哪种数据流，你还记得吗？

先说个容易踩的坑。很多人被追问性能指标后，第一反应是回去把数字编漂亮，比如硬报一个百分之七八十的利用率。这比答不上来更危险，因为面试官只要顺着问一句「你怎么测的、计数器加在哪、一次突发搬多少数据」，你就露馅了，而且性质从「没做过性能分析」变成「数据存疑」，后者更伤。

替代做法是留一个诚实的短板。你回去把两个计数器补上，一个数总周期，一个数有效MAC次数，跑一遍MNIST，算出真实利用率。哪怕只有百分之十几，你也能讲清楚为什么低：比如全连接层权重没做片上复用，每算一次都去DDR搬，带宽先卡死了。面试官听到这种自我剖析，反而会觉得这项目是你亲手做的。

所以不是项目白做，是你只做了前半段。风险在于你既没有数字，也没有对瓶颈的判断，那面试官只能认为你没走完「算法映射到硬件」这条链。补测一次，把数字和原因一起带上，比任何包装都稳。

你现在手头还有能重新跑板子的环境吗？有的话这件事两三天就能补上。

把这件事拆成一条主线，你顺着走一遍就通了。做加速器本质是把算法映射到硬件，然后回答三个问题：算力够不够、带宽够不够、片上资源够不够。面试官问吞吐量，是在检验你有没有走完这条映射链，不是考你背数字。

第一步算峰值。MAC阵列几乘几，比如16乘16，每周期256次乘加，一次乘加算两次操作，所以每周期512 OP，再乘频率200MHz，约102GOP每秒，也就是0.1TOPS量级。这是天花板，先写在纸上。

第二步算实际。一帧推理花了多少周期，或者用帧率乘每帧运算量，得到实测有效算力。峰值除以实测就是利用率。数字难看很正常，关键是知道为什么低。

第三步找瓶颈，无非三类：DSP打满、BRAM带宽不够、DDR供不上。你要能说出自己卡在哪一类，以及数据复用策略是怎么设计的，比如权重能不能常驻片上、输入特征图怎么分块复用。

这里其实藏着一个取舍。想做高复用，就得占更多BRAM或寄存器，面积和布线压力上来，频率可能掉；想省资源，就得频繁访存，带宽成瓶颈。roofline模型说的就是这个：算力再高，访存跟不上，实际性能就被带宽那条斜线压住。面试官真正想听的是你意识到这条约束，并且做过权衡。

所以别急着包装。花两天把峰值、实测、瓶颈三个数补齐，再想清楚你的复用策略牺牲了什么换来了什么。这套逻辑讲顺了，项目就立住了，追问反而变成你的加分项。

你这个情况，我建议先把心态放平：项目没白做，只是简历上那句话把它写大了。『基于FPGA的CNN加速器』这几个字本身就等于向面试官发出邀请——那你总得知道它跑多快吧。所以被追问不是倒霉，是必然。

真要补救，就一条主线：回去把账算一遍。峰值怎么来？MAC阵列几乘几，乘加算两次操作，再乘频率，比如16×16乘2乘200MHz，约100GOPS量级。这是天花板。实测怎么来？一帧推理跑了多少周期，或者帧率乘每帧运算量，除一下就是利用率。数字低很正常，关键你能说出为什么低：是DSP打满、BRAM带宽不够，还是DDR供不上。

能讲清这两件事，面试官基本就信你亲手做过。你现在缺的不是包装，是这一小时的补测。你的板子时钟跑多少、阵列是几乘几，方便说下吗，我可以帮你估一下峰值大概落在哪个量级。

先说个不太一样的角度。很多同学以为面试官问吞吐量是在考数字，其实他是在考你有没有形成『性能是从哪来、又从哪漏掉』的直觉。这个直觉一旦建立，你答任何加速器题都稳；没建立，你背再多公式也会被下一问戳穿。

那这个直觉怎么长出来？我建议你从一条因果链去理解，而不是记三个公式。

第一层，算力从哪来。你的硬件每周期能并行做多少次乘加，取决于MAC阵列规模；再乘上时钟频率，就是每秒的理论操作数。这个数字是天花板，你设计得好不好都超不过它。它告诉你『我的硬件上限在哪』。

第二层，算力为什么用不满。这一步才是精髓。理想情况下每个周期阵列都在干活，但现实中数据得先搬进来。如果权重没做片上复用，每算一次都要去DDR取，那你的阵列大部分时间在等数据，利用率自然低。这就是常说的roofline思想：计算强度和带宽共同决定你实际能跑多快，谁先卡住谁说了算。

第三层，卡在哪。片上资源无非DSP、BRAM、LUT。DSP打满说明计算单元用尽了；BRAM带宽不够说明数据供给跟不上；DDR供不上说明片外带宽是瓶颈。你要能指着自己的设计说『我卡在第二类，因为我特征图分块策略没做好，复用率太低』。

沿着这条链走一遍，你会发现面试官追问的每一句，其实都在这条链的某个节点上。他问峰值，是在第一层；问利用率，是在第二层；问瓶颈在DSP还是带宽，是在第三层。你不是要背答案，是要把这条链在心里跑通。

具体到行动，回去做三件事就够了：一，把你的阵列规模和频率写下来，算出峰值；二，加两个计数器，一个数总周期，一个数有效MAC次数，重新跑一次MNIST，算出真实利用率；三，写下利用率低的原因，诚实的那种。做完这三件事，你的项目就从『跑通了』升级成『我算过账』，面试时的底气完全不一样。

顺便说，低利用率不丢人。学术界的加速器论文里，利用率百分之二三十都很常见，因为真实网络层结构复杂、数据复用难做。面试官怕的不是数字低，是你连数字都没有、连低在哪都不知道。你现在这个阶段补上完全来得及。你项目里权重是放片上还是每次从DDR读的，这个决定了你瓶颈大概率落在哪。

给你提个反向的风险点，比讲方法更有用。

现在很多人被追问性能后，第一反应是回去把数字描漂亮，比如硬报个百分之七十的利用率。这比答不上来危险得多。面试官只要顺着问一句『你怎么测的、计数器加在哪、一次突发搬多少数据』，你当场就露馅。而且性质变了：从『没做过性能分析』变成『数据存疑』，后者在面试官心里是减分项，直接怀疑你简历真实性。

替代做法是留一个诚实的短板。回去加两个计数器，一个数总周期，一个数有效MAC次数，跑一遍MNIST，算出真实利用率。哪怕只有百分之十几，你也能讲清楚为什么低，比如全连接层权重没做片上复用，每次都要去DDR搬，带宽先卡死。面试官听到这种自我剖析，反而觉得项目是你亲手做的。

所以包装的正确姿势不是美化，是补全。你不用假装利用率很高，你只要证明你走过『算法映射到硬件』这条链，并且知道自己在哪一环偷了懒。这比任何漂亮数字都值钱。你现在最想不通的是算峰值还是找瓶颈那一块？