title: CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流
english_title: CPU–GPU Heterogeneous World Computation and Causal Microflows: Bounded Batching, Device Residency, Synchronization, and Render-Aware Scheduling
series: CWSR — Causal World-State Runtime
paper: 05 / 08
version: v0.1
date: 2026-10-16
author: Neo.K
ai_research_collaborator: Aletheia / GPT-6
institution: EveMissLab / 一言諾科技有限公司
status: Research Draft — Engineering Extension / Not an Independent Foundational Theory
canonical_source: UTF-8 Markdown; mathematical delimiters $...$ and $$...$$ only
language: zh-TW
predecessor: CWSR Paper 04 v0.1
next_paper: CWSR Paper 06 — 24／72 計算範式的世界狀態自適應路由

CWSR Paper 05｜CPU／GPU 異質世界計算與因果小流

從事件義務與多尺度世界狀態，到消費級顯示卡上的可驗證批次計算、記憶體駐留與渲染協調

English: CPU–GPU Heterogeneous World Computation and Causal Microflows: Bounded Batching, Device Residency, Synchronization, and Render-Aware Scheduling
系列位置： CWSR Paper 05 / 08；承接 Paper 00–04，下一篇由 Paper 06 處理 24／72 的計算形態路由。
研究身份： 單機遊戲之 CPU／GPU 異質執行方法論與規格候選；不是新的通用計算本體論，也不是宣稱 GPU 通用計算由本文發明。
主要交付： 因果小流的工作定義、合法合批規則、CPU／GPU 資料與同步契約、候選與世界提交邊界、渲染競爭治理、成本模型、參考排程及可證偽試驗規格。
本篇不交付： 已編譯執行的 shader、可商用引擎、實機 FPS／耗電改善報告，或可以跨 GPU 保證的最優排程演算法。

作者： Neo.K
機構： EveMissLab / 一言諾科技有限公司
日期： 2026-10-16
版本： v0.1

摘要

現代單機開放世界之性能壓力，並非所有問題都能靠增加記憶體、升級顯示卡或提高 CPU 時脈解決。世界中可能同時存在大量不同尺度與不同時間精度的需求：NPC 代謝與日程、群體經濟、地區物流、天氣格點、道路擁塞、人口與派系變化。若所有計算都綁在每幀物件更新，會產生多餘的檢查與資料活動；但若把所有子系統都改成事件驅動或一律丟給 GPU，也可能因資料搬移、微小 dispatch、同步、排程額外成本、數值非決定性及渲染資源競爭而更慢，甚至破壞世界因果。

CWSR Paper 00–04 分別建立系列邊界、世界邏輯狀態與執行狀態分離、義務保全的條件喚醒、宏觀—中觀—微觀跨尺度模擬，以及動靜態記憶體契約。Paper 05 在不重新定義前篇形式語義的前提下，進一步研究「如何將已被證明需要的世界工作，組成適合異質硬體的可執行單元」。本篇提出 Causal Microflow（因果小流） 的局部工程語義：具備可追溯事件來源、版本快照、讀寫集合、因果前置、模擬時間、精度界限與世界副作用契約的小型世界更新。小流不必逐一提交硬體；在不破壞依賴、身份與時間義務的條件下，可依共同 kernel 形態、資料布局、兼容的快照／規則與期限形成 Causal Microflow Batch（因果小流批次）。

本篇將 GPU 定位為世界計算候選執行者，而非僅做顯示輸出的裝置。大批弱耦合、資料平行、可規則化的世界轉移可以直接在消費級 GPU 上執行；CPU 則可承擔嚴格低延遲分支、事件路由、排程治理、複雜依賴解析與權威提交。這只是候選分工，宏觀並非 CPU 專屬，微觀亦非 GPU 專屬。當 GPU 連續消費仍有效的常駐世界資料時，可以減少 host–device 傳輸；但 shader 完成、buffer 常駐、渲染可見與世界事實提交，仍是四個不同事件。

本篇建立一套完整路徑而非單一 kernel的成本模型與保守治理策略，明列 CPU 準備、搬移、GPU 排隊、dispatch、kernel、barrier、必要 readback、驗證、提交、VRAM 容量、幀時間尾端以及模擬期限。對於 device loss、過時候選、浮點差異、競態寫入、動態 MOD 規則及高速切換等反例，提出明確拒絕、回退、降低精度或縮小適用域的條件。最後給出可供 Paper 07 原型化與 Paper 08 對照實測的型別、流程、工作負載與反駁標準；所有效能優勢仍屬可證偽假說。

關鍵詞： CWSR；Causal Microflow；GPU World Simulation；CPU–GPU Heterogeneous Computing；Compute Shader；SIMT；Batching；Sparse／Dense；RAM／VRAM；Resident State；Wake Ticket；Scale Bridge；Commit Gate；Async Compute；Frame Pacing；Data Transfer；Deterministic Replay；World-State Simulation；Consumer GPU。

0. 研究問題、範圍與非主張

0.1 源於實際的遊戲執行問題

一個 RPG 或模擬遊戲的畫面可以維持原樣，但遊戲仍可能不斷執行各種 CPU 指令、資料交換或排程。CWSR 的切入點不是武斷地說這些工作全部無用，而是要求每個系統能回答：其規則上的必需工作是什麼、何時必需、資料目前在哪裡、哪一個硬體路徑具有最低完整成本，而且不會侵犯其他系統的期限？

對一些世界子系統，答案會是 CPU 持續運算；對另一些是事件喚醒、在 CPU 合批；對另一些則可能是大型 GPU 執行批次。也可以保留成熟引擎的現有路徑，因為一個小規模既有 update() 可能比引入複雜 Runtime 更合理。

0.2 本篇的八項研究問題

RQ05-1： 什麼樣的微小狀態更新能成為有來源、依賴與提交責任的因果小流？
RQ05-2： 小流在什麼條件下可以合批、重排或預計算，而不漏掉或重複世界事件？
RQ05-3： 哪些世界工作適合消費級 GPU，哪些應留在 CPU 或混合處理？
RQ05-4： 如何讓 GPU 常駐資料真正降低搬移，而不是形成更多無必要的 VRAM 副本？
RQ05-5： GPU 工作如何保持時間、版本、同步、渲染和權威提交的一致？
RQ05-6： 當遊戲的圖形與 Compute Shader 競爭同一顆 GPU，如何以幀時間尾端及世界期限共同治理？
RQ05-7： 如何處理隨機性、浮點順序、原子操作及跨裝置精度差異？
RQ05-8： 哪些反例會證明 CWSR 的異質小流策略比成熟 CPU／GPU 基線更差？

0.3 既有技術與本篇局部創新之分界

GPU Compute、CUDA、Vulkan Compute、DirectCompute、OpenCL、SIMT、ECS、SoA、Dirty Flag、事件佇列、物理休眠、GPU 粒子模擬、prefix scan、compaction、double buffering、異步佇列與 timeline synchronization 都有成熟技術脈絡。本文不將其列為 CWSR 的原創技術。

新增的是單機世界狀態中的跨篇工程組合契約：喚醒義務如何形成 GPU 工作、跨尺度資料如何保持身份及守恆、顯存副本如何與正確版本關聯、GPU 候選如何在有限資源與期限條件下被接受或拒絕。此組合是否提供實質效能收益，必須由 Paper 08 的成熟對照組證明。

0.4 不成立的捷徑主張

本篇不聲稱：

GPU 適合所有 NPC、物理、AI 或世界事件；
將狀態搬入 VRAM 就自然更快；
一次 dispatch 必定勝過多個 CPU thread；
任意兩個同類事件都可以交換執行順序；
CPU／GPU 的浮點結果必然逐位相同；
GPU 計算完成即表示新的世界事實已提交；
可以靠 GPU barrier 取代世界版本檢查；
Consumer GPU 的 queue priority 一定可提供硬即時保證；
所有不可見區域都能無條件降精度；
24／72 格天然能預測實機最快硬體；
CWSR 已完成 Godot／EveWorld Engine 產品整合；
高 GPU 利用率本身就是成功指標。

0.5 論文完成標準

本篇完成僅表示交付可追溯的概念定義、有限條件命題、資料接口、候選排程、反例與測試設計。可執行的 Rust、WGSL／Vulkan／DirectCompute／CUDA 後端與實機 benchmark 由 Paper 07–08 負責。

1. 固定上游契約：不改變先前世界

1.1 直接繼承的五篇責任

上游	已有結論或契約	Paper 05 只能增加什麼
Paper 00	世界存在、執行、物化、觀察、渲染及提交分離	CPU／GPU 路徑與小流工作單位
Paper 01	世界狀態 ID／修訂、讀寫依賴、候選／權威、Commit Gate	GPU 候選包與完成憑據
Paper 02	Wake Ticket、義務保留、訂閱屏障、期限與合法休眠	工作分桶、合法合批、設備回退
Paper 03	Scale View、Scale Bridge、聚合／細化、時間切面與帳本	多尺度工作在同一或多個 backend 的安排
Paper 04	Memory Region Contract、ReplicaRef／generation、lease、fence、Recovery Plan	設備駐留緩衝、資料布局、渲染分額與搬移決策

1.2 世界與活動工作集記號

沿用 Paper 01–04：

W_t^{\mathrm{log}}=\langle V_t,E_t,X_t,T_t,H_t,\Gamma_t\rangle.

R_t^{\mathrm{run}}\subseteq A_t^Q\subseteq Q_t.

N_t\subseteq A_t^Q\cup P_t.

$N_t$ 是必須保留的規則義務， $P_t$ 是符合延後契約的待處理義務， $A_t^Q$ 是可取得執行階段資格的工作投影。GPU 尚在執行的工作是一類實際執行，不會因不在 CPU 執行緒上就被認為停止；工作也不得因取得一張 Wake Ticket 便自動視為已提交。

1.3 GPU Resident 不是 Canonical

沿用 Paper 04 的地址、版本與副本分離：

\mathrm{StateRef}=(\mathrm{sid},\mathrm{revision},\mathrm{schema},\mathrm{rule}).

\mathrm{ReplicaRef}=(\mathrm{StateRef},\mathrm{replica\_id},\mathrm{generation}).

即使 GPU buffer 正在保存某一批最新的世界計算結果，也不得單靠 GPU resident、kernel completed、graphics visible 或 readback finished 判斷其是否已通過 Commit Gate。

1.4 相對於先前全域計算理論的定位

GCM：全域一致與有限活動實現，作為執行安全與結構原則。
GCCF 04：可尋址狀態、選擇性物化與重建能力，作為 GPU 駐留契約上游。
GCCF 05：因果前沿與預記載；此處只用於可撤銷的預熱與預備批次。
GCCF 06：24／72 計算形態的路由文法；細部路由留給 Paper 06。
GCCFT：動態耦合拓撲、相位與計算域，作為小流並行合法性的概念來源。
GCCWT Paper 04：計算場及 CPU／GPU／Memory 異質資源激發與遷移。
GCCWT Paper 06：規劃權、執行權、修改權及資源所有權分離。

嚴格界線： 本篇提出 CausalMicroflow 型別，不聲稱 GCCF／GCCFT 原稿已有同名且同欄位的 canonical object。

2. 不同工作對 CPU／GPU 的自然適配性

2.1 先分工作性質，後分硬體

單機遊戲子系統不能按照「NPC 一律 CPU、粒子一律 GPU」或「宏觀 CPU、微觀 GPU」做固定分類。下表只是合理候選，而非測量結果。

