VRAM 12Gb 그래픽카드로 23GiB LLM을 돌리면?

Caston 8월 30, 2026 1 min read

집에 있는 그래픽카드에 AI 모델을 올려보려다 “메모리가 부족합니다”에서 막혀본 적이 있다면, 아마 이렇게 결론 내렸을 것이다. 카드에 달린 메모리보다 큰 모델은 못 돌린다고. 실제로 대부분의 안내문이 그렇게 적혀 있다. 그래픽카드 메모리가 12기가면 12기가보다 작은 파일을 받으라는 식이다.

그런데 지난 주말에 12기가짜리 그래픽카드로 23기가짜리 모델을 돌렸다. 두 배 크기다. 게다가 초당 32개 단어를 뱉는다. 사람이 눈으로 읽는 속도보다 빠르다.

조건이 하나 있는데, 그 조건을 모르면 같은 카드에서 초당 6개밖에 안 나온다. 다섯 배 차이가 설정값 하나에서 갈린다.

이 글은 원래 다른 걸 쓰려고 시작했다. “로컬 LLM 프로그램 중 뭐가 제일 빠른가”를 재보려 했다. 여기서 로컬 LLM이란 챗GPT처럼 인터넷 너머 회사 서버를 쓰는 게 아니라, 내 컴퓨터 안에서만 도는 AI를 말한다. 인터넷이 끊겨도 되고 요금도 안 나가고 내가 쓴 내용이 밖으로 안 나간다.

그런데 자료를 모으다 보니 그 질문이 성립하지 않았다. 사람들이 흔히 비교하는 오라마(Ollama), LM 스튜디오, 잔(Jan), GPT4All은 llama.cpp라는 똑같은 엔진을 안에 넣고 겉모습만 다르게 씌운 프로그램들이다. 자동차 네 대에 같은 엔진을 얹어놓고 배기음을 비교하는 셈이다.

실제로 다른 사람이 잰 수치를 봐도 순수 엔진이 초당 77개, 오라마가 69개, LM 스튜디오가 76.8개였다. 순위표를 만들 만한 차이가 아니다.

그래서 더 쓸모 있는 질문으로 바꿨다. 내 그래픽카드에 얼마나 큰 모델을, 몇 개의 속도로 올릴 수 있는가. 로컬 AI를 돌리는 사람이 실제로 부딪히는 벽은 “어느 프로그램이 5퍼센트 빠른가”가 아니라 “이건 내 카드에 안 들어간다”이기 때문이다.

실험에 쓴 장비

부품	사양
중앙처리장치(CPU)	AMD 라이젠 5 9600X, 6코어
그래픽카드(GPU)	엔비디아 RTX 3080 Ti, 메모리 12기가
주 메모리(RAM)	DDR5 32기가
운영체제	윈도우 11

여기서 그래픽카드 메모리를 흔히 브이램(VRAM)이라고 부른다. 컴퓨터 본체에 꽂는 일반 메모리와는 다른 물건이고, AI 모델은 이 브이램에 통째로 올라가야 제 속도가 난다. 그래서 브이램 용량이 곧 “얼마나 큰 모델을 쓸 수 있나”의 상한선으로 여겨져 왔다.

측정에 쓴 모델은 세 개다. 첫 번째는 알리바바가 만든 Qwen3의 30B 모델로 17.28기가, 나머지 둘은 GLM-4.7-Flash를 각각 20.08기가와 23.11기가로 압축한 버전이다. 같은 모델을 다른 강도로 압축하면 파일 크기가 달라지는데, 이걸 양자화라고 부른다. 사진을 JPEG로 저장할 때 화질을 조절하는 것과 비슷하다고 보면 된다. 셋 다 브이램 12기가보다 크고, 가장 큰 건 두 배다.

이게 가능한 원리는 MoE와 오프로드 덕분이다. MoE는 “전문가 혼합”이라는 뜻인데, 모델 안에 작은 전문가 수백 명을 두고 질문마다 그중 몇 명만 불러 쓰는 구조다. 그래서 전체 크기가 30기가여도 단어 하나를 만들 때 실제로 일하는 부분은 3기가 남짓이다. 나머지 전문가들은 그 순간 놀고 있다.

