VR2R-0237
① SA Source
- Source: 開啟完整 SA 文章
- Section:
BlueField-4 - Line hint:
329
Context Before
As we noted in mid-January in our Memory Model note ↗, Nvidia’s ICMS inserts a new G3.5 tier between local SSD (G3) and shared storage (G4), optimized specifically for ephemeral, recomputable KV cache. The ICMS requires a dedicated networking layer designed exclusively for KV traffic. Wherever networking is used in this architecture, it is provisioned as a context memory network — isolated from general data movement and optimized for predictable decode latency.
The challenge with this is that the volumes of SSDs going to ICMS / CMX are quite overblown by the industry. We worked through the math in the Memory model ↗ and Tokenomics model ↗.
Evidence
BlueField-4 will be the silicon anchor of this third network. Positioned on the storage array, it terminates NVMe-oF and RDMA traffic at line rate and manages KV movement independently of host CPUs and GPUs. With 2×400G SerDes links providing 800Gb/s of bandwidth, integrated Grace CPU, and LPDDR, BlueField-4 would act as the controller for a distributed context memory fabric. In a preferred DGX-style configuration, a single BlueField-4 per tray may serve four Rubin processors, with the DPU dedicated purely to KV cache traffic and not shared with generic storage I/O.
Context After
The new CMX/ICMS ecosystem will likely include leading storage providers such as Weka, DDN, Dell Technologies, NetApp, VAST Data, and others.
Power Delivery
② Atomic Claim
在偏好的 DGX-style configuration 中，每個 tray 可能配置 1 顆 BlueField-4，服務 4 顆 Rubin processors。
- Epistemic Mode:
HYPOTHETICAL - Mapping Status:
COMPLETE
③ Semantic Frame
{
"frame_type": "NARY_RELATION",
"participants": [
{
"node": {
"id": "04_knowledge_base/BlueField-4",
"label": "BlueField-4"
},
"role": "controller"
},
{
"node": {
"id": "04_knowledge_base/Vera Rubin",
"label": "Rubin"
},
"role": "processor"
}
],
"qualifiers": {
"condition_text": "preferred DGX-style configuration; hypothetical",
"numeric_mentions": [
"1",
"4"
],
"temporal_mentions": []
},
"relation_type": "BLUEFIELD4_SERVES_RUBIN_PROCESSORS_PER_TRAY"
}④ Canonical Entity Mapping
| Role | Surface Label | Canonical Target |
|---|---|---|
| controller | BlueField-4 | BlueField-4 |
| processor | Rubin | 04_knowledge_base/Vera Rubin |
⑤ V2 Draft（需要修正時直接編輯）
Inline repair
只編輯以下三個 Draft 區塊。完成後將
review_action設為REQUEST_REPAIR，再手動執行 Repair Preview。
執行腳本前，Draft 不會寫入 Claim Store 或 Graph。
V2 Atomic Claim Draft
在偏好的 DGX-style configuration 中，每個 tray 可能配置 1 顆 BlueField-4，服務 4 顆 Rubin processors。
V2 Semantic Frame Draft
{
"frame_type": "NARY_RELATION",
"participants": [
{
"node": {
"id": "04_knowledge_base/BlueField-4",
"label": "BlueField-4"
},
"role": "controller"
},
{
"node": {
"id": "04_knowledge_base/Vera Rubin",
"label": "Rubin"
},
"role": "processor"
}
],
"qualifiers": {
"condition_text": "preferred DGX-style configuration; hypothetical",
"numeric_mentions": [
"1",
"4"
],
"temporal_mentions": []
},
"relation_type": "BLUEFIELD4_SERVES_RUBIN_PROCESSORS_PER_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 才是正式決策。