8GB 그래픽카드로 30B 코딩 LLM 돌리기: 45토큰/초 최적화 전 과정

2019년에 출시된 RTX 2070 SUPER(VRAM 8GB)와 6코어 CPU만으로 300억 파라미터급 코딩 모델을 초당 45토큰으로 구동하는 데 성공했다. 모델 전체를 VRAM에 올릴 수 없는 환경에서 어디까지 끌어올릴 수 있는지, 설정값 하나하나를 실측하며 찾은 결과와 실패한 시도까지 그대로 정리한다. 마지막에는 이 환경에서 생성한 테트리스 코드의 품질을 실제 실행 화면과 함께 검증했다.

실험에 사용한 최소 사양 시스템

의도적으로 평범한 조합을 사용했다. 고가의 GPU 없이 어디까지 가능한지가 이 실험의 목적이기 때문이다.

항목	사양
GPU	NVIDIA RTX 2070 SUPER (VRAM 8GB, 실사용 약 7.6GB)
CPU	Intel Core i5-12400F (6코어 / 12스레드)
RAM	32GB DDR5-5600 (싱글채널, 실측 대역폭 29.1GB/s)
추론 엔진	llama.cpp (CUDA 백엔드, 소스 빌드)
모델	Qwen3-Coder-30B-A3B-Instruct (UD-Q3_K_XL, 13.81GB)

최종 성능은 생성 45.07 tok/s, 프롬프트 처리 438.73 t/s다. 8GB VRAM에 13.81GB 모델이 들어갈 리 없는데도 이 속도가 나오는 이유는 아래에서 설명한다.

핵심은 MoE 부분 오프로드

먼저 일반적인 조밀(dense) 모델들을 같은 조건에서 측정했다. 결과는 냉정했다.

모델	방식	생성 속도
Qwen2.5-Coder-32B	덴스, 20레이어만 GPU	6.1 tok/s
Qwen2.5-Coder-14B	덴스, 41레이어 GPU	15~18 tok/s
Qwen2.5-Coder-7B	덴스, 전체 GPU	58~64 tok/s
Qwen3-Coder-30B-A3B	MoE 부분 오프로드	45 tok/s

32B 덴스 모델은 초당 6토큰으로 실사용이 불가능했고, 7B는 빠르지만 코드 품질이 떨어졌다. 해답은 전문가 혼합(Mixture of Experts, MoE) 구조였다. Qwen3-Coder-30B-A3B는 총 305억 파라미터지만 토큰 하나를 만들 때 실제로 활성화되는 것은 약 30억뿐이다. 즉 지식 용량은 30B급이면서 연산량은 3B급이다.

여기에 llama.cpp의 --n-cpu-moe 옵션을 쓰면 전문가 가중치 일부만 CPU/RAM에 남기고 어텐션 등 나머지는 GPU에 올릴 수 있다. 8GB VRAM에서 30B급 모델을 돌리는 핵심 장치다.

설정을 하나씩 실측한 과정

1단계 — 양자화를 낮출수록 빨라진다

보통 양자화는 용량 문제로만 생각하지만, 이 구성에서는 속도에 직결됐다. 매 토큰마다 CPU가 담당한 전문가 가중치를 RAM에서 읽어야 하므로, 가중치가 작아지면 그만큼 빨라진다.

양자화	크기	CPU에 남긴 레이어	생성 속도
Q4_K_M	18.56GB	36	37.5 tok/s
IQ4_XS	16.38GB	34	37.8 tok/s
UD-Q3_K_XL	13.81GB	32	43.2 tok/s

모델이 작아질수록 GPU에 더 많이 올라가고(CPU 담당 레이어 36→32), 읽어야 할 데이터도 줄어 이중으로 빨라진다. Unsloth의 UD(Dynamic) 계열 양자화는 중요한 텐서를 높은 정밀도로 유지해 3비트대에서도 품질 저하가 크지 않았다.

2단계 — 진짜 병목은 GPU가 아니라 메모리 대역폭

세 가지 독립적인 측정이 같은 결론을 가리켰다.

• 스레드를 늘려도 소용없다: 2→3코어에서 30% 빨라지지만, 5→6코어에서는 겨우 1.5%만 오른다. CPU 연산력이 남는데도 속도가 안 오른다는 뜻이다.
• 레이어당 비용이 완전히 선형: CPU에 남긴 전문가 레이어 하나당 정확히 0.448ms. 토큰당 25.6ms 중 15.2ms(약 60%)가 가중치를 읽는 시간이었다.
• 실측 대역폭이 이론치와 일치: 29.1GB/s로, DDR5-5600 싱글채널 이론 피크의 약 65%다.

