로컬 AI 모델 구동하기-3

핵심 요약

• 컨텍스트 윈도우를 키우면 KV 캐시가 VRAM을 쓴다.
• 27B Dense는 96K에서 128K로 넘어가는 순간 생성 속도가 1/4가 된다 
• 35B MoE는 CPU로 오프로드하면서도 27B Dense 96K보다 빠르다

중요한건 모델 크기만이 아니다 

로컬 모델에 처음 관심을 가질 때 모델의 크기만 중요한 걸로 생각했다.

그래서 '구동이 가능하다'라는 것만 보고 되는구나 라고 생각했다.

하지만 실제 VRAM 사용량은 이렇다.

VRAM = 모델 가중치 + KV 캐시 + 런타임 버퍼

KV 캐시는 이전 토큰의 연산 결과를 저장해두는 공간이다.

컨텍스트가 길수록 캐시가 커진다. 256K 컨텍스트라면 모델 크기와 맞먹는 수준의 VRAM이 추가로 필요할 수 있다.

아무리 큰 모델을 구동할 수 있다 한들 컨텍스트 윈도우가 작으면 쓸데가 없다.

그래서 KV 캐시도 양자화하는데 기본값인 f16 KV 캐시 대신 q8_0으로 바꾸면 절반으로 줄어든다.

품질 손실은 미미하다.

Ollama에서는 환경 변수 두 줄이면 된다.

OLLAMA_FLASH_ATTENTION=1
OLLAMA_KV_CACHE_TYPE=q8_0

Flash Attention을 켜야 KV 캐시 양자화가 활성화된다. 둘은 세트다.

RTX 3090 Ti 실측 결과

Qwen3.5 9B, Qwen3.6 27B, Qwen3.6 35B A3B를 각각 긴 컨텍스트로 돌렸다. 모두 Q4_K_M GGUF.

메모리 사용 

모델	컨텍스트	가중치	KV 캐시	VRAM	CPU 오프로드
Qwen3.5 9B	256K	6.1 GB	7.6 GB	13.7 GB	없음
Qwen3.6 27B	96K	16.2 GB	5.1 GB	21.3 GB	없음
Qwen3.6 27B	128K	16.2 GB	8.2 GB	22.0 GB	2.4 GB
Qwen3.6 35B A3B	256K	22.3 GB	5.0 GB	22.0 GB	5.3 GB

27B 모델은 96K는 오프로드가 발생하지 않아서 꽤 빠른 속도를 보여준다.

하지만128K로 늘리면 KV cache가 5.1에서 8.2GB로 커지면서 24GB를 초과한다.

2.4GB가 CPU RAM으로 밀려난다.

35B A3B는 처음부터 5.3GB가 CPU에 있다.

근데 빠르다.

생성 속도 실측 (약 116K 토큰 컨텍스트 채운 상태)

모델	컨텍스트	생성 속도
Qwen3.5 9B	256K	80.5 tok/s
Qwen3.6 35B A3B	256K	69.9 tok/s
Qwen3.6 27B	96K	39.1 tok/s
Qwen3.6 27B	128K	9.2 tok/s

35B MoE가 27B Dense보다 빠르다

35B가 27B보다 파라미터가 많은데 더 빠르다.

MoE(Mixture of Experts) 구조 때문이다.

MoE는 토큰 하나를 처리할 때 전체 파라미터를 쓰지 않는다.

Qwen3.6 35B A3B는 총 35B이지만 실제 활성 파라미터는 3B에 불과하다.

나머지는 "대기 중인 전문가"들이다.

Dense 모델인 27B는 전체가 매 토큰마다 활성화된다.

결과적으로 토큰 생성 속도는 Dense 27B < MoE 35B A3B다.

오프로드 5.3GB > 오프로드 2.4GB

35B A3B는 5.3GB가 CPU에 있는데 69.9 tok/s. 27B 128K는 2.4GB만 CPU에 있는데 9.2 tok/s.

오프로드 양이 두 배 이상 많은 쪽이 7.6배 더 빠르다.

차이는 무엇을 오프로드하느냐다.

