title

SMPDC Paper 10｜AI 訓練與推論適用域：稀疏路由、持續工作流、訓練一致性、Time-to-Quality 與異質效率邊界

english_title

Domains of Validity for AI Training and Inference in SMPDC: Sparse Routing, Persistent Workflows, Training Consistency, Time-to-Quality, and Heterogeneous Efficiency Boundaries

series

SMPDC — Stellar Multi-Primary Persistent Diffusive Computing

paper

10 / 11

version

0.1

date

2026-10-17

language

zh-TW

status

Full Research Manuscript — AI Workload and Quality Contracts, Conditional Propositions and Falsifiable Experiments; Model and Hardware 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–09 v0.1

artifact_scope

AI training/inference validity matrix, typed workload and convergence contracts, sparse/dense/agent/verifier use cases, model-state consistency, baseline/ablation protocol, hardware budget, mock contract test, and Paper 11 handoff

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

——稀疏路由、持續工作流、訓練一致性、Time-to-Quality 與異質效率邊界

English: Domains of Validity for AI Training and Inference in SMPDC: Sparse Routing, Persistent Workflows, Training Consistency, Time-to-Quality, and Heterogeneous Efficiency Boundaries
系列： 群星多主節點持續擴散計算論（SMPDC）
主構想提出： Neo.K
研究協作： Aletheia／GPT-6
機構： EveMissLab／一言諾科技有限公司
版本／日期： v0.1／2026-10-17
研究成熟度： L1——工作負載形式化、具型別接口、條件命題、反例、對照與驗證規劃；沒有完成 SMPDC 原生訓練器、大型模型訓練加速、一般化速度證明或 AI 品質提升的實測。
前篇依賴： SMPDC Paper 00–09 [I0–I9]；尤其 Paper 03（R0–R3）、04（正式提交）、06（PDAIS-IR）、07（控制平面）、08（GPU 可見性）、09（HLC09 實體成本）。

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

摘要

SMPDC 的中觀—宏觀構想讓多個 CPU 核心得以成為自治主要工作流的實體承載候選，工作流在相位約束下進行有界資訊擴散、冗餘傳播與局部合併；適合 GPU 的批次關係運算可以交由裝置並行處理，但 CPU/GPU 之間仍受記憶體、實體互連與同步下界限制。前九篇已分別提出工作流身分與租約、擴散 credit、R0–R3 冗餘、權威提交、抽象指令、程式語言、OS／AI 控制平面、GPU 執行證據及硬體局部性模型。這些組件能使一套執行系統在形式上可描述、可編譯、可驗證，卻不能直接推出 AI 模型會訓練得更快、更準，或推論得更好。

本文提出 AIWorkloadValidity Contract v0.1（AWV10）：把 SMPDC 對人工智慧的適用性變成具備可反駁條件的工作負載分類與實驗問題。至少研究四種不可混同的負載：高吞吐 dense tensor、稀疏 Mixture-of-Experts（MoE）路由、長壽推論／多 Agent 工作流，以及具有版本化持續狀態的候選驗證流程；另分析序列模型 prefill／decode、資料平行／參數分片訓練、管線平行與混合精度／重計算。每類均建立 model/data/optimizer/seed/precision/shape/context/quality/hardware lineage、不同計算階段的可見性與提交契約、延遲和記憶體配額、完整成本模型及對照組。

本篇提出三個不能合併的效能判準。**訓練：**相同品質目標下的 time-to-quality，並加計編譯、暖機、評估、儲存、恢復、失敗與能源成本；**推論：**相同模型版本、品質契約及服務負載下的吞吐、TTFT／TPOT、p95／p99 延遲及 RAM/VRAM；**持續 Agent／驗證：**合法完成任務的成功率、驗證義務、已提交成果及 end-to-end goodput。單純 tokens/sec、steps/sec、GPU 使用率或單個算子 kernel 時間，均不足以證明 AI 系統得到整體改善。

本篇維持 Paper 03–04 的嚴格分層：冗餘候選不是獨立真值、暫態結果不是已提交狀態、一次 GPU kernel 結束不是完成跨裝置可見性。針對訓練另新增 optimizer step 版本化、梯度血緣、參數一致性、管線權重版本、隨機種子重現及可觀察模型品質的約束。本文提出九項有明確前提的命題、32 條最低安全與測量不變量、36 個故障／反例、可執行的契約級微型檢查器以及 V0–V2 反證路線。文獻對照涵蓋 Switch Transformer、Tutel、ZeRO／FSDP、GPipe／PipeDream、vLLM、SGLang、DistServe、NCCL、CUDA Graphs 和 MLPerf。它們皆屬成熟先例，SMPDC 的增量若存在，應由整體可驗證執行契約與同等品質下的測量證明，而非語彙重新命名。

關鍵詞： SMPDC、異質運算、稀疏專家路由、MoE、長壽工作流、模型品質、time-to-quality、梯度一致性、權重版本、持續推論、TTFT、TPOT、GPU 記憶體、可驗證控制、CPU–GPU、可證偽系統研究。

1. 研究問題與論文性質

1.1 一個刻意不把假說當成結論的起點

研究起點不是「模仿大腦，AI 必然較快」，也不是「核心越多，訓練越強」。問題是：在某些工作負載中，獨立持續主工作流、相位調度、選擇性冗餘、批次化 GPU 關係計算及權威提交的聯合規則，能否在相同正確性與品質條件下，勝過成熟的專用軟體執行架構？

設工作負載 $w$ 、基線 $b$ 與候選 SMPDC 配置 $s$，品質契約 $Q$，資源上限 $R$。研究的是：

式子是要透過實驗查驗的存在性問題，不是本篇已證明的存在定理。若在指定工作負載與平台上無法滿足，應記錄為負面結果；不允許事後無限制擴張「適用域」逃避反證。

1.2 本篇六個核心問題

1. **RQ10-A：**哪些 AI 工作負載具有持久、相位相關且局部可自治的 CPU 工作流，而非單次大量 GPU kernel？
2. **RQ10-B：**在 dense tensor、MoE、推論服務、多 Agent／驗證工作中，何處的動態耦合可節省 critical path，何處只增加 dispatch、copy 和同步？
3. **RQ10-C：**兩路／多路候選資訊能否降低特定 tail latency，同時遵守梯度血緣、唯一生效、隨機性與跨裝置可見性？
4. **RQ10-D：**訓練的收益能否由達到同一模型品質目標所需時間證明，而不是由每秒 step 數冒充？
5. **RQ10-E：**當 RAM、VRAM、功率與 CPU/GPU 帶寬受限時，哪些負載可在消費級硬體上得到淨效益？
6. **RQ10-F：**如何以充分強的既有系統作對照、消融新增機制並建立明確 FAIL／INCONCLUSIVE 例？

1.3 本篇不宣稱的事

• 不宣稱 SMPDC 自己發明 MoE、批次路由、資料平行、事件驅動執行、GPU collectives、動態 batching、KV cache paging、可撤銷推測、混合精度、回滾或 AI 自主排程。
• 不宣稱目前 RTX 3070 已完成本研究中的 AI 訓練驗證。
• 不宣稱降低 step 延遲必然改善收斂；也不宣稱提高 CPU 利用率就是提高 AI 生產力。
• 不把 GPU 當成實體 CPU 核心互連的替代物；也不以雙路複製自動形成獨立證據。
• 不假設每種 AI 都適合 persistent diffusion；無收益、無相位資訊增量或無法證明安全時，必須允許 phase-blind／no-diffusion／no-redundancy 基線。
• 不把模擬器 PASS、Mock 演示與真實權重訓練收斂混淆。

2. 從 Paper 00–09 承接的不可變語義

2.1 九元系統與載體投影

沿用 Paper 00 九元中觀形式：

此處的工作流節點是邏輯主節點／Primary Workflow Node（PWN），不能直接與實體 core、SM、thread、expert、attention head 或 agent 同義化。Paper 09 的硬體投影／觀測層只提供可驗證載體資訊；它不要求九元本體自身就是晶片拓撲。

在 AI 工作負載中，映射關係需要先聲明粒度。可選為 microbatch dispatcher、expert-routing owner、cache-owner、verification worker、model-serving session manager、optimizer step authority，但不應預設每個 Transformer token 或每個權重都對應一顆 CPU 核心。

2.2 必須保留的八個交接契約

這些是候選契約名稱，不表示已部署的 Runtime API。具體 ABI 的最終 canonical 版本由後續實作與測試報告決定。

2.3 三種權威不能被混為一談

• **資料權威：**誰可讀、修改、持有某份資料、梯度、KV 或權重版本。
• **執行權威：**誰可把工作片段發送到實體 CPU/GPU；OS 和設備驅動保留實體資源控制。
• **結果權威：**哪個 commit domain 可以接受一次 optimizer update、一次使用者回覆或一次外部效果。

模型路由器若能選擇 expert，不意味它能寫入 optimizer；CPU 工作流若擁有某個 session，不意味它能看見尚在 GPU stream 上寫入的 tensor；AI planner 產生分配建議，不意味它可直接改寫 commit record。

3. AIWorkloadValidity Contract v0.1：形式核心

3.1 有型別的 AI 工作負載

定義：

其中 $F$ 是工作負載族； $D$ 是可檢核資料來源； $M$ 是模型與權重版本； $O$ 是 optimizer 或 decoding／search method； $P$ 是精度、隨機性和數值政策； $L$ 是執行／血緣； $B$ 是 batch、microbatch、context、concurrency； $Q$ 是品質與交付義務； $H$ 是硬體及資源配額； $A$ 是權限、風險和外部效果。

所有欄位不得簡化成單一 task_id，否則無法辨識「同一組輸入但不同權重」或「同一模型但不同 RNG stream」的工作結果。

3.2 工作負載族分類

AIWorkloadFamilyV0_1 =
    DenseTensorTraining
  | SparseMoETraining
  | SmallModelFineTuning
  | DenseAutoregressiveInference
  | SparseMoEInference
  | PersistentAgentWorkflow
  | VerifierCoupledCandidateSearch
  | TrainingServingCoupledLoop

前四類以模型 tensor 與生成為主；後四類包含持續狀態、依賴、驗證、權限或服務目標。分類可多標籤，但評估時必須指定主族與子族，不得事後移動門檻。

3.3 完整研究輸入格式

