노드 준비¶

목표: 모든 노드가 다음 상태가 되도록 준비합니다.

RoCE NIC 드라이버와 RBLN Driver가 로드되어 각 노드가 NIC과 NPU를 인식합니다.
RBLN NPU Operator와 dranet이 각자의 DeviceClass(npu.rebellions.ai, dranet)를 게시합니다.
RBLN NPU Operator에서 Rebellions Direct Storage(RDS)가 활성화되어 있고, RDS를 사용할 노드에 rebellions.ai/rds.present=true 레이블이 지정되어 있습니다.

호스트의 RoCE NIC 드라이버¶

각 노드의 호스트 OS에 NIC 벤더의 RoCE 드라이버를 설치하세요. 레퍼런스 노드는 Ubuntu 22.04에서 Broadcom bnxt_en 드라이버와 bnxt_re 드라이버를 사용합니다.

DRA 모드의 RBLN Driver 및 RBLN NPU Operator¶

RBLN NPU DRA 드라이버에 따라 RBLN NPU Operator를 DRA 모드로 설치하세요. 차트는 기본적으로(devices.npu.mode: dra) Dynamic Resource Allocation(DRA)으로 NPU를 요청합니다. RBLN NPU Operator가 DRA 모드가 아니면 Operator는 npu.rebellions.ai DeviceClass를 게시하지 않습니다. 그러면 prefill Pod와 decode Pod가 device class npu.rebellions.ai does not exist 이벤트와 함께 Pending 상태로 남습니다.

이 문서는 DRA 모드를 기준으로 설명합니다. DRA를 사용하지 않는 클러스터는 디바이스 플러그인 모드를 참고하세요.

RBLN Driver는 NPU 디바이스 노드(/dev/rbln*)를 생성합니다. RBLN Driver는 다음 두 드라이버 모드 중 하나로 실행됩니다.

컨테이너 드라이버 모드(RBLN NPU Operator Helm values의 driver.enabled=true): RBLN NPU Operator가 RBLN Driver를 컨테이너로 배포하고 관리합니다. 레퍼런스 노드는 이 모드를 사용합니다.
호스트 드라이버 모드(driver.enabled=false, RBLN NPU Operator 차트의 기본값): 사용자가 RBLN NPU Operator를 설치하기 전에 각 노드의 호스트 OS에 RBLN Driver를 직접 설치합니다.

컨테이너 드라이버 모드와 호스트 드라이버 모드 모두 RDS를 지원합니다. RDS는 RBLN NPU Operator Helm values의 rds.enabled로 따로 활성화합니다(RDS 설정 참고). 드라이버 모드를 선택하는 방법은 NPU 드라이버 설치를 참고하세요. 호스트에 RBLN Driver를 설치하는 절차는 설치 가이드의 "RBLN 드라이버" 절을 참고하세요.

RBLN NPU Operator의 설치와 업그레이드 절차는 RBLN NPU Operator 설치와 RBLN NPU Operator 업그레이드를 참고하세요. NPU 정보를 나타내는 노드 레이블은 RBLN NPU Feature Discovery를 참고하세요.

RoCE NIC용 dranet¶

RoCE NIC 드라이버를 설치한 뒤 dranet을 설치하세요. 검증한 dranet 버전은 소프트웨어 스택과 버전을 참고하세요. dranet은 RoCE NIC을 DRA 디바이스로 게시합니다. dranet은 NIC 벤더의 RDMA 드라이버가 로드된 NIC만 RDMA를 쓸 수 있는 NIC으로 게시합니다.

Pod가 받을 NIC은 차트 values가 아니라 ResourceClaimTemplate(이하 RCT)에 정의합니다. RCT는 dranet DeviceClass를 지정하고, dranet이 게시한 속성으로 NIC 셀렉터를 정의합니다. 다른 RoCE DRA 드라이버를 사용하려면 RCT의 DeviceClass 이름과 셀렉터를 바꾸세요(Unverified). devices.rdma.count는 디바이스 플러그인 모드를 참고하세요.

RDS 설정¶

이 스택에서 LMCache는 prefill Pod 안에서 실행되며 tier 2 KV 캐시를 RDS에 저장합니다. AGG 레시피에서는 LMCache가 decode Pod 안에서 실행됩니다. LMCache가 실행되는 Pod를 배치할 노드마다 RBLN NPU Operator에서 RDS를 활성화하고 노드에 rebellions.ai/rds.present=true 레이블을 지정하세요. RDS 전용 NVMe만 선택하는 방법을 포함한 설정 절차는 RDS 지원을 참고하세요.

서빙 스택은 RDS 디바이스를 따로 요청하지 않습니다. RDS가 활성화된 노드에서는 RBLN NPU Operator의 NPU 할당 플러그인이 NPU를 받는 모든 컨테이너에 RDS 디바이스(/dev/rblnfs*)를 추가합니다. 스택을 설치한 뒤 prefill Pod 또는 decode Pod 안에서 sh -c 'ls /dev/rblnfs*'로 RDS 디바이스를 확인하세요.

