ZPX 계층적 선택연산 아키텍처 게임 그래픽과 인공지능을 위한 통합 공간선택·연산절감 구조 작성 시점: 2026년 8월

[분석]

zpx_reference.py

15.23KB

ZPX-Selective-Compute-v0.1.zip

21.50KB

아래 백서는 지금까지 대화의 게임 그래픽 최적화 + CPU/GPU 분업 + G17/34/68/136 계층 + 이진벡터/벡터위상/리만위상 + AI 선택연산을 하나의 구현 가능한 구조로 묶은 것입니다. 중요한 것은 증명된 부분, 이번 시뮬레이션에서 확인된 부분, 앞으로 실제 GPU/AI 모델에서 검증해야 할 가설을 분리했다는 점입니다.

ZPX 계층적 선택연산 아키텍처게임 그래픽과 인공지능을 위한 통합 공간선택·연산절감 구조

문서 유형: 공개 기술 백서 / 연구 프로토타입 명세
버전: 0.1
작성 시점: 2026년 8월

---

초록

본 백서는 다음 하나의 원리에서 출발한다.

전체 구조를 미리 알고 있다면, 매 순간 전체를 다시 계산할 필요가 없다. 현재 필요한 부분집합만 선택하여 계산하면 된다.

이를 ZPX의 기존 개념인

[
\boxed{
이진벡터
\rightarrow
벡터위상
\rightarrow
리만위상
}
]

으로 번역하면 다음과 같다.

• 이진벡터: 현재 어떤 영역을 계산할 것인가 — 0/1 활성 마스크

• 벡터위상: 객체·지식·계산 블록의 위치와 방향 및 관계

• 리만위상: 전체 관계가 사전에 구조화된 전역 지도

• G17→G34→G68→G136→G272: 큰 영역에서 작은 영역으로 내려가는 계층적 분할

본 문서는 이 개념을 두 분야에 적용한다.

[
\boxed{\text{게임 그래픽}}
]

에서는

[
전체 게임 공간
\rightarrow
필요 공간
\rightarrow
필요 객체
\rightarrow
GPU
]

로 변환한다.

[
\boxed{\text{인공지능}}
]

에서는

[
전체 계산 공간
\rightarrow
관련 지식/Expert/Token
\rightarrow
활성 계산 블록
\rightarrow
Neural\ Compute
]

로 변환한다.

핵심 목적은 더 강한 하드웨어로 더 많은 계산을 수행하는 것이 아니라, 계산하지 않아도 되는 부분을 계산 전에 제거하는 것이다.

---

1. 가장 쉬운 설명

게임을 하나의 거대한 도시라고 생각한다.

현재 플레이어가 서울역 앞에 있는데 매 프레임마다 대한민국의 모든 건물·나무·자동차를 다시 검사할 필요는 없다.

지도는 이미 존재한다.

따라서

[
\boxed{
전체 지도
\rightarrow
현재 위치
\rightarrow
주변 구역
\rightarrow
현재 보이는 것
}
]

만 찾으면 된다.

AI도 동일하다.

사용자가 CPU와 GPU에 대해 질문했는데 모든 전문 계산영역을 같은 깊이로 사용할 필요는 없다.

[
\boxed{
전체 AI
\rightarrow
컴퓨터
\rightarrow
하드웨어
\rightarrow
CPU/GPU
\rightarrow
필요 Expert
}
]

만 선택한다.

따라서 두 시스템의 공통 공식은

[
\boxed{
전체 공간
\rightarrow
관련 공간
\rightarrow
관련 객체
\rightarrow
실제 계산
}
]

이다.

---

2. ZPX의 세 가지 기본 정의2.1 이진벡터

계산영역 (i)에 대해

[
b_i\in{0,1}
]

를 정의한다.

[
b_i=
\begin{cases}
1,&\text{현재 활성}\
0,&\text{현재 비활성}
\end{cases}
]

전체 상태는

[
B=(b_1,b_2,\ldots,b_N)
]

이다.

게임에서는

[
b_i=1
]

이면 해당 객체 또는 공간을 렌더 후보로 사용한다.

AI에서는

[
b_i=1
]

이면 해당 Expert·Attention block·Memory block 등을 활성화한다.

---

3. 벡터위상

각 객체 또는 계산영역이 단순 ID가 아니라 관계가 있는 좌표를 가진다고 정의한다.

게임 객체:

[
V_i=
(x_i,y_i,z_i,r_i,d_i,\ldots)
]

또는 구면형 표현으로

[
V_i=
(r_i,\theta_i,\phi_i,\ldots)
]

이다.

AI 계산블록이라면

[
V_i=
(e_{i1},e_{i2},\ldots,e_{id})
]

와 같은 embedding 벡터가 된다.

중요한 것은 숫자를 그냥 독립된 값으로 두지 않고

[
\boxed{\text{거리·방향·인접성·관계}}
]

