로컬 Qwen 긴 컨텍스트가 일찍 멈출 때 KV Cache·백엔드·GPU 한계를 분리해 진단하는 법

로컬 Qwen을 128K 컨텍스트로 설정했는데도 72K 부근에서 오류가 나거나, 너무 느려져 사용할 수 없거나, 생성은 끝났지만 앞부분 지시를 잊는 일이 생길 수 있습니다. 보통은 하나의 “정답 옵션”이 없는 문제입니다. 모델 가중치 양자화, KV Cache, 추론 백엔드, GPU 배치 방식이 함께 한계를 만듭니다.

이 글의 목표는 128K를 억지로 실행하는 것이 아니라, 현재 장비에서 안정적이고 충분히 빠르며 긴 입력의 정보를 실제로 활용하는 구간을 찾는 것입니다. 먼저 증상을 분류하고, 이후에는 테스트마다 변수 하나만 바꿉니다. 그러면 cache를 바꿀지, backend를 바꿀지, GPU split을 조정할지, 운영 컨텍스트 목표를 낮출지 근거를 갖고 결정할 수 있습니다.

결론부터 말하면 설정값은 상한일 뿐, 사용 가능성을 보장하지 않는다

128K 설정은 백엔드에 그 크기의 입력을 준비하라고 요청할 뿐입니다. 실제로 동작하려면 다음 메모리 예산이 맞아야 합니다.

model weights + KV cache + runtime workspace + safety margin ≤ memory the backend can actually use

모델 가중치는 로딩할 때 크고 거의 고정된 공간을 차지합니다. KV Cache는 이전 token의 attention 상태를 저장하므로 유지하는 token 수에 따라 커집니다. workspace와 임시 buffer는 backend, batch, kernel에 따라 달라집니다. 메모리 할당이 성공해도 속도나 먼 위치의 정보 회상 능력이 먼저 실용 범위를 벗어날 수 있습니다.

따라서 세 가지를 따로 확인해야 합니다. 입력이 들어가는지, 허용 가능한 시간에 끝나는지, 시작 부분의 정보를 정확히 사용하는지입니다. 화면에 표시된 최대 컨텍스트 값만으로는 어느 것도 알 수 없습니다.

증상을 먼저 나누면 잘못된 부품을 고치는 일을 피할 수 있다

“128K까지 못 간다”는 표현은 서로 다른 실패를 한데 묶습니다. 자신의 현상과 가장 가까운 항목부터 확인하세요.

증상	가능성이 높은 방향	첫 확인 항목
모델 로딩 또는 긴 컨텍스트 할당 때 즉시 OOM	가중치와 KV Cache의 VRAM 경쟁, 특정 GPU의 할당 실패	GPU별 peak VRAM과 여유 공간을 따로 기록
늘 비슷한 token 수에서 backend error	KV 형식, 백엔드 구현, 연속 할당 경계	모델과 하드웨어를 고정하고 cache 또는 backend만 변경
prompt는 받지만 prefill이나 생성이 극단적으로 느림	대역폭, GPU 간 전송, kernel, 지나치게 큰 목표	prompt 처리와 생성 속도를 분리 측정
생성은 끝나지만 앞부분 조건이나 사실을 잊음	단순 용량이 아닌 effective context 품질	입력 곳곳에 배치한 사실의 회상 테스트
동일한 실행이 통과했다가 실패함	부족한 여유, 동시 부하, 불안정한 runtime	다른 부하를 제거하고 같은 테스트를 3회 반복

메모리에 들어가지만 너무 느린 문제라면 더 작은 KV 형식만으로 해결되지 않을 수 있습니다. 들어가지만 앞부분을 기억하지 못한다면 VRAM을 늘려도 품질이 자동으로 좋아지지 않습니다.

72K에서 128K로 늘었다는 한 사례가 보여 주는 범위

2026년 9월 23일의 구성 보고에서 Nigel Hungerford-Symes는 RTX 5060 Ti 16GB와 RTX 3070 8GB에서 Qwen3.8-27B(Unsloth UD-Q5_K_M)를 실행했다고 적었습니다. 보고된 128K 구성은 beellama.cpp + kvarn5 KV + MTP n=2를 사용했고, 짧은 컨텍스트에서 약 36 tok/s, 126K에서 약 18 tok/s였습니다. 이전 mainline llama.cpp와 q8_0 KV 구성은 약 72K에서 멈췄다고 합니다.

이 사례는 특정 한 대의 장비에서 추론 stack을 바꾸면 사용 가능한 길이가 달라질 수 있다는 점을 보여 줍니다. 그러나 backend, KV-cache 방식, 다른 runtime 설정이 동시에 바뀌었으므로 kvarn5 하나가 72K에서 128K로 늘렸다고 증명하지는 못합니다. 속도 수치를 다른 GPU나 모델에 그대로 적용할 수도 없습니다.

