Qwen3 로컬 실행 방법 - AI 애호가를 위한 실용 가이드

지난달, 알리바바의 Qwen3 모델이 출시되었다는 소식을 처음 들었을 때, 저는 바로 직접 사용해보고 싶었습니다. 인상적인 벤치마크 결과와 기능들을 살펴본 후, 많은 분들이 겪는 고민과 마주했습니다: "그냥 클라우드 API를 쓸까, 아니면 이걸 내 로컬에서 직접 돌려볼까?"

클라우드 API는 편리하지만, 개인정보 보호 문제, 사용 비용, 그리고 순수한 도전 정신 때문에 저는 제 하드웨어에서 Qwen3를 직접 실행하는 여정을 시작하기로 했습니다. 몇 주간의 실험, 수많은 설정 조정, 그리고 GPU 팬 소리에 놀란 순간들을 거쳐, 제가 배운 내용을 이 포괄적인 가이드에 담았습니다.

데이터 프라이버시를 지키고 싶거나, API 비용을 줄이고 싶거나, 모델을 커스터마이징하고 싶거나, 혹은 최첨단 AI를 내 컴퓨터에서 직접 돌려보는 만족감을 느끼고 싶다면, 이 가이드가 도움이 될 것입니다.

Qwen3란 무엇인가?

설치 과정에 들어가기 전에, 우리가 다룰 대상이 무엇인지 이해해봅시다. Qwen3(발음: "츈")는 Qwen 팀이 2025년 4월에 발표한 3세대 대형 언어 모델입니다. 0.6B 파라미터의 경량 모델부터 235B 파라미터의 거대 모델까지 다양한 크기로 제공됩니다.

Qwen3가 특히 흥미로운 점은 이중 아키텍처 방식을 채택했다는 것입니다:

Dense 모델: 0.6B에서 32B 파라미터까지, 추론 시 모든 파라미터가 활성화됩니다:

• Qwen3-0.6B, 1.7B, 4B (32K 컨텍스트 윈도우)
• Qwen3-8B, 14B, 32B (128K 컨텍스트 윈도우)

Mixture-of-Experts (MoE) 모델: 계산 효율성을 위해 희소 아키텍처를 활용합니다:

• Qwen3-30B-A3B: 총 30B 파라미터지만 추론 시 약 3B만 활성화
• Qwen3-235B-A22B: 235B 파라미터의 거대 모델로 추론 시 약 22B만 활성화

MoE 모델 이름의 "A"는 "Active" 파라미터를 의미합니다. 이는 모든 것을 아는 한 사람을 고용하는 대신, 각 작업에 가장 적합한 전문가 팀만을 활용하는 것과 같은 똑똑한 접근법입니다. 덕분에 파라미터 수에 비해 훨씬 효율적입니다.

Qwen3의 또 다른 특징은 하이브리드 사고 능력입니다 — 내부적으로 단계별 추론을 수행하는 '사고 모드'와 직접 답변을 제공하는 '비사고 모드'를 지원해, 깊은 추론과 속도 사이의 균형을 제공합니다.

왜 Qwen3를 로컬에서 실행해야 할까?

클라우드 API가 있는데 왜 굳이 로컬에서 실행하려 할까요? 제가 설득된 몇 가지 이유는 다음과 같습니다:

1. 데이터 프라이버시: 모든 데이터가 내 컴퓨터에만 머무릅니다.
2. 비용 통제: 예상치 못한 청구서나 토큰 쿼터 걱정 없이, 초기 하드웨어 비용과 전기료만 부담.
3. 오프라인 사용 가능: 초기 모델 다운로드 후 인터넷 연결 불필요.
4. 커스터마이징 자유: 내 데이터에 맞게 모델을 미세 조정 가능.
5. 학습 경험: 최첨단 AI 시스템을 내 하드웨어에서 직접 돌려보는 만족감.
6. 낮은 지연 시간: 네트워크 왕복 시간을 없애 더 빠른 응답.

특히 개인정보 보호 측면이 매우 중요했습니다. 민감한 데이터 분석을 외부 서버로 전송 걱정 없이 할 수 있다는 점이 큰 해방감을 주었습니다.

하드웨어 요구 사항 - 필요한 것들

솔직히 말해, 특히 큰 모델을 로컬에서 돌리는 건 쉽지 않습니다. 어떤 모델을 돌릴지에 따라 하드웨어 요구 사항이 크게 달라집니다.

모델별 요구 사항은 다음과 같습니다:

RAM 요구 사항

