65 篇博文 含有标签「Tech Deep Dive」

每一次制程换代都会重新洗牌 AI 算力格局。2026 年，2nm 从路线图走进量产车间：AMD 抢下 N2 AI GPU 首发权，EPYC Venice 成为全球首款 2nm 数据中心 CPU，Intel 的 High-NA EUV 则悄悄跨过百万晶圆门槛。制程竞赛的规则，也在这一年悄悄改变。

制程、能效与晶体管密度的链条​

制程的意义可以用一条链概括：更小的晶体管 → 更高的密度与更低的开关功耗 → 同样封装面积塞进更多计算单元与更大缓存 → 单位 token 的能耗与成本下降。对 AI 芯片而言，这条链的最后一段尤其重要——推理集群的电费和散热已经取代芯片采购价，成为 TCO 的最大头之一，制程每前进一代，同等机柜功率下能跑的 token 数就上一个台阶。

2026 年的 2nm 落地图谱如下：

厂商	产品	制程	状态与要点
AMD	Instinct MI455X	TSMC N2 计算芯粒 + N3 I/O 与缓存芯粒	首款 TSMC N2 AI GPU，3200 亿晶体管，432GB HBM4，2026-07-23 发布
AMD	EPYC Venice（Zen 6）	TSMC N2	全球首款 2nm 数据中心 CPU，256 核，2026 年 5 月量产
Google	TPU 8t（Trillium 2）	TSMC 2nm	训练专用 ASIC，双计算 Die，9600 芯片 Pod，121 EFLOPS FP4
Intel	Foundry High-NA EUV 产线	High-NA EUV	已处理超 100 万片晶圆（2026-09-21 当周口径）
三星	2nm AI 芯片制程	SF2 路线	联合台积电推进，目标 2027 年量产，宣称能效比提升 40%（2026-09 口径）

N2 AI GPU 首发为何是 AMD​

按过往节奏，新制程的首发大客户通常是谁？答案是 AMD——而且这不是偶然。MI455X 采用 8 个 N2 计算芯粒（XCD）加 2 个 I/O die 与 2 个缓存/fabric die（N3）的混合封装：把最吃密度的计算芯粒放最先进节点，把成本敏感的 I/O 与缓存留在成熟一档的 N3，用 CoWoS-L 先进封装拼合，既拿到 2nm 的能效红利，又控制了整片成本。

同一家公司连下两城：EPYC Venice 用 N2 做出 8 颗 Zen 6C CCD、每颗 32 核、总计 256 核、1GB L3 缓存的怪兽 CPU，单路内存带宽 1.6TB/s，与 MI455X 组成 Helios 机架（18 颗 Venice + 72 颗 MI455X，31TB HBM4，2.9 FP4 exaFLOPS）。CPU 与 GPU 同代同步上新制程，是 AMD chiplet 战略的复利——分芯粒设计天然适配"最先进节点给计算、次先进节点给 I/O"的分配策略。Google TPU 8t 也选择了同样的 N2 + Broadcom 协作路线，印证了"定制 ASIC 抢新制程"的趋势。

High-NA EUV 百万晶圆的意义​

Intel 在 2026 年 9 月 21 日当周披露，其 Foundry 的 High-NA EUV 产线累计处理晶圆已超过 100 万片。这个数字的意义在于：High-NA EUV——分辨率更高、专为 2nm 及以下节点准备的下一代光刻机——从"实验室样机"正式进入"规模化生产"阶段。百万晶圆意味着工艺窗口验证、良率爬坡和产能利用都跨过了商业化门槛，Intel 18A 与 14A 路线因此有了现实的制造底盘。

对照看三星的动作同样密集：HBM4 已于 2026 年 2 月量产（成为 Rubin 等旗舰 GPU 的 HBM 供应商之一），2nm AI 芯片制程则与台积电形成竞争态势，目标 2027 年量产。制程竞赛与 HBM 竞赛第一次同步开跑。

"十年之约"：平台期被拉长​

台积电的投入力度佐证了这个节点的分量：2026 年 CAPEX 顶格到 560 亿美元上限，全年营收增速指引 30% 以上，3nm 产能同时在台湾、亚利桑那与熊本三地扩张。但硬币的另一面是 ASML 与 ZEISS 给出的"十年之约"——下一代光刻（High-NA 之后的技术）可能还需要十年才能成熟。这意味着 2nm/1.4nm 将成为一个超长平台期：没有新的光学分辨率红利可吃，各家的竞争焦点必须转移。

转移的方向已经很清晰。第一是先进封装：MI455X 的 12 颗 HBM4 堆栈、Rubin 的 MCM 多芯片设计，都说明系统级创新正在替代晶体管微缩。第二是 HBM 配套：N2 计算芯粒如果没有 22-23TB/s 的 HBM4 喂数据，算力就是摆设——制程与内存的协同定义能力，比制程数字本身更能决定产品成败。

小结​

2026 年的制程竞赛呈现出三个信号：2nm 实力量产，AMD 借 chiplet 架构连夺 AI GPU 与数据中心 CPU 双首发，Google 定制 ASIC 跟进；Intel 用 High-NA EUV 百万晶圆宣告制造能力回归牌桌；而 ASML 的十年之约意味着制程数字的边际收益递减，先进封装、HBM 协同与能效工程将成为新的竞争主轴。对 AI 算力买家来说，评估一颗芯片时，"几纳米"正在变成一个越来越不完整的答案——封装里装了什么、带宽喂了多少、每瓦能跑多少 token，才是更完整的提问方式。

