포스트

Qwen 3.5 로컬 실행 완전 가이드

게시
By BLUEBUG
39 분읽는 시간
Qwen 3.5 로컬 실행 완전 가이드

소비자 하드웨어로 진입한 프론티어급 로컬 LLM 시대
작성 기준: 2026년 3월 | 원본 출처: Unsloth 공식 문서, Hacker News 커뮤니티, @jaehong 분석 글

목차

  1. 개요 및 의의
  2. 모델 라인업 상세 분석
  3. 하드웨어 요구사항 및 메모리 계획
  4. Unsloth Dynamic 2.0 양자화 기술
  5. 실전 성능 벤치마크
  6. 설치 및 실행 가이드 (llama.cpp)
  7. 추론 모드 및 파라미터 설정
  8. LM Studio로 쉽게 시작하기
  9. OpenAI 호환 API 서버 구성
  10. 도구 호출(Tool Calling) 활용
  11. Claude Code / Codex 연동
  12. 현재의 제약과 주의사항
  13. Hacker News 커뮤니티 실사용 보고
  14. 모델 선택 가이드 및 결론

1. 개요 및 의의

알리바바가 공개한 Qwen 3.5는 단순한 오픈 웨이트 모델 업데이트가 아니다. 이번 릴리스는 로컬 LLM 생태계에서 하나의 전환점으로 기록될 만한 사건이다. 공개 직후 Hacker News를 비롯한 개발자 커뮤니티가 들끓은 이유는 두 가지다.

첫째, 벤치마크 성능의 도약이다. 397B 파라미터의 최상위 모델이 Claude Opus 4.5, GPT-5.2와 동일한 성능 티어에 올라섰다는 공식 발표가 나왔다. 오픈 웨이트 모델이 클로즈드 소스 프론티어 모델과 어깨를 나란히 하는 시대가 왔다는 신호다.

둘째, 그리고 더욱 중요한 것은 소비자 하드웨어에서의 실용성이다. 16GB VRAM GPU에서 9B 모델이 초당 100토큰이라는 빠른 속도로 구동된다는 실사용 보고, 22GB Mac에서 35B MoE 모델이 실용적인 속도로 추론된다는 사실이 커뮤니티를 흥분시켰다. “쓸 만한 수준”을 넘어 “실무에서 경쟁력 있는 수준”이라는 평가가 처음으로 설득력을 얻기 시작한 것이다.

Qwen 3.5는 멀티모달 하이브리드 추론 LLM 패밀리로, 256K 컨텍스트 윈도우를 기본 지원하고 YaRN 기술을 통해 최대 1M까지 확장이 가능하다. 201개 언어를 커버하며, 에이전틱 코딩·비전·장문 컨텍스트 작업에 특화된 설계를 갖추고 있다. Unsloth는 알리바바로부터 출시 당일 접근권을 제공받아, 공개와 동시에 고품질 GGUF 양자화 파일과 상세한 로컬 실행 가이드를 제공했다.

2. 모델 라인업 상세 분석

Qwen 3.5는 단일 모델이 아니라 8개 변종으로 구성된 패밀리다. 크게 두 계열, MoE(Mixture of Experts)와 Dense로 나뉜다.

MoE(Mixture of Experts) 계열

MoE 구조의 핵심은 이름에서 알 수 있다. 예를 들어 35B-A3B에서 ‘A3B’는 “Active 3B”, 즉 전체 350억 파라미터 중 실제로 한 번에 활성화되는 파라미터가 30억임을 의미한다. 나머지 320억 파라미터는 해당 추론 스텝에서 잠들어 있다. 이 구조 덕분에 모델이 가진 총 지식 용량은 크게 유지하면서, 실제 연산에 사용되는 메모리와 계산 자원은 극적으로 줄어든다.

  • Qwen3.5-35B-A3B: 전체 35B 중 3B만 활성화. 22GB Mac이나 24GB VRAM GPU에서 실용적으로 구동 가능. 속도와 품질의 균형이 가장 뛰어나 커뮤니티에서 가장 인기 있는 선택지다.
  • Qwen3.5-122B-A10B: 전체 122B 중 10B 활성화. 70GB 이상의 RAM 환경이 필요하며, 고성능 워크스테이션이나 고사양 Mac에 적합하다.
  • Qwen3.5-397B-A17B: 전체 397B 중 17B 활성화. 프론티어 모델과 동급의 성능을 자랑하지만, 최소 192GB RAM이 필요해 소비자 하드웨어의 경계선에 걸쳐 있다.

