결론: 아래의 글은 일부 오류가 섞여있는 글이라서 폐기해야 하는 글입니다. 아래 같은 분들이 있는 것은 사실이지만 적어도 Hermes agent를 사용할 때는 나타나지 않는다는 점을 확인했습니다.
llama.cpp + Qwen3.6-27B에서 매 호출마다 prompt 재처리되는 문제 — --swa-full로 절반 가까이 해결
llama.cpp 빌드 b200 (25b1bc9c2)에서 Qwen3.6-27B-MTP를 Hermes 계열 코딩 에이전트에 물려 쓰고 있었는데, 호출할 때마다 prompt가 거의 처음부터 재처리됐습니다. 같은 시스템 프롬프트, 같은 코드베이스인데도 cache miss 비율이 50%. ctx는 빨리 차오르고 매 호출이 느렸습니다.
같은 문제 보고
Reddit에 동일 증상 보고가 있습니다 — opencode/pi.dev 사용자들이 같이 겪고 있는 문제입니다:
"https://www.reddit.com/r/LocalLLaMA/comments/1td9stc/"
원인 (추정)
Qwen3.6은 hybrid SSM-Attention 구조(Gated DeltaNet)입니다. 로그상 n_swa = 0이라 sliding window attention을 안 써야 하지만, hybrid/recurrent memory path가 내부적으로 SWA 캐시 제거 로직을 공유하는 것으로 보입니다. 그래서 매번 캐시가 잘려나갑니다.
시도했지만 효과 없던 것들
해결
서버 실행 옵션에 --swa-full 한 줄 추가:
llama-server ... --swa-full
SWA 캐시를 잘라내지 않고 전체 보존하는 옵션입니다. VRAM은 약 +1.2 GB 증가 — 24GB 카드면 부담 없습니다.
측정 결과
설정
| Miss rate
| Hits 시 prefix 재사용률
|
|---|
기본 (MTP on)
| 50%
| 92%
|
MTP off
| 60%
| 89%
|
preserve_thinking
| 100%
| (표본 부족)
|
+ swa-full
| 25%
| 98%
|
같은 워크플로우를 두 차례 측정 (총 17 호출). 표본은 작지만 두 세션 모두 일관된 결과였습니다.
보너스 — MTP --spec-draft-n-max 스윕
같은 김에 speculative draft 토큰 수도 측정해봤습니다:
n-max
| TPS
| Accept rate
|
|---|
0 (off)
| 36.75
| —
|
1
| 51.46
| 89%
|
2
| 57.23
| 85%
|
3
| 51.33
| 68%
|
n=2가 sweet spot. n=3은 accept rate가 떨어져서 낭비된 draft 비용이 이득을 깎습니다.
주의
--swa-full로 다 잡히는 건 아닙니다. 남은 25% miss는 실제 prefix가 바뀐 호출(새 세션, 시스템 프롬프트 변경 등)이라 어쩔 수 없는 부분입니다. 더 근본적인 fix는 업스트림에서 PR #22826, #22929로 진행 중입니다.
확실한 개선이고, 한 줄 추가라 부담도 없으니 같은 증상 겪으시는 분들은 한 번 적용해보시기 바랍니다.