torch.compile 常被当作"提个速的开关"，但对 AI 基础设施工程师来说，它更大的价值在于暴露了一套清晰的编译栈分层：TorchDynamo 负责捕图，后端负责下沉。理解这套分层，才能看懂国产芯片为什么能在不 fork PyTorch 的前提下接入。

编译栈的三层结构​

PyTorch 2.x 的编译链路可以拆成三层：

1. TorchDynamo：在 Python 字节码层面安全捕获计算图，遇到不支持的语法自动切段（graph break），保证兼容性优先。
2. 后端接口：torch.compile 的 backend 参数既接受内置名称，也接受任意可调用对象，签名为接收一个 FX GraphModule 与示例输入，返回优化后的可执行体。这层是所有第三方硬件的接入点。
3. TorchInductor：默认后端，为 NVIDIA、AMD、Intel GPU 生成 Triton 或 C++ 内核，支持 max-autotune、reduce-overhead 等模式，并通过动态形状追踪避免频繁重编译。

内置后端与自定义后端​

PyTorch 树内提供了一批非实验性后端，可以用 torch._dynamo.list_backends() 枚举：

后端	用途	阶段
inductor	默认后端，性能与开销平衡	生产可用
cudagraphs	CUDA Graph 加速，小批量推理	生产可用
aot_eager	仅做 AOT 捕图不优化，调试用	调试
tensorrt	经 Torch-TensorRT 下沉推理	推理
ipex	Intel CPU/GPU 优化	生产可用
onnxrt / openvino / tvm	各自运行时下沉	实验或推理

自定义后端的最小实现非常简单：写一个函数接收 GraphModule，做完变换后原样返回，就能挂进 torch.compile。厂商的真功夫在于把 FX 图拆分、算子映射到自家指令集、再生成高性能内核，同时处理动态形状与守护条件（guard），避免图缓存失效退化回 eager。

国产芯片的接入实践​

昇腾走的是 torch-npu 路线：以 PyTorch 插件形式提供 NPU 设备支持，vllm-ascend 的路线图里专门有支持 torch.compile（图模式）的条目，通过 ACL 图捕获来降低调度开销。这意味着上层代码基本不需要为编译模式做特殊改造，由插件在算子级完成下沉。类似地，Intel 在 PyTorch 2.5 中增强了 GPU 后端的 torch.compile 支持，并用 AMX 指令优化了 Xeon 上的 FP16 路径。对自研加速器团队而言，官方建议的路径是先让模型在 eager 模式跑通，再逐段评估 graph break 位置，最后决定是注册独立后端还是为 Inductor 扩展设备支持。

实操建议​

接入新硬件时优先确认三点：官方是否提供 PyTorch 插件而非 fork 版框架；插件对 torch.compile 的支持程度是"有接口"还是"经过生产验证"；动态形状场景的重编译频率是否可控。工程师调试编译链路时善用 TORCH_LOGS 环境变量（设为 guards 或 dynamic 可以定位守护失败与过度特化），并用 cache_size_limit 关注图缓存上限——缓存打满会静默回退 eager，性能悄悄掉一半而无人察觉。

数值格式（FP8、FP4）解决的是"硬件支持什么精度"，而量化算法解决的是"训练好的模型怎么安全地住进低精度"。后者才是工程落地的日常：手里一个 70B 模型、一张 80GB 的卡，怎么让它跑起来还尽量不掉点。

GPTQ：用二阶信息做误差补偿​

GPTQ 的思路源于经典的二阶最优剪枝方法。它逐层处理权重：用少量校准数据（几百条即可）估计该层输入的二阶统计量，然后按列量化权重，每量化一列，就利用 Hessian 信息调整其余未量化列，把引入的误差"摊"到还没量化的地方去补偿。整个过程不需要反向传播，在单张卡上几个小时内就能压完一个百亿级参数模型。

代价是它本质上在做"整体最优的近似"：逐层的贪心决策叠加起来，对校准数据分布有一定敏感性，校准集与真实业务分布偏差大时，掉点风险随之上升。

AWQ：抓住关键的 1% 通道​

AWQ 从另一个观察出发：权重中真正对精度敏感的通道，是那些对应激活值特别大的少数通道——通常只占 1% 上下。与其逐列做全局误差补偿，不如识别出这些显著通道，用一个按通道缩放的变换保护它们，让它们落在量化网格的"好位置"上。

这个方法同样不需要反向传播，校准成本与 GPTQ 相当，但对校准数据规模和分布的依赖更弱，跨领域、跨任务的鲁棒性通常更好，这也是它在开源社区部署中被广泛采用的原因。它只解决权重侧的压缩（常见的 W4A16 形态：权重 4bit、激活保持 16bit），计算时需要把权重反量化回高精度再做矩阵乘。

W8A8 与激活离群值​

想同时压缩激活（W8A8）会撞上大模型的经典难题：激活分布中存在系统性的离群通道，个别通道的数值比其余大几个数量级，直接按统一 scale 量化会把这些通道全压废。SmoothQuant 的解法很巧：用一个等效数学变换，把激活里的离群难度迁移到权重侧，让两边都变得"平缓"，从而实现全整数推理。W8A8 的算子效率高、适合大 batch 高并发服务，但精度风险高于 W4A16，需要更仔细的评估。

方法对照与取舍​

方法	典型形态	是否需要反传	主要优势	适用场景
GPTQ	W4A16	否	压缩比高，工具链成熟	单卡/双卡装下大模型
AWQ	W4A16	否	鲁棒性好，跨域稳定	通用生产部署
SmoothQuant	W8A8	否	激活也压缩，算子高效	高并发吞吐服务
QAT（量化感知训练）	任意	是	精度上限最高	有训练资源且对精度极敏感

实操建议​

