当前位置: 首页 > news >正文

架构深解:英伟达Rubin CPX如何通过专用预填充加速器与解耦架构重塑AI推理效率与成本

英伟达最新发布的Rubin CPX专用加速器,通过专注于预填充阶段计算优化实现了推理领域的突破性创新,其重要性仅次于2024年3月发布的GB200 NVL72 Oberon机架级形态产品。只有通过为推理中截然不同的两个阶段——预填充和解码(decode)——配备专用硬件,解耦式服务(disaggregated serving)才能充分发挥其潜力。

这一举措使其在机架系统设计上进一步扩大了与AMD等竞争对手的差距,迫使后者不得不重新规划产品路线并追加投入以开发同类预填充芯片,重现了当年Oberon架构发布后的行业格局重塑。

Rubin CPX

由于推理过程中的预填充阶段往往 heavily 利用计算(FLOPS)而 lightly 使用内存带宽,在配备大量昂贵且具有极高内存带宽的HBM的芯片上运行预填充是一种浪费。解决方案是一款内存带宽相对“瘦”(skinny)而计算相对“胖”(fat)的芯片。于是,Rubin CPX GPU应运而生。
在这里插入图片描述
Rubin CPX具备20 PFLOPS的FP4稠密计算能力,但内存带宽仅为2TB/s。它还配备了128GB的GDDR7内存,与VR200相比,其内存容量更低且成本更低。作为对比,双芯片的R200提供33.3 PFLOPS的FP4稠密计算能力和288GB的HBM,内存带宽高达20.5 TB/s。
在这里插入图片描述
Rubin CPX的引入将VR200系列机架级服务器扩展为三种配置:
**VR200 NVL144:**包含72个GPU封装(packages),分布在18个计算托盘(compute tray)中,每个计算托盘包含4个R200 GPU封装。
**VR200 NVL144 CPX:**除了72个(逻辑)GPU封装外,还包含144个Rubin CPX GPU封装,分布在18个计算托盘(compute tray)中,每个计算托盘包含4个R200 GPU封装和8个Rubin CPX GPU封装。
**Vera Rubin CPX 双机架:**两个独立的机架——一个VR200 NVL144机架加上一个VR CPX机架;VR CPX机架包含144个Rubin CPX GPU,分布在18个计算托盘(compute tray)中,每个计算托盘包含8个Rubin CPX GPU。
在这里插入图片描述

在下面的内容中,我们将首先解释背景和推动Rubin CPX开发的动因,即内存在推理的预填充和解码阶段所扮演的不同角色。然后,我们将深入探讨Rubin CPX芯片的架构以及部署它的机架级解决方案。接着,我们将焦点从过去和现在转向未来,探讨解耦式推理服务的未来前景,以及今日的公告如何影响其他商用加速器提供商和定制芯片项目的未来路线图与竞争力。

内存:背景与现状

内存墙(Memory wall)一直是AI最重要的制约因素。更大的内存容量对于将更大模型加载到加速器中是必需的,而内存带宽一直是推理和训练令牌吞吐量(token throughput)的主要瓶颈。这就是为什么每GPU的高带宽内存(HBM)容量和带宽迅速增加——从H100的80GB和3.4TB/s到GB300的288GB和8.0TB/s,在不到三年的时间内,内存容量增加了两倍多,带宽增加了约2.5倍。

因此,从Hopper到Blackwell,HBM占加速器BOM的成本比例持续上升,如今HBM已成为GB300封装BOM中最大的单一组件。HBM对于训练和推理都极具价值,但当我们把推理分解为预填充和解码两个组成部分时,HBM的高价值主要体现在解码阶段。在计算密集的预填充阶段,由于预填充的并行性质,生成KVCache(键值缓存)对带宽的需求要低得多,因此HBM在此阶段未被充分利用。
在这里插入图片描述

HBM因其额外的带宽而相对于其他形式的DRAM携带了昂贵的溢价,当这部分带宽未被充分利用时,这些HBM就被“浪费”了。HBM在BOM中所占比例的不断攀升构成了另一堵“墙”,这也是推动Rubin CPX GPU开发的动因。

带宽与计算差异

