LiveHard

DGX Spark로 OpenClaw Local LLM 구성- GPT-OSS-120B 최적화하기

DanielZZI — Wed, 25 Feb 2026 19:34:17 +0900

DGX Spark에서 GPT-OSS 최적화하기

NVIDIA DGX Spark (GB10, SM 12.1, 128GB 통합 메모리) 환경에서
vLLM + openai/gpt-oss-120b의 추론 성능을 단계별로 최적화한 기록

1. 테스트 환경

항목	사양
하드웨어	NVIDIA DGX Spark (GB10 SoC)
GPU 아키텍처	Blackwell SM 12.1 (consumer/edge)
메모리	128GB 통합 메모리 (CPU+GPU 공유), 273 GB/s
OS	Linux 6.17.0-1008-nvidia (aarch64)
모델	openai/gpt-oss-120b (120B MoE, MXFP4)
추론 엔진	vLLM (NGC 이미지: nvcr.io/nvidia/vllm:26.01-py3)
배포 방식	Docker Compose

2. Baseline — 현재 상태

2.1 docker-compose.yml (원본)

services:
  vllm:
    image: nvcr.io/nvidia/vllm:26.01-py3
    container_name: vllm
    ipc: host
    shm_size: "32g"
    restart: unless-stopped
    ulimits:
      memlock: -1
      stack: 67108864
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "30000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ~/.cache/vllm:/root/.cache/vllm
      - ~/tiktoken_encodings:/tiktoken_encodings
    environment:
      - HF_TOKEN=${HF_TOKEN}
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
      - HF_HUB_OFFLINE=1
      - TIKTOKEN_ENCODINGS_BASE=/tiktoken_encodings
      - VLLM_USE_FLASHINFER_MXFP4_MOE=1
    command: >
      vllm serve openai/gpt-oss-120b
      --host 0.0.0.0
      --port 8000
      --trust-remote-code
      --async-scheduling
      --swap-space 16
      --max-model-len 32000
      --tensor-parallel-size 1
      --max-num-seqs 1024
      --gpu-memory-utilization 0.7

2.2 Baseline 성능 측정

지표	결과
모델 로딩 시간	~7분 19초 (439.87s safetensors + 455.3s 전체)
모델 메모리 사용	65.97 GiB
KV 캐시 가용 메모리	9.41 GiB
최대 동시 처리 (32K 토큰 기준)	8.01x
TTFT (Time to First Token)	179 ms
생성 속도	~34.9 tok/s
Marlin 경고	"GPU does not have native FP4... may degrade performance"

2.3 Baseline의 문제점

--swap-space 16: 통합 메모리에서 CPU swap 16GB를 예약하면 GPU가 사용할 수 있는 대역폭이 줄어듦
--max-num-seqs 1024: 단일 사용자 환경(OpenClaw)에서 1024 시퀀스는 과도. 불필요한 메모리 예약
KV 캐시 기본 dtype: auto(fp16)로 KV 캐시 메모리 효율이 낮음
Prefix caching 미사용: 동일 시스템 프롬프트를 매 요청마다 재계산
reasoning/tool-call parser 미설정: GPT-OSS의 reasoning 토큰이 올바르게 분리되지 않음
캐시 마운트 부족: flashinfer, triton JIT 캐시가 컨테이너 재시작 시 소실

3. 1단계 — NGC 이미지 튜닝

이미지 변경 없이, 실행 파라미터와 환경 설정만으로 성능을 개선한다.

3.1 변경 사항

변경	Before	After	근거
`--swap-space`	16	제거	통합 메모리에서 CPU swap은 GPU 대역폭 손실
`--max-num-seqs`	1024	8	단일 사용자 환경에 맞게 축소, 메모리 절감
`--kv-cache-dtype`	(auto)	fp8	KV 캐시 메모리 절반 절감 → 더 많은 토큰 처리 가능
`--enable-prefix-caching`	없음	추가	반복되는 시스템 프롬프트 캐싱으로 TTFT 단축
`--max-num-batched-tokens`	(없음)	8192	배치 크기 제한으로 메모리 사용 안정화
`--reasoning-parser`	없음	openai_gptoss	GPT-OSS reasoning 토큰 올바른 파싱
`--tool-call-parser`	없음	openai	tool call 올바른 파싱
`--enable-auto-tool-choice`	없음	추가	자동 tool call 감지
환경변수	`VLLM_USE_FLASHINFER_MXFP4_MOE`	양쪽 모두 설정	버전 호환성 확보
캐시 마운트	vllm만	flashinfer, triton 추가	JIT 캐시 재시작 시 유지

3.2 docker-compose.yml (1단계 튜닝)

services:
  vllm:
    image: nvcr.io/nvidia/vllm:26.01-py3
    container_name: vllm
    ipc: host
    shm_size: "32g"
    restart: unless-stopped
    ulimits:
      memlock: -1
      stack: 67108864
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "30000:8000"
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ~/.cache/vllm:/root/.cache/vllm
      - ~/.cache/flashinfer:/root/.cache/flashinfer
      - ~/.triton:/root/.triton
      - ~/tiktoken_encodings:/tiktoken_encodings
    environment:
      - HF_TOKEN=${HF_TOKEN}
      - HUGGING_FACE_HUB_TOKEN=${HF_TOKEN}
      - HF_HUB_OFFLINE=1
      - TIKTOKEN_ENCODINGS_BASE=/tiktoken_encodings
      - VLLM_USE_FLASHINFER_MXFP4_MOE=1
      - VLLM_USE_FLASHINFER_MOE_MXFP4_MXFP8=1
    command: >
      vllm serve openai/gpt-oss-120b
      --host 0.0.0.0
      --port 8000
      --trust-remote-code
      --async-scheduling
      --max-model-len 32000
      --tensor-parallel-size 1
      --max-num-seqs 8
      --gpu-memory-utilization 0.7
      --kv-cache-dtype fp8
      --enable-prefix-caching
      --max-num-batched-tokens 8192
      --reasoning-parser openai_gptoss
      --tool-call-parser openai
      --enable-auto-tool-choice
    healthcheck:
      test: ["CMD", "curl", "-f", "http://localhost:8000/health"]
      interval: 30s
      timeout: 10s
      retries: 5
      start_period: 600s

3.3 각 변경의 의미

--swap-space 제거
일반 서버에서는 CPU RAM과 GPU VRAM이 물리적으로 분리되어 있어, CPU 쪽에 KV 캐시 swap 공간을 두면 GPU 메모리가 부족할 때 백업으로 활용된다. 하지만 DGX Spark의 통합 메모리에서는 CPU swap도 GPU와 같은 물리 메모리를 사용하므로, 16GB를 CPU swap으로 예약하면 GPU가 실제로 쓸 수 있는 메모리 대역폭이 줄어든다.

--kv-cache-dtype fp8
KV 캐시는 이전 토큰들의 "기억"을 저장하는 공간이다. 기본값 fp16(16비트)을 fp8(8비트)으로 바꾸면 같은 메모리에 2배의 토큰을 저장할 수 있다. 정밀도가 약간 줄지만 실제 출력 품질 차이는 거의 없다.

--enable-prefix-caching
OpenClaw 같은 코딩 어시스턴트는 매 요청마다 동일한 시스템 프롬프트를 보낸다. prefix caching을 켜면 이 부분의 KV 캐시를 재활용하여 두 번째 요청부터 TTFT가 단축된다.

--max-num-seqs 8
동시에 처리할 최대 시퀀스 수. 1024는 대규모 서비스용이고 단일 사용자 환경에서는 8이면 충분하다. 줄이면 KV 캐시를 위한 메모리 예약이 줄어 실제 사용 가능한 캐시 공간이 늘어난다.

--reasoning-parser openai_gptoss + --tool-call-parser openai
GPT-OSS는 답변 전에 reasoning(사고 과정)을 생성한다. 파서가 없으면 reasoning과 실제 답변이 뒤섞여 나온다. tool-call 파서는 function calling(파일 읽기/쓰기 등)을 사용할 때 필요하다.

캐시 마운트 (flashinfer, triton)
FlashInfer(어텐션 커널)와 Triton(JIT 컴파일러)은 처음 실행 시 GPU 커널을 컴파일한다. 호스트에 마운트하면 컨테이너 재시작 후에도 컴파일 결과를 재사용할 수 있다.

3.4 1단계 성능 측정

지표	Baseline	1단계	변화
모델 로딩 시간	439.87s (~7분 19초)	408.98s (~6분 49초)	-31초
모델 메모리 사용	65.97 GiB	65.97 GiB	동일
KV 캐시 가용 메모리	9.41 GiB	14.89 GiB	+58%
KV 캐시 토큰 수	137,024	433,760	+3.2배
최대 동시 처리 (32K기준)	8.01x	21.51x	+2.7배
TTFT (첫 요청, cold)	179 ms	915 ms	CUDA graph 초기화
TTFT (이후 요청, warm)	179 ms	174 ms	-5ms
생성 속도	~34.9 tok/s	~34.9 tok/s	변화 없음
Marlin 경고	있음	있음	동일

3.5 1단계 결론: 속도는 안 바뀐다

tok/s가 동일한 이유: 생성 속도의 병목은 Marlin 커널이다.

Marlin은 SM 12.1(DGX Spark)에서 FP4 네이티브 연산을 지원하지 못하고, "FP4 가중치를 압축 해제 → fp16으로 변환 → 일반 행렬 곱셈"으로 처리한다. 아무리 KV 캐시를 최적화하고 메모리를 확보해도, 가중치 연산 자체가 느린 것은 바뀌지 않는다.

생성 속도 병목 분석:

[요청] → [KV 캐시 조회] → [가중치 연산 (Marlin)] → [토큰 출력]
         ↑ 1단계 개선됨     ↑ 병목 — 여기가 안 바뀜

그러나 1단계는 쓸모없는 것이 아니다:

KV 캐시 3.2배 확대로 더 긴 대화를 처리할 수 있게 됨
동시 처리 능력 2.7배 증가로 다중 요청 시 유리
로딩 31초 단축, reasoning/tool-call 올바른 파싱
tok/s를 올리려면 2단계(CUTLASS)가 필수

참고) KV 캐시 용량이 늘면 왜 tok/s는 안 바뀌나?

직관적으로는 "메모리가 많으면 빨라야지"가 맞지만, LLM 추론에는 두 가지 다른 종류의 "빠름"이 있다.

토큰 생성의 두 단계:

[Prefill]  입력 토큰을 한꺼번에 처리 → KV 캐시에 저장
           이 단계의 속도 = TTFT (Time to First Token)
           ※ KV 캐시 용량이 중요

[Decode]   토큰을 하나씩 생성 (반복)
           이 단계의 속도 = tok/s
           ※ 가중치 연산(Marlin/CUTLASS) 속도가 중요

토큰 1개를 생성할 때 일어나는 일:

KV 캐시에서 이전 토큰 정보 읽기 — 메모리 읽기 (~2ms)
120B 모델의 가중치를 곱하는 행렬 연산 — GPU 연산 (~24ms) ← 여기가 병목
다음 토큰 확률 계산, 출력 — (~2ms)

토큰 1개 생성 시간 (~28ms = 1/34.9초):

  KV 캐시 읽기:  ██ (~2ms)
  가중치 연산:   ████████████████████████ (~24ms)  ← Marlin 병목
  토큰 출력:     █ (~2ms)

KV 캐시를 3배로 늘려도 2번의 가중치 연산 24ms는 줄어들지 않는다.
더 큰 KV 캐시는 "더 많은 걸 기억할 수 있다"이지 "더 빨리 계산할 수 있다"가 아니다.

KV 캐시 확대가 빛을 발하는 순간:

상황	Baseline (9.41 GiB)	1단계 (14.89 GiB)
단일 요청, 짧은 대화	34.9 tok/s	34.9 tok/s (동일)
동시 3명이 32K 대화	가능 (8.01x)	가능 (21.51x)
동시 10명이 32K 대화	불가능	가능
매우 긴 코드 파일 분석	메모리 부족 가능	여유

비유하면: KV 캐시 = 책상 크기, 가중치 연산 = 계산 속도.
책상을 3배로 키우면 서류를 더 많이 펼쳐놓을 수 있지만,
계산을 빨리 하려면 더 빠른 계산기(CUTLASS)가 필요하다.

4. 2단계 — 커스텀 이미지 빌드 (spark-vllm-docker)

eugr/spark-vllm-docker 프로젝트의
Experimental MXFP4 빌드를 사용하여 SM 12.1 전용 최적화를 적용한다.

4.1 커스텀 빌드가 다른 점

NGC 이미지(nvcr.io/nvidia/vllm:26.01-py3)는 범용 이미지로, DGX Spark(SM 12.1)에 특화된 최적화가 없다.
spark-vllm-docker의 Experimental MXFP4 빌드는 다음이 다르다:

구분	NGC 이미지	spark-vllm-docker MXFP4 빌드
베이스	nvcr.io/nvidia/vllm:26.01-py3	nvcr.io/nvidia/pytorch:26.01-py3 (직접 빌드)
vLLM	NVIDIA 사전 빌드	christopherowen/vllm 포크 (MXFP4 최적화)
FlashInfer	NGC 번들	christopherowen/flashinfer 포크 (SM 12.1 전용)
CUTLASS	NGC 번들	christopherowen/cutlass 포크 (MXFP4 커널)
GPU 아키텍처 타겟	범용	`TORCH_CUDA_ARCH_LIST=12.1a` 전용
MXFP4 백엔드	Marlin (범용 사전 컴파일)	CUTLASS (SM 12.1 최적화)
모델 로딩	safetensors (mmap)	fastsafetensors (멀티스레드, mmap 회피)
Quantization	암시적 (모델 내장)	명시적 `--quantization mxfp4`

4.2 GPT-OSS 전용 Recipe

spark-vllm-docker는 GPT-OSS 전용 recipe를 제공한다:

# recipes/openai-gpt-oss-120b.yaml
container: vllm-node-mxfp4
build_args:
  - --exp-mxfp4

env:
  VLLM_USE_FLASHINFER_MOE_MXFP4_MXFP8: "1"

command: |
  vllm serve openai/gpt-oss-120b \
    --tool-call-parser openai \
    --reasoning-parser openai_gptoss \
    --enable-auto-tool-choice \
    --enable-prefix-caching \
    --load-format fastsafetensors \
    --quantization mxfp4 \
    --mxfp4-backend CUTLASS \
    --mxfp4-layers moe,qkv,o,lm_head \
    --attention-backend FLASHINFER \
    --kv-cache-dtype fp8 \
    --max-num-batched-tokens 8192 \
    --gpu-memory-utilization 0.70

핵심 차이:

--quantization mxfp4 --mxfp4-backend CUTLASS: Marlin 대신 CUTLASS 백엔드로 MXFP4 연산
--mxfp4-layers moe,qkv,o,lm_head: MoE뿐 아니라 attention(QKV, O)과 LM head까지 MXFP4 적용
--attention-backend FLASHINFER: 커스텀 FlashInfer로 SM 12.1에서도 FlashInfer 사용 가능
--load-format fastsafetensors: mmap 대신 멀티스레드 직접 로딩

4.3 빌드 방법

git clone https://github.com/eugr/spark-vllm-docker.git
cd spark-vllm-docker

# MXFP4 전용 이미지 빌드 (20~30분 소요)
./build-and-copy.sh -t vllm-node-mxfp4 --exp-mxfp4

# 실행 (단일 노드)
./launch-cluster.sh --solo -t vllm-node-mxfp4 exec \
  vllm serve openai/gpt-oss-120b \
    --host 0.0.0.0 --port 8888 \
    --enable-auto-tool-choice \
    --tool-call-parser openai \
    --reasoning-parser openai_gptoss \
    --gpu-memory-utilization 0.70 \
    --enable-prefix-caching \
    --load-format fastsafetensors \
    --quantization mxfp4 \
    --mxfp4-backend CUTLASS \
    --mxfp4-layers moe,qkv,o,lm_head \
    --attention-backend FLASHINFER \
    --kv-cache-dtype fp8 \
    --max-num-batched-tokens 8192

4.4 빌드 소요 시간

실측 빌드 시간: 약 65분 (DGX Spark ARM CPU에서)

README에서는 20~30분이라고 했지만, 이는 x86 환경 기준이다.
DGX Spark의 ARM CPU(aarch64)에서는 CUDA 크로스 컴파일이 더 오래 걸린다.
다만 Docker 빌드 캐시 덕분에 두 번째 빌드부터는 변경된 부분만 재컴파일되어 훨씬 빨라진다.

빌드 단계별 소요 시간 (실측):

[1] 베이스 이미지 풀 (pytorch:26.01-py3)     ~10분
[2] FlashInfer CUDA 커널 컴파일              ~15분
[3] CUTLASS MXFP4 커널 컴파일                ~10분
[4] vLLM 소스 빌드                           ~25분
[5] Runner 이미지 조립                        ~5분
                                     합계: ~65분

4.5 2단계 성능 측정

로그에서 확인된 핵심 변화:

[MXFP4] Using backend: CUTLASS (--mxfp4-backend)
SM12x detected - using native FlashInfer CUTLASS attention
Loading safetensors using Fastsafetensor loader
[MXFP4] lm_head quantized: BF16 -> FP4 (4x smaller)

