# 舊應用與遊戲的 AI 加速
## 從實作串行化到必要串行化

**English Title:** *AI Acceleration of Legacy Applications and Games: From Implementation Serialization to Necessary Serialization*  
**系列：**《計算域支配智能：AI 語義控制面與自適應多 X 計算》第 5 篇  
**系列代號：** CDI / AIVS  
**文件編號：** EML-CDI-05-LGAA-2026-v0.1  
**作者：** Neo.K  
**協作整理：** Aletheia  
**機構：** EveMissLab／一言諾科技有限公司  
**版本：** v0.1  
**日期：** 2026-08-10  
**文件類型：** 計算架構論文／Legacy Application Performance Methodology／Game Runtime Benchmark Specification  
**證據成熟度：** E0–E1。Windows tracing、game profiling、threading analysis、binary API instrumentation 等 primitive 已成熟；本文提出的 CDI/AIVS 自動辨識「實作串行化」並將其安全改造成多 X 執行仍需 MVP 與 benchmark 驗證。

---

## 摘要

現代 CPU 普遍具有多核心，GPU、NPU 與其他 accelerator 亦提供大量平行資源；然而，大量既有應用與遊戲的主要進度仍可能受到單一 main thread、歷史架構、同步設計、共享可變狀態或固定 pipeline 限制。這不表示所有串行工作都能被平行化，也不表示作業系統不知道如何調度多核心。真正的工程問題是：

> **現有序列中，有多少順序是由計算本身的必要因果依賴造成，又有多少只是程式當初的實作方式所造成？**

本文將兩者分離為：

$$
\boxed{
ImplementationSerialization
}
$$

與：

$$
\boxed{
NecessarySerialization.
}
$$

並定義 **串行化缺口**（Serialization Gap）：

$$
\boxed{
G_S
=
I_S-N_S,
}
$$

其中 $I_S$ 為觀察到的實作串行量， $N_S$ 為經依賴、狀態、副作用與正確性分析後仍必須維持的必要串行量。 $G_S$ 不是一個天然可直接量測的物理量，而是本文提出的工程估計目標。

本文提出：AI 對 legacy application 的價值，不應首先被理解成「把 binary 即時改成 16 核」，而應分成三個可見度層級：

$$
\boxed{
L_1:
SourceVisible
}
$$

$$
\boxed{
L_2:
TraceVisible
}
$$

$$
\boxed{
L_3:
OpaqueBinary.
}
$$

在 $L_1$ ，AI 可結合 source、AST/IR、profiler、tests 與 compiler dependence information 產生 parallelization/refactor candidate；在 $L_2$ ，AI 只能從 ETW、call stacks、thread timing、locks、I/O、GPU timing、application markers 等 runtime evidence 建立近似因果圖；在 $L_3$ ，則應進一步收縮權限，將 binary instrumentation 主要用於觀察與 API boundary interception，不得把「能 hook」誤寫成「能安全重排任意內部指令」。

對遊戲，本文進一步指出「FPS 增加」不是充分成功條件。AI 改變 main-loop、task graph 或 offload route 後，還必須驗證：

- simulation state；
- frame/tick epoch；
- RNG stream；
- event ordering；
- physics invariants；
- save/load state；
- networking semantics；
- render submission；
- player-visible behavior；
- rollback / correction。

因此本文提出 **Game Equivalence Contract（GEC）** 與 **Acceleration Promotion Gate（APG）**：

$$
\boxed{
NewRoute
\rightarrow
Shadow
\rightarrow
Equivalence
\rightarrow
Performance
\rightarrow
Promotion.
}
$$

本文並將前四篇整合：

1. CDI 提供 AI 語義—因果控制面；
2. AIVS 讓高頻計算只在高價值同步點升級認知；
3. Candidate/Commit 讓新執行方式先成為 shadow candidate；
4. 24／72 PRL 提供計算形態與 routing prior；
5. 本文則建立 legacy/game 取得 evidence、估計 serialization gap、驗證加速與安全 promotion 的方法。

本文最後提出 **Legacy Acceleration Pipeline（LAP）**、五類 acceleration channel、三類 visibility、Game Equivalence Contract、benchmark protocol、失敗分類與十二組可反駁假說。下一篇將把五篇理論收斂成可直接實作的 **CDI Runtime + AIVS Windows MVP**。

---

## 關鍵詞

Legacy Application、Game Acceleration、AI-assisted Parallelization、Serialization Gap、Main Thread、ETW、WPR、WPA、PIX、VTune、Concurrency Visualizer、Detours、CDI、AIVS、Game Equivalence Contract、Shadow Execution、Multi-X

---

# 0. 系列位置

前四篇回答：

$$
\boxed{
AI怎麼治理計算？
}
$$

本文開始回答：

$$
\boxed{
它能不能真的對既有程式產生可量測的加速？
}
$$

所以第五篇是：

$$
\boxed{
Theory
\rightarrow
BenchmarkableEngineeringHypothesis.
}
$$

---

# 1. 首先取消一個錯誤問題

錯誤問法：

> 「這個遊戲支不支援多核心？」

更好的問法：

> **這個遊戲的主要 frame / simulation critical path 中，有哪些 region 真正受到序列依賴限制？**

因為一個程式可以：

- 已有多個 thread；
- 仍由 main thread 決定 frame；
- GPU 很忙但 CPU bottleneck；
- background task 已平行；
- simulation 還是串行。

所以：

$$
\boxed{
ThreadCount
\neq
EffectiveParallelism.
}
$$

---

# 2. OS Scheduler 不是主要研究對象

Windows 本身已經能：

- schedule threads；
- migrate threads across cores；
- manage waits；
- expose kernel/app tracing；
- support thread pools。

因此本文不主張：

$$
WindowsCannotUseMulticore.
$$

真正研究對象是：

$$
\boxed{
ApplicationLevelDependencyStructure.
}
$$

---

# 3. 串行化的四個來源

本文先分：

$$
\boxed{
Serialization
=
Causal
+
State
+
Effect
+
Implementation.
}
$$

---

# 4. Causal Serialization

真正前後依賴：

$$
x_{t+1}=F(x_t).
$$

沒有：

$$
x_t
$$

