OpenClaw·OpenCode를 로컬 모델로 — 에이전트에 필요한 컨텍스트와 VRAM

OpenClaw(오픈클로), OpenCode, Claude Code 같은 에이전트는 채팅보다 훨씬 긴 프롬프트를 보냅니다. Ollama 문서도 이런 도구를 로컬 모델로 쓸 때 컨텍스트를 64k 이상으로 잡으라고 권합니다. 이 길이에서는 모델이 GPU에 다 올라갈지를 모델 파일보다 KV 캐시가 가르는 경우가 많습니다. 24GB인 RTX 3090에서 Qwen3.8 27B는 기본 f16 KV 캐시로 64k를 써도 GPU에 전부 올라갑니다. Qwen3.6 35B-A3B는 KV 캐시를 q8_0으로 둬야 GPU에 다 올라갑니다. 모델이 들어간 다음에는 프롬프트 처리 속도를 봐야 합니다. 모델은 매 턴 에이전트가 보낸 내용을 다 읽은 뒤에야 답을 씁니다.

에이전트가 컨텍스트를 많이 쓰는 이유

에이전트는 한 번 요청할 때 채팅보다 훨씬 많은 내용을 보냅니다. 에이전트의 지시문, 호출할 수 있는 도구 하나하나의 설명, 지금까지의 대화가 들어갑니다. 열어 본 파일과 실행한 명령의 출력, 답을 쓸 자리까지 한꺼번에 컨텍스트에 담겨야 합니다. OpenClaw의 로컬 모델 문서도 이 모두가 들어갈 자리를 남기라고 안내합니다. 짧은 질문에는 잘 답하는 모델도 에이전트 작업 한 턴에서는 실패할 수 있다고 적어 두었습니다.

Ollama 컨텍스트 길이 문서는 에이전트, 웹 검색, 코딩 도구에 64k 이상을 권합니다. OpenCode·OpenClaw·Claude Code 연동 문서에도 같은 권고가 있습니다. Ollama는 ollama launch opencode, ollama launch openclaw, ollama launch claude처럼 도구마다 한 줄로 설정하는 명령도 안내합니다. 다만 로컬 모델을 쓸 때 컨텍스트 길이는 직접 정해야 합니다.

그런데 Ollama 기본값은 대부분의 카드에서 이보다 훨씬 짧습니다. Ollama는 감지한 GPU 메모리가 24GiB 미만이면 4k, 24~48GiB면 32k, 48GiB 이상이면 256k 토큰을 기본 컨텍스트 길이로 씁니다 (Ollama 문서, 2026-09-29 확인). 그래서 16GB 카드는 따로 정하지 않으면 4k로 시작합니다. 컨텍스트가 차면 Ollama는 오류 없이 오래된 메시지부터 버립니다. 이 동작은 ‘올라마(Ollama)가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값’ 가이드에서 자세히 다룹니다. 길이를 정하는 방식은 도구마다 다르며, OpenClaw·OpenCode·Claude Code는 아래 설정 절에서 다룹니다.

생각 모드 모델은 추론 과정도 같은 컨텍스트에 씁니다. 모델 카드에 따르면 Qwen3.6 35B-A3B와 Qwen3.8 27B는 생각 모드가 기본으로 켜져 있습니다. Qwen3.6 모델 카드는 생각 능력을 지키려면 컨텍스트를 128k 이상으로 두라고 권합니다.

16GB·24GB 카드에서 32k·64k에 들어가는 코딩 모델

아래 표는 f16 KV 캐시로 64k를 쓸 때 각 모델에 필요한 그래픽카드 메모리입니다. 그래픽카드에 올라가는 가중치, KV 캐시, 계산 중에 쓰는 연산 버퍼를 더했습니다. 가중치는 4비트 양자화인 Q4_K_M 기준이고, gpt-oss-20b만 원래 형식인 MXFP4 기준입니다. 합계는 카드의 사용 가능 메모리와 비교합니다. Windows에서 그 카드로 화면을 출력한다고 보면 CanRun 계산으로 사용 가능 메모리는 이렇습니다. 16GB 카드는 15.4GB, 24GB 카드는 23.4GB, 32GB 카드는 31.4GB입니다.

합계 순서는 파일 크기 순서와 다릅니다. Qwen3 30B-A3B (2507)은 파일이 18.6GB로, Qwen3.6 35B-A3B의 22.3GB보다 작습니다. 그런데 64k에서는 25.9GB가 필요해 Qwen3.6 35B-A3B의 23.5GB보다 많습니다. 모든 층이 KV 캐시를 두기 때문입니다. 본문에서 말하는 판정은 8k 컨텍스트와 f16 KV 캐시 기준입니다. 더 긴 컨텍스트의 판정은 아래 표에서 길이와 KV 캐시 종류별로 볼 수 있습니다.