Marlin 경고(may degrade performance) → 완전히 사라짐
어텐션 백엔드: triton JIT → FlashInfer 네이티브 CUTLASS
모델 로딩: mmap(28초/샤드) → fastsafetensors(3초/샤드)
lm_head: fp16 유지 → MXFP4 양자화 (4배 압축)

지표	Baseline	1단계	2단계 (실측)
가중치 로딩 시간	439.87s (7분 19초)	408.98s (6분 49초)	46.16s (46초) — 9.5배 빨라짐
모델 메모리	65.97 GiB	65.97 GiB	61.33 GiB (-4.6 GiB)
TTFT (1st, cold)	179 ms	915 ms	264 ms
TTFT (2nd, warm)	179 ms	174 ms	129 ms
생성 속도	34.9 tok/s	34.9 tok/s	56.8 tok/s (+63%)
Marlin 경고	있음	있음	없음

4.6 왜 56.8 tok/s가 가능한가?

NGC 이미지의 Marlin 백엔드는 SM 12.1에서 FP4 네이티브 연산을 활용하지 못하고 weight-only 압축으로 동작한다.
이것이 바로 "may degrade performance" 경고의 의미다.

Marlin (Baseline):
  FP4 가중치 → fp16 압축 해제 → fp16 행렬 곱셈 → 결과
  ↑ 변환 오버헤드              ↑ 정밀도 높지만 느림

CUTLASS MXFP4 (2단계):
  FP4 가중치 → 직접 FP4 행렬 곱셈 → 결과
               ↑ 변환 없이 바로 연산, SM 12.1 mma.sync 최적화

CUTLASS 기반 MXFP4 빌드가 빠른 이유:

FP4 가중치를 변환 없이 직접 연산 — Marlin의 "압축 해제 → fp16 변환" 오버헤드 제거
MoE뿐 아니라 QKV/O/LM-head까지 MXFP4 적용 → 전체 연산의 양자화 범위 확대, 메모리 4.6GiB 절감
FlashInfer 커스텀 빌드로 attention도 SM 12.1에 맞게 CUTLASS 기반 네이티브 어텐션 사용
fastsafetensors로 mmap 대신 멀티스레드 직접 로딩 → 로딩 시간 9.5배 단축

5. 성능 비교 요약

지표	Baseline	1단계 (NGC 튜닝)	2단계 (MXFP4 빌드)
이미지	NGC 26.01-py3	NGC 26.01-py3	spark-vllm-docker MXFP4
생성 속도	34.9 tok/s	34.9 tok/s	56.8 tok/s (+63%)
TTFT (warm)	179 ms	174 ms	129 ms (-28%)
모델 로딩	439.87s (7분 19초)	408.98s (6분 49초)	46.16s (46초) — 9.5배
모델 메모리	65.97 GiB	65.97 GiB	61.33 GiB (-4.6GiB)
KV 캐시 용량	9.41 GiB	14.89 GiB	fp8 + CUTLASS
최대 동시 처리	8.01x	21.51x	-
prefix caching	미사용	사용	사용
MXFP4 백엔드	Marlin (범용)	Marlin (범용)	CUTLASS (SM 12.1 최적화)
Marlin 경고	있음	있음	없음
reasoning 파싱	미지원	지원	지원
난이도	쉬움	쉬움	빌드 ~65분 (ARM)

6. 결론 및 권장 사항

1단계만으로 충분한가?

tok/s는 변하지 않지만, KV 캐시 3.2배 확대와 reasoning/tool-call 파싱은 의미 있는 개선이다.
단, 코딩 어시스턴트처럼 체감 응답 속도가 중요한 경우 2단계가 필수다.

2단계의 실질적 가치

56.8 tok/s: 사람이 읽는 속도(~5 tok/s)의 11배. 코드 생성 시 거의 실시간 체감
46초 로딩: 컨테이너 재시작 시 1분 안에 서비스 복구 (baseline은 7분 이상)
메모리 4.6GiB 절감: 다른 서비스를 함께 돌릴 여유 확보
Marlin 경고 해소: "may degrade performance" 없이 깨끗한 운영

권장 사항

용도	권장	이유
빠른 셋업, 테스트용	1단계 (NGC 튜닝)	이미지 빌드 없이 즉시 적용
OpenClaw/Cursor 상시 운영	2단계 (MXFP4 빌드)	63% 빠른 응답, 9.5배 빠른 재시작
다중 사용자 서비스	2단계 + `--max-num-seqs` 조정	높은 동시성 + 빠른 생성
Dual DGX Spark 클러스터	2단계 + `-tp 2 --distributed-executor-backend ray`	더 큰 모델/컨텍스트

참고 자료

eugr/spark-vllm-docker — DGX Spark 전용 vLLM Docker 최적화 프로젝트
christopherowen/vllm — MXFP4 CUTLASS 백엔드 포크
NVIDIA DGX Spark 공식 문서
이전 블로그: DGX Spark로 OpenClaw Local LLM 구성 — Provider 선정기

DGX Spark로 OpenClaw Local LLM 구성 — Provider 선정기

DanielZZI — Wed, 25 Feb 2026 13:45:30 +0900

DGX Spark로 OpenClaw Local LLM 구성 — Provider 선정기

핫한 OpenClaw로 이것저것 시도해보던중 유료 LLM의 탁월한 성능과 함께 개발단계부터 비용적 한계를 느꼈다.

그래서 하이브리드 구성(전략: 유료 LLM 연산/실행: Local LLM) 을 위해 먼저 local LLM Provider로 Ollama, SGLang, vLLM 세 가지를 DGX Spark에서 테스트했다.

GPT-OSS-120B 모델 기준으로 DGX Spark에서 테스트해보고 내린 결론은

개인 사용이면 Ollama(41 tok/s), 팀 공유 서버면 vLLM(35.3 tok/s)이다.

SGLang은 DGX Spark의 GPU(SM 12.1)가 데이터센터 Blackwell(SM 100)과 다른 명령어 세트를 사용하여 구조적으로 동작하지 않는다.

1. 배경: OpenClaw에 로컬 LLM이 필요한 이유

OpenClaw 같은 AI 코딩 어시스턴트를 업무에 쓰려면 LLM Provider가 필요하다.

클라우드 API(OpenAI, Anthropic 등)를 쓸 수도 있지만, 보안/비용/레이턴시를 고려하면 로컬 LLM 서빙이 매력적인 선택지다.

마침 NVIDIA DGX Spark가 있으니, 128GB 통합 메모리에 120B 파라미터 모델(openai/gpt-oss-120b)을 올려서 OpenClaw의 로컬 Provider로 쓸 수 있는지 테스트해보기로 했다.

문제는 어떤 추론 엔진(Provider)을 써야 하는가이다.

후보는 세 가지:

후보	특징	기대
Ollama	llama.cpp 기반, 설정 간편, 개인용	빠르게 올려서 바로 쓰기 좋을 것
SGLang	LMSYS 개발, DGX Spark 공식 가이드 존재	공식 지원이니 가장 안정적일 것
vLLM	NVIDIA 공식 Docker 이미지, 프로덕션급 서빙	다중 사용자 대응에 유리할 것

결론부터 말하면, 예상과 달리 SGLang은 DGX Spark에서 아예 동작하지 않았고, 그 과정에서 "Blackwell"이라는 이름 아래 숨어있는 하드웨어 아키텍처 차이(SM 100 vs SM 12.1)를 발견했다. 이 글은 그 선정 과정의 기록이다.

중요 배경: DGX Spark의 GB10 GPU는 "Blackwell"이라는 브랜드명을 공유하지만, 데이터센터 Blackwell(B200, SM 100)과는 다른 명령어 세트(ISA)를 사용한다(SM 12.1). 이 차이가 SGLang 실패의 근본 원인이다. 자세한 내용은 부록 B와 11장 참조.

2. 테스트 환경

하드웨어

항목	사양
장치	NVIDIA DGX Spark
GPU	NVIDIA GB10 (Blackwell, SM 12.1)
메모리	128GB 통합 메모리 (CPU/GPU 공유)
아키텍처	aarch64 (ARM64)
스토리지	3.6TB NVMe

소프트웨어

항목	버전
OS	Ubuntu (Linux 6.17.0-1008-nvidia)
NVIDIA Driver	580.126.09
CUDA	13.0
Docker	29.1.3
Docker Compose	v5.0.1

모델

항목	값
모델	`openai/gpt-oss-120b`
파라미터 수	120B (MoE)
양자화	MXFP4
모델 크기 (디스크)	~65GB (safetensors)
포맷	HuggingFace safetensors

3. 후보 1: Ollama — "일단 빠르게 올려보자"

구성

항목	값
Docker 이미지	`ghcr.io/open-webui/open-webui:ollama`
엔진	Ollama (llama.cpp 백엔드)
양자화	MXFP4 (네이티브 4-bit)
모델 크기	~65 GB
메모리 관리	mmap (메모리 매핑)

docker-compose.yml

services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:ollama
    container_name: open-webui
    restart: unless-stopped
    volumes:
      - /home/username/ollama-data:/root/.ollama
    deploy:
      resources:
        reservations:
          devices:
            - driver: nvidia
              count: all
              capabilities: [gpu]
    ports:
      - "3000:8080"
      - "11434:11434"

결과: 성공

첫 시도에서 성공. OOM 없이 안정적으로 운영되었다.

메모리 사용량 (안정 상태)

자원	사용량
GPU (모델)	~65 GB
CPU RAM	~2 GB
합계	~67 GB / 128 GB
여유	~61 GB

Ollama는 llama.cpp 기반으로 mmap(메모리 매핑 파일)을 사용한다. 모델 가중치를 CPU RAM에 별도 로드하지 않고 디스크에서 직접 GPU 메모리로 매핑하므로, CPU RAM 사용량이 극히 낮다. 128GB 통합 메모리 환경에서 가장 효율적인 방식이다.

성능 벤치마크

항목	결과
Decode 속도	~41 tok/s
Prefill 속도	~1,169 tok/s
모델 로딩	~5초 (cold start, mmap)

Ollama의 강점과 한계

강점:

mmap 기반으로 통합 메모리 환경에서 OOM 위험이 거의 없다
CPU RAM 오버헤드가 극히 낮다 (~2GB)
설정이 간단하고 Docker에서도 안정적
단일 사용자 기준으로 가장 빠른 토큰 생성 속도

한계:

llama.cpp는 단일 사용자 중심 설계로, 동시 요청 처리 시 성능이 선형으로 감소
PagedAttention, Continuous Batching 등 고급 서빙 기능이 없음
KV 캐시 관리가 원시적이어서 다중 세션에서 비효율적
OpenAI 호환 API 지원이 제한적 (reasoning/tool-call 파싱 미지원)

4. 후보 2: SGLang — "공식 가이드가 있으니 안정적이겠지"

구성

항목	값
Docker 이미지	`lmsysorg/sglang:spark` (23.8GB)
엔진 버전	SGLang (Spark 전용 빌드)
CUDA Capability	12.1 (PyTorch 지원 범위 8.0~12.0 경고 발생)

docker-compose.yml (최종 시도)

services:
  sglang:
    image: lmsysorg/sglang:spark
    container_name: sglang
    ipc: host
    shm_size: "32g"
    restart: unless-stopped
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ~/tiktoken_encodings:/tiktoken_encodings
    environment:
      - HF_HUB_OFFLINE=1
      - TIKTOKEN_ENCODINGS_BASE=/tiktoken_encodings
    command: >
      python3 -m sglang.launch_server
      --model-path openai/gpt-oss-120b
      --host 0.0.0.0
      --port 30000
      --reasoning-parser gpt-oss
      --tool-call-parser gpt-oss

시도 과정 및 결과

시도 1: `--attention-backend flashinfer`

AssertionError: GptOssForCausalLM requires one of
['triton', 'trtllm_mha', 'fa3', 'fa4'] attention backend,
but got flashinfer

GPT-OSS 모델은 flashinfer 백엔드를 지원하지 않아 시작 단계에서 즉시 실패했다.

시도 2: `--attention-backend triton`, `--mem-fraction-static 0.75`

모델 가중치 15/15 샤드 로딩 성공
GPU 메모리에 62.8GB 적재 완료
이후 triton 커널 JIT 컴파일 단계에서 CPU RAM이 급격히 증가
CPU RAM: 3.8GB → 14.7GB → 26.7GB → 35.8GB → 51.2GB (20분간 지속 증가)
최종적으로 OOM Kill 발생

Out of memory: Killed process 618610 (sglang::schedul)
total-vm: 155.5GB, anon-rss: 51.2GB

OOM 시점의 메모리 상황:

자원	사용량
GPU (모델 가중치)	62.8 GB
CPU RAM (scheduler)	51.2 GB
합계	~114 GB / 128 GB

통합 메모리 풀의 한계(128GB)에 도달하여 커널이 프로세스를 강제 종료했다.

시도 3: `--mem-fraction-static 0.40` (KV 캐시 축소)

메모리 비율을 0.75 → 0.40으로 낮춰 재시도
동일하게 triton 커널 컴파일 중 CPU RAM 폭주
컨테이너 재시작 반복 (OOM → restart → OOM 루프)

시도 4: 공식 LMSYS 가이드 준수 (attention-backend/mem-fraction 제거)

LMSYS 공식 블로그 기반으로 불필요한 옵션 제거
tiktoken 인코딩 사전 다운로드, HF_HUB_OFFLINE=1 추가
여전히 커널 컴파일 단계에서 CPU RAM이 32GB 이상으로 증가하며 불안정

SGLang 실패 원인 분석

통합 메모리 구조의 한계: DGX Spark의 128GB는 CPU와 GPU가 공유하는 물리 메모리 풀이다. SGLang은 PyTorch 기반으로 GPU 메모리(모델 62.8GB)와 CPU 메모리(scheduler 50GB+)를 동시에 대량 소비하여 풀 전체를 고갈시킨다.
triton 커널 JIT 컴파일: MoE 모델의 triton 커널을 JIT 컴파일하는 과정에서 CPU RAM 사용량이 제어 없이 증가한다. 이 과정에서 로그 출력도 없어 진행 상황 파악이 불가능하다.
Docker 오버헤드: NVIDIA 포럼의 SGLang 성공 사례는 대부분 네이티브 설치(uv venv)이며, Docker 환경에서의 성공 사례는 드물다. 컨테이너 런타임의 추가 메모리 오버헤드가 128GB 통합 메모리 환경에서는 치명적이다.

5. 후보 3: vLLM — "SGLang이 안 되니 대안을 찾자"

구성

항목	값
Docker 이미지	`nvcr.io/nvidia/vllm:26.01-py3` (13.1GB)
엔진 버전	vLLM v0.13.0 (nv26.01)
Attention 백엔드	TRITON_ATTN (자동 감지)
양자화 백엔드	Marlin (MXFP4)
MoE 최적화	separate CUDA stream for shared_experts

docker-compose.yml

services:
  vllm:
    image: nvcr.io/nvidia/vllm:26.01-py3
    container_name: vllm
    ipc: host
    shm_size: "32g"
    restart: unless-stopped
    ulimits:
      memlock: -1
      stack: 67108864
    volumes:
      - ~/.cache/huggingface:/root/.cache/huggingface
      - ~/.cache/vllm:/root/.cache/vllm
      - ~/tiktoken_encodings:/tiktoken_encodings
    environment:
      - HF_HUB_OFFLINE=1
      - TIKTOKEN_ENCODINGS_BASE=/tiktoken_encodings
      - VLLM_USE_FLASHINFER_MXFP4_MOE=1
    command: >
      vllm serve openai/gpt-oss-120b
      --host 0.0.0.0
      --port 8000
      --trust-remote-code
      --async-scheduling
      --swap-space 16
      --max-model-len 32000
      --tensor-parallel-size 1
      --max-num-seqs 1024
      --gpu-memory-utilization 0.7

시작 로그 (주요 단계)

V1 LLM engine (v0.13.0+faa43dbf.nv26.01)
quantization=mxfp4, dtype=torch.bfloat16, max_seq_len=32000
Using TRITON_ATTN attention backend
Using Marlin backend (MXFP4)
Enabled separate cuda stream for MoE shared_experts

Loading safetensors: 15/15 [06:32, 26.20s/it]
Loading weights took 393.18 seconds
Model loading took 65.97 GiB memory and 408.14 seconds

Available KV cache memory: 7.69 GiB
GPU KV cache size: 112,000 tokens
Maximum concurrency for 32,000 tokens per request: 6.55x

Graph capturing finished in 21 secs
init engine (profile, create kv cache, warmup model) took 77.09 seconds

Starting vLLM API server on http://0.0.0.0:8000

결과: 성공

첫 시도에서 성공적으로 서버가 가동되었다. OOM 없이 안정적으로 운영 가능했다.

메모리 사용량 (안정 상태)

자원	사용량
GPU (모델 + KV 캐시)	84.7 GB
CPU RAM	6.5 GB
합계	~91.2 GB / 128 GB
여유	~37 GB

성능 벤치마크

테스트 1: 단순 질의

curl http://localhost:30000/v1/chat/completions \
  -d '{"model":"openai/gpt-oss-120b",
       "messages":[{"role":"user","content":"What is 2+2? Answer briefly."}],
       "max_tokens":50}'