Dense(밀집) 계열

Dense 모델은 모든 파라미터가 매 추론마다 활성화되는 전통적인 아키텍처다. 같은 크기에서 MoE보다 정확도가 소폭 높지만, 연산량이 많아 추론 속도는 느리다.

  • Qwen3.5-27B: Dense 계열의 주력 모델. SWE-bench 등 코딩 벤치마크에서 35B-A3B보다 약간 높은 수치를 기록하지만, 실제 추론 속도는 눈에 띄게 느리다. 특수한 정확도 요구사항이 없다면 35B-A3B가 대부분의 상황에서 더 나은 선택이다.

Small 시리즈

  • Qwen3.5-0.8B / 2B / 4B / 9B: 경량 추론 및 엣지 배포를 위한 소형 모델군. 이 시리즈는 thinking(추론 체인) 모드가 기본적으로 비활성화 상태라는 점이 중요하다. 활성화하려면 별도 옵션이 필요하다(7장에서 상세 설명). 9B 모델은 4비트 양자화 기준 6.5GB 메모리만 있으면 구동 가능해 가장 광범위한 하드웨어에서 활용할 수 있다.

3. 하드웨어 요구사항 및 메모리 계획

로컬 LLM에서 가장 먼저 확인해야 할 것은 “내 장비에서 돌아가는가”다. 아래 표는 Unsloth 공식 문서 기준, 양자화 수준별 필요 메모리다(단위: RAM + VRAM 합산, 또는 통합 메모리).

모델3-bit4-bit6-bit8-bitBF16(풀정밀도)
0.8B + 2B3 GB3.5 GB5 GB7.5 GB9 GB
4B4.5 GB5.5 GB7 GB10 GB14 GB
9B5.5 GB6.5 GB9 GB13 GB19 GB
27B14 GB17 GB24 GB30 GB54 GB
35B-A3B17 GB22 GB30 GB38 GB70 GB
122B-A10B60 GB70 GB106 GB132 GB245 GB
397B-A17B180 GB214 GB340 GB512 GB810 GB

굵게 표시된 4-bit 수치가 대부분의 사용자에게 권장되는 출발점이다. 총 가용 메모리(VRAM + 시스템 RAM)가 다운로드한 양자화 파일 크기를 초과하는 것이 최적이지만, 그 이하여도 llama.cpp는 SSD/HDD 오프로딩을 통해 실행 가능하다(속도는 느려진다).

하드웨어 시나리오별 권장 모델

16GB VRAM GPU (RTX 4080, RTX 3080 등) 또는 16GB 통합 메모리 Mac: 9B 모델이 여유 있게 구동된다. 4비트 양자화 시 6.5GB면 충분하다. 초당 약 100토큰의 빠른 속도를 기대할 수 있으며, 대부분의 일상 작업에 충분한 품질을 제공한다.

24GB VRAM GPU (RTX 4090) 또는 24GB Mac: 35B-A3B를 4비트 양자화로 구동할 수 있다(22GB). 코딩 품질이 DeepSeek 기준 90% 수준이며, 속도와 품질의 황금 비율을 원하는 사용자에게 가장 권장되는 조합이다.

64GB Mac (M1 Max 등): 35B-A3B를 여유 있게 운용하거나, 필요에 따라 122B-A10B의 저비트 양자화를 시도할 수 있다.

192GB+ RAM 시스템: 397B-A17B를 3비트 양자화로 구동 가능. 256GB Mac Studio에서는 4비트를 직접 로드할 수 있다.

24GB GPU + 256GB 시스템 RAM: MoE 오프로딩을 활용해 397B-A17B를 초당 25토큰 이상의 속도로 구동하는 것이 보고되고 있다.

