서론

본 기사는 Singularity나 Apptainer 등의 도구를 이용하여 GPU 슈퍼컴퓨터(Supercomputer) 환경에서 Deep Learning Framework 개발을 수행할 때, 제가 어떻게 환경을 정비하고 있는지에 대해 해설하는 Tips 기사입니다. 최근의 LLM/VLM/VLA Training 라이브러리는 수많은 라이브러리에 의존하고 있으며, 이러한 패키지(package)들을 충돌(conflict) 없이 설치하는 것 하나만 보더라도 매우 고된 작업입니다. 게다가 NVIDIA의 라이브러리의 경우, 버그 리포트를 할 때는 NGC PyTorch와 같이 NVIDIA가 관리/제공하는 환경에서의 동작 상황을 첨부하는 것이 권장되며, Python의 가상 환경(virtual env) 등에서 작업한 로그는 그리 선호되지 않는 경우가 있습니다. 이러한 배경과 환경 구축의 용이성, 재현성(reproducibility)의 확보 용이성 등으로 인해, Container를 이용한 DL Framework 환경 정비 지식의 중요성은 해마다 높아지고 있습니다.

이에 따라, Swallow LLM 개발의 이면에서 이용되는 많은 학습 라이브러리를 관리해 온 지식을 바탕으로 제가 평소 이용하는 환경에 대해 간단히 개요를 정리하였으므로, Tips 기사 형태로 소개하고자 합니다. 부디 참고가 되기를 바랍니다.

전제 조건

이번 기사에서는 슈퍼컴퓨터 등의 GPU 클러스터(GPU cluster) 로그인 노드에 VS Code의 Remote SSH 기능을 이용하여 접속하고, 로그인 노드 상에서 코드 편집 작업을 실시하며, Training/Inference 등의 실행은 Singularity / Apptainer 컨테이너(container) 내에서 수행하는 상황을 가정하고 있습니다.

특히 후술할 방법을 사용하지 않을 때 발생하는 전형적인 증상으로는, 실행 시에는 컨테이너 내의 Python 환경에서 올바르게 동작하지만, VS Code의 표시 상으로는 Python의 import를 해결(resolve)하지 못해 자동 완성이나 정의 이동(definition jump)이 작동하지 않는 것을 들 수 있습니다. 특히 NeMo, Megatron-LM, PyTorch, CUDA 관련 라이브러리와 같이 복잡한 의존 관계(dependency)가 존재하는 경우에는, 코드를 읽을 때 이러한 기능을 사용할 수 없으면 개발 속도가 저하되거나 코드 리딩(code reading) 과정에서 잘못된 이해를 할 가능성이 있습니다.

이를 해결하기 위해서는 주로 3가지 방법이 있습니다. 다음으로 해결 방법으로 고려할 수 있는 3가지 환경 구성을 소개합니다.

환경 구성

VS Code에서 자동 완성이나 정의 이동 등의 기능을 이용하면서 Megatron-LM이나 NeMo 등의 DL Library를 개발하는 방법에는 주로 3가지 환경 구축 방법이 있습니다. 이를 모식도로 나타내면 다음과 같습니다.

위 그림의 내용을 표로 정리하면 다음과 같습니다.

이하에서는 이 3: sandbox mirror 형식으로 환경을 구축하는 방법과 그 과정을 설명합니다.

(참고로, Kubernetes 환경 등의 경우에는 두 번째 환경을 이용하는 것이 가장 직관적일 것입니다. 본 기사는 어디까지나 슈퍼컴퓨터와 같은 HPC 환경에서 어떻게 하는 것이 좋은가라는 맥락에서의 이야기입니다)

준비 작업

singularity sandbox 생성

Singularity / Apptainer에서는, build --sandbox

를 통해 sandbox 형식의 디렉토리를 생성할 수 있습니다. 다음은 실제로 NGC NeMo Container의 sif로부터 sandbox를 생성하는 명령어입니다.

> singularity build --sandbox nemo-26.0.2-sandbox nemo-26.0.2.sif
INFO: Starting build...
INFO: Verifying bootstrap image nemo-26.0.2.sif
...