항목	결과
응답	"4."
Prompt tokens	79
Completion tokens	40 (reasoning 포함)
응답 시간	1.73초

테스트 2: 긴 텍스트 생성

curl http://localhost:30000/v1/chat/completions \
  -d '{"model":"openai/gpt-oss-120b",
       "messages":[{"role":"user","content":"Generate a long story about a robot learning to cook."}],
       "max_tokens":512}'

항목	결과
Prompt tokens	84
Completion tokens	512
소요 시간	14.49초
토큰 생성 속도	35.3 tokens/sec

6. 세 후보 종합 비교

안정성

항목	Ollama	SGLang	vLLM
Docker 이미지	`open-webui:ollama`	`lmsysorg/sglang:spark` (23.8GB)	`nvcr.io/nvidia/vllm:26.01-py3` (13.1GB)
서버 가동	성공 (첫 시도)	실패 (4회 OOM)	성공 (첫 시도)
OOM 발생	없음	반복 (커널 강제 종료)	없음
CPU RAM 사용	~2 GB	30~51 GB (제어 불가)	6.5 GB
GPU 메모리	~65 GB	62.8 GB (KV 캐시 전 OOM)	84.7 GB (모델 + KV 캐시)
메모리 여유	~61 GB	부족 (OOM)	~37 GB
초기화 시간	~5초 (mmap)	측정 불가 (OOM)	~8분

메모리 효율

항목	Ollama	SGLang	vLLM
런타임	C++ (llama.cpp)	Python (PyTorch)	Python (PyTorch)
모델 로딩	mmap (디스크 직접 매핑)	전체 로드	PagedAttention + Marlin
KV 캐시 관리	동적 (단순)	고정 비율 사전 할당	PagedAttention (동적 페이지)
통합 메모리 적합성	최적	부적합	양호

기능 비교

기능	Ollama	SGLang	vLLM
OpenAI 호환 API	△ (기본적)	O	O (완전)
Reasoning/Tool Call 파싱	X	O	O (자동 감지)
Chunked Prefill	X	O	O
CUDA Graph	X	O	O
Prefix Caching	X	O	O
Continuous Batching	X	O	O
Async Scheduling	X	-	O
동시 요청 처리	△ (성능 선형 감소)	O	O (효율적)

성능 비교 (Docker 환경, 단일 요청)

엔진	토큰 생성 속도	환경	출처
Ollama (Docker)	41 tok/s	Docker	직접 테스트
vLLM (Docker)	35.3 tok/s	Docker	직접 테스트
SGLang (Docker)	측정 불가 (OOM)	Docker	직접 테스트

참고: 네이티브 환경 벤치마크

엔진	토큰 생성 속도	출처
llama.cpp (네이티브)	~60 tok/s	NVIDIA 포럼
SGLang (네이티브)	~52 tok/s	LMSYS 블로그
vLLM (네이티브)	~35 tok/s	NVIDIA 포럼

네이티브 설치 환경에서도 llama.cpp 계열이 가장 빠르다. 이는 C++ 네이티브 구현 + mmap의 메모리 효율이 PyTorch 기반 엔진보다 DGX Spark의 통합 메모리 구조에 본질적으로 유리하기 때문이다.

7. 결론: OpenClaw Provider로 무엇을 골랐는가

왜 Ollama(llama.cpp)가 가장 빠른가 — 통합 메모리 구조의 이해

일반 서버 vs DGX Spark — 메모리 구조가 근본적으로 다르다

일반 GPU 서버(A100, H100 등)는 CPU 메모리(RAM)와 GPU 메모리(VRAM)가 물리적으로 분리되어 있다. 각자 독립된 메모리 칩과 독립된 대역폭을 가진다.

[일반 서버]

  CPU ──── RAM (256GB, DDR5)          ← CPU 전용, 서로 간섭 없음
            │
         PCIe 연결
            │
  GPU ──── VRAM (80GB, HBM3)         ← GPU 전용, 서로 간섭 없음

  → CPU가 RAM을 많이 써도 GPU VRAM 성능에 영향 없음

DGX Spark(GB10)는 다르다. CPU와 GPU가 하나의 물리 메모리(128GB)를 함께 쓴다. 마치 하나의 수도관을 두 집이 나눠 쓰는 것과 같다.

[DGX Spark — 통합 메모리]

  CPU ────┐
          ├──── 128GB 통합 메모리 (LPDDR5x, 273 GB/s)
  GPU ────┘

  → CPU가 RAM을 많이 쓰면, GPU가 쓸 수 있는 대역폭이 줄어든다

LLM 추론의 병목: 메모리 대역폭

LLM이 토큰을 생성할 때, GPU는 모델 가중치(65GB)를 메모리에서 읽어온다. 이 과정은 계산보다 메모리 읽기가 병목이다 (memory-bound). 즉, 메모리를 얼마나 빨리 읽느냐 = 토큰 생성 속도다.

DGX Spark의 메모리 대역폭은 273 GB/s이다. 이론적 최대 토큰 생성 속도는:

65GB 모델 ÷ 273 GB/s = 0.238초/토큰 → 이론상 한계 약 4.2 tok/s... 가 아니다.

MoE 모델이므로 토큰당 활성 파라미터는 5.1B뿐이다.
5.1B × 0.5 byte(FP4) ≈ 2.55GB

2.55GB ÷ 273 GB/s = 0.0093초/토큰 → 이론상 한계 약 107 tok/s

실제로는 어텐션, KV 캐시 접근, 커널 오버헤드 등으로 이론치보다 낮지만, 대역폭을 얼마나 순수하게 추론에 쓸 수 있느냐가 핵심이다.

세 엔진이 메모리를 쓰는 방식의 차이

Ollama (llama.cpp) — mmap 방식:

128GB 통합 메모리
┌────────────────────────────────────────────────┐
│  모델 가중치 (65GB)              │ OS (2GB) │   │
│  ← GPU가 직접 읽음 (mmap)       │          │   │
│                                  │          │   │
│                                  │  여유     │   │
│                                  │  (61GB)  │   │
└────────────────────────────────────────────────┘
  273 GB/s 대역폭 → 거의 전부 GPU 추론에 사용 가능

mmap은 운영체제의 가상 메모리 기능으로, 파일을 메모리 주소에 매핑한다. 모델 파일을 별도로 "로드"하지 않고, GPU가 필요한 부분을 직접 읽는다. CPU가 중간에 개입하지 않으므로 CPU RAM 오버헤드가 거의 없다.

vLLM (PyTorch) — 전통적 로딩 방식:

128GB 통합 메모리
┌────────────────────────────────────────────────┐
│  GPU 영역:                       │  CPU 영역: │
│  모델 가중치 (66GB)              │  PyTorch   │
│  KV 캐시 (7.7GB)                │  런타임    │
│  CUDA 컨텍스트 등                 │  (6.5GB)   │
│                                  │            │
│  총 ~84.7GB                      │  여유 37GB │
└────────────────────────────────────────────────┘
  273 GB/s 대역폭 → GPU와 CPU가 나눠 사용

PyTorch는 모델을 CPU RAM에 로드한 뒤 GPU 메모리로 복사하는 과정이 필요하고, Python 런타임 + CUDA 컨텍스트 + KV 캐시 관리 자료구조 등이 CPU RAM을 소비한다. 통합 메모리에서는 이 CPU 영역이 GPU가 쓸 수 있는 공간과 대역폭을 줄인다.

SGLang (PyTorch + triton JIT) — 메모리 폭주:

128GB 통합 메모리
┌────────────────────────────────────────────────┐
│  GPU 영역:                  │  CPU 영역:       │
│  모델 가중치 (63GB)         │  PyTorch 런타임  │
│                             │  triton 컴파일   │
│                             │  중간 결과물     │
│                             │  (51GB+!!)       │
│                             │                  │
│  합계: 63 + 51 = 114GB      │  ← 128GB 초과!  │
└────────────────────────────────────────────────┘
  → OOM Kill (커널이 프로세스 강제 종료)

SGLang은 MoE 모델의 triton 커널을 실시간으로 컴파일(JIT)하면서 CPU RAM을 50GB 이상 소비했다. 통합 메모리의 128GB 한도를 초과하여 운영체제가 프로세스를 강제 종료했다.

결론: 같은 하드웨어, 다른 결과의 원인

엔진	CPU RAM 사용	GPU 가용 대역폭 비율	토큰 생성 속도
Ollama	2 GB (1.6%)	~98%	41 tok/s
vLLM	6.5 GB (5.1%)	~90%	35.3 tok/s
SGLang	51+ GB (40%+)	측정 불가 (OOM)	OOM

세 엔진 모두 같은 128GB 통합 메모리를 쓰지만, CPU가 차지하는 몫이 작을수록 GPU가 쓸 수 있는 대역폭이 많아지고, 그만큼 토큰을 빠르게 생성한다. Ollama는 CPU 오버헤드가 거의 없어서 가장 빠르고, SGLang은 CPU가 40% 이상을 삼키다 OOM으로 아예 실행이 불가능했다.

OpenClaw Provider 선정 결과

세 엔진의 테스트를 마치고, OpenClaw의 로컬 LLM Provider를 다음과 같이 선정했다.

시나리오	Provider	이유
개발자 1명 + OpenClaw 단독 사용	Ollama	41 tok/s로 가장 빠름, 설정 간편, `docker compose up` 한 줄로 끝
개발자 1명 + 여러 도구 병렬 사용	vLLM	Continuous Batching으로 OpenClaw + 린터 + 자동완성 병렬 요청 처리
팀(2명+) 공유 서버	vLLM	PagedAttention으로 동시 세션 메모리 효율, OpenAI 호환 API 완전 지원
빠른 응답이 최우선	Ollama	단일 요청 기준 16% 빠름 (41 vs 35.3 tok/s)

SGLang은 후보에서 탈락했다. DGX Spark(SM 12.1)에서 구조적으로 동작하지 않기 때문이다.

왜 이 선택인가?

OpenClaw 같은 AI 코딩 어시스턴트의 핵심 사용 패턴은 "코드를 보여주고, 수정/생성을 요청하고, 결과를 받는" 단방향 인터랙션이다. 한 번에 하나의 요청이 오가는 경우가 대부분이므로, 단일 요청 처리 속도(tok/s)가 가장 중요한 지표다.

Ollama(41 tok/s): llama.cpp 기반이라 동시 요청이 들어오면 순차 처리한다. 2번째 요청은 1번째가 끝날 때까지 대기한다. 하지만 개인 사용에서는 이게 문제가 되지 않고, 단일 요청 속도가 16% 빠르다.
vLLM(35.3 tok/s): Continuous Batching으로 여러 요청을 GPU에서 동시 처리한다. 여러 도구가 LLM을 동시에 호출하거나, 팀원들이 서버를 공유하는 환경에서는 vLLM의 이점이 크다.

범용 참고: 용도별 권장 엔진

용도	권장 엔진	이유
개인 사용 (단일 사용자)	Ollama	가장 빠르고, 설정 간편, 메모리 효율 최고
API 서버 (다중 동시 요청)	vLLM	PagedAttention, Continuous Batching으로 동시 처리 효율적
최대 성능 (단일 사용자)	llama.cpp 네이티브	Docker 없이 ~60 tok/s 달성 가능
최대 성능 (서버)	SGLang 네이티브	~52 tok/s + 고급 서빙 기능 (Docker 환경에서는 비권장)

핵심 정리

OpenClaw 개인 사용 → Ollama(41 tok/s) — 가장 빠르고, Docker 한 줄로 설정 완료
팀 공유/다중 도구 → vLLM(35.3 tok/s) — 동시 요청 처리에 최적화
SGLang → 탈락 — SM 12.x 소프트웨어 생태계 미성숙으로 Docker에서 구조적 불가
"Blackwell 최적화"에 주의 — 대부분의 "Blackwell 최적화" 커널은 SM 100(B200) 전용이며 DGX Spark(SM 12.1)/RTX 5090(SM 12.0)에서는 동작하지 않음

8. 부록: 기술 심화

A. vLLM과 SGLang의 MoE 커널 처리 방식 차이

GPT-OSS-120B는 MoE(Mixture-of-Experts) 모델이라, 토큰마다 120B 파라미터 중 5.1B만 활성화하는 라우팅 연산이 필요하다. 이 MoE 연산을 GPU에서 실행하려면 전용 커널이 필요한데, 두 엔진이 다른 방식으로 이 커널을 확보한다.

vLLM — Marlin 커널 (사전 컴파일)

MXFP4 가중치 → Marlin 커널 (CUDA C++, Docker 이미지에 이미 컴파일 완료)
              → 바로 실행 가능, 컴파일 과정 없음
              → CPU RAM 거의 안 씀

Marlin은 CUDA C++로 작성되어, Docker 이미지 빌드 시 사전 컴파일되어 포함된다. 모델 로딩 시 추가 컴파일이 없다. 단, Marlin이 사전 컴파일되는 대상은 SM 80(Ampere) 이상의 범용 mma.sync 명령어 기반이며, SM 100(데이터센터 Blackwell)의 tcgen05 전용 커널과는 다르다.

SGLang — triton 커널 (실시간 JIT 컴파일)

MXFP4 가중치 → triton 커널 (Python 코드)
              → JIT 컴파일: Python → LLVM IR → PTX → GPU 바이너리
              → 컴파일 과정에서 CPU RAM 대량 소비 (51GB+)

triton은 Python으로 GPU 커널을 작성하는 프레임워크다. 실행 시점에 LLVM 컴파일러가 감지된 GPU 아키텍처에 맞는 바이너리를 실시간 생성한다.

단, triton은 SM 12.x(DGX Spark)를 SM 80(Ampere)으로 취급하여 모든 Blackwell 관련 최적화를 비활성화한다.

실제로는 Ampere 수준의 커널이 생성되지만, MoE 모델의 Expert 레이어가 많아 컴파일할 커널 수가 많고 LLVM 중간 결과물이 CPU RAM에 누적되는 것이 OOM의 원인이다.

비교 요약:

	Marlin (vLLM)	triton (SGLang)
커널 작성 언어	CUDA C++ (저수준)	Python (고수준)
컴파일 시점	Docker 이미지 빌드 시 (사전)	모델 로딩 시 (실시간 JIT)
컴파일 CPU RAM	0 (이미 완료)	51GB+ (실시간)
SM 12.1 대응	범용 `mma.sync` 기반 (사전 컴파일)	Ampere(SM 80) 호환 모드로 JIT
장점	즉시 실행, 메모리 안정	다양한 GPU에 자동 대응, 유연성
단점	SM 100 전용 최적화 미포함	JIT 컴파일에 시간 + 메모리 대량 소비

SGLang이 triton을 쓰는 이유는 유연성 때문이다. JIT 컴파일은 다양한 GPU에 자동 대응 가능하므로 별도 빌드 없이 새로운 하드웨어를 지원할 수 있다. 반면 Marlin은 CUDA C++ 사전 컴파일이라 지원 GPU마다 별도 빌드가 필요하다.

단, DGX Spark(SM 12.1)에서는 triton도 Blackwell 전용 최적화를 적용하지 않으므로, "JIT이라서 더 최적화된 커널을 생성한다"는 주장은 성립하지 않는다.

B. Docker 환경과 네이티브 환경의 성능 차이 — 왜 SGLang은 네이티브에서 성공하는가

NVIDIA 포럼 벤치마크에서 네이티브 SGLang은 ~52 tok/s를 달성했다. 같은 DGX Spark에서 Docker SGLang은 OOM으로 실행조차 안 됐다. 이 차이의 원인은 Docker 자체의 성능 오버헤드가 아니다.

실제 원인은 triton 커널 캐시에 있다.

네이티브 환경에서 SGLang이 성공하는 과정:

[1회차 실행]
  sudo sysctl -w vm.drop_caches=3          ← 시스템 캐시를 비워 메모리 확보
  python3 -m sglang.launch_server ...
  → triton JIT 컴파일 시작
  → CPU RAM 50GB+ 소비 (아슬아슬하지만, 캐시를 비운 덕에 128GB 내에서 가능)
  → 컴파일된 커널을 ~/.triton/cache/ 에 디스크 저장
  → 이후 정상 서빙

[2회차 이후]
  python3 -m sglang.launch_server ...
  → ~/.triton/cache/ 에서 컴파일된 커널을 바로 로드
  → JIT 컴파일 건너뜀
  → CPU RAM 소비 최소
  → 빠르게 시작

핵심은 triton이 컴파일 결과를 디스크에 캐시한다는 점이다. 네이티브 환경에서는:

vm.drop_caches=3으로 시스템 캐시를 비워 triton 컴파일에 필요한 메모리를 확보
1회차 컴파일이 성공하면 ~/.triton/cache/에 바이너리가 저장
2회차부터는 캐시된 커널을 로드하므로 JIT 컴파일 자체가 발생하지 않음

Docker에서 실패하는 이유:

[매번 docker compose up]
  → 컨테이너 파일시스템 초기화 (이전 triton 캐시 없음)
  → triton JIT 컴파일을 매번 처음부터 수행
  → CPU RAM 51GB+ 소비
  → 128GB 통합 메모리 한도 초과 → OOM Kill
  → restart → 같은 상황 반복 (캐시 없으므로 다시 JIT) → 무한 OOM 루프

