H200 NVL Docker Container 초보 탐험기

참고로 나는 Docker Container 에서 CUDA GPU가 Load 된 이미지를 통하여 API를 실행만 하였지

직접 Docker Container 를 설치하거나 HOST Server 와 Container 간의 연동을 작업한적은 없었다.

 자 이제부터 삽질하기에 들어간다. ㅜㅜ

 

먼저 여기서 기본 가정은 인프라 업체에서 GPU 서버 설치와 OS 설치 및 NVIDIA Driver 설치를 완료하고 nvidia-smi 결과가 나온상태에서 시작한다는 점이다.

 

참고로 내가 경험한 GPU 서버는 H200 NVL 이다.  H200 은 어디서 들어봤는데 NVL이 무엇인지 모른다면 당신도 초보

 

첫번째 일단 용어와 기본 개념 부터 정리하고 가야 할듯 하다.

왜 벌써 부터 보기 싫어지는가? ㅋㅋ

왜 처음하면 제일 필요한 기초 지식을 무시하고 하다가 엄청 삽질을 하고 처음으로 돌아오게 되서 다시 기본 개념을 공부하고 있는 자신을 발견하고 있지 않을까 싶다.

 

나도 아무것도 모르면서 GPT 와 대화하고 검색하면서 작성한 내용이라 잘못된 것이 있으면 댓글 부탁드린다. 

 

첫번째로 설정을 셋팅하거나 수정하다보면 다음과 같은 3가지 의문점이 생겨서 알아보게 되었다.

 

1. HOST GPU 와 Docker Container 간의 연결 관계
2. GPU CUDA Version 과 NVIDIA Driver 호환성 관계
3. Docker Container 에서 Cuda 드라이버 인식 관계

근데 위 내용에서 용어 자체도 복잡하니 잘 모르겠다.

하면 내가 찾아본 개념을 적어보고자 한다.

 

1. 컨테이너란 무엇인가요?
   • 컨테이너는 호스트 시스템의 커널을 공유하는 자체 포함 실행 환경이며, 시스템 내의 다른 컨테이너와 (선택적으로) 격리됩니다.
   • 컨테이너는 컨테이너 서버의 커널과 호환되는 모든 애플리케이션이나 데몬을 실행할 수 있는 운영체제별 기술로 이해하는 것이 가장 좋습니다. 컨테이너를 생각할 때는 가상 머신에 대한 기존의 개념을 버리고, 서버에서 실행되는 일반 프로세스를 감싸는 래퍼로 생각하는 것이 좋습니다.
2. Docker compose 는 무엇인가요?
   • Docker Compose는 기존에 매우 번거롭고 오류 발생 가능성이 높았던 다양한 개발 작업을 간소화할 수 있는 매우 유용한 도구입니다. 개발자는 Docker Compose를 활용하여 복잡한 애플리케이션 스택을 신속하게 구축하고, 복잡한 로컬 개발 환경을 설정할 필요 없이 애플리케이션을 컴파일하는 등 다양한 작업을 손쉽게 수행할 수 있습니다.
3. 컨테이너 상세 정보?
   • 각 하위 시스템이 컨테이너 작동 방식에서 어떤 역할을 하는지 이해하는 데 도움이 되는 비유를 들어보겠습니다. 일반적인 컴퓨터를 작업자(프로세스)로 가득 찬 넓은 창고라고 상상해 보세요. 창고에는 공간과 자원이 풍부하지만, 작업자들이 서로 방해하기 쉽고 대부분의 자원은 먼저 확보한 작업자가 사용하게 됩니다.
   • Docker를 실행하고 Linux 컨테이너를 워크로드에 사용하는 것은 마치 창고가 사무실 건물로 바뀌어 각 작업자가 자신만의 사무실을 갖게 된 것과 같습니다. 각 사무실에는 작업자가 업무를 수행하는 데 필요한 모든 것이 갖춰져 있으며, 일반적으로 다른 사람(프로세스)이 무엇을 하고 있는지 크게 신경 쓰지 않고 작업에 집중할 수 있습니다
   • 네임스페이스는 사무실의 벽과 같아서, 프로세스가 특별히 허용되지 않은 방식으로 인접한 프로세스와 상호 작용할 수 없도록 합니다. 컨트롤 그룹은 공과금을 사용하기 위해 임대료를 지불하는 것과 비슷합니다. 프로세스가 처음 시작될 때 CPU와 스토리지 하위 시스템에서 매 주기마다 사용할 수 있는 시간과 특정 시점에 사용할 수 있는 메모리 양이 할당됩니다. 이를 통해 작업자(프로세스)는 필요한 리소스를 확보하면서 다른 프로세스가 예약한 리소스나 공간을 사용하지 않도록 할 수 있습니다. 최악의 시끄러운 이웃을 상상해 보면 사무실 간의 견고한 장벽이 얼마나 중요한지 비로소 깨달을 수 있을 것입니다. 마지막으로, 보안 컴퓨팅 모드, SELinux 및 AppArmor는 사무실 보안과 유사하게, 예상치 못한 문제가 발생하더라도 서류 작업을 하고 사고 보고서를 작성하는 정도의 간단한 조치로 피해를 최소화하도록 합니다.