여기서 나온 실용적 결론이 있다. 이 시스템은 RAM이 한 슬롯에만 꽂혀 싱글채널로 동작 중이다. 동일 규격 모듈을 하나 더 추가해 듀얼채널이 되면 대역폭이 두 배가 되어 50 tok/s 이상이 기대된다. CPU를 더 좋은 것으로 바꾸는 것보다 램 한 장 추가가 훨씬 효과적인 셈이다.

3단계 — 정확도를 좌우한 샘플링 설정

의외의 함정이 있었다. llama-server의 기본 샘플링 값은 코딩 에이전트용으로 지나치게 무작위하다.

파라미터	서버 기본값	Qwen3-Coder 권장값
temperature	0.80	0.70
top_p	0.95	0.80
top_k	40	20
repetition_penalty	1.00	1.05

기본값 그대로 두면 존재하지 않는 API나 폐기된 임포트 경로를 만들어낼 여지가 커진다. 속도 비용은 전혀 없으므로 반드시 지정하는 편이 좋다.

최종 실행 설정

llama-server \
  -m Qwen3-Coder-30B-A3B-Instruct-UD-Q3_K_XL.gguf \
  -ngl 99 -ncmoe 32 -fa on -t 6 -lm none \
  -c 36864 -ctk q8_0 -ctv q8_0 \
  --temp 0.7 --top-p 0.8 --top-k 20 --repeat-penalty 1.05 --min-p 0.0 \
  --host 127.0.0.1 --port 8080

• -ncmoe 32: 전문가 레이어 32개를 CPU에 남기고 나머지는 GPU로
• -lm none: 메모리 매핑 대신 전량 RAM 적재. 프롬프트 처리가 34% 빨라졌다
• -t 6: 물리 코어 수. 하이퍼스레딩(12스레드)을 켜면 오히려 11% 느려진다
• -fa on: Flash Attention. 품질 손실 없는 무료 속도 향상

실패한 시도들

효과가 있을 것 같았지만 실측에서 탈락한 방법들이다. 같은 시행착오를 반복하지 않도록 기록해둔다.

• 추측 디코딩(speculative decoding): 32B 덴스 모델에서는 효과가 있었지만, MoE에서는 오히려 45 → 17.3 tok/s로 느려졌다. 이미 CPU가 전문가 레이어 처리로 포화 상태인데 드래프트 모델까지 같은 코어를 두고 경쟁하기 때문이다.
• KV 캐시를 4비트로 낮추기: 컨텍스트를 33% 늘려주지만 생성 속도가 13.5% 느려졌다. Turing 세대 GPU에는 4비트 V캐시용 최적화 커널이 없어 역양자화 비용을 그대로 물기 때문이다.
• 텐서 단위 세밀 오프로드: 작은 컨텍스트에서는 3% 빨랐지만, 실제 운영 컨텍스트에서는 VRAM이 이미 포화라 메모리 부족으로 실행조차 되지 않았다.

Cline 연동 — 반드시 컨텍스트 한계를 알려줄 것

코딩 에이전트 Cline을 붙였을 때 반복적으로 다음 오류가 발생했다.

error: request (41403 tokens) exceeds the available context size (36864 tokens)

서버의 컨텍스트를 계속 늘려주는 것은 해법이 아니다. 요청 크기가 25,544토큰에서 41,403토큰으로 계속 커졌기 때문이다. 원인은 Cline이 자신의 컨텍스트 한계를 모른 채 대화를 무한정 쌓는 것이었다. Cline은 contextWindow 값을 받으면 그 값의 0.9 / 0.7 지점에서 대화를 자동으로 압축한다.

{
  "provider": "openai-compatible",
  "baseUrl": "http://127.0.0.1:8080/v1",
  "apiKey": "sk-no-key-required",
  "model": "Qwen3-Coder-30B-A3B-Instruct-UD-Q3_K_XL.gguf",
  "contextWindow": 36864,
  "maxTokens": 4096
}

이 방식은 서버 설정을 전혀 건드리지 않으므로 속도 손실이 없다. 반대로 서버의 컨텍스트를 65,536으로 늘려 해결하려면 CPU에 남기는 레이어를 늘려야 해서 속도가 9% 떨어진다.

한 가지 더. Cline은 샘플링 파라미터를 명시적으로 설정했을 때만 요청에 실어 보낸다. 따로 지정하지 않으면 앞서 언급한 서버 기본값이 그대로 적용되므로, 서버 쪽에서 권장값을 지정해두는 것이 중요하다.

실전 검증 — 테트리스를 만들어봤다