Docker 컨테이너는 재시작할 때마다 파일시스템이 초기화되므로, triton 캐시가 유지되지 않는다. 매번 JIT 컴파일을 처음부터 해야 하고, 매번 OOM이 발생한다.

해결 가능성: Docker에서도 triton 캐시 디렉토리를 호스트에 마운트(-v ~/.triton/cache:/root/.triton/cache)하면, 1회차 컴파일만 성공하면 이후에는 캐시를 재사용할 수 있다. 다만 1회차 컴파일 자체가 통합 메모리 128GB에서 OOM이 나는 문제가 먼저 해결되어야 하므로, vm.drop_caches=3 등 수동 메모리 확보가 선행되어야 한다.

그렇다면 네이티브 SGLang은 왜 vLLM보다 빠른가?

NVIDIA 포럼에서 보고된 네이티브 SGLang ~52 tok/s vs vLLM ~35 tok/s 차이의 정확한 원인은 현 시점에서 확정할 수 없다. 초기에 "triton JIT이 Blackwell에 완벽히 최적화된 커널을 생성하기 때문"이라고 기술했으나, 이는 사실과 다른 것으로 밝혀졌다.

~~이전 분석 (오류)~~:

~~triton JIT이 Blackwell 전용 명령어(tcgen05)를 사용하여 Marlin보다 최적화된 커널을 생성한다.~~

정정: GB10(SM 12.1)은 데이터센터 Blackwell(SM 100)과 다른 명령어 세트를 사용한다.

SM 12.1은 tcgen05와 TMEM이 없으며, 확장된 mma.sync(Ampere 방식)을 사용한다. triton은 SM 12.x를 SM 80(Ampere)으로 취급하여 Blackwell 관련 최적화를 전혀 적용하지 않는다.

Marlin도 마찬가지로 SM 100 전용 최적화가 아닌 범용 mma.sync 기반으로 동작한다. 즉, triton과 Marlin 모두 SM 12.1에서는 동일한 하드웨어 제약 아래에 있다.

실제로 vLLM에서도 아래 경고가 출력되었는데:

Your GPU does not have native support for FP4 computation
but FP4 quantization is being used.
Weight-only FP4 compression will be used leveraging the Marlin kernel.
This may degrade performance for compute-heavy workloads.

이 경고는 정확하다. GB10(SM 12.1)은 SM 100의 tcgen05 기반 네이티브 FP4 연산을 지원하지 않으므로, Marlin은 weight-only 압축으로 우회한다. 그런데 triton도 SM 12.1을 Ampere로 취급하므로, triton 역시 네이티브 FP4를 사용하지 못한다. 두 엔진 모두 같은 제약 아래에 있다.

네이티브 SGLang이 vLLM보다 빠른 가능한 원인 (추정, 검증 필요):

MoE 라우팅/스케줄링 최적화 차이: SGLang의 triton_kernels 패키지가 MoE Expert 라우팅에 특화된 최적화(메모리 접근 패턴, Expert 배치 전략 등)를 포함할 수 있음
스케줄러 아키텍처 차이: SGLang의 zero-overhead batch scheduler와 RadixAttention이 vLLM의 V1 엔진 스케줄러보다 단일 요청 처리에 유리할 수 있음
CUDA Graph 최적화 차이: 두 엔진의 CUDA Graph 캡처 범위와 전략이 다를 수 있음
소프트웨어 버전/설정 차이: NVIDIA 포럼의 벤치마크는 서로 다른 시점, 다른 설정으로 수행되었을 수 있어 엄밀한 비교가 아닐 수 있음

최종 정리:

환경	SGLang	vLLM	차이 원인
네이티브	52 tok/s	35 tok/s	MoE 스케줄링/커널 전략 차이 (추정)
Docker	OOM (실패)	35.3 tok/s	triton 캐시 미유지 → 매번 JIT → OOM

Docker 환경 vs 네이티브 환경의 차이는 성능 오버헤드가 아니라, triton 커널 캐시의 영속성 문제다. vLLM은 사전 컴파일된 Marlin을 쓰므로 Docker/네이티브 간 성능 차이가 없다(둘 다 ~35 tok/s). SGLang은 triton JIT에 의존하므로 캐시가 유지되는 네이티브에서만 제 성능을 발휘한다.

중요 보충 — SM 12.1은 "데이터센터 Blackwell"이 아니다

DGX Spark의 GB10은 "Blackwell"이라는 이름을 공유하지만, B200/GB200(SM 100)과는 완전히 다른 명령어 세트를 가진다. Backend.AI 기술 블로그 분석에 따르면:

SM 100 (B200, 데이터센터) SM 12.1 (GB10, DGX Spark)

텐서코어 명령어 tcgen05 (5세대 전용) 확장된 mma.sync (Ampere 방식)

TMEM 256 KB/SM 없음

WGMMA 지원 미지원

FP4 하드웨어 tcgen05 네이티브 mma.sync 확장 (제한적)

공유 메모리/SM 228 KB 128 KB

SM 100은 텐서코어를 자율적 연산 유닛으로 만들었고(TMEM + tcgen05), SM 12.x는 Ampere의 mma.sync 위에 새로운 데이터 타입(FP4, FP6)만 추가한 것이다. "Blackwell"이라는 마케팅 이름은 같지만, 커널 개발자 입장에서는 Hopper(SM 90), 데이터센터 Blackwell(SM 100), 소비자/엣지 Blackwell(SM 12.x) 세 가지 별도 코드패스를 유지해야 한다.

이 사실은 DGX Spark에서 LLM 추론 엔진을 평가할 때 "Blackwell 최적화"라는 표현에 주의해야 함을 의미한다. 대부분의 "Blackwell 최적화" 커널(FlashMLA, FA4, FlashInfer SM100 등)은 SM 100 대상이며, SM 12.1에서는 동작하지 않는다.

	SM 100 (B200, 데이터센터)	SM 12.1 (GB10, DGX Spark)
텐서코어 명령어	`tcgen05` (5세대 전용)	확장된 `mma.sync` (Ampere 방식)
TMEM	256 KB/SM	없음
WGMMA	지원	미지원
FP4 하드웨어	`tcgen05` 네이티브	`mma.sync` 확장 (제한적)
공유 메모리/SM	228 KB	128 KB

C. SGLang의 MoE 커널 백엔드 옵션 — triton 이외의 선택지

SGLang은 --moe-runner-backend 옵션으로 MoE 커널 백엔드를 수동 선택할 수 있다. SGLang 서버 인자 문서 참조.

옵션	백엔드	JIT 필요	설명
`auto` (기본값)	자동 선택	모델에 따라 다름	GPT-OSS 감지 시 `triton_kernel` 자동 선택
`triton`	Triton	예	범용 triton JIT 커널
`triton_kernel`	triton_kernels 패키지	예	GPT-OSS 자동 선택 대상, OOM 원인
`deep_gemm`	DeepGEMM	예	SM90+(Hopper/Blackwell) JIT 커널
`flashinfer_cutlass`	FlashInfer CUTLASS	아니오	사전 컴파일, 범용
`flashinfer_trtllm`	FlashInfer TRT-LLM	아니오	사전 컴파일, TensorRT 기반
`flashinfer_mxfp4`	FlashInfer MXFP4	아니오	사전 컴파일, MXFP4 전용
`cutlass`	CUTLASS	아니오	사전 컴파일, NVIDIA 공식

본 테스트에서 SGLang 로그에 아래가 출력되었다:

WARNING server_args.py:979: Detected GPT-OSS model, enabling triton_kernels MOE kernel.

GPT-OSS 모델이 감지되면 --moe-runner-backend를 triton_kernel로 강제 설정한다. 이것이 triton JIT 컴파일을 유발하고, 통합 메모리 128GB 환경에서 OOM의 직접적인 원인이 되었다.

Docker에서 SGLang OOM을 회피할 수 있었는가?

이론적으로 --moe-runner-backend flashinfer_mxfp4를 명시하면, GPT-OSS 자동 감지를 우회하고 사전 컴파일된 FlashInfer MXFP4 커널을 사용할 수 있다. 이 경우 triton JIT가 발생하지 않으므로 OOM을 회피할 가능성이 있다.

command: >
  python3 -m sglang.launch_server
  --model-path openai/gpt-oss-120b
  --host 0.0.0.0
  --port 30000
  --moe-runner-backend flashinfer_mxfp4
  --reasoning-parser gpt-oss
  --tool-call-parser gpt-oss

추가 실험 결과 (2026-02-25): 실제로 --moe-runner-backend flashinfer_mxfp4를 적용하여 테스트했다. MoE 커널 자체는 flashinfer_mxfp4로 정상 설정되었으나, attention 백엔드가 여전히 triton으로 동작하여 attention 커널의 triton JIT 컴파일이 CPU RAM을 소비했다.

메모리 추이:

~~시점 (컨테이너 시작 후)~~	~~RAM 사용~~	~~Swap 사용~~	합계
1분	~~85 GB~~	~~0.3 GB~~	~~85 GB~~
2분	~~90 GB~~	~~1.3 GB~~	~~91 GB~~
3분	~~98 GB~~	~~3 GB~~	~~101 GB~~
4분	~~102 GB~~	~~12 GB~~	~~114 GB~~
~~4분 30초~~	~~104 GB~~	~~12 GB~~	~~116 GB~~

Swap 15GB 한도 초과 직전에 수동으로 컨테이너를 종료하여 OOM Kill은 피했으나, 결론적으로 MoE 커널만 flashinfer_mxfp4로 바꿔서는 OOM을 회피할 수 없다. attention 백엔드의 triton JIT도 상당한 CPU RAM을 소비하기 때문이다.

DGX Spark의 통합메모리에서 swap-space 파라미터는 오히려 독이된다. 아무생각없이 했다가 나중에 아차 했다. 소프트웨어 레벨의 swap-space가 동작하면, 똑같은 물리 메모리 주소 내에서 데이터를 복사하는 불필요한 연산이 발생하며 CPU 사이클만 낭비하게된다. 이 글의 이후 swap-space 관련 내용은 무시하면된다...

sglang:spark 이미지에서 triton 대신 사용 가능한 attention 백엔드가 없는 상태이므로, SGLang Docker에서 triton JIT를 완전히 회피하는 것은 현시점에서 불가능하다.

GPT-OSS 모델이 지원하는 attention 백엔드는 ['triton', 'trtllm_mha', 'fa3', 'fa4'] 4가지뿐인데, SM 12.1에서의 상태는 다음과 같다:

백엔드	SM 12.1 지원	테스트 결과
`triton`	Ampere(SM 80)로 동작	JIT 컴파일 → OOM
`trtllm_mha`	SM 100 전용	`ValueError: TRTLLM MHA backend is only supported on Blackwell GPUs (SM100)`
`fa3`	import 실패	`Can not import FA3 in sgl_kernel`
`fa4`	SM 100 전용	시도 불가

추가 실험 (2026-02-25): --attention-backend trtllm_mha --moe-runner-backend flashinfer_mxfp4 조합으로 triton JIT를 완전히 회피하려 시도했으나, trtllm_mha가 SM 100 전용이라 즉시 에러로 실패했다.

ValueError: TRTLLM MHA backend is only supported on Blackwell GPUs (SM100).
Please use a different backend.

결론: GPT-OSS 모델이 지원하는 4개 attention 백엔드 중 SM 12.1에서 동작하는 것은 triton뿐이고, triton은 JIT 컴파일로 OOM을 유발한다. SGLang Docker + GPT-OSS + SM 12.1 조합은 현시점에서 구조적으로 불가능하다.

향후 sglang:spark 이미지에 SM 12.1 호환 attention 커널(예: cuDNN SDPA 기반)이 추가되면 상황이 달라질 수 있다.

MXFP4 관련 추가 옵션

SGLang은 FP4 GEMM 백엔드도 별도로 선택할 수 있다 (--fp4-gemm-backend):

옵션	설명
`flashinfer_cutlass` (기본값)	FlashInfer CUTLASS, 범용
`flashinfer_cudnn`	cuDNN 9.15+ 필요, CUDA 13+에서 최적
`flashinfer_trtllm`	TensorRT-LLM 백엔드, 가중치 셔플링 필요

DGX Spark는 CUDA 13.0이므로 flashinfer_cudnn이 최적일 수 있으나, cuDNN 버전 요구사항(9.15+)을 sglang:spark 이미지가 충족하는지 확인이 필요하다.

9. 참고 자료

LMSYS - Optimizing GPT-OSS on DGX Spark
NVIDIA Forum - Run SGLang in Spark
NVIDIA Forum - Run vLLM in Spark
NVIDIA - vLLM for Inference on DGX Spark
SGLang Server Arguments Documentation
Backend.AI - Inside NVIDIA DGX Spark: Is DGX Spark Actually Blackwell? — SM 100 vs SM 12.x 아키텍처 차이 상세 분석

10. 작업 로그: 테스트 진행 과정 기록

이 섹션은 실제 테스트를 진행하면서 겪은 시행착오, 의사결정 과정, 트러블슈팅 흐름을 시간순으로 기록한 것이다. 단순한 결과 비교보다 "왜 이 결론에 도달했는가"를 이해하는 데 도움이 된다.

Phase 1: SGLang Docker 환경 구성

목표: DGX Spark에서 openai/gpt-oss-120b를 SGLang Docker로 서빙

프로젝트 구조:

/home/username/projects/sglang/gpt-oss-120b/
├── docker-compose.yml
└── .env

초기 docker-compose.yml 구성:

이미지: lmsysorg/sglang:spark (23.8GB, DGX Spark 전용 빌드)
모델: openai/gpt-oss-120b (HuggingFace 캐시에서 로드)
attention-backend: flashinfer (초기 선택)
mem-fraction-static: 0.75
볼륨: ~/.cache/huggingface 마운트

--ipc host 필요 여부에 대한 검토: 초기에는 ipc: host를 포함하지 않았으나, 이후 LMSYS 공식 가이드를 참고하여 PyTorch의 GPU 간 통신(실제로는 단일 GPU지만 내부 IPC)을 위해 추가했다. shm_size: "32g" 설정과 함께 사용하면 컨테이너 내 공유 메모리 부족 문제를 예방할 수 있다.

Phase 2: SGLang 트러블슈팅 (4회 연속 실패)

시도 1 — flashinfer 비호환

docker compose up -d

즉시 실패. 로그 확인 결과:

AssertionError: GptOssForCausalLM requires one of
['triton', 'trtllm_mha', 'fa3', 'fa4'] attention backend,
but got flashinfer

원인: GPT-OSS 모델 아키텍처는 flashinfer attention 백엔드를 지원하지 않는다.
조치: --attention-backend triton으로 변경

시도 2 — triton JIT 중 OOM (mem-fraction 0.75)

모델 가중치 15/15 샤드 로딩까지 성공. GPU에 62.8GB 적재 완료. 이후 triton 커널 JIT 컴파일 단계에서 CPU RAM이 20분에 걸쳐 3.8GB → 51.2GB까지 증가. 최종적으로 OOM Kill 발생:

Out of memory: Killed process 618610 (sglang::schedul)
total-vm: 155.5GB, anon-rss: 51.2GB

분석: journalctl -k 로 OOM Kill 이벤트 확인. nvidia-smi로 GPU 메모리 62.8GB 사용 확인. CPU RAM 51.2GB + GPU 62.8GB = 약 114GB로, 128GB 통합 메모리 한도에 근접.
조치: --mem-fraction-static을 0.75 → 0.40으로 낮춤 (GPU 쪽 할당 축소)

시도 3 — mem-fraction 0.40에서도 OOM

KV 캐시 비율을 줄였으나, OOM의 원인은 KV 캐시가 아니라 triton JIT 컴파일의 CPU RAM 소비였으므로 효과 없음. 동일한 OOM → restart → OOM 무한 루프 발생.

핵심 발견: 이 시점에서 "메모리 부족은 GPU 측이 아니라 CPU 측 문제"라는 것을 확인. triton의 LLVM 컴파일러가 MoE 모델의 Expert 커널을 컴파일하면서 CPU RAM을 제어 불가 수준으로 소비하고 있었다.

시도 4 — LMSYS 공식 가이드 기반 재구성

LMSYS 블로그를 참고하여 전면 재구성:

--attention-backend, --mem-fraction-static 옵션 제거 (자동 선택)
ipc: host, shm_size: "32g" 추가
tiktoken 인코딩 파일 사전 다운로드 (o200k_base.tiktoken, cl100k_base.tiktoken)
HF_HUB_OFFLINE=1 추가 (HF_TOKEN 한글 placeholder로 인한 UnicodeEncodeError 회피)
--reasoning-parser gpt-oss, --tool-call-parser gpt-oss 추가

UnicodeEncodeError 에피소드: .env 파일의 HF_TOKEN이 hf_여기에_토큰_입력(한글 placeholder)으로 설정되어 있어, HuggingFace Hub 인증 시 latin-1 인코딩 에러가 발생했다. HF_HUB_OFFLINE=1로 네트워크 접근 자체를 차단하여 해결.

결과: 여전히 triton JIT 컴파일 중 CPU RAM 32GB+ 증가, OOM 불안정.

