먼저 읽는 요약
메모리 구성 — 실행에는 모델 가중치 외에 작업 공간과 KV 캐시가 필요합니다. 파일 용량만으로 실행 메모리를 판단할 수 없습니다.
설정 확인 — 필요한 문맥 길이와 GPU 오프로딩을 정하고, 실제 환경에서 메모리·속도·답변 품질을 함께 확인합니다.
캐시 양자화 — q4_0은 f16 대비 캐시 메모리를 약 1/4로 줄입니다. 전체 실행 메모리의 감소율이나 답변 품질을 보증하는 수치는 아닙니다.
로컬 AI는 모델의 계산을 외부 클라우드 대신 내 컴퓨터에서 수행하는 방식입니다. 다만 모델을 메모리에 불러오는 데 성공한 것과 긴 문서를 넣고 오래 대화해도 쓸 만한 것은 다릅니다. 두 상황에서 필요한 메모리에도 차이가 있습니다.
모델 파일이 그래픽카드 메모리보다 작더라도 긴 대화에 필요한 공간까지 확보됐다는 뜻은 아닙니다. 저는 다운로드할 용량에 앞서 그 모델로 얼마나 긴 일을 시킬 것인가를 정하는 것이 중요하다고 봅니다.
모델 파일 크기와 양자화의 차이

LM Studio는 Discover에서 모델을 찾아 다운로드하고, 불러와 대화하는 흐름입니다. 모델명뿐 아니라 user/model 형식이나 Hugging Face 주소로도 지원 모델을 검색할 수 있습니다. 같은 모델의 다운로드 옵션이 여럿인 것은 대체로 양자화 방식이 다르기 때문입니다. 가중치를 더 적은 용량으로 표현하는 대신 품질과 절충하므로 가장 작은 파일이 항상 최선인 것은 아닙니다.
ISTA-DASLab의 Qwen3.8-27B GSQ-RCO 배포본을 예로 들면 IQ3_S 파일은 11.8GB, 다중 토큰 예측(MTP) 포함판은 12.1GB입니다. 이미지 처리용 비전 프로젝터 mmproj의 BF16 파일은 별도로 931MB입니다. 텍스트만 다룰지 이미지도 다룰지에 따라 구성을 살펴야 하며 MTP는 선택 사항입니다. 이 수치들은 모두 파일 용량이므로 11.8GB만 보고 실행에 필요한 메모리를 확정할 수 없습니다.
긴 문맥에서 늘어나는 실행 메모리