工作	可能擅長的路徑	傾向原因	可能使選擇失效的條件
大量獨立需求值更新	GPU／SIMD CPU	共同公式、密集資料、低耦合	工作很少或每筆需立即提交
高分支劇情裁決	CPU	複雜控制流、低延遲、外部副作用	若可化為大型批次規則表則可能 GPU
城市流量格點演化	GPU／多執行緒 CPU	鄰域更新、資料規整	跨格同步過多、資料極稀疏
單一玩家即時動作裁決	CPU／GPU 適配	反應期限與引擎耦合強	回傳與提交延遲不可忽略
百萬級候選 NPC 篩選	GPU／SIMD CPU	布林遮罩、並行篩選	索引可將候選縮至極少時 GPU 多餘
複雜任務鏈／關係圖遍歷	CPU／混合	分支與間接存取多	大型規則化圖演算法仍可 GPU
大範圍天氣／擴散網格	GPU	大量相似局部更新	模型精度、顯存壓力、渲染競爭
對話、外交決策、規則副作用	CPU／專用推論後端	非純數值、需可追蹤語義	批量推論可使用 GPU，但另需資源預算
跨尺度聚合與統計	GPU／CPU	reduce、scan、分區統計	結果量小、排序需精確、資料搬移大
UI 投影與世界提交	CPU 控制＋GPU 呈現	權威決策與輸出責任分離	某些結果可 device resident，不等於直接 commit

2.2 GPU 的平行不是免費

GPU 的性能通常依賴足夠大的同構工作量、適合記憶體存取的布局、可承受的分支分歧和同步成本。若將大量互相依賴、資料零碎、每筆都要 CPU 認可的任務拆為數千個小型 dispatch，可能只得到更高的開銷。

2.3 消費級顯示卡的硬體限制

典型單機 PC 的 GPU 同時負責畫面、桌面合成、影音與世界 Compute 工作。應實際觀察：

VRAM 容量以及驅動和遊戲渲染已保留的部分；
GPU memory bandwidth、cache 與 host–device 連結；
compute queue 可用性、命令提交與執行排程限制；
多隊列是否真的並行，而非 API 上宣告不同 queue 即代表硬體同時執行；
shader 編譯、驅動差異、裝置重置與熱節流；
GPU world compute 對玩家操作反應及 p99 frame time 的影響。

不能拿「顯卡有很多 TFLOPS」直接推算每個遊戲事件更新速度；記憶體、控制流與完成證據可能主導成本。

2.4 不把傳統計算判為錯誤

固定時間步進、主循環、ECS Job System、成熟 GPU 粒子系統與原有遊戲物理引擎仍有適用域。CWSR 的執行規劃是疊加與局部替換，不是要求每個遊戲重寫所有演算法。

3. 因果小流：定義及不可偷換的含義

3.1 為什麼不直接稱作 Event 或 GPU Kernel？

事件是某個已發生或應當處理的事實／通知；工作單元是為履行事件義務而需要的計算；kernel 是某種執行實現。這三者可能不是一對一關係。一個事件可能觸發多個小流；一個小流可能需要 CPU 判斷與 GPU 子程序；同一 kernel 可以承擔許多小流。

因此 Causal Microflow 不等於 Event、不等於 Coroutine、不等於 GPU Dispatch，也不等於一筆新的世界事實。

3.2 工作性定義

對一個邏輯小流 $m$ ，提出：

m=\langle id,c,w,\sigma,rd,wr,g,\theta,\pi,\epsilon,\alpha,\delta\rangle.

其欄位解釋如下：

記號	工作欄位	作用
$id$	Microflow ID	防止同一義務被重複記帳
$c$	Cause／Wake Ticket	已驗證事件來源與因果鏈
$w$	World Snapshot	世界版本、規則版本與執行 epoch
$\sigma$	Scale Context	Macro／Meso／Micro 與尺度憑據
$rd$	Read Set	必需資料與版本
$wr$	Write Intent	候選修改範圍，並非既有修改權
$g$	Guard	執行必要條件及失效判準
$\theta$	Time Contract	模擬時間、期限與必要排序
$\pi$	Compute Shape	稠密度、資料形狀、可並行與同步特徵
$\epsilon$	Precision Contract	精確／有界近似／統計契約
$\alpha$	Authority／Effect	權限、副作用與提交要求
$\delta$	Recovery／Fallback	失敗、取消與重試方案

小流是局部工作描述符；不要求每項都在每筆記憶體中重複儲存，可共用 typed batch metadata 或間接引用。若治理 metadata 比工作本身更昂貴，可降低粒度，將一整個區域視為一個小流。

3.3 因果性不能由相鄰時間推論

兩個資料更新在同一幀發生，不能因此宣稱存在因果邊。Cause 必須指向規則依賴、經證實的事件、時間義務或明示的查詢／物化請求。統計相關與預取預測只可當路由提示，不得升格為權威依賴。

3.4 微觀尺度不等於小流規模

一個宏觀經濟計算可以分成許多小流，微觀碰撞也可能整批形成一個較大計算區域。Microflow 中的 micro 是可組合的工作粒度，不是 Paper 03 的 Micro 世界尺度。

3.5 小流生命週期

Wake Ticket / valid demand / continuous contract
    -> Microflow formed
    -> dependency and deadline ready
    -> optional coalescing and resource plan
    -> snapshot acquisition and buffer leases
    -> backend admission
    -> host/device execution
    -> completion and candidate receipt
    -> invariant/precision/version verification
    -> Commit Gate or typed rejection
    -> downstream wake propagation or safe recycle

若某階段受阻，保留 Pending 及截止期限；不能簡化為「GPU 太忙，所以這張 Ticket 消失」。

4. 因果圖與合法執行重排

4.1 Microflow Dependency Graph

令 $M_t$ 為某時間窗的候選小流集合， $D_t^M$ 為經規則證實的必要先後關係：

G_t^M=(M_t,D_t^M).

若 $m_i$ 的輸出決定 $m_j$ 的輸入、Guard、提交合法性或截止期限判定，則不能簡單以兩者都「同一種 kernel」為由重新排序。

4.2 可並行的充分條件候選

兩個小流 $m_i,m_j$ 在指定隔離語義下可以形成互不干擾批次的一組保守充分條件為：

wr_i\cap(rd_j\cup wr_j)=\varnothing,

wr_j\cap(rd_i\cup wr_i)=\varnothing.

另須同時具備相容時間契約、相容輸入快照、不衝突權限與可合法合併的外部副作用。這是便於實作的保守充分條件，不是判定所有可平行系統的必要條件。若更新是已證明具備交換律與結合律的規則，可另由正式 Reduction Contract 放寬衝突判準。

4.3 Snapshot Parallel 與 Sequential Semantics

同一批工作若共同從 $W^{(k)}$ 讀取並提出候選值：

C_i=f_i(W^{(k)}),

並不表示任意合併結果都與依序執行相同。需確定其 write intent 不互相覆蓋，或使用版本明確、合併律已核對的 reducer。

4.4 衝突圖、因果邊及 kernel 同構是三個不同條件

因果邊： 是否需要先執行某工作才能正確執行下一工作。
寫入衝突： 是否會對相同權威或候選位置提出不相容更新。
計算形態兼容： 是否可使用同一個 kernel、布局與裝置契約。

只有第三項相同，無法推出第一項與第二項可忽略。

4.5 依賴環與跨階段收斂

對強連通分量（SCC）與迭代方程，不能將彼此依賴的工作全部當作任意順序的獨立 thread。可使用迭代 kernel、barrier 分階段、全量固定步或求解器，但需有明確收斂條件與精度／期限政策。不同 GPU dispatch 之間的排序及 memory visibility 應由實際後端同步契約保障。

4.6 External Effect 不得在 GPU 先行提交

例如支付、存檔、成就、任務宣告、戰鬥掉落與 UI 推送具有世界外或不可逆副作用。小流可以在 GPU 計算其候選條件，但實際不可逆副作用必須在經驗證的世界提交後由具權限的系統執行，並應有去重及可重播設計。

5. 從小流形成合法 GPU 批次

5.1 為什麼要合批

若存在 $n$ 個極小事件，GPU 路徑的 dispatch、同步及資料建構成本可能遠高於數值計算本身。若先將它們聚合成少量具有共同 shape 的工作，固定開銷有可能被攤薄，同時讓 GPU threads 具備較充分的工作量。

因果小流的核心不是一條小流派一個 kernel，而是小流具有語義 ID，實際 dispatch 可以承載多個兼容 ID。

5.2 Batch Descriptor

定義候選批次：

B=\langle bid,\mathcal M,\omega,\kappa,\lambda,\theta_B,\epsilon_B,\beta_B,\nu_B\rangle.

其中：

$bid$ ：批次唯一 ID；
$\mathcal M$ ：包含的小流 ID 與去重政策；
$\omega$ ：快照／規則／schema／epoch 的兼容證據；
$\kappa$ ：kernel family 與資料形態；
$\lambda$ ：輸入／輸出 ReplicaRef、layout、buffer lease、generation；
$\theta_B$ ：最早可執行時間與最緊迫 deadline；
$\epsilon_B$ ：精度與 reducer 契約；
$\beta_B$ ：RAM／VRAM／GPU 時間／渲染餘裕的上界；
$\nu_B$ ：版本驗證與錯誤回退計畫。

5.3 合批最低合法性檢查

每張 Wake Ticket 已被承認且尚未履行或合法折疊。
若有依賴先後，需切成可執行前沿，不可越過前置條件。
所需的世界快照、規則、schema 和尺度版本相容。
read/write hazard 有策略（隔離、分區、雙緩衝或證明合法的 reduce）。
批次的等待時間不超過任何不可延後義務的期限。
各小流精度與 RNG 政策不因合批被偷換。
物化資源、lease、VRAM guard 與 in-flight buffer 安全。
執行失敗後有可恢復且不漏 Ticket 的路徑。
副作用只在合法 Commit 後觸發。
被取代或合併的小流需能解釋其 duty 是否已涵蓋。

5.4 Compatibility Key 只是初步分桶

可用以下分桶鍵產生候選：

(kernel_family,
 rule_revision,
 schema_revision,
 scale_policy,
 precision_class,
 layout_class,
 time_epoch,
 device_capability_class)

但同鍵不代表無衝突。真正合批仍須依讀寫集合、必要因果邊與 deadline 核查。

5.5 批次等候窗口與期限

令 $d_i$ 為小流最遲可合法完成時間， $a_i$ 為其 ready 時間。批次等待窗口不能被設定成固定的「等到 GPU 夠滿」。至少須有：

\mathrm{finishBound}(B)\leq\min_{i\in B}d_i,

並在 finishBound 未能保守估計時採取縮小 batch、CPU route 或可證明安全的 Pending；若期限已經不可滿足，需記錄明確 failure，而非吞掉事件。

5.6 合批不是無限擴大

批次太大也可能增加 GPU 尾延遲、渲染飢餓、VRAM 壓力、取消浪費及 stale snapshot 的拒絕率。應同時有 min_efficient_size 的軟提示及 max_batch_duration、max_inflight_bytes、max_deadline_slack 的硬性／契約上限。

5.7 弱耦合分區與局部前沿

當世界事件圖龐大，可先依 Rule Domain、Scale Region、寫入衝突及時間區間形成工作分區，再就當前 ready frontier 做批次。若局部區域的一個 update 會使全球所有人都改變，圖可能不存在有效稀疏分界；應允許直接採用大型 kernel 或傳統固定步，不強求「小流」之名。

5.8 Coalesce 需要明示語義

純刷新 UI 的多次同類型失效可能只需最後修訂；人口遷移與金錢交易則未必可把十次事件變成一次更新。合併操作必須標記：

LatestWins：只有確實具覆蓋語義才可使用；
Accumulate：需有可證明的結合與去重規則；
RecomputeFromSnapshot：以最終快照重算派生值，僅限純函式且依賴齊全；
OrderedReplay：涉及歷史順序與副作用，必須保留事件序列；
NotCoalescible：不得合併。

