원격 LLM 서버 최종 모델 선정: 벤치마크 완료 및 구성 확정

이전 글: LLM 벤치마크로 최적의 모델 찾기: 18개 모델 성능 비교

지난 포스트에서 18개 모델을 벤치마크한 후, 본격 운영을 위해 추가 테스트를 진행했습니다. 그 과정에서 예상과 다른 발견들이 있었습니다.

🔴 발견: “30B 이상 모델은 작동하지 않는다”

테스트 경과

패턴 분석

✅ 작동 정상: 7B ~ 14B 범위
⚠️ 불안정: 27B ~ 34B 범위
❌ 극도로 느림: 70B 이상 범위

결론: 30B 이상은 “크기의 저주(Curse of Dimensionality)“에 빠진 상태

✅ 최종 선정 모델 (8개)

1. qwen3:14b (9.3GB) - 메인 모델

용도: 실시간 채팅, 일반 작업

• 속도: 빠름 (15.4 tok/s)
• 한국어: 매우 우수 ⭐
• 코딩: 준수함
• 권장: 메인 모델

2. codellama:13b (7.4GB) - 코딩 전문

용도: 소프트웨어 개발, 코드 리뷰

• 속도: 빠름
• 코딩: 최고 수준 ⭐⭐⭐
• 한국어 주석: 준수함

3. deepseek-r1:7b (4.7GB) - 가벼운 추론

용도: 로직 분석, 문제 해결

• 속도: 매우 빠름
• 추론 능력: 매우 우수 ⭐
• 경량: 효율적

4. gemma3:12b (8.1GB) - 범용 모델

용도: 텍스트 생성, 번역, 요약

• 속도: 빠름 (18.98 tok/s)
• 일반 능력: 우수
• 안정성: 매우 높음 ⭐

5. gemma3:27b (17.3GB) - 고급 범용 모델

용도: 깊이있는 분석, 장문 생성, 복잡한 요청

• 속도: 느림 (10.11 tok/s)
• 성능: 12b보다 높은 정확도 ⭐⭐
• 활용: “속도보다 품질"이 중요한 작업에 최적

6. neural-chat:7b (4.1GB) - 경량 채팅

용도: 빠른 응답 필요 시

• 속도: 매우 빠름 (41.34 tok/s)
• 대화 능력: 우수
• 메모리 효율: 최고 ⭐⭐⭐

7. gemma2:9b (5.4GB) - 범용 경량

용도: 일반 작업 보조

• 속도: 빠름 (28.15 tok/s)
• 안정성: 높음
• 유연성: 우수

8. mistral:latest (4.4GB) - 경량 다목적

용도: 가벼운 작업, 실험

• 속도: 빠름 (34.78 tok/s)
• 안정성: 높음
• 범용성: 우수

🗑️ 삭제된 모델 (10개, ~110GB 절감)

배운 교훈

1. 크기 ≠ 성능

qwen3:30b (68.69 tok/s) vs qwen3:32b (9.99 tok/s)
→ 2B 차이로 7배 느림

2. GGUF 양자화의 중요성

30B는 Q4_K_M 최적화: 초고속
32B는 같은 양자화: 성능 역전
→ 양자화 수준이 크기보다 중요

3. GPU 메모리 구조의 한계

GB10 GPU (100GB VRAM):
- 14B 이하: 여유있게 작동
- 27B 이상: 메모리 스왑 발생 가능
- 70B: 실시간 처리 불가능

📊 최종 구성 비교

기존 (18개 모델, ~500GB)

❌ 무겁고 비효율적
❌ 30B+ 모델 불안정
❌ 관리 부담 높음

최종 (8개 모델, ~61GB)

✅ 가볍고 효율적
✅ 속도 + 품질의 균형
✅ 용도별 최적 배치
✅ 깊이있는 분석 가능

저장소 절감: 439GB (88%)

🎯 모델별 최적 사용 시나리오

qwen3:14b (메인)

→ "이 문제는 어떻게 해결할까?"
→ "Python 코드를 한국어 주석으로 작성해줘"
→ "인프라 설정 가이드 작성"

codellama:13b (코딩)

→ "이 SQL 쿼리 최적화해줘"
→ "React 컴포넌트 구현"
→ "버그 분석 및 수정"

deepseek-r1:7b (추론)

→ "Docker vs Kubernetes 비교"
→ "시스템 설계 아이디어"
→ "복잡한 로직 분석"

gemma3:27b (깊이있는 분석)

→ "깊이있는 기술 블로그 글 작성"
→ "복잡한 시스템 설계 문서"
→ "정교한 코드 리뷰"
→ "시간이 걸려도 괜찮은 경우 사용"

neural-chat:7b (빠른 응답)

→ "빠르게 답변이 필요한 경우"
→ "모바일 앱 통합"
→ "실시간 채팅"

🔧 기술 스택 최종 확정

원격 LLM 서버

• OS: NVIDIA DGX Spark (Linux ARM64)
• Ollama: 호스트 바이너리 운영
• 모델 저장소: 61GB
• 네트워크: 80Mbps 제한 (공유 회선 배려)

모니터링

• Prometheus: 메트릭 수집
• Grafana: 시각화
• Nginx: 로드밸런싱

💡 결론

1. “속도 > 품질"은 상황에 따라 다르다

• 실시간 필요: qwen3:14b, neural-chat:7b
• 깊이 필요: gemma3:27b (느려도 괜찮음)
• 거짓: “더 크면 더 좋다”

2. 하드웨어 한계를 인정하라

• 88% 저장소 절감 (500GB → 61GB)
• 30B 이상 불안정 → 14B 이하 + 27B 선택형
• 메모리 스왑 제거 → 응답 속도 향상

3. 속도-품질의 스펙트럼을 구성하라

• 🚀 빠름: neural-chat:7b, qwen3:14b
• ⚖️ 균형: gemma3:12b, codellama:13b
• 🎯 정확함: gemma3:27b (시간 무관)

4. 실전이 정답이다

• 벤치마크는 시작일 뿐
• 실제 운영하며 문제를 발견하고 개선
• 기준이 변하면 구성도 유연하게 변경

📈 다음 단계

✅ 완료:

• 18개 → 8개 모델로 정리
• 88% 저장소 절감
• 최종 모델 선정 완료

⏳ 예정:

• 각 모델별 세부 테스트
• 분신 AI 팀 운영 시작
• 성능 모니터링 및 최적화

작성일: 2026-02-12
관련 글: 벤치마크 비교 분석, 원격 서버 구축