为什么AI芯片公司正在越来越像系统公司？

一颗GPU的性能，已经越来越“装不进”一颗GPU里。

如果你今天去看一家领先AI芯片公司的研发组织，会发现一个很有意思的变化。

它当然还有传统芯片公司最核心的团队：

架构、RTL、验证、后端、封装、驱动、编译器。

但在这些团队旁边，越来越重要的部门开始出现：

高速网络、

交换芯片、

集群通信、

系统软件、

服务器设计、

电源、

液冷、

机柜、

数据中心基础设施，

甚至还有专门研究“几千颗GPU怎样一起工作”的系统架构团队。

这已经和我们传统印象中的Fabless公司非常不一样了。

过去，一家芯片公司可以把自己的责任边界画在PCIe接口附近：

我的芯片符合标准，你把它插进服务器，剩下的事情由OEM和客户解决。

今天这个模式正在失效。

因为AI客户真正购买的，并不是一颗GPU。

训练客户购买的是：

多长时间能够训练完一个模型。

推理客户购买的是：

在给定延迟下，一美元能够生成多少Token。

云厂商购买的是：

一个MW电力最终能够变成多少有效AI计算。

一旦客户用这些指标衡量产品，芯片公司就会发现：

决定最终性能的很多东西，根本不在芯片里面。

于是一个非常重要的产业变化开始出现：

AI芯片公司的产品边界正在从Silicon，不断向System外扩。

这也是为什么下一代AI芯片公司，看起来会越来越像一家系统公司。

一、首先要定义：什么叫“系统公司”？

这里很容易产生一个误解。

所谓AI芯片公司变成系统公司，并不是说：

NVIDIA、AMD或者未来所有AI芯片创业公司，都必须自己生产服务器、交换机、CDU、机柜和数据中心。

如果这么理解，结论反而是错的。

真正的变化是：

芯片公司必须对芯片之外越来越多的系统性能负责。

过去可以把产品定义成：

一颗GPU。

后来变成：

一块加速卡。

再后来变成：

一个八卡服务器平台。

现在进一步变成：

一个Rack-scale计算系统。

甚至开始向：

Cluster和AI Factory扩展。

这里真正改变的不是“自己生产多少零部件”。

而是：

你必须控制哪些接口，才能保证客户最终得到预期性能。

所以所谓系统公司，更准确的定义应该是：

能够定义系统架构、控制关键接口、提供参考设计、完成跨层验证，并对最终工作负载性能负责的公司。

电源模块可以外购。

液冷CDU可以由合作伙伴提供。

服务器也可以由OEM生产。

但GPU、网络、供电、散热和软件之间如何组合，已经不能再完全交给别人决定。

二、为什么过去芯片公司可以只做芯片？

因为过去的计算系统，相对“松耦合”。

以传统服务器为例。

CPU通过标准Socket安装；

DDR通过标准内存接口连接；

网卡走PCIe；

硬盘走SAS、SATA或者NVMe；

服务器之间通过Ethernet连接。

各个组件之间拥有比较清晰的标准接口。

因此Intel、AMD可以主要负责CPU。

Broadcom可以主要负责网络芯片。

Micron、Samsung、SK hynix负责DRAM。

Dell、HPE、浪潮等OEM负责服务器整机。

数据中心运营商负责供电和制冷。

这套产业分工能够成立，有一个非常重要的前提：

不同层之间的耦合没有强到必须联合优化。

但AI把这个前提打破了。

原因是今天的AI系统拥有三个非常鲜明的特点：

第一，计算密度极高。

第二，GPU之间通信极其频繁。

第三，一个模型往往必须跨大量GPU运行。

结果就是：

GPU性能、HBM、网络、电源、散热和软件已经无法彼此独立设计。

改变其中一个变量，其他层往往必须跟着变化。

这就是所谓：

Cross-layer Co-design，跨层协同设计。

也是AI芯片公司系统化的真正技术原因。

三、第一个被拉进来的能力：网络 GPU越来越快以后，GPU之间的距离开始成为问题

假设只有一颗GPU。

网络基本不是核心问题。

但如果模型装不进一颗GPU怎么办？

两颗。

八颗。

72颗。

几百颗。

几千颗。

这时候计算问题就逐渐变成通信问题。