여기서 요령이 나온다. 매번 반드시 돌아야 하는 부분은 빠른 그래픽카드 메모리에 두고, 가끔만 불려 나오는 거대한 전문가 무리는 느리지만 널널한 본체 메모리로 내보내는 것이다. 이걸 오프로드라고 한다. 짐을 다 트렁크에 넣으려다 안 들어가니, 자주 쓰는 것만 앞자리에 두고 나머지를 뒷좌석으로 옮기는 것과 같다.

중요한 건 이 요령이 MoE 모델에서만 통한다는 점이다. 흔히 쓰는 일반 모델은 단어 하나를 만들 때마다 모든 부분이 다 계산에 참여하기 때문에, 느린 곳으로 내보낼 “잘 안 쓰이는 덩어리”가 애초에 없다. 그래서 모델을 고를 때 이름에 MoE가 붙었는지부터 확인해야 한다.

실제로 따라해보기

준비물은 llama.cpp의 윈도우용 실행 파일 하나다. 깃허브 배포 페이지에서 CUDA 버전을 받아 압축을 풀면 설치랄 것도 없이 끝난다. 그다음 파워셸에서 아래와 같이 입력하면 된다.

llama-server -m 모델파일.gguf -ngl 99 --n-cpu-moe 20 -fa

핵심은 맨 뒤의 숫자 20이다. 전문가 무리를 몇 겹이나 본체 메모리로 내보낼지를 정한다. 앞의 99는 그대로 두면 된다. 여기서 자주 헷갈리는데, 우리가 옮기는 건 모델의 층이 아니라 전문가다. 앞의 숫자를 만지면 오히려 설정이 꼬인다.

그럼 저 숫자를 얼마로 두는 게 좋을까. 이걸 재려다 두 번 틀렸고 두 번 다 데이터를 버렸다. 처음에는 여러 숫자를 한 번에 나열해서 측정 프로그램에 넘겼다. 편하긴 한데, 17기가짜리 파일을 연달아 읽으면 운영체제가 파일을 임시로 담아두는 공간의 상태가 매번 달라지고 그게 그대로 결과에 섞인다. 같은 설정인데 회차에 따라 초당 23.6개와 32.6개가 나왔다.

결국 설정 하나마다 프로그램을 완전히 새로 띄우고, 전체를 두 번 독립적으로 반복해서 다시 쟀다. 그랬더니 처음에 최고 기록이라고 믿었던 초당 58.14개가 실제로는 70.09개였다. 측정 방식 하나 때문에 20퍼센트를 그냥 잃고 있었던 것이다.

두 번째로 몰랐던 건 윈도우의 조용한 뒷처리다. 엔비디아 드라이버에는 그래픽카드 메모리가 모자라면 실패를 알리는 대신 슬그머니 본체 메모리를 빌려 쓰는 기능이 켜져 있다. 리눅스는 보통 그냥 메모리가 부족하다고 에러를 낸다. 윈도우에서는 “안 들어감”이 에러가 아니라 그냥 느린 정상 동작처럼 보인다는 뜻이다. 이걸 모르면 다음 표를 완전히 거꾸로 해석하게 된다.

내보내는 양에 따른 속도 변화 (Qwen3 17.28기가)

내보낸 겹	1차 측정	2차 측정
0	23.58	23.60
12	34.33	34.32
16	38.61	42.48
18	50.54	38.63
20	69.92	70.09
24	61.47	61.28
32	50.21	50.04
40	42.96	42.85
48	34.17	34.10

단위는 초당 만들어내는 단어 조각 수다. 그래프로 그리면 산 모양이 된다. 왼쪽에서 올라가 20에서 꼭대기를 찍고 오른쪽으로 완만하게 내려온다. 그런데 이 산의 양쪽 비탈은 원인이 전혀 다르다.

오른쪽 내리막은 당연한 결과다. 전문가를 본체 메모리로 많이 내보낼수록 그걸 다시 그래픽카드로 실어 나르는 시간이 늘어난다. 문제는 왼쪽 오르막이다. 이건 성능이 좋아지는 게 아니라, 모델이 그래픽카드에 안 들어가서 망가져 있던 상태에서 빠져나오는 과정이다. 앞서 말한 윈도우의 조용한 뒷처리가 그 구간에서 일어나고 있다.

인터넷에는 이 산의 서로 다른 쪽만 보고 다투는 글들이 있다. “12기가 카드에서도 초당 50~60개가 나온다”는 쪽과 “많이 내보낼수록 느려지며, 빨라진다면 그건 뭔가 잘못됐다는 신호다”라는 쪽이다. 둘 다 맞다. 각자 산의 다른 비탈을 보고 있었을 뿐이다.

