從全域計算方法論到 AI 原生計算編排

GCM Reference Runtime、計算配置分配演算法、Native Compute Fabric 與 HDUS 介接總體技術白皮書

版本： v0.1
日期： 2026-08-25
文件性質： 統合技術白皮書／下一階段工程架構文
狀態： Canonical Draft
上游來源： GCM Series-00、Paper 01–06、TW-01、TW-02、TW-03、GCM Reference Runtime MVP v0.1

摘要

Global Computation Methodology（GCM）已由最初的 24／72 計算配置結構，逐步發展為一套處理異質計算、全域一致性、動態配置路由、觀察與物化分離、有限活動實現以及可追溯歷史的形式方法論，並已進一步形成 Canonical Specification、Reference Runtime Architecture、Conformance Specification 與可執行 Reference Runtime。

因此，下一階段的核心問題已經不再只是：

「什麼是 Global Computation？」

而是：

一個 AI、原生計算機或未來 World-native 作業系統，如何在 GCM 的語義、權限、資源與驗證約束內，自主判斷應採取何種計算、使用何種計算配置、分配多少資源、在哪裡執行、何時切換方法，以及什麼時候結果具有足夠證據可以提交？

本白皮書提出以下長期演進架構：

\boxed{ \text{GCM Semantic Runtime} \rightarrow \text{Compute Orchestrator / Allocator} \rightarrow \text{Native Compute Fabric} \rightarrow \text{HDUS Adapter} }

其工程順序則固定為：

\boxed{ \text{Reference MVP 100\%} \rightarrow \text{Deterministic Compute Allocation} \rightarrow \text{AI-assisted Orchestration} \rightarrow \text{Native Resource Fabric} \rightarrow \text{HDUS Integration}. }

第一階段先把現有 GCM Reference Runtime 補足為陌生工程師可以獨立安裝、執行、擴張與驗證的 Developer-Usable Reference Runtime；第二階段建立 deterministic、constraint-first 的計算配置與資源分配演算法；第三階段讓 AI 成為 proposal / planning layer，在 deterministic admissibility、authority、budget 與 verification gates 內進行自主計算編排；第四階段介接 CPU、GPU、NPU、memory、storage、network、cluster 與其他計算載體；最後才透過明確 adapter 對接未來 HDUS。

本文件不是新的第七篇 GCM 核心論文，也不重新定義 00–06。它是從既有形式系統走向 AI-native computational operating layer 的工程交接總圖。

1. GCM 已完成的基礎

目前 GCM 的配置基礎為：

\mathfrak P_{24} = \mathfrak B_2 \times \mathfrak U_4 \times \mathfrak I_3,

以及：

\mathfrak P_{72} = \mathfrak P_{24} \times \mathfrak L_3.

其中：

\boxed{ \mathfrak P_{24},\mathfrak P_{72} = \text{Extensible Computational Configuration Basis} }

而不是計算世界的封閉窮舉。

GCM 的上層定義仍然是：

\boxed{ \text{Global Computation} = \text{Globally Coherent Heterogeneous Computation}. }

經過 Paper 01–06、TW-01–TW-03 與 Reference Runtime，以下邊界已經成為後續系統不得破壞的基本 invariants：

\boxed{ \mathcal M_G\neq\mathbf W }

\boxed{ \text{Computation} \neq \text{Observation} \neq \text{Materialization} }

\boxed{ \text{Can Execute} \neq \text{May Execute} }

\boxed{ \text{Executor Success} \not\Rightarrow \text{Global Commit} }

\boxed{ \text{Global Dependency} \neq \text{Full Materialization} }

\boxed{ \text{Finite Active Realization} + \text{Unbounded Extensibility} }

\boxed{ \text{State Equality} \not\Rightarrow \text{History Equality}. }

因此，「AI 自主管理計算能力」並不是在 GCM 上加入一個任意 scheduler，而是把 AI 自主性放入這組已經建立的 invariants 內。

2. 為什麼下一階段不只是 AI Scheduler

傳統 scheduler 通常面對的是：

已經存在一組 runnable tasks，如何把它們安排到 processor、node 或 time slice？

但 GCM 下一階段所處理的問題更早。

對一個目標 $G$ ，系統首先可能需要判斷：