메모리가 부족할 때: llama.cpp는 모델 가중치를 SSD/HDD에서 스트리밍하는 mmap 방식을 지원한다. MoE 모델은 비활성 전문가(expert)의 가중치를 디스크에서 불러오는 방식으로 속도 저하를 최소화할 수 있다. NVMe SSD를 사용한다면 이 방식도 실용적이다.

4. Unsloth Dynamic 2.0 양자화 기술

양자화란 무엇인가

LLM의 가중치는 기본적으로 32비트 또는 16비트 부동소수점으로 저장된다. 이를 더 낮은 비트 수로 변환하는 것이 양자화다. 4비트로 줄이면 메모리 사용량은 약 4~8배 감소하지만, 정보 손실로 인한 품질 저하가 발생한다.

Unsloth Dynamic 2.0의 차별점

단순한 균등 양자화는 모든 레이어를 동일한 비트 수로 줄인다. 이 방식은 단순하지만 중요한 레이어까지 손상시켜 품질 저하가 심하다. Unsloth의 Dynamic 2.0은 다른 전략을 취한다. 모델 내 각 레이어의 품질 민감도를 분석하여, 중요한 레이어는 8비트나 16비트로 보존하고, 덜 민감한 레이어만 4비트나 2비트로 낮추는 선택적 양자화를 적용한다.

이 전략의 효과는 KL 다이버전스(KLD) 벤치마크로 확인된다. Unsloth는 150개 이상의 KLD 벤치마크를 수행하고 9TB 분량의 GGUF를 테스트하여, UD-Q4_K_XL과 IQ3_XXS 등의 변종이 Pareto 프론티어에서 최고 수준(99.9% KLD)을 달성한다는 것을 입증했다.

397B 모델 양자화 제3자 검증 결과

Benjamin Marie가 750개 프롬프트(LiveCodeBench v6, MMLU Pro, GPQA, Math500 혼합)로 수행한 독립 벤치마크 결과는 다음과 같다:

버전정확도원본 대비 변화상대 오류 증가율
원본 가중치81.3%기준-
UD-Q4_K_XL (4비트)80.5%−0.8포인트+4.3%
UD-Q3_K_XL (3비트)80.7%−0.6포인트+3.5%

주목할 점은 3비트가 4비트보다 소폭 높게 나왔다는 것인데, 이는 이 규모의 실험에서 발생하는 정상적인 실행 편차 범위 내의 차이이므로 실질적으로 두 변종은 동등한 품질이라 볼 수 있다. 디스크 절약 효과는 약 500GB 이상으로, 품질 손실 대비 메모리 효율이 매우 뛰어나다.

2025년 3월 5일 업데이트 내용

Unsloth는 출시 이후에도 지속적으로 GGUF 품질을 개선했다. 주요 변경 사항으로는 개선된 양자화 알고리즘 적용, 새로운 imatrix 데이터 반영(채팅·코딩·장문 컨텍스트·툴 콜링 성능 향상), 툴 콜링 채팅 템플릿 버그 수정(모든 업로더의 Qwen3.5 포맷에 보편적으로 적용), Q2_K_XL·Q3_K_XL·Q4_K_XL에서 MXFP4 레이어 제거 등이 있다.

양자화 옵션 선택 가이드

다양한 양자화 변종(IQ4_XS, Q4_K_S, IQ4_NL, Q4_0, Q4_K_M, UD-Q4_K_XL 등)은 초보자에게 진입 장벽이 될 수 있다. 일반적인 선택 기준은 다음과 같다:

  • 메모리가 충분하다면: UD-Q4_K_XL (4비트 다이내믹) — 품질과 속도의 최적 균형
  • 메모리를 최소화하고 싶다면: UD-Q3_K_XL (3비트 다이내믹) — 품질 손실 거의 없음
  • 극한의 메모리 절약: UD-Q2_K_XL (2비트 다이내믹) — Unsloth 최소 권장 수준

5. 실전 성능 벤치마크

코딩 능력 독립 평가

DeepSeek API 응답을 기준(100%)으로, Claude Opus를 심판 모델로 활용한 독립 코딩 벤치마크 결과는 다음과 같다:

