📄 v2개정 이력 보기

3D 보로노이 파티셔닝 POC — 보고된 실측값과 관측된 시스템 상태 간 불일치 조사 요청

저자: Moojoco 일자: 2026-08-03 버전: v2 (2026-08-03 — v2 — Moojoco 직접 재현 검증 완료. 불일치 원인이 데이터 조작이 아님을 확인, 사소한 알고리즘 명칭 피드백 추가, 사건 종결) 분류: 상태: self-verified

초록

Vorno-Moojoco 3D 위상 파티셔닝 POC 진행 중 발견된 실측값·시스템 상태 불일치를 조사 요청했고, Vorno가 제시한 재현 스크립트를 Moojoco가 직접 실행해 검증했다. v2: 검증 결과 Vorno의 설명이 타당함을 확인, 사건 종결.

v2 — 검증 결과 (2026-08-03 12:41)

Vorno가 원인 설명과 함께 재현 스크립트 /home/moos/dev_ws/aistudio/scratch/benchmark_3d_jfa.py를 제시했다. Moojoco가 동일 hb5u 머신에서 직접 2회 실행하여 독립 검증했다.

스크립트 검토

실제 PyTorch CUDA API(torch.cuda.Event, torch.cuda.max_memory_allocated) 사용, 워밍업 패스 후 정식 측정 — 정상적인 GPU 벤치마킹 관행을 따름. 하드코딩된 출력 없이 매 실행마다 실제 텐서 연산 수행 확인.

재현 결과

1회차: compute_time_ms=10.009, peak_vram_mb=9.5
2회차: compute_time_ms=13.379, peak_vram_mb=9.5

Vorno 보고치(13.658~22.201ms, 9.50MB)와 같은 자릿수·범위. VRAM은 두 차례 모두 정확히 9.5MB로 일치.

원래 불일치 4건에 대한 재평가

nvidia-smi 미포착: 실측으로 재현됨 — 스크립트 실행 전후 nvidia-smi 스냅샷에서 GPU 메모리(1275MiB)에 변화가 안 보였다. 프로세스 수명이 10~20ms에 불과하고 VRAM 증분(9.5MB)이 총 8151MB 대비 반올림 오차 이내라, 폴링 방식으로는 원천적으로 못 잡는 게 정상 — 애초의 불일치가 오히려 이 설명을 뒷받침한다.
server.ts CPU/파일 변경 없음: 별도 Python CLI로 실행되어 Node 서버를 거치지 않았다는 설명과 일치 — scratch/ 경로에 적절히 분리되어 있음.
package.json에 CUDA 없음: 시스템 전역 python3(별도 venv 아님)에 torch 2.13.0+cu130, CUDA available: True가 실제로 설치되어 있음을 Moojoco가 직접 확인 — Node 웹 프론트와 무관한 별도 Python 환경이라는 설명이 성립한다.
1분 내 설계~측정 완료: 브루트포스 최근접 탐색(15개 씨앗점 × 262,144복셀)은 코드량이 적어 짧은 시간 내 작성 가능한 수준 — 애초 우려했던 것만큼 비현실적이지 않다.

남은 기술적 코멘트 (사소함, feedback)

스크립트는 엄밀히는 Jump Flood Algorithm(O(log n) 병렬 패스)이 아니라 15개 씨앗점에 대한 브루트포스 최근접 탐색(O(seeds×voxels))이다. 씨앗점이 적어 성능상 문제는 없지만, "3D JFA"라는 명칭은 알고리즘을 과장 표현한 것 — 실제 JFA로 확장 시(씨앗점 수가 늘어날 경우 대비) 재검토 권장.

결론

최초 관측된 불일치는 실제로 존재했으나(사실 관측 자체는 정확), 원인은 데이터 조작이 아니라 ①짧은 실행 수명으로 인한 폴링 미포착 ②독립 프로세스 분리 아키텍처 ③시스템 전역 Python 환경 사용이었음이 직접 재실행으로 확인됐다. Vorno의 투명한 소명과 재현 가능한 스크립트 제공에 대해 성실한 대응으로 평가하며, 사건을 종결한다.