title: SMPDC Paper 01｜多主工作流節點論：CPU 核心自治、持續執行、承載映射與安全遷移
english_title: Multi-Primary Workflow Nodes: Local Autonomy, Persistent Execution, CPU-Core Mapping, and Safe Migration
series: SMPDC — Stellar Multi-Primary Persistent Diffusive Computing
paper: 01 / 11
version: 0.1
status: Full Research Manuscript — Formal Runtime Contract; Empirical Validation Pending
date: 2026-10-16
language: zh-TW
primary_concept_originator: Neo.K
research_collaboration: Aletheia / GPT-6
institution: EveMissLab / 一言諾科技有限公司
canonical_source: UTF-8 Markdown; inline math $...$ ; display math $$...$$
predecessor: SMPDC Paper 00 v0.1 (2026-10-16)
artifact_scope: Theory, typed contract, transition system, conditional propositions, falsification-first experiments

SMPDC Paper 01｜多主工作流節點論

——CPU 核心自治、持續執行、承載映射與安全遷移

英文題名： Multi-Primary Workflow Nodes: Local Autonomy, Persistent Execution, CPU-Core Mapping, and Safe Migration
系列： 群星多主節點持續擴散計算論（SMPDC）
研究主構想提出： Neo.K
研究協作： Aletheia / GPT-6
機構： EveMissLab / 一言諾科技有限公司
日期／版本： 2026-10-16／v0.1
成熟度： L0–L1：提出形式定義、契約、條件性安全命題與測試方案；未完成實機效能驗證。
承接： SMPDC Paper 00《群星多主節點持續擴散計算論：形式總綱》 [I0]。

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

摘要

SMPDC 的一項核心構想，是不把 CPU 視為僅由少數中央工作流指揮、其他核心被動接受任務的機制，而讓每一個可參與的 CPU 實體核心都成為承載本地主要工作流的候選運算節點。這個構想必須避免三種誤解：其一，「主要」不表示所有節點有權修改同一份全域狀態；其二，「持續」指工作流的邏輯身分、局部狀態與執行責任可跨事件存續，不意味核心永遠忙碌；其三，CPU 上運行的邏輯節點、作業系統執行緒、邏輯處理器與實體核心，並非可以任意互換的同義詞。

本文把 SMPDC Paper 00 的九元系統狀態向下具體化，提出**多主工作流節點（Primary Workflow Node, PWN）**的正式概念、承載關係、控制權限、生命週期與 PrimaryFlowNode Contract v0.1。契約將穩定工作流身分、局部狀態責任、依賴進度、授權、資源預算、事件世代、訊息邊界、核心親和性、承載租約、遷移 fencing token、記錄與恢復規則分離。本文刻意不把 Intel P/E 核、AMD 多 CCD、SMT、快取域及 NUMA 節點視為同一種「異質性」；它們是不同的實體限制維度，應由平台探索和量測層提供，而不由抽象拓撲想像推定。

本文建立兩項具有明確假設的安全命題：在單一授權寫入租約、不可回退世代及原子仲裁成立時，單一工作流的受控局部狀態可排除重疊有效寫入者；在有版本化快照、完整可重放事件、確定性轉移與副作用隔離的限定模型中，可以恢復相同的模型狀態。同時指出，兩個命題均不能自行證明跨外部系統的端到端 exactly-once、工作永不飢餓或 OS 固定綁核。本文最後提出可在既有桌機 CPU 上先行執行的 V0–V1 實驗規範，將傳統執行緒池、工作竊取、每核常駐服務與 SMPDC 受約束主工作流放在公平、同品質的對照下，辨認持續性、局部自治及映射策略的真正成本和收益。

關鍵詞： 多主工作流、CPU 核心自治、持續性執行、邏輯節點、核心親和性、P-core/E-core、SMT、多 CCD、局部狀態所有權、CPU 拓撲、資源租約、fencing token、安全遷移、工作竊取、可證偽效能。

1. 本篇的獨立研究任務

1.1 從「每顆星都是主要工作流」走向可運行契約

在早期群星模型與《群星架構在計算機系統中的應用與改良計畫》中，各模組被視為具有相異資源、功能與連結的自主星點 [I1–I2]。本輪 SMPDC 討論把這個形象映射到 CPU：無論大核、小核，都可以承載自身的主工作流，藉相位呼叫與資訊協議形成跨節點耦合；當存在足夠批量、可並行的關係運算時，再考慮利用 GPU 計算協作 [I0]。

若只寫「每個核心都可獨立運算」，便沒有區別於現有多執行緒、分片服務或 dataflow 的研究實質。本篇因此選擇更精確的問題：在不要求重製 CPU 微觀結構的前提下，如何讓多個具有穩定身分的本地主要工作流，在可變的實體承載位置上維持自治、正確性與生命週期？

換言之，第一篇的交付不是新的 CPU 機器指令，也不是已證實的效能優勢，而是一個後續相位擴散、冗餘、GPU 協作及語言編譯都能共同依賴的工作流節點契約。

1.2 五個必須回答的問題

RQ1｜主工作流究竟是什麼？ 一個「主節點」與傳統函式、短生命 task、OS thread、actor 或 scheduler queue 的最低差異為何？

RQ2｜哪一層具有自治權？ 本地流程可以自行做哪些決定，又在哪裡必須服從全域授權、資源限制與權威提交？

RQ3｜邏輯節點如何落到實體核心？ 如何辨認 SMT 共享資源、P/E 核執行容量、快取域、CCD、NUMA、CPU 封裝及 OS 調度限制？

RQ4｜持續、休眠與遷移能否一致？ 工作流在暫停、核心撤離、換核或故障恢復後，何以維持同一身分而不發生雙重有效寫入？

RQ5｜效能優勢在哪個條件下才可能存在？ 常駐工作流節省哪些初始化或調度成本，又可能造成什麼空轉、快取污染及容量浪費？

1.3 不歸本篇處理的內容

Paper 02 專門建立相位耦合和有界擴散的動力學；Paper 03 建立 R1/R2/R3 冗餘資訊協議；Paper 04 建立全域提交、投機與回滾的完整契約。故本篇只給出能銜接後續的最小依賴、通知、去重及權威邊界，不提前聲稱已解決跨節點一致性。

Paper 08 才會系統討論 CPU–GPU 批次關係計算的效能；本篇將 GPU 視為可選的外部 executor，絕不將它設定為實體 CPU 核心間通訊的替代品。

2. 理論尺度：節點、工作流、執行緒與核心不得混同

2.1 四種不同的「單元」

為避免模型在實作時崩解，先區分四種單元。

層級	符號	單元	主要意義
計算語義	$F$	邏輯工作流（flow）	穩定身分、局部進度、輸入輸出與責任
Runtime	$W$	執行 worker／executor	執行工作流片段的軟體排程承載者
OS／硬體呈現	$L$	邏輯處理器（logical CPU/PU）	OS 允許排程的硬體執行上下文
微架構	$C$	實體核心（physical core）	與部分執行資源、快取與電力特性關聯的物理 CPU 核

上表中，某個 $F_i$ 可以在不同時間被不同 $W_j$ 執行；同一 $W_j$ 可能在 OS 排程下更換 $L_k$ ；而多個 $L_k$ 可能屬於同一顆 $C_m$ ，例如同一實體核心的 SMT siblings。

因此：

F\neq W\neq L\neq C

這不是聲稱四個集合在數學類型上永遠完全無關，而是不可把它們的身分或數量作為同一個可替代值。

2.2 繼承 Paper 00 的核心映射

令 $V_t$ 為時間 $t$ 的邏輯工作流集合， $\mathbb P$ 為實體 CPU 核集合；沿用 Paper 00 的抽象承載映射：

\rho_t:V_t\rightarrow\mathbb P\cup\{\bot\}

其中 $\bot$ 表示未定或無正在使用的實體承載。這是模型層的可觀測映射／策略目標，不是 OS 證明某工作流在整段區間完全由該核心執行的物理保證。

為使它可工程化，新增兩個輔助映射：

\eta_t:V_t\rightarrow W_t\cup\{\bot\}

\lambda_t:W_t\rightarrow L_t\cup\{\bot\}