单卡或双卡要装下大模型、追求低延迟，选 W4A16 的 AWQ 或 GPTQ，两者精度差异通常不大，优先看框架支持度；高并发吞吐场景考虑 W8A8。评估时不要只看困惑度，困惑度的小幅变化可能对应下游任务的大幅波动，务必跑自己的业务评测集。另外，KV Cache 量化是独立的压缩维度，长上下文场景可与权重量化叠加使用。最后，任何量化方案上线前都先在影子流量上对照全精度基线跑一段时间，这是最便宜也最可靠的保险。

当训练集群规模迈过千卡、冲向万卡，网络布线就不再是"把线插上"那么简单。Rail-optimized（轨道优化）拓扑是当今几乎所有大规模 GPU 集群的标准答案——DGX SuperPOD、各大云厂商的 H100 与 B200 集群都在使用。本文从工程视角拆解它的原理、布线纪律与运维要点。

为什么需要 Rail-optimized​

现代分布式训练的通信模式高度规律：数据并行场景下，每个节点的 GPU0 与其他所有节点的 GPU0 通信最频繁，梯度 AllReduce 的主要流量就发生在这种"同位号"GPU 之间。Rail-optimized 的思路是顺着这个模式布线：一台 8 卡服务器有 8 张网卡，GPU0 的网卡统一接入 Rail 0 叶子交换机，GPU1 接入 Rail 1，以此类推。这样同轨通信只经过一层叶子交换机，只有跨轨流量才需要上脊层，跳数与拥塞都显著降低。

对比传统的"随机上联"布线，Rail-optimized 把物理拓扑与集合通信模式对齐，NCCL 等通信库可以据此选择最优路径。据公开报道，在万卡规模下，布线方式对有效通信带宽的影响可以达到两位数百分比，一根错误的跳线就足以拖慢整个训练作业。

一个典型的部署单元​

以业界常见的参考架构为例，最小部署单元（Scalable Unit，SU）通常由 32 台 8 卡服务器组成，共 256 卡，配 8 组 Rail 叶子交换机；多个 SU 通过脊层汇聚，两级架构可平滑扩展到 4096 卡以上，三层结构则可支撑数万卡。Ethernet 路线的代表是 NVIDIA Spectrum-X 平台：Spectrum-4 交换机单端口 800G，配合 BlueField-3 SuperNIC、逐包自适应路由与硬件拥塞控制；InfiniBand 阵营同样采用 rail 思路组织 Fabric。

值得关注的新趋势是多平面设计：在最新的 NVL72 级别企业参考架构中，每块 800G 网卡被拆分为两条 400G 链路，分别接入两个独立的网络平面。每个平面各由 4 台叶子交换机负责同一 GPU 位号的轨，两个平面互为冗余，单一平面故障时集群仍能继续训练。这种"拓扑并行化"正在成为十万卡级别机房的主流选择。

维度	传统随机上联	Rail-optimized
同位号 GPU 通信路径	多层跳转，路径不定	单层叶子交换机，路径确定
集合通信带宽	受 ECMP 哈希不均影响	适配 NCCL，接近线速
布线复杂度	低，随机可插	高，必须严格按图施工
故障定位	需全网排查	按 Rail 分域，边界清晰
扩容方式	灵活但性能难预测	按 SU 整体扩展

布线纪律：运维最容易踩的坑​

Rail-optimized 对施工的容错率极低。GPU3 的网卡若被误接到 Rail 5 交换机，链路照样能通，ping 与带宽抽测都看不出异常，但一旦跑起大规模 AllReduce，通信性能立刻劣化。工程上必须做到三点：

• 交付验收时逐链路核对竣工图（as-built），用带外管理工具确认每个端口对应的 GPU 位号与 Rail 编号，形成逐端口验证记录；
• 更换线缆或光模块后执行通信回归测试，重点验证跨节点同轨带宽与 AllReduce 基线；
• 把布线拓扑录入 CMDB，与 NCCL 的拓扑探测结果交叉校验，任何变更走双人复核。

此外，"同轨流量只过一层叶子"也意味着叶子交换机成为关键故障域：每组 Rail 应至少保留上联冗余，核心训练集群建议直接参考双平面设计，把容错做进拓扑而不是靠事后补救。

写在最后​

对正在规划千卡以上集群的团队，我们建议：第一，网络设计先行，Rail 拓扑、SU 划分与机柜布局要在服务器下单前锁定，避免交付期被动返工；第二，把布线验收当成与硬件点检同级的交付里程碑，逐端口记录、责任到人；第三，运维侧建立"布线变更双人复核加通信性能回归"的标准流程；第四，交换机选型预留端口余量，为后续扩容留出空间，避免为加几台机器而全机房重新跳线。万卡集群的很多故障，其实在建机房那天就已经埋下。

训练和推理抢卡、分布式作业因部分调度而死锁、GPU 利用率常年趴在低位——这些问题的根源往往是调度层设计。Ray 与 Kubernetes 生态各自给出了一套答案，关键是怎么组合。

两条路线的心智模型​

路线一：Ray 为中心。 把 Ray 当作计算编排层，Kubernetes 只负责运行 Ray Pod。KubeRay Operator 管理 RayCluster、RayJob、RayService 三类资源，Ray 自动伸缩器根据任务与 actor 的资源需求增删 worker 组。优点是 Python 世界的体验极好，任务级弹性、异构资源混用（不同代次 GPU 混部）都是内置能力；代价是调度决策发生在集群之外，Kubernetes 只看到结果。

