英伟达开放 Vera Rubin 设计规范:256 颗自研 CPU 机架、800V 直流供电

十月十五日陆家嘴财经早餐披露,英伟达宣布向外部厂商开放下一代 AI 平台 Vera Rubin 的服务器设计规范,并发布一款搭载多达 256 颗自研 CPU、专为 AI 智能体打造的机架系统。供电架构上,机架直流电压从常见的水平提到了 800 伏。这是英伟达从「卖芯片」进一步走向「卖整机架构」的明确信号。 256 颗自研 CPU 为什么这么多? Hopper 时代一个 NVL72 机柜里 CPU 是配角,主要跑_host 侧调度。Vera Rubin 这一代把 CPU 数量拉到 256,是因为智能体工作负载的瓶颈从 GPU 张量核转移到了 CPU 侧的工具调用、浏览器、文件系统、沙箱编排。一个 agent 任务要并行开几十个子进程,CPU 核数和内存带宽比 FLOPs 更卡脖子。256 CPU 机架等于把「GPU 集群」重新定义为「GPU 加 CPU 编排集群」。 800V 直流供电解决什么问题? AI 机柜功率密度已经冲到 100kW 以上,传统 48V 母线的铜损和母排体积不可接受。800V 直流把电流压到 48V 的十六分之一,铜损降为二百五十六分之一,母排可以从铜板缩成线缆。这跟特斯拉、奔驰在电动车上用 800V 平台是同一个物理逻辑——功率密度上去后,电压必须跟着上去。对数据中心,这意味着供电柜、UPS、PDU 全要重做一代。 开放设计规范对 OEM 意味着什么? 过去 OEM 买 NVIDIA 参考设计贴牌,现在直接拿到图纸,可以自己改电源、散热、互联。这是英伟达绑定生态的更深一招:让 OEM 把研发投到 NVIDIA 定义的架构里,而不是去支持 AMD 或自研。对国内算力产业链,这既是压力也是配套机会——电源、液冷、光模块的订单会跟着 Vera Rubin 机架放量。 ...

2026-10-15 · 1 min · 120 words · 王波

英伟达开放 Vera Rubin 设计规范:256 颗自研 CPU 机架,供电拉到 800 伏

十月十五日,据陆家嘴财经早餐披露,英伟达宣布向外部厂商开放其下一代 AI 平台 Vera Rubin 的服务器设计规范,同时发布一款搭载多达 256 颗自研 CPU、专为 AI 智能体打造的机架系统。在供电架构上,新方案把机架直流电压从常见水平一口气提到了 800 伏。这是英伟达从「卖芯片」进一步走向「卖整机架构」的标志性一步:过去它只供 GPU,现在连机架怎么组、电怎么供,都把规范公开给 OEM 照着造。 为什么要把设计规范对外开放? 过去英伟达的机柜参考设计是半封闭的,大客户要照着搭一整套 NVL72 机柜,基本只能找少数几家合作 OEM。这次开放 Vera Rubin 设计规范,等于把制造门槛降下来——更多服务器厂商、代工方都能合法照着图纸造整机,把整个生态绑在英伟达的技术栈上。这招其实是从英特尔的 x86 开放模式学来的:我不自己造所有机器,但所有机器都必须按我的标准造。对国内算力产业链,这既是压力——你很难再绕开英伟达的机架规范另起炉灶——也是代工与配套零部件的机会窗口。 256 颗 CPU 加 800 伏电是在为什么铺路? 两个细节都指向同一件事:下一代 AI 智能体集群的功耗密度。256 颗自研 CPU 一个机架,说明推理和智能体编排正在从 GPU 旁边「长」出一个巨大的控制面——成千上万个 Agent 并发跑起来,CPU 侧的调度、内存、网络开销被放大到需要一个机柜专门塞 CPU。而 800 伏直流供电,是因为整柜功率已经高到传统 400 伏方案在线损上扛不住了。电压翻倍、电流减半、线损按平方下降,这是物理定律逼出来的升级。换句话说,AI 智能体不是软件概念,它正在实打实改写数据中心的供电与散热标准。 对国内算力链是机会还是压力? 短期看是压力:Vera Rubin 规范一开放,全球 OEM 都会加速转过去,国产机架想进海外超大规模数据中心的门槛更高了。但中长期看也有窗口——800 伏供电、高压直流、液冷、铜连接、光模块这一套配套,是全球统一的新规格,谁能先把这些零部件做到低成本高良率,谁就能吃到这一轮整机换代的订单。国内供应链在电源、液冷、光模块上本就有分量,关键看能不能赶在 Vera Rubin 大规模上量前,把配套产能和认证做进去。 去论坛讨论 前往 silicon-agi.com 论坛 参与讨论。 💬 更多交流内容,请点击本站论坛交流区:silicon-agi.com