24GB: RTX 3090·RTX 4090

Qwen3.6 35B-A3B는 토큰마다 가중치 일부만 쓰는 MoE(전문가 혼합) 모델입니다. RTX 3090에서 8k로 돌리면 21.8GB가 필요하고, 쾌적하게 돌아갑니다. f16 KV 캐시로 32k까지 늘려도 GPU에 전부 올라갑니다. 64k에서는 23.5GB가 필요해 사용 가능 메모리를 조금 넘습니다. 이때 CanRun 계산은 들어가는 만큼 전문가 층을 GPU에 두고, 나머지를 시스템 RAM에 둡니다. 이 구성의 속도는 이론 추정(±30%)입니다. KV 캐시를 8비트인 q8_0으로 두면 64k에서 22.9GB로 줄어 다시 GPU에 다 올라갑니다. 여유가 1GB도 안 되니 모델을 올린 뒤 ollama ps로 확인하세요.

이 모델은 128k 행도 눈여겨봐야 합니다. 모델 카드가 생각 능력을 지키려면 128k 이상을 권하기 때문입니다. 24GB 카드에서는 128k에서 KV 캐시를 q4_0으로 줄여도 전문가 일부가 시스템 RAM에 남습니다. 표에서도 128k·q4_0 칸은 이론 추정입니다. RTX 4090도 사용 가능 메모리가 같아서, GPU에 들어가는지는 똑같이 나옵니다. 64k에서 q8_0을 쓰면 GPU에 다 올라갑니다.

Qwen3.8 27B는 dense 모델이라 토큰마다 가중치 전체를 읽습니다. 대신 KV 캐시를 두는 층이 네 층에 하나뿐입니다. RTX 3090에서 8k로 쾌적하게 돌아갑니다. f16 KV 캐시로 64k를 써도 21.9GB라서 1GB 넘게 여유가 남습니다. 128k에서 f16이면 26.8GB가 필요해, 가중치 일부를 시스템 RAM에 두는 부분 오프로드로 넘어갑니다. q8_0이면 22.8GB로 GPU에 아슬아슬하게 들어갑니다.

두 표를 나란히 보면 무엇을 맞바꾸는지 보입니다. Qwen3.6 35B-A3B는 토큰마다 고른 전문가만 읽습니다. 그래서 생성 속도 추정치가 Qwen3.8 27B의 몇 배입니다. 반면 Qwen3.8 27B는 KV 캐시 종류를 바꾸지 않고도 64k를 GPU에 담습니다.

24GB 카드에서 다른 모델은 이렇습니다.

• Gemma 4 26B-A4B는 f16으로 64k를 써도 19.4GB라서 GPU에 다 올라갑니다.
• Qwen3 30B-A3B (2507)과 Mistral Small 3.2 24B는 8k에서 둘 다 쾌적하게 돌아갑니다. 하지만 f16으로 64k를 쓰면 각각 25.9GB, 25.8GB가 필요합니다. CanRun 계산으로 Qwen3 30B-A3B는 전문가 일부를 시스템 RAM에 둡니다. dense 모델인 Mistral Small 3.2 24B는 가중치 일부를 시스템 RAM으로 보냅니다. q8_0 KV 캐시를 쓰면 둘 다 64k에서 GPU에 다 올라갑니다. 필요량은 22.9GB(여유 1GB 미만)와 20.8GB입니다. Qwen3-Coder-30B-A3B-Instruct는 설정 파일상 구조가 Qwen3 30B-A3B (2507)과 같아서, 이 수치를 거의 그대로 참고할 수 있습니다. 컨텍스트별 결과는 ‘GeForce RTX 3090에서 Qwen3 30B-A3B (2507)’ 페이지에 있습니다.
• Nemotron 3.5 Lightning 30B-A3B는 8k에서도 25.1GB가 필요해 24GB 카드에 다 들어가지 않습니다. 그래서 어느 길이에서든 전문가 일부를 시스템 RAM에 두고, 이론 추정으로는 원활하게 돌아갑니다. KV 캐시가 아주 작아서 64k로 늘려도 26.0GB로 거의 늘지 않습니다.

16GB: RTX 5060 Ti 16GB

