평범하듯, 흔하지 않게

[TIL] CVAT "Cannot connect to the server" 팝업 트러블슈팅 — 디스크 용량 문제와 WSL2 VHDX 확장까지

Hanna 한나 — Mon, 27 Apr 2026 11:27:58 +0900

개요

Docker로 CVAT(Computer Vision Annotation Tool)을 운영하던 중 갑자기 아래와 같은 팝업이 발생했다.

Cannot connect to the server
Make sure the CVAT backend and all necessary services
(Database, Redis and Open Policy Agent) are running and available.
If you upgraded from version 2.2.0 or earlier, manual actions may be needed,
see the Upgrade Guide.

모든 컨테이너는 정상적으로 Up 상태였고, API도 응답하고 있었다.
원인을 찾는 데 예상보다 시간이 걸렸으며, 최종 원인은 WSL2 디스크 포화였다.

환경

OS: Windows 11 + WSL2 (Ubuntu)
CVAT: v2.47.1 (Docker Compose)
Docker Desktop 사용

트러블슈팅 과정

1단계 — 컨테이너 상태 확인

docker ps --format "table {{.Names}}\t{{.Status}}\t{{.Ports}}"

cvat_server, cvat_db, cvat_redis_inmem, cvat_opa 등 모든 컨테이너가 Up 상태.
문제없어 보였다.

2단계 — API 직접 호출

curl http://localhost:8080/api/server/about

{
  "name": "Computer Vision Annotation Tool",
  "version": "2.47.1",
  ...
}

서버 자체는 정상 응답. 브라우저 캐시 문제를 의심하고 하드 리프레시, 시크릿 창 접속을 시도했으나 팝업은 그대로였다.

3단계 — 브라우저 Network 탭에서 실패 요청 확인

DevTools → Network 탭에서 빨간색 요청을 확인:

GET /api/server/health/?format=json&org=
Status: 500 Internal Server Error

/api/server/health/ 가 500을 반환하고 있었다.
CVAT 프론트엔드는 이 엔드포인트를 주기적으로 폴링하며, 실패 시 팝업을 표시한다.

4단계 — health 엔드포인트 내부 호출

컨테이너 외부에서 호출하면 500이 떨어지지만, 컨테이너 내부에서 호출하면 상세 내용을 볼 수 있다.

docker exec cvat_server curl -s "http://localhost:8080/api/server/health/?format=json"

{
  "Cache backend: default": "working",
  "Cache backend: media": "working",
  "DatabaseBackend": "working",
  "DatabaseBackend[default]": "working",
  "DiskUsage": "warning: 1b4b9cbff009 98.1% disk usage exceeds 90%",
  "MemoryUsage": "working",
  "OPAHealthCheck": "working"
}

범인은 DiskUsage였다.
CVAT는 디스크 사용량이 90%를 초과하면 ServiceWarning을 raise하고, Django가 이를 500으로 처리한다.

서버 로그에서도 동일한 traceback 확인:

health_check.exceptions.ServiceWarning:
warning: 1b4b9cbff009 98.1% disk usage exceeds 90%

5단계 — 디스크 사용량 확인

df -h

Filesystem   Size   Used  Avail  Use%  Mounted on
/dev/sdd    1007G   938G   19G   99%   /

WSL2 가상 디스크(/dev/sdd)가 1007GB 중 938GB를 사용 중이었다.

docker system df

Images        16    13    49.24GB    23.94GB (48%)
Local Volumes 29     9   141.9GB     4.356GB (3%)
Build Cache   50     0   172.7MB   172.7MB

Docker 미사용 이미지에서 약 24GB를 회수할 수 있었다.

해결 방법

방법 1 — Docker 리소스 정리 (단기)

# 미사용 이미지 삭제 (~24GB 확보)
docker image prune -a -f

# 빌드 캐시 삭제
docker builder prune -f

# 미사용 볼륨 삭제 (cvat_ 접두사 볼륨은 삭제 금지)
docker volume prune -f

이 작업으로 19GB → 65GB로 여유 공간이 확보되었으나,
94%로 여전히 임계값 초과 상태였다.

방법 2 — WSL2 VHDX 디스크 확장 (근본 해결)

WSL2는 VHDX 가상 디스크 파일을 사용하며, 이 파일 크기 자체를 확장할 수 있다.

VHDX 파일 위치 확인 (PowerShell)

ls "$env:LOCALAPPDATA\Packages\CanonicalGroupLimited*\LocalState\ext4.vhdx"

여러 개가 나올 경우 파일 크기가 큰 것이 현재 사용 중인 배포판이다.

WSL 종료

wsl --shutdown

diskpart로 VHDX 확장

diskpart

DISKPART> select vdisk file="C:\Users\<사용자명>\AppData\Local\Packages\CanonicalGroupLimited.Ubuntu_79rhkp1fndgsc\LocalState\ext4.vhdx"
DISKPART> detail vdisk
DISKPART> expand vdisk maximum=1500000
DISKPART> exit

maximum 값의 단위는 MB이며, 1500000 = 1500GB.

주의: diskpart 명령어는 반드시 PowerShell이 아닌 diskpart 프롬프트 내에서 실행해야 한다. PowerShell에서 직접 입력하면 오류가 발생한다.

WSL 재시작 후 파일시스템 확장

sudo resize2fs /dev/sdd

df -h /

Use%가 90% 미만으로 떨어지면 CVAT 팝업이 자동으로 사라진다.

방법 3 — 임계값 조정 (임시 우회)

근본 해결이 어려운 상황이라면, CVAT의 디스크 경고 임계값 자체를 높일 수 있다.

# docker-compose.override.yml
services:
  cvat_server:
    environment:
      DISK_USAGE_MAX: "99"

docker compose down && docker compose up -d

데이터 손실 없이 팝업을 없앨 수 있으나, 근본적인 디스크 관리는 별도로 필요하다.

정리

단계	확인 방법	결과
컨테이너 상태	`docker ps`	모두 정상
API 응답	`curl /api/server/about`	정상
실패 요청 특정	브라우저 Network 탭	`/api/server/health/` 500
health 상세 내용	컨테이너 내부 curl	DiskUsage 98.1%
디스크 확인	`df -h`	WSL2 /dev/sdd 99%
해결	VHDX 확장 + resize2fs	정상

CVAT의 "Cannot connect to the server" 팝업은 네트워크나 서비스 연결 문제가 아닌 디스크 용량 부족이 원인일 수 있다. /api/server/health/ 엔드포인트를 컨테이너 내부에서 직접 호출하는 것이 원인 특정의 핵심 포인트였다.

TIL: CUDA_LAUNCH_BLOCKING=1 이 운영 환경에서 TIMEOUT을 유발한 원인 분석

Hanna 한나 — Wed, 25 Feb 2026 16:53:03 +0900

환경: RTX 5090 (Blackwell, sm_120) / PyTorch 2.8.0+cu129 / ultralytics YOLOv8 / FastAPI

상황

1초에 1번씩 이미지를 분석하는 서버에서 갑자기 아래와 같은 TIMEOUT 에러가 발생했다.

[ENGINE] timeout
time1: 3.003807306289673

정상적으로 동작할 때는 time1이 약 0.02초(20ms)였는데, 특정 요청부터 3초가 넘어가기 시작했다.

원인 찾기

실제 hang 위치 특정

각 단계별 로그를 추가했다.

print("[DEBUG] predict start")
torch.cuda.synchronize()
print("[DEBUG] pre-forward sync complete")

result = self.model(im, ...)

torch.cuda.synchronize()
print("[DEBUG] post-forward sync complete")

로그 결과:

[DEBUG] predict start
inference!!
visualize!!
im shape: torch.Size([1, 3, 384, 640])
im dtype: torch.float16
im nan: False
im inf: False
[DEBUG] pre-forward sync complete
← 여기서 hang. post-forward sync complete 출력 안 됨

NMS(postprocess)가 아닌 self.model(im, ...) forward pass 자체에서 hang이 발생하고 있었다.

입력 텐서 조건도 정상(shape 동일, nan/inf 없음)이었는데 간헐적으로 특정 이미지에서만 hang이 발생했다.

원인

코드 함수 상단에 아래 코드가 있었다.

os.environ['CUDA_LAUNCH_BLOCKING'] = "1"

CUDA_LAUNCH_BLOCKING이란

NVIDIA 공식 문서 (CUDA Environment Variables 5.2.3.1):

The environment variable specifies whether to disable or enable asynchronous kernel launches. Disabling asynchronous execution results in slower execution but is useful for debugging. It forces GPU work to run synchronously from the CPU's perspective. This allows CUDA API errors to be observed at the exact API call that triggered them, rather than later in the execution. Synchronous execution is useful for debugging purposes.

1: Disables asynchronous execution.

0: Asynchronous execution (default).

한마디로 디버깅 전용 옵션이다. 운영 환경에서는 반드시 제거해야 한다.

기본 동작 비교

CUDA_LAUNCH_BLOCKING=0 (기본값, 비동기):
    CPU: 커널A 요청 → 즉시 반환 → 커널B 요청 → 즉시 반환 → 커널C 요청
    GPU: [커널A 실행 중...] [커널B 실행 중...] [커널C 실행 중...]
    → CPU가 GPU 완료를 기다리지 않고 계속 진행

CUDA_LAUNCH_BLOCKING=1 (동기):
    CPU: 커널A 요청 → 완료 대기 → 커널B 요청 → 완료 대기 → 커널C 요청
    GPU: [커널A] → [커널B] → [커널C]
    → CPU가 각 커널이 완료될 때까지 블로킹

왜 RTX 3060(개발 서버)에서는 괜찮았고 RTX 5090(운영 서버)에서만 문제가 생겼을까

개발 서버(RTX 3060)에도 동일하게 CUDA_LAUNCH_BLOCKING=1이 설정되어 있었는데 문제가 없었다.

아래는 추측 기반 분석이며 공식 문서로 완전히 검증된 내용은 아니다.

추측 이유 1. SM 수 차이로 인한 동기화 부담

RTX 3060 (Ampere, sm_86): SM 28개
RTX 5090 (Blackwell, sm_120): SM 170개 이상

CUDA_LAUNCH_BLOCKING=1은 모든 SM이 완료될 때까지 CPU가 대기한다. SM 수가 6배 이상 차이나므로 동기화 대기 지점이 훨씬 많아지고 CPU 블로킹 시간이 길어져 deadlock 조건이 형성되기 쉽다.

추측 이유 2. Thread Block Cluster로 인한 동기화 복잡도

RTX 3060 (Ampere):
    Thread Block 단위 실행
    동기화 구조 단순
    CUDA_LAUNCH_BLOCKING=1과 충돌 없음

RTX 5090 (Blackwell):
    Thread Block Cluster 단위 실행 (여러 Block을 묶어서 처리)
    여러 SM이 서로 통신하며 실행
    CUDA_LAUNCH_BLOCKING=1로 강제 직렬화 시
    → SM 간 통신 대기 + CPU 동기 대기 중첩
    → deadlock 조건 더 쉽게 형성

추측 이유 3. 드라이버 성숙도 차이

RTX 3060 출시: 2021년 → 드라이버 4년간 수십 번 패치 → 안정화 완료
RTX 5090 출시: 2025년 → 드라이버 초기 단계 → 미해소 엣지 케이스 존재 가능

CUDA_LAUNCH_BLOCKING=1과 새 아키텍처 조합에서 발생하는 엣지 케이스가 아직 드라이버에서 해소되지 않았을 가능성이 있다.

해결 방법

아래 한 줄을 제거(또는 주석 처리)했다.

# os.environ['CUDA_LAUNCH_BLOCKING'] = "1"  ← 제거

교훈

CUDA_LAUNCH_BLOCKING=1은 CUDA 오류 디버깅 시 일시적으로만 사용해야 한다. 운영 코드에 남아 있으면:

GPU 연산 전체가 직렬화되어 성능이 저하된다.
멀티스레드 환경에서 deadlock이 발생할 수 있다.
특히 최신 GPU(Blackwell 등)에서 예상치 못한 hang이 간헐적으로 발생할 수 있다.

디버깅이 끝나면 반드시 제거하자.

참고 링크

[TIL] AWS EC2에서 학습하기

Hanna 한나 — Tue, 9 Dec 2025 15:02:01 +0900

1. EC2 고속 저장소의 비밀: /dev/mapper와 LVM

AI 학습 인스턴스에서 보이는 /dev/mapper 경로는 고성능을 위한 스토리지 구성의 핵심

1.1. /dev/mapper의 정의와 역할

정의: /dev/mapper는 Linux Device Mapper (장치 매퍼) 시스템에 의해 생성된 가상 장치 파일
비유: 여러 개의 작은 창고'(디스크)를 하나로 합쳐서 쓰는 '가상의 대형 창고 관리 시스템'
역할: 하위의 물리적 장치(/dev/nvme0n1 등)와 상위의 파일 시스템 사이에 위치하며, 물리적 디스크를 논리적으로 조합하고 관리할 수 있게 해주는 Linux 커널 프레임워크.

1.2. vg.01-lv_ephemeral의 구성 원리

/dev/mapper/vg.01-lv_ephemeral은 Device Mapper의 주요 기술인 LVM (Logical Volume Manager)을 사용하여 구성된 논리 볼륨(Logical Volume).

LVM 역할: 여러 개의 물리적 디스크를 하나의 볼륨 그룹(vg.01)으로 묶고, 그 안에서 유연하게 크기를 조절 가능한 논리 볼륨(lv_ephemeral)을 생성.
EC2 활용: AWS Deep Learning AMI(DLAMI) 계열 인스턴스는 여러 개의 NVMe SSD (인스턴스 스토어)를 LVM으로 묶어 단일하고 거대한 고성능 작업 공간(예: 3.5T)을 /opt/dlami/nvme 등에 제공합니다.

휘발성 주의 이 볼륨은 인스턴스 스토어를 기반으로 하기에 이름에 ephemeral이 포함되어 있으며, EC2 인스턴스를 중지(Stop)하면 이 공간에 저장된 모든 데이터는 영구적으로 삭제됨

1.3. LVM의 아키텍처 이점과 오버헤드

동적 용량 관리 및 유연성 (Flexibility)
- 논리 볼륨(LV)의 크기를 시스템을 중단하지 않고 (온라인 상태로) 자유롭게 확장 또는 축소할 수 있음.
- AI 프로젝트의 데이터셋 크기가 예상치 못하게 증가할 경우, 인스턴스에 새 디스크(PV)를 추가하고 볼륨 그룹(VG)에 편입시킨 후, /dev/mapper LV의 크기를 즉시 확장하여 다운타임을 최소화함.
통합된 스토리지 풀 관리 (Consolidation)
- 크기가 다르거나 종류가 다른 여러 물리적 볼륨(PV)을 하나의 볼륨 그룹(VG)으로 통합하여, 사용자나 애플리케이션에게 단일하고 거대한 연속적인 저장 공간으로 제공
- 여러 개의 개별 NVMe 인스턴스 스토어 디스크를 하나로 묶어 3.5TB와 같은 대용량 고속 캐시 공간으로 만들어, 데이터 로더가 단일 경로로 대규모 데이터셋을 접근하게 함

1.4. 단일 디스크 사용 대비 잠재적 오버헤드

LVM은 관리 계층을 추가하므로, 다음과 같은 미세한 오버헤드가 발생할 수 있습니다.

I/O 경로의 복잡성 증가 (Mapping Lookup)
- LVM은 논리적 주소(LV)를 물리적 주소(PV 내의 오프셋)로 변환하는 매핑 테이블(Mapping Table) 조회가 필요함.
- 이 조회 과정에서 아주 미세한 수준의 CPU 및 메모리 오버헤드가 발생할 수 있음
초기 설정 및 관리 복잡도
- 단일 디스크와 달리, LVM은 VG 생성, LV 생성, 파일 시스템 포맷 및 마운트 등 초기 설정 단계가 복잡하며, 문제 발생 시 디버깅이 더 어려움(운영 오버헤드)

2. YOLO 학습을 위한 S3 데이터 파이프라인 최적화

S3에 있는 학습 데이터를 효율적으로 사용하려면, S3를 직접 마운트하는 것을 피하고 '복사-학습-백업' 전략을 사용해야 함

2.1. S3 직접 마운트를 피해야 하는 이유

S3는 객체 스토리지(Object Storage)로, Linux 파일 시스템(POSIX)과 호환성이 낮고, AI 학습에 필요한 무작위 접근(Random I/O) 성능이 매우 떨어짐. 특히, 딥러닝 데이터 로더는 수많은 작은 파일(이미지/어노테이션)을 랜덤하게 읽고, 메타데이터(파일 목록, 크기 등)에 빈번하게 접근함.

성능 저하: S3는 객체당 네트워크 지연 시간(Latency)이 높아, 수백만 개의 작은 파일을 반복적으로 GET 요청할 때 발생하는 총 지연 시간이 NVMe SSD의 로컬 접근 속도와 비교할 수 없을 정도로 길어저 심각한 병목 현상을 초래함.
파일 시스템 불일치: 파일 잠금 등 일부 기능 부재로 학습 프레임워크에서 예상치 못한 오류를 유발할 수 있음.
- 원자적 이름 변경 (Atomic Rename) : S3는 Rename 명령이 없으며, 파일을 복사하고 원본을 삭제하는 **두 단계 작업(Copy & Delete)**으로 에뮬레이션됨. 이는 학습 중 임시 파일 처리나 체크포인트 저장 시 지연 시간(Latency)을 크게 증가시킴
- 파일 잠금 (File Locking) : S3는 기본적으로 파일 잠금 메커니즘을 제공하지 않음. s3fs 같은 도구는 임시 파일 등으로 이를 에뮬레이션하려 하지만, 불안정하거나 성능이 크게 저하됨. 딥러닝에서 동시 접근 시 데이터 충돌 위험이 존재

2.2. 권장되는 학습 데이터 워크플로우

인스턴스 시작 시 (복사):
- aws s3 sync 명령어를 사용하여 S3의 학습 데이터를 고속 볼륨(/opt/dlami/nvme 등)으로 복사합니다.
- 명령어 예시: aws s3 sync s3://[S3_버킷]/[데이터_경로]/ /opt/dlami/nvme/
학습 진행 시 (활용):
- YOLO 모델은 /opt/dlami/nvme에 복사된 데이터를 읽으며 초고속으로 학습
학습 완료/중간 (백업):
- 휘발성 위험에 대비하여, 학습 결과물(모델 체크포인트)은 다시 S3로 업로드하거나 영구 EBS에 저장하도록 설정해야 함

GraphRAG를 실무에 적용하기 위한 고려요소

Hanna 한나 — Sun, 12 Oct 2025 20:18:16 +0900

본 포스팅은 아래 유투브 방송을 기반으로 정리하였습니다.

https://www.youtube.com/live/zHN2jDZHvI0?si=6qdOcUgd0PvbX_ke

GraphRAG의 경우 기술 자체의 매력도 있지만, 빅테크의 기술 마케팅 활동, 마이크로 소프트의 GraphRAG 기술 공개, (확실하진 않지만) 팔란티어 사례로 주목을 받고 있는 것으로 판단됨

하지만, GraphRAG의 경우 비용 문제가 큰 걸림돌인데, 그 이유는 특정 기준을 만족할 때까지 계속 반복되는 현상 때문임. 따라서, 엔티티의 정확도를 기반으로 비용이 달라질 수 있음. 따라서, 문서간의 데이터나 관계 파악이 중요하지 않는다면 기존 RAG를 사용하는 것이 더 나을 수 있음. 특히 관계 정의가 부실하다면 기존 벡터 기반 RAG보다 성능이 더 떨어질 수 있음.

1. GraphRAG를 제대로 활용하기 위해 중요한 것

GrpahRAG에서 중요한 요소 : 1.온톨로지 2. 스키마 설계임

온톨로지는 일종의 합의된 세계관, 공통된 체계로 볼 수 있음. 예를 들어 '핀테크 A가 고객B에게 C를 제공한다'의 경우 A, B, C는 노드, 제공한다는 엣지가 됨. 더 나아가 명시적 참조, 언어적 애매모호함을 해결하는 것이 중요한데, 정규 표현식, 키워드 뿐만 아니라 LLM을 활용하여 의미를 분석하고 연결하는 작업도 수행하고 있음.

1. 문제 정의 및 목표 명확화

기존 벡터 RAG의 한계를 명확하게 인지하고, 그래프 구조가 유리한 문제 상황을 정의

특히 멀티 홉 쿼리나 추론 복잡성이 높은 질문 등 관계 기반 추론이 필요한 경우 GraphRAG를 도입. 성공 기준은 기술 구현이 아닌 상용화되어 유저에게 서비스 되는 것

2. 관계 중심 문서 선정

모든 문서(데이터)에 GraphRAG를 적용할 필요는 없으므로, 관계의 중요성이 높은 문서(보험, 법률 관련)부터 시작

3. 온톨로지 및 스키마 협의

그래프에서 노드 간의 관계 생성은 주관적인 해석이 많이 들어가므로, 엔지니어, 분석가, 도메인 전문가 간의 합의를 이루는 것이 필수적. 이 합의를 체계화 하는 도구로 온톨로지가 사용되고, 스키마는 노드가 가질 라벨과 프로퍼티를 정의

예를 들어, 제조 공정에서 결함 추적 사례로, 현장 전문가와 분석가가 정의하는 연결의 의미가 다를 수 있기 때문에, 주관적인 차이를 극복하고 관계를 정의하는 온톨로지부터 만드는 것이 성공의 열쇠

또한, 요구 사항이 바뀌면 스키마를 계속 진화되는데 기존 엔티티를 업데이트 진행하여 수행해야 함

4. 구체화된 엔티티 추출

이 지점에서 LLM은 하드 또는 소프트 프롬프팅으로 나누게 됨. 하드 프롬프팅은 추출된 서브 그래프를 텍스트 형태로 LLM에 직접 주입하는 방식이며, 소프트 프롬프팅은 그래프 인코드(GNN)을 사용하여 노드와 엣지의 피처를 벡터로 변환하여 사용하는 방식으로, 구조적인 정보를 직접 넣어주는 방식임. 최근에는 이 두 가지를 활용하여 텍스트 정보랑 구조 정보를 함께 활용하는 것이 많음

결국, 공통적으로 얼마나 정확하게 관계를 추출하고, 필요한 정보를 어떻게 효율적으로 찾아내느냐가 제일 중요함.

현실적으로 현장에서는 특히, 표 데이터를 어떻게 그래프로 구조화할 것인가 같은 문제가 있음. 이를 해결하기 위해서, 문서나 데이터 간의 복잡하고 암묵적인 연결성을 명시적으로 구축하는데 중점을 둔 관계 중심 접근과 LLM이 표를 요약하고, 이 요약을 노드 정보로 활용하여 검색 효율성을 높이는 요약 중심으로도 해결하고 있음. 특히, 요약 중심에서는 LLM 기반 프롬프팅 엔지니어링이 중요함. 다양한 참조 표현을 LLM을 통해 학습을 시켜, 참조 표현 사전을 구축해서 다양한 형태의 참조 관계를 잡아내기도 함. (문서가 업데이트 되면 참조 관계가 변경될 수 있음)

2. Text-to-Cypher