\boxed{ \begin{aligned} &\text{如何分解 computational domains？}\\ &\text{每個 domain 使用何種 computational configuration？}\\ &\text{需要哪一種 transition law？}\\ &\text{需要哪些 representation bridges？}\\ &\text{哪些資料需要 materialize？}\\ &\text{哪些區域只需 dormant / coarse realization？}\\ &\text{需要多少 compute resolution？}\\ &\text{哪些 hardware resources 值得投入？}\\ &\text{哪些結果必須增加 verification？} \end{aligned} }

最後才進入：

CPU、GPU、NPU 或哪一個 node 執行？

因此：

\boxed{ \text{GCM Compute Orchestration} \neq \text{OS Scheduling}. }

OS scheduler 是未來 GCM 可以驅動或提供 hint 的低層 actuator，但不是 GCM 本身。

同樣：

\boxed{ \text{GCM Compute Orchestration} \neq \text{Compiler Auto-Tuning}. }

TVM MetaSchedule 已經可以在 tensor program 的 schedule design space 中，用 cost model、hardware measurement 與 task scheduler 搜尋高效 implementation；Ansor 亦已研究如何自動生成和搜尋大型 tensor-program search spaces。

這些技術未來可以成為 GCM 的 executor 或 optimization backend。

GCM 所處的位置更上層：

\boxed{ \text{Which computation} \rightarrow \text{Which configuration} \rightarrow \text{Which implementation} \rightarrow \text{Which resources}. }

3. 四層總體架構

3.1 Layer 0：GCM Semantic Runtime

這就是目前已完成的 Reference Runtime 核心。

其 canonical World mutation pipeline 為：

\boxed{ \text{Proposal} \rightarrow \text{Reconcile} \rightarrow \text{Verify} \rightarrow \text{Commit / Reject}. }

Layer 0 負責：

World / Runtime / Observer / Foundation separation；
typed operation；
reachability；
admissibility；
authority；
representation bridge；
proposal isolation；
reconciliation；
verification；
commit；
rollback / compensation；
materialization；
active support；
typed history。

其最高優先原則仍然是：

\boxed{ \text{Semantic Correctness} \succ \text{Performance Optimization}. }

也就是後面的 AI、cost model 或 optimization algorithm 都不能反過來修改這一層的合法性定義。

3.2 Layer 1：Compute Orchestrator / Allocator

下一階段真正新增的是這一層。

定義一個 orchestration problem：

\mathcal Q = \left\langle G, B_W, \mathcal D, \mathfrak P, \mathcal E, \mathcal B, \mathcal R, \mathcal C, \mathcal A, \mathcal H, \mathcal Bgt \right\rangle.

其中：

G = \text{Goal / Intent},

B_W = \text{World Boundary},

\mathcal D = \text{Candidate Domain Decompositions},

\mathfrak P = \text{Computational Configuration Space},

\mathcal E = \text{Executor Registry},

\mathcal B = \text{Bridge Registry},

\mathcal R = \text{Resource State},

\mathcal C = \text{Constraints / Invariants},

\mathcal A = \text{Authority Context},

\mathcal H = \text{Historical Evidence},

\mathcal Bgt = \text{Budget Envelope}.

Orchestrator 產生：

\Omega = \left\langle \Delta_D, \Gamma, E, Br, A_R, \sigma, \rho^C, M, V, K \right\rangle.

其中：

\Delta_D = \text{Domain Decomposition / Refinement},

\Gamma = \text{Configuration Assignment},

E = \text{Executor Binding},

Br = \text{Representation Bridge Plan},

A_R = \text{Resource Allocation},

\sigma = \text{Execution / Scheduling Relation},

\rho^C = \text{Compute Resolution},

M = \text{Materialization / Active-Support Plan},

V = \text{Verification Strategy},

K = \text{Recovery / Compensation Contract}.

但是：

\boxed{ \Omega \neq \text{Execution Authority}. }

Orchestrator 的輸出首先是一個 plan proposal。

3.3 Layer 2：Native Compute Fabric

這一層將 GCM 的 logical compute demand 映射到實際計算載體。

定義：

\mathsf{ResourceAdapter}: \mathsf{LogicalDemand} \rightharpoonup \mathsf{PhysicalBinding}.

可能包含：

