Pointcept:BuildMatrix

Pointcept 사전 빌드 휠 매트릭스 (amd64 · arm64)

작성일: 2026-09-28 · 대상: app.cvp.run Pointcept 에이전트 앱의 pointcept-wheelhouse 패키지

개요

Pointcept 에이전트 앱은 레지스트리에 올린 pointcept-wheelhouse만으로 환경을 만든다(로드맵 결정 R5). 호스트에 맞는 wheelhouse가 없으면 소스 빌드로 넘어가지 않고 차단 상태로 멈춘다. 따라서 에이전트가 다운로드만으로 동작하려면 호스트 조합별 wheelhouse를 미리 빌드해서 올려 두어야 한다.

PyPI와 PyG 인덱스에는 CUDA 13(cu130)용 휠과 arm64용 휠이 대부분 없다. 이 문서는 scripts/build_wheels.sh로 미리 빌드할 amd64·arm64 매트릭스와, 실제로 빌드하고 실행하며 확인한 제약을 정리한다.

결론: 조합을 많이 만드는 것보다 accel마다 wheelhouse 하나를 넓은 cuda_arch로 빌드하는 것이 커버리지를 가장 넓힌다. amd64 3~4개, arm64 3~4개면 충분하다.

에이전트의 wheelhouse 선택 규칙

app.cvp.run/cli/src/pointcept/packages.ts의 wheelhouseFits·selectWheelhouse 기준이다.

권장 빌드 매트릭스

모든 행은 python 3.12, torch 2.9.1이다.

† 7.5(Turing)는 에이전트를 먼저 고쳐야 넣을 수 있다. flash-attn 참고.

제외를 권장하는 조합

확인한 제약

torch 휠 인덱스

2026-09-28 기준 download.pytorch.org/whl/<accel>/torch/의 cp312 휠 목록이다.

cu126·cu128·cu129·cu130과 두 arch 모두에 공통으로 있는 버전은 2.9.x, 2.10, 2.11이다. 이 중 검증된 것은 2.9.1뿐이다.

빌더가 거르는 torch 하한(cuda_min_torch): cu126 ≥ 2.6.0, cu128 ≥ 2.7.0, cu129 ≥ 2.8.0, cu130 ≥ 2.9.0, cu132 ≥ 2.12.0.

PyPI · PyG prebuilt 공백

따라서 arm64는 네이티브 패키지 12종을 전부 소스로 컴파일한다. 순수 파이썬 패키지인 pccm, torch-geometric, ocnn만 prebuilt를 쓴다.

패키지별 고정과 패치

flash-attn

• flash-attn 2.x는 sm_80, 90, 100, 120용 cubin만 만든다. 8.6·8.7·8.9는 sm_80 cubin으로 돈다.
• 10.3과 12.1은 Blackwell family가 달라 cubin이 로드되지 않는다. 빌더가 100+PTX, 120+PTX로 빌드해 드라이버 JIT로 도달한다(커밋 c35c4d4, 2026-09-10).
  • DGX Spark(sm_121)에서 빌드되고 동작한다. 2026-09-11 이후 manifest에 compiled flash_attn-2.8.3.post1-…-linux_aarch64.whl로 남아 있고, 2026-09-21 enable_flash=True로 60 epoch 학습을 완주했다.
  • 2026-09-10 이전에는 12.1에 대응하는 arch가 없어 조용히 건너뛰었다.
• 7.5(Turing), 11.0(Thor), Orin만 대상인 빌드는 컴파일할 대상이 없어 건너뛴다.
• 에이전트는 import flash_attn이 되는지로만 flash 사용을 판단한다(scripts.ts). 그래서 flash-attn이 든 wheelhouse의 태그에 7.5를 넣으면 T4에서 flash가 켜져 실패한다. 7.5를 넣으려면 에이전트가 capability ≥ 8.0일 때만 flash를 켜도록 먼저 고쳐야 한다.
• PTX는 첫 로드 때 JIT로 컴파일되므로 CUDA_CACHE_PATH를 쓰기 가능한 경로로 두어야 JIT 비용을 한 번만 치른다.
• 빌드 시간이 가장 긴 패키지다. GB10에서 12.1 하나만 빌드해도 약 18.7분이 걸렸다. cubin이 최대 4개라 arch 목록을 넓혀도 비용이 끝없이 늘지는 않는다.

