结论前置：能效比的胜负手早已不在单一制程节点

在球友体育技术解读栏目梳理的多个架构案例中，一个反复出现的判断是：能效比的提升越来越依赖架构、制程、封装三者的协同，而不是单纯等待下一代制程。程砚舟在智能芯片设计行业做了十多年架构工作，他的体会是，十年前团队讨论能效比，重点是把每瓦性能做上去；如今讨论能效比，先要问清楚这颗芯片跑在什么场景、配什么内存、用什么封装。球友体育在整理技术资料时也发现，同一架构在不同封装方案下的实测能效差异，往往比跨一个制程节点还明显。

这篇文章不堆参数，而是沿着一位架构师的职业轨迹，把能效比这个指标拆开来看。球友体育希望读者读完能建立一个判断框架：看到一颗芯片宣称能效领先时，知道该追问哪些前提。

第一阶段：能效比是设计部门的事

程砚舟入行时参与的第一颗芯片，能效目标写在设计规格书的第一页，考核方式很直接——每瓦能跑多少运算。那个阶段，架构团队的主要手段是压缩数据通路、减少无效翻转、把常用操作固化进流水线。球友体育技术解读栏目在复盘早期架构文档时注意到，这类优化对能效的贡献通常在百分之十几的量级，属于“挤毛巾”式的精细活。

他回忆，当时跨部门协作很少，封装和板级设计基本是后端的事。芯片设计完成，交给封装厂按标准方案走，能效数据在实验室里测出来就算交差。问题在于，芯片真正装进设备后，内存访问的功耗占比往往超出预期，而这些损耗在设计阶段几乎没人负责。球友体育在梳理产业公开资料时也看到类似规律：计算单元的能效提升容易被看到，数据搬运的能效损耗却常被低估。

  • 设计阶段关注每瓦运算量，考核口径单一。
  • 内存与互连功耗常被归入“系统问题”，缺少责任人。
  • 封装按标准方案执行，能效协同空间有限。

第二阶段：显存带宽把能效问题摆上台面

转折出现在他参与的一颗面向推理场景的芯片上。团队把计算单元能效做得很漂亮，但整机实测时，功耗大头落在显存访问上。程砚舟用一个比喻解释：计算单元像厨房，显存像仓库，菜刀再快，来回搬菜的路太长，整体效率就上不去。球友体育技术解读栏目在多篇显存带宽相关解读中强调过同一个结论：推理场景的能效瓶颈，常常先出现在数据供给端，而不是算力端。

这次经历改变了他的工作方式。架构评审开始要求显存子系统同步提交能效预算，缓存层级、数据复用策略、片上互连拓扑都要纳入能效评估。球友体育在整理这类案例时发现，把数据搬运功耗显性化之后，很多设计取舍会立刻变得清晰：与其堆更多计算单元，不如先把数据复用率提上去。这种思路上的转变，比任何单项技术都更影响最终能效。

第三阶段：封装成为能效设计的前置变量

最近几年，程砚舟的团队在设计启动阶段就会拉上封装工程师。原因很实际：芯粒方案能把不同功能的晶片分开制造再集成，但芯粒之间的互连功耗、信号完整性和散热路径，都会直接改变整颗芯片的能效表现。球友体育技术解读栏目在封装技术相关文章里反复说明，先进封装不是简单的“拼装”，而是能效预算的再分配。

他举了一个内部讨论的例子：同样两颗芯粒，采用不同互连密度和基板方案，整芯片能效在典型负载下可以拉开可观差距。这个差距无法靠架构优化单独弥补，必须在封装选型时就锁定方向。球友体育认为，这正是能效比从“设计指标”变成“系统约束”的典型体现——它不再由某一个部门负责，而是贯穿架构、制程、封装、板级的共同目标。

  • 芯粒互连功耗需要与计算功耗一并纳入预算。
  • 封装选型影响散热路径，进而影响持续负载下的能效。
  • 能效评估从单点指标转向典型场景下的整机表现。

给读者的判断框架

程砚舟现在带新人，第一课不是讲架构，而是让新人把一颗芯片的功耗拆成计算、存储、互连、供电几块，再问每一块由谁负责。球友体育技术解读栏目推荐读者也用这个方式看新闻：看到能效宣称时，先确认测试场景、内存配置和封装形态，再看数字。能效比从来不是孤立成绩，而是一整套工程取舍的结果。理解这一点，比记住任何一个具体数值都更有价值。

对关注智能芯片的读者来说，球友体育会继续沿着人物与工程实践的角度，把复杂概念拆成可理解的判断线索。技术演进的方向，往往藏在工程师日常的取舍里。