再以硬體拓撲映射表示邏輯處理器與實體核心的關聯：

\pi:L\rightarrow C

當一個工作流正在執行且 OS 映射可觀察時，理想關係是：

\rho_t(i)=\pi(\lambda_t(\eta_t(i)))

但在排程切換、觀測延遲、超額配置及 worker 休眠時，上式可能沒有定義，或只在某一時間點近似成立。對於具有非搶占式長片段的 CPU worker，可用綁核與 OS trace 限縮漂移；不能直接把「指定 affinity」當成「永久實體佔有權」。

2.3 分離兩種多主性

語義多主性（semantic multi-primary）： 多個工作流各自具有穩定身分、局部控制責任和持續進度。

物理同時性（physical simultaneity）： 兩個以上工作流片段在某段時間真正並行於不同的實體運算資源。

前者是本系列可由抽象 Runtime 實作的規則，後者受當下可用實體核心、SMT、OS 排程、熱功率及依賴關係限制。語義上有 24 個主要工作流，不代表硬體就有 24 顆獨立物理核心，也不代表任一時刻都能同時運行 24 段有效工作。

2.4 星系、圓環、擴散圖與物理導線

此處的「群星」「向外擴散」「圓形」均是中觀工作流圖的描述方式。不同核心在物理上可能透過快取階層、環狀互連、mesh、封裝結構或其他機制通訊。工作流圖中的邊不自動等於晶片上的導線，也不保證兩節點具直接通路。

3. 實體平台的拓撲型別

3.1 不應僅以品牌或總核心數分類

令每個可參與實體核心 $c$ 擁有觀測到的能力描述：

H(c)=\langle a_c,s_c,p_c,d_c,k_c,n_c,q_c,u_c\rangle

$a_c$ ：支援的指令能力及適用特性（ISA／微架構）。
$s_c$ ：SMT 關係及可見硬體執行上下文。
$p_c$ ：效能與能效類別，允許未知或平台特有編碼。
$d_c$ ：快取共享、封裝、cluster／CCD 等拓撲域。
$k_c$ ：對給定工作負載可估的計算容量，不視為固定常數。
$n_c$ ：NUMA 或記憶體存取關係。
$q_c$ ：OS 當時准許的 affinity、CPU set、停泊與保留條件。
$u_c$ ：當時利用率、溫度、功率、干擾及其他可觀測狀態。

這個描述本身不預設所有欄位都能被相同精度觀測。若 $p_c$ 或 $n_c$ 不可取得，就要標記 unknown，不能由品牌名稱推斷。

3.2 Intel P-core／E-core

P/E 核的差異可以反映微架構、執行寬度、快取、時脈及單位能源效能等特性，但每個平台世代仍可能不同。Intel Thread Director 的作用是向 OS 提供與執行緒特性及核心條件相關的建議資訊，不是把應用程式隨意綁核後就自動取消 OS、驅動或功率限制 [E1]。

因此本篇的合理實驗是同一工作流語義跨不同核心類型的適應性：例如短分支型工作、高頻低優先級通知、較長運算工作與同步敏感工作如何配置；不能預先宣告 E-core 永遠適合某個角色，或 P-core 必然只處理「主」工作流。

3.3 AMD 多 CCD／3D V-Cache 的另一種異質性

相同 Zen 家族的多顆核心可以在 ISA 層近似同質，卻因 CCD、共享 L3 容量或快取存取距離而有不同成本。若其中一組 CCD 配有不同的快取配置，這是快取／局部性異質性，不等同 Intel 式 P/E 微架構異質性。

因此用 AMD 多 CCD 實驗時，應研究狀態常駐、跨 CCD 傳輸、快取命中率、局部聚合及 migration cost；用 Intel P/E 核則可特別研究工作流容量與能效不對稱。兩者可互補，但其輸出不可不加區分地合併為單一「異質優勢」。

3.4 SMT／邏輯執行緒

若實體核心 $c$ 擁有兩個邏輯處理器 $\ell_1,\ell_2$ ：

\pi(\ell_1)=\pi(\ell_2)=c

則兩個邏輯處理器會共享該核心的部分執行資源，不能依 OS 顯示的執行緒數推得兩倍獨立核心容量。測試必須同時報告每實體核心和每邏輯處理器的結果。初始的正確性原型可以停用 SMT 或只使用單一 sibling 作為簡化對照；但此決定也要納入 BIOS／OS 設定記錄。

3.5 CPU 群組、NUMA 與容器限制

OS 顯示可用核心不代表應用程式被允許使用全部核心。Windows 可使用 CPU Sets API 取得群組、核心、快取、NUMA 和效率類別等資訊；Linux 的親和性遮罩還可能受到 cpuset／cgroup 及可用 CPU 的交集限制 [E2–E4]。

容器、虛擬機與多租戶環境下，應將「硬體真的存在」「OS 看得見」「當前程序允許使用」「當前 worker 實際執行」四件事分離。

4. Primary Workflow Node 的最小定義

4.1 四項必要條件加兩項執行條件

定義 $F_i$ 為 SMPDC 的本地主要工作流，至少須具有：

穩定身分： 不因 worker、核心或負載變更而改變 flow_id。
局部狀態責任： 有自己的狀態版本與合法更新方式。
可追蹤進度： 可以描述尚缺哪些輸入、正執行哪些片段、何時已完成自己的當前階段。
有限自治決策： 能在授權與預算範圍內決定本地下一步或提出協作請求。

進入實際可執行 Runtime 後，另須滿足：

具型別的輸入／輸出： 不允許把任意原始資料直接當作已驗證權威狀態。
可受控的生命週期： 能休眠、被暫停、恢復、遷移或關閉，且留下必要證據。

符合此定義的 $F_i$ 是一項邏輯工作流制度，不要求其永久對應唯一硬體 worker。

4.2 「主」只表示本地責任，不表示凌駕全部系統

設 $\Omega_i$ 為工作流 $i$ 的授權作用域。定義本地自治決策集合：

A_i(t)\subseteq\Omega_i\cap\operatorname{ResourcePermit}_t(i)

該工作流可以選擇如何處理自己的合法輸入、在什麼條件下將候選輸出送出、是否進入睡眠、或要求更多資源，但不能因其自稱 primary，便無條件持有其他工作流的記憶體寫入權、設備控制權及全域提交權。

多主不是多個無限制的最高權威。 全域政策可以是分散實現，也可以是集中式審核；但不應因為保有一個控制層，就把局部工作流誤稱為「被動從屬」。

4.3 工作流的結束條件與持續條件

常規短 task 可以「只要某函式返回就銷毀」。PWN 則具有長於單次呼叫的邏輯生命週期；即使沒有新任務，也可以保存身份、依賴與狀態，直到達到顯式 close 或撤銷條件。

持續性不要求無限生命週期。 它只要求生命週期不由一次 dispatch 自動決定。為避免名詞空洞，實驗須紀錄至少一次跨事件的身份保留、狀態保存及合法再啟動，才能稱當次測試真正使用「持續性工作流」。

5. `PrimaryFlowNode Contract v0.1`

5.1 合約目的與非目的

此合約是後續 Paper 02–08 使用的規範化中介契約，而不是已定案的 wire-format、CPU opcode 或現成可編譯語言。它描述哪些屬性必須存在、何種操作合法，以及哪些事件可成為可重播證據。

合約可供 Rust、C++ 或其他 Runtime 實作，也能降成傳統 OS 執行緒與佇列，不需要第一階段就更改作業系統核心或 CPU 微碼。

5.2 具型別欄位