每个Rubin CPX芯片将是一个采用传统倒装芯片BGA封装的单片SoC(系统级芯片)。Rubin CPX将使用128GB的GDDR7 DRAM,而非HBM。从使用HBM转向更便宜的GDDR7内存,使得每GB成本降低了50%以上。

内存速度可能为32Gbps,总线宽度为512位。这使得每个Rubin CPX的内存带宽达到2TB/s,而每个R200的内存带宽为20.5TB/s。值得注意的是,通过此次主题演讲,英伟达也确认了常规Rubin(指R200)的带宽将显著升级。正如我们之前在加速器和HBM模型中所讨论的,R200的HBM4速度已显著提升至10Gbps,以实现每个R200 20.5TB/s的内存带宽。相比之下,R200最初发布时的规格“仅”为13TB/s内存带宽(基于6.4Gbps速度档位)。我们也在模型中讨论并量化了这对HBM供应商的影响。144个各提供2.0 TB/s内存带宽的CPX芯片与72个各提供20.5TB/s内存带宽的R200芯片相结合,将提供总计1.7PB/s的系统内存带宽。

计算方面,每个CPX提供30 PFLOPS的稀疏FP4计算吞吐量(20 PFLOPS稠密),而R200为50 PFLOPS稀疏FP4(33.3 PFLOPS稠密)。Rubin CPX的稠密PFLOPS与稀疏PFLOPS之比遵循与R200相同的3:2比例,因为它继承了与Rubin R200相似的张量核心架构。相对于双芯片的R200,CPX为单计算芯片提供了非常强大的FP4计算吞吐量。其性能提升可能源于减少了高精度计算单元以拥有更多的FP4 ALU(算术逻辑单元)。这正是B300所采用的方法,以便在相同的4NP制程节点上获得比B200更高的FP4吞吐量。

然而,与往常一样,峰值理论FLOPs在实践中极难达到。与英伟达其他受功耗限制的GPU一样,鉴于我们估计其额定功耗仅约800W,Rubin CPX很难持续维持接近峰值的FLOPs:我们认为其功率密度突破1W/mm²是不可行的,尤其是在其电路板采用夹层形式集成的情况下。

另一个不同之处在于网络。Rubin CPX没有用于纵向扩展(scale-up)的NVLink SerDes(串行器/解串器),而是依靠PCIe Gen 6通过横向扩展(scale-out)网络上的CX-9 NIC(网卡)与其他GPU通信。这种降低的网络能力通过实施流水线并行(pipeline parallelism)是完全可行的。
在这里插入图片描述

由于总硅含量更低且内存更便宜,Rubin CPX的生产成本远低于R200。降低总内存容量并使用成本更低的GDDR7意味着内存成本降低了5倍。芯片架构也简单得多,因为避免了HBM且只有一个光罩尺寸(reticle-sized)的芯片而没有I/O小芯片(chiplets),这意味着不需要CoWoS封装。打个比方,Rubin CPX的设计类似于下一代RTX 5090或RTX PRO 6000 Blackwell(基于消费级Blackwell GPU芯片),因为它们都使用大型单片芯片和512位宽的GDDR7内存接口。但这些(消费级)芯片的FLOPS仅为其配备HBM的“大哥”B200的20%。而对于Rubin CPX,这一比例跃升至60%,因为它将是一个更接近R200计算芯片的独立流片(tapeout)。作为实现每单位成本最大FLOPS的实践——Rubin CPX是无与伦比的。

英伟达Oberon机架架构升级:VR NVL144 CPX、VR NVL144、VR CPX

去年三月,在GTC 2024上,英伟达展示了其第一代Oberon架构:GB200 NVL72。一年半后的今天,第二代Oberon架构GB300 NVL72即将大规模量产出货。这两代之间的设计变更和升级非常少。而第三代Oberon架构,Vera Rubin (VR),则是Ian今日在AI Infra Summit上演讲的重点。VR将于2026年推出(距Oberon机架级形态首次亮相不到三年),其设计相较GB200/GB300将有重大变更和升级。

Vera Rubin Oberon将Oberon架构的功率密度推向了极限,这需要对供电内容进行重大升级并对冷却解决方案进行设计更改。选择无线缆设计是为了克服GB200/300组装中飞线(flyover cable)布线的困难以及托盘内电缆带来的可靠性挑战。连接OSFP笼子与ConnectX NIC的电缆已被移除。连接PCIe到前端Bluefield DPU以及本地NVMe存储的电缆,以及其他边带(side band)电缆也都被移除。