4. 도커의 구조
   • 우리가 Docker라고 생각하는 것은 API를 통해 공통된 다섯 가지 주요 서버 측 구성 요소로 이루어져 있습니다. 우리는 그 API와 상호작용하는 데 많은 시간을 보냈습니다. 사실 도커는 도커를 구성하는 전체 구성 요소를 조율하는 역할을 합니다. 하지만 컨테이너를 시작할 때, Docker는 컨테이너 인스턴스화를 처리하는 데 의존합니다. 이 모든 것은 과거에는 직접 공정에서 처리되었으나, 그 설계에는 몇 가지 단점이 있었습니다:dockerd containerd runc containerd-shim-runc-v2 docker-proxy dockerd containerd dockerd
     • dockerd 수많은 직업을 가졌고,
     • 모놀리식 런타임 때문에 어떤 구성 요소도 쉽게 교체할 수 없었습니다.
     • dockerd 컨테이너 자체의 수명 주기를 감독해야 했고, 재시작이나 업그레이드를 하면 모든 실행 중인 컨테이너가 모두 사라지기 때문입니다.  
   • 또 다른 주요 동기 중 하나는, 앞서 보여줬듯이 컨테이너가 단순한 추상화가 아니라는 점입니다. 리눅스 플랫폼에서는 AppArmor 또는 SELinux에서 네임스페이스, cgroups, 보안 규칙을 포함하는 프로세스입니다. 하지만 도커는 윈도우에서도 실행되며 앞으로 다른 플랫폼에서도 작동할 수 있습니다. 이 아이디어는 구현과 상관없이 개발자들이 특정 리눅스 시스템 호출에 신경 쓰지 않고 컨테이너, 태스크, 스냅샷과 같은 상위 개념에 대해 생각할 수 있는 표준 계층을 외부에 제시하는 것입니다. 이로 인해 Docker 데몬이 크게 단순화되고, Kubernetes 같은 플랫폼이 Docker API를 사용하지 않고 직접 통합할 수 있게 되었습니다. Kubernetes는 오랫동안 Docker shim에 의존했지만, 현재는 직접 사용합니다.
   • dockerd
     • 서버당 하나씩. API를 제공하고, 컨테이너 이미지를 구축하며, 볼륨, 로깅, 통계 보고 등 고수준 네트워크 관리를 수행합니다.
   • docker-proxy
     • 포트당 하나씩 포워딩하는 규칙이에요. 각 인스턴스는 정의된 호스트 IP와 포트에서 정의된 컨테이너 IP와 포트로 정의된 프로토콜 트래픽(TCP/UDP)을 전달하는 작업을 처리합니다.
   • containerd
     • 서버당 하나씩. 수명 주기, 실행, 쓰기 시 복사 파일 시스템, 그리고 저수준 네트워킹 드라이버를 관리합니다.
   • containerd-shim-runc-v2
     • 컨테이너당 하나씩. 컨테이너에 전달된 파일 디스크립터(예: /)를 처리하고 종료 상태를 보고합니다.stdin out
   • runc
     • 컨테이너를 구성하고 실행하며, 통계를 수집하고 라이프사이클 이벤트를 보고합니다.
   • 구성 요소들(그림 11-2에 나타난 것)을 살펴보고 각각이 어떤 역할을 하는지 살펴보겠습니다:

그림 11-2 도커의 구조

삽질 시작