\begin{aligned} &\text{CPU / NUMA},\\ &\text{GPU / VRAM},\\ &\text{NPU / TPU / accelerator},\\ &\text{system memory},\\ &\text{unified memory},\\ &\text{NVMe / storage},\\ &\text{network},\\ &\text{remote nodes},\\ &\text{cloud executors}. \end{aligned}

Ray 已提供 CPU、GPU、memory 與 custom logical resources 的 resource-aware scheduling；其文件也特別指出 logical resource request 並不等於 physical CPU isolation。

所以 GCM 必須明確保持：

\boxed{ \text{Logical Resource Claim} \neq \text{Physical Enforcement}. }

Resource Adapter 最低應回報：

\mathfrak R_{\mathrm{bind}} = \left\langle \mathsf{Requested}, \mathsf{Granted}, \mathsf{Enforced}, \mathsf{Observed}, \mathsf{Isolation}, \mathsf{Topology}, \mathsf{Failure} \right\rangle.

3.4 Layer 3：HDUS Adapter

HDUS 與 GCM 不應互相吞併。

應保持：

\boxed{ \text{HDUS Semantics} \neq \text{GCM Semantics}. }

兩者之間以 typed adapter 對接：

\boxed{ \text{HDUS} \xleftrightarrow{\text{Typed Adapter}} \text{GCM}. }

例如：

\mathsf{HDUSIntent} \rightarrow \mathsf{GCMOperationRequest},

\mathsf{HDUSWorldBoundary} \rightarrow B_W,

\mathsf{HDUSSubjectAuthority} \rightarrow \mathsf{AuthorityContext},

\mathsf{HDUSResourceFabric} \rightarrow \mathsf{ResourceAdapterRegistry}.

因此不允許簡化為：

\boxed{ \text{HDUS Process Success} = \text{GCM World Commit}. }

同樣：

\boxed{ \text{HDUS Subject} \neq \text{GCM Executor}. }

HDUS 可以成為未來最深度的 native integration target，但 GCM 必須保持可獨立存在。

4. Reference Runtime MVP 的 100% 定義

目前的 Reference Runtime 已完成 semantic kernel 與 R0-M4 conformance。

但 Developer-Usable Reference MVP 應再完成五個區塊。

4.1 Durable Core

最低要求：

\boxed{ \text{Process Restart} \not\Rightarrow \text{Semantic Reset}. }

需要：

SQLite 或同級 local durable backend；
durable World head；
Foundation version persistence；
append-only provenance / evidence；
canonical serialization；
recoverable transaction marker；
restart recovery；
durable history index。

4.2 Demo UX

最低提供：

gcm demo heterogeneous
gcm demo authority
gcm demo observer
gcm demo bounded-world
gcm demo history
gcm conformance

每個 demo 都必須展示 GCM invariant，而不是只有 happy-path output。

4.3 Plugin SDK

第一版 plugin surface：

ExecutorPlugin
BridgePlugin
ResourceAdapter
CostEstimator
VerificationPlugin

但：

\boxed{ \text{Plugin Capability} \not\Rightarrow \text{Plugin Authority}. }

Plugin 可以宣告：

我會做什麼。

不能因此宣告：

所以我有權修改 World。

4.4 Recovery Matrix

至少覆蓋：

\begin{aligned} &\text{before execution},\\ &\text{after execution / before proposal persist},\\ &\text{after proposal / before verification},\\ &\text{after verification / before World write},\\ &\text{after World write / before receipt},\\ &\text{after receipt / before acknowledgement},\\ &\text{during archive / restore},\\ &\text{during compensation},\\ &\text{during Foundation revision}. \end{aligned}

目標不是所有 fault 都能「神奇恢復」，而是：

\boxed{ \text{Fault} \not\Rightarrow \text{Unknown Silent State}. }

4.5 External Developer Packaging

一個沒有讀過 GCM 論文的工程師應可：

\boxed{ \text{Install} \rightarrow \text{Run} \rightarrow \text{Inspect} \rightarrow \text{Extend} \rightarrow \text{Conform}. }

具體而言：

安裝 package；
跑五組 demos；
執行 conformance；
新增一個簡單 executor；
查看 proposal / receipt / history；
理解 route 為什麼被 reject；
不需要先讀完 00–06。

完成以上五項後，才正式封板：

\boxed{ \text{GCM Reference Runtime MVP v0.1} = 100\%. }