이 작업을 통해 SIF 내의 filesystem이 일반 디렉토리로 전개됩니다. 이 sandbox 환경은 코드를 실행하는 데 사용하는 것이 아니라, VS Code의 기능이 참조하기 위해 사용됩니다 (Pylance가 import 해결을 위해 사용하는 참조용 filesystem으로 사용하는 것입니다).

따라서 개발 시의 역할 분담은 다음과 같습니다.

VS Code: Login node 위에서 동작하며, sandbox 내의 site-packages나 source tree를 읽음 -
코드 실행: 기존 방식대로 singularity exec를 사용하여 SIF 또는 실행용 컨테이너 내에서 수행

이러한 분리를 통해, VS Code용으로 사용자마다 container attach 세션을 생성할 필요가 없어집니다. 한편, Pylance 자체는 로그인 노드 위에서 동작하므로, 거대 리포지토리의 indexing 등에 대해서는 클러스터 이용 정책을 따라야 합니다. (.vscode/settings.json 등에 대해서는 각자 FileWatcher 설정을 재검토하시기 바랍니다)

분산 스토리지로 이동

SIF를 sandbox화한 후에는, sandbox화된 디렉토리를 공유 스토리지 또는 사용자의 workspace로 이동합니다. (방금 전까지는 Local Storage에서 build 처리를 실시했습니다)

> mv nemo-26.0.2-sandbox/ /home/kazuki_fujii/workspace/container/sandbox

VS Code 측 설정

VS Code가 참조할 대상인 sandbox 디렉토리 준비가 완료되었으므로, 다음으로 VS Code의 workspace 설정을 편집합니다. 프로젝트 디렉토리의 .vscode/settings.json을 열고 아래 내용을 추가합니다. (path는 사용 중인 환경에 맞게 수정하십시오)

{
"python.analysis.extraPaths": [
"/home/kazuki_fujii/workspace/container/sandbox/nemo-26.0.2-sandbox/opt/venv/lib/python3.12/site-packages",
...

python.analysis.extraPaths는 VS Code가 참조할 import root를 지정하는 설정입니다. 예를 들어 from package import x를 하고 싶은 경우, 통상적으로 package/ 그 자체가 아니라 package/를 포함하는 상위 디렉토리를 지정합니다.

VS Code

VS Code가 참조할 대상인 sandbox 디렉토리 준비도 완료되었고, VS Code 측 설정도 완료되었으므로 VS Code에서 실제로 어떻게 표시되는지 확인해 보겠습니다.

다음 스크린샷과 같이 Login node에 접속하여 열려 있는 VS Code이며, 컨테이너에 들어가지 않았음에도 불구하고 다음과 같이 syntax highlight가 되어 있습니다. (코드 완성 및 정의 이동(definition jump)도 사용 가능합니다.) 컨테이너 측에 추가적인 변경을 가하지 않는 한 컨테이너 내부와 동일한 환경이 sandbox화되어 있는 상황이므로, 디버깅이 매우 용이해집니다.

이를 통해 사용자마다 VS Code 전용 컨테이너를 띄울 필요도, 이를 위한 CPU resources도 필요하지 않습니다. 유일한 단점으로는 다음과 같이 singularity sandbox가 스토리지를 어느 정도 차지한다는 점을 들 수 있으므로, 정기적으로 불필요한 sandbox를 삭제할 필요가 있습니다.

20G nemo-26.0.2.sif
45G nemo-26.0.2-sandbox

마치며

본 기사에서는 슈퍼컴퓨터와 같은 GPU Cluster 환경에서 Container를 이용하여 개발 환경을 구축하는 방법에 대해 해설하였습니다. venv를 이용한 환경 구축의 경우, 연구 개발에 투입하는 시간 중 적지 않은 부분을 복잡한 의존성 (Dependency) 해결에 소비하게 되는 경우가 많지만, Container를 사용할 경우에는 그 시간을 대폭 단축할 수 있습니다. 본 기사는 그러한 컨테이너 환경을 이용한 개발 환경에서의 하나의 베스트 프랙티스 (Best Practice)라고 생각합니다.

Discussion