路线二：Kubernetes 为中心。 用批调度器直接管理 GPU 作业，代表性组件是 Volcano 与 Kueue。Volcano 提供 Gang 调度、队列公平共享、抢占与网络拓扑感知调度；Kueue 做作业准入控制，排队等资源到位再放行。Ray 作业同样能被纳管：KubeRay 从早期版本就集成 Volcano 解决分布式训练的资源死锁，2025 年发布的 Volcano v1.13 进一步支持直接用原生 Volcano Job 创建和管理 Ray 集群。

能力对比​

能力	Ray 自动伸缩	Volcano	Kueue	NVIDIA KAI Scheduler
Gang 调度	弱（依赖 minReplicas）	原生支持	原生支持	原生支持
任务级弹性伸缩	强，秒级感知任务需求	作业级	队列准入级	支持工作负载伸缩
抢占与优先级	部分支持	支持	配合优先级类	高优推理可抢占低优训练
网络拓扑感知	无	v1.12 起 IB 拓扑，v1.13 支持 Label 自动发现	无	无
异构 GPU 混部	强	强	强	强

实践中的组合形态​

最常见的生产形态是"KubeRay 加批调度器"：RayCluster 的 Pod 标注调度器与队列，Gang 调度保证多机训练作业要么全起要么不起；启用了自动伸缩的集群按 minReplicas 做 Gang 约束，兼顾弹性与死锁防护。大型团队还会叠 NVIDIA KAI Scheduler，让在线推理在算力紧张时抢占离线训练。工程细节上，KubeRay 在大规模集群下要调大 reconcile 并发与客户端 QPS，社区压测显示默认并发配置扩容上万个 Pod 会明显变慢。Volcano 的基于节点标签的 HyperNode 自动发现功能则把"机架到交换机到节点"的拓扑维护简化为打标签，对要求亲和性调度的 IB 集群很实用。

实操建议​

纯 Python 研发团队、任务粒度碎、需要异构混部的场景，以 Ray 为中心最省心；作业规模大、需要队列治理与多团队配额的平台团队，以 Volcano 或 Kueue 为骨架、Ray 作为负载接入。两条路线不冲突，先想清楚"谁拥有资源审批权"这个组织问题，技术选型自然清晰。

LLM 推理从来不是一种负载，而是两种。Rubin CPX 的出现，是 NVIDIA 第一次在芯片层面把这两种负载拆开：prefill 交给一颗便宜的 GDDR7 芯片，decode 交给昂贵的 HBM 芯片。这是自 RTX 以来 NVIDIA 对 GPU 品类最激进的一次扩容。

为什么 prefill 值得一颗专用芯片​

LLM 推理分两个阶段。上下文阶段（prefill）读入整段提示词并构建 KV Cache，是算力密集型；生成阶段（decode）逐 token 出字，瓶颈在显存带宽。过去两种负载共享同一种 GPU，结果是为了 decode 的带宽为 prefill 买了昂贵的 HBM，而 prefill 本可以跑在便宜得多的存储介质上。

Rubin CPX 关键规格	数值
Die 设计	单晶片（区别于标准 Rubin 的双 Die 封装）
算力	最高 30 PFLOPS（NVFP4）
显存	128GB GDDR7（约 HBM4 单位成本的五分之一）
视频引擎	4 组 NVENC + 4 组 NVDEC
注意力性能	官方称较 GB300 NVL72 系统快约 3 倍
发布时间	2025 年 9 月 9 日

GDDR7 带宽远低于 HBM，但对瓶颈在算力的 prefill 而言是可接受的取舍，换来的是更低的每 GB 成本和免硅中介层的标准封装。芯片还内置了硬件注意力加速与视频编解码引擎——处理一小时视频可能需要百万 token 量级的上下文，Cursor、Runway、Magic 等公司在发布时即表态探索将其用于代码库级理解与长视频生成。

系统层面，Vera Rubin NVL144 CPX 机柜集成 144 颗 Rubin CPX、144 颗标准 Rubin GPU 与 36 颗 Vera CPU，合计 8 EFLOPS NVFP4、100TB 快速内存、1.7PB/s 内存带宽，官方称 AI 算力较 GB300 NVL72 高 7.5 倍。144 颗 CPX 负责 prefill，144 颗 Rubin 负责 decode，NVIDIA Dynamo 推理平台在两个池之间调度 KV Cache 的传递。

2026 年的现实：延期、缺席与 HBM4 传闻​

差异化设计的故事在 2026 年出现了转折。按原计划，Rubin CPX 应于 2026 年底出货，但 2026 年 3 月的 GTC 主题演讲上它并未出现——NVIDIA 当场展示的是用于低延迟解码的 Groq 3 LPX 机架，据 Tom's Hardware 报道，NVIDIA 高管在问答中确认 CPX 被调整让路于 LPU 解码路线。

时间节点	事件
2025 年 9 月	Rubin CPX 正式发布，宣布 2026 年底上市
2026 年 3 月	GTC 2026 主题演讲未亮相，官方称聚焦 LPU 解码
2026 年 9 月	据公开报道，分析师郭明錤称 HBM4 改版 CPX 计划 2027 年一季度投产（未经证实）

对采购者的含义很直接：不要围绕 CPX 做部署规划。但它背后的 disaggregated serving 架构——prefill 池与 decode 池分离、跨池传递 KV Cache——是成熟且已经落地的模式，今天的推理引擎与 GPU 租赁就能实践。CPX 若最终以 HBM4 形态归来，说明市场对"专用 prefill 硅片"的定价尚未收敛；若长期缺席，则证明混合负载仍将由通用 GPU 一肩挑。

小结​