모델 세 개를 같은 방식으로 재본 결과

항목	Qwen3	GLM 중간 압축	GLM 약한 압축
파일 크기	17.28기가	20.08기가	23.11기가
가장 좋은 설정값	20	26	28~30
그때 속도	70.0	43.1	약 32
설정값 0일 때	23.6	10.5	6.3~8.6
꼭대기 바로 아래	16~18에서 흔들림	24에서 14.4로 추락	26에서 21.0

여기서 두 가지가 드러난다. 먼저 파일이 커지면 가장 좋은 설정값도 뒤로 밀린다. GLM 두 개는 같은 모델을 압축 강도만 다르게 한 것이라 크기 효과만 깔끔하게 비교된다. 3기가가 커지자 최적값이 26에서 28~30으로 옮겨가고 최고 속도는 4분의 1이 깎였다.

더 중요한 건 두 번째다. 가장 좋은 설정값 바로 아래에 함정이 있다. GLM 중간 압축을 보면 22에서 23.0, 24에서 14.4, 26에서 43.1이다. 24라는 숫자 하나 때문에 속도가 3분의 1로 주저앉는다. 두 번 측정해서 14.31과 14.56으로 거의 같게 나왔으니 우연이 아니다.

이유는 단순하다. 26이 모델이 겨우 들어가는 최소값이고, 24는 아슬아슬하게 넘쳐서 앞서 말한 조용한 뒷처리에 걸린다. 딱 한 칸 차이다.

그래서 설정값은 위에서부터 내려오며 찾아야 한다. 낮은 숫자에서 시작해 하나씩 올리면 저 함정을 먼저 만나고, “역시 내 카드로는 무리구나” 하고 잘못 포기하게 된다. 반대로 48처럼 큰 값에서 시작해 하나씩 줄이면서 속도가 오르는 걸 확인하다가, 갑자기 뚝 떨어지는 지점 바로 앞에서 멈추면 그 자리가 정답이다.

설정을 안 만졌을 때와 만졌을 때

모델	기본값 근처	제대로 맞췄을 때	차이
Qwen3 17.28기가	23.6	70.0	3.0배
GLM 20.08기가	10.5	43.1	4.1배
GLM 23.11기가	6.3~8.6	약 32	4~5배

같은 컴퓨터, 같은 파일, 숫자 하나 차이다. 12기가 카드에서 23기가 모델이 초당 32개로 돈다.

이쯤에서 궁금해지는 게 있다. 이 오프로드를 전문으로 하는 엔진이 따로 있다. KTransformers인데, 중국 칭화대 연구실 등이 만들었고 컴퓨터 시스템 분야 최상위 학회인 SOSP 2025에 논문이 실렸다. 24기가 카드 한 장에 넉넉한 본체 메모리를 붙여 671B짜리 초대형 모델을 돌린다는, 듣기만 해도 솔깃한 물건이다.

설치해서 직접 돌려봤다. 그런데 이 엔진에 딸린 진단 도구가 첫 화면에서 답을 줬다. 내 프로세서에는 AMX가 없다는 것이었다.

AMX는 인텔이 서버용 프로세서에 넣은 특수 연산 장치로, 행렬 계산을 한 번에 크게 처리한다. KTransformers의 화제성 수치는 바로 이 AMX에 맞춰 만든 코드에서 나온다. 일반 소비자용 프로세서에는 없다.

얼마나 차이 나는지 궁금해서 kt-kernel에 들어있는 CPU MoE 커널 벤치마크를 직접 돌려보았다. 모델을 받지 않고도 연산 성능만 잴 수 있는 도구다.

연산 성능 비교

항목	논문 측정 환경	이 컴퓨터
프로세서	인텔 제온 8452Y 두 개	라이젠 5 9600X 한 개
코어 수	72	6
특수 연산 장치	AMX 있음	없음
초당 연산량	21.0	1.19

총량만 보면 17.6배 차이다. 하지만 이 숫자를 그대로 쓰면 안 된다. 코어 수가 72개와 6개로 열두 배 차이 나기 때문이다. 코어 하나당으로 나누면 0.292와 0.198, 1.47배로 줄어든다. 격차의 대부분은 AMX가 아니라 그냥 코어 수인 것이다.