사용자의 자연어 질문을 GDBMS가 이해하고 처리할 수 있는 질의 언어닌 Cypher로 자동 변환하는 Text-to-Cypher가 시스템의 가장 큰 병목 현상임. 기존 벡터DB는 사용자의 쿼리를 임베딩하여 벡터 검색을 수행하는 것으로 충분하지만, GDBMS는 둘 중 하나는 수행해야 함.

1. 사용자 쿼리를 임베딩하여 그래프 DB내 벡터와 조화하는 방식

2. 사용자 쿼리에서 엔티티를 추출하여 엔티티 기반의 키워드 검색을 수행하는 방식

궁극적으로 GDB는 유저 쿼리를 Cypher로 변환하여 데이터를 조회해야 하므로, 이 변환 및 조회 과정에서 병목 현상이 발생함. 이는 Text2SQL이 격는 어려움과 유사한 맥락임.

결국 Text-to-Cypher의 성공률을 높이기 위해서는

1. 프롬프트 엔지니어링 및 Few-shot

LLM이 복잡한 그래프 스키마를 이해하고 정확한 Cypher를 생성하도록 돕기 위해서는 정교한 프롬프트 엔지니어링이 필수로, few-shot을 통해 스키마를 인지 시켜줘야 함. few-shot 예시로는 특정 기간과 같은 수치형 데이터를 처리하는 방식, 그리고 필터링을 위한 내용 등이 반영되어야 함.

성공적인 퓨삿 예시는 사용자가 직접 만들지 않고도, LLM에 요청하여 초벌 Cypher를 생성하게 한 뒤, 이를 튜닝하는 방식으로 효율적으로 로 구축 가능

2. 라우팅 전략

단일 프롬프트가 모든 그래프 검색 시나리오를 커버하는 것은 비현실적이므로, 쿼리에 따라 사전에 설정된 Text-to-Cypher 프롬프트를 활용하여 라우팅하는 것이 합리적.

라우팅을 위해 사전에 쿼리마다 셋업하고, 유저의 쿼리, 사전에 설정된 텍스트 투 사이퍼 프롬프트, 그리고 그 결과물(혹은 예시)이 함께 들어가야 LLM이 거기에 맞게 쿼리를 번형해줌.

이 라우팅 방식은, 기존 유저의 쿼리를 분석하여 쿼리의 유사성, 길이, 그리고 난이도 등을 기준으로 설정

3. 결국 DB 최적화

LLM이 성공적으로 Cypher 쿼리를 생성했더라도, 대규모 데이터 환경에서는 DB 자체에서 성능 병목이 발생할 수 있음. LangGraph와 같은 에이전트 도구를 활용하여 Text-to-Cypher의 생성-검증-보정 과정을 체계적으로 수행. 또한, 메모리 증설, 인덱싱, 가비지 컬렉터 튜닝, 실행 계획 강제 적용 등에 따라 데이터베이스 차원의 쿼리 튜닝이 병행되어야 함

3. 평가 시스템 선정

GraphRAG의 고유한 추론 능력을 정량적으로 평가하기 위해, 기존의 평가 방식에 의존하기 보다 추론 복잡성에 따라 쉬움/중간/어려움으로 나눈 특화 데이터셋을 자체적으로 구축하는 것이 필요함. 또한, 실질적인 비즈니스 지표로도 평가 필요함

4. GDBMS 선정 기준

1. 생태계 : DB-Engines 랭킹, LangChain/LlamaIndex와의 통합 여부, 지원하는 언어(Cypher, Gremlin 등)을 확인

2. 성능 검증 : LDBC(Linked Data Benchmarking Council)에서 제공하는 표준화된 벤치마크 결과를 참고하여 스케일 팩터(데이터량) 대비 비용 및 성능 예측 필요

3. 적합성 : 데이터의 성격(CRUD 빈도, 인메모리 필요 여부) 등을 고려

주요 GDBMS 예시 : Neo4j(생태계 우수, 엔터프라이즈 비용 높음), KuzuDB(디스크 기반, 확장성 좋음), TigherGraph(매트릭스 형태로 속도 빠름)

[TIL] PyTorch + DeepSpeed 학습 중 !block->expandable_segment_ 에러 해결

Hanna 한나 — Mon, 25 Aug 2025 21:20:41 +0900

문제 상황

환경: AWS g5.12xlarge, CUDA 12.4, PyTorch 2.4 + DeepSpeed ZeRO-3 + Flash-Attn + InternVL3-2B
에러 증상: 학습 도중 !block->expandable_segment_ 발생

RuntimeError: !block->expandable_segment_ INTERNAL ASSERT FAILED at "../c10/cuda/CUDACachingAllocator.cpp":2586

특징:
- 특정 step에서 GPU OOM으로 터짐
- expandable_segments=True 설정 시 주로 재현
- DeepSpeed ZeRO-3 + gradient checkpointing이 켜진 상태에서 자주 발생

원인 분석

PyTorch CUDA allocator의 expandable segment 모드( PYTORCH_CUDA_ALLOC_CONF="expandable_segments=True" )와
DeepSpeed ZeRO-3의 parameter offloading / all_gather hooks가 충돌하면서 발생.
특히 Vision Transformer(ViT) 쪽 torch.utils.checkpoint.checkpoint가 재진입(reentrant) 모드일 때,
backward 시 동일 레이어 재호출로 allocator 내부 블록 확장 로직이 꼬이는 현상이 주요 트리거.

해결 방법

Allocator 설정 제거 : export PYTORCH_CUDA_ALLOC_CONF="max_split_size_mb=32,garbage_collection_threshold=0.8" 제거
ViT 체크포인트 비재진입 설정
- 기존: torch.utils.checkpoint.checkpoint(self.layer_fn, hidden_states)
- 수정: torch.utils.checkpoint.checkpoint( self.layer_fn, hidden_states, use_reentrant=False)
- 비재진입 모드로 바꾸면, backward 시 함수 재호출을 피하고 메모리 충돌 위험이 줄어듦.

PYTORCH_CUDA_ALLOC_CONF=expandable_segments=True는 CUDA 메모리 단편화를 줄여주는 대신, 큰 연속 메모리 블록을 재할당할 수 없게 강제하는 옵션으로, expandable_segments=True로 설정하면 여러 작은 청크로 나눠 쓰는 대신, 어떤 연산이 갑자기 큰 텐서를 요구하면 !block->expandable_segment_ 오류가 발생
unset PYTORCH_CUDA_ALLOC_CONF하면, CUDA allocator가 기본 동작(필요시 큰 블록을 할당/재할당)으로 돌아가서, 큰 텐서 요청도 받아들이지만, 대신 메모리 단편화가 생길 수 있고 OOM 위험은 올라감
그런데 실제로는 expandable_segments=True로 터지는 원인은 ZeRO-3 all-gather 버퍼 + ViT flash-attn이 동시에 큰 contiguous 블록을 요구하기 때문으로, unset하였을 때 PyTorch allocator가 큰 블록을 새로 잡아줘서 OOM 없이 넘어감

TAO Toolkit 설치방법

Hanna 한나 — Tue, 12 Aug 2025 17:10:23 +0900

그 어디에도 문서가 친절하게 되어 있지 않아서, 작성해본다.

- 환경 : WSL Ubuntu 24.04LTS, CUDA 12.4, Docker Desktop 설치 완료

1. https://org.ngc.nvidia.com/ 계정 생성 및 API key 받기

2. 환경 설치

$ git clone https://github.com/NVIDIA/tao_tutorials.git
$ cd tao_tutorials/setup
$ bash quickstart_launcher.sh --install

이런 식으로 docker login nvcr.io 를 하라고 나온다.

이 때, 다시 dockr login을 하고, 생성한 API key를 입력한다

$ docker login nvcr.io
Username: $oauthtoken
Password: <Your Key>

3. 실행하기

로그인을 하고, jupyter notebook 또는 VS Code을 실행하여서 tutorial 대로 진행을 하면 된다

$ cd ../notebooks/tao_launcher_starter_kit/

참고자료

- TAO Toolkit 문서 : https://docs.nvidia.com/tao/tao-toolkit/text/overview.html

Overview — Tao Toolkit

Overview TAO focuses on training, finetuning, and optimizing computer vision foundation models. Users can select one of 100+ pretrained vision AI models from NGC, and can fine-tune and customize on their own dataset without writing a single line of code. T

docs.nvidia.com

[TIL] PyTorch CUDA Out of Memory(OOM) 오류 해결기 (feat. VLM 모델 학습)

Hanna 한나 — Tue, 5 Aug 2025 10:27:54 +0900

개발 환경:

- AWS g5.12xlarge (NVIDIA A10G 24GB x4)

- CUDA 12.8

- PyTorch 2.7.1

1. 문제 사항

Vision-Language Model (VLM)을 학습하는 과정에서 다음과 같은 CUDA OOM 오류가 지속 발생