Rubin CPX 的价值一半在硬件，一半在范式：它把"推理是两种负载"写进了产品线，逼迫整个行业认真核算 prefill 的成本占比。单 Die 加 GDDR7 的设计逻辑——用便宜的介质喂饱算力密集的段——未来大概率以某种形态回归。2026 年底的现在，把它当作路线图上值得追踪的节点，而不是采购清单上的选项。

2026 年 3 月 17 日的 GTC 大会上，NVIDIA 正式发布了 Rubin R200——这颗基于 3nm 制程、集成 3360 亿晶体管的 AI GPU，用 2.75 倍显存带宽和 5 倍 FP4 推理算力，完成了对 Blackwell 的一次教科书式代际跨越。本文依据站内芯片数据库数据，结合 MLPerf Inference v6.1 实测结果，拆解这颗芯片的技术细节与系统级打法。

核心规格总览​

据站内芯片数据库，Rubin R200 的完整规格如下：

规格	参数
GPU 架构	Rubin 架构（MCM 多芯片模块设计）
制程工艺	台积电 3nm N3P（计算 die）+ N5B（I/O die）
晶体管数量	3360 亿
SM 数量	224 个
FP4 推理算力	50 PFLOPS（sparse）
FP4 训练算力	35 PFLOPS（sparse）
FP8/FP6 算力	17.5 PFLOPS（sparse）
显存容量	288 GB HBM4
显存带宽	22 TB/s
互联技术	NVLink 6（单向 3.6 TB/s）
TDP	1800-2300W（必须液冷）
量产时间	2026 年 6 月（全面量产）
定价	单 NVL72 机柜 350-400 万美元

单看数字，Rubin R200 的 TDP 达到 1800-2300W，是 B200（1000W）的近两倍——功耗墙的持续抬升，正是当代 AI 芯片竞争的缩影：算力提升越来越依赖"堆晶体管 + 堆显存 + 堆带宽"的三重奏。

MCM 设计：2+2+8 的多芯片方程式​

Rubin R200 没有走"单颗巨 die"的路线，而是采用多芯片模块（MCM）设计，核心包含三部分：

• 2 颗计算 die：GPU 核心本体，采用台积电 3nm N3P 工艺；
• 2 颗 I/O die：负责 HBM 控制器与 NVLink 物理层，采用成本更低的 N5B 工艺；
• 8 颗 HBM4 显存堆栈：提供 288GB 总容量。

这种"计算与 I/O 分离"的设计是 HBM4 时代的必然选择。HBM4 的接口宽度翻倍到每堆栈 2048bit，如果继续让 3nm 计算 die 直接挂载 HBM 控制器，die 面积将被大量 I/O 逻辑占据，成本失控。把 HBM 控制器和 NVLink PHY 下放到 N5B 工艺的 I/O die，既保护了最昂贵的 3nm 面积，又让存储互联部分可以独立迭代——这也是 AMD 在 MI400 系列上殊途同归的工程共识。

第三代 Transformer Engine​

Rubin 架构的第三代 Transformer Engine 支持硬件级自适应精度压缩，不需要重写模型代码即可在 FP4/FP6/FP8/FP16/BF16/TF32/FP32/FP64 之间动态切换。对用户而言，这意味着 FP4 量化不再是"敢不敢用"的权衡，而是训练与推理管线的默认状态。

HBM4：接口翻倍如何换来 2.8 倍带宽​

显存是这代产品最戏剧性的升级点。据站内芯片数据库的对比数据：

对比项	Blackwell B200	Rubin R200	提升比例
晶体管数	2080 亿	3360 亿	1.6 倍
显存容量	192GB HBM3e	288GB HBM4	1.5 倍
显存带宽	8 TB/s	22 TB/s	2.75 倍
NVLink 带宽	1.8 TB/s	3.6 TB/s	2 倍
FP4 推理算力	~10 PFLOPS	50 PFLOPS	5 倍
TDP	1000W	1800-2300W	1.8-2.3 倍

HBM4 将单堆栈接口从 HBM3e 的 1024bit 翻倍到 2048bit，引脚速率提升至 10.8 GT/pin 左右。两个因素相乘，让单堆栈带宽突破 2.7 TB/s 量级——8 个堆栈聚合后达到 22 TB/s，相比 B200 的 8 TB/s 实现 2.75 倍提升。相比 B300 Ultra（288GB HBM3e、8 TB/s 带宽），容量持平但带宽提升 2.75 倍；而对比 B200 的 FP4 算力是 5 倍，对比 FP4 sparse 口径的 B300 Ultra 则约 3.3 倍。

值得注意的是 HBM4 的供货格局：三星、SK 海力士、美光三家多源供货，其中 SK 海力士 12 层 HBM4（36GB/堆栈、2.8 TB/s/堆栈、11 Gbps）已于 2026 年 7 月启动量产出货。多源策略显著降低了 NVIDIA 在 HBM4 时代的供应链风险。

NVLink 6 与 Vera Rubin NVL72​

单 GPU 的 NVLink 6 互联带宽达到 3.6 TB/s（双向），是上一代 1.8 TB/s 的整整两倍。在一个 NVL72 机柜内，72 颗 Rubin R200 与 36 颗 Vera CPU 全互联，机柜总 NVLink 带宽达 260 TB/s。

Vera Rubin NVL72 的机柜级规格（据站内芯片数据库）：

• 总算力：FP4 约 3.6 EFLOPS
• 总显存：20.7 TB HBM4
• 总带宽：1.58 PB/s
• TDP：约 180kW（必须全液冷）
• 定价：350-400 万美元

规划中的 Vera Rubin NVL144 将把 144 颗 Rubin R200 装进一个互联域，FP4 总算力约 7.2 EFLOPS，NVIDIA 宣称大模型推理成本可降至 Blackwell 平台的 1/10。

