오픈소스 LLM 생태계

​

왜 오픈소스 LLM인가

1. 데이터 주권(Data Sovereignty): API 호출 시 데이터가 외부 서버로 전송됩니다. 금융, 의료, 정부 등 규제 산업에서는 이것만으로도 사용이 불가능할 수 있습니다.
2. 비용 예측 불가: 토큰 기반 종량제는 사용량 증가 시 비용이 기하급수적으로 증가합니다. 대량 배치 처리나 높은 트래픽에서 월 수만 달러의 API 비용이 발생할 수 있습니다.
3. 커스터마이징 한계: 상용 모델은 파인튜닝이 제한적이거나 불가능합니다. 특정 도메인(법률, 의학, 제조)에 최적화된 모델이 필요한 경우 오픈소스가 유일한 선택입니다.

​

실행 & 서빙 도구

​

주요 도구 비교

​

Ollama 상세

1. ollama pull llama3.2 — 모델 다운로드 (양자화된 GGUF 포맷)
2. ollama run llama3.2 — 모델 로드 + 대화형 인터페이스 시작
3. 내부적으로 llama.cpp 기반 추론 엔진 사용
4. http://localhost:11434 에서 OpenAI 호환 API 제공

• 설치 간편: macOS, Linux, Windows 모두 원클릭 설치. Apple Silicon Mac에서 Metal API를 통한 GPU 가속 자동 적용
• 모델 라이브러리: ollama.com/library에서 수백 개 모델 즉시 다운로드. 양자화 수준별 변형(Q4, Q5, Q8)을 태그로 선택
• Modelfile: Dockerfile처럼 커스텀 모델 구성 파일 작성. 시스템 프롬프트, 파라미터(temperature, top_p), 모델 어댑터(LoRA) 등을 정의
• OpenAI 호환 API: 기존 OpenAI SDK 코드를 base_url만 변경하여 로컬 모델로 전환. AI 코딩 어시스턴트(Continue, Cursor 등)의 로컬 모델 백엔드로 활용 가능

# Ollama 기본 사용법
ollama pull llama3.2        # 모델 다운로드
ollama run llama3.2         # 대화형 실행
ollama serve                # API 서버 모드

# Python에서 OpenAI SDK로 로컬 모델 호출
from openai import OpenAI
client = OpenAI(base_url="http://localhost:11434/v1", api_key="ollama")
response = client.chat.completions.create(
    model="llama3.2",
    messages=[{"role": "user", "content": "PySpark 윈도우 함수 예시"}]
)

• 프로덕션 서빙에는 부적합 (동시 요청 처리, 모니터링 부족)
• 대형 모델(70B+)은 고사양 하드웨어 필요
• 파인튜닝 기능 없음 (추론 전용)

​

vLLM 상세

1. KV Cache를 고정 크기의 블록(Page) 으로 분할 (기본 16토큰 단위)
2. 토큰이 생성될 때마다 필요한 블록만 동적으로 할당
3. 요청이 끝나면 블록을 즉시 반환하여 재활용
4. 블록이 물리적으로 비연속적이어도 논리적 테이블로 매핑 (OS의 페이지 테이블과 동일 원리)

• 최고 처리량: PagedAttention + Continuous Batching으로 업계 최고 수준. 동일 GPU에서 HuggingFace TGI 대비 2~3배 높은 throughput
• OpenAI 호환 API: python -m vllm.entrypoints.openai.api_server 한 줄로 OpenAI 호환 서버 시작. 기존 코드 변경 없이 전환
• 텐서 병렬화(Tensor Parallelism): 여러 GPU에 모델의 각 레이어를 분산하여 대형 모델(70B+) 서빙
• 양자화 지원: AWQ, GPTQ, FP8, BitsAndBytes 등 다양한 양자화 포맷으로 GPU 메모리 요구량 감소

• GPU 서버 운영 전문 지식 필요. CUDA 버전, 드라이버, PyTorch 호환성 관리가 복잡
• 모델 로딩 시간이 수 분 걸릴 수 있음 (콜드 스타트). 프로덕션에서는 모델을 미리 로드하는 warm pool 전략 필요
• 설정 최적화(배치 크기, 최대 시퀀스 길이, GPU 메모리 비율 등)에 경험이 필요하며, 잘못된 설정은 OOM(Out of Memory) 에러로 이어짐

​

Hugging Face 생태계

• Hub: 80만+ 모델, 15만+ 데이터셋 호스팅. 모델 카드로 성능/한계 문서화
• Transformers: 가장 널리 사용되는 ML 라이브러리. from_pretrained()로 어떤 모델이든 로드
• TGI (Text Generation Inference): 프로덕션 서빙 엔진. vLLM의 대안
• Spaces: 데모 앱 호스팅 (Gradio, Streamlit 기반)
• PEFT: LoRA 등 효율적 파인튜닝 라이브러리