glibc 호환성

2026-09-28 갱신: build_wheels.sh 기본값이 --os manylinux_2_28로 바뀌어 이 문제는 해결됐다. 아래는 그 전 ubuntu24.04 빌드(현재 레지스트리에 게시된 2026.09.11 포함)의 측정값이다. manylinux_2_28 빌드 참고.

현재 휠은 ubuntu24.04 컨테이너에서 빌드된다. objdump로 확인한 최대 심볼 버전은 다음과 같다(amd64 cu130).

Ubuntu 22.04 호스트(glibc 2.35, GLIBCXX 3.4.30)에서는 cumm·spconv import가 실패한다. 에이전트의 os 태그는 linux뿐이라 이런 호스트를 미리 걸러내지 못한다. 대안은 둘이다.

1. --os ubuntu22.04로 빌드한다. 22.04에서 만든 휠은 24.04에서도 돈다. 아직 빌드해 본 적 없다.
2. 태그에 glibc 버전을 추가하고 wheelhouseFits에서 검사한다.

prebuilt와 태그 정확성

A1·A2처럼 amd64에서 prebuilt spconv·cumm·PyG를 받으면, 그 휠의 arch 집합은 업스트림이 정한 것이라 cuda_arch 태그와 다를 수 있다. 태그를 정확히 맞추려면 --force-source를 쓴다. 대신 빌드 시간이 늘어난다.

업로드 크기

arch 목록을 넓히면 cumm·spconv 휠이 커진다. 관리자 패키지 업로드 릴레이의 Workers CPU 한도 문제(pointcept-agent-app-roadmap.md)가 해결됐는지 먼저 확인해야 한다.

빌드 방법

amd64는 amd64 호스트에서, arm64는 DGX Spark에서 직접 빌드한다. QEMU 교차 빌드는 nvcc가 10~30배 느려서 쓰지 않는다. 기존 단일 arch 결과와 섞이지 않도록 출력 디렉터리를 분리한다. 같은 디렉터리를 쓰면 manifest.txt가 이어 붙는다.

아래 두 반복문은 저장소에 scripts/build_matrix_amd64.sh, scripts/build_matrix_arm64.sh로 들어 있다. 출력은 wheelhouse-wide/(git 무시 대상)로 가고, 뒤에 붙인 인자는 build_wheels.sh로 넘어간다(예: --jobs 8, --dry-run).

# amd64
for spec in "cu126|8.0 8.6 8.9 9.0" \
            "cu128|8.0 8.6 8.9 9.0 10.0 12.0" \
            "cu130|8.0 8.6 8.9 9.0 10.0 10.3 12.0"; do
  bash scripts/build_wheels.sh build --arch amd64 --accel "${spec%%|*}" \
    --torch 2.9.1 --python 3.12 --cuda-arch "${spec#*|}" \
    --force-source --out wheelhouse-wide --keep-going -y
done

# arm64 (DGX Spark)
for spec in "cu126|8.0 8.6 8.9 9.0" \
            "cu128|8.0 8.6 8.9 9.0 10.0 12.0" \
            "cu130|8.0 8.6 8.9 9.0 10.0 10.3 12.0 12.1"; do
  bash scripts/build_wheels.sh build --arch arm64 --accel "${spec%%|*}" \
    --torch 2.9.1 --python 3.12 --cuda-arch "${spec#*|}" \
    --out wheelhouse-wide --keep-going -y
done

A3·B3(cu129)을 넣으려면 같은 형식으로 "cu129|… 10.3 12.1"을 추가한다.

검증과 게시

1. scripts/verify_wheels.sh <wheelhouse 디렉터리>로 설치, import, 커널, PTv3 forward를 확인한다.
2. 가능하면 scripts/verify_mlops.sh로 학습까지 확인한다.
3. 레지스트리에 조합마다 고유한 version으로 게시하고 태그를 붙인다.

{"os":"linux","arch":"arm64","accel":"cu130","torch":"2.9.1","python":"3.12",
 "cuda_arch":"8.0 8.6 8.9 9.0 10.0 10.3 12.0 12.1"}