[rank1]: torch.OutOfMemoryError: CUDA out of memory. Tried to allocate 2.70 GiB. GPU 1 has a total capacity of 22.07 GiB of which 2.06 GiB is free. Including non-PyTorch memory, this process has 20.00 GiB memory in use. Of the allocated memory 19.39 GiB is allocated by PyTorch, and 149.28 MiB is reserved by PyTorch but unallocated. If reserved but unallocated memory is large try setting PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True to avoid fragmentation. See documentation for Memory Management (https://pytorch.org/docs/stable/notes/cuda.html#environment-variables)

2. 원인 분석

GPU 메모리 부족: 2.70 GiB 할당 요청 중, 사용 가능한 메모리는 2.06 GiB
PyTorch 메모리 할당: 이미 19.39 GiB가 PyTorch에 의해 사용 중
단편화(Fragmentation) 문제: 일부 메모리는 reserved 상태지만 실제 할당되지 않아 할당 실패

3. 해결 과정

1. expandable_segments:True 설정

단편화 완화를 위해 PyTorch 환경변수 추가:

export PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True

PyTorch는 GPU 메모리를 다음 두 단계로 관리함:

예약(reserved): GPU에서 큰 덩어리의 메모리를 미리 확보
할당(allocated): 이 예약된 영역 중 일부를 실제 연산에 사용하도록 나눔

학습 중 layer별로 GPU 메모리 할당/해제가 반복되면서, 남은 메모리가 작고 쪼개진 조각으로 남게 되는데, 이때 PyTorch가 연속된 일정 크기의 메모리를 요청할 경우, 실제 총 남은 용량은 충분해도 할당이 실패할 수 있음.

PyTorch 2.0 이후에는 PYTORCH_CUDA_ALLOC_CONF=expandable_segments:True 옵션을 통해 단편화 문제를 줄일 수 있는 개선된 allocator를 사용할 수 있음. 이 옵션은 기존에 고정된 크기의 allocator segment를 사용하는 대신, 동적으로 확장 가능한 segment를 도입함

그 결과 더 유연한 메모리 할당이 가능하고, 단편화에 강함. 또한, 연속 메모리 블록을 찾기 쉬워짐. 결과적으로 메모리 할당 실패(=allocation failure)가 줄어들고, 모델 학습 중 OOM 발생 빈도도 감소하게 됨

2. gc.collect() + torch.cuda.empty_cache() 사용

CUDA 메모리를 자주 할당(allocate)/해제(free)를 하면 GPU 드라이버 레벨에서 오버헤드가 크기 때문에, PyTorch는 자체 캐싱 메커니즘을 통해 관리함.

gc.collect() : Python의 Carbage Collector(GC)를 수동으로 실행시켜, 더 이상 참조되지 않는 파이썬 객체를 메모리 해제하는 역할을 함. PyTorch에서 Tensor는 파이썬의 객체이기도 하고, GPU 메모리를 소유한 C++의 객체이기도 함. del tensor를 하더라도 참조 카운트가 0이 아니면 즉시 해제되지 않기 때문에, gc.collect()를 호추랗여 파이썬 인터프리터가 순환 참조된 객체까지도 강제로 해제하게 만드는 역항르 함

torch.cuda.empty_cache() : GPU 메모리 중 PyTorch가 캐시용으로 보유하고 있는 메모리 블록을 해제하여, CUDA 드라이버에 반환하는 역할. 실제 GPU 상의 메뮤리를 줄일 수 있음. 다만, allocated된 메모리는 해제 하지 않고, 캐시용으로 보유하던 메모리만 반환하는 역하을 진행

단독으로 torch.cuda.emtpy_cache()만 호출하면, 아직 참조되고 있는 Tensor 때문에 PyTorch가 여전히 allocated 메모리를 유지함. 따라서 gc.collect()로 객체를 해제하여 참조를 끊고, 메모리를 반환 조건 충적 후 empty_cache()로 GPU 메모리를 실 반환하므로써 OOM 문제를 해결

gc.collect() + torch.cuda.empty_cache() 조합의 경우, 적절한 타이밍에 위치를시켜야 효과적임

큰 텐서들이 소멸한 후
다음 GPU 연산이 시작되기 전
반복적 학습 스텝 간에 일시적 피크 메모리가 문제가 될 때

나의 경우에는 HuggingFace Traniner.train() 내부에서, 학습이 진행중인 step에서, forward -> bachward로 수행하는 loss.backward() 중 OOM이 발생하였다. 한 step 처리 중 backward pass 계산 그래프가 너무 커져서 GPU VRAM을 초과한 상태였다. 근본적인 해결책은 max_token_length를 줄이거나, gradient checkpointing를 적용해서 해결을 해야 했다.

먼저, 적용하기 전에 초기 캐시 메모리 및 expandable_segments:True 적용하고, Trainer 인스턴스를 완전히 구성하고 나서, 불필요하게 남아 있을 수 있는 메모리를 수동 정리하여 일단 돌아가게는 했다.

    trainer = Trainer(
        model=model,
        args=training_args,
        train_dataset=train_dataset if training_args.do_train else None,
        eval_dataset=None,
        tokenizer=tokenizer,
        data_collator=collator,
    )

    import gc
    gc.collect()
    torch.cuda.empty_cache()

이렇게 정리하여, forward/backward 전에 더 많은 여유 메모리를 확보하여 전체적인 VRAM 사용은 줄이도록 하였다.

accelerate, deepspeed, transformers 버전

Hanna 한나 — Mon, 4 Aug 2025 18:51:30 +0900

진짜 vLM 라이브리 안 맞으면 고생하는 accelerate, deepspeed, transformers

torch==2.4.1+cu124 또는 torch=2.7.1+cu128에서 돌아가는 것을 확인했다.

내가 찾은 최적의 버전

accelerate==0.34.2
deepspeed==0.15.4
transformers==4.37.2

[TIL] AWS EC2 재시작 시 NVIDIA 드라이버와 CUDA가 삭제되는 이슈

Hanna 한나 — Mon, 4 Aug 2025 11:55:44 +0900

1. 이슈 상황

AWS EC2 인스턴스(Ubuntu 24.04, g5.12xlarge)를 인스턴스를 중지(Stop) 후 재시작(Start)했더니 드라이버가 사라지는 현상 발생.

nvidia-fabricmanager-570 패키지가 apt에서 재설치되지 않음 (no installation candidate)
드라이버 관련 의존성 충돌로 인해 nvidia-smi가 작동하지 않거나 드라이버 자체가 제거됨
CUDA는 설치되어 있는데 GPU 장치를 인식하지 못함

2. 원인 분석

# 현재 설치된 드라이버/라이브러리 확인
dpkg -l | grep -E 'nvidia|cuda'

$ dpkg -l | grep -E 'nvidia|cuda'

ii  cuda-cccl-12-8                                 12.8.90-1                               amd64        CUDA CCCL
ii  cuda-cccl-12-9                                 12.9.27-1                               amd64        CUDA CCCL
ii  cuda-command-line-tools-12-8                   12.8.1-1                                amd64        CUDA command-line tools
ii  cuda-command-line-tools-12-9                   12.9.1-1                                amd64        CUDA command-line tools
ii  cuda-compiler-12-8                             12.8.1-1                                amd64        CUDA compiler
ii  cuda-compiler-12-9                             12.9.1-1                                amd64        CUDA compiler
ii  cuda-crt-12-8                                  12.8.93-1                               amd64        CUDA crt
ii  cuda-crt-12-9                                  12.9.86-1                               amd64        CUDA crt
ii  cuda-cudart-12-8                               12.8.90-1                               amd64        CUDA Runtime native Libraries
ii  cuda-cudart-12-9                               12.9.79-1                               amd64        CUDA Runtime native Libraries
ii  cuda-cudart-dev-12-8                           12.8.90-1                               amd64        CUDA Runtime native dev links, headers
ii  cuda-cudart-dev-12-9                           12.9.79-1                               amd64        CUDA Runtime native dev links, headers
ii  cuda-cuobjdump-12-8                            12.8.90-1                               amd64        CUDA cuobjdump
ii  cuda-cuobjdump-12-9                            12.9.82-1                               amd64        CUDA cuobjdump
ii  cuda-cupti-12-8                                12.8.90-1                               amd64        CUDA profiling tools runtime libs.
ii  cuda-cupti-12-9                                12.9.79-1                               amd64        CUDA profiling tools runtime libs.
ii  cuda-cupti-dev-12-8                            12.8.90-1                               amd64        CUDA profiling tools interface.
ii  cuda-cupti-dev-12-9                            12.9.79-1                               amd64        CUDA profiling tools interface.
ii  cuda-cuxxfilt-12-8                             12.8.90-1                               amd64        CUDA cuxxfilt
ii  cuda-cuxxfilt-12-9                             12.9.82-1                               amd64        CUDA cuxxfilt
ii  cuda-documentation-12-8                        12.8.90-1                               amd64        CUDA documentation
ii  cuda-documentation-12-9                        12.9.88-1                               amd64        CUDA documentation
ii  cuda-driver-dev-12-8                           12.8.90-1                               amd64        CUDA Driver native dev stub library
ii  cuda-driver-dev-12-9                           12.9.79-1                               amd64        CUDA Driver native dev stub library
ii  cuda-gdb-12-8                                  12.8.90-1                               amd64        CUDA-GDB
ii  cuda-gdb-12-9                                  12.9.79-1                               amd64        CUDA-GDB
ii  cuda-keyring                                   1.1-1                                   all          GPG keyring for the CUDA repository
ii  cuda-libraries-12-8                            12.8.1-1                                amd64        CUDA Libraries 12.8 meta-package
ii  cuda-libraries-12-9                            12.9.1-1                                amd64        CUDA Libraries 12.9 meta-package
ii  cuda-libraries-dev-12-8                        12.8.1-1                                amd64        CUDA Libraries 12.8 development meta-package
ii  cuda-libraries-dev-12-9                        12.9.1-1                                amd64        CUDA Libraries 12.9 development meta-package
ii  cuda-nsight-12-8                               12.8.90-1                               amd64        CUDA nsight
ii  cuda-nsight-12-9                               12.9.79-1                               amd64        CUDA nsight
ii  cuda-nsight-compute-12-8                       12.8.1-1                                amd64        NVIDIA Nsight Compute
ii  cuda-nsight-compute-12-9                       12.9.1-1                                amd64        NVIDIA Nsight Compute
ii  cuda-nsight-systems-12-8                       12.8.1-1                                amd64        NVIDIA Nsight Systems
ii  cuda-nsight-systems-12-9                       12.9.1-1                                amd64        NVIDIA Nsight Systems
ii  cuda-nvcc-12-8                                 12.8.93-1                               amd64        CUDA nvcc
ii  cuda-nvcc-12-9                                 12.9.86-1                               amd64        CUDA nvcc
ii  cuda-nvdisasm-12-8                             12.8.90-1                               amd64        CUDA disassembler
ii  cuda-nvdisasm-12-9                             12.9.88-1                               amd64        CUDA disassembler
ii  cuda-nvml-dev-12-8                             12.8.90-1                               amd64        NVML native dev links, headers
ii  cuda-nvml-dev-12-9                             12.9.79-1                               amd64        NVML native dev links, headers
ii  cuda-nvprof-12-8                               12.8.90-1                               amd64        CUDA Profiler tools
ii  cuda-nvprof-12-9                               12.9.79-1                               amd64        CUDA Profiler tools
ii  cuda-nvprune-12-8                              12.8.90-1                               amd64        CUDA nvprune
ii  cuda-nvprune-12-9                              12.9.82-1                               amd64        CUDA nvprune
ii  cuda-nvrtc-12-8                                12.8.93-1                               amd64        NVRTC native runtime libraries
ii  cuda-nvrtc-12-9                                12.9.86-1                               amd64        NVRTC native runtime libraries
ii  cuda-nvrtc-dev-12-8                            12.8.93-1                               amd64        NVRTC native dev links, headers
ii  cuda-nvrtc-dev-12-9                            12.9.86-1                               amd64        NVRTC native dev links, headers
ii  cuda-nvtx-12-8                                 12.8.90-1                               amd64        NVIDIA Tools Extension
ii  cuda-nvtx-12-9                                 12.9.79-1                               amd64        NVIDIA Tools Extension
ii  cuda-nvvm-12-8                                 12.8.93-1                               amd64        CUDA nvvm
ii  cuda-nvvm-12-9                                 12.9.86-1                               amd64        CUDA nvvm
ii  cuda-nvvp-12-8                                 12.8.93-1                               amd64        CUDA Profiler tools
ii  cuda-nvvp-12-9                                 12.9.79-1                               amd64        CUDA Profiler tools
ii  cuda-opencl-12-8                               12.8.90-1                               amd64        CUDA OpenCL native Libraries
ii  cuda-opencl-12-9                               12.9.19-1                               amd64        CUDA OpenCL native Libraries
ii  cuda-opencl-dev-12-8                           12.8.90-1                               amd64        CUDA OpenCL native dev links, headers
ii  cuda-profiler-api-12-8                         12.8.90-1                               amd64        CUDA Profiler API
ii  cuda-profiler-api-12-9                         12.9.79-1                               amd64        CUDA Profiler API
ii  cuda-repo-ubuntu2404-12-8-local                12.8.1-570.124.06-1                     amd64        cuda repository configuration files
ii  cuda-repo-ubuntu2404-12-9-local                12.9.1-575.57.08-1                      amd64        cuda repository configuration files
ii  cuda-sandbox-dev-12-9                          12.9.19-1                               amd64        nvsandboxutils native dev links, headers
ii  cuda-sanitizer-12-8                            12.8.93-1                               amd64        CUDA Sanitizer
ii  cuda-sanitizer-12-9                            12.9.79-1                               amd64        CUDA Sanitizer
ii  cuda-toolkit-12-8                              12.8.1-1                                amd64        CUDA Toolkit 12.8 meta-package
ii  cuda-toolkit-12-8-config-common                12.8.90-1                               all          Common config package for CUDA Toolkit 12.8.
ii  cuda-toolkit-12-9                              12.9.1-1                                amd64        CUDA Toolkit 12.9 meta-package
ii  cuda-toolkit-12-9-config-common                12.9.79-1                               all          Common config package for CUDA Toolkit 12.9.
ii  cuda-toolkit-12-config-common                  12.9.79-1                               all          Common config package for CUDA Toolkit 12.
ii  cuda-toolkit-config-common                     12.9.79-1                               all          Common config package for CUDA Toolkit.
ii  cuda-tools-12-8                                12.8.1-1                                amd64        CUDA Tools meta-package
ii  cuda-tools-12-9                                12.9.1-1                                amd64        CUDA Tools meta-package
ii  cuda-visual-tools-12-8                         12.8.1-1                                amd64        CUDA visual tools
ii  cuda-visual-tools-12-9                         12.9.1-1                                amd64        CUDA visual tools
ii  datacenter-gpu-manager-4-cuda12                1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management binaries supporting CUDA12 environments
ii  datacenter-gpu-manager-4-proprietary-cuda12    1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management proprietary CUDA12 binaries
ii  libnvidia-container-tools                      1.17.7-1                                amd64        NVIDIA container runtime library (command-line tools)
ii  libnvidia-container1:amd64                     1.17.7-1                                amd64        NVIDIA container runtime library
hi  libnvidia-nscq-570                             570.133.20-1                            amd64        NVSwitch Configuration and Query library
ii  nvidia-container-toolkit                       1.17.7-1                                amd64        NVIDIA Container toolkit
ii  nvidia-container-toolkit-base                  1.17.7-1                                amd64        NVIDIA Container Toolkit Base
ii  nvidia-driver-local-repo-ubuntu2404-550.163.01 1.0-1                                   amd64        nvidia-driver-local repository configuration files
ii  nvidia-driver-local-repo-ubuntu2404-570.172.08 1.0-1                                   amd64        nvidia-driver-local repository configuration files
hi  nvidia-fabricmanager-570                       570.133.20-1                            amd64        Fabric Manager for NVSwitch based systems.

$  nvidia-smi topo -m
        GPU0    GPU1    GPU2    GPU3    CPU Affinity    NUMA Affinity   GPU NUMA ID
GPU0     X      PHB     PHB     PHB     0-47    0               N/A
GPU1    PHB      X      PHB     PHB     0-47    0               N/A
GPU2    PHB     PHB      X      PHB     0-47    0               N/A
GPU3    PHB     PHB     PHB      X      0-47    0               N/A

Legend:

  X    = Self
  SYS  = Connection traversing PCIe as well as the SMP interconnect between NUMA nodes (e.g., QPI/UPI)
  NODE = Connection traversing PCIe as well as the interconnect between PCIe Host Bridges within a NUMA node
  PHB  = Connection traversing PCIe as well as a PCIe Host Bridge (typically the CPU)
  PXB  = Connection traversing multiple PCIe bridges (without traversing the PCIe Host Bridge)
  PIX  = Connection traversing at most a single PCIe bridge
  NV#  = Connection traversing a bonded set of # NVLinks

1. Fabric Manager는 NVSwitch 기반 시스템에만 필요

AWS G5 인스턴스는 A10G GPU 4개가 PCIe 기반으로 연결됨
nvidia-smi topo -m 결과에서도 PHB(PCIe Host Bridge)만 표시됨
NVLink / NVSwitch 없음 → Fabric Manager 불필요
NUMA Affinity도 모두 0 → 단일 NUMA 노드에 붙은 PCIe 디바이스임

2. FabricManager가 apt에서 누락되면 재설치 불가 & 충돌 유발

/var/nvidia-driver-local-repo-* 경로에 해당 .deb 파일 없음
CUDA repo에 등록된 fabricmanager만을 의존하므로 apt는 "설치 후보 없음" 오류 발생

3. 이전 버전(550) 리포지터리와 충돌

/var/nvidia-driver-local-repo-ubuntu2404-550.xxx.xx 와 /570.xxx.xx 가 동시에 존재
apt가 GPG 키 또는 우선순위 문제로 특정 패키지를 제거하거나 업데이트 중단

4. 인스턴스를 중지(stop) 후 시작(start)하면 인스턴스가 다른 하드웨어 노드로 이동하여 GPU 드라이브 커널 바인딩이 깨짐

3. 해결 과정

1. 모든 NVIDIA 관련 패키지 정리

sudo apt-get --purge remove 'nvidia-*' 'cuda-*'
sudo apt-get autoremove
sudo apt-get autoclean

2. NVIDIA 드라이버 재설치

드라이버 유형별(https://docs.aws.amazon.com/ko_kr/AWSEC2/latest/UserGuide/install-nvidia-driver.html#nvidia-driver-types)

다음은 GPU 기반 인스턴스에서 사용할 수 있는 주요 NVIDIA 드라이버 유형입니다.
Tesla 드라이버
이러한 드라이버는 주로 컴퓨팅 워크로드를 위한 것입니다. 컴퓨팅 워크로드는 기계 학습을 위한 병렬화된 부동 소수점 계산과 고성능 컴퓨팅 애플리케이션을 위한 고속 푸리에 변환과 같은 컴퓨팅 작업에 GPU를 사용합니다.
GRID 드라이버
이러한 드라이버는 3D 모델 또는 고해상도 비디오와 같은 콘텐츠를 렌더링하는 전문 시각화 애플리케이션에 최적의 성능을 제공하는 것으로 인증됩니다. 두 가지 모드를 지원하도록 GRID 드라이버를 구성할 수 있습니다. Quadro 가상 워크스테이션은 GPU당 4개의 4K 디스플레이에 대한 액세스를 제공합니다. GRID vApp은 RDSH 앱 호스팅 기능을 제공합니다.
게임 드라이버
이러한 드라이버는 게임을 위한 최적화 기능을 포함하고 있으며 성능 향상을 제공하기 위해 자주 업데이트됩니다. 이러한 드라이버는 GPU당 단일 4K 디스플레이를 지원합니다.

구성된 모드
Windows에서 Tesla 드라이버는 TCC(Tesla 컴퓨팅 클러스터) 모드에서 실행되도록 구성됩니다. GRID 및 게임 드라이버는 WDDM(Windows 디스플레이 드라이버 모델) 모드에서 실행되도록 구성됩니다. TCC 모드에서 이 카드는 컴퓨팅 워크로드에 전용됩니다. WDDM 모드에서 이 카드는 컴퓨팅 워크로드와 그래픽 워크로드를 모두 지원합니다.

wget https://us.download.nvidia.com/tesla/570.172.08/nvidia-driver-local-repo-ubuntu2404-570.172.08_1.0-1_amd64.deb
sudo dpkg -i nvidia-driver-local-repo-ubuntu2404-570.172.08_1.0-1_amd64.deb
sudo apt update

* 안정적인 사용을 위해 cuda 12.8를 지원하는 570.172.08로 설치함

설치 결과 확인

$ dpkg -l | grep -E 'nvidia|cuda'
ii  datacenter-gpu-manager-4-cuda12                1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management binaries supporting CUDA12 environments
ii  datacenter-gpu-manager-4-proprietary-cuda12    1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management proprietary CUDA12 binaries
ii  nvidia-driver-local-repo-ubuntu2404-570.172.08 1.0-1                                   amd64        nvidia-driver-local repository configuration files

3. CUDA 재설치

wget https://developer.download.nvidia.com/compute/cuda/repos/ubuntu2404/x86_64/cuda-ubuntu2404.pin
sudo mv cuda-ubuntu2404.pin /etc/apt/preferences.d/cuda-repository-pin-600
wget https://developer.download.nvidia.com/compute/cuda/12.8.1/local_installers/cuda-repo-ubuntu2404-12-8-local_12.8.1-570.124.06-1_amd64.deb
sudo dpkg -i cuda-repo-ubuntu2404-12-8-local_12.8.1-570.124.06-1_amd64.deb
sudo cp /var/cuda-repo-ubuntu2404-12-8-local/cuda-*-keyring.gpg /usr/share/keyrings/
sudo apt-get update
sudo apt-get -y install cuda-toolkit-12-8

$ dpkg -l | grep -E 'nvidia|cuda'
ii  cuda-cccl-12-8                                 12.8.90-1                               amd64        CUDA CCCL
ii  cuda-command-line-tools-12-8                   12.8.1-1                                amd64        CUDA command-line tools
ii  cuda-compiler-12-8                             12.8.1-1                                amd64        CUDA compiler
ii  cuda-crt-12-8                                  12.8.93-1                               amd64        CUDA crt
ii  cuda-cudart-12-8                               12.8.90-1                               amd64        CUDA Runtime native Libraries
ii  cuda-cudart-dev-12-8                           12.8.90-1                               amd64        CUDA Runtime native dev links, headers
ii  cuda-cuobjdump-12-8                            12.8.90-1                               amd64        CUDA cuobjdump
ii  cuda-cupti-12-8                                12.8.90-1                               amd64        CUDA profiling tools runtime libs.
ii  cuda-cupti-dev-12-8                            12.8.90-1                               amd64        CUDA profiling tools interface.
ii  cuda-cuxxfilt-12-8                             12.8.90-1                               amd64        CUDA cuxxfilt
ii  cuda-documentation-12-8                        12.8.90-1                               amd64        CUDA documentation
ii  cuda-driver-dev-12-8                           12.8.90-1                               amd64        CUDA Driver native dev stub library
ii  cuda-gdb-12-8                                  12.8.90-1                               amd64        CUDA-GDB
ii  cuda-libraries-12-8                            12.8.1-1                                amd64        CUDA Libraries 12.8 meta-package
ii  cuda-libraries-dev-12-8                        12.8.1-1                                amd64        CUDA Libraries 12.8 development meta-package
ii  cuda-nsight-12-8                               12.8.90-1                               amd64        CUDA nsight
ii  cuda-nsight-compute-12-8                       12.8.1-1                                amd64        NVIDIA Nsight Compute
ii  cuda-nsight-systems-12-8                       12.8.1-1                                amd64        NVIDIA Nsight Systems
ii  cuda-nvcc-12-8                                 12.8.93-1                               amd64        CUDA nvcc
ii  cuda-nvdisasm-12-8                             12.8.90-1                               amd64        CUDA disassembler
ii  cuda-nvml-dev-12-8                             12.8.90-1                               amd64        NVML native dev links, headers
ii  cuda-nvprof-12-8                               12.8.90-1                               amd64        CUDA Profiler tools
ii  cuda-nvprune-12-8                              12.8.90-1                               amd64        CUDA nvprune
ii  cuda-nvrtc-12-8                                12.8.93-1                               amd64        NVRTC native runtime libraries
ii  cuda-nvrtc-dev-12-8                            12.8.93-1                               amd64        NVRTC native dev links, headers
ii  cuda-nvtx-12-8                                 12.8.90-1                               amd64        NVIDIA Tools Extension
ii  cuda-nvvm-12-8                                 12.8.93-1                               amd64        CUDA nvvm
ii  cuda-nvvp-12-8                                 12.8.93-1                               amd64        CUDA Profiler tools
ii  cuda-opencl-12-8                               12.8.90-1                               amd64        CUDA OpenCL native Libraries
ii  cuda-opencl-dev-12-8                           12.8.90-1                               amd64        CUDA OpenCL native dev links, headers
ii  cuda-profiler-api-12-8                         12.8.90-1                               amd64        CUDA Profiler API
ii  cuda-repo-ubuntu2404-12-8-local                12.8.1-570.124.06-1                     amd64        cuda repository configuration files
ii  cuda-sanitizer-12-8                            12.8.93-1                               amd64        CUDA Sanitizer
ii  cuda-toolkit-12-8                              12.8.1-1                                amd64        CUDA Toolkit 12.8 meta-package
ii  cuda-toolkit-12-8-config-common                12.8.90-1                               all          Common config package for CUDA Toolkit 12.8.
ii  cuda-toolkit-12-config-common                  12.8.90-1                               all          Common config package for CUDA Toolkit 12.
ii  cuda-toolkit-config-common                     12.8.90-1                               all          Common config package for CUDA Toolkit.
ii  cuda-tools-12-8                                12.8.1-1                                amd64        CUDA Tools meta-package
ii  cuda-visual-tools-12-8                         12.8.1-1                                amd64        CUDA visual tools
ii  datacenter-gpu-manager-4-cuda12                1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management binaries supporting CUDA12 environments
ii  datacenter-gpu-manager-4-proprietary-cuda12    1:4.2.3                                 amd64        NVIDIA® Datacenter GPU Management proprietary CUDA12 binaries
ii  nvidia-driver-local-repo-ubuntu2404-570.172.08 1.0-1                                   amd64        nvidia-driver-local repository configuration files

4. stop/start 이후 GPU 초기화 스크립트 작성

1. 스크립트 작성

sudo vi /usr/local/bin/gpu-recover.sh

#!/bin/bash

echo "[GPU RECOVER] Unloading NVIDIA kernel modules..."
modprobe -r nvidia_uvm nvidia_drm nvidia_modeset nvidia || true

echo "[GPU RECOVER] Reloading NVIDIA kernel module..."
modprobe nvidia

echo "[GPU RECOVER] Checking NVIDIA GPU status..."
nvidia-smi

권한 부여

sudo chmod +x /usr/local/bin/gpu-recover.sh

2. systemd 서비스 등록

sudo vi /etc/systemd/system/gpu-recover.service

[Unit]
Description=Recover NVIDIA GPU after AWS instance restart
After=multi-user.target
ConditionPathExists=/usr/local/bin/gpu-recover.sh

[Service]
Type=oneshot
ExecStart=/usr/local/bin/gpu-recover.sh
RemainAfterExit=true

[Install]
WantedBy=multi-user.target

3. systemd 적용 및 부팅 시 자동 실행 설정

sudo systemctl daemon-reexec
sudo systemctl daemon-reload
sudo systemctl enable gpu-recover.service

4. 테스트

# 수동 실행 (테스트용)
sudo systemctl start gpu-recover.service

# 로그 확인
journalctl -u gpu-recover.service

NVILA: Efficient Frontier Visual Language Models

Hanna 한나 — Thu, 31 Jul 2025 14:44:13 +0900

왜 NVILA가 필요한가?

VLM(Visual Language Model)은 사진이나 영상을 보고 텍스트로 설명하거나 대화할 수 있는 AI 모델이지만 이런 모델을 제대로 훈련시키는 건 엄청나게 비싸고 오래 걸리는 문제가 발생함. 예를 들어, 7B 파라미터를 가진 최신 모델을 훈련하려면 GPU 400일이나 소요하는 문제가 발생 또한, 특수 분야(예: 의료 영상)에 맞추려면 모델을 조금 조정(fine-tuning)해야 하는데, 그 작업도 GPU 메모리 64GB 이상이 필요할 정도로 무거움. 마지막으로 이 모델들을 엣지 장비와 같은 제한된 장비(노트북, 로봇)에서 돌리려고 하면, 너무 많은 연산과 메모리를 필요로 해서 실행하기 어려움.

NVILA가 해결한 방법

기존 VILA는 이미지 해상도와 영상 길이에 제한이 있어서, 이미지는 무조건 448x448로 리사이즈, 영상은 최대 14프레임만 사용해야 함. 이렇게 하면 연산은 줄어들지만, 정보 손실이 커져서 정확도가 낮아지는 문제가 발생함

NVILA는 빠르고 효율적인 VLM을 목표로 새로 만든 모델로, 핵심 전략이 “Scale-then-Compress(확대 후 압축)” 방식으로 진행함.

- Scale (확대): 이미지나 영상을 더 큰 해상도와 더 많은 프레임으로 분석 → 더 자세하고 정확한 정보 확보.
- Compress (압축): 분석한 정보를 꼭 필요한 토큰(데이터 단위)만 남기고 줄임 → 계산량과 속도 문제 해결.

만약, Scale(확대)만 하면 계산량이 폭증하여 연산에 느리고 많은 GPU를 사용하게 되고, Compress(압축)만 하면 정보 손실로 정확도가 떨어지는 문제가 발생함. 그래서 확대해서 충분한 정보를 확보하고, 그걸 압축해서 효율화하는 처리 과정을 거침

이 방식 덕분에 NVILA는 고해상도 이미지나 긴 영상도 빠르고 효율적으로 처리할 수 있었음. 추가로, NVILA는 학습부터 파인튜닝, 실제 배포(추론)까지 전 과정에서 효율성을 극대화하여 훈련할 때도 빠르고, 특수 도메인에 맞춰 조정할 때도 덜 무겁고, 실제 사용할 때도 가볍게 동작할 수 있음

NVILA 모델을 설계한 방법

NVILA는 3개의 주요 구성요소로 이루어진 자동회귀(autoregressive) VLM로, 이미지나 영상을 입력 받아서 텍스트로 설명하는 방식임

Visual Encoder (시각 인코더) : 이미지나 영상에서 중요한 정보를 뽑아내는 역할, 여기서는 SigLIP이라는 모델 사용
Projector (투영기) : 뽑아낸 시각 정보와 언어 정보를 연결해주는 역할, 간단한 2층짜리 MLP 사용
Token Processor (토큰 처리기) : 시각/언어 정보를 받아서, 최종 언어 출력 생성, Qwen2 LLM 사용 (GPT류 모델)

1. Spatial "Sacle-Then-Compress"

VLM은 시각 정보를 처리하기 위해 Vision Transformer(ViT)와 같은 인코더를 사용함. 하지만, ViT의 경우 입력 이미지 크기가 고정되어 있어서 학습시 사용한 해상도보다 큰 이미지를 그대로 처리 할 수 없는 문제가 발생함. 예를 들어, 448x448 해상도로 학습된 ViT에 1344x896 같은 큰 이미지를 입력하면 강제로 리사이징하게 되면서, 디테일 손실이나 왜곡이 발생함. 그래서 등장한 방법이 스마트 타일링(S2, Smart Tiling)

S2는 이미지를 여러 해상도(448, 896, 1344)로 리사이징하고, 각 해상도에서 이미지를 448x448 단위의 여러 개의 작은 타일로 분활함. 그 이후, 각 타일을 독립적으로 인코더에 통과하여, 결과로 얻은 각 타일의 특징을 다시 합쳐서 전체 이미지의 특징 맵을 구성하는 방법.

예를 들어, 입력 이미지가 1344x896인 경우 이 이미지를 448x448, 896x896x 1344x1344로 리사이징한 뒤, 각 리사이즈된 이미지를 448x448 단위로 타일을 분할함. 이러면, 각각 1개(1x1), 4개(2x2), 9개(3x3)의 타일이 됨. 이 이후, 각 타일을 Vision Encoder(SigLIP 등)에 개별로 통과시켜 로컬 특징을 추출한 다음 같은 해상도의 타일끼리 다시 붙여(concat)하여 특징맵을 완성시킴. 이후, 마지막으로 여러 해상도에서 나온 특징맵을 채널 기준으로 합치게 됨. 이 결과로, 큰 이미지는 고해상도 정보를 유지하고, 작은 이미지의 경우 낭비 없이 효율적으로 처리하게 됨.

하지만 문제는 S2 방법은 강제로 정사각형으로 리사이징되어 가로/세로 비율이 깨져서 찌그러지는 문제가 발생함. 따라서, 이를 해결하기 위해 NVILA는 Dynamic-S2를 활용하여 이미지의 원래 비율을 유지한 채로 처리할 수 있게 개선을 하였음. 단, 타일의 크기인 448에 딱 나눠떨어지도록 보정하여 1344x896타일 마지막 3x2 타일로 분활하여 원본의 비율을 유지하여 왜곡 없는 고품질 시각 특징을 추출하여, 효율은 S2 만큼 높고, 정확도는 훨씬 좋은 효과를 받았음. 또한, 타일 수 증가에도 불구하고 나중에 token compression(STC)으로 전체 토큰수를 조절하여 계산량 증가 및 제어가 가능해졌음.

2. Temporal "Sacle-Then-Compress"

NVILA는 더 많은 프레임을 보게 해서 정확도를 높이고 중복된 장면은 압축해서 연산량을 줄이는 전략을 세움. 기존 VILA는 영상에서 8프레임만 샘플링해서 사용하지만 영상은 시간적으로 길고, 다양한 정보가 포함돼 있기 때문에 주요한 정보를 놓칠 가능성이 있음. 이는 성능 저하의 원인임

NVILA는 프레임 수를 32, 64, 최대 256까지 늘려서 적용함. NVILA의 경우 8->32 프레임으로 늘리면 Video-MME에서 정확도가 5% 이상 향상됨(55.7->61.0). 다만, 프레임 수가 4배로 늘리면 비주얼 토큰 수(연산량)도 4배 또는 4배 이상으로 증가하여 학습 및 추론 속도 급격히 느려지는 문제가 발생함. 따라서, 영상의 연속 프레임들을 하나의 그룹으로 묶고, 해당 그룹의 시각 정보를 평균(pooling)하여 압축함.

예를 들어 32프레임 입력 시, 이를 4프레임씩 묶어 총 8개 그룹으로 나눔. 각 그룹의 비주얼 토큰을 평균화하여 1개로 축소. 결과적으로 4배 압축하여 원래 8192개를 2048개로 감소하였음. 이 과정을 통해 중요 정보는 유지하고, 시간적 중복 정보만 제거하는 효과를 얻음

효율적으로 NVILA를 학습하는 방법

1. Efficient Training

NVILA는 학습 효율을 높이기 위한 주요 전략 중 하나로 Dataset Pruning(데이터셋 정제)를 제안함. 여기서 핵심은 불필요하거나 덜 유익한 샘플을 제거하여 학습 효율을 높이고 계산 자원을 절감하는 방식을 적용함

기존 SFT(Supervised Fine-Tuning) 데이터셋은 대규모로 구성되지만, 모든 데이터가 모델 학습에 유익하지 않으므로, 효율적인 학습을 위해 가치 있는 샘플만 남기는 pruning이 필요함. 학습 샘플의 '유용도'를 정량화하기 위해 Delta Loss를 도입. Delta Loss는 크고 작은 모델의 예측 차이를 의미함

: 전체 데이터셋의 서브셋
′ : 정제된 데이터셋
Plarge( ) : 전체 데이터셋으로 학습한 모델이 샘플 x에 대해 예측한 확률
Psmall( ) : 축소된 데이터셋(x 제외, 또는 소규모 데이터셋)으로 학습한 모델이 샘플 x에 대해 예측한 확

둘 다 정답 또는 오답일 경우 Δ ≈ 0. 둘다 잘하거나 못하는 문제는 학습에 도움이 안 되어, 제거 대상
작은 모델은 맞췄는데, 큰 모델은 틀린 경우 Δ < 0. 불안정하거나 노이즈일 경우가 높아, 실제로 학습에서 이런 예시는 학습을 방해하거나 무시됨. 제거 대상
작은 모델은 틀렸는데, 큰 모델은 맞춘 경우 Δ > 0. 학습에 도움이 되는 유익한 샘플로 선택하여 남김

거대 언어모델(LLM)에 대한 자체 개발 수준에 따른 등급

Hanna 한나 — Tue, 29 Jul 2025 15:07:26 +0900

이승현 디지털플랫폼 정부위원회 인공지능플랫폼 혁신국장이 제안하고 있는 LLM에 대한 등급 체계 제시하였다.

T0 : 외부 폐쇄 API 호출 후 프롬프트·필터만 추가한 LLM
- 아키텍처, 가중치 기원은 100% 외산·폐쇄형
- 통제나 주권성이 거의 없어 API 계약, 쿼터에 의존
- 챗GPT 기반 다수 PoC 서비스가 대표 사례

T1 : 폐쇄 가중치에 LoRA, RAG 등 경량 튜닝을 더하는 것
- 중치 불투명성이 특징이며, 통제나 주권성 측면에서 설명 가능성과 재현성이 제한됨
- 의료, 금융 시범 모델, UAE TAMM 3.0, KT 챗GPT-4oK(예정) 등

T2 : LLAMA, Qwen 등 공개 가중치 100%를 이용해 전면 추가 학습한 것
- 기반 모델 라이선스 준수가 필요
- 로컬 호스팅, 가중치 수정이 가능해 통제나 주권성이 중간 수준
- SK텔레콤 A.X 4.0(Qwen 2.5 CPT)

T3: 오픈소스 모델 구조·레이어를 확장한 후 전체 재학습한 LLM
- 기반 모델 라이선스 부분 준수가 필요
- 통제나 주권성이 중간 이상이지만 구조 혁신은 제한
- 업스테이지 솔라 프로 2(Phi‑4→DUS)

T4 : LLAMA-류 구조를 차용하고, 가중치 전량을 자체 사전 학습한 것
- 구조 의존적이지만 가중치는 독립적이며, 통제나 주권성이 높으나 구조 혁신은 다소 제한
- 학습 데이터나 토크나이저 자체 설계로 통제권을 어느 정도 확보했지만 핵심 블록은 여전히 동일해 구조에 제한이 있어, 특허, 트렌드에 영향이 있을 것
- KT 믿음 2.0, SK텔레콤 A.X 3.1

T5 : 구조까지 변형하고 가중치 자체 학습을 하는 것
- 구조와 가중치 모두 완전 국산이며, 주권성과 통제 가능성이 매우 높다.
- 통제권과 설명 가능성을 확보했으나, 막대한 투자 및 컴퓨트, 데이터가 필요하므로 효율성 부분에서 우려도 있을 것
-LG AI연구원이 개발한 엑사원 4.0, 네이버 하이퍼클로바 X 씽크

T6 : T5 등급 요건에 칩, 프레임워크, IDC, 데이터까지 완전 자립한 단계
- 공급망, 법적 완전 통제가 가능하며, 통제나 주권성이 최고 수준

출처 : 뉴스웍스(https://www.newsworks.co.kr)

ChatGPT Prompt 가이드

Hanna 한나 — Wed, 16 Jul 2025 16:47:37 +0900

아래 내용들은 OpenAI Cookbook에서 제시한 프롬프트 가이드를 정리한 내용이다. 출처

프롬프트 예시

당신은 다음 역할을 수행합니다:
당신은 NewTelco에서 근무하는 친절한 고객 서비스 상담원입니다. 고객의 요청을 효율적으로 처리하면서 주어진 지침을 엄격히 준수해야 합니다.

# 지침 (Instructions)
- 항상 다음 문구로 고객에게 인사합니다: “안녕하세요, NewTelco입니다. 무엇을 도와드릴까요?”
- 회사, 상품, 서비스, 또는 고객 계정에 관한 사실 기반 질문에는 반드시 도구(tool)를 호출한 후에 응답해야 합니다. 직접 알고 있는 지식을 기반으로 답변해서는 안 되며, 반드시 조회된 컨텍스트에만 의존해야 합니다.
- 만약 도구 호출을 위해 필요한 정보가 부족하다면, 사용자에게 필요한 정보를 먼저 요청하세요.
- 사용자가 요청하는 경우, 사람 상담원에게 연결하세요.
- 다음과 같은 금지된 주제에 대해 논의하지 마세요(정치, 종교, 논쟁적 시사, 의학, 법률 또는 재정 관련 조언, 개인적 대화, 회사 내부 운영)
- 특정 인물이나 회사에 대한 비판 가능한 경우 샘플 문구를 사용하되, 같은 대화 내에서 같은 문구를 반복하지 마세요
- 적절하게 변형하여 자연스럽고 덜 반복적으로 들리도록 하세요.
- 항상 정해진 출력 형식(Output Format)을 따라 응답하며, 사실 기반 정보에는 반드시 출처를 포함해야 합니다.
- 도구를 호출할 경우, 도구 호출 전과 후에 사용자에게 메시지를 보내어 안내해야 합니다.
- 모든 응답은 전문적이고 간결한 어조를 유지하며, 문장 사이에 이모지를 활용해 친근한 느낌을 줍니다.
- 사용자의 요청을 해결한 경우, "다른 도움이 필요하신가요?"라고 물어보세요.

# 응답 절차 (Precise Response Steps)
1. 사용자의 요청을 처리하기 위해 필요 시 도구를 호출합니다.- 도구 호출 전후에는 항상 사용자에게 관련 메시지를 보내 상황을 공유해야 합니다.
2. 사용자에게 응답할 때는:
a. 사용자의 요청을 능동적으로 경청하고, 이해한 내용을 요약하여 확인합니다.
b. 위의 지침을 기반으로 적절하게 응답합니다.

# 샘플 문구 (Sample Phrases)
## 금지 주제 회피 시
- “죄송하지만 해당 주제에 대해서는 안내해드릴 수 없습니다. 다른 도움을 드릴 수 있을까요?”
- “그 부분에 대해서는 안내드릴 수 없지만, 다른 문의가 있다면 기꺼이 도와드리겠습니다!”

## 도구 호출 전
- “해당 내용을 도와드리기 위해 고객 정보를 먼저 확인할게요.”
- “잠시만 기다려 주세요, 확인해보겠습니다.”
- “최신 정보를 조회해드릴게요.”

## 도구 호출 후
- “확인해본 결과 다음과 같습니다: [응답 내용]”
- “이렇게 확인되었습니다: [응답 내용]”

# 출력 형식 (Output Format)
- 항상 사용자에게 보낼 최종 응답 메시지를 포함하세요.
- 조회된 정책 문서에서 나온 사실 기반 정보는 다음과 같은 인용 형식을 사용하세요:
- 단일 출처: [정책명](ID)
- 복수 출처: [정책1](ID1), [정책2](ID2)
- 회사의 정책, 상품, 서비스, 계정 정보 등만 제공해야 하며, 반드시 조회된 문서 기반이어야 합니다. 이 범위를 벗어난 질문은 답변하지 않습니다.

# 예시
## 사용자
가족 요금제에 대해 알려줄 수 있나요?

## 어시스턴트 응답 1:
### 메시지
"안녕하세요, NewTelco입니다. 무엇을 도와드릴까요? \n\n가족 요금제에 대해 알고 싶으시군요. 확인해드릴게요, 잠시만 기다려 주세요. "

### 도구 호출
lookup_policy_document(topic="family plan options")

// 도구 호출 후, 어시스턴트는 다음을 행동하세요

## 어시스턴트 응답 2 (도구 호출 후)
### 메시지
"확인해본 결과 다음과 같습니다: 당사의 가족 요금제는 최대 5회선까지 데이터를 공유할 수 있으며, 추가 회선마다 10% 할인 혜택이 적용됩니다 [가족 요금제 정책](ID-010). 다른 도와드릴 내용이 있을까요? "

일반적인 추천 프롬프트 구조

# Role and Objective
# Instructions
## Sub-categories for more detailed instructions
# Reasoning Steps
# Output Format
# Examples
## Example 1
# Context
# Final instructions and prompt to think step by step

Prompt Engineering 관점에서 구조 설명

# Role and Objective : 모델의 응답 스타일 및 정체성을 컨트롤함 (zero-shot 설정에 매우 중요)

역할(Role): 모델이 어떤 역할(예: 수학 교사, 판사, 데이터 분석가 등)을 수행해야 하는지를 명확히 지정합니다.
목표(Objective): 모델이 어떤 목적을 가지고 응답해야 하는지를 정의합니다.

# Instructions : 전체 작업의 범위를 제약하며, 정확한 출력 컨트롤을 유도합니다.

작업에 대한 일반적인 지시사항을 제시합니다.
무엇을 해야 하고, 무엇은 하지 말아야 하는지를 간단명료하게 설명합니다.

## Sub-categories for more detailed instructions : 모델의 step-by-step 사고 (chain-of-thought)를 유도하고, 구조화된 출력을 기대할 수 있음

작업이 복잡하거나 다단계일 경우, 이를 하위 지침으로 세분화합니다.
각 단계를 명시하면 모델은 그 흐름대로 사고하게 됩니다.

# Reasoning Steps : 모델의 내적 추론 과정을 강화하여 정확도, 일관성 향상할 수 있으며, CoT (Chain of Thought) 유도에 핵심

모델이 답을 생성할 때 따라야 할 추론의 단계를 기술합니다.
논리적, 수학적, 언어적 사고 과정이 포함됩니다.

# Output Format : 정형화된 출력을 얻어 후속 처리 및 자동화에 적합하고, 파이프라인 응답 구성에 유리

모델이 출력해야 할 형식이나 템플릿을 명시합니다.
JSON, 표, 리스트, 마크다운 등 다양한 포맷을 지정 가능

# Examples : 모델이 유사한 상황에서 형식과 추론 구조를 모방하게 하고 성능 개선에 매우 효과적

좋은 예시를 포함시켜 few-shot prompting을 수행합니다.
예시는 모델이 기대되는 응답 스타일을 학습하는 데 매우 효과적입니다.

# Context : 문맥 인식 향상 및 더 정밀한 결과 유도 가능

모델이 이해하고 작업을 수행하기 위한 배경 정보를 제공합니다.
문서, 이전 대화, 시스템 상태 등 포함 가능

# Final instructions and prompt to think step by step : 답변의 논리적 일관성과 정확성이 높아지짐. 특히 추론, 판단 기반 태스크에서 성능이 향상됨

마지막으로 “step-by-step으로 생각하라”는 지시로 마무리합니다.
이는 모델의 자기 유도적 사고 (self-consistency)를 활성화합니다.

구분기호

1. 마크다운 : 권장합니다. 코드를 정확하게 감싸려면 인라인 백틱이나 백틱 블록을 사용하고, 필요에 따라 표준 번호 매기기 또는 글머리 기호 목록을 사용할 수 있습니다.

2. XML : ChatGPT 4.1의 경우 XML도 성능이 좋으며, XML 정보의 일관성을 개선했습니다

3. JSON : 특히 코딩 환경에서 모델이 쉽게 이해할 수 있습니다. 하지만 JSON은 더 정황하고 오버헤드를 유발할 수 있는 문자 이스케이프를 요구할 수 있습니다. 또한, 대량의 문서나 파일을 입력 컨텍스트의 경우 성능이 특히 좋지 않았습니다.

[TIL] Multimodal RAG

Hanna 한나 — Sun, 20 Apr 2025 18:46:25 +0900

1. RAG의 본질과 가치

LLM은 정보를 학습(1)하거나 외부로부터 가져와 활용(2)할 수 있습니다.
- (1) Fine-tuning: 가중치 업데이트
- (2) RAG: 관련 문맥을 프롬프트로 주입 → 최신 정보/사실 기반 응답에 효과적
특히 엔터프라이즈 데이터에서 정확한 사실 회상에 RAG는 강력한 접근법

2. RAG 향상 기법

Base RAG	문서 청크 임베딩 후 Top-K 검색	LangChain vectorstores
Summary Embedding	요약 임베딩 검색 후 원문 전달	LangChain Multi Vector Retriever
Windowing	청크 검색 후 확장 영역 반환	LangChain Parent Document Retriever
Metadata Filtering	메타데이터 기반 필터링 검색	Self-query retriever
Embedding Fine-tune	임베딩 모델 자체를 커스터마이징	LangChain Fine-tuning
2-Stage RAG	키워드 기반 1차 → 의미기반 2차	Cohere Re-rank

3. Multi-Vector Retriever 핵심 전략

문서의 검색용 요약과 응답용 원문을 분리

예: 문서 요약은 벡터 검색에 최적화하고, LLM에는 전체 문서를 주입
텍스트뿐 아니라 표(Table)와 이미지(Image)에도 동일 전략 적용 가능

4. 문서 유형별 Cookbook 요약

1) Semi-Structured (Text + Tables)

표 데이터를 자연어 요약으로 변환 후 임베딩
질문과 의미적으로 유사한 요약이 검색되면 → 원본 표 전체를 LLM에 전달
사용 도구: Unstructured + Multi-vector Retriever

2) Multi-modal (Text + Tables + Images)

이미지도 포함하는 경우 세 가지 접근 방식 제시

Option 1	CLIP 등으로 이미지와 텍스트 공동 임베딩 → 이미지 경로만 링크해 LLM에 전달
Option 2	LLM으로 이미지 요약 텍스트 생성 → 텍스트 임베딩 → 텍스트만 LLM에 주입
Option 3	이미지 요약 → 임베딩 → 이미지와 텍스트 모두 LLM에 전달

3) Private Multimodal RAG (로컬 실행)