를 검색할 수 있는 좌표로 만든다는 것이다.

---

4. 리만위상 — 프로젝트상의 정의

본 백서에서 리만위상이라는 명칭은 ZPX 프로젝트 내부의 전역 관계지도 개념으로 사용한다.

엄밀한 수학의 Riemann surface와 동일하다고 주장하지 않는다.

구현에서는

[
\mathcal R=
{V_1,V_2,\ldots,V_N}
]

과 그 계층 관계를 갖는 metric/spatial index로 번역한다.

즉,

게임 또는 AI 전체를 하나의 구조화된 공간으로 보고, 현재 필요한 국소 영역만 선택한다.

는 의미다.

---

5. G17 → G34 → G68 → G136의 구현 가능한 정의

본 백서에서는 G17을 다음과 같이 정의한다.

[
G_0=17
]

그리고 각 영역을 이진 분할하면

[
G_k=17\cdot2^k
]

이다.

따라서

[
17
\rightarrow34
\rightarrow68
\rightarrow136
\rightarrow272
\rightarrow544
]

가 된다.

이때 G17이 특별한 하드웨어 가속을 발생시킨다고 가정하지 않는다.

17은 프로젝트의 root partition 수이고, 실제 성능상의 핵심은 이진 계층 분할이다.

---

6. 왜 G 구조가 유용한가

객체가

[
N=10,000,000
]

개 있다고 하자.

전체를 하나씩 검사하는 대신

G17 ├─ Region 0 ├─ Region 1 ├─ ... └─ Region 16

부터 본다.

현재 카메라와 관련된 Region이 3개뿐이라면 나머지 14개의 내부 객체는 열어 볼 이유가 없다.

관련 Region만 다시

[
G34
]

로 분할한다.

다시 필요한 부분만

[
G68
]

로 간다.

따라서

[
10,000,000
\rightarrow
1,000,000
\rightarrow
100,000
\rightarrow
20,000
]

처럼 후보 수를 단계적으로 줄이는 것이 목적이다.

숫자는 장면마다 달라지지만 계층적 제거 원리가 핵심이다.

---

7. 중요한 원칙 — 무조건 G272까지 가지 않는다

깊은 분할 자체에도 비용이 있다.

따라서

[
G17\rightarrow34\rightarrow68\rightarrow136\rightarrow272
]

를 항상 모두 수행하면 안 된다.

셀 (C)에 들어 있는 객체 개수를

[
n(C)
]

라고 한다.

예를 들어

[
n(C)\le16
]

이라면 더 쪼개지 않는다.

또 다음 분할에 의해 감소할 후보 수를

[
\Delta K
]

분할 관리비를

[
C_{\mathrm{split}}
]

이라고 하면,

[
\boxed{
\Delta K\cdot C_{\mathrm{object}}

C_{\mathrm{split}}
}
]

일 때만 분할하는 것이 기본 원칙이다.

따라서 실제 구조는

[
\boxed{
G68\ 기본
+
G136\ 선택
+
G272\ 특수영역
}
]

같은 적응형 계층으로 발전시키는 것이 좋다.

---

8. 게임 그래픽 적용

게임에서 가장 먼저 나눠야 하는 것은

[
World=
StaticWorld+DynamicWorld
]

이다.

StaticWorld

• 산

• 건물

• 도로

• 고정 장식

• 지형

등이다.

위치가 거의 변하지 않으므로 사전 구조화 효과가 크다.

DynamicWorld

• 플레이어

• NPC

• 차량

• 총알

• 움직이는 물체

등이다.

이들은 위치가 바뀔 때 해당 공간 주소만 갱신한다.

---

9. 게임 사전 처리

게임 또는 맵을 로드할 때 정적 객체에 대해 다음을 계산한다.

[
O_i=
(P_i,R_i,M_i,L_i)
]

• (P_i): 위치

• (R_i): bounding volume

• (M_i): mesh/material reference

• (L_i): LOD 정보

그리고

[
O_i\rightarrow G\text{-Tree node}
]

에 등록한다.

한번 완성된 구조는 반복 사용한다.

---

10. 게임 프레임 계산

현재 카메라를

[
C_t
]

라고 한다.

기존의 단순 전체검사는

[
\forall O_i,\quad Visible(C_t,O_i)?
]

이다.

즉 (N)개를 검사한다.

ZPX 방식은

[
\mathcal N_t=
QueryTree(C_t)
]

로 관련 node만 찾는다.

그 안의 객체집합을

[
K_t
]

라고 하면

[
K_t\ll N
]

인 것이 목표다.

그 다음에만 정밀 검사를 한다.

---

11. 게임에서 수학적으로 증명 가능한 부분

공간 node (C) 안의 모든 객체가 하나의 bounding sphere

[
B(c_C,r_C)
]

안에 존재한다고 하자.

카메라 frustum을 (F)라고 한다.

만약