Chat 화면에서 모델을 로드한 뒤에는 실행 메모리가 중요해집니다. 모델 가중치 외에 계산용 작업 공간이 필요하고, 긴 문맥에서는 KV 캐시가 큰 비중을 차지할 수 있습니다. KV 캐시는 이미 처리한 토큰의 어텐션 계산에 쓰이는 키·값을 보관해 다음 토큰 생성에 재사용하는 공간입니다. 앞의 내용을 매번 처음부터 계산하지 않는 대신 그 결과를 보관할 메모리가 필요합니다.
문맥에는 마지막 질문뿐 아니라 이전 대화와 지시, 붙여 넣은 코드·문서, 도구가 반환한 내용과 새 답변까지 포함해 생각해야 합니다. 코딩 질문 자체는 짧아도 함께 전달하는 파일과 오류 기록은 길 수 있습니다. 길이를 세는 단위는 대화 횟수나 글자 수가 아니라 토큰입니다.
메모리가 대화 길이에 따라 늘어나는 비율은 모델 구조와 캐시 방식에 따라 다릅니다. 필요한 공간을 미리 확보하는 실행 방식에서는 대화를 시작하기 전부터 큰 컨텍스트 설정이 메모리를 차지할 수 있습니다. 문맥을 두 배로 늘려도 전체 실행 메모리가 정확히 두 배가 되지는 않으며, 새 대화를 열어도 미리 확보한 공간이 곧바로 줄어드는 것은 아닙니다. 필요한 문맥 길이로 낮춰 다시 로드하는 방법도 확인해야 합니다.
같은 128K라도 기기와 설정은 다릅니다
Ollama 앱에서는 설정의 Context length 슬라이더로 문맥 길이를 조절합니다. 기본값을 무조건 4,096토큰으로 생각하기보다 실제 값을 확인하는 편이 낫습니다. VRAM 규모에 따라 4K·32K·256K로 나누어 안내하므로 모델의 최대 지원 길이와 현재 할당된 길이를 구분해야 합니다. 웹 검색·에이전트·코딩 도구처럼 긴 문맥을 쓰는 작업에 64K 이상을 권하는 안내도 있지만, 모든 질문에 필요하거나 내 컴퓨터에서 쾌적하게 실행된다는 보증은 아닙니다. 실행 중인 모델은 다음 명령으로 확인할 수 있습니다.
ollama ps
확인할 항목은 CONTEXT와 PROCESSOR입니다. CONTEXT는 할당된 문맥 길이, PROCESSOR는 모델이 CPU와 GPU에 어떻게 나뉘어 올라갔는지 보여줍니다. VRAM이 부족할 때 일부를 시스템 RAM에 두면 실행 가능성은 넓어지지만 두 메모리의 속도가 같아지지는 않습니다. VRAM 16GB와 RAM 64GB를 더해 같은 속도의 80GB 메모리처럼 볼 수는 없습니다. GPU 안에서 처리할 때와 CPU·GPU로 나누어 처리할 때는 같은 속도를 기대할 조건이 아닙니다.
커뮤니티 사례도 기기와 설정을 함께 읽어야 합니다. 2026년 10월 7일에는 시스템 RAM 64GB와 VRAM 16GB 환경에서 30GB가 넘는 Qwen 3.8 FlashNext 파일을 쓰는 것이 실속 있는지 묻는 글이 올라왔고 의견이 갈렸습니다. 파일을 담을 수 있는 공간과 실제로 쓸 만한 실행 환경은 다른 문제입니다. 아래 두 사례 역시 조건을 함께 보아야 합니다.
| 커뮤니티 글 | 공유된 기기·모델·실행 환경 | 글에서 보고한 내용 |
|---|---|---|
| 2026년 10월 7일, LocalLLM | RTX 5080 + 시스템 RAM 96GB | 코딩 작업에서 64K 문맥의 활용을 질문. 128K에서 속도가 47→37 tok/s로 내려갔다고 보고 |
| 2026년 10월 8일, LocalLLM | Qwen3.8-27B GSQ-RCO IQ3_S / RX 9070 VRAM 16GB + DDR5 RAM 32GB / Ubuntu / llama.cpp·ROCm | 128K 문맥과 q4_0 KV 캐시 사용을 보고. MTP는 효과를 보지 못해 사용하지 않았다고 설명 |
두 번째 구성에 첫 번째 사례의 속도를 적용할 수는 없습니다. 같은 128K라도 모델·작업·캐시 설정이 같다는 뜻은 아닙니다. 다른 댓글의 NVIDIA 기기나 다른 모델의 결과까지 합치면 실제로 확인되지 않은 성공 사례가 됩니다. 이 사례들은 내 컴퓨터의 예상 속도보다 실행에 성공했다는 말 뒤에서 확인해야 할 조건을 보여줍니다.
다운로드 후 로드 조건과 추정치를 확인합니다

LM Studio에서는 로드 전에 Manually choose model load parameters를 선택해 문맥 길이와 GPU 오프로딩 등을 조절할 수 있습니다. 모델이 긴 문맥을 지원한다는 이유만으로 최대값을 선택하기보다 짧은 질문에 쓸지, 긴 문서를 다룰지 먼저 정하는 편이 낫습니다.
메모리 필요량을 먼저 가늠하려면 lms load --estimate-only를 사용할 수 있습니다. 대상은 이미 로컬에 다운로드한 모델입니다. lms ls로 실제 model_key를 확인한 뒤 아래의 <model_key>를 그 값으로 바꿉니다. 8,192와 32,768은 서로 다른 문맥 길이의 추정치를 비교하는 예시이며, 모든 모델에 권하는 설정값은 아닙니다.
lms ls
lms load --estimate-only <model_key> --context-length 8192
lms load --estimate-only <model_key> --context-length 32768
--estimate-only는 모델을 실제로 로드하지 않고 메모리 추정치를 보여줍니다. 문맥 길이와 GPU 오프로딩, Flash Attention, 비전 모델 여부 등이 반영되므로 다운로드 파일 크기만 보는 것보다 실행 조건에 가까운 비교가 가능합니다. 다만 다운로드 전의 원격 파일에 대한 정확한 실행량을 알려주는 기능은 아닙니다. 추정치가 적절해 보여도 로드 성공이나 긴 작업의 안정성을 보증하지는 않습니다. 설정을 비교하는 추정치이며 실행 성공의 확인은 아닙니다.

