VR2R-0212::SPLIT02
① SA Source
- Source: 開啟完整 SA 文章
- Section:
BlueField-4 - Line hint:
319
Context Before
Source: Nvidia VR NVL72 BoM and Power Budget Model ↗
Evidence
The BlueField-4 DPU sits in center of the front of the chassis between the left-side Orchid module and the management module. As mentioned in the sections above, BlueField-4 is made up of a Grace CPU and a CX-9 NIC. The module also comes with 128GByte of on board LPDDR5x, 512Gbyte of on board pluggable SSD and an integrated AST2600 BMC from Aspeed. In the reference design of the VR NVL72 compute tray, BlueField-4 acts as a DPU providing up to 800Gb/s of front end networking capability. However, just like BlueField-3, BlueField-4 will only be adopted by a handful of customers, namely CoreWeave and other smaller Neoclouds customers who have less customization capability. For most hyperscalers’ deployments, the BlueField-4 module will be replaced with their in-house frontend networking module or simply with a CX-9 which is cheaper.
Context After
Speaking of BlueField-4, it is important to discuss the new offering Jensen highlighted at CES earlier this year: ICMS, or Inference Context Memory Storage — a platform that we hear may be rebranded to “CMX” at GTC. ICMS, or CMX, introduces a third, entirely separate network dedicated solely to context memory. CMX is a purpose-built KV cache fabric. As long-context inference pushes context windows toward millions of tokens and agentic concurrency scales across users and services, the current memory hierarchy used to store KVcache begins to look insufficient.
KV cache grows linearly with sequence length and multiplicatively with workload parallelism, quickly expanding beyond what any single tier of memory was designed to hold. GPU HBM, while unmatched in bandwidth and latency, is not enough on its own to store KV especially for longer sequence length queries that are becoming popular between turns or tool calls. Host DRAM extends capacity but remains node-bound and limited in aggregate footprint and ultimately has limited capacity. Meanwhile, traditional shared storage—architected for durability rather than latency —has more access time and power overhead, making it unsuitable for participation in the decode loop.
② Atomic Claim
BlueField-4 contains a CX-9 NIC.
- Epistemic Mode:
ASSERTED - Mapping Status:
COMPLETE
③ Semantic Frame
{
"additional_nodes": [
{
"id": "04_knowledge_base/NIC",
"label": "NIC"
}
],
"frame_type": "RELATION",
"object": {
"id": "04_knowledge_base/ConnectX-9",
"label": "CX-9"
},
"predicate": "CONTAINS",
"qualifiers": {
"condition_text": null,
"numeric_mentions": [],
"temporal_mentions": []
},
"subject": {
"id": "04_knowledge_base/BlueField-4",
"label": "BlueField-4"
}
}④ Canonical Entity Mapping
| Role | Surface Label | Canonical Target |
|---|---|---|
| subject | BlueField-4 | BlueField-4 |
| object | CX-9 | ConnectX-9 |
| additional_0 | NIC | NIC |
⑤ V2 Draft（需要修正時直接編輯）
Inline repair
只編輯以下三個 Draft 區塊。完成後將
review_action設為REQUEST_REPAIR，再手動執行 Repair Preview。
執行腳本前，Draft 不會寫入 Claim Store 或 Graph。
V2 Atomic Claim Draft
BlueField-4 contains a CX-9 NIC.
V2 Semantic Frame Draft
{
"additional_nodes": [
{
"id": "04_knowledge_base/NIC",
"label": "NIC"
}
],
"frame_type": "RELATION",
"object": {
"id": "04_knowledge_base/ConnectX-9",
"label": "CX-9"
},
"predicate": "CONTAINS",
"qualifiers": {
"condition_text": null,
"numeric_mentions": [],
"temporal_mentions": []
},
"subject": {
"id": "04_knowledge_base/BlueField-4",
"label": "BlueField-4"
}
}V2 Revision Metadata Draft
{
"epistemic_mode": "ASSERTED",
"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 才是正式決策。