title

SMPDC Paper 09｜記憶體階層與微觀硬體映射：快取、CCD／NUMA、實體互連、資料局部性與成本邊界

english_title

Memory Hierarchy and Microarchitectural Mapping: Cache, CCD/NUMA, Physical Interconnects, Data Locality, and Cost Boundaries

series

SMPDC — Stellar Multi-Primary Persistent Diffusive Computing

paper

09 / 11

version

0.1

date

2026-10-17

language

zh-TW

status

Full Research Manuscript — Candidate Hardware Locality and Cost Contract; Formal and Experimental Design; Physical Validation Pending

primary_concept_originator

Neo.K

research_collaboration

Aletheia / GPT-6

institution

EveMissLab / 一言諾科技有限公司

canonical_source

UTF-8 Markdown; inline mathematics $...$ ; display mathematics $$...$$

predecessors

SMPDC Paper 00–08 v0.1

artifact_scope

Physical topology discovery, cache/CCD/NUMA mapping, atomic coherence, CPU–GPU memory transfer, bounded redundancy, hardware cost profiling, falsifiable placement, memory and energy budgets, optional future ISA/NoC candidates

SMPDC Paper 09｜記憶體階層與微觀硬體映射

——快取、CCD／NUMA、實體互連、資料局部性與成本邊界

英文題名： Memory Hierarchy and Microarchitectural Mapping: Cache, CCD/NUMA, Physical Interconnects, Data Locality, and Cost Boundaries
研究系列： 群星多主節點持續擴散計算論（SMPDC）
主構想提出： Neo.K
研究協作： Aletheia／GPT-6
機構： EveMissLab／一言諾科技有限公司
日期／版本： 2026-10-17／v0.1
研究成熟度： L1。已建立形式候選、硬體映射契約、條件命題、反例與基準規格；沒有宣稱已完成真實微架構測量、RTL、FPGA、晶片設計、GPU 加速驗證或 AI 訓練加速。
直接依賴： SMPDC Paper 00–08 [I0–I8]。
公開查核： AMD、Intel、Linux Kernel、Microsoft、NVIDIA、hwloc、AMD uProf、Intel VTune 與 C++ 記憶體模型參考資料，查核截至 2026-10-17 [E1–E16]。

作者： Neo.K
日期： 2026-10-17
版本： 0.1

摘要

SMPDC 原始構想從多個 CPU 大核／小核皆可維持獨立主要工作流開始，透過相位呼叫形成動態耦合，由適用的 GPU 並行運算處理大量資訊關係，並允許受控冗餘訊息先行、主節點局部合併、再交由具有權限的仲裁域決定正式提交。Paper 00–08 已逐步定義主要工作流節點（Primary Workflow Node, PWN）、有界相位擴散、不可複製的傳播 credit、R0–R3 冗餘、推測與確定性提交、PDAIS 指令中介表示、語言型別／效果檢查、OS／可選 AI 控制平面，以及 CPU–GPU 設備協作。這些定義主要存在於邏輯、中觀與宏觀執行層；它們不要求微觀晶片採用圓形互連、神經元式電路、單一共享匯流排或把 GPU 當作 CPU–CPU 的實體捷徑。

本文填補邏輯架構與可用硬體之間的映射缺口。核心問題不再是「任務可以擴散到哪個節點」的抽象圖示，而是：當 PWN 的承載位置、工作集合、cache line 所有權、CCD／die／cluster、OS NUMA node、記憶體頁、CPU–GPU buffer、PCIe 路徑及同步權限皆可能不同時，如何在實體可觀測限制下決定哪些擴散、冗餘、預先配置、資料複製、重新計算與設備 offload 值得執行？

本文提出 SMPDC Hardware Locality & Cost Contract v0.1（縮寫 HLC09，限本文命名空間），包含 HardwareTopologyManifestV0_1、HardwareLocalityGraphV0_1、MemoryResidenceLeaseV0_1、HardwareCostProfileV0_1、PlacementCostEnvelopeV0_1、MemoryVisibilityGuardV0_1、BottleneckEvidenceV0_1 和 HardwarePlacementTraceV0_1。以分層加權圖表示實體計算與儲存域，以可驗證的 PWN-to-carrier 投影連結 Paper 00 的九元狀態，並將分配決策建立在測量所得的延遲分布、可用頻寬、快取衝突、重送流量、版本重驗證、能源及外部效果成本，而非單一「連線速度」常數之上。

本文特別區分五類常被誤認為同一個概念的邊界：(a) CPU 核心／邏輯處理器不等於 PWN；(b) CCD／晶片內部共享快取群不必等於 OS NUMA node；(c) CPU cache coherence 不等於跨 GPU memory domain 的通用一致性；(d) 冗餘傳輸提高容錯候選或縮短某些尾延遲，不等於免費頻寬或準確性證明；(e) 新抽象指令可映射到既有 x86／CUDA runtime，不代表已有任何新實體 ISA。對 Intel P/E 混合核心與 AMD 不對稱 3D V-Cache／CCD 平台，均要求實際列舉與量測；對目前的舊款 AMD CPU＋RTX 3070＋32 GB 系統，提供不需要立即購置昂貴處理器的 V0–V1 研究路線。

本文建立八項附前提命題、32 條硬體映射與一致性不變量、36 類故障反例、微基準與完整端到端對照實驗，並給出「何種觀測證據才足以提出自訂 NoC、FPGA 或 ISA 候選」的必要但不充分條件。正式結論是：SMPDC 的中宏觀執行模型可能使具有特定局部性、長壽工作流、稀疏動態耦合及可重用資料的工作負載產生收益；然而實體互連、快取容量、記憶體一致性與資料搬移構成不可任意繞過的下界。是否有優勢，必須與經過良好最佳化的傳統 CPU、多核心、NUMA-aware 與 CUDA 工作負載做等口徑比較。

關鍵詞： SMPDC、群星式多主節點、硬體局部性、cache coherence、false sharing、CCD、CCX、NUMA、SMT、P-core、E-core、記憶體階層、PCIe、GPU VRAM、DMA、memory ordering、DRAM、HardwareCostProfile、資料放置、可證偽微架構研究。

1. 研究問題與必要尺度分離

1.1 從群星拓撲圖到可量測的硬體現實

「群星」提供的是節點自治與動態關係的中宏觀計算表示，不是晶片布線設計圖。物理系統的快取、總線、ring、mesh、crossbar、die-to-die link、memory controller、PCIe 與裝置 VRAM 各有不同的延遲、帶寬、功耗、仲裁及一致性範圍。就算兩個邏輯節點在模型中相鄰，也不保證它們被映射到同一 cache domain、同一 CCD 或同一 NUMA node。

抽象的耦合邊 $e_{ij}\in E_t$ 表示「工作流間有一個受到相位、權限與流量限制的互動資格」。實體載體的路徑 $p_{ij}$ 則可能穿越多種記憶體與互連域，兩者必須由可觀測的映射函數橋接，而不能直接相等：

此式為否定錯誤推論，而非宣稱所有路徑必然昂貴。

1.2 五項正式研究問句

• RQ09-1 — 映射： 如何從 OS 與硬體能力列舉 CPU core、logical processor、共享 cache、die／CCD、NUMA、memory range 和 PCIe 裝置，並保持未知與不支援狀態？
• RQ09-2 — 成本： 相位擴散、R0–R3 傳送與主節點聚合在何種條件下受 cache line 搬移、記憶體頻寬、DRAM 延遲、跨 CCD 通訊或 GPU copy 所限制？
• RQ09-3 — 安全： 如何將 CPU 原子／記憶體順序、OS 資源授權、DMA buffer lease、GPU event 與 Paper 04 提交契約接成不產生未授權可見性的因果鏈？
• RQ09-4 — 異質性： Intel P/E core、AMD 不對稱 CCD cache 與 SMT 相互爭用，如何改變 PWN 放置策略，而不破壞工作流邏輯自治？
• RQ09-5 — 可證偽性： 何種硬體、工作負載與對照足以驗證「資料局部性敏感的 SMPDC」較既有最佳路線更有效？何種負面結果應明確接受？

1.3 本篇之刻意不主張

本篇不宣稱已設計或製造新的 CPU、GPU、NoC、記憶體控制器、晶片間封裝、相位振盪器或生物神經元電路；不宣稱新指令集已為 x86、ARM 或 RISC-V 硬體所支援；不把近似「神經網絡」的形態當作效能證明；不認為記憶體成本可以由圖像式路由憑空消失；不假設 Intel E-core 是可由應用任意操控的專用網路轉發器；也不假設 GPU 可以繞過 CPU cache-coherence protocol 替兩個 CPU core 直接交換資料。

研究成熟度保持 L1。 本文中的數值示例是人工構造的解析例；以後附錄的微型測試也只能驗證契約守衛，不能當成實體跑分。

1.4 範圍結構

2. 與 Paper 00–08 的不可變更承接

2.1 九元正規狀態與本文外接具體化

沿用 Paper 00 的九元中觀狀態：

其中 $V_t$ 為主工作流節點， $E_t$ 為受相位與權限約束的耦合， $\rho_t$ 為邏輯到執行承載的投影。Paper 08 另以 $\Gamma_t$ 描述 GPU executor 的具體狀態 [I8]。本篇引入的是實體觀測投影 $\mathcal H_t$，不是在 canonical 九元狀態中暗中加一條全新公理：

$C_t$ 為運算承載、 $K_t$ 為 cache domains、 $N_t$ 為記憶體／NUMA domains、 $D_t$ 為 GPU／DMA 等設備域、 $P_t$ 為探測所得物理關係圖、 $\Lambda_t$ 為所有權與 lease、 $\Omega_t$ 為觀測成本及能力。它能由 OS、硬體計數器、微基準或設備 API 觀測；缺少資料時可部分未知。

2.2 Paper 01 的 PWN 身分

flow_id 是長期存在的邏輯主要工作流身分，worker_id、logical_cpu_id、physical_core_id、cache_group_id、ccd_id、numa_node_id、gpu_device_id 都是不同識別。只有後者表示具體資源，且其中部分可能無法被所使用 OS 精確辨識。工作流執行緒被暫停、遷移或重新排程，不等於消滅或創造原 flow_id [I1]。

2.3 Paper 02 的 bounded phase diffusion

相位資格規則、message_id、lineage_id、delivery_attempt_id、event_epoch、傳播 credit、背壓及終止判定維持效力。快取中保存一份 payload、副本預先放進另一 NUMA node，不會自動生成額外的邏輯傳播 credit。頁面搬移與擴散訊息是兩種不同層次的操作 [I2]。

2.4 Paper 03 的 R0–R3

R0 是單路；R1 是多路競速；R2 是具來源條件的佐證；R3 是帶編碼義務的冗餘。R1 可降低某些尾延遲，但會消耗額外 cache／DRAM／PCIe 頻寬；R2 的來源獨立性不能由不同 cache line 自動建立；R3 的解碼能力取決於具體編碼及錯誤模型 [I3]。

2.5 Paper 04 的提交權威

CPU 原子 CAS、快取一致性、GPU event 完成或記憶體 barrier 都不直接授予 CommitProposalEnvelopeV0_1 的應用權威。硬體可以提供原子性、同步與可見性機制；應用層的隔離等級、版本讀集驗證、謂詞衝突、權威 epoch、不可重覆外部效果，仍需由 Paper 04 的交易契約保證 [I4]。

2.6 Paper 05–06 的語義保持

PDAIS-IR 及 SMPDC-Lang 將線性 credit、GPUBufferLease、HostVisible、Tentative、fencing 與能力檢查視為效果義務。本篇可新增 LOCALITY_HINT、MEMORY_REGION_HINT 或映射 metadata，不得把 hint 當作取代語義檢查的強制 ISA 指令，也不得用異質降階最佳化非法略過 owner/lease guard [I5–I6]。

2.7 Paper 07 的控制權與降級

AI 只可提出資源配置建議，OS／可信 runtime 決定實際可用 CPU affinity、memory policy 和 GPU buffer。當拓撲不明、profiling 資料過期、權限不足或 controller 出錯，系統必須回退至傳統 OS scheduler／安全配置，而不是宣稱 AI 掌握不可見的硬體真相 [I7]。

