最近这几个月冯·诺依曼已死根底座才是未来这句话在我们做底层系统的圈子里被转了好几轮。第一次看到时我以为是哪家芯片公司的发布会预热词看多了才明白这其实是很多从业者对当下计算产业走向的一个真实判断。冯·诺依曼架构当然没有物理消亡今天你手里的手机、电脑、云服务器几乎清一色还是这个结构。真正发生变化的是当计算任务从文本处理切换到大模型推理从单机程序变成无处不在的分布式协同之后这套统治了半个多世纪的顶层设计越来越力不从心。于是根底座从一个抽象口号变成了一个必须落到实处的工程目标。这篇文章不打算复述教科书也不做趋势预言。我想从一个长期写底层代码、踩过无数性能坑的开发者视角把三件事说清楚冯·诺依曼结构到底卡在哪所谓根底座本质上是什么以及我们这些还在写业务代码和系统代码的人如何在新底座切换的过程中少交学费。1. 为什么冯·诺依曼架构会被宣布死亡1.1 拆掉那堵看不见的存储墙冯·诺依曼体系结构最核心的特点是存储和计算分离。指令放在内存里数据也放在内存里CPU负责一条一条取指令、取数据、算完写回。这个模型在纸面上非常干净问题在于现实世界里的取和算速度完全不对等。我在一次分享里打过这样一个比方。假设你在一个超大型仓库里工作执行力很强一分钟能完成一百次计算但你要的工具和材料都堆在几百米外的货架上每次取一趟要跑十分钟。无论你的计算能力多强真实产出都被取材料卡死了。这个仓库管理员就是CPU货架就是内存取一趟材料的时间成本就是业界常说的存储墙。三十年前CPU和内存之间的速度差距大概是一个数量级今天一次内存访问的延迟已经是寄存器访问的几十倍带宽的提升也远远赶不上算力的膨胀。更麻烦的是缓存层级缓解了一部分问题但缓存命中有概率缓存不命中就要付出数百个时钟周期的代价。对通用程序来说这个墙还能靠分支预测、乱序执行、大缓存去堵但对海量数据处理的任务来说存储墙已经从性能瓶颈升级为功耗黑洞。数据挪动的能耗比数据计算的能耗高出几个数量级这已经是行业共识。1.2 数据不是串行的但冯·诺依曼只懂串行冯·诺依曼架构的第二个硬伤是它天生为指令流驱动设计。程序要逐步执行加载A加载B相乘存回C。每一步都依赖前一步的结果本质上是一种高度串行的思维方式。这种模型处理文本、事务逻辑、传统数值计算非常好用因为那些问题本身就是一步步拆开的。但人工智能时代的数据不是这个形状。一次矩阵乘法要同时对成千上万个元素做乘加一个卷积核要在整张特征图上滑动。数据本身是高度并行的强行塞进指令流驱动的模型里要么靠多核硬堆并行度要么靠SIMD指令一条指令处理多个元素。无论哪种方式指令取指和译码的开销都会被放大大量功耗花在指挥上而不是计算上。我参与过的一个图像处理Demo项目特别能说明问题。同样的边缘检测算法在传统CPU上跑单帧要十几毫秒因为要反复读内存、写内存换到某个GPU集群方案后单帧降到不到一毫秒。差距不在算法而在于数据不再被当作一串需要挨个过CPU的流水线工件而是被直接铺开成二维矩阵让成千上万个计算单元同时上手。这个例子让我意识到冯·诺依曼已死并不是耸人听闻它其实是在说当数据并行成为主流传统架构那种一切皆串行的底层心智模式必须退休。1.3 摩尔定律放缓换CPU解决问题的路径失效了过去几十年软件遇到性能问题最简单的解法是等下一代CPU。主频提升、核心数增加、晶体管密度变大程序基本不用改换个机器就快了。这就是免费性能午餐的黄金时代。但物理规律不讲情面晶体管的尺寸逼近原子尺度频率提升撞上功耗墙单核性能增速明显放缓。现在CPU更新换代跑起老程序能有百分之十几的提升已经算不错远谈不上救火。主频这条路走不通厂商开始堆核心数、加AVX指令集、引入NPU和GPU。但一个残酷的事实摆在眼前硬件越来越异构软件跟不上。原来一个程序跑在一个统一的CPU模型上编译器把C代码翻译成指令就能跑现在你要让程序跑在多个异构计算单元上就需要拆任务、分数据、协调同步。这个复杂度传统以CPU为中心的软件栈根本没有准备好。所以冯·诺依曼已死背后还有一个含义摩尔定律的余晖靠通用处理器已经吃不到太多红利未来五到十年的性能增量主要来自专用计算单元和底层架构的创新而不是等着CPU自动变快。2. 根底座到底是什么——从芯片到生态的底层能力2.1 我的理解一个五层底座模型根底座这个词还不是教科书术语网上讨论也常常各说各话。我在一线摸爬滚打这些年逐渐形成自己的判断它不是一个单一硬件也不是一个操作系统而是一整套从硅到应用的全栈底层能力。我习惯把它拆成五层来理解这样和团队沟通时特别有效。层次承载内容典型形态第一层制造与工艺晶圆制造、封装、先进制程第二层芯片IP与微架构指令集定义、核设计、互连总线、片上存储第三层系统软件底座操作系统内核、编译工具链、运行时、驱动第四层中间件与开发框架算子库、推理引擎、分布式调度、统一编程模型第五层开发者生态文档、调试工具、社区、案例沉淀、人才池这五层每一层都不可缺失。某个做AI芯片的开发者和我聊天时说过一句话我一直记得芯片流片成功只是第一步真正难的是让生态里的开发者愿意在这上面写程序并且感觉不到痛苦。这句话把根底座落到了现实它不是一个闪光的概念而是从电路到API之间所有平凡但致命的细节集合。2.2 根为什么重要源头设计权决定生存权五层模型里最关键的是带根味道的那几层——指令集、微架构、操作系统内核。为什么说根很重要因为底层一旦定了上层软件就有粘性。举个行业里反复上演的例子。某芯片公司想从旧指令集切换到一套新指令集结果发现过去编译出来的所有二进制程序全部无法运行ISV独立软件开发商需要重新编译、重新测试、重新适配。很多老客户不愿意承担这个成本新架构推广举步维艰。反过来说牢牢掌握指令集和微架构定义权的一方可以决定软件生态往哪个方向演进今天加一个矩阵运算指令明天支持一类新的内存模型整个上层都要跟着走。这个规律在个人计算时代、移动计算时代反复出现过。谁定义了最底层的那套规则谁就掌握了生态的入口。现在AI计算扑面而来新的指令集比如RISC-V这种开源架构、新的计算范式、新的系统软件栈都在野蛮生长。每个人都有机会参与定义下一代的根但同样地选错了底层未来的生存空间就会被锁死。这就是根底座这个词里根的沉重含义。2.3 智能时代的底座在整体迁移如果只看PC时代和移动时代底座其实是相对稳定的。一个Wintel式的组合一套OS可以吃十年。但AI时代不一样模型的结构每年在变训练和推理的比例在变数据规模更是指数级膨胀。底座如果固定死了就难以适应。我观察到一个明显的趋势计算重心正在从CPU为中心转向数据为中心。以前的系统设计先选CPU然后决定内存、硬盘、网卡怎么搭配现在的系统设计先看数据规模和计算模式比如大模型训练要的并行方式、推理场景要的时延和吞吐然后倒推需要什么样的计算单元、什么样的内存层次、什么样的网络拓扑。这个倒推式的底座构建恰恰是冯·诺依曼已死之后必然出现的局面——因为你想让计算适配数据而不是让数据排队等着被CPU处理。底座迁移还体现在软件形态上。过去一个操作系统给应用提供文件、进程、网络就够了现在一个底座还要提供张量编排、内存池、梯度同步、异构调度。这些能力不再是应用层可以自己解决的问题必须下沉到系统软件和中间件层。换句话说AI时代的底座已经不是传统意义的OS而是包含OS、编译器和分布式运行时在内的一个广义系统底座。3. 构建根底座的实操路径从存算一体到全栈优化3.1 存算一体第一代拆墙尝试既然存储墙是主要矛盾最直观的解法就是把计算放进存储里减少数据搬运。这个思路在学术圈叫存内计算或存算一体。具体做法是在DRAM、SRAM、Flash甚至新型非易失存储器内部实现基本的乘加运算单元。矩阵乘法的部分结果不用搬回CPU在存储阵列内部就能算完。我接触过一个模拟项目用存算一体的思路实现了一个小规模的线性分类器。效果确实出乎意料功耗只有传统方案的四分之一因为减少了几百次内存读写。但这里面的坑也不少。数据放进去之后做高精度浮点运算非常难很多存算器件只能支持低比特的整数运算编程模型也不成熟一套新的算子映射方法要重新设计开发者学习成本高。所以业界目前的共识是存算一体适合特定形态的高能效推理但距离全面替代传统架构还有距离。即便如此这种探索非常有价值。它至少证明了一件事——继续死守CPU那套取指-译码-执行-写回的固化流程在数据密集型任务上是走不通的。很多芯片公司已经开始把这种能力打包进专用加速器让数据到哪里、算力就到哪里成为现实。3.2 异构计算与Chiplet把底座模块化另一个绕开冯·诺依曼藩篱的路径是把一个通用计算单元拆成多个专用计算单元再用先进封装把不同工艺的小芯片拼在一起。这就是现在常说的高性能异构计算和Chiplet。异构计算的思路很好理解CPU负责控制和通用逻辑GPU负责大规模并行浮点运算NPU负责神经网络算子DPU负责网络和存储卸载。每个单元都做自己最擅长的事数据在单元之间通过高速互连传输而不是所有任务都挤在CPU这条独木桥上。这种架构带来一个真正意义上的底座问题如何管理这些异构资源老一套以CPU为master、其他单元做奴隶的模式在系统规模小的时候没问题规模一大就暴露性能损耗。于是出现了统一内存模型、统一寻址空间等新技术目的就是让不同计算单元能更平等地访问数据而不是什么都得先搬回主存。Chiplet则是从硬件形态上打破摩尔定律的限制。我不需要把一个芯片做大做强我可以把CPU核、AI加速器、IO模块分别用最合适的工艺制造然后用先进封装把它们封装在一起。这样单个模块的良率更高整体性能还能超过一块大芯片。这种做法把芯片设计变成了系统集成底座的定义从一颗芯片扩展成了一个封装内的系统。对从业者来说这意味着系统软件面对的硬件多样性骤增驱动和运行时必须抽象出统一的接口层否则上层应用没法高效工作。3.3 编译器与运行时底座里最容易被低估的操作系统时刻很多人聊根底座第一反应是芯片设计但我必须说一句公道话编译器、运行时、算子库这些系统软件才是决定底座能不能被用起来的关键。芯片再强编译器生成的代码效率差性能照样稀烂算子库覆盖不全开发者只能退回去写手写汇编——那不是死路吗举一个真实的工作场景。我们在优化某跨平台系统的矩阵运算模块时第一版直接用基础编译器编译性能惨不忍睹。后来花了一周时间做三件事调整数据布局对齐向量化的宽度、选择正确的循环展开策略、给关键循环加上编译器调度提示性能提升了近六倍。整个过程中芯片算力一点没变变化的只是软件和硬件之间的翻译质量。# 一个非常粗糙的编译器调用示例实际参数要按目标架构细调 gcc -O3 -marchnative -fopenmp -ffast-math matmul.c -o matmul这一行命令背后藏着一整套问题-marchnative让编译器知道当前CPU支持哪些指令集-ffast-math是否允许重新排列浮点运算可能影响精度-fopenmp引入并行运行时。在传统环境下开发者不需要理解这些也能跑但在新底座上编译器是否支持新指令集、是否能自动做算子融合、是否能跨异构单元调度直接决定你写的Python或者C代码最终能发挥出多少硬件性能。从发展趋势看编译器正在变成通用计算图编译器前端接各种框架的模型描述中间做算子融合和内存规划后端生成针对不同计算单元的代码。这是所谓底座化改造里最精细也算最枯燥的部分但它决定了生态的开发体验。一个底座好不好用很多时候不是看芯片PPT多漂亮而是看开发者写第一行代码、跑第一次profile时顺不顺。在我看来工具链就是底座真正的开发者体验层。芯片是引擎工具链才是方向盘和仪表盘。一个没有仪表盘的引擎再快驾驶员也不敢全速前进。3.4 开发者工具链常被忽略的底座关键层聊到工具链我必须强调调试器、性能剖析器、内存检查工具这些看起来不起眼的东西是底座生态能否留住开发者的临门一脚。我见过好几个项目芯片性能数据非常亮眼但开发者一上手就崩溃没有像样的性能profiler不知道热点在哪调试器不支持多核断点并发问题根本查不了内存分配器没有适配非对称内存导致频繁访问远端内存性能直接滑坡。这些都不是核心架构问题但每一个都足以劝退一批优秀开发者。我自己挑底座时会刻意做一个周末测试选一个周末尝试在这个底座上把一个中等规模的传统程序跑起来并优化到满意的性能。如果文档清晰、工具链完备、社区能快速回答我的问题这个底座大概率值得长期投入如果连装环境都要折腾两天就算芯片跑分再高我也不敢把核心业务放上去。对做基础设施的人多一点耐心工具链的价值在长期使用中会非常突出。4. 实战中的坑与心得从传统架构迁移到新底座4.1 性能评估不能只看算力TOPS好看不等于快很多团队选型时第一眼就看算力指标比如TOPS每秒万亿次操作。这个数字确实重要但它就好比发动机排量只能说有参考意义。真实应用跑得快不快要看数据搬运、内存带宽、算子覆盖率、软件栈调度开销这些往往是选型中被低估的部分。我们迁移某图像处理Demo项目时就踩过这个坑。一个方案宣称算力是传统方案的三倍我们满怀期待地迁移结果线上实测比原方案只快了百分之三十。原因是数据量大的时候内存带宽先见顶算力利用率不到百分之二十。后来我们把图像分块、调整数据流水才把加速比拉上来。教训很朴素任何指标都要放到端到端的场景里验证不要信纸面峰值。评估维度传统CPU方案新底座方案关键提醒纸面算力低高峰值不等于有效吞吐内存带宽占用高更高数据搬运常是隐形瓶颈算子覆盖全面部分缺失算子上CPU回退会拖慢整体首次开发效率高中低工具链成熟度决定上手速度长期演进空间有限大看底座社区和路线图稳健度这张表是我的常备参考。选底座不是选最大数字而是选最匹配你业务负载的组合。4.2 数据布局是底座的隐形杀手传统CPU编程里数据结构怎么排工程师不会太纠结缓存层级会帮你兜底。可到了新底座上数据布局直接影响能不能命中带宽、能不能走向量化、能不能被近数据处理单元直接访问。举一个很常见的例子。同样一份矩阵数据行主序和列主序在不同架构上的表现可能差出几倍。很多开发者从老平台迁移过来代码没改只是换了个底座性能就崩了。原因往往不是算法变慢而是数据排布和新的内存层次不匹配导致内存访问模式从顺序变成跳跃缓存命中率骤降。我处理这类问题有一个标准方法拿到一个新底座先跑一个micro-benchmark测试顺序读、随机读、顺序写、随机写的带宽表现。然后根据结果反推业务数据应该怎么重整。看起来费时间但一次测试能省下后面几周的排查时间。还有一个细节数据对齐也很重要。很多专用计算单元要求数据按特定字节对齐不满足的话要么复制一份对齐的数据要么性能大跌。我后来养成了写数据结构时显式加对齐属性的习惯新底座适配省了不少事。4.3 生态绑定的取舍选底座就是在选长期契约每选择一个底座本质上是在签一份长期契约——你绑定了它的指令集、编程模型、工具链、升级节奏和社区走向。好处是深度适配、性能最大化风险是未来如果想换迁移成本巨大。我在多次技术选型中总结的心得是必须从三个维度来看生态绑定。第一看社区活跃度。一个底座无社区文档写得再好也危险。高速迭代时期问题能不能一两天内有人回答直接决定开发效率。第二看开放程度。包括底层接口是否公开、是否能自定义算子、是否能绕过运行时做底层优化。过于封闭的底座在初期好用但越往后越受制于人。第三看演进路线图。一个底座对未来有没有清晰规划决定你五年后还能不能站在技术前沿。我见过一个团队选了某闭源GPU生态一开始跑得好好的后来业务需要自定义算子但厂商更新慢长期等不到支持项目一度停滞。最后只能用兼容手段绕浪费了整整一个季度。所以我把逃逸成本看得和眼前性能一样重。开放底座短期可能没那么顺滑但它把选择权的根留给了你自己。4.4 常见问题速查表迁移到新底座的过程中好多问题都是反复踩坑。我整理了一份高频问题速查表给团队内部用今天一并贴出来问题现象可能原因排查思路新底座跑旧代码反而更慢未触发目标计算单元能力先用profiler看热点是否在CPU通用核上内存占用持续增长数据往返拷贝过多检查运行时是否反复搬运数据优先共享内存算子缺失触发回退中间件模块覆盖不全热点算子建议手写优化或自定义实现多设备扩展性能上不去同步开销大于计算收益调整切分比例增加计算与通信重叠同样数据两次运行结果不一致并行计算浮点累加顺序变化固定累积顺序或改用高精度累加工具链无法定位热点调试信息缺失或运行时代码未暴露确保启用了足够的符号信息和事件记录接口这份表不神秘但每一条都是真金白银的排障经验。遇到问题先对照排查至少能省掉一半的无头苍蝇式搜索。要想真正摸清底座的脾气最终还是得在一个真实业务负载上反复打磨。结尾一点个人的掏心话我在实际项目里用的是笨办法不管新底座叫什么都必须找一个小而真实的业务负载把它完整迁过去跑通、优化、上线再谈其他。踩过几次坑之后我发现所谓冯·诺依曼已死根底座才是未来其实可以用一句更朴素的话翻译未来的计算性能不靠硬件本身也不靠单点突破而是靠从晶体管到开发者工具的全栈协同深度。谁能把这条链路上的根和底座打磨得既高效又好用谁就能定义下一个十年。最后再分享一个我始终坚信的技巧在新底座上做任何性能优化都先花一天时间把数据流的全链路看一遍标出每次搬运的字节数和延迟再决定要不要动算子、动调度还是动数据布局。很多性能问题第一眼以为是芯片慢仔细一查全是数据搬运太多白白浪费了几个星期。先把数据到底怎么走的这个问题想明白比什么花哨的优化技巧都管用。善用底座的底层逻辑才能站在未来计算趋势的潮头。
