16GB GPU에서 돌린 2비트 Qwen 27B, 웹 앱은 거뜬하고 3D는 아쉬움

270억 개 parameter(모델이 학습으로 익힌 값)를 가진 Qwen3.8 27B를 2비트까지 줄인 Qwen3.8-27B-Escha-W2가 16GB 메모리의 그래픽카드 한 장에서 웹 앱, 게임, 3D 모델을 만드는 개발 과제 다섯 가지를 모두 해냈습니다. 가중치 크기는 약 10GB로 줄었고, 256k token 길이의 문서 속에 숨긴 암호를 15번 모두 찾아냈으며, 코딩 문제 100개 가운데 75개를 통과했습니다. 다만 3D 결과물의 완성도와 특정 게임 엔진 코드에서는 2비트 양자화(quantization, 모델의 숫자 정밀도를 낮춰 크기를 줄이는 방법)의 한계도 드러났습니다. 메모리가 넉넉하지 않은 컴퓨터로 큰 로컬 모델을 돌리려는 사람에게 어떤 판단 기준을 주는지 시험 결과로 정리합니다.

27B 모델을 10GB로 줄인 2비트 모델

Qwen3.8-27B-Escha-W2는 Qwen3.8 27B를 2비트로 양자화하고 fine-tuning(이미 학습한 모델을 특정 목적에 맞게 더 학습시키는 방법)한 모델입니다. 원래 가중치는 10.15GB이고, 16GB나 24GB 메모리의 소비자용 그래픽카드에 올려도 context(모델이 한 번에 참고하는 입력)를 담을 공간이 넉넉히 남습니다.

llama.cpp에서 쓸 수 있는 GGUF 형식으로 바꾼 파일은 Hugging Face에 두 가지로 올라와 있습니다.

정밀도 차이가 거의 없으므로 시험에는 Q8_0 빌드를 썼습니다. 2.93GB짜리 MTP(multi-token prediction, 여러 token을 미리 예측해 생성을 빠르게 하는 보조 모델) 초안 모델도 제공되지만, 16GB 그래픽카드에서는 context에 쓸 메모리를 아끼려고 붙이지 않았습니다.

시험 환경과 아홉 가지 과제

시험은 Ubuntu Server 24.04.4를 설치한 컴퓨터에서 llama.cpp로 모델을 띄워 진행했습니다. CPU는 AMD Ryzen 5700X, 시스템 메모리는 DDR4 32GB입니다. 모델은 16GB 메모리의 NVIDIA RTX 2000 Ada에서 돌렸고, 함께 꽂은 RTX 5090은 시험 자동화에만 썼습니다.

과제는 아홉 가지입니다. 처리 속도와 긴 context 기억력을 먼저 재고, 단계별 추론 문제와 코딩 문제 100개를 풀게 한 뒤, Kanban 보드 웹 앱, 모래 물리 시뮬레이션, 던전 탐험 게임을 만들게 했습니다. 마지막으로 MCP(Model Context Protocol, AI가 외부 도구를 다루게 하는 표준)로 Blender와 Godot을 조작하는 agent 과제를 맡겼습니다.

▲ 로컬 모델의 아홉 가지 시험

속도는 메모리 대역폭이 정한다

생성 속도가 초당 11 token 남짓에 그친 까닭은 주로 그래픽카드에 있는 것으로 보입니다. RTX 2000 Ada는 70W로 전력 효율을 앞세운 워크스테이션용 카드라 메모리 대역폭이 초당 225~250GB에 그칩니다. 전력 한도와 메모리 대역폭이 더 큰 RTX 30·40·50 시리즈의 16GB 데스크톱 카드, 예를 들어 RTX 4080이나 RTX 4070 Ti Super라면 생성 속도가 훨씬 빠를 것으로 예상됩니다.

긴 문서 기억과 추론, 코딩 점수

기억력 시험은 Needle-in-a-Haystack 방식입니다. context를 256,608 token까지 늘리고 문서의 0%, 25%, 50%, 75%, 100% 깊이에 비밀 암호를 숨긴 뒤 깊이마다 세 번씩, 모두 15번 찾게 했습니다. 56분 36초 동안 15번 모두 정답을 내 통과율 100%를 기록했습니다. 다만 답 앞뒤에 생각하는 과정과 군더더기 문장이 붙었고, 깊은 위치일수록 답이 조금 더 길고 어수선해졌습니다. 정답을 뽑아내는 정확도에는 영향이 없었습니다.