[
B(c_C,r_C)\cap F=\varnothing
]

이면 node 안의 모든 객체 (x)에 대해

[
x\notin F
]

이다.

증명

전제상

[
x\in B(c_C,r_C)
]

이다.

그런데

[
B(c_C,r_C)\cap F=\varnothing
]

이므로 bounding sphere 안의 어떤 점도 (F)에 들어갈 수 없다.

따라서

[
x\notin F.
]

QED.

즉,

[
\boxed{
node\ bounding\ volume이\ 완전히\ 시야\ 밖이면
그 아래 모든 객체를 검사하지 않아도
가시 객체를 잃지 않는다.
}
]

이 부분은 가설이 아니라 보수적 bounding volume이라는 전제 아래 논리적으로 증명 가능하다.

---

12. CPU와 GPU 역할 분담

ZPX의 목표가 저가·중급 GPU에서도 게임을 잘 돌리는 것이라면 CPU에게 픽셀 계산을 시키는 것이 목적이 아니다.

CPU:

[
\boxed{\text{무엇을 계산하지 않아도 되는지 판단}}
]

GPU:

[
\boxed{\text{살아남은 데이터를 병렬 렌더링}}
]

가 좋다.

구조는

Game ↓ CPU ZPX spatial scheduler ↓ G17/G34/G68/G136 search ↓ active region list ↓ candidate objects ↓ GPU fine culling ↓ indirect draw ↓ rendering

이다.

Direct3D 12는 CPU 또는 GPU가 indirect command buffer를 생성할 수 있으며, Microsoft의 공식 ExecuteIndirect 샘플은 compute shader로 보이는 triangle만 골라 해당 draw만 graphics pipeline으로 보내는 구조를 보여준다. 따라서 ZPX의 coarse selection 결과를 기존 indirect drawing 구조와 연결하는 것은 API 구조상 가능하다. (Microsoft Learn)

Vulkan 공식 샘플 역시 mesh shader의 primitive culling과 GPU 기반 multi-draw indirect/frustum culling 예제를 제공한다. 즉 ZPX는 기존 GPU culling을 대체하기보다 그 앞단에서 후보를 더 줄이는 계층으로 개발하는 것이 현실적이다. (Vulkan Documentation)

Unreal Engine 역시 visibility/occlusion culling을 성능 최적화에 사용하며 Nanite는 fine-grained geometry 및 culling 구조를 제공한다. 따라서 ZPX가 실제 가치를 가지려면 이런 기존 구조와 동일 장면에서 직접 비교해야 한다. (Epic Games Developers)

---

13. 프레임 간 변화량

현재 활성 node가

[
A_t=
{31,32,33,34}
]

라고 하자.

다음 프레임에는

[
A_{t+1}=
{32,33,34,35}
]

라고 한다.

그러면 공통부분

[
A_t\cap A_{t+1}

{32,33,34}
]

은 재사용한다.

실제 변경은

[
31\rightarrow OFF
]

[
35\rightarrow ON
]

뿐이다.

따라서

[
\boxed{
A_{t+1}=A_t+\Delta A
}
]

로 계산할 수 있다.

이것이 ZPX에서 말한 위상 변화량 계산을 실제 게임 알고리즘으로 번역한 형태다.

---

14. 이번 게임 합성 시뮬레이션

본 백서와 함께 제공한 Python 참조 구현에서 다음 합성실험을 수행했다.

조건:

• 3D 객체: 200,000개

• 최대 계층: G136

• bounding sphere hierarchy

• 임의 카메라 위치 및 방향

• frustum exact test와 결과 비교

결과:

항목결과

전체 객체	200,000
실제 가시 객체	12,506
계층 node 검사	191
최종 개별 point 정밀검사	68,847
전체 객체 중 개별검사 비율	34.42%
brute-force와 결과 일치	True
구조 생성	0.1364 s
brute-force query	0.0277 s
tree query	0.0037 s

이번 특정 합성 장면과 Python/NumPy 환경에서 query wall time은 대략

[
\frac{0.0277}{0.0037}\approx7.5
]

배 차이가 났다.

이 수치는 실제 게임 FPS 향상률이 아니다.

그러나 다음 두 가지는 확인했다.

1. 보수적 경계를 사용하면 가시 객체를 잃지 않고 전체 객체 검사를 줄일 수 있다.

2. 계층 탐색 자체의 비용보다 제거되는 정밀검사가 충분히 많을 경우 실제 실행시간도 줄어들 수 있다.

---

15. 게임용 복잡도 분석

전체 객체 수를

[
N
]

실제 후보를

[
K
]

방문한 tree node 수를

[
H
]

라고 하면 ZPX query 비용을 단순화하여

[
T_{\mathrm{ZPX}}

H C_n+
K C_o
]

라고 할 수 있다.

전체검사는

[
T_{\mathrm{dense}}

N C_o
]

이다.

따라서 이득 조건은