例如Tensor Parallel。

一层神经网络的矩阵可能被切到多个GPU上。

算完以后，不同GPU之间需要交换结果。

MoE更明显。

一个Token可能被路由到不同GPU上的Expert。

于是产生大量All-to-All通信。

训练过程中还有：

AllReduce、

AllGather、

ReduceScatter。

这些操作意味着一个事实：

GPU不是独立计算，而是在进行同步计算。

只要其中一部分GPU等待网络，昂贵的Tensor Core就会闲置。

所以网络第一次从“外围设备”进入了AI芯片的核心性能公式。

四、于是芯片公司开始自己定义Scale-up网络

NVIDIA的演进非常典型。

如果只看GPU，会误以为它卖的是越来越强的Blackwell GPU。

但看完整的NVL72系统，产品就完全不是这个逻辑了。

NVIDIA公开的GB300 NVL72参考架构中，一个机柜集成72颗Blackwell Ultra GPU和36颗Grace CPU，通过9个NVSwitch Tray形成完整NVLink域，整个系统的NVLink聚合带宽达到130TB/s。

这里真正重要的不是130TB/s这个数字。

而是：

GPU间网络已经进入GPU系统本身。

过去网络是：

服务器连服务器。

现在Scale-up网络越来越像：

大型GPU内部被“拉长”的片上互联。

只不过原来连接的是一个Die中的计算单元。

现在连接的是不同GPU。

于是芯片架构团队不得不开始理解：

拓扑、

SerDes、

Switch、

Collective Communication、

拥塞、

路由、

链路故障，

以及通信和计算如何Overlap。

这已经明显超出了传统GPU微架构的边界。

五、Scale-up之后，又出现Scale-out

Scale-up解决的是：

几十颗GPU怎样变成一个紧密计算域。

但前沿训练系统往往需要几千、几万甚至更多加速器。

所以还必须Scale-out。

这时需要的东西又增加了：

NIC、

交换机、

光模块、

InfiniBand或者Ethernet、

RDMA、

拥塞控制、

Collective Library、

拓扑调度。

一颗GPU有多快，开始只是第一层问题。

第二层问题变成：

增加一倍GPU以后，实际性能能够增加多少？

假设：

1000颗GPU获得1000单位性能。

扩展到2000颗以后只有1700。

那么Scaling Efficiency就是决定投资回报的重要变量。

这意味着AI芯片公司的竞争指标已经从：

单GPU Benchmark

逐渐变成：

Cluster Scaling Efficiency。

网络团队自然就从配套团队变成了核心产品团队。

六、第二个被拉进来的能力：软件 AI芯片越来越像一种“需要软件才能完成设计”的硬件

传统芯片设计有一个很明显的时间节点：

Tape-out。

芯片流片以后，大部分硬件能力已经固定。

但AI加速器很特殊。

同一颗芯片，最终到底能发挥多少性能，可以被软件显著改变。

例如：

一个算子调用三个Kernel还是一个Kernel？

中间结果需不需要写回HBM？

Tensor Parallel怎么切？

通信什么时候发生？

能不能和矩阵计算Overlap？

KV Cache怎么管理？

Batch怎么组？

不同请求怎么调度？

模型采用FP16、FP8还是FP4？

这些都不是简单的Driver问题。

它们会直接决定GPU利用率。

所以AI芯片公司慢慢发现：

Compiler和Runtime并不是芯片完成之后再补的软件，而是芯片架构的一部分。

七、为什么CUDA真正难复制的并不只是API？

很多讨论CUDA时，喜欢把问题简化成：

“开发者习惯”。

当然，生态惯性非常重要。

但如果只看到API兼容，仍然低估了问题。

现代AI软件栈实际上至少包含：

框架；

Compiler；

Kernel Library；

Communication Library；

Runtime；

Inference Engine；

Distributed Training；

Scheduler；

Profiling；

Debug；

Cluster Management。

而且它们越来越需要知道底层硬件拓扑。

例如：

这个模型应该切到哪几颗GPU？

这些GPU是不是位于同一个Scale-up域？

不同GPU之间的带宽是多少？

KV Cache应该放在哪里？

通信能不能提前发起？

故障以后任务怎么恢复？

所以未来AI编译器面对的已经不只是一颗芯片。