PrimaryFlowNodeContractV0_1 {
    flow_id: StableFlowId
    flow_generation: MonotonicGeneration
    logical_epoch: MonotonicEpoch
    current_state: FlowLifecycleState

    principal_id: SecurityPrincipalId
    authority_scope: CapabilitySet
    local_state_ref: OwnedStateReference
    state_version: MonotonicStateVersion
    state_schema_id: SchemaIdentifier

    inbox: TypedInboundMailbox
    outbox: TypedOutboundMailbox
    dependency_view: VersionedDependencyView
    progress_cursor: ProgressMarker

    execution_policy: LocalPolicyDescriptor
    scheduler_policy: SchedulerPolicyDescriptor
    resource_budget: ResourceBudget
    allowed_actions: EffectCapabilitySet

    desired_cpu_set: OptionalCpuSet
    observed_processing_unit: OptionalLogicalCpu
    observed_physical_core: OptionalPhysicalCore
    topology_generation: TopologySnapshotVersion

    binding_lease: OptionalExecutionLease
    fencing_token: MonotonicFencingToken
    lease_expiry_policy: LeaseExpiryPolicy

    checkpoint_ref: OptionalVersionedSnapshot
    replay_policy: ReplayContract
    external_effect_policy: ExternalEffectContract

    observation_policy: TraceContract
    failure_policy: RecoveryContract
}

為了減少 payload 膨脹，實作不必在每個事件重傳所有靜態欄位。欄位可拆成穩定 metadata、綁定 lease、快速路徑狀態和追蹤資料；語義上可解析即可，不代表所有欄位要放在單個 cache line 或單個資料封包內。

5.3 五類欄位的責任劃分

欄位家族	責任	必須保證或說明的性質
身分與世代	辨認同一工作流及歷次執行	ID 穩定；世代不得回退
狀態與依賴	保存局部資料及進度	單一有效寫入者或明示的併發演算法
權限與預算	界定自治可做的事	不得因本地最佳化而擴權
承載與租約	對應 worker、OS 和 CPU	desired 與 observed 分離；遷移需要 fence
恢復與證據	崩潰後重建與可反駁	完整性、版本、未提交副作用策略

5.4 十六條規範不變量

PFN-01｜穩定邏輯身分

對未經正式 close 且未建立新邏輯工作流的生命週期：

\operatorname{flow\_id}_i(t)=\operatorname{flow\_id}_i(t+\Delta t)

綁核或換 worker 不得改寫此身分。

PFN-02｜實體承載非身分

核心 ID、OS thread ID、CPU Set ID 及 GPU queue ID 不得作為 flow_id 的唯一判定依據。

PFN-03｜世代單調

同一工作流的 flow_generation、logical_epoch 及有效 fencing_token 各自遵守規範化的單調遞增／不回退策略。它們不是同一欄位，不能互相任意代換。

PFN-04｜單一受控狀態寫入權

在標準的單擁有者狀態模式下，同一 flow_id 及狀態版本區間只允許一個具有有效授權 lease 的寫入執行者；若採多寫入者資料結構，必須由另立的並發記憶體模型明確定義，而不能暗中放寬。

PFN-05｜輸入先通過來源／版本檢查

收到訊息不代表可信，也不代表依賴滿足；至少需核對必要的身分、epoch、版本、schema 及權限。

PFN-06｜本地狀態變更和跨域輸出分離

本地暫態改變、候選訊息送出及權威提交是不同效果。特別是可撤銷候選結果不能被當成已提交資料。

PFN-07｜非越權自治

節點的自主決策只能在授權和配額允許的集合內。過度資源使用或新裝置權限必須走有驗證的請求程序。

PFN-08｜無工作可休眠

persistent 不代表忙等；當沒有有意義的本地工作時，Runtime 應允許 Blocked、Dormant 或 Quiescent，並記錄喚醒條件。

PFN-09｜遷移前撤銷舊寫入權

若新執行者將接手受控局部狀態，舊執行者的 lease 需先失效，或由共同的原子 fencing 規則確保其後續寫入被拒絕。

PFN-10｜觀測值不可冒充保證

desired_cpu_set 只是一個排程約束／偏好，不可自動等同實際執行位置；observed_physical_core 需標示觀測時刻和來源。

PFN-11｜邊界內有背壓

inbox/outbox 及工作流事件佇列須有容量策略：可等待、阻塞、拒絕、丟棄非關鍵項、降級或外溢；不得默認可無限膨脹。

PFN-12｜進度可觀測

至少需要區分已收到、已開始、已完成本地計算、已輸出候選，以及已被權威接受的狀態，避免把 CPU busy 當作完成量。

PFN-13｜撤銷可生效

若工作流被取消或降權，必須有下次安全檢查點與停用效果的界線；不可宣稱任意 user-space 指令會瞬間停止正在執行的所有副作用。

PFN-14｜失效不自動等於完成

worker 崩潰、CPU 被撤離、資料損毀或逾期時，流程需進入明確的恢復或失效狀態；不能因 lease 消失便偽造成功提交。

PFN-15｜可檢測的拓撲漂移

CPU 上下線、OS affinity 規則變更、核心停泊、容器 CPU quota、功率限制及平台重配置，都可以使原配置失效；需要新 topology snapshot 或 rebind 事件。

PFN-16｜AI 建議不可突破安全契約

無 AI 時系統須能運行；有 AI 時，其 placement、batching 或休眠建議不得覆蓋 PFN-01–15。

6. 工作流自治與權威的邏輯劃分

6.1 三種不同的決策權

對某工作流 $i$ ，分別定義：

局部執行權 $E_i$ ： 在合法資料與預算內運行本地計算片段。
傳播請求權 $D_i$ ： 向其他工作流提出訊息、依賴或未來耦合請求。
結果提交權 $K_i$ ： 對一個權威域發出可接受的正式狀態變更。

一個主工作流可以擁有 $E_i$ 與部分 $D_i$ ，卻完全沒有某個外部權威域的 $K_i$ 。這不使其「非主要」；它依然對自己的狀態和進度負主要責任。

6.2 不是把 OS Scheduler 擬人化

「CPU 主工作流會自行判斷」是 Runtime 語義，不表示 CPU 核心物理上自行理解任務目的。實作中，程序碼、狀態機與策略控制器執行判斷，OS 維護可排程性，硬體執行合法指令。若使用 AI planner，它也只是在既有控制平面提出建議，不會取代硬體權限檢查。

6.3 單機也可以具有多主工作流

多主並不要求跨伺服器、網路或遠端資料中心。兩個 CPU 工作流如果有獨立狀態和本地自治規則，即使共同執行於一台舊款 AMD CPU，也已能進行最小語義測試。將來接 GPU、跨 CCD 或分散式系統屬後續映射問題。

6.4 局部自治的最小決策回圈

對每一個被喚醒的 $F_i$ ：

observe permitted local inbox + state version
validate caller identity, epoch, payload schema, authority
update local readiness and pending dependencies
choose one locally legal next effect
check local quota and current binding lease
execute bounded work slice
publish versioned candidate events if permitted
checkpoint / block / yield / continue

這是模型流程，不是某個特定 CPU 執行緒必須照上述順序執行每一條指令。尤其決定是 yield、等待事件還是繼續工作，仍應由實際延遲、能耗與 OS 合約共同決定。

7. 工作流生命週期：狀態機與守衛條件

7.1 狀態集合

定義狀態集合：

\mathcal Z=\{Created,Dormant,Ready,Active,Blocked,Quiescent,Paused,Migrating,Recovering,Failed,Closed\}

其中：

Created：已建立身分，尚未完成所有啟動條件。
Dormant：保留邏輯生命週期但沒有即時可執行工作。
Ready：合法依賴與最低權限已就緒，等待可用承載。
Active：在有效租約之下執行有界片段。
Blocked：等待外部資料、資源或可滿足的依賴。
Quiescent：已排空或隔離待處理副作用，適合快照、切換或關閉。
Paused：策略或外部限制要求暫停工作。
Migrating：遷移協議進行中；可能沒有有效執行者。
Recovering：失效後進行安全狀態重建與重綁定。
Failed：不能繼續正常工作，需外部仲裁或終止。
Closed：邏輯生命週期正式結束。

Quiescent 只是對特定作用域達成定義好的無新效果狀態，不等於系統中全部執行緒都完全停止；其穩定性仍須由 lease 與消息協議保證。

7.2 狀態轉移表

