LabGPU 클라우드 관점에서 다시 고른 LLM 오픈소스 — 모델부터 파인튜닝까지
on this page
2026년 오픈소스 LLM 이야기는 “어떤 모델이 제일 똑똑한가”가 아니라 **“어떤 조합을 어떤 GPU 위에서 돌릴 것인가”**의 문제로 옮겨왔습니다. gcube를 쓰는 입장에서 진짜 중요한 질문은 세 가지로 좁혀집니다.
- 이 모델, VRAM 몇 GB짜리 인스턴스가 필요한가
- 이 서빙 엔진, 같은 GPU에서 처리량이 얼마나 차이 나는가
- 우리 데이터로 튜닝하려면 GPU 몇 장, 며칠이 필요한가
아래 구성은 이 질문에 먼저 답하는 순서로 짰습니다.
01. 먼저 짚고 가는 트렌드 3가지
① 스파스 MoE가 오픈웨이트의 기본형이 됐다
DeepSeek-V3(671B 전체 / 37B 활성)를 기점으로 대형 오픈웨이트 모델 대부분이 MoE(Mixture of Experts) 구조로 수렴했습니다. GLM-4.5도 355B 전체 / 32B 활성입니다.
GPU 인스턴스를 고를 때 반드시 구분해야 할 두 숫자입니다.
- 총 파라미터 → 필요한 VRAM을 결정 (전문가가 무엇이 선택될지 미리 알 수 없어 가중치 전체를 메모리에 올려야 함)
- 활성 파라미터 → 초당 처리 속도와 GPU 단가를 결정
즉 “671B 모델인데 GPU는 37B급만 있으면 된다”는 흔한 오해입니다. VRAM은 총 파라미터 기준으로, 처리량은 활성 파라미터 기준으로 따로 계산해야 인스턴스 사이징이 맞습니다.
② 라이선스가 실제로 느슨해졌다
DeepSeek(MIT, 코드), Qwen3·gpt-oss·Gemma(Apache 2.0)처럼 상위권 모델 다수가 허용형 라이선스를 택했습니다. 다만 Kimi-K2(수정 MIT), Llama(커뮤니티 라이선스)처럼 예외가 있고, 코드 라이선스와 가중치 라이선스가 다른 경우가 흔하니 저장소 배지 하나로 판단하지 마세요.
③ 에이전트 프레임워크 층이 정리됐다
AutoGen이 Semantic Kernel에 흡수되며 사실상 유지보수 모드로 전환, 새 프로젝트는 LangGraph·CrewAI·smolagents 쪽으로 이동했습니다.
02. 오픈웨이트 모델 — gcube에서 뭘 돌릴까
이 목록의 7개는 모두 gcube GPU 인스턴스에서 직접 서빙 대상이 되는 모델 계열입니다. VRAM 사이징의 기준이 되므로 계열별 특성을 정리했습니다.
| 저장소 | 라이선스 | 핵심 |
|---|---|---|
| huggingface/transformers | Apache-2.0 | 모델 정의 표준. 새 아키텍처가 가장 먼저 구현되는 곳. 프로덕션 추론은 vLLM/SGLang으로 넘어가야 함 |
| deepseek-ai/DeepSeek-V3 | MIT(코드) | 671B 전체 / 37B 활성 MoE. 대형 오픈웨이트 설계의 레퍼런스. 가중치는 별도 모델 라이선스 확인 필요 |
| QwenLM/Qwen3 | Apache-2.0 | 소형 dense부터 서버급 MoE까지 사이즈 라인업이 가장 촘촘함. 한국어 처리 안정적. 로컬 PoC → gcube 서버 배포로 스케일업할 때 계열을 바꿀 필요가 없다는 점이 실무적으로 큼 |
| zai-org/GLM-4.5 | Apache-2.0 | 355B/32B MoE. 에이전틱·추론·코딩(ARC) 특화. 툴 콜링 워크로드 백엔드로 자주 검토됨 |
| MoonshotAI/Kimi-K2 | 수정 MIT | 1T급 초대형 MoE. 다단계 에이전트에 강점이나 이 목록에서 자체 호스팅 GPU 비용이 가장 높은 편 — gcube 견적 낼 때 우선 확인 대상 |
| openai/gpt-oss | Apache-2.0 | 120b/20b 두 사이즈. 20b는 단일 GPU 로컬 실행 후보로 자주 거론됨 |
| google-deepmind/gemma | Apache-2.0 | 온디바이스·경량 특화. GPU 예산이 빠듯한 환경의 dense 소형 모델 대안 |
모델 버전을 본문에 고정하지 않은 이유 — 주요 계열의 버전 표기가 분기 단위로 바뀌고 있어, 최신 버전과 벤치마크 점수는 각 저장소 README에서 확인하는 편이 정확합니다.
03. 서빙과 런타임 — 같은 GPU에서 처리량을 쥐어짜는 계층
gcube Lab이 실제로 벤치마크를 돌려본 계층입니다. 모델을 안 바꿔도 런타임 교체만으로 처리량이 몇 배 달라지는 구간이라 GPU 인스턴스 대비 투자 효과가 가장 큽니다.
| 저장소 | 라이선스 | 핵심 | 언제 |
|---|---|---|---|
| vllm-project/vllm | Apache-2.0 | PagedAttention + 연속 배칭으로 GPU 활용률을 끌어올림. OpenAI 호환 API. 오픈웨이트를 사내 API로 낼 때 사실상 1순위 | 거의 모든 상황 |
| sgl-project/sglang | Apache-2.0 | RadixAttention으로 프리픽스(공통 앞부분) 계산 재사용. 구조화 출력·추측 디코딩 지원 | 긴 공통 프롬프트를 반복 전송하는 에이전트·RAG 워크로드에서 vLLM 대비 유의미한 이득 |
| ggml-org/llama.cpp | MIT | GGUF 양자화 모델을 CPU/Apple Silicon/소비자용 GPU에서 실행. 의존성 거의 없음 | GPU 예산이 없거나 폐쇄망일 때. 동시 요청 많은 서버 워크로드엔 부적합 |
| ollama/ollama | MIT | llama.cpp 위의 편의 레이어. 다운로드·양자화·서버 실행을 한 줄로 | 로컬 개발 표준화·데모. 운영 서빙은 vLLM/SGLang으로 |
gcube Lab에서는 Qwen3-8B 기준 vLLM/LMDeploy/Ollama 3사 서빙 엔진 벤치마크와 FP8 양자화 벤치마크를 직접 검증했습니다 — 처리량·TTFT 실측치가 궁금하면 해당 포스트를 함께 참고하세요.
04. 파인튜닝 — 내 GPU로 모델을 내 것으로 만들기
gcube Lab의 Axolotl 멀티GPU 파인튜닝 시리즈와 직접 맞닿는 계층입니다.
hiyouga/LLaMA-Factory (Apache-2.0) 설정 파일 하나로 수많은 모델 계열에 LoRA·QLoRA·전체 파인튜닝·DPO까지 통일된 방식으로 수행. 웹 UI 포함. 여러 모델·기법을 같은 조건에서 비교하는 실험 설계 비용을 크게 줄여줍니다. 도메인 데이터로 튜닝 효과가 있는지 먼저 확인할 때 시작점으로 적합.
unslothai/unsloth (Apache-2.0) 커스텀 커널로 파인튜닝 속도를 높이고 VRAM 사용량을 크게 줄임. 소비자용 GPU 한 장으로도 실용적 크기의 모델을 튜닝할 수 있게 만든 라이브러리로, gcube RTX 5090 단일 인스턴스에서 반복 실험할 때 진입 비용을 실질적으로 낮춥니다. Hugging Face 인터페이스 호환.
RAG로 안 풀리는 “형식·톤·용어” 문제일 때만 파인튜닝을 검토하세요. “우리 회사 정보를 모른다”는 문제는 대부분 RAG로 풀립니다.
05. RAG와 지식검색 — 요약
임베딩·검색은 GPU를 쓰지만, 이 계층의 승부는 대개 파싱 품질과 청킹 전략에서 갈립니다.
- infiniflow/ragflow (Apache-2.0) — 파싱부터 인용까지 묶인 완성형 RAG 엔진. 도커 컴포즈 한 번으로 “우리 문서로 RAG가 될지” 빠르게 검증할 때
- langchain-ai/langchain (MIT) — 벤더 어댑터가 가장 많은 생태계. 여러 벡터 DB·모델을 갈아 끼울 예정일 때
- run-llama/llama_index (MIT) — 청킹·인덱싱 전략 자체가 1급 개념. 단순 벡터 유사도로 정확도 한계에 부딪혔을 때
- deepset-ai/haystack (Apache-2.0) — 파이프라인을 그래프로 명시. 재현성·회귀 테스트 중시하는 팀
- milvus-io/milvus (Apache-2.0) — 수억 건 규모 분산 벡터 DB. 문서 수 수십만 건 넘고 권한별 필터링 필요할 때
gcube Lab에서는 BGE-M3 + Chroma + vLLM + LangChain 조합으로 RAG 챗봇을 직접 구축·검증한 포스트가 있습니다.
06. 그 외 생태계 — 빠르게 훑기
GPU 인스턴스 사이징과 직접 연결되지 않는, 오케스트레이션·전처리·관측 계층입니다. 필요할 때 이름만 기억해뒀다가 찾아보는 정도로 충분합니다.
문서·멀티모달 입력 처리 | 저장소 | 한 줄 | |—|—| | opendatalab/MinerU | PDF/DOCX/PPTX/XLSX를 구조화 마크다운·JSON으로. 레이아웃 복잡한 문서 1순위 | | PaddlePaddle/PaddleOCR | 100개+ 언어 OCR. 텍스트 레이어 없는 스캔본·사진 | | docling-project/docling | 가벼운 문서 변환 라이브러리. 기존 파이썬 파이프라인에 얹기 좋음 | | QwenLM/Qwen3-VL | 비전-언어 모델. 표·차트·화면 이해가 필요할 때 |
에이전트와 자동화 | 저장소 | 한 줄 | |—|—| | langchain-ai/langgraph | 상태 머신 기반 에이전트 오케스트레이터. 승인 단계 있는 운영 워크플로의 사실상 기본값 | | crewAIInc/crewAI | 역할 기반 멀티에이전트를 최소 코드로 | | huggingface/smolagents | 모델이 파이썬 코드를 직접 작성·실행하는 최소주의 에이전트 | | All-Hands-AI/OpenHands | 격리 환경에서 실제로 코드를 고치는 소프트웨어 에이전트 | | browser-use/browser-use | API 없는 시스템에 브라우저로 접근 | | langgenius/dify | 비개발자용 비주얼 LLM 앱 플랫폼. 다중 테넌트 재판매 제한 조항 있어 상업 도입 전 라이선스 확인 필요 |
튜닝 평가 · 표준 | 저장소 | 한 줄 | |—|—| | langfuse/langfuse | LLM 앱 추적·평가·프롬프트 버전 관리. 사용자 노출 시점부터 붙이는 게 정석 | | modelcontextprotocol/servers | 도구 연동 개방 표준 MCP의 참조 서버 모음. 여러 AI 클라이언트에 같은 도구를 재사용할 때 |
07. 목적별 최소 스택 조합
| 목적 | 조합 |
|---|---|
| 사내 문서 질의응답 | MinerU → RAGFlow → Qwen3 계열 → vLLM → Langfuse |
| 로컬 개인용 AI | Ollama(llama.cpp) → Gemma/Qwen3 소형 → Docling → LlamaIndex |
| 코드베이스 개발 자동화 | OpenHands → GLM/Qwen3-Coder 계열 → SGLang → MCP 서버 연동 |
| 도메인 특화 모델 | LLaMA-Factory + Unsloth → 평가셋 구축 → Langfuse → vLLM |
가운데 세 조합(모델·서빙·튜닝)은 그대로 gcube GPU 인스턴스 위에서 구성 가능한 조합입니다.
08. 도입 전 체크리스트
- 코드 라이선스와 모델 가중치 라이선스를 따로 확인했는가 (같은 저장소 안에서도 다를 수 있음)
- 상업적 재판매·다중 테넌트 제공에 제약이 있는가 (Dify 등 Apache 기반 수정 라이선스 사례 증가 중)
- 데이터가 어디서 처리되는가 (셀프호스팅이라도 기본 설정에서 외부 API·텔레메트리 호출하는 경우 흔함)
- 보안 패치·릴리스 주기가 살아 있는가
- 교체 비용을 미리 계산했는가 (OpenAI 호환 API, MCP, ONNX 같은 표준 인터페이스 경유 시 이관 비용 감소)
- 평가 데이터셋을 먼저 만들었는가 (50~100개만 있어도 이후 의사결정 기준이 됨)
09. 자주 묻는 질문
오픈소스 모델이 상용 API보다 저렴한가요? 사용량에 따라 다릅니다. 자체 호스팅은 GPU 상시 비용이 고정으로 발생하므로 트래픽이 적으면 상용 API가 쌉니다. 손익분기는 대개 GPU가 꾸준히 바쁠 만큼의 요청량이 나올 때부터입니다.
RAG와 파인튜닝, 뭘 먼저 해야 하나요? 거의 항상 RAG가 먼저입니다. “회사 정보를 모른다”는 검색으로, “출력 형식을 계속 어긴다”는 튜닝으로 접근하세요.
MoE 모델은 활성 파라미터만큼의 GPU만 있으면 되나요? 아닙니다. 연산량은 활성 파라미터에 비례하지만 가중치는 전체를 메모리에 올려야 합니다. 671B MoE가 토큰당 37B만 활성화한다고 37B 모델과 같은 VRAM으로 돌지 않습니다. **MoE의 이점은 “적은 VRAM”이 아니라 “같은 VRAM에서 더 높은 처리량”**입니다 — gcube 인스턴스 선택 시 가장 자주 나오는 오해입니다.
에이전트 프레임워크는 꼭 써야 하나요? 단일 루프 수준이면 직접 짜는 게 빠릅니다. 상태 지속, 중단 후 재개, 사람 승인 개입, 병렬 실행이 필요해질 때부터 프레임워크가 값을 합니다.
마무리
2026년 오픈소스 LLM 생태계를 한 문장으로 요약하면, 부품은 충분히 좋아졌고 이제 조립이 문제입니다. 30개를 다 훑기보다 지금 풀려는 문제 하나를 정하고, 모델 → 서빙 → 튜닝 세 계층에서 하나씩만 골라 gcube GPU 위에서 직접 처리량·비용·지연시간을 재보는 편이 가장 빠릅니다.
작성 기준일: 2026년 8월 11일 (원문 기준). 모델 버전·벤치마크 점수는 분기 단위로 갱신되므로 본문에 고정하지 않았습니다. 개별 저장소의 라이선스(코드/가중치 각각), 상업적 이용 범위는 공식 저장소에서 재확인하시기 바랍니다. 이 글은 기술 검토를 돕기 위한 참고 자료이며 법적 조언이 아닙니다.