따라서 원인 확정이 아니라 진단 단서로 사용하세요. 늘 같은 길이에서 멈춘다면 모델 파일만 보지 말고 KV Cache와 backend도 통제된 비교에 넣어야 합니다.

변경 전에 현재 72K 구성을 재현 가능한 baseline으로 남긴다

먼저 현재 상태를 다시 실행할 수 있을 정도로 기록하세요. baseline이 없으면 새 구성이 성공해도 어떤 변화가 효과를 냈는지 알 수 없습니다.

영역	기록할 값
모델	전체 model 이름, 정확한 파일, weight quantization, 파일 크기
백엔드	backend 이름, version 또는 commit, 실행 방식
컨텍스트	requested window, 실제 input tokens, 예약한 output tokens
KV Cache	data type 또는 방식, GPU/host 배치, 압축 설정
하드웨어	각 GPU 모델과 VRAM, system RAM, PCIe topology
배치	GPU split, offload 범위, 장치 간 작업 여부
runtime	batch, concurrency, sampling, 최대 출력 길이
결과	성공/오류, 정확한 오류문, peak VRAM/RAM, prefill 및 생성 속도

16GB GPU와 8GB GPU를 단순한 24GB 공유 pool로 계산하지 마세요. backend가 가중치, cache, workspace의 위치를 결정합니다. 한 GPU가 먼저 찰 수 있고, 긴 입력에서는 장치 간 전송이 속도 병목이 될 수 있습니다.

네 가지 변수를 한 번에 하나씩 시험한다

1. 가중치 양자화는 주로 고정 점유량을 바꾼다

Weight quantization은 모델을 로딩하는 데 필요한 메모리를 주로 바꿉니다. 더 작은 가중치는 KV Cache에 공간을 남길 수 있지만, 긴 사용 가능 컨텍스트를 보장하지 않고 품질이나 속도도 바꿀 수 있습니다.

가중치가 cache 공간을 밀어내는지 확인하려면 backend, KV 형식, test prompt를 고정하세요. weight quantization만 바꾸고, 확보된 VRAM과 실패 지점이 이동했는지 기록합니다.

2. KV Cache 형식은 token마다 증가하는 점유량을 바꾼다

KV Cache는 다음 token 생성에 재사용할 이전 상태를 저장합니다. 같은 모델과 표현이라면 메모리 사용량은 유지 token 수에 따라 대체로 증가하므로 긴 컨텍스트의 직접적인 조절점입니다.

두 cache 방식을 비교할 때 peak memory, 가장 긴 안정 입력, 회상 정확도를 함께 보세요. “128K가 들어갔다”는 것만으로 충분하지 않습니다. 먼 정보의 정확도가 낮아지거나 backend가 불안정해지면 운영상 성공이 아닙니다.

3. 백엔드는 형식을 실제로 구현하는 방법을 결정한다

Backends는 cache layout, allocation, multi-GPU placement, kernel에서 다를 수 있습니다. 같은 모델 파일과 같은 컨텍스트 값이어도 메모리 곡선과 속도가 달라질 수 있습니다.

새 backend가 다른 KV 형식을 필수로 요구한다면 결과를 “이 stack 전체가 통과했다”라고 기록하세요. 한 형식만 원인이라고 단정하지 마세요. 가능하면 두 backend가 모두 지원하는 공통 설정으로 별도의 A/B 테스트를 실행합니다.

4. 하드웨어 배치는 어떤 자원이 먼저 한계에 닿는지 결정한다

Multi-GPU에서 총 VRAM만 보는 것은 흔한 실수입니다. 한 장치에 충분한 연속 공간이 없거나, cache가 한 GPU에 몰리거나, workspace 여유가 없거나, GPU 간 전송 때문에 속도가 실용선 아래로 떨어질 수 있습니다.

각 GPU를 따로 모니터링하세요. 한 장치는 거의 가득 찼는데 다른 장치에는 뚜렷한 여유가 있다면 모델 품질을 낮추기 전에 split이나 placement를 조정합니다.

길이 ladder로 반복 가능한 긴 컨텍스트 검증을 실행한다

짧은 prompt에서 바로 128K로 뛰지 마세요. 고정된 길이 ladder를 쓰면 실패가 갑자기 발생하는지, 메모리·속도·회상이 점진적으로 나빠지는지 알 수 있습니다.

시작점으로 8K → 32K → 64K → 72K → 96K → 126K를 권합니다. 126K는 128K에 가깝고 출력용 예산을 명시적으로 남깁니다. 긴 출력을 원하면 입력 목표를 그만큼 줄여야 합니다.