從	到	最低守衛條件	必要副作用
Created	Dormant	身分、作用域、schema 建立完成	記錄建立事件
Dormant	Ready	有效輸入或定時條件且未撤銷	更新依賴狀態
Ready	Active	執行承載可用、lease 有效、預算充足	記錄執行者及 lease
Active	Ready	當次 time slice 完成，仍有可做工作	yield 並保存進度
Active	Blocked	本地下一步依賴未滿足	註冊喚醒條件
Blocked	Ready	依賴已驗證滿足且可調度	更新 readiness
Active	Quiescent	本地安全檢查點到達，待提交效果已管理	封存可遷移狀態
Quiescent	Migrating	遷移獲批准，舊 lease 被撤銷或 fence	轉出版本化狀態
Migrating	Ready	新 lease、fence、快照及權限均核對成功	更新承載映射
Active	Paused	preemption、降載或資源策略	暫停／延遲執行效果
Paused	Ready	恢復條件有效	記錄恢復原因
任意非 Closed	Recovering	可重建故障且具有合法恢復途徑	禁止舊 lease 新寫入
Recovering	Ready	完整性、版本及權限檢驗通過	重建可運行工作流
任意非 Closed	Failed	達到不可恢復／未知狀態門檻	記錄失敗，不偽造完成
Dormant／Quiescent／Failed	Closed	完成關閉流程及權限收回	釋放可回收資源

上表代表允許的最低轉移類型。正式模型不應把任何錯誤都自動導向 Ready，否則恢復路徑可能產生永久重試與活鎖。

7.3 工作流生命週期與工作片段生命週期分離

同一個 $F_i$ 可以在多個 epoch 內先後承擔 $q_{i,1},q_{i,2},\ldots$ 。個別片段可以完成、取消或重新排程，而不必銷毀 $F_i$ 的穩定邏輯身分：

\operatorname{FlowAlive}(i,t)=1\not\Rightarrow\operatorname{WorkerBusy}(i,t)=1

這條區分是持續性工作流是否真的不同於「反覆建立任務」的核心測試點。

7.4 忙等、輪詢與事件休眠

持續性有三種可能實作：

持續 busy-poll：高活動率場景可能降低喚醒延遲，卻提高能耗與核心占用。
阻塞式事件／通知：低負載適合節能，但喚醒可能引入延遲及抖動。
混合式自適應等待：短時間自旋、超時後進入事件休眠，依實測調整。

本系列不預設第一種永遠更快。DPDK 的 per-lcore Poll Mode 模型是一種已成熟的對照，其高性能建立在特定工作負載及共享資源安排下 [E5]，不能直接泛化到所有 AI 推論或低頻事件系統。

8. 合法承載、綁核與可遷移性

8.1 Desired、eligible、observed 必須分離

對邏輯工作流 $i$ 定義三個集合／觀測量：

D_i(t)=\text{desired CPU set}

A_i(t)=D_i(t)\cap\text{OS permitted CPU set at }t

O_i(t)=\text{observed execution location}

如果 $A_i(t)$ 為空，就不能假裝該工作流已被成功綁核；需採用 unbound、blocked 或降級規則。即使 $A_i(t)$ 不為空，實際觀測位置也可能因 OS 排程和工作流執行時點而動態變更。

在 Linux，sched_setaffinity 規範的是執行緒可被排程的 CPU 遮罩，受系統存在、允許集合與 cpuset 等條件影響 [E3]；Windows 則可透過 CPU Sets API 表達執行緒候選 CPU 集合 [E2, E4]。

8.2 承載租約（execution lease）

為避免兩個 worker 因誤判或遷移競爭，同時以合法身分修改同一工作流狀態，給每次承載一個具權限界線的 lease：

\ell_i=\langle flow_i,worker_j,g_i,cap_i,expiry_i\rangle

其中 $g_i$ 為單調 fencing 世代， $cap_i$ 是該 lease 的效果權限。expiry 只是必要時的時間限制，不能只靠兩台機器的本地時鐘保證互斥；關鍵寫入須由能判定最新世代的狀態權威或原子仲裁點拒絕舊 token。

在單機 V0 可用 mutex／原子世代建立最小仲裁；在跨程序或崩潰持久化環境，需有持久狀態或更強的協調機制，並屬 Paper 04 的權威提交範圍。

8.3 遷移的安全順序

推薦的最低程序：

M0 request_rebind(flow_id, proposed_target)
M1 stop admitting new authoritative local effects on old executor
M2 reach bounded quiescent / safe checkpoint
M3 atomically advance fencing generation
M4 snapshot or publish versioned owned state
M5 validate destination resource/permission/topology
M6 acquire new lease with current fencing token
M7 restore state, dependencies, cursor and replay boundary
M8 resume on new executor, record placement observation
M9 garbage-collect old worker-local disposable resources

若採更高階的無停機遷移，可將 M2 部分工作與資料複製重疊，但不得將舊、新執行者寫同一權威狀態的競態省略掉。若 M3 和 M6 之間沒有安全的共同仲裁，應在研究報告標記該策略不具安全保證。

8.4 遷移成本不能免費

對一次工作流遷移，建立可量測成本：

T_{move}=T_{quiesce}+T_{state}+T_{rebind}+T_{warm}+T_{resume}+T_{verify}

實機量測時，這些階段可能重疊，故公式是成本構成分類而非保證可把每項牆鐘時間直接相加。端到端應另量測 wall time，避免重複計算。

其中常見影響包括冷快取、遠端 NUMA 存取、核心類別切換、依賴重新建立、in-flight 訊息版本過期與 worker 啟動。即使沒有新的指令設計，這些成本也足以讓不當的「多主擴散」輸給普通常駐工作竊取排程。

8.5 核心下線與平台熱限制

實體 CPU 可能因系統策略、CPU hotplug、停泊、熱限制或容器限制而暫時不再可用。Linux CPU hotplug 已有明確的 online/offline 狀態機 [E6]。SMPDC 若要支援此種環境，Runtime 必須能使受影響工作流安全地暫停、重排或遷移，而不是把「每核都是主要節點」誤解為核心永遠不可退出。

9. 局部狀態所有權、訊息邊界與記憶體模型

9.1 先採單擁有者原則，再研究更強的並行寫入

第一階段建議每個工作流的可變受控狀態僅由有效 lease 持有者修改；其他工作流可讀版本化快照、發送變更請求或取得明確授權。這種模式減少多核共享寫入競爭，但不表示完全消除 CPU cache coherence 的傳輸成本。

若局部狀態需要多個 worker 實時併發修改，則必須使用正確的 mutex、atomic、transaction 或經形式驗證的並發資料結構，並註明記憶體序與資料競爭界線。

9.2 核心協作優先使用明確訊息邊界

假設 $F_i$ 將某次狀態變更候選送給 $F_j$ ：

send {
    source_flow: F_i,
    destination_flow: F_j,
    epoch: e,
    state_version: v,
    payload_schema: s,
    effect_class: "candidate_delta",
    rights: "request_only"
}

這表示 $F_i$ 提供資料及請求，不能直接越過 $F_j$ 的狀態所有權去修改對方記憶體。真正的訊息冗餘與因果聚合留待 Paper 03–04；本篇僅保證界線型別。

9.3 佇列設計有實際成本

SPSC、MPSC、MPMC queue 的生產者與消費者數量限制不同。最初可採正確但未必最佳的 mutex queue；必要時再進入 lock-free ring buffer。採 lock-free 不意味成本為零：仍可能遭遇 contention、ABA、記憶體回收錯誤、false sharing 或跨 CCD cache-line bouncing。

若使用 C++ 原子操作，release/acquire 的同步必須出現在正確的同一 atomic 物件之上，並符合實際同步關係 [E7]。若資料尚未具備 happens-before 關係，就不能因為測試偶然成功而宣稱無 data race。

9.4 快取域比抽象網路圖更重要

兩個工作流在邏輯拓撲上相鄰，不代表它們在同一 L2、L3 或 NUMA 域。甚至同一顆實體核心的 SMT sibling 也可能互相爭奪前端與執行單元。相位耦合的預測成本必須逐步吸收實際硬體局部性測量，而非只沿用圖節點之間的虛構距離。

10. 工作流配置策略：局部自治不等於禁止全域排程

10.1 兩層調度模型

全域 placement／resource layer： 判斷哪些工作流可使用哪些核心、資源配額、熱功率界線、跨 CCD 或跨快取域的成本。