전체 파이프라인을 로컬 머신에서 실행 가능한 버전
구성 요소:
- 이미지 요약: LLaVA 7B
- 벡터 검색: Chroma
- 임베딩: Nomic GPT4All
- LLM: LLaMA2-13b-chat (via Ollama.ai)

출처 : https://blog.langchain.dev/semi-structured-multi-modal-rag/

[TIL] Emerging Properties in Self-Supervised Vision Transformers

Hanna 한나 — Tue, 4 Feb 2025 16:07:30 +0900

Emerging Properties in Self-Supervised Vision Transformers

Mathilde Caron, Hugo Touvron, Ishan Misra, Hervé Jégou, Julien Mairal, Piotr Bojanowski, Armand Joulin

In this paper, we question if self-supervised learning provides new properties to Vision Transformer (ViT) that stand out compared to convolutional networks (convnets). Beyond the fact that adapting self-supervised methods to this architecture works particularly well, we make the following observations: first, self-supervised ViT features contain explicit information about the semantic segmentation of an image, which does not emerge as clearly with supervised ViTs, nor with convnets. Second, these features are also excellent k-NN classifiers, reaching 78.3% top-1 on ImageNet with a small ViT. Our study also underlines the importance of momentum encoder, multi-crop training, and the use of small patches with ViTs. We implement our findings into a simple self-supervised method, called DINO, which we interpret as a form of self-distillation with no labels. We show the synergy between DINO and ViTs by achieving 80.1% top-1 on ImageNet in linear evaluation with ViT-Base.

