TL;DR
Qwen3 35B A3B(MoE)는 32GB VRAM 환경에서 구동 가능한 로컬 LLM 중 현재 가장 주목할 만한 선택지로 부상했다. 다만 이번 실험에서 비교한 4개 모델(Qwen3 35B A3B, Qwen3 27B, Gemma 4 26B A4B, Nemotron 3 Nano) 모두 인상적인 성능을 보였으며, 단순히 Qwen3 35B A3B만을 추천하는 것은 원문의 취지를 벗어난다. 장문맥 처리를 위한 Gated Delta Net, Hybrid Mamba2, Sliding Window Attention 등의 아키텍처 혁신이 소형 모델의 코드 이해 능력을 실질적으로 끌어올렸다. 단, 이 평가는 1명의 사용자가 약 2일간 특정 학술 도메인 코드 이해 태스크에 국한하여 진행한 개인 실험임을 전제해야 한다.
배경: 소형 로컬 LLM의 르네상스
불과 수개월 전까지만 해도 32GB VRAM 이하 환경에서 구동 가능한 로컬 LLM은 복잡한 코드베이스 이해에 명확한 한계를 드러냈다. 16GB 단일 GPU로는 긴 컨텍스트를 수용하는 것 자체가 어려웠고, 결과적으로 모델이 참조할 수 있는 정보의 양이 제한되었다.
Reddit의 LocalLLaMA 커뮤니티에 올라온 해당 스레드는 이러한 상황이 달라졌음을 시사한다. 저자는 2개의 GPU(총 32GB VRAM)로 업그레이드한 후, 아래 네 모델을 대상으로 약 2일간 실험을 진행했다.
- Qwen3 35B A3B (MoE, 35B 총 파라미터 / 3B 활성화)
- Qwen3 27B (Dense, 27B 파라미터)
- Gemma 4 26B A4B (MoE, 26B 총 파라미터 / 4B 활성화)
- Nemotron 3 Nano (NVIDIA Nemotron 시리즈의 소형 모델. 원문에서 정확한 파라미터 크기가 명시되지 않았으며, 공개 정보 기준으로는 약 8B 파라미터로 추정되나 확인이 필요하다.)
테스트 방법론은 단순하지만 실용적이다. 학술 논문 원문과 해당 논문을 구현한 코드를 동시에 모델에 제공하고, “이 코드가 논문의 어느 부분에 대응하는지 설명하라”는 태스크를 부여했다. 저자의 연구 분야가 LLM 학습 데이터에 거의 포함되어 있지 않을 것으로 추정되는 틈새 영역이라는 점에서, 단순 암기가 아닌 실질적인 추론 능력을 측정하는 데 유리한 설계다.
4개 모델 비교: 모두 “incredible”했다
원문 저자는 4개 모델 모두 이전 세대 대비 눈에 띄게 향상된 성능을 보였다고 평가했다. 포스트 제목이 Qwen3 35B A3B에 집중되어 있지만, 원문의 핵심 메시지는 “32GB VRAM 환경 전반의 르네상스”에 가깝다. 아래 비교표는 공개된 정보와 원문의 정성적 평가를 종합한 것이다.
| 모델 | 구조 | 총 파라미터 | 활성 파라미터 | 컨텍스트 길이 | 공개 벤치마크 (HumanEval) | 원문 정성 평가 |
|---|---|---|---|---|---|---|
| Qwen3 35B A3B | MoE | 35B | ~3B | 128K | ~85% (추정, 공식 미발표) | 최상위, 장문맥 코드 이해 탁월 |
| Qwen3 27B | Dense | 27B | 27B | 128K | ~82% (추정) | 우수, 일관된 응답 품질 |
| Gemma 4 26B A4B | MoE | 26B | ~4B | 128K | ~78% (추정) | 우수, 특정 태스크에서 강점 |
| Nemotron 3 Nano | Dense | ~8B (미확인) | ~8B | 미확인 | 미발표 | 양호, 경량 대비 준수한 성능 |
⚠️ 주의: HumanEval 수치는 원문에 포함되지 않은 추정치이며, 공식 발표 전까지는 참고용으로만 활용해야 한다. SWE-bench 등 코드 생성 특화 벤치마크에서의 공식 비교는 아직 충분히 이루어지지 않았다. Nemotron 3 Nano의 파라미터 크기는 원문에서도 명시되지 않았으며, NVIDIA 공식 문서를 통한 별도 확인이 필요하다.
Qwen3 35B A3B가 장문맥 코드 이해 태스크에서 가장 두드러진 성능을 보인 것은 사실이나, 다른 모델들도 각자의 영역에서 충분히 경쟁력 있는 선택지다. 특히 Qwen3 27B(Dense)는 MoE 특유의 전문가 라우팅 오버헤드 없이 안정적인 응답을 제공한다는 점에서 서빙 환경에 따라 더 유리할 수 있다.
핵심 메커니즘: 장문맥 처리 아키텍처의 진화
소형 모델의 성능 향상을 견인한 핵심은 장문맥(Long Context) 처리 아키텍처의 다양화다. 기존 Transformer의 Self-Attention은 시퀀스 길이 $n$에 대해 $O(n^2)$ 복잡도를 가지므로, 컨텍스트가 길어질수록 메모리와 연산 비용이 급격히 증가한다.
이를 해결하기 위한 세 가지 접근법이 현재 주목받고 있다.
Sliding Window Attention (SWA)
각 토큰이 전체 시퀀스가 아닌 고정 크기의 윈도우 내 토큰에만 어텐션을 계산한다. Mistral 계열이 채택한 방식으로, 메모리 복잡도를 $O(n \cdot w)$ ($w$: 윈도우 크기)로 줄인다. 단, 윈도우 밖의 장거리 의존성은 레이어를 거쳐 간접적으로만 전파된다.
Hybrid Mamba2
SSM(State Space Model) 기반의 Mamba 아키텍처는 선형 시간 복잡도로 시퀀스를 처리한다. Hybrid 구성에서는 Mamba 레이어와 Attention 레이어를 혼합하여 장거리 의존성 포착과 연산 효율을 동시에 확보한다. Recurrent 구조이므로 추론 시 KV 캐시 대신 고정 크기의 상태 벡터만 유지한다.
Gated Delta Net
Delta Net의 핵심은 연상 기억(Associative Memory) 관점에서 어텐션을 재해석하는 것이다. 기존 선형 어텐션의 한계였던 표현력 부족을 게이팅 메커니즘으로 보완한다. 수식으로 표현하면:
$$h_t = (1 – \alpha_t) \cdot h_{t-1} + \alpha_t \cdot (k_t^T v_t)$$
여기서 $\alpha_t$는 입력에 의존하는 게이트로, 이전 상태를 얼마나 유지할지를 동적으로 결정한다. 이를 통해 선형 복잡도를 유지하면서도 선택적 망각과 기억이 가능해진다.
아래 코드는 개념 이해를 위한 단순화된 참고용 구현이다. 실제 프로덕션 수준의 Gated Delta Net과는 차이가 있으며, 직접 실행보다는 동작 원리 파악 용도로 활용하길 권장한다.
# Gated Delta Net의 개념적 구현 (단순화된 참고용 — 프로덕션 코드 아님)
# 주의: h의 shape을 (B, D, D)로 설정하여 key-value 외적을 저장하는 구조이나,
# 실제 구현에서는 헤드 분할, 정규화, 스케일링 등이 추가로 필요합니다.
import torch
import torch.nn as nn
class GatedDeltaNet(nn.Module):
def __init__(self, d_model: int):
super().__init__()
self.q_proj = nn.Linear(d_model, d_model)
self.k_proj = nn.Linear(d_model, d_model)
self.v_proj = nn.Linear(d_model, d_model)
self.gate_proj = nn.Linear(d_model, 1) # 스칼라 게이트로 단순화
def forward(self, x: torch.Tensor) -> torch.Tensor:
B, T, D = x.shape
q = self.q_proj(x) # (B, T, D)
k = self.k_proj(x) # (B, T, D)
v = self.v_proj(x) # (B, T, D)
# 입력 의존적 게이트: 이전 상태 유지 비율 결정 (스칼라로 단순화)
alpha = torch.sigmoid(self.gate_proj(x)) # (B, T, 1)
# h: key-value 외적을 누적하는 연상 기억 행렬 (B, D, D)
h = torch.zeros(B, D, D, device=x.device)
outputs = []
for t in range(T):
# Delta 업데이트: 현재 k-v 외적으로 연상 기억 갱신
delta = torch.einsum('bd,be->bde', k[:, t], v[:, t]) # (B, D, D)
h = (1 - alpha[:, t]) * h + alpha[:, t] * delta
# 쿼리로 현재 메모리에서 값 검색
out = torch.einsum('bd,bde->be', q[:, t], h) # (B, D)
outputs.append(out)
return torch.stack(outputs, dim=1) # (B, T, D)
실제 배포: vLLM으로 Qwen3 35B A3B 서빙하기
이론보다 실용이 중요한 독자를 위해, 실제 환경에서 바로 사용할 수 있는 배포 예제를 제시한다. 아래는 2×16GB GPU(총 32GB VRAM) 환경을 전제로 한다.
사전 요구사항
# Python 3.10+, CUDA 12.1+ 환경 권장
pip install vllm>=0.4.0
vLLM 서버 실행
# Qwen3 35B A3B MoE 모델 서빙 (tensor_parallel_size=2: GPU 2장 분산)
python -m vllm.entrypoints.openai.api_server \
--model Qwen/Qwen3-35B-A3B \
--tensor-parallel-size 2 \
--max-model-len 32768 \
--dtype bfloat16 \
--gpu-memory-utilization 0.90 \
--port 8000
--max-model-len 32768: 32K 컨텍스트로 제한하면 32GB VRAM 내에서 안정적으로 동작한다. 128K 풀 컨텍스트는 추가 메모리가 필요하다.
Docker Compose로 배포
# docker-compose.yml
version: "3.9"
services:
vllm-qwen3:
image: vllm/vllm-openai:latest
runtime: nvidia
environment:
- NVIDIA_VISIBLE_DEVICES=0,1
- HF_TOKEN=${HF_TOKEN}
command: >
--model Qwen/Qwen3-35B-A3B
--tensor-parallel-size 2
--max-model-len 32768
--dtype bfloat16
--gpu-memory-utilization 0.90
--port 8000
ports:
- "8000:8000"
volumes:
- ~/.cache/huggingface:/root/.cache/huggingface
deploy:
resources:
reservations:
devices:
- driver: nvidia
count: 2
capabilities: [gpu]
# 실행
HF_TOKEN=your_token docker compose up -d
llama.cpp로 경량 배포 (단일 GPU 또는 CPU 오프로드)
# GGUF 모델 다운로드 (Q4_K_M 양자화 권장)
# huggingface-cli download Qwen/Qwen3-35B-A3B-GGUF --include "*.Q4_K_M.gguf"
./llama-server \
-m Qwen3-35B-A3B-Q4_K_M.gguf \
--n-gpu-layers 40 \
--ctx-size 32768 \
--threads 8 \
--port 8080
API 호출 예시
from openai import OpenAI
client = OpenAI(base_url="http://localhost:8000/v1", api_key="dummy")
response = client.chat.completions.create(
model="Qwen/Qwen3-35B-A3B",
messages=[
{"role": "user", "content": "이 코드가 논문의 어느 부분에 대응하는지 설명해줘:\n\n[코드 및 논문 내용]"}
],
max_tokens=2048,
temperature=0.7,
)
print(response.choices[0].message.content)
참고: 예상 메모리 사용량
| 설정 | 예상 VRAM 사용량 | 컨텍스트 길이 |
|---|---|---|
| bfloat16, ctx=32K | ~28–30GB | 32,768 토큰 |
| bfloat16, ctx=16K | ~24–26GB | 16,384 토큰 |
| Q4_K_M (llama.cpp), ctx=32K | ~20–22GB | 32,768 토큰 |
실제 수치는 배치 크기, 시스템 구성에 따라 달라질 수 있다. 공식 vLLM 문서 및 Qwen3 모델 카드를 함께 참조하길 권장한다.
한국 개발 환경에서의 시사점
카카오, 네이버, 토스 등 국내 테크 기업에서는 온프레미스 또는 프라이빗 클라우드 환경에서 코드 어시스턴트를 운용하는 수요가 꾸준히 존재한다. 특히 내부 코드베이스나 사내 문서를 외부 API에 전송할 수 없는 보안 제약이 있는 팀에서, 32GB VRAM 수준의 로컬 GPU 서버로 Qwen3 35B A3B 수준의 성능을 확보할 수 있다는 점은 실질적인 옵션이 된다.
MoE(Mixture of Experts) 구조 덕분에 35B 총 파라미터 중 실제 추론 시 활성화되는 파라미터는 약 3B에 불과하다. 이는 추론 속도와 메모리 효율 측면에서 동급 Dense 모델 대비 유리하며, 위에서 제시한 vLLM이나 llama.cpp 기반의 서빙 스택에서도 비교적 수월하게 배포할 수 있다.
한계: 이 실험이 말해주지 않는 것
이 평가를 액면 그대로 받아들이기 전에 몇 가지 제약을 명확히 해야 한다.
첫째, 표본 크기와 실험 기간. 가장 근본적인 한계다. 이 실험은 단 1명의 사용자가 약 2일간 진행한 것이다. 통계적 신뢰성을 논하기 어려운 수준이며, 동일한 결과가 다른 사용자, 다른 도메인, 더 긴 기간에서 재현된다는 보장이 없다.
둘째, 도메인 편향. 저자 본인이 인정하듯, 테스트에 사용된 코드와 논문은 매우 특화된 학술 영역에 속한다. 일반적인 웹 서비스 백엔드 코드나 데이터 파이프라인 작업에서 동일한 우위가 재현된다는 보장이 없다.
셋째, 비교 기준의 부재. 이전 최고 성능 모델로 언급된 Devstral Small 2(24B)는 32GB VRAM에서 긴 컨텍스트를 수용하지 못해 재테스트가 불가능했다. 공정한 조건의 A/B 비교가 이루어지지 않았다.
넷째, 객관적 지표 미제시. 제목의 “hype is real”은 저자의 주관적 감탄에 가깝다. HumanEval, SWE-bench 같은 공개 벤치마크 수치가 아닌 정성적 인상 평가이며, 상세 결과는 외부 GitHub 링크에만 공개되어 있다. 공개 벤치마크에서 Qwen3 35B A3B의 공식 수치가 발표되면 이 정성 평가와 교차 검증하는 것이 바람직하다.
다섯째, 인간-AI 협력 가설의 검증 어려움. 저자는 “인간과 로컬 모델의 협력이 Claude Opus 단독보다 우수하다”고 주장하지만, 이는 특정 작업 스타일과 전문성을 전제로 한 개인적 판단이다.
여섯째, Nemotron 3 Nano 파라미터 미확인. 원문에서도 정확한 파라미터 크기가 명시되지 않았다. 공개 정보 기준 약 8B로 추정되나, NVIDIA 공식 문서를 통한 확인이 필요하며 이 불확실성이 비교 분석의 정확도를 제한한다.
결론
Qwen3 35B A3B를 비롯한 최신 소형 로컬 LLM의 성능 향상은 단순한 파라미터 증가가 아닌, 아키텍처 수준의 장문맥 처리 혁신에 기반한다. Gated Delta Net, Hybrid Mamba2, Sliding Window Attention은 각각 다른 방식으로 $O(n^2)$ 어텐션의 병목을 완화하며, 이것이 제한된 VRAM 환경에서도 충분한 컨텍스트를 활용할 수 있게 한다.
중요한 것은 이번 실험에서 비교된 4개 모델 모두가 이전 세대 대비 실질적인 도약을 보였다는 점이다. Qwen3 35B A3B가 장문맥 코드 이해 태스크에서 두드러졌지만, Qwen3 27B, Gemma 4 26B A4B, Nemotron 3 Nano 역시 각자의 강점을 가진 선택지다.
다만 이 실험은 단 1명의 사용자가 2일간 진행한 특정 도메인 평가이며, HumanEval이나 SWE-bench 같은 벤치마크 수치로 뒷받침되지 않는다. 실제 도입 여부는 자신의 워크로드에 맞는 직접 검증을 거쳐야 한다. 아키텍처 트렌드 자체는 주목할 만하며, Mistral을 포함한 다른 플레이어들이 유사한 방향으로 소형 모델을 개선할 경우 로컬 LLM 생태계의 실용성은 더욱 높아질 것으로 전망된다.
출처: The Qwen 3.6 35B A3B hype is real!!! — Reddit LocalLLaMA