特別注意： 稅收、傷害、庫存、計時與 RNG 事件即使數值看似可相加，也可能因上限、觸發點、次序或離散化政策而不具合法的簡單合併律。

6. 世界狀態的設備駐留：哪些資料留在哪裡？

6.1 World Authority 與 Device Residency 的兩軸設計

物理資料可以放在 RAM、VRAM、儲存裝置或合法可重建路徑，世界權威卻不能以裝置位置決定。應分別追蹤：

Logical validity： 內容是否符合某世界修訂及其依賴。
Physical residency： 哪個 tier 持有哪個 generation 的哪份 bytes。
Execution readiness： 此副本是否已滿足目前工作所需的裝置存取及同步。
Commit eligibility： 候選輸出是否可提交到權威世界版本。

四者不能合併成一個 dirty 布林旗標。

6.2 版本化 Input Buffer

GPU job 必須由明確的 WorldSnapshotRef、StateRef、ReplicaRef 與 lease 建構輸入。buffer 可共用，但若世界在 dispatch 後發生改變，舊 buffer 只能是舊快照的合法副本，不得自動被視為新世界資料。

6.3 CPU RAM 與 VRAM 的三種典型配置

Host-first： 主要 state 在 CPU 記憶體，GPU 工作需要時上傳或使用可用的共享路徑；適合事件稀疏與複雜分支。

Device-resident： 大型數值狀態在 GPU 長期保持合法副本，允許多次 device-side 更新與聚合；適合高重用、規則化與頻繁批次。

Dual representation： CPU 保存權威索引、身份、事件帳本與小型關鍵摘要，GPU 保持密集數值陣列及其版本鏡像。這不表示物理上必須保留所有資料兩份；可按必要欄位與恢復政策配置。

6.4 常駐資料不是永久豁免回收

即使維持 GPU resident 能節省搬運，只要 Render 需求增加、VRAM 緊張或版本長期無效，合法副本可能被壓縮、下放或釋放。回收必須符合 Paper 04 的 lease、fence、可恢復性與因果義務條件。

6.5 與 Paper 03 的 Scale View 對應

宏觀人口摘要可能只需要一組向量；中觀城市可能擁有按產業分組的矩陣；微觀居民可能是具名 ID 與事件日誌。無論載入何種資料，GPU 工作不得從宏觀人口數隨意「製造出」真實具名居民的過去歷史。細化必須使用已有 anchors、refinement policy 與可驗證憑據。

6.6 GPU 地址不是長期世界 ID

GPU buffer 的 binding、offset 或 descriptor index 是實體執行資訊。擴容、compact、回收及 heap relocation 後皆可能改變；要以 Paper 04 的世代 handle 檢查是否仍指向原本所允許的 StateRef。

6.7 VRAM 需求估計的最低責任

對批次 $B$ ，可定義保守估計：

M_B=M_{in}+M_{out}+M_{scratch}+M_{staging}+M_{sync}+M_{guard}.

in/out 可能實際共用部分實體資源，不應重複計數；但若後端需要額外不可見配置、alignment、copy 或 debug layer，也不能以純 payload bytes 低估真實峰值。用 allocation trace 和 device telemetry 校準估計。

6.8 動靜態宣告的使用方式

在遊戲載入與區域進入階段，可以宣告：

World Region: city-economy
  immutable rule table: versioned, sharable, evictable
  mutable city aggregates: bounded, revisable, recoverable
  in-flight batch scratch: transient, fence-governed
  event/commit ledger: durable, never silently discarded
  renderer reservation: external contention-sensitive budget
  future expansion: allowed only after typed capacity admission

預宣告的是資源種類、容量政策、生命週期與額外增長規則，不是啟動時就強制佔滿 RAM／VRAM。

7. GPU 資料布局：避免把狀態機原封不動搬上去

7.1 AoS、SoA 與 Hybrid Layout

CPU 物件導向遊戲可以將一名 NPC 的所有欄位放在一個複合物件中，但 GPU 的大量簡單計算通常需要對同類欄位做規整訪問。可比較：

AoS（Array of Structures）： 便利個體存取，跨欄位的局部性可能較好；
SoA（Structure of Arrays）： 便利大批同欄位計算及合併存取；
Hybrid／AoSoA： 按群組與 device workgroup 特徵折衷。

選擇布局需基於事件稀疏度、規則變化、實際 cache hit 與傳輸量，而不是一律規定 SoA 必然最快。

7.2 稀疏更新與 Dense Scan 的取捨

若只有很少 NPC 在世界時間內受影響，可用活躍 ID 清單更新；若幾乎每名 NPC 的飢餓值都需每步推進，掃描整個 dense array 可能更快。真正的成本不是單看被更新人數，而要計算建立 active list、排序、間接存取與重構 scatter 的成本。

7.3 Active-ID Compaction

候選流程可為：

validated wake flags / region dirty masks
    -> build active predicate
    -> optional prefix scan / compact
    -> stable or unordered active-id list
    -> GPU kernel on active entries
    -> candidate outputs / reductions

若 active list 在 CPU 上已存在，將它再次下載、重新排序後上傳不一定合理。當同一批 GPU 結果能直接產生後續 GPU active list，可避免不必要 readback；但仍受 device-side hazard 與世界義務驗證約束。

7.4 分支分歧的治理

角色的職業、狀態、地區規則差異可能使 GPU threads 在同一 kernel 內大量走不同分支。可按規則族、地理域、行為型態分桶；但每次分桶都可能引入掃描與排序成本。只有實測收益足夠，才應進行細分。

7.5 Indirection Table 與穩定身份

裝置側資料列的 slot 不是 NPC Identity。需要維護 StableEntityID -> slot 及其 generation／schema；經 compact 後，所有引用必須依正確規則更新。若缺乏 generation，就可能在實體 slot 重用後錯誤地將舊事件套用到新 NPC。

7.6 重複寫入與 Reduction

GPU 多 thread 對同一市場庫存寫入時，不可依賴未定義的資料競態。可以選擇：

先 per-entity 計算，再以確定規則合併；
透過分桶令每個輸出只由一個 kernel invocation 寫入；
使用後端支持的 atomic，但另行處理非決定性及精度；
對具有歷史順序義務的更新，回到排序事件重播或 CPU 處理。

選擇方案後須測試不同 workgroup size、執行次序與設備上的語義，而不是只在一張 GPU 成功便認為具備跨裝置等價。

7.7 Ring Buffers 與版本世代

假設 $b_0,b_1,b_2$ 為 staging／result ring。新 epoch 不可在舊 job 尚使用同一 generation 時直接覆寫記憶體。要等待完成訊號、持有 lease 或使用新 generation；設備完成表示 buffer 可以依對應規則回收，不表示上面的世界結果已提交。

7.8 中間資料的最小物化

Device-side scan、filter、reduce 產生的暫存不一定需要常態複製回 CPU。若後續 kernel 可直接消費相同合法版本與 layout，可保留在 GPU；若 CPU 的世界裁決只需一個摘要，也只取回該摘要及證據，而非整張陣列。

但是只讀回摘要只有在該摘要對 Commit Gate 的必要驗證足夠時才合法。如果 Commit 需要逐個實體的精確新值、歷史或完整不變量檢查，則仍需提供對應資料或可信的可驗證設備側檢查流程。

8. CPU／GPU 執行路徑與同步責任

8.1 GPU 工作管線的完整階段

Ready Microflow Frontier
  -> legal grouping / read-write conflict filter
  -> versioned input snapshot + leases
  -> materialization / device capability check
  -> CPU pack / device-side compaction (as appropriate)
  -> upload / descriptor update / queue submission
  -> compute dispatch(es)
  -> device barriers / signal completion
  -> optional device-side validate / dependent dispatch
  -> selected readback / completion receipt
  -> Commit Gate checks / canonical world revision
  -> notify subscriptions / release buffers after fences

因果路徑內可能包含多個 CPU／GPU 交替階段；GPU 不是一個不可觀察、不可撤銷的黑盒成功訊號。

8.2 三種不同「完成」

Command submitted： CPU 已將工作提交給後端，不等於 GPU 已開始。
Device completed： 裝置聲稱命令已完成，並在相應同步條件下可觀察輸出。
World committed： 驗證與版本條件通過，權威世界才接受候選變化。

需另行區分 graphics presentation（畫面實際呈現）。四種事件可有不同時間順序和延遲。

8.3 正確使用 barrier、fence 與 queue dependency

In-queue ordering 應依 Vulkan／D3D12／CUDA／其他後端的實際記憶體模型；
Resource barrier 處理讀寫 hazard、可見性、布局或使用狀態的適當轉換；
Fence／timeline signal 提供非同步完成觀測及生命週期保證；
Queue ownership transfer 在需要時確保 compute／graphics queue 間的合法存取；
Host readback 可能還需要 host visibility、mapping 與同步。

不能使用一個名為 wait() 的任意函式就假定以上全部成立。具體 API 必須由 Paper 07 後端 adapter 列出，Paper 08 再做 GPU validation layer 與競態測試。

8.4 CPU 與 GPU 同時寫世界資料的危險

如果 CPU 已把市場稅率由 $r_1$ 修改為 $r_2$ ，但 GPU 仍拿舊 $r_1$ 計算交易稅，不能在完成後直接寫回一個「最新稅收」。候選需綁定 rule_revision 與 world snapshot；提交時檢查讀取版本，過期則重新計算或走已證明合法的 rebase。

8.5 精細分段的同步風險

假設每個 NPC 都立即要求一次 GPU 完成、readback 和 CPU commit，往返成本可能幾乎吞噬全部收益。必須衡量可合法延後的期限，並盡量讓同一版本前沿的一批結果共同提交；若立即回應是硬性玩法需求，應考慮 CPU 路徑。

8.6 不必要的全域同步

同一 GPU 上兩批互不干擾的資料更新，不應因方便而每次執行完整裝置 idle；但也不可憑直覺拿掉必要的 buffer hazard barrier。最佳化只在實際後端提供足夠可見性與依賴證據時成立。

8.7 過時執行的處理

若批次讀取的世界版本已變：

對可純重算的數值派生值，可拒絕後重新安排；
對版本無關的合法聚合，可走有證據的縮減或合併；
對不可重播的外部副作用候選，必須禁止事先輸出；
對超期限工作，需觸發安全回退或明確期限違反。

不可採用「GPU 都算完了就先收下」的策略。

9. Device-side 世界小流：不需要每段都回 CPU

9.1 Device Microflow Chain

若批次 $B_1,B_2,B_3$ 可以形成合法資料依賴：

B_1\rightarrow B_2\rightarrow B_3,

且它們使用兼容、版本明確的 device buffers，則可以在 GPU 上依序執行與交換結果，中間不必每段 CPU readback。這是 GPU 計算可真正服務世界模擬的重要途徑之一。

9.2 連續處理不等於任意提前世界時間

Device-side chain 只表示硬體資料在合法依賴下流動，不意味著可提前提交尚未到達的遊戲時刻，或越過必須由玩家輸入、腳本事件、時間期限或劇情裁決決定的因果分支。

9.3 Candidate Reduction

裝置端可以將大量居民的食品需求轉換為城市層級摘要：

D_{city}=\sum_{i\in\mathcal P_{city}}d_i.

但若 $d_i$ 由不同 NPC 實際交易構成，摘要仍須符合 Paper 03 的身份、帳本與去重規則。若先把人口總需求誤認為已成交商品，會直接創造不存在的資產流。

9.4 Device-side Validation 的適用範圍

可以在 GPU 上檢查局部範圍、有限性、非負約束、守恆殘差或數值精度，輸出 flags、summary 和候選證據。Commit Gate 可以使用這些設備側結果，但不得假定硬體不會出錯或 GPU 回傳的少量標誌天然證明所有世界語義。若需要更高可信度，應採抽樣覆核、獨立重算或 CPU 上的確定性驗證。