它面对的是：

一个分布式异构计算系统。

这也是为什么软件能力越来越难作为硬件团队的“附属品”。

它正在进入产品核心。

八、AMD的Helios为什么值得观察？

AMD Helios体现的是另一种系统化路径。

AMD在2026年发布的Helios rack-scale方案，把Instinct MI455X GPU、EPYC CPU、Pensando网络以及ROCm软件放入统一的Rack架构，并直接把它定义为面向训练和大规模推理的完整计算、网络与开放软件基础。

这并不意味着AMD必须自己生产Helios所有部件。

实际上它更接近一种：

Rack-scale Reference Architecture。

AMD公开信息显示，Helios参考设计向合作伙伴开放，并计划在2026年下半年进入规模部署。

这恰好说明：

成为系统公司，并不一定意味着垂直制造。

也可以采用：

GPU自己定义；

CPU自己定义；

网络自己定义；

软件自己定义；

Rack架构自己定义；

然后让OEM、ODM和供应商共同制造。

这里控制的不是全部产能。

而是：

系统架构。

九、第三个被拉进来的能力：电源

这可能是AI芯片产业最反直觉的一次扩张。

一家做GPU的公司，为什么最后需要研究数据中心怎么送电？

答案仍然是：

因为芯片功耗已经高到电源架构会反过来限制计算架构。

NVIDIA目前公开的GB300 NVL72参考系统，整Rack最大功率需求可达到约142kW，并配置8个33kW Power Shelf。

100kW以上的Rack意味着什么？

意味着你不能再把供电视作数据中心建设完成之后的配套工作。

因为：

线缆有电流上限；

铜有成本；

Power Shelf占机柜空间；

转换过程存在损耗；

瞬时负载变化会影响供电稳定；

备用电源也必须重新设计。

于是计算密度进一步增加以后，电源系统本身需要改变。

十、为什么行业开始讨论800V DC？

2026年，Google、Microsoft和NVIDIA开始通过OCP推动下一代AI数据中心800V DC供电架构标准化。

OCP给出的核心理由之一非常直接：

随着AI Rack功率不断提高，使用更高电压输送同样功率，可以降低电流，从而减少导体和铜材需求，并支持更高密度系统。

这件事情意义非常大。

因为它说明：

芯片公司的产品定义已经开始触碰数据中心配电架构。

过去产品会议可能讨论：

Tensor Core数量。

现在可能还要讨论：

Rack功率是多少？

输入电压是多少？

电源转换放在哪里？

Rack内部使用什么Busbar？

Power Shelf占多少空间？

GPU负载快速变化时，电网侧看到什么？

这已经不是传统意义上的芯片设计。

这是计算架构、电气工程和数据中心基础设施共同设计。

十一、第四个被拉进来的能力：液冷

为什么液冷正在成为AI系统架构的一部分？

因为任何芯片最终都必须满足最简单的一条物理定律：

输入多少电，最终基本就要排出多少热。

如果一个Rack消耗100kW电力，那么最终就必须处理接近这个量级的热负荷。

空气并不是一种特别优秀的高密度热传递介质。

因此随着GPU功率和Rack密度持续增加，液冷逐渐从“高端可选项”变成高密度AI系统的重要设计变量。

NVIDIA的GB300 NVL72本身就是液冷Rack，并且参考设计已经包括Rack级和Tray级漏液检测。

注意这一点。

一家GPU公司的官方计算系统文档，现在已经需要定义：

液冷、

Manifold、

Leak Detection。

这个变化本身已经说明产业边界发生了什么。

十二、液冷也不是“装一根水管”那么简单

把冷却液送到GPU附近只是第一步。

真正工程化以后会出现：

Cold Plate怎么设计？

流量多少？

压降多少？

进水温度多少？

Quick Disconnect使用什么规格？

不同材料是否腐蚀？

液体泄漏怎么检测？

CDU怎么冗余？

一台设备维修时能不能不停止整个Rack？

不同供应商的冷板和Manifold能不能互换？

OCP的AI系统白皮书已经把Cold Plate、Rack Manifold、快速接头、CDU测试方法、冷却液规范和漏液检测等都列入开放系统需要解决的问题。

所以“上液冷”并不是把风扇换成水。

本质上是增加了一整套：