2.8 Paper 08 的 GPU event／buffer 契約

本篇承接 DeviceBufferLeaseV0_1、GpuDeviceCapabilitySnapshotV0_1、GpuExecutionTicketV0_1、DeviceVisibilityWitnessV0_1 與 GpuCollaborationTraceV0_1。Submitted、KernelDone、CopyDone、HostReadable、LocalVerified、Committed 必須可區分；物理資料放置改變時，不能把上一個執行 epoch 的完成見證直接套用在新 buffer 版本 [I8]。

3. 硬體局部性圖的形式核心

3.1 多類型分層圖而非單一環形圖

定義有限且帶不完整資訊的候選硬體圖：

其中 $U_t$ 的節點可以是 physical core、SMT sibling、cache domain、CCD／tile、OS NUMA node、DRAM bank domain、device memory region 或 I/O device； $F_t$ 表示由可觀測證據支援的「共享、包含、連線、親和、隸屬、傳輸」等帶型別關係， $\tau_U$ 、 $\tau_F$ 分別為節點與邊的型別， $\mathcal A_t$ 為觀測屬性與來源。若一個 CCD 的資訊無法取得，允許 ccd_id = unknown，不能由 CPU 行銷名稱推算而寫成已探測事實。

3.2 執行與記憶體位置的兩重投影

令 $p_i\in V_t$ 是一個 PWN， $m_k$ 是某個受控資料物件：

$\rho_t$ 是執行承載； $\mu_t$ 是資料常駐或近似放置的觀測。真正 cache residence 往往瞬態、不可任意鎖定，因此 $\mu_t$ 不等於可以永久保證某頁「就在 L2」。對 cache，應優先採用 likely_resident、shared_domain、measured_hit_ratio 類證據；對 DRAM page，則可在 OS 支援時使用 NUMA memory policy 或 page migration API。兩者的權限及時間尺度不同 [E3–E5]。

3.3 實體映射版本化

任何硬體位置決策使用 topology_epoch 與 placement_epoch：

這裡的 compatible 不一定要求 epoch 永遠完全相等；它必須證明使用的 topology facts 仍有效，例如可用 CPU 未被關閉、CPU Sets 未撤銷、GPU 裝置未重置、memory affinity 未因熱插拔失效。

3.4 圖上路徑成本不是物理最短路公式

對某 payload 的端到端工作，不能簡單把邏輯邊權重相加就當作時間，因為搬移、排隊、資料複製、計算與同步可能部分重疊，也可能互相阻塞。本文使用兩層模型：

僅作為無重疊之粗略成本或估計特徵；真實時延須以事件因果 DAG 的關鍵路徑長度和 trace 端到端結果測量。對相關性強的共享資源，不能假設 $c_e$ 彼此獨立。

3.5 非單調性

更高的擴散 fanout 不一定使總完成時間降低；更短的軟體佇列不一定較少 LLC miss；更多快取容量不一定改善小型 streaming workload；更高的記憶體頻率也不保證在同步密集型負載中取得更好效能。這些皆列為待測現象，不作為先驗定律。

4. 可觀測硬體拓撲與識別的證據邊界

4.1 Windows 的最小探測接口

Windows 可透過 GetLogicalProcessorInformationEx 列舉 processor core、cache、NUMA node、processor group、die 等關係，並由 CPU Sets、處理器群組與可用親和限制建立執行承載候選；不同 Windows 版本、韌體或裝置可能暴露不同粒度 [E6]。任何系統返回都要保留 source_api、queried_at、OS_build、group_id、cpu_set_id、error_code。

不能直接假定 Windows 顯示單一 NUMA node 就表示只有一個 CCD，或 NUMA node 數等於 CCD 數；有些系統會在單一 OS NUMA domain 內保留多個不對稱 cache 群。

4.2 Linux 的最小探測接口

Linux 可使用 /sys/devices/system/cpu/cpuX/topology/、cpuX/cache/indexY/、/sys/devices/system/node/、/proc/cpuinfo、numactl --hardware 與 hwloc 的拓撲抽象；可視系統能力搭配 sched_getaffinity、get_mempolicy、move_pages、mbind 等。OS 曝露資料不一定具有相同細緻度，hwloc 探測也需要對應的執行權限與正確容器可見範圍 [E4–E5, E7]。

taskset 可以限制 CPU 執行集合，但不能據此保證所有資料已遷移到該 CPU 的近端記憶體。numactl 的策略也不代表快取內容永久固定。

4.3 容器、虛擬機與 WSL

容器的 CPU Sets 可能小於 host 實際拓撲；虛擬機可提供虛擬 cache／NUMA 觀點；WSL 可能沒有 native Linux 一樣的 PMU 權限與精確 NUMA 資訊。承載已知、硬體拓撲未知是合法狀態；本篇不能將自動回退標記為實驗失敗以外的「已成功識別」。

4.4 硬體 manifest 的不變性假說不可過強

HardwareTopologyManifestV0_1 是某時刻、某權限視角下的版本化描述。CPU hotplug、BIOS 選項、驅動與 OS 更新、微碼、電源模式、停用 SMT、GPU reset 與虛擬化配置可能改變其有效性。測量時必須保存它，任何比較都需檢查原版本是否與實驗版本相容。

5. 快取階層：容量、共享域與寫入所有權

5.1 不是所有 L3 都是同一種資源

典型 CPU 可包含私有或部分共享的 L1、L2、LLC，以及不同 die／CCD 間的互連；實際配置依微架構與產品而不同。SMPDC 的 cache_group_id 必須透過探測或有可信依據的硬體文件辨識；不能在不對稱 cache 平台上只用「CPU 有 128 MB L3」就推斷所有核心對同一份資料享有同樣延遲與容量。

工作集合 $W_i$ 若適合某個快取域，可能獲得更高命中率；但快取是競爭性、替換性的資源。 $W_i<C_{cache}$ 只是粗略必要線索，不是命中率必然很高的充分條件。

5.2 Cache line 是實體一致性單位，並非軟體物件

兩個 thread 更新兩個不同欄位，若欄位落在同一一致性粒度，仍可能導致 false sharing。Intel 的最佳化手冊與 VTune 示範這類競爭造成的時間耗損 [E8–E9]。因此 PWN 的 local_state 雖是邏輯獨立，若其頻繁更新的 metadata、ring pointer、credit counter 被排在相鄰 cache line，依然可能反覆爭奪 cache line ownership。

不是所有平台一致性粒度都應硬編為 64 bytes。參考實作可以採 std::hardware_destructive_interference_size 作為部分 C++ 環境中的 hint，但其值、編譯選項、可攜性與實際硬體特性須驗證；在不支援平台採保守可配置 alignment，並記錄 manifest。

5.3 兩種不可混同的共享

• read_shared：多核心讀取同一份不可變資料，可能具有良好的 cache 共用局部性。
• write_contended：多核心頻繁寫入或原子更新共同位置，可能引發 cache coherence ownership 轉移、serialization 與 tail latency 擴大。

兩者在邏輯群星圖都可稱為「耦合」，但實體代價完全不同。R1 的多路複本如果每條路徑都原子寫入一個共享計數器，可能使冗餘的理論競速優勢被同一 hot cache line 消耗。

5.4 適合 PWN 的資料配置候選

優先研究「多讀者—單寫者」、「每節點 append-only journal＋批次發布」、「分離熱寫 metadata 與冷讀 payload」、「批次仲裁避免每訊息原子 RMW」，以及將常駐資料與活躍工作流放在共享 cache 群中的策略。所有候選均有 trade-off：批次可以節省同步成本，但會提高排隊等待；更大 buffer 降低頻繁配置，卻增加工作集合與快取污染。

6. 記憶體順序：硬體一致性與程式正確性的界線

6.1 CPU cache coherence 不等於任意程式都 race-free

硬體 cache coherence 通常處理某種粒度上的存取一致性，但程式語言記憶體模型還規範資料競爭、可見性與重排序。對 C++ 而言，普通非原子資料若被競爭性讀寫且缺乏 happens-before，可能構成 undefined behavior；不能因 x86 實務上較強的順序直覺就忽略 C++ 標準的約束 [E10]。

6.2 發布—取得的最低示例

以下為一個受限制的 CPU-side 示意，不是 SMPDC 全域提交：

struct Packet { uint64_t version; uint64_t checksum; };
Packet packet;
std::atomic<bool> ready{false};

// Producer: only one writer, packet cannot be modified while published.
packet = compute_packet();
ready.store(true, std::memory_order_release);

// Consumer: the acquire must observe the producer's published value.
if (ready.load(std::memory_order_acquire)) {
    verify(packet);
}

此示例只在「一次發布、沒有其他同時競爭性寫入、生命週期正確」前提下成立。複用旗標、環狀緩衝與多重 writer 需要 sequence、slot ownership、ABA 防護與完整的 ring protocol，不能直接套用。

6.3 relaxed 不是對 payload 的萬能發布方法

memory_order_relaxed 只提供所定義的原子保證與 modification order，不替其他非原子資料建立必要的發布—取得同步。若 payload 剛寫完，只更新 relaxed ready 而讓另一 CPU 讀取 payload，可能違反預期的 happens-before 關係 [E10]。

6.4 線性化點、提交點與 GPU event

「某個原子操作線性化」意味這個特定共享物件的操作能被賦予一致的觀測次序；但 Paper 04 的多鍵隔離、版本讀集、資料來源可信度及外部效果提交並不自動成立。GPU 上的 event 完成也要依設備 API 建立 host 可讀的正確依賴；CPU 端的一個原子 ready=true 不能替代 GPU transfer 完成與 buffer lifetime guard。

6.5 測試的關鍵

原子／鎖正確性使用 race detector、model-based stress、模擬排程與事件 trace 檢查；cache line 競爭則使用實體 profiling。安全測試 PASS 不推出記憶體效能好；性能跑分好不推出沒有 data race。

7. CCD／chiplet／tile：共享快取範圍和 OS NUMA 範圍不等同

7.1 拓撲詞彙分離

7.2 AMD Ryzen 9 9950X3D 作為不對稱快取研究樣本

AMD 官方資料顯示 9950X3D 為 Zen 5、16 核／32 執行緒、128 MB L3、170 W TDP；3D V-Cache 技術採堆疊快取設計 [E1–E2]。其 CCD 快取分布及可用的 OS 排程表現應由官方文件、系統探測及實測共同確認。對 SMPDC，這比單純「有 16 核」更重要：相同 PWN 的工作集合放在不同 cache group，可能產生不同的 memory-bound 成本和調度收益。

重要限制： 不能在尚未購買或未完成測量的情況下，將 9950X3D 的跨 CCD 延遲寫成某個確定數字，也不把它當成使用者已擁有的設備。

7.3 Intel Core Ultra 7 270K Plus 作為異質核心研究樣本

Intel 官方列示此 CPU 有 24 個實體核心（8 P-core、16 E-core）、24 執行緒、36 MB Smart Cache；基礎與加速功率配置依官方產品規格及平台限制而定 [E11]。此架構適合在 OS 可識別的 P/E 資源上研究不等算力的 PWN 承載與耦合，但不能由 P/E 數量推論每一組核心的共享 cache 邊界或相同工作負載的實際計算能力。

7.4 研究對比不是品牌戰

對 SMPDC，Intel P/E 測試軸主要是核心計算能力及資源共享異質性；AMD 9950X3D 主要是不對稱快取域及跨晶片局部性。這兩軸互相補充，但不是非此即彼。若只使用其中一台機器，也可以先驗證部分命題；不同硬體所能代表的實驗適用域應清楚標示。

8. SMT、P/E 與 CPU 主工作流的物理承載

8.1 「每個核心是一個主節點」是邏輯規範

SMPDC 的原始直覺是每個 CPU 大核、小核皆能作為主要工作流的承載，不是命令所有實體核心在任意時刻都必須滿載，也不是命令一個 PWN 永久綁定某 CPU。實作上，一個 PWN 可以暫停／喚醒／遷移；而同一實體 CPU 的兩個 SMT siblings 並不代表獨立的兩套完整執行資源。