9.5 GPU 計算的「世界小流」不是 GPU 渲染資料流

GPU 世界狀態可間接提供渲染需要的 transform、天氣參數、群體密度或地區統計，但不等於每個 buffer 都可直接作為 canonical source。Graphics 只消費對其而言版本與時間足夠新的觀察投影；真正的世界修改仍需權威提交規則。

9.6 若不需要 CPU readback，怎麼提交？

提出兩種明確方案：

A — Host-mediated candidate： GPU 輸出經同步的完整或必要摘要／差分至 CPU，由 CPU Commit Gate 驗證後更新權威 state；實作簡單但可能有 readback 成本。

B — Device-resident candidate with host-authorized publish： GPU 輸出停留在版本化、不可被未授權覆寫的設備資源，由 Commit Gate 在取得必要證據後發佈其權威描述符或下一個版本的不可變引用。此時提交的是經驗證的狀態綁定關係，不是 CPU 任意改寫 VRAM bytes；仍需處理 durable history、device loss、回讀要求、依賴新鮮度及事件去重。

B 不是自動可行：若引擎存檔、腳本、任務裁決或確定性重播需要 CPU 端完整狀態，最終仍需適當資料轉移、紀錄或重建策略。

9.7 裝置側推演與玩家可見世界

畫面連續不代表世界權威每個顯示幀都必須提交一次。例如渲染可以在兩個合法物理狀態間插值；反過來世界狀態也可能在無任何畫面變化時完成一次經濟結算。這是 Paper 00 的觀察／計算分離，不是獨立的新渲染理論。

10. Render-Aware GPU Governance：同一張顯卡不等於同一種工作

10.1 渲染和世界 Compute 會競爭

當遊戲畫面負擔提高，世界 Compute 會競爭 VRAM、GPU execution lanes、cache、頻寬、功率、散熱及排程時間。平均 FPS 上升不代表玩家體感必然改善；p95／p99 frame time、輸入反應和抖動都可能變差。

10.2 世界工作不能假設固定 VRAM 剩餘

可把可用預算視為時間變化的保守值：

B_{world}^{gpu}(t)\leq B_{device}^{usable}(t)-B_{render}^{reserve}(t)-B_{safety}(t).

這是治理預算與策略上限，不是作業系統保證實體 GPU 調度精確符合該式。若實際應用回報可用容量不可信或無法強制隔離，只能使用保守限流、觀察或禁用高風險路徑。

10.3 時間預算與幀時間

假設畫面期望顯示週期為 $T_f$ 、渲染關鍵路徑估計為 $T_r$ 、必要安全保留為 $T_s$ ，世界 compute 的軟性時間餘裕可表示為：

H_f=\max(0,T_f-T_r-T_s).

$H_f$ 不是 GPU world compute 必定可用的真實執行時槽，因為佇列、依賴和資源競爭並非單純相加，可能重疊也可能串行。因此實際路由須以觀測的 frame-time 分布與設備佇列反饋校準，不能把這個近似當硬即時證明。

10.4 世界期限與渲染期限是雙重約束

例如畫面須每隔固定時間呈現，但城市市場結算只要在遊戲日結束前完成。此時可以批次、分段、低優先執行世界計算；然而若一個戰鬥判定需要在當前操作回合內完成，不能為了 FPS 而無限推遲。

10.5 三級 Render Pressure 回應候選

Normal： 在容量與期限允許下採通常 GPU 批次；
Elevated： 縮小 dispatch、取消投機預熱、減少並行 scratch、優先維持必要世界義務；
Critical： 將可合法延期的工作轉 Pending、可轉移的高分支／小工作移回 CPU；若仍無法保證必要期限，啟用明示 fallback 或回報資源不足。

三級只是範例，不是硬性標準；門檻必須由實測及遊戲需求設定，並防止壓力狀態短時間來回切換。

10.6 Async Compute 不必然可與 Render 完美並行

GPU 多 queue 的名義並行不保證物理上擁有獨立算力或可被任意搶佔。不同架構可能有不同 queue scheduler、barrier、driver 與 power 管理。應檢查實際 overlap 和 frame-time 尾端；若兩種工作產生顯著互擾，就應降低同時提交量或改排程。

10.7 互動與模擬的品質公平

降低世界工作優先序不應永久讓遠方世界停止演化。應建立 aging、世界 deadline、群組最低服務及逾期報告；渲染性能與世界一致性都屬於玩家體驗，不是只要 FPS 高就能忽略世界模擬錯誤。

10.8 計算與繪圖不必二擇一

當 GPU 用於世界 Compute 時，仍可保留傳統渲染；世界結果可能節省 CPU 並讓更精細圖像成為可能，也可能在某種負載下反而擠壓畫面預算。最終是權衡與測量，不能從「GPU 能做 AI 推論」直接推導「遊戲 GPU 世界模擬沒有代價」。

11. 完整路徑成本模型：什麼時候 GPU 真的比較便宜？

11.1 不比較裸 kernel 與整個 CPU 函式

對同一組遵守相同語義契約的工作 $B$ ，定義 CPU 完整路徑：

T_C(B)=T_{route,C}+T_{prepare,C}+T_{execute,C}+T_{verify,C}+T_{commit,C}.

GPU 完整路徑：

\begin{aligned} T_G(B)={}&T_{route,G}+T_{prepare,G}+T_{upload,G}\\ &+T_{queue,G}+T_{dispatch,G}+T_{kernel,G}\\ &+T_{sync,G}+T_{readback,G}+T_{verify,G}+T_{commit,G}. \end{aligned}

上式是成本拆項清單，不是宣稱所有階段必然串行或必須各自獨立支出。實際批次延遲須由依賴 DAG 的 critical path 求得，而非把能重疊的時間錯誤地全部相加。

11.2 Device-resident 能消除哪些成本？

若輸入已以正確版本常駐 GPU，可減少或消除該批的輸入 upload；若下一階段仍使用裝置端輸出，可不在中間做 readback。但無法因此省略必要同步、候選驗證、GPU queue wait、版本檢查或提交權限。

11.3 簡化 crossover 分析

僅為建立可檢驗假說，假設同質工作數 $n$ 、每件 CPU 增量成本 $c_C$ 、GPU 增量成本 $c_G$ ，以及 GPU 額外固定成本 $K_G$ 、CPU 額外固定成本 $K_C$ ：

T_C(n)=K_C+n c_C,

T_G(n)=K_G+n c_G.

若 $c_C>c_G$ 且 $K_G>K_C$ ，GPU 可能較快的理想門檻為：

n>\frac{K_G-K_C}{c_C-c_G}.

這不是可套用於任意 GPU 的通則。 $c_G$ 可能因尺寸、稠密度、分支、記憶體頻寬與競爭非線性變動； $K_G$ 亦包含動態 queue wait、驗證與傳輸。實際 cutoff 必須由 profiler 估計、並針對硬體／遊戲規則版本化。

11.4 吞吐量與完成期限的區別

一個 GPU 批次總吞吐量很高，仍可能因等待合批或 queue backlog 讓最早的事件超過 deadline。因此決策需同時量測 throughput、latency、tail latency 及 deadline miss rate，不能只報每秒更新數。

11.5 以多維成本選擇，而非只問快慢

對候選路由 $r$ ，至少觀察：

J(r)=\langle L,P_{99},M_R,M_V,X,E,Q,F\rangle.

其中 $L$ 表示世界工作的關鍵路徑延遲、 $P_{99}$ 表示畫面／互動尾端、 $M_R$ 與 $M_V$ 為 RAM／VRAM 壓力、 $X$ 為傳輸、 $E$ 為能耗、 $Q$ 為誤差或品質、 $F$ 為失敗／恢復風險。各項有不同尺度、部分需方向翻轉；此式只是多目標記錄向量，不宣稱能直接作無單位加總。

11.6 Hard Constraints 先於路由優化

若某路由無法滿足世界版本、資料安全、必要精度、期限與硬容量契約，即使平均 GPU kernel 快十倍，也不應進入可行集合。可行集合建立之後，才依 Pareto、成本估計或 policy 選擇；此程序延伸 GCM Phase B 的 constrained allocation，但不重定義 GCM 原算法。

11.7 切換成本與抖動

CPU／GPU 兩條路徑的效益差很小時，頻繁切換會引入 buffer 重配、shader warming、狀態複製及測量噪音。可以建立滯後與最短持續時間，但若出現裝置錯誤或期限迫近，仍需允許安全緊急回退。

11.8 計算可能真的需要連續運行

高頻碰撞、音訊即時路徑與特定物理積分依契約要求每步運算，則不必硬塞入事件小流排程；可以直接作為大型持續執行域，並在其他子系統使用選擇性小流。

12. 世界時間與 GPU 延遲完成

12.1 Simulation Clock 不等於 Render Clock

世界時刻 $t_s$ 、CPU 單調時間 $t_m$ 與呈現時間 $t_p$ 應分離。某個 GPU 工作可以在現實時間稍後完成，但其結果描述的是明確的模擬時間窗及輸入版本；不可因 completion 到達較晚便把其事件時間直接改成當前畫面時間。

12.2 Epoch Batch 與時序憑據

每個批次應標記 (world_revision, simulation_epoch, time_window, event_frontier, rule_version)，並明示跨時間窗的必要事件是否已完成。結果提交前仍須進行 Paper 02–03 的期限與因果切面核對。

12.3 時間快進的 GPU 機會

玩家快速旅行時，某些世界經濟、群體數值或氣候網格可合批多個合法世界步；但是有分支、互動、隨機門檻及關鍵 NPC 歷史的模擬，可能不能簡單從 $t$ 一步跳到 $t+k$ 。必須先由 Paper 03 的合法聚合／細化與 Paper 02 的時間事件前沿判定，才能安排 GPU kernel。

12.4 事件期限比 GPU Batch 更高位

若世界規則要求在 $t+\Delta$ 前完成一個事件，GPU queue wait、shader compile、buffer recovery、結果驗證及 Commit 都是期限的成本。若時間不足，不得只計算 GPU kernel 預估時間並宣布可行。

12.5 暫停遊戲的不同政策

暫停模擬時鐘：世界義務不自動推進，render 可以持續。
暫停畫面但世界時鐘繼續：世界相關 due events 仍須處理。
戰鬥慢動作：不同子系統可能具有不同 clock contract。
從讀檔狀態恢復：in-flight 的舊 GPU 批次不得不經 epoch 檢查寫入新世界。

12.6 截止期限與回放一致性

大量任務雖能並行執行，其可見提交順序可能需要符合先前已提交事件的因果偏序。若任意採 GPU 完成順序當世界順序，會造成不可重現的劇情或存檔結果；需明確定義 deterministic order 或合法的 partial-order equivalence。

13. 隨機、浮點與跨裝置可重現性

13.1 三種不同等價政策

Bitwise Exact： 逐位等價，用於要求嚴格重播、存檔確定性或權威規則的子系統；可選用整數／定點、固定約簡順序與一致算法，仍須確認跨後端語義。

Bounded Numerical Equivalence： 指定容許誤差與保留不變量，適合有界物理或連續場近似；不可用浮點容差掩飾身份、資產與劇情違規。

Statistical Equivalence： 指定隨機過程及可檢驗統計指標，適合某些隨機群體模擬；單次結果不必相同，但樣本分布、可重播來源及重要事件義務仍受約束。

13.2 GPU 不保證浮點加總順序

平行 reduction 的加法順序不同時，浮點舍入可能改變。GPU 原子加法及 workgroup 排程可能導致跨次執行的非逐位一致。若此結果進一步驅動閾值事件（例如城市破產），微小偏差可能變成世界分支差異。