AIWorkloadManifestV0_1 {
  run_id, experiment_id, protocol_version
  task_family, model_architecture, model_revision, weights_digest
  tokenizer_revision?, dataset_id, dataset_digest, data_split_digest
  preprocessing_digest, data_order_digest, data_license_scope
  optimizer_name?, optimizer_config_digest?, scheduler_digest?
  initial_optimizer_state_digest?, initial_rng_state_digest?
  precision_policy, determinism_policy, numerical_tolerances
  batch_size, microbatch_size, context_length, input_shape_distribution
  expert_count?, top_k?, expert_capacity_policy?, router_version?
  arrival_process?, concurrency?, session_duration?, timeout_policy?
  quality_metric, quality_direction, quality_target, eval_protocol_digest
  metric_aggregation, confidence_rule, heldout_data_digest
  machine_manifest_ref, hardware_cost_profile_ref
  ram_budget_bytes, vram_budget_bytes, energy_measurement_policy
  baseline_id, candidate_policy_id, code_revision, build_digest
  operator_permissions, commit_authority_scope, external_effect_policy
  telemetry_schema_version, status, notes
}

未適用欄位可以明示 NotApplicable，不能默默缺失。資料是受權限約束的，不因為進入 AIWorkloadManifest 就取得外部揭露許可；原始私有資料可儲存在受控倉，公開實驗至少提供可審核的雜湊與脫敏 manifest。

3.4 模型狀態與任務結果必須分離

ModelStateIdentityV0_1 {
  architecture_digest
  parameter_version
  weights_digest
  optimizer_state_version?
  optimizer_state_digest?
  precision_policy_digest
  rng_lineage_digest
  training_step_commit_id?
}

在訓練過程中，同一模型架構的不同版本不能當成可交換的「等價」候選；如果 R1 複製用於非確定性生成或蒙地卡羅路由，必須標記抽樣語義、seed 血緣以及結果比較政策。

3.5 最小接受與拒絕決策

WorkloadAdmissionV0_1 =
    Admit(phase_plan, placement_plan, budget_lease, quality_guard)
  | CpuOnly(policy_ref)
  | GpuOnly(policy_ref)
  | PhaseBlind(reason)
  | Reject(reason, violated_guard)
  | Defer(reason, retry_condition)

CpuOnly、GpuOnly、PhaseBlind 不是「失敗」，而是理論允許選擇傳統方案的必要結果。若系統不允許這些結果，它只能自我證成，不能稱為可反證的計算架構。

4. 「更快」的三套不可互換度量

4.1 訓練目標：Time-to-Quality

設評估量 $q(\theta_t)$，預先定義方向、門檻 $q_\star$ 和資格判定 $\mathcal V$：

若實驗時窗內未達品質，結果必須標為 RightCensored／FailedToConverge（依預註冊規則），而不是設法用每秒 steps 或把無收斂結果寫成零耗時。模型達標時間至少計入有效負載的初始化、資料處理、GPU/CPU 執行、同步、必要評估與錯誤恢復。若報告另外給出穩態訓練時間，兩者需分開命名。

處理不同架構的品質差異時，可指定多個可比門檻 $q_{\star,1}, q_{\star,2}$，不得因候選端未達高門檻就只展示低門檻。MLPerf Training 是「達到指定品質」的成熟 benchmark 制度，屬對照與方法學先例 [E1]。

4.2 推論目標：有品質條件的有效交付率

令 $\mathcal C$ 為合格完成並通過品質與服務義務的請求集合。定義：

這是 goodput 而不是純總吞吐；需要一起報告 TTFT（time-to-first-token）、TPOT（time-per-output-token）、p50／p95／p99 latency、tokens/s、SLO 違約率、品質通過率，以及 GPU/CPU/RAM/VRAM 的配額。對串流推論須分開定義首 token、後續 token 與整段回覆的完成時間。

requested_tokens、generated_tokens、accepted_tokens、quality_accepted_tokens 應各自保留；否則某個候選可能藉由短回覆、拒答率升高或少算 KV cache 提升表面吞吐。

4.3 Agent 與驗證目標：合法完成而非只產生候選

長壽 Agent 或 verifier pipeline 的進度包括：產生候選、工具呼叫、局部驗證、全域合法提交和外部效果完成。模型可大量產生尚未通過檢驗的「計算進度」，但任務完成率仍然為零。

正式報告必須另外列出驗證失敗、回滾、重試、重複外部效果、錯誤狀態可見性與任務品質；有效完成率不得拿總候選數替代。

4.4 不同分母不可任意選一個

5. AI 的執行相位：語義、版本與因果偏序

5.1 相位不是物理振盪的強制等價物

依 PCMT 與 GCCFT，SMPDC 中 phase 首先是工作流依賴、可執行資格、資源可見性或驗證／提交狀態；除非專門研究振盪器，否則不得把它等同電路時脈、神經振盪或任何物理量。

建議區分以下 task-relevant AI 相位：

AIPhaseV0_1 =
    DataReady | InputTransferReady | ForwardReady | BackwardReady
  | GradientReducible | OptimizerCandidate | OptimizerCommitReady
  | ModelWeightsPublished | PrefillReady | DecodeReady
  | ExpertDispatchReady | ExpertMergeReady | VerifyReady
  | LocallyReconciled | AuthoritativelyCommitted | RetireReady

同一節點可能同時持有多個相位軸，不必所有節點處於相同「時刻」。例如負載 A 正在 backward，負載 B 同時 prefill，並不表示它們在同一相位。

5.2 計算相位與權重版本的組合

相位相容性必須至少依賴：

VersionOK 是不可選項：若 forward 用 $\theta^{(k)}$，其 backward 在要求同版梯度的訓練制度下，就不能偷用 $\theta^{(k+2)}$ 而當作相同梯度證據；若允許 bounded staleness，必須獨立列入訓練策略和品質驗證，而不是由 Runtime 默許。[E6]

5.3 GPU 事件不是 CPU 可見性的無條件證明

ForwardGpuDone 只表示對特定 device graph 或 stream 路徑而言的完成條件；若 CPU 需要讀取裝置結果，仍要符合 Paper 08 DeviceVisibilityWitnessV0_1。一個未完成必要 H2D/D2H copy、stream/event 依賴、buffer lease 或 OS 可見性檢查的 tensor，不能被標示為 HostReadable。

5.4 最小執行偏序示例

BatchDataSealed
  -> H2DVisible
  -> ForwardDone(weights=v7)
  -> BackwardDone(weights=v7)
  -> GradientTypedAndReduced(step=52)
  -> OptimizerPrepared(base_model=v7)
  -> CommitAuthorityAccept(step=52)
  -> ModelWeightsPublished(v8)

若相位圖中 ForwardDone、BackwardDone 的 weights_version 不符，則不能靠提高 CPU 核心數或 GPU 並行數去補救；必須拒絕或進入獨立設計的非同步學習制度。

6. 高吞吐 Dense Tensor：最容易失去 SMPDC 收益的場域

6.1 應承認 GPU 的既有最佳化強項

大規模 dense GEMM、attention、convolution、MLP 等算子通常能從 CUDA／cuBLAS／cuDNN／PyTorch 的成熟並行 kernel 取得高吞吐。對固定 shape、長時間重複的運算，CUDA Graphs 可以攤銷 CPU launch overhead [E12]。SMPDC 如要把每個 token 或每個 tile 都回傳 CPU 主節點進行相位呼叫，可能把原本可連續執行的 GPU 路徑切碎。

合理候選不是「CPU 做更多矩陣計算」，而是僅把較高階、存在分支或依賴不規則的決策留在長壽 CPU workflow：例如資料準備、動態 expert admission、稀疏 batch 排程、驗證候選和多請求隔離。

6.2 Dense 最低對照組

• B0：成熟 GPU eager execution，包含框架預設正當最佳化。
• B1：相同 model／precision 的 torch.compile 或支援的 compiler baseline。
• B2：CUDA Graphs（在 shape／memory 可適用時）。
• B3：合適的 fusion、batching 或原生 library kernel。
• E0：SMPDC 控制器僅管理外圍流程，不介入 dense kernel 的內部執行。
• E1：SMPDC 控制器加上相位擴散、冗餘與跨核調度。

若 E1 慢於 B3，或 E0 與 B3 基本相同，應報告 SMPDC 在該 dense workload 上沒有附加價值。對於只在大量 CPU host overhead 的小 kernel 工作負載取得的結果，也不可推廣到 GPU-bound 大模型。

6.3 Dense 的潛在正向例外

若模型輸入長度高度變動、需要多份候選驗證、資料準備可被分散，或 kernel-launch overhead 無法由 Graphs 完整消除，可測試 SMPDC 是否對 peripheral orchestration 產生收益。但報告需顯示端到端 critical path 真正縮短，而不只是其他執行緒變忙。

6.4 Roofline 與傳輸限制（描述性下界）

對 $F$ 次運算與搬運 $D$ bytes，理想化計算／頻寬下界：

此式忽略 cache、啟動、同步、內容競爭等，僅為必要而不充分的硬體限制。任何「擴散後繞過傳輸」的主張若與此下界不相容，必須回頭檢查是否減少了 $D$ 、改變表示或實際重新利用 cache，而不是認定物理規律失效。

7. Sparse MoE：具有較清晰實驗切入點的工作負載

7.1 MoE 並不是 SMPDC 的原創概念

Switch Transformer 已研究稀疏 expert 啟動的可訓練性與 routing 平衡 [E3]；Tutel 已研究動態路由造成的負載不均和自適應 expert parallelism [E4]。因此「模型不同 token 選擇不同 expert」與「動態任務路由」不能用作 SMPDC 的獨創性證據。

SMPDC 在此的候選增量，必須更窄：由多個 CPU 主工作流在持續 session、GPU admission、跨迴圈 model version 和有界冗餘的統一契約下，減少某類 routing／驗證／記憶體局部性開銷，並在強基線比較下產生淨效果。

7.2 Routing 的最小形式

設 token $x_i$ 和 expert $e_j$，router 計算 score：

TopK 的排序、相同 score 的 tie-break、capacity overflow、訓練 dropout 和路由權重版本，都必須被定義。若不同 policy 改了可選 expert 或丟 token 規則，則比較的是模型演算法與訓練制度，不僅是 Runtime。

7.3 MoE 執行分層

RouteCandidate
  -> CapacityAdmitted
  -> ExpertTokensGrouped
  -> ExpertGpuBatchPlanned
  -> ExpertKernelSubmitted
  -> ExpertResultVisible
  -> ExpertMergeLocallyVerified
  -> TrainingGradientReady / InferenceTokenCandidate
  -> AuthorizedResult

ExpertTokensGrouped 可以被 GPU scatter/gather、現成 dispatch library 或 CPU 驅動的 batcher 實作；SMPDC 不預設 CPU 每個 token 逐一處理。如果成熟 GPU routing kernel 已足夠快，CPU 介入可能完全沒有意義。

7.4 MoE 有界擴散的真正入口

