clm_f4f1d46c476549a1b64e48ca067f1ecc_r1

VR2R-0575::SPLIT02

回到這篇 SA Coverage

① SA Source

• Source: 開啟完整 SA 文章
• Section: GB200 Hardware Architecture - Component Supply Chain & BOM
• Line hint: 735

Context Before

While the VR NVL72 system features GPUs and scale-up switches that are connected by copper cables, the VR HGX system features servers consisting of eight Rubin GPUs and four NVLink Switch chips. The second meaningful difference between the NVL72 and HGX deployments is that the former has a scale-out bandwidth of 1.6T per GPU while the latter only has a scale-out bandwidth of 800G per GPU. How is it that all Rubin 200 deployments use CX-9 NICs even though some deployments have half the per GPU scale-out bandwidth?

The HGX Rubin NVL8 server consists of eight 800G CX-9 NIC packages – one NIC per GPU – which means that the scale-out bandwidth does not increase from its predecessor, the HGX B300 server. The Vera Rubin NVL72 deployment on the other hand doubles the per GPU scale-out bandwidth to 1.6T, but not by doubling the bandwidth per NIC. Rather, the “1.6T NIC” attached to each Rubin chip is comprised of two 800G CX-9 packages that is connected to the Vera CPU by PCIe Gen 6.0 lanes.

Evidence

Each compute tray on the VR NVL72 has eight 800G CX-9 NICs, but there are two possibilities for the number of OSFP cages - either one 1.6T OSFP cage per GPU for a total of 4 per compute tray, or two 800G OSFP cages per GPU for a total of 8 cages per compute tray. We think that the latter would be the more popular deployment assumption, and will be the base case for our discussion of scale-out networking architectures in later sections of the article.

Context After

Source: Nvidia VR NVL72 Component BoM and Power Budget Model

② Atomic Claim

Another VR NVL72 option uses two 800G OSFP cages per GPU, totaling eight per compute tray.

• Epistemic Mode: HYPOTHETICAL
• Mapping Status: COMPLETE

③ Semantic Frame

{
  "attribute": "OSFP_CONFIGURATION_OPTION",
  "context_nodes": [
    {
      "id": "04_knowledge_base/800G",
      "label": "800G"
    },
    {
      "id": "04_knowledge_base/OSFP (Octal Small Form-factor Pluggable)",
      "label": "OSFP"
    },
    {
      "id": "04_knowledge_base/GPU",
      "label": "GPU"
    },
    {
      "id": "04_knowledge_base/Compute Tray",
      "label": "compute tray"
    }
  ],
  "entity": {
    "id": "04_knowledge_base/VR NVL72",
    "label": "VR NVL72"
  },
  "frame_type": "ATTRIBUTE",
  "qualifiers": {
    "condition_text": null,
    "numeric_mentions": [],
    "temporal_mentions": []
  },
  "value": {
    "numeric_mentions": [],
    "value_text": "Another VR NVL72 option uses two 800G OSFP cages per GPU, totaling eight per compute tray."
  }
}

④ Canonical Entity Mapping

Role	Surface Label	Canonical Target
entity	VR NVL72	04_knowledge_base/VR NVL72
context_0	800G	800G
context_1	OSFP	04_knowledge_base/OSFP (Octal Small Form-factor Pluggable)
context_2	GPU	GPU
context_3	compute tray	04_knowledge_base/Compute Tray

⑤ V2 Draft（需要修正時直接編輯）

Inline repair

只編輯以下三個 Draft 區塊。完成後將 review_action 設為 REQUEST_REPAIR，再手動執行 Repair Preview。
執行腳本前，Draft 不會寫入 Claim Store 或 Graph。

V2 Atomic Claim Draft

Another VR NVL72 option uses two 800G OSFP cages per GPU, totaling eight per compute tray.

V2 Semantic Frame Draft

{
  "attribute": "OSFP_CONFIGURATION_OPTION",
  "context_nodes": [
    {
      "id": "04_knowledge_base/800G",
      "label": "800G"
    },
    {
      "id": "04_knowledge_base/OSFP (Octal Small Form-factor Pluggable)",
      "label": "OSFP"
    },
    {
      "id": "04_knowledge_base/GPU",
      "label": "GPU"
    },
    {
      "id": "04_knowledge_base/Compute Tray",
      "label": "compute tray"
    }
  ],
  "entity": {
    "id": "04_knowledge_base/VR NVL72",
    "label": "VR NVL72"
  },
  "frame_type": "ATTRIBUTE",
  "qualifiers": {
    "condition_text": null,
    "numeric_mentions": [],
    "temporal_mentions": []
  },
  "value": {
    "numeric_mentions": [],
    "value_text": "Another VR NVL72 option uses two 800G OSFP cages per GPU, totaling eight per compute tray."
  }
}

V2 Revision Metadata Draft

{
  "epistemic_mode": "HYPOTHETICAL",
  "mapping_status": "COMPLETE"
}

⑥ Human Review

請在 Properties 逐項確認：

• 原文 → Atomic Claim 是否忠實
• Atomic Claim → Semantic Frame 是否忠實
• Canonical Entity mapping 是否正確
• Epistemic mode 是否保留原文語氣
• 最後選擇 review_action

Review state

Markdown 內文不是正式 approval。只有 Apply bridge 寫入的 Decision Ledger event 才是正式決策。