13.3 決定性計算策略候選

對金錢與不可分割存量使用適當範圍的整數或定點表示；
定義固定 reduction tree 或合法的精確累加策略；
以排序、分區或兩段式更新解決同一目標的多重寫入；
把浮點近似限定於允許誤差的視圖或預測層；
對影響世界分支的閾值重新採權威演算法核對。

以上不代表任一 GPU 天然支持所有精確運算或每種固定點範圍皆安全，必須測試 overflow、NaN、Inf、underflow、溢位界限與跨裝置特徵。

13.4 RNG 不依賴線程執行順序

可考慮以不可混淆的 world_seed + logical_entity_id + rule_id + event_id + time_index 作為 counter-based RNG 的邏輯索引，避免工作重排後 RNG 消耗序列改變；真正設計仍須檢查碰撞、序列空間、隨機性品質與 version stability。

13.5 預測性 preload 不是 RNG 事件消費

為了提升 GPU 成功率提前載入或演算候選，不得直接消耗 canonical 世界 RNG 次序或提前定案未來事件。若投機推演使用 RNG，須在獨立命名空間且可棄置；只有合法提交的因果事件才能影響權威隨機歷史。

13.6 關鍵決策只允許已認證的數值語義

一個 NPC 是否死亡、商品庫存是否為負、任務是否完成、世界金幣是否被重複創造等，不能只因候選來自 GPU 便接受；要在相應 precise rule 或不變量契約下驗證。

13.7 Driver／硬體差異需作為測試維度

不同廠商與不同型號 GPU 可能具有不同的運算特性。對跨平台遊戲，不應因單一開發者 GPU 可重播，就宣稱所有玩家機器具備相同的 floating-point path 或 GPU scheduler 行為。

14. 故障、取消、設備失聯與恢復

14.1 GPU Compute 可能失敗

應預設 GPU device loss、shader 編譯失敗、backend feature 不支援、VRAM allocation 失敗、TDR／驅動重置、資料上傳錯誤、queue timeout 或 device validation failure 都可能發生。不要把它們視為在商用遊戲中不可能出現的例外。

14.2 一張 Ticket 的義務不隨 GPU 失敗而消失

當裝置工作失敗或被取消，對應的合法 Wake Ticket 與未履行義務必須保留或重新入隊。若其原始輸入世界快照仍可恢復，才可安全重跑；若快照失效，需重新確認依賴與規則，不能盲目重放舊輸出。

14.3 Device Loss 與持久世界歷史

若 GPU 是某狀態唯一的實體載體，突然失去裝置就可能使不可恢復事實消失。Paper 04 的 Recovery Plan 因此必須在選擇 Device-resident policy 時就建立。重要的權威事件帳本、身份及可恢復快照應由持久化策略保護，不能將不可恢復資料只放在 VRAM。

14.4 雙緩衝取消及過時輸出

已 dispatch 的 GPU 工作未必能被無成本即刻取消。可將其輸出標示為待驗證或過時候選，即使之後完成也不得提交；但只有裝置完成證據足夠時才能回收輸入／輸出 buffer 或重用同一配置世代。

14.5 腐敗結果與 Validation Failure

候選若違反有限值範圍、資產守恆、跨尺度邊界帳本、世界時間單調性或 precision contract，應進入 RejectedCandidate，附原因與 provenance。不得把 GPU 結果不合理地歸咎於「畫面還能玩就算通過」。

14.6 從 GPU 退回 CPU 的前提

CPU fallback 要能履行相同的世界規則、修訂、事件去重及精度契約，才是真正的替代路徑。若 CPU 在 Deadline 內同樣不可能完成，系統須明確報告超載、啟用遊戲設計允許的世界降級，或停止不合法的提交；不能默默跳過必要事件。

14.7 故障事件也應可重播

最低建議記錄：batch_id、world_epoch、device_backend、shader_version、input_revision、resource_generation、ticket_set、failure_kind、recovery_action 與最終履行狀態，以協助重現特定 GPU／驅動下的錯誤。

15. 局部世界 Compute Runtime 的最低元件

15.1 不是重新打造完整 Game Engine

CWSR Paper 05 只提出一組可置於已有 Rust／C++／Godot 等遊戲程式旁的候選元件：

元件	最低責任	不應持有的權限
Causal Work Intake	接 Wake Ticket／fixed-step obligation	不自行宣告世界事件完成
Dependency Resolver	檢查版本與讀寫因果	不擅自改規則依賴
Microflow Batcher	合批、分類與期限保留	不擅自折疊不可合併事件
Compute Shape Analyzer	提供稠密度、局部性與 kernel 候選	不無條件綁定 GPU
Memory／Replica Adapter	依 Paper 04 租用版本化資料	不修改已提交世界歷史
CPU Executor	執行合法 CPU 工作	不越過 Commit Gate
GPU Executor	dispatch、sync、completion、candidate	不因執行成功取得世界寫入權
Render Budget Watcher	提供幀時間與設備競爭指標	不刪除必要世界義務
Candidate Reconciler	檢查結果、誤差與版本	不把不一致資料當作成功
Commit Gate Bridge	唯一授權提交接口	不授予排程器額外權限
Telemetry／Replay	保存可復現資訊	不用虛構數據補齊測試

15.2 Device Backend 抽象

後端只需宣告能力與責任，例如 supported precision、workgroup limits、buffer usage、queue semantics、fence、device loss 回報與資料上限。不可僅以 CUDA 或 Vulkan 名稱判斷某張消費級顯示卡一定支援特定 shader 功能。

15.3 Rust 只是一種參考表達

Rust 所有權與借用可以協助限制 host memory 的資料競爭和 buffer handle 使用，但 GPU command 的非同步生命週期、shader memory model、跨佇列同步以及遊戲語義版本，仍必須由 API 契約及執行測試證明。這些型別不是宣稱程式已通過編譯。

16. 參考型別草案：小流、批次、設備結果與提交

16.1 概念性 Rust 資料模型

下列程式碼為協定草案，沒有引入具體 backend crate，也不聲稱已編譯／跑通：

#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct WorldRevision(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct SimulationEpoch(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct MicroflowId(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct BatchId(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct TicketId(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct ReplicaId(u64);
#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash)]
struct AllocationGeneration(u64);

struct SnapshotStamp {
    world_revision: WorldRevision,
    sim_epoch: SimulationEpoch,
    rule_revision: u64,
    schema_revision: u64,
    scale_certificate_id: Option<String>,
}

struct StateRead {
    logical_state_id: String,
    required_revision: WorldRevision,
}

struct CandidateWrite {
    logical_state_id: String,
    merge_contract_id: String,
}

struct TimeDuty {
    simulation_window: (u64, u64),
    deadline_monotonic_ticks: Option<u64>,
    ordering_group: Option<String>,
}

enum PrecisionMode {
    BitwiseExact,
    Bounded { absolute_error_bits: u64 },
    Statistical { policy_id: String },
}

enum CoalescingPolicy {
    LatestWins,
    Accumulate { reducer_id: String },
    RecomputeFromSnapshot,
    OrderedReplay,
    Never,
}

enum EffectPolicy {
    PureCandidate,
    CommitDependentEffect { effect_kind: String },
}

struct ComputeShape {
    kernel_family: String,
    estimated_active_items: u64,
    estimated_dense_items: u64,
    layout_class: String,
    branch_class: String,
    device_feature_class: String,
}

struct CausalMicroflow {
    id: MicroflowId,
    wake_ticket: TicketId,
    source_stamp: SnapshotStamp,
    reads: Vec<StateRead>,
    candidate_writes: Vec<CandidateWrite>,
    guard_id: String,
    time: TimeDuty,
    precision: PrecisionMode,
    coalesce: CoalescingPolicy,
    effect: EffectPolicy,
    shape: ComputeShape,
    recovery_plan_id: String,
}

struct ReplicaLease {
    replica_id: ReplicaId,
    generation: AllocationGeneration,
    state_revision: WorldRevision,
    lease_token: String,
}

struct MicroflowBatch {
    batch_id: BatchId,
    microflows: Vec<MicroflowId>,
    snapshot: SnapshotStamp,
    kernel_family: String,
    leases: Vec<ReplicaLease>,
    deadline_min: Option<u64>,
    memory_reservation_bytes: u64,
    policy_version: String,
    validation_plan_id: String,
}

struct DeviceCompletionReceipt {
    batch_id: BatchId,
    backend_id: String,
    shader_revision: String,
    completed_execution_generation: u64,
    candidate_replica_ids: Vec<ReplicaId>,
    failure_code: Option<String>,
}

struct CandidateResult {
    batch_id: BatchId,
    source_stamp: SnapshotStamp,
    candidate_states: Vec<String>,
    completion: DeviceCompletionReceipt,
    verification_evidence_id: String,
}

enum ExecutionError {
    UnsupportedBackend,
    NotEnoughBudget,
    DeadlineNotAdmissible,
    CausalConflict,
    InvalidReplicaGeneration,
    StaleWorldRevision,
    DeviceSubmissionFailed,
    DeviceLost,
    ValidationFailed,
    CancelledAfterSubmit,
    RecoveryUnavailable,
}

16.2 Rust 型別草案尚未覆蓋什麼

此資料模型未表示所有 borrow scope、持久化同步、shader specialization、queue ownership transfer、交易性通知、存檔及細粒度多目標規劃。所有 String 和 Vec 在真正 Runtime 可能改為 interned ID、small-vector 或池化結構，避免小流 metadata 過大。硬性不變量應透過封裝 API、測試與設計審查強制執行，而非僅靠列出結構體名稱。

16.3 WGSL／Compute Shader 介面草案

以「對批次的獨立經濟需求值」為例，kernel 概念可以縮為：

Device Input:
    stable_entity_slots[]
    demand_base[]
    price_coefficient[]
    candidate_mask[]
    batch_rule_version
Device Output:
    candidate_demand[]
    numerical_error_flags[]

parallel for local_index in [0, active_count):
    entity_slot = stable_entity_slots[local_index]
    if !candidate_mask[entity_slot]: continue
    v = demand_base[entity_slot] * price_coefficient[entity_slot]
    candidate_demand[entity_slot] = v
    numerical_error_flags[entity_slot] = validate_range(v)

// no canonical world commit inside the kernel
// no external side effect inside the kernel
// actual device synchronization lives in backend adapter

此例沒有解決動態依賴、高階社交關係、貨幣精度或世界結算；它只是適合作為第一個 GPU parallel baseline 的純候選值計算。

16.4 提交證據仍需明示

DeviceCompletionReceipt 只能證明某次設備工作在指定後端語義下回報完成；verification_evidence_id 必須能連到真正被檢查的不變量、版次、誤差及其測試證據。不能單靠有 verification_evidence_id 字串就當作已驗證。

17. 參考算法：從已到期世界義務到異質執行

17.1 Ingest、Resolve 與 Partition

function plan_world_compute(ready_tickets, world_snapshot, capacity):
    microflows = []
    for ticket in ready_tickets:
        assert ticket.is_durable_or_replayable
        q = derive_microflow_from_verified_rules(ticket, world_snapshot)
        if q.has_unresolved_dynamic_dependencies:
            keep_pending(ticket, REQUIRES_DEPENDENCY_RESOLUTION)
            continue
        if not guard_and_clock_eligible(q):
            keep_pending_or_prove_duty_folded(ticket)
            continue
        microflows.push(q)

    dependency_graph = build_rule_verified_edges(microflows)
    conflict_graph = build_read_write_conflicts(microflows)
    ready_frontier = select_dependency_ready_nodes(dependency_graph)

    return partition_by_shape_and_admissibility(
        ready_frontier, conflict_graph, world_snapshot, capacity)