모델 및 설정상대 성능
DeepSeek API (기준)100%
35B-A3B, 8비트, thinking 모드92.5%
35B-A3B, 4비트, thinking 모드90.0%
35B-A3B, 8비트, non-thinking 모드81.3%
27B Dense, thinking 모드75.3%

이 결과에서 눈여겨볼 점은 non-thinking 모드가 thinking 모드보다 훨씬 빠르면서도 81%의 코딩 성능을 유지한다는 것이다. 대부분의 일상적 코딩 작업에서는 속도 우선인 non-thinking 모드가 실용적인 선택이 될 수 있다. thinking 모드는 복잡한 알고리즘 설계나 까다로운 디버깅 작업에 활용하는 것이 효율적이다.

토큰 생성 속도 실사용 보고

Hacker News 커뮤니티에서 수집된 실사용 속도 보고는 벤치마크만큼이나 중요한 정보다.

ASUS RTX 5070Ti (16GB VRAM) 에서 9B 모델을 LM Studio로 구동한 사용자는 초당 약 100토큰의 안정적인 생성 속도를 보고했다. 이는 대부분의 클라우드 LLM API 서비스보다 빠른 속도이며, 출력 품질도 벤치마크와 일치한다는 평가를 받았다. 소비자급 하드웨어에서 처음으로 실용적인 모델을 경험했다는 반응이 나왔다.

M3 Air (24GB 통합 메모리) 에서 35B-A3B 3비트 버전을 구동한 사용자는 초당 14~22토큰을 보고했다. 반면 27B Dense 모델은 동일 환경에서 초당 2토큰에 불과했다. 이 극명한 차이가 MoE 구조의 실질적 이점을 보여준다.

RTX 3090 (24GB VRAM) 에서 ik_llama.cpp를 활용해 27B 4bpw 양자화를 구동한 사용자는 제로 컨텍스트 기준 초당 40.7토큰의 생성 속도와 1312토큰/초의 프롬프트 처리 속도를 달성했다. 컨텍스트가 40,960까지 증가해도 36.2토큰/초를 유지했다.

긴 컨텍스트에서의 속도 트레이드오프

35B-A3B가 이전 세대(Qwen3-30B-A3B)보다 항상 빠른 것은 아니다. M1 Max 64GB MacBook에서 Claude Code와 함께 33K 토큰 컨텍스트를 처리할 때, Qwen3-30B-A3B는 초당 25토큰이었지만 Qwen3.5-35B-A3B는 초당 12토큰에 그쳤다. 슬라이딩 윈도우 어텐션 구조가 RAM 사용량을 줄이고 응답 품질을 높이는 대신, 긴 컨텍스트에서의 생성 속도를 희생하는 트레이드오프가 존재한다. 속도가 최우선이고 긴 컨텍스트를 자주 사용한다면 이전 세대가 더 적합할 수 있다.

6. 설치 및 실행 가이드 (llama.cpp)

Qwen 3.5의 현재 권장 실행 환경은 llama.cpp다(Ollama 미지원 이슈는 12장 참고). 아래는 Ubuntu/Debian 기반 시스템 기준 설치 절차다.

llama.cpp 빌드

1
2
3
4
5
6
7
8

apt-get update
apt-get install pciutils build-essential cmake curl libcurl4-openssl-dev -y
git clone https://github.com/ggml-org/llama.cpp
cmake llama.cpp -B llama.cpp/build \
    -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON   # GPU 없으면 -DGGML_CUDA=OFF
cmake --build llama.cpp/build --config Release -j --clean-first \
    --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

Apple Mac/Metal: -DGGML_CUDA=OFF로 설정하면 Metal 지원이 자동으로 활성화된다.

모델 다운로드 (Hugging Face Hub)

1
2
3
4
5
6
7
8
9
10
11
12
13

pip install huggingface_hub hf_transfer

# 35B-A3B 4비트 다이내믹 (권장)
hf download unsloth/Qwen3.5-35B-A3B-GGUF \
    --local-dir unsloth/Qwen3.5-35B-A3B-GGUF \
    --include "*UD-Q4_K_XL*"