Vera Rubin的主要变更和升级集中于以下三种Vera Rubin (VR) 计算托盘型号的革新:
● VR NVL144 (仅含Rubin)
● VR NVL144 CPX (仅含Rubin CPX)
● VR NVL144 + VR CPX (双机架,Rubin + Rubin CPX 位于同一托盘)
在这里插入图片描述

首先介绍的是VR NVL144 CPX机架。它与VR NVL144相似,不同之处在于,对于VR NVL144 CPX,在18个计算托盘中的每一个里面,除了4个R200 GPU和2个Vera CPU外,现在还增加了8个Rubin CPX GPU。

VR NVL144 CPX机架也将采用液冷——但其功率预算要高得多,约为370kW,而VR NVL144约为190kW。
在这里插入图片描述

另一种部署选项是Vera Rubin CPX双机架。顾名思义,该解决方案允许已经部署了VR NVL144机架的客户随后在其数据中心添加VR CPX机架,从而实现专用于解耦式PD推理的硬件。VR CPX不通过NVLink连接,因此VR CPX机架不包含NVSwitch托盘。VR CPX机架通过横向扩展的InfiniBand或以太网络连接到集群,并且可以随后在方便的物理位置添加到集群中——它不必物理上紧邻VR NVL144机架。

与VR NVL144 CPX单机架相比,双机架解决方案提供了更大的灵活性,因为客户可以根据喜好设计预填充与解码的比例。此外,并非所有人的数据中心基础设施都能立即支持约370kW的VR NVL144 CPX。另外,与单机架变体相比,(故障的)爆炸半径更小。
在这里插入图片描述

在下表中,我们可以看到单个计算托盘内集成了多少计算和网络内容——每个计算托盘总计22个英伟达芯片(其中14个是XPU),或者说每个VR NVL144 CPX机架有396个芯片。为了将所有这些内容塞进一个计算托盘,英伟达转向了无线缆的模块化设计,并重新设计了托盘内部的冷却回路。
在这里插入图片描述

NVL144 CPX将在计算托盘机箱的后半部分保持与GB200/GB300类似的计算板设置。显著区别是采用了可插拔的SOCAMM DRAM模块,而不是焊接的LPDDR5X内存来运行CPU。VR NVL144 CPX与GB200/GB300的大部分区别在于机箱前半部分,即主机处理器主板(‘HPM’)计算板(在Blackwell一代中也称为“Bianca”板)下方。

在前部,VR NVL144 CPX设计是模块化的,由7个子卡模块组成。

● 四个子卡模块放置在机箱两侧。每侧有两个子卡上下堆叠。这四个子卡每个包含两个800G CX-9 NIC、一个1.6T OSFP笼子、一个E1.S SSD NVMe模块和两个Rubin CPX。
● 一个子卡位于机箱中部(下图下部中心),容纳Bluefield-4模块,该模块包含一个Grace CPU和一个CX-9 NIC。
● 堆叠在此Bluefield-4模块之上的一个子卡容纳供电板(PDB)。PDB负责将从后方母线连接器进入机箱的48-54V电压降至12-13.5V。
● 最后一个子卡小得多,位于Bluefield-4模块右侧。它更薄,包含公用事业管理模块,内有BMC、HMC、DC-SCM和管理I/O等组件。
在这里插入图片描述
在这里插入图片描述

我们估计Rubin CPX芯片的TDP约为800W,但考虑到包含GDDR7内存的整个模块,总功耗会升至880W。为了冷却计算托盘前部总计7,040W的Rubin CPX模块,机箱前部的冷却必须从风冷升级为液冷。

为实现这一点,英伟达重新采用了其2009年GTX 295的设计。Rubin CPX和CX9子卡采用夹层设计,中间共享一个液冷冷板。在PCB的外侧,热管和均热板将热量从每个夹壳式GDDR7内存模块的背面传递到主冷板。通过充分利用1U托盘高度并使用冷板的两面,将容纳这些GPU所需的计算托盘面积减半,实现了最大密度。
在这里插入图片描述