8.2 Capacity 並非固定的 P/E 二元標籤

一個核心的 effective_capacity 會受 ISA、指令混合、頻率、功率預算、溫度、SMT 競爭、快取命中與記憶體壓力影響。控制器可用 P、E、Zen5-3DVCache、Zen5-Standard 之類的類別作為提示，但真正的 placement score 應使用工作負載相關的測試結果而非固定比例。

8.3 SMT 對照的最低要求

在支援 SMT 的平台，至少比較：一實體核心只跑一條工作流、同一核心兩個 SMT siblings 跑兩條、不同實體核心跑兩條、跨共享 cache 群或 CCD 跑兩條。要測量有效吞吐、p95/p99 延遲、cache miss、context switching、能源以及是否造成對其他系統工作的干擾。

8.4 不強制每核都承接消息

若某耦合邊的資料少、工作短、phase window 窄，固定派給每顆核心一份任務可能比一個良好的 thread pool 慢得多。控制器應有 do_not_diffuse、stay_local、merge_work、sleep_node 和 recompute_local 的合法決策。

9. NUMA：記憶體頁、CPU 親和性及遷移代價

9.1 OS NUMA 與 LLC 在不同層級

NUMA policy 決定 OS 能如何選擇頁面分配位置；其單位、分配範圍與控制能力不同於 L1／L2／LLC。Linux 透過 mbind、set_mempolicy、move_pages 等界面控制或觀測特定頁面的 NUMA 位置，配置政策與實際既存頁面位置也未必相同 [E4–E5]。

9.2 First-touch、頁面搬移與成本

首次寫入或 fault 可能影響頁面所在的 memory node；長壽 PWN 轉移到另一 core 並不保證原資料也被自動移到近端。搬移本身要耗費 memory bandwidth、CPU 核心時間，並可能暫停部分工作流；對高 churn data，頻繁遷移反而比容忍遠端存取更昂貴。

9.3 頁面放置策略比較

• local_preferred：偏好目前工作流所在記憶體域，可能提升局部存取，但多處讀寫者可能互相衝突。
• interleave：跨多個允許 memory nodes 分配，可能提升某些帶寬情境，但提高某些核心遠端存取比例。
• replicate_read_only：複製不變資料供多個 domain 就近讀取，代價是容量與版本管理。
• migrate_on_epoch：在可驗證的 epoch 邊界變更常駐位置，代價是搬移與暫停。
• no_move：對不可搬移、極短存活或高頻改寫資料保持原位。

本文不將上述選項硬編為 OS 通用功能；它們是 policy intention，需檢查平台能力與配置許可後才能下沉。

9.4 版本與資料放置的聯動

當 memory_region_id 或 allocation_epoch 變更，任何依賴實體位址、DMA 映射、page lock／pin 或 buffer lease 的消費者都必須重新驗證有效性。PWN 的邏輯 flow_id 可持續存在，不代表它可以使用已撤銷的舊頁面指標。

10. GPU、DMA、PCIe 與跨設備記憶體

10.1 裝置擁有高吞吐數值核心，不擁有免費傳輸路徑

以離散 GPU 為例，GPU device memory 的本地帶寬一般不應與 CPU host memory 之間 PCIe 傳輸視為同一個階層。NVIDIA CUDA Best Practices 明確把減少 host/device 交換量與批次化傳輸列為重要優化方向 [E12]。因此即使 GPU 以極高速度算完關係評分，只要每條邊都要單獨往返 CPU，端到端可能很慢。

10.2 Addressable、Accessible、Resident、Visible 分離

某個 pointer 在 unified virtual addressing 模式下具有可表示的位址，不表示資料沒有搬移成本、當前可安全被兩種處理器同時訪問，或完成了必要同步。SMPDC 應區分：

• Addressable：能表示或識別該記憶體區域；
• Permitted：執行域有使用它的授權；
• Resident：目前實際位於某物理／裝置位置（可能非永久）；
• Ready：必要的複製或 kernel 操作已完成；
• HostVisible：CPU 端可依正確 API 與 happens-before／device event 結果讀取；
• ApplicationCommitted：Paper 04 的正式提交已核准。

這六項互不等價。

10.3 Pinned memory 不是免費的

Page-locked／pinned host memory 往往有助於非同步傳輸，但會占用有限系統資源，配置與鎖頁亦有成本。當同時維持 R1／R2 多個副本，pinned pool 可能變成更嚴重的容量瓶頸。這也意味 GPU 小工作批次不一定值得先做 pinned copy [E12]。

10.4 DeviceBufferLeaseV0_1 的延續規則

GPU buffer 被 CPU 工作流提交運算後，其生命週期不應隨 OS thread 遷移或取消信號立即消失。在所有相關 GPU kernel、copy、event 與依賴使用者終止之前，資源釋放必須由明確 lease/refcount/stream-ordered semantics 保護。即使 GPU 輸出對 CPU 可讀，仍然可能因 owner generation 過期、來源不可信或 version readset 不合法而被拒絕提交 [I8]。

10.5 GPU 不應處理的路徑

微小分支密集的控制流、極少資料的相位握手、逐訊息單獨 PCIe 傳輸、依賴強且無批量的一致性操作，可能更適合 CPU 本地。GPU 可加速的是適合大量平行的計算內容，不是替所有 CPU 核心創造無延遲實體連結。

11. Data Layout：從消息物件到實體 cache line

11.1 AoS 與 SoA 的關聯

SMPDC DiffusionEnvelopeV0_1 包含 message_id、lineage_id、event_epoch、authority_scope、delivery_attempt_id、credit 與 payload。若每個 GPU kernel 只需要權重與相位標籤，直接搬移完整含字串、指標和大型 payload 的 AoS 會浪費帶寬。資料平面可使用 SoA 或緊湊欄式 batch，但必須保留可回溯的邏輯身份與 lineage map。

11.2 AOS→SOA 改寫需語義證明

格式轉換只要保存 message_id 到 batch row 的單射或可逆映射、版本與失敗分類，即可視為候選 layout lowering。若編譯器把兩條不同來源的 R2 證據合併成一條 GPU row 而丟失來源身份，便不是合法的最佳化；如果它把一次性 credit 複製成兩份可消耗資源，也屬不合法。

11.3 Cache-line 局部性與 metadata 分離

建議參考資料布局為：PWNLocalHotState、ReadMostlyPhaseSnapshot、MPSCMessageRing、PayloadArena、CreditLedgerShard、ReconciliationBatch。高頻讀寫 metadata 應按實際 cache line/ownership profile 防止 false sharing；大型 payload 應盡量避免在熱路徑反覆複製。分離與對齊是可比較的候選，不是自動證明能提高速度。

11.4 長壽工作流與暫態消息的不同配置

長期的工作流註冊表可能從專用 pool、穩定 handle 與分代 slot 中受益；短壽事件可以批次配置並在 epoch 安全邊界回收。對外可見的 flow_id 不應包含可被重複利用的實體指標值，以免 ABA 與生命週期混淆。

11.5 讀取快照與寫入 journal

一個多讀者相位快照可採版本化只讀發布，寫入則先落入局部 journal，再由仲裁決定可見。這樣可減少某些 hot lock contention，但會提高版本管理、暫存記憶體與垃圾回收成本。其收益要以 per-flow 有效完成工作量而非瞬間佇列深度判斷。

12. 成本模型：頻寬、延遲、衝突與有效完成

12.1 端到端完成時間分解

對某一個受管控任務 $q$，定義事件 DAG 的完成時刻 $T_q$。一條沒有重疊的候選路徑可以寫為：

但具實際 pipeline 時，總時間通常不是各元件計時的簡單總和。本篇採用：

其中 $\mathcal D_q$ 為事件依賴 DAG、 $d(a)$ 是依賴鏈上已歸責且不重複計算的活動時長、 $\epsilon_q$ 是不可歸類測量殘差。若活動重疊，應記錄各 lane 的 interval，避免將搬移與計算重覆相加。若存在共享容量競爭， $d(a)$ 本身亦依並發配置改變。

12.2 資料傳輸的下界與非下界

若必須實際通過某條連線傳送 $B$ bytes，且該路徑在該時段有效頻寬不超過 $\beta_{\max}$，則純傳送部分至少需要：

這不是整個任務時間的普遍下界，更不是對所有自動壓縮或重算方案都成立：若演算法改為就地計算、不必傳送相同位元組， $B$ 本身已被重新定義。SMPDC 的有效比較必須明確記錄原 payload bytes、實際傳輸 bytes、重算運算量和輸出等價性。

12.3 可見性與快取衝突成本

定義可測的修正向量：

其中 $R_{coh}$ 為依平台可能取得的 cache-to-cache／HITM／類似一致性競爭指標，並非所有硬體皆支援；若 unavailable，欄位明示 unavailable，不能寫零。 $F_{invalid}$ 是合法性失敗與撤銷率。若只用平均 latency 或單一 cache miss rate，無法描述 R1 race 和 p99 尾端成本。

12.4 受限制的配置目標

對候選配置 $\pi$，提出多目標形式：

其中 $\mathcal F$ 是所有符合原協議的安全與資源限制的候選。此處以 Pareto 支配關係比較，不要求在沒有使用者指定優先順序時把多個不同單位的目標草率相加。

12.5 冗餘是否值得的解析門檻

考慮 R1 單路時間 $T_1$，雙路候選完成時間 $T_A,T_B$，驗證成本 $T_V$，新增冗餘造成的共同佇列與傳輸成本 $T_R$。只有在適用的競速政策下：

才有期望延遲收益。若兩路共享同一 DRAM channel， $T_A,T_B$ 受共同擁塞影響，不能將兩者簡單當成獨立分布，也不能忽略 $T_R$。若目標為 p99 或可靠性，則應直接比較相應指標，不以期望值替代。

12.6 有效完成吞吐量與能源效率

定義合法工作完成數 $N_{valid}$，觀測窗口時長 $\Delta t$ 和整機能源 $E$：

若多路重算同一邏輯結果，不能把每條物理路徑都算成一次有效完成；如果 CPU/GPU 只完成 kernel 卻未通過局部驗證，也不能算成正式有效提交。

12.7 資料局部性收益的反轉風險

把兩個有頻繁互動的 PWN 放近，可能減少讀取延遲；但若它們同時爭奪同一共享 cache 容量、SMT 執行資源或 memory controller，效果可能反轉。同一位置的「接近」不是一個必然正向的效益函數，應使用 workload-sensitive cost profile。

13. 記憶體配置、重算與相位擴散的相互決策

13.1 不是所有資料都應被搬往計算節點

在 SMPDC 的多主工作流架構中，move_compute、move_data、replicate_read_only、materialize_partial、recompute_local 和 defer_until_phase 是不同候選。最直覺的「把資料拉到當前核心」可能造成大量 DRAM/PCIe 流量；若計算本身只需幾十個操作，將部分輸入保留原位並在近端重新計算，反而可能更快。

由於在 CPU cache、DRAM 與 GPU VRAM 之間搬移的成本並不相同，任何 planner 不能只有一個含糊的「distance」欄位。

13.2 定義資料決策操作的前提

13.3 相位不等於時鐘；局部性與相位的共同准入

沿用 Paper 02 的 generalized computational phase。某一項關係訊息可能在 ready、causal、sync、verify 等相位具備不同的交互資格；若 phase compatibility 不合法，就算資料已在 L1 也不能啟動該工作。相反地，即使 phase 合法，硬體成本過高也可以選擇暫停或走安全替代路徑。

定義：

$A_{ij}(t)$ 只是當下候選是否准入，不是實際已發送或已提交的斷言。硬體條件可以包含可用記憶體、deadline、device readiness、必要工作長度與實測成本上界。

13.4 避免相位式資料乒乓

若某工作流在兩組 cache domain 間快速交替，就算每次遷移方向都看似「比較近」，也可能導致頻繁快取暖機與狀態回填。本文建議加上遷移滯後：只在預估收益超過交換成本、觀測誤差與安全邊際時採納；一個 epoch 內對同一物件設定最大遷移數，並留存拒絕原因。