[
\boxed{
H C_n+
K C_o
<
N C_o
}
]

이다.

다시 쓰면

[
\boxed{
(N-K)C_o

H C_n
}
]

이다.

즉,

제거한 객체 검사비용이 tree 탐색비용보다 커야 한다.

이 식이 ZPX 게임 최적화의 기본 수학 조건이다.

---

16. CPU 사양 문제

ZPX가 고가 GPU를 피하려고 만든 시스템인데 고가 CPU를 요구하면 의미가 없다.

따라서 CPU 구조는

[
\boxed{
고정 전용 코어
}
]

보다

[
\boxed{
짧은 worker jobs
}
]

형태가 적절하다.

기본 목표:

• 4코어: 최소 기능

• 6코어: G68 + 필요한 G136

• 8코어: 권장

• 12~16코어: 추가 prefetch 및 분석

• 12~16코어를 필수로 요구하지 않음

그리고

[
CPU_{\mathrm{free}}
]

가 작아지면 ZPX depth를 자동으로 줄인다.

[
G136\rightarrow G68
]

으로 되돌아간다.

즉 하드웨어가 ZPX에 맞추는 것이 아니라

[
\boxed{
ZPX가 하드웨어 예산에 맞춘다.
}
]

---

17. 인공지능으로 확장

게임에서

[
공간\rightarrow필요\ 객체
]

를 골랐다면,

AI에서는

[
의미공간\rightarrow필요\ 계산
]

을 고른다.

AI 전체 계산 블록을

[
E_1,E_2,\ldots,E_M
]

이라고 하자.

각 expert가 embedding

[
e_i\in\mathbb R^d
]

를 가진다.

입력 query를

[
q\in\mathbb R^d
]

라고 한다.

---

18. AI 이진벡터

각 Expert 또는 연산 블록에

[
m_i\in{0,1}
]

마스크를 만든다.

[
Y=
\sum_{i=1}^M m_iE_i(X)
]

이다.

전체 (M)개를 모두 계산하는 대신

[
\sum_i m_i=K
]

만 사용한다.

목표는

[
K\ll M
]

이다.

이것은 기존 sparse Mixture-of-Experts가 실제로 사용하는 핵심 방향과 맞는다. Switch Transformer는 sparse expert routing을 통해 일부 expert만 활성화하는 구조를 연구했고, DeepSeek-V3 기술보고서는 671B 전체 파라미터 가운데 토큰당 37B를 활성화하는 MoE 구조를 보고한다. (arXiv)

---

19. ZPX AI의 차별화 목표

단순 MoE라면

[
Token
\rightarrow Router
\rightarrow Expert
]

이다.

ZPX 구조는

[
Token
\rightarrow
G17
\rightarrow
G34
\rightarrow
G68
\rightarrow
G136
\rightarrow
Expert
]

와 같은 계층 routing을 연구 대상으로 한다.

즉 모든 expert의 routing score를 처음부터 계산하지 않고,

[
\boxed{
큰 의미영역
\rightarrow
하위영역
\rightarrow
실제 Expert
}
]

순서로 좁힌다.

---

20. AI에서도 수학적으로 정확한 pruning을 만들 수 있다

Expert embedding 집합을 갖는 node (N)이 있다고 하자.

node 중심:

[
\mu_N
]

node 안 모든 expert를 포함하는 반경:

[
R_N
]

를 둔다.

즉 모든 (e_i\in N)에 대해

[
|e_i-\mu_N|\le R_N
]

이다.

query (q)에서 node 안 임의 expert까지의 거리는 삼각부등식에 의해

[
|q-e_i|
\ge
|q-\mu_N|

|e_i-\mu_N|
]

이고,

[
|e_i-\mu_N|\le R_N
]

이므로

[
\boxed{
|q-e_i|
\ge
\max
\left(
0,
|q-\mu_N|-R_N
\right)
}
]

이다.

이 값을

[
LB(q,N)
]

이라고 한다.

---

21. AI exact top-k pruning 증명

현재까지 찾은 (k)번째 가장 가까운 expert의 거리를

[
D_k
]

라고 하자.

어떤 node (N)에 대해

[
LB(q,N)>D_k
]

라면 node 안 모든 expert (e_i)에 대해

[
|q-e_i|>D_k
]

이다.

따라서 node 안에서는 현재 top-k를 이길 expert가 존재하지 않는다.

그러므로 node 전체를 검색하지 않아도 된다.

[
\boxed{
LB(q,N)>D_k
\Rightarrow
Prune(N)
}
]

이 pruning은 선택한 embedding metric에서 exact top-k를 바꾸지 않는다.

이 부분은 명확히 증명 가능하다.

---

22. 무엇이 아직 증명되지 않았는가

여기서 매우 중요한 구분이 있다.

위 알고리즘은

embedding 공간에서 정확한 nearest experts를 찾는다

는 것은 증명한다.