https://github.com/facebookresearch/dino

GitHub - facebookresearch/dino: PyTorch code for Vision Transformers training with the Self-Supervised learning method DINO

PyTorch code for Vision Transformers training with the Self-Supervised learning method DINO - facebookresearch/dino

github.com

이 연구는 새로운 자기 지도 학습(self-supervised learning, SSL) 방법을 Vision Transformer(ViT)에 적용하여 놀라운 성질을 발견하는 연구이다. 기존 ViT는 CNN과 비교했을 때 지도 학습(supervised learning)에서 유의미한 성능을 보여주지만, 큰 데이터셋이 필요, 계산량이 많음, 고유한 특성이 드러나지 않음 등의 문제로 인해 널리 채택되지는 못했다.

이 연구는 SSL이 ViT에 새로운 속성을 부여할 수 있는지를 탐구하며, 이를 위해 DINO(Self-Distillation with No Labels) 라는 기법을 제안하였다.

DINO의 주요 개념

Self-Distillation Without Labels
- 지식 증류 (Knowledge Distillation) : 대형 신경망(Teacher Model)의 지식을 소형 신경망(Student Model)으로 전달하여 학습하는 기법, 주로 모델 경량화(model compression) 및 성능 향상을 위해 사용된다.
- 먼저 크고 강력한 네트워크(Teacher)을 학습 시킨 후 소프트 라벨(고양이=0, 강아지=1의 형태가 아닌 고양이=0.2, 강아지=0.8의 형태)로 출력을 생성한다. 학생 네트워크에 원래 정답 라벨 뿐만 아니라, 교사 네트워크에 소프트 라벨을 데이터 간의 관계 및 일반화된 지식을 학습시킨다.
- 이로 인한 대형 네트워크에서 작은 네트워크로 전이시켜 연산량과 메모리를 절약시키고, 소프트 라벨을 활용함으로써 일반화 성능을 향상시킨다. 또한 다른 데이터셋 또는 도메인 간의 지식으로 전이가 가능하다.
- 전통적인 지식 증류는 교사 네트워크 -> 학생 네트워크 구조를 가지지만 DINO는 라벨이 없는 상태에서도 모델을 학습하는 기법을 사용하였다.
- 입력 이미지에 다양한 변환(augmentation)을 적용하여 서로 다른 버전의 데이터를 생성하였고, 학생과 교사에 같은 이미지를 서로 다른 변형을 입력하였다. 교사 네트워크의 출력을 학생 네트워크가 예측하도록 학습하였다.
- 또한, 기존 지식 증류와 달리, 교사 네트워크가 고정되지 않고, 학생 모델의 EMA( Exponential Moving Average, 지수 이동 평균)로 지속적으로 업데이트 하였다
  - EMA는 새로운 데이터가 들어올 때, 이전 데이터의 정보를 점진적으로 반영하는 평균 계산 방법, 이를 통해 새로운 정보는 빠르게 반영하면서도, 과거 정보도 유지하는 효과를 얻을 수 있음.
  - DINO에서 교사 네트워크는 고정된 네트워크가 아니라, 학생 네트워크를 일정 비율만큼 반영하여 교사 네트워크를 천천히 갱신하는 방식으로 동작하였음
  - 이는, 학생 네트워크보다 교사 네트워크가 더 나은 표현 학습을 하도록 유도(Polyak-Ruppert Averaging)하고 Negative Pairs 없이도 서능이 뛰어날 수 있었음
