26S26f2

QK·2026년 9월 27일

B300 8장(총 8×192GB or 8×288GB HBM3e)이 장착된 단일 노드는 연산력과 메모리 대역폭이 매우 압도적인 머신입니다.

위의 문서 전처리 스크립트는 수많은 청크를 동시에 밀어 넣는 비동기 배치(High Throughput) 작업이므로, 모델 크기 및 운영 방식에 맞춰 아래 2가지 구성 전략 중 하나를 선택하는 것이 가장 효율적입니다.

구성 전략 선택: 어떻게 8장을 나눌 것인가?

  1. 전략 A: 고속 다중 인스턴스 (가장 추천 - 배치 전처리 처리량 극대화)
  • 대상 모델: Qwen/Qwen2.5-32B-Instruct 또는 14B, Llama-3.1-8B/70B
  • 방식: 32B/70B 모델을 GPU 8장 전체에 TP(Tensor Parallel)=8로 1개 띄우는 것보다, TP=2 또는 TP=4로 쪼개어 독립된 vLLM 인스턴스를 2~4개 띄우고 앞단에 가벼운 로드밸런서(Nginx 또는 HAProxy)나 포트 분산을 두는 방식입니다.
  • 이유: B300 8장 단일 TP=8 통신 오버헤드보다, 여러 인스턴스가 독립적으로 Continuous Batching을 처리할 때 전체 처리량(Throughput / sec)이 2~3배 이상 높아집니다.
  • 예시:
  • GPU 0, 1 (TP=2, Port 8001)
  • GPU 2, 3 (TP=2, Port 8002)
  • GPU 4, 5 (TP=2, Port 8003)
  • GPU 6, 7 (TP=2, Port 8004)
  1. 전략 B: 단일 대형 모델 인스턴스 (가장 단순한 구성)
  • 대상 모델: Llama-3.1-70B-Instruct or Qwen2.5-72B-Instruct (또는 추후 DeepSeek-V2/V3 계열)
  • 방식: 8장 전체를 묶어 tensor-parallel-size 8로 단일 vLLM 서버(Port 8000)를 띄웁니다.
  • 장점: 관리가 편하고 설정이 단순함.

1. 베어메탈 환경 사전 점검

  1. 드라이버 및 CUDA 점검:
nvidia-smi
# B300 인식 확인 (Driver 550+ / 560+ 권장)
  1. Docker / NVIDIA Container Toolkit 설치:
    베어메탈 파이썬 venv에 직접 설치하기보다, vLLM 공식 배포 Docker 컨테이너를 쓰는 것이 CUDA 12.4+/12.5 환경 충돌 없이 가장 안정적입니다.
# NVIDIA Container Toolkit 동작 확인
docker run --rm --gpus all nvidia/cuda:12.4.1-base-ubuntu22.04 nvidia-smi

2. 베어메탈에서 vLLM 서비스 구동 방법

방법 1: 8장 전체를 묶어 단일 인스턴스로 구동 (전략 B - 빠른 시작)

가장 간단하게 단일 포트(8000)로 8장을 모두 활용하는 실행 방법입니다.

  • Docker 명령어로 구동:
docker run -d --name vllm-server \
  --runtime nvidia \
  --gpus all \
  --ipc=host \
  -p 8000:8000 \
  -v /data/models:/data/models \
  vllm/vllm-openai:latest \
  --model /data/models/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 8 \
  --gpu-memory-utilization 0.90 \
  --max-model-len 8192 \
  --max-num-seqs 256 \
  --port 8000
  • 핵심 튜닝 옵션:
  • --tensor-parallel-size 8: 8장의 GPU로 모델 가중치를 분산.
  • --max-num-seqs 256: 배치 내에서 동시에 동적 스케줄링할 최대 요청 수(스크립트의 --concurrency 48 이상을 거뜬히 처리).
  • --gpu-memory-utilization 0.90: KV Cache에 VRAM 90% 할당 (대용량 컨텍스트 및 다중 배치 수용).
  • --ipc=host: PyTorch 분산 통신(NCCL) 공유 메모리 부족 방지 (필수).

방법 2: GPU 분할 멀티 인스턴스 구동 (전략 A - 배치 처리량 극대화 추천)

8장의 GPU를 2장씩 4개 인스턴스로 분할 실행하면 스크립트의 수천 개 청크 처리 속도가 극대화됩니다.

# Instance 1 (GPU 0, 1) -> Port 8001
docker run -d --name vllm-01 --runtime nvidia --gpus '"device=0,1"' --ipc=host \
  -p 8001:8000 -v /data/models:/data/models vllm/vllm-openai:latest \
  --model /data/models/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 --max-model-len 8192 --max-num-seqs 128

# Instance 2 (GPU 2, 3) -> Port 8002
docker run -d --name vllm-02 --runtime nvidia --gpus '"device=2,3"' --ipc=host \
  -p 8002:8000 -v /data/models:/data/models vllm/vllm-openai:latest \
  --model /data/models/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 --max-model-len 8192 --max-num-seqs 128