# 9B 4비트 다이내믹
hf download unsloth/Qwen3.5-9B-GGUF \
    --local-dir unsloth/Qwen3.5-9B-GGUF \
    --include "*UD-Q4_K_XL*"

# 2비트 다이내믹(최소 메모리)은 "*UD-Q2_K_XL*"로 변경

모델별 실행 명령어

35B-A3B (Thinking 모드, 정밀 코딩)

1
2
3
4
5

export LLAMA_CACHE="unsloth/Qwen3.5-35B-A3B-GGUF"
./llama.cpp/llama-cli \
    -hf unsloth/Qwen3.5-35B-A3B-GGUF:UD-Q4_K_XL \
    --ctx-size 16384 \
    --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00

35B-A3B (Non-thinking 모드, 일반 작업)

1
2
3
4
5

./llama.cpp/llama-server \
    -hf unsloth/Qwen3.5-35B-A3B-GGUF:UD-Q4_K_XL \
    --ctx-size 16384 \
    --temp 0.7 --top-p 0.8 --top-k 20 --min-p 0.00 \
    --chat-template-kwargs '{"enable_thinking":false}'

9B (Thinking 모드 활성화 — Small 시리즈는 기본 비활성)

1
2
3
4
5
6
7

./llama.cpp/llama-server \
    -hf unsloth/Qwen3.5-9B-GGUF:UD-Q4_K_XL \
    --ctx-size 16384 \
    --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00 \
    --alias "unsloth/Qwen3.5-9B-GGUF" \
    --port 8001 \
    --chat-template-kwargs '{"enable_thinking":true}'

397B-A17B (MoE 오프로딩, 24GB GPU + 256GB RAM)

1
2
3
4
5
6

./llama.cpp/llama-cli \
    --model unsloth/Qwen3.5-397B-A17B-GGUF/UD-Q4_K_XL/Qwen3.5-397B-A17B-UD-Q4_K_XL-00001-of-00006.gguf \
    --mmproj unsloth/Qwen3.5-397B-A17B-GGUF/mmproj-F16.gguf \
    --ctx-size 16384 \
    --temp 0.6 --top-p 0.95 --top-k 20 --min-p 0.00 \
    --n-gpu-layers 2   # GPU 메모리 초과 시 값을 줄여가며 조정

팁: --n-gpu-layers 값을 조정하여 GPU에 올릴 레이어 수를 제어할 수 있다. GPU 메모리 할당 오류가 발생하면 이 값을 낮춰보자.

7. 추론 모드 및 파라미터 설정

Qwen 3.5의 가장 독특한 특징 중 하나는 하이브리드 추론 모드다. 동일한 모델에서 thinking 모드(추론 과정을 보여주는 Chain-of-Thought)와 non-thinking 모드(직접 답변)를 전환할 수 있다.

Thinking 모드 (추론 과정 포함)

사용 목적에 따라 파라미터 설정이 달라진다:

일반 작업용:

1

temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

정밀 코딩 작업용 (웹개발 등):

1

temperature=0.6, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=0.0, repetition_penalty=1.0

일반 작업에서는 temperature를 높여 창의성을 허용하고 presence_penalty로 반복을 억제하는 반면, 코딩 작업에서는 temperature를 낮춰 결정론적 출력을 유도하고 presence_penalty를 제거해 동일한 코드 패턴의 반복을 허용한다.

Non-thinking 모드 (직접 답변)

일반 대화용:

1

temperature=0.7, top_p=0.8, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

추론 작업용:

1

temperature=1.0, top_p=0.95, top_k=20, min_p=0.0, presence_penalty=1.5, repetition_penalty=1.0

Thinking 모드 활성화/비활성화

1
2
3
4
5
6
7
8

# 비활성화 (llama-server에서)
--chat-template-kwargs '{"enable_thinking":false}'

# 활성화
--chat-template-kwargs '{"enable_thinking":true}'

# Windows PowerShell에서는 따옴표 이스케이프 필요
--chat-template-kwargs "{\"enable_thinking\":true}"

중요: Small 시리즈(0.8B, 2B, 4B, 9B)는 thinking이 기본 비활성화되어 있으며, llama-server를 통해서만 활성화할 수 있다. 이 세팅을 모르고 사용하면 작은 모델의 추론 능력을 전혀 활용하지 못하게 된다.