5. 第一版 Compute Allocation Algorithm

Reference MVP 完成後，下一個正式工程不是先加入 LLM，而是：

\boxed{ \mathsf{GCMAllocator}_{0} = \text{Deterministic Constraint-First Allocator}. }

5.1 Safe Set

所有候選 orchestration plans 為：

\mathbb \Omega.

先建立：

\mathbb \Omega_{\mathrm{safe}} = \left\{ \Omega\in\mathbb \Omega \mid \mathsf{Reachable} \land \mathsf{Admissible} \land \mathsf{Authorized} \land \mathsf{BridgeValid} \land \mathsf{BudgetFeasible} \land \mathsf{InvariantPreserving} \right\}.

只有：

\Omega\in\mathbb \Omega_{\mathrm{safe}}

才能進入 optimization。

所以：

\boxed{ \text{Admissibility First} \rightarrow \text{Optimization Second}. }

5.2 Multi-objective Resource Evaluation

對 plan $\Omega$ 定義：

\mathbf J(\Omega) = \left[ T, C, E, M, D, R, \epsilon, H, X \right].

可分別表示：

T=\text{latency},

C=\text{compute / financial cost},

E=\text{energy},

M=\text{memory pressure},

D=\text{data movement},

R=\text{operational risk},

\epsilon=\text{approximation error},

H=\text{history / verification burden},

X=\text{configuration switching / bridge cost}.

預設不要求全部壓成：

J(\Omega)\in\mathbb R.

可先使用：

\boxed{ \text{Pareto-safe Selection} }

再由 policy 指定 ranking。

因此：

\boxed{ \text{Mathematics} \neq \text{Verification} \neq \text{Optimization}. }

6. AI 的正確位置

第一版 AI 不應直接取代 deterministic allocator。

AI 應產生：

\Omega^{AI}_1, \Omega^{AI}_2,\ldots,\Omega^{AI}_n.

而 deterministic core 執行：

\mathsf{Validate} \left( \Omega^{AI}_k \right).

只有：

\Omega^{AI}_k \in \mathbb\Omega_{\mathrm{safe}}

的計畫才可以執行。

因此：

\boxed{ \text{AI Planning Authority} \neq \text{Execution Authority} \neq \text{Commit Authority}. }

7. AI 自主計算編排階梯

Level 0 — Deterministic

使用：

capability matching；
fixed constraints；
deterministic ranking。

Level 1 — Heuristic

加入：

known hardware preference；
locality；
cache；
estimated execution cost。

Level 2 — Learned Cost Model

從歷史 receipt 與 metrics 學習：

\widehat{\mathbf J}(\Omega).

但 learned model 只能：

排 safe candidates。

不能：

把 unsafe candidate 變成 safe。

TVM MetaSchedule 已展示以 cost model、實際 hardware measurement 與 tuning database 驅動 search 的成熟工程方式，可作為此層重要參照。

Level 3 — AI Proposal Planner

AI 可以提出：

domain decomposition；
configuration；
executor；
bridge；
resource；
materialization；
verification strategy。

Level 4 — Bounded Autonomous Orchestrator

AI 在：

\left\langle B_W, \mathcal A, \mathcal Bgt, \mathcal C \right\rangle

約束內自動重規劃。

Level 5 — Continual Self-Tuning

根據 history 自動調整：

cost model；
routing preference；
resource policy；
exploration policy。

即使到了 Level 5：

\boxed{ \text{Foundation Auto-Revision} = \text{Forbidden by Default}. }

8. Closed-loop Compute Orchestration

真正的 AI-native compute runtime 不應只做一次 allocation。

其控制迴路為：

\boxed{ \text{Observe} \rightarrow \text{Plan} \rightarrow \text{Validate} \rightarrow \text{Allocate} \rightarrow \text{Execute} \rightarrow \text{Measure} \rightarrow \text{Replan}. }

但 World mutation 仍然是另一條：

\boxed{ \text{Proposal} \rightarrow \text{Reconcile} \rightarrow \text{Verify} \rightarrow \text{Commit}. }

所以：

\boxed{ \text{Adaptive Resource Reallocation} \not\Rightarrow \text{Unverified World Mutation}. }

9. History 從 audit 變成 allocator evidence

Paper-06 所建立的 typed history 未來可以作為 allocator 的 empirical evidence base。