반복해서 쓰는 값은 My Models의 톱니바퀴에서 모델별 기본 로드 설정으로 정할 수 있습니다. GPU 오프로딩, 문맥 길이, Flash Attention 등이 대상이며 다음에 모델을 로드할 때 적용됩니다. 한 번의 로드 설정을 바꾸는 일과 앞으로 쓸 기본값을 저장하는 일은 구분해야 합니다. 기본값을 저장했다고 현재 메모리에 올라간 모델까지 새 조건으로 바뀌는 것은 아닙니다.
KV 캐시 양자화의 절감 범위
작은 모델 파일을 선택해도 긴 문맥이 부담스럽다면 모델 가중치와 별개로 KV 캐시를 줄이는 방법을 볼 수 있습니다. Ollama는 Flash Attention이 활성화된 환경에서 OLLAMA_KV_CACHE_TYPE으로 캐시 양자화 형식을 지정할 수 있습니다. 다운로드할 때 고른 IQ3_S는 모델 가중치, 이 설정은 문맥 계산에 쓰는 캐시를 대상으로 한다는 차이가 있습니다.
| Ollama KV 캐시 형식 | f16 대비 캐시 메모리 | 품질에서 고려할 점 |
|---|---|---|
| f16 | 기준값·기본 설정 | 높은 정밀도와 메모리 사용량 |
| q8_0 | 약 1/2 | 정밀도 손실이 작지만 작업 결과 확인은 필요 |
| q4_0 | 약 1/4 | 더 큰 절감 대신, 특히 긴 문맥에서 품질 저하가 더 드러날 수 있음 |
표에서 약 4분의 1로 줄어드는 것은 캐시 메모리입니다. 모델 가중치와 나머지 실행 공간까지 75% 줄어드는 것은 아닙니다. 또 이 환경변수는 특정 모델 하나가 아니라 모든 모델에 영향을 주는 전역 설정입니다. 한 모델의 메모리를 줄이려고 바꿨다면 다른 모델의 답변도 함께 확인해야 합니다. 메모리 절감 폭과 품질 변화는 모델과 과제에 따라 달라집니다.
앞의 GSQ-RCO 배포본에서 task-lossless라는 표현은 제작자가 선정한 벤치마크의 평가 범위를 뜻합니다. 모든 한국어 작업·코딩·긴 대화가 무손실이라는 뜻도, 별도로 바꾼 KV 캐시 설정의 품질을 보증한다는 뜻도 아닙니다. 설정을 비교할 때는 같은 질문과 자료를 사용하고 한국어 표현의 자연스러움뿐 아니라 숫자·단위·부정 표현과 처음에 준 조건이 끝까지 유지되는지 살펴야 합니다. 유창한 답변과 정확한 작업 수행은 별개입니다.
확인한 설정을 저장하고 작업을 나눕니다

LM Studio에서 문맥 길이와 메모리 여유, 답변 상태를 확인했다면 다음 로드 화면의 Remember settings로 그 모델의 기본값을 저장할 수 있습니다. 화면에 나온 Llama 3.2의 숫자를 그대로 따르는 것이 아니라, 확인한 값을 다음 로드에도 사용하는 기능입니다. 설치를 마친 뒤에는 활용할 작업에 맞는 설정을 정해 두는 과정이 필요합니다.
긴 코딩 작업도 꼭 한 대화에 모두 넣을 필요는 없습니다. 작업을 나누고 필요한 파일만 전달하거나, 결정된 내용과 남은 일을 요약해 다음 대화로 넘길 수 있습니다. 다만 요약 과정에서 요구사항이 빠지지 않도록 숫자·제약·바꾸면 안 되는 조건을 남겨야 합니다. 새 대화에 이전 기록 전체를 다시 넣으면 문맥을 줄이려는 목적이 사라집니다. 큰 캐시를 미리 확보하는 환경에서는 문맥 설정 자체도 함께 살펴야 합니다.
총평: 필요한 문맥을 확보하고 일을 마치는 조합을 고릅니다
제가 로컬 AI 모델을 비교할 때 먼저 보는 기준은 컴퓨터에 들어가는 가장 큰 모델이 아닙니다. 필요한 문맥을 확보하면서 감당할 만한 속도와 품질로 일을 마칠 수 있는 조합입니다. 짧은 질문에는 잘 답해도 긴 대화에 필요한 공간이 부족한 모델과, 조금 작더라도 필요한 자료를 다룰 수 있는 모델은 선택 이유가 다릅니다. 파일 크기에서 시작하되 실제 작업을 마칠 수 있는지는 실행 메모리·설정·결과로 확인해야 합니다.