27B 128K는 KV 캐시 일부가 CPU로 밀려난 경우다. KV 캐시는 토큰을 하나 생성할 때마다 반드시 읽어야 한다.

2.4GB를 매 토큰마다 CPU에서 GPU로 올리는 것이다. 컨텍스트에 이미 80K 토큰이 쌓인 상태라면 이 비용이 폭발한다.

35B A3B의 CPU 오프로드는 비활성 전문가 레이어들이다.

대부분의 토큰 생성에서 이 레이어들은 접근하지 않는다.

있어도 없는 것처럼 동작한다.

Dense 27B 오프로드: KV 캐시 → 매 토큰마다 CPU↔GPU 전송 → 누적 비용 폭발
MoE 35B A3B 오프로드: 비활성 전문가 → 대부분의 토큰에서 접근 안 함 → 영향 최소

이게 핵심이다. 오프로드의 양보다 오프로드의 종류가 중요하다.

27B는 96K가 실질적 한계였다

96K와 128K의 차이를 다시 보면 이렇다.

96K  장문 생성: ████████████████████████████████████████ 39.1 tok/s
128K 장문 생성: █████████  9.2 tok/s

KV 캐시 3GB가 VRAM에서 넘쳐서 CPU로 밀렸고, 생성 속도는 4.2배 떨어졌다.

9.2 tok/s는 체감상 느리다.

짧은 응답은 그냥 기다릴 수 있지만, 긴 출력을 기다리면 힘들다.

27B Dense에서 컨텍스트를 더 늘리고 싶다면 q4_0 KV 캐시로 전환하는 게 맞다.

KV 캐시를 1/3으로 줄이면 같은 VRAM에서 컨텍스트를 더 넣을 수 있다.

단, 품질이 q8_0보다 약간 떨어진다.

MoE 오프로드를 일부러 쓰는 경우

35B A3B의 예에서 배울 수 있는 게 있다.

MoE 모델은 전문가 레이어 일부를 의도적으로 CPU로 내려서 VRAM을 확보하고, 그 공간을 KV 캐시에 쓸 수 있다.

Ollama에서는 Modelfile에서 num_gpu 파라미터로 GPU에 올릴 레이어 수를 조정한다.

전체보다 낮게 잡으면 나머지가 CPU로 내려간다.

속도는 약간 떨어지지만, 이미 오프로드 5.3GB에서 69.9 tok/s를 보여준 모델이라 추가 오프로드를 해도 실용적인 속도를 유지할 가능성이 높다.

Dense 모델에서는 이 전략이 통하지 않는다. 오프로드는 무조건 KV 캐시나 가중치 레이어에 영향을 주고, 매 토큰마다 비용이 발생한다.

번외로 122B A10B도 구동은 가능했다. 

196K 컨텍스트 윈도우로 약 15 tok/s, RAM이 64gb 밖에 안돼서 256K까진 안되지만 '구동은 가능하다'.

실사용 환경

• OLLAMA_FLASH_ATTENTION=1 + OLLAMA_KV_CACHE_TYPE=q8_0 세트 적용이 기본
• RTX 3090 TI 1장에선 27B Dense는 96K가 실질 상한이었다 
• 35B MoE A3B는 256K에서도 70 tok/s가 나온다.
• 9B는 256K 컨텍스트에 VRAM 13.7GB 간단한 Tool calling에 사용하기에 좋다.
• MoE는 오프로드 되어도 Dense모델보다 빠르다 

---

학습 환경

따라해보고 싶다면:

용도	도구	비고
LLM 런타임	Ollama	curl 설치 스크립트 한 줄
KV 캐시 최적화	OLLAMA_FLASH_ATTENTION, OLLAMA_KV_CACHE_TYPE	환경 변수로 설정
9B 모델	Qwen3.5-9B Q4_K_M	ollama pull로 바로 사용
27B 모델	Qwen3.6-27B Q4_K_M	96K ctx 권장
35B MoE 모델	Qwen3.6-35B-A3B Q4_K_M	256K ctx에서도 70 tok/s
메모리 확인	ollama ps	CPU/GPU 배분 실시간 확인