新的机械系统、新的可靠性问题和新的供应链。

而且冷却能力一旦不足，会直接导致：

GPU降频。

于是热设计最终又回到了计算性能。

这就是AI系统典型的跨层闭环：

GPU功耗上升
↓
热密度上升
↓
液冷架构改变
↓
Rack结构改变
↓
供电和网络布局改变
↓
最后又反过来影响GPU能够运行在什么功率。

所以液冷并不是芯片之外的东西。

它已经成为芯片可持续性能的一部分。

十三、第五个变化：系统验证开始比“芯片点亮”困难得多

传统芯片公司有一个非常重要的里程碑：

First Silicon成功。

芯片点亮。

Benchmark跑通。

产品基本进入最后阶段。

但Rack-scale AI系统完全不是如此。

72颗GPU同时工作以后，需要验证的东西可能包括：

GPU；

CPU；

HBM；

NVLink；

PCIe；

NIC；

Switch；

光模块；

Power Shelf；

BMC；

Firmware；

CDU；

漏液检测；

Compiler；

Runtime；

Collective；

Scheduler。

其中任何一个环节异常，都可能让客户看到：

GPU利用率下降。

更麻烦的是，有些问题只有在大规模部署以后才出现。

例如：

100块GPU运行正常。

10000块以后，某种极低概率故障每天都会发生。

单机网络没有问题。

几千节点以后出现拥塞。

单Rack供电稳定。

大量Rack同时进行AI训练以后出现高同步性负载变化。

于是AI系统出现一个非常重要的工程变化：

规模本身开始产生新的故障模式。

这意味着芯片公司的验证团队，也必须从：

Silicon Validation

走向：

System Validation，

甚至：

Cluster Validation。

十四、为什么RAS突然变得这么重要？

RAS就是：

Reliability、Availability、Serviceability。

可靠性、可用性和可维护性。

如果只有8颗GPU，一颗坏掉只是一个局部事件。

如果系统拥有10万颗GPU，即使单颗设备的故障率非常低，整个集群也可能持续有设备处于异常状态。

因此系统真正的问题不再是：

“会不会坏？”

而是：

“坏了以后整个计算任务还跑不跑？”

这会进一步要求：

错误检测；

链路隔离；

GPU健康监测；

自动重试；

Checkpoint；

任务迁移；

Failover；

预测性维护。

所以未来评价AI芯片时，一个很容易被忽略的指标是：

不是芯片能不能跑Benchmark，而是集群一年里有多少时间真正处于有效计算状态。

利用率从90%提高到95%，在一个几十亿美元规模的数据中心里，可能意味着非常巨大的经济价值。

这也是系统公司必须承担的责任。

十五、组织结构于是被迫改变

把前面几个变化放在一起，就会看到一个更深的结果：

AI正在改变芯片公司的组织结构。

过去一家典型Fabless AI芯片公司的核心组织可能是：

架构；

RTL；

Verification；

Physical Design；

DFT；

Firmware；

Driver；

Compiler。

未来则可能需要扩展成：

Silicon

芯片架构
RTL
验证
Physical Design
SerDes
HBM
先进封装

System

Board
Server
Rack
SI/PI
Power
Thermal
Liquid Cooling

Network

NIC
Switch
Scale-up
Scale-out
Collective Communication

Software

Compiler
Kernel
Runtime
Inference Engine
Distributed Training
Scheduler

Infrastructure

Cluster Management
Telemetry
RAS
Deployment
Validation

这已经不再像传统Fabless公司。

它越来越像：

计算系统公司。

十六、但这里有一个巨大的代价：组织复杂度爆炸

系统化听上去很好。

现实却非常残酷。

因为每增加一层产品边界，都会增加新的组织接口。

芯片团队需要和封装团队协同；

封装需要和Board团队协同；

Board需要和电源团队协同；

电源需要和液冷团队协同；

网络团队需要和Runtime协同；

Runtime需要理解模型；

模型团队又会反过来要求硬件增加新的功能。

这会造成一个AI系统最常见的工程问题：

每个局部团队都做对了，但整个系统仍然做错了。

例如：

芯片团队把GPU TDP提高20%，获得更高算力。

但Rack电力已经到上限。

于是只能减少每Rack GPU数量。