2026-10-15 · 1 min · 66 words · 王波

Vera Rubin NVL72 上架后,按小时租一晚跑离线评测的省钱玩法

10 月以来,NVIDIA Vera Rubin NVL72 在 CoreWeave、Google Cloud、Azure、Oracle 等云陆续进入部署节奏。这是新一批「按小时就能摸到」的顶级推理算力。对个人开发者和小团队,最划算的用法不是拿它做在线服务——你吃不下那个并发——而是租它跑「晚上才需要的重活」:离线评测、长文档批量摘要、模型微调后的全量回归。 为什么偏要夜里租新机架? 在线推理看延迟和并发,离线批处理只看吞吐。新一代机架的优势恰恰是每瓦吞吐和长上下文成本,跑批任务时利用率能拉到九成以上,比白天跑在线划算得多。多数云厂商的现货实例在夜间闲置时段报价更低,配合自动关机脚本,一晚成本可以压到按需价的两三成。 夜间租机跑批处理该怎么操作? 第一步,先在便宜的现货小实例上把镜像、依赖、数据集、评测脚本全部调好,确保一条命令能从头跑到尾,不要等到租了整机才开始装环境。第二步,用对象存储把待评测的样本集和参考答案提前传好,批任务只读存储、不依赖你本机网络。第三步,晚上开一台现货实例,用 tmux 或 nohup 挂批处理,脚本里写死「完成后自动调用云 API 关机」。第四步,结果直接回写对象存储,第二天早上拉本地分析。 关键参数:把批大小拉到实例显存允许的上限,长上下文任务开前缀复用,避免重复 prefill。 多角色交接有哪两个坑? 现货实例可能被随时回收,所以脚本必须每隔几分钟把进度 checkpoint 到存储,回收了就从断点续跑,别从头再来。另外,新平台的驱动和推理栈版本偏新,你上周在老卡上能跑的量化格式,在新卡上可能要重新编译 engine——预留一小时做兼容性验证。 小团队蹭新硬件红利的正确姿势是什么? 顶级算力不再是大厂专属,但它的正确打开方式是「夜间批处理」,而不是白天硬扛在线延迟。把评测、摘要、回归这些可延迟的活攒到夜里跑,是现阶段小团队蹭新硬件红利最稳的姿势。 去论坛讨论 这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:VeraRubin租机 💬 更多交流内容,请点击本站论坛交流区:silicon-agi.com

2026-10-09 · 1 min · 32 words · 王波

Vera Rubin NVL72 量产拆解:20.7TB HBM4 为什么比算力更重要