就無法合法得到：

$$
x_{t+1}.
$$

這類通常屬於：

$$
NecessarySerialization.
$$

---

# 5. State Serialization

兩個 region 同時讀寫共享 state：

$$
R/W
$$

產生：

- RAW；
- WAR；
- WAW；
- alias；
- lock；
- version conflict。

有些是必要，

有些可以經：

- snapshot；
- partition；
- double buffering；
- local state；

被解除。

---

# 6. Effect Serialization

例如：

- graphics API order；
- file mutation；
- network send；
- audio device；
- OS window state；
- save game；
- external hardware。

即使 calculation 可平行，

effect commit 仍可能需要序列化。

---

# 7. Implementation Serialization

這是本文最有興趣的部分。

例如：

```text
MainLoop:
  update_ui()
  calculate_npc_paths()
  decode_assets()
  update_audio()
```

只是因為歷史上寫成：

$$
A\rightarrow B\rightarrow C\rightarrow D
$$

不等於：

$$
A\prec B\prec C\prec D
$$

都是必要因果。

---

# 8. Serialization Gap

定義概念性估計：

$$
\boxed{
G_S=I_S-N_S.
}
$$

但：

$$
I_S
$$

與：

$$
N_S
$$

不能只靠 AI 主觀打分。

必須由 evidence 支持。

---

# 9. Evidence for $I_S$

可以包括：

- CPU thread timeline；
- call stack；
- idle cores；
- waiting；
- main-thread occupancy；
- synchronization；
- GPU queue delay；
- I/O；
- task boundaries。

---

# 10. Evidence for $N_S$

需要更強資料：

- source / IR；
- read/write set；
- shared state；
- locks；
- invariants；
- side effect；
- deterministic replay；
- tests；
- shadow execution。

所以：

$$
\boxed{
ObservedSerialization
}
$$

容易看到，

$$
\boxed{
NecessarySerialization
}
$$

比較難證明。

---

# 11. 三個可見度層級

$$
\boxed{
L_1:
SourceVisible
}
$$

$$
\boxed{
L_2:
TraceVisible
}
$$

$$
\boxed{
L_3:
OpaqueBinary.
}
$$

這三層不能使用同樣的自動化權限。

---

# 12. Level 1 — Source Visible

AI 可以取得：

- source；
- symbols；
- build；
- tests；
- AST / IR；
- compiler diagnostics；
- profiler。

這是第一個應做的 MVP。

---

# 13. Source Visible 的主要工作

$$
\boxed{
Source
\rightarrow
RegionSegmentation
\rightarrow
DependencyAnalysis
\rightarrow
RouteCandidates.
}
$$

AI 補充：

- subsystem semantics；
- task intent；
- high-level role；
- possible partition strategy。

---

# 14. AI 不應直接提交 code rewrite

仍然遵守：

$$
\boxed{
Patch
=
Candidate.
}
$$

流程：

$$
AIRefactor
\rightarrow
Build
\rightarrow
Tests
\rightarrow
ShadowBenchmark
\rightarrow
Review
\rightarrow
Commit.
$$

---

# 15. 最有價值的 Source-visible 轉換

例如：

- loop → parallel loop；
- serial task chain → task DAG；
- synchronous I/O → async I/O；
- repeated search → precomputed index；
- shared global → partitioned/local state；
- CPU scalar → SIMD；
- CPU bulk work → GPU candidate；
- frame-blocking load → background asset pipeline。

---

# 16. 這些轉換不都需要 LLM

例如：

$$
LoopDependence
$$

compiler 可以做。

AI 的價值是：

> 把 compiler finding、profiler hotspot、subsystem meaning 與測試目標連起來。

---

# 17. Level 2 — Trace Visible

沒有完整 source，

但有：

- symbols 或部分 symbols；
- ETW；
- call stack sampling；
- thread timing；
- waits；
- I/O；
- DirectX activity；
- markers。

這時只能建立：

$$
\boxed{
\hat G_C
}
$$

近似 Causal Compute Graph。

---

# 18. ETW 的角色

ETW 可以：

- 記 kernel / app events；
- 動態啟停；
- 即時或離線 consumption；
- 支援 WPR/WPA。

因此 Windows 本身已提供一個很適合作為 CDI Observer 的：

$$
\boxed{
EventPlane.
}
$$

---

# 19. WPR / WPA

WPR：

$$
Capture.
$$

WPA：

$$
Analyze.
$$

對 CDI MVP 最重要：

> 不必一開始自己寫 kernel tracer。

可以先把 ETL：

$$
\rightarrow
StructuredTrace
\rightarrow
AI.
$$

---

# 20. Concurrency Visualizer

可觀察：

- CPU utilization；
- thread contention；
- cross-core migration；
- synchronization delay；
- DirectX activity；
- overlapped I/O。

這些資料適合用來：

$$
\boxed{
FindCandidateRegions.
}
$$

但不能直接證明：

$$
ParallelSafe.
$$

---

# 21. VTune 的角色

VTune 可以分析：

- hotspots；
- threaded performance；
- synchronization objects；
- CPU/GPU bound；
- offload effectiveness。

所以它可以當：

$$
\boxed{
ExternalProfilerOracle
}
$$

而不是讓 CDI 自己重造完整 profiler。

---

# 22. PIX 對遊戲特別重要

PIX Timing Capture 可以把：

- CPU；
- GPU；
- file I/O；
- memory allocation；
- game markers；

放進同一 timing capture。

對遊戲：

$$
\boxed{
CrossCPU/GPUTimeline
}
$$

是判斷：

> main thread bottleneck？

> GPU starvation？

> queue delay？

的重要 evidence。

---

# 23. Trace 的真正用途不是直接叫 AI 看全部

原始：

$$
Trace_{raw}
$$

可能非常大。

應：

$$
\boxed{
RawTrace
\rightarrow
Reducer
\rightarrow
RegionEvents
\rightarrow
AIVS.
}
$$

---

# 24. Region Event

```yaml
region_event:
  region_id:
  thread_id:
  frame_epoch:
  start_ns:
  end_ns:

  cpu:
    running_ns:
    waiting_ns:
    core_migrations:

  gpu:
    queue_delay_ns:
    execution_ns:

  io:
    read_bytes:
    wait_ns:

  dependency_refs:
  markers:
  anomaly_score:
```

