英伟达为什么推Rubin NVL144 CPX?为什么我不太看好它?

英伟达为什么推Rubin NVL144 CPX?为什么我不太看好它?


英伟达又发了一个期货:号称专门针对长上下文(百万tokens)推理的Rubin CPX芯片,以及加入该芯片的Rubin NVL144 CPX。

TL;DR:我不看好这样的产品,理由如下:

  1. 这种配置很鸡肋,用户的使用场景是多样的。即使这样的配置专攻AI搜索、代码生成、视频图像处理等长上下文场景,那么我们也很容易得出这样的结论:即使Rubin和Rubin CPX的配比是4:8,实际算力是1:1,HBM还是有非常多的时间在休息。推理服务厂商为什么不直接使用非HBM算力?省钱,功耗低,散热好解决,维修还方便;
  2. 如果依然还是把各种用户场景融合在一起,那么对话的绝对请求量还是大的,GDDR7相对的低带宽又可能拖慢整个系统的响应时间;
  3. 当然,这套系统可能在机房容量受限的背景下有一定的存在合理性,毕竟算力密度是大幅提升的,推理服务提供商其实也可以在后期进行更复杂的调度,甚至把两类芯片分开用,但是,问题就又回到散热和CPU瓶颈上了;更何况,推理服务提供商(模型公司)做的优化越多,越意味着硬件层面英伟达的不可替代性就在降低。

以下是全文。

下图为Rubin CPX芯片,使用128GB GDDR7显存。

下图为Rubin NVL144 CPX:一个机架18个Tray,一个Tray有四颗Rubin GPU,再加八颗Rubin CPX。

Rubin NVL144 CPX

所以会有一堆新的天花板指标:8 exaflops (NVFP4),100TB内存 (HBM+GDDR7),号称性能是GB300 NVL72的7.5倍。

反正英伟达又赢了:“每1亿美金投资,可以有50亿美金回报。”

Investment Return

https://nvidianews.nvidia.com/news/nvidia-unveils-rubin-cpx-a-new-class-of-gpu-designed-for-massive-context-inference

这句话堂而皇之的在它的新闻稿里出现,而且是没有加注释条件的,我已经截屏了,不知道是不是有一天可以“集体诉讼”。我对英伟达的能力和地位从没有任何怀疑过,但是我对这种近似于“不负责任”的“虚假宣传”越来越反感。至今为止,按照英伟达刚在MLPerf 5.1和自己官网中公布的数据,即使GB300 NVL72,推理Deepseek R1,相比于Hopper架构,单GPU性能的提升也只有5.2倍,请勇敢地把产品发布时宣传的30x性能提升展示出来。

Performance Data

https://developer.nvidia.com/blog/nvidia-blackwell-ultra-sets-new-inference-records-in-mlperf-debut/

GB200 Specs

https://www.nvidia.com/en-sg/data-center/gb200-nvl72/

更何况,这还是一个期货,预计交货时间是26年底,那就再往后至少加半年吧。

以上纯情绪性“不看好”,下面简单讨论技术层面问题:为什么要推这个产品?

最主要原因当然是应对潜在的竞争压力,AMD已经发布了NVL的竞品,基于MI400的Rack:Helios。有更强的CPU,可以提供更好的推理性价比。虽然AMD产品节奏比英伟达要延迟至少半代时间,但其实社区里对这款产品还是很看好的,加上对标CUDA的生态ROCm成熟了不少,竞品对英伟达构成的压力是不小的。当然,还有被Google的TPU带火的XPU。

AMD Helios

https://www.amd.com/en/blogs/2025/amd-delivering-open-rack-scale-ai-infrastructure-to-unlock-agentic-ai.html

竞争压力之外,确实在实际应用中,面向长上下文的推理场景增长太快了。去年开始的token调用量快速提升,主要贡献者就是长上下文场景(搜索,代码生成,以及接下来的图片视频生成)。长上下文场景跟传统的AI对话式场景区别其实很大。

我们知道,一次推理分为两个阶段:prefill(预填充)和decode(生成)。蓝色部分就是prefill,即将用户输入(上下文填充到模型中),绿色部分是生成,即“猜下一词”。

Prefill vs Decode

两个阶段对硬件性能的要求不太一样,简单解释就是:prefill更多需要算力,decode更多需要内存带宽,而KV-Cache(注意力缓存,是提高性能的一个关键架构,通常需要容量更大)。

Hardware Requirements

所以,当输入的上下文越长,对prefill的需求就越大,也就是对芯片的计算能力要求就越高,但是对内存带宽要求就相对较小。当应用场景更多是AI对话时,这个区别不太明显。例如DeepSeek在知乎上关于R1模型优化的文章披露:全天输入token(上下文prefill)是680B tokens,输出(decode)为168B tokens。我们可以认为在AI对话场景下,输入和输出的比例是3-4:1,硬件优化的空间不大。

但是,当进入到搜索和代码生成阶段,有了Agent的加入,情况就发生了非常大的区别。比例发生了巨大变化。

如下图所示,当更多是搜索任务时,输入token可以是输出token的几百倍。

Search Task Ratio

在代码生成类的任务中,输入token和输出的比例也可以达到100:1。

Code Generation Ratio

另一方面,因为长上下文需要更长的prefill时间(其实是二次方增长的,但因为长上下文是基于让模型分段处理实现的,所以时间消耗接近线性增长)。这意味着在prefill过程中,显存(HBM)的高带宽实际上是不工作的,或者负载很小。站在硬件折旧角度考虑,HBM的高带宽在长上下文场景(输入是输出百倍以上)下,至少有超过一半的时间是浪费的,不经济的。

好了,这就是英伟达对市场高度敏感的表现:配上一个算力一样,但是显存便宜得多的芯片,专攻prefill。

这就是这款芯片和硬件架构存在的价值,也是英伟达官网下面这张图要表示的含义。

Rubin Value Proposition

但我依然不看好这样的产品,理由如文初所述:这种配置在实际多样化的用户场景中显得尴尬,且模型公司的软件优化正在降低英伟达硬件的不可替代性。英伟达的核心竞争力在于其激进的迭代速度,但在当下,物理限制依然存在。

← Back to Blog