在垂直整合中走钢丝：co-design 加速器科研是否能落地？
每当同行问我是做什么研究方向的，我总会说是先说“做数字架构的“，“做AI芯片的”，再问得细了才说“做加速器的”、“做co-design的”。因为虽然在靠这个话题发文章生存，但社区非常常见观点一提到加速器，就说不够落地，就像 NVIDIA 的 sparsity，数值高高挂起却鲜少人用。自己找不到很站得住脚的论据反驳这种观点，心理上加速器说出来气势上就低了半截。经过一年的 PhD 生活观察，我发现这一看法不仅在我一个人身上存在，无论是芯片方向相关，甚至在和我一样本身从事这个方向的人身上同样普遍。特别是做这个方向的同学，难免会因此引入额外心理负担焦虑。但 PhD 要考虑 idea 创新、实验工程、文章发表等等本身已经很辛苦了，如果再摊上这些焦虑、怀疑，前行负担未免太大。与其将问题都藏在心里，“等之后实习到业界看看”把问题丢给未来，亦或者吐槽末法时代大道不再，不如把这个问题敞开来说明白，思考应以什么定位和视角对待自己的研究方向。
这个问题以往网上也有很多讨论[1]，不过一方面时过境迁，code agent 的落地改变了许多诸如生态的平衡；另一方面这篇 blog 我会更多结合个人这一年的视角补充。以下是我个人 PhD 一年对加速器科研的看法观点总结，有较强的个人视角和主观倾向。希望能带给大家一些启发，也欢迎各种观点一起讨论交流。
在垂直整合方向走钢丝
在具体展开讨论分析前，我们先给这个方向下下定义。Software-hardware co-design，既然是 co-design 意味着算法层和硬件层都需要设计改进，而非单纯算法不动做硬件适配。这是一个非常典型的垂直整合和跨学科方向，旨在打破软件和硬件的抽象边界释放更多空间，探索垂直整合优化极限。Everything with cost，抽象是为了层层分工提高整体生产效率人为或自发形成的知识边界，打破边界的代价就是暴露了极大的系统复杂度让人掉 san。不过，如果收益足够大，忍受复杂度就是值得的。在实践中，由于硬件侧开发复杂度本来就高，而 AI 算法迭代日新月异，打破边界往往意味着要像走钢丝一样，在落地性、创新性、工程难度之间做取舍。标题是“加速器科研能否落地”，接下来将从“科研”、“加速器”、“落地” 三个方向展开。
科研：ISSCC 的 "3M 困境"
ISSCC 会议被誉为“集成电路的奥利匹克”，一大标志是发表工作都带有流片实现，涉及流片开发更贴合实际生产十分适合作为典型切入（当然也有带流片要求的其他会议期刊，只是 ISSCC 个人更熟悉一点）。学界 co-design accelerator 论文一般主要集中分布在 ISSCC 的存算和数字架构 session（比如 ISSCC 2026 S30 和 S31，ISSCC 2025 S14 、S23 和 S37，ISSCC 2024 S20、S30 和 S34，业界加速器芯片一般单独有个 session ，不纳入讨论），同时也会在其他 session 零散分布。
具体来说，ISSCC 会议的中稿标准可归纳为 3M，（1）道德（Moralitas）：首先这个是一个学术会议，有基础的学术道德要求；（2）实测（Measurement）：ISSCC 投稿架构文章区别于一般架构会议，有流片实测要求；（3）改进（Modification）：顶会的先进性，相对前人方案要有所改善。
然而，在 software-hardware co-design 话题大背景和学界资源相对困乏前提下，同时维持住 3M 标准十分困难，乃至一部分标准社区默认放宽。
改进不用多数，要超过前人的 baseline，重点讨论其余两点在流片背景下如何会和改进形成 trade-off 关系。首先谈谈实测，实测这一指标主要衡量流片的人力和物力成本，完整学术流片人力成本的分析可见以前博客[2][3]，更多的是物力成本约束。要保持先进性，某些设计问题仅在特殊的工艺、硬件设置下成立，比如最基础的 MPW 费用（成熟工艺 28nm 约1.4W 刀每平方毫米[4]）；现在大多问题都卡在访存侧，如果做加速器常涉及的边缘场景，由于 TDP 约束存储-逻辑的不平衡会比云端更夸张，一个 DDR IP 动辄几十万乃至几百万授权费用。国内青年基金大致是 30万元，面上基金大致平均是 50 万元，还不够 DDR IP 的费用，更别提流一次片了。ISSCC 的规则倾向应当是应该尽可能实测数据，但像 DDR 访存都默认允许使用模拟数据进行分析，而至于其他的面积 scaling、工艺 scaling 、系统 scaling 或者其余 IP 仿真，边界则相应模糊。
再说说道德，ISSCC 只要求流片，但没要求提交实物或者复核数据，再叠上半导体领域的高度黑盒特点，存在大量不可核对检验只能由作者团队自觉的灰色操作空间。道德水平存在几个等级，最高等级是 “真话都说了” ，将实验中所有好的坏的结果都如实攥写呈现，这一点别说是芯片会议，放眼整个学术界也鲜少有论文达到；其次等级是 “说的是真话”，将不利的关键实验配置、参数隐藏起来，挑选有利的实验配置比较或者有利的结果呈现。在 ISSCC 会议还要叠上半导体黑盒特点，本身加速器是一个极其复杂的系统，包含算法、编译器、runtime 最后才是硬件，CPU SPEC 测试都要对齐编译器选项，而 ISSCC 别说对齐选项，选项都没有，simulator 怎么设置的、一些指标的含义是什么、芯片数据是怎么测试的，文章里都没有（当然一部分原因来自 ISSCC 的版面短写不下，期刊会好一些），再叠上本身流片工作肯定占少数，很难对齐 workload 和工艺面积配置等，ISSCC 的对齐基本上属于意思意思。至于修改工作点，将电压压到标准工作电压的一半以下，频率拉到标准频率十分之一以换取极致能效数据也属于基操；最后等级是 “说的不全是真话”，涉及造假等，比如流片点亮失败文章继续写，情节相对严重。
流片就像一个放大器，削弱了本来靠社区向心力和自觉约束的大量规范作用，实测数据难以获得，论文结果无法复现，前人数据不断提高攀升，雪球越滚越大，陷入恶性竞争，最后损害了社区的名声。这或许也是为什么今年 ISSCC [5] 自上而下改革，添加了密度检测、关系申报以及鼓励开源更新。这些并不是强力规矩全面禁止劣币，而是君子协议给良币一个更高的舞台，期待优秀工作能引导社区风气。
加速器：软硬件博弈
如果依靠幸运和努力，能够较好维持住硬件工作的 3M 平衡，满足了基础的科研起点，接下来面对是加速器科研软硬件博弈问题。即泛化性、合理性以及改进效果的平衡。
从大方向说，软硬件耦合势必就是以损失泛化性为出发点的，这里泛化性并不是指相比通用加速器比如 NPU、GPU 之类，而是指更细粒度的实验层次，因为硬件系统本身很复杂庞大，这一个问题是在特定参数组合下出现、在特定 benchmark 模型上出现，还是仅仅作为局部现象。不过个人认为这一点并不是十分重要，泛化性研究没有边界，只要故事说得通，甚至即使技术本身当前看没有太多立足点，只要技术本身足够新颖有趣，泛化性都可以先让步。这里讨论泛化性是建立在通过了第一关 3M 平衡基础上，如果是选择报告某些数据又是另一维度的事情了。
更难维持平衡则是来自合理性，合理性说白了就是一句话“这个问题是否有必要让硬件解决”。Software-hardware co-design，在这里 software 往往狭义指代算法，但算法和硬件之间并不是真空，这是一个 algorithm-compiler-runtime-hardware 的多层系统，硬件设计实现轻则是 FPGA flow 复杂硬件开发，重则是流片血的代价，如果一个技术能够轻量地在现有硬件上通过软件修改达到大致效果，为什么需要设计硬件呢？
这类逻辑问题可以直观从文章叙述逻辑和 baseline 设置上体现。从叙事设置上，左图是常见的“ABC逻辑”，problem A： 先通过标准平台/simulator profiling 发现某个问题部署效率很严重，problem B： 然后指出如果用硬件方案实现会遇到什么问题，solution C： 最后提出改进方案解决了硬件问题，这之中跳过了“为什么要用硬件解决”的逻辑，更严密务实的思路应该是“ABCD 逻辑”：problem A： 先通过标准平台/simulator profiling 发现某个问题部署效率很严重；problem B: 研究这个问题最适合用什么方案解决；problem C： 如果 xx 方案最合适，那么 xx 方案实现的问题是什么？；solution D： 提出了什么改进方案。从 baseline 消融设置上，算法和硬件都进行改动，可以根据算法/硬件-旧方法/新方法划出 4 个象限，一般认为改进硬件专用性较强和算法耦合，删去 “旧算法-新硬件” 还剩 3 个象限，此时 baseline 上往往会忽视 “新算法-旧硬件” 的 baseline 2 对照组。导致此类工作与其说是 software-hardware co-design，不如说是做了算法的优化，套了个硬件的壳子，就好比从算法的矿洞中挖出了金矿却说是从硬件的矿洞里面挖出来的。
那么 problem B 一个问题什么时候适合硬件解决，什么时候适合其他层解决呢？一个必要条件是从动态性以及频次 出发。动态性针对该问题是 ahead-of-time 可以在编译期间解决的，还是 runtime 必须要在运行期间处理的。随着技术栈演进，现有硬件设计在软硬件系统的定位是 “细粒度的执行者+短周期内的控制流”，而更粗粒度的问题则交给上层软件栈解决。推理加速器动态性十分常见讨论，但频次往往找到忽视，一些规则式的 if-else 如果粒度太粗，放到片外/片内的 CPU 软件实现代价完全可以忽略没有必要设计硬件。以下给出几个常见技术和对应频次对照表。
| 频次 | 常见问题 | 相关技术 |
|---|---|---|
| 周期级（cycle-level） | 矩阵乘法执行和配套细粒度控制流 | 矩阵乘法计算单元（systolic array, cim, tensor core）, TMA，低精度计算单元等 |
| 块级/层级(block/layer-level) | 粗粒度稀疏（粗粒度规则 sparsity attention、MoE） | 集群 all-to-all 转发能力，专家调度编排策略等 |
| 网络级(network-level) | 时空冗余性 | diffusion cache, token pruning 等 |
另外关于机制放在编译器 AoT 还是硬件 runtime 还有生态兼容性的角度，传统 CPU 生态兼容性是重中之重，因此偏向 AoT 的 VLIW 败给了偏向 runtime 的 superscalar，但放到 AI 芯片完全不一样，（1）AI 算法迭代迅猛，（2） AI 芯片生态负担历史负担没有 CPU 重，（3）神经网络计算更加规律动态性更少，（4）结合 agent 等等技术降低软件开发成本，AI 芯片基本都以 AoT 静态调度为重心，对于加速器常见轻弹性的边缘场景尤其如此。
除了来自系统层面不同层的竞争，做硬件同样面对着做算法软件的竞争。这里不得不提及经典 hardware lottery 文章[6]，指的是软件和硬件有着相互选择塑造的作用。但硬件也分研究用、训练用、推理用， 硬件能给软件施加影响力的是掌握研究和训练的垄断巨头，而 software-hardware co-design 在整个链条里处于下游，极其受算法研究风向的牵引，算法是 co-design 的起点，一旦problem A 变动整个故事也就立不住了。比如长上下文下 attention ， kv cache 是 bottleneck ，那么多长是多长呢？算法添加一个 group attention 因此，上下文平衡长度减少 16 倍，问题还立得住吗？一旦一个问题推理效率问题足够严重，算法侧开发会主动介入解决这个问题，导致 co-design 开发变成一种你追我赶的逃逸游戏，我要发文章速度足够才能逃逸算法侧的包围，但本身 co-design 开发在链条处于信息下游，又带着系统的沉重负担，既折磨同学在一次次工作切换消耗身心，也难免在路上丢失一些东西，难以维持前文所述的两个平衡。
落地：预测终局
如果战斗力足够强悍在以上两个大逃杀中幸存，科研问题算是比较好解决，终于可以面对落地问题。我们暂且把“落地”定义为可以为社会/企业创造持续的价值。
“Computer organization and design” 中书名直接明确提出“（ISA）架构是硬件和软件的接口”，其实扩充到整个体系架构也同样成立。接口可以从长期短期角度理解，短期意味着修修 bug 完善兼容性；长期意味着全局抽象规划路线选择。学界受限于资源和定位，往往更加关注性能问题而不侧重兼容性问题。但即使短期的 bug 修复，对于社会价值不弱于直接性能提升。AI 芯片每年都在推陈出新，集群从购买那一刻开始就在折旧，如果一个bug导致集群训练多花费几个星期才收敛或者是研究额外多迭代几轮，这额外算力限制损失不可估量。
硬件研发，往往是先能用，然后再是用得好。即使 AI 降低了硬件开发和生态建设的成本，即使 AI 算力需求使得性能的收益杠杆越来越大，硬件研发仍然在整个链条中处于风险较高的底牌。引入硬件系统极致优化往往处于生态的终局（end game），此时商业路线清晰，主要技术路线收敛，此时引入硬件优化提高整体竞争力。廖博访谈[7]提到 910 和 950 设计最大变化在于 950 设计时出现了大量可参考的模式路线，大模型 code agent 落地商业路线清晰，自回归 LLM 范式收敛。
我并不是认为 co-design 加速器不能落地，而是不应过度夸大硬件的作用。 面对 co-design 加速器落地的方案，一种是以硬件为主体的加速思路，通过高度软硬件开发人物力协同优化解决方案，通过垂直整合极致压低成本使得某些平衡点成立，扩大蛋糕。我以为这种想法忽视了 co-design 的下游跟从定位，一次 follow 就要次次 follow ，follow 是无法积累自己的独特路线。另一种则是以软件为主体的预测思路，加速器是要在路线不清晰收敛时预测终局，再加大投入。至于命中率低等并不是路线本身问题，而是本身预测的固有现象。
浙公网安备 33010602011771号