동일한 controlled prompt set을 준비한다

1. 문자 수나 파일 크기로 추정하지 말고 목표 모델이 실제 사용하는 tokenizer로 token을 셉니다.
2. 입력의 약 10%, 20%부터 90%까지 서로 다른 “canary facts”를 놓습니다. 예: ORBIT-17 = copper.
3. 시작, 중간, 끝에 각각 coding constraint를 넣고 마지막 요청에서 조건을 다시 말한 뒤 작은 code 변경을 수행하게 합니다.
4. 모든 길이에서 content order, sampling, output budget을 동일하게 유지합니다.
5. 다른 시스템 부하를 끄고 중요한 길이는 3회 반복합니다.

Canary facts는 검색·회상을 측정할 뿐 전체 coding 능력을 대신하지 않습니다. 최종 검증에는 실제 업무와 비슷한 code, logs, repository documentation을 추가하세요.

매번 같은 지표를 기록한다

지표	답하는 질문
실제 input tokens	backend가 목표 길이를 정말 받았는가?
할당 결과와 정확한 error	용량 또는 호환성이 어디서 깨졌는가?
GPU별 peak VRAM과 peak RAM	어느 장치가 병목이 되었는가?
prompt 처리 시간 또는 속도	긴 입력 prefill이 허용 가능한가?
생성 속도	긴 prompt 이후 상호작용이 실용적인가?
맞힌 canary 수	먼 위치의 정보를 활용하는가?
충족한 coding constraints	긴 window가 실제 작업에 도움이 되는가?

테스트 전에 통과 기준을 적어 두세요. 예를 들어 목표 길이에서 3회 연속 완료, memory/backend error 없음, canary 10개 중 최소 9개 정답, prefill과 생성이 업무 시간 한도 안에 들어오는 조건입니다. 9/10은 예시일 뿐이며, 결과를 본 뒤 기준을 낮추지 않는 것이 핵심입니다.

결과에 따라 다음 조치를 고른다

같은 길이에서 안정적으로 OOM이 난다

먼저 어느 device가 가득 차는지 확인합니다. 컨텍스트가 늘수록 cache가 남은 여유를 소비한다면 더 작은 메모리를 쓰는 KV 방식을 비교합니다. 가중치 로딩 직후 이미 여유가 거의 없다면 더 작은 weight quantization을 비교합니다. 실행마다 하나만 바꾸고 실패 지점이 예상대로 이동하는지 봅니다.

새 backend는 128K, 기존 backend는 72K까지 간다

새 stack을 후보로 두고 3회 재현한 뒤 회상 테스트를 수행합니다. backend와 cache가 함께 바뀌었을 수 있으므로 확인 가능한 결론은 “후보 stack이 동작한다”입니다. 단일 root cause가 증명된 것은 아닙니다.

128K는 완료하지만 속도가 허용되지 않는다

이는 용량 실패가 아니라 운영 경계입니다. 일상 작업에는 더 작은 기본 window를 쓰고, 꼭 필요한 작업에서만 초장문 컨텍스트를 켜세요. 더 작은 모델, 다른 backend, 더 나은 placement도 비교할 수 있습니다. “실행 가능”과 “매일 쓸 가치가 있음”은 다른 판단입니다.

128K는 실행되지만 앞부분을 계속 잊는다

Effective-context quality 문제로 다룹니다. 같은 prompt를 64K, 72K, 96K에서 실행해 회상 곡선을 만드세요. 더 짧은 입력이 분명히 안정적이라면 할당 가능한 위치가 아니라 품질이 통과하는 위치를 운영 상한으로 정합니다. 매우 큰 repository 작업에서는 retrieval, chunking, 사전 요약으로 불필요한 정보를 줄일 수도 있습니다.

목표는 가장 큰 메뉴 숫자가 아니라 검증된 작업 window다

72K가 일상적인 repository와 logs를 이미 다룬다면 128K를 표시하기 위해 quantization, KV Cache, backend, GPU split을 한꺼번에 바꾸지 마세요. 안정적인 baseline을 보존하고, 각 변경이 용량·속도·회상 중 적어도 하나에서 측정 가능한 이득을 내는지 확인합니다.

100K가 넘는 입력이 정말 필요하다면 먼저 length ladder와 pass 기준을 만들고, 그 다음 cache와 backend 조합을 비교하세요. 유용한 최종 문장은 “이 모델, backend, cache, hardware는 126K에서 세 번 연속 필요한 속도와 회상 기준을 통과했다”입니다. 단순히 “128K를 지원한다”는 문장으로는 부족합니다.