실제 GPU에서 검증된 것은 sm_120(RTX PRO 2000)과 sm_121(GB10) 둘뿐이다. 나머지 arch는 컴파일만 된 상태이니 패키지 description에 "미검증"이라고 적어 둔다.

실행 조건: arch와 GPU만 맞으면 되는가

그렇지 않다. 위 매트릭스가 모두 빌드됐다고 가정해도 호스트 쪽 조건이 더 있고, 일부 GPU는 휠이 맞아도 에이전트 코드가 바뀌어야 제대로 돈다.

호스트 조건

에이전트가 먼저 바뀌어야 하는 GPU

검증 상태

"빌드됨"과 "실행됨"은 다르다. 실제 GPU에서 end-to-end로 확인한 조합은 amd64 cu130 sm_120과 arm64 cu130 sm_121(mlops에서, Native 고정 포함) 둘뿐이다. 나머지 arch는 nvcc가 컴파일에 성공했다는 것까지만 확인된 상태다. cubin으로 빌드되는 8.0~9.0, 10.0, 12.0은 위험이 낮지만, PTX JIT에 기대는 10.3·12.1은 실기 검증이 필요하다.

정리

Linux, 드라이버 CUDA ≥ accel, glibc 2.28 이상(manylinux 빌드 기준), 인터넷 접속을 갖춘 호스트라면 arch·GPU만 맞으면 설치와 추론까지는 된다. 다만 다음 두 가지가 먼저 필요하다.

1. GB10과 B300: 에이전트에 spconv Native 고정을 추가해야 한다.
2. Ubuntu 22.04·RHEL 호스트: wheelhouse를 manylinux_2_28로 다시 빌드해 게시해야 한다. 지금 게시된 2026.09.11은 ubuntu24.04 빌드다.

단일 번들 배포 (sudo 없이 한 번 받아서 실행)

에이전트가 훈련과 추론에 쓰는 모든 것을 (arch, accel)마다 하나로 묶어, 받아서 풀기만 하면 실행되게 할 수 있다. NVIDIA 드라이버와 glibc는 번들에 넣을 수 없어서 호스트에 있어야 한다. 형식은 AppImage보다 (arch, accel)별 압축 아카이브(tar.zst)를 권장한다.

번들에 넣을 수 있는 것과 없는 것

AppImage를 권장하지 않는 이유

• AppImage는 FUSE로 마운트해야 실행된다. libfuse2가 없는 호스트에서는 sudo apt install libfuse2가 필요해서 목적과 어긋난다. 컨테이너에는 /dev/fuse가 없는 경우가 많다. --appimage-extract-and-run을 쓰면 결국 매번 압축을 푸는 셈이다.
• 번들이 5 GB대라, 실행할 때마다 squashfs를 마운트하는 이점이 없다.
• 에이전트에는 이미 필요한 구조가 있다. 레지스트리의 archive 종류, CLI의 extractAll, 버전 마커, ~/.cache/cvp/<app> 루트가 그대로 쓰인다. 아카이브를 한 번 받아 풀고 bin/python3로 실행하면 sudo, FUSE, 네트워크(PyPI, download.pytorch.org) 어느 것도 필요 없다.

권장 구조

pointcept-runtime-<arch>-<accel>.tar.zst   # 예: arm64-cu130
└─ runtime/
   ├─ python/          # python-build-standalone 3.12. venv가 아니라 이 python의 site-packages에 직접 설치
   │  └─ lib/python3.12/site-packages/   # torch, nvidia-*, Pointcept 휠, 순수 의존성
   ├─ lib/             # 호스트보다 새 공유 라이브러리가 필요할 때만
   ├─ src/pointcept/   # 고정 커밋 소스
   ├─ scripts/         # 추론·학습 워커
   └─ env.sh           # PYTHONPATH, LD_LIBRARY_PATH, TRITON_CACHE_DIR, CUDA_CACHE_PATH