對多個 request、expert group 或分散資料佇列，PWN 可以持有長壽 batch_window、capacity_lease、weights_version 和 deadline，相位到達時開啟受 credit、記憶體預算和 GPU admittance 限制的消息擴散。消息目的主要是提交下一個合法 GPU batch 或驗證結果，而不是把 dense expert matmul 切成數千次 CPU 呼叫。

7.5 稀疏 routing 的數值／品質一致性

如果候選 runtime 與 baseline 的選中 expert 集合相同、token 權重相同、丟棄規則相同、數值公差內相符，較能歸因於執行系統差異。若候選改成不同 expert 選擇或 capacity 機制，則須明確啟動「演算法變更」組，並以 end-to-end time-to-quality／等品質推論衡量；不得宣稱這是零語義變更的排程提升。

7.6 Load balance 與通信變數

設 expert $j$ 處理量 $n_j$。路由不均可用 dispersion 或 max-load ratio 描述，但最終瓶頸依賴算子時間、AllToAll traffic、記憶體局部性與 GPU occupancy。對多 GPU MoE，應比較 Tutel、框架 expert parallel、NCCL／其他 collective；對單 GPU，明確標記 multi_gpu_expert_parallel=NotApplicable，不得拿模擬網路速度冒充實機結果。

8. 訓練資料平行、FSDP、ZeRO 與模型狀態一致性

8.1 舊方法已解決的重要問題

ZeRO 的核心是減少 optimizer/gradient/parameter 等複製狀態的記憶體冗餘 [E5]。PyTorch FSDP2 以參數分片、all-gather、reduce-scatter 等手段管理大型模型記憶體及通訊 [E8]。NCCL 有成熟的 reduce／all-reduce／all-gather 等 collective 實作 [E11]。

SMPDC 若在這些系統之外增加冗餘資料流，不能因此推論總訓練記憶體下降；兩者甚至可能衝突。R1/R2 所需額外 Buffer、CPU cache 和 PCIe 搬運，必須從 HLC09 明確計價。

8.2 訓練的一次 optimizer step 是複合轉換

對已確認參數 $\theta_k$ 、optimizer state $o_k$ 、學習率政策 $\eta_k$ 與有效梯度 $g_k$，抽象 step：

$g_k$ 必須是對正確樣本集合、有效權重版本與約定 reduce 規則所得的梯度。若因 R1 重送而把同一 sample／microbatch 的梯度累加兩次，已改變最佳化路徑；若兩個 worker 都提交同一 optimizer step，則是重複更新，不能以「雙路加速」合理化。

8.3 梯度血緣類型

GradientLineageV0_1 {
  run_id, training_epoch, global_step, microbatch_id
  sample_ids_digest, sample_weight_digest
  model_version_forward, model_version_backward
  router_version?, expert_assignment_digest?
  loss_scale_version, precision_policy_digest
  reduction_group_id, reduction_members_digest
  rng_lineage_digest, gradient_digest
  device_visibility_witness_ref, provenance_ref
}

gradient_digest 不能單獨證明其正確：若兩路都使用同一錯誤權重版本，雜湊一致也不代表梯度合法。若訓練採受控 nondeterministic kernel，精確 digest 等價要求可能不適用；必須依數值容差、統計品質與故障模型分開測試。

8.4 提交點設於權威訓練狀態，而非每個 tensor

單 GPU、無多程序情況下，成熟訓練循環可以提供足夠正確性；不強求每一步都通過重型分散式交易。若需要持久化恢復、跨進程重播或多路合併，才應建立版本與權威提交，並明確測量成本。

ModelWeightsPublished(v+1) 必須依賴合法的 optimizer step 與必要的 device completion／visibility witness；checkpoint 的 durable guarantee 另由儲存與 recovery layer 定義，不應因權重已留在 VRAM 就宣稱抗 crash。

8.5 不同梯度策略必須分組比較

• 等演算法：相同資料順序、有效 batch、optimizer／schedule、loss scale、數值政策，變動僅限執行調度。
• 非同步演算法：允許梯度 stale、local SGD 或延遲合併，另建策略與品質對照。
• 不同分片制度：FSDP／ZeRO 等依 GPU 和模型適用性比較。

若候選透過增大 global batch 才提高 samples/sec，其收斂與最佳化制度已改變；必須報告 time-to-quality 才能比較。

9. 版本化管線平行與梯度陳舊性

9.1 前向與反向需要一致的權重語義

GPipe 利用 microbatch 將大網絡切為管線 stage [E7]；PipeDream 研究混合批次並行與參數版本管理 [E6]。它們已經處理了 pipeline bubble、weight stashing 與訓練效率的核心問題。SMPDC 不應重新命名這些策略。

對某 microbatch $m$ 、stage $j$，若策略規定 forward/backward 使用同版 $v_{m,j}$，則：

若放寬此條件，必須明確標成新訓練算法及其收斂風險，不能默默歸在執行佇列最佳化。

9.2 計算進度不等於數學等價

有些 pipeline 策略允許新 microbatch 使用較新權重、舊 microbatch 在較舊權重做 backward；即使每個 microbatch 自身的 weight stashing 正確，與完全同步 SGD 仍可能不是同一更新序列。因此必須雙層核對：局部前後向可計算正確性與全域訓練策略的統計品質。

9.3 SMPDC 可能測試的附加價值

如果同一系統同時處理資料前處理、CPU 驗證、GPU stage queue、動態 shape 和多模型 serving，長壽主工作流可能降低建立/拆除 worker、跨任務排程和狀態初始化的成本。這是外圍 Runtime 潛在收益，不是替代成熟 1F1B scheduler 的憑空聲明。

9.4 對照最低要求

一旦研究擴展到多 GPU，基線必須包含支援環境下的成熟 pipeline/tensor/data parallel 組合，並記錄內部不確定性、失敗重試、權重版本、失效率和 time-to-quality。只在一張 GPU 的 V1 實驗不得聲稱已驗證跨機管線收斂。

10. 混合精度、RNG 與數值穩定性

10.1 快速與準確不是一條單調軸

AMP、FP16、BF16、TF32、quantization、activation checkpointing 和 fused optimizer 會改變時間、記憶體及數值誤差。其可用性由 GPU 能力與框架決定，不得把不同 precision 下的更快推論直接當成 SMPDC 架構提升。

同一 benchmark 需至少保留：模型權重格式、運算格式、梯度累加格式、loss scaling／overflow 規則、結果比較 tolerance、硬體支援。若實體不支援某格式，標記 UNAVAILABLE，不要用軟體模擬結果假裝有原生硬體加速。

10.2 隨機性是執行語義的一部分

一次 dropout／sampling 的 seed、stream、counter 和工作流分配關係會決定輸出。把候選計算從核心 A 遷至核心 B，不應默默重用同一 RNG counter 或使同一 microbatch 被不同數量地抽樣。可用 counter-based RNG 及唯一 lineage 實作，但選用何種庫不是本文已確定的規範。

必要條件之一：

此式表示候選設計原則，不要求一定採 hash 實作；若框架與 kernel 的 RNG 演算法本身因排程不同產生不同結果，則應改採統計等價測試並明確宣告，不能聲稱逐 bit 重現。

10.3 決定性和統計等價需要分開的 PASS

四者互不自動包含。在 GPU 上浮點 reduce 可能受順序改變影響，採 deterministic 路徑通常存在實際效能成本，必須計入比較。

11. LLM 推論：Prefill、Decode、KV 與批次耦合

11.1 兩個工作階段不能被當成同一耗時來源

Prefill 通常處理輸入 prompt 的大量 token 計算；decode 通常以自回歸方式依賴先前結果，服務壓力和 latency 特徵不同。DistServe 研究分離 prefill 與 decode 以及 TTFT／TPOT 的資源配置取捨 [E10]；SMPDC 若只是把兩者排到不同 GPU，並無獨立新意。

單一 RTX 3070 實驗不等於實體分離兩台 GPU；可以分離邏輯排程與 phase buffer，卻不能宣稱完成 DistServe 式多 GPU disaggregation。

11.2 vLLM 和 SGLang 是不可忽視的成熟基線

vLLM 透過 PagedAttention 管理動態成長的 KV cache [E9]；SGLang 透過 RadixAttention、structured generation／runtime 最佳化等支援複雜 LLM 程式 [E16]。因此，不得將「KV cache 重用」、「持續 session」或「GPU 排程同時服務多個請求」列為 SMPDC 的獨立發明。

SMPDC 的可能切入點是更高一層的 CPU PWN 對請求、驗證分支、工具呼叫和 GPU admission 的持續管理，且不破壞現有框架自己的高效服務核心。

11.3 多請求 session 與 phase guard

SessionCreated
  -> InputReady
  -> PrefillQueued
  -> KVLeaseBound
  -> PrefillGpuDone
  -> DecodeEligible
  -> DecodeTokenCandidate
  -> QualityOrPolicyValidated
  -> TokenStreamPublished
  -> SessionRetired

Streaming 的部分 token 可能早於整段結果提交給使用者；這屬明確的 partial-result contract，若要求強一致的完整答覆，應採不同發布政策。已對外送出的 token 並非簡單可回滾，必須在外部效果模型中標明。

11.4 KV 是版本化資源，不是免費流通的資訊

每個 KV block 的內容與 model weights、token prefix、位置編碼、注意力布局、精度及 tokenizer 有關。只有在 prefix identity、可見性與生命週期相容時才能共用；跨模型或跨不同 tokenizer 復用 KV，不能僅因「語義近似」就認定安全。

KvLeaseIdentityV0_1 {
  model_state_ref, tokenizer_digest, prefix_tokens_digest
  kv_layout_revision, attention_policy_digest
  precision_policy_digest, device_id, buffer_lease_ref
  extent_bytes, refcount_owner, lifetime_generation
  host_device_visibility_ref?, eviction_policy
}

GPU BufferLease／HostReadable 應承接 Paper 08；記憶體位置和搬運下界應承接 Paper 09。SMPDC 不得另宣稱只靠新語言即可消除 KV cache 與 PCIe 成本。

11.5 TTFT／TPOT 的多目標 tradeoff

推論服務最好以四象限比較：相同品質下的低負載延遲、繁忙延遲、整體吞吐及 VRAM 峰值。微批次較大可能增加 tokens/sec，同時損害某些互動請求的 TTFT／尾延遲；SMPDC 控制器如採 dynamic batching，必須在 SLO 與 fairness 約束內決策。

12. 持續 Agent 與工具使用工作流

12.1 這裡的「主節點」更貼近邏輯常駐工作流

一個 Agent session 可能維持目標、子工作、觀測、工具狀態、模型版本和恢復點。它可能大量等待 I/O、工具回覆或外部服務，而非佔滿 CPU 核心。PWN 可以持續保留邏輯身分與責任，但不應為 idle agent 專佔實體 CPU core；實體 placement 應交回 OS 控制器。