Self-Attention을 활용한 객체 분할 능력
- DINO를 적용한 ViT는 별도의 지도(supervision) 없이도 이미지 내 객체 경계를 인식하였다.
k-NN 분류에서의 강력한 성능
- 일반적으로 딥러닝 모델은 학습 후 별도의 분류기를 추가해야 하지만, DINO를 사용하면 단순한 k-NN 분류기만으로도 높은 성능을 기록했다.
모멘텀 인코더(Momentum Encoder) 활용
- MoCo(He et al., 2020)에서 사용된 모멘텀 기반 업데이트 방식을 변형하여 적용했다.
- 교사 네트워크의 가중치는 학생 네트워크의 EMA(Exponential Moving Average)로 업데이트된다.
다중 크롭(Multi-Crop) 데이터 증강 적용
- SwAV(Caron et al., 2020)에서 사용된 multi-crop 기법을 적용하여 학습 안정성을 높혔다.

실험 결과 및 비교 분석

ImageNet 분류 성능
- ViT-S/8 모델 기준, DINO는 기존 SSL 기법(MoCo, BYOL, SwAV)보다 우수한 성능을 보임.
- Linear Evaluation: 80.1% (ViT-B/8 기준)
- k-NN Evaluation: 78.3% (ViT-S/8 기준)
이미지 검색 및 복제 감지(Copy Detection)
- Oxford, Paris 이미지 검색 데이터셋에서 기존 비지도 학습 모델보다 높은 성능을 기록.
객체 경계 인식(Object Discovery without Supervision)
- DINO가 학습한 ViT의 Self-Attention Map을 활용하면 객체 경계 인식이 가능.
- PASCAL VOC 데이터셋에서 비교적 높은 Jaccard Similarity 점수를 기록.
계산량 및 학습 시간 절약
- 기존 CNN 기반 SSL 기법보다 적은 연산량으로 더 높은 성능을 기록.
- 2대의 8-GPU 서버에서 3일간 학습하여 최적 성능을 달성 가능