MLPerf 实测：99% 扩展效率意味着什么​

2026 年 9 月 16 日，Rubin R200 在 MLPerf Inference v6.1 上完成首秀：

测试项	对比基准（GB300 NVL72）	提升
Qwen3-VL 吞吐	同配置	最高 3.7 倍
DeepSeek-R1 吞吐	同配置	最高 2.5 倍
288 卡扩展效率	—	99%

99% 的 288 卡扩展效率是比峰值算力更有说服力的指标——它意味着 NVLink 6 与系统软件栈在跨机柜扩展时几乎没有"漏水"，集群规模翻倍时吞吐也近乎线性翻倍。对于按 token 计价的推理业务，NVIDIA 宣称 Rubin 平台的推理 token 成本最高可降 10 倍。

量产节奏与客户版图​

• CES 2026：NVIDIA 宣布 Vera Rubin NVL72 进入全面投产，H2 2026 出货；
• 首批客户：AWS 与微软率先确认；站内芯片数据库同时记录 CoreWeave、Google Cloud、Microsoft Azure、Oracle Cloud 的 NVL72 机柜已交付并扩大部署；
• OpenAI 合作：NVIDIA 计划与 OpenAI 合建的首个 1GW 数据中心将于 2026 H2 通过 Rubin 平台交付；
• 自建机房用户：2027 年第一季度可采购。

"七芯片堆栈"：R200 只是一部分​

理解 Rubin R200，不能只看这颗 GPU。Vera Rubin 平台的完整组成是七颗芯片：Vera CPU + Rubin GPU + NVLink 6 交换机 + ConnectX-9 SuperNIC + BlueField-4 DPU + Spectrum-6 以太网交换机 + Groq 3 LPX（专为智能体解码阶段设计的低延迟推理加速器）。

这套组合拳的逻辑很清晰：训练吃算力，推理吃带宽与延迟，而不同环节由不同架构的芯片承担，整体效率最高。GPU 负责训练与 prefill，Groq 3 LPX 负责智能体 decode 阶段的低延迟输出，网络芯片保证 72 乃至 576 卡像一个 GPU 一样工作。竞争对手要在单点芯片上追平 R200 的规格或许可行，但要复制整套系统，难度完全不在一个量级。

小结​

Rubin R200 是一次典型的"系统级代际跨越"：3360 亿晶体管和 50 PFLOPS FP4 是显性的规格领先，而 MCM 封装、HBM4 多源供货、NVLink 6 的 99% 扩展效率，以及七芯片堆栈的完整生态，才是 350-400 万美元机柜定价背后的真正护城河。H2 2026 大规模出货后，AI 算力市场的竞争焦点将进一步从"单芯片跑分"转向"每 token 成本"——这正是 Rubin 平台设计之初就瞄准的战场。

当 Rubin R200 还在陆续爬坡之际，NVIDIA 的下一个两年已经被写进路线图：2027 H2 的 Rubin Ultra 与 2028 年的 Feynman。但与以往"官宣即定型"不同，Rubin Ultra 在 2026 年经历了一次罕见的架构大改——原版 4 芯片设计被取消。本文依据站内芯片数据库与行业路线图口径，拆解这次调整背后的工程与商业逻辑。

Rubin Ultra（V300）：从官宣到修订​

Rubin Ultra 在 GTC 2026（2026-03-17）与 Rubin R200 一同公布，定位超大规模训练/推理的顶端产品。据站内芯片数据库，其原版设计规格如下：

规格	参数（原版设计，待官方最终确认）
GPU 架构	Rubin 架构（MCM 多芯片模块）
封装	原版 4 芯片设计（已取消）
FP4 推理算力	推测约 100 PFLOPS（原版，密集）
FP8 训练算力	推测约 70 PFLOPS（原版）
显存容量	576 GB HBM4e（原版设计）
显存带宽	推测 >44 TB/s（HBM4e）
互联技术	NVLink 7（推测，单向 >3.6 TB/s）
TDP	推测 3000W+（必须液冷）
量产时间	推测 2027 H2 – 2028
定价	推测单 NVL144 机柜 1500-2100 万美元

原版 NVL144 机柜配置为 144 颗 Rubin Ultra GPU + 72 颗 Vera CPU，总显存 82.9 TB HBM4e，FP4 总算力推测约 14 EFLOPS，TDP 推测约 360kW——是 Vera Rubin NVL72（约 180kW）的整整一倍。

关键调整：4 芯片设计取消​

2026 年最重要的路线图变化，是据 SemiAnalysis 报道，原版 4 芯片 Rubin Ultra 设计因封装制造难度被取消，新版规模缩减约一半、性能相应减半，仅保留 2 芯片版本——规模扩展能力弱于原设计。站内芯片数据库也明确记录了这一调整。

与之相伴的是显存减配传闻：2026 年 9 月，SemiAnalysis 与科创板日报报道 Rubin Ultra 的 HBM 配置拟从 HBM4E 12-Hi（384GB 档）下调至 HBM4 8-Hi（192GB），三星配合开发 8 层产品。动因是 HBM/DRAM 涨价后内存已占整机 TCO 约 40%，减配后 HBM 成本可降超 50%；省下的预算转向 Scale-up 纵向扩展网络——以 NVL576 NPO 方案测算，Scale-up 网络占机架支出比例将从 4% 升至 12%。TrendForce 显示 NVIDIA 自 2026 Q3 起并行评估 HBM4E 8-Hi、HBM4E 12-Hi、HBM4 8-Hi 多套方案。

行业路线图口径：VR300 NVL576 与 Feynman​