注意：如果 derive_microflow 發現規則依賴不完整，不得直接把它視為沒有依賴。保守的作法是保留 Ticket、回退既有更新流程或要求規則補齊。

17.2 合批與選擇後端

function admit_batch(candidate_bucket, render_feedback, capacity):
    groups = split_by_snapshot_rule_schema_precision(candidate_bucket)
    output = []
    for group in groups:
        legal = resolve_causal_and_write_hazards(group)
        for batch in legal:
            cpu_plan = estimate_complete_cpu_path(batch)
            gpu_plan = estimate_complete_gpu_path(batch, render_feedback)
            possible = filter_hard_constraints([cpu_plan, gpu_plan], capacity)
            if possible.is_empty():
                mark_pending_with_reason_and_deadline(batch, NO_ADMISSIBLE_ROUTE)
                continue
            chosen = choose_by_policy_and_telemetry(possible)
            reservation = reserve_memory_and_queue_budget(chosen)
            if reservation.failed:
                choose_fallback_or_keep_pending(batch)
            else:
                output.push((batch, chosen, reservation))
    return output

Paper 05 只要求 CPU／GPU 的最低安全選擇，不聲稱此演算法就是 Paper 06 的完整 24／72 Form Router。estimate_complete_gpu_path 必須持續校準，並允許返回 Unknown 而非產生虛假的精確預估。

17.3 GPU 執行與提交

function execute_gpu_batch(batch, plan, reservation):
    verify_ticket_coverage(batch)
    leases = acquire_snapshot_replica_leases(batch)
    if !leases: return retry_or_fallback(PENDING_MATERIALIZATION)

    if !recheck_snapshot_and_deadlines(batch):
        release(leases)
        return replan(STALE_OR_EXPIRED)

    buffers = materialize_and_bind(batch, reservation, leases)
    submission = backend_submit_with_explicit_hazards(buffers, plan)
    if submission.failed:
        preserve_all_unfulfilled_tickets(batch)
        return recover_or_fallback(submission.failure)

    receipt = await_device_completion_or_timeout(submission)
    if receipt.failed:
        mark_candidates_unusable()
        preserve_all_unfulfilled_tickets(batch)
        defer_resource_release_until_safe_fence()
        return recover_or_fallback(receipt.failure)

    result = build_versioned_candidate(receipt, batch)
    evidence = verify_against_snapshot_rules_ledgers_and_precision(result)
    if !evidence.sufficient:
        reject(result)
        preserve_or_requeue_tickets(batch)
        return typed_failure(evidence.reason)

    outcome = commit_gate.try_commit(result, evidence, expected_world_revision)
    if outcome.conflict:
        reject_or_legally_rebase(result)
        preserve_or_requeue_unfulfilled_tickets(batch)
        return REPLAN_REQUIRED

    register_commit_notifications_atomically(outcome)
    mark_tickets_fulfilled_exactly_once(batch, outcome)
    release_leases_and_buffers_after_safe_completion()
    return COMMITTED

以上為先驗驗證骨架。實際實作須處理「一批內部分成功」、「提交跨資源原子性」、「多讀者並發」、「提交通知失敗」及「過期快照重試」等細節。尤其 exactly_once 在實作上需靠穩定事件 ID、可重播 ledger／交易政策，不是呼叫一次 mark_tickets_fulfilled_exactly_once 即自動得到的保證。

17.4 CPU 執行也遵守同一 Commit Gate

GPU 特殊的是設備提交、資料駐留與同步，不是唯一需要世界權威檢查的後端。CPU 的純計算、ECS Job、Worker Thread 或 SIMD 也需要相同的版本與因果提交政策。對照測試必須使用共同的世界語義，而不是對 GPU 加一堆驗證、CPU 卻偷偷省略相同責任。

17.5 Shader 編譯與 warming

首次 shader compile 和 pipeline construction 可能對幀時間產生顯著尖峰。預先準備可減少當前臨界路徑，但若預熱耗盡 VRAM 或大量 CPU 時間亦可能有害。GCCF 05 的預記載只能建議暖化；預測不準時不得影響正確世界結果。

17.6 動態替換與 MOD 安全

若遊戲 MOD 更改規則、NPC 屬性與腳本，shader specialization、batch compatibility、快取與依賴索引可能全部失效。至少須重新版控 rule_revision、重新編譯或選擇 CPU fallback，並對未完成 batches 做 safe rejection，不能在舊 shader 下默默延續新規則世界。

18. 跨尺度因果小流的具體世界案例

18.1 案例 A：橋樑毀損與跨區域物價

起點： 玩家在微觀世界摧毀一座橋，事件先經合法提交。

因果： 道路網路連通性改變，地方商隊路徑失效，兩座城市運輸能力受影響，城市商品流量與價格摘要須更新。

CPU 候選： 確認橋樑身份、事件去重、路網變更、特殊商隊與任務腳本。強分支且低延遲的局部圖判定可留 CPU。

GPU 候選： 若許多城市商品／路段具有相同轉移公式，可合批計算流量擬合或需求候選；同時保留港口、山路等特殊規則在 CPU 或其他 kernel。

提交： 交易／庫存不能在跨城市尺度聚合時重複記帳；必須通過 Paper 03 的 boundary ledger、時間一致性與版本檢查。若橋重新開通而舊 GPU batch 尚未完成，必須拒絕舊結果或依法 rebase。

失敗反例： GPU 算了 10,000 條貨流，但其中任一不守恆的過時候選被當作新交易提交，等同創造或消滅世界物資。

18.2 案例 B：百萬居民的飢餓／需求更新

世界模型： 大量匿名群體個體具有規則化代謝／需求參數；少量具名 NPC 具有更複雜個體歷史。

GPU 候選： 大量簡單個體數值可採 SoA、局部活躍清單與批次 kernel；多次合法世界步可由明確時間轉移律處理。

CPU 候選： 具名 NPC 的劇情選擇、工作分歧、閾值事件、任務與資產裁決。若具名 NPC 也有簡單數值欄位，其該部分仍可由 GPU 計算候選。

守恆與細化： 宏觀人口總量或平均飢餓不能反推出某具名居民「昨天吃過什麼」。需要已存在的身份錨點或被遊戲規則明示為生成的歷史，並區分真實記錄與近似視圖。

效能問題： 若每次喚醒只有 40 名居民，GPU dispatch 很可能比 CPU 直接更新更不划算；若十萬名弱耦合居民需同一公式，GPU 才更值得測試。

18.3 案例 C：全國天氣與地區災害

候選模型： 廣域氣候可用網格或區域方程，GPU 擅長大量局部鄰域運算；但需要明確數值穩定性、誤差、邊界條件及時間步長。

跨尺度： 國家級天氣趨勢更新後，降雨、河流、村莊洪災不是無條件由平均數直接推論。地區尺度的臨界事件須局部細化或使用合法的邊界／不確定性政策。

渲染競爭： 暴雨畫面本就增加 GPU 渲染負擔，這時同時大量 GPU 天氣運算可能引發 p99 frame spike；可依期限調整世界計算批次，但不得違反洪災判定義務。

驗證： 與固定步高精度／CPU 同算法 baseline 比較數值殘差、災害觸發、邊界交換帳本與負載尾端。

18.4 案例 D：戰鬥結算與物理混合

GPU 適合部分： 大量相似投射物候選位置、粒子受力、無複雜接觸圖的批次視覺效果。

CPU／精確裁決適合部分： 玩家擊中、格擋、傷害規則、任務事件、戰利品與死亡結果的權威提交；這些也可研究 GPU 協作，但必須滿足低延遲與精確世界規則。

重要區別： 畫面的 particle motion 可用較寬容的渲染精度；影響角色生死的碰撞或命中判定應遵守遊戲明確的權威精度與時間責任，不得因它們共享圖形 API 就偷換語義。

18.5 案例 E：玩家快速旅行與十日世界推進

世界需求： 必須處理農作物成熟、經濟稅收、商隊、疾病擴散、角色生死及任務期限。

GPU 機會： 批次處理許多沒有分支、具有合法閉式更新或固定步數值演化的區域候選。

CPU／事件責任： 按 Paper 02 的 due frontier 找出不可跨越的時間事件，按 Paper 03 的 causal temporal cut 保持必要順序；在強分歧時不得把整個十日世界一次算成平均狀態。

失敗反例： 十日糧食消耗被合併，但第三天發生商隊遭搶劫事件，直接套用第十天正常供應會產生錯誤世界。

18.6 案例 F：MOD 將簡單 NPC 規則改為強分支 AI

原狀態： 十萬名 NPC 使用 GPU 批次簡單遷移規則。

MOD 變動： 加入個體記憶、派系信任網路、每步複雜腳本。

安全行為： 新規則 version 使既有 batch code、派生快取和路由估計失效；Runtime 應分割新的 Compute Shape、採取 CPU／混合方案、重新驗證或暫時退回成熟更新路徑。

失敗反例： MOD 更改 Guard，但某個 compiled shader 仍按舊 Guard 模擬，畫面一切正常卻造成世界長期偏移。這類錯誤比直接 crash 更難被察覺。

18.7 案例 G：長期靜止畫面與背景演化

起點： 玩家停留在城鎮選單，圖像幾乎沒有變化。

合法選擇： UI 可以保持有效投影不重建；未到期 NPC 工作可以安全休眠；仍需世界時間義務的城市經濟可由 CPU 或 GPU 小批次按期處理；render 並不因世界工作而一定需要每次更新整個場景。

必要區別： 畫面不變不能當成所有世界工作都可以停下的證據。因果小流必須從規則與時間契約建立，而不是從「這一幀像素沒變」建立。

19. 可證偽工作命題與證明責任

19.1 命題 P05-1：合法合批不應改變規則要求的可觀測世界

條件命題： 假設一組小流共享相容的已驗證世界快照，彼此沒有規則級必要先後、所有寫入互不衝突或以已證明的合併律處理、沒有提前發生外部副作用，且使用滿足精度契約的計算後端，則合批後按合法拓撲及 Commit Gate 提交，應與參考排程在明示的可觀測契約下等價。

證明概念： 對純函式、讀寫互斥的工作，可以把同時評估視為對同一快照的一組不相互覆蓋候選結果；因果偏序與合併律保證其合法合成。若上述任一條件失效，不能繼續主張等價。

主要反例： 同時更新市場庫存，但其中一個工作讀取另一個工作的中間結果；或兩者都觸發「首次跌破閾值」事件而沒有去重。

19.2 命題 P05-2：GPU 優勢存在工作量與資料局部性條件

條件命題： 在某設備、規則與工作形態固定的局部測量條件下，若 GPU 對每件合法計算的增量成本低於 CPU，且工作量足以攤銷額外固定路徑成本、渲染互擾可接受、期限與記憶體契約成立，則 GPU 有機會降低同一工作集的完整成本。

限制： 即使簡化 crossover 模型成立，也只給出候選門檻，不等於任意大小都線性加速。

反例： CPU 處理數十個簡單事件只需極短時間，卻因 GPU pipeline warming、queue wait、readback 形成更長尾延遲。

19.3 命題 P05-3：Device-resident 工作鏈可能減少重複搬移

條件命題： 若多階段 GPU 工作合法共用同一版本資料、正確同步且不需要每階段 host 語義驗證，持續設備駐留可避免某些輸入／中間結果重複傳輸。

反例： 資料在兩個 kernel 中間必須 CPU 作高階劇情決策，或顯存壓力迫使頻繁驅逐，可能完全吃掉其效益。

19.4 命題 P05-4：GPU Kernel 完成不推出世界 Commit

這是一個契約分離而非效能定理：

\mathrm{GPUComplete}(B)\not\Rightarrow\mathrm{WorldCommitted}(B).

設備完成只構成候選輸出可被進一步驗證的一項必要資訊。提交仍須世界版本、讀寫衝突、精度、不變量、事件去重、期限及權限檢查。