벤치마크 숫자만으로는 실제 쓸모를 알 수 없다. 그래서 채점 가능한 요구사항 9가지(7종 테트로미노, 월킥 회전, 라인 클리어와 점수, 다음 조각 미리보기, 레벨별 속도 증가, 게임오버 판정, 키보드 조작, 단일 파일, 상태 표시)를 명시해 테트리스 게임을 요청했다.

항목	결과
생성 토큰	3,687 토큰
소요 시간	93초
생성 속도	40.2 tok/s
결과물	515줄 HTML 단일 파일 (잘림 없이 정상 종료)

결과물은 한 번에 실행됐다. 레이아웃은 기대 이상이었다. 점수·레벨·라인 수 표시, 다음 조각 미리보기, 조작법 안내까지 갖춘 완성된 화면이 나왔다.

게임 로직도 정확했다. 7종 테트로미노의 형상 배열이 모두 표준과 일치했고, 월킥 회전·라인 클리어·하드드롭·레벨별 낙하 속도 증가가 모두 구현돼 있었다.

그런데 실행해보니 결함이 있었다

실제로 플레이해보니 명백한 버그가 드러났다. 바닥에 쌓인 조각은 색이 정상인데, 현재 떨어지는 조각과 다음 조각 미리보기만 배경과 같은 어두운 색으로 보이지 않았다.

원인은 같은 파일 안에서 CSS 클래스명을 만드는 방식이 두 갈래로 엇갈린 것이었다. CSS에는 .piece-I부터 .piece-L까지 문자 기반 클래스만 정의돼 있는데,

• drawBoard()는 배열 인덱스로 piece-I 같은 올바른 클래스를 만든다 → 쌓인 조각은 정상
• drawPiece()와 drawNextPiece()는 color.replace('#', 'piece-')로 piece-ffff00을 만든다 → CSS에 없는 클래스라 색이 적용되지 않음

문법 오류도 아니고 실행도 멈추지 않는, 사람이 코드 리뷰로 잡아야 하는 종류의 결함이다. 다만 515줄 중 문제는 2줄이었고, 클래스 생성 방식을 drawBoard()와 통일하자 즉시 정상 동작했다.

자주 묻는 질문

8GB VRAM으로 정말 30B 모델을 돌릴 수 있나요?

가능하다. 단 조건이 있다. 조밀(dense) 모델이 아니라 MoE 구조여야 하고, llama.cpp의 전문가 오프로드 기능을 써야 한다. 이 실험에서는 13.81GB 모델의 전문가 레이어 32개를 CPU/RAM에 남기고 나머지를 GPU에 올려 45 tok/s를 얻었다. 32GB 이상의 시스템 RAM이 사실상 필수다.

속도를 더 올리려면 무엇을 바꿔야 하나요?

이 구성에서는 GPU도 CPU도 아닌 메모리 대역폭이 병목이다. 실측 결과 CPU 코어를 더 써도 속도가 오르지 않았다. 램이 싱글채널이라면 같은 규격 한 장을 추가해 듀얼채널로 만드는 것이 가장 효과적이다. 대역폭이 두 배가 되면 CPU가 담당하는 구간의 시간이 절반으로 줄어든다.

3비트 양자화를 써도 코드 품질이 괜찮은가요?

이번 테트리스 생성에서는 7종 테트로미노 형상, 회전 로직, 라인 클리어, 점수 계산이 모두 정확했다. 다만 발견된 버그처럼 같은 파일 안에서 규칙이 일관되지 않는 종류의 실수는 나올 수 있다. 생성된 코드를 그대로 신뢰하지 말고 반드시 실행해보고 검토해야 한다.

클라우드 API 대신 로컬로 쓸 만한가요?

용도를 나누는 것이 현실적이다. 보안이 중요한 내부 코드 처리, 단일 함수 작성, 반복적인 변환 작업에는 로컬 모델이 충분하다. 반면 여러 파일이 얽힌 복잡한 리팩터링이나 아키텍처 설계는 여전히 상위 모델이 낫다. 무제한·무료·오프라인이라는 장점이 분명하므로 일상 작업의 상당 부분을 넘길 수 있다.

맺음말

8GB VRAM이라는 제약은 생각보다 큰 장애물이 아니었다. MoE 구조와 부분 오프로드, 적절한 양자화 선택만으로 30B급 모델을 초당 45토큰으로 돌릴 수 있었다. 다만 이 과정에서 얻은 가장 중요한 교훈은 병목이 예상과 달랐다는 점이다. GPU를 탓하기 전에 메모리 대역폭을 측정해볼 필요가 있다. 그리고 생성된 코드는 아무리 그럴듯해 보여도 반드시 실행해봐야 한다는 것도.