VR NVL144 CPX的另一个关键设计变更是采用无线缆设计。正如我们在关于PCB超级周期和Amphenol AI内容的核心研究报告中讨论过的,采用此设计有两个原因。首先,飞线存在多个潜在的故障点,因为它们在组装过程中很容易损坏。其次,VR NVL144 CPX的高密度设计没有为电缆布线留下空间。

那么没有电缆信号如何路由?答案很简单:来自HPM(Bianca)板的信号通过Amphenol的Paladin板对板连接器离开电路板。这在我们最近关于Amphenol AI内容的文章中有更详细的讨论。然后信号通过位于机箱中间的PCB中板(midplane)进行路由。在PCB中板的另一侧,子卡通过另一组Paladin B2B连接器连接到PCB中板。
在这里插入图片描述

为适应这种无线缆设计,HPM(Bianca)板上部的CX-9 NIC从机箱的后半部分移到了前半部分,如下图所示。对于GB200/GB300,GPU/CPU与CX-7/8之间的PCIe信号距离短于CX-7/8与OSFP笼子之间的以太网/InfiniBand信号距离。

以前——必须将200G以太网/InfiniBand信号从计算托盘后半部分的NIC传输到计算托盘前部的OSFP笼子,这需要使用飞线,因为在PCB上以每通道200Gbit/s(单向)传输的信号损耗太高。

但现在NIC更靠近OSFP笼子,较低速的每通道PCIe Gen6信号(每通道64Gbit/s单向)传输更长的距离,并且这种连接现在可以通过PCB路由。尽管在PCB上驱动PCIe Gen6信号仍然具有挑战性,但通过升级PCB材料仍可以实现良好的信号完整性。
在这里插入图片描述

为了更好的可维护性,子卡也被设计成模块。每个子卡模块可以滑入和滑出子卡模块托架。计算托盘内部设计了用于此目的的内部导轨套件。

下面我们展示了信号在不同Vera Rubin计算托盘型号内的路由方式,以及VR Rubin型号的计算托盘拓扑。这些图表的一个重点是CX-9在实现Rubin CPX和横向扩展连接方面起着关键作用,因为它也是一个集成的PCIe交换机。
在这里插入图片描述

巨大飞跃:解耦式服务(Disaggregated Serving)

近日发布的Rubin CPX对推理而言是一项颠覆性创新,其重要性仅次于首次发布GB200 NVL72 Oberon机架级形态产品。只有通过为推理中截然不同的预填充和解码阶段配备专用硬件,才能真正实现解耦式服务。

处理LLM请求涉及两个阶段:预填充阶段和解码阶段。在预填充阶段,LLM根据用户提示(prompt)生成第一个令牌(token)。此阶段影响首令牌时间(TTFT),它通常是计算瓶颈,未充分利用内存带宽。另一方面,解码阶段在从KV缓存加载先前令牌的同时生成新令牌。此阶段影响每输出令牌时间(TPOT),它始终是内存瓶颈,未充分利用计算能力。
在这里插入图片描述
在这里插入图片描述

在下图中,我们看到一个说明性示例, highlighting 在同一系统上进行预填充和解码时内存带宽和FLOPS利用率之间的权衡。预填充单个令牌所需的FLOPS随输入序列长度线性增长。解码所需的FLOPS也随系统上的用户数(即批处理大小)和序列长度而缩放。

较短的输入序列长度可能无法完全饱和推理系统上可用的FLOPS,在这种情况下,系统的输出将受到参数加载到芯片内存的速度的限制——这是内存带宽的函数。然而,随着输入序列长度增加,工作负载最终将增长到使用推理系统上所有可用的FLOPS,并且工作负载将受到系统总FLOPS的限制。在下图的右半部分,我们说明当序列长度超过32k时,FLOPS利用率达到100%,而内存带宽利用率下降。
在这里插入图片描述

因此我们可以看到,当一个节点执行非常侧重于预填充的工作负载(具有长序列长度或大批处理大小)时,内存带宽未被利用。如前一节所述,随着过去几年芯片BOM中内存所占百分比不断增加,这最终导致了对资源的非常昂贵的未充分利用!