containerd LimitMEMLOCK drop-in¶

다음 두 조건을 모두 충족하면 컨테이너의 memlock 제한(ulimit -l)을 unlimited로 올리세요.

devices.rdma.enabled가 기본값인 true입니다.
Pod가 기본 실행 모드인 non-root 모드에서 uid 2000으로 실행됩니다.

P/D 분리에서는 NIXL이 KV 전송 버퍼를 RDMA용으로 등록합니다. 등록한 메모리는 memlock 제한에 포함됩니다.

modelserver의 엔트리포인트는 시작할 때 memlock 제한을 unlimited로 올리려고 시도합니다. 엔트리포인트가 memlock 제한을 올리지 못하면 엔트리포인트는 devices.rdma.enabled 값에 따라 다음과 같이 동작합니다.

devices.rdma.enabled: true이면 엔트리포인트가 오류를 기록하고 종료합니다.
devices.rdma.enabled: false이면 엔트리포인트가 경고를 기록하고 시작을 계속합니다.

노드에서 containerd의 memlock 제한을 올릴 수 없으면 root 모드를 사용하세요(권한 및 실행 모드 참고).

# /etc/systemd/system/containerd.service.d/20-memlock.conf

[Service]
LimitMEMLOCK=infinity

containerd는 Container Runtime Interface(CRI) base runtime spec(base_runtime_spec, 예: /etc/containerd/cri-base.json)의 RLIMIT_MEMLOCK 값을 각 컨테이너에 적용합니다. base runtime spec에 RLIMIT_MEMLOCK이 없으면 containerd는 containerd 프로세스의 제한을 적용합니다. 각 노드에서 다음 순서로 컨테이너의 memlock 제한을 설정하세요.

base runtime spec을 확인하세요. base runtime spec에 RLIMIT_MEMLOCK이 있으면 컨테이너의 제한이 unlimited가 되도록 RLIMIT_MEMLOCK 항목을 수정하세요. 없으면 20-memlock.conf drop-in을 추가하세요.
다시 시작하기 전에 남아 있는 Pod 샌드박스를 제거하세요. containerd는 시작할 때 CRI 상태를 복구합니다. 이름이 같은 Pod 샌드박스가 두 개 있으면 containerd가 비정상 종료됩니다. 그러면 노드가 Ready=False(container runtime is down) 상태가 되고, 클러스터 안에서는 노드를 복구할 수 없습니다.
1
sudo crictl pods --state NotReady # NotReady Pod 샌드박스가 남아 있으면 먼저 sudo crictl rmp <pod-id>로 제거합니다.
sudo systemctl daemon-reload && sudo systemctl restart containerd로 containerd를 다시 시작하세요.

CRI-O를 사용하는 노드에서는 /etc/crio/crio.conf.d/ 아래 drop-in 파일의 [crio.runtime] 테이블에 default_ulimits = ["memlock=-1:-1"]을 설정해 같은 memlock 제한을 적용한 뒤 CRI-O를 다시 시작하세요. OpenShift에서는 MachineConfig로 CRI-O drop-in 파일을 배포하세요. CRI-O 설정은 Unverified입니다. 레퍼런스 검증은 containerd에서 수행했습니다.

스택을 설치한 뒤 다음 명령으로 decode Pod의 modelserver 컨테이너에서 memlock 제한을 확인하세요. base runtime spec에 RLIMIT_MEMLOCK이 있으면 노드의 systemctl show containerd -p LimitMEMLOCK 출력이 컨테이너의 실제 제한과 다릅니다.

kubectl -n <ns> exec deploy/<release-name>-decode -c modelserver -- sh -c 'ulimit -H -l'  # 기대값: unlimited

노드 준비 확인¶

각 노드에서 다음 명령을 실행하세요.

ls /sys/class/infiniband/    # RoCE NIC 드라이버가 로드되었는지 확인합니다.
lspci -d 1eff:              # NPU가 감지되는지 확인합니다(vendor ID 1eff, pci.ids에 1eff의 이름이 없어도 표시됩니다).

RBLN Driver와 RBLN NPU Operator는 RBLN NPU Operator 설치 › 설치 확인에 따라 확인하세요. 호스트 드라이버 모드에서는 노드에서 ls /dev/rbln* /dev/rblnfs*로 NPU와 RDS 디바이스 노드를 확인할 수 있습니다. 컨테이너 드라이버 모드에서는 NPU Pod에서 RDS 장치 확인하기에 따라 Pod 안에서 NPU와 RDS 디바이스 노드를 확인하세요.

디바이스 할당 확인의 항목(1)과 항목(2)로 DeviceClass와 ResourceSlice가 게시되었는지 확인하세요. RBLN NPU Operator와 dranet을 설치한 직후에는 ResourceSlice가 아직 게시되지 않았을 수 있습니다.