SA260324R-0015::SPLIT03
① SA Source
- Source: 開啟完整 SA 文章
- Section:
Groq - Line hint:
27
Context Before
This is our GTC 2026 recap, and we will address many of the key questions that have been left unanswered by Nvidia. Specifically, we will go through the LPX rack and LP30 chip and explain how attention and feed forward network disaggregation (AFD) works; more details on the various rack architectures behind NVL144, NVL576, and NVL1152 and clarify just how much optics will be inserted as well as the rationale behind the dense Vera ETL256. The next generation Kyber rack had some big updates and some hidden details.
Groq
Evidence
First up is the Groq LPU. One of the most significant recent events in AI infrastructure was Nvidia’s “acquisition” of Groq. Strictly speaking, Nvidia paid Groq $20B to license their IP and hire most the team. This functions almost as an acquisition, though its structure technically falls short of it being legally considered as one, thereby simplifying or obviating the need for regulatory approvals. Given Nvidia’s market share, if this transaction were structured as a full acquisition and were put to anti-trust review, such a transaction would likely not go through. The other benefit is that it avoids a drawn-out transaction closing process. Nvidia got instant access to Groq’s IP and people. This is why, less than four months after the deal was announced, Nvidia already has a system concept that is being integrated into the Vera Rubin inference stack.
Context After
Let’s now go through a refresher on the LPU architecture to see how Groq’s LPU complements Nvidia’s GPU. For more details see our original Groq piece. ↗ The premise from that piece remains unchanged: the standalone Groq LPU system is not economical for serving tokens at scale, but it can serve tokens very quickly which can demand a large market premium. This is the premise behind how LPU fits into a disaggregated decode system.
LPU chip
② Atomic Claim
SemiAnalysis states: 由於這項交易在法律上不構成正式收購，因此可簡化、甚至免除監管核准需求。
- Epistemic Mode:
ATTRIBUTED - Mapping Status:
CLAIM_ONLY
③ Semantic Frame
{
"frame_type": "CLAIM_ONLY",
"qualifiers": {
"condition_text": "because the transaction legally falls short of a formal acquisition",
"numeric_mentions": [],
"temporal_mentions": []
},
"reason": "GENERIC_REGULATORY_APPROVAL_PROCESS_NOT_CANONICALIZED",
"statement": "SemiAnalysis states: 由於這項交易在法律上不構成正式收購，因此可簡化、甚至免除監管核准需求。"
}④ Canonical Entity Mapping
- 此
CLAIM_ONLYrevision 沒有 canonical Entity mapping。
⑤ V2 Draft（需要修正時直接編輯）
Inline repair
只編輯以下三個 Draft 區塊。完成後將
review_action設為REQUEST_REPAIR，再手動執行 Repair Preview。
執行腳本前，Draft 不會寫入 Claim Store 或 Graph。
V2 Atomic Claim Draft
SemiAnalysis states: 由於這項交易在法律上不構成正式收購，因此可簡化、甚至免除監管核准需求。
V2 Semantic Frame Draft
{
"frame_type": "CLAIM_ONLY",
"qualifiers": {
"condition_text": "because the transaction legally falls short of a formal acquisition",
"numeric_mentions": [],
"temporal_mentions": []
},
"reason": "GENERIC_REGULATORY_APPROVAL_PROCESS_NOT_CANONICALIZED",
"statement": "SemiAnalysis states: 由於這項交易在法律上不構成正式收購，因此可簡化、甚至免除監管核准需求。"
}V2 Revision Metadata Draft
{
"epistemic_mode": "ATTRIBUTED",
"mapping_status": "CLAIM_ONLY"
}⑥ 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 才是正式決策。