흔히 쓰는 16GB 카드인 GeForce RTX 5060 Ti 16GB에서 gpt-oss-20b는 8k로 쾌적하게 돌아갑니다. 이 조합의 8k 결과는 추정치가 아니라 공개 벤치마크 결과입니다. f16 KV 캐시로 64k를 써도 14.2GB라서 사용 가능 메모리 15.4GB 안에 들어갑니다. 128k에서 f16이면 16.4GB가 필요해 전문가 일부가 시스템 RAM으로 갑니다. 표의 128k·f16 칸은 이론 추정입니다. q8_0이면 14.9GB로 GPU에 아슬아슬하게 남습니다. 이 모델이 지원하는 최대 길이는 128k입니다. 늘 생각한 뒤에 답하고, 모델 카드에는 에이전트 기능으로 함수 호출이 적혀 있습니다.

Qwen3.6 35B-A3B는 8k에서도 21.8GB가 필요해 이 카드에 다 들어가지 않습니다. 그래서 어느 길이에서든 전문가 일부를 시스템 RAM에 둡니다. 8k에서는 이론 추정으로 원활하게 돌아갑니다. KV 캐시가 작아서 64k로 늘려도 23.5GB로 8k와 큰 차이가 없습니다. 다른 카드와의 비교는 Qwen3.6 35B-A3B 모델 페이지에 있습니다.

Qwen3.8 27B는 8k에서도 17.6GB가 필요해 이 카드에 들어가지 않습니다. 가중치 일부를 시스템 RAM에서 돌려야 합니다. dense 모델은 토큰마다 가중치를 전부 읽으므로 겨우 돌아갑니다.

Qwen3.5 9B는 Qwen3.8 27B와 같은 구조라서 KV 캐시를 두는 층이 네 층에 하나입니다. 작은 모델이라 에이전트에 쓸 길이에서도 GPU에 남습니다. f16으로 64k를 쓰면 8.4GB가 필요하고, 이 카드에 다 들어갑니다. RTX 3060 12GB에도 들어갑니다. 다만 에이전트 작업을 얼마나 잘 해내는지는 이 표들로 알 수 없습니다.

8GB·12GB·32GB 카드

GeForce RTX 4060 같은 8GB 카드에서는 Qwen3.5 9B도 64k가 빠듯합니다. f16이면 일부가 시스템 RAM으로 넘어갑니다. q8_0이면 7.4GB가 필요하고, 사용 가능 메모리는 7.4GB입니다. CanRun 계산으로는 GPU에 남지만 여유가 거의 없습니다. 실제로 쓰기 전에 ollama ps로 확인하세요.

GeForce RTX 3060 12GB 같은 12GB 카드에서 gpt-oss-20b는 64k를 쓰면 전문가 일부를 시스템 RAM에 둡니다. 이때 이론 추정으로는 원활하게 돌아갑니다.

GeForce RTX 5090 같은 32GB 카드라면 Qwen3.6 모델 카드가 권하는 128k까지 쓸 수 있습니다. CanRun 계산으로는 Qwen3.6 35B-A3B를 f16 KV 캐시로 128k까지 늘려도 GPU에 전부 올라갑니다. 이때 필요량은 25.5GB입니다. Qwen3.8 27B도 f16으로 128k에서 26.8GB가 필요하고, GPU에 다 올라갑니다.

토큰당 KV 캐시가 작은 모델이 유리한 이유

KV 캐시는 컨텍스트 전체를 보는 층마다 토큰 하나당 키와 값을 저장합니다. 토큰당 크기는 모델 구조로 정해지므로, 캐시는 컨텍스트 길이에 비례해 커집니다. 아래 표는 모델별 토큰당 크기와, f16 기준으로 32k·64k·128k에서 차지하는 크기입니다.

차이는 파라미터 수가 아니라 캐시를 두는 층의 수에서 납니다. 각 모델의 설정 파일이나 모델 카드를 보면 이렇습니다.

• 모든 층이 전체 어텐션: Mistral Small 3.2 24B는 이런 층이 40개이고, 층마다 KV 헤드가 8개이며 슬라이딩 윈도는 없습니다. Qwen3 30B-A3B (2507)은 48층이고 KV 헤드는 4개입니다.
• 하이브리드 선형 어텐션: Qwen3.6 35B-A3B·Qwen3.8 27B·Qwen3.5 9B는 Gated DeltaNet 세 층 뒤에 Gated Attention 한 층이 오는 묶음을 되풀이합니다. 선형 층은 크기가 정해진 상태만 들고 있어서, 컨텍스트에 따라 커지는 층은 네 층에 하나입니다.
• 슬라이딩 윈도: gpt-oss-20b는 최근 토큰 일부만 보는 슬라이딩 윈도 층과 전체 어텐션 층을 번갈아 둡니다. Gemma 4 26B-A4B는 30층 가운데 25층이 1024토큰 슬라이딩 윈도입니다.
• 대부분 Mamba: Nemotron 3.5 Lightning 30B-A3B는 52층 가운데 어텐션 층이 6개뿐입니다. 나머지는 토큰마다 캐시를 쌓지 않는 Mamba 층과 MoE 층입니다.