• venv는 쓰지 않는다. pyvenv.cfg와 스크립트 shebang에 절대 경로가 박혀 있어 위치를 옮기면 깨진다. 실행은 항상 python/bin/python3 -m … 또는 스크립트 경로로 한다.
• 크기: 지금 에이전트의 rfdetr·sam2 venv가 풀린 상태로 4.7~5.3 GB다(torch 1.1 + nvidia 2.7 + triton 0.7 GB). Pointcept는 여기에 약 0.2 GB가 더해져 압축 후 약 2.5~3 GB로 예상한다. 권장 매트릭스 6개 조합이면 합계 약 15~18 GB다.
• 가중치는 번들에 넣지 않는다. 모델마다 555 MB이고 선택적이라, 지금처럼 별도 패키지로 둔다.
• 재사용: torch와 nvidia 부분(약 4.5 GB)은 rfdetr·sam2와 같다. 나중에 여러 앱을 번들로 옮긴다면 "(arch, accel)별 torch 베이스"와 "앱 레이어" 두 층으로 나누면 다운로드와 디스크를 공유할 수 있다. 지금은 python 버전이 다르다(rfdetr·sam2는 3.11, Pointcept는 3.12).

남는 호스트 조건

1. Linux, 그리고 (arch, accel)에 맞는 NVIDIA 드라이버. nvidia-smi가 동작해야 한다.
2. 빌드 베이스로 정해지는 glibc 하한 이상 (manylinux_2_28이면 2.28)
3. 디스크 약 8 GB 이상 (압축 파일과 푼 결과)
4. GB10·B300은 에이전트 스크립트에 spconv ConvAlgo.Native 고정이 필요하다. 번들과는 무관한 코드 문제다.

걸리는 점

• 업로드: 수 GB짜리 파일을 레지스트리에 올리려면 관리자 업로드 릴레이의 Workers CPU 한도 문제가 먼저 해결돼야 한다. presigned 직접 업로드로 바꾸는 방법이 있다.
• 검증 방법: 아무것도 설치하지 않은 베이스 이미지에서 받아서 푸는 과정부터 추론·학습까지 돌려 본다. docker run --gpus all ubuntu:22.04, debian:12, rockylinux:9처럼 드라이버만 nvidia-container-toolkit으로 주입한 상태를 말한다. Triton이 컴파일러를 찾는지도 이 단계에서 드러난다.

manylinux_2_28 빌드

manylinux는 glibc 의존을 없애는 방식이 아니다. 오래된 glibc 위에서 빌드해서 하한을 낮추는 방식을 표준화한 것이다. build_wheels.sh는 이제 이것을 기본값(--os manylinux_2_28)으로 쓴다.

manylinux가 실제로 하는 일

결과적으로 glibc 2.28 이상인 모든 Linux(RHEL 8·9, Ubuntu 20.04 이상, Debian 10 이상)에서 동작한다. 이 하한은 torch 휠 자체의 하한(manylinux_2_28)과 같으므로 Pointcept 휠 때문에 생기는 추가 제약은 0이다. 업스트림 spconv-cu124·cu126과 cumm-cu126도 manylinux_2_28로 배포되고 있다.

휠 파일명에 플랫폼 태그가 붙으므로, glibc가 모자란 호스트에서는 pip이 설치 단계에서 이유를 밝히며 거절한다. import 단계에서 알 수 없는 오류로 죽던 문제가 사라진다.

빌드 베이스 이미지

nvidia/cuda:<버전>-devel-rockylinux8은 CUDA 11.8, 12.1, 12.4, 12.6, 12.8, 12.9, 13.0, 13.1, 13.2 모두 amd64와 arm64로 배포된다(Docker Hub, 2026-09-28 확인). CPU 대상은 rockylinux:8을 쓴다.

PyTorch가 자기 휠을 빌드할 때 쓰는 pytorch/manylinux2_28-builder(x86_64)와 pytorch/manylinuxaarch64-builder(aarch64)도 있다. 하지만 아키텍처마다 저장소가 달라서, 한 이름으로 두 플랫폼을 받는 rockylinux8 이미지를 골랐다.

build_wheels.sh의 동작