19.5 命題 P05-5：不存在無條件最好的 CPU／GPU 分工

若硬體能力、render pressure、狀態稠密度、規則分支及依賴改變，最合適路徑也可能改變。本篇不主張固定路由對所有負載占優；相反地，把 CPU-only、GPU-only、hybrid、fixed-step 及 event-driven 全部視為必須比較的合法候選。

19.6 命題 P05-6：當依賴治理成本過高，應退回更粗的工作單元

設某負載在細粒度分割下產生額外 metadata、索引維護、hazard resolve、device dispatch 及版本核對成本。若這些成本大於因為跳過更新、資料並行或重用而節省的工作，應減少小流數量、擴大 grain 或禁用該策略。這是明確的設計退讓，不是理論失敗需要掩蓋的部分。

19.7 語義正確不表示成本較低

一套完全正確的 CWSR 可以比成熟 ECS／Job System 更慢。Paper 08 不得在結果中把「沒有世界狀態錯誤」當成「效率提升」，也不能把 GPU 利用率提升當成比高品質基準優越。

20. 實驗設計：最低比較基準與公平性

20.1 Benchmark 不可只比較一個慢基準

定義最低候選基線：

Baseline	內容	目的
B0	樸素每幀逐物件更新	展示原始負載，但不能當唯一對照
B1	成熟 CPU ECS／Job System／批次 SIMD	排除「只是把迴圈寫得更好」的效果
B2	CPU 事件驅動／Dirty Flag／期限排程	排除「只是跳過無用工作」的效果
B3	GPU Compute 的成熟直接批次方案	排除「只是利用 GPU 平行」的效果
B4	GPU 常駐與批次＋成熟 CPU 配套	與較完整的異質工程基線比較
CWSR	Paper 01–05 契約下的可選 CPU／GPU 小流	測量新組合額外價值與治理成本

必要公平條件： 使用相同世界規則、資料集、提交義務、精度政策、時間窗口、存檔需求和觀察介面。若某 baseline 少做了必要世界工作，不能把它的快當作同等正確性的勝利；若 CWSR 使用近似，必須拿同等精度約束的成熟近似 baseline 比較。

20.2 主要工作負載因子

世界規模： 依系統類型選擇小型、中型及壓力測試，例如 $10^2$ 至 $10^6$ 個可建模單元；不預設每種負載都能在一台設備上完整物化。
活躍比例： 稀疏、中等、高密度直到接近全量更新。
因果耦合： 無依賴、局部網格、高扇出、SCC、全域事件。
規則性： 同構數值、少量分支、高分支腳本、動態 MOD。
時間模式： 正常運行、選單停留、暫停、時間快進、讀檔恢復。
資料布局： AoS、SoA、AoSoA、active list 與 device-resident。
設備壓力： 輕、中、重渲染負載及不同顯存餘裕。
輸出策略： 每批 readback、摘要 readback、合法 device-resident chain。
精度： Exact、Bounded numerical、Statistical，各自獨立比較。
後端： 至少 CPU 及一個實際可用的 GPU 計算後端；跨平台結果應獨立報告。

20.3 GPU 時間不能只看 API 回報一個數值

須分別量測：

CPU 工作產生與合批；
buffer pack／materialize／copy；
CPU 提交成本與 GPU queue wait；
kernel GPU 執行時間；
device synchronization；
必要 readback；
世界驗證／Commit Gate；
渲染 p50／p95／p99 frame time；
CPU wall time、GPU busy time 與可用記憶體峰值；
已處理且合法提交的世界義務數量。

裝置 GPU timestamp、CPU monotonic tracing 與外部 profiler 需要時鐘對齊，不能直接把不同時間域的 timestamp 相減當作精確 latency。

20.4 符合遊戲規則的效能目標

效能至少由兩類結果共同衡量：

A. 體驗： frame-time tail、輸入到反應延遲、畫面卡頓、長時間穩定性及背景世界義務履行。

B. 世界： 已提交更新吞吐量、未解決義務量、最大 deadline lateness、跨尺度誤差、RNG／回放差異、版本拒絕率及恢復成功率。

若 FPS 提升但 unresolved_duties 持續增長，不能算是成功。

20.5 不能省略記憶體與能耗

記錄 RAM／VRAM reserved、committed、peak、staging bytes、重複副本、device upload／download bytes、reclaim／restore 次數、buffer generation 衝突、CPU/GPU 功耗或可用代理指標。沒有可靠的功率量測時應明說缺失，不可將 GPU 低占用假定為必然低耗電。

20.6 GPU 與 CPU 比較需符合後端語義

CPU 若使用固定點，而 GPU 使用浮點加速近似，差異需由規則明確准許；若 CPU 用小型全量迴圈，GPU 卻用完整預先壓縮／合批，需分解辨認真正來源，不能把全部收益歸於「異質排程」。

20.7 熱機、冷機與遊戲執行長度

實測須區分 cold shader compile、warm pipeline、區域首次載入、已有 VRAM resident、長期內存壓力和反覆旅行。一次短跑可能只顯示預熱優勢，長跑可能出現 VRAM 失控或 buffer 抖動。

20.8 重複性與資訊保存

應紀錄硬體型號、VRAM、CPU、RAM、OS、Driver、Graphics API、遊戲規則版本、shader 版本、資料集 seed、測試日期、電源／溫控模式及原始 trace。不是為了填寫華麗表格，而是讓他人判斷何處真正更快、何處只是硬體或配置不同。

21. 可證偽測試矩陣

以下皆為待實作／待執行測試，並非測試已 PASS 的報告。

Test ID	條件與故障注入	期待的不變量或可證偽判準
C05-T01	一千個互不衝突的簡單數值小流	合批與參考順序在指定精度下等價
C05-T02	兩工作同時寫同一庫存	拒絕不合法平行，或使用已證明的 reducer
C05-T03	第一工作輸出為第二 Guard	不可越過必要依賴順序
C05-T04	batch 中某張 Ticket 重複入隊	權威副作用 exactly-once／有證據去重
C05-T05	類似事件在合批等待時遇期限	在合法期限內完成，否則 typed failure
C05-T06	GPU queue 排隊時世界規則修訂	拒絕過時 shader／候選，不發生錯誤提交
C05-T07	版本相同但 Replica generation 改變	stale handle 無法重新存取別人的配置
C05-T08	shader 執行時 GPU buffer 被要求回收	lease／fence 防止提早回收
C05-T09	compute／graphics 共用 buffer	使用正確 barrier／queue ownership／visibility
C05-T10	device loss 發生在 kernel 中	世界權威完整、Ticket 可重播與恢復
C05-T11	GPU 結果完成後 canonical world 改版	Commit Gate 拒絕，或以合法可驗證重算處理
C05-T12	浮點 reduce 改變 thread order	依指定 Exact／Bounded／Statistical 語義判定
C05-T13	隨機事件先 preload、後取消	不消耗或改寫 canonical RNG／因果歷史
C05-T14	Macro 城市摘要傳至 Micro	不隨機冒充已存在具名 NPC 的歷史
C05-T15	橋樑毀損導致貨運變化	邊界帳本無資產重複／遺失
C05-T16	時間快進跨越條件分支	不漏 due events 與不可跳過的 Guard
C05-T17	幀時間尖峰而 GPU 批次堆積	Render policy 變更仍保存世界期限
C05-T18	大量稀疏事件且 batch 很小	不強迫 GPU；與 CPU baseline 比成本
C05-T19	GPU resident chain 無需中間 host 參與	實測傳輸量降低；不預設總延遲改善
C05-T20	合批 metadata 比小流本身更大	能縮粒度、禁用策略或回退
C05-T21	MOD 變更 NPC 規則，舊 shader 未完成	rule revision 與快取失效正確處理
C05-T22	城市天氣 GPU 計算與重渲染競爭	記錄 p95／p99、期限、熱節流與 VRAM 峰值
C05-T23	連續物理積分被誤判為可休眠	保守 fallback 保持時間積分正確
C05-T24	多尺度重疊區域同時計算同一交易	僅一個合法權威更新，無重複貨物
C05-T25	連續讀檔與舊批次晚到	以 world epoch 隔離，舊輸出不能改新存檔
C05-T26	CPU/GPU 選擇閾值附近反覆波動	避免無益切換；必要緊急回退不被阻擋
C05-T27	VRAM soft／hard limit 接近	排程保守處理、OOM 與 renderer reserve 有可觀測紀錄
C05-T28	kernel 只回傳 summary，但世界需要逐筆驗證	不應以不足的摘要通過 Commit Gate
C05-T29	GPU device loss 後使用 durable snapshot＋journal	可重建必要世界狀態與未處理義務
C05-T30	同工作量在兩種 GPU 或驅動下運行	差異被記錄，不聲稱無條件跨設備最優

21.1 結構性失敗需要形成反例資產

每次錯誤需附 fixture、world rule revision、event graph、input hashes、ticket set、device info、candidate output、commit result、重現步驟與期望觀察；只留下「某 GPU 有時會錯」不足以修正模型。

21.2 若測試通過，但效能沒改善

只代表系統能在該試驗條件下符合正確性要求，不能反推 CWSR 的加速假說成功；可在保留契約的前提下關閉昂貴的細粒度小流，選用成熟 CPU／GPU 方案。

22. 可能使本系列局部主張失效的反例

22.1 反例 E05-A：所有世界單元每步都改變

當世界真正具有高密度且連續的必要更新，建立大量事件訂閱與小流 metadata 可能是多餘的；大型固定步或直接 GPU kernel 可能占優。

22.2 反例 E05-B：資料太少且必須立即回傳

微小低延遲工作先打包、上傳、dispatch、readback 再提交，比單執行緒 CPU 更慢；應退出 GPU 路徑。

22.3 反例 E05-C：寫入衝突超高

所有小流都修改同一世界聚合值，又不具合法結合律，GPU 高平行性可能無法發揮；強制使用 atomic 還可能引入排序或浮點差異。

22.4 反例 E05-D：渲染高負載

同一顆消費級 GPU 的世界 compute 會提高畫面 p99、溫度或功耗；即使世界吞吐量提升，總玩家體驗可能退步。

22.5 反例 E05-E：舊版結果大量失效

GPU batches 長時間排隊，世界規則頻繁更新；大多數完成後被 Commit Gate 拒絕，浪費計算、同步與顯存。

22.6 反例 E05-F：跨尺度近似不具正確邊界

如果宏觀經濟統計不能充分描述某些關鍵玩家互動，GPU 做得愈快也只是在更快產生錯誤世界；必須先修正尺度模型而不是調整後端。

22.7 反例 E05-G：規則或 MOD 太動態

動態腳本與高階狀態機需要大量特殊規則，shader kernel family 激增，編譯與切換成本高於收益；CPU 路徑可能合理。

22.8 反例 E05-H：硬體功能與跨平台成本不足

部分玩家設備沒有足夠 GPU 特徵或顯存，或 backend 在跨平台支援成本過高；應保留 CPU reference 或適當功能退化，不把購買新 GPU 當作正確性的先決條件。

22.9 反例 E05-I：觀測本身比工作昂貴

追蹤每個事件的 GPU timing、完整資料 hash、頻繁 readback 若過度細緻，可能嚴重改變效能。應在保留足夠診斷能力的前提下使用抽樣 telemetry、批次記錄與離線驗證；安全相關的核心證據仍不可被抽樣省略。

23. 成熟技術對照與本篇增量界線

23.1 不是發明一般的 GPU 計算

Compute Shader、SIMD／SIMT、資料平行、GPU fluid／particle／crowd simulation 都已有長期研究及產品實踐。CWSR 研究的是，在多尺度世界、因果喚醒、邏輯狀態、版本化駐留與權威提交同時存在時，哪些 GPU 工程策略才具有合法性與收益。