기타 중요 설정

  • 최대 컨텍스트: 262,144 토큰 (YaRN으로 1M 확장 가능)
  • 권장 출력 길이: 대부분의 쿼리에 32,768 토큰
  • 이상한 출력(gibberish)이 나올 때: 컨텍스트 길이가 너무 낮거나, --cache-type-k bf16 --cache-type-v bf16 옵션을 추가해 볼 것
  • presence_penalty: 0.0~2.0 범위. 기본 비활성화. 반복 문제가 있을 때만 활성화하되, 너무 높이면 성능이 약간 떨어질 수 있음

8. LM Studio로 쉽게 시작하기

llama.cpp 직접 빌드가 부담스러운 사용자라면 LM Studio가 좋은 대안이다. 통합 UI 환경에서 모델 다운로드부터 실행까지 처리할 수 있다.

LM Studio 설정 방법

  1. LM Studio를 공식 사이트에서 다운로드해 설치한다.
  2. Model Search에서 ‘unsloth/qwen3.5’를 검색한다.
  3. 원하는 크기와 양자화 수준의 GGUF를 선택해 다운로드한다.

Thinking 토글 활성화 (추가 설정 필요)

LM Studio에서 thinking/non-thinking 토글이 기본적으로 표시되지 않을 수 있다. 이를 활성화하려면:

1
2
3
4
5

# 터미널/PowerShell에서 LM Studio CLI 확인
lms --help

# CLI가 정상 작동하면 아래 명령 실행 (4b 부분을 원하는 모델 크기로 변경)
lms get unsloth/qwen3.5-4b

이 명령은 thinking 토글을 활성화하는 YAML 설정 파일을 다운로드한다. 이후 LM Studio를 재시작하고 해당 모델을 로드하면 Thinking 토글이 나타난다. 파라미터 설정도 LM Studio UI에서 직접 조정 가능하다.

9. OpenAI 호환 API 서버 구성

llama-server는 OpenAI API와 호환되는 엔드포인트를 제공하므로, 기존 OpenAI SDK를 사용하는 애플리케이션을 수정 없이 로컬 모델로 전환할 수 있다.

서버 실행

1
2
3
4
5
6

./llama.cpp/llama-server \
    --model unsloth/Qwen3.5-35B-A3B-GGUF/Qwen3.5-35B-A3B-UD-Q4_K_XL.gguf \
    --mmproj unsloth/Qwen3.5-35B-A3B-GGUF/mmproj-F16.gguf \
    --alias "unsloth/Qwen3.5-35B-A3B" \
    --temp 0.6 --top-p 0.95 --ctx-size 16384 --top-k 20 --min-p 0.00 \
    --port 8001

Python에서 호출

1
2
3
4
5
6
7
8
9
10
11
12

from openai import OpenAI

openai_client = OpenAI(
    base_url="http://127.0.0.1:8001/v1",
    api_key="sk-no-key-required",   # 로컬 서버는 키 불필요
)

completion = openai_client.chat.completions.create(
    model="unsloth/Qwen3.5-35B-A3B",
    messages=[{"role": "user", "content": "파이썬으로 스네이크 게임을 만들어줘."}],
)
print(completion.choices[0].message.content)

Thinking 모드에서 reasoning_content 활용

1
2
3

# 9B thinking 모드 서버에 연결 시
print(completion.choices[0].message.content)           # 최종 답변
print(completion.choices[0].message.reasoning_content)  # 추론 과정

10. 도구 호출(Tool Calling) 활용

Qwen 3.5는 툴 콜링(함수 호출)을 지원한다. 2025년 3월 업데이트에서 채팅 템플릿 버그가 수정되어 신뢰성이 크게 향상됐다.

llama-server로 API 엔드포인트를 열고, OpenAI SDK의 tools 파라미터를 활용해 외부 함수를 연결할 수 있다. 기본적인 수학 연산, Python 코드 실행, 터미널 명령 실행 등을 모델이 자율적으로 판단하여 호출하도록 구성할 수 있다. 상세한 툴 콜링 구현 코드는 Unsloth Tool Calling Guide를 참고하라.