다만 이 1.47배라는 값에는 단서가 붙는다. 공식 문서와 평가 환경을 밝힌 글을 대조해 코어 수를 72개로 봤다. 그런데 저 21.0이라는 수치가 프로세서 두 개를 다 쓴 값인지 한 개만 쓴 값인지는 문서에 명시가 없다. 한 개 기준이라면 코어당 격차는 2.9배가 된다.

이 컴퓨터 쪽 측정에도 조건이 하나 붙는다. 메모리가 모자라 전문가 수를 256명에서 32명으로 줄여 돌린 값이라, 실제보다 유리하게 나왔을 가능성이 있다.

그리고 논문 본문이 이미 이렇게 적고 있다. AMX는 계산이 빽빽한 구간에 쓰고, 짧은 질문에 답을 만들어내는 구간에는 오히려 더 가벼운 일반 연산 방식을 기본으로 쓴다고. 소비자용 프로세서가 타게 되는 경로는 고장이 아니라 저자들이 의도한 경로라는 뜻이다.

커널 벤치 결과 중 초당 연산량과 함께 메모리 대역폭도 살펴보자. 메모리 대역폭이란 메모리와 프로세서 사이로 1초에 오갈 수 있는 데이터 양이다. 측정값은 초당 12.06기가였다. 그런데 이 컴퓨터에 꽂힌 DDR5 메모리의 이론상 한계는 초당 83기가다. 15퍼센트밖에 못 쓰고 있었다.

메모리는 놀고 있고 프로세서가 막고 있다는 뜻이다. 그러면 프로세서가 한 번에 처리하는 작업 줄 수를 늘리면 될까 싶었다. 마침 이 컴퓨터는 한 코어가 두 줄을 동시에 처리하는 기능이 꺼져 있었다. 바이오스에서 켜서 6줄을 12줄로 만들고 같은 측정을 다시 돌렸다.

작업 줄 수를 두 배로 늘린 결과

항목	6줄	12줄	변화
초당 연산량	1.1904	1.3046	9.6퍼센트 증가
메모리 대역폭	12.06	13.22	9.6퍼센트 증가

두 배로 늘렸는데 10퍼센트도 안 올랐다. 이 기능은 코어가 메모리를 기다리며 노는 틈에 다른 작업을 끼워 넣는 방식이다. 이득이 이렇게 작다는 건 애초에 그 노는 틈이 별로 없다는 뜻이다. 참고로 이 측정은 바이오스와 칩셋 드라이버를 함께 갱신한 뒤에 이뤄져서, 9.6퍼센트가 전부 이 기능 덕분이라고는 말할 수 없다.

결국 세 가지 후보 중 둘이 지워졌다. 메모리 대역폭이 모자란 것도 아니고, 작업 줄이 부족한 것도 아니다. 남는 건 코어 자체의 계산 능력이 이미 꽉 찼다는 설명뿐이다.

그래서 AMX가 왜 그렇게 큰 차이를 만드는지가 여기서 설명된다. AMX는 작업 줄을 늘리는 게 아니라 코어 하나가 한 번에 처리하는 계산 덩어리를 키우는 장치다. 지금 막혀 있는 바로 그 지점을 뚫는다. 뒤집어 말하면 일반 사용자에게는 메모리를 더 빠른 걸로 바꾸는 것도, 작업 줄을 늘리는 것도 큰 도움이 안 된다는 얘기다.

다행히 여기에 매달릴 필요는 없다. 앞에서 본 것처럼 설정값 하나를 제대로 맞추는 것만으로 이미 네다섯 배를 얻기 때문이다. 프로세서를 바꾸는 것보다 숫자를 몇 번 바꿔가며 재보는 쪽이 훨씬 싸다.

정리하면 이렇다. MoE라고 적힌 모델을 고르고, 앞의 99는 건드리지 말고 뒤의 숫자만 큰 값에서 하나씩 줄여가며 재본다. 속도가 갑자기 떨어지는 지점 바로 앞이 정답이다. 파일이 커지면 그 정답도 함께 커진다. 그리고 그래픽카드 메모리와 본체 메모리를 합친 것보다 파일이 크면 그때는 정말 방법이 없다.

2년 전이면 데이터 센터에서나 가능했던 일인데, 이제는 12기가 그래픽카드면 23기가짜리 모델을 초당 32개 속도로 돌릴 수 있게 된 것이다. 게임하려고 산 카드가 저녁에는 남의 서버를 거치지 않는 나만의 AI가 된다.