--- 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$。研究的是： $$ \exists w,\,s,\,b:\quad Q(s,w)\succeq Q(b,w)\quad\land\quad R(s,w)\preceq R_{\max}\quad\land\quad T(s,w) 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，理想化計算／頻寬下界： $$ T_{\mathrm{ideal}}\ge\max\left(\frac{F}{P_{\max}},\frac{D}{B_{\max}}\right). $$ 此式忽略 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： $$ \pi_{ij}=\mathrm{Router}(x_i,e_j,\theta_r),\qquad \mathcal E_i=\mathrm{TopK}_k(\pi_{i1},\ldots,\pi_{iE}). $$ `TopK` 的排序、相同 score 的 tie-break、capacity overflow、訓練 dropout 和路由權重版本，都必須被定義。若不同 policy 改了可選 expert 或丟 token 規則，則比較的是**模型演算法與訓練制度**，不僅是 Runtime。 ## 7.3 MoE 執行分層 ```text 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： $$ (\theta_{k+1},o_{k+1})=U(\theta_k,o_k,g_k,\eta_k). $$ $g_k$ 必須是對正確樣本集合、有效權重版本與約定 reduce 規則所得的梯度。若因 R1 重送而把同一 sample／microbatch 的梯度累加兩次，已改變最佳化路徑；若兩個 worker 都提交同一 optimizer step，則是重複更新，不能以「雙路加速」合理化。 ## 8.3 梯度血緣類型 ```text 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}$，則： $$ v^{\mathrm{forward}}_{m,j}=v^{\mathrm{backward}}_{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 實作，但選用何種庫不是本文已確定的規範。 必要條件之一： $$ \mathrm{RNGIdentity}=H(\mathrm{run},\mathrm{step},\mathrm{sample},\mathrm{op},\mathrm{drawIndex}). $$ 此式表示候選設計原則，不要求一定採 hash 實作；若框架與 kernel 的 RNG 演算法本身因排程不同產生不同結果，則應改採統計等價測試並明確宣告，不能聲稱逐 bit 重現。 ## 10.3 決定性和統計等價需要分開的 PASS | 層級 | 範例 | 可以聲稱的範圍 | |---|---|---| | bitwise equivalence | 同硬體與相同 deterministic kernel，逐 bit 相等 | 特定版本硬體／程式 | | numerical equivalence | 公差、ULP、相對誤差可接受 | 特定算子／形狀／精度 | | distributional equivalence | 多 seed 的統計品質差異在預註冊區間 | 特定隨機策略與資料 | | application-quality equivalence | 任務目標、品質／安全門檻相符 | 定義的應用契約 | 四者互不自動包含。在 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 ```text 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，不能僅因「語義近似」就認定安全。 ```text 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 有效成果的最低分類 ```text 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$ 的總端到端成本： $$ \mathbf C(s)=\bigl(T_{\mathrm{wall}},T_{\mathrm{device}},B_{\mathrm{transfer}},M_{\mathrm{peak}},J_{\mathrm{energy}},N_{\mathrm{rollback}},N_{\mathrm{verify}}\bigr). $$ 不同成本維度的單位並不相同：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 建議決策流程 ```text 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 和工作流排程；但必須證明或測量其對數值結果的影響在預註冊政策內。 ```text 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 類型保護 ```text 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 最低狀態向量 令工作負載狀態： $$ Z_w=(I,M,D,C,V,S,A,Q), $$ 其中 $I$ 為 CPU orchestration intensity， $M$ 為記憶體壓力， $D$ 為主機／裝置資料搬移， $C$ 為動態耦合密度， $V$ 為驗證義務， $S$ 為狀態持續性， $A$ 為到達率／負載波動， $Q$ 為品質政策的嚴格程度。 這些維度尚無跨平台通用尺度。每個維度都需要定義可重現的測量估計器，不能用主觀 1–10 分數推出效能。 ## 16.2 研究型態的初步分組 | 工作負載 | 候選優勢來源 | 主要風險 | 初步研究優先級（非效能結論） | |---|---|---|---| | Large dense GEMM | host dispatch 攤銷（若存在） | GPU 已最佳化，增加 barrier | 低 | | 固定 shape LLM 推論 | 常駐服務與 session 隔離 | CUDA Graphs／vLLM 很強 | 中低 | | 動態 MoE／稀疏 routing | 負載均衡與分批、局部消息 | token scatter、AllToAll、CPU 介入 | 高 | | 經常 changing batch/context | 動態 phase/admission | GPU 重編圖與 cache 浪費 | 中 | | persistent multi-agent | I/O overlap、有限分支驗證 | idle memory、外部效果不可撤銷 | 高 | | 多候選 verifier | R1 尾延遲／R2 獨立佐證 | 額外成本、相關錯誤 | 高 | | 大型分散訓練 | 跨 stage orchestration | NCCL 通訊、staleness、權重安全 | 條件性，需多 GPU | | 單卡 LoRA／小模型微調 | 資料管線、GPU 工作 admission | VRAM 很小、編譯成本 | 高（易於 V1） | **表中的高低代表首先做實驗的可行性／信息量，不代表推測加速效果的大小。** ## 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$，則無額外仲裁／提交延遲的理想化候選時間： $$ T_{\mathrm{first}}=\min(T_1,T_2)\le T_1. $$ **限制：** 實際系統另有啟動、複製、競爭、驗證及取消開銷，總完成時間不必小於單路；而且兩路相同結果不等於雙重獨立正確性證明。此命題僅指出理想化選優的數學事實。 ## 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。每項都是候選**契約要求**，而非已驗證的硬體事實。 | ID | 不變量 | 必要的拒絕／處置 | |---|---|---| | C10-01 | 每個工作負載有不可混淆的 family、run、model version | 缺失則 Reject | | C10-02 | 每次對照都具 dataset／split／preprocess identity | 未可追溯則 Inconclusive | | C10-03 | 訓練者必須具 optimizer、有效 batch、初態與 seed lineage | 缺失則不承認同演算法比較 | | C10-04 | 精度、loss-scale、numerical tolerance 版本化 | 不一致則拆成不同實驗組 | | C10-05 | 品質目標在 confirmatory run 前固定 | 不得事後修改門檻 | | C10-06 | 未達標者標記 censor/failure，不能報為達標 | 關閉錯誤 speedup 宣稱 | | C10-07 | 模型 forward/backward 版本需符合所選策略 | 失配拒絕梯度 | | C10-08 | 每個 microbatch 梯度具有唯一血緣 | 重試不能重複累加 | | C10-09 | Optimizer 更新具有唯一提交鍵與 authority | 無權或過期則 Reject | | C10-10 | 一次 step 不得被兩個 attempts 重複提交 | 返回既存決定 | | C10-11 | Stale-gradient 政策不可隱式啟用 | 當作 algorithm-changing variant | | C10-12 | 修改 MoE top-k/capacity/drop 規則要標明語義變更 | 禁止混作等價 runtime | | C10-13 | Expert assignment 具有模型/router/version identity | 不相符就不能 merge | | C10-14 | 同一輸出 candidate 的 R1/R2/R3 型別保持 | 不得以相似訊息偽稱編碼冗餘 | | C10-15 | R1 競速優勝仍須通過合法品質／權限守衛 | 不能最快就直接公開 | | C10-16 | R2 同意不自動等同形式正確性 | 實際 verifier 必須獨立驗證 | | C10-17 | `PhaseDiffusion` 必有 credit、budget、epoch、TTL | 無界傳播應拒絕 | | C10-18 | 長壽 PWN 不必專佔物理 CPU | OS placement 可回收 | | C10-19 | GPU ticket 完成不等於 HostReadable | 要求 DeviceVisibilityWitness | | C10-20 | 所有 activation/KV/gradient buffer 必有生命週期 | 過期 lease 禁止存取 | | C10-21 | GPU offload 累加 transfer/launch/sync 的真實成本 | 不准只回報 kernel time | | C10-22 | CPU/GPU fallback 必維持模型狀態和版本 | 不可默默使用舊權重 | | C10-23 | 每個推論請求具輸入、context、deadline 和品質契約 | 缺失不能進 SLO 比較 | | C10-24 | TTFT／TPOT、tokens/sec、goodput 不相互替代 | 分欄記錄 | | C10-25 | KV lease 必綁 model/tokenizer/prefix identity | 異源 cache 不得直接重用 | | C10-26 | 已對外輸出的 token/side effect 無簡單回滾假設 | 必須有發佈政策 | | C10-27 | 多 Agent 執行候選與 authorized commit 區分 | 候選不計成功任務 | | C10-28 | RAM/VRAM/energy/時間預算於 admission 前判定 | 超額走 fallback/拒絕 | | C10-29 | 既有基線必經與候選相當的調優 | 禁止弱 baseline | | C10-30 | 測試資料、評估集和工作負載族不事後更換 | 變更則重新預註冊 | | C10-31 | AI planner 建議不得超越 OS/driver/commit authority | 不合法提案丟棄並記錄 | | C10-32 | 所有主張具 trace／manifest／原始數據鏈結 | 缺失則標為未驗證 | ## 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） 這些情境刻意包含**概念相似卻本質不同**的失敗，以便測試架構是否能維持層級邊界。預期處置是候選合約，不是宣稱原型已全部通過。 | 反例 ID | 情境 | 可接受的系統反應 | |---|---|---| | F10-01 | 訓練候選 step/sec 增加但 validation accuracy 降低 | 不接受等品質加速 | | F10-02 | 一個 run 永不達品質門檻 | 標 RightCensored 或失敗 | | F10-03 | 報告刪掉收斂較慢的 random seeds | 判研究數據不完整 | | F10-04 | 把 fp16 與 bf16 成果放同一等價組 | 拆組或明確算法變動 | | F10-05 | 對照更換 tokenizer 但維持同一 tokens/sec 名稱 | 拒絕直接可比性 | | F10-06 | R1 同一 microbatch 重送，被當成兩份梯度 | 防止 double accumulation | | F10-07 | R2 兩路共享同一錯誤資料標籤 | 不把一致當真值 | | F10-08 | R3 只傳語義相似文字而無碼本 | 拒絕 coded-recovery claim | | F10-09 | forward 用 v7、backward 用 v9 | 拒絕或改為獨立 stale 策略 | | F10-10 | Optimizer v7 更新兩次 | 原子提交鍵去重與衝突隔離 | | F10-11 | 崩潰重開後 RNG counter 被錯誤重設 | 拒絕重播或標不可重現 | | F10-12 | scheduler 恢復時錯置 optimizer state | 校驗版本／快照才可繼續 | | F10-13 | AMP overflow 被忽略，梯度 NaN 仍提交 | loss-scale guard／Reject | | F10-14 | 分散式 reduce group 少了一位 rank | collective 失敗與超時處理 | | F10-15 | 未一致的 collective 順序導致 hang | abort、restore、記錄 fault | | F10-16 | MoE router 改 top-1 到 top-2 但仍宣稱等價 | 重新定義算法組 | | F10-17 | Expert overflow 丟 token 卻未計品質影響 | 拒絕同品質主張 | | F10-18 | CPU PWN 對每個 token 做細粒度跨 PCIe 呼叫 | 以端到端 profile 揭露退化 | | F10-19 | GPU queue 已飽和，仍強制 offload | 回退 CPU 或 defer | | F10-20 | GPU device event 完成但 D2H copy 未完成 | 不標 HostReadable | | F10-21 | GPU buffer 被提前 free/reuse | lease／generation 防護 | | F10-22 | GPU driver 重新初始化使舊 ticket 失效 | fencing、降級與重試 | | F10-23 | VRAM peak 超配額但仍將 run 標 PASS | 拒絕資源合法性 | | F10-24 | GPU memory 壓力造成頻繁 offload | 計入完整搬移成本 | | F10-25 | 不同 model revision 共用 KV cache | 拒絕 cache reuse | | F10-26 | 修改 context truncation 但未更新品質／SLO | 分組，不算等價推論 | | F10-27 | 批次變大 tokens/sec 增加但 p99 惡化 | 記錄 SLO 失敗 | | F10-28 | 推論縮短答案提升吞吐 | 以合格 token／任務計量 | | F10-29 | Stream token 已對外輸出後嘗試內部回滾 | 外部效果政策處理，不能假裝撤銷 | | F10-30 | verifier 候選未正式驗證即提交 | 阻擋提交／外部效果 | | F10-31 | 多 Agent 重送導致工具付款兩次 | 冪等外部效果／補償流程 | | F10-32 | phase-blind 的成熟 scheduler 更快 | 承認 SMPDC 該工作負載失效 | | F10-33 | AI planner 違反 VRAM/權限硬限制 | 拒絕 AI proposal | | F10-34 | 對照組使用過時或未暖機的 GPU 程式 | 基線無效，重測 | | F10-35 | 只報 sample/sec 但不報 VRAM/energy/cpu 占用 | 標不完整或不具可比性 | | F10-36 | 模擬器全部 PASS 卻宣稱硬體已加速 | 限制主張成熟度、拒絕效能結論 | ## 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 案例 | 最小資料 | 預期可驗證結果 | |---|---|---| | V0-01 | 同鍵 microbatch 梯度重送 | 恰一次邏輯納入 | | V0-02 | forward/backward weight version 失配 | 拒絕產生合法 gradient | | V0-03 | optimizer step version stale | commit conflict，不 double update | | V0-04 | KV lease 的 model/tokenizer mismatch | 禁止 reuse | | V0-05 | GPU result 無 HostReadable witness | CPU aggregator 拒絕 | | V0-06 | 同樣平均延遲，不同尾延遲的兩路 | 假設模型下測試 R1 eligibility 與資源成本 | 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：最小公平基線群 | 基線 | 名稱 | 對應場景 | 強化規則 | |---|---|---|---| | B10-00 | CPU serial reference | 微型正確性／Verifer | 合法數學輸出，非弱化故意慢版 | | B10-01 | CPU optimized parallel | 資料處理、routing、驗證 | thread pool、SIMD 或成熟並行方案 | | B10-02 | Native framework GPU eager | Dense／MoE／LoRA | 正確最佳化 library | | B10-03 | Compiled/Graphed GPU | 固定／重複 shape | torch.compile／CUDA Graphs（若支援） | | B10-04 | Standard async runtime | Agent/Verifier | 有界 queue、現代 async scheduling | | B10-05 | vLLM style paging/batching | LLM serving | 只有可在設備上合法運行才計入 | | B10-06 | SGLang／prefix reuse | structured LLM inference | 固定同一模型和輸入 | | B10-07 | Framework MoE dispatch | Sparse MoE | 實際可用的最佳成熟 router | | B10-08 | Tutel／專業 expert parallel | 多 GPU MoE | 只在支援硬體上比較 | | B10-09 | FSDP／ZeRO | 訓練記憶體分片 | 只在需要／可用的情境比較 | | B10-10 | GPipe／PipeDream style | pipeline training | 保留權重版本及策略差異 | | B10-11 | Best locality-aware placement | 硬體局部性 | HLC09 既有最強部署對照 | | B10-12 | Combined best-known pipeline | 指定 workload 全域基線 | 預註冊最佳成熟合法組合 | 不應要求任何一顆單 GPU 電腦實際執行 B10-08～B10-10，若支援條件不成立可寫 `NotApplicable/UNAVAILABLE`。但也不能用不可運行的基線數值作為低品質假想對照。每個實驗要指明**實際適用的最強基線**，不能挑最弱者。 ## 23.2 A10-00～A10-12：消融設計 | 消融 | 配置 | 要識別的變量 | |---|---|---| | A10-00 | baseline only | 成熟路徑基準 | | A10-01 | PWN persist only | 工作流常駐的淨收益／成本 | | A10-02 | phase guard only | 相位資訊是否有額外用途 | | A10-03 | diffusion with fixed topology | 有界傳播的成本 | | A10-04 | dynamic coupling | 動態邊相較固定邊的差異 | | A10-05 | R1 only | 競速／尾延遲與資源放大 | | A10-06 | R2 only | 異源驗證成本與錯誤識別 | | A10-07 | R3 when applicable | 碼率／恢復與傳輸成本 | | A10-08 | speculative compute only | rollback、wasted work | | A10-09 | GPU relation batch only | GPU 批次的淨收益 | | A10-10 | locality-aware placement only | cache／NUMA／copy 影響 | | A10-11 | AI advisory disabled | 基本 OS 控制器下界 | | A10-12 | full SMPDC bundle | 聯合效果與交互作用 | 任何消融若違反前篇不可刪除的安全 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 不能單獨代替品質 對成功達到相同目標的兩配置，可定義： $$ S_Q=\frac{T_Q(\mathrm{baseline})}{T_Q(\mathrm{candidate})}. $$ 當其中一者未達標時，不報該組的有限 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 ```text 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` ```text 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` ```text 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 競品／前例清單與實際研究差異 | 公開先例 | 已具備的成熟概念 | SMPDC 要證明的額外內容 | |---|---|---| | Switch Transformer | 稀疏 expert 激活和訓練穩定化 | 多主 PWN 是否有淨 orchestration 效益 | | Tutel | 動態 expert parallelism 和 pipelining | 相位／信用／權威契約是否在額外成本後仍有用 | | ZeRO／FSDP | 訓練狀態分片和通訊 | 不破壞分片優勢的可驗證工作流擴散 | | GPipe／PipeDream | 流水線和權重版本管理 | CPU 持續工作流的安全編排是否另有增量 | | vLLM／PagedAttention | KV cache paging 和高效 serving | 外圍多任務工作流是否改善合法 goodput | | SGLang | 複雜生成程式和 KV/prefix reuse | 具 authority／proof 的擴散協作是否有增量 | | DistServe | Prefill/decode 分離與服務 goodput | phase-aware 跨型別執行的公平收益 | | NCCL | GPU 多設備通信、collectives | 不與現成 GPU network/collectives 重複的部分 | | CUDA Graphs | GPU graph 重播降低 launch overhead | 在同等最佳化後是否仍有可改善的 host 部分 | | MLPerf | 指定品質目標的訓練公平評估 | 引入可反證的 SMPDC workload domain 證據 | ## 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。 | 序 | 事件 | 狀態／檢查 | 決策 | |---|---|---|---| | 1 | `PWN-A` 產生 `DataReady(M3)` | data digest 固定，owner generation 5 | Admit | | 2 | router 指派 top-2 expert | router=v2、model=v7、capacity accepted | Admit | | 3 | `PWN-B` 批次提交 GPU expert matmul | ticket=T21、lease=L11、phase eligible | Admit | | 4 | GPU 回報 kernel completion | 缺 HostReadable witness | Hold | | 5 | D2H/event dependency 到齊 | witness=W21、L11 未過期 | HostReadable | | 6 | `PWN-A` 聚合 expert result | expected token/expert assignment matched | LocalVerified | | 7 | backward 使用 model=v7 | forward/backward version matched | GradientAccepted | | 8 | 梯度重送 attempt 2 | same logical gradient lineage as attempt 1 | DuplicateIgnored | | 9 | optimizer 提交 `step=52, base=v7` | authority/lease/grad membership validated | Committed(v8) | | 10 | 相同 step 被再次提交 | identical commit key | AlreadyDecided | 此例說明各種「完成」都不同：GPU kernel 完成、HostReadable、局部驗證與持久化 optimizer commit 是不同義務。即使每步都被宣告成功，本例仍**不證明**相同模型在真實資料上會更快收斂，因為沒有任何真實訓練或品質量測。 ## A.2 反例：看似更快卻無法達到品質門檻 設定兩個具相同模型與資料版本的候選（此為假想資料，**非實測**）。策略 A 保留原版權重一致性；策略 B 放寬 stale gradient 並允許第二路的相同 microbatch 梯度重複累加。 ```text 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 實體成效證據。 ```python 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 範圍及合法欄位。 ```json { "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` 示例 ```json { "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） | 檢查 | 必要結果 | |---|---| | 模型／資料／optimizer／RNG 初態身份 | 固定且可驗證 | | 測試族、品質方向和達標門檻 | 預註冊 | | 基線適用性與缺席原因 | 可追溯 | | RAM／VRAM／能耗／功耗上限 | 明確 | | 模擬／實機來源、硬體拓撲 | 明確 | | 相位、R0–R3、GPU offload 可用性 | 分別宣告 | | 外部副作用與權限風險 | 隔離或授權 | | warmup／compile／預處理規則 | 對兩方相同 | ## D.2 執行中（During-run） | 檢查 | 必要結果 | |---|---| | forward/backward weight lineage | 不失配，或屬宣告過的演算法族 | | step commit and replay | 不重複生效 | | GPU buffer ownership/visibility | 受 lease/witness 保護 | | bounded diffusion and backpressure | 不發生未授權無界擴散 | | VRAM/RAM 峰值 | 全程量測 | | eval metrics、TTFT/TPOT、已提交結果 | 以主終點的完整定義採集 | | 故障注入與 recovery | 與安全 guard 不衝突 | ## D.3 執行後（Post-run） | 檢查 | 必要結果 | |---|---| | 全部 seed、完成／未完成 run | 完整揭露 | | 主要品質判定和全成本 | 完整 | | Baseline 與候選的相同資源前提 | 核對 | | 消融交互作用 | 報告無益或有害配置 | | 類型化 `PASS/FAIL/INCONCLUSIVE/UNAVAILABLE` | 不混同 | | 可重演 manifest、版本、原始 trace | 保存 | | 偏離預註冊內容 | 清楚列出 | | 尚未驗證／只在 Mock 通過的內容 | 明確標記 | ## 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 無界智庫公開版：。相位本體、表示、演化與載體分離。 - **[X3]** 〈GCCFT 的 AI 實例化：神經模型、多模態耦合與 Agent 計算場〉，EveMissLab。AI family 與 phase-aware relevance 的先前候選研究。 - **[X4]** 〈GCCFT Paper 08｜可證偽驗證〉，EveMissLab。A/B、資源、公平與研究反證方法。 - **[X5]** 〈GCCWT Paper 04｜計算場與資源激發〉，EveMissLab 無界智庫公開版：。CPU/GPU/Memory/Agent 資源相對性。 ## 公開學術與工程文獻（查核日期：2026-10-17） - **[E1]** MLCommons, *MLPerf Training*，基準與工作群說明：。用途：訓練品質門檻與同條件公平比較的成熟制度；本篇不聲稱符合 MLPerf 正式提交流程。 - **[E2]** MLCommons, *MLPerf Training Rules*，公開原始政策：。用途：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). 。用途：MoE 稀疏啟動、路由與訓練穩定化的成熟先例。 - **[E4]** Hwang, C. et al. (2022), *Tutel: Adaptive Mixture-of-Experts at Scale*, arXiv: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. 。用途：訓練 optimizer/gradient/parameter 分片及記憶體副本成本。 - **[E6]** Narayanan, D. et al. (2019), *PipeDream: Generalized Pipeline Parallelism for DNN Training*, SOSP 2019. ；開放論文：。用途：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. 。用途：microbatch 和 pipeline parallelism。 - **[E8]** PyTorch, *torch.distributed.fsdp.fully_shard (FSDP2)*，官方文件：。用途：參數分片、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. 。用途：vLLM、KV 分頁／重用與 serving 既有研究。 - **[E10]** Zhong, Y. et al. (2024), *DistServe: Disaggregating Prefill and Decoding for Goodput-optimized Large Language Model Serving*, arXiv:2401.09670. 。用途：TTFT／TPOT、prefill／decode 分離與服務目標。 - **[E11]** NVIDIA, *NCCL User Guide and Collective Operations*. ；。用途：集體運算、all-reduce/communication 及其實體異質限制。 - **[E12]** NVIDIA, *CUDA Programming Guide — CUDA Graphs*. 。用途：GPU graph capture／replay、host launch overhead 的成熟基線。 - **[E13]** NVIDIA, *GeForce RTX 3070 Family Specifications*. 。用途：RTX 3070 參考顯存容量及架構規格，實機必須查詢核實。 - **[E14]** NVIDIA, *Nsight Systems User Guide*. 。用途：GPU/CPU timeline、CUDA launch/copy/stream trace；profiler 自身的侵入性須作控制。 - **[E15]** NVIDIA, *CUDA C++ Best Practices Guide*. 。用途：memory transfers、host/device 工作分工與資料搬移下界。 - **[E16]** Zheng, L. et al. (2023/2024), *SGLang: Efficient Execution of Structured Language Model Programs*, arXiv:2312.07104. 。用途：SGLang、RadixAttention 與複雜生成工作流 runtime 的既有路徑。 - **[E17]** MLCommons (2026-09), *MLPerf Training v6.1: First LLM Post-Training Benchmark*. 。用途：大型 MoE policy、trajectory、訓練與推論耦合時的端到端品質評估動機；不據此聲稱 SMPDC 已完成同規模測試。 - **[E18]** NVIDIA, *CUDA Graph Troubleshooting—Performance Issues*. 。用途：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。