062、NPU的BERT加速：嵌入层与编码器硬件设计上周五凌晨三点，我在调试一块自研NPU的BERT推理时，发现一个诡异现象：同样的输入，FPGA仿真结果和RTL仿真差了整整两个数量级的延迟。排查了三天，最后定位到嵌入层的查表操作——我用了双端口BRAM，但BERT的Token Embedding和Segment Embedding同时访问同一个地址空间，导致读端口冲突，硬件自动插入了等待周期。这个坑让我意识到，BERT在NPU上的加速，远不止是堆算力那么简单。嵌入层的硬件化：查表不是你想的那样BERT的嵌入层包含Token Embedding、Segment Embedding和Position Embedding三张表。软件实现时，这不过是三个nn.Embedding层，但硬件上，查表操作直接映射为SRAM或寄存器文件的随机读取。第一个坑：多表并行读取的带宽瓶颈。BERT Base的词汇表大小是30522，每个Token用768维向量表示。单张Embedding表的大小是30522×768×2字节（FP16）≈ 45MB。三张表加起来超过130MB。如果全部用片上SRAM，成本直接爆炸。我的做法是：Token Embedding放在片外DDR，Segment和Position Embedding因为表小（2×768和512×768），放在片上TCM（紧耦合内存）。但问题来了——片外DDR的读取延迟是几十纳秒级别，而NPU的MAC阵列一个周期就能完成一次乘加。这意味着嵌入层会成为整个流水线的瓶颈。解决方案是
062、NPU的BERT加速：嵌入层与编码器硬件设计
062、NPU的BERT加速：嵌入层与编码器硬件设计上周五凌晨三点，我在调试一块自研NPU的BERT推理时，发现一个诡异现象：同样的输入，FPGA仿真结果和RTL仿真差了整整两个数量级的延迟。排查了三天，最后定位到嵌入层的查表操作——我用了双端口BRAM，但BERT的Token Embedding和Segment Embedding同时访问同一个地址空间，导致读端口冲突，硬件自动插入了等待周期。这个坑让我意识到，BERT在NPU上的加速，远不止是堆算力那么简单。嵌入层的硬件化：查表不是你想的那样BERT的嵌入层包含Token Embedding、Segment Embedding和Position Embedding三张表。软件实现时，这不过是三个nn.Embedding层，但硬件上，查表操作直接映射为SRAM或寄存器文件的随机读取。第一个坑：多表并行读取的带宽瓶颈。BERT Base的词汇表大小是30522，每个Token用768维向量表示。单张Embedding表的大小是30522×768×2字节（FP16）≈ 45MB。三张表加起来超过130MB。如果全部用片上SRAM，成本直接爆炸。我的做法是：Token Embedding放在片外DDR，Segment和Position Embedding因为表小（2×768和512×768），放在片上TCM（紧耦合内存）。但问题来了——片外DDR的读取延迟是几十纳秒级别，而NPU的MAC阵列一个周期就能完成一次乘加。这意味着嵌入层会成为整个流水线的瓶颈。解决方案是