• --os 기본값은 manylinux_2_28이다. ubuntu24.04, ubuntu22.04도 그대로 쓸 수 있다.
• 컨테이너 안에서는 dnf로 EPEL과 PowerTools를 켜고 gcc-toolset, cmake, git, openblas-devel, sparsehash-devel을 설치한다.
• gcc-toolset 버전은 nvcc가 허용하는 범위에 맞춘다. cu118은 11, cu121은 12, 그 밖에는 13이다.
• 컴파일한 휠과 linux_* 태그의 prebuilt 휠(PyG 등)은 모두 auditwheel repair --plat manylinux_2_28_<arch>를 거친다. prebuilt가 정책을 통과하지 못하면 그 패키지는 소스로 컴파일한다.
• repair에서 제외하는 라이브러리: libtorch*, libc10*, libshm*, libcaffe2*, libgomp*(torch가 제공), libcudart*, libnvrtc*, libcublas*, libcusparse*, libcurand*, libcufft*, libcusolver*, libnvJitLink*, libnvToolsExt*, libcudnn*, libnccl*, libcupti*, libnvshmem*(nvidia-* 휠이 제공), libcuda.so*(드라이버가 제공). 이것들을 휠에 넣으면 torch가 쓰는 것과 다른 사본이 로드돼 충돌한다.
• ROCm은 Ubuntu 이미지만 있다. --os를 주지 않으면 ubuntu24.04로 빌드하고(태그 없음), --os manylinux_2_28을 명시하면 그 조합을 건너뛴다.
• --native 빌드는 호스트의 OS로 빌드하므로 manylinux 태그를 붙이지 않는다.
• 출력 경로는 OS를 구분하지 않는다(<out>/linux-<arch>/<accel>/torch<ver>-cp<py>/). 같은 디렉터리에 다시 빌드하면 예전 ubuntu 휠이 manylinux 휠로 교체된다.

다른 방법과 비교

검증 결과 (2026-09-28, amd64 · cu130 · torch 2.9.1 · sm_120)

--os manylinux_2_28로 pccm, cumm, spconv, torch-scatter, pointops를 빌드했다.

같은 조합을 ubuntu24.04로 빌드했을 때는 cumm이 GLIBC 2.38 / GLIBCXX 3.4.32를 요구했다.

PyG prebuilt는 정책을 통과하지 못했다. torch_scatter-2.1.2+pt29cu130-…-linux_x86_64.whl(data.pyg.org)에 대해 auditwheel이 "too-recent versioned symbols"로 거절했고, 빌더가 소스 컴파일로 넘어갔다. 지금까지 amd64에서 쓰던 PyG prebuilt도 오래된 호스트에서는 깨질 수 있었다는 뜻이다. 대신 amd64 빌드 시간이 PyG 3종 컴파일만큼 늘어난다.

실행 확인 (docker run --gpus all, 아무것도 설치하지 않은 베이스 이미지에 uv, python 3.12, torch 2.9.1+cu130과 휠만 설치):

아직 확인하지 않은 것

• manylinux로 빌드한 flash-attn, swin3d, torch-sparse, torch-cluster, pointops2, pointgroup_ops, pointseg, pointrope
• arm64 (DGX Spark) manylinux 빌드
• gcc-toolset-11·12를 쓰는 cu118·cu121

남은 결정

• glibc: ubuntu22.04로 빌드할지, 태그로 구분할지 → manylinux_2_28 기본값으로 해결
• 7.5(Turing): 에이전트가 capability로 flash 사용을 판단하도록 고친 뒤 태그에 넣을지
• cu129(A3·B3)를 게시할지
• 에이전트(app.cvp.run)에 spconv ConvAlgo.Native 고정을 추가할지. GB10·B300을 지원하려면 필요하다

참고

• Pointcept
• Pointcept fork: scripts/build_wheels.sh, scripts/verify_wheels.sh, scripts/verify_mlops.sh
• mlops: src/geo_mlops/resources/training_runtime/Dockerfile.pointcept, src/geo_mlops/resources/training_runtime/pointcept_semseg.py(GeoSpconvAlgo),docs/plans/36_pointcept_training_runtime_plan.md, docs/plans/50_pointgroup_instance_segmentation_plan.md
• app.cvp.run: cli/src/pointcept/packages.ts, cli/src/pointcept/env.ts, cli/src/pointcept/scripts.ts, docs/plans/pointcept-agent-app-roadmap.md