GPU数量减少以后，Scale-up拓扑改变。

拓扑变化以后模型并行效率下降。

结果：

单GPU性能提高了，

系统性能却未必提高。

这就是为什么AI系统产品定义越来越难。

局部最优，不等于全局最优。

十七、真正稀缺的能力开始变成“复杂工程组织能力”

这可能是AI芯片行业接下来最容易被低估的一项竞争力。

一家企业可以招到优秀GPU架构师。

也可以买到高速SerDes IP。

可以找到服务器ODM。

可以买交换芯片。

可以买液冷设备。

但最困难的问题是：

谁来决定整个系统应该是什么？

模型需要什么？

GPU应该提供什么？

HBM应该配多少？

Scale-up域多大？

网络带宽多少？

Rack功率是多少？

液冷能力多少？

Compiler如何利用硬件？

客户机房能不能部署？

这些决策必须在产品定义早期彼此协调。

等GPU Tape-out以后再发现：

网络不够、

HBM不够、

供电不够、

散热不够，

很多问题已经无法补救。

所以未来大型AI芯片项目真正重要的角色之一，很可能并不只是Chief Chip Architect。

而是：

Chief System Architect。

他的工作不是把某一层做到极致。

而是：

在几十个约束之间找到全局可制造、可部署、可维护、可盈利的平衡点。

十八、这也是为什么芯片创业公司会越来越难

对于创业公司而言，这是一个非常不友好的趋势。

过去设计一颗芯片已经非常昂贵。

现在即使成功流片，还只是开始。

你还需要解决：

板卡；

服务器；

网络；

软件；

机柜；

供电；

散热；

集群验证。

而且这些投入不是简单相加。

它们之间是相互依赖的。

例如你的软件生态不成熟，客户就不愿意部署大量芯片。

客户不愿意规模部署，就无法发现Cluster级问题。

没有规模数据，又很难改善软件和可靠性。

这就是为什么AI芯片正在形成一个越来越强的：

系统生态飞轮。

硬件越多
→ 软件优化机会越多

软件越好
→ 客户部署越多

部署越多
→ 系统问题暴露越充分

系统越成熟
→ 客户更敢扩大部署

最终竞争就不再只是：

谁先Tape-out。

而是：

谁先完成从Silicon到Cluster的工程闭环。

十九、但这并不意味着“小公司没有机会”

系统化还有另外一面。

并不是每家公司都必须和NVIDIA一样覆盖整个技术栈。

真正需要回答的问题应该是：

你的产品边界应该画在哪里？

一种公司可能做到Chip。

然后依赖成熟标准和OEM生态。

另一种做到Board。

再一种提供Server Reference Design。

还有公司直接提供Rack-scale系统。

也可能有公司专门针对某一种推理工作负载设计完整Appliance。

真正危险的不是产品边界小。

而是：

你的关键性能依赖于产品边界之外的东西，却没有能力控制它。

比如一颗GPU严重依赖某种特殊Scale-up网络。

那么网络就不能只是客户的问题。

如果性能高度依赖Compiler。

Compiler就不能是第三方适配问题。

如果芯片功率密度必须依赖液冷才能达到标称性能。

那么液冷系统就已经进入产品定义。

所以系统公司的核心原则不是：

什么都自己做。

而是：

把决定最终性能的关键变量纳入可控范围。

二十、系统化还有一个经常被忽略的商业意义

当芯片公司向系统扩展以后，它销售的价值单位也发生了变化。

卖GPU时，很容易比较：

每颗GPU多少钱。

卖Rack以后，可以比较：

每Rack性能。

到了Cluster，则可以比较：

训练时间；

Token吞吐；

Performance per Watt；

Cost per Token。

这实际上改变了竞争维度。

假设A芯片单颗性能比B芯片高20%。

但B系统拥有：

更大的HBM；

更好的互联；

更成熟的软件；

更高的利用率；

更低的故障时间。

最终客户的Cost per Token完全可能出现不同结果。

所以系统化还有一个重要作用：

把竞争从容易比较的芯片参数，移动到更接近客户业务价值的系统指标。

这也是为什么今天越来越多厂商开始讨论：

AI Factory、

Rack-scale Computing、

Tokens per Watt、

Tokens per Dollar。

这不只是营销语言变化。

