태그: #gpu
GPU·LLM·MLOps·쿠버네티스, 그리고 마음가짐에 관한 글 · 74 편
홈랩 쿠버네티스 3노드에서 7노드로 — 컨트롤 플레인 확장, etcd 쿼럼, 그리고 "조인만 하면 HA"라는 착각
워커 2대와 컨트롤 플레인 2대를 추가해 홈랩을 7노드로 확장했습니다. kubeadm의 certificate-key가 왜 2시간짜리인지, etcd 멤버 3개가 실제로 어떻게 등록되는지를 실측으로 기록했습니다. 그리고 가장 중요한 발견 — etcd 쿼럼을 갖췄다고 HA가 되는 게 아니었습니다. 엔드포인트가 물리 IP에 고정된 클러스터에서 첫 노드가 죽으면 무슨 일이 벌어지는지, 인증서 재발급
2026-08-28 · 15 분 읽기 #kubernetes#kubeadm#etcd#high-availability#homelabGPU Operator 설치 중 만난 "no runtime for nvidia is configured" — 컨테이너 런타임과 Helm 업그레이드가 실제로 하는 일
5노드 홈랩에 NVIDIA GPU Operator를 올리다 파드가 전부 Init에서 멈췄습니다. 원인은 컨테이너 런타임에 nvidia 핸들러가 없다는 것이었고, 호스트에 nvidia-ctk 바이너리가 있다고 방심한 제 판단 착오였습니다. 왜 쿠버네티스에서 container toolkit이 필수인지, Helm upgrade가 내부적으로 무엇을 바꾸는지, 그리고 Operator가 containe
2026-08-27 · 20 분 읽기 #kubernetes#gpu#nvidia#containerd#helm세 줄짜리 설정 파일이 GPU 4장을 일주일 동안 죽였다 — containerd 드롭인 병합의 진실
노드가 GPU를 광고하지 않았습니다. 설정 파일에는 nvidia 런타임이 멀쩡히 적혀 있는데 containerd config dump에는 없었습니다. 범인은 일주일 전에 넣은 세 줄짜리 레지스트리 설정이었고, 이유는 containerd의 imports 병합이 필드 단위가 아니라 플러그인 단위 통째 교체이기 때문이었습니다. 두 번 잘못 진단한 과정과, 결국 답을 준 실험을 그대로 옮깁니다.
2026-08-26 · 20 분 읽기 #kubernetes#containerd#gpu#nvidia#troubleshootingvLLM 메트릭 — 무엇을 대시보드에 올리고 무엇으로 알람을 걸까
vLLM이 노출하는 시계열은 GPU 메트릭이 답하지 못하는 질문에 답합니다. 지금 몇 개가 실행 중이고 몇 개가 대기 중인지, KV 캐시가 얼마나 찼는지, 첫 토큰까지 얼마나 걸리는지 같은 것들입니다. 이 글은 vLLM 공식 문서와 저장소의 메트릭 로거 소스를 직접 읽고 스케줄러 상태 게이지, 캐시 계열 카운터, 지연 히스토그램의 정확한 이름과 의미를 정리하고, 카운터 이름의 접미사 차이처럼
2026-08-12 · 13 분 읽기 #gpu#kubernetes#vllm#prometheus#observabilityMIG와 time-slicing — GPU 한 장을 여럿이 쓰는 두 가지 방법
GPU 한 장에 여러 워크로드를 올리는 방법은 크게 두 가지입니다. 시간을 나누는 time-slicing과 하드웨어를 나누는 MIG인데, 이름이 비슷해 보이는 것과 달리 격리 수준이 전혀 다릅니다. 이 글은 NVIDIA GPU Operator 공식 문서를 기준으로 두 방식의 설정 파일 구조와 노드 라벨, 광고되는 리소스 이름, 지원 하드웨어 조건을 정리하고, time-slicing 복제본 사
2026-08-12 · 12 분 읽기 #gpu#kubernetes#mig#time-slicing#nvidiaDCGM Exporter — GPU 이용률은 당신이 생각하는 그것이 아니다
DCGM Exporter는 GPU 텔레메트리를 프로메테우스 형식으로 노출하는 표준 경로지만, 가장 많이 대시보드에 올라가는 GPU 이용률 계열 메트릭은 사람들이 기대하는 것을 재지 않습니다. 이 글은 dcgm-exporter 저장소의 기본 카운터 CSV와 DCGM 공식 문서, NVML API 문서를 직접 읽고 기본으로 켜져 있는 메트릭 목록, 이용률 메트릭이 실제로 무엇을 뜻하는지, 함께 봐
2026-08-12 · 17 분 읽기 #gpu#kubernetes#dcgm#prometheus#observabilityGPU 서빙 SLO와 알람 설계 — 무엇을 약속하고 무엇을 깨울 것인가
GPU 추론 서비스에 SLO를 걸려면 먼저 어떤 지표가 사용자 경험을 대변하는지 정해야 합니다. 첫 토큰 지연과 처리량은 서로를 잡아먹는 관계라 하나만 보고 목표를 세우면 반드시 다른 쪽이 무너집니다. 이 글은 vLLM과 DCGM Exporter가 실제로 노출하는 시계열만 써서 SLI를 정의하는 방법, 히스토그램 버킷 경계를 임계값으로 삼아야 하는 이유, 포화 신호를 읽는 순서, 증상 기반
2026-08-12 · 13 분 읽기 #gpu#kubernetes#slo#alerting#prometheusGPU 장애 진단 플레이북 — 계층을 정해 놓고 내려간다
쿠버네티스에서 GPU 문제를 진단할 때 가장 큰 낭비는 순서 없이 아무 데나 찔러 보는 것입니다. 파드가 스케줄되지 않는 것, 파드는 떴는데 GPU가 안 보이는 것, 드라이버와 툴킷 버전이 어긋난 것, 메모리가 부족한 것, 노드에서 GPU가 사라지는 것은 서로 다른 계층의 문제라 확인 순서가 다릅니다. 이 글은 NVIDIA GPU Operator 공식 트러블슈팅 문서와 dcgm-exporte
2026-08-12 · 14 분 읽기 #gpu#kubernetes#troubleshooting#nvidia#gpu-operator디바이스 플러그인과 GPU 스케줄링 — nvidia.com/gpu는 어디서 오는가
쿠버네티스는 GPU를 모릅니다. 노드가 GPU를 자원으로 광고하게 만드는 것은 kubelet에 등록된 디바이스 플러그인이고, 그 결과로 생기는 이름이 확장 리소스 nvidia.com/gpu입니다. 이 글은 디바이스 플러그인이 구현해야 하는 gRPC 인터페이스와 등록 소켓 경로, 확장 리소스에서 requests와 limits가 반드시 같아야 하는 이유, GPU를 CPU처럼 밀리코어로 쪼갤 수
2026-08-12 · 11 분 읽기 #gpu#kubernetes#device-plugin#scheduling#nvidiaNVIDIA GPU Operator 소개 — 원래 손으로 깔아야 했던 여섯 조각
쿠버네티스에서 GPU를 쓰려면 드라이버, NVIDIA Container Toolkit, 디바이스 플러그인, DCGM, GPU Feature Discovery, Node Feature Discovery를 노드마다 손으로 맞춰야 했습니다. NVIDIA GPU Operator는 이 조각들을 하나의 오퍼레이터로 묶고 ClusterPolicy 하나로 상태를 관리합니다. 각 컴포넌트가 정확히 무엇을 하
2026-08-12 · 11 분 읽기 #gpu#kubernetes#gpu-operator#nvidia#dcgmvLLM 내부 구조 (1) — 요청 하나가 토큰이 되어 나오기까지
vLLM에 요청 하나가 들어와 토큰이 나오기까지의 전체 경로를 따라갑니다. API 서버, 스케줄러, KV 캐시 매니저, 워커, 샘플러가 각각 무슨 일을 하는지, V1 재작성 이후 프로세스가 어떻게 나뉘는지를 공식 문서와 소스로 확인해 정리했습니다. vLLM 내부 구조 시리즈 1편.
2026-08-12 · 10 분 읽기 #vllm#llm#inference#gpu#ai-platformvLLM 내부 구조 (7) — 배포 튜닝과 흔한 함정, OOM 진단 순서
vLLM 배포를 실제로 튜닝하는 순서를 정리했습니다. gpumemoryutilization이 무엇을 정하는지, 텐서 병렬과 파이프라인 병렬을 언제 쓰는지, 양자화와 KV 캐시 자료형을 어떻게 고르는지, 그리고 OOM이 났을 때 기동 단계와 운영 단계를 나눠 진단하는 순서까지 공식 문서 기준으로 확인해 정리했습니다. vLLM 내부 구조 시리즈 마지막 편.
2026-08-12 · 17 분 읽기 #vllm#gpu#quantization#tensor-parallel#llmvLLM 내부 구조 (2) — PagedAttention은 KV 캐시를 왜 페이지로 쪼갰는가
PagedAttention이 KV 캐시를 블록 단위로 쪼갠 이유를 원 논문(arXiv:2309.06180)과 vLLM 공식 설계 문서로 확인해 정리했습니다. 연속 할당이 만드는 내부·외부 단편화, 블록 테이블이 하는 일, 블록 크기를 키우고 줄일 때의 트레이드오프까지 다룹니다. vLLM 내부 구조 시리즈 2편.
2026-08-12 · 12 분 읽기 #vllm#paged-attention#kv-cache#llm#gpuGPU 컴파일러와 프레임워크 지형 — 그래프를 받아 커널을 만드는 하나의 문제, 층마다 다른 답
NVCC와 PTX부터 LLVM, MLIR, Triton, torch.compile, XLA, IREE, TVM까지를 하나의 지도 위에 올렸습니다. 이름이 다르고 소속이 다르지만 이들은 전부 같은 문제를 풉니다. 연산 그래프를 받아 실행 가능한 커널을 만드는 일입니다. 각 층이 그 문제의 어느 부분을 잘라 가져갔는지, 왜 층이 이렇게 많아졌는지, 그리고 엔지니어가 어떤 상황에서 어느 층까지 내
2026-08-02 · 39 분 읽기 #gpu#compiler#mlir#triton#pytorchRay 2.56의 레이블 로컬리티 스케줄링 — 배치 그룹이 노드가 아니라 NVLink 랙을 보기 시작했다
2026년 6월 29일 나온 Ray 2.56.0은 배치 그룹에 도메인 레벨 스케줄링 레이어를 알파로 추가했습니다. 지금까지 PACK·STRICTPACK 같은 배치 전략은 전부 노드 단위로만 동작해서, GB200·GB300 NVL72처럼 NVLink 도메인이 노드 여러 개에 걸치는 랙에서는 "이 배치 그룹을 한 랙 안에 다 넣어 달라"를 표현할 방법이 없었습니다. 새 레이블 로컬리티 스케줄링은
2026-07-17 · 21 분 읽기 #ray#gpu#scheduling#distributed-systems로컬에서 LLM 돌리려면 VRAM이 얼마나 필요한가 — 표 말고 공식으로 계산하기
"8B 모델에 몇 GB 필요한가요"의 정답은 표가 아니라 두 개의 공식입니다. 가중치는 파라미터 수 곱하기 bpw 나누기 8이고, KV 캐시는 2 곱하기 레이어 수 곱하기 KV 헤드 수 곱하기 headdim 곱하기 바이트 수 곱하기 토큰 수입니다. 이 글은 두 공식을 llama.cpp 소스와 공식 표에 직접 대조해 검증합니다 — ggml 블록 구조체에서 유도한 Q80의 8.5 bpw는 lla
2026-07-17 · 43 분 읽기 #llm#quantization#kv-cache#local-llm#gpuTriton Gluon — 컴파일러가 숨기던 레이아웃을 손으로 쓰는 언어
Gluon은 Triton과 같은 컴파일러 스택 위에 올라간 하위 레벨 GPU 언어로, Triton이 감춰 두던 레이아웃·공유 메모리·워프 특수화를 커널 작성자에게 그대로 넘깁니다. 존재 이유는 명확합니다 — Triton 컴파일러가 잘 못 뽑는 코드를 만났을 때, 지금까지는 손쓸 방법이 없었기 때문입니다. 이 글은 Gluon이 무엇을 노출하는지, BlockedLayout이 실제로 무엇을 뜻하는
2026-07-16 · 33 분 읽기 #gpu#triton#kernel#compiler#performanceRust 1.97이 Volta 이전 GPU를 잘라냈다 — nvptx64 베이스라인 상향의 내막
Rust 1.97(2026년 7월 9일)은 nvptx64-nvidia-cuda 타깃의 최소 사양을 PTX ISA 7.0(CUDA 11 드라이버 이상)과 SM 7.0(Volta 이상)으로 올렸습니다. Maxwell·Pascal 세대 GPU와 CUDA 10 이하 드라이버는 이제 대상이 아닙니다. 이 글은 실제로 바뀐 숫자, 컴파일러 팀이 근거로 든 세 개의 구체적인 결함(디버그 심볼·아토믹 순서
2026-07-16 · 21 분 읽기 #rust#cuda#gpu#compiler#nvidiaRTX 5090 한 장으로 작은 모델들 직접 굴려보기 — microGPT·OCR·음악 생성
RTX 5090(Blackwell, 32GB) 한 장에 SSH로 붙어 작은 모델 셋을 직접 돌려봤습니다. char-level GPT를 밑바닥부터 28초 만에 학습시키고(10.75M 파라미터, 117만 tokens/s), 전용 OCR(TrOCR)과 소형 VLM(Qwen2-VL-2B)을 같은 이미지에 붙여 CER로 대결시키고, MusicGen으로 8초짜리 음악을 1.9초(4.2배 실시간)에 생성
2026-07-11 · 12 분 읽기 #pytorch#gpu#llm#ocr#hands-on확산 LLM이 CUDA 커널을 쓴다 — DICE와 왜 병렬 생성이 도움이 되는가
DICE는 2026년 2월 프리프린트로, 확산(diffusion) 대규모 언어 모델이 CUDA 커널 생성에서 같은 규모의 자기회귀(autoregressive) 모델을 능가하고 새로운 최고 성능(SOTA)을 세웠다고 주장합니다. 핵심 아이디어는 토큰을 왼쪽에서 오른쪽으로 하나씩 쓰는 대신, 전체 시퀀스를 병렬로 생성하고 어느 위치든 비순차적으로 고쳐 쓸 수 있다는 것 — 전역 구조가 중요한 코
2026-07-11 · 12 분 읽기 #ai#llm#diffusion#cuda#gpu