12.2 多 Agent 並行不得繞過授權

若子 Agent A、B 並行撰寫計畫，兩者結果不等於可合併的最終真值。必須根據文件版本／權限／外部效果，經過 LocalReconciliationOutcomeV0_1 和 Paper 04 commit policy 處理。對聊天或資料整理類任務，品質 contract 可能是結構驗證／人工覆核或形式檢查；不能把模型自述的信心分數當作獨立證據。

12.3 Persistent flow 的成本與收益

長壽 workflow 可攤銷初始化成本，減少重建狀態，但也可能增加 RAM 常駐、cache 競爭、排程／回收成本。對很短的工具任務，普通 async runtime 通常更簡單；SMPDC 必須證明自己的額外契約在特定情況下值得支付。

12.4 有效成果的最低分類

AgentOutcomeV0_1 =
    CandidateOnly
  | LocallyChecked(checker_ref)
  | AwaitingAuthority(commit_key)
  | AuthorizedCommitted(commit_index)
  | ExternalEffectObserved(effect_receipt)
  | Rejected(reason)
  | UnknownExternalState(query_handle)

只有最後幾種具備必要提交證據的狀態，才能依任務 contract 計入 authorized_completed。推測多路生成的候選數必須單列，不得當作成功任務數。

13. Verifier-Coupled Branches：最可能受益於 R1／R2 的區域

13.1 兩種不同的「多路」

第一種是同演算法競速：同一校驗任務送往兩條不同資源路徑，先到的合法結果先被採納。這是 Paper 03 R1，目的偏向尾延遲；如果故障來源高度相關，未必能降低 p99。

第二種是異算法或異權威佐證：同一候選透過符號檢查、測試執行、規則驗證或第二模型各自產生證據。這是 R2，主要增加可觀察差異與可驗證性；即便兩方同意，也不自動成為形式證明。若有真正能判定正確性的 verifier，該 verifier 的權威與完整性必須單獨聲明。

13.2 R3 不能被拿來「憑近似語義重建真值」

編碼冗餘必須有明確碼本、碼參數、有效 share 與解碼假設；對模型回覆只拆成兩份相似文字，再合併並不構成容錯碼。語義相似度、embedding 距離與模糊比對可以提供 comparator 訊號，但不能取代嚴格的 error correction guarantee。

13.3 以有效完成率與信任域衡量

Verifier workflow 的效益可能來自提早啟動獨立檢查、平行候選探索或將慢分支從 critical path 移開。其成本包括計算副本、RAM/VRAM、驗證本身、錯誤仲裁和副作用隔離。必須比較單路最佳 verifier、成熟平行 pipeline 及 SMPDC 的完整成本。

13.4 早發布與可回滾性的限制

對已展示給使用者的答案、已發出付款或已更新外部資料庫的結果，簡單的內部回滾不會撤銷現實世界後果。Paper 04 external effects policy 是硬性約束；具重要副作用的 agent pipeline 不得因「最快候選先到」就跳過外部效果防護。

14. 從相位擴散到 AI Workload Admission

14.1 邊界成本進入決策

設候選 $s$ 的總端到端成本：

不同成本維度的單位並不相同：wall-clock 與 device busy time 不能無條件相加，bytes、peak memory、joules 和 event counts 更不能直接相加。若研究政策需要單一分數，必須先預先宣告單位、正規化、硬性約束與權重，再形成可解釋的有量綱／無量綱目標。端到端時間以 trace 的 critical path 及實際 wall-clock 計量為準；其他維度用於發現瓶頸與資源外部性。

14.2 工作片段進入 GPU 的必要判準

只有當 HLC09 的 hardware profile 足夠新、GPU buffer lease 可被保障、kernel／copy 因果可驗證、批次大小足夠且未違反 quality guard 時，才建議 offload。對小型、不規則或 GPU 佇列擁塞片段，CPU SIMD／單核心／thread pool 可能更快；不應因架構名稱內含「異質」就強迫使用 GPU。

14.3 Admission 建議決策流程

function admit_ai_slice(slice, model, quality, hardware):
    if not lineage_and_permissions_valid(slice): REJECT
    if not version_and_phase_guard_valid(slice): REJECT
    candidates = [cpu_serial, cpu_parallel, gpu_library]
    if persistent_flow_applicable: candidates += [smpdc_cpu]
    if heterogeneous_candidate_eligible: candidates += [smpdc_gpu]
    candidates = filter_by_memory_energy_latency_quality(candidates)
    if candidates is empty: DEFER_OR_REJECT
    return choose_measured_candidate_with_safe_fallback(candidates)

此演算法是候選策略綱領，不是已建好的排程器。對 uncertain／out-of-profile cost 必須拒絕過度自信，或者執行保守基線。

14.4 AI planner 僅能提出建議

AI 可建議 batch window、分配 core、調整 redundancy 模式、是否融合 GPU kernel 或改變 cache 預取，但不得改變資料授權、模型品質門檻、optimizer commit 或安全規則。Paper 07 既有可回退、受約束的決策制度繼續有效。

15. 兩條不可偷換的研究路線：Equivalent Runtime 與 Algorithm-changing Runtime

15.1 E 路線：保持演算法與品質契約

對等價執行研究，要求固定模型與資料版本、loss、optimizer、有效 global batch、輸出形狀、模型初態／RNG 政策、容差與品質評估程序。允許變更 thread placement、batch grouping 的實作、GPU launch 方式、合法 cache layout 和工作流排程；但必須證明或測量其對數值結果的影響在預註冊政策內。

EQUIVALENT_RUNTIME:
  model_algorithm = fixed
  dataset_and_evaluation = fixed
  optimizer_and_global_batch = fixed
  precision = fixed or pre-approved equivalent
  runtime_placement = variable
  scheduling = variable within declared semantic constraints
  randomization = lineage-preserving
  quality = must pass the same target

這一路線最能隔離 SMPDC 作為計算執行架構的效果，而不受更換模型、優化器或推論演算法的干擾。

15.2 A 路線：允許改變訓練／推論演算法

例如採用不同 speculative decoding、路由策略、optimizer staleness、gradient compression 或 learning rate schedule。此時應宣告是「架構＋演算法」聯合實驗，而非等價 executor。公平比較應以品質門檻、有效預算與多 seed 統計處理，必要時設定品質—速度 Pareto frontier，而不是直接把不同 loss、不同模型規模或不同精度當成同一組。

15.3 類型保護

ExperimentSemanticsV0_1 =
    EquivalentExecution(semantic_fingerprint, tolerance_contract)
  | AlgorithmVariant(change_log, independent_quality_guard)
  | ExploratoryPilot(no_performance_claim)

最終統計報告必須按這三種型別分開呈現；不得把探索性 pilot 的最好一次跑分混入 confirmatory experiment。

15.4 模型品質與機器正確性分開計分

兩個模型可能在 benchmark 準確率相當，但存在不同的輸出和錯誤分布；這並不表示逐 token／逐張量等價。反過來，某些浮點實作不同的 kernel 可能在公差內得到等效輸出。報告需明示自己檢驗的是 bitwise、numerical、statistical 還是 application-level equivalence。

16. 多目標成本與 AI 適用性相圖（候選）

16.1 最低狀態向量

令工作負載狀態：

其中 $I$ 為 CPU orchestration intensity， $M$ 為記憶體壓力， $D$ 為主機／裝置資料搬移， $C$ 為動態耦合密度， $V$ 為驗證義務， $S$ 為狀態持續性， $A$ 為到達率／負載波動， $Q$ 為品質政策的嚴格程度。

這些維度尚無跨平台通用尺度。每個維度都需要定義可重現的測量估計器，不能用主觀 1–10 分數推出效能。

16.2 研究型態的初步分組

表中的高低代表首先做實驗的可行性／信息量，不代表推測加速效果的大小。

16.3 何時「沒有相位」才是正確答案

如果 phase-aware controller 相較同等狀態的 phase-blind controller，對 tail latency、吞吐與品質沒有可辨別的增量，就應消去 phase bookkeeping。用無效的多維相位座標裝飾普通非同步執行，無助於宣稱新範式。

16.4 何時擴散必須停止

所有 AI 工作流可以長壽存在，但每個 event_epoch 的擴散需要受 credit、截止時間、背壓與資源預算約束。完成既定訓練 microbatch、推論請求或驗證分支後，局部 credit 必須回收／退休；不能從 agent session 常駐推論「事件永不需要偵測終止」。

17. 九項條件性命題與證明／反證邊界（AWV10-P1～P9）

下列命題是依明確系統模型給出的條件性正確性或成本判準。除非標明形式證明完成，以下均是 paper-level proof sketch，不構成經獨立形式驗證的定理。硬體／AI 性能須由量測佐證。

17.1 AWV10-P1：血緣完整條件下的重送去重

前提： 每個梯度有唯一 (run,step,microbatch,lineage,gradient_kind) 身分；收件方以原子記錄判斷第一次採納；持久化記錄不會在合法重播期限內遺失。

命題： 相同邏輯梯度的重送 attempts 不會使該梯度在同一 reducer aggregation 中被計入多次。

理由概要： 所有 attempts 映射到同一邏輯鍵，接收者對該鍵只執行一次原子 Admit；其他 attempts 都返回既存決定。若鍵過粗（不同梯度同鍵），會漏算；若鍵過細（同一梯度重試生成新鍵），會重複累加。命題不保證梯度數值本身正確。

17.2 AWV10-P2：合法 optimizer step 的單一權威更新

前提： optimizer step 的提交鍵、model base version 和 optimizer state version 可被原子仲裁；重試使用同鍵查詢／冪等提交；過期 lease 被 fencing。

命題： 在同一訓練狀態域，兩份不同傳送 attempts 不會使同一合法 step 被持久化生效兩次。

理由概要： Paper 04 的提交域將相同 key 映射至唯一決定；不同 key 仍可能競爭 base version，必須受到版本與衝突規則限制。若跨獨立訓練系統或外部副作用，則不在此命題涵蓋範圍。

17.3 AWV10-P3：有同版保證的管線局部梯度一致性

前提： stage $j$ 的每個 microbatch 在 forward 與 backward 使用所需一致的權重版本，且 activation 保存或重算政策合法。

命題： 由「不同權重版本混用」造成的該 stage 局部梯度不一致可被排除。

理由概要： 版本檢查在 gradient admission 前執行，不符則拒絕；其餘數值誤差、非決定性 kernel、數學模型本身不當或全域訓練策略的陳舊性，仍須另行檢驗。

17.4 AWV10-P4：GPU visible-before-read 的局部安全性

