두 대화가 각각 128K를 쓰면, 캐시와 동시 요청은 어떻게 되나

EVO-X2에서 llama-server 슬롯 두 개에 각각 약 120K토큰짜리 대화를 올려 캐시 재사용과 동시 요청을 쟀습니다. 후속 질문은 99.9% 캐시를 써서 2초 안에 답했고, 두 요청이 겹치면 생성 속도가 떨어졌습니다.

로컬 LLM 서버 하나를 두 사람(또는 두 agent)이 각자 긴 대화로 쓰면 어떻게 되는지 쟀습니다. EVO-X2(Ryzen AI Max+ 395, 128GB)의 llama-server에 슬롯을 두 개 열고, 각 슬롯에 약 120K토큰짜리 대화를 올렸습니다. 확인하고 싶었던 것은 두 가지입니다. 대화를 번갈아 이어 갈 때 캐시가 유지되는지, 그리고 두 대화가 동시에 요청을 보내면 속도가 어떻게 되는지입니다.

99.94%후속 질문의 캐시 재사용 비율
약 1.8초후속 질문 첫 토큰까지 (처음은 700초대)
9.0~9.3 tok/s번갈아 요청할 때 생성
4.7 / 7.4 tok/s동시에 요청할 때 A / B 생성

설정

항목 값
모델 Qwen3.8 Flash Next Uncensored IQ4_XS
엔진 llama.cpp 90c26fc, HIP / ROCm 10
슬롯 2개, 전체 context 262,144, 슬롯당 131,072
대조군 슬롯 1개, context 131,072, 나머지 같음
KV / 프롬프트 캐시 K/V Q8_0, Flash Attention on, RAM 프롬프트 캐시 8GiB
입력 공개 소설 원문(대화 A)과 C++ 코드(대화 B), 각 약 120K토큰짜리 첫 프롬프트
출력 요청당 최대 256토큰, thinking off, temperature 0

매 요청마다 전체 대화 이력을 chat template로 다시 만들어 보냈습니다. 일반적인 채팅 클라이언트가 대화를 통째로 다시 보내는 방식과 같습니다. 실제 OpenCode 앱 두 개를 띄운 시험은 아니고, API로 그 흐름을 재현했습니다. 응답에 이모지가 섞이면 토큰 ID가 빠지는 llama-server 버그가 있어서 주요 이모지 대역은 문법으로 막았습니다.

처음 한 번은 오래 걸린다

요청 첫 토큰까지 전체 생성
슬롯 2개, 대화 A 처음 705.73초 731.17초 10.03 tok/s
슬롯 2개, 대화 B 처음 745.09초 772.42초 9.34 tok/s
슬롯 1개, 대화 A 처음 743.56초 770.19초 9.58 tok/s

약 120K토큰을 처음 읽는 데 12분 안팎이 걸렸습니다. 각 1회 측정입니다.

번갈아 이어 가면 캐시가 그대로 쓰인다

대화 이력을 유지한 채 A, B에 번갈아 후속 질문을 세 번씩 보냈습니다.

대화 캐시 재사용 비율 첫 토큰까지 생성
A (3회) 99.94% 1.85초 8.96 tok/s
B (3회) 99.94% 1.83초 9.27 tok/s

새로 처리한 토큰은 요청마다 78개뿐이었습니다. 두 대화가 각자 슬롯을 하나씩 차지해서, 다른 대화가 끼어들어도 서로의 캐시를 밀어내지 않았습니다. 재사용 비율은 요청 입력 중 캐시에서 가져온 토큰의 비율입니다.

슬롯이 하나일 때도 A → B → A로 돌아왔을 때 A의 캐시가 살아 있었습니다(123,135토큰 재사용, 첫 토큰까지 2.02초). RAM 프롬프트 캐시(8GiB)가 B로 넘어갈 때 A의 상태를 보관했다가 돌려준 것으로 보입니다. 이 경우는 1회만 쟀습니다.

동시에 보내면 생성이 느려진다

두 대화에서 후속 질문을 거의 같은 순간(차이 0.004~0.006초)에 보냈습니다. 두 슬롯이 실제로 동시에 돌았습니다.

대화 첫 토큰까지 생성
A (3회 평균) 2.40초 4.72 tok/s
B (3회 평균) 2.40초 7.41 tok/s

번갈아 보낼 때(약 9 tok/s)보다 둘 다 느려졌고, A가 더 많이 느려졌습니다. 두 요청의 생성 속도를 단순히 더한 값(약 12 tok/s)을 실제 처리량으로 볼 수는 없습니다. 두 요청이 출력한 토큰을 전체 소요 시간으로 나누면 회차별로 8.99, 7.93, 6.85 tok/s였습니다. 동시 요청에서는 출력 길이가 회차마다 달라서(A 13~53토큰, B 56~205토큰) 이 값도 출력 길이의 영향을 받습니다.

정리하면

긴 대화 두 개를 한 서버에서 나눠 쓰는 것은 충분히 가능했습니다. 각 대화가 슬롯을 하나씩 가지면 서로의 캐시를 지키고, 후속 질문은 2초 안에 답이 시작됩니다. 다만 두 대화가 동시에 생성하면 각자의 속도가 크게 떨어지므로, 두 agent가 동시에 긴 출력을 내는 작업에서는 체감 속도가 절반 가까이 될 수 있습니다.

측정 중 OOM이나 GPU 오류는 없었고, 최소 가용 메모리는 14.3GiB였습니다. 품질이나 대화 간 내용 분리는 이 시험으로 확인하지 않았습니다.