그러나

그 nearest expert들만 계산하면 dense Transformer와 같은 언어능력을 가진다

는 것은 증명하지 않는다.

그것은 학습과 모델 구조의 문제이며 실험 검증이 필요하다.

따라서

[
\boxed{
Routing\ correctness
\neq
Model\ accuracy\ proof
}
]

이다.

---

23. 이번 AI 합성 시뮬레이션

참조 구현에서는

• Expert: 16,384

• Embedding dimension: 16

• 의미 cluster: 64

• top-k: 8

• query: 50회

조건으로 실험했다.

결과:

항목결과

전체 Expert	16,384
평균 실제 거리계산 Expert	1,431.7
전체 Expert 중 직접 검사	8.74%
exact top-k 일치	50 / 50

즉 이번 구조화된 합성 embedding에서는

[
16,384
\rightarrow
1,432
]

정도만 개별적으로 거리 계산하면서도 brute-force top-k와 모든 시험 query에서 동일한 결과를 얻었다.

이것은 neural model 품질시험이 아니라 routing search 자체의 정확성과 탐색감소를 검증한 실험이다.

---

24. AI에서 반드시 알아야 할 실패 조건

Expert embedding이 아무 구조 없이 고차원에 무작위로 퍼져 있다면 hierarchy의 bounding sphere들이 서로 크게 겹칠 수 있다.

그러면

[
LB(q,N)
]

가 충분히 커지지 않아 대부분의 node를 방문하게 된다.

결국

[
K\rightarrow M
]

이 되어 dense scan과 비슷해질 수 있다.

따라서 ZPX-AI가 성공하려면 단순히 tree를 만드는 것으로 부족하다.

[
\boxed{
학습 과정에서 Expert를 실제로 구조화된 계산공간으로 분리해야 한다.
}
]

이것이 매우 중요한 연구 과제다.

---

25. 기존 AI 연구와의 연결

현재 sparse AI 연구도 이미 “모든 것을 계산하지 않는다”는 방향을 검증하고 있다.

Switch Transformer는 sparse expert routing을 연구했고, DeepSeek-V3는 전체 파라미터와 활성 파라미터를 크게 분리한 MoE 모델 사례다. (arXiv)

Routing Transformer는 content 기반 sparse routing으로 attention의 계산복잡도를 표준

[
O(n^2d)
]

에서

[
O(n^{1.5}d)
]

형태로 줄이는 방법을 제안했다. (arXiv)

Mixture-of-Depths는 모든 token에 동일한 FLOPs를 사용하지 않고 layer마다 선택된 token에 계산예산을 동적으로 배분하는 구조를 연구했으며, 논문에서는 일부 post-training sampling 조건에서 50% 이상의 step 속도 향상을 보고한다. (arXiv)

PagedAttention은 LLM의 KV cache를 OS의 paging과 유사하게 block 단위로 관리해 메모리 낭비와 fragmentation을 줄이는 방향을 제시한다. (arXiv)

따라서 ZPX의 핵심 철학 자체,

[
\boxed{
필요한 것만 활성화한다
}
]

는 기존 AI 연구와 정면으로 충돌하지 않는다.

ZPX가 새 연구가 되려면 Expert routing, attention sparsity, memory paging, depth selection을 하나의 계층적 공간주소로 통합할 수 있는가를 보여줘야 한다.

---

26. ZPX Global Compute Map

장기적인 AI 구조는 다음처럼 정의할 수 있다.

[
\mathcal Z=
(
P,T,M,L
)
]

• (P): parameter/expert space

• (T): token/context space

• (M): memory space

• (L): layer/depth space

query (q)가 들어오면

[
Router(q)
]

가

[
A_P,A_T,A_M,A_L
]

이라는 활성영역을 만든다.

실제 계산은

[
Compute(
A_P,
A_T,
A_M,
A_L
)
]

만 수행한다.

이것이 ZPX Global Compute Map의 기본 정의다.

---

27. 게임과 AI를 하나의 알고리즘으로 표현

게임:

[
Universe=Objects
]

AI:

[
Universe=ComputeBlocks
]

공통 과정:

[
\boxed{
BuildHierarchy(Universe)
}
]

그 다음 매 query/frame마다

[
\boxed{
Candidates

SelectRelevant(Hierarchy,Query)
}
]

그리고

[
\boxed{
Result

ExpensiveCompute(Candidates)
}
]

이다.

---

28. 공통 의사코드def process(query, hierarchy): active = [] queue = hierarchy.roots() while queue: node = queue.pop() if definitely_irrelevant(query, node): continue if node.is_leaf(): active.extend(exact_test(query, node.items)) else: queue.extend(node.children) return expensive_compute(active)

핵심은

if definitely_irrelevant(...): continue

한 줄이다.

이 조건이 보수적이고 값싼 판단이어야 한다.

---