7 月 21 日 NVIDIA 宣布 Vera Rubin NVL72 量产全面加速,CoreWeave、Google Cloud、Microsoft Azure、Oracle Cloud 的机架已经上线运行;供应链覆盖 30 个国家 350 多家工厂。10 月初 SpaceXAI 又宣布把优化版 Vera Rubin NVL72 搬上第一代 Starmind 卫星。这颗继任者的规格表里,最值得技术人记住的不是 3.6 EFLOPS FP4,而是那 20.7TB 的 HBM4。 规格表读错的方式 官方数据:Vera Rubin NVL72 整机架 20.7TB HBM4、约 1.6PB/s 内存带宽、3600 PFLOPS NVFP4 算力;单颗 Rubin GPU 配 288GB HBM4、19.2TB/s;超芯片(Superchip)配 576GB HBM4、38.5TB/s;NVLink 进入第六代。Micron 的 HBM4 36GB 12-Hi 已在 3 月量产,单栈带宽超过 2.8TB/s。 外行看 FLOPS,内行看容量。原因在于 Agent 负载的瓶颈已经转移。 为什么容量墙先到 过去两年的推理优化,主线是「让每 HBM 字节动得更快」——KV cache 量化、分页注意力、前缀缓存。但当模型越做越大(MoE 总参数逼近万亿)、上下文越拉越长(十万、百万 token)、并发越来越高(一个 Agent 同时挂着十几个工具会话),单卡显存装不下权重加 KV,才是硬约束。 ...

2026-10-08 · 1 min · 117 words · 王波

Vera Rubin NVL72 量产铺开:智能体算力基建从「训练厂」转向「常驻电厂」

10 月初的几条消息拼出一张图:NVIDIA Vera Rubin NVL72 量产正在加速,CoreWeave、Google Cloud、Azure、Oracle、Mistral 等相继宣布部署计划;与之配套的 Vera CPU 拿下 SpaceXAI 大单。作为对照,上一代 GB300 NVL72 已把智能体低延迟推理成本压到约每百万 token 0.123 美元。把这些放在一起,能看到一个清晰的前沿趋势——AI 算力基建的重心,正在从「训练大模型的工厂」转向「常年跑智能体的电厂」。 训练是脉冲,推理是常驻 过去几年的 AI 基建叙事是训练:建超大集群、跑数月、烧巨资,产出一个模型就关炉。这是脉冲式的、一次性的。 智能体时代的负载完全不同。一个通用工作智能体要 7×24 小时挂着,随时等用户一句话,然后调工具、跑代码、连业务系统。它不是训练完就走,而是常年在线、持续吞吐 token。这更像电厂——稳定供电,而不是开矿式的一次性开采。 基建形态随之改变 这种负载变化,正在重塑基建的几个维度: 单位成本优先:谁能把每百万 token 压得更低,谁就赢得常驻负载。GB300 比 Hopper 低约 35 倍成本,正是冲着这个来的。 CPU-GPU 协同:智能体的关键路径上,CPU 负责工具调用与编排,GPU 负责模型推理。Vera CPU 的出现,就是把这条链路补上。 多云铺开:CoreWeave、Google、Azure、Oracle 同时部署,说明常驻算力要贴近用户、贴近业务系统,不能集中在一两个超算中心。 判断 未来衡量一家算力公司的指标,不会是它训练过多大的模型,而是它能以多低的成本、多稳的在线率,养活多少个常年值守的智能体。智能体电厂这个词,会取代「训练巨兽」,成为下一代 AI 基建的主角。 再展开一层:这种从脉冲到常驻的迁移,还会改变算力的采购与结算方式。训练负载是项目制的——立项、烧钱、结项;常驻负载是订阅制的——像交电费一样按月为在线率付费。当 CoreWeave、Google、Azure、Oracle 同时铺开 Vera Rubin,它们卖的已经不是「一批卡」,而是「一份全年无休的智能体运力」。这种生意模式的切换,比任何单一硬件参数都更能说明:智能体时代的算力,到底长成了什么样子。 去论坛讨论 这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:智能体算力基建 💬 更多交流内容,请点击本站论坛交流区:silicon-agi.com

2026-10-08 · 1 min · 59 words · 王波

当算力搬上轨道:「外脑」的地理边界正在消失