13.5 不為了節省時間而無限增加常駐副本

當 DRAM 容量受限時，多組 cache/NUMA/GPU 副本可能導致 page reclaim、swap、allocator fragmentation、VRAM OOM 或原生輸入資料被擠出。MemoryResidenceLeaseV0_1 應帶 bytes、owner、region、version、expiry／release rule、eviction policy 及是否可重建。若無足夠資源，縮減副本、降低 fanout、延後一部分消息或關閉 GPU offload 都是合法行為。

14. 冗餘資訊流在硬體層的三種不同開銷

14.1 R1 的尾延遲改善需支付公共資源競爭

R1 競速使兩條候選先行，採第一個通過必要驗證的結果。然而即便最慢路徑最終被撤銷，早已進入 LLC、DRAM、PCIe 或 GPU queue 的工作仍可能消耗 bandwidth。停止後還要等待設備操作抵達可安全回收的生命週期點。故 winner latency 與 resource total cost 必須分別紀錄。

14.2 R2 的佐證並非增加 cache 副本

若兩個計算結果僅是從相同原始錯誤、相同版本不可信的權重或相同不正確的求解器複製而來，即使在兩組 CPU 核心或 GPU 執行，仍不能視為獨立來源。硬體不同可能有助觀測部分硬體故障，但來源獨立性必須由來源血緣與故障模型定義，並透過 ReconciliationEnvelopeExtensionV0_1 追蹤 [I3]。

14.3 R3 編碼冗餘與資料運算權衡

R3 若採具體的錯誤校正／抹除編碼，必須指明編碼 $(n,k)$ 、失敗模型、最小可解碼分塊、編碼時間、重建成本與儲存比例。若只是「把兩份相似位元合併」，沒有確定的碼字關係或解碼條件，不能主張能糾正任意錯誤。

14.4 一個可計算的容量例子

假設單一結果 payload 為 $B$，建立 $r$ 份完整物理副本，忽略 metadata 時最低暫存容量大約為 $rB$ ；如果使用 $(n,k)$ 系統性的等長抹除編碼、每片約為 $B/k$，則資料片總量約 $nB/k$。這只是容量量級示例，實際 alignment、metadata、checksum、replica version 和傳輸緩衝皆增加成本；不代表 $n/k$ 配置在所有 failure pattern 下都有正確復原能力。

14.5 單位有效輸出的記憶體放大

定義：

分母必須正且有明確最小資料依賴模型，若不能合理建立則標示 not_applicable。當 $A_{mem}$ 或 $A_{traffic}$ 急升而 $Q_{valid}$ 沒有改善，冗餘模式應進入降級或重新計畫。

15. 推測執行、版本校驗與實體所有權

15.1 計算進度與確定性提交進度仍須分離

Paper 04 允許暫態結果先行，但不允許未驗證的結果對外成為正式狀態。就硬體而言，推測分支可以先配置資料、執行 GPU kernel、把候選放在 CPU 本地快取；但任何正式回寫須通過依賴版本、authority epoch、owner generation、必要可見性見證與提交域 [I4]。

15.2 物理緩衝租約的兩種失效

• 邏輯失效： 結果已因快照過期、相位不符或品質判斷不合格而不應被採納。
• 物理失效： buffer 已釋放／重新映射，仍有 GPU DMA、CPU reader 或 background copy 可能存取它。

第一種不表示可以立即回收第二種仍被使用的 buffer；第二種也不表示只要資料仍在記憶體裡就可以重新合法使用。撤銷權限、等待完成及資源安全回收是不同步驟。

15.3 版本化 buffer 身分

最小身份建議為：

(region_id, allocation_epoch, buffer_generation, owner_scope, version)

對 GPU 另關聯 device_id、stream_id、completion_event_id、visibility_witness_id。同一物理位址在不同 allocation_epoch 間重新利用，不得繼承舊 BufferLease；也不得只用 raw pointer 的相等判定是同一合法物件。

15.4 永續化、cache flush 與應用提交不可混淆

若研究持久性儲存或 persistent memory，cache flush／memory fence 的硬體保證與檔案系統／交易日誌的 durability 是額外議題。此篇不把 DRAM cache coherence 誤當成 crash-safe durable commit；Paper 04 的 WAL、權威提交與外部效果政策不變。

16. HardwareTopologyManifestV0_1：可探測拓撲封套

16.1 文件目的

以平台返回的觀測為基準保存整個 run 的硬體拓撲與能力，讓下一次 benchmark 具可比性。manifest 可匿名化敏感序號，但必須保存與效能重現相關的欄位，例如 CPU family/model、OS build/kernel、BIOS/microcode（如允許）、physical core／SMT grouping、cache share map、visible NUMA nodes、GPU driver、PCIe link 實際協商能力及 memory size。

16.2 欄位規格

contract: HardwareTopologyManifestV0_1
schema_version: "0.1"
manifest_id: "example-id"
observed_at: "2026-10-17T00:00:00+08:00"
topology_epoch: 12
os:
  family: "windows_or_linux"
  version: "detected_value"
  containerized: false
cpu:
  model: "detected_value"
  logical_processor_ids: [0, 1]
  physical_core_map: "detected_or_unknown"
  cpu_class_map: "detected_or_unknown"
  shared_cache_groups: "detected_or_unknown"
  die_or_ccd_map: "detected_or_unknown"
  os_numa_nodes: "detected_or_unknown"
  available_affinity: "detected_value"
memory:
  physical_ram_bytes: "detected_value"
  numa_page_placement_supported: "true_false_or_unknown"
gpu:
  device_ids: "detected_value"
  driver_versions: "detected_value"
  pcie_link: "detected_or_unknown"
  vram_bytes: "detected_or_unknown"
  unified_memory_capability: "detected_or_unknown"
observability:
  pmu_access: "available_unavailable_or_unknown"
  source_tools: []
  limitations: []

這份 YAML 是契約示例而非真實機器的 dump。其示例字串 detected_or_unknown 不得在 runtime 內直接當作有效核心 ID 或實際容量。

16.3 證據來源優先序

對可觀測事實，優先使用當次 OS／CPU／GPU API 的結果，並以官方架構規格、CPU microarchitecture 文件、profiling trace 與其他工具交叉檢查。公開產品規格可描述平台特性，但不保證已成功啟用某 BIOS/OS 設定。當來源衝突，保留衝突與 provenance，而非自動選擇看似最快的描述。

16.4 不能通過的示例

• CPU 顯示 24 logical processors，就宣稱有 24 個獨立 physical cores，未檢查 SMT/P-E topology。
• CPU 被列為 AMD，就預設 ccd_id 一定存在、且能一對一對應 NUMA node。
• GPU device list 有 RTX 3070，就宣稱目前 PCIe 實際連線為特定固定 lane/speed，未檢查 link negotiation。
• OS 有虛擬化容器，卻用宿主機處理器總數當可用 CPU affinity。

17. MemoryResidenceLeaseV0_1：記憶體常駐與生命週期

17.1 核心欄位

contract: MemoryResidenceLeaseV0_1
region_id: "payload-arena-A"
allocation_epoch: 7
buffer_generation: 3
owner_scope: "flow-42"
logical_version: 19
location_class: "cpu_dram"
location_hint: "numa_node_unknown"
bytes_reserved: 8192
bytes_valid: 6144
access_mode: "read_only_snapshot"
reservation_kind: "best_effort"
retain_until: "consumer_epoch_closed"
related_gpu_lease: null
lifecycle: "active"

location_class 可能是 cpu_dram、gpu_vram、pinned_host、mapped_host 或其他已支援域；對 cache 必須標記 hint_only，不能虛構固定 cache residence。

17.2 生命週期狀態機

Proposed -> Reserved -> Active -> Revoking -> Quiescent -> Released。任何能直接從 Active 跳到 Released 的快速路徑都需要證明所有讀者、DMA、copy、GPU kernel 或 epoch guard 已完成，不能以取消信號替代安全 quiescence。

17.3 可讀版本與寫入者世代

對於寫入者，需保留 owner generation 或 lease generation，並使用 Paper 04 的 fencing 防範遲到結果回寫。對只讀 snapshot，可允許跨多個 PWN 共用，但必須明示快照版本與撤銷策略。當新 snapshot 取代舊版本時，舊版本可以暫時保留到所有 reader 結束；其記憶體成本應計入實測。

17.4 記憶體頁搬移和 lease 不等價

OS 可以變更頁面物理位置但保留虛擬位址；這不等於 lease 的所有邏輯權限或 version 變更。反之，lease 的邏輯失效也不保證實體頁面立即被系統釋放。二者需要一個可審計的橋接狀態。

18. HardwareCostProfileV0_1 與證據品質

18.1 不設一個永遠正確的「跨核心延遲」

微架構性能取決於工作集合、core class、SMT occupancy、讀寫比、共享快取、記憶體訪問模式、頻率、PCIe link、CPU memory pressure、thermal state 等。HardwareCostProfile 是測量所得的局部條件模型，不能把某一次 synthetic ping-pong 的最小 cycle 數直接套用於高負載 AI pipeline。

18.2 主要資料欄位

18.3 適用域與失效條件

Profile 包含 CPU power limit、GPU driver、memory frequency、BIOS/SMT/P-E 策略、併發與負載類型時，才可以用於相應 placement。若環境差異超出合約允許範圍，應改為 out_of_domain，先回退基準策略並重新取樣。p99 若樣本量太少，則不能聲稱統計穩健。

18.4 PlacementCostEnvelopeV0_1

contract: PlacementCostEnvelopeV0_1
candidate_plan_id: "plan-17"
related_manifest_id: "manifest-12"
related_profile_ids: ["prof-1", "prof-2"]
flow_id: "flow-42"
source_location: "cache-group-A"
destination_hint: "cache-group-B"
logical_validity: "checked"
memory_budget_check: "checked"
latency_prediction: "interval_or_distribution"
energy_prediction: "interval_or_unknown"
data_motion_bytes_estimate: 0
required_barriers: []
provenance: "rule_based_v0"
admission_status: "proposal_only"

值 0 只能表示推估不需搬移，不能表示真實傳輸已觀測到零。此欄位與 OS/AI 控制層的 FlowPlacementProposalV0_1 可橋接，但無權限直接改動硬體排程。

19. 安全可見性：MemoryVisibilityGuardV0_1

19.1 分離語義記憶體版本與實體資料生命週期

MemoryVisibilityGuard 的目的，是在 CPU／GPU／DRAM 不同域之間建立明確的讀取先決條件：合法主體、buffer 世代、資料版本、設備 event、必要 cache／host 可見性見證以及未失效的 owner 權限。這是 Paper 08 DeviceVisibilityWitnessV0_1 的補充，不是改名替代。

19.2 守衛謂詞

這是必要前提模式；若某讀取還需要設備同步、owner epoch 或校驗值，應同樣成為合取項。safe_read 不是憑空由某個 CPU acquire flag 保證全系統的 GPU 記憶體可見性。

19.3 失效與拒絕行為

不一致的 manifest、舊 buffer generation、未完成 copy event、缺少 device visibility witness 或被撤銷的權限，均回覆 typed rejection，而不是「等一段時間再試」當作可見性證明。可以重試，但重試需有新的有效證據。

19.4 GPU reset 與 buffer reclaim

裝置重置後若 GPU event 和 buffer context 的有效性不可確立，相關結果須標為 unknown_or_invalid，進入安全資源回收流程。只憑 driver_error == 0 的另一個無關 API 呼叫不能補正失效事件。可能發生未完成的 GPU side effect，必須遵守 Paper 04 的不確定外部效果策略 [I4, I8]。

20. 硬體映射 Runtime：由政策提案到實體執行

20.1 模組邊界

SMPDC-Lang / PDAIS-IR
       |
       v
Flow + Phase + Credit + Authority Gate (Papers 01-06)
       |
       v
OS/AI-free Control Plane (Paper 07)
       |
       v
Hardware Manifest + Cost Profiler (Paper 09)
       |
       v