8k에서 둘 다 들어가는 모델이라면, 토큰당 캐시가 작은 쪽이 64k에서도 들어갈 가능성이 큽니다. CanRun은 슬라이딩 윈도·하이브리드 모델에서 컨텍스트에 따라 커지는 층만 셉니다. 크기가 고정된 부분(짧은 윈도, 선형 층의 상태)은 빼므로, 이 모델들의 KV 캐시 수치는 실제보다 조금 작게 나옵니다. 원리는 ‘KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까’ 가이드에서 자세히 다룹니다.

답이 늦게 시작되는 이유 — 프롬프트 처리 속도

로컬 모델의 속도는 두 가지입니다. 보낸 내용을 읽는 프롬프트 처리 속도와, 답을 쓰는 생성 속도입니다. CanRun의 판정과 속도 범위는 생성 속도 추정입니다. 에이전트는 프롬프트가 깁니다. 세션 첫 턴에는 에이전트 지시문과 도구 설명이 모두 들어갑니다. 이후 턴에는 파일 전체나 긴 명령 출력이 붙기도 합니다. 모델은 이 내용을 다 읽은 뒤에야 답의 첫 단어를 씁니다.

읽기는 쓰기보다 토큰당 훨씬 빠릅니다. GPU가 프롬프트는 여러 토큰을 한꺼번에 처리하고, 답은 한 토큰씩 차례로 쓰기 때문입니다. llama.cpp의 NVIDIA 카드 성능 모음을 보면 프롬프트 처리(pp512)가 생성(tg128)보다 몇십 배 빠릅니다. CanRun은 프롬프트 처리 속도를 카드의 FP16 연산 성능으로, 생성 속도는 메모리 대역폭으로 추정합니다. 프롬프트 처리 추정은 대략값(±40%)입니다. 조합 페이지는 모델 전체가 GPU에 올라갈 때만 이 값을 보여 주고, 전문가나 층 일부가 시스템 RAM에 있으면 추정하지 않습니다. 이 추정은 모델 크기에 따라 달라집니다. 같은 카드에서 Qwen3.8 27B 같은 27B dense 모델은 7B 모델의 4분의 1쯤 되는 속도로 읽습니다.

런타임은 바뀌지 않은 부분을 다시 읽지 않습니다. llama-server는 앞 요청과 앞부분이 같으면 그 부분의 KV 캐시를 그대로 재사용합니다. 그래서 달라진 뒷부분만 처리합니다(cache_prompt, 기본으로 켜짐). Ollama API 문서도 prompt_eval_duration을 캐시되지 않은 프롬프트 토큰을 처리한 시간으로 설명합니다. 에이전트가 대화 끝에 내용을 덧붙이기만 하면, 턴마다 새로 붙은 부분을 주로 읽습니다. 프롬프트 앞쪽이 바뀌면 그 지점부터 뒤는 전부 다시 읽습니다. 슬라이딩 윈도·하이브리드 모델(이 글의 8개 중 6개)은 llama-server가 저장해 둔 체크포인트(--ctx-checkpoints)로만 되돌아갈 수 있습니다. 그래서 중간이 바뀌면 더 앞에서부터, 심하면 처음부터 다시 읽습니다.

Ollama에서 프롬프트를 읽는 속도는 prompt_eval_count에서 prompt_eval_cached_count를 뺀 값을 prompt_eval_duration으로 나눠 구합니다. 시간 값은 나노초 단위입니다. ollama run <모델> --verbose로 실행하면 같은 값을 ‘prompt eval rate’로 보여 주고, 모델을 올리는 데 걸린 시간은 load_duration에 나옵니다. llama-server는 응답의 timings 객체에 prompt_per_second와 캐시에서 다시 쓴 토큰 수(cache_n)를 기본으로 넣어 줍니다. 이후 턴에서 cache_n이 0에 가까우면 프롬프트 전체를 다시 읽은 것입니다.