# Instance 3 (GPU 4, 5) -> Port 8003
docker run -d --name vllm-03 --runtime nvidia --gpus '"device=4,5"' --ipc=host \
  -p 8003:8000 -v /data/models:/data/models vllm/vllm-openai:latest \
  --model /data/models/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 --max-model-len 8192 --max-num-seqs 128

# Instance 4 (GPU 6, 7) -> Port 8004
docker run -d --name vllm-04 --runtime nvidia --gpus '"device=6,7"' --ipc=host \
  -p 8004:8000 -v /data/models:/data/models vllm/vllm-openai:latest \
  --model /data/models/Qwen2.5-32B-Instruct \
  --tensor-parallel-size 2 --max-model-len 8192 --max-num-seqs 128

앞단에 Nginx를 띄워 8000번 포트로 들어오는 요청을 8001~8004로 라운드로빈 로드밸런싱하거나, 단순하게 Nginx 없이 단일 인스턴스(방법 1)로 시작하셔도 B300 스펙상 충분히 강력합니다.

3. 서비스 동작 테스트

서버가 정상 구동되었는지 curl로 헬스체크 및 OpenAI 호환 엔드포인트를 호출해 봅니다.

# 1. 모델 목록 확인
curl http://localhost:8000/v1/models

# 2. 간단한 추론 테스트 (JSON 모드 지원 확인)
curl http://localhost:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{
    "model": "/data/models/Qwen2.5-32B-Instruct",
    "messages": [{"role": "user", "content": "Ping test"}],
    "max_tokens": 10
  }'

4. 이전 작성 스크립트(batch_enrich_markdown.py) 호출

vLLM이 베어메탈에서 실행되면, 작성해 둔 스크립트에서 --vllm-url과 --model 인자를 지정하여 실행합니다.

python batch_enrich_markdown.py \
  --input-dir ./docs_markdown \
  --output-dir ./vectordb_dataset \
  --final-json bulk_chunks_for_vectordb.json \
  --component "directpv" \
  --vllm-url "http://localhost:8000/v1" \
  --model "/data/models/Qwen2.5-32B-Instruct" \
  --concurrency 64

성능 팁: B300 환경에서는 --concurrency를 64~128 수준으로 올려도 vLLM의 PagedAttention과 Continuous Batching 덕분에 GPU 연산 유닛이 풀로 돌면서 수천 개 청크 처리가 순식간에 끝납니다.

==

vllm/vllm-openai:latest는 레지스트리 도메인이 생략되어 있으므로, Docker의 기본 레지스트리인 Docker Hub(docker.io)에서 가져옵니다.

전체 정규 주소(Full Image Name)는 다음과 같습니다:

  • Docker Hub: docker.io/vllm/vllm-openai:latest (또는 특정 버전 태그 권장: vllm/vllm-openai:v0.6.x 등)

폐쇄망 환경 반입 시 주의할 점 및 대체 레지스트리

  1. GitHub Container Registry (ghcr.io) 확인:
  • vLLM 프로젝트는 버전에 따라 Docker Hub뿐만 아니라 GitHub Container Registry(ghcr.io)에도 빌드 이미지를 배포합니다.
  • 예: ghcr.io/vllm-project/vllm:latest
  1. 폐쇄망 반입(Save & Load / 사내 Harbor 푸시):
  • 외부 인터넷이 연결된 망(망연계 PC/Bastion)에서 pull 받은 뒤 tar 파일로 묶어 폐쇄망으로 반입하거나, 사내 프라이빗 레지스트리(Harbor 등)에 push하여 사용합니다.
# 외부망에서 다운로드 및 저장
docker pull vllm/vllm-openai:latest
docker save -o vllm-openai-latest.tar vllm/vllm-openai:latest

# 폐쇄망 반입 후 로드
docker load -i vllm-openai-latest.tar

# 사내 레지스트리에 등록 시
docker tag vllm/vllm-openai:latest harbor.internal.net/ai-platform/vllm-openai:latest
docker push harbor.internal.net/ai-platform/vllm-openai:latest
  1. B300(Blackwell) 아키텍처 지원 태그 확인:
  • B300은 최신 CUDA 및 아키텍처 지원이 필요하므로, latest보다는 Blackwell(Compute Capability 10.0/12.0 계열)과 CUDA 12.4+ 환경이 정상 패키징된 공식 릴리스 태그를 확인하고 다운로드하는 것을 권장합니다.

===

RCA(근본 원인 분석)에 특화된 5가지 확장 메타데이터(doc_category, symptoms_and_errors, related_metrics, target_resources, is_destructive_action)를 vLLM에서 고속 비동기로 추출하고 청크 헤더와 JSON에 반영하도록 보강한 전체 스크립트 파일을 생성하겠습니다.