29. 게임용 알고리즘PREPROCESS ────────── 1. Load static object positions 2. Divide into 17 root regions 3. Binary split dense regions 4. Store conservative bounds 5. Save hierarchy/cache FRAME ───── 1. Read camera state 2. Test G17 nodes 3. Reject invisible nodes 4. Descend only surviving branches 5. Exact-test uncertain leaves 6. Build active object mask 7. Send candidates to GPU 8. GPU fine-cull + render 9. Cache active set for next frame 10. Next frame updates ΔActive only

---

30. AI용 알고리즘TRAIN / PREPARE ─────────────── 1. Assign or learn expert embeddings 2. Form coarse semantic regions 3. Build hierarchy 4. Store center + conservative radius 5. Train router while enforcing useful specialization INFERENCE ───────── 1. Encode query/token 2. Compare against coarse regions 3. Compute lower bounds 4. Prune impossible regions 5. Descend surviving regions 6. Obtain exact/approx top-k experts 7. Activate selected attention/memory/depth 8. Run expensive neural computation 9. Cache routing state

---

31. CPU/GPU/Memory 통합 구조 INPUT │ ▼ ZPX CONTROL CORE │ ┌──────────────┼──────────────┐ │ │ │ ▼ ▼ ▼ Phase Tree Active Mask Budget │ │ │ └──────────────┼──────────────┘ ▼ CPU coarse │ ▼ surviving work │ ┌────────┴────────┐ ▼ ▼ GPU compute RAM/SSD │ streaming/cache └────────┬────────┘ ▼ RESULT

---

32. 자동 하드웨어 예산 제어

ZPX는 G136을 무조건 사용하는 구조가 되어서는 안 된다.

현재 프레임 CPU 시간을

[
T_C
]

GPU 시간을

[
T_G
]

target frame time을

[
T_B
]

라고 하자.

CPU가 한가하고 GPU가 병목이면

[
Depth\rightarrow Depth+1
]

로 한다.

예:

[
G68\rightarrow G136
]

CPU가 병목이면

[
Depth\rightarrow Depth-1
]

한다.

즉

[
\boxed{
Depth_{t+1}

Controller(
T_C,T_G,T_B
)
}
]

로 자동 결정한다.

AI에서도 동일하게

[
K_{experts},K_{tokens},Depth
]

를 latency/VRAM 예산에 맞춰 조절할 수 있다.

---

33. 무엇이 진짜로 입증되었나수학적으로 입증 가능게임

보수적인 bounding volume이 시야와 완전히 분리되면 내부 객체 전체를 제거해도 가시 객체를 놓치지 않는다.

AI routing

node의 중심·반경을 이용한 거리 lower bound가 현재 top-k threshold를 넘으면 해당 node를 제거해도 metric 기준 exact top-k가 바뀌지 않는다.

---

34. 이번 시뮬레이션에서 확인Game prototype

[
200,000
]

객체에서 brute-force와 ZPX 결과가 정확히 일치했다.

동시에 개별 point 정밀검사는 전체의 약

[
34.4%
]

로 감소했다.

AI prototype

[
16,384
]

Experts 중 평균 약

[
8.74%
]

만 직접 거리 비교하면서 50개 query 모두 exact top-8과 일치했다.

---

35. 아직 입증되지 않은 것

다음 주장은 아직 해서는 안 된다.

[
\boxed{
ZPX가\ BVH보다\ 무조건\ 빠르다
}
]

미증명.

[
\boxed{
G136이\ 모든\ 게임의\ 최적값이다
}
]

미증명.

[
\boxed{
Windows에\ 설치만\ 하면\ 모든\ 기존게임이\ 자동으로\ 빨라진다
}
]

미증명.

[
\boxed{
ZPX\ routing을\ 넣으면\ dense\ AI와\ 동일한\ 정확도를\ 유지한다
}
]

미증명.

[
\boxed{
G17이라는\ 숫자\ 자체가\ 하드웨어\ 속도를\ 높인다
}
]

주장하지 않는다.

---

36. 왜 이 구분이 중요한가

좋은 연구는

아이디어가 좋아 보인다.

와

특정 조건에서 정리가 증명되었다.

와

실제 하드웨어에서 성능이 좋아졌다.

를 구분해야 한다.

본 백서에서는

[
\boxed{
Theory
\rightarrow
Synthetic\ Simulation
\rightarrow
Prototype
\rightarrow
Real\ Benchmark
}
]

순서로 검증한다.

---

37. 다음 실제 게임 검증

같은 장면에서 다음을 비교한다.

1. Brute-force

2. Octree

3. BVH

4. ZPX G17 hierarchy

5. ZPX + BVH hybrid

측정:

[
FPS
]

[
CPU\ FrameTime
]

[
GPU\ FrameTime
]

[
NodeTests
]

[
ObjectTests
]

[
DrawCalls
]

[
VRAM
]

[
MemoryBandwidth
]

[
BuildTime
]