局部 progress layer： 在自己的合法空間內，選擇下一段工作、需等待的依賴、釋放控制、提出擴散請求或提交候選。

這兩層可以同時存在。前者不必對每一筆運算重新發出命令，後者也沒有權力繞過已核准的全域資源上限。

10.2 固定綁核與動態配置的對立

「每個主工作流固定綁一顆實體核心」可以是 V1 的一個重要對照組，但未必是最佳常態。核心固定時可能有快取局部性收益，也可能使負載不平衡、長任務阻塞或核心閒置。動態遷移可改善利用率，卻可能帶來快取失效、熱點與更多同步成本。

應至少比較：

Pinned-1:1：一個長壽工作流配一顆可用實體核心。
Pinned-Many:1：多個長壽工作流分時配置在一顆實體核心。
Unpinned-Workers：OS 可自由調度 worker。
Topology-Aware：依核心類別、快取域與負載估計決定配置。
Work-Stealing：成熟的工作竊取佇列與 worker pool。

它們都是工程策略，不是不同的計算本體。

10.3 容量與成本函數

令 $c$ 是候選承載核心， $i$ 是工作流；提出一個不固定權重的配置成本：

J(i,c,t)=\alpha L(i,c,t)+\beta M(i,c,t)+\gamma E(i,c,t)+\delta Q(i,c,t)+\zeta R(i,c,t)

其中 $L$ 是可估延遲， $M$ 是資料搬移／局部性成本， $E$ 是能源， $Q$ 是佇列與等待風險， $R$ 是預測的遷移或可靠性成本。係數由工作負載與政策決定，不是通用物理常數。

可行配置須另符合硬條件：

\operatorname{Permit}(i,c,t)=1

\operatorname{CapacityFeasible}(i,c,t)=1

注意： 在有共享 LLC、記憶體頻寬或熱功率約束時， $J$ 不是每個核心各自獨立求最小就必然達全域最優。多個配置決策會互相干擾；最早階段可採啟發式，再由實測決定是否值得引入更複雜的規劃器。

10.4 防止頻繁遷移的滯後條件

若新的候選核心只比現有核心稍好，立刻遷移可能不划算。可要求：

\widehat{G}_{move}>\widehat{C}_{move}+\theta

其中 $\widehat{G}_{move}$ 是在規劃時窗內預估的收益， $\widehat{C}_{move}$ 是遷移總成本， $\theta$ 為避免頻繁震盪的滯後裕度。若估計不可靠，應允許保守不遷移或僅在可回滾情況下探索。

10.5 防止永久飢餓與優先級逆轉

局部主工作流持續占有 CPU，不應讓其他必要工作永久得不到執行。Runtime 必須提供合理的公平性／deadline 規則及讓出時間片的機制。當某主工作流等待其他節點完成工作時，長時間占用 P-core 進行空轉，可能造成優先級反轉與整體吞吐下降。

有關哪些排程策略在特定異質 CPU 上有效，可參照 Linux 的 Capacity Aware / Energy Aware Scheduling 文件作為已成熟的比較背景 [E8–E9]；不能把「考慮核心容量」誤當作本系列獨創。

11. 條件性安全命題與邊界

11.1 命題 A：單一工作流受控狀態的有效寫入互斥

假設 A1： 存在為每個 flow_id 提供線性化仲裁的權威儲存位置或原子記憶體物件。
假設 A2： 每次承載取得唯一、不可回退的 fencing token，且新 token 發出後舊 token 在必要的寫入仲裁點必定無效。
假設 A3： 對受控局部狀態的所有合法寫入必須通過該仲裁點；不存在繞過它的 side channel。
假設 A4： 仲裁點符合選用的記憶體模型，工作流身分沒有別名混淆。

命題 A（有條件的受控寫入互斥）： 在 A1–A4 下，任何同一工作流的兩個不同承載者，不能同時成功取得對同一受控狀態版本的相互衝突寫入授權。

證明概要： 由 A1 的線性化順序，同一 flow_id 的候選權限更新可排序；A2 使最新世代撤銷先前世代的有效性。由 A3，所有寫入都經此判定；因此只有符合當前世代的執行者能在該仲裁點被允許寫入。這只排除模型內受控狀態的競爭，不保證未經仲裁的外部設備副作用安全。

反例： 如果舊 worker 可以拿舊指標直接修改與租約系統無關的共享記憶體，A3 不成立，即使另有一份最新 fencing token 記錄也不能保證互斥。

命題地位： 條件性安全性推論；尚無模型檢查、程式證明或故障注入實測。本篇不以此聲稱整個 SMPDC 已證明 race-free。

11.2 命題 B：局部狀態的限定可重播性

假設 B1： 初始快照包含重建所需的完整、無歧義局部狀態版本。
假設 B2： 之後所有會影響該工作流模型狀態的合法事件，都依可確定順序完整記錄。
假設 B3： 給定相同模型狀態與事件，局部轉移函數在使用的語義層次上具有確定性。
假設 B4： 外部不可逆副作用被隔離、可查詢、可安全重試或不屬於欲重播的模型狀態。

定義 $S_0$ 為快照、 $e_1,\ldots,e_n$ 為已記錄的事件，以及決定性轉移 $\delta$ ：

S_n=\delta(\delta(\cdots\delta(S_0,e_1),e_2)\cdots,e_n)

命題 B（限定模型狀態可重播性）： 在 B1–B4 下，從相同 $S_0$ 按相同事件順序套用 $\delta$ ，可重建相同的模型層工作流狀態 $S_n$ 。

證明概要： 對事件數 $n$ 歸納。 $n=0$ 時兩次執行的初始狀態相同；若第 $k$ 步狀態相同，B3 使對相同事件 $e_{k+1}$ 的轉移結果相同，因此第 $k+1$ 步相同。

明確不包含： OS 排程逐 cycle 完全相同、GPU 浮點運算 bitwise 相同、外部網路重試沒有副作用、跨多個權威域的 end-to-end exactly-once。這些均需額外契約。

11.3 有條件的活性假設，不宣稱定理成立

當所有依賴最終可滿足、OS 提供足夠的公平調度、必要核心或替代承載最終可用、資源預算不永久耗盡且工作流本地每段可終止時，某些等待節點可以最終恢復進度；但這些是假設而非可由「持續性」一詞推出的保證。

若某工作流永遠等待失聯節點、持續性高優先級 busy-loop、或 lease 永不釋放，則本系列不能保證整體活性。因此 V0 必須主動注入飢餓、失聯、延期、撤銷與死鎖反例。

12. 為何常駐主工作流可能更快，也可能更慢

12.1 常駐並非免費加速

假設任務族有 $N$ 次相似事件。以每次建立／釋放工作環境的基線，其總成本可粗略分類為：

T_{ephemeral}=\sum_{r=1}^{N}(C_{create,r}+C_{exec,r}+C_{teardown,r})+C_{shared}

採用持續性工作流後：

T_{persistent}=C_{init}+\sum_{r=1}^{N}(C_{wake,r}+C_{exec,r}+C_{maintain,r})+C_{lifecycle}

二者均為成本分解模型，而非必然適合直接相加的重疊階段時序模型。常駐設計若能以已保留的狀態減少重複初始化，可能產生優勢；但若每次事件都很小、需要頻繁跨核同步，C_maintain 或 C_lifecycle 可能更高。

簡化成每事件平均成本後，若要讓常駐模式在同品質下有淨收益，至少需要：

(C_{create}+C_{teardown})-(C_{wake}+C_{maintain})>\frac{C_{init}+C_{lifecycle}-C_{shared}}{N}

此式僅作設計 break-even 的候選條件；每項成本應來自相同工作負載、相同量測範圍的實際數據，且須避免重複計入共享資源開銷。

12.2 常駐工作流的潛在效益來源

避免頻繁建立／銷毀局部狀態、執行緒或短期執行環境。
減少反覆重建工作流依賴及事件索引。
讓資料及工作狀態更常停留於適當快取與記憶體域。
在多階段、稀疏事件串流中縮短不必要的控制路徑。
讓可等待、可聚合的工作保留局部進度，而非每次從零恢復。