前提： device event／copy ordering 正確；HostReadable witness 與 BufferLease 仍有效；必要同步在 CPU consume 前完成。

命題： CPU 上層聚合不會在上述模型下合法讀取尚未宣告可見的 GPU candidate。

理由概要： 讀取需要有效 witness；若 witness 不存在或已過期則無法完成型別化的 Consume。這不是對所有硬體故障提供防護的命題，取決於 Runtime／driver 提供正確事件證據。

17.5 AWV10-P5：R1 競速對特定完成時間的條件性上界

前提： 兩條候選路徑各自能產生可接受結果，允許第一個合格結果決定，且 cancellation 不造成不合法副作用；兩路額外成本已計入。

若兩條可接受路徑完成時間為 $T_1,T_2$，則無額外仲裁／提交延遲的理想化候選時間：

限制： 實際系統另有啟動、複製、競爭、驗證及取消開銷，總完成時間不必小於單路；而且兩路相同結果不等於雙重獨立正確性證明。此命題僅指出理想化選優的數學事實。

17.6 AWV10-P6：固定訓練演算法下的等品質端到端加速判準

前提： 訓練語義、精度、資料集、品質判準與實驗資源一致，候選及基線均達標，並以相同起訖計時。

命題： 只有當多次獨立重跑的 time-to-quality 的預註冊統計比較滿足既定優勢門檻，才能宣稱候選在該訓練工作負載的端到端速度上取得可信收益。

理由概要： step/sec 既不能保證同等收斂，也不保證相同初始化/評估/恢復成本；品質達標時間直接觀察研究目標。若某組大量不收斂，須按 censoring 規則報告，不能當成已完成數值比較。

17.7 AWV10-P7：超額 VRAM 不可被語義契約消除

前提： 已定量的 peak live tensor/KV/workspace/buffer lease，且沒有經合法釋放、壓縮、分片或換入換出的行為。

命題： 若同一時刻所需實體 live memory 超過可用 VRAM，單靠新增相位標籤、消息協議或 CPU 主工作流，不能使該 GPU 配置合法執行。

理由概要： Runtime 需選擇降低 live range、microbatch、重算、offload、shard、精度或直接拒絕。任何成功執行都表示實體配置實際改變，不能宣稱「免費容量」。

17.8 AWV10-P8：R2 相關錯誤不能自動因雙路變獨立

前提： 兩份驗證結果共享資料、模型、檢查器或其他可能的故障來源。

命題： 從 agree(A,B) 無法單獨推出 correct(A)；兩者相關時尤然。

反例： 兩個驗證器複製了同一錯誤規則，即使輸出相同，也都可能錯。此命題是對錯誤推論的禁止條件，而非對 verifier 效能的保證。

17.9 AWV10-P9：選擇性退回成熟基線的安全邊界

前提： 系統保存已驗證的 CPU／GPU fallback 路徑，切換過程尊重 model state/version、buffer lease、提交與 OS 資源權限；不會回收仍被使用的 state。

命題： 當 SMPDC policy 被停用或遭 watchdog 禁用時，可以在界定的工作邊界安全轉移到 fallback，而不必把尚未完成的候選誤發佈為已提交結果。

限制： 不保證切換即時、無性能損失或任何不一致狀態都可被無痛恢復；失敗的外部 side effect 仍受 Paper 04 限制。

18. AWV10 三十二條最低不變量（C10-01～C10-32）

所有不變量都應進入 V0 參考執行器的 schema validator、有限狀態測試或 V1 的 telemetry assertions。每項都是候選契約要求，而非已驗證的硬體事實。

18.1 契約依賴的具體優先級

C10-07～C10-10 是訓練正確性的 critical guard；C10-19～C10-20 是 CPU/GPU device memory 的 critical guard；C10-05～C10-06、C10-24、C10-29～C10-32 是研究誠信 guard。任何 critical guard 失敗，即使實驗數值看似較快，也不得標 PASS。

18.2 Trace 中需要的守衛證據

每次拒絕必須留下 run_id、event_epoch、model_version、拒絕原因、責任域和可查回的證據 reference；不得僅寫「GPU error」或「not optimal」。若涉及使用者資料，trace 應保護原文或秘密，只保存有合法揭露權的摘要及必要識別碼。

19. 三十六項故障、反例與觀察義務（F10-01～F10-36）

這些情境刻意包含概念相似卻本質不同的失敗，以便測試架構是否能維持層級邊界。預期處置是候選合約，不是宣稱原型已全部通過。

19.1 故障注入優先級

V0 必須首先覆蓋 F10-06、09、10、11、13、20、21、25、30、31、33、36；V1 在實體設備上優先觀察 F10-18、19、23、24、27、32、34、35。其他情境可依 task family 給出 NotApplicable，但必須明示原因。

19.2 Crash／Retry／Unknown 的三態必要性

分散式或具外部效果的系統收到 timeout 時，並不能直接推論沒有成功；必須支援 UnknownDecision(query_handle)，先查詢持久結果或已授權效果，再決定是否同鍵重試。AI pipeline 若只靠模型推斷「應該失敗了」，就可能造成不可逆的重複寫入或付款。

20. V0：不依賴昂貴 GPU 的確定性模擬與契約檢查

20.1 目標

V0 不求證明 SMPDC 性能優勢，而是檢驗型別、狀態、版本、成本計算及研究規格是否自洽。可先使用單一 host 程式、虛擬 CPU PWN、模擬 GPU ticket、模擬 VRAM lease、人工生成到達過程與可重演 fault injection。

20.2 六個子實驗

V0-06 可以用人工指定的到達時間，驗證純事件規則；其時間數值不是 GPU 真實 latency。完整的參考事件 trace 必須包含每次採納／拒絕的原子狀態與 epoch，供 Paper 11 重播。

20.3 V0 PASS 不等於 GPU PASS

若 Mock 中 GPU_DONE 是手動注入狀態，只能證明狀態機拒絕非法轉移；無法證明 CUDA event 或實際 device buffer 可見性正確。若 Mock 模擬了 sample 資料，也不能證明真實模型達到品質門檻。

21. V1：既有消費級桌機的真實實驗

21.1 已知但不臆測的現有硬體

截至本研究規劃，現有桌機由舊款 AMD CPU、32 GB RAM 與 NVIDIA GeForce RTX 3070 組成。NVIDIA 參考規格列 RTX 3070 標準配置為 8 GB GDDR6 [E13]，但實際 VRAM、OS、CUDA、驅動、GPU 功耗及是否被其他程式占用，一律由本地工具探測並寫入 manifest。沒有購買的 Ryzen 9950X3D、Intel 270K Plus 或 N5 Pro 不當作測試設備。

在此硬體條件下，不應以大型 70B 模型全參數訓練作為 V1 預設。建議使用能在實際可用 VRAM 內完成且可重演的中小型模型，必要時採低階模型／LoRA／梯度累加作研究對照；仍須固定完整公平性參數。

21.2 W10-A：Dense 前後向固定工作

選定小型可訓練 Transformer 或 MLP，固定 token/sample、batch、precision、optimizer、seed 和資料集，對照 eager、適用的 torch.compile／CUDA Graphs、以及 SMPDC 僅外圍 orchestration 方案。測量 compile/warm-up/forward/backward/optimizer、peak VRAM、CPU utilization、wall-clock 至品質門檻；不只比單一 kernel。

21.3 W10-B：動態 MoE Routing 微型模型

建議一個小型可訓練 top-k expert 模型（例如 4／8 個 expert，需符合實際 VRAM），比較 token grouping、batch preparation、expert dispatch、不同到達分布的效果。先確保 GPU／PyTorch 的合格基線，再引入 PWN pool、phase guard、bounded batching；只研究相同 routing 演算法的執行差異。若要比較不同 top-k/capacity，另列 AlgorithmVariant。

21.4 W10-C：LLM 推論服務（若資源允許）

採同一具明確版號的小模型，對照成熟可在 8GB 及該平台實際執行的 serving／推論框架。若 vLLM／SGLang 在現有 Windows、WSL、CUDA 或 VRAM 上不支援，則標 UNAVAILABLE，改採明確的 CPU 或 PyTorch/HF 最佳可行基線，不能寫「擊敗 vLLM」。

Workload 至少含短請求、長上下文、混合到達與多 Session；採固定 tokenizer、輸出長度／停止條件、品質評估、warm-up。分開量 TTFT、TPOT、tokens/s、p99、VRAM 和品質通過。

21.5 W10-D：持續 Agent／Verifier pipeline

在隔離 sandbox 中實作 deterministic tool／verifier mock 或真實但非破壞性的任務。比較 async thread pool、bounded queue，以及 SMPDC phase+R1/R2+commit。測量合法任務完成數、tail latency、回滾、重試、驗證錯誤與 RAM；完全不需要真實付款或外部不可逆服務。

21.6 W10-E：GPU 資料搬運對照

選取需頻繁 gather／scatter 的中小張量，量 H2D/D2H、pinned/pageable RAM、batch 聚合、GPU launch 與 host consume。與 Paper 08 GPU collaboration 和 Paper 09 HLC09 同一份 manifest 比較，避免「MoE 的收益其實是少做了一次不必要的 memcpy」卻錯誤歸功於擴散模型。

21.7 V1 不做的推論

單 GPU V1 不會驗證 NCCL AllToAll 在多 GPU 的擴充性；單 OS 的測試不會證明跨 Windows／Linux 效能普遍性；未達品質門檻的極短訓練不會證明 time-to-quality；Mock fault test 通過不會代表 production fault tolerance。

22. V2：可選的跨架構／多設備擴充

V2 不是本篇完成條件。當 V1 已有可重現的端到端收益或否定結果，且平台採購確實合理時，再加入不同 CPU core topology、不同 GPU、單機多 GPU、真正 NCCL collectives、不同 VRAM 及高速互連。需要預註冊跨平台測試才可聲稱 architecture portability。

當比較 Intel P/E 與 AMD chiplet／3D V-Cache，實際要用的是探測到的物理 topology、共享快取範圍、頻寬、溫度與排程特性；不准只以品牌名稱當代理變數。CPU 核心數及 SMT 執行緒數亦不得混用，承接 Paper 09 的硬體識別制度。

多 GPU 訓練時可加入 NCCL、FSDP2、expert parallel、pipeline parallel 的最佳成熟基線。新增網卡、NVLink、PCIe 規格與功耗仍會改變可行域，不可以在同一結果圖中當作相同硬體預算。

23. 正式基線（B10）與消融（A10）矩陣

23.1 B10-00～B10-12：最小公平基線群