• 소형 모델 (0.6B, 1.7B): 최소 8GB, 권장 16GB
• 중형 모델 (4B, 8B): 최소 16GB, 권장 32GB
• 대형 모델 (14B, 32B): 최소 32GB, 권장 64GB
• MoE 모델 (30B-A3B, 235B-A22B): 64GB 이상, 특히 235B 모델은 더 필요

GPU/VRAM 요구 사항

여기서부터가 진짜입니다. GPU 메모리(VRAM)가 보통 병목입니다:

• Qwen3-0.6B: 2GB 이상 VRAM (구형 GTX 1060도 가능)
• Qwen3-1.7B: 4GB 이상 VRAM (GTX 1070 이상)
• Qwen3-4B: 8GB 이상 VRAM (RTX 3060 이상)
• Qwen3-8B: 16GB 이상 VRAM (RTX 3090, 4080, A4000)
• Qwen3-14B: 24GB 이상 VRAM (RTX 4090, A5000)
• Qwen3-32B: 40GB 이상 VRAM (A100 또는 다중 소비자 GPU)
• Qwen3-30B-A3B: 활성 파라미터 수가 적어도 24GB 이상 VRAM 필요
• Qwen3-235B-A22B: 고성능 GPU 여러 대 필요 (예: A100 80GB 2대 이상 또는 A6000 4대 이상)

좋은 소식은, 양자화(Quantization)를 통해 요구 사항을 크게 줄일 수 있다는 점입니다. 예를 들어 4비트 양자화(아래에서 자세히 설명)로 Qwen3-8B를 6GB GPU에서 돌릴 수도 있지만, 성능 저하가 있을 수 있습니다.

실제로 저는 처음에 RTX 3080(10GB VRAM)에서 Qwen3-14B를 돌리려다 "CUDA out of memory" 오류를 겪었습니다. 4비트 양자화를 적용한 후 실행은 가능했지만 응답 속도가 느렸습니다. 이후 RTX 4090(24GB VRAM)으로 업그레이드해 8비트 양자화로 14B 모델을 원활히 돌리고 있습니다.

CPU 전용 옵션?

기술적으로는 소형 모델(0.6B, 1.7B 정도)을 CPU만으로도 돌릴 수 있지만, 기적을 기대하지 마세요. 제가 Core i7 CPU에서 Qwen3-0.6B를 GPU 없이 돌려봤는데, 간단한 문단 생성에 거의 45초가 걸렸습니다. 실시간 대화용으로는 적합하지 않습니다!

저장 공간 요구 사항

디스크 공간도 잊지 마세요! 필요 용량은 다음과 같습니다:

• 소형 모델: 모델당 2~5GB
• 중형 모델: 모델당 8~16GB
• 대형 모델: 모델당 30~60GB
• MoE 모델: 60~120GB 이상

SSD 사용을 권장합니다. HDD로 시도했을 때 Qwen3-8B 로딩에 거의 10분이나 걸렸습니다!

소프트웨어 사전 준비 사항

설치 전에 다음을 준비하세요:

1. Python 3.10 이상: 최신 ML 라이브러리와 호환성 좋음
2. CUDA Toolkit: NVIDIA GPU 사용 시 11.8 이상 권장
3. 호환 OS: Linux 권장 (Ubuntu 22.04 이상 최적), Windows도 지원
4. Git: 저장소 다운로드용
5. 가상 환경 도구: Conda 또는 venv로 의존성 관리

방법 1: Ollama로 Qwen3 실행하기 (간단한 방법)

여러 방법을 시도한 결과, Ollama가 Qwen3를 로컬에서 시작하기 가장 쉬운 방법이었습니다. 복잡함을 많이 추상화하고 깔끔한 CLI 인터페이스를 제공합니다.

1단계: Ollama 설치

먼저 공식 웹사이트에서 다운로드하거나 터미널에서 다음 명령어 실행:

curl -fsSL https://ollama.com/install.sh | sh

Windows 사용자는 웹사이트에서 설치 프로그램을 받으세요.

2단계: Qwen3 모델 실행

가장 간단한 실행 명령은 다음과 같습니다:

ollama run qwen3:4b

이 명령은 다음을 수행합니다:

1. 모델이 없으면 다운로드
2. 메모리에 로드
3. 대화형 채팅 세션 시작

4b 대신 0.6b, 1.7b, 8b, 14b, 32b, 30b-a3b 등 지원하는 다른 변형도 가능합니다.

처음 실행 시 모델 다운로드에 약 15분 걸렸으니 인내심을 가지세요! 이후 실행은 캐시 덕분에 훨씬 빠릅니다.

3단계: 채팅 및 실험