---

# 25. AIVS 在 Legacy Profiling 中的角色

正常 frame：

$$
R_0.
$$

只記：

- summary；
- digest；
- hotspot counter。

異常：

$$
R_1.
$$

才取：

- stack；
- extended trace。

多 subsystem conflict：

$$
R_2/Governor.
$$

---

# 26. Level 3 — Opaque Binary

最危險的情況。

只有：

- executable；
- DLL；
- API calls；
- OS trace；
- timing；
- memory / module info。

此時：

$$
\boxed{
Confidence\downarrow.
}
$$

---

# 27. Detours 能證明什麼？

Microsoft Detours 可以：

- runtime intercept binary function；
- hook Win32 API；
- 建 trampoline；
- 插入 DLL；
- 對沒有 source 的 app 做 instrumentation。

這證明：

$$
\boxed{
BinaryBoundaryObservation
}
$$

是可行的。

---

# 28. Detours 不能證明什麼？

它不能自動保證：

- 任意 instruction 可安全 reorder；
- 任意 function 可 parallelize；
- hidden state 不衝突；
- game anti-cheat / integrity policy 允許修改；
- timing semantics 不變。

所以：

$$
\boxed{
CanIntercept
\neq
CanParallelizeSafely.
}
$$

---

# 29. Opaque Binary 的合理第一階段

允許：

- observe；
- timestamp；
- count；
- API boundary trace；
- read-only instrumentation。

不允許：

- arbitrary instruction reordering；
- uncontrolled memory patch；
- speculative irreversible effect。

---

# 30. Sidecar Acceleration

Opaque app 最安全的加速方向之一可能是：

$$
\boxed{
SidecarCompute.
}
$$

不改核心 simulation，

只把外圍工作移出：

- asset decode；
- file preprocess；
- compression；
- shader preprocess；
- indexing；
- remote query；
- cache building。

---

# 31. Sidecar 的基本形式

```text
Legacy App
   │
   ├─ Original Critical Path
   │
   └─ Boundary / Request
           │
           ▼
       Sidecar Worker
           │
           ▼
       Verified Result
```

---

# 32. Sidecar Result 仍然是 Candidate

如果 legacy app 會 consume：

$$
SidecarResult,
$$

仍需：

- version；
- request id；
- TTL；
- input digest。

否則：

$$
StaleSidecarResult.
$$

---

# 33. Safe Acceleration Channels

本文分五類。

## A — Offline Refactor

改 source。

---

# 34. B — Runtime Reschedule

已有 task boundary，

調整：

- worker count；
- affinity；
- ordering；
- queue。

---

# 35. C — Offload

移到：

- GPU；
- NPU；
- other process；
- remote worker。

---

# 36. D — Sidecar

不改主核心，

外部處理可獨立工作。

---

# 37. E — Speculative Shadow

先算未來可能需要的結果，

但不直接 commit。

---

# 38. 五類風險不同

$$
Risk(A)
<
Risk(B/C)
<
Risk(E)
$$

不是固定定理，

但作為一般工程 prior：

Opaque runtime speculation 應比 source-visible refactor 更保守。

---

# 39. Legacy Acceleration Pipeline（LAP）

本文提出：

$$
\boxed{
LAP
=
Observe
\rightarrow
Segment
\rightarrow
Infer
\rightarrow
Classify
\rightarrow
Propose
\rightarrow
Shadow
\rightarrow
Verify
\rightarrow
Promote.
}
$$

---

# 40. Observe

收集 baseline。

不能：

> 先改，再量。

需要：

$$
\boxed{
BaselineFirst.
}
$$

---

# 41. Baseline Run Set

至少多次：

$$
R_1,\ldots,R_n.
$$

因遊戲：

-場景；
- save；
- camera；
- NPC；
- shader cache；
- asset cache；

都影響 performance。

---

# 42. Scenario Contract

每個 benchmark scene：

```yaml
scenario:
  game_version:
  save_id:
  map:
  camera_path:
  duration_s:
  warmup_s:
  rng_seed:
  resolution:
  graphics_settings:
  network_mode:
```

---

# 43. Segment

將 main loop / trace 分：

$$
E_1,\ldots,E_n.
$$

來源：

- markers；
- call stack clusters；
- modules；
- source functions；
- timing phases。

---

# 44. Infer

建立：

$$
\hat G_C.
$$

Edge 可能：

- data；
- control；
- state；
- effect；
- time。

---

# 45. Classify

可使用：

$$
24/72\ ParadigmProfile.
$$

但採：

$$
ProgressiveResolution.
$$

先問：

> S/J/P/R？

---

# 46. Propose

AI 產生：

$$
RouteCandidate.
$$

不是直接改正式程式。

---

# 47. Shadow

使用：

- shadow process；
- replay；
- duplicated region；
- offline capture。

新 route：

$$
NoExternalAuthority.
$$

---

# 48. Verify

兩類：

$$
Correctness
$$

與：

$$
Performance.
$$

必須先 correctness。

---

# 49. Promote

只有：

$$
CorrectnessPass
\land
PerformanceGain>Threshold
\land
StabilityPass.
$$

才 active。

---

# 50. 為什麼遊戲比一般 batch app 更難？

遊戲有：

$$
\boxed{
RealTimeStatefulInteraction.
}
$$

不是一次 input → output。

玩家每一個動作都會改變：

$$
FutureState.
$$

---

# 51. Game State

定義：

$$
\boxed{
S_f
=
(
World,
Physics,
Actors,
Script,
RNG,
Network,
Resources
)_f.
}
$$

 $f$ 可是 frame 或 simulation tick。

---

# 52. Frame 不一定等於 Simulation Tick

有些 engine：

$$
RenderFrame
\neq
SimulationTick.
$$

所以 Runtime 不能只用 frame number 做全部 causal epoch。

---

# 53. Epoch Vector

本文提出：

$$
\boxed{
\mathbf e
=
(
e_{sim},
e_{render},
e_{asset},
e_{network}
).
}
$$

不同 subsystem 可不同步前進。

---