行业路线图汇总口径（Thunder Compute，2026-10）给出了另一个观察视角，需注意与 GTC 2026 原版公布信息存在差异，最终以官方为准：

产品	目标时间	关键规格（行业口径）
Rubin Ultra VR300	2027 H2	100 PFLOPS FP4/GPU、1TB HBM4e、NVL576、机架约 600kW
Feynman	2028	规格未公布（preliminary/未确认）

这个口径下的 VR300 与站内数据库记录的原版 NVL144（576GB HBM4e/GPU）明显不同：单卡显存更高（1TB）、机柜规模更大（NVL576）、单机架功耗推高到约 600kW。两条信息线的分歧恰恰说明 Rubin Ultra 仍处于架构修订期，唯一确定的是方向——显存继续翻倍、机柜规模继续翻倍、功耗继续飙升。

一年一代：与客户 capex 的绑定节奏​

从 Hopper（2022）到 Blackwell（2024）再到 Rubin（2026），NVIDIA 已把旗舰产品节奏锁定为两年一代；而在同一代际内部，GB200→GB300 的中期升级又把"可买的最新品"刷新周期压缩到约一年。这种节奏对客户 capex 形成了强绑定：

• 锁定采购：超大规模云厂商若想保持算力性价比领先，必须按 NVIDIA 的节奏滚动下单，否则两年后单位算力成本被拉开数倍；
• 规划反推：Rubin Ultra 的 2027 H2 时间点，意味着客户 2026 年就要锁定机位、电力与液冷改造——约 600kW/机架的功耗口径直接改写数据中心设计规范；
• 竞争挤压：AMD Helios II/MI500 同样瞄准 2027 年窗口，NVIDIA 把 Rubin Ultra 顶在 2027 H2，本质上是在客户年度预算分配前抢先占位。

HBM4e 供给与功耗：砍半的真实原因​

Rubin Ultra"砍半"并非技术退缩，而是三重现实约束的交汇：

1. 封装良率：4 颗计算 die 的 MCM 封装对 CoWoS-L 工艺的良率要求过高，量产风险不可控；
2. HBM 成本：内存占 TCO 40% 的现实下，576GB→192GB 档的减配能省下过半 HBM 预算；
3. 功耗墙：原版 360kW 乃至行业口径 600kW 的机架功耗，正在逼近现有液冷基础设施与供电改造的承受极限。

省下的预算被重新分配给 Scale-up 网络——这透露出 NVIDIA 的判断：下一代旗舰的瓶颈不在单卡 FLOPS，而在机柜内纵向扩展的互联效率。光互联（NPO）进入 Scale-up 网络，就是这个判断的落地。

Feynman：2028 的悬念与命名暗示​

Feynman 目标 2028 年，目前规格完全未公布（preliminary/未确认）。但命名本身已传递信息——继以物理学家命名的传统（Fermi、Maxwell、Volta），Feynman（理查德·费曼）指向的是量子电动力学与路径积分的缔造者。行业普遍猜测其架构方向可能包括：更激进的近存计算、光子互联的规模化引入，以及面向 agentic AI 负载的原生优化。考虑到 NVIDIA 2026 年收购 Groq 后已在 LPU 架构上积累经验，Feynman 完全可能首次把"训练芯片"与"推理加速器"在架构层面统一调度。

不过需要冷静看待：NVIDIA 的公开路线图历来在临近发布时大幅修订，Feynman 的最终形态大概率与今天的任何猜测都不同。

与 AMD Helios II/MI500 的时间赛跑​

2027 年的正面交锋已经排定：AMD 的 Helios II 机架与 MI500 系列瞄准同一时间窗口。AMD 的打法是开放生态（UALink、开放 HBM4/4e 规格）+ 激进显存（延续 MI400 432GB HBM4 的堆料路线），而 NVIDIA 则以 NVLink 域规模与 CUDA 软件栈守正。Rubin Ultra 的架构修订，某种意义上正是对 AMD 显存策略的回应——当单卡显存竞争的成本效益递减时，把预算转向 Scale-up 网络与系统效率是更聪明的花法。

小结​

NVIDIA 2027-2028 路线图的核心叙事是"从堆规格到堆系统"：Rubin Ultra 取消 4 芯片设计、显存减配、预算转向 Scale-up 光互联，是 HBM4e 供给与功耗现实下的理性选择；行业口径中 2027 H2 的 VR300 NVL576 与 2028 年的 Feynman，则勾勒出机架功耗迈向 600kW、架构走向异构统一的下一幕。对采购方而言，最重要的不是记住这些规格数字，而是理解一年一代节奏下"早买早享受、晚买享折扣"的 capex 决策模型正在失效——不跟上节奏，两年后的单位算力成本差距将大到无法用预算延迟来弥补。

当整个行业在"堆算力"上内卷时，SambaNova 选择回答另一个问题：推理效率取决于喂饱计算单元的能力，而不只是计算单元本身。

RDU：可重构数据流架构​

SN40L 的核心是可重构数据流单元（Reconfigurable Dataflow Unit，RDU）。它没有采用传统的"CPU 式取指执行"或"GPU 式 SIMT"，而是把计算组织成可编程的数据流图：每个 RDU 插槽包含 1040 个模式计算单元（PCU）与 1040 个模式内存单元（PMU），通过可编程的数据流网络互连。

芯片采用台积电 5nm 工艺与 2.5D CoWoS 封装，集成两个 RDU 计算裸片，单插槽峰值算力为 638 TFLOPS（BF16），片上聚合内存带宽达数百 TB/s 量级。这种架构最大的价值在于算子融合：编译器可以把数百个复杂操作合并为一次内核调用，把中间结果留在片上。以论文中给出的 Monarch FFT 为例，未融合时算术强度为每字节约 39.5 次操作，完全空间融合后提升至约 410 次——外部访存需求大幅下降。