11. Claude Code / Codex 연동

Qwen 3.5를 에이전틱 코딩 워크플로우에 통합할 수 있다. llama-server로 OpenAI 호환 엔드포인트를 열면, Claude Code나 OpenAI Codex 같은 코딩 에이전트 도구들이 이 로컬 엔드포인트를 외부 모델처럼 활용할 수 있다.

설정 방법은 해당 에이전트 도구의 API 엔드포인트를 http://127.0.0.1:8001/v1로, 모델명을 서버에서 지정한 alias로 변경하는 것이다. 자세한 연동 방법은 Unsloth의 Claude Code 가이드를 참고하라.

실무에서는 Qwen으로 야간 장시간 작업(코드 생성, 리팩토링 등)을 돌리고, Claude Opus 같은 프론티어 모델로 결과를 검증·교정하는 하이브리드 워크플로우를 사용하는 개발자들이 늘고 있다. 클라우드 API 비용을 최소화하면서 품질을 유지하는 실용적 전략이다.

12. 현재의 제약과 주의사항

Ollama 미지원 문제

현재 가장 큰 진입 장벽이다. Qwen 3.5의 멀티모달 비전 파일(mmproj)이 별도로 분리되어 있어 현재 Ollama에서 GGUF가 작동하지 않는다. ollama run qwen3.5와 같은 방식은 사용할 수 없으며, llama.cpp 호환 백엔드(llama-cli, llama-server)를 직접 사용해야 한다.