定義：

\mathsf{Evidence}(\Omega) = \left\langle \mathsf{Runtime}, \mathsf{Cost}, \mathsf{Error}, \mathsf{Failure}, \mathsf{Recovery}, \mathsf{Hardware}, \mathsf{WorldContext} \right\rangle.

Allocator 可以學習：

某類 domain 適合哪種 configuration；
某 executor 在某硬體上的實際性能；
某 bridge 的 loss；
哪種 resolution 已經足夠；
哪些任務值得 GPU；
哪些任務 CPU 反而更快；
哪些 route 雖然快但 verification burden 過大。

但：

\boxed{ \text{Historical Performance} \not\Rightarrow \text{Semantic Admissibility}. }

10. 與既有技術的公平定位

StarPU 已經是一套成熟的 heterogeneous runtime，可以處理 task dependencies、CPU/GPU execution、data movement、asynchronous execution，並使用 performance models 進行 processor-aware scheduling。

Legion 已經透過 logical regions、privileges 與 coherence 建立 correctness constraints，也明確讓 mapper 負責硬體 mapping，而 mapping decision 原則上不應改變程式 correctness。

Ray 已處理 distributed CPU/GPU/custom logical resource scheduling。

TVM MetaSchedule 與 Ansor 已處理 automatic search space exploration、cost model、measurement 與 tuning budget。

MLIR Transform Dialect 已經提供 compiler transformation orchestration surface。

Linux sched_ext 則已允許使用 BPF 實作 extensible scheduler，並在 scheduler failure 時退回 kernel default scheduling behavior。

截至 2026 年，Kubernetes Dynamic Resource Allocation 已經成為 stable resource-allocation mechanism，並持續擴展 accelerator、CPU、memory 與更多 device/resource classes。

因此 GCM 不宣稱發明上述技術。

GCM 下一階段真正研究的是：

\boxed{ \begin{aligned} &\text{World-relative computational planning}\\ +&\text{extensible computational configuration selection}\\ +&\text{authority-preserving orchestration}\\ +&\text{verification-bound adaptation}\\ +&\text{observer/materialization/history-aware resource use}. \end{aligned} }

11. Native Compute Fabric

Native Compute Fabric 應作為 GCM 和底層系統之間的 adapter layer。

第一版本可只支援：

\boxed{ \text{CPU} + \text{Memory} + \text{Local GPU} + \text{Storage} + \text{Executor Concurrency}. }

後續再擴張：

\begin{aligned} &\text{NUMA},\\ &\text{NPU},\\ &\text{unified memory},\\ &\text{remote GPU},\\ &\text{cluster},\\ &\text{network-aware allocation},\\ &\text{cloud},\\ &\text{energy-aware execution}. \end{aligned}

Linux 上未來可考慮：

cgroups；
affinity；
NUMA APIs；
accelerator APIs；
sched_ext。

但：

\boxed{ \text{GCM Plan} \neq \text{Kernel Scheduling Decision}. }

GCM 可以給低層 scheduler policy / hint / resource contract，但不必取代 kernel scheduler。

12. HDUS 的長期位置

HDUS 未來可以成為：

\boxed{ \text{World-native OS / Runtime} }

而 GCM 成為：

\boxed{ \text{Computational Semantics / Orchestration Layer}. }

所以更合理的關係是：

Human / AI / HDUS Subject
          ↓
Intent / World Operation
          ↓
GCM Compute Orchestrator
          ↓
GCM Semantic Validation
          ↓
Native Compute Fabric
          ↓
HDUS / Linux / Hardware Runtime

而不是：

HDUS = GCM

也不是：

GCM = HDUS Scheduler

兩套系統應各自保留 canonical semantics，再透過 adapter 合成。

13. 正式工程 Roadmap

Phase A｜Reference Runtime MVP 100%

A1 — Durable Core

完成 local persistence、restart recovery 與 durable provenance。

A2 — Demo UX

完成：

heterogeneous
authority
observer
bounded-world
history
conformance

六條 developer-facing path。

A3 — Plugin SDK

完成第一版：

Executor
Bridge
ResourceAdapter
Estimator
Verifier

plugin surface。

A4 — Recovery Matrix

將 Reference Runtime 的 crash/recovery coverage 從單一重點 case 擴張到關鍵 fault boundaries。

