매칭표는 얼마나 맞나 — 24GB에서 경계를 직접 찾아봤다

2026-08-25 · 실측

이 포스팅은 쿠팡 파트너스 및 네이버 쇼핑 커넥트 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

그래픽카드별 실행 가능표를 만들어 뒀습니다. VRAM 용량별로 어떤 모델이 몇 토큰까지 올라가는지 계산해서 보여주는 표입니다.

계산으로 만든 표입니다. 맞는지 재본 적은 없었습니다.

무엇을 확인할 수 있나

표는 24GB에서 Qwen3 30B-A3B Q4_K_M 의 최대 컨텍스트를 32k라고 답합니다.

이건 반증 가능한 주장입니다. 컨텍스트를 올려가며 어디서 VRAM을 넘치는지 찾으면 됩니다. RTX 3060 12GB 두 장, 합계 24GB에서 쟀습니다.

넘쳤는지는 ollama ps가 알려줍니다. 전부 올라가면 100% GPU, 넘치면 2%/98% CPU/GPU 처럼 나옵니다.

결과

num_ctx	VRAM	생성 속도	배치
16,384	19,713 MiB	90.4 tok/s	GPU 100%
32,768	21,277 MiB	96.8 tok/s	GPU 100%
40,960	22,077 MiB	95.8 tok/s	GPU 100%
49,152	22,635 MiB	58.0 tok/s	2% / 98%
65,536	22,315 MiB	49.5 tok/s	10% / 90%

컨텍스트 설정별 생성 속도 — 48k에서 절벽

시험한 지점 중에서는 40,960이 마지막으로 전부 올라갔고 49,152에서 처음 넘쳤습니다. 그 사이는 재지 않았으므로 실제 경계가 어디인지는 모릅니다.

예측은 1.3~1.7% 안에 들었다

전부 GPU에 올라간 구간만 비교하면 이렇습니다.

num_ctx	표의 예측	실측	오차
16,384	19.58 GiB	19.25 GiB	+1.7%
32,768	21.08 GiB	20.78 GiB	+1.5%
40,960	21.83 GiB	21.56 GiB	+1.3%

세 조건 모두 표가 실제보다 조금 크게 잡습니다. 예측이 부족한 방향으로 틀리면 “된다”고 해놓고 안 되는 일이 생기는데, 그 방향은 아니었습니다.

49,152부터는 이 비교를 하지 않았습니다. 일부가 CPU로 내려가면 예측값은 전체 필요량인데 실측값은 GPU 에 남은 양이라 서로 다른 것을 비교하게 됩니다. 65,536에서 겉보기 오차가 10.5%로 뛰는 것도 같은 이유이며, 이 숫자는 예측 정확도를 뜻하지 않습니다.

10% 여유 규칙이 거의 정확히 맞았다

표는 예상 사용량 × 1.1 ≤ VRAM 일 때만 “들어간다”고 판정합니다. 10%를 여유로 둔 겁니다.

이 규칙을 뒤집으면 임계값이 나옵니다.

24 GiB ÷ 1.1 = 21.818 GiB

예상 사용량이 21.818 GiB를 넘으면 표는 안 된다고 답합니다.

실측 경계는 이랬습니다.

시험한 지점 중 마지막으로 전부 올라간 40,960 → 예측 21.83 GiB
처음 넘친 49,152 → 예측 22.58 GiB

임계값 21.818은 시험한 지점 중 마지막으로 성공한 40,960의 예측값 21.83과 0.055% 차이입니다.

다만 이걸 “규칙이 정확했다”로 읽으면 안 됩니다. 오히려 반대입니다. 40,960은 임계값을 0.012 GiB 넘겨서 표가 “안 된다”고 판정하는데 실제로는 올라갔습니다. 규칙이 이 한 칸을 틀리게 분류한 것입니다.

말할 수 있는 건 여기까지입니다. 임의로 잡은 10%가 이 구성에서 실측 경계 근처에 떨어졌습니다. 그리고 경계에서 안전한 쪽으로 틀렸습니다.

경계점 하나가 가깝다는 것만으로 규칙 자체가 맞다고 하기엔 표본이 부족합니다.

그래서 표는 32k라고 답한다

이 한 칸 때문에 표는 시험에서 확인된 것보다 한 단계 아래를 말합니다. 40,960이 되는 걸 확인했는데 32k라고 합니다.

고칠까 고민했는데, 두지 않기로 했습니다. 틀리는 비용이 양쪽에서 다르기 때문입니다.

40,960에서 49,152로 넘어갈 때 ollama ps 의 CPU 비율이 **2%**로 바뀌었습니다. 같은 구간에서 생성 속도는 95.8에서 58.0 tok/s로 39% 떨어졌습니다.