정리

DINO는 ViT의 자기 지도 학습을 최적화하는 방법으로, 객체 경계 감지 및 k-NN 분류 성능이 우수함
Self-Distillation 기법을 활용하여 지도 학습 없이도 강력한 특징 표현을 학습함
모멘텀 인코더 및 Multi-Crop 기법이 주요한 역할을 수행함
기존 CNN 기반 SSL 기법보다 계산량이 적고 효율적인 학습 가능.
DINO의 후속 연구(DINOv2 등)를 통해 더욱 발전된 방법론이 제시되고 있음.

[TIL] 데이터 품질의 비밀 3. 데이터 수집, 정제, 변환, 테스트

Hanna 한나 — Sat, 25 May 2024 21:11:26 +0900

데이터 수집에 초점을 맞추면, 데이터 파이프라인 중 가장 업스트림에 있는 '진입점'은 아마 가장 중요할 것이다. '진입점'은 '외부 세계의 데이터가 파이프라인에 들어오는 초기 접촉 지접'으로 정의할 수 있으며, 진입점의 데이터는 외부 세계의 전형적인 노이즈와 불규칙성을 모두 포함하기 때문에 원시적이다. 데이터 수집 소스는 크게 애플리케이션 로그 데이터, API 응답, 센서 데이터로 나누어 살펴 볼 수 있다.

진입점을 통과한 데이터가 거쳐야 하는 다음 단계는 데이터 정제 단계이다. 높은 데이터 품질을 달성하는 데 가장 큰 장애물 중 하나는 데이터 정제이며, 이는 사용 가능한 데이터셋에서 부정확하거나 대표적이지 않은 데이터를 제거하는 것이다. 데이터 정제의 중요성은 머신러닝에서 대두되고 있으며, 어떻게 올바르게 데이터를 정제할 것인가 결정하는 데에는 많은 노력이 든다.

데이터 정제는 노이즈를 제거하는 오류값 제거, L1, L2 등의 정규화, 데이터 보간법 등을 활용한 데이터 재구성, 부동소주점을 정수로, 혹은 문자를 문자열로 변환하는 유형 변환 등이 있다.

데이터를 처리는 크게 배치 처리와 실시간 처리로 나눌 수 있다. 배치 처리는 일정 기간 동안 데이터를 수집하여 대량의 데이터를 별개의 패킷으로 배치하는 반면, 실시간 처리는 배치 처리보다 프로세스는 길지만 데이터를 거의 즉시 실행한다. 책에서 말하는 대표적인 예는 각각 신용 카드 거래 처리와 실시간 승차 공유앱이 있다.

배치 처리와 실시간 처리의 주요 차이점은 배치당 처리되는 데이터의 양과 처리 속도이다. 파이프라인에서 데이터의 품질 상태는 배치 스트리밍 시스템에서 더 높은 경향이 있지만, 데이터를 실시간 스트리밍할 때 데이터 품질의 중요성은 훨씬 커진다. 단위테스트, 기능 테스트, 통합 테스트와 같은 방법으로는 실시간 데이터 품질을 다루기엔 한계가 있다. 이 책에서는 아마존 키네시스 및 아파치 카프카를 실행하여 실시간 처리 시스템의 품질 관리하는 방법을 제시한다.

데이터 처리가 끝났으면, 데이터 변환을 통하여 데이터를 이해해야 한다. 첫번째 운영 데이터 변환 레이어를 데이터 정규화 단계라고 하며, 이 단계에서는 몇 단계 고려해야 할 점이 있다. (자세한 것은 책에...)

데이터 정규화가 끝났으면, 분석에 수행되는 분석 데이터로 변환해야 한다. 분석 데이터는 운영 데이터와 다르기 때문에 데이터 변환시 주의해야 할 점들이 몇 가지가 있다. 예를 들면, 소스 데이터를 필터링, 집계 및 요약, 중복 제거 또는 정제 및 통합을 한다거나 데이터 필드나 업계 또는 정부 규정을 충족하기 위해 암호화를 하는 것들이다.

마지막으론 데이터 테스트이다. 데이터 테스트는 데이터 파이프라인에 들어가기 전에 데이터 품질 문제를 발견하는 가장 중요한 단계로 NULL 값이 있는지, 데이터 용량은 적절한지, 데이터 분포가 허용되는 분포인지 등이 있다. 이 책에서는 데이터 품질 테스트를 위하여 단위 테스트, 파이프라인 상태에 대한 가시성 메트링, 경고 등에서 자유 사용되는 툴들의 사용방법을 제시한다.