SERIES

AI 서빙 인프라: GPU부터 문서 파싱까지

11 POSTS

01
system
Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유
PyTorch를 pip install로 깔았는데 시스템에 CUDA Toolkit을 따로 안 깔아도 GPU가 돌았다. 그러다 nvidia-smi는 CUDA 12.2라고 하고, nvcc --version은 아예 명령이 없다고 하고, python -c "import torch; print(torch.version.cuda)"는 12.6이라고 한다. 같은 머신에서...
02
system
GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지
GPU로 모델을 추론하는 문서 파싱 서비스의 컨테이너 이미지가 압축 기준 10GB, 디스크에 풀면 30GB까지 부푼 걸 마주했다. 줄여보려고 들여다보다가, 정작 내가 GPU 컨테이너의 버전 체계를 제대로 모른다는 걸 알았다. nvidia-smi가 찍어주는 두 개의 버전 숫자가 무슨 뜻인지, 왜 컨테이너 안 CUDA를 마음대로 못 올리는지부터 막혔다. 이 글...
03
system
GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림
자바로 백엔드만 짤 때는 컴퓨팅 자원이 단순했다. CPU 코어 수, JVM heap (-Xmx), 시스템 RAM. 워크로드가 커지면 인스턴스를 늘리거나 스레드를 늘리는 게 답이었다. ML 서비스를 다루기 시작하면 그림이 한 층 더 생긴다. GPU 라는 별도 컴퓨팅 장치, 그 안의 VRAM 이라는 별도 메모리, 그리고 그것들을 다루는 CUDA·cuDNN·MP...
04
system
한 GPU 를 여러 프로세스가 나눠 쓰기 — Time-Slicing 과 MPS
GPU·CUDA·MPS 기초 에서 MPS 라는 약어가 NVIDIA 와 Apple 두 가지를 가리킨다는 것까지 정리했다. 그 글 끝에 "multi-process GPU 패턴은 다음 글에서" 라고 미뤄둔 부분을 이어 쓴다. 질문은 단순하다. GPU 는 한 장인데, 그 위에서 추론하는 프로세스가 여러 개면 GPU 를 어떻게 나눠 쓰는가. 여러 워커 프로세스가 각...
05
system
Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이
자바 백엔드에서 ThreadPoolExecutor 는 거의 만능이었다. CPU bound 든 I/O bound 든 스레드 풀 크기만 잘 잡으면 동시성을 챙길 수 있었다. JVM 안에서 메모리를 공유하니 작업 간 데이터 전달도 가볍다. Python ML 서비스는 그림이 다르다. ThreadPoolExecutor 가 있지만 CPU/GPU 작업에서는 거의 안 쓰...
06
system
Kubernetes GPU 노드에서 /run tmpfs가 꽉 차서 Pod가 안 뜰 때
NHN Cloud OCR 리얼 배포 중 ArgoCD sync가 Degraded로 떨어졌다. pod sandbox 생성 단계에서 no space left on device 에러가 반복 발생했고, 원인은 GPU 노드의 /run tmpfs 포화였다. 루트 디스크는 16%밖에 안 쓰고 있는데 pod가 안 뜨는 상황이라 처음엔 혼란스러웠다. 이 글에서는 /run t...
07
system
OCR 동작 원리 — Layout · Text · Post-process 3단계
자바 백엔드만 다뤄오다가 OCR (Optical Character Recognition) 서비스를 분석할 일이 생겼다. "이미지에서 글자를 뽑는다" 라는 한 줄 요약은 알았지만, 실제 코드를 열어보면 모델이 둘이상이고, 여러 단계가 직렬·병렬로 엮여 있고, "왜 이 단계가 따로 있지" 같은 의문이 계속 생긴다. 이 글은 OCR 파이프라인의 표준 구조를 정리...
08
ai
Docling — IBM Research 의 문서 파싱 toolkit 상세 정리
문서를 RAG·LLM 컨텍스트로 넣으려면 PDF·PPTX·HTML 같은 입력을 깨끗한 텍스트 (또는 markdown / JSON) 으로 변환해야 한다. 이걸 "쉽게" 해주는 라이브러리는 의외로 많지 않다. 표가 있는 PDF, 스캔본, 다단 레이아웃, 페이지 안의 그림과 캡션 같은 변형이 많기 때문. Docling 은 IBM Research (Zurich)...
09
ai
STORM Parse
- Sionic AI의 Intelligent Document Parser - https://www.sionic.ai/ko/parse - 단순히 문서에서 텍스트를 추출하는 것을 넘어서, 문서의 구조와 의미를 이해하고 이를 AI가 효과적으로 활용할 수 있는 형태로 변환하는 것이 핵심목표이다. - 다양한 포맷과 대용량 문서 학습 지원 - PDF, DOCX, XL...
10
ai
멀티모달 LLM (Multimodal Large Language Model)
- 여러 종류의 입력을 동시에 이해하고 처리할 수 있는 LLM - 즉, 기존 LLM이 텍스트만 이해했다면, 멀티모달 LLM은 다음을 모두 처리할 수 있다 - 텍스트 - 이미지 - 음성 - 비디오 - 코드 이미지와 텍스트를 함께 다루는 모델을 특히 VLM(Vision-Language Model)이라고 부른다. 요즘 쓰는 GPT-4o, Claude, Gemin...
11
system
ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점
이 시리즈의 마무리 글이다. 앞선 글들에서 다음 주제를 자바 백엔드 비교 관점으로 정리했다. - Python 문법 - 의존성 관리 - FastAPI - async/await - GPU·CUDA·MPS - PyTorch - multi-process worker pool - OCR 파이프라인 마지막은 이 모든 개념을 적용해 실제 ML 서비스의 성능을 분석하는...

AI 서빙 인프라: GPU부터 문서 파싱까지

Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유

GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지

GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림

한 GPU 를 여러 프로세스가 나눠 쓰기 — Time-Slicing 과 MPS

Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이

Kubernetes GPU 노드에서 /run tmpfs가 꽉 차서 Pod가 안 뜰 때

OCR 동작 원리 — Layout · Text · Post-process 3단계

Docling — IBM Research 의 문서 파싱 toolkit 상세 정리

STORM Parse

멀티모달 LLM (Multimodal Large Language Model)

ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점

AI 서빙 인프라: GPU부터 문서 파싱까지

Python CUDA 버전 생태계 — nvidia-smi, nvcc, pip, conda가 다 다른 버전을 말하는 이유

GPU 컨테이너의 CUDA 버전 호환성 — nvidia-smi부터 이미지 다이어트까지

GPU·CUDA·MPS 기초 — 자바 백엔드 개발자가 처음 만나는 그림

한 GPU 를 여러 프로세스가 나눠 쓰기 — Time-Slicing 과 MPS

Multi-process GPU 워크로드 — 자바 ThreadPool 사용자가 만나는 모델 차이

Kubernetes GPU 노드에서 /run tmpfs가 꽉 차서 Pod가 안 뜰 때

OCR 동작 원리 — Layout · Text · Post-process 3단계

Docling — IBM Research 의 문서 파싱 toolkit 상세 정리

STORM Parse

멀티모달 LLM (Multimodal Large Language Model)

ML 서비스 성능 분석 워크플로 — 자바 백엔드 트러블슈팅과 다른 점