2026年了，FPGA工程师做AI推理加速卡，用UltraScale+跑LLM的KV Cache，BRAM和URAM怎么分配才够用？

先别急着在BRAM和URAM之间做纯容量分摊，这个问题的关键其实是时序跑不满，而不是容量不够。你算的几十MB KV Cache，对UltraScale+来说，URAM总共也就几十Mb量级，纯片上肯定放不下，所以本质上你已经在做分层了，只是分层策略没理顺。我的建议是：把URAM当成L2，专门放当前活跃的几层KV，按注意力头分bank，每个bank对应一个头，这样多bank并行读的时候冲突会小很多；BRAM则做成L3的写回缓存，也就是URAM miss之后才去HBM/DDR搬数据，BRAM只做小容量乒乓缓冲，别指望它存多少数据。你时序跑不满，大概率是AXI批量搬运和计算流水没配合好，常见做法是提前预取下一层的KV，用双缓冲把搬运延迟藏进计算里。另外注意URAM的读写端口比BRAM少，如果你把URAM当普通RAM频繁随机访问，很容易成为瓶颈，正确用法是整块搬进搬出，而不是逐字读写。还有个容易被忽略的点：7B量化模型的KV Cache大小其实和序列长度、层数、头数强相关，你现在固定512长度，如果后续要支持更长序列，最好把分层策略做成参数可配，别写死。建议你先用Vivado的resource utilization报告看看URAM和BRAM的实际占用比，再决定要不要把部分KV Cache挪到HBM。你现在用的UltraScale+具体是哪个型号？不同型号的URAM和BRAM比例差挺多的。

URAM大块、BRAM小块，这个方向没错，但时序跑不满大概率是搬数据的方式太粗暴了。试试把AXI批量搬运改成每次固定搬一个head的KV，配合双缓冲，别让搬运和计算抢同一个bank。你先查一下URAM的读写冲突是不是卡在同一个bank上。

这个问题我在实际项目里踩过一整轮坑，给你说点可能没人提的细节。首先，你算的几十MB KV Cache，要分清是单层还是全部层。7B模型一般几十层，如果每层KV都要片上缓存，那BRAM和URAM加起来都不够，所以第一件事是把「全部层」变成「当前层+下一层」。我当时的做法是，URAM只缓存当前正在计算的这一层的KV，其他层全部丢到HBM，等计算到那层之前，用AXI提前把整层的KV搬进URAM。这样URAM容量只需要覆盖单层KV，也就是序列长度512×头数×头维度×2（K和V）×量化字节数，算下来可能就几MB，URAM完全能放下。BRAM则用来做K和V的多bank乒乓缓冲，具体来说，把每个注意力头拆成两个bank，一个bank在读当前token的KV，另一个bank在写上一个token的KV，这样读写操作天然流水化，时序就不会因为bank冲突而掉速。你时序跑不满，我猜大概率是你在BRAM里做了随机访问，比如按token索引去读，这样每个周期地址都不一样，BRAM的读延迟和写延迟没法隐藏。正确做法是固定顺序读，比如每个bank只负责一个头，读地址就是token序号，这样BRAM可以做到每个周期稳定读出一个数据。关于经验公式，我个人感觉没有标准公式，但可以给你一个参考方向：URAM容量约等于单层KV大小，BRAM容量约等于2倍的单头KV大小（因为乒乓需要双份），HBM容量约等于全部层KV减去URAM能覆盖的部分。另外，你提到量化后的模型，注意量化位宽会影响KV Cache的存储格式，如果量化后KV是按bit打包的，那URAM的读写位宽要重新设计，否则会浪费带宽。最后说个容易忽略的点：AXI批量搬运的burst长度要匹配URAM的列宽，比如URAM是72bit宽，那你burst长度尽量取整数倍，否则搬运效率会低一半。你现在用的量化方案是GPTQ还是AWQ？不同量化方案对KV Cache的位宽影响挺大的，这个会直接决定URAM的打包逻辑怎么写。

如果你还在方案阶段，我劝你先想想这个板子到底要跑多长的序列。512这个长度对7B模型来说算比较短的，KV Cache几十MB其实已经说明你的量化可能不够激进。要是后面要支持2K或者4K序列，你就算把BRAM和URAM全填满也不够，所以一开始就要把HBM/DDR当成主存储，片上只做热数据缓存。我的经验是：URAM不做KV Cache的主体，而是做「当前计算窗口」的缓存，比如一次只缓存最近64个token的KV，其他全部放HBM，这样URAM容量需求大幅下降，时序压力也小很多。BRAM则用来做跨bank的转置缓冲，因为注意力计算需要按token维度读KV，而HBM搬回来的数据是按层排列的，中间需要BRAM做一次转置，这个转置如果做不好，时序照样崩。至于资源分配比例，不建议硬套公式，不如先写一个最小系统，把单层KV的读写链路跑通，看实际时序和资源占用，再逐步加层数。你现在板子上HBM的带宽是多少？如果带宽够，甚至可以把KV Cache全部放HBM，BRAM和URAM全用来做流水线缓冲，这样设计更简单，时序也更好收敛。

楼上的方案都不错，但我想补充一个不同角度：你时序跑不满，也许不是BRAM/URAM分配的问题，而是你的计算单元和存储单元之间的数据路径太长了。UltraScale+的URAM是列状分布的，如果你把KV Cache放在离计算单元很远的URAM上，布线延迟会吃掉你的时序余量。实际工程里，我会先用floorplan把URAM和BRAM的位置固定到计算单元附近，然后再看时序，往往比调分配比例有效得多。另外，你提到的「BRAM做小容量高速缓存，URAM做大容量缓冲」这个思路，我个人觉得在LLM推理场景下有点反了。URAM虽然容量大，但随机访问性能不如BRAM，而KV Cache的访问模式恰恰是随机性很强的（每个token要读所有头的KV），所以BRAM更适合做随机访问的缓存，URAM更适合做顺序搬运的缓冲。你可以试试把角色对调：BRAM放当前活跃的几个头的KV，URAM放从HBM搬下来的整层数据，用AXI顺序搬运，这样BRAM承担随机读，URAM承担顺序写，各取所长。最后问一句，你用的UltraScale+是-2速度等级还是-3？速度等级对URAM的访问延迟影响很大，如果是-2的话，时序余量可能会更紧。