답이 아예 오지 않는다면 모델을 아직 올리는 중일 수 있습니다. OpenClaw 로컬 모델 문서는 멈춘 것처럼 보이는 흔한 원인으로 콜드 스타트를 꼽습니다. 느린 서버라면 두 가지 타임아웃을 늘리라고 안내합니다. 하나는 제공자 쪽 models.providers.<id>.timeoutSeconds입니다. 다른 하나는 실행 쪽 agents.defaults.timeoutSeconds입니다. Ollama는 기본 설정에서 모델을 5분 동안만 메모리에 두고 내립니다. 이 시간은 OLLAMA_KEEP_ALIVE로 바꿀 수 있습니다(Ollama FAQ). ollama ps의 PROCESSOR 열에 CPU와 GPU가 나뉘어 나오면, 모든 턴이 표의 오프로드 칸처럼 느려집니다.

설정 — Ollama·llama.cpp·OpenClaw·OpenCode·Claude Code

이 설정들은 자주 바뀌므로 각 도구의 공식 문서(출처 참고)를 기준으로 삼으세요. 아래에는 메모리를 좌우하는 부분만 정리했습니다. CanRun 조합 페이지도 표에서 고른 컨텍스트와 KV 캐시 종류에 맞춘 Ollama·llama.cpp 명령을 보여 줍니다. 예시는 ‘GeForce RTX 5060 Ti 16GB에서 gpt-oss-20b’ 페이지에서 볼 수 있습니다.

Ollama

서버 전체 컨텍스트를 정하고 Ollama를 다시 시작합니다. Windows라면 작업 표시줄 아이콘에서 Ollama를 먼저 종료합니다. 그다음 PowerShell에서 실행합니다.

$env:OLLAMA_CONTEXT_LENGTH="65536"; ollama serve

macOS·Linux에서는 OLLAMA_CONTEXT_LENGTH=65536 ollama serve로 실행합니다. 계속 쓸 값이라면 Ollama 앱의 컨텍스트 슬라이더나 계정의 환경 변수로 정합니다. 방법은 ‘올라마(Ollama)가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값’ 가이드에 있습니다. 모델을 올린 뒤 ollama ps를 실행합니다. CONTEXT 열이 정한 길이인지, PROCESSOR 열이 100% GPU인지 확인합니다.

컨텍스트 표에서 f16은 넘치고 q8_0은 들어간다면 KV 캐시를 양자화합니다. Ollama는 서버를 띄울 때 OLLAMA_KV_CACHE_TYPE(f16·q8_0·q4_0)을 지정하고 플래시 어텐션을 켜야만 KV 캐시를 양자화합니다. 이 설정은 그 서버가 돌리는 모든 모델에 적용됩니다 (Ollama 문서, 2026-09-29 확인). PowerShell에서는 이렇게 실행합니다.

$env:OLLAMA_CONTEXT_LENGTH="65536"; $env:OLLAMA_FLASH_ATTENTION="1"; $env:OLLAMA_KV_CACHE_TYPE="q8_0"; ollama serve

llama.cpp(llama-server)

PowerShell, macOS, Linux 모두 명령이 같습니다.

llama-server -m model.gguf -c 65536 -ctk q8_0 -ctv q8_0 -fa on

-c는 직접 지정하세요. 비워 두면 llama-server는 모델이 지원하는 최대 길이에서 출발합니다. Qwen3.6 35B-A3B라면 256k입니다. 그러다 메모리가 모자라면 자동 배치(--fit, 기본으로 켜짐)가 가중치를 옮기기 전에 컨텍스트부터 줄입니다. 줄이는 하한은 --fit-ctx로 정하며 기본값은 4k입니다. 그러면 에이전트는 기대보다 훨씬 짧은 컨텍스트를 받게 됩니다. -c를 지정하면 컨텍스트는 그대로 둡니다. 대신 가중치를 시스템 RAM으로 옮기고, MoE 모델이면 전문가부터 옮깁니다. 실제로 잡힌 길이는 시작 로그에서 확인합니다. f16 KV 캐시를 쓰려면 -ctk와 -ctv를 빼면 됩니다. README가 OpenAI 방식 도구 호출에 필요하다고 적은 채팅 템플릿(--jinja)은 기본으로 켜져 있습니다.

OpenClaw