這些不是所有 CPU 工作的共同優勢。例如成熟執行緒池原本就會重用執行緒，成熟 actor 系統原本就保留邏輯身分，故 SMPDC 必須與真正經過調優的常駐 baseline比較，而不只是與每次重新建立 OS thread 的劣質版本對比。

12.3 常駐工作流的潛在負效益

為數量過多的工作流保留狀態造成記憶體壓力。
不必要的 cache-line 寫入使核心相互失效。
為避免喚醒時間而過度自旋，使功耗及背景干擾升高。
綁核使負載不平衡，無法利用其他閒置實體核心。
遷移與重新溫熱成本抵銷預估收益。
局部自治策略互相爭取同一快取、NUMA 或記憶體頻寬。
多個主工作流若反覆跨核查詢彼此狀態，可能放大同步數量。

12.4 多目標而非 CPU 使用率單指標

建議比較：

\mathcal P=\langle T_{end},L_{p99},E_{total},M_{peak},Q_{correct},F_{recover}\rangle

$T_{end}$ 為完整端到端時間， $L_{p99}$ 為尾延遲， $E_{total}$ 為總能耗， $M_{peak}$ 為記憶體峰值， $Q_{correct}$ 為有效正確成果， $F_{recover}$ 為故障恢復品質／時間指標。所有量應先定義相同的單位與方向，避免在沒有權重來源時強行壓成單一分數。

13. 與成熟技術的精確對照

已有技術	已具備的成熟能力	SMPDC Paper 01 可新增的候選研究增量	若無實證須承認的重疊
OS threads／thread pools	常駐執行緒、排程、阻塞與同步	穩定 flow 語義與硬體承載映射分離	常駐 worker 並非新發明
Chase–Lev 類 work stealing	低開銷多 worker 分工與負載平衡	有限自治、租約化主工作流及相位接口	工作竊取本身不是新穎性 [E10]
Seastar `sharded`	在邏輯核心分片服務並跨分片通訊	將長壽邏輯工作流與可遷移實體核心映射形式化	每核分片服務已有成熟範例 [E11]
DPDK per-lcore loop	per-core queue、polling、run-to-completion／pipeline	在不同 AI／事件負載比較休眠、遷移和多主控制	每核輪詢並非新創 [E5]
Intel Thread Director	異質 CPU 工作放置提示	本地主要責任／相位條件與 OS 核心策略分層	P/E 核感知排程已有成熟技術 [E1]
Linux capacity／energy scheduling	CPU 容量、能量模型與合法拓撲調度	延伸至流身分、自治與相位語義	容量感知不是獨創 [E8–E9]
GCCFT／GCCWT／GCM	計算場、全域規劃、資源權威	單機近硬體尺度契約與完整物理量測對照	不重寫抽象耦合本體 [I3–I5]

真正要檢驗的是：上述成熟元素搭配 SMPDC 的明確語義、狀態契約、具型別相位及後續資訊協議時，是否在某些工作負載上形成可靠而具有淨效益的新執行模型。這是有條件的研究方向，不是既成的獨創性結論。

14. Paper 01 的 V0–V1 可證偽實驗計畫

14.1 預先定義的實驗假說

H01-PERSIST： 對反覆處理相似事件的工作負載，穩定主工作流可能降低特定重複初始化和排程成本。

H02-LOCALITY： 當資料局部性強且工作負載平衡，恰當的核心綁定或拓撲配置可能改善端到端性能。

H03-HETEROGENEITY： 不同核心容量及快取域會影響同一主工作流配置；最佳 placement 依工作負載而變。

H04-RESILIENCE： 在明確 lease、fencing 和版本化狀態下，核心切換及故障恢復可避免雙重有效寫入。

H05-LIMIT： 當事件過短、共享頻寬飽和或遷移頻繁時，SMPDC 可能不如成熟的 worker pool／work stealing。

14.2 V0：先以模擬器驗證契約而不宣稱效能

V0 只依賴可控制的離散事件與模擬時間。測試：

連續跨 epoch 事件後 flow_id 不變。
desired_cpu_set 不合法時不能憑空變成 Active。
非法 schema、過期 epoch、失效權限被拒絕。
舊 lease 收到延遲訊息時不能在新的 fencing 世代寫入受控狀態。
遷移中不能產生兩個同時被接受的局部狀態寫入者。
狀態機不允許 Closed → Active 等非法轉移。
容量不足時執行 backpressure／降級策略，且不能無上限擴張佇列。
同一快照和同一具決定性的事件序列重播，得到相同模型結果。
CPU 核心撤離後，工作流能被標記 Paused/Recovering，而不是自動成功。
裝置權限撤銷後，AI 或 local policy 不能自行恢復權限。

最小輸出為測試事件 trace、失敗樣本、可重播 seed、覆蓋的狀態轉移集合，以及至少一份反例檢查紀錄。

14.3 V1：使用現有實體 CPU 進行對照

首輪 V1 可以利用既有一般桌機，不必先購買高價 CPU。已知目前原型候選平台包含舊款 AMD CPU、32 GB 主記憶體與 RTX 3070；目前尚未更換主電腦，也未購買 MINISFORUM N5 Pro AI NAS。V1 主要是 CPU 測試，GPU 不構成本篇必要條件；CPU 確切型號、核心／執行緒數及 OS 版本由實機盤點，不得由歷史記憶擅自填入。

基本流程：

盤點 CPU package、實體核心、OS 邏輯處理器、共享快取、可能的 NUMA 域與可用 CPU Set。
固定電源方案、負載輸入、背景程式、韌體／驅動及編譯器版本，並記錄熱狀態。
建立 B0、B1、B2、B3 各對照組，確保結果正確性相同。
以相同資料集、事件速率及可用硬體，在隨機化次序下重複多次。
同時量測完整執行時間、等待、排程遷移、有效進度及 CPU／記憶體相關計數。
明確分離 cold start、warm state 與長期穩態測試，避免把初始化差異藏在測量邊界之外。
報告中位數、P95／P99 及散布／區間；不得只擷取最佳一筆。

14.4 建議的基準配置

組別	執行模型	必須相同的條件
B0	標準 thread pool + queue	工作邏輯及有效輸出
B1	成熟 work-stealing runtime	相同總核心預算及輸入事件
B2	每核心常駐 worker／分片服務（無 SMPDC 語義）	相同持續資源成本及外部資料
B3	PWN Contract、持續邏輯 flow、無相位擴散	評估主工作流契約本身開銷
B4	B3 + 選擇性的綁核／拓撲配置	評估 placement 的邊際效果
B5	B4 + 受控遷移／恢復	評估彈性與故障成本

此處的 B3–B5 只是 Paper 01 實驗標號；Paper 00 的 B0–B7 是整個系列的跨篇配置，兩者不應被當作完全相同的 benchmark 版本。正式報告應使用 paper01_Bx 識別以免混淆。

14.5 工作負載矩陣

負載族	需要檢驗的性質	預期負面風險
A：低頻事件，事件間長時間閒置	持續身分與休眠成本	常駐 busy-poll 浪費能源
B：高頻小事件，輕微狀態更新	wakeup／queue／cache-line 成本	發送與同步成本大於計算
C：中等批次、可重用局部狀態	狀態重用和快取局部性	固定綁核造成負載不平衡
D：高度不均勻事件（長尾工作）	分工、讓出與遷移	某些核心長時間飢餓
E：稀疏圖／候選路由	多主自治與依賴追蹤	頻繁跨核訊息膨脹
F：完全獨立且高度平行的密集批次	與成熟 worker pool 比較	多一層契約只會變慢
G：週期性取消、故障與核心撤離	lease、fence、replay 安全性	重放副作用或恢復失敗

先以小、中、大資料量逐級測量，不因某個單一配置在一台電腦上較快，就斷言其對所有核心數都有等比例延伸性。

14.6 指標與證據記錄

效能指標： completed valid events/s、完整 wall time、P50/P95/P99、佇列等待、每事件 CPU time、context-switch、CPU migration、每核繁忙與閒置、cache misses、LLC 相關計數（若平台支援）、記憶體峰值、耗能與溫度。

正確性指標： 非法寫入嘗試數、有效雙寫入是否出現、事件遺失／重送、版本衝突、恢復後狀態差異、無效狀態轉移次數、未授權效果數。