低效还源于一个事实:预填充和解码阶段的工作负载特性天生差异巨大,以至于当它们同时处理时,预填充和解码请求总是相互干扰性能。有许多优化尝试来平衡两者——例如添加预填充计算以确保请求长度相对统一以提高利用率,但它们总是导致权衡折衷。另一种方法是将预填充和解码阶段完全分离,但如果你优先处理解码阶段,那么你的预填充就需要等待——导致首令牌时间很长。反之,如果优先处理预填充,你的解码阶段将被迫等待,并且你的令牌间延迟(inter-token latency)会变慢,因为内存带宽随后未被充分利用。

初步尝试:使用相同硬件实现预填充与解码的解耦

首要解决方案是实现解耦式服务(disaggregated serving),通过将预填充和解码请求路由到不同的计算单元来初步解决性能干扰问题,从而更简单地推理性能。这样做的好处是能够更好地管理服务级别协议(SLA),这些协议通常侧重于特定的每秒每用户令牌数(token/s/user)。然而,这存在一些注意事项。这种完全的解耦似乎仅在特定的输入/输出序列长度比例和长解码长度下才能提供优异的结果,在其他场景下收益并不显著。此外,这种解耦仍然存在“规模失配”问题,即纯粹的预填充操作几乎总是严重未充分利用内存带宽。

在下方的说明性示例中,我们展示了当R200仅用于预填充时,几乎不会使用其大部分内存带宽。随着序列长度增加且更有效地利用可用FLOPS,内存带宽利用率变得越来越低—— effectively 浪费了非常昂贵的HBM内存。
在这里插入图片描述

下一步:在专用硬件上实现预填充与解码的解耦——Rubin CPX登场

由于预填充天生就会未充分利用内存带宽资源,一种减少浪费的方法是减少内存的数量和成本。这正是Rubin CPX所采用的方法,即使用数量更少、成本更低的GDDR7内存。

在下方的说明性示例中,我们展示了当R200仅用于预填充时,几乎不使用其大部分内存带宽。相比之下,Rubin CPX在相当短的输入长度下实际上利用了更高百分比的内存带宽,然后在我们认为典型的输入长度下进一步下降。
在这里插入图片描述
在下表中,我们提供了一个示例来比较R200 GPU和Rubin CPX GPU的内存带宽利用率。在此场景中,两者都存在很低的内存带宽利用率,但区别在于Rubin CPX GPU至少闲置的是数量更少、便宜得多的内存。对于R200——我们看到运行与CPX上完全相同的预填充工作负载会导致每小时0.90美元的总拥有成本浪费!
在这里插入图片描述

Rubin CPX带来了更大的内存容量,但这些比特是“较低质量”的,因为它们是GDDR7,其每GB成本不到HBM的一半。从内存供应商的角度来看,GDDR7的利润率较低,因为它是一种技术要求较低、竞争更激烈的产品(例如,三星可以供应它)。

这意味着使用CPX系统降低了HBM在系统总内容成本中的份额。与将同等金额花费在独立的VR200 NVL144机架上相比,花费在VR200 NVL144 CPX或VR CPX机架上的每一美元中,用于HBM的比例更低。在其他条件相同的情况下,假设固定在AI系统上的支出金额不变,每美元支出对应的HBM需求将会下降。

为何不进一步减少内存?

许多读者倾向于进一步削减内存以降低HBM成本,然而技术现实更为复杂。Rubin CPX通过采用成本更低的GDDR7替代HBM,显著降低了预填充阶段的单位计算成本。这种成本下降将刺激市场需求增长,从而带动整体解码算力需求的提升,最终可能推动AI算力市场总规模的扩大。从供应链角度看,英伟达已向三星等供应商下达大量GDDR7订单,这将使具备相应产能的厂商受益,而专注于HBM的供应商则可能面临结构性需求变化。

更多关于预填充流水线并行:Rubin CPX解耦预填充的一个有趣优势

在上面的内容中,我们概述了Rubin CPX如何减少内存浪费,但Rubin CPX放弃使用非常快速的纵向扩展(scale-up)网络功能解决方案(如NVLink)是另一个关键节省。Rubin CPX的片外I/O仅限于16通道PCIe Gen6,这大约是1Tbit/s的单向带宽,而R200的NVLink为14.4Tbit/s。这对于执行预填充来说已经足够,即使是现代的MoE前沿LLM也是如此。

