SA260324R-0120
① SA Source
- Source: 開啟完整 SA 文章
- Section:
GPU and LPU Integration: Attention FFN Disaggregation (AFD) - Line hint:
137
Context Before
With AFD, token routing from GPUs to LPUs can become the bottleneck, especially under strict latency constraints. The token routing flow involves two operations: dispatch and combine. In the dispatch step, we route each token to their top k experts with an All-to-All collective operation. After experts complete their computation, we perform the combine step, where the outputs are sent back to the source location with a reverse All-to-All collective, continuing the next layer’s computation.
Evidence
To hide the communication latency of dispatch and combine, we employ ping pong pipeline parallelism.
Context After
In addition to splitting batches into micro-batches and computation pipelining like standard pipeline parallelism, the tokens dispatched to the LPUs are combined back to the source GPUs, so they ping pong between the GPUs and the LPUs.
② Atomic Claim
為了隱藏 dispatch 與 combine 的 communication latency，系統採用 ping-pong pipeline parallelism。
- Epistemic Mode:
ASSERTED - Mapping Status:
PARTIAL
③ Semantic Frame
{
"attribute": "USAGE",
"context_nodes": [],
"entity": {
"id": "04_knowledge_base/Pipeline parallelism",
"label": "pipeline parallelism"
},
"frame_type": "ATTRIBUTE",
"qualifiers": {
"condition_text": "dispatch 與 combine 在此 claim 沒有 canonical entity",
"numeric_mentions": [],
"temporal_mentions": []
},
"value": {
"numeric_mentions": [],
"value_text": "以 ping-pong 方式使用，用來隱藏 dispatch 與 combine 的 communication latency。"
}
}④ Canonical Entity Mapping
| Role | Surface Label | Canonical Target |
|---|---|---|
| entity | pipeline parallelism | 04_knowledge_base/Pipeline parallelism |
⑤ 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 才是正式決策。