A5 — Developer Release

完成 package、installation、tutorial、extension example、evidence inspection 與 release validation。

達成：

\boxed{ \text{GCM Reference Runtime MVP v0.1} = 100\%. }

Phase B｜Deterministic Compute Allocator

建立：

\boxed{ \mathsf{GCMAllocator}_{0}. }

流程：

\boxed{ \text{Goal} \rightarrow \text{Candidate Decomposition} \rightarrow \text{Safe Set} \rightarrow \text{Configuration Selection} \rightarrow \text{Resource Allocation} \rightarrow \text{Pareto Ranking} \rightarrow \text{Plan Proposal}. }

Phase C｜AI-assisted Compute Orchestrator

加入：

AI domain decomposition；
route generation；
counterfactual plans；
learned cost model；
adaptive replanning；
evidence-driven self-tuning。

但 deterministic gates 保留。

Phase D｜Native Compute Fabric

先 local machine，再 heterogeneous hardware，再 distributed systems。

Phase E｜HDUS Integration

完成：

\boxed{ \mathsf{HDUSGCMAdapter}. }

讓 HDUS 可以原生請求 GCM 計算編排，但不重新定義 GCM。

14. 下一階段十大不可破壞 Invariants

AO-01

\boxed{ \text{AI Proposal} \neq \text{Execution Authority}. }

AO-02

\boxed{ \text{Execution Authority} \neq \text{Commit Authority}. }

AO-03

\boxed{ \text{Resource Optimization} \not\Rightarrow \text{Constraint Relaxation}. }

AO-04

\boxed{ \text{Historical Performance} \not\Rightarrow \text{Semantic Admissibility}. }

AO-05

\boxed{ \text{Logical Resource Claim} \neq \text{Physical Enforcement}. }

AO-06

\boxed{ \text{GCM Orchestration} \neq \text{Kernel Scheduling}. }

AO-07

\boxed{ \text{Native Compute Fabric} \neq \text{GCM World}. }

AO-08

\boxed{ \text{HDUS Integration} \neq \text{GCM Redefinition}. }

AO-09

\boxed{ \text{Adaptive Routing} \not\Rightarrow \text{Foundation Auto-Revision}. }

AO-10

\boxed{ \text{Optimization} \neq \text{Mathematics} \neq \text{Verification}. }

15. 結論

GCM 已經完成：

\boxed{ \mathfrak P_{24}/\mathfrak P_{72} \rightarrow \text{Formal Methodology} \rightarrow \text{Runtime Architecture} \rightarrow \text{Conformance} \rightarrow \text{Executable Reference Runtime}. }

下一步應該先把 Reference Runtime 完成到真正的 Developer-Usable 100%，再建立 deterministic Compute Allocator。

之後才逐步加入 AI autonomy。

最終演進為：

\boxed{ \begin{aligned} &\text{GCM Reference Runtime}\\ \rightarrow\;&\text{Deterministic Compute Allocator}\\ \rightarrow\;&\text{AI Compute Orchestrator}\\ \rightarrow\;&\text{Native Compute Fabric}\\ \rightarrow\;&\text{HDUS Integration}. \end{aligned} }

到那時，AI 所做的不只是：

「把這個程式丟到 GPU。」

而是：

判斷這個目標應採何種計算、如何分解、在哪裡執行、使用多少解析度、哪些資料應物化、哪些部分應保持休眠、需要投入多少 CPU／GPU／NPU／memory／storage、何時切換配置，以及哪些結果具備足夠證據可以 commit。

這才是 GCM 從一套 Global Computation Methodology 逐步成為：

\boxed{ \text{AI-native Computational Operating Layer} }

的合理下一階段。

Canonical Handoff

本白皮書之後的立即工程工作固定為：

\boxed{ \textbf{先將 GCM Reference Runtime MVP v0.1 補至 Developer-Usable 100\%。} }

完成後才正式啟動：

\boxed{ \textbf{GCM Deterministic Compute Allocation Algorithm v0.1。} }

AI Orchestration、Native Compute Fabric 與 HDUS Adapter 依序建立於其上。

除非出現新的 explicit canonical revision，否則不得跳過 MVP hardening，直接讓 AI autonomy 控制尚未完成 durability、plugin、recovery 與 external-developer contract 的 Reference Runtime。