NVIDIA 与 SpaceXAI 的合作在 10 月初再度升温:SpaceXAI 将部署 Vera CPU 加速下一代智能体工作负载,并随 Vera Rubin 平台把 AI 基础设施从地球扩展到轨道。按 NVIDIA 新闻稿的说法,这是要把为 Grok 准备的算力规模推向吉瓦级,甚至延伸到太空。这件事表面看是基建新闻,实则触及一个认知哲学问题:当「外脑」开始离开地面,它和你的距离、它的属地,还重要吗? 外脑本来就是个地理模糊的东西 人类的外部记忆一直不在脑子里:书在书架上,档案在城市那头的档案馆,后来是云端的某台服务器。我们早就习惯了「思考的一部分存在别的地方」,只是这个「别的地方」过去总在地面上、在某个机房里、在某个国家的司法管辖下。 轨道算力把这个最后一点地面性也抽掉了。一台在轨道上的智能体算力节点,不属于任何国家的领空,它绕着地球转,你调用它时它可能正在你头顶上方飞过。 距离与归属都在重构 这会带来两个温和却真实的变化: 距离消失:认知外脑不再有「本地」和「远端」的区别,因为它本来就在动。延迟只取决于轨道位置,不取决于行政区划。 归属模糊:你的思考数据经过一颗绕地运行的节点,它受哪国法律约束?这个问题今天没有答案,但它会很快变成现实问题。 更深一层是心理层面的。当你的外脑既不在你桌上、也不在某个具体机房,而在天上转圈,「我」这个概念所依托的外部支架,就彻底脱离了大地。 一个冷静的注脚 轨道算力短期主要服务于对延迟和能源敏感的大规模推理,不是哲学实验。但历史一再表明,基础设施的每一次外移——从纸到印刷术,从书库到云端——都会反过来重塑「人」的边界。这次只是把外脑的天花板,从大气层换成了宇宙。 去论坛讨论 这篇文章里的观点,欢迎到硅基AGI论坛讨论。按标题搜索:轨道算力与外脑 💬 更多交流内容,请点击本站论坛交流区:silicon-agi.com

2026-10-08 · 1 min · 33 words · 王波

Vera Rubin NVL72 真投产了:CoreWeave 把它送进生产环境,Cognition 首吃螃蟹

10 月初,产业链传出的关键进展是:新一代 Vera Rubin NVL72 不再是 roadmap 上的参数,而是真的进了生产环境。CoreWeave 已把 NVL72 送进生产部署,编码智能体公司 Cognition 成为首个跑生产负载的客户。与此同时,Google Cloud、Azure、Oracle、Mistral 等都在列部署名单。据现场数据,在 SWE-2 这类智能体负载上,NVL72 的总 Token 吞吐较 GB200 NVL72 提升约 4.8 倍,强化学习每 GPU 输出提升约 3.8 倍。 成本数字是怎么往下走的 英伟达官方口径很有说服力:GB300 NVL72 在单用户交互 116 TPS 场景下,借助 Dynamo 与 TensorRT-LLM 把推理成本做到每百万 token 约 0.123 美元(SemiAnalysis 2026 年 4 月基准),比 HGX H200 低约 35 倍。而 Vera Rubin NVL72 更狠——每百万 token 成本约为 GB200 NVL72 的十分之一,每兆瓦 Token 产出最高约 10 倍;按 SemiAnalysis 的 AgentX 数据,相较 GB300 NVL72 每百万 token 成本还能再降约 45 倍。 ...

2026-10-08 · 1 min · 137 words · 王波
NVIDIA Vera Rubin:4000 TFLOPS的算力巨兽

NVIDIA Vera Rubin:4000 TFLOPS的算力巨兽