# 54. Game Equivalence Contract（GEC）

AI acceleration 的結果要回答：

> 新執行方案和原版「一樣」到底指什麼？

定義：

$$
\boxed{
GEC=(I_s,I_p,I_r,I_e,\epsilon).
}
$$

---

# 55. State Invariant $I_s$

例如：

- actor count；
- health；
- transform；
- inventory；
- quest state。

---

# 56. Physics Invariant $I_p$

例如：

- no penetration；
- conserved / bounded quantities；
- collision result within tolerance。

---

# 57. RNG Invariant $I_r$

視需求：

## Strict

保持同 RNG stream。

## Statistical

只要求分布一致。

遊戲 replay 測試通常優先 strict。

---

# 58. Event Invariant $I_e$

例如：

$$
A\prec B
$$

必須保持。

不一定要求：

$$
timestamp_A
$$

完全相同。

---

# 59. Tolerance $\epsilon$

浮點 simulation：

$$
ExactBitEquality
$$

可能不是合理要求。

可定義：

$$
d(S,S')\le\epsilon.
$$

---

# 60. GEC 不等於「畫面看起來差不多」

視覺相似：

$$
\neq
$$

simulation equivalence。

所以：

$$
\boxed{
ScreenshotOnly
}
$$

不能做主要 correctness oracle。

---

# 61. MSSP Runtime 的啟示

現有遊戲 Computer Runtime 已採：

$$
Frame
\rightarrow
Diff
\rightarrow
StructuredEvent
$$

而非：

$$
EveryFrame
\rightarrow
DeepAI.
$$

對本篇：

$$
\boxed{
PerformanceTrace
}
$$

也應採相同原則：

$$
RawTimeline
\rightarrow
Diff/Region
\rightarrow
AI.
$$

---

# 62. RNG 是 parallelization 的大坑

原來：

```text
NPC A calls RNG
NPC B calls RNG
```

序列：

$$
r_1,r_2.
$$

平行後：

呼叫順序可能交換。

結果：

$$
GameplayDivergence.
$$

---

# 63. 解法 A：Per-Entity RNG Stream

$$
RNG_A
$$

$$
RNG_B
$$

分離。

---

# 64. 解法 B：Counter-Based RNG

以：

$$
(entity,tick,event)
$$

定址。

是否適用依遊戲架構。

---

# 65. 解法 C：保留原 RNG Commit Order

compute 平行，

RNG consumption：

$$
Serialized.
$$

可能限制 speedup，

但先保 correctness。

---

# 66. Physics 也不能粗暴平行

物件分區：

$$
A,B
$$

若完全沒有 interaction：

可以。

若跨區碰撞：

需要：

$$
BoundarySync.
$$

---

# 67. AI 能做的是找 Partition Candidate

例如：

$$
GraphPartition(
InteractionGraph
).
$$

但真正 correctness：

由 physics invariant / engine test 決定。

---

# 68. NPC / Pathfinding

通常是很有吸引力的 candidate，

因很多 agent query：

$$
Q_1,\ldots,Q_n
$$

可以部分獨立。

但 navmesh version：

$$
v
$$

必須跟 world state 對齊。

---

# 69. Asset Streaming

往往：

- I/O-bound；
- decode；
- decompression；
- upload。

非常適合：

$$
Async/Sidecar/Pipeline.
$$

但 GPU upload / resource lifetime 仍有 effect ordering。

---

# 70. Audio

mixing / decode 可能 parallel，

但 device deadline：

$$
HardLatency.
$$

所以：

$$
TransferOverhead
$$

可能讓 GPU offload 反而更糟。

---

# 71. UI

很多 UI 工作對 simulation：

$$
ReadOnly.
$$

可以較晚更新。

因此：

$$
StaleTolerance
$$

可能高於 physics。

---

# 72. Network

不能只因 CPU parallel safe 就改 packet order。

因：

$$
ProtocolSemantics.
$$

---

# 73. Render Submission

render preparation 可大量 parallel，

但 API / resource dependency / queue submission 有自己的規則。

所以：

$$
\boxed{
RenderWorkParallel
\neq
ArbitraryRenderSubmitOrder.
}
$$

---

# 74. Acceleration Promotion Gate（APG）

正式 promotion 要經：

$$
\boxed{
APG
=
Correctness
\land
Performance
\land
Stability
\land
Fallback.
}
$$

---

# 75. Correctness Gate

GEC pass。

---

# 76. Performance Gate

不只 average FPS。

至少：

- frame-time p50；
- p95；
- p99；
- main-thread time；
- total CPU utilization；
- wait time；
- GPU utilization / queue delay；
- memory。

---

# 77. 為什麼 p99 很重要？

如果：

平均：

$$
16ms
$$

但每幾秒：

$$
100ms,
$$

玩家感覺仍可能很差。

所以：

$$
\boxed{
AverageOnly
}
$$

不足。

---

# 78. Stability Gate

至少：

- multi-run variance；
- no crash；
- no deadlock；
- no growing memory；
- no error accumulation。

---

# 79. Fallback Gate

AI / optimizer 關掉：

$$
\boxed{
OriginalRouteStillWorks.
}
$$

---

# 80. A/B Replay

相同：

$$
Scenario.
$$

跑：

$$
Original
$$

與：

$$
Candidate.
$$

比較：

$$
\Delta Performance
$$

與：

$$
\Delta State.
$$

---

# 81. Performance Gain

$$
\boxed{
G_T
=
\frac{
T_{base}-T_{new}
}{
T_{base}
}.
}
$$

---

# 82. Parallel Efficiency

若使用：

$$
p
$$

個 compute units：

$$
\boxed{
E_p
=
\frac{S_p}{p}.
}
$$

低：

$$
E_p
$$

表示：

- overhead；
- dependency；
- imbalance；
- contention。

---

# 83. Amdahl Bound

若不可平行比例：

$$
s,
$$

其餘可用：

$$
p
$$

單元：

$$
S(p)
\le
\frac{1}{
s+\frac{1-s}{p}
}.
$$

這提醒：

$$
\boxed{
NecessarySerialization
}
$$

永遠會限制 speedup。

---

# 84. AI 的任務是降低估計的 $s$

不是違反 Amdahl。

也就是找出：

> 原本被當成 serial，其實不是 necessary serial 的區域。

---

# 85. Synchronization Tax

新增 parallel region：

$$
Gain
$$

但同時：

$$
SyncTax.
$$

因此：

$$
\boxed{
NetGain
=
ParallelGain
-
SyncTax
-
TransferTax
-
AICost.
}
$$

---

# 86. AI Tax

包括：

- profiling；
- inference；
- trace reduction；
- validation；
- route switching。

如果：

$$
AITax>Gain,
$$

撤回。

---

# 87. Offline AI Tax 與 Runtime AI Tax

Offline：

$$
C_{offline}
$$

可以高，

因一次分析可長期重用。

Runtime：

$$
C_{runtime}
$$

必須低。

這就是為什麼：

$$
RouteCache
$$

很重要。

---

# 88. Learn Once, Retrieve Later

第一次：

$$
Analyze.
$$

穩定後：

$$
ProfileHash
\rightarrow
KnownRoute.
$$

再度呼應：

$$
\mathsf R.
$$

---

# 89. Source-visible 優先序

第一個真實 MVP：

$$
\boxed{
OpenSourceLegacyStyleGame.
}
$$

比：

$$
AAAClosedBinary
$$

合理很多。

---

# 90. 第一 MVP 選擇標準

- Windows 可跑；
- source 可 build；
- main loop 明確；
- baseline 單／少 thread bottleneck；
- deterministic test scene；
- 有 profiler markers 或容易加入；
- 不含 anti-cheat；
- license 允許修改。

---

# 91. 不應第一個選 MMO / competitive game

原因：

- network；
- anti-cheat；
- integrity；
- server authority；
- nondeterminism。

難度太高。

---

# 92. Source-visible MVP 模式

Mode A：

$$
\boxed{
Advisor.
}
$$

AI 只提出候選。

---

# 93. Mode B

$$
\boxed{
PatchGenerator.
}
$$

產生 code patch，

仍需 build/tests。

---

# 94. Mode C

$$
\boxed{
ShadowParallel.
}
$$

新 task path 不正式 commit。

---

# 95. Mode D

$$
\boxed{
VerifiedPromotion.
}
$$

通過 APG 才 active。

---

# 96. Trace-visible MVP

先不改程式。

只輸出：

```yaml
finding:
  region:
  hotspot:
  observed_serialization:
  inferred_dependencies:
  confidence:
  candidate_strategy:
  required_evidence:
```

---

# 97. Binary-only MVP

只做：

$$
\boxed{
ObservationOnly.
}
$$

Detours / ETW：

用於建立：

- API timeline；
- I/O；
- waits；
- module boundaries。

---

# 98. Binary-only 第二階段

只允許 sidecar：

- preload；
- decode；
- cache；
- indexing。

---

# 99. Binary-only Runtime Rewrite

列為：

$$
\boxed{
ResearchOnly/HighRisk.
}
$$

不作 v0.1 的主產品路線。

---

# 100. AI 不應誤把 CPU Idle 當可平行證據

CPU idle 可能因：

- GPU bound；
- I/O bound；
- frame cap；
- sleep；
- vsync；
- lock；
- network wait。

所以：

$$
\boxed{
IdleCore
\not\Rightarrow
ParallelizableWork.
}
$$

---

# 101. AI 不應誤把 Main Thread Hotspot 當可 offload

hot function 可能：

$$
NecessarySerial.
$$

所以：

$$
Hotspot
\rightarrow
CandidateForInvestigation,
$$

不是：

$$
Hotspot
\rightarrow
Parallelize.
$$

---

# 102. Profiling First Principle

$$
\boxed{
Measure
\rightarrow
Explain
\rightarrow
Transform.
}
$$

不是：

$$
Guess
\rightarrow
Patch.
$$

---

# 103. Evidence Ladder

$$
E_0:
TimingOnly
$$

$$
E_1:
CallStack/Thread
$$

$$
E_2:
Markers/API/Locks
$$

$$
E_3:
Source/IR/ReadWrite
$$

$$
E_4:
ShadowEquivalence
$$

$$
E_5:
RepeatedBenchmark.
$$

---

# 104. Automation Authority 依 Evidence Level

低 evidence：

$$
AdviceOnly.
$$

高 evidence：

$$
AllowPromotion.
$$

所以：

$$
\boxed{
Authority
=
f(Evidence).
}
$$

---

# 105. AI Confidence 不能取代 Evidence

$$
Confidence_{AI}=0.99
$$

不等於：

$$
Evidence=E_5.
$$

---

# 106. Serialization Finding

```yaml
serialization_finding:
  finding_id:
  region_id:
  evidence_level:
  observed:
    serialized_ms:
    idle_core_ms:
    waits:
  inferred:
    necessary_serial_ms:
    candidate_gap_ms:
  confidence:
  blockers:
  next_measurement:
```

---

# 107. $G_S$ 的估計

$$
\hat G_S
=
T_{serialized}
-
\hat T_{necessary}.
$$

注意：

$$
\hat T_{necessary}
$$

可能隨 evidence 更新。

---

# 108. Bayesian / iterative update

可以：

$$
P(G_S\mid E_0)
\rightarrow
P(G_S\mid E_1)
\rightarrow\cdots.
$$

v0.1 不需真正 Bayesian model，

只需明確：

$$
\boxed{
FindingIsRevisable.
}
$$

---

# 109. Failed Optimization 也是資料

如果：

$$
CandidateRoute
$$

變慢：

保留：

- reason；
- trace；
- conflict；
- overhead。

避免 AI 未來重試同錯誤。

---

# 110. Negative Optimization Memory

```yaml
negative_route:
  region_hash:
  route:
  reason:
  benchmark:
  invalid_until:
```

---

# 111. 這可以降低 AI Token

因下次：

$$
RetrieveFailure
$$

而不是：

$$
ReasonAgain.
$$

---

# 112. AIVS Relay 如何分 subsystem

遊戲：

$$
\Omega_{physics}
$$

$$
\Omega_{npc}
$$

$$
\Omega_{asset}
$$

$$
\Omega_{render}.
$$

每個 Relay 管自己的 performance / causal profile。

---

# 113. Governor 何時介入？

只有：

- cross-subsystem conflict；
- route mutation；
- repeated failure；
- global frame budget；
- energy / thermal policy。

---

# 114. Frame Budget Governance

目標：

$$
T_{frame}
\le
B_f.
$$

Governor 可以分：

$$
B_f
=
B_{input}
+
B_{sim}
+
B_{render}
+\cdots.
$$

---

# 115. 這不是硬 real-time scheduler

除非：

- deadline；
- priority；
- fallback；
- bounded latency；

都有正式保證。

v0.1：

$$
\boxed{
Advisory/SoftRealTime.
}
$$

---

# 116. Thermal / Power

如果：

GPU 已：

$$
100\%.
$$

把 CPU task offload GPU：

可能：

$$
Worse.
$$

所以：

$$
\boxed{
ResourceState
}
$$

必須進 PRL。

---

# 117. Laptop / handheld

Policy 可能不是最高 FPS，

而是：

$$
\boxed{
FPSPerWatt.
}
$$

所以 AI routing objective 需可改權重。

---

# 118. Performance Policy

```yaml
performance_policy:
  target_frame_ms:
  max_power_w:
  max_ai_overhead_ms:
  min_state_equivalence:
  optimization_goal:
    - latency
    - smoothness
    - energy
```

---

# 119. Smoothness

可用：

$$
p95/p99\ frame\ time
$$

作 proxy。

但不宣稱單一 metric 就完整代表玩家體感。

---

# 120. AI 遊戲加速的四種產品形態

## 1. Developer Tool

最現實。

分析 source / profiler，

提出 patch。

---

# 121. 2. Build-time Optimizer

CI：

$$
Build
\rightarrow
Profile
\rightarrow
AIOptimize
\rightarrow
Test.
$$

---

# 122. 3. Runtime Sidecar

不改核心，

做：

- prefetch；
- cache；
- asset work；
- monitoring。

---

# 123. 4. Runtime Governor

最高難度。

動態：

- route；
- worker；
- sync；
- fallback。

這就是第六篇的長期方向。

---

# 124. 不應從第 4 類起步

工程順序：

$$
\boxed{
DeveloperTool
\rightarrow
BuildTime
\rightarrow
Sidecar
\rightarrow
Governor.
}
$$

---

# 125. 與 MSSP Game Runtime 的關係

現有 MSSP Runtime 已處理：

- 遊戲視窗；
-持續 vision；
- diff/event；
- bounded AI inference；
- action verification；
- human interrupt；
- audit。

它可以作 CDI Game MVP 的：

$$
\boxed{
ObservationAndControlReference.
}
$$

但本文不把它當 performance profiler。

ETW / PIX / VTune 才是性能 evidence plane。

---

# 126. 雙觀察面

$$
\boxed{
VisualSemanticPlane
}
$$

來自 MSSP 類 runtime。

$$
\boxed{
PerformanceTracePlane
}
$$

來自 ETW / PIX / profiler。

兩者結合：

> 「玩家看到卡頓」

與：

> 「哪個 subsystem 在卡」

可被對齊。

---

# 127. 這可能是 AI 特別有價值的地方

傳統 profiler 顯示：

$$
FunctionX=8ms.
$$

AI 還可以知道：

> 這 8ms 正好發生在玩家進入場景、UI 已切換、NPC 大量 spawn 的語義事件後。

這是：

$$
\boxed{
PerformanceCausality
+
WorldSemantics.
}
$$

---

# 128. 但仍是相關線索，不自動等於因果證明

需要：

- controlled replay；
- intervention；
- repeated measurement。

---

# 129. Benchmark Matrix

至少：

$$
3
$$

維：

1. visibility；
2. workload；
3. intervention level。

---

# 130. Visibility

$$
Source
/
Trace
/
Binary.
$$

---

# 131. Workload

$$
CPU
/
GPU
/
IO
/
Mixed.
$$

---

# 132. Intervention

$$
Observe
/
Advise
/
Shadow
/
Commit.
$$

---

# 133. 核心 Metrics

### Performance

- frame p50/p95/p99；
- main-thread ms；
- CPU utilization；
- waits；
- GPU delay；
- memory；
- I/O。

### Correctness

- GEC pass；
- state divergence；
- RNG divergence；
- crash；
- deadlock。

### AI

- Token；
- calls；
- latency；
- escalation；
- false finding。

---

# 134. False Finding

AI 說：

> 可 parallelize。

結果：

$$
NoGain
$$

或：

$$
Incorrect.
$$

需要分：

- false safe；
- false beneficial。

---

# 135. Missed Opportunity

AI 沒找到，

人工 expert 找到。

這是：

$$
FalseNegative.
$$

---

# 136. Baselines

至少比較：

1. original；
2. human profiler optimization；
3. compiler/static tools；
4. AI advisory；
5. AI + verification。

---

# 137. H1 — AI + profiler 能找到額外的 serialization candidate

要求：

$$
Candidates_{AI+Profiler}
>
Candidates_{ProfilerOnly}
$$

但這還不是成功。

---

# 138. H2 — 額外 candidate 中存在真正 beneficial region

要求至少一部分：

$$
CorrectnessPass
\land
NetGain>0.
$$

---

# 139. H3 — Source Visible 顯著優於 Trace Visible

預期：

$$
SafePromotionRate_{L1}
>
SafePromotionRate_{L2}.
$$

若沒有，source semantic access 的價值需重新評估。

---

# 140. H4 — Trace Visible 仍能提供有效 advisory

即使不改 code，

能否：

$$
RankHotRegions
$$

與 expert 判斷有顯著一致？

---

# 141. H5 — Opaque Binary 不適合高權限自動 parallelization

這可作 negative hypothesis：

若 binary-only 自動 rewrite 的：

- correctness；
- stability；
- benefit；

明顯差於 source-visible，

支持本文保守邊界。

---

# 142. H6 — AIVS 可降低 profiler → AI 資訊成本

比較：

$$
RawTraceToAI
$$

與：

$$
ReducedEventsToAI.
$$

要求：

$$
Token\downarrow
$$

而 hotspot / anomaly recall 不顯著下降。

---

# 143. H7 — GEC 能抓到 FPS-only benchmark 漏掉的錯誤

故意產生：

$$
FPS\uparrow
$$

但：

- RNG；
- simulation；
- event order；

錯誤。

GEC 必須 fail。

---

# 144. H8 — Shadow Promotion 降低錯誤 route 進入正式遊戲

比較：

direct apply vs shadow.

要求：

$$
InvalidActiveOptimization\downarrow.
$$

---

# 145. H9 — Sidecar 對 Opaque Binary 有實際價值

選 asset / I/O workload。

要求：

$$
FrameTailLatency\downarrow
$$

且 core binary 不改。

---

# 146. H10 — Serialization Gap 與 speedup 相關

估：

$$
\hat G_S.
$$

測實際：

$$
G_T.
$$

若完全無相關：

$$
G_S
$$

作為 routing prior 需要修正。

---

# 147. H11 — Negative Optimization Memory 降低重複探索

多輪 AI optimization：

要求：

$$
RepeatedFailedRoutes\downarrow.
$$

---

# 148. H12 — Route Cache 降低 Runtime AI Calls

穩定 workload：

$$
AIcalls_{cached}
<
AIcalls_{reanalyze}
$$

且 performance 不下降。

---

# 149. 主要失敗模式

1. 把 idle core 誤認可平行；
2. 把 hotspot 誤認可 offload；
3. hidden shared state；
4. RNG divergence；
5. floating-point nondeterminism；
6. GPU transfer tax；
7. synchronization tax；
8. profiler perturbation；
9. trace 太大；
10. binary hook 改變 timing；
11. anti-cheat / integrity conflict；
12. frame cap / VSync 誤判；
13. thermal throttling；
14. shader cache / warmup bias；
15. save / scene 不一致；
16. network nondeterminism；
17. AI optimization overfit benchmark scene；
18. average FPS 提升但 tail latency 惡化；
19. state equivalence 未測；
20. AI overhead 抵消 gain。

---

# 150. Profiler Perturbation

任何 instrumentation：

$$
Observer
$$

都可能改變：

$$
ObservedSystem.
$$

所以：

- baseline；
- low-overhead mode；
- repeated run；
- no-instrument control；

都需要。

---

# 151. Warmup

第一次：

- shader compile；
- asset cache；
- JIT；

會造成假 hotspot。

所以：

$$
\boxed{
WarmupSeparate.
}
$$

---

# 152. Thermal Repeatability

長跑：

$$
Clock\downarrow
$$

可能造成後半 slowdown。

需要記：

- power；
- temperature；
- frequency；

若工具可用。

---

# 153. AI 語義分析也要固定版本

如果 model：

$$
M_1\rightarrow M_2,
$$

finding 可能變。

benchmark 需記：

- model id；
- prompt/schema version；
- policy version。

---

# 154. 開發者工具的最小輸出

不要先產生 500 行 patch。

先：

```yaml
acceleration_report:
  bottleneck:
  serialization_findings:
  candidate_regions:
  blockers:
  evidence_needed:
  expected_gain_range:
  confidence:
  safest_next_experiment:
```

---

# 155. 最安全的第一步是「下一個實驗」

AI 的高價值輸出可以只是：

> 把 NPC pathfinding 移出 main loop 做 shadow，先跑 1000 tick，檢查 navmesh version 與 RNG。

這比：

> 我已經幫你多核化完成。

可靠得多。

---

# 156. 從 Advisor 到 Autonomy

$$
\boxed{
Observe
\rightarrow
Recommend
\rightarrow
Generate
\rightarrow
Shadow
\rightarrow
Promote.
}
$$

每升一階：

$$
EvidenceRequirement\uparrow.
$$

---

# 157. Legacy Application 不一定要是遊戲

同一方法可用：

- media editor；
- scientific desktop app；
- CAD；
- accounting app；
- compression tool；
- simulation；
- legacy server。

但遊戲是很好的 stress test，

因為：

$$
\boxed{
Latency
+
State
+
Interaction
+
CPU/GPU
}
$$

同時存在。

---

# 158. 第六篇需要的 Windows MVP 元件

本篇正式要求工程版至少有：

```text
TraceCollector
TraceReducer
RegionSegmenter
SerializationAnalyzer
DependencyStore
GameEpochTracker
RNGPolicy
GameEquivalenceContract
BenchmarkRunner
RouteAdvisor
ShadowRunner
PromotionGate
NegativeRouteMemory
```

---

# 159. Windows Evidence Adapter

第一版優先：

$$
\boxed{
ETW/WPR
}
$$

而不是自行 kernel driver。

可再接：

- WPA export；
- PIX capture；
- VTune report。

---

# 160. Source Adapter

支援：

- source map；
- symbols；
- function / module；
- test command；
- build command。

---

# 161. Binary Adapter

只：

- modules；
- exported APIs；
- ETW；
- optional Detours observer。

v0.1 不做 arbitrary binary optimizer。

---

# 162. Game Adapter

最低：

```yaml
game_adapter:
  process:
  window:
  frame_marker:
  sim_tick_marker:
  state_probe:
  rng_probe:
  benchmark_scenario:
```

---

# 163. 如果遊戲無 state probe？

第一階段：

$$
PerformanceOnlyAdvisory.
$$

不能 promotion 到 high-risk runtime modification。

---

# 164. 如果沒有 deterministic replay？

可用：

- scripted input；
- repeated scenario；
- statistical equivalence。

但 evidence level 下降。

---

# 165. 如果連 scripted input 都沒有？

只能：

$$
Observation.
$$

不能宣稱 correctness。

---

# 166. 這是整條研究線的重要方法論

$$
\boxed{
Capability
\le
Evidence.
}
$$

AI 能做多少，

不能超過我們能驗證多少。

---

# 167. 與 CDI 的總整合

Legacy / Game：

$$
\boxed{
Trace/Source
\rightarrow
CausalComputeGraph
\rightarrow
ParadigmProfile
\rightarrow
RouteCandidate
\rightarrow
AIVS
\rightarrow
Shadow
\rightarrow
GEC
\rightarrow
Commit.
}
$$

---

# 168. 統籌 AI 的角色

Governor 不負責：

- 每個 CPU instruction；
- 每個 frame 全畫面；
- 每個 trace event。

而負責：

- bottleneck hypothesis；
- cross-flow routing；
- conflict；
- promotion；
- fallback。

---

# 169. Relay AI 的角色

Relay 負責：

- subsystem trace；
- local anomaly；
- stale result；
- performance regression；
- evidence reduction。

---

# 170. Non-AI 的角色

仍然最大：

- scheduler；
- compiler；
- profiler；
- ETW；
- test；
- hash；
- state comparison；
- GPU driver。

所以：

$$
\boxed{
AI
}
$$

是控制層，

不是取代整個 software stack。

---

# 171. 「AI 加速」的更準確定義

本文最後定義：

$$
\boxed{
AIAcceleration
}
$$

不是：

> AI 自己算得比較快。

而是：

> AI 的介入使同一目標在可接受正確性與資源約束下，以更低時間／成本／功耗完成。

---

# 172. Speedup 可以來自很多地方

- parallelization；
- offload；
- prefetch；
- caching；
- reduced waiting；
- better scheduling；
- avoided recomputation；
- recognition/retrieval；
- speculative preparation。

因此：

$$
\boxed{
Acceleration
\neq
ParallelizationOnly.
}
$$

---

# 173. 最後回到原始問題

「一個原本沒有很好利用多核的遊戲，AI 能不能介入後加速？」

本文的受限答案是：

$$
\boxed{
Possibly,
}
$$

但前提不是：

> AI 有智能，所以能破解單核限制。

而是：

1. 能觀察真實瓶頸；
2. 找到非必要的實作串行；
3. 取得足夠 dependency evidence；
4. 建立候選新 route；
5. shadow 驗證；
6. GEC 確認沒有破壞遊戲語義；
7. performance 確認 Net Gain > 0；
8. 可安全 fallback。

---

# 174. 何時答案是 No？

如果：

$$
G_S\approx0,
$$

也就是：

$$
ImplementationSerialization
\approx
NecessarySerialization,
$$

那 AI 不能創造不存在的 parallelism。

最多：

- 更快硬體；
- algorithm improvement；
- cache；
- approximation；
- redesign。

---

# 175. 何時最有機會？

如果：

$$
G_S\gg0
$$

且：

- region large；
- dependency sparse；
- state partitionable；
- effect delayable；
- transfer cost low；

則：

$$
\boxed{
CDIAccelerationPotential\uparrow.
}
$$

---

# 176. 結論

AI 對 legacy application 與遊戲最有價值的問題，不是：

> 「能不能把單核變多核？」

而是：

$$
\boxed{
\text{現有的串行，到底有多少是真的必須串行？}
}
$$

這將問題從硬體神話拉回：

$$
\boxed{
Dependency
+
State
+
Effect
+
Evidence.
}
$$

本文因此提出：

$$
\boxed{
SerializationGap
=
ImplementationSerialization
-
NecessarySerialization.
}
$$

AI 的第一任務是估計這個 gap；

第二任務才是：

$$
GenerateCandidate.
$$

第三任務不是直接部署，

而是：

$$
\boxed{
Shadow
\rightarrow
Equivalence
\rightarrow
Benchmark
\rightarrow
Promotion.
}
$$

對有 source 的程式，AI 可以逐步升級到 refactor / task graph / offload；對只有 trace 的程式，應以 advisory 與 sidecar 為主；對 opaque binary，則必須更保守：

$$
\boxed{
CanObserve
\neq
CanRewriteSafely.
}
$$

對遊戲，FPS 也不是唯一真相。任何加速都必須在：

$$
\boxed{
GameEquivalenceContract
}
$$

下證明 simulation、RNG、physics、event ordering 與可恢復性仍在接受範圍。

因此本系列到第五篇形成完整閉環：

$$
\boxed{
SemanticControl
\rightarrow
AdaptiveObservation
\rightarrow
VerifiedCommit
\rightarrow
ParadigmRouting
\rightarrow
Legacy/GameBenchmark.
}
$$

下一篇將不再擴張概念，而是把上述五篇收斂成：

# 《CDI Runtime + AIVS》
## AI 治理多 X 計算的工程架構、協議與 MVP

並給出 Windows-first、source-visible-first、observer-first 的可直接實作版本。

---

## 參考資料

### 內部研究線

1. Neo.K / Aletheia. 《AI 不必替代計算：從傳統執行平面到語義—因果控制平面》，v0.1，2026。
2. Neo.K / Aletheia. 《AI 垂直同步：分層中繼、認知比例性與低成本因果一致》，v0.1，2026。
3. Neo.K / Aletheia. 《候選不是提交：多 X 計算中的因果校正、錯位檢測與可恢復執行》，v0.1，2026。
4. Neo.K / Aletheia. 《從 24／72 計算範式到 Runtime 路由：AI 如何選擇、組合與切換計算形態》，v0.1，2026。
5. Neo.K / Aletheia. 《Adaptive Cognitive Runtime（ACR）工程白皮書》，v0.1，2026。
6. EveMissLab. *MSSP Game Computer Runtime*, v0.8.0，2026。

### 2026-08-10 重新查閱之公開 Primary Sources

7. Microsoft. *Event Tracing for Windows (ETW)* / *Event Tracing Tools*, Microsoft Learn。
8. Microsoft. *Windows Performance Recorder (WPR)* / *Windows Performance Analyzer (WPA)*, Microsoft Learn。
9. Microsoft. *PIX Timing Captures — Analyze CPU and GPU*, Microsoft Learn。
10. Microsoft. *Concurrency Visualizer*, Visual Studio documentation。
11. Intel. *VTune Profiler 2026 — Hotspots Analysis / Threading Analysis / User Guide*。
12. Microsoft Research. *Detours*, official GitHub repository and technical wiki。

---

## 版本紀錄

- **v0.1 / 2026-08-10**：建立 Serialization Gap、L1/L2/L3 visibility、Legacy Acceleration Pipeline、五類 acceleration channel、Game Equivalence Contract、Acceleration Promotion Gate、Epoch Vector、Windows evidence plane、Source/Trace/Binary adapters、12 組可反駁假說與第 6 篇工程元件需求。