例如,DeepSeek V3在NVFP4数字格式下运行时,需要335GB的内存容量来加载所有模型权重——这超过了单个CPX芯片128GB的内存容量。这可以通过使用流水线并行(‘PP’)来克服,即将模型的多个层拆分到不同的GPU上。在PP中,每个GPU顺序处理令牌,并将激活值传递到流水线的下一阶段。

PP的缺点是令牌需要跨多个GPU顺序传递,会产生阶段间通信的延迟。重要的含义是,PP往往比专家并行(EP)提供更高的每GPU令牌吞吐量,但代价是PP比EP具有更高的首令牌时间(TTFT)。PP具有更高的 tok/s/gpu 吞吐量,因为EP具有很高的通信开销,因为它涉及全对全(all-to-all)集合操作,而PP只是简单的发送和接收操作。

因此,对于流水线并行推理,更简单的通信要求意味着预填充几乎永远不会使通信链路饱和——这意味着无需配备昂贵的快速纵向扩展网络。与HBM一样,这是另一个可以通过剥离另一层在纯预填充操作中未使用的设备来节省成本的领域——为系统所有者节省浪费的TCO美元。

在下表中,我们显示使用PP8或PP4并行方案对DeepSeek进行预填充时,每个令牌的消息大小为7kB。如果我们用消息完全饱和PCIe Gen6 x16通道的I/O,这意味着我们最多可以每秒传输(并因此处理)1830万个令牌。这是通信瓶颈。

转向计算瓶颈场景,我们看到每个令牌的预填充FLOP为0.074 TFLOP。因此,如果我们将Rubin CPX的19,800 PFLOPS的稠密FP4吞吐量除以0.074 TFLOP,我们得到最大令牌吞吐量为26.76万个令牌/秒。

这远低于通信瓶颈,并且远远未饱和即使是相当普通的PCIe Gen6 I/O,更不用说提供超过16通道PCIe Gen6带宽14倍以上的NVLink了。

我们估计,纵向扩展NVLink对最终系统所有者的总成本(包括NVSwitch和背板)约为每GPU 8000美元——略高于每GPU集群总成本的10%。这是Rubin CPX为最终用户带来显著节省的另一个维度。
在这里插入图片描述

然而,尝试将专家并行(EP)与较低速度的网络连接一起使用会导致延迟问题和瓶颈。通信需求随top_k值与层数的乘积而缩放。DeepSeek V3的top_k为8,有61层,因此粗略计算表明,使用EP而非PP将使通信需求增加约488倍。

AMD MI400系列 UALoE72 和 MI500 UAL256

然而,随着Rubin CPX GPU的发布,AMD的回归战略现在看起来不够快也不够激进,AMD将发现自己再次追赶英伟达。AMD即将凭借机架规模的MI400赶上,但英伟达提高了门槛。

AMD今年早些时候在其“Advancing AI”活动上引起了轰动,首次展示了其MI400 72 GPU机架级系统。我们当时的分析指出,相对于FP4 FLOPS,MI400可以提供比VR200 NVL144系统更低的总拥有成本——同时还能提供19.8TB/s的内存带宽,而最初宣传的VR200 NVL144内存带宽为13.0 TB/s。

英伟达的VR200 NVL144现在通过向供应商要求更快的速度档,宣传其每逻辑GPU内存带宽约为20.5TB/s。VR200的内存带宽现在与AMD MI400持平,但使用的HBM堆栈数量更少。
在这里插入图片描述
如果MI400的FP4有效稠密FLOPS(即微基准测试实际表现出的性能,而非营销吞吐量)结果与VR200 NVL144持平或更低,那么AMD effectively 将比英伟达更晚上市一个VR200 NVL144的翻版。与此同时,随着VR200 CPX NVL144为长上下文长度提供更好的每TCO性能,英伟达将再次领先。AMD届时将不得不再次等到2027年才能赶上。

然而,我们相信AMD仍处于战斗模式,它现在需要开辟另一个战线,在开发其机架级系统和改进软件之外,还要进行仅预填充芯片的战斗,才有机会在2027年赶上英伟达。

最后
英伟达发布的Rubin CPX,并非一次简单的迭代,而是对AI推理底层经济学的重塑。它精准地针对了解耦式推理中预填充(Prefill)阶段的特点——计算密集而内存带宽需求相对较低。