을 기록한다.

---

38. 중요한 후보: ZPX + BVH

ZPX와 기존 구조를 적으로 볼 필요가 없다.

오히려

[
\boxed{
ZPX\ coarse\ phase
\rightarrow
BVH\ local\ traversal
\rightarrow
GPU\ fine\ culling
}
]

구조가 더 강할 수 있다.

즉 ZPX는 전역 구조를 빠르게 자르는 상위층이고 BVH는 국소 geometry를 정확히 찾는 하위층이 된다.

---

39. AI 실제 검증

작은 Transformer 또는 MoE를 준비한다.

Baseline

모든 Expert router score 계산.

ZPX

계층 router로 후보 Expert를 먼저 제거한다.

측정:

• Router FLOPs

• Expert FLOPs

• latency

• GPU utilization

• VRAM

• tokens/sec

• perplexity

• task accuracy

• routing recall

• load balance

을 비교한다.

성공조건은

[
\boxed{
Latency_{ZPX}<Latency_{baseline}
}
]

동시에

[
\boxed{
Quality_{ZPX}\approx Quality_{baseline}
}
]

이다.

---

40. 개발 단계Phase 1 — Python

현재 제공된 참조 코드.

목적:

• 알고리즘 검증

• correctness test

• parameter 탐색

---

Phase 2 — C++ / Rust

공통 ZPX core 작성.

zpx-core/ ├─ phase_tree ├─ spatial_bounds ├─ routing ├─ active_mask ├─ scheduler └─ cache

---

Phase 3 — 게임zpx-game/ ├─ unreal_plugin ├─ dx12_backend ├─ vulkan_backend └─ benchmark_scene

---

Phase 4 — AIzpx-ai/ ├─ pytorch_router ├─ expert_tree ├─ sparse_attention ├─ memory_router └─ benchmark

---

41. 범용 API 예시class ZPXHierarchy { public: void build(const Item* items, size_t count); CandidateSet query( const QueryState& query, const ComputeBudget& budget ); void update( const ItemID id, const PhaseState& newState ); };

게임:

auto visible = hierarchy.query(camera, frameBudget);

AI:

auto experts = hierarchy.query(queryEmbedding, inferenceBudget);

같은 추상화를 사용할 수 있다.

---

42. 게임 이진마스크 예시struct ActiveMask { bool graphics; bool physics; bool ai; bool audio; bool shadows; };

공간 하나에 대해

graphics = 0 physics = 1 ai = 1 audio = 1 shadows = 0

처럼 각 계산을 별도로 끌 수 있다.

따라서

[
\boxed{
Space\ OFF
}
]

뿐 아니라

[
\boxed{
ComputeType\ OFF
}
]

가 가능하다.

---

43. AI 마스크 예시mask = { "experts": [3, 17, 42, 91], "memory": [2, 5, 6], "attention": [0, 4, 8], "depth": 12, }

즉 하나의 query가 필요한 계산지도 자체를 만든다.

---

44. 코드의 핵심 한 줄

게임:

if bounding_region_is_outside_view(node): skip_entire_subtree()

AI:

if node_lower_bound > current_topk_distance: skip_entire_subtree()

결국 두 분야가 같은 사고를 사용한다.

[
\boxed{
\text{하위 내용을 하나씩 보기 전에
상위 공간 전체를 제거할 수 있는지 먼저 판단한다.}
}
]

---

45. 학생에게 설명한다면

도서관에 책이 100만 권 있다고 하자.

“그래픽카드”를 찾으려는데 100만 권의 제목을 전부 읽는 것은 비효율적이다.

먼저

도서관 ↓ 컴퓨터 층 ↓ 하드웨어 구역 ↓ 그래픽카드 책장 ↓ 책

으로 간다.

게임도 같다.

세계 ↓ 도시 ↓ 동네 ↓ 건물 ↓ 보이는 물체

AI도 같다.

전체 모델 ↓ 관련 분야 ↓ 관련 Expert ↓ 관련 Memory ↓ 실제 계산

이것이 ZPX를 가장 쉽게 설명하는 방법이다.

---

46. 개발자에게 설명한다면

ZPX의 본질은 새로운 렌더링 공식 하나가 아니다.

[
\boxed{
Hierarchical\ Conservative\ Work\ Elimination
}
]

이다.

즉,

expensive compute 전에 cheap conservative routing을 수행한다.

가 핵심이다.

게임에서는 spatial bounds.

AI에서는 metric bounds.

memory에서는 paging.

frame에서는 temporal reuse.

모두 동일한 상위 설계 원칙에 들어간다.

---

47. 프로젝트의 가장 강한 부분

가장 중요한 아이디어는

[
\boxed{
성능을 높이기 위해
각 계산을 더 빠르게 만드는 것만 생각하지 않는다.
}
]

이다.

대신

[
\boxed{
그 계산 자체가 필요한가?
}
]