23.2 不是發明圖排程與 ECS

成熟 ECS、Job System、資料導向設計、dirty update 及圖排程器已有可能達成大部分性能收益。本篇不以特定名稱區別新舊，而以多尺度因果義務的可追蹤性、異質執行候選與世界提交一致性作為要測量的整合部分。

23.3 並非每個世界工作都需要所謂 AI

世界模擬可用傳統確定演算法、數值方法、規則機、腳本與硬體原生 Compute 完成。AI 可協助程式重構、kernel 產生、依賴圖提案、配置候選與測試；但 AI 產出的圖與程式不因 AI 身份就免除對資料競態、浮點範圍與世界語義的驗證。

23.4 GCCFT／GCCWT 與 CWSR 的研究責任不同

GCCFT 關注一般動態耦合計算場；GCCWT 關注共享計算世界與異質資源激發、權限及狀態。CWSR Paper 05 縮小到單機消費級 GPU 工作負載，允許只採用成熟 kernel＋有限 CPU 控制，而不要求先實作跨世界、跨 Agent、跨資料中心的完整計算織體。

23.5 Paper 06 才處理 24／72 的路由文法

本篇只為每個小流提出形態特徵與 CPU/GPU 執行候選；並未假定其 shape 直接對應某一 24 格或 72 格。下篇可在固定 canonical basis 的前提下，將這些實際成本特徵映射到 GCM／GCCF 06 的路由描述，而不重發明既有分類。

24. 下一階段：從本篇方法論到可執行工程

24.1 Paper 06 的直接交接

Paper 06 應收到：

Microflow 的世界修訂、Guard、Deadline、Precision 與 Scale Context；
經已驗證依賴與寫入 hazard 形成的合法批次前沿；
ComputeShape 與 CPU/GPU backend capability profiles；
RAM／VRAM／render reserve、in-flight bytes、資料搬移與恢復成本；
完整路徑估計、量測的不確定性與已知反例；
資源硬限制、提交限制及 fallback routes；
24／72 classification 可以提供的資訊與不能直接判斷的效能；
不可省略的版本及 Commit Gate 邊界。

Paper 06 的獨立責任： 將計算形態、資源、期限、硬體、適用域、動態切換成本與 Pareto 選擇結合為可評估的路由策略，不把 24／72 解釋為固定硬體性能級別。

24.2 Paper 07 的最小實作順序

建議先採取小型、可替換、可測試的 engineering milestones，而不是立即建構整個大型開放世界：

M1 — CPU Causal Microflow Baseline
以同一 world fixture 建立 stable identity、ticket intake、版本、read/write hazard、batch／fallback、Commit Gate 與 replay。此階段不必有 GPU，以確保規則語義已能正確測試。

M2 — One GPU Kernel Family
挑選純數值、弱耦合、資料規整的城市經濟需求或人口簡單狀態，加入最小 GPU adapter、buffer lease、fence、candidate receipt 與可重現的 CPU 對照。

M3 — Device Residency and Render Contention
加入 versioned GPU buffers、合法 device-to-device 依賴、staging／readback 比較、graphics budget 監控、device loss 恢復。

M4 — Mixed-scale and Dynamic Rule Fixture
接入橋樑／雙城市物流／關鍵 NPC 的尺度圖，加入 MOD 式規則修改、時間跳躍、跨尺度帳本及 stale candidate test。

M5 — Integration Adapter
為 Godot／EveWorld 或其他實際選定引擎建立 WorldTick / Event / ComputeRequest / CandidateCommit / RenderProjection 的明確橋接。只在核心測試達標後才放入真遊戲資料路徑。

以上是待實施路線，不代表目前已有以上可執行產品。

24.3 Paper 08 的硬性交付

依 B0–B4 對照組完成真正同語義比較；
以原始 trace 與可重播資料建立世界規則正確性證據；
公布成功、失敗、退步與未能量測的條件；
記錄消費級硬體、driver、GPU backend、渲染壓力與 VRAM；
同時報告 CPU/GPU 計算成本、傳輸、p95/p99 幀時間與世界義務履行；
若 CWSR 在某 domain 無明顯優勢，將其標記為不建議啟用或僅保留契約檢查。

24.4 如果某些工作真的適合只用傳統循環

應允許每個子系統保持 FixedStep, EventTriggered, ScheduledBatch, GpuBatch, Hybrid, Dormant 等可版本化路徑，並能在變更前確保義務、記憶體及時間契約。此處的路徑標籤只屬於本篇工程規格，不能冒充現有 24／72 canonical 格點。

24.5 避免新母理論擴張

CWSR 是九篇固定閉環（Paper 00–08）。本篇即使發現 GPU 世界小流很有用途，也不因此另立一套宇宙級計算本體論；若出現真正超出舊理論定義的反例，先標註為待核對上游的研究問題，而非當場宣告新公理。

25. 來源、原稿版本與學術責任

25.1 本輪直接核對的 CWSR 原始 UTF-8 Markdown

Neo.K × Aletheia，CWSR Paper 00｜因果世界狀態運行：既有計算理論的單機遊戲 Runtime 延伸總綱，v0.1，2026-10-16。CWSR_Paper00_Causal_World_State_Runtime_Series_Charter_v0.1_2026-10-16.md。
Neo.K × Aletheia，CWSR Paper 01｜世界狀態本體與可執行狀態分離，v0.1，2026-10-16。CWSR_Paper01_World_State_Ontology_and_Executable_State_Separation_v0.1_2026-10-16.md。
Neo.K × Aletheia，CWSR Paper 02｜因果觸發、執行休眠與條件喚醒機制，v0.1，2026-10-16。CWSR_Paper02_Causal_Trigger_Execution_Dormancy_and_Conditional_Wakeup_v0.1_2026-10-16.md。
Neo.K × Aletheia，CWSR Paper 03｜宏觀—中觀—微觀多尺度世界模擬，v0.1，2026-10-16。CWSR_Paper03_Macro_Meso_Micro_Multi_Scale_World_Simulation_v0.1_2026-10-16.md。
Neo.K × Aletheia，CWSR Paper 04｜動靜態記憶體契約與選擇性物化，v0.1，2026-10-16。CWSR_Paper04_Dynamic_Static_Memory_Contracts_and_Selective_Materialization_v0.1_2026-10-16.md。

25.2 既有 EveMissLab 上游原稿

Neo.K × Aletheia，全域計算方法論：異質計算的全域一致組合，v0.1，2026-08-23。01_全域計算方法論_異質計算的全域一致組合_v0.1.md。
Neo.K，《計算的二十四重範式》，正式版候選稿 v4.0，2026-07-19。計算的二十四重範式_正式版_v4.0.md。
Neo.K × Aletheia，《從二十四重計算形態學到七十二格計算動力學》，v0.1，2026-07-19。從二十四重計算形態學到七十二格計算動力學_v0.1.md。
Neo.K × Aletheia，GCCF 04｜全域可尋址狀態與選擇性物化，v0.1，2026-09-22。GCCF_04_Globally_Addressable_State_and_Selective_Materialization_v0.1_zh-TW.md。
Neo.K × Aletheia，GCCF 05｜因果流計算與預記載，v0.1，2026-09-22。GCCF_05_Causal_Flow_and_Predictive_Preloading_v0.1_zh-TW.md。
Neo.K × Aletheia，GCCF 06｜計算 24 範式與 72 格作為全域計算路由文法，v0.1，2026-09-22。GCCF_06_24_Paradigms_72_Cell_Global_Computation_Routing_Grammar_v0.1_zh-TW.md。
Neo.K × Aletheia，GCCWT Paper 04｜計算場與資源激發：跨 CPU／GPU／Memory／Agent 的動態執行域，Draft v0.2。GCCWT_Paper04_Draft_v0.2.md。
Neo.K × Aletheia，GCCWT Paper 06｜AI 原生全域調度：從 Task Scheduler 到 World Computation Planner，Draft v0.2。GCCWT_Paper06_Draft_v0.2.md。
EveMissLab，GCM Phase B：Deterministic Compute Allocator 技術白皮書，v0.1，2026-08-27。GCM Phase B：Deterministic Compute Allocator 技術白皮書 v0.1.md。
Neo.K × Aletheia，《從有序計算到全域耦合計算》統合母論文，v0.1，2026-09-22。Global_Coupled_Computation_Integration_Mother_Paper_v0.1_2026-09-22.md。

以上來源用於繼承與核對概念邊界，不等於每份文件均已由獨立同行審查；如正式公開投稿，應將內部版本與對外可追溯的公開版本逐一對齊。

25.3 成熟外部工程背景（不冒充原創）

本篇使用 GPU Compute、CUDA／DirectCompute／Vulkan Compute、SIMT、ECS Job Scheduling、GPU synchronization、memory barriers、resource lifetime、SoA／AoSoA、prefix scan、stable compaction、device-side reduction、counter-based RNG、fixed-point／floating-point arithmetic、benchmark methodology 以及 profiler 等成熟概念。具體 API 與同步語義須以實際採用的 Khronos、Microsoft、Rust／GPU backend、driver 及遊戲引擎官方文件版本為準。

本篇沒有聲稱完成外部文獻的系統性搜尋，也沒有虛構跨設備實驗結果。將來需要做正式學術引用時，應補齊實際查閱的版本化技術規格、相關期刊／會議研究與公開效能工作；本輪研究只承諾可供後續驗證的形式與方法。

26. 結論

CWSR Paper 05 的根本問題不是「CPU 應該讓多少工作給 GPU」，而是：當一個世界由多尺度、異步、具時限且彼此耦合的狀態構成，應如何在保持必要因果、版本、精度與世界提交責任的前提下，讓消費級硬體只執行真正需要的工作，並將適合的工作組合成有效的異質運算。

CPU 與 GPU 都可以是世界計算的合法執行者。GPU 不只是畫面加速器，還能承擔人口、物流、區域需求、天氣與某些群體演化的批次數值候選；CPU 也不只是 GPU 命令提交器，而能負責事件、複雜判斷、遊戲腳本、排程與權威世界協調。兩者都不應被固定到宏觀、中觀或微觀某一個尺度。

本文提出的 Causal Microflow 是將世界義務與實際 GPU 工作形式分離的工程中介單位。一個小流包含事件、快照、讀寫、規則、時間與精度責任，許多合法小流可以合批成少量 GPU dispatch；同時，合批不得覆蓋因果先後、身份、交易順序和必要事件。裝置側鏈式計算有可能減少往返資料，卻不能僅因 bytes 留在 VRAM 便宣稱其已成為新的世界事實。

資源治理的終點也不是「GPU 永遠要滿載」，而是維持世界所需模擬深度、玩家交互反應、可接受幀時間、有限 RAM／VRAM、正確的世界事件與穩定的回放／恢復。當 GPU dispatch 太小、分支過深、資料太散、渲染太忙或版本太常變，CPU／傳統固定步／成熟 GPU kernel 可能明確更好。CWSR 必須允許此種結果。

這篇論文的工作結論可濃縮為：

因果決定必要工作，資料決定適合布局，契約決定合法並行，設備決定實際成本；GPU 可以計算世界，但只有通過驗證與提交，候選結果才成為世界。

本篇尚未證明任何具體性能優勢。Paper 06 接手 24／72 的自適應計算路由，Paper 07 實作參考 Runtime 與 GPU adapter，Paper 08 以成熟基線、反例與可重現 trace 驗證。若實驗顯示本方法只在少數場景有效，應縮小適用域，而不是修改效能報告來維持理論敘事。

下一篇：CWSR Paper 06｜24／72 計算範式的世界狀態自適應路由。

End of CWSR Paper 05 v0.1 — Research Draft.