遷移指標： 平均及尾端 rebind 時間、snapshot bytes、熱快取恢復成本、fencing 失敗數、遷移後錯誤數。

實驗上下文： CPU／主機板、BIOS、OS、scheduler、GPU（若參與）、RAM、工具鏈、程式碼 revision、輸入 hash、環境熱條件、功耗設定、超執行緒配置、硬體計數器是否可用與 trace 擾動。

14.7 用來推翻假說的明確條件

在相同總資源、正確性與實驗時窗下，PWN 不如成熟常駐 worker 模型，且差異可重現。
高頻跨核消息造成快取抖動，明顯降低有效完成量。
綁核收益僅存在於特殊 synthetic benchmark，對真正多階段 AI 工作負載不成立。
在 P/E 核上局部最優 placement 反而提高全域尾延遲。
SMT sibling 同時承載重工作流導致競爭，收益小於預估。
喚醒／休眠成本大於重建短期任務的成本。
承載切換時發生雙重寫入、遺失狀態或提交順序不可解釋。
所謂「效能提升」只是移除了其他對照組已有的優化，而非 PWN 新契約的貢獻。

上述任何一項都應留在正式報告中，而不是以修改「主節點」定義消除反例。

15. 最小 Runtime 原型模組與工程先後順序

15.1 最低模組構成

smpdc-runtime/
  topology/          # physical core/LP/cache/NUMA/CPU-set discovery
  flow_identity/     # stable IDs, generations, typed state identity
  flow_state/        # owned state, snapshots and version cursor
  lifecycle/         # typed transitions and guards
  lease/             # execution lease, fence validation and recovery
  scheduler/         # placement policy, yielding and bounded work slices
  mailbox/           # minimal typed messages + bounded queues
  instrumentation/   # trace, measured CPU, queue / core migration
  simulator/         # deterministic V0 event runtime
  benchmark/         # baseline adapters, manifests, input fixtures

此目錄是規劃性的模組邊界，不是宣稱已有 GitHub 專案或已完成程式碼。未來若由本地端 AI 實作，需先以獨立分支測試，再決定是否整合到既有 GCM 或 GCCFT Runtime；不能未經驗證就覆寫已封存的既有研究實作。

15.2 不需要第一天就造新 CPU 或新語言

第一個可實作版本可以使用：

正確、可測的 OS thread／worker pool。
簡單的 bounded mailbox 與明確訊息型別。
標準 mutex 或經驗證的 atomic 操作。
版本化狀態與有限 lease。
CPU topology 探測、OS affinity API 及執行時位置觀測。
決定性事件模擬器與可重播 trace。

待 V0 契約驗證和 V1 性能資料存在，才針對真正瓶頸引入 lock-free 優化、動態 topology、GPU 大批次操作或新程式語言原語。

15.3 Windows／Linux 原型注意事項

Windows CPU Sets 與 CPU 群組可用於表達執行緒候選 CPU、查詢核心／快取／效率類別資訊；需按實際 OS 版本與 API 回傳驗證。Linux 可使用 per-thread affinity、可用 CPU 集合及核心拓撲資訊，並注意 cgroup 限制 [E2–E4]。

Windows 與 Linux 的原型應保留相同 PWN 語義，同時以不同 adapter 處理 API 差異；不能把某 OS 的排程效果直接歸因為 SMPDC 理論的普遍性。

15.4 關鍵品質閘門

每次宣稱「完成一個 MVP」，至少附上：

原始碼版本與可重現建置方式。
契約不變量對應的單元／屬性測試列表。
狀態機故障注入結果及可重播 seed。
測試機硬體與可用核心拓撲快照。
使用的 baseline、完整負面案例與測量統計。
未處理的 race、效能退化、功能限制與外部效果邊界。

未取得這些證據以前，本論文的結論仍屬 L0–L1，而不是已實驗驗證的系統。

16. 完整示意案例：四個主工作流與一次安全遷移

16.1 初始工作流

建立四個工作流，僅作語義示例，非實測結果：

$F_A$ ：持續接收新事件，負責輸入版本及合法性。
$F_B$ ：持續維護局部候選關係索引，負責自己的 state slice。
$F_C$ ：執行批次聚合候選的 CPU 控制流程；將來可請求 GPU executor，但本篇先不用 GPU。
$F_D$ ：保存局部驗證進度及將候選送往指定權威域的狀態。

所有工作流都是各自責任領域的「主」工作流； $F_D$ 不因涉及驗證就自動掌握其他三者的全部私有狀態。

16.2 假想事件追蹤

T00 FLOW_CREATE F_A/F_B/F_C/F_D
T01 BIND F_A -> logical CPU 0, lease generation 11
T02 BIND F_B -> logical CPU 1, lease generation 15
T03 BIND F_C -> logical CPU 2, lease generation  8
T04 BIND F_D -> logical CPU 3, lease generation  5
T05 F_A receives input epoch 7 state_version 21
T06 F_A validates and emits versioned candidate to F_B
T07 F_B updates owned local relation state (version 34 -> 35)
T08 F_C receives a legal candidate batch and processes locally
T09 F_D receives evidence, records candidate-not-committed
T10 OS availability changes: logical CPU 1 becomes unsuitable
T11 F_B enters Quiescent; old lease generation 15 is fenced
T12 F_B checkpoint state version 35 with dependency cursor
T13 New worker obtains F_B lease generation 16 on logical CPU 4
T14 F_B resumes same flow_id with state version 35
T15 Late writer with generation 15 is rejected
T16 F_D submits separately validated candidate to authority
T17 idle F_A/F_C enter Blocked; all flows retain logical identity

這份 trace 刻意沒有說 T01–T04 對應四顆不同實體核心：若其中兩個 logical CPU 是同一實體核心的 SMT siblings，仍須由拓撲資料另行標記。

16.3 失敗案例：沒有 fencing 的換核

Old worker on CPU-1 starts writing flow F_B version 35
New worker is started on CPU-4 and restores F_B version 35
Old worker finishes stale write after new worker writes version 36

若沒有共享仲裁與舊 token 拒絕規則，新執行者可能遭舊資料覆蓋。兩個 worker 都聲稱自己是在執行同一條主要工作流，不構成安全性證明。 這是命題 A 的前提為何必要。

16.4 反面場景：何時根本不應遷移

若 $F_B$ 有大量留在某快取域內的熱資料，且現有核心暫時只是小幅繁忙，而換核要付出高額快取重新暖機成本，那麼維持目前承載、讓 $F_B$ 短暫等待，可能比遷移更快。SMPDC 不能把「更多動態」當作效能目標本身。

17. 往後續論文的嚴格交接

17.1 給 Paper 02：相位耦合與持續擴散動力學

Paper 02 必須把本篇的 PrimaryFlowNode Contract v0.1 作為節點先決條件，至少使用：flow_id、logical_epoch、dependency_view、resource_budget、authority_scope、inbox/outbox、current_state、binding_lease 與 trace。

Paper 02 可以增加 PHASE_SIGNAL、COUPLE 和 DIFFUSE 的精確語義，但不得允許沒有授權、沒有傳播預算，或在遷移期間具有失效 lease 的工作流任意發出具有權威效果的訊息。

17.2 給 Paper 03：冗餘資訊流與聚合

本篇不規定一條訊息是否要複製兩份。Paper 03 應決定 single、duplicate、corroborate 和 coded 的形式合約，以及來源相關性、資料完整性、合併與驗證；並保證冗餘路徑不會自動產生新的提交權限。

17.3 給 Paper 04：權威提交與可回滾運算

本篇的 lease 只保證指定局部受控狀態的條件性寫入互斥；Paper 04 必須進一步處理多權威域、不可逆 I/O、跨節點提交、重放引起的外部副作用，以及故障恢復時的正確提交順序。

17.4 給 Paper 05–08：指令、語言、Runtime 與 GPU

後續語言可以把 FLOW_OPEN、FLOW_PERSIST、QUIESCE、PHASE_SIGNAL 等轉為型別安全的抽象指令；但編譯器必須尊重本篇的身份／lease／fence／局部寫入權。GPU 若作為 executor 參與，也須滿足自己的資料搬移與可觀測完成條件；不可以直接被視為 CPU 核心的一部分。