• 먼저 무엇부터 확인해봐야할지 어떻게 오류에 대한 해결책을 찾을 것인지 GPT 한테 질문을 했다.
  • 답변에 대하여 이것저것 확인해 보니 문제가 없었다.
  • 그러다가 참조 링크를 발견하고 NVIDIA 사이트라서 가장 신뢰할만한 페이지라는 생각이 들었다.

https://docs.nvidia.com/nim/large-language-models/latest/troubleshooting/cuda-driver.html

Troubleshooting CUDA Driver Initialization Failures — NVIDIA NIM for Large Language Models (LLM) and Vision Language Models (V

• 사이트에 들어가서 한국어로 번역을 하니 다음과 같은 내용이 나온다.

CUDA 드라이버 초기화 오류 문제 해결

• NIM은 시작 시 CUDA 드라이버가 초기화될 수 있는지 확인합니다 torch.cuda.init(). 이 검사에 실패하면 시작이 실패하고 다음과 같은 오류가 발생합니다 RuntimeError.일반적인 오류 메시지는 다음과 같습니다.
• "오류 803: 시스템에서 지원되지 않는 디스플레이 드라이버/CUDA 드라이버 조합이 있습니다." — 컨테이너가 호스트의 커널 드라이버와 일치하지 않는 번들 CUDA 호환 드라이버를 로드하고 있습니다. 이것이 가장 일반적인 원인입니다.
• "오류 802: 시스템이 아직 초기화되지 않았습니다." — NVIDIA 커널 드라이버가 로드되지 않았거나 패브릭 관리자가 실행 중이 아닙니다(DGX A100/H100과 같은 NVSwitch 시스템에서 필요).

원인 호스트 드라이버가 마운트되지 않는 일반적인 이유:

• NVIDIA Container Toolkit이 설치되지 않았거나 구성되지 않았습니다.
• 컨테이너 런타임이 nvidia( --runtime=nvidia또는 그와 동등한 값) 으로 설정되어 있지 않습니다.
• CDI 모드가 활성화되었지만 제대로 구성되지 않았습니다.
• LD_LIBRARY_PATH컨테이너 내부에서는 호스트 드라이버보다 호환 라이브러리를 우선시합니다 .

해결 

• NVIDIA 컨테이너 툴킷이 설치 및 구성되었는지 확인하십시오.

nvidia-ctk --version

• 컨테이너가 NVIDIA 런타임을 사용하도록 설정하십시오.

docker run --runtime=nvidia --gpus all ...

• libcuda.so컨테이너 내부에 무엇이 로드되었는지 확인하세요 :경로는 호스트 드라이버(예: /usr/lib/x86_64-linux-gnu/libcuda.so.1)를 가리켜야 하며, 를 가리키면 안 됩니다/usr/local/cuda-*/compat/ .

docker exec ${CONTAINER} python3 -c \
  "import ctypes; ctypes.CDLL('libcuda.so.1'); \
   [print(l.split(None,5)[-1].strip().removesuffix(' (deleted)')) for l in open('/proc/self/maps') if 'libcuda.so' in l][:1]"

• NVSwitch 시스템에서 오류 802가 발생하는 경우 , nvidia-fabricmanager시스템이 실행 중이고 버전이 드라이버와 일치하는지 확인하십시오.

nvidia-smi  # check driver version
nv-fabricmanager --version  # must match
sudo systemctl start nvidia-fabricmanager

• NIM 컨테이너 이미지에는 CUDA 호환 라이브러리가 포함되어 있습니다 /usr/local/cuda-*/compat/. 런타임 시 NVIDIA 컨테이너 툴킷은 호스트의 사용자 공간 CUDA 드라이버를 컨테이너에 바인드 마운트하여 번들로 제공되는 호환 라이브러리를 덮어써야 합니다. 이 메커니즘이 실패하면 컨테이너는 번들로 제공되는 호환 드라이버를 로드하는데, 이 드라이버는 호스트의 커널 드라이버와 일치하지 않을 수 있습니다.

• RuntimeError: CUDA driver failed to initialize: <error message>.
  This may indicate a driver mismatch — ensure the NVIDIA Container Toolkit
  is bind-mounting the host driver into the container.
  Common causes: compat shims loaded instead of host driver,
  or missing nvidia-container-toolkit configuration.
  

우와 처음에는 위에 말이 무슨 외계어인줄 알았다. ㅠㅠ

 

• NVIDIA 컨테이너 툴킷이 설치 및 구성되었는지 확인하십시오. (컨테이너 툴킷은 설치했다.) 

# 오프라인 환경이라 버전을 rocky 9.7 이미지에서 컨테이너를 올려서 직접 다운로드 받음
sudo dnf install -y libnvidia-container1-xxx.x86_64.rpm
sudo dnf install -y libnvidia-container-tools-xxx.x86_64.rpm
sudo dnf install -y nvidia-container-toolkit-base-xxx.x86_64.rpm
sudo dnf install -y nvidia-container-toolkit-xxx.x86_64.rpm
# 컨테이너 런타임 연결 설정
sudo nvidia-ctl runtime configure --runtime=docker

• 여기서 부터 방황함

# docker 설치 버전이 최신이라서 기존 서버에서는 docker 낮은 버전으로 돌아가서 의심함
# 신규로 다운로드 받은 도커 버전은 일단 다음과 같이 설치함

sudo dnf install containerd.io-xxx.x86_64.rpm docker-ce-cli-xxx.x86_64.rpm
docker-ce--xxx.x86_64.rpm docker-buildx-plugin-xxx.x86_64.rpm
docker-compose-plugin-xxx.x86_64.rpm container-selinux-xxx.x86_64.rpm --disablerepo=*

sudo vi /etc/docker/daemon.json
# IP 대역대가 겹쳐서 다른 대역대로 설정
- "bip" : "10.10.0.1/24"
  "default-address-pools" : [
  	{"base": "10.10.0.1/16", "size":24}
  ]
  
sudo systemctl enable --now docker


# 일단 삭제

sudo systemctl stop containerd docker docker.socket

sudo dnf remove -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin 
docker-compose-plugin docker-ce-rooteless-extras

# 디렉토리 삭제 하지 않으면 설정 변경해도 기존 디렉토리에 설치할려고 함
/var/lib/docker (docker 설치파일)
/var/lib/containerd (컨테이너 설치파일 이미지 크기에 따라 사이즈가 엄청 커짐)

# /var 파티션이 작아서 다시 설치
sudo vi /etc/docker/daemon.json
- "data_root": new_directory
sudo vi /etc/containerd/config.toml
- "root": new_directory

# 컨테이너 쿠다 연결이 안되서 하위 버전으로 다시 설치

sudo dnf install containerd.io-xxx.x86_64.rpm docker-ce-cli-xxx.x86_64.rpm
docker-ce--xxx.x86_64.rpm docker-buildx-plugin-xxx.x86_64.rpm
docker-compose-plugin-xxx.x86_64.rpm container-selinux-xxx.x86_64.rpm --disablerepo=*

• 하위 버전을 깔고 해봤는데 똑같은 오류가 발생한다.

어떻게 해야 되지? 나는 누구고 여긴 어디고 무엇을 공부하고 어떻게 해야 하지? ㅜㅜ

• 이것 저것 찾아보다가 가장 기본적인 사실을 발견했다.

NIM ( NVIDIA NIM은 공식적으로 nvcr.io (NVIDIA Container Registry) 또는 nvcr.io/nim 주소에서 다운로드 받은 이미지)이든 vLLM, Ollama 같은 일반 오픈소스 이미지든, 컨테이너 내부에서 GPU를 쓰려면 결국 동일한 기반 기술을 거쳐야 합니다.

1. 호스트 OS에 NVIDIA 그래픽 드라이버가 깔려 있고,
2. NVIDIA 컨테이너 툴킷(NVIDIA Container Toolkit)이 설치되어 있다면,

Docker는 컨테이너 구동 시 호스트의 GPU 자원과 CUDA 라이브러리를 컨테이너 내부로 주입(Injection)해 줍니다. 따라서 이미지의 종류와 상관없이 똑같이 호스트 GPU 가속을 온전히 사용할 수 있습니다.

---

• 컨테이너가 NVIDIA 런타임을 사용하도록 설정하십시오. 
  • 이미지에 run --gpus all 명령어를 넣으라는데 container 를 만들때마다 에러가 나서
  • 그냥 docker compose yaml 에 추가하는 방식으로 넣었다.

deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia          
              count: all              # <-- --gpus all 과 같은 기능
              capabilities: [gpu]

• 덕분에 container 에서 nvidia-smi 를 실행하니 gpu 8장이 다 보이기는 했다.

sudo docker exec -it container_id nvidia-smi

• 근데 역시 에러는 해결되지 않았다.

---

• libcuda.so컨테이너 내부에 무엇이 로드되었는지 확인
  • /usr/lib64/libcuda.so.580.95.05

ㅠㅠ 이상이 없었다.

---

• NVSwitch 시스템에서 오류 802가 발생하는 경우

처음에는 이것 보고 드디어 무언가를 발견했구나 하는 희망이 들었다.

하지만 결국 자세히 알고보니 H200에는 설치 방법에 따라 3가지가 존재했다.

---

🎛️ NVIDIA H200의 3가지 설치 형태 및 종류

구분	H200 SXM (SXM5)	H200 NVL (NVLink PCIe)	H200 PCIe (Standard)
장착 형태	전용 보드(HGX) 일체형 베어메탈 장착	일반 슬롯 장착 + 상단 브릿지 연결	일반 슬롯 장착 (단독 구동)
외형	메인보드에 직접 칩처럼 얹는 모듈형	2개의 카드가 NVLink 브릿지로 묶인 세트	일반적인 단일 그래픽 카드 형태
대역폭(속도)	900 GB/s (초고속 전 영역 통신)	900 GB/s (묶인 카드 간 통신)	128 GB/s (PCIe Gen5 레일 통신)
최대 소비전력	700W (강력한 전력 및 성능)	600W (공랭식 랙 최적화)	350W~450W 내외 (표준 전력)
핵심 용도	초거대 LLM 학습 및 대규모 클러스터	데이터센터 공랭 환경 120B+ LLM 추론	중소규모 인공지능 파인튜닝 및 추론
FabricManger	설치 및 적용 필요	설치 및 적용 필요	설치 X

---

🔍 각 종류별 특징 및 인프라 차이

1. H200 SXM (최고 성능 엔터프라이즈형)

• 특징: 일반 메인보드 슬롯에 꽂을 수 없습니다. NVIDIA가 설계한 전용 베어메탈 베이스보드(HGX H200)에 4장 또는 8장 단위로 공장에서 장착되어 나옵니다. [4, 5]
• 구조: 카드 전체가 하나의 고속 거대 메모리 공간처럼 연동되므로(Full NVLink Fabric), 국가 대표급 AI 연구소나 초대형 클라우드사에서 초거대 AI 학습(Training)을 돌릴 때 무조건 사용합니다. 수랭식 냉각이 동반되는 경우가 많습니다. [6, 7]

2. H200 NVL (데이터센터 공랭 맞춤형)

• 특징: 엔비디아가 일반 기업들의 공랭식 데이터센터 서버 랙 인프라를 겨냥해 설계한 버전입니다.
• 구조: 형태는 PCIe 카드 규격이지만, 2장의 카드를 상단에 전용 NVLink 커넥터(Bridge)로 꽁꽁 묶어서 하나의 유닛처럼 작동하게 만듭니다. SXM급 인프라를 갖추지 못한 일반 데이터센터에서 고성능 LLM 추론 서버를 안정적으로 대량 배치(Scale-Out)할 때 채택합니다. [3, 6, 8, 9]

3. H200 PCIe (범용 단독 설치형)

• 특징: 일반 조립용 서버 메인보드의 PCIe 5.0 슬롯에 표준 그래픽 카드처럼 낱개로 1장씩 자유롭게 꽂아 쓸 수 있는 독립형 카드입니다. [3, 10]
• 구조: 별도의 상단 브릿지 통신 없이 메인보드 대역폭(PCIe Gen5)만 활용하므로 속도는 SXM보다 느리지만, 하드웨어 호환성이 가장 뛰어납니다. 단일 노드 내부에서 소규모 실험, 파인튜닝, 독립 API 서버를 빌드할 때 매우 경제적입니다. [7, 10, 11]

---

나의 경우는 H200 PCIe (Standard) (NLV) 이었다. nvidia-fabricmanager 만 설치하면 되는줄 알았는데 ㅠㅠ

알고보니 설치가 필요없는 상황이었다.

---

이렇게 다시 원점으로 돌아왔다.

 

이렇게 NIM 이미지를 다운받아서 내부에서 설치해서 확인 할 날을 다시 기다리며 이 글을 마치려고 한다.

끝날때 까지 To be continue...