실행 후 터미널에서 모델과 직접 대화할 수 있습니다. 예시 대화:

> LLM에서 mixture-of-experts 아키텍처에 대해 알려줘.

Mixture-of-Experts (MoE)는 대형 언어 모델(LLM)에서 효율성을 높이기 위해 입력에 따라 네트워크 일부만 선택적으로 활성화하는 아키텍처 접근법입니다.

전통적인 'dense' 트랜스포머 모델은 모든 파라미터를 모든 토큰 처리에 사용해 계산 비용이 큽니다. MoE 모델은 '전문가(experts)'라는 특화된 서브네트워크와, 어떤 전문가를 활성화할지 결정하는 라우팅 메커니즘을 도입해 이를 해결합니다.

예를 들어 Qwen3의 MoE 모델(Qwen3-30B-A3B, Qwen3-235B-A22B)은 각 MoE 레이어에 128개의 전문가 FFN이 있지만, 토큰당 8개만 활성화합니다. 따라서 총 파라미터가 235B라도 추론 시 약 22B만 사용됩니다.

이 접근법의 장점은:
1. 계산 효율성 - 추론 시 일부 파라미터만 계산
2. 용량 확장성 - 거대한 총 용량 유지하면서 계산 비용 절감
3. 전문화 - 전문가별로 다른 지식이나 작업에 집중 가능

MoE 레이어의 핵심 구성요소는:
- 전문가 네트워크: 특화된 FFN
- 라우터: 어떤 전문가를 활성화할지 결정
- 게이팅 함수: 선택된 전문가 출력 가중치 조합

이 아키텍처 덕분에 계산 요구량 증가 없이 점점 더 큰 모델 개발이 가능해졌습니다.

괜찮죠? 제 RTX 4090에서 약 15초 만에 생성된 답변입니다.

4단계: API 사용 (선택 사항)

Ollama는 보통 http://localhost:11434에서 OpenAI 호환 API 형식의 로컬 서버도 시작합니다. curl이나 Python 클라이언트로 프로그래밍적으로 접근할 수 있습니다.

간단한 Python 예제:

import requests

response = requests.post('http://localhost:11434/api/generate', 
                       json={
                           'model': 'qwen3:4b',
                           'prompt': '신경망에 관한 짧은 시를 써줘.',
                           'stream': False
                       })
print(response.json()['response'])

로컬 Qwen3 모델 위에 애플리케이션을 쉽게 구축할 수 있습니다.

방법 2: vLLM으로 Qwen3 실행하기 (고성능 경로)

더 높은 성능, 특히 프로덕션 환경에 가까운 서비스용으로는 vLLM이 적합합니다. PagedAttention 같은 기술로 GPU 활용도를 극대화해 처리량과 지연 시간을 최적화합니다.

초기 설정은 복잡하지만, 제대로 구성하면 Ollama보다 훨씬 빠릅니다.

1단계: vLLM 설치

가상 환경 사용 권장:

python -m venv venv
source venv/bin/activate  # Windows: venv\Scripts\activate

pip install -U vllm

이전에 적절한 CUDA 드라이버가 설치되어 있어야 합니다.

2단계: Qwen3 모델 서비스 시작

예를 들어 Qwen3-7B 모델을 서비스하려면:

vllm serve Qwen/Qwen3-7B \
    --enable-reasoning \
    --reasoning-parser deepseek_r1

단일 GPU에 맞지 않는 큰 모델은 텐서 병렬화 사용 가능:

vllm serve Qwen/Qwen3-30B-A3B \
    --enable-reasoning \
    --reasoning-parser deepseek_r1 \
    --tensor-parallel-size 2

--enable-reasoning 플래그는 Qwen3의 하이브리드 사고 기능을 활성화하며, --reasoning-parser deepseek_r1은 vLLM이 모델의 사고 형식을 올바르게 해석하도록 합니다.

처음에 --reasoning-parser 플래그가 없으면 응답이 잘리거나 이상한 형식이 나오는 문제가 있었습니다.

3단계: vLLM 서버와 상호작용

실행 후 vLLM은 기본적으로 http://localhost:8000에서 OpenAI API 규격의 서버를 호스팅합니다. curl로 요청 가능:

curl http://localhost:8000/v1/completions \
    -H "Content-Type: application/json" \
    -d '{
        "model": "Qwen/Qwen3-7B",
        "prompt": "양자 컴퓨팅을 쉽게 설명해줘",
        "max_tokens": 150,
        "temperature": 0.7
    }'

Python OpenAI 클라이언트 사용 예:

from openai import OpenAI