Placement Proposal --> OS / GPU Adapter Admission
       |
       v
CPU Worker / NUMA Allocation / CUDA Execution (Paper 08)
       |
       v
Visibility + Owner + Version Witness
       |
       v
Local Reconcile --> Trusted Commit Domain (Papers 03-04)

這張圖是責任與證據流程，不是聲稱 GPU 位於 CPU cache-coherence network 中，或所有工作都必須從 GPU 經過一次。

20.2 observe -> propose -> admit -> execute -> verify 五階段

1. Observe： 收集硬體拓撲、資源壓力、cache contention、queue depth、GPU event 與工作簽名。
2. Propose： 基於 profile 為 stay_local、same_cache、cross_cache、move_data、offload_gpu 等候選估算成本區間。
3. Admit： 通過相位、credit、所有權、memory budget、OS／device API 能力與期限檢查。
4. Execute： 接受 OS 實際授予的承載位置及相關 lease，執行 CPU 或 GPU 任務並記錄事件 DAG。
5. Verify： 用正式 trace 分辨預測與觀測；驗證版本、可見性、去重、合法結果與提交契約。

20.3 自適應不能自動破壞可重現性

AI 顧問可提出新的位置或工作切片建議，但每項策略都須有 policy_id、模型版本（如使用）、輸入快照、候選集合、核准理由與拒絕原因。每個正式 benchmark 應可鎖定 policy 不再自動學習，以免測試資料動態改變造成難以比較。

20.4 以保守操作作為預設

沒有足夠 profile 或沒有 topology features 的普通消費平台，預設應使用成熟 OS scheduler 加本地優化與少量受控 parallelism。只有當可辨認的瓶頸足以抵消調度額外成本，才啟用複雜跨群組擴散與多副本；新運算架構應能在沒有 AI 規劃的情況下正常執行。

20.5 BottleneckEvidenceV0_1 的三重要求

BottleneckEvidence 至少包含 (1) 可重現的高成本事件及其量測來源；(2) 一個明確可替代的成熟 baseline；(3) 一項局部改變後的受控 A/B 或消融結果。只有看到 GPU profiler 顯示某個 kernel 很慢，不能推論「晶片互連需要重做」；可能真正問題只是 batch size、演算法、資料布局或記憶體壓力。

21. 八項條件性命題與可反駁的推導

閱讀限制： 下列命題主要是建立在已明確給定的安全契約、標準計算定義及數學不等式上的條件結論；它們不構成新硬體的速度定理，也不代表 2026-10-17 已有真實 SMPDC 執行器實測。

命題 H09-P1｜邏輯身分與實體位置分離下的合法遷移

前提： (a) PWN 身分由穩定 flow_id 指定；(b) 所有受控寫入均檢查單調遞增的 owner_generation；(c) 遷移只在可驗證 safepoint 進行並交接未完成義務；(d) 沒有繞過 guard 的非授權寫入路徑。

主張： PWN 從實體承載 $c_1$ 遷至 $c_2$，不會因兩個 worker 同時存在而產生兩個具有有效寫入權限的同一代主工作流。

論證摘要： 遷移時將有效 generation 原子推進至 $g+1$，舊 worker 若使用 $g$ 的令牌，任何受控寫入必被 guard 拒絕。由於有效寫入權限只依身分及 generation 判定，載體是否位於同一 CCD 不改變安全性。此命題不保證舊 worker 的 GPU event 立即被取消，亦不保證沒有外部效果副本；後者需承接 Paper 04 [I1, I4]。

反證邊界： 若存在未受控制的裸指標共享寫入、OS worker 在進入 guard 後無安全同步或 owner generation 可回退，前提不成立。

命題 H09-P2｜共享 cache line 可使邏輯獨立的節點產生物理競爭

前提： 兩條相互獨立的 PWN 頻繁更新同一硬體 cache line 上不同地址，所處微架構對此資料採具有寫入所有權轉移的一致性協議。

主張： 即使兩者沒有邏輯資料依賴，仍可能產生額外 coherence traffic、延遲與吞吐損失。

論證摘要： 物理一致性系統通常追蹤粒度大於單一程式語言欄位，更新可能造成整條 cache line 所有權轉移，與兩個欄位邏輯上互不相干無關。這是既有 false-sharing 機制，不是 SMPDC 新發現 [E8–E9]。

反證邊界： 若資料只讀、落在不同實體 cache line，或該平台具有不同的一致性機制，不得由此斷言同樣的衝突成本。

命題 H09-P3｜資料遷移取得淨收益的必要成本門檻

前提： 候選策略不改變任務品質及合法性，且兩個策略在同一資源／負載條件下可比較；將資料放近使後續工作節省 $\Delta T_{\mathrm{access}}$，但需要搬移／驗證／失效處理總時間 $T_{\mathrm{relocate}}$，其他效應以 $\Delta T_{\mathrm{other}}$ 表示。

主張： 若 $T_{\mathrm{relocate}}+\Delta T_{\mathrm{other}}\geq\Delta T_{\mathrm{access}}$，僅以此搬移策略不能聲稱端到端時間得到正收益。

論證摘要： 淨節省為 $\Delta T_{\mathrm{access}}-T_{\mathrm{relocate}}-\Delta T_{\mathrm{other}}$。此式要求正值。若存在可重疊的階段，應改以關鍵路徑淨影響代替簡單相加；不能沿用沒有重疊時的門檻。

反證邊界： 若候選也改變模型演算法、有效工作量或輸出品質，應重建比較口徑。

命題 H09-P4｜冗餘不能免除實體資源成本

前提： $r>1$ 條副本物理上包含非共享的正長度資料或獨立計算狀態，且沒有採用完全共享的零複製視圖。

主張： 建立副本對總系統記憶體或傳輸／運算負載至少有一項可觀測的增量成本；冗餘本身不推出更高答案正確性。

論證摘要： 物理上新增資訊副本或需要新增計算／傳遞事件。若兩個結果源自同一錯誤資料，副本增加無法自動消除共享錯誤；來源獨立性與可解碼性皆另有條件 [I3]。

反證邊界： 共用同一不可變 buffer 的雙路消費者在某些情況下可能沒有 payload bytes 複製，則此命題的「非共享物理副本」前提不成立；仍可能有 queue、同步或 reader 成本。

命題 H09-P5｜必要跨連線資料搬移的頻寬下界

前提： 某工作必須經過同一受限連線搬移 $B>0$ bytes，該期間的可達帶寬上界為有限正數 $\beta_{max}$，且傳輸不能被替換為等價的本地重算或其它通道。

主張： 完成該段物理傳輸所需時間不小於 $B/\beta_{max}$。

論證摘要： 定義帶寬為時間內成功移動的資料量，若少於 $B/\beta_{max}$ 時間，最大可搬移量小於 $B$，矛盾。

限制： 這是該傳輸階段的下界，不是整個平行計算或 AI 模型完成時間的普遍下界；它不能用來聲稱新資訊編碼或資料縮減在原理上不可能。

命題 H09-P6｜GPU 完成事件不足以授權應用提交

前提： GPU device execution 只具有 GpuExecutionTicketV0_1 的 executor 權限；Paper 04 的正式提交需要額外版本、讀集、來源、owner、可見性及 authority policy 驗證。

主張： KernelDone 不能被合法當成 Committed 的等價標籤。

論證摘要： 提交必要條件嚴格包含不由 GPU kernel 完成自動保證的其他前提，僅有必要條件之一不能推出全部條件成立 [I4, I8]。

反證邊界： 若一個特殊工作根本沒有應用狀態提交義務，就不應假裝它需要完整交易；相應的 minimal adapter 仍不能偽稱存在過權威提交。

命題 H09-P7｜安全降級對無支援拓撲的閉包

前提： HardwareCostProfile 不可信、過期、不可用或超出採樣適用域；SMPDC runtime 保留經成熟 OS 接受的安全 baseline；控制器不可繞過 OS／裝置權限或 Paper 01–04 的保護。

主張： 退回不依賴該不可信 profile 的基準策略，能避免因依賴此 profile 而產生的非法 placement／lease 動作。

論證摘要： 沒有有效 profile 的分支不會被送進需要該 profile 的特殊准入通道，並沿用可信權限檢查。因此與該錯誤 profile 有關的錯誤動作不會執行。

限制： 此命題不宣稱 baseline 天然沒有 OS bug 或記憶體錯誤，也不保證回退後仍高性能。

命題 H09-P8｜新實體互連的設計需要先識別不可由現有最佳化消除的瓶頸

前提： 研究目標是論證某種新 NoC／ISA／專用硬體單元相較既有 CPU／GPU／OS 方案有必要。

主張： 若尚未建立能被反覆量測、歸責且在成熟基線及合理軟體消融後仍存在的瓶頸，就不能僅由 SMPDC 邏輯模型推出有必要採用新硬體。

論證摘要： 新硬體至少需解決可指認的物理或控制成本。如果缺乏可歸責瓶頸，無法判定特定新電路是否改善目標、是否被成本抵銷或是否增加其他瓶頸。

限制： 即使具有上述瓶頸，也只形成研究候選的必要證據，並非新硬體必然有效的充分證明；還需 PPA（performance/power/area）、製程、介面、生態、安全及製造等完整評估。

22. HLC09 三十二條最低不變量

為避免與 Paper 07 C07、Paper 08 G08 等序列混淆，本篇使用 C09-01 到 C09-32。任何 V0／V1 參考執行器必須能對條件適用的規則提供程式化 assertion 或可審計證據；若規則依賴特定硬體 capability 且當次裝置不支援，應標記 NOT_APPLICABLE 或 UNAVAILABLE，不可寫成 PASS。

22.1 重要的跨篇一致性測試

C09-17 與 C09-18 分別對應 Paper 08 的裝置可見性與 Paper 04 的權威提交；C09-21 對應 Paper 02 的不可複製 credit；C09-25 對應 Paper 01/07 的 owner generation；C09-31 防止把尚無實測的晶片想像誤報成工程成果。

22.2 驗收狀態分類

• PASS：在明確範圍內有實際驗證證據；
• FAIL：觀測到與契約不符的反例；
• NOT_APPLICABLE：本平台／本案例不涉及該規則；
• UNAVAILABLE：能力或權限不足，不能做有效測量；
• NOT_RUN：尚未執行；
• INCONCLUSIVE：結果不足以支持成功或失敗。

此分類應在資料文件中統一使用，不可把 UNAVAILABLE 合併成 PASS。

23. 三十六類故障反例與預期處置

這些案例是應被故障注入覆蓋的測試設計，不是聲稱本稿已在真實處理器上觸發這些故障。

23.1 故障類別分群

• F09-01～14：拓撲誤讀、核心／記憶體異質性與局部性瓶頸。
• F09-15～20：buffer life cycle、GPU 可見性與資源安全。
• F09-21～26：資料傳遞、冗餘、相位遷移與 AI 控制。
• F09-27～36：實驗測量、可證偽性、輸出品質與權威提交。

23.2 何者只靠模擬器不能證明？

False sharing 的存在機理已由文獻支持，但某個 PWN 工作負載是否因此產生可測性能瓶頸必須依真實硬體 trace。SIMD、SMT、CCD、PCIe、DRAM 等實體吞吐皆同理。契約模擬器能驗證 invalid lease／owner generation 被拒絕，不能驗證某顆 9950X3D 會快多少。

24. V0–V1 實驗綱領與公平比較

24.1 V0｜純軟體可重演的 HardwareLocality Simulator

建立有限拓撲圖，包含 logical cores、cache groups、可用 NUMA domains、GPU memory domains 與 bounded links。輸入合成的 workload profile、工作流相位與 memory footprint，要求系統在明確的安全／成本欄位下選擇 placement。V0 是 correctness/falsification harness，不宣稱等於真實 CPU 快取行為。

V0 最低完成條件：manifest parser、typed unknown、lease state machine、owner generation guard、HardwareCostProfile 驗證、topology epoch invalidation、R1 capacity accounting、CUDA HostReadable mock gate 及降級策略；必須能輸出候選 trace 與已知失效案例。