GitHub에서 관련 이슈가 추적되고 있으며(#14419, #14503), 하류 프로젝트들이 최신 llama.cpp를 반영할 때까지는 이 제약이 유지된다. Ollama에 익숙한 사용자라면 LM Studio를 대안으로 활용하는 것이 현실적이다.

환각(Hallucination) 문제

Qwen 3.5는 성능이 뛰어나지만 환각 문제에서 자유롭지 않다. 실무에서 Qwen 계열을 사용하는 개발자들은 “존재하지 않는 라이브러리 기능을 지어내는 빈도가 초기 GPT-4 수준과 비슷하다”고 경고한다. 특히 라이브러리 API 참조나 특정 버전에 의존하는 코드 생성 시 결과물을 반드시 검증해야 한다.

양자화 옵션의 복잡성

IQ4_XS, Q4_K_S, IQ4_NL, Q4_0, Q4_1, Q4_K_M, UD-Q4_K_XL처럼 다양한 양자화 변종이 존재하며, 각각의 트레이드오프에 대한 명확한 공식 설명이 부족하다. 가이드라인: Unsloth의 UD(다이내믹) 시리즈를 우선으로, 최소 UD-Q2_K_XL 이상을 권장한다.

GPU 오프로딩 환경별 편차

4GB VRAM의 구형 GPU(GTX 1650 Ti 등)에서 GPU 오프로딩 시 메모리 할당 오류가 보고되고 있다. --n-gpu-layers 값을 낮춰가며 시행착오가 필요한 상황이다. CPU 기반 작업은 문제없이 동작하는 경우가 많다.

Thinking 모드 기본 설정 혼란

Small 시리즈(0.8B~9B)에서 thinking이 기본 비활성화라는 점을 모르는 사용자가 많다. 또한 llama-server를 통해서만 토글할 수 있으며, llama-cli에서는 활성화가 불가능하다. 이 설정을 놓치면 모델 능력의 절반만 활용하게 된다.

13. Hacker News 커뮤니티 실사용 보고

공식 문서와 벤치마크 외에, Hacker News 토론(https://news.ycombinator.com/item?id=47292522)에서 수집된 실사용자 경험은 실전 배포 시 매우 유용한 정보를 담고 있다.

긍정적 보고:

  • ASUS RTX 5070Ti 16GB에서 9B 모델 100토큰/초 달성 — “소비자급 하드웨어에서 처음으로 진정 실용적인 경험”
  • 16GB VRAM에 27B 4비트 양자화가 들어가며, Sonnet 4.0(2025년 여름 기준) 수준의 품질 달성 가능
  • RTX 3090에서 ik_llama.cpp로 27B를 40토큰/초로 구동
  • M3 Air 24GB에서 35B-A3B 3비트를 14~22토큰/초로 구동

주의사항 보고:

  • Ollama에서 MoE 버전이 작동하지 않는 이슈(GitHub #14419, #14503) — 현재 llama.cpp 직접 사용 권장
  • Oh My Pi 같은 일부 코딩 에이전트 도구에서 35B-A3B 모델이 thinking 파라미터 전달 실패로 크래시하는 이슈
  • M3 Air 24GB에서 27B Dense는 2토큰/초에 불과 — 35B-A3B MoE와 극명한 속도 차이

아키텍처 관련 토론: 커뮤니티에서는 “왜 27B 양자화 모델이 훨씬 큰 Sonnet과 비슷한 품질이 될 수 있는가”에 대한 흥미로운 토론이 벌어졌다. 결론은 파라미터 수 증가의 수익 체감이 크게 작용하며, 모델의 “품질 인지도”는 규모보다 사후 훈련(post-training) 방법론에 더 크게 영향받는다는 것이다. 7B~12B 범위의 파인튜닝 모델이 프론티어 모델과 경쟁하는 사례가 연구 논문에서 반복적으로 보고되는 이유도 이 때문이다.

14. 모델 선택 가이드 및 결론

하드웨어별 권장 모델 요약

보유 장비권장 모델예상 속도
16GB VRAM GPU 또는 Mac9B (4비트, 6.5GB)~100토큰/초
24GB VRAM GPU 또는 24GB Mac35B-A3B (4비트, 22GB)~14~25토큰/초
64GB Mac35B-A3B (8비트) 또는 122B-A10B (저비트)환경별 상이
192GB+ RAM397B-A17B (3비트, 180GB)25토큰/초+
256GB Mac Ultra397B-A17B (4비트, 214GB)25토큰/초+

35B-A3B vs 27B 선택 기준

27B Dense는 SWE-bench 등 일부 코딩 벤치마크에서 35B-A3B보다 수치가 높지만, 실제 속도 차이가 매우 크다(M3 Air 24GB에서 2토큰/초 vs 14~22토큰/초). 특별히 정확도가 중요한 작업(예: 복잡한 수학 추론, 세밀한 코드 리뷰)이 아니라면 35B-A3B MoE가 압도적으로 유리한 선택이다.

로컬 LLM의 현재 좌표

Qwen 3.5는 로컬 LLM 생태계에서 세 가지 명확한 지점을 보여준다.

9B 구간: 이미 온라인 서비스를 능가하는 속도와 충분한 품질이 소비자 하드웨어에서 달성됐다.

35B MoE 구간: 코딩 벤치마크 기준 DeepSeek의 90% 수준에 도달하여, 대부분의 실무 작업에 투입 가능한 지점에 왔다. 클라우드 API 비용 없이, 데이터 프라이버시를 유지하면서, 밤새 에이전트 작업을 돌릴 수 있는 환경이 24GB Mac/GPU 소유자에게 현실화됐다.

397B 구간: 프론티어 모델과 동일한 성능 티어에 올랐지만, 192GB 이상의 RAM이 필요해 아직 일반 소비자 영역은 아니다. 고사양 워크스테이션이나 Mac Studio 사용자의 영역이다.

Ollama 미지원과 양자화 옵션의 복잡성 같은 마찰은 여전히 존재한다. 하지만 이는 시간이 해결할 문제다. 오픈 웨이트 LLM이 “쓸 만한 수준”을 넘어 “실무 경쟁력”을 갖추는 방향은 이미 확정됐으며, Qwen 3.5는 그 이정표를 가장 선명하게 보여준 릴리스다.

참고 자료

이 문서는 2026년 3월 15일 기준으로 작성되었습니다. llama.cpp 및 Ollama의 Qwen 3.5 지원 상황은 이후 변경될 수 있습니다.

AI, Model
AI Qwen unsloth-dynamic hybrid-reasoning lm-studio Claude.write
이 기사는 저작권자의 CC BY 4.0 라이센스를 따릅니다.