실행 및 활용 가이드

  1. 실행 명령 (B300 베어메탈 기준):
   python batch_enrich_markdown.py \
     --input-dir ./docs_markdown \
     --output-dir ./vectordb_dataset \
     --final-json bulk_chunks_for_vectordb.json \
     --component "directpv" \
     --vllm-url "http://localhost:8000/v1" \
     --model "/data/models/Qwen2.5-32B-Instruct" \
     --concurrency 48
  1. 최종 산출물 검증:
    생성된 bulk_chunks_for_vectordb.json의 각 청크는 아래와 같이 메타데이터 필터링(doc_category, related_metrics, is_destructive_action 등)에 완벽히 대응할 수 있는 구조로 저장됩니다.
{
  "id": "directpv_troubleshooting_drives.md_0001",
  "page_content": "[Context: Troubleshooting > Drive Discovery]\n[Category: TROUBLESHOOTING] [Target Resources: DirectPVDrive, Node]\n[Summary: DirectPV 디스크 자동 탐색 실패 시 해결 절차]\n[Symptoms/Errors: Drive formatted status stuck in pending, Discovery timeout]\n- Q: directpv에서 신규 드라이브가 인식되지 않을 때 확인 커맨드는?\n- Q: kubectl directpv drives discover 타임아웃 해결 방법\n\n## Drive Discovery Failure\nDirectPV discovers drives...",
  "metadata": {
    "component": "directpv",
    "doc_category": "TROUBLESHOOTING",
    "breadcrumb": "Troubleshooting > Drive Discovery",
    "summary": "DirectPV 디스크 자동 탐색 실패 시 해결 절차",
    "questions": [
      "directpv에서 신규 드라이브가 인식되지 않을 때 확인 커맨드는?",
      "kubectl directpv drives discover 타임아웃 해결 방법"
    ],
    "symptoms_and_errors": [
      "Drive formatted status stuck in pending",
      "Discovery timeout"
    ],
    "related_metrics": [
      "minio_node_drive_total_duration_microseconds"
    ],
    "target_resources": [
      "DirectPVDrive",
      "Node"
    ],
    "commands": [
      "kubectl directpv drives discover"
    ],
    "is_destructive_action": false,
    "h1": "Troubleshooting",
    "h2": "Drive Discovery"
  }
}

===

사내 Confluence에 저장된 장애 이력(Post-mortem) 및 SOP 문서를 REST API(단일 Page ID 또는 특정 Space 내 전체 검색 CQL)로 일괄 조회하여 Markdown으로 변환하고, 앞서 설계한 B300 vLLM을 활용해 RCA 특화 메타데이터와 가상 질문을 보강한 뒤 단일 JSON으로 묶어주는 통합 파이프라인 스크립트 파일을 생성하겠습니다.

주요 특징 및 Confluence 특화 추가 사항

  1. root_cause_hypotheses (알려진 근본 원인) 자동 추출:
  • Confluence에 작성된 장애 보고서(Post-mortem)에서 "이 장애를 일으켰던 실제 근본 원인"을 LLM이 요약하여 메타데이터와 청크 헤더에 심어줍니다.
  • 추후 RCA Agent의 가설 수집 단계(Node 3)에서 과거 동일 증상의 원인을 지식 베이스에서 즉시 소환할 수 있습니다.
  1. 단일 페이지(--page-id) 및 Space 일괄(--space) 지원:
  • 테스트로 특정 SOP 1개만 돌려볼 수도 있고, 특정 팀 Space 전체(예: --space SRE_STORAGE)를 한 번에 긁어모아 변환할 수도 있습니다.
  1. 원본 Markdown 백업 분리:
  • vLLM 보강 결과인 통합 JSON 외에도 raw_confluence_md/ 폴더에 깔끔하게 변환된 .md 파일들을 남겨두어, 사람이 직접 열람하거나 다른 용도로 활용할 수 있습니다.

실행 예시

# 1. 특정 장애 보고서/SOP 단일 페이지 변환 및 vLLM 보강
python confluence_to_vectordb_pipeline.py \
  --url "https://confluence.mycorp.internal" \
  --page-id "98765432" \
  --token "your-confluence-pat-token" \
  --no-verify-ssl \
  --component "minio-aistor" \
  --vllm-url "http://localhost:8000/v1" \
  --model "/data/models/Qwen2.5-32B-Instruct" \
  --concurrency 48

# 2. 특정 Space의 장애 매뉴얼 전체 일괄 변환
python confluence_to_vectordb_pipeline.py \
  --url "https://confluence.mycorp.internal" \
  --space "STORAGE_SOP" \
  --token "your-confluence-pat-token" \
  --no-verify-ssl \
  --component "minio-aistor" \
  --output-dir ./storage_sop_dataset \
  --final-json bulk_sop_chunks.json
profile
QK
engineer
이전 포스트

26S26f1

다음 포스트

26S26g

0개의 댓글