client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")

response = client.completions.create(
  model="Qwen/Qwen3-7B",
  prompt="재귀적으로 팩토리얼을 계산하는 파이썬 함수 작성",
  max_tokens=150
)
print(response.choices[0].text)

vLLM 성능 고려사항

흥미로운 성능 패턴을 발견했습니다:

• 배치 크기 중요: 배치 크기(--max-batch-size 8 등)를 늘리면 동시 요청 처리량이 크게 향상됨
• 첫 요청 워밍업: 서버 시작 후 첫 요청은 모델 워밍업 때문에 느림
• 효율적 메모리 관리: PagedAttention 덕분에 긴 컨텍스트 처리 시 다른 프레임워크보다 훨씬 효율적

양자화: 대형 모델을 소비자 하드웨어에 맞추기

처음 Qwen3-32B를 돌리려 했을 때, 제 컴퓨터가 "안 돼"라고 말하는 것 같았습니다. 이때 양자화가 큰 도움이 됐습니다.

양자화는 모델 가중치 정밀도를 낮춰 메모리 사용량을 크게 줄이는 대신 약간의 정확도 손실을 감수하는 방법입니다. 주요 옵션은:

• FP16 (16비트): 기본, 최고 정확도지만 VRAM 사용량 많음
• INT8 (8비트): VRAM 사용량 약 50% 절감, 품질 저하 적음
• INT4 (4비트): VRAM 사용량 약 75% 절감, 품질 저하는 있지만 보통 허용 가능

Ollama에서 양자화 사용하기

Ollama는 일부 양자화를 자동 적용하지만, Modelfile로 사용자 설정 가능:

# Modelfile 생성
FROM qwen3:14b
PARAMETER num_gpu_layers 35
PARAMETER quantization_method q4_0

이후 커스텀 양자화 모델 빌드 및 실행:

ollama create qwen3-14b-quantized -f Modelfile
ollama run qwen3-14b-quantized

vLLM에서 양자화 사용하기

vLLM은 명령줄 플래그로 다양한 양자화 지원:

vllm serve Qwen/Qwen3-14B \
    --enable-reasoning \
    --reasoning-parser deepseek_r1 \
    --quantization awq

awq, gptq, squeezellm 옵션이 있으며, 저는 Qwen3 모델에 AWQ가 압축과 품질 균형이 가장 좋다고 느꼈습니다.

실제 성능: 제 벤치마크 결과

제 환경(RTX 4090, 32GB RAM, Ryzen 9 5900X)에서 비공식 벤치마크를 돌려봤습니다:

모델	양자화	토큰/초	로딩 시간	최대 컨텍스트	VRAM 사용량
Qwen3-0.6B	없음 (FP16)	42.3	6초	32K	1.9 GB
Qwen3-4B	없음 (FP16)	28.7	18초	32K	9.2 GB
Qwen3-4B	4비트 (Q4_0)	26.1	12초	32K	3.4 GB
Qwen3-14B	8비트 (AWQ)	15.2	45초	128K	11.3 GB
Qwen3-14B	4비트 (GPTQ)	12.8	38초	128K	7.1 GB

이 수치는 vLLM 사용 기준이며, 하드웨어와 작업에 따라 달라질 수 있습니다.

흥미롭게도, 창의적 글쓰기나 코드 생성 같은 작업에서는 4비트 양자화 모델도 꽤 잘 작동했습니다. 하지만 복잡한 추론 작업에서는 4비트 양자화 시 품질 저하가 더 눈에 띄었습니다.

고급 기능: 하이브리드 사고 모드

Qwen3의 가장 흥미로운 기능 중 하나는 하이브리드 사고 능력으로, 상호작용 시 제어할 수 있습니다.

Ollama에서는 프롬프트에 특수 태그를 사용:

/think 이 문제를 단계별로 풀어야 해. f(x) = x^3 * ln(x)의 도함수는?

이렇게 하면 모델이 내부 추론 모드를 사용합니다.

vLLM에서는 --enable-reasoning 플래그로 서버 차원에서 활성화하지만, 프롬프트 포맷으로도 제어 가능합니다.

수학 문제나 논리적 추론 작업에서 사고 모드는 특히 유용하며, 모델이 생각 과정을 단계별로 보여준 후 답변을 제공합니다.

자주 겪는 문제 해결법

Qwen3를 다루며 만난 흔한 문제와 해결책입니다:

CUDA 메모리 부족 오류

문제: "CUDA out of memory" 또는 "RuntimeError: CUDA error: out of memory" 오류 발생
해결:

1. 더 강력한 양자화 방법 사용
2. 배치 크기나 컨텍스트 길이 줄이기
3. 실행 사이에 CUDA 캐시 비우기: torch.cuda.empty_cache()
   다른 GPU 사용 앱(예: 백그라운드의 WebGL 탭 포함)을 종료하는 것도 중요합니다.

첫 추론이 느림

문제: 첫 쿼리가 이후보다 훨씬 오래 걸림
해결: 정상입니다! 모델이 로드되고 최적화되는 과정입니다. 이후 쿼리는 빨라집니다.

이상한 출력 형식

문제: 출력에 이상한 형식이나 잘림 현상 발생
해결: vLLM 사용 시 --reasoning-parser 플래그 확인, Ollama 사용 시 프롬프트 형식 점검

설치 실패

문제: 특히 vLLM 설치 중 라이브러리 오류
해결: CUDA 버전 호환성 확인, Python 3.10 이상 사용, Linux에서는 추가 시스템 라이브러리 설치 필요:

sudo apt-get install python3-dev

결론: Qwen3 로컬 실행, 해볼 만한가?

몇 주간 로컬에서 Qwen3를 탐험한 결과, 제 답은 명확한 "예"입니다 — 다만 몇 가지 조건이 붙습니다.

로컬 실행은 전례 없는 제어권과 프라이버시, 그리고 최첨단 AI를 내 손안에 둔다는 만족감을 줍니다. Qwen 팀은 이 모델들을 접근 가능하게 만들었고, Ollama와 vLLM 같은 도구 덕분에 로컬 배포가 점점 쉬워지고 있습니다.

하지만 큰 모델을 무거운 양자화 없이 돌리려면 꽤 좋은 하드웨어가 필요합니다. 많은 사용자에게는 Qwen3-4B 또는 8B를 적당한 양자화와 함께 RTX 3080급 GPU에서 돌리는 것이 적절한 균형점일 것입니다.

처음 시작한다면:

1. Ollama로 간단히 시작하세요
2. 작은 모델(0.6B, 1.7B, 4B)부터 시도
3. 양자화로 최적의 균형 찾기
4. 더 높은 성능이 필요하면 vLLM으로 단계 업

로컬 AI 배포 환경은 빠르게 진화 중이며, 1년 전에는 불가능해 보였던 일들이 이제는 소비자 하드웨어에서 가능해졌습니다. 최적화 기술이 계속 발전함에 따라 더 큰 모델도 점점 쉽게 로컬에서 돌릴 수 있을 것입니다.

Qwen3나 다른 대형 언어 모델을 로컬에서 실행해본 경험이 있나요? 여러분의 경험과 팁을 공유해 주세요!

---

FAQ: Qwen3 로컬 배포 관련 자주 묻는 질문

Q: AMD GPU에서도 Qwen3를 실행할 수 있나요?

A: 가능합니다만 제한적입니다. ROCm 같은 라이브러리가 AMD GPU를 지원하지만, 호환성과 성능이 NVIDIA GPU만큼 좋지 않을 수 있습니다. 저는 직접 테스트하지 않았지만, 커뮤니티 보고에 따르면 가능하긴 하나 더 까다롭다고 합니다.

Q: 모든 Qwen3 모델을 로컬에 저장하려면 얼마나 많은 디스크 공간이 필요한가요?

A: 모든 변형을 다 저장하려면 약 250~300GB가 필요합니다(일반적이지 않음). 대부분 사용자는 특정 모델 하나만 사용하므로 5~60GB 정도면 충분합니다.

Q: Qwen3를 로컬에서 미세 조정할 수 있나요?

A: 네, 가능하지만 추론보다 더 많은 자원이 필요합니다. 4B 이하 소형 모델은 LoRA나 QLoRA를 이용해 소비자 하드웨어에서 미세 조정이 가능합니다. 더 큰 모델은 더 많은 리소스가 필요합니다.

Q: Qwen3 모델은 Llama 3나 Mistral 같은 다른 오픈 모델과 어떻게 비교되나요?

A: 제 테스트 결과, Qwen3는 다국어 처리와 추론 능력에서 특히 뛰어납니다. 비슷한 크기의 다른 모델들과 비교해 각기 다른 분야에서 강점이 있습니다.

Q: 로컬 배포가 프로덕션 환경에 적합한가요?

A: vLLM의 최적화 덕분에 가능하지만, 신뢰성, 확장성, 모니터링을 신중히 고려해야 합니다. 진지한 프로덕션 용도라면 적절한 오류 처리, 모니터링, 다중 서버 부하 분산 구현이 필요합니다.