OpenClaw에서는 /v1을 붙이지 않은 Ollama 기본 주소(http://localhost:11434)로 연결하세요. 문서에 따르면 OpenAI 호환 /v1 주소를 쓰면 도구 호출이 깨집니다. 그러면 모델이 도구 호출을 일반 텍스트로 써 버릴 수 있습니다. OpenClaw는 스스로 찾아낸 로컬 모델에 보통 32k를 보내고, 이 값이 서버 설정보다 우선합니다. OLLAMA_CONTEXT_LENGTH를 64k로 정해도, 그 모델의 contextTokens나 params.num_ctx를 올리기 전에는 32k로 올라갑니다. 두 설정은 Ollama 고급 설정 문서에 나오고, 어느 값이 적용됐는지는 ollama ps의 CONTEXT 열에서 확인합니다. OpenClaw가 직접 관리하는 llama.cpp 설치에서는 추천 구성이 64k 컨텍스트를 씁니다.

OpenCode

OpenCode 문서는 Ollama와 llama-server를 OpenAI 호환 제공자로 연결합니다. 이때 baseURL은 /v1로 끝납니다. 로컬 모델마다 limit.context를 서버에 실제로 잡힌 컨텍스트와 같게 적으세요. 그래야 OpenCode가 남은 자리를 제대로 셉니다. 문서는 도구 호출이 안 될 때 Ollama의 num_ctx를 늘려 보라고도 안내합니다.

Claude Code

ollama launch claude는 Ollama의 Anthropic 호환 API로 Claude Code를 연결합니다. Ollama 문서는 로컬 모델이면 64k 이상을 권하므로, 위 Ollama 설정으로 길이를 정하고 ollama ps의 CONTEXT 열로 확인합니다.

이 숫자는 얼마나 확실한가

메모리 수치는 실제 GGUF 파일 크기와 파일 헤더, 모델 설정으로 공식에 따라 계산했습니다. 그래서 오차 범위를 붙이지 않습니다. 속도는 추정치라서 오차 범위와 신뢰 라벨을 함께 붙입니다. 보정된 추정은 NVIDIA·AMD 카드에서 dense 모델을 GPU에만 올릴 때 ±12%입니다. MoE 모델, 부분 오프로드, 그 밖의 하드웨어에서는 ±20%입니다. 이론 추정은 ±30%이고, MoE 전문가를 시스템 RAM에 두는 경우처럼 실제 속도의 편차가 큰 구성에 붙습니다. 이 글의 컨텍스트 표 세 개에서 전문가를 RAM에 둔 칸은 이론 추정입니다. RTX 5060 Ti 16GB의 gpt-oss-20b 8k·f16 칸에는 ‘실측’ 라벨이 붙고, 나머지는 보정된 추정입니다. 조합 페이지의 프롬프트 처리 추정은 이보다 거친 ±40%입니다.

‘실측’ 라벨의 근거는 llama.cpp의 gpt-oss 실행 안내 토론에 올라온 공개 벤치마크 한 건입니다. 2k 컨텍스트에서 llama-bench로 잰 값이고, CanRun이 직접 잰 것은 아닙니다. 아래에 CanRun의 8k 추정 범위와 함께 보여 줍니다.

정한 길이만큼의 메모리는 모델을 올릴 때 미리 잡히므로 메모리 수치는 첫 턴부터 그대로입니다. 각 행의 속도만 컨텍스트가 그 길이까지 찼다고 가정하고, 에이전트 세션은 쓰는 동안 그 길이까지 차 갑니다. 표는 다음 조건을 가정합니다. Windows에서 그 카드가 화면도 출력하고, 시스템 RAM은 32GB(DDR5)입니다. 모델은 하나만 올리고, 요청은 한 번에 하나만 처리합니다. Ollama FAQ에 따르면 필요 메모리는 OLLAMA_NUM_PARALLEL과 컨텍스트 길이를 곱한 만큼 늘어납니다. 동시 요청을 쓰면 표보다 메모리가 더 듭니다. Ollama와 llama.cpp는 메모리를 스스로 추정합니다. llama.cpp 자동 배치는 카드마다 VRAM을 조금 비워 두기도 합니다. 그래서 여기서 아슬아슬하게 들어가는 모델이 실제로는 일부 시스템 RAM으로 갈 수 있습니다. 내 PC에서는 ollama ps의 PROCESSOR 열이나 llama.cpp 시작 로그를 기준으로 봅니다.

생각 모드가 있는 모델에는 속도 기준을 1.5배 엄격하게 적용합니다. 생각 모드를 켜면 답 하나에 토큰을 훨씬 많이 쓰기 때문입니다. 아래 기준표에는 이 내용이 빠져 있습니다. 이 글의 모델 가운데 gpt-oss-20b는 늘 생각합니다. Qwen3.6 35B-A3B, Qwen3.8 27B, Qwen3.5 9B에는 생각 모드가 있습니다. Gemma 4 26B-A4B와 Nemotron 3.5 Lightning 30B-A3B도 마찬가지입니다. Qwen3 30B-A3B (2507)과 Mistral Small 3.2 24B에는 생각 모드가 없습니다. CanRun은 모델이 코드를 얼마나 잘 쓰는지, 도구를 얼마나 잘 부르는지는 평가하지 않습니다.

다음 단계

• Ollama 기본 컨텍스트와 설정 방법: 올라마(Ollama)가 느리거나 앞 내용을 잊을 때 — 컨텍스트 기본값
• KV 캐시가 커지는 원리와 q8_0·q4_0: KV 캐시와 컨텍스트 길이 — 컨텍스트를 늘리면 VRAM이 얼마나 더 필요할까
• 8k에서 VRAM 구간별로 들어가는 모델: 로컬 LLM 사양 — VRAM 8~32GB로 돌릴 수 있는 모델 (2026)

자주 묻는 질문

로컬 코딩 에이전트에는 컨텍스트가 얼마나 필요한가요?

Ollama 문서 기준으로 64k 이상입니다. Qwen3.6 35B-A3B 모델 카드는 생각 능력을 위해 128k 이상을 권합니다. 모델 전체가 GPU에 남는 범위에서 가장 긴 컨텍스트를 고르세요. f16 KV 캐시로 64k를 쓰면 Qwen3.8 27B는 21.9GB, gpt-oss-20b는 14.2GB가 필요합니다. 사용 가능 메모리는 24GB 카드가 23.4GB, 16GB 카드가 15.4GB입니다.

로컬 에이전트가 답을 늦게 시작하거나 타임아웃이 나는 이유는 무엇인가요?

대개 긴 프롬프트를 읽는 중이거나 모델을 올리는 중이기 때문입니다. Ollama API 응답의 prompt_eval_duration과 load_duration을 비교해 보세요. OLLAMA_KEEP_ALIVE로 모델을 메모리에 오래 두고, 에이전트의 타임아웃을 늘립니다. OpenClaw 문서에 timeoutSeconds 설정이 나옵니다. ollama ps에 CPU와 GPU가 나뉘어 나오면 컨텍스트를 줄이거나 q8_0 KV 캐시를 씁니다. 100% GPU가 나올 때까지 조정합니다.

q8_0 KV 캐시를 쓰면 코딩 품질이 떨어지나요?

Ollama FAQ는 q8_0의 정밀도 손실을 아주 작다고 설명합니다. 메모리는 q8_0이 f16의 약 절반, q4_0이 약 4분의 1이고, q4_0의 손실은 작거나 중간 정도라고 합니다. CanRun은 출력 품질을 재지 않습니다. 메모리 기준으로는 f16이 원하는 컨텍스트에 안 들어갈 때 q8_0을 먼저 씁니다. q8_0으로도 넘칠 때만 q4_0을 씁니다. 24GB 카드에서 Qwen3.6 35B-A3B를 64k로 GPU에 다 올리려면 q8_0이 필요합니다.

에이전트가 도구를 실행하지 않고 호출 내용을 글자로 출력하는 이유는 무엇인가요?

연결 방식, 컨텍스트, 모델 가운데 하나가 원인일 수 있습니다. OpenClaw 문서에 따르면 Ollama의 OpenAI 호환 /v1 주소로 연결하면 도구 호출이 깨집니다. 이때 모델이 호출 내용을 일반 텍스트로 쓰기도 하니, /v1 없는 기본 주소로 연결합니다. OpenCode 문서는 도구 호출이 안 되면 Ollama의 num_ctx를 늘려 보라고 합니다. 모델도 도구 호출을 지원해야 합니다. Qwen3.6 35B-A3B와 Qwen3 30B-A3B (2507) 모델 카드에는 도구 호출 설명이 있습니다. gpt-oss-20b 모델 카드에는 함수 호출이 적혀 있습니다.

CanRun 목록에 없는 코딩 모델도 확인할 수 있나요?

네, 확인할 수 있습니다. Qwen3-Coder-30B-A3B-Instruct는 설정 파일상 Qwen3 30B-A3B (2507)과 구조가 같습니다(48층, KV 헤드 4개, 전문가 128개). Devstral Small 2507은 Mistral Small 3.1을 바탕으로 만든 모델로, Mistral Small 3.2 24B와 층 수(40층)·KV 헤드 수(8개)가 같습니다. 그래서 두 모델은 위 표의 해당 행을 거의 그대로 참고할 수 있습니다. 다른 모델은 계산기에 Hugging Face 모델 id를 붙여 넣고 컨텍스트를 64k로 고르면 같은 메모리 계산을 해 줍니다. 불러온 모델의 결과는 이론 추정(±30%)입니다. 계산기는 그 모델에 생각 모드가 있는지 알 수 없어서, 생각 모드 모델용 엄격한 기준은 적용하지 않습니다.

출처

• Ollama 문서: 컨텍스트 길이: 에이전트·웹 검색·코딩 도구에 64k 이상 권고, VRAM 구간별 기본값, ollama ps, CPU 오프로드를 피하라는 권고
• Ollama 문서: OpenCode 연동: ollama launch opencode, OpenCode에 64k 이상 컨텍스트가 필요하다는 설명, 로컬 모델은 64k 이상을 직접 설정
• Ollama 문서: OpenClaw 연동: ollama launch openclaw, 로컬 모델이면 64k 이상 권고
• Ollama 문서: Claude Code 연동: ollama launch claude, Anthropic 호환 API, 로컬 모델은 64k 이상을 직접 설정
• Ollama FAQ: 모델을 메모리에 두는 시간(기본 5분, OLLAMA_KEEP_ALIVE), KV 캐시 양자화와 정밀도 설명, OLLAMA_NUM_PARALLEL에 따라 늘어나는 메모리
• Ollama API 문서: 사용량: prompt_eval_count, prompt_eval_cached_count, 캐시되지 않은 프롬프트 토큰 처리 시간인 prompt_eval_duration, load_duration, 나노초 단위
• Ollama 소스: api/types.go: --verbose가 보여 주는 ‘prompt eval rate’를 캐시되지 않은 토큰으로 계산
• OpenClaw 문서: Ollama: Ollama 자체 API 사용, /v1 주소를 쓰면 도구 호출이 깨진다는 경고
• OpenClaw 문서: Ollama 고급 설정: 찾아낸 로컬 모델의 32k 상한, Ollama 자체 기본값보다 우선하는 contextTokens·params.num_ctx, OpenAI 호환 모드의 num_ctx
• OpenClaw 문서: 로컬 모델: 프롬프트·도구·대화·출력이 들어갈 자리, 64k 컨텍스트의 llama.cpp 추천 구성, 타임아웃과 콜드 스타트
• OpenCode 문서: 제공자: Ollama·llama-server를 OpenAI 호환 제공자로 연결, limit.context, 도구 호출이 안 될 때 num_ctx를 늘리라는 안내
• llama.cpp 서버 README: -c(0이면 모델 최대 길이), --fit·--fit-ctx, -ctk·-ctv, -fa, --jinja와 도구 호출, cache_prompt, --ctx-checkpoints, cache_n·prompt_per_second가 담긴 timings 객체
• llama.cpp 소스: server-context.cpp: 슬라이딩 윈도·하이브리드 모델은 컨텍스트 체크포인트로 되돌아가거나 프롬프트를 처음부터 다시 처리
• llama.cpp PR #16653 (자동 배치): 지정하지 않은 컨텍스트를 가중치보다 먼저 줄인다는 설명, MoE 모델은 dense 가중치를 먼저 GPU에 둔다는 설명
• llama.cpp 토론 #15013: NVIDIA CUDA 성능: NVIDIA 카드별 pp512·tg128 결과
• llama.cpp의 gpt-oss 실행 안내 토론: RTX 5060 Ti 16GB·gpt-oss-20b 공개 벤치마크 결과
• Qwen3.6-35B-A3B 모델 카드: 하이브리드 구조, 전문가 구성, 기본 지원 컨텍스트, 생각 능력을 위한 128k 이상 권고, 생각 모드 기본값, 도구 호출
• Qwen3.8-27B 모델 카드: 하이브리드 구조, KV 헤드 수, 기본 지원 컨텍스트, 생각 모드 기본값
• Qwen3.5-9B 모델 카드: Gated DeltaNet·Gated Attention 하이브리드 구조
• Qwen3-30B-A3B-Instruct-2507 모델 카드: 48층, KV 헤드 4개, 생각 모드 없음, 도구 호출
• Qwen3-Coder-30B-A3B-Instruct 설정 파일: 48층, KV 헤드 4개, 전문가 128개 중 8개로 Qwen3-30B-A3B-Instruct-2507과 같음
• Devstral Small 2507 모델 카드와 설정 파일: Mistral Small 3.1을 바탕으로 만든 모델, 128k 컨텍스트, 40층·KV 헤드 8개
• Mistral Small 3.2 24B 설정 파일: 40층, KV 헤드 8개, 슬라이딩 윈도 없음
• gpt-oss-20b 모델 카드와 설정 파일: 함수 호출, 슬라이딩 윈도 층과 전체 어텐션 층의 교차 배치
• Gemma 4 26B-A4B 설정 파일: 슬라이딩 윈도 25층·전체 어텐션 5층, 1024토큰 윈도
• Nemotron 3.5 Lightning 30B-A3B 설정 파일: 52층 가운데 어텐션 6층, 나머지는 Mamba·MoE 층