24.2 V1｜既有桌機的實機初步測試

目前已知使用者的實體基準為：舊款 AMD CPU、32 GB RAM、NVIDIA RTX 3070。CPU 精確型號、核心數、快取拓撲、記憶體時序、主機板、PCIe link 和 Windows build 均須以執行當次實際探測為準。不能假設新 Intel 270K Plus、AMD 9950X3D 或 MINISFORUM N5 Pro NAS 已被購買。舊平台即可先做核心親和性、false sharing、MPSC queue、CPU/GPU transfers、冗餘容量放大與可見性守衛測試。

24.3 對照組 B0–B9

不是所有 B0–B9 都適用每個測試。各工作負載需事前列明哪些策略確實可行，不能因某個 baseline 不利於 SMPDC 就偷偷刪除。

24.4 SMPDC 實驗組 E0–E8

採 E0–E8 的全序列只是便於進行消融；若某特定負載不需要 R3，應使用 component_not_applicable 或最小必要配置，不為了展示「全系統」強制開啟所有機制。

24.5 最低測試矩陣 K09-01～K09-20

24.6 需要保留三個時間尺度

對每個微基準都要記錄 startup/cold、warm steady state 與 teardown/cancel：若只取暖機後最漂亮的穩態數據，便不能解釋真實短請求系統；反之若只取短冷啟動，又可能低估持續性 PWN 的 amortization 優勢。平均值、p95／p99、有效吞吐及能源必須使用同一段完整追蹤資料計算。

24.7 量測限制與統計程序

在可控條件下隨機化基線／實驗組執行順序，鎖定輸入種子和版本；每一組保留 warm-up、運作時間、觀測筆數、檢查失敗數及 raw CSV/JSON traces。對尾端延遲使用足夠樣本與合理置信區間，並將每次 run 作為重複單位，避免把同一 run 裡高度相關的百萬筆訊息當作百萬次獨立實驗。Windows/Linux 的能源取得能力不同，缺值以 unavailable 表示。

24.8 「有比較」不代表有效實驗

若實驗組有 64 GB 記憶體而基準只有 32 GB，或 GPU batch 可以 warm-cache 而 CPU 每次 cold-start，便不能將差異歸因於 SMPDC。必須固定硬體、時脈策略、記憶體配額、驗證強度、輸入品質、存取權限及有效完成定義，或在報告中明示差異並放棄強結論。

24.9 設定失敗門檻（事前預註冊候選）

最低建議把「新 Runtime 在同品質與相同內存限制下沒有比最強 B 組降低端到端成本」視為有效的否定結果；若額外 metadata/credit/lease/phase 的熱路徑開銷高於 saved synchronization，接受結果為 SMPDC 在此工作負載不適用。若 CPU/GPU 常態傳輸造成 $A_{traffic}$ 明顯增加、p99 惡化或 OOM 頻率升高，也必須記錄為缺點。

25. 不同 CPU 平台的研究價值與購置決策邊界

25.1 先用現有平台，後購新硬體是有意義的研究順序

SMPDC 繼續堅持原始的成本約束：在尚未實驗確立效益前，不必購買高價伺服器級 CPU。既有 AMD CPU 與 RTX 3070 已可以測量 cache false-sharing、線程親和、core-to-core queue latency、各種工作集合的快取敏感性，以及 CPU/GPU 傳輸和 microbatch 代價。這些量測能幫助判斷目前最值得投資的是新 CPU、記憶體、PCIe 主機板、顯示卡 VRAM、額外 DIMM，抑或只是更好的軟體資料布局。

25.2 Intel Core Ultra 7 270K Plus 的實驗角色

若選用 Intel 270K Plus，可針對 P/E 核性能不對稱、共享 cache group、負載放置、混合工作流的 tail latency、少量高優先控制節點與大量一般工作節點的交互進行驗證。須先檢查搭配主機板、BIOS、OS scheduler、記憶體及散熱是否穩定，並辨識哪些差異其實來自硬體規格而不是 SMPDC。

不應宣稱：「24 實體核心必然等於 24 條完全獨立的物理連線」、「E-core 自然是 GPU 與 P-core 之間的轉送器」，或「更高 E-core 數量必然對 AI 訓練帶來相同比例加速」。

25.3 AMD Ryzen 9 9950X3D 的實驗角色

若選用 AMD 9950X3D，可研究雙 CCD、不對稱共享快取域、工作集合超過與未超過某群快取有效容量時的效能轉折，及不同調度對跨快取通信的影響。資料是否能有效留在有利 cache domain，不是由核心總數推導；例如強制將所有工作流移往某個快取較大群組，也可能因算力、同群組 cache 競爭或熱設計限制而退步。

不應宣稱：「128 MB L3 能被所有 16 顆核心以相同成本直接共享」、「每個 CCD 就是 NUMA node」，或「大型 L3 對任何 AI 工作負載都有效」。

25.4 不對稱平台是否更適合檢驗理論？

研究上，異質 CPU 的優點是能展示「相同邏輯工作流在不同承載條件下的行為差異」；然而異質性本身提高實驗混雜因素。若研究的是 SMPDC 的核心協議是否安全，較單純的硬體就足夠；若研究的是動態硬體規劃策略能否超過 OS 或 domain-specific scheduler，異質平台可能更有辨識力。此處的研究價值不等於該 CPU 一定是日常使用或遊戲效能的最佳選擇。

25.5 最小採購決策表

25.6 現有顯示卡的現實限制

RTX 3070 能承擔部分 CUDA 驗證，但 GPU 型號本身不足以保證任意 memory feature、async copy engine、compute capability、driver 版本或 PCIe link。每次實驗都要執行 runtime capabilities query。若顯示卡記憶體不足以承載完整 AI 模型，不應把 offload失敗直接歸因於 SMPDC 的擴散理念；可以先用小型圖運算、稀疏矩陣、資訊比較或編碼子程序分離 hardware mapping 效果。

26. 未來的新硬體與新 ISA：何時有資格提出？

26.1 四個與軟體不同層次的設計方向

1. 硬體輔助訊息交換／共享佇列： 將常見的有界 enqueue/dequeue 及通知路徑降低 CPU instruction/atomic overhead，但仍需考慮 memory consistency、實體 cache line ownership 與安全。
2. 可配置工作流 metadata／phase controller： 在可驗證的資格檢查中使用低成本硬體判斷，可能降低頻繁軟體 dispatch，卻可能增加 silicon area、energy 與 ISA complexity。
3. 拓撲感知的 NoC／封裝互連： 嘗試優化某些芯片局部資料交換，但未必適合一般化的工作流；路由器擁塞、排隊、線長、時鐘域跨越與可靠性需要實際物理模型。
4. 專用 DMA／collective／reconciliation accelerator： 在大量可批次的格式核對、聚合或編碼中卸載固定操作，可能降低 CPU hot path；但需先證明已有 GPU／SIMD/library 無法有效替代。

以上只是候選研究方向，不是本文已設計的產品。

26.2 PPA 與證明義務

每一個微觀硬體提案都須至少回答：輸入 workload 是什麼？用哪一種 HDL／微架構圖表示？會增加多少 gates、storage、wire、power 及驗證成本？哪個 coherence domain 負責安全？是否破壞既有 OS、ABI 與 compiler？資料無法位於目標晶片上時，仍要經過多少 DRAM／PCIe 傳輸？若 GPU／CPU 專用 library 已足夠，為何新增硬體仍能節約 total system cost？

26.3 新的擴散指令不一定需要新增機器指令

Paper 05 的 PDAIS 可以先降階到現有 native ISA、語言 runtime、shared-memory queues、OS scheduler 和 CUDA streams。只有當 profiler 指出對應語義操作在熱路徑中占顯著比例、成熟最佳化無法避免、且後端 ISA support 具有可證成收益時，才合理談「把某條抽象指令硬體化」。否則設計新機器指令只是語義與維護負擔增加。

26.4 一個負面的設計例子

假設傳送單一 16-byte 消息透過 CPU 本地 cache-coherent queue 已經很快，但控制器每條都啟動一個 GPU kernel 來判斷 routing。新增「GPU 連結加速微指令」即使縮短 kernel 算術時間，若不消除 launch/copy/sync 的占比，仍可能比原本 CPU 路徑慢。此時應先考慮 stay_local 或併批，不應先買昂貴互連設備。

26.5 一個較有研究意義的正向候選

若在穩態長壽 AI routing 裡，每個 PWN 每秒產生大量具可重用結構的稀疏關係邊，且 profiler 反覆顯示同步、資料 layout 和可見性成本在最佳 library 基線下仍佔顯著比例，才有理由考察低成本 hardware collective 或共享資料結構。此處仍需要以軟體 emulation、cycle model、FPGA 或 RTL 提供量化證據才能進一步主張。

27. 與 Paper 10、Paper 11 的正式交接

27.1 Paper 10｜AI 訓練與推論適用域

Paper 10 必須將硬體局部性研究映射到至少四類不同 AI 工作負載：高吞吐 dense tensor、sparse／MoE routing、長壽多 Agent／推論工作流、具 persistent state 的分支／verification pipeline。每個 workload 需提交 model/version、optimizer／seed lineage、precision、batch、context、資料及品質門檻；對 AI 訓練需保留 time_to_quality 而非只比較 step/sec，對推論需保留等品質的 tokens/sec、p95／p99 latency 與 VRAM/RAM 配額。

Paper 10 不得把更多 CPU 核心、記憶體快取或群星拓撲比喻視為 AI 模型收斂性改善的充分理由；必須用其對應的模型及資料實驗證明。

27.2 Paper 11｜全系列可證偽閉環

Paper 11 必須承接 HLC09 各資料契約、H09-P1～P8、C09-01～C09-32、F09-01～F09-36、K09-01～K09-20 及 B0–B9/E0–E8，制定跨平台量測與明確的 PASS／FAIL／INCONCLUSIVE／UNAVAILABLE 報告格式。Paper 11 需要比較最強傳統 CPU／GPU／locality baseline，並允許「新架構在目前平台沒有正收益」作為有效科學結論。

27.3 核心跨篇接口圖

27.4 本篇 artifact 清單

交付物是：HardwareTopologyManifestV0_1、HardwareLocalityGraphV0_1、MemoryResidenceLeaseV0_1、HardwareCostProfileV0_1、PlacementCostEnvelopeV0_1、MemoryVisibilityGuardV0_1、BottleneckEvidenceV0_1、HardwarePlacementTraceV0_1 的候選結構；本篇只以 Markdown formal specification 與示例 code 提供，尚未宣稱有 native compiler implementation、跨 OS adapter、真實硬體 profile database 或專用微架構實作。

28. 研究限制、文獻關係與貢獻邊界

28.1 不把成熟機制重新命名成新發明

Cache coherence、false sharing、NUMA、memory policy、CPU affinity、CUDA streams、host/device buffer、GPU event、pinned memory、microarchitectural profiler、hardware topology discovery 和 Roofline 類計算／帶寬權衡均已有成熟研究。本文的研究價值不能來自把它們改叫「群星」；而只能來自把持續主要工作流、相位資格、冗餘證據、權威提交與實體成本模型接成一套具有明確型別、守衛及可反駁驗證的跨層協議候選。

28.2 有效貢獻的最低定義

只有在已證明比成熟方法多出特定可觀測能力、較低端到端成本、較佳故障恢復品質，或能提供之前缺少且難以以既有 API 補出的保證時，才可主張有效的研究貢獻。形式契約有價值，但形式名稱並不等於證明了性能突破。

28.3 「像大腦」只能定位為宏觀比較

神經系統同樣具有分散、事件與局部耦合特性，但生物神經元的細胞動力學、突觸可塑性、傳導時延、神經膠細胞與發育機制並未在本篇被重現。SMPDC 在中宏觀上可具有類神經計算組織特徵，不等於微觀電路使用神經元，也不等於能直接產生認知智能。

28.4 不把局部假說包裝為普遍定律