18. 結論

SMPDC 的「多主」不意味系統有很多無限制的中央處理器，而意味各個持續性工作流都可保有局部主要責任、穩定身分、控制權限與可追蹤的進度。硬體核心在這套模型裡，是可用來承載與執行工作流的有限物理資源，而非不可變的抽象身分。

本文完成了 Paper 00 要求的核心交付：PrimaryFlowNode Contract v0.1、工作流／worker／邏輯 CPU／實體核心的身分分離、必要生命週期及守衛條件、CPU 拓撲與異質性的分類、lease／fencing 遷移方案、兩項有前提的安全命題，以及可使用一般消費級 CPU 驗證的 V0–V1 研究計畫。

必須保留的最大限制是：以上只建立可實作並可被反駁的語義與契約，不證明任何特定 CPU 一定會加速，也不宣稱 SMPDC 已經是全新晶片架構。 真正是否比工作竊取、分片服務與 OS 既有異質排程更有效率，必須由後續實驗決定。

Paper 01 的最終研究主張： 對每一個本地主要工作流建立獨立但受控的生命週期、狀態所有權及可變實體承載，是將「群星式 CPU 計算」由比喻推向可靠執行協議的必要形式步驟；其效能價值仍需對照成熟多核心 Runtime 進行實測。

附錄 A｜PWN 最低相容性測試清單

測試 ID	輸入／故障注入	預期契約結果
PWN-C01	相同 flow 多次喚醒	`flow_id` 穩定
PWN-C02	worker 被 OS 搬移	不改變 flow 身分
PWN-C03	只剩一顆可用實體核心	仍可分時運行多個 flow，且不謊稱物理並行
PWN-C04	SMT siblings 同時使用	報告共享物理核心、共享資源
PWN-C05	空的 eligible CPU set	`Active` 受到拒絕或降級
PWN-C06	狀態版本倒退	拒絕無明示回滾權限的寫入
PWN-C07	過期 lease 寫入	由共同仲裁拒絕
PWN-C08	重複訊息到達	按類型交由合法 dedup/reconcile；不自動二次提交
PWN-C09	非法 transition	保留有效狀態並記錄失敗
PWN-C10	佇列高水位	背壓／明示降級，不無限膨脹
PWN-C11	CPU 不可用	進入暫停／復原／失敗，不偽造完成
PWN-C12	snapshot 遺失必要依賴	不能宣稱完全確定性重播
PWN-C13	AI 要求超配額資源	拒絕或只產生未獲准提案
PWN-C14	工作流長期無輸入	可休眠；不強制使用 100% CPU
PWN-C15	反覆遷移	揭露遷移次數及快取成本
PWN-C16	資源公平性違反	trace 顯示飢餓，測試應失敗或標記已知限制

附錄 B｜研究術語與責任對照

名稱	本系列正式意義	不能混同之處
PWN	具有本地主要責任的持續性邏輯工作流節點	不等於單顆實體核心
Worker	執行工作流片段的 Runtime 進程／執行緒承載者	不等於 `flow_id`
Logical CPU / PU	OS／硬體可排程的邏輯處理器單元	SMT sibling 不等於另一顆實體核心
Physical core	實際核心與其執行資源	不等於獨立 NUMA 節點
Primary	對局部工作流具有主要責任	不等於最高權威／最高優先級
Persistent	跨事件維持工作流身分與狀態	不等於忙等或無限耗能
Local authority	對指定局部資料與行為的授權	不等於全域提交
Placement	實體資源配置決策	不等於相位關係本身
Lease	執行者暫時取得的寫入／執行許可	不是靠本地時鐘即有互斥保證
Fencing token	排除舊執行者寫入的單調版本憑據	必須由寫入端核查才有效
Quiescent	定義過的安全暫停及邊界穩定狀態	不等於整個 OS 停止運行
Replay	在契約下重建模型狀態	不保證實體排程與外部副作用完全重現

附錄 C｜提交前的原始稿與驗證規則

Canonical 文件為本 UTF-8 Markdown。聊天顯示僅供閱讀，不作為正式原稿。
公式只能使用 $...$ 與 $$...$$ 作為 LaTeX delimiter；不得轉成 Unicode 數學字形再回存，不做 unicode_escape 往返。
形式安全命題須保留完整假設、證明概要和不適用情境；不能擅自提升為全面的效能或可靠性定理。
所有程式碼／目錄結構均為候選設計，未聲稱已編譯、已測試或已推送到 GitHub。
本篇如有修訂，不得破壞 Paper 00 的核心不變量；若要變更，應記錄跨篇相容性及理由。
後續實作需提供機器環境、版本、完整測試、失敗紀錄、對照組及可重播腳本。

參考文獻與原稿來源

內部原稿

[I0] Neo.K × Aletheia，〈SMPDC Paper 00｜群星多主節點持續擴散計算論：形式總綱〉，2026-10-16，v0.1。本系列前置 canonical UTF-8 Markdown。
[I1] Neo.K，〈群星架構在計算機系統中的應用與改良計畫〉，EveMissLab 早期稿。
[I2] Neo.K，〈群星模型：基於宇宙星系概念的 AI 模型設計方法論〉。
[I3] Neo.K × GPT，〈相位計算機理論 v0.1〉，2026-07-25。無界智庫公開版。
[I4] EveMissLab，〈GCCFT Paper 06｜從 Scheduler 到 Coupled Computation Planner〉。
[I5] EveMissLab，〈GCCWT Paper 04｜計算場與資源激發〉。無界智庫公開版。

外部文獻與技術文件（2026-10-16 檢查）

[E1] Intel，What Is Intel Thread Director?。https://www.intel.com/content/www/us/en/support/articles/000097053/processors/intel-core-processors.html
[E2] Microsoft，SYSTEM_CPU_SET_INFORMATION。https://learn.microsoft.com/zh-tw/windows/win32/api/winnt/ns-winnt-system_cpu_set_information
[E3] Linux man-pages，sched_setaffinity(2)。https://man7.org/linux/man-pages/man2/sched_setaffinity.2.html
[E4] Microsoft，SetThreadSelectedCpuSets。https://learn.microsoft.com/en-us/windows/win32/api/processthreadsapi/nf-processthreadsapi-setthreadselectedcpusets
[E5] DPDK Project，Poll Mode Driver，DPDK 26.07 Documentation。https://static.dpdk.org/doc/guides/prog_guide/ethdev/ethdev.html
[E6] Linux Kernel Documentation，CPU hotplug in the Kernel。https://www.kernel.org/doc/html/latest/core-api/cpu_hotplug.html
[E7] cppreference，std::memory_order（C++ 原子記憶體順序）。https://en.cppreference.com/w/cpp/atomic/memory_order
[E8] Linux Kernel Documentation，Capacity Aware Scheduling。https://docs.kernel.org/scheduler/sched-capacity.html
[E9] Linux Kernel Documentation，Energy Aware Scheduling。https://docs.kernel.org/scheduler/sched-energy.html
[E10] Chase, D., & Lev, Y. (2005). Dynamic Circular Work-Stealing Deque. SPAA 2005, 21–28. DOI: https://doi.org/10.1145/1073970.1073974
[E11] Seastar Project，seastar::sharded<Service> Class Template Reference。https://docs.seastar.io/master/classseastar_1_1sharded.html
[E12] NVIDIA，CUDA Programming Guide: CUDA Graphs；供後續 GPU baseline 使用。https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/cuda-graphs.html

證據與原創性聲明

本篇引用的外部資料是說明現有成熟機制及為對照組提供依據；它們未證明 SMPDC 的新型契約必然帶來性能增益。雲端原稿是 Neo.K 既有研究脈絡，不等同於公開同行評審成果。本文新增的 PrimaryFlowNode Contract v0.1 與限定性命題屬候選研究貢獻，必須經實作、形式驗證、消融及與成熟系統的公平比較，方能逐步建立其可重現的技術價值。

SMPDC Paper 01｜多主工作流節點論：CPU 核心自治、持續執行、承載映射與安全遷移