不應要求任何一顆單 GPU 電腦實際執行 B10-08～B10-10，若支援條件不成立可寫 NotApplicable/UNAVAILABLE。但也不能用不可運行的基線數值作為低品質假想對照。每個實驗要指明實際適用的最強基線，不能挑最弱者。

23.2 A10-00～A10-12：消融設計

任何消融若違反前篇不可刪除的安全 guard（例如為了快而移除 device visibility witness），不可列為「性能消融」；只能在故障注入中作拒絕測試。安全不變量不屬可關閉的 optional feature。

23.3 預註冊交互作用

例如 R1 在空閒 GPU 可能降低長尾，在飽和 GPU 會造成負資源外部性；同樣的 routing 操作在 Intel P/E 或同構核心配置上，可能有不同 CPU placement 效果。必須在實驗設計中交叉：負載密度、GPU 壅塞、context 長短、phase 調度是否啟用、memory locality policy，才能辨識表面 speedup 是否其實來自不公平環境。

24. 測量指標、統計與反證規則

24.1 主要與次要終點預先綁定

訓練主終點：time_to_quality，並報告全 seed 的達標／未達標狀態。推論主終點：品質與 SLO 合格前提下的 goodput，輔以 TTFT、TPOT、p99、VRAM。Agent 主終點：合法已提交任務的 end-to-end completion rate；任何未經授權結果不計入。

次要終點包含 system energy、GPU busy%、CPU user/kernel time、context-switch、queue depth、buffer bytes、copy bytes、重試次數、驗證開銷及恢復成本。

24.2 測量公平性

• 同一硬體、同一資料／模型、同一有效 global batch 和輸出品質政策。
• 公開或受控保存 build flags、驅動、CUDA／PyTorch／依賴套件版號、CPU governor、GPU power policy、溫度環境。
• 預熱與初始編譯是否在計時內必須事前定義；不能候選只量穩態、基線卻含下載模型。
• 不同策略的 CPU/GPU 常駐記憶體、pinned host memory、disk cache、先驗預計算均須記錄。
• 混合外部請求到達率採固定 trace replay，避免不同負載造成不公平。
• 每組至少記錄完整獨立 seed／重跑，不因單次最好結果而宣稱顯著。

24.3 訓練未達標：右設限與品質失敗的區別

若預先設定時間預算 $T_{\max}$，run 在截止前未達標，記錄 RightCensored(Tmax, last_q)；若系統因崩潰或非法狀態導致無法訓練，記錄 ExecutionFailure；若反覆出現數值發散，記錄 Diverged。這三者都不能當作「已訓練完成」。若要比較分布，可使用適當的 survival 分析或報告達標率與置信區間，但方法必須在看結果前規劃。

24.4 Speedup 與 Pareto 不能單獨代替品質

對成功達到相同目標的兩配置，可定義：

當其中一者未達標時，不報該組的有限 speedup。對不同硬體預算則以 quality/latency/memory/energy 多維 Pareto front 顯示，不能只用一個相加權重說「全面較好」。

24.5 門檻與實證採納

V1 先採探索性試驗，等成本分解、樣本數規劃與可重演性通過後，在 Paper 11 預註冊 confirmatory threshold（例如指定效果量、誤差界、bootstrap CI 或 paired analysis）；本篇不虛構既有加速比、未測結果或 p-value。對負面結果應保存完整環境與 artifact；若新架構對某負載無收益，就是有效的適用域排除資訊。

25. 研究證據封套與 Trace Schema

25.1 應用到硬體的 trace chain

AIWorkloadManifestV0_1
  -> ExperimentSemanticsV0_1
  -> ModelStateIdentityV0_1
  -> PrimaryFlowNode / PhaseDiffusion epoch
  -> Redundancy R0-R3 / LocalReconciliationOutcome
  -> HeterogeneousWorkSliceV0_1
  -> GpuExecutionTicket / DeviceVisibilityWitness
  -> GradientLineage or InferenceSessionOutcome
  -> SpeculativeCommit Decision
  -> HardwareCostProfile / Energy and Latency Evidence
  -> QualityEvaluationWitness
  -> ExperimentRunVerdict

每層只有在確實使用時才要求其實體 artifact；未使用 GPU 路徑要明示 NotApplicable，不能硬塞假的 GPU witness。

25.2 AIQualityEvaluationWitnessV0_1

AIQualityEvaluationWitnessV0_1 {
  run_id, evaluation_id, evaluator_digest, heldout_data_digest
  model_state_ref, evaluated_step_or_checkpoint
  metric_name, metric_direction, metric_value
  target_value, pass_rule_digest, pass_status
  wallclock_timestamp, elapsed_wallclock
  sample_count, random_seed_or_sampling_policy
  provenance_ref, score_integrity_digest
}

pass_status 應依任務契約計算：例如「越高越好」與「越低越好」不可混用。若 evaluation step 只有訓練內部 loss，卻把它當成 held-out quality，則不允許直接宣稱達標。

25.3 ExperimentRunVerdictV0_1

ExperimentRunVerdictV0_1 {
  run_id, workload_manifest_ref, baseline_id, candidate_id
  semantics_kind, primary_metric, quality_status
  resource_budget_status, safety_invariant_status
  timing_scope, raw_trace_digest, reproducibility_manifest_ref
  verdict: PASS | FAIL | INCONCLUSIVE | UNAVAILABLE
  censoring_reason?, unsupported_capability?, failure_refs[]
  claims_allowed[], claims_prohibited[]
}

PASS 表示達到預先指定的驗證條件，不等於整個 SMPDC 理論被證實或通用優勢成立。FAIL 可以是安全違反、品質不等價、無法達到效果門檻。INCONCLUSIVE 可因樣本不足、系統干擾或缺少完整原始數據而給出，不能為了漂亮報表轉成 PASS。

25.4 Trace 保留的最低原子欄位

至少：timestamp_monotonic、device_clock_domain、event_epoch、run_id、flow_id、flow_generation、model_version、work_slice_id、copy_bytes、gpu_ticket_id、buffer_lease_id、device_event_id、commit_key、quality_evaluation_id、failure_code。跨 CPU 與 GPU clock domain 需要校準或以明確 event causality 建立偏序，不得拼接不同時鐘產生虛假的負 latency。

26. 與公開成熟研究的原創性邊界

26.1 不是「生物腦式拓撲」就足以構成新理論

多節點、神經類比、局部傳遞、異步事件和訊號收斂本身均有長期學術研究。SMPDC 的近硬體中觀研究希望檢驗：多 CPU 主工作流的責任與權威、phase-bounded diffusion、R0–R3 typed redundancy、GPU visibility witness、AI state versioning 以及端到端品質治理，能否整合成獨立可測的執行契約。 目前只能稱為候選架構研究，不能宣稱其組合必然新穎或已取得性能改善。

26.2 競品／前例清單與實際研究差異

26.3 與 EveMissLab 既有系列的準確定位

群星模型 與 群星架構在計算機系統中的應用 提供先前的節點組織靈感；PCMT 提供相位本體和演化分類；GCCFT 提供耦合場和 phase-aware interaction；GCCWT/GCCF/GCM 提供更廣義的異質執行及 global orchestration；ISQL-CMF 可成為將來對照與資料表示候選。Paper 10 不將上述理論硬性合併，也不使 SMPDC 成為所有 AI 架構的不可替代底座。可行性與收益需藉由分離組件的消融來判斷。

26.4 引文不當作實驗證據

成熟系統文獻支持其自身的演算法和公開報告，不是 SMPDC 的效果證明。對 vLLM、Tutel 或 PipeDream 文獻中列出的既有加速比，不能轉寫成 SMPDC 預期加速比；也不得拿不同 GPU 世代或不同模型上的數值作同口徑直接比較。

27. 對 Paper 11 的正式交接、研究判決與結論

27.1 AWV10 交付清單

Paper 10 交付以下候選 contract：

1. AIWorkloadManifestV0_1、AIWorkloadFamilyV0_1 和 WorkloadAdmissionV0_1。
2. ModelStateIdentityV0_1、GradientLineageV0_1、KvLeaseIdentityV0_1。
3. AIQualityEvaluationWitnessV0_1、ExperimentRunVerdictV0_1。
4. ExperimentSemanticsV0_1：分離 EquivalentExecution、AlgorithmVariant 和 ExploratoryPilot。
5. AWV10-P1～P9 條件性命題、C10-01～C10-32 不變量、F10-01～F10-36 反例。
6. B10-00～B10-12、A10-00～A10-12、W10-A～E 及 V0/V1/V2 測試設計。
7. Time-to-Quality、Inference Goodput、TTFT、TPOT、已授權提交的可比品質／效能判準。
8. 能由既有桌機開始的軟體研究路線，禁止虛構新 CPU／伺服器／多 GPU 實測。

27.2 Paper 11 必須補的全系列閉環

Paper 11 應建立從 PrimaryFlowNode 至 AIWorkloadValidity 的跨篇可執行測試與反證結果，統一以下判決：PASS／FAIL／INCONCLUSIVE／UNAVAILABLE。需要列出所有使用中的硬體、真實實驗碼、seed、資料、模型、編譯旗標、測試重跑、儀器不確定性、基線調優與安全不變量；包含對 SMPDC 不利的結果，不得只上傳成功案例。

27.3 三個優先實驗的選擇理由

• 優先 1： 長壽 verifier／多路候選，因為容易以確定性、嚴格版本和有限資源建立正確性測試。
• 優先 2： 中小型 MoE／動態 routing，因為有可獨立觀察的 CPU orchestration、GPU group computation 和 phase admission。
• 優先 3： 單 GPU 上可達品質門檻的微調／小型模型訓練，因為可以真正回答 time-to-quality，但不可用 Toy Mock 假稱模型收斂。

這三者研究優先，並不等於預期效果都正向。若前兩者即已顯示 SMPDC overhead 過大，可能反而應縮減後續硬體開發，而非急於購買更昂貴 CPU。

27.4 本篇研究結論

群星多主節點持續擴散模型在 AI 領域的候選價值，應優先從動態、不規則、持續且存在可驗證工作流責任的部分尋找，而非預設它會超越 GPU 已十分成熟的 dense 大規模矩陣運算。其適用域由相位資訊增量、路由與計算開銷比例、memory/copy/launch 成本、模型品質、故障與提交責任等條件共同決定。

本文最重要的約束是：訓練要以相同品質的達標時間評估，推論要以相同品質與服務義務下的有效吞吐與延遲評估，Agent/Verifier 則必須以合法提交結果衡量；任何純算力占用、GPU kernel 速度或虛擬事件 Mock 都不能跨越這些判準。 SMPDC 的獨立科學價值目前在於提出一套可以容許反例、負結果、退回成熟基線及跨平台重現的研究框架；至於實際效益仍須由 Paper 11 與後續真實原型檢驗。