를 먼저 묻는다.

즉

[
ComputeFast
]

보다 먼저

[
ShouldCompute?
]

를 둔다.

---

48. 프로젝트의 가장 위험한 부분

routing 자체가 비싸지면 실패한다.

전체 계산 비용을

[
C_D
]

ZPX를

[
C_Z

C_R+
C_A+
C_M
]

이라고 하자.

• (C_R): routing

• (C_A): active expensive compute

• (C_M): memory/communication

성공 조건은

[
\boxed{
C_R+C_A+C_M<C_D
}
]

이다.

따라서 복잡한 수학을 앞단에 너무 많이 넣어서는 안 된다.

G17/G34/G68/G136 구조는 오히려 매우 값싼 비교와 비트·인덱스 연산으로 구현해야 한다.

---

49. 연구 철학

ZPX를 실제 기술로 만들기 위해서는 다음 원칙을 지켜야 한다.

1. 증명 가능한 것은 증명한다.

2. 측정 가능한 것은 benchmark한다.

3. 가설은 가설이라고 표시한다.

4. 기존 BVH/MoE와 직접 비교한다.

5. 비싼 CPU/GPU를 전제로 하지 않는다.

6. 저가 하드웨어에서도 이득이 있는지 우선 시험한다.

7. routing overhead를 항상 측정한다.

8. 정확도나 그래픽 품질을 희생했으면 반드시 같이 보고한다.

---

50. 최종 통합 공식

ZPX의 공통 구조를 다음 하나로 정리할 수 있다.

전체 상태:

[
\mathcal U
]

query 또는 관측자:

[
q_t
]

사전 hierarchy:

[
H(\mathcal U)
]

활성 부분집합:

[
A_t=
Route(q_t,H)
]

실제 비싼 계산:

[
Y_t=
Compute(A_t)
]

그리고 다음 상태:

[
A_{t+1}

A_t+\Delta A_t
]

이다.

따라서 최종적으로

[
\boxed{
\mathcal U
\overset{offline}{\longrightarrow}
H
\overset{query}{\longrightarrow}
A_t
\overset{expensive}{\longrightarrow}
Y_t
}
]

가 된다.

---

51. 최종 결론

이 백서에서 제시한 ZPX 구조의 핵심은 매우 단순하다.

전체 공간을 미리 구조화하고, 현재 필요 없는 공간은 그 내부까지 계산하지 않는다.

게임에서는

[
\boxed{
World
\rightarrow
Relevant\ Regions
\rightarrow
Visible\ Objects
\rightarrow
GPU
}
]

AI에서는

[
\boxed{
Model
\rightarrow
Relevant\ Compute\ Regions
\rightarrow
Experts/Tokens/Memory
\rightarrow
Neural\ Compute
}
]

이다.

게임의 보수적 공간 pruning과 AI의 metric top-k pruning은 각각 명확한 조건 아래 정확성을 수학적으로 증명할 수 있다.

이번 참조 시뮬레이션에서도

• 게임: 전체 200,000개 중 정밀검사를 약 34.4%로 낮추면서 brute-force와 동일한 결과

• AI: 16,384 Experts 중 평균 약 8.74%만 직접 비교하면서 50/50 query에서 exact top-8 일치

를 얻었다.

그러나 이것이 곧

“ZPX가 기존 게임엔진이나 Transformer보다 이미 우수함이 증명됐다.”

는 뜻은 아니다.

그 다음 단계는 반드시

[
\boxed{
ZPX\ vs\ BVH/Octree/Nanite
}
]

및

[
\boxed{
ZPX\ vs\ Dense/MoE/Sparse\ Router
}
]

실물 benchmark다.

따라서 현재 가장 정확한 연구 결론은 다음이다.

[
\boxed{
\textbf{ZPX의 ‘전체 구조를 알고 필요한 부분만 계산한다’는 원리는
수학적으로 구현 가능한 선택연산 구조이며,
게임과 AI 모두에서 실제 프로토타입 검증을 진행할 충분한 기술적 근거가 있다.}
}
]

그리고 최종 목표는 다음 한 문장이다.

더 비싼 하드웨어로 계산을 밀어붙이는 것이 아니라, 계산하지 않아도 되는 것을 먼저 알아내는 시스템을 만든다.

실행 가능한 참조 코드는 여기 있습니다. Python 3 + NumPy만 사용하며, 게임 G17→G136 공간검색과 AI exact top-k 계층 라우터, 두 합성 시뮬레이션을 한 파일에 넣었습니다.

ZPX 참조 알고리즘 코드 다운로드

이 코드는 현재 연구용 기본 뼈대입니다. 다음 실제 개발 단계에서는 C++/Rust ZPX Core → Unreal/DX12/Vulkan 플러그인과 PyTorch ZPX Router → 작은 MoE/Transformer benchmark 두 갈래로 동일한 공통 구조를 구현하면 됩니다.