​

LM Studio 상세

• 데스크톱 앱: macOS, Windows, Linux에서 설치 후 바로 사용
• 모델 탐색: Hugging Face에서 호환 모델을 검색/다운로드
• 채팅 UI: ChatGPT와 유사한 인터페이스에서 로컬 모델과 대화
• 로컬 서버: OpenAI 호환 API를 로컬에서 제공

• CLI/자동화에는 Ollama가 더 적합
• 기업 환경 배포에는 부적합

​

주요 오픈소스 모델 비교

참고 모델 선택 시 파라미터 수만 보지 말고 활성 파라미터 수 를 확인하세요. Llama 4 Maverick은 400B 모델이지만 활성 파라미터는 17B로, 실제 추론 비용은 17B 모델과 유사합니다.

​

Databricks에서 오픈소스 LLM 활용

​

Model Serving으로 배포

1. Foundation Model APIs: Databricks가 사전 배포한 오픈소스 모델(Llama, Mistral, DBRX 등) 즉시 사용
2. Provisioned Throughput: 전용 GPU에 모델을 배포하여 일관된 성능 보장
3. 커스텀 모델 배포: 파인튜닝한 모델을 MLflow로 패키징하여 배포

import mlflow

# 파인튜닝된 모델을 MLflow에 로깅
with mlflow.start_run():
    mlflow.transformers.log_model(
        transformers_model=fine_tuned_model,
        artifact_path="model",
        registered_model_name="my-custom-llama"
    )

# Unity Catalog에 등록된 모델을 Model Serving으로 배포
# Databricks UI 또는 API로 서빙 엔드포인트 생성

​

파인튜닝

• UI에서 몇 번의 클릭으로 파인튜닝 실행
• 학습 데이터를 Delta 테이블에서 직접 로드
• LoRA/QLoRA 기반 효율적 파인튜닝

• Databricks 클러스터에서 직접 학습 코드 실행
• Hugging Face Transformers + PEFT 라이브러리 활용
• MLflow로 실험 추적 및 모델 관리

​

거버넌스

• 모델 레지스트리: 모델 버전 관리, 스테이징/프로덕션 승격
• 접근 제어: 누가 어떤 모델을 사용할 수 있는지 세밀한 권한 관리
• 리니지 추적: 모델이 어떤 데이터로 학습되었는지, 어디서 사용되는지 추적
• Inference Table: 모든 추론 요청/응답을 자동 로깅하여 모니터링과 디버깅에 활용

주의 오픈소스 모델의 라이선스 를 반드시 확인하세요. Llama 4는 Meta의 커뮤니티 라이선스로 상업적 사용은 허용되지만 월 7억 활성 사용자 이상일 경우 별도 라이선스가 필요합니다. Apache 2.0(Mistral, Qwen)은 제한 없이 사용 가능합니다. MIT(DeepSeek, Phi)도 마찬가지입니다.

​

로컬 vs 클라우드 실행 선택 가이드

​

자체 vLLM 서빙 vs Databricks Model Serving: 언제 무엇이 유리한가

• GPU 인프라 전문 인력이 없는 팀: Databricks가 GPU 프로비저닝, 스케일링, 장애 대응을 모두 처리
• 거버넌스가 핵심 요구사항: Unity Catalog 통합으로 모델 접근 제어, 추론 로그 자동 저장, 리니지 추적이 기본 제공
• 가변적 트래픽: 오토스케일링으로 트래픽에 따라 GPU를 자동 조정. 야간에는 0으로 축소하여 비용 절감
• 빠른 시작: Provisioned Throughput 엔드포인트를 수 분 내에 생성하여 즉시 서빙 시작

• GPU 비용 최적화가 최우선: 예약 인스턴스(Reserved Instance)나 스팟 인스턴스를 직접 관리하면 Databricks 대비 30~50% 비용 절감 가능
• 극도로 높은 커스터마이징 필요: vLLM의 모든 파라미터를 직접 튜닝, 커스텀 sampling 전략 적용, 특수한 모델 아키텍처 지원
• 멀티 클라우드/온프레미스: AWS, GCP, Azure, 온프레미스 GPU 서버 등 어디서든 동일한 방식으로 배포
• 이미 Kubernetes 전문 팀이 있는 경우: vLLM + KServe/Triton 조합으로 대규모 서빙 인프라 구축 가능

참고 실무에서 가장 흔한 패턴은 “개발/실험은 Databricks, 대규모 프로덕션은 자체 vLLM” 입니다. Databricks에서 모델 파인튜닝과 평가를 수행하고, 검증된 모델을 MLflow로 패키징하여 자체 vLLM 클러스터에 배포하는 하이브리드 접근입니다.