附錄 A｜兩份可逐步重演的 AI 工作流實例

A.1 正例：同一權重版本的 MoE microbatch + 唯一提交

實驗條件：run=R, epoch=E1, step=52, model=v7, precision=fp32, microbatch=M3, router=v2；此處所有 id 是示範字串，非真實 GPU benchmark。

此例說明各種「完成」都不同：GPU kernel 完成、HostReadable、局部驗證與持久化 optimizer commit 是不同義務。即使每步都被宣告成功，本例仍不證明相同模型在真實資料上會更快收斂，因為沒有任何真實訓練或品質量測。

A.2 反例：看似更快卻無法達到品質門檻

設定兩個具相同模型與資料版本的候選（此為假想資料，非實測）。策略 A 保留原版權重一致性；策略 B 放寬 stale gradient 並允許第二路的相同 microbatch 梯度重複累加。

Illustrative synthetic scenario only:
A: 100 steps/sec, reached validation target after 1200 steps -> 12 s
B: 160 steps/sec, did not reach target by 4000 steps -> right-censored at 25 s

B 的單位時間 step 更多，但不能說它縮短 time-to-quality；B 還違反了同等訓練算法與梯度唯一性條件。正確判決應是 AlgorithmVariant 或 InvalidExecution，而非 S_Q>1。

A.3 正例：Verifier R1 競速但安全提交

一個只讀 proof checker 任務需在硬性 deadline 前回答是否通過。兩條獨立計算路徑 A、B 的輸出先進入 LocalReconciliationOutcome：B 雖先回傳，但證據版本不符，應 Hold；A 較慢但有合法 verifier witness，才可送交權威層。若 A 亦無法合法提交，最終結果應是超時或 INCONCLUSIVE，而非強行從最快結果推斷正確。

A.4 反例：KV prefix「語義相似」但模型版本不同

若 session A 的 KV 使用 model=v7，session B 使用 model=v8，即使 prompt 字面完全相同，cache reuse 仍須拒絕，除非有明確被驗證的 cross-version semantic adapter；一般 PagedAttention 或 copy-on-write 本身不賦予這種跨權重等價性。

附錄 B｜AWV10 微型契約參考程式（Python 3，標準函式庫）

此程式可從本 Markdown 中獨立擷取執行；只測試抽象控制契約，不包含真實 PyTorch model、真實 CUDA、真實模型品質、OS scheduler 或 CPU/GPU 效能。assert 是可重演的 mock 行為驗證，絕不能當成 SMPDC 實體成效證據。

from dataclasses import dataclass

@dataclass(frozen=True)
class Model:
    version: int
    tokenizer: str
    weights_digest: str

@dataclass(frozen=True)
class Gradient:
    run: str
    step: int
    batch: str
    weight_forward: int
    weight_backward: int
    digest: str

@dataclass(frozen=True)
class KvLease:
    model_version: int
    tokenizer: str
    weights_digest: str
    prefix: str
    alive: bool

class GradientReducer:
    def __init__(self):
        self.seen = {}
        self.accepted = []

    def admit(self, g: Gradient):
        if g.weight_forward != g.weight_backward:
            return "REJECT_VERSION"
        key = (g.run, g.step, g.batch)
        if key in self.seen:
            return "DUPLICATE_IGNORED" if self.seen[key] == g.digest else "KEY_CONFLICT"
        self.seen[key] = g.digest
        self.accepted.append(g.digest)
        return "ACCEPTED"

class StepAuthority:
    def __init__(self, initial_version=7):
        self.version = initial_version
        self.records = {}

    def commit(self, key, base_version):
        if key in self.records:
            saved_base, saved_result = self.records[key]
            if saved_base != base_version:
                return ("KEY_CONFLICT", saved_result)
            return ("ALREADY_DECIDED", saved_result)
        if base_version != self.version:
            return ("STALE", self.version)
        self.version += 1
        self.records[key] = (base_version, self.version)
        return ("COMMITTED", self.version)

def kv_reusable(lease: KvLease, model: Model, prefix: str):
    return (lease.alive and lease.model_version == model.version
            and lease.weights_digest == model.weights_digest
            and lease.tokenizer == model.tokenizer and lease.prefix == prefix)

def gpu_cpu_read_allowed(kernel_done, copy_done, witness, lease_alive):
    return bool(kernel_done and copy_done and witness and lease_alive)

def classify_quality(value, target, direction):
    if value is None:
        return "RIGHT_CENSORED"
    if direction == "higher":
        return "PASS" if value >= target else "NOT_YET"
    if direction == "lower":
        return "PASS" if value <= target else "NOT_YET"
    raise ValueError("unsupported quality direction")

def route_mode(mode, same_algorithm, independent_sources, coded_scheme):
    if mode == "R0": return "SINGLE"
    if mode == "R1" and same_algorithm: return "HEDGE"
    if mode == "R2" and independent_sources: return "CORROBORATE"
    if mode == "R3" and coded_scheme: return "DECODE"
    return "REJECT"

def device_admission(bytes_needed, available, kernel_eligible, visible_cost):
    return (bytes_needed <= available and kernel_eligible
            and visible_cost is not None)

def first_acceptable_time(path_a, path_b, overhead):
    return min(path_a, path_b) + overhead

# 1–8: logical gradient identity, collision and weight-version guards.
red = GradientReducer()
g1 = Gradient("R", 52, "M3", 7, 7, "hash1")
g1_retry = Gradient("R", 52, "M3", 7, 7, "hash1")
g1_collision = Gradient("R", 52, "M3", 7, 7, "different_hash")
g2 = Gradient("R", 52, "M4", 7, 7, "hash2")
g_bad = Gradient("R", 52, "M5", 7, 9, "hash_bad")
assert red.admit(g1) == "ACCEPTED"
assert red.admit(g1_retry) == "DUPLICATE_IGNORED"
assert red.admit(g1_collision) == "KEY_CONFLICT"
assert red.admit(g2) == "ACCEPTED"
assert red.admit(g_bad) == "REJECT_VERSION"
assert len(red.accepted) == 2
assert red.accepted == ["hash1", "hash2"]
assert len(red.seen) == 2

# 9–14: optimizer step may not be duplicated or key-collided.
auth = StepAuthority()
assert auth.commit(("R", 52), 7) == ("COMMITTED", 8)
assert auth.commit(("R", 52), 7) == ("ALREADY_DECIDED", 8)
assert auth.commit(("R", 52), 6) == ("KEY_CONFLICT", 8)
assert auth.commit(("R", 53), 7) == ("STALE", 8)
assert auth.commit(("R", 53), 8) == ("COMMITTED", 9)
assert auth.version == 9

# 15–20: cache identity and ownership.
m7 = Model(7, "tok-v1", "w7")
m8 = Model(8, "tok-v1", "w8")
lease = KvLease(7, "tok-v1", "w7", "abcd", True)
assert kv_reusable(lease, m7, "abcd")
assert not kv_reusable(lease, m8, "abcd")
assert not kv_reusable(lease, m7, "other")
assert not kv_reusable(KvLease(7, "tok-v1", "w7", "abcd", False), m7, "abcd")
assert not kv_reusable(lease, Model(7, "tok-v2", "w7"), "abcd")
assert not kv_reusable(lease, Model(7, "tok-v1", "different_weights"), "abcd")

# 21–25: device completion is not automatically host visibility.
assert gpu_cpu_read_allowed(True, True, True, True)
assert not gpu_cpu_read_allowed(True, False, True, True)
assert not gpu_cpu_read_allowed(True, True, False, True)
assert not gpu_cpu_read_allowed(False, True, True, True)
assert not gpu_cpu_read_allowed(True, True, True, False)

# 26–31: quality evidence and comparison direction.
assert classify_quality(0.91, 0.9, "higher") == "PASS"
assert classify_quality(0.89, 0.9, "higher") == "NOT_YET"
assert classify_quality(0.11, 0.12, "lower") == "PASS"
assert classify_quality(0.13, 0.12, "lower") == "NOT_YET"
assert classify_quality(None, 0.90, "higher") == "RIGHT_CENSORED"
try:
    classify_quality(1.0, 0.9, "sideways")
    raise AssertionError("invalid direction was accepted")
except ValueError:
    pass

# 32–38: R0–R3 are different information protocols.
assert route_mode("R0", False, False, False) == "SINGLE"
assert route_mode("R1", True, False, False) == "HEDGE"
assert route_mode("R1", False, False, False) == "REJECT"
assert route_mode("R2", False, True, False) == "CORROBORATE"
assert route_mode("R2", False, False, False) == "REJECT"
assert route_mode("R3", False, False, True) == "DECODE"
assert route_mode("R3", False, False, False) == "REJECT"

# 39–43: hardware cost and hedge overhead counterexamples.
assert device_admission(100, 200, True, 0.01)
assert not device_admission(300, 200, True, 0.01)
assert not device_admission(100, 200, False, 0.01)
assert not device_admission(100, 200, True, None)
assert first_acceptable_time(10.0, 8.0, 5.0) > 10.0  # R1 can lose after overhead

print("AWV10 mock contract checks: 43/43 PASS (logical-only; no GPU or AI benchmark)")

這份微型 checker 的作用是把特定安全規則轉為可執行的反例保護。它仍故意省略真實 gradient tensor equality、完整 GPU event identity、跨 process crash durability、正式 ML eval、worker 式樣與統計檢定；因此 43/43 PASS 只代表上述 **43 條 Python 檢查（42 個 assert 與 1 個預期例外）**通過，不代表論文 32 條不變量已全部被模型檢查或 GPU 硬體驗證。

附錄 C｜可解析的實驗 Manifest（JSON 範例）

此 JSON 是文件內的介面示意資料，各個 digest 使用 placeholder，不可當作已存在的實體資料或實際訓練紀錄。實驗系統必須另以 schema 驗證型別、digest 範圍及合法欄位。

