1. 从一颗芯片的诞生说起为什么“芯模协同”是个真问题芯片设计这行干久了你会发现一个很有意思的现象做前端逻辑的人不太关心后端物理实现的约束做后端的人又常常抱怨前端给的网表“不接地气”而等到流片回来跑推理任务算法团队又会说“这芯片怎么跑我的模型这么慢”。三个团队各自都没做错什么但凑在一起就是各种拧巴。这几年大模型推理需求爆发之后这种拧巴被放大了十倍不止——因为模型结构迭代的速度已经远远超过了芯片设计周期。一颗中大规模SoC从架构定义到tapeout顺利的话也要12到18个月而主流大模型的架构半年就可能换一代。你流片时针对某个注意力结构做的硬件加速单元等芯片回来可能已经没人用那种结构了。这就是“芯模协同进化”这个命题的现实背景不是让芯片去追模型也不是让模型去迁就芯片而是让两边在设计阶段就互相知道对方在干什么。Qwen系列模型在这件事上提供了一个很好的切入点。它的开源程度足够高模型结构、量化方案、推理框架适配都比较透明团队可以拿它当“靶子模型”来做芯片设计的验证。而“推理适配”这个词落到工程上其实就是三件事算子映射、内存布局、精度策略。这三件事如果等到芯片回来再做基本就是灾难如果能在设计阶段就用Qwen这样的真实模型跑通仿真链路很多坑可以提前填掉。这篇文章面向的是做AI芯片架构、EDA工具链、推理框架适配的工程师也适合想了解“模型和芯片怎么协同”这个方向的产品和技术管理者。我会从整体思路、核心细节、实操流程、问题排查四个层面把“Qwen落地生产级芯片设计与推理适配”这件事拆开讲尽量给到可以直接参考的方案和踩过的坑。2. 整体设计思路为什么选Qwen做协同靶子2.1 靶子模型的选择逻辑做芯模协同第一件事是选一个“够真实但又不至于失控”的模型作为协同对象。太小的模型比如几层CNN验证不出真实推理负载的压力太大的模型比如千亿参数MoE又会让仿真和验证成本爆炸。Qwen系列的好处是它有完整的尺寸梯度从0.5B到72B甚至更大都有而且同一代模型的架构是一致的这意味着你可以在小尺寸上把流程跑通再平滑迁移到大尺寸做压力测试。另一个关键点是Qwen的量化生态比较成熟。芯片设计阶段最怕的就是“模型精度要求”和“硬件数值格式”对不上。Qwen有GPTQ、AWQ、GGUF等多种量化版本还有官方和社区维护的量化配置这让硬件团队可以直接拿不同精度版本的模型去跑观察精度损失和硬件资源占用的关系。我实测下来用Qwen2.5-7B的INT4量化版本做算子级仿真精度损失在可接受范围内而硬件面积能比FP16方案省下将近60%。2.2 协同进化的三个层次“芯模协同”不是一句口号落到工程上我把它分成三个层次。第一个层次是算子级协同模型的算子清单和硬件的指令集/加速单元要能对上哪些算子走通用计算、哪些走专用加速这个映射关系要在设计阶段就定下来。第二个层次是内存级协同KV Cache怎么放、权重怎么切分、激活值怎么复用这些决定了片上内存和带宽的设计。第三个层次是精度级协同模型哪些层对精度敏感、哪些层可以大胆量化这直接影响硬件是否要支持混合精度。这三个层次里算子级协同是最先要做的也是最容易出问题的。我见过太多项目硬件团队按自己的理解设计了一套加速指令结果模型团队一看常用的算子根本没覆盖或者覆盖了但数据排布对不上最后只能靠CPU兜底性能直接腰斩。用Qwen做靶子就是因为它算子清单清晰、社区适配多你可以拿它的推理图去反推硬件该支持什么。2.3 为什么强调“生产级”“生产级”这三个字很关键。学术界的芯模协同往往停留在“能跑通”的层面但生产级要求的是“跑得稳、跑得快、跑得省”。具体来说生产级芯片设计要考虑良率、功耗、散热、封装推理适配要考虑批处理、动态shape、多卡互联。Qwen作为靶子模型它的生产级推理需求包括支持变长输入、支持KV Cache动态增长、支持多并发请求。这些需求如果不在芯片设计阶段考虑进去流片回来就是硬伤。我个人的经验是在架构定义阶段就要把Qwen的推理trace跑一遍统计出真实的算子分布、内存访问模式、计算密度。这个trace不用太精确但一定要真实。用仿真器跑一遍Qwen2.5-7B的prefill和decode阶段你会发现decode阶段的瓶颈根本不在算力而在内存带宽和KV Cache的访问效率。这个结论直接决定了你的芯片是该堆算力还是该堆带宽。3. 核心细节解析算子映射、内存布局与精度策略3.1 算子映射从模型图到硬件指令Qwen的推理图拆开看核心算子其实不多矩阵乘GEMM、注意力Attention、归一化RMSNorm、激活SiLU、旋转位置编码RoPE。但每个算子在硬件上的实现方式差别很大。以GEMM为例prefill阶段是大矩阵乘适合高并行度的 systolic arraydecode阶段是矩阵向量乘GEMV并行度上不去反而对内存带宽更敏感。如果你的芯片只设计了一种GEMM加速器decode阶段就会很尴尬。我的做法是在设计阶段就把Qwen的prefill和decode分开建模。prefill阶段统计出M、N、K的分布decode阶段统计出batch size和序列长度的分布。然后根据这些分布去设计加速器的形状。比如prefill阶段M普遍在512以上那systolic array的M维度就可以做大一点decode阶段M基本等于batch size通常小于32那就要考虑用向量单元或者小规模阵列来跑。这里有个坑要提醒Qwen不同尺寸的模型算子分布差异很大。0.5B模型的hidden size是8967B是358472B是8192。如果你的加速器形状只针对某一个尺寸优化换一个尺寸效率就掉得厉害。所以生产级设计一定要做参数化让加速器能适应不同的hidden size和head数。3.2 内存布局KV Cache是真正的战场做推理芯片的人都有一个共识decode阶段的性能瓶颈在KV Cache。Qwen的KV Cache大小可以算出来2 × num_layers × num_kv_heads × head_dim × seq_len × batch_size × dtype_size。以Qwen2.5-7B为例28层、4个KV head、head_dim 128、序列长度4096、batch size 1、FP16算下来大约是2 × 28 × 4 × 128 × 4096 × 1 × 2 234MB。这个数字看起来不大但问题是它要频繁读写而且随着序列增长线性膨胀。芯片设计阶段要考虑的是KV Cache放在哪、怎么切、怎么复用。放片上SRAM当然快但234MB根本放不下放HBM带宽又不够。常见的做法是分层放置最近几个token的KV放片上历史KV放HBM用预取和缓存策略来掩盖延迟。这个策略要在设计阶段就用Qwen的真实访问模式去验证否则你设计的预取器可能根本预取不到点子上。还有一个细节是KV Cache的排布格式。是按层连续排、还是按head排、还是按token排对带宽利用率影响很大。我试过几种排布最后发现按head分组、层内连续的格式在Qwen上表现最好因为同一层的多个head可以并行读取层间切换的开销也能被掩盖。3.3 精度策略哪些层可以大胆量化Qwen的量化适配已经有很多现成方案但芯片设计关心的不是“能不能量化”而是“量化后硬件能省多少”。我的经验是Qwen的FFN层对量化最不敏感INT4甚至INT3都能扛住Attention层的QK^T对量化比较敏感建议至少INT8而RMSNorm和RoPE这些非矩阵算子最好保持FP16因为它们的计算量小量化省不了多少资源反而可能引入误差。混合精度对硬件的要求是加速器要支持多种数值格式并且能在层间切换。这听起来简单做起来麻烦。不同精度格式的累加器宽度、舍入模式、溢出处理都不一样如果设计时没考虑周全后期改起来就是伤筋动骨。我建议在架构定义阶段就列一张表把Qwen每一层的推荐精度、累加器宽度、是否支持动态切换都标清楚然后让硬件团队按这张表去设计。层类型推荐精度累加器宽度是否动态切换FFN GEMMINT4/INT832bit支持Attention QK^TINT832bit支持Attention PVINT832bit支持RMSNormFP16FP16不支持RoPEFP16FP16不支持SiLUFP16FP16不支持这张表不是拍脑袋来的是拿Qwen2.5-7B在仿真器上跑了几十组配置对比出来的。当然不同模型尺寸会有差异但大方向是一致的。4. 实操过程从模型trace到硬件仿真4.1 第一步提取Qwen的推理trace要做的第一件事是把Qwen的推理过程trace下来。工具上可以用PyTorch的profiler也可以用推理框架自带的dump功能。我习惯用PyTorch profiler因为它能同时抓到算子耗时、内存分配、kernel launch信息。具体操作是加载Qwen模型构造一批有代表性的输入不同长度、不同batch size跑推理然后把trace导出成JSON或者CSV。这里要注意trace的环境要尽量接近真实部署环境。如果你在A100上trace然后拿这个trace去指导边缘芯片设计那算子分布可能完全对不上。我的做法是在目标算力级别的GPU或者CPU上trace比如你要设计的是端侧芯片那就在类似算力的设备上跑这样得到的算子耗时比例才有参考价值。trace出来之后重点看三个东西算子耗时占比、内存访问量、kernel launch次数。Qwen2.5-7B在decode阶段GEMM的耗时占比可能只有30%但内存访问量占70%以上。这个结论直接告诉你芯片设计要把重心放在内存子系统上而不是一味堆算力。4.2 第二步算子映射与硬件建模拿到trace之后下一步是把算子映射到硬件单元上。这一步需要硬件团队和算法团队坐在一起逐个算子过。比如GEMM算子硬件上是用systolic array、还是用向量单元、还是用DSP不同的选择对应不同的面积、功耗、灵活性。我的建议是先用一个高层次的性能模型比如用Python写的cycle-level模拟器去评估不同方案的吞吐和延迟再决定最终的硬件配置。建模的时候要特别注意数据复用。Qwen的GEMM里权重矩阵是固定的激活值是变化的所以权重可以常驻片上激活值流式读取。这个复用模式如果能在硬件上实现带宽需求能降一个数量级。但前提是你的片上内存够大能放下至少一部分权重。7B模型的权重INT4量化后大约3.5GB片上肯定放不下但可以放一部分热点权重剩下的走HBM。4.3 第三步精度仿真与误差分析精度仿真是最容易被忽视但最不能省的一步。具体做法是用Qwen的原始FP16输出作为基准然后模拟硬件量化后的输出逐层对比误差。工具上可以用PyTorch的量化模拟也可以自己写定点仿真。关键是误差要逐层看不能只看最终输出因为误差会累积某一层的微小误差可能在后面被放大。我实测下来Qwen2.5-7B在INT4量化下如果FFN层用INT4、Attention用INT8、其他用FP16最终输出的困惑度perplexity上升不到5%完全可接受。但如果Attention的QK^T也用INT4困惑度会飙升20%以上这就不能忍了。所以精度策略一定要分层制定不能一刀切。4.4 第四步端到端仿真与性能评估前面三步做完就可以跑端到端仿真了。端到端仿真的目的是验证在给定的硬件配置下Qwen的推理延迟、吞吐、功耗能不能达到设计目标。这一步通常要用到cycle-accurate的模拟器或者至少是transaction-level的模型。仿真时间可能很长所以输入要选有代表性的比如prefill用512长度、decode用128长度batch size选1和8两档。仿真结果要跟设计目标对比。如果延迟超标就要定位是哪个算子、哪个环节的问题。常见的问题包括KV Cache访问冲突、权重加载带宽不足、算子间同步开销过大。这些问题在仿真阶段发现改起来还来得及等流片回来再发现那就只能改软件或者降频跑了。5. 常见问题与排查技巧实录5.1 算子对不上模型有但硬件没有这是最常见的问题。Qwen用到的某些算子比如RoPE的变体、或者某些归一化方式硬件加速器可能没覆盖。排查方法是把Qwen的算子清单和硬件的指令集清单做交集和差集差集里的算子就是风险点。解决方法有两种一是硬件增加指令二是软件用等价算子替换。我倾向于后者因为改硬件周期太长而软件替换只要精度和性能可接受就行。提示RoPE在Qwen里是分半旋转的有些硬件加速器只支持全旋转这时候可以用两次半旋转来模拟性能损失很小。5.2 精度掉点量化后模型变傻精度掉点的排查要逐层做。先定位是哪一层开始误差变大的然后看这一层的量化配置是不是太激进。常见的原因是累加器宽度不够导致中间结果溢出。比如INT4乘INT4结果用INT8累加几次累加就溢出了。解决办法是加宽累加器或者用分块累加。我一般建议累加器至少32bit这样基本不会溢出。5.3 带宽瓶颈算力没用满带宽瓶颈的表现是算力利用率很低但内存带宽跑满了。排查方法是看仿真里的带宽利用率曲线如果持续在90%以上那就是带宽瓶颈。解决办法包括增加片上缓存、优化数据排布、用压缩技术减少数据传输量。Qwen的权重可以用稀疏化或者低秩分解来压缩但要注意精度损失。5.4 动态shape支持变长输入处理不了生产级推理必须支持变长输入但很多硬件加速器只支持固定shape。排查方法是构造不同长度的输入看硬件能不能正确处理。如果不行就要在软件层做padding或者分桶。padding简单但浪费算力分桶复杂但效率高。我的经验是对于Qwen这种模型按64或者128分桶比较合适既能覆盖大部分长度又不会浪费太多。问题类型典型表现排查方法解决思路算子缺失仿真报错或走CPU兜底算子清单差集软件替换或硬件增加精度掉点困惑度上升明显逐层误差对比调整量化配置或加宽累加器带宽瓶颈算力利用率低带宽利用率曲线增加缓存或优化排布动态shape变长输入失败多长度输入测试padding或分桶5.5 仿真与实测的gap仿真结果和流片后的实测结果往往有差距这个gap可能来自工艺偏差、时钟树偏差、或者模型本身的动态性。减小gap的方法是仿真模型要尽量精确包括时序、功耗、温度的影响同时要留足够的margin不要卡着设计目标做。我的经验是仿真结果至少要比设计目标好20%流片后才有可能达标。6. 工具链与协作流程的几点经验6.1 EDA工具在协同中的角色EDA工具在这件事里不只是画版图的它还要承担协同验证的角色。比如用EDA工具做功耗分析时要能把Qwen的推理负载映射进去看不同算子在不同工艺角下的功耗表现。这要求EDA流程和模型推理流程能对接通常需要自己写一些脚本做转换。我见过一些团队用立创EDA做前期验证虽然它主要面向PCB但在系统级功耗估算上也能提供参考。6.2 Agent化的工作流现在很多团队在用Agent来做设计流程的自动化。比如用Agent去跑Qwen的推理trace、自动提取算子清单、自动生成硬件配置。这确实能省不少人力但要注意Agent的输出需要人工复核尤其是涉及精度和性能的关键决策。我试过用Agent做算子映射的初筛效率提升很明显但最终的映射表还是要人工确认一遍。6.3 跨团队协作的节奏芯模协同最大的挑战不是技术是协作节奏。模型团队迭代快硬件团队迭代慢两边的时间线要对齐。我的做法是设立一个“协同基线”选定一个Qwen版本作为基线硬件设计围绕这个基线做同时模型团队的新版本要定期在仿真环境里跑看是否兼容。这样既能保证硬件设计有稳定的目标又能及时捕捉模型的变化。7. 一些实操心得与避坑建议第一不要等到芯片回来才做推理适配。设计阶段就要用Qwen跑仿真哪怕仿真速度慢也比流片回来发现跑不了强。我见过一个项目芯片回来才发现KV Cache的排布和推理框架对不上最后只能降batch size跑性能损失一半以上。第二精度策略要分层制定不要一刀切。Qwen的不同层对量化的敏感度差异很大FFN可以大胆量化Attention要保守一点。这个结论要在设计阶段就通过仿真确认不要拍脑袋。第三内存子系统的设计要留余量。Qwen的KV Cache会随着序列长度增长如果你的片上内存刚好够4096长度那8192长度就崩了。建议按目标长度的1.5倍来设计留出余量。第四仿真环境要尽量真实。用A100的trace去指导端侧芯片设计结论可能完全相反。trace的设备算力要跟目标芯片在一个量级这样得到的算子分布才有参考价值。第五跨团队协作要有固定的同步机制。模型团队和硬件团队最好每周过一次仿真结果及时发现问题。不要等到里程碑才对齐那时候改起来成本太高。最后再分享一个小技巧Qwen的推理trace可以用不同batch size多跑几组然后看算子分布的变化。batch size小的时候decode阶段的GEMV是瓶颈batch size大的时候prefill阶段的GEMM变成瓶颈。这个变化规律直接决定了你的硬件该偏向哪一边。如果你的目标场景是小batch推理那就把GEMV的效率做上去如果是大batch那就堆GEMM的算力。这个决策在设计阶段就要定下来后面改不了。