이전 글에서 본 절벽과 모양이 같습니다. 다만 2%라는 수치가 39% 하락의 원인임을 이번 측정으로 분리하지는 못했습니다. 컨텍스트 길이 자체도 함께 늘었고, 조건당 1회라 변동폭도 모릅니다. 두 가지가 같이 관측됐다는 것까지가 사실입니다.

“안 되는데 된다”고 하면 39%를 잃습니다. “되는데 안 된다”고 하면 한 단계 짧은 컨텍스트를 쓰게 됩니다. 후자가 훨씬 쌉니다.

대신 다른 걸 고쳤다

표의 진짜 문제는 규칙이 아니라 눈금이었습니다.

컨텍스트 후보가 4k, 8k, 16k, 32k, 64k, 128k 여섯 개뿐이었습니다. 2배씩 뛰니까 그 사이 값을 아예 못 냅니다. 40,960이 된다는 걸 알아도 표에는 나올 자리가 없었습니다.

6k, 12k, 24k, 40k, 48k, 96k를 추가했습니다. 결과가 이렇게 달라집니다.

모델	VRAM	기존	개선
Gemma 2 9B	24GB	32k	48k
Gemma 2 27B	24GB	8k	12k
Qwen2.5 14B	16GB	16k	24k
Llama 3.2 3B	16GB	64k	96k
Llama 3.1 8B	12GB	32k	40k
Mistral 7B	12GB	32k	48k

전부 기존 표가 실제보다 짧게 답하던 칸입니다. 계산이 틀린 게 아니라 답할 수 있는 값이 없어서 한 단계 내려 적고 있었습니다.

정리

표의 VRAM 예측 오차는 전부 GPU에 올라간 세 지점에서 1.3~1.7%, 모두 크게 잡는 방향
10% 여유 규칙의 임계값이 실측 경계 근처(0.055% 차이)에 떨어졌다. 다만 경계의 한 칸은 안전한 쪽으로 틀리게 분류했다
경계에서 한 단계 보수적인 건 그대로 뒀다. 2% 넘쳐서 39% 잃는 쪽이 더 비싸다
눈금을 촘촘하게 고쳐서 6개 칸이 실제 값에 가까워졌다

이 글로 계산기 4개가 모두 실측 검증을 거쳤습니다. 각각의 측정 과정과 오차는 따로 적어 뒀습니다.

이 측정에 쓴 장비

RTX 3060 12GB 계열 — 쿠팡에서 보기 · 네이버 380,000원
이 사이트의 모든 측정에 쓰는 카드입니다. 두 장을 꽂아 24GB로 씁니다.

측정 방법

RTX 3060 12GB × 2 (합계 24GB), AMD Ryzen 7 5800X
Ollama 0.20.0, Qwen3-Coder 30B-A3B Q4_K_M, KV 타입 f16
num_ctx 를 바꿔가며 매번 모델을 완전히 언로드 후 재적재
배치는 ollama ps 의 CPU/GPU 분할, VRAM 은 nvidia-smi 두 장 합산
생성 24토큰, temperature=0, seed=1
측정 화면은 터미널 녹화로 저장소에 남겼습니다

한계

조건당 1회입니다. 변동폭을 모릅니다. 32,768에서 96.8 tok/s 로 16,384(90.4)보다 빠르게 나온 것도 이 변동폭 안이라고 보지만 확인하지 못했습니다.
경계를 40,960과 49,152 사이로만 좁혔습니다. 그 사이를 더 잘게 재지 않아 정확한 지점은 모릅니다.
모델 하나, 표의 한 칸만 검증했습니다. 나머지 행은 같은 계산식을 쓰지만 직접 재지 않았습니다. 특히 MoE 가 아닌 모델은 확인하지 못했습니다.
여유 10%가 다른 구성에서도 맞는지는 모릅니다. 카드 개수, 드라이버, 런타임이 다르면 사용 가능한 VRAM 자체가 달라집니다.
VRAM 은 프로세스가 잡은 양이며 생성 완료 후 1회 샘플입니다. 피크는 재지 않았습니다.
눈금을 늘려도 40,960~49,152 사이의 분해능은 거의 그대로입니다. 다른 칸은 개선됐지만 이 경계 자체를 더 정밀하게 만들지는 못했습니다.
두 GPU 사이에 모델과 KV 가 어떻게 나뉘었는지 기록하지 않았습니다. PCIe 토폴로지(두 번째 슬롯 x4)도 결과에 영향을 줄 수 있습니다. 단일 24GB 카드에 그대로 옮기기 어렵습니다.
프롬프트와 출력 길이, 샘플링 설정, 백그라운드 부하를 통제하지 않았습니다. 워밍업도 두지 않았습니다.
원본 데이터와 녹화는 저장소에 공개해 두었습니다. 다른 카드 결과를 알려주시면 출처를 밝히고 반영하겠습니다.

#로컬LLM#VRAM#RTX3060#컨텍스트#CPU오프로드