通过采用成本更低、容量更大的GDDR7替代昂贵的HBM,并舍弃为纵向扩展设计的NVLink转而依赖PCIe,Rubin CPX在单一任务上实现了极致的“性价比”。这使得将预填充与解码任务分配至不同的专用硬件成为可能,避免了统一硬件带来的资源浪费和性能干扰,最终为用户显著降低了总体拥有成本(TCO)。这一举措不仅将迫使竞争对手重新规划产品路线,更可能改变HBM与GDDR在AI加速领域的需求格局,标志着AI硬件设计进入了更加精细化、专用化的新阶段。


文章转载自:

http://8z7kYfZJ.zsyrk.cn
http://Ps1XL7RX.zsyrk.cn
http://HyXp5nAT.zsyrk.cn
http://7D0Z6TZB.zsyrk.cn
http://twW6ziGl.zsyrk.cn
http://IOOj0Jcy.zsyrk.cn
http://mFddFvdY.zsyrk.cn
http://dpav97yj.zsyrk.cn
http://N8ZHlnoX.zsyrk.cn
http://ho2iBjFp.zsyrk.cn
http://2bLR8r2z.zsyrk.cn
http://8f6w2yOn.zsyrk.cn
http://2ZsB3RD0.zsyrk.cn
http://x4isCLTD.zsyrk.cn
http://3PS6eFWr.zsyrk.cn
http://bw4ihbsr.zsyrk.cn
http://qmFUmWjr.zsyrk.cn
http://ebwDRwXc.zsyrk.cn
http://HYJoJsUE.zsyrk.cn
http://110bC5U3.zsyrk.cn
http://DnywTIxv.zsyrk.cn
http://FO7YKWjL.zsyrk.cn
http://ucng7tSt.zsyrk.cn
http://VD6RvCXq.zsyrk.cn
http://IVUUEvwV.zsyrk.cn
http://I1L1WRss.zsyrk.cn
http://OhMu5xdk.zsyrk.cn
http://h251F8b1.zsyrk.cn
http://Ni0eCV4V.zsyrk.cn
http://RmwKSIqP.zsyrk.cn
http://www.dtcms.com/a/378363.html

相关文章:

  • 线下小店悄然增长:两个关键模式与它们的运营启示
  • 开发安全利器:detect-secrets 敏感信息扫描工具实战指南
  • 中间件架构设计与实践:构建高性能分布式系统的核心基石
  • 错误于make.names(vnames, unique = TRUE): invalid multibyte string 9 使用 R 语言进行数据处理时
  • 前端基础标签
  • 深度学习基本模块:ConvTranspose2D 二维转置卷积层
  • 多模态数据治理新范式:衡石Agentic BI如何统一结构化与非结构化数据?
  • Gopeed下载器本地部署指南:cpolar实现远程任务管理
  • App 苹果 上架全流程解析 iOS 应用发布步骤、App Store 上架流程
  • unity UGUI 鼠标画线
  • ALBEF(Align Before Fuse)
  • redis 集群——redis cluster(去中心化)
  • k8s部署kafka三节点集群
  • 11.ImGui-加载字体和中文
  • 大模型推理革命
  • 项目-sqlite类的实现
  • 物联网领域中PHP框架的最佳选择有哪些?
  • ARM1.(ARM体系结构)
  • Linux开机启动设置全攻略
  • 解决Pytest参数化测试中文显示乱码问题:两种高效方法
  • PHP弱类型比较在CTF比赛中的深入分析与实战应用
  • 科大讯飞一面
  • html块标签和内联标签的通俗理解
  • 【C++】STL--Vector使用极其模拟实现
  • QT子线程与GUI线程安全交互
  • 论 Intel CPU 进化史:德承工控机全面进化 搭载新一代 Intel® Core™ Ultra 7/5/3 处理器
  • 论文阅读/博弈论/拍卖:《Truthful Auction for Cooperative Communications》
  • 【论文阅读】Towards Privacy-Enhanced and Robust Clustered Federated Learning
  • [论文阅读] 告别“数量为王”:双轨道会议模型+LS,破解AI时代学术交流困局
  • 【UE】2D SphereNormalsMap - 实时计算2D “球形法线” 贴图