對靜態 dense tensor、大量重複的成熟 GPU kernel、非常小的單核工作、極少改變的固定 routing，以及高共享寫入競爭的負載，SMPDC 可能被傳統方法明顯超越。若這些負面結果出現，應更新適用域、關閉多餘協議或退回 baseline，而不是事後增添不可檢驗的例外條款。

29. 結論：群星拓撲的下一步不是畫出更漂亮的晶片

本篇確立 SMPDC 的微觀映射原則：中宏觀持續擴散執行模型與微觀電路結構必須有橋接，不得直接同一化。 CPU 的每個大核／小核可以是主要工作流的承載候選；GPU 可以在適合的條件下加速大量資訊關係運算；但 cache coherence、SMT 共享資源、CCD／tile 互連、OS NUMA page placement、DRAM bandwidth、GPU VRAM、PCIe 傳輸及 DMA/CPU memory visibility 都不是可由概念擴散略過的物理條件。

本篇的主要形式化成果是：版本化 HardwareLocalityGraph、有能力／未知邊界的 HardwareTopologyManifest、具生命週期與版本守衛的 MemoryResidenceLease、工作負載相關的 HardwareCostProfile、接受不確定性的 PlacementCostEnvelope、不混同 GPU event 與正式提交的 MemoryVisibilityGuard，以及只有在實測瓶頸與公平基線支持下才允許進入新硬體研究的 BottleneckEvidence。

本篇的核心可證偽假說是：針對長壽多主工作流、局部資料重用、受限相位擴散及可批次異質處理的特定工作負載，硬體局部性敏感的 SMPDC 可能減少有效工作完成的總成本；但對高度短小、共享寫入衝突頻繁、缺少並行性或主要受 PCIe／DRAM 容量所限的工作負載，可能不取得任何淨收益。

研究狀態： 完成 Paper 09 v0.1 的原始稿、形式候選、條件命題、反例、硬體成本契約、實驗規格與附錄級微型契約測試；未完成 CPU／GPU 真實跑分、芯片 RTL、FPGA 實測、AI time-to-quality 或效能普遍性驗證。下一篇應研究 AI workload 的適用域，不應先假定更高核心數或大型 cache 能直接改善模型品質。

附錄 A｜HLC09 實作與實驗檢查表

A.1 拓撲可觀測性

• 以當次 API 列舉 physical cores、logical processors、cache groups、NUMA nodes 與 GPU IDs。
• 明確區分 OS 可見拓撲與未被 OS 分辨的 die／CCD 內部資訊。
• 對 unsupported／unknown 值保留 typed 狀態，不虛構欄位。
• 保存 OS、driver、BIOS／microcode（可用時）和 topology epoch。
• 保存 CPU affinity、可用記憶體預算、GPU VRAM 與實際 link capability。
• 對於容器／VM／WSL，保存觀測視角限制。

A.2 安全與所有權

• flow_id 與 CPU/core placement 分離。
• PWN migration 維持 owner generation、safepoint 和未完成義務。
• 每個 MemoryResidenceLease 有唯一配置世代與 owner scope。
• CPU 多執行緒發布遵守合法 memory ordering。
• GPU device event、copy event 和 HostReadable 不混同。
• 已撤銷的 buffer 不因地址重用而恢復舊的合法性。
• R1/R2/R3 物理副本不能複製邏輯傳播 credit。
• 正式應用提交保留 Paper 04 權威版本守衛。
• GPU reset、driver exception、owner migration 有安全降級。

A.3 量測與反證

• Profile 包含明確樣本數、觀測欄位、單位與工具版本。
• Counter 不支援時標記 unavailable，而非填入零。
• 保存 raw trace、事件 DAG、host/device copy 時間與完整尾延遲。
• 比較成熟 thread pool、cache-friendly、NUMA-aware、CUDA 基線。
• 用一致品質、資源、時間窗口與工作總量比較。
• 測量冗餘副本實際帶寬、容量和被取消的物理作業。
• 對 page migration／core switching 量測從開始到回復穩態的總成本。
• 每個 positive claim 帶有適用域、信賴區間與可重現 run manifest。
• 沒有新硬體實測就不標記 RTL／NoC 的效能 PASS。

A.4 逐項 C09 覆蓋門檻

正式 harness 應產生 C09-01 到 C09-32 的 machine-readable verdict。允許 NOT_RUN、UNAVAILABLE 和 NOT_APPLICABLE，但須列出原因。不得在未執行時自行換成 PASS。負例 F09-01～36 必須能對應必要守衛或效能反例；若只具 mock 能力，必須標成 mock 證據。

附錄 B｜可單獨執行的 HLC09 微型契約參考程式

B.1 使用目的與不變量

以下程式只模擬 topology epoch、flow owner generation、buffer lease、GPU host-visible witness、capacity admission 和正式提交 gate；不使用或測量真實 CPU cache、NUMA 或 GPU，不能當成已完成硬體效能驗證。它的用處是確認某些非法狀態可被一組顯式守衛拒絕。程式只需 Python 3 標準函式庫；PASS 指 Mock assertions 成立，不表示 SMPDC L2／L3 物理驗證已完成。

from __future__ import annotations
from dataclasses import dataclass, replace


class Reject(Exception):
    pass


@dataclass(frozen=True)
class Manifest:
    topology_epoch: int
    allowed_cores: frozenset[int]
    supported_gpu: frozenset[str]
    memory_budget: int


@dataclass(frozen=True)
class PlacementProposal:
    flow_id: str
    owner_generation: int
    topology_epoch: int
    destination_core: int
    requested_bytes: int
    profile_valid: bool
    authorized: bool


@dataclass(frozen=True)
class Lease:
    region_id: str
    allocation_epoch: int
    generation: int
    logical_version: int
    bytes_reserved: int
    owner_scope: str
    state: str = "active"
    readers: int = 0
    device_pending: bool = False


@dataclass(frozen=True)
class GPUWitness:
    device_id: str
    region_id: str
    buffer_generation: int
    version: int
    kernel_done: bool
    copy_done: bool
    host_visible: bool
    owner_generation: int


@dataclass(frozen=True)
class CommitRequest:
    flow_id: str
    owner_generation: int
    read_version: int
    authority_ok: bool
    local_verified: bool


class MockRuntime:
    def __init__(self, manifest: Manifest):
        self.manifest = manifest
        self.owner_generations = {"flowA": 5}
        self.canonical_versions = {"flowA": 9}
        self.active_bytes = 0
        self.logical_credits = {"msgA": 1}
        self.active_leases: dict[str, Lease] = {}

    def admit(self, proposal: PlacementProposal) -> str:
        if proposal.flow_id not in self.owner_generations:
            raise Reject("unknown_flow")
        if proposal.owner_generation != self.owner_generations[proposal.flow_id]:
            raise Reject("stale_owner")
        if proposal.topology_epoch != self.manifest.topology_epoch:
            raise Reject("stale_topology")
        if proposal.destination_core not in self.manifest.allowed_cores:
            raise Reject("core_not_available")
        if not proposal.authorized:
            raise Reject("no_resource_authority")
        if not proposal.profile_valid:
            return "FALLBACK_TO_OS_SAFE_BASELINE"
        if proposal.requested_bytes < 0:
            raise Reject("negative_allocation")
        if self.active_bytes + proposal.requested_bytes > self.manifest.memory_budget:
            raise Reject("budget_exceeded")
        return "ADMITTED_PROPOSAL_NOT_YET_EXECUTED"

    def reserve(self, lease: Lease) -> None:
        if lease.region_id in self.active_leases:
            raise Reject("duplicate_region")
        if lease.bytes_reserved < 0:
            raise Reject("negative_allocation")
        if self.active_bytes + lease.bytes_reserved > self.manifest.memory_budget:
            raise Reject("budget_exceeded")
        if lease.state != "active":
            raise Reject("invalid_initial_lease_state")
        self.active_leases[lease.region_id] = lease
        self.active_bytes += lease.bytes_reserved

    def gpu_host_read(self, region_id: str, witness: GPUWitness,
                      required_owner_generation: int) -> int:
        lease = self.active_leases.get(region_id)
        if lease is None or lease.state != "active":
            raise Reject("no_active_lease")
        if witness.device_id not in self.manifest.supported_gpu:
            raise Reject("gpu_not_supported")
        if witness.region_id != region_id:
            raise Reject("region_mismatch")
        if witness.buffer_generation != lease.generation:
            raise Reject("stale_buffer_generation")
        if witness.version != lease.logical_version:
            raise Reject("stale_buffer_version")
        if witness.owner_generation != required_owner_generation:
            raise Reject("stale_owner")
        if not (witness.kernel_done and witness.copy_done and witness.host_visible):
            raise Reject("not_host_visible")
        return lease.logical_version

    def consume_credit(self, message_id: str) -> None:
        if self.logical_credits.get(message_id, 0) <= 0:
            raise Reject("credit_already_consumed")
        self.logical_credits[message_id] -= 1

    def attempt_release(self, region_id: str) -> None:
        lease = self.active_leases.get(region_id)
        if lease is None:
            raise Reject("unknown_region")
        if lease.readers != 0 or lease.device_pending:
            raise Reject("not_quiescent")
        del self.active_leases[region_id]
        self.active_bytes -= lease.bytes_reserved

    def commit(self, request: CommitRequest) -> int:
        if request.owner_generation != self.owner_generations.get(request.flow_id):
            raise Reject("stale_owner")
        if not request.local_verified:
            raise Reject("unverified_candidate")
        if not request.authority_ok:
            raise Reject("no_commit_authority")
        if request.read_version != self.canonical_versions.get(request.flow_id):
            raise Reject("stale_read_version")
        self.canonical_versions[request.flow_id] += 1
        return self.canonical_versions[request.flow_id]


def must_reject(fn, expected):
    try:
        fn()
    except Reject as exc:
        assert str(exc) == expected, (str(exc), expected)
    else:
        raise AssertionError("expected rejection: " + expected)


def run_mock_contract_checks():
    passed = []

    def check(label, condition):
        assert condition, label
        passed.append(label)

    m = Manifest(12, frozenset({0, 1, 2}), frozenset({"gpu0"}), 16384)
    r = MockRuntime(m)
    p = PlacementProposal("flowA", 5, 12, 1, 4096, True, True)
    check("01_valid_admission", r.admit(p) == "ADMITTED_PROPOSAL_NOT_YET_EXECUTED")
    must_reject(lambda: r.admit(replace(p, owner_generation=4)), "stale_owner")
    check("02_stale_owner_rejected", True)
    must_reject(lambda: r.admit(replace(p, topology_epoch=11)), "stale_topology")
    check("03_stale_topology_rejected", True)
    must_reject(lambda: r.admit(replace(p, destination_core=99)), "core_not_available")
    check("04_unavailable_core_rejected", True)
    must_reject(lambda: r.admit(replace(p, authorized=False)), "no_resource_authority")
    check("05_authority_enforced", True)
    check("06_profile_fallback", r.admit(replace(p, profile_valid=False)) == "FALLBACK_TO_OS_SAFE_BASELINE")
    must_reject(lambda: r.admit(replace(p, requested_bytes=-1)), "negative_allocation")
    check("07_negative_allocation_rejected", True)
    must_reject(lambda: r.admit(replace(p, requested_bytes=20000)), "budget_exceeded")
    check("08_budget_gate", True)

    lease = Lease("regionA", 7, 3, 9, 8192, "flowA", readers=0, device_pending=True)
    r.reserve(lease)
    check("09_lease_accounting", r.active_bytes == 8192)
    must_reject(lambda: r.reserve(lease), "duplicate_region")
    check("10_duplicate_region_rejected", True)
    w = GPUWitness("gpu0", "regionA", 3, 9, True, True, True, 5)
    check("11_valid_host_read", r.gpu_host_read("regionA", w, 5) == 9)
    must_reject(lambda: r.gpu_host_read("regionA", replace(w, buffer_generation=2), 5), "stale_buffer_generation")
    check("12_stale_buffer_rejected", True)
    must_reject(lambda: r.gpu_host_read("regionA", replace(w, version=8), 5), "stale_buffer_version")
    check("13_version_guard", True)
    must_reject(lambda: r.gpu_host_read("regionA", replace(w, copy_done=False), 5), "not_host_visible")
    check("14_copy_event_guard", True)
    must_reject(lambda: r.gpu_host_read("regionA", replace(w, host_visible=False), 5), "not_host_visible")
    check("15_host_visibility_guard", True)
    must_reject(lambda: r.gpu_host_read("regionA", replace(w, device_id="gpu9"), 5), "gpu_not_supported")
    check("16_gpu_capability_guard", True)
    must_reject(lambda: r.attempt_release("regionA"), "not_quiescent")
    check("17_device_lease_guard", True)

    r.consume_credit("msgA")
    check("18_single_credit_consumed", r.logical_credits["msgA"] == 0)
    must_reject(lambda: r.consume_credit("msgA"), "credit_already_consumed")
    check("19_duplicate_credit_rejected", True)
    request = CommitRequest("flowA", 5, 9, True, True)
    must_reject(lambda: r.commit(replace(request, authority_ok=False)), "no_commit_authority")
    check("20_kernel_not_commit_authority", True)
    must_reject(lambda: r.commit(replace(request, local_verified=False)), "unverified_candidate")
    check("21_local_verify_gate", True)
    check("22_authorized_commit", r.commit(request) == 10)
    must_reject(lambda: r.commit(request), "stale_read_version")
    check("23_stale_read_version_rejected", True)
    r.active_leases["regionA"] = replace(lease, device_pending=False)
    r.attempt_release("regionA")
    check("24_safe_release_and_accounting", r.active_bytes == 0)
    must_reject(lambda: r.gpu_host_read("regionA", w, 5), "no_active_lease")
    check("25_released_lease_rejected", True)
    print(f"SMPDC HLC09 MOCK CONTRACT: {len(passed)}/{len(passed)} PASS")