{
  "schema": "AIWorkloadManifestV0_1",
  "run_id": "example-moe-run-001",
  "experiment_id": "AWV10-V0-moe",
  "protocol_version": "0.1",
  "task_family": "SparseMoETraining",
  "model_architecture": "synthetic-toy-moe",
  "model_revision": "example-r1",
  "weights_digest": "PLACEHOLDER_SHA256",
  "tokenizer_revision": "NotApplicable",
  "dataset_id": "synthetic-data",
  "dataset_digest": "PLACEHOLDER_DATASET_DIGEST",
  "data_split_digest": "PLACEHOLDER_SPLIT_DIGEST",
  "preprocessing_digest": "PLACEHOLDER_PREPROCESS_DIGEST",
  "data_order_digest": "PLACEHOLDER_DATA_ORDER_DIGEST",
  "optimizer_name": "SGD",
  "optimizer_config_digest": "PLACEHOLDER_OPTIMIZER_DIGEST",
  "initial_rng_state_digest": "PLACEHOLDER_RNG_DIGEST",
  "precision_policy": "FP32",
  "determinism_policy": "seeded_reproducible_in_reference_runtime",
  "batch_size": 16,
  "microbatch_size": 4,
  "context_length": 8,
  "expert_count": 4,
  "top_k": 2,
  "expert_capacity_policy": "explicit_fixed",
  "quality_metric": "validation_accuracy",
  "quality_direction": "higher",
  "quality_target": 0.90,
  "eval_protocol_digest": "PLACEHOLDER_EVAL_DIGEST",
  "ram_budget_bytes": 4294967296,
  "vram_budget_bytes": 2147483648,
  "baseline_id": "B10-02",
  "candidate_policy_id": "A10-00",
  "semantics_kind": "ExploratoryPilot",
  "code_revision": "PLACEHOLDER_COMMIT",
  "status": "UNRUN",
  "claims_allowed": ["contract-design-only"],
  "claims_prohibited": ["real-ai-speedup", "hardware-validation", "convergence-verified"]
}

C.1 ExperimentRunVerdictV0_1 示例

{
  "schema": "ExperimentRunVerdictV0_1",
  "run_id": "example-moe-run-001",
  "quality_status": "NOT_EVALUATED",
  "resource_budget_status": "NOT_MEASURED",
  "safety_invariant_status": "NOT_TESTED",
  "verdict": "UNAVAILABLE",
  "failure_refs": [],
  "claims_allowed": ["schema-example"],
  "claims_prohibited": ["time-to-quality-gain", "gpu-accelerated", "SMPDC-confirmed"]
}

C.2 正式 V1 Manifest 至少應再加

• Driver／CUDA runtime/toolkit／kernel library 與 OS 版本。
• CPU 型號、核心拓撲、各核心頻率政策、RAM，GPU VRAM、PCIe path、溫度及功率設定。
• 推論 server、模型檔案 hash、tokenizer、量化、prompt/data 固定 trace。
• 每個 run 的最終品質、資格判定、完成時間、未達標記錄及 censored reason。
• 每組 warmup、compiler cache、模型載入與最後資料回收的計時範圍。
• 來源、使用許可與環境差異；未記錄者不可用「同機器」概括。

附錄 D｜AI Workload 測試檢查表與研究治理

D.1 執行前（Pre-run）

D.2 執行中（During-run）

D.3 執行後（Post-run）

D.4 研究成熟度層級

• L0： 構想與問題界定。
• L1： 可執行方向的形式規格、反例、參照與 Mock 契約；本篇目前所在地位。
• L2： 真實小模型／真實 GPU Runtime 的功能／正確性測試。
• L3： 單機 V1 的公平效能比較與不同 seed、time-to-quality／goodput 統計。
• L4： 跨平台、跨模型、跨負載且由外部獨立重現的研究結果。

進入新等級必須有原始數據、重現步驟與預註冊品質閘門，不能由研究文章的篇幅、形式命題數量、Mock 單元測試通過率或工作流日誌替代。

參考文獻與原始研究來源

內部系列承接：SMPDC Paper 00–09

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

EveMissLab 相鄰研究：理論基底而非效能證據

• [X1] 〈群星架構在計算機系統中的應用與改良計畫〉，EveMissLab。早期多硬體節點的星系式動態設計。
• [X2] 〈相位計算機理論 v0.1〉，EveMissLab 無界智庫公開版：https://unboundedaxiom.org/p/lm-001850/。相位本體、表示、演化與載體分離。
• [X3] 〈GCCFT 的 AI 實例化：神經模型、多模態耦合與 Agent 計算場〉，EveMissLab。AI family 與 phase-aware relevance 的先前候選研究。
• [X4] 〈GCCFT Paper 08｜可證偽驗證〉，EveMissLab。A/B、資源、公平與研究反證方法。
• [X5] 〈GCCWT Paper 04｜計算場與資源激發〉，EveMissLab 無界智庫公開版：https://unboundedaxiom.org/p/lm-004846/。CPU/GPU/Memory/Agent 資源相對性。

公開學術與工程文獻（查核日期：2026-10-17）

• [E1] MLCommons, MLPerf Training，基準與工作群說明：https://mlcommons.org/working-groups/benchmarks/training/。用途：訓練品質門檻與同條件公平比較的成熟制度；本篇不聲稱符合 MLPerf 正式提交流程。
• [E2] MLCommons, MLPerf Training Rules，公開原始政策：https://github.com/mlcommons/training_policies/blob/master/training_rules.adoc。用途：time-to-target-quality、數據、run clock、評估頻率與規則中的可比性限制。
• [E3] Fedus, W., Zoph, B., & Shazeer, N. (2022), Switch Transformers: Scaling to Trillion Parameter Models with Simple and Efficient Sparsity, JMLR 23(120). https://www.jmlr.org/papers/v23/21-0998.html。用途：MoE 稀疏啟動、路由與訓練穩定化的成熟先例。
• [E4] Hwang, C. et al. (2022), Tutel: Adaptive Mixture-of-Experts at Scale, arXiv:2206.03382. https://arxiv.org/abs/2206.03382。用途：MoE 動態 routing 與 adaptive expert parallelism；不得把已有的 expert load-balancing 算作 SMPDC 發明。
• [E5] Rajbhandari, S. et al. (2019/2020), ZeRO: Memory Optimizations Toward Training Trillion Parameter Models, arXiv:1910.02054. https://arxiv.org/abs/1910.02054。用途：訓練 optimizer/gradient/parameter 分片及記憶體副本成本。
• [E6] Narayanan, D. et al. (2019), PipeDream: Generalized Pipeline Parallelism for DNN Training, SOSP 2019. https://doi.org/10.1145/3341301.3359646；開放論文：https://people.eecs.berkeley.edu/~matei/papers/2019/sosp_pipedream.pdf。用途：pipeline、weight stashing、forward/backward 版本。
• [E7] Huang, Y. et al. (2018/2019), GPipe: Efficient Training of Giant Neural Networks using Pipeline Parallelism, arXiv:1811.06965. https://arxiv.org/abs/1811.06965。用途：microbatch 和 pipeline parallelism。
• [E8] PyTorch, torch.distributed.fsdp.fully_shard (FSDP2)，官方文件：https://docs.pytorch.org/docs/stable/distributed.fsdp.fully_shard.html。用途：參數分片、all-gather、gradient synchronization 及 shard-residency 語義。
• [E9] Kwon, W. et al. (2023), Efficient Memory Management for Large Language Model Serving with PagedAttention, SOSP 2023, arXiv:2309.06180. https://arxiv.org/abs/2309.06180。用途：vLLM、KV 分頁／重用與 serving 既有研究。
• [E10] Zhong, Y. et al. (2024), DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving, arXiv:2401.09670. https://arxiv.org/abs/2401.09670。用途：TTFT／TPOT、prefill／decode 分離與服務目標。
• [E11] NVIDIA, NCCL User Guide and Collective Operations. https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/；https://docs.nvidia.com/deeplearning/nccl/user-guide/docs/usage/collectives.html。用途：集體運算、all-reduce/communication 及其實體異質限制。
• [E12] NVIDIA, CUDA Programming Guide — CUDA Graphs. https://docs.nvidia.com/cuda/cuda-programming-guide/04-special-topics/cuda-graphs.html。用途：GPU graph capture／replay、host launch overhead 的成熟基線。
• [E13] NVIDIA, GeForce RTX 3070 Family Specifications. https://www.nvidia.com/content/nvidiaGDC/us/en_US/geforce/graphics-cards/30-series/rtx-3070/。用途：RTX 3070 參考顯存容量及架構規格，實機必須查詢核實。
• [E14] NVIDIA, Nsight Systems User Guide. https://docs.nvidia.com/nsight-systems/UserGuide/index.html。用途：GPU/CPU timeline、CUDA launch/copy/stream trace；profiler 自身的侵入性須作控制。
• [E15] NVIDIA, CUDA C++ Best Practices Guide. https://docs.nvidia.com/cuda/cuda-c-best-practices-guide/index.html。用途：memory transfers、host/device 工作分工與資料搬移下界。
• [E16] Zheng, L. et al. (2023/2024), SGLang: Efficient Execution of Structured Language Model Programs, arXiv:2312.07104. https://arxiv.org/abs/2312.07104。用途：SGLang、RadixAttention 與複雜生成工作流 runtime 的既有路徑。
• [E17] MLCommons (2026-09), MLPerf Training v6.1: First LLM Post-Training Benchmark. https://mlcommons.org/2026/09/mlperf-training-llm-post-training/。用途：大型 MoE policy、trajectory、訓練與推論耦合時的端到端品質評估動機；不據此聲稱 SMPDC 已完成同規模測試。
• [E18] NVIDIA, CUDA Graph Troubleshooting—Performance Issues. https://docs.nvidia.com/dl-cuda-graph/troubleshooting/performance-issues.html。用途：graphs 可攤銷 launch 但亦有 input copy／capture 等實際成本。

文獻使用與研究誠信說明

公開來源所建立的是各自成熟技術或其公開測量結果，不構成 SMPDC 優勢的直接證據。EveMissLab 雲端資料提供原始構想與前置理論脈絡，也不是同行評審或獨立效能重現的替代品。不同 GPU、模型、精度、資料集和 SLO 下的研究數字不得作為同樣條件的速度直接相除。本篇所有尚無實體量測的收益性主張均屬假說或條件判準；形式 proof sketch 與 Mock 控制驗證的有效範圍已逐項標示。

原稿結案標記｜SMPDC Paper 10 v0.1

• 本篇交付： AWV10 的多工作負載有效性分類；模型／梯度／KV／品質評估型別與資料契約；九項條件命題；C10-01～C10-32；F10-01～F10-36；B10/A10 與 W10 實驗矩陣；V0/V1/V2 預算和研究路徑；跨篇 interface；可執行 Python mock 檢查器。
• 尚未交付： 真實 SMPDC 跨 CPU/GPU 運行時、任何可正式驗證的 AI training speedup、同品質 latency 實測、跨平台統計、GPU kernel 原生實作、正式 MLPerf 提交或 Paper 11 全系列反證結果。
• 下篇： SMPDC Paper 11｜系統驗證與可證偽實驗：跨篇契約、基線、消融、效能／品質統計、硬體重現與最終結案。
• canonical source： 本 UTF-8 Markdown 原始檔；僅 $...$ 和 $$...$$ 作為正式數學 delimiter，不透過聊天畫面回抄再充當 source。