SGLang 최종 판단

4회 연속 실패 후 SGLang Docker를 포기하기로 결정. 핵심 원인 정리:

MoE 모델에 대해 triton_kernel 백엔드가 자동 선택 (강제)
triton JIT 컴파일이 CPU RAM 50GB+ 소비
통합 메모리 128GB에서 GPU(63GB) + CPU(51GB) = 114GB → OOM
Docker 컨테이너 재시작 시 triton 캐시 소멸 → 매번 JIT 반복

Phase 3: Ollama와의 비교 — "왜 Ollama는 문제없었나?"

SGLang의 반복 OOM 중, 이전에 같은 DGX Spark에서 Ollama로 동일 모델을 성공적으로 서빙했던 경험과 비교 질문이 제기되었다.

Ollama는 왜 OOM이 없었는가?

항목	Ollama	SGLang
백엔드	llama.cpp (C++)	PyTorch + triton (Python)
모델 로딩	mmap (디스크 → 메모리 직접 매핑)	safetensors 전체 로드
CPU RAM 사용	~2GB (최소)	51GB+ (JIT 컴파일)
JIT 컴파일	없음 (사전 컴파일된 C++)	있음 (triton, 실시간)
합계 메모리	~67GB / 128GB	~114GB / 128GB → OOM

결론: llama.cpp의 mmap 방식은 CPU RAM을 거의 쓰지 않아 통합 메모리 환경에서 압도적으로 유리하다. PyTorch 기반 엔진은 구조적으로 CPU RAM 오버헤드가 크고, 여기에 triton JIT까지 더해지면 128GB 한도를 쉽게 초과한다.

Phase 4: vLLM으로 전환

SGLang 실패 후 대안으로 vLLM 선택.

프로젝트 구조 (SGLang 파일은 보존):

/home/username/projects/vllm/gpt-oss-120b/
├── docker-compose.yml
└── .env

vLLM 구성 결정 근거:

이미지: nvcr.io/nvidia/vllm:26.01-py3 (NVIDIA 공식 빌드, Blackwell 지원)
- SGLang의 커뮤니티 이미지(23.8GB)와 달리, NVIDIA가 직접 빌드(13.1GB)하여 Marlin 커널이 사전 컴파일되어 있음
~~--swap-space 16: vLLM 고유의 KV 캐시 CPU 스왑 기능. SGLang에는 이 기능이 없어 메모리 부족 시 대응 불가~~
--gpu-memory-utilization 0.7: GPU 메모리를 70%만 사용하여 여유 확보
--max-model-len 32000: 컨텍스트 길이 제한으로 KV 캐시 크기 제어
VLLM_USE_FLASHINFER_MXFP4_MOE=1: MoE 모델에 FlashInfer MXFP4 최적화 활성화

Docker 이미지 풀: nvcr.io/nvidia/vllm:26.01-py3 (13.1GB) — NVIDIA NGC에서 직접 pull

결과: 첫 시도에서 성공. 모델 로딩 ~6분 32초, 엔진 초기화 ~77초, 총 ~8분 소요. OOM 없이 안정적 서빙 시작.

성능 테스트:

단순 질의 ("What is 2+2?"): 1.73초, 40 completion tokens
긴 텍스트 생성 (512 tokens): 14.49초, 35.3 tok/s

vLLM 로그에서 주목할 경고:

Your GPU does not have native support for FP4 computation
but FP4 quantization is being used.
Weight-only FP4 compression will be used leveraging the Marlin kernel.

Marlin 커널은 SM 100(데이터센터 Blackwell)의 tcgen05 기반 네이티브 FP4를 활용하지 못하고, 범용 mma.sync 기반 행렬 곱셈으로 우회한다. 단, triton도 SM 12.1을 SM 80(Ampere)으로 취급하므로, triton 역시 Blackwell 전용 최적화를 적용하지 않는다. 네이티브 SGLang(52 tok/s)이 vLLM(35 tok/s)보다 빠른 정확한 원인은 FP4 네이티브 지원 차이가 아니라, MoE 스케줄링/커널 전략 등 다른 요인으로 추정된다 (부록 B 참조).

Phase 5: 3자 비교 및 분석

Ollama(41 tok/s), vLLM(35.3 tok/s), SGLang(OOM) 세 결과를 종합하여 기술 블로그 작성.

주요 발견 사항:

통합 메모리에서 CPU RAM 오버헤드가 곧 GPU 성능 손실: 일반 서버에서는 CPU RAM과 GPU VRAM이 분리되어 있어 CPU 메모리 사용이 GPU 성능에 영향을 주지 않지만, DGX Spark에서는 같은 물리 메모리를 공유하므로 CPU 오버헤드가 GPU 대역폭을 직접 감소시킨다.
Marlin vs triton — 사전 컴파일 vs JIT: vLLM의 Marlin 커널은 Docker 이미지 빌드 시 사전 컴파일되어 있어 모델 로딩 시 추가 CPU RAM 소비가 없다. SGLang의 triton은 실행 시점에 JIT 컴파일하므로 CPU RAM을 대량 소비하고, Docker의 ephemeral 파일시스템으로 인해 캐시도 유지되지 않는다. 단, SM 12.1에서는 Marlin과 triton 모두 Blackwell 전용 최적화(tcgen05, TMEM)를 사용하지 못하므로, 커널 품질 자체의 차이는 제한적이다.
Docker vs 네이티브의 핵심 차이는 성능 오버헤드가 아니라 triton 캐시 영속성: 네이티브 SGLang은 1회차 JIT 후 ~/.triton/cache/에 캐시를 저장하여 2회차부터는 JIT를 건너뛸 수 있다. Docker는 컨테이너 재시작 시 캐시가 사라지므로 매번 처음부터 컴파일해야 한다.
SGLang의 대안 경로 (이후 검증 완료 → 전부 실패):
- --moe-runner-backend flashinfer_mxfp4: MoE 커널의 triton JIT는 회피했으나, attention 백엔드가 triton이라 attention JIT에서 여전히 OOM (4분 만에 104GB RAM )
- --attention-backend trtllm_mha: ValueError: only supported on SM100 — SM 100 전용
- fa3, fa4: 각각 import 실패, SM 100 전용
- 결론: GPT-OSS + SM 12.1에서 SGLang Docker는 구조적으로 불가능

Phase 6: 외부 docker-compose.yml 비교 평가

커뮤니티에서 공유되는 SGLang docker-compose.yml과 테스트에서 사용한 버전을 비교 검토했다.

커뮤니티 버전의 주요 차이점:

image: lmsysorg/sglang:latest — sglang:spark(DGX Spark 전용)가 아닌 범용 이미지. Blackwell SM 12.1 지원 여부 불확실
--quantization mxfp4 — GPT-OSS는 모델 자체에 양자화가 내장되어 있어 이 옵션이 불필요 (vLLM은 자동 감지)
--mem-fraction-static 0.8 — 본 테스트에서 0.75/0.40 모두 OOM 실패. 0.8은 더 위험
--enable-paged-attention — SGLang에 존재하지 않는 옵션 (vLLM의 기능)
--model-path /models/gpt-oss-120b — HuggingFace 캐시 대신 로컬 모델 디렉토리 직접 지정
shm_size: '16gb' — LMSYS 가이드는 32GB 권장
version: '3.8' — Docker Compose v5+에서는 불필요한 레거시 키

평가: 커뮤니티 버전은 DGX Spark 특화 설정이 부족하고, 존재하지 않는 옵션(--enable-paged-attention)을 포함하고 있어, 실제 실행 시 에러가 발생할 가능성이 높다.

시간순 의사결정 요약

SGLang 시작 (flashinfer)
  ↓ 에러: flashinfer 미지원
  ↓
SGLang (triton, 0.75)
  ↓ OOM: CPU RAM 51GB
  ↓
SGLang (triton, 0.40)
  ↓ OOM: 동일 (KV 캐시가 아닌 JIT가 원인)
  ↓
SGLang (LMSYS 가이드 준수)
  ↓ OOM: 여전히 triton JIT 문제
  ↓
"Ollama는 왜 됐지?" → mmap vs PyTorch 메모리 모델 차이 분석
  ↓
SGLang Docker 포기 → vLLM으로 전환
  ↓
vLLM 첫 시도 성공 (35.3 tok/s)
  ↓
3자 비교: Ollama(41) > vLLM(35.3) > SGLang(OOM)
  ↓
근본 원인 분석: 통합 메모리 + Marlin vs triton + Docker 캐시 영속성
  ↓
SGLang 서버 인자 분석 → flashinfer_mxfp4 대안 경로 발견 (미검증)
  ↓
"triton JIT이 Blackwell 최적화 커널을 생성한다" 주장 검증
  ↓ SM 12.1 ≠ SM 100 아키텍처 분석 (Backend.AI 블로그)
  ↓ triton은 SM 12.1을 SM 80(Ampere)으로 취급 → Blackwell 최적화 없음
  ↓
환각 정정: triton/Marlin 모두 SM 12.1에서는 동일한 하드웨어 제약
  → 네이티브 SGLang의 속도 우위 원인은 "FP4 네이티브"가 아닌 다른 요인 (추정)
  ↓
SGLang 추가 실험: --moe-runner-backend flashinfer_mxfp4
  ↓ MoE JIT는 회피했으나 attention triton JIT에서 OOM (4분 만에 116GB)
  ↓
SGLang 추가 실험: --attention-backend trtllm_mha
  ↓ "only supported on SM100" → 즉시 에러
  ↓
최종 결론: GPT-OSS attention 백엔드 4종 중 SM 12.1에서 동작하는 건 triton뿐
           → triton은 JIT OOM → SGLang Docker는 구조적으로 불가능

교훈 및 향후 과제

DGX Spark에서 Docker로 LLM을 서빙할 때, 통합 메모리 구조를 반드시 고려해야 한다. 일반 서버의 경험치를 그대로 적용하면 예상치 못한 OOM이 발생한다.
PyTorch 기반 엔진(SGLang, vLLM)은 CPU RAM 오버헤드가 본질적으로 존재한다. 통합 메모리에서는 이것이 GPU 성능에 직접 영향을 미친다.
Docker 컨테이너의 ephemeral 파일시스템은 triton JIT 캐시와 충돌한다. 볼륨 마운트로 ~/.triton/cache/를 영속화하면 해결 가능하지만, 1회차 컴파일 자체의 메모리 문제는 별도 대응이 필요하다.
SM 12.1 ≠ SM 100 — "Blackwell" 표기에 주의: DGX Spark(SM 12.1)와 B200(SM 100)은 같은 "Blackwell"이지만 명령어 세트(ISA)가 완전히 다르다. "Blackwell 최적화"라고 표기된 커널(FlashMLA, FA4, FlashInfer SM100 등)은 대부분 SM 100 전용이며 SM 12.1에서는 동작하지 않는다. triton도 SM 12.1을 SM 80(Ampere)으로 취급한다.
검증 완료된 대안 경로:
- ~~--moe-runner-backend flashinfer_mxfp4 옵션으로 SGLang Docker OOM 회피~~ → 실패: attention triton JIT가 여전히 OOM 유발
- ~~--attention-backend trtllm_mha로 triton 완전 회피~~ → 실패: SM 100 전용, SM 12.1 미지원
향후 검증 사항:
- triton 캐시 볼륨 마운트(-v ~/.triton/cache:/root/.triton/cache) + vm.drop_caches=3 조합으로 SGLang Docker 1회차 부팅 가능 여부
- sglang:spark 이미지 업데이트 후 SM 12.1 호환 attention 커널(cuDNN SDPA 기반 등) 추가 여부
- vLLM --fp4-gemm-backend flashinfer_cudnn 옵션으로 성능 향상 여부 (cuDNN 9.15+ 필요)
- 네이티브 SGLang(52 tok/s)이 vLLM(35 tok/s)보다 빠른 정확한 원인 규명

11. SM 12.x 소프트웨어 생태계 현황과 향후 방향

2026-02-25 기준

GB10(SM 12.1)의 현실

DGX Spark는 하드웨어적으로 FP4 연산을 지원하지만, 소프트웨어 생태계가 SM 12.x를 아직 제대로 지원하지 못하는 과도기에 있다. Backend.AI 기술 블로그의 분석이 이 상황을 정확히 짚고 있다.

소프트웨어	SM 12.x 지원 상태	비고
Triton	SM 80(Ampere)으로 취급	Blackwell 최적화 전부 비활성화
FlashAttention	SM 12.x 미인식	"Ampere GPUs or newer" 에러
FlashAttention 4 (FA4)	SM 100 전용	SM 12.1 지원 불가
FlashMLA	SM 100/SM 90만 지원	SM 12.x 백엔드 없음
FlashInfer	SM 100/SM 90만 지원	SM 12.x 백엔드 새로 작성 필요
cuDNN SDPA	동작 가능	현재 유일한 SM 12.x attention 경로
llama.cpp	자체 CUDA 커널	외부 커널 의존 없음, 가장 안정
Marlin (vLLM)	범용 `mma.sync` 기반	SM 12.x에서 안정 동작

현재 최선의 선택

용도	권장 엔진	이유
개인/단일 사용자	Ollama (41 tok/s)	llama.cpp의 자체 CUDA 커널 + mmap. SM 12.x 커널 이슈 자체가 없음
API 서버 (다중 요청)	vLLM (35.3 tok/s)	Marlin이 범용 `mma.sync`로 안정 동작. PagedAttention 등 서빙 기능
최대 성능 추구	대기	SM 12.x 전용 커널이 갖춰지면 성능이 큰 폭으로 상승할 여지 있음

SGLang Docker가 SM 12.x에서 구조적으로 불가능한 이유 (최종 확인)

GPT-OSS 모델이 지원하는 attention 백엔드 4가지를 SM 12.1에서 모두 테스트한 결과:

attention 백엔드	테스트 결과	원인
`triton`	OOM (4회 실패)	JIT 컴파일 중 CPU RAM 51GB+ 소비
`trtllm_mha`	즉시 에러	`ValueError: only supported on SM100`
`fa3`	import 실패	`sglang:spark` 이미지에 미포함
`fa4`	시도 불가	SM 100 전용

MoE 백엔드도 flashinfer_mxfp4로 교체하여 triton JIT를 우회하려 했으나, attention 백엔드에서 triton JIT가 여전히 발생하여 OOM을 피할 수 없었다. GPT-OSS + SM 12.1 조합에서는 SGLang Docker를 사용할 수 없다.

이는 DGX Spark뿐 아니라 RTX 5090(SM 12.0)에서도 동일한 상황이다. SM 12.x에서 SGLang의 Blackwell 최적화 성능을 확인하는 것 자체가 현시점에서 불가능하다.

향후 전망

DGX Spark의 128GB 통합 메모리는 200B 파라미터 모델을 데스크탑에서 돌릴 수 있는 유일한 환경이다. 하드웨어의 확장 mma.sync는 FP4/FP6 데이터 타입을 지원하므로, SM 12.x 전용 커널이 작성되면 현재보다 상당한 성능 향상이 예상된다.

주시해야 할 채널:

NVIDIA DGX Spark 포럼
SGLang GitHub Issues — SM 12.x 관련 이슈
vLLM GitHub Issues — SM 12.x 관련 이슈
Backend.AI 블로그 — DGX Spark 관련 기술 분석
NVIDIA CUTLASS — sm120f 타겟 커널 개발 진행 상황

seedance 2.0 사용해보기

DanielZZI — Mon, 16 Feb 2026 17:21:45 +0900

seedance 2.0 이 요즘 핫하다. 중국 AI 공부도 하고, 중국어 복습도 해볼겸. 가끔 글을 올려야겠다.

