나만의 LLM 서버 구축해보기
목차
- 개요 — 작고 귀여운 AI 연구소 차려보기
- 하드웨어: 뭘 살까 (What to Buy)
- 이 장비로 뭘 할 수 있나 (What to Do)
- 소프트웨어 아키텍처 (How to Implement)
- MLOps: 이걸 어떻게 굴릴까
- 연구원에게 주피터 노트북 쥐여주기 (JupyterHub)
- 실전 운영 시나리오: GPU 4장을 학습/추론으로 쪼개 쓰기
- 소프트웨어 스택 한방 정리
1. 개요 — 작고 귀여운 AI 연구소 차려보기
가끔은.. 내가 정말 돈이 남아도는 부자가 되면 뭐 하지..? 라는 생각을 한다. 오늘은 시간적·금전적 자원이 적당히..? 합리적으로..? 남아돈다고 가정하고, 나만의 작고 귀여운 AI 연구소 인프라를 계획해본다.
이번 글의 타겟은 "1억 원 예산으로 구축하는 엔터프라이즈급 개인 AI 서버" 다. 한 줄로 요약하면 이렇다.
192GB VRAM을 기반으로 70B급 최상위 LLM을 원본(FP16) 그대로 추론·파인튜닝하고, 쿠버네티스(K8s)와 예약 스케줄러로 OOM 없이 안정적으로 굴리는 MLOps 인프라.
글의 흐름은 이렇게 잡았다.
- 뭘 살지(하드웨어) → 뭘 할 수 있는지(가능 범위) → 어떻게 구현할지(소프트웨어 아키텍처) 를 먼저 정리하고,
- 그다음 어떻게 운영할지(MLOps · 주피터 제공 · GPU 배분 시나리오) 를 파고든 뒤,
- 마지막에 소프트웨어 스택을 한 방에 정리한다.
2. 하드웨어: 뭘 살까 (What to Buy)
핵심 전략은 하나다. 고가의 인피니밴드(InfiniBand) 네트워크 장비 대신, 단일 노드 안에 GPU를 고밀도로 몰아넣고 일반 고속 이더넷을 쓴다. 가성비와 운영 편의성을 동시에 잡는 구성이다. (개인 연구소에 노드 간 InfiniBand 패브릭까지 깔면 그건 이미 작고 귀여운 게 아니다.)
| 분류 | 핵심 품목 및 스펙 | 비고 |
|---|---|---|
| GPU | NVIDIA RTX 6000 Ada 48GB × 4장 (총 192GB VRAM) | 70B급 모델 FP16 무손실 구동의 핵심 |
| 호스트 | AMD EPYC 또는 Threadripper Pro + 256GB RAM | PCIe 5.0 레인 확보 및 병목 방지 |
| 전력·랙 | 2000W~3000W 리던던트 파워 + 4U 랙마운트 케이스 | 상시 운용 안정성 확보 |
| 네트워크 | 10GbE / 25GbE SFP+ 스위치 및 NIC | 노드 간 스케일아웃 및 대용량 데이터 전송 |
참고로 RTX 6000 Ada는 데이터센터 GPU(A100/H100)와 달리 MIG(Multi-Instance GPU)를 지원하지 않는다. GPU 한 장을 하드웨어적으로 쪼갤 수는 없고, 배분은 "장 단위" 로 한다는 점을 기억해두자. (7번 시나리오에서 이게 핵심 제약이 된다.)
3. 이 장비로 뭘 할 수 있나 (What to Do)
192GB VRAM 환경은 최신 70B급 오픈소스 모델을 압축(양자화) 없이 원본 정밀도로 구동할 수 있는 최적의 스펙이다. 이 절에서는 GPU 여러 장의 의미부터 우리 장비의 현실 가능 범위까지 핵심만 정리한다.
3-1. GPU 여러 장 = VRAM 합산? (흔한 오해)
RTX 6000 Ada 48GB를 한 보드에 ×4로 꽂는다고 192GB GPU 한 장이 되는 건 아니다. 어디까지나 48GB GPU ×4다. 대신 AI 프레임워크(PyTorch, DeepSpeed, FSDP 등)가 아래처럼 일을 나눠서
- 모델을 분산 (Model Parallelism)
- 데이터를 분산 (Data Parallelism)
- 계산을 분산 (Tensor / Pipeline Parallelism)
총 192GB의 VRAM을 협력해서 쓰게 만든다. "합쳐진 것처럼 쓴다"가 정확한 표현이다.
3-2. 그래서 왜 여러 장을 쓸까
- 더 큰 모델 실행
- 더 빠른 학습
- 더 큰 Batch Size
- 더 많은 동시 추론
- 여러 연구를 동시에 수행
3-3. GPU 한 장 기준, 2026년엔 어디까지 돌아갈까
모델을 있는 그대로(FP16) 다운받아 돌린다면 대략 이렇다.
| 모델 | FP16 필요 VRAM | RTX 4090 (24GB) |
|---|---|---|
| 7B | 약 14GB | ✅ |
| 13B | 약 26GB | △ |
| 32B | 약 64GB | ❌ |
| 70B | 약 140GB | ❌ |
곧 죽어도 70B가 필요하다면, 4bit 양자화로 약 35~45GB까지 줄이면 RTX 6000 Ada(48GB) 한 장으로도 Llama 70B 추론은 된다.
- 근데 정말 "되기만" 하는 거지 원활한 건 아니다. 정신 건강을 위해서는 한 장에선
32B를 돌리는 게 맞을 것 같다.
3-4. 모델을 "건드리는" 작업별 리소스 분석
같은 "AI를 다룬다"도 프롬프트만 쓰는 것과 모델을 처음부터 만드는 것은 리소스가 수백만 배 차이 난다. 자동차에 비유하면 이렇다.
| 작업 | 모델 변화 | 학습 대상 | 리소스 지수 | 최소 하드웨어 | 주체 | 자동차 비유 |
|---|---|---|---|---|---|---|
| Prompt Engineering | 없음 | 없음 | 0.01 | CPU | 누구나 | 운전만 함 |
| RAG | 없음 | 없음 | 0.05 | CPU | 대부분 기업 | 네비게이션 추가 |
| Inference | 없음 | 없음 | 0.1 | RTX 3060~4090 | 누구나 | 운행 |
| Quantization | 모델 압축 | 없음 | 0.5 | RTX 4090 | 개인 | 경량화 |
| QLoRA | Adapter | 0.01~1% | 3 | RTX 3090~4090 | 개인 | ECU 맵핑 |
| LoRA | Adapter | 0.01~1% | 5 | RTX 4090~6000 | 개인·연구실 | 튜닝 파츠 교체 |
| PEFT Fine-tuning | 일부 Layer | 1~10% | 20 | GPU 2~4장 | 연구실 | 엔진 일부 튜닝 |
| Full Fine-tuning | 전체 | 100% | 300 | H100 × 8 이상 | 기업 | 엔진 전체 오버홀 |
| Continued Pretraining | 전체 | 100% | 1,000 | H100 수십 장 | 기업·연구실 | 기존 차로 신차 개발 |
| Domain Pretraining | 전체 | 100% | 3,000 | H100 수십~수백 장 | 대기업 | 플랫폼 재설계 |
| Foundation Model | 처음부터 | 100% | 100,000 | H100 수백~수천 장 | OpenAI·Meta | 철광석부터 자동차 제작 |
| GPT-4급 Foundation | 처음부터 | 100% | 10,000,000+ | H100/B200 수천~수만 장 | 극소수 기업 | 자동차 산업 자체 구축 |
체감 비용/인력은 이렇다.
| 작업 | GPU 규모 | 개발 인력 | 인프라 비용(대략) |
|---|---|---|---|
| Prompt / RAG | 없음 | 1명 | 거의 없음 |
| LoRA | RTX 4090 1장 | 1~2명 | 수십~수백만 원 |
| Fine-tuning | GPU 2~8장 | 2~5명 | 수천만 원 |
| Continued Pretraining | GPU 수십 장 | 5~20명 | 수억~수십억 원 |
| Foundation Model | GPU 수백~수천 장 | 수십~수백 명 | 수백억 원 |
| GPT-4급 | GPU 수천~수만 장 | 수백~천 명 이상 | 수천억~조 단위 추정 |
※ 비용은 GPU 임대/구매와 대규모 학습 인프라를 포함한 매우 거친 업계 체감치이며, 회사 규모·학습 기간에 따라 크게 달라진다.
3-5. 우리 장비의 현실 가능 범위
① 모델 제작 (Pretraining)
| 규모 | 가능 여부 |
|---|---|
| 100M ~ 1B | ✅ 매우 적합 |
| 1B ~ 3B | ✅ 가능 |
| 3B ~ 7B | △ 연구 목적 가능 (시간 오래 걸림) |
| 7B ~ 13B | ⚠️ 현실적으로 매우 어려움 |
| 13B 이상 | ❌ 사실상 불가능 |
| 70B Foundation | ❌ |
② 모델 튜닝 (Fine-tuning)
| 작업 | 가능 여부 |
|---|---|
| LoRA (7B~70B) | ✅ 매우 적합 |
| QLoRA (7B~70B) | ✅ 매우 적합 |
| PEFT (7B~32B) | ✅ |
| Full Fine-tuning (7B) | △ |
| Full Fine-tuning (13B) | ⚠️ |
| Full Fine-tuning (70B) | ❌ (192GB로는 불가 — 옵티마이저 상태까지 하면 560GB+ 필요) |
③ 추론 (Inference)
| 모델 | 가능 여부 |
|---|---|
| 7B | ✅ |
| 13B | ✅ |
| 32B | ✅ |
| 70B (4bit) | ✅ |
| 70B (FP16) | ✅ (멀티 GPU 분산, TP=4) |
| 100B~150B | △ (FP8 양자화 시) |
| 405B | ❌ |
3-6. 핵심 한 줄 요약 & 할 수 있는 것 / 없는 것
| 분야 | RTX 6000 Ada × 4 |
|---|---|
| 추론 | 70B까지 충분히 가능 |
| LoRA / QLoRA | 매우 적합 |
| Fine-tuning | 7B~32B급까지 현실적 |
| Continued Pretraining | 1B~7B 연구용 가능 |
| Foundation Model 개발 | 사실상 어려움 |
- 할 수 있는 것
- ✅ 대부분의 오픈소스 LLM 추론
- ✅ LoRA / QLoRA
- ✅ 중소형 모델 사전학습 연구
- ✅ 새로운 Transformer 구조 연구
- ✅ AI 논문 재현
- ✅ 멀티 GPU 분산 학습 연구
- 불가능한 것
- ❌ GPT-4급 모델 개발
- ❌ 70B 신규 Foundation Model 개발
- ❌ 수백B급 모델 학습
즉, RTX 6000 Ada × 4는 '최신 오픈소스 모델을 활용하고 개선하는 연구'에는 매우 적합하지만, '세계 최고 수준의 초거대 모델을 처음부터 만드는 단계'까지는 도달하지 못하는 워크스테이션급 장비라고 이해하면 된다.
이 장비로 실제로 돌려볼 만한 대표 모델은 이 정도다.
- 70B~72B급 (FP16 원본 구동 & 파인튜닝)
- Qwen2.5-Coder-72B (한국어 특화 및 코딩 에이전트)
- Llama 3.3 70B Instruct (글로벌 표준 벤치마크 및 범용 AI)
- DeepSeek-R1-Distill-70B (고난도 수학·수식 추론)
- Qwen2.5-VL-72B (논문 PDF·차트·이미지 멀티모달 분석)
- 100B+급 대형 모델
- Mistral Large 2 (123B) 등을 FP8 양자화로 탑재해 GPT-4o급 성능 활용
4. 소프트웨어 아키텍처 (How to Implement)
개발자 원격 접속, 사내 서비스, 파인튜닝 작업 사이의 자원 경합(OOM)을 자동으로 제어하는 계층형 레이어 구조로 설계한다. 위로 갈수록 사람이 만지는 영역, 아래로 갈수록 인프라 영역이다.
[ Layer 5: 사용자 접점 (Interfaces) ]
├─ Open WebUI (논문/PDF 기반 RAG 분석 — NotebookLM 대체)
├─ JupyterHub on K8s (연구원별 GPU 동적 할당 파이썬 환경)
└─ LLaMA-Factory (웹 GUI 파인튜닝) / Continue.dev (IDE 연동)
[ Layer 4: MLOps & 자원 예약 (Gateway & Scheduler) ]
├─ LiteLLM Gateway (API 키 관리, Rate Limit, 사용자별 사용량 제어)
└─ Kueue / KEDA (타임슬롯 예약 스케줄링 ➔ 학습 시 vLLM 자동 스케일다운으로 OOM 방지)
[ Layer 3: 고성능 추론 엔진 (Inference Engine) ]
└─ vLLM (Tensor Parallelism=4 옵션으로 4개 GPU 병렬 처리)
[ Layer 2: 오케스트레이션 및 보안 (K8s & Security) ]
├─ Kubernetes (k3s 또는 RKE2) + NVIDIA GPU Operator
└─ Tailscale Mesh VPN / Cloudflare Tunnel (외부 IP 노출 없는 안전한 원격 접속)
[ Layer 1: 기본 환경 (Base OS) ]
└─ Ubuntu Server LTS + NVIDIA Driver + Container Toolkit이 구조의 핵심은 Layer 4의 스케줄러다. 추론(항상 떠 있어야 함)과 학습(무겁고 GPU를 다 먹음)이 같은 4장을 두고 싸우지 않도록, 자원을 시간·우선순위 기준으로 자동 배분한다. 이 배분 로직을 실제로 어떻게 굴리는지가 5~7절의 주제다.
5. MLOps: 이걸 어떻게 굴릴까
장비만 좋다고 연구소가 굴러가진 않는다. "누가 언제 무슨 데이터로 어떤 모델을 학습해서 어떤 성능이 나왔고, 그게 지금 어디에 배포돼 있는지" 를 추적할 수 없으면, 한 달만 지나도 final_final_v3_진짜최종.pt 지옥이 열린다. 그래서 MLOps 파이프라인을 K8s 위에 얹는다.
5-1. 파이프라인 전체 흐름
[데이터] → [실험] → [학습 파이프라인] → [모델 레지스트리] → [배포] → [모니터링] → (재학습 트리거)
MinIO/DVC Jupyter Argo/Kubeflow MLflow vLLM Grafana
+MLflow Registry /KServe +DCGM- 데이터 준비: 데이터셋과 체크포인트는 MinIO(S3 호환 오브젝트 스토리지)에 저장하고, DVC로 버전을 건다. "이 모델은 어떤 데이터 스냅샷으로 학습했나"가 커밋 해시로 남는다.
- 실험: 연구원은 JupyterHub 노트북에서 돌리고, 모든 하이퍼파라미터·메트릭·아티팩트를 MLflow Tracking에 자동 로깅한다.
- 학습 파이프라인: 실험이 익으면 노트북 코드를 Argo Workflows / Kubeflow Pipelines 잡으로 승격시킨다. 전처리 → 학습 → 평가 → 등록이 하나의 DAG로 재현 가능하게 돌아간다.
- 모델 레지스트리: 학습이 끝난 모델은 MLflow Model Registry에
Staging → Production단계로 등록한다. - 배포: Production 승격된 모델을 vLLM(또는 KServe)이 서빙한다. GitOps(ArgoCD)로 "레지스트리에 올라온 태그 = 클러스터에 뜬 버전"을 일치시킨다.
- 모니터링: GPU 사용률·온도·전력은 DCGM Exporter → Prometheus → Grafana로, 로그는 Loki로 본다.
5-2. MLOps 소프트웨어 스택
| 역할 | 소프트웨어 | 한 줄 설명 |
|---|---|---|
| 실험 추적 | MLflow Tracking / (선택) W&B | 하이퍼파라미터·메트릭·아티팩트 기록 |
| 데이터·모델 버저닝 | DVC + MinIO | 데이터/체크포인트를 Git처럼 버전 관리 |
| 파이프라인 오케스트레이션 | Argo Workflows / Kubeflow Pipelines | 학습 DAG를 재현 가능하게 실행 |
| 모델 레지스트리 | MLflow Model Registry | 모델 버전·스테이지 관리 |
| 배포 (GitOps) | ArgoCD | 선언형 배포, 롤백 용이 |
| 서빙 | vLLM / (선택) KServe | 고성능 추론 서빙 |
| 관측성 | Prometheus + Grafana + DCGM Exporter + Loki | GPU 메트릭·로그 통합 모니터링 |
개인 연구소 규모에선 처음부터 Kubeflow 풀스택을 다 깔 필요는 없다. MLflow + Argo Workflows + MinIO 세 개만 있어도 "추적 · 파이프라인 · 저장"의 뼈대는 선다. 규모가 커지면 Kubeflow로 확장하는 게 현실적이다.
6. 연구원에게 주피터 노트북 쥐여주기 (JupyterHub)
연구원마다 노트북 환경을 따로 세팅해주다 보면 하루가 다 간다. 그래서 JupyterHub on Kubernetes (Zero to JupyterHub, z2jh) 로 "접속하면 GPU 붙은 노트북이 자동으로 뜨는" 환경을 만든다.
6-1. 동작 방식
연구원 접속 → 로그인(OAuth) → 프로파일 선택 → KubeSpawner가 개인 Pod 스폰 → GPU 붙은 노트북 → 작업 종료/유휴 → 자동 반납- 격리된 개인 서버: 연구원 한 명당 독립된 single-user 노트북 Pod가 뜬다. 남의 커널이 내 메모리를 잡아먹는 일이 없다.
- 프로파일로 GPU 동적 선택: 로그인 후 사양을 고른다. KubeSpawner의
profile_list로 구현한다.CPU only— 데이터 전처리·EDA용 (GPU 0장)GPU 1장— 가벼운 추론·QLoRA 실험GPU 2장— 본격 파인튜닝- 내부적으로
extra_resource_limits: {"nvidia.com/gpu": "2"}같은 설정이 붙는다.
- 커스텀 이미지: CUDA + PyTorch + vLLM 클라이언트 + 사내 라이브러리 + MLflow SDK를 미리 구운 도커 이미지를 쓴다. "환경 안 맞아서 안 돌아요" 를 원천 차단한다.
- 스토리지: 개인 홈 디렉토리는 각자 PVC로 영속화하고, 공유 데이터셋은 MinIO/NFS를 읽기 전용으로 마운트한다.
- 인증: GitHub/Google OAuth로 SSO. 접근 자체는 Tailscale VPN 안쪽에서만 가능하게 막는다.
- ⭐ 유휴 GPU 자동 회수 (핵심!):
jupyterhub-idle-culler로 일정 시간 놀고 있는 노트북 Pod를 자동 종료한다. GPU를 붙잡은 채 점심 먹으러 간 연구원 때문에 남들이 GPU를 못 쓰는 사태를 막는다. 개인 연구소에서 GPU 낭비는 곧 돈 낭비다.
6-2. JupyterHub 스택
| 역할 | 소프트웨어 |
|---|---|
| 허브 & 스포너 | JupyterHub + KubeSpawner (z2jh Helm 차트) |
| 노트북 이미지 | 커스텀 CUDA/PyTorch 이미지 |
| 인증 | OAuthenticator (GitHub/Google) |
| 스토리지 | PVC (개인) + MinIO/NFS (공유 데이터셋) |
| 유휴 회수 | jupyterhub-idle-culler |
7. 실전 운영 시나리오: GPU 4장을 학습/추론으로 쪼개 쓰기
여기가 이 글의 하이라이트다. GPU는 4장뿐인데, 하고 싶은 건 세 가지다.
- 평소엔 추론 서비스도 띄우면서 학습도 하고 싶고,
- 큰 파인튜닝 돌릴 땐 4장 다 학습에 몰아넣고 싶고,
- 데모 날엔 4장 다 추론에 투입해서 70B FP16을 시원하게 서빙하고 싶다.
앞서 말했듯 RTX 6000 Ada는 MIG가 없으니 GPU를 하드웨어로 쪼갤 순 없다. 그래서 "장 단위 배분 + 우선순위 + 선점(preemption)" 조합으로 소프트웨어에서 유동적으로 나눈다. 세 가지 상태를 왔다 갔다 하는 그림이다.
시나리오 A — 평시: 추론 2장 + 학습 2장
일상적인 상태. 사내 서비스와 코딩 어시스턴트는 항상 살아 있어야 하니 추론에 2장을 상시 배정한다.
| 용도 | GPU | 구성 |
|---|---|---|
| 추론 (vLLM) | 2장 | TP=2로 32B FP16 또는 70B 4bit 서빙 |
| 학습/실험 | 2장 | LoRA/QLoRA, PEFT, 노트북 실험 |
시나리오 B — 집중 학습: 4장 몰빵
70B QLoRA나 4-GPU FSDP 같은 무거운 작업을 돌릴 때. 추론 서비스를 최소로 축소(scale-down) 하고 확보된 4장 전체를 학습 Pod에 몰아준다.
| 용도 | GPU | 구성 |
|---|---|---|
| 추론 (vLLM) | 0~1장 | 최소 유지 or 완전 중단 |
| 학습 | 3~4장 | 4-GPU FSDP / 70B QLoRA 풀 배치 |
시나리오 C — 데모 데이: 추론에 4장 투입
시연 당일. 70B FP16을 최고 성능으로 보여줘야 하니 학습을 전부 선점·중단시키고 4장을 추론에 몰아넣는다.
| 용도 | GPU | 구성 |
|---|---|---|
| 추론 (vLLM) | 4장 | TP=4로 70B FP16 풀로드, 최대 처리량 |
| 학습 | 0장 | 전부 suspend / preempt (데모 끝나면 자동 재개) |
이걸 자동으로: K8s 스케줄링 메커니즘
세 상태를 사람이 kubectl로 손수 바꾸면 실수하기 딱 좋다. 엔터프라이즈급으로 자동화하는 스택은 이렇게 조합한다.
① 우선순위 클래스 (PriorityClass) — "누가 양보하나"
demo-inference (최상위) ─ 데모/장애 대응. 뜨는 순간 아래를 밀어냄
serving (중간) ─ 평시 상시 추론
training (하위, 선점 가능) ─ 학습 잡. 위가 GPU 필요하면 양보학습 잡을 preemptible로 두면, 상위 워크로드가 GPU를 요구할 때 K8s가 학습 Pod를 자동으로 밀어낸다.
② Kueue — "4장짜리 GPU 풀을 큐로 나눠 쓰기"
serving-queue와training-queue를 하나의 Cohort로 묶고, 4 GPU를 공유 자원으로 등록한다.- 평시엔 각 큐에 명목 할당(nominalQuota)을 2장씩 주되, borrowing을 허용한다. → 추론이 놀면 학습이 2장을 빌려 4장으로 돌리고(시나리오 B), 데모가 시작되면 추론이 빌려준 걸 회수 + 선점한다(시나리오 C).
- 학습은 항상 Kueue Workload로 제출한다. GPU가 없으면 즉시 죽는 게 아니라
pending으로 얌전히 대기하다가 자리가 나면 admission 된다. → OOM 대신 큐잉.
③ KEDA — "추론 수요에 맞춰 자동 스케일"
- vLLM replica를 요청 큐 길이/QPS 기반으로 오토스케일한다. 새벽에 트래픽이 0이면 추론을 0장까지 내려서 학습에 자리를 내주고, 트래픽이 몰리면 다시 올린다.
④ 예약 스케줄링 — "데모는 미리 잡아둔다"
- 정기 데모 시간대는 CronJob(또는 Argo Events)으로 미리 vLLM을 TP=4로 scale-up + 학습 큐를 suspend 한다. 데모 창이 닫히면 원복.
정리하면, PriorityClass(양보 규칙) + Kueue(풀 공유·큐잉·선점) + KEDA(수요 기반 오토스케일) + Cron/Argo Events(예약) 네 가지가 물려서, A ↔ B ↔ C 상태 전환이 자동으로 일어난다. 사람은 "데모 잡아줘" 하고 캘린더에 등록만 하면 된다.
핵심 운용 Workflow 요약
- 상시 추론 (A): 평시엔 vLLM + LiteLLM으로 Open WebUI·IDE 어시스턴트에 자원을 쓴다.
- 예약 기반 학습 (B): 연구원이 타임슬롯을 예약하면 Kueue가 지정 시간에 vLLM 서빙을 scale-down하고 학습에 GPU를 몰아준다.
- 자원 전유 및 복구 (B→A / C→A): 확보한 GPU를 학습 Pod에 할당해 OOM 없이 완주한 뒤, 작업이 끝나면 vLLM 서빙을 자동 복구한다. 데모(C)가 끼면 최우선으로 추론에 4장을 붙였다가 끝나면 원복한다.
8. 소프트웨어 스택 한방 정리
앞에서 흩어져 나온 소프트웨어를 레이어별로 한 방에 정리하면 이렇다. 이 표가 곧 이 연구소의 설계도다.
| 레이어 | 역할 | 소프트웨어 |
|---|---|---|
| 기반 OS | 운영체제·드라이버 | Ubuntu Server LTS, NVIDIA Driver, NVIDIA Container Toolkit |
| 오케스트레이션 | 컨테이너·GPU 관리 | Kubernetes (k3s / RKE2), NVIDIA GPU Operator, DCGM |
| 네트워크·보안 | 안전한 원격 접속 | Tailscale Mesh VPN, Cloudflare Tunnel |
| 스토리지 | 데이터·체크포인트 | MinIO (S3 호환), NFS / Longhorn (PVC), DVC |
| 자원 스케줄링 | GPU 배분·예약·선점 | Kueue, KEDA, PriorityClass, CronJob / Argo Events |
| 추론 엔진 | 모델 서빙 | vLLM, (선택) KServe, LiteLLM Gateway |
| 학습·튜닝 | 파인튜닝·사전학습 | PyTorch, DeepSpeed / FSDP, LLaMA-Factory, Axolotl, TRL / PEFT |
| MLOps | 실험·파이프라인·배포 | MLflow (추적·레지스트리), DVC, Argo Workflows / Kubeflow Pipelines, ArgoCD |
| 관측성 | 모니터링·로깅 | Prometheus, Grafana, DCGM Exporter, Loki |
| 사용자 접점 | 개발·사용 환경 | JupyterHub (z2jh), Open WebUI, Continue.dev, (선택) code-server |
마무리. 결국 이 연구소의 정체성은 "H100 클러스터는 못 되지만, 최신 오픈소스 70B를 원본으로 다루고 개선하는 데는 부족함 없는, K8s로 잘 정돈된 1억 원짜리 작고 귀여운 워크스테이션 연구소" 만들기임
- 명심해야할껀 AI 가 돈먹는 하마고, 이렇게 구축해도 뭔가 학습한다, 배워본다는 의미를 제외하고 숫자적인 관점으로만 보면 파멸적인 재앙일 뿐이고 1억으로 가능성을 제외하면 아무런 부가가치 창출하지 못하고 금리4% 짜리 은행예금만도 못하다는 사실은 명심하고 만들자!