if __name__ == "__main__":
    run_mock_contract_checks()

B.2 測試能力聲明

上段示例在沒有 DMA、真實 GPU event、compiler lowering 或 OS 原生 memory policy 的條件下，只能確認 MemoryResidenceLease 與 CommitRequest 的一部分守衛邏輯。要做正式 conformance，需要再加入並發、page migration、CPU affinity readback、GPU reset、PCIE link path、原子 memory-order litmus、統計功耗與有效的跨程序權限測試。若測試只執行上述程式，正式研究報告應標示為 MOCK_CONTRACT_PASS，而不是 HARDWARE_PASS。

附錄 C｜事件追蹤與反事實分析的資料格式

C.1 建議的 trace record

{
  "contract": "HardwarePlacementTraceV0_1",
  "event_id": "ev-100",
  "event_epoch": 12,
  "flow_id": "flowA",
  "owner_generation": 5,
  "topology_epoch": 12,
  "placement_plan": "plan-17",
  "observed_carrier": "cpu:1",
  "logical_message_id": "msgA",
  "physical_delivery_attempt_id": "attempt-1",
  "buffer_region_id": "regionA",
  "buffer_generation": 3,
  "logical_version": 9,
  "phase_eligibility": "eligible",
  "authority_result": "proposal_admitted",
  "device_event": null,
  "start_ns": 1000000,
  "end_ns": 1001500,
  "elapsed_ns": 1500,
  "profile_id": "prof-1",
  "measurement_status": "synthetic_example_only",
  "result_scope": "not_committed"
}

此 JSON 是合成格式示例；上面 1500 ns 不是任何 CPU/GPU 實測值。真實 trace 的 start_ns/end_ns 必須來自明確計時來源；CPU clock 與 GPU device clock 可能位於不同時鐘域，不能直接把原始 tick 當成全域絕對時間。需要跨域比較時，應使用經驗證的校正或以宿主側可觀測邊界標定，並保留 clock uncertainty。

C.2 反事實資料欄位

每個正式比較必須保存：baseline_id、experimental_id、same_input_hash、same_quality_contract、same_hardware_manifest、profiled_workload_signature、effective_unique_completions、bytes_moved、energy_scope、confidence_method、excluded_runs 與 exclusion_reason。若使用同一整機執行多個對照，還要保存熱狀態、背景程序、驅動狀態與執行順序。

C.3 時鐘與時間座標的必要限制

SMPDC 既有的相位理論不假設相位就是時鐘；本篇記錄微架構時間也不等於證明所有事件天然共享一個物理時鐘。CPU 的 invariant TSC 是否存在、OS 高解析計時器行為、GPU event timestamp 可比性、PCIe queue timestamp，均需具體平台能力與工具說明。跨 clock domain 的事件若有不確定性，就用帶誤差界的事件窗口或因果偏序，不可編造奈秒級精度。

附錄 D｜術語與型別邊界表

參考文獻與研究來源

內部 canonical 前作

• [I0] Neo.K × Aletheia, SMPDC Paper 00｜群星多主節點持續擴散計算論：形式總綱, v0.1, 2026-10-16。原始 UTF-8 Markdown：SMPDC_Paper00_Stellar_Multi_Primary_Persistent_Diffusive_Computing_v0.1_2026-10-16.md。
• [I1] Neo.K × Aletheia, SMPDC Paper 01｜多主工作流節點論, v0.1, 2026-10-16。SMPDC_Paper01_Multi_Primary_Workflow_Nodes_v0.1_2026-10-16.md。
• [I2] Neo.K × Aletheia, SMPDC Paper 02｜相位耦合與有界持續擴散動力學, v0.1, 2026-10-16。SMPDC_Paper02_Phase_Coupling_and_Bounded_Persistent_Diffusion_v0.1_2026-10-16.md。
• [I3] Neo.K × Aletheia, SMPDC Paper 03｜冗餘資訊流與主節點聚合協議, v0.1, 2026-10-16。SMPDC_Paper03_Redundant_Information_Flow_and_Primary_Node_Reconciliation_v0.1_2026-10-16.md。
• [I4] Neo.K × Aletheia, SMPDC Paper 04｜推測運算與確定性提交, v0.1, 2026-10-16。SMPDC_Paper04_Speculative_Execution_and_Deterministic_Commit_v0.1_2026-10-16.md。
• [I5] Neo.K × Aletheia, SMPDC Paper 05｜持續擴散指令集, v0.1, 2026-10-16。SMPDC_Paper05_Persistent_Diffusive_Instruction_Set_and_Executable_Semantics_v0.1_2026-10-16.md。
• [I6] Neo.K × Aletheia, SMPDC Paper 06｜擴散程式語言與可驗證編譯器, v0.1, 2026-10-16。SMPDC_Paper06_Diffusive_Programming_Language_and_Verifiable_Compiler_v0.1_2026-10-16.md。
• [I7] Neo.K × Aletheia, SMPDC Paper 07｜作業系統與 AI 動態控制架構, v0.1, 2026-10-16。SMPDC_Paper07_OS_and_AI_Dynamic_Control_Plane_v0.1_2026-10-16.md。
• [I8] Neo.K × Aletheia, SMPDC Paper 08｜CPU–GPU 異質協作, v0.1, 2026-10-17。SMPDC_Paper08_CPU_GPU_Heterogeneous_Collaboration_v0.1_2026-10-17.md。

公開技術資料與先例

• [E1] AMD, AMD Ryzen 9 9950X3D Product Specifications. 官方 16 cores／32 threads／128MB L3 等產品欄位。https://www.amd.com/en/products/processors/desktops/ryzen/9000-series/amd-ryzen-9-9950x3d.html。
• [E2] AMD, AMD 3D V-Cache Technology. 堆疊快取、晶片設計與適用架構。https://www.amd.com/en/products/processors/technologies/3d-v-cache.html。
• [E3] Linux Kernel Documentation, Page Migration. 頁面搬移與 CPU locality 原理。https://www.kernel.org/doc/html/latest/mm/page_migration.html。
• [E4] Linux Kernel Documentation, NUMA Memory Policy. mbind()、set_mempolicy() 等配置策略與限制。https://www.kernel.org/doc/html/latest/admin-guide/mm/numa_memory_policy.html。
• [E5] Linux Kernel Documentation, Stable ABI: CPU topology sysfs. 提供 core/die/cluster 與 CPU topology 部分介面。https://www.kernel.org/doc/html/latest/admin-guide/abi-stable-files.html。
• [E6] Microsoft Learn, GetLogicalProcessorInformationEx Function. Windows cache／NUMA／processor group 等拓撲列舉。https://learn.microsoft.com/en-us/windows/desktop/api/sysinfoapi/nf-sysinfoapi-getlogicalprocessorinformationex。
• [E7] hwloc／Open MPI, Portable Hardware Locality Documentation. 可攜式 CPU/cache/NUMA/I/O 拓撲模型。https://www.open-mpi.org/projects/hwloc/doc/v1.11.13/。
• [E8] Intel, Intel VTune Profiler Cookbook — False Sharing. Cache line 假共享實務範例。https://www.intel.com/content/www/us/en/docs/vtune-profiler/cookbook/2024-0/false-sharing.html。
• [E9] Intel, Intel 64 and IA-32 Architectures Optimization Reference Manual, section on preventing modified-data/false-sharing overhead。https://cdrdv2-public.intel.com/821612/248966-Optimization-Reference-Manual-V1-050.pdf。
• [E10] cppreference, std::memory_order. C++ acquire/release/relaxed 等同步語義（標準規範解讀參考，非標準原文）。https://en.cppreference.com/w/cpp/atomic/memory_order。
• [E11] Intel, Intel Core Ultra 7 270K Plus Specifications. P/E cores、threads、cache 等官方資料。https://www.intel.com/content/www/us/en/products/sku/245692/intel-core-ultra-7-processor-270k-plus-36m-cache-up-to-5-50-ghz/specifications.html。
• [E12] NVIDIA, CUDA C++ Best Practices Guide. Host/device transfer、pinned memory、資料局部性與應用效能核算。https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html。
• [E13] AMD, AMD uProf User Guide — Cache Analysis Using CLI. Memory profiling／cache line analysis。https://docs.amd.com/r/en-US/57368-uProf-user-guide/Cache-Analysis-Using-CLI。
• [E14] Linux perf／man-pages, perf c2c — Shared Data C2C/HITM Analyzer. Cache-to-cache／contention profiling；支援依 CPU/PMU 版本而異。https://www.man7.org/linux/man-pages/man1/perf-c2c.1.html。
• [E15] Intel, VTune Profiler — Memory Access Analysis for Cache Misses and High Bandwidth Issues. NUMA、LLC misses、memory bottleneck。https://www.intel.com/content/www/us/en/docs/vtune-profiler/user-guide/2024-0/memory-access-analysis.html。
• [E16] NVIDIA, CUDA Programming Guide. CUDA 非同步執行、Unified/System Memory、CUDA C++ memory model、device event/stream 與設備能力。https://docs.nvidia.com/cuda/cuda-programming-guide/index.html。

文獻引用說明

上列公開文獻支持對 CPU/cache/NUMA/CUDA 的既有技術描述，不表示這些來源證實 SMPDC 有效、驗證了本篇新增的契約或贊同其性能假說。若後續報告聲稱 SMPDC 有特定加速比，必須引用當次原始 benchmark、完整程式版本、實體拓撲 manifest、測量方法與結果，而不能只引用產品規格或技術教學文件。

原稿結案標記（Paper 09 v0.1）

• 本篇完成： 中宏觀—微觀尺度邊界、硬體拓撲和記憶體成本形式化、八項條件命題、32 條不變量、36 類反例、實機可用的 V0／V1 研究規格、Mock 契約程式、參考文獻及 Paper 10／11 交接。
• 尚未完成： SMPDC 真實 CPU／GPU runtime、HardwareCostProfile 實機資料庫、跨 CCD／NUMA 真實 benchmark、ASIC／FPGA／NoC、AI 模型 time-to-quality 與普遍性效能主張。
• 下一篇： SMPDC Paper 10｜AI 訓練與推論適用域：稀疏路由、持續模型工作流、time-to-quality、記憶體與計算效率。
• 正式來源： 本 UTF-8 Markdown 檔；數學僅保留 $...$ 與 $$...$$ 為原稿 delimiter；聊天渲染非 canonical source。