bytedance 산하의 AI플랫폼 jimeng AI ( https://jimeng.jianying.com/ ) 에서 해당 모델을 테스트해 볼 수 있다.

1. 홈페이지 메뉴 설명

文生图 : wenshengtu -> Text to Image
视频生成: shipin shengcheng -> 영상 생성
智能画布: zhineng huabu -> smart canvas
探索: tansuo -> 다른 유저들의 작품 및 프롬프트 참고
未来影像计划: weilai yingxiang jihua -> 미래 비전등을 볼수있는 페이지

开启即梦 : kaiqi jimeng -> 회원가입. 직역하면 즉각적인 꿈만들기 (jimeng)를 시작하세요!

2.seedance를 활용해 영상만들

开启即梦 버튼 클릭

순서대로

Agent Model

이미지생성

영상생성

3. 회원가입

同意协议后前往登录： 동의 후 로그인페이지로 이동

同意 (tóngyì): 동의하다, 찬성하다
协议 (xiéyì): 계약, 약관, 동의서
后 (hòu): ~후에, ~한 다음
前往 (qiánwǎng): ~로 가다, 이동하다
登录 (dēnglù): 로그인(Log in)

用户服务协议，隐私政策， AI功能使用须知： 이용약관, 개인정보처리방침, AI사용시 책임 제한 안내

用户服务协议 : 서비스 이용 규칙, 사용자 권리와 의무, 서비스 제한 사항, 책임 면제, 분쟁 해결 방법 등을 다룹니다. 이를 동의해야 서비스를 이용할 수 있음.
隐私政策: 수집하는 정보의 종류, 목적, 보관 기간, 제3자 제공 여부, 사용자가 자신의 데이터를 관리(열람, 삭제)할 수 있는 권리 등을 설명
AI功能使用须知:

결과물의 정확성: AI가 생성한 답변은 부정확하거나 사실과 다를 수 있음을 고지합니다.

데이터 안전: 입력한 데이터가 모델 학습에 사용될 수 있는지 여부.

사용 제한: 불법, 윤리적, 위험한 콘텐츠 생성 금지.

책임: AI 결과물에 대한 최종 책임은 사용자에게 있음을 명시합니다.

使用抖音账号登录即梦 : douyin(중국TIKTOK명) 계정으로 jimeng 로그인하기

打开「抖音APP」点击左上角扫一扫 : douyin APP 열고, 좌상단 scan(扫一扫) 클릭하기

이제 보니까, 중국판 TIKTOK(douyin)을 설치하고 douyin 회원가입을 한후에 douyin app에서 인증을 해줘야하는 것이었다.

이제 douyin 앱을 설치해보자.

https://z.douyin.com/dpwnT

나는 안드로이드를 쓰는데 이 링크에서 파일을 다운받은후에 apk파일을 열기, 설치하기 등을 통해 설치하면 된다.

우리가 흔히 쓰는 TIKTOK앱으로 먼저 해봤는데 안되더라. 아니 scan기능을 못찾았다.

(참고로 iphone은 다운로드가 안되는것 같다.)

이제는 조금 중국어 번역하기가 귀찮아져서

아래 douyin app 가입관련 스샷을 대충 넣었다.

한국은 hanguo로 H열에서 시작

아래는 닉네임 대충짓기

아래는 회원가입 및 로그인하면, 이제 douyin 메인화면에서 좌상단 목록버튼 클릭 후

scan( 扫一扫 ) 기능을 클릭해서 아까 위의 jimeng app QR code를 인식해주자.

그렇게 로그인을 하고, 다시 jimeng에서 무료로 영상생성을 해보자.

먼저 영어 프롬프트로 해보기로했다. 나는 이미지 두개로 처음과 끝부분을 이어지게하는 영상을 만들려고했다.

옵션을 보자.

1.생성모드: 영상생성

2.모델 선택: seedance 2.0 Fast

3.영상모드: 아래참고

全能参考 (전능참조): 영상 생성 시 이미지, 텍스트 등 모든 요소를 종합적으로 참고하여 결과물을 만드는 모드입니다. 특정 스타일이나 구도를 고정하면서도 AI가 창의적으로 디테일을 채우도록 할 때 사용합니다. seedance2.0 fast와 seedance 2.0만 사용가능
首尾帧 (수미프레임): 영상의 '첫 장면(시작 프레임)'과 '마지막 장면(끝 프레임)'을 의미합니다. 영상 생성 도구에서 시작 이미지와 끝 이미지를 각각 지정하면, AI가 그 사이의 움직임을 자연스럽게 연결해 줍니다.
智能多帧 (지능형 다중 프레임): AI가 여러 프레임을 분석하여 움직임을 더 부드럽고 정교하게 만드는 기술입니다. 프레임 간의 연속성을 높여 영상이 끊기거나 어색하게 변하는 현상을 줄여줍니다.
主体参考 (주체참조): 영상 속 핵심 인물이나 사물(주체)의 형태와 특징을 그대로 유지하며 영상을 생성하는 기능입니다. 배경은 바뀌어도 주인공 캐릭터의 외형이 변하지 않게 고정할 때 유용합니다

4.프레임사이즈: 자동비율 (21:9, 16:9, 4:3, 1:1 등 선택가능)

그후, 생성버튼 을 클릭하면 아래와 같이 법적책임에 대한 동의가 필요

安全确认

请您使用本人照片/视频或取得其充分授权，确保不存在违反法律法规、侵犯他人权益或违反公序良俗的内容。若因您不当使用本功能导致任何第三方权益受损，您将依法承担相应法律责任。

拒绝 / 确认

주요 단어 풀이

安全确认 (안전확인): 보안 및 안전 이용 확인
本人 (본인): 자기 자신
充分授权 (충분수권): 충분한 권한 부여(허가)를 받음
违反 (위반): 어김
法律法规 (법률법규): 법과 규정
侵犯 (침범): (권리를) 침해함
权益 (권익): 권리와 이익
公序良俗 (공서양속): 공공의 질서와 선량한 풍속
不当使用 (부당사용): 부적절한 사용
第三方 (제3자): 당사자 이외의 인물
承担 (승담): (책임을) 떠맡음
法律责任 (법률책임): 법적 책임
拒绝 / 确认 (거절 / 확인): 거부하기 / 동의(확인)하기

안전 확인

본인의 사진/동영상을 사용하거나 그에 대한 충분한 권한을 취득하여, 법률 및 규정 위반, 타인의 권익 침해 또는 공공질서와 미풍양속에 어긋나는 내용이 없음을 보장해 주십시오. 귀하의 부적절한 본 기능 사용으로 인해 제3자의 권익이 손해를 입을 경우, 귀하는 법에 따라 상응하는 법적 책임을 지게 됩니다.

거절 / 확인

확인을 누르면 영상이 생성중인데, 대충 기다려봤는데 생성이 안되길래 다시보니

이것이 바로 대륙의 기다림!

해석하면 "앞에 13856 명의 대기자 중 13713등이다. 예측시간은 47분, 고등급회원은 최고 가속을 누릴수있다."

앞서 기다린 시간까지 합치면 나는 무료회원은 무려 60분은 기다려야 하는거같다.

옆에 파란색 글자를 마우스를 대보면 위와 같이 뜬다.

중간 흰색 안내문

제목: 会员生成加速 (멤버십 생성 가속)
내용: 开通会员, 享快速生成独立通道, 告别拥挤 (멤버십을 개통하여 독립된 빠른 생성 채널을 누리고 혼잡함과 작별하세요.)
추가 설명: 会员等级越高速度越快 (멤버십 등급이 높을수록 속도가 더 빠릅니다.)
버튼: 1元试用7天会员 (1위안으로 7일 멤버십 체험하기)

하단 회색 텍스트 (실시간 상태)

현재 순번: 当前 (13329/13658) 位 (현재 13,658명 중 13,329번째 순서)
대기 시간: 预计等待 2 小时 (약 2시간 대기 예상 -> 갑자기 바뀌었다)
무료 혜택: 免费加速 2 次 (무료 가속 2회 가능)

그러나 멤버쉽 가입을 안해도 무료회원에게 2번의 가속기회는 있다.

앞선 파란색버튼 (免费加速2次）을 클릭하니 시간이 40분에서 27분으로 줄었다.

갑자기 4시간이 되었다. GPU가 많이 부족한지, 무료 요청대기자가 많은건지는 유료멤버쉽으로 테스트해봐야할듯

이후 단독 회원 한달가입을 진행했다. 월구독은 두가지로 나뉘는데,

-단독 월 구독 : 79위안 (1회성 구독)

-연속 월 구독 : 69위안

이다. 나는 단독 월구독으로 했다.

이후 영상은 조금씩 다르지만 fast로 할경우 3분 내외로 생성이 된다.

local llm: Open WebUI를 tailscale로 외부에서 접속하기

DanielZZI — Mon, 16 Feb 2026 15:38:25 +0900

내 책상 위 AI 슈퍼컴퓨터, 외부에서 안전하게 접속하기 (Open WebUI + Tailscale)

집에서 local llm을 만들고 open webui로 사용해보는데, 집 밖에서도 사용해야할 경우가 있다.
하지만 공유기 포트 포워딩은 보안상 찝찝하고 설정도 귀찮다. 이럴 때 가장 깔끔한 정답은 Tailscale이다. 복잡한 VPN 설정 없이 내 기기들을 하나의 가상 네트워크로 묶고, 심지어 HTTPS 도메인까지 공짜로 입히는 법을 알아보자.

1. Tailscale 설치 및 연동

먼저 고속도로부터 깔아야 한다. 접속할 llm및 open webui 호스트서버와 클라이언트(노트북) 양쪽 모두에 Tailscale을 설치하자.

llm host 서버에서:

curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.noarmor.gpg | sudo tee /usr/share/keyrings/tailscale-archive-keyring.gpg >/dev/null
curl -fsSL https://pkgs.tailscale.com/stable/ubuntu/noble.tailscale-keyring.list | sudo tee /etc/apt/sources.list.d/tailscale.list
sudo apt update && sudo apt install tailscale
sudo tailscale up



* **노트북(클라이언트)에서:** [Tailscale 공식 홈페이지](https://www.google.com/search?q=https://tailscale.com/download)에서 OS에 맞는 앱을 설치하자.
* **로그인:** 양쪽 기기 모두 동일한 계정으로 로그인하면 하나의 **Tailnet**에 자동으로 연결된다. 이제 두 기기는 전용 가상 IP(100.x.x.x)로 통신할 준비가 끝났다.

---

## 2. Open WebUI 구동 (Docker)

host서버(pc 등)에서 Docker로 Open WebUI를 띄우자. 여기서는 외부 포트를 `12000`으로 바인딩했다.

```bash
docker run -d -p 12000:8080 --gpus=all \
  -v open-webui:/app/backend/data \
  -v open-webui-ollama:/root/.ollama \
  --name open-webui \
  ghcr.io/open-webui/open-webui:ollama

핵심: -p 12000:8080 설정을 통해 컨테이너 내부의 8080 포트를 server 본체의 12000번 포트로 연결했다.

3. MagicDNS와 HTTPS 활성화 (중요!)

IP 주소(100.x.x.x)를 외우는 건 고통스럽다. 도메인 이름을 쓰고 HTTPS를 적용하기 위해 Tailscale 관리자 페이지에서 설정을 켜자.

Tailscale Admin Console 접속 → DNS 탭 이동.
MagicDNS 활성화 (Enabled 확인).
하단 HTTPS Certificates 항목에서 Enable HTTPS 버튼 클릭.

4. HTTPS 서빙 설정 (Tailscale Serve)

이제 하이라이트다. llm host서버에서 돌아가는 open webui HTTP 서비스를 보안이 강화된 HTTPS 도메인으로 변환해주자.

# HTTPS 인증서 생성 및 백그라운드 서빙 시작
sudo tailscale serve --bg --https=443 http://localhost:12000

명령어 설명: * --bg: 백그라운드에서 계속 실행한다.
--https=443: 외부에서는 표준 HTTPS 포트로 접속한다.
http://localhost:12000: 실제로 연결할 로컬 서비스 포트다.

추가 팁: 만약 접속이 안 된다면 llm host서버의 방화벽(ufw)이 포트를 막고 있을 수 있다. sudo ufw allow 12000/tcp와 sudo ufw allow 443/tcp를 확인해보자.

5. 외부에서 도메인으로 접속하기

이제 모든 준비가 끝났다. 밖에서 노트북 브라우저를 켜고 주소창에 내 llm hosting서버의 도메인 주소를 입력해보자.

접속 주소: https://기기이름.네트워크이름.ts.net
장점: * 포트 번호(:12000)를 붙일 필요가 없다.
브라우저에 자물쇠 아이콘이 뜨는 안전한 연결이 완성됐다.

PDF Table 처리 비교

DanielZZI — Fri, 16 Jan 2026 00:22:06 +0900

EURO Regulations관련 Annex table을 LLM에서 가장 잘이해하고 처리할 수있는 형태로 chungking하고자했다.

LLM은 일반적으로 Markdown에 더 높은 성능과 안정성을 보인다.

pdf table -> markdown 전환시 완성도 우수
pdf table -> markdown direct 변환(pandas 등 중간 layer x)
무료 > 유료

라는 조건으로 llamaparse(llamaindex), pymupdf4llm 등 RAG특화 툴과 비교적 classic한 pdfplumber, camelot+pandas 조합을 테스트해봤다.

원본 pdf파일

1. llamaparse

llamaindex의 명성에 비해,, 생각보다 실망스러웠다.

# Step 1: LlamaParse로 PDF를 Markdown으로 변환
print("LlamaParse로 PDF를 Markdown으로 변환 중...")
print("(클라우드 처리로 시간이 걸릴 수 있습니다)")

# LlamaParse 파서 생성
# result_type: "markdown" 또는 "text"
parser = LlamaParse(
    result_type="markdown",
    verbose=True,
)

# PDF 파일 파싱
documents = parser.load_data(pdf_path)

print(f"\n✓ 파싱 완료: {len(documents)}개 문서 청크")

2. pymupdf4llm

결과적으로 제일 만족스러웠다. 셀병합못한 부분과 ,other컬럼이 miss였으나 이정도면 우수하다.

# Step 1: PDF를 Markdown으로 변환

print("PDF를 Markdown으로 변환 중...")

md_text = pymupdf4llm.to_markdown(
    pdf_path,
    pages=range(136, 367),
    write_images=False,
)
print("변환완료")

Path("output.md").write_bytes(md_text.encode())

3. camelot+pandas

코드도 길었고, 중간에 pandas를 끼는것도 복잡해지고, 속도처리도 느렸다.

그리고 무엇보다 결과가 안좋았다.

# Step 1: Camelot으로 PDF에서 테이블 추출
# Annex III가 있는 페이지 범위 (137-367 페이지)
# pages 파라미터: "1-10" 또는 "1,3,5" 또는 "all"

print("Camelot으로 PDF에서 테이블 추출 중...")
print("(페이지 수에 따라 시간이 걸릴 수 있습니다)")

# lattice 모드: 테이블 경계선이 있는 경우
# stream 모드: 경계선 없이 공백으로 구분된 테이블
tables = camelot.read_pdf(
    pdf_path,
    pages="137-367",  # Annex III 페이지 범위
    flavor="lattice",  # 또는 "stream"
)

print(f"\n✓ 추출 완료: {len(tables)}개 테이블")

# 중간 생략

# Step 4: 모든 테이블을 Markdown으로 변환하여 저장
output_file = Path("output3.md")

with open(output_file, "w", encoding="utf-8") as f:
    
    for i, table in enumerate(tables):
        
        # DataFrame을 Markdown 테이블로 변환
        df = table.df
        f.write(df.to_markdown(index=False))
        f.write("\n\n---\n\n")

print(f"✓ Markdown 파일 저장 완료: {output_file}")
print(f"  파일 크기: {output_file.stat().st_size / 1024:.2f} KB")

3. pyplumber + pandas

camelot과 큰차이 없었다.

# Step 1: pdfplumber로 PDF에서 테이블 추출
# Annex III가 있는 페이지 범위 (137-367 페이지, 0-indexed: 136-366)

print("pdfplumber로 PDF에서 테이블 추출 중...")
print("(페이지 수에 따라 시간이 걸릴 수 있습니다)")

all_tables = []

with pdfplumber.open(pdf_path) as pdf:
    total_pages = len(pdf.pages)
    print(f"총 페이지 수: {total_pages}")
    
    # Annex III 페이지 범위 (0-indexed)
    start_page = 136
    end_page = min(367, total_pages)
    
    for page_num in range(start_page, end_page):
        page = pdf.pages[page_num]
        tables = page.extract_tables()
        
        if tables:
            for table in tables:
                all_tables.append({
                    'page': page_num + 1,  # 1-indexed로 저장
                    'data': table
                })

print(f"\n✓ 추출 완료: {len(all_tables)}개 테이블")

# 중간 생략

# Step 3: 첫 번째 테이블 미리보기 (DataFrame)
if all_tables:
    print("--- 첫 번째 테이블 (DataFrame) ---\n")
    first_table = all_tables[0]['data']
    
    # 첫 행을 헤더로 사용
    if first_table and len(first_table) > 1:
        df = pd.DataFrame(first_table[1:], columns=first_table[0])
    else:
        df = pd.DataFrame(first_table)
    
    print(df.head(10))
    print(f"\n크기: {df.shape}")

NVIDIA vGPU GPU Operator install

DanielZZI — Sun, 16 Jun 2024 19:15:56 +0900

대부분의 내용은 gpu operator 페이지에 다있다.

https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/

docs.nvidia.com

1.vGPU드라이버 다운로드

vGPU드라이버는 유료라이센스. 전용페이지에서 다운

2.준비물

driver(.run) 파일

vGPUDriverCatalog.yaml

gridd.conf

.tok파일

3.환경변수설정

4.driver 이미지 빌드

준비물포함

5.configmap 생성

- licensing-config

vGPU 라이센스

- metrics-config

DCGM exporter의 커스텀 메트릭 사용을 위한 csv파일 다운로드후 configmap으로 생성

6.helm install

helm install 시 -f add_values.yaml 로 overwrite

-- vGPU helm 주요 옵션

operator.defaultRuntime : 나의 경우 containerd를 cri로 사용

driver.image: 커스텀이미지

driver.licensingConfig.configMapName: 라이센스

dcgmexporter.config, env: 커스텀 메트릭 사용시

rdma,gds, gdrcopy : 지원가능여부에 따라 함께 사용시 강려크.

gpu operator helm 주요 파라미터

DanielZZI — Sun, 16 Jun 2024 18:51:17 +0900

# redhat openshift 여부

platform:
openshift: false

# node feature discovery 사용여부. node의 정보(cpu, gpu, mem등)을 수집
nfd:
enabled: true
nodefeaturerules: false

# pod security admission 사용여부
psa:
enabled: false

# containder device interface 사용여부/ true로 하면 default runtime class(nvidia)외에 2개의 runtime class(nvidia-cdi, nvidia-legacy)를 모두 사용가능

# cri에서 nvidia gpu같은 복잡한 device를 활용하는데 있어서 표준 스펙을 만듬.
cdi:
enabled: false
default: false

# KubeVirt, Kata Container, Confidential Containers 기능 사용시 필요. 노드별 gpu환경구성이 주로 어떤걸로 이뤄지는지.

# container, vm-passthrough, vm-vgpu 중 가장 많이 사용하는것으로 선택
sandboxWorkloads:
enabled: false
defaultWorkload: "container"

daemonsets:
  labels: {}
  annotations: {}
  priorityClassName: system-node-critical
  tolerations:
  - key: nvidia.com/gpu
    operator: Exists
    effect: NoSchedule
  # configuration for controlling update strategy("OnDelete" or "RollingUpdate") of GPU Operands
  # note that driver Daemonset is always set with OnDelete to avoid unintended disruptions
  updateStrategy: "RollingUpdate"
  # configuration for controlling rolling update of GPU Operands
  rollingUpdate:
    # maximum number of nodes to simultaneously apply pod updates on.
    # can be specified either as number or percentage of nodes. Default 1.
    maxUnavailable: "1"

# gpu validator는 Daemonset으로 실행, 모든 GPU 노드에서 모든 구성 요소가 예상대로 작동하는지 확인.

# 각 구성 요소에 대해 InitContainers를 통해 검증을 수행하고, 결과로 /run/nvidia/validations 디렉터리 아래에 상태 파일을 작성한다.
validator:
  repository: nvcr.io/nvidia/cloud-native
  image: gpu-operator-validator
  # If version is not specified, then default is to use chart.AppVersion
  #version: ""
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  args: []
  resources: {}
  plugin:
    env:
      - name: WITH_WORKLOAD
        value: "false"

operator:
  repository: nvcr.io/nvidia
  image: gpu-operator
  # If version is not specified, then default is to use chart.AppVersion
  #version: ""
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  priorityClassName: system-node-critical
  defaultRuntime: docker
  runtimeClass: nvidia

# redhat openshift의 driver toolkit사용여부
  use_ocp_driver_toolkit: false
  # cleanup CRD on chart un-install
  cleanupCRD: false
  # upgrade CRD on chart upgrade, requires --disable-openapi-validation flag
  # to be passed during helm upgrade.
  upgradeCRD: false
  initContainer:
    image: cuda
    repository: nvcr.io/nvidia
    version: 12.4.1-base-ubi8
    imagePullPolicy: IfNotPresent
  tolerations:
  - key: "node-role.kubernetes.io/master"
    operator: "Equal"
    value: ""
    effect: "NoSchedule"
  - key: "node-role.kubernetes.io/control-plane"
    operator: "Equal"
    value: ""
    effect: "NoSchedule"
  annotations:
    openshift.io/scc: restricted-readonly
  affinity:
    nodeAffinity:
      preferredDuringSchedulingIgnoredDuringExecution:
        - weight: 1
          preference:
            matchExpressions:
              - key: "node-role.kubernetes.io/master"
                operator: In
                values: [""]
        - weight: 1
          preference:
            matchExpressions:
              - key: "node-role.kubernetes.io/control-plane"
                operator: In
                values: [""]
  logging:
    # Zap time encoding (one of 'epoch', 'millis', 'nano', 'iso8601', 'rfc3339' or 'rfc3339nano')
    timeEncoding: epoch
    # Zap Level to configure the verbosity of logging. Can be one of 'debug', 'info', 'error', or any integer value > 0 which corresponds to custom debug levels of increasing verbosity
    level: info
    # Development Mode defaults(encoder=consoleEncoder,logLevel=Debug,stackTraceLevel=Warn)
    # Production Mode defaults(encoder=jsonEncoder,logLevel=Info,stackTraceLevel=Error)
    develMode: false
  resources:
    limits:
      cpu: 500m
      memory: 350Mi
    requests:
      cpu: 200m
      memory: 100Mi

# multi-instance gpu를 1개 디바이스로만 사용

# 모든 노드가 mig를 사용하는게 아니라면 mixed로 설정해야함.

mig:
strategy: single

driver:
enabled: true

#clusterplicy crd가 아닌 nvidia driver crd 사용. 각 노드별 서로다른 gpu driver와 os로 셋업해 cluster구성가능
  nvidiaDriverCRD:
    enabled: false
    deployDefaultCR: true
    driverType: gpu
    nodeSelector: {}

# GDS사용시, GDS driver version 2.17.5 or newer버전은 open kernel module사용필요.
  useOpenKernelModules: false
  # use pre-compiled packages for NVIDIA driver installation.
  # only supported for as a tech-preview feature on ubuntu22.04 kernels.

#인터넷환경이 제약적인경우, precompiled된 driver사용.
  usePrecompiled: false
  repository: nvcr.io/nvidia
  image: driver
  version: "550.90.07"
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  startupProbe:
    initialDelaySeconds: 60
    periodSeconds: 10
    # nvidia-smi can take longer than 30s in some cases
    # ensure enough timeout is set
    timeoutSeconds: 60
    failureThreshold: 120

# RDMA 사용여부. 별도로 다룸
rdma:
enabled: false

#rdma를 위한 mofed설치를 직접host에 설치한경우 true, network operator를 통해 설치할 경우 false.
    useHostMofed: false
  upgradePolicy:
    # global switch for automatic upgrade feature
    # if set to false all other options are ignored
    autoUpgrade: true
    # how many nodes can be upgraded in parallel
    # 0 means no limit, all nodes will be upgraded in parallel
    maxParallelUpgrades: 1
    # maximum number of nodes with the driver installed, that can be unavailable during
    # the upgrade. Value can be an absolute number (ex: 5) or
    # a percentage of total nodes at the start of upgrade (ex:
    # 10%). Absolute number is calculated from percentage by rounding
    # up. By default, a fixed value of 25% is used.'
    maxUnavailable: 25%
    # options for waiting on pod(job) completions
    waitForCompletion:
      timeoutSeconds: 0
      podSelector: ""
    # options for gpu pod deletion
    gpuPodDeletion:
      force: false
      timeoutSeconds: 300
      deleteEmptyDir: false
    # options for node drain (`kubectl drain`) before the driver reload
    # this is required only if default GPU pod deletions done by the operator
    # are not sufficient to re-install the driver
    drain:
      enable: false
      force: false
      podSelector: ""
      # It's recommended to set a timeout to avoid infinite drain in case non-fatal error keeps happening on retries
      timeoutSeconds: 300
      deleteEmptyDir: false

# 다양한 운영 체제 및 커널 버전과 호환되는 드라이버를 자동으로 선택하고 배포, 업그레이드 등 수행
  manager:
    image: k8s-driver-manager
    repository: nvcr.io/nvidia/cloud-native
    # When choosing a different version of k8s-driver-manager, DO NOT downgrade to a version lower than v0.6.4
    # to ensure k8s-driver-manager stays compatible with gpu-operator starting from v24.3.0
    version: v0.6.8
    imagePullPolicy: IfNotPresent

#작업시 노드에 pod유지/퇴출에 관한 설정들..
    env:
      - name: ENABLE_GPU_POD_EVICTION
        value: "true"
      - name: ENABLE_AUTO_DRAIN
        value: "false"
      - name: DRAIN_USE_FORCE
        value: "false"
      - name: DRAIN_POD_SELECTOR_LABEL
        value: ""
      - name: DRAIN_TIMEOUT_SECONDS
        value: "0s"
      - name: DRAIN_DELETE_EMPTYDIR_DATA
        value: "false"
  env: []
  resources: {}
  # Private mirror repository configuration
  repoConfig:
    configMapName: ""
  # custom ssl key/certificate configuration
  certConfig:
    name: ""
  # vGPU licensing configuration

# vGPU 사용시 필수
  licensingConfig:
    configMapName: ""
    nlsEnabled: true
  # vGPU topology daemon configuration
  virtualTopology:
    config: ""
  # kernel module configuration for NVIDIA driver
  kernelModuleConfig:
    name: ""

#host에 container toolkit직접 설치시, false
toolkit:
  enabled: true
  repository: nvcr.io/nvidia/k8s
  image: container-toolkit
  version: v1.15.0-ubuntu20.04
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  resources: {}
  installDir: "/usr/local/nvidia"

devicePlugin:
  enabled: true
  repository: nvcr.io/nvidia
  image: k8s-device-plugin
  version: v0.15.0-ubi8
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  args: []
  env:
    - name: PASS_DEVICE_SPECS
      value: "true"
    - name: FAIL_ON_INIT_ERROR
      value: "true"
    - name: DEVICE_LIST_STRATEGY
      value: envvar
    - name: DEVICE_ID_STRATEGY
      value: uuid
    - name: NVIDIA_VISIBLE_DEVICES
      value: all
    - name: NVIDIA_DRIVER_CAPABILITIES
      value: all
  resources: {}
  # Plugin configuration
  # Use "name" to either point to an existing ConfigMap or to create a new one with a list of configurations(i.e with create=true).
  # Use "data" to build an integrated ConfigMap from a set of configurations as
  # part of this helm chart. An example of setting "data" might be:
  # config:
  #   name: device-plugin-config
  #   create: true
  #   data:
  #     default: |-
  #       version: v1
  #       flags:
  #         migStrategy: none
  #     mig-single: |-
  #       version: v1
  #       flags:
  #         migStrategy: single
  #     mig-mixed: |-
  #       version: v1
  #       flags:
  #         migStrategy: mixed
  config:
    # Create a ConfigMap (default: false)
    create: false
    # ConfigMap name (either exiting or to create a new one with create=true above)
    name: ""
    # Default config name within the ConfigMap
    default: ""
    # Data section for the ConfigMap to create (i.e only applies when create=true)
    data: {}
  # MPS related configuration for the plugin
  mps:
    # MPS root path on the host
    root: "/run/nvidia/mps"

# standalone dcgm hostengine

# dcgm은 기본적으로 dcgm exporter내 hostengine을 사용한다.

# 단독 standalone으로 사용필요시 true
dcgm:
  # disabled by default to use embedded nv-hostengine by exporter
  enabled: false
  repository: nvcr.io/nvidia/cloud-native
  image: dcgm
  version: 3.3.5-1-ubuntu22.04
  imagePullPolicy: IfNotPresent
  args: []
  env: []
  resources: {}

dcgmExporter:
  enabled: true
  repository: nvcr.io/nvidia/k8s
  image: dcgm-exporter
  version: 3.3.5-3.4.1-ubuntu22.04
  imagePullPolicy: IfNotPresent
  env:
    - name: DCGM_EXPORTER_LISTEN
      value: ":9400"
    - name: DCGM_EXPORTER_KUBERNETES
      value: "true"
    - name: DCGM_EXPORTER_COLLECTORS
      value: "/etc/dcgm-exporter/dcp-metrics-included.csv"
  resources: {}
  serviceMonitor:
    enabled: false
    interval: 15s
    honorLabels: false
    additionalLabels: {}
    relabelings: []
    # - source_labels:
    #     - __meta_kubernetes_pod_node_name
    #   regex: (.*)
    #   target_label: instance
    #   replacement: $1
    #   action: replace

#gpu feature discovery 사용여부. 필수
gfd:
  enabled: true
  repository: nvcr.io/nvidia
  image: k8s-device-plugin
  version: v0.15.0-ubi8
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env:
    - name: GFD_SLEEP_INTERVAL
      value: 60s
    - name: GFD_FAIL_ON_INIT_ERROR
      value: "true"
  resources: {}

#mig 사용시 mig config설정
migManager:
  enabled: true
  repository: nvcr.io/nvidia/cloud-native
  image: k8s-mig-manager
  version: v0.7.0-ubuntu20.04
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env:
    - name: WITH_REBOOT
      value: "false"
  resources: {}
  config:
    name: "default-mig-parted-config"
    default: "all-disabled"
  gpuClientsConfig:
    name: ""

#굳이필요없어보임.
nodeStatusExporter:
  enabled: false
  repository: nvcr.io/nvidia/cloud-native
  image: gpu-operator-validator
  # If version is not specified, then default is to use chart.AppVersion
  #version: ""
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  resources: {}

#별도로 다룸
gds:
  enabled: false
  repository: nvcr.io/nvidia/cloud-native
  image: nvidia-fs
  version: "2.17.5"
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  args: []

# NVIDIA GPU와 호스트 시스템 간의 메모리 복사 성능을 최적화하기 위해 개발된 라이브러리.

# GDRCopy는 특히 GPU Direct RDMA (Remote Direct Memory Access) 기술을 활용하여 GPU와 호스트 메모리 간의 데이터를 효율적으로 복사할 수있도록한다. HPC (High-Performance Computing) 및 데이터 집약적인 응용 프로그램에서 중요한 역할.

#RDMA사용시 추가적옵션.
gdrcopy:
  enabled: false
  repository: nvcr.io/nvidia/cloud-native
  image: gdrdrv
  version: "v2.4.1"
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  args: []

#vm host에 설치하여 vgpu할당/생성해주는 매니저. k8s cluster위의 vm생성시 필요(KubeVirt)
vgpuManager:
  enabled: false
  repository: ""
  image: vgpu-manager
  version: ""
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  resources: {}
  driverManager:
    image: k8s-driver-manager
    repository: nvcr.io/nvidia/cloud-native
    # When choosing a different version of k8s-driver-manager, DO NOT downgrade to a version lower than v0.6.4
    # to ensure k8s-driver-manager stays compatible with gpu-operator starting from v24.3.0
    version: v0.6.8
    imagePullPolicy: IfNotPresent
    env:
      - name: ENABLE_GPU_POD_EVICTION
        value: "false"
      - name: ENABLE_AUTO_DRAIN
        value: "false"

# vgpu device 관리
vgpuDeviceManager:
  enabled: true
  repository: nvcr.io/nvidia/cloud-native
  image: vgpu-device-manager
  version: "v0.2.6"
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  config:
    name: ""
    default: "default"

# vm환경에서 gpu passthrough를 통한 직접 vgpu사용시, vfio-pci를 로드하고(vf는 sr-iov등을 통한 가상화된 디바이스), 노드의 모든 gpu에 바인딩해주는 매니저

# vm gpu passthrough사용시 필수
vfioManager:
  enabled: true
  repository: nvcr.io/nvidia
  image: cuda
  version: 12.4.1-base-ubi8
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  resources: {}
  driverManager:
    image: k8s-driver-manager
    repository: nvcr.io/nvidia/cloud-native
    # When choosing a different version of k8s-driver-manager, DO NOT downgrade to a version lower than v0.6.4
    # to ensure k8s-driver-manager stays compatible with gpu-operator starting from v24.3.0
    version: v0.6.8
    imagePullPolicy: IfNotPresent
    env:
      - name: ENABLE_GPU_POD_EVICTION
        value: "false"
      - name: ENABLE_AUTO_DRAIN
        value: "false"

# 주요 용어 페이지 참고
kataManager:
  enabled: false
  config:
    artifactsDir: "/opt/nvidia-gpu-operator/artifacts/runtimeclasses"
    runtimeClasses:
      - name: kata-nvidia-gpu
        nodeSelector: {}
        artifacts:
          url: nvcr.io/nvidia/cloud-native/kata-gpu-artifacts:ubuntu22.04-535.54.03
          pullSecret: ""
      - name: kata-nvidia-gpu-snp
        nodeSelector:
          "nvidia.com/cc.capable": "true"
        artifacts:
          url: nvcr.io/nvidia/cloud-native/kata-gpu-artifacts:ubuntu22.04-535.86.10-snp
          pullSecret: ""
  repository: nvcr.io/nvidia/cloud-native
  image: k8s-kata-manager
  version: v0.2.0
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env: []
  resources: {}

# kubevirt사용시 vm환경에서 gpu자원 사용을 도움
sandboxDevicePlugin:
  enabled: true
  repository: nvcr.io/nvidia
  image: kubevirt-gpu-device-plugin
  version: v1.2.7
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  args: []
  env: []
  resources: {}

# confidential container환경에서 사용
ccManager:
  enabled: false
  defaultMode: "off"
  repository: nvcr.io/nvidia/cloud-native
  image: k8s-cc-manager
  version: v0.1.1
  imagePullPolicy: IfNotPresent
  imagePullSecrets: []
  env:
    - name: CC_CAPABLE_DEVICE_IDS
      value: "0x2339,0x2331,0x2330,0x2324,0x2322,0x233d"
  resources: {}

#gpu, cpu, mem등 노드 상태를 수집.
node-feature-discovery:
  enableNodeFeatureApi: true
  gc:
    enable: true
    replicaCount: 1
    serviceAccount:
      name: node-feature-discovery
      create: false
  worker:
    serviceAccount:
      name: node-feature-discovery
      # disable creation to avoid duplicate serviceaccount creation by master spec below
      create: false
    tolerations:
    - key: "node-role.kubernetes.io/master"
      operator: "Equal"
      value: ""
      effect: "NoSchedule"
    - key: "node-role.kubernetes.io/control-plane"
      operator: "Equal"
      value: ""
      effect: "NoSchedule"
    - key: nvidia.com/gpu
      operator: Exists
      effect: NoSchedule
    config:
      sources:
        pci:

#03이
          deviceClassWhitelist:
          - "02" # 모든 네트워크 컨트롤러 허용
          - "0200" # 이더넷 컨트롤러 허용
          - "0207" # Infiniband 컨트롤러 허용
          - "0300" # VGA 호환 그래픽 컨트롤러 허용 (주로 GPU)
          - "0302" # VGA 호환이 아닌 3D 그래픽 컨트롤러 허용 (주로 고성능 GPU)
          deviceLabelFields:
          - vendor
  master:
    serviceAccount:
      name: node-feature-discovery
      create: true
    config:
      extraLabelNs: ["nvidia.com"]
      # noPublish: false
      # resourceLabels: ["nvidia.com/feature-1","nvidia.com/feature-2"]
      # enableTaints: false
      # labelWhiteList: "nvidia.com/gpu"

NVIDIA GPU Operator 용어

DanielZZI — Sun, 16 Jun 2024 17:28:35 +0900

GPU Driver CRD (NVIDIA Driver CRD)

개별 노드에 GPU driver type과 버전을 지정할 수 있는 nvidia custom driver, custom resource를 생성할 수 있다.
노드셀렉터를 통해 노드별 os에 따른 드라이버설정 가능

-- Cluster Policy CRD와 NVIDIA Driver CRD 비교

https://docs.nvidia.com/datacenter/cloud-native/gpu-operator/latest/gpu-driver-configuration.html

KubeVirt

k8s cluster상 VM환경 생성성하고 관리하게 해주는 기술.
VM과 Container를 위한 개별 클러스터를 구성할 필요 없이 하나의 k8s cluster에서 모두 사용가능하게 해주는 기술

ex) 아래와 같은 노드별 GPU환경을 구동하려고 한다.
node A: container구동
node B: GPU PassThrough방식의 VM사용
node C: vGPU방식의 VM사용

이때 구성요소는
node A:

NVIDIA Datacenter Driver: GPU Driver설치
NVIDIA Container toolkit: CRI에서 GPU 활용하게 해준다.
NVIDIA k8s Device Plugin: GPU자원을 발견
NVIDIA DCGM Exporter: GPU 모니터링

node B:

VFIO Manger : vfio-pci 로딩 및 GPU바인딩
Sandbox Device Plugin: GPU자원을 발견

node C:

NVIDIA vGPU Manager: vGPU driver설치
NVIDIA vGPU Device Manager: vGPU 생성할당 위해 host에 설치
Sandbox Device Plugin: vGPU device 발견
위 와같은 구성요소를 설치하여 각 k8s의 worker node는 라벨링을 통해 용도를 구분하여 전용 workloads를 처리할 수있다.

Kata Containers

docker container와 다르게 kernel과 유저공간을 모두 격리한다.
kata runtime은 QEMU와 같은 hypervisor를 사용하여 vm을 제공하고, 그 위에서 kata container를 실행한다.
NVIDIA는 Confidentail Container를 통해 KATA runtime과 QEMU를 설치하고, kata container를 지원한다.

Confidential Container

computing측면에서 GPU workloads와 코드의 보안강화/격리를 위한 컨테이너기술

RDMA

별도로 다룸

GDS(GPU Direct Storage)

별도로 다룸

NFD(Node Feature Discovery)

NFD의 구성 요소

nfd-master:
NFD의 중앙 구성 요소로, 각 노드에서 수집된 기능 정보를 수신하고 이를 기반으로 노드에 라벨을 적용
nfd-worker:
각 노드에서 실행되며, 하드웨어 및 소프트웨어 기능을 검색하여 이를 nfd-master에 보고

NFD의 작동 방식

nfd-worker 실행: NFD 데몬셋이 각 노드에서 nfd-worker를 실행. nfd-worker는 노드의 하드웨어 및 소프트웨어 상태를 검사
기능 검색: nfd-worker는 노드의 다양한 기능을 검색. 여기에는 GPU, CPU, 메모리, 네트워크 인터페이스, 커널 모듈 등이 포함.
라벨 생성: 발견된 기능 정보를 기반으로 라벨을 생성. 예를 들어, GPU가 감지되면 nvidia.com/gpu.present=true와 같은 라벨이 생성된다.
nfd-master 보고: nfd-worker는 검색된 기능 정보를 nfd-master에 보고.
노드 라벨링: nfd-master는 수신된 정보를 바탕으로 노드에 적절한 라벨을 추가.

GFD(GPU Feature Discovery)

GFD는 노드에 GPU의 세부정보(gpu 모델, 메모리크기, cuda버전, 드라이버 버전..)를 수집하여 k8s노드에 레이블을 추가해준다.
NFD(Node Feature Discovery) 마스터에 수집정보를 알린다.

SR-IOV(Single Root I/O Virtualization)

단일 PCI Express(PCIe) endpoint가 여러 개별 디바이스로 사용될 수 있게 해주는기술
하나의 PCIe장치를 여러개의 가상PCIe장치로 보이게 만드는 기술

NVIDIA Ampere아키텍쳐에서 vGPU활용위해 필수
The virtualization and IOMMU extensions (Intel VT-d or AMD IOMMU) are enabled in the BIOS.
The host is booted with intel_iommu=on or amd_iommu=on on the kernel command line.
If planning to use NVIDIA vGPU, SR-IOV must be enabled in the BIOS if your GPUs are based on the NVIDIA Ampere architecture or later. Refer to the NVIDIA vGPU Documentation to ensure you have met all of the prerequisites for using NVIDIA vGPU.

NVIDIA Driver Manager for k8s (k8s-driver-manager)

gpu operator의 구성요소로 vfio manager, vGPU manager 등에서 이미지로 쓰임. 아래역할을 수행하는 중요한 component

Check for already installed kernel modules.
Perform Drain on the node ignoring Daemonset pods.
Evict GPU Operator components like Device-Plugin, GPU Feature Discovery, DCGM Exporter etc.
Unload kernel-modules.
Unmount Driver root filesystem mounted on the host previously under /run/nvidia/driver.
Uncordon the node.

GPUDirect RDMA와 vGPU

DanielZZI — Tue, 11 Jun 2024 03:53:41 +0900

먼저 RDMA부터 알아보자

RDMA (Remote Direct Memory Access)

RDMA는 네트워크를 통해 데이터 전송 시, CPU의 개입을 최소화하고 메모리 대 메모리 전송을 직접 수행하는 기술입니다. 주요 특징은 다음과 같습니다:

낮은 지연 시간: 데이터 전송 중에 CPU가 관여하지 않기 때문에 지연 시간이 매우 짧습니다.
높은 대역폭: 네트워크 인터페이스 카드(NIC)가 직접 메모리에 접근하여 데이터를 전송하기 때문에 높은 대역폭을 제공합니다.
낮은 CPU 오버헤드: CPU의 개입이 최소화되어 CPU 사용률이 낮아집니다.
제로 카피: 데이터가 직접 전송되므로 추가적인 데이터 복사가 필요 없습니다.

RDMA는 인피니밴드(InfiniBand), RoCE (RDMA over Converged Ethernet), iWARP (Internet Wide Area RDMA Protocol) 등의 프로토콜을 통해 구현됩니다.

다음 GPUDirect RDMA를 알아보자

GPUDirect RDMA

GPUDirect RDMA는 NVIDIA의 기술로, RDMA를 GPU 메모리에 직접 적용하여 GPU와 네트워크 장치 간의 데이터 전송을 효율화합니다. 주요 특징은 다음과 같습니다:

GPU와 네트워크 장치 간의 직접 데이터 전송: 데이터가 GPU와 네트워크 장치 간에 직접 전송되므로, CPU 메모리로의 불필요한 전송 단계를 제거합니다.
낮은 지연 시간: 데이터 전송 중에 CPU 개입을 최소화하여 지연 시간을 줄입니다.
높은 대역폭: GPU 메모리와 네트워크 장치 간의 고속 데이터 전송을 가능하게 합니다.
효율적인 자원 사용: CPU 자원 사용을 줄이고, 데이터 전송 효율성을 극대화합니다.

GPUDirect RDMA를 사용하기위해서는 다음과 같은 것들이 필요하다.

1.GPU

RDMA 지원 NVIDIA GPU like Tesla, Quadro, A시리즈 등

2.NIC

Infiniband, RoCE를 지원하는 NIC. 대표적으로 Mellanox의 ConnetX시리즈를 많이 사용한다.

3.SW

Linux kernel특정버전 호환성 확인필요
driver 및 library: Nvidia GPU Driver, CUDA 툴킷, Mellanox OFED 드라이버(MOFED) 등
-> NVIDIA GPU Operator 및 Netwokr Operator를 통해 container로 셋업가능하다.

vGPU와 GPUDirect RDMA 활용

먼저 VM 구성시 옵션을 통한 RoCE또는 물리적 NIC 연결필요

pciPassthru.allowP2P = true: PCI 장치 간의 P2P 통신 허용.
pciPassthru.RelaxACSforP2P = true: ACS 규칙을 완화하여 P2P 통신 허용.
pciPassthru.use64bitMMIO = true: 64비트 MMIO 주소 공간 사용.
pciPassthru.64bitMMIOSizeGB = 128: 64비트 MMIO 주소 공간 크기를 128GB로 설정.

SR-IOV 설정
SR-IOV는 물리적 NIC를 여러 가상 NIC(VF)로 나누어 VM이 직접 NIC에 접근할 수 있게 하는 기술

커널파라미터 설정
he host is booted with intel_iommu=on or amd_iommu=on on the kernel command line.
/etc/default/grub 파일을 편집하여 커널 파라미터에 IOMMU 설정을 추가합니다.
bash
코드 복사
GRUB_CMDLINE_LINUX="... intel_iommu=on" # Intel
GRUB_CMDLINE_LINUX="... amd_iommu=on" # AMD
그런 다음, GRUB 설정을 업데이트하고 시스템을 재부팅합니다.
bash
코드 복사
sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot
물리 NIC에서 SR-IOV VF(가상스위치)생성

1.command로 생성
echo 8 > /sys/class/net/<PF 인터페이스 이름>/device/sriov_numvfs

2.ui를 통한 생성 참고
https://www.juniper.net/documentation/kr/ko/software/vmx/vmx-vmware/topics/task/vmx-sriov-enabling-vmware.html

VF를 VM에 할당
https://www.juniper.net/documentation/kr/ko/software/vmx/vmx-vmware/topics/task/vmx-sriov-enabling-vmware.html

완벽하진 않으나, 일단 정리..

keydb

DanielZZI — Wed, 22 May 2024 22:09:05 +0900

1. keydb vs redis

기본적으로 keydb는 redis에서 fork되어 개선하고자 탄생했다.

특히 keydb는 기존 redis에서 더 발전한 HA구성이 돋보인다.

기존 reids처럼 master-slave 구성도 지원하지만,

Active-Replica와 Multi-Master 이 두가지 특성이 Redis보다 발전된 load balancing 기능을 지원한다.
이 경우 keydb에서 sentinel을 사용할 필요가 없어진다.(redis-sentinel-HA proxy 더이상 안써도되나!!!)

Active-Replica:

Active-Replica 모드는 하나의 마스터 노드와 여러 Replica노드를 허용하는 Redis의 일반적인 Master-Slave replica 모델을 개선한 것이다.
Active-Repllica 모드에서는 모든 노드가 읽기 및 쓰기 요청을 처리할 수 있다.
데이터가 한 노드에서 업데이트 되면 다른 노드로 전파된다. 이를 위해서 각 노드는 비동기적으로 서로 데이터를 복제한다.
업데이트가 발생하면 변경사항이 나머지 노드로 전파되고, 이 과정에서 지연이 발생할 수 있다.

Multi-Master:

Multi-Master모드에서는 모든 노드가 완전한 마스터로 동작한다. 즉, 각노드가 데이터를 독립적으로 수정하고, 이러한 변경사항이 다른 모든 노드로 동기화된다.
이 모드에서는 노드 간의 데이터 충돌을 방지하기위해 CRDT(Conflict-free Replicated Data Types)와 같은 알고리즘을 사용하여 데이터충돌을 해결한다.
데이터가 어느 한 노드에서 업데이트 되면 , 해당 업데이트가 다른 모든 노드에 복제되어 일관성을 유지한다.

고성능 및 멀티스레드 아키텍쳐

keydb는 멀티스레드 아키텍쳐를 통해 Redis의 싱글스레드 제한을 극복하고 성능극대화를 할수있다.

2. 현재 내가 사용하고 있는 구성을 보자

https://github.com/Enapter/charts/tree/master

k8s 구성
replica 3의 statefulset으로 구성되어있고, 각 pod는 독립적인 keydb instance를 실행하며 ,이들간의 비동기 데이터 동기화를 이루고 있다.
data볼륨을 EmptyDir volume으로 하여 해당pod유실시 기본적으로 데이터는 없어진다.
active-replica "yes" 로 active 레플리카를
multi-master "yes"로 멀티마스터구조를
repl-diskless-sync "yes"로 비동기적인 sync를
repl-diskless-sync-delay 5 로 비동기주기를 5초로
repl-diskless-load disabled 옵션을 통해 memory기반이 아닌 disk기반 비동기 sync를
설정하고 있다.

이를 통해서 keydb의 3개 pod가 서로간 sync될 충분한 시간(5초+동기화시간)없이 pod가 전부 다운될경우 데이터가 유실될수 있음을 유의해야한다.

LiveHard

DGX Spark로 OpenClaw Local LLM 구성- GPT-OSS-120B 최적화하기

DGX Spark에서 GPT-OSS 최적화하기

1. 테스트 환경

2. Baseline — 현재 상태

2.1 docker-compose.yml (원본)

2.2 Baseline 성능 측정

2.3 Baseline의 문제점

3. 1단계 — NGC 이미지 튜닝

3.1 변경 사항

3.2 docker-compose.yml (1단계 튜닝)

3.3 각 변경의 의미

3.4 1단계 성능 측정

3.5 1단계 결론: 속도는 안 바뀐다

참고) KV 캐시 용량이 늘면 왜 tok/s는 안 바뀌나?

4. 2단계 — 커스텀 이미지 빌드 (spark-vllm-docker)

4.1 커스텀 빌드가 다른 점

4.2 GPT-OSS 전용 Recipe

4.3 빌드 방법

4.4 빌드 소요 시간

4.5 2단계 성능 측정

4.6 왜 56.8 tok/s가 가능한가?

5. 성능 비교 요약

6. 결론 및 권장 사항

1단계만으로 충분한가?

2단계의 실질적 가치

권장 사항

참고 자료

DGX Spark로 OpenClaw Local LLM 구성 — Provider 선정기

DGX Spark로 OpenClaw Local LLM 구성 — Provider 선정기

1. 배경: OpenClaw에 로컬 LLM이 필요한 이유

2. 테스트 환경

하드웨어

소프트웨어

모델

3. 후보 1: Ollama — "일단 빠르게 올려보자"

구성

docker-compose.yml

결과: 성공

메모리 사용량 (안정 상태)

성능 벤치마크

Ollama의 강점과 한계

4. 후보 2: SGLang — "공식 가이드가 있으니 안정적이겠지"

구성

docker-compose.yml (최종 시도)

시도 과정 및 결과

시도 1: --attention-backend flashinfer

시도 2: --attention-backend triton, --mem-fraction-static 0.75

시도 3: --mem-fraction-static 0.40 (KV 캐시 축소)

시도 4: 공식 LMSYS 가이드 준수 (attention-backend/mem-fraction 제거)

SGLang 실패 원인 분석

5. 후보 3: vLLM — "SGLang이 안 되니 대안을 찾자"

구성

docker-compose.yml

시작 로그 (주요 단계)

결과: 성공

메모리 사용량 (안정 상태)

성능 벤치마크

테스트 1: 단순 질의

테스트 2: 긴 텍스트 생성

6. 세 후보 종합 비교

안정성

메모리 효율

기능 비교

성능 비교 (Docker 환경, 단일 요청)

참고: 네이티브 환경 벤치마크

7. 결론: OpenClaw Provider로 무엇을 골랐는가

왜 Ollama(llama.cpp)가 가장 빠른가 — 통합 메모리 구조의 이해

일반 서버 vs DGX Spark — 메모리 구조가 근본적으로 다르다

LLM 추론의 병목: 메모리 대역폭

세 엔진이 메모리를 쓰는 방식의 차이

결론: 같은 하드웨어, 다른 결과의 원인

OpenClaw Provider 선정 결과

왜 이 선택인가?

범용 참고: 용도별 권장 엔진

핵심 정리

8. 부록: 기술 심화

A. vLLM과 SGLang의 MoE 커널 처리 방식 차이

B. Docker 환경과 네이티브 환경의 성능 차이 — 왜 SGLang은 네이티브에서 성공하는가

C. SGLang의 MoE 커널 백엔드 옵션 — triton 이외의 선택지

시도 1: `--attention-backend flashinfer`

시도 2: `--attention-backend triton`, `--mem-fraction-static 0.75`

시도 3: `--mem-fraction-static 0.40` (KV 캐시 축소)