ARM64 Ubuntu에서 LLM 스택 굴리기, 컨테이너 한 줄로 안 풀리는 이유

이미지: lifehardmode 자체 제작

엔비디아가 2026년 초 DGX Spark, 그레이스-블랙웰 기반 데스크탑 시리즈를 풀면서 ARM64 Ubuntu가 다시 LLM 운영 환경의 후보로 올라왔다. 가격이 잡히는 머신이 등장한 건 좋은데, 막상 설치하려고 보면 x86 가이드 하나로 안 풀리는 부분이 꽤 많다.

이 글은 ARM64 Ubuntu 24.04에서 vLLM·CUDA·컨테이너 스택을 굴릴 때 막히는 지점과 우회 경로를 정리한다.

ARM64는 이제 LLM에서 보조 아키텍처가 아니다. 그런데 x86 가이드를 그대로 따라하면 절반은 안 돌아간다.

핵심만 보면

• x86용 도커 이미지를 그대로 끌면 즉시 ExecFormatError가 난다
• 일부 CUDA 라이브러리는 ARM64 휠이 늦게 올라온다. 컨테이너로 우회하는 게 빠르다
• 신규 GPU 아키텍처에서는 FP8·BF16 같은 정밀도가 라이브러리에서 미지원이 흔하다

무슨 일이 있었나

엔비디아는 2026년 1분기 DGX Spark를 정식 출시했다. ARM Cortex 기반 Grace CPU + Blackwell GPU 데스크톱 형태로, 개인 개발자도 손에 잡을 수 있는 가격대다. 우분투 24.04 ARM64가 사실상 기본 OS다.

Hugging Face와 vLLM 진영은 ARM64 지원 폭을 빠르게 늘리고 있지만, 출시 직후엔 휠이 안 올라온 라이브러리가 적지 않았다. 5월 시점에선 대부분 정리됐는데, 그래도 한국 개발자가 따라하는 가이드 다수는 여전히 x86 기준이다.

1. 컨테이너 이미지는 multi-arch부터 확인한다

도커 허브에서 끌어오는 이미지 다수가 amd64만 빌드돼 있다. docker pull은 성공하지만 실제 실행 시 exec format error를 뱉는다.

대응은 단순하다.

• docker buildx imagetools inspect <image>로 multi-arch 여부를 먼저 확인한다
• NVIDIA 공식 NGC 이미지(nvcr.io/nvidia/pytorch, nvcr.io/nvidia/tritonserver)는 ARM64 빌드가 따로 있다
• vLLM 공식 이미지는 2026년 초부터 multi-arch가 됐다. 그 이전 태그는 amd64 전용

--platform linux/arm64를 명시하면 multi-arch 이미지에서 ARM 빌드를 강제할 수 있다. 빠진 게 어디인지 추적할 때 유용하다.

2. CUDA·cuDNN은 컨테이너 안에서 푼다

호스트 우분투에 CUDA 툴킷을 직접 설치하는 흐름은 ARM64에서 자주 깨진다. 드라이버는 호스트에 깔되, 툴킷과 라이브러리는 컨테이너 안에 두는 게 훨씬 안정적이다.

흐름은 이렇다.

• 호스트엔 NVIDIA Driver와 nvidia-container-toolkit만 설치
• 작업은 NGC 컨테이너 안에서 진행
• 호환성은 NVIDIA가 컨테이너 단위로 검증한 조합으로 강제된다

이 방식이 정착되면 다음 GPU로 갈아탈 때도 호스트는 그대로 두고 컨테이너만 갈아 끼우면 된다.

3. 신규 GPU 아키텍처는 정밀도 함정이 있다

Blackwell 계열 GB10 같은 신규 아키텍처에선, FP8 같은 신규 정밀도 지원이 라이브러리 단에서 늦게 따라온다. CUDA Compute Capability(sm_*)가 새 값이라, 일부 vLLM·TensorRT-LLM 빌드가 즉시 못 받아준다.

모델 카드에 FP8이라 적혀 있어도, 그 GPU에서 그 라이브러리가 그 정밀도를 받아줄지는 별개 문제다.

체크 순서는 이렇게 잡는다.