引子:把算力堆成一座山 如果说2026年的AI芯片圈有一个绕不开的名字,那就是NVIDIA Vera Rubin。这家公司在"堆算力"这件事上,从来没让人失望过——而Vera Rubin,是它迄今为止最凶猛的一次堆料。 单卡4000 FP16 TFLOPS、288GB HBM4显存、3360亿个晶体管——这三个数字任意一个拿出来,都足以定义一个时代。而当NVIDIA把72颗这样的卡塞进一个整柜,它跑出的是3.6 EFLOPS的整柜算力。这已经不是"芯片"的概念了,这是一座专门为AI建造的算力山。 单卡参数:为什么4000 TFLOPS是个里程碑 先把Vera Rubin的核心规格摆出来。 项目 Vera Rubin FP16算力 4000 TFLOPS HBM显存 288GB HBM4 晶体管规模 3360亿个 整柜方案 NVL72 整柜算力 3.6 EFLOPS 4000 FP16 TFLOPS这个数字,标志着单卡浮点性能再次跳上一个数量级台阶。要理解它的意义,得知道AI训练的瓶颈从来不是"算力不够"那么简单——它是算力、显存、互联三者的三角平衡。Vera Rubin的厉害之处在于,它不是单项领先,而是三项一起堆上去: 算力:4000 TFLOPS让超大模型的单步训练时间进一步压缩 显存:288GB HBM4能塞下更大的模型、激活值和更长的上下文 互联:NVL72整柜方案保证72颗卡之间数据高速流通,不把时间浪费在等数据上 3360亿晶体管则是这一切的物理基础——在一颗芯片上塞进超过3000亿个晶体管,本身就是先进制程与封装技术的极限表演。 数据来源:NVIDIA官方发布与技术白皮书,2026年 NVL72整柜:从"芯片"到"数据中心" Vera Rubin真正的杀招,不是单卡,而是NVL72整柜方案。这反映出NVIDIA思路的根本转变:竞争单位不再是单颗芯片,而是整个整柜。 层级 规格 单卡 4000 TFLOPS / 288GB HBM4 整柜(NVL72) 72颗卡互联 整柜总算力 3.6 EFLOPS 3.6 EFLOPS是什么概念?1 EFLOPS等于每秒百亿亿次浮点运算。把72颗Vera Rubin通过高速互联连成一个池化的算力单元,客户买到的不再是一堆孤立的GPU,而是一个开箱即用的"超算级AI引擎"。 这种整柜化趋势的背后,是大模型训练的现实——没有任何一个模型是靠单卡训练出来的,真正比拼的是千卡、万卡规模下的有效算力利用率。NVIDIA把互联、供电、散热、软件全部打包进整柜,客户买回去插上电就能跑最大模型,这正是它锁定超大规模客户的护城河。 成本与现实:巨兽不是人人养得起 算力巨兽的另一面,是惊人的成本。 Vera Rubin级别的整柜,单机柜造价、功耗、散热要求都达到了新高度。4000 TFLOPS很诱人,但只有超大规模云厂商、国家级算力中心、顶尖大模型公司才养得起这种配置。这意味着: 算力进一步向头部集中:中小团队更难自建顶级训练集群,只能租用云 推理与训练分层:这种巨兽用于训练,推理则交给更便宜的Flash级芯片 能源成为新瓶颈:3.6 EFLOPS的整柜,耗电量本身就是一座小型电厂的级别 NVIDIA的护城河因此越来越深:它卖的不只是芯片,而是一整套"算力工厂"的交钥匙方案。客户一旦进入NVL72的生态,迁移成本极高。 ...

2026-09-14 · 1 min · 117 words · 王波
AI芯片三国杀:NVIDIA Vera Rubin vs AMD Helios vs OpenAI Jalapeño

AI芯片三国杀:NVIDIA Vera Rubin vs AMD Helios vs OpenAI Jalapeño

NVIDIA Vera Rubin、AMD Helios、OpenAI Jalapeño三方角逐AI推理市场。Vera Rubin推理成本降至Blackwell的1/10,AMD Helios单机柜HBM4容量超NVIDIA 50%,OpenAI自研ASIC声称便宜50%。2026年Q2全球十大IC设计营收1414.5亿美元,英伟达独占64%。

2026-09-14 · 1 min · 107 words · 王波
🔗 硅基 AGI 论坛 · silicon-agi.com | 📡 RSS 订阅
鲁ICP备2026018361号
📮 联系信箱:13789892969@139.com