HumanEval Remix는 OpenAI의 HumanEval benchmark를 바탕으로 만든 Python 코딩 문제 100개입니다. 1시간 8분 걸렸고 문항당 평균 응답 시간은 41,067ms였습니다. 추론 79%와 코딩 75%는 2비트까지 줄인 이 크기의 모델로서는 탄탄한 결과로 볼 수 있습니다. 전문가 난이도에서 점수가 크게 떨어지는 점은 어려운 논리 문제를 맡길 때 염두에 둘 만합니다.

실제 개발 과제: 웹 앱과 게임은 수월, 3D는 아쉬움

Kanban 보드는 카드 끌어 옮기기, 열 순서 바꾸기, 카드 편집 창, 우선순위 표시, 밝은·어두운 테마 전환이 모두 작동했습니다. 처음 만든 코드에서 열 추가 버튼에 클릭 이벤트를 연결하지 않은 것이 유일한 결함이었고, 버튼이 반응하지 않는다고 알려 주자 모델이 원인을 찾아 바로 고쳤습니다. 화면 디자인은 무난한 수준이지만 기능 코드의 품질은 높았습니다.

모래 물리 시뮬레이션은 cellular automata(칸마다 규칙에 따라 상태가 바뀌는 계산 모형) 방식으로, 모래가 쌓이고 물이 경사를 따라 흐르며 산이 벽과 모래를 녹이는 상호작용을 첫 시도에 구현했습니다. 던전 탐험 게임도 BSP(공간을 사각형으로 반복해 나누는 방법)로 방과 통로를 만들고, Bresenham 직선 알고리즘으로 플레이어 주변 9칸까지 시야를 계산해 안개를 걷어 내는 기능을 추가 요청 없이 완성했습니다.

▲ 게임 구현과 3D 결과물의 차이

MCP 과제에서는 2비트 양자화의 한계가 보였습니다. Blender로 만든 랜턴은 육각형 틀과 뾰족한 지붕, 고리, 내부 광원을 갖췄지만 안쪽이 지나치게 밝고 위쪽 고리가 장식에 파고들었습니다. 작업 중 장면을 저장하고 화면 없이 Blender를 실행하려다 같은 시도를 되풀이하는 데 갇혀, 사람이 렌더링 결과를 보여 달라고 요청한 뒤에야 넘어갔습니다. Godot 게임은 조작 방향이 거꾸로였고 구덩이를 덮은 물체에 충돌 판정이 없었으며, Godot 4에 없는 속성을 써서 스크립트 오류가 났습니다. 세 번 고쳐 달라고 요청한 끝에 열쇠를 모으고 움직이는 장애물을 피해 목표에 닿는 게임이 완성됐습니다.

16GB 그래픽카드로 큰 모델을 돌릴 때 기억할 것

이 시험 결과로 보면 2비트 양자화 모델은 메모리가 16GB인 그래픽카드 한 장으로 27B 모델을 돌려야 하는 사람에게 충분히 고려할 만한 선택지로 보입니다. 시스템 메모리로 넘기지 않고 그래픽카드 안에서 모두 돌아가며, 긴 문서 검색과 일반적인 웹 개발에서는 성능 손실을 크게 느끼기 어렵습니다. 반대로 시각적 완성도가 중요한 3D 작업이나 특정 프레임워크 문법을 정확히 지켜야 하는 코드는 Q4나 Q5 양자화가 눈에 띄게 낫습니다.

로컬 모델을 고르고 설정할 때 다음을 확인하면 좋습니다.

• 16GB 그래픽카드에서는 F16보다 Q8_0 embed·head 빌드를 골라 2GB 넘는 메모리를 아낍니다.
• 메모리가 빠듯하면 MTP 초안 모델을 붙이지 않고 그만큼 context에 씁니다.
• 생성 속도는 그래픽카드의 메모리 대역폭에 크게 좌우되므로 카드의 사양부터 확인합니다.
• 웹 앱의 작은 결함은 어떤 버튼이 반응하지 않는지처럼 증상을 구체적으로 알려 주면 빠르게 고쳐집니다.
• MCP 작업에서 모델이 같은 명령을 되풀이하면 중간에 끊고 결과 파일을 직접 보여 달라고 요청합니다.
• Godot 4처럼 버전마다 문법이 다른 도구의 코드는 없는 속성을 쓰지 않았는지 꼭 확인합니다.