• nvidia-smi -q | grep "Compute Cap"로 sm 값을 확인한다
• vLLM·TRT-LLM의 릴리스 노트에서 해당 sm을 지원하는 첫 버전을 찾는다
• 지원되지 않으면 BF16으로 떨어뜨려 일단 돌리고, 정밀도 업그레이드는 다음 릴리스를 기다린다

여기서 무리하게 빌드를 짜맞추려고 하면 일주일을 날린다. 라이브러리 패치 노트만 기다리는 게 합리적이다.

4. Python 휠은 ARM64 build를 명시한다

PyPI에서 끌어오는 라이브러리 다수가 manylinux2014_aarch64 휠을 올린 지 오래되지 않았다. 일부는 소스 빌드만 가능한데, ARM64에서 소스 빌드는 의존성 지옥이 더 깊다.

대처법은 다음과 같다.

• pip install --only-binary :all: <pkg>로 휠이 없으면 즉시 실패하게 만든다
• 휠이 없는 라이브러리는 컨테이너 안에서 소스 빌드 환경을 잡고, 그 결과를 캐시로 박는다
• conda-forge가 ARM64 휠을 더 빠르게 풀어주는 경우가 있어 보조로 본다

이 부분은 한 번 잡아두면 다음부터 머신을 갈아도 재사용된다.

5. 메모리 사용량은 x86보다 빡빡하게 잡는다

DGX Spark처럼 통합 메모리 구조를 쓰는 GPU에서는, CPU와 GPU가 메모리를 공유한다. vLLM의 --gpu-memory-utilization을 x86처럼 0.9로 잡으면 OOM이 자주 난다.

권장 출발점.

• 메인 모델: 0.6 정도부터 시작
• 사이드카(VL OCR 등)를 같이 띄우면 메인은 0.5, 사이드는 0.27 수준
• max-model-len도 16K부터 시작해 단계적으로 늘린다

이 영역은 머신마다 다르다. 출발점만 보수적으로 잡고, nvidia-smi로 실시간 사용량을 보면서 올리면 된다.

과장하면 안 되는 부분

ARM64 LLM 환경은 빠르게 좋아지고 있다. 위 가이드 중 일부는 6개월 안에 시대에 뒤떨어질 수 있다. 특히 PyPI 휠 가용성은 매주 바뀌므로, 막혔을 때마다 라이브러리 릴리스 노트를 다시 보는 게 가장 빠르다.

DGX Spark의 성능 자체도 데이터센터 GPU와 비교할 수준은 아니다. 1인 개발자나 소규모 팀이 자체 모델을 굴리기 위한 머신이지, 프로덕션 서빙용은 아니다. 동시 사용자 수십 명 단위가 넘어가면 클라우드 추론으로 가는 게 비용 효율적이다.

마지막으로, FP8 같은 신규 정밀도가 안 된다고 라이브러리가 안 돌아가는 게 아니다. BF16으로 떨어뜨리면 거의 모든 모델이 정상 작동한다. 메모리는 더 쓰지만 정상이다.

한국 독자가 볼 지점

DGX Spark 정식 유통은 한국에도 2026년 들어 시작됐다. 가격은 수입 부가세 포함 환산 시 한국 카드 결제 기준 1500만 원 안팎으로 형성됐다. 사업자라면 부가세 환급이 들어가지만, 개인은 그 차이만큼 더 무겁다.

전력 소모는 가정용 전기 등급에서 운영 가능한 수준이다. 사무실 전용 220V 콘센트면 충분하고, 별도 PDU나 200V 산업용 전기는 필요 없다. 다만 발열이 큰 워크로드를 길게 돌릴 거라면 책상 옆 환기는 필수다.

지금 체크할 것

• 사용할 컨테이너 이미지가 ARM64 multi-arch인지 미리 확인
• 호스트엔 드라이버만, 작업은 NGC 컨테이너 안에서
• GPU sm 버전과 라이브러리 릴리스 노트 정합성 체크
• 메모리 활용률은 0.6에서 시작해 단계적으로 올리기
• 안 풀리는 정밀도는 BF16으로 떨어뜨려 우선 동작 확보

참고

• NVIDIA NGC Catalog
• vLLM Documentation
• NVIDIA Container Toolkit
• PyTorch Get Started — ARM64
• Hugging Face Hardware Compatibility