三层内存：SRAM、HBM、DDR 各司其职​

SN40L 最具辨识度的设计是三层内存体系：

内存层级	容量（每芯片）	角色
片上 SRAM（PMU）	520 MB	最高带宽，紧贴计算单元
片上 HBM（封装内）	64 GB	存放正在运行的模型与热点数据
可插拔 DDR DRAM	最高 1.5 TB	存放更多模型与检查点

这个设计的巧思在于容量与成本的平衡：HBM 贵而小，DDR 便宜而大。模型从 DDR 加载到 HBM 的速度超过 1 TB/s，因此一套 16 芯片的 SambaRack 拥有 24TB DDR，可以在单系统中驻留 DeepSeek-R1 671B 这样的大模型，也能同时服务大量小模型。SambaNova 披露，在混合专家推理部署中，SN40L 相比 DGX H100 端到端提速 3.7 倍，模型切换时间提升 15 至 31 倍，机房占地最多缩减 19 倍；整rack采用风冷，功耗约 10kW，远低于晶圆级方案的 23kW 水冷系统。

企业推理的差异化路线​

SambaNova 与 Cerebras、Groq 的公开对比揭示了路线差异：Cerebras 擅长单用户极致 token 速度，但 SambaNova 指出其每片 LPU 仅约 230MB SRAM、无片外内存，服务 70B 模型需要数百颗芯片；而 SN40L 用 16 颗芯片即可完成同类部署。换句话说，SambaNova 押注的是"多用户、多模型、企业级"的推理经济学，而非单点跑分。

据公开报道，2026 年 2 月 SambaNova 发布了下一代 SN50 芯片，宣称面向智能体 AI 工作负载提供 3.2 PFLOPS FP8 算力，三层内存可支持高达 10 万亿参数模型，软银成为首个客户，公司同期完成超过 3.5 亿美元融资，并宣布与 Intel 展开多年期软硬件协同合作。

小结与建议​

SN40L 的启示在于：推理时代的竞争正在从峰值算力转向"单位 token 的系统经济学"。如果你的业务是多租户、多模型的企业 AI 平台，或需要频繁切换模型、在私有环境部署超大模型，三层内存架构提供了 GPU 集群难以复制的容量弹性；如果追求单用户最低延迟，晶圆级与 LPU 路线可能更合适。选型的关键，是先弄清自己的负载形状。

当业务里有大量重复系统提示词、多轮对话历史或 RAG 共享文档时，vLLM 的 PagedAttention 只能做页级缓存，而 SGLang 的 RadixAttention 能把前缀 KV Cache 的复用率推到极高。这正是它被 DeepSeek 官方推荐的原因。

RadixAttention 到底省在哪​

传统推理框架里，每个请求都要为相同的前缀重复计算 KV Cache。SGLang 把已计算的 KV Cache 存进一棵基数树，新请求到来时先做前缀匹配，命中部分直接复用，只计算增量部分。社区实测数据显示：

场景	SGLang 缓存命中率	传统无前缀缓存方案
Few-shot 学习	85% 至 95%	接近 0
多轮对话	75% 至 90%	接近 0
RAG 共享文档	显著命中	接近 0

命中率直接转化为首 token 时延下降与吞吐提升。在重前缀负载的独立评测中，SGLang 相比 vLLM 有 29% 至 50% 的吞吐优势；而在单轮、无前缀共享的自由文本场景，两者差距很小，选型时要先看清自己的流量画像。

另外两个性能引擎​

零开销 CPU 调度器：传统调度是 CPU 准备批次、GPU 计算、再准备下一批的串行流程，GPU 在调度期间空转。SGLang 用流水线方式让 CPU 准备批次与 GPU 计算重叠，持续负载下 GPU 利用率可逼近满载。

结构化输出：Agent 应用要求模型严格输出合法 JSON。SGLang 把格式约束编译成有限状态机，每生成一个 token 都限制下一个可选 token 范围，从源头保证格式合法，避免了"生成后校验失败再重试"的浪费，底层通过 xgrammar 实现高速约束。

生产环境关键配置​

1. PD 分离：Prefill 是计算密集型，Decode 是访存密集型，两者资源画像冲突。SGLang 支持 Prefill/Decode 分离部署，通过 RDMA 高速网络连接，能显著降低每 token 平均生成时间并提升整体吞吐。DeepSeek 部署实践曾基于 96 张 H100 的 PD 分离加大规模专家并行，跑出接近官方报告的吞吐水平。
2. 显存与调度参数：结合业务上下文长度设置 max-total-tokens，避免 KV Cache 池过小导致频繁淘汰；高并发短输出场景可调大并行批处理窗口。
3. 硬件覆盖：SGLang 原生支持 NVIDIA、AMD、Intel Xeon、Google TPU 与昇腾 NPU，截至发稿社区数据显示其已在超过 40 万张 GPU 上运行，每天生成数万亿 token。
4. 版本管理：项目于 2025 年 3 月加入 PyTorch 生态，由 LMSYS 托管，迭代速度快、API 变动频繁，建议镜像锁版本，升级前跑回归。

实操建议​

上线前先统计业务的系统提示词与文档前缀重复度，重复度越高，SGLang 的相对收益越大。开启结构化输出时要给出精简的 JSON Schema，约束越细生成越快。如果团队已经在用 vLLM，可以按模型灰度切换并用同一套压测脚本对比 P99 时延与吞吐，用数据说话而不是跟风选型。