它反映了真正的产品边界变化。

二十一、NVIDIA和AMD正在展示两种不同的“系统公司”路径

NVIDIA呈现的是一种比较强的纵向整合路线：

GPU；

CPU；

NVLink；

NVSwitch；

ConnectX；

BlueField；

Spectrum-X；

CUDA；

Rack架构，

逐渐形成一套高度协同的计算系统。

AMD则正在尝试另一种模式：

GPU；

EPYC CPU；

Pensando网络；

ROCm，

再结合UALink、Ethernet、OCP以及OEM/ODM合作伙伴形成开放Rack-scale系统。

AMD与Meta在2026年公布的合作甚至明确把联合工程范围描述为Compute、Memory、Networking、Power、Cooling和Software。

值得关注的并不是简单判断哪条路线一定更好。

真正的问题是：

强垂直整合

优势可能是：

跨层优化更彻底；

系统验证边界清晰；

性能更容易形成确定性。

代价可能是：

客户锁定更强；

生态体系更封闭；

供应商替换难度更高。

开放模块化

优势可能是：

供应链灵活；

OEM参与度高；

客户拥有更多选择。

代价可能是：

接口协调更困难；

跨供应商验证成本更高；

局部优化更难形成完整系统收益。

未来AI基础设施很可能长期存在这两种模式之间的拉扯。

二十二、未来判断一家AI芯片公司，应该换一套问题

过去我们习惯问：

什么制程？

多少晶体管？

多少TFLOPS？

HBM多大？

这些问题仍然重要。

但已经不够。

下一代可能更应该问：

第一，它的Scale-up方案是什么？

几十颗GPU如何通信？

第二，它的软件能不能真正把硬件跑满？

不仅仅是能不能运行PyTorch。

而是Kernel、Compiler、Runtime和Collective是否成熟。

第三，它能不能做Rack-scale验证？

不是八卡机器跑通。

而是72卡、几百卡、几千卡以后还能不能稳定运行。

第四，它有没有电源和散热边界意识？

标称性能到底需要什么供电和液冷条件？

第五，它的RAS做到了什么程度？

发生故障以后是整份Job重启，还是能够隔离和恢复？

第六，它有没有成熟供应链？

GPU有货但HBM没有。

HBM有货但先进封装不足。

Rack有了但CDU部署跟不上。

最终都等于没有系统。

第七，也是最重要的：

客户购买的到底是一颗芯片，还是一种确定的计算产能？

如果答案逐渐变成后者，那么系统能力的重要性只会继续提高。

结语：一颗GPU的性能，正在越来越“装不进”一颗GPU里

AI芯片公司为什么正在越来越像系统公司？

因为决定GPU价值的东西，正在不断离开GPU本身。

计算单元太快以后，

瓶颈来到HBM。

HBM解决以后，

瓶颈来到GPU之间的互联。

互联扩大以后，

问题来到网络。

GPU数量增加以后，

功耗来到100kW级Rack。

功耗提高以后，

电源和液冷成为架构问题。

系统扩大以后，

故障和软件调度成为新的瓶颈。

最终你会发现：

所谓AI芯片性能，其实是几十个工程层共同产生的结果。

所以未来真正强大的AI芯片公司，未必是所有环节都自己制造的公司。

但它一定越来越需要具备一种能力：

从模型一路看到电力。

理解模型需要什么；

理解软件怎样映射模型；

理解芯片怎样执行软件；

理解HBM怎样供应数据；

理解网络怎样连接芯片；

理解电源怎样支撑机柜；

理解液冷怎样带走热量；

最终理解整个系统怎样变成客户真正能够购买的计算产能。

过去芯片公司的核心问题是：

“怎样设计一颗更好的芯片？”

AI时代，这个问题正在被重新定义成：

“怎样设计一台由成千上万颗芯片共同组成的计算机？”

这才是AI芯片公司越来越像系统公司的根本原因。

不是因为芯片不再重要。

恰恰是因为芯片太重要、太昂贵、功耗太高，

以至于已经不能再脱离整个系统单独设计。

下一代AI计算真正的竞争单位，

正在从Chip，

走向Board，

走向Server，

走向Rack，

最终走向整个Cluster。

而当这一步发生之后，

芯片公司与系统公司的边界，也会越来越模糊。