I made my local LLM start thinking while I'm still typing: 12s → 3s wait on a 6 GB GPU (open source)
입력하는 동안 로컬 LLM이 미리 읽고 생각하게 했습니다: 6GB GPU에서 대기 시간 12초 → 3초
MAFDET는 사용자가 입력하는 동안 LLM의 KV 캐시를 갱신하고, Qwen3의 추론도 미리 진행하는 오픈소스 앱입니다. RTX 2060에서 Qwen3-4B의 답변 대기 시간은 12.2초에서 3.2초로 줄었지만, 미리 한 추론은 최종 입력이 바뀌면 정확성을 보장하지 않습니다.
- 주제
에디터 노트
읽기 선행과 추론 선행은 신뢰도를 따로 봐야 합니다. 최장 공통 접두사에 맞춰 KV 캐시를 되돌리는 읽기 선행은 처음부터 계산한 결과와 일치하도록 설계했고, 답변 생성도 입력이 그대로일 때만 재사용합니다. 반면 추론 선행은 수정 전 입력에서 만든 노트를 남기므로 결과가 달라질 여지가 있습니다. 24개 문제에서 정답률이 같았다는 결과는 산수 문제와 Qwen3-4B에 한정됩니다. 댓글에서 제기한 숫자 수정 사례도 9회 시험에서 맞았지만, 작성자 스스로 노트에 이전 값이 남는 약점이라고 했습니다. 따라서 대기 시간 감소는 확인된 성능이고, 다양한 입력에서 품질을 유지한다는 근거는 아직 제한적입니다. 추론 선행을 끄고 읽기 선행만 쓰는 선택지도 구분해 볼 필요가 있습니다.
AI 요약
사용자가 메시지를 입력하는 동안 모델이 프롬프트를 읽고 추론을 진행해 Enter 이후의 대기 시간을 줄이는 오픈소스 앱 MAFDET입니다. Windows와 NVIDIA GPU를 기준으로 만들었으며 CPU에서도 작동합니다. Linux 지원 경로는 마련했지만 아직 테스트하지 않았습니다.
입력 중 KV 캐시 갱신
LLM은 입력을 병렬로 처리하는 prefill 단계와 토큰을 하나씩 생성하는 decode 단계로 작동합니다. MAFDET는 입력이 멈출 때마다 텍스트를 토큰화하고, 마지막 몇 토큰은 단어 입력에 따라 토큰 분할이 바뀔 수 있어 보류합니다. 새 토큰과 캐시의 최장 공통 접두사를 찾아 캐시를 그 지점까지 되돌린 뒤 새 부분만 처리합니다. 중간 수정이나 붙여넣기에도 이 절차로 캐시를 처음부터 계산한 결과와 일치시킵니다. 저자는 mafdet judge로 처음부터 계산한 결과와 비교해 오류가 0이어야 한다고 설명합니다.
추론도 입력과 함께 진행
Qwen3의 thinking mode에서는 입력 중 32토큰 단위로 추론을 수행합니다. 메시지를 수정하면 기존 추론을 버리지 않고 새 메시지 뒤에 노트로 남깁니다. Enter를 누르면 모델이 그 지점부터 추론을 마치고 답합니다. 따라서 읽기 선행은 정확하지만 추론 선행은 아직 완성되지 않은 입력을 대상으로 하므로 결과가 처음부터 계산한 답과 달라질 수 있습니다. 입력이 멈춘 뒤 메시지가 그대로라면 답변 자체도 미리 생성할 수 있으며, 이 경우는 입력이 동일할 때만 재사용합니다.
저자는 추론 노트가 입력 미완성을 되풀이하는 문제를 줄이기 위해 모델에 사실과 중간 계산을 모으라고 지시하는 프레임을 썼습니다. 여섯 문장을 실시간 입력해 비교했을 때 사용자나 입력 상태를 언급한 문장의 비율은 일반 프레임의 86%에서 예시 문장과 logit bias를 적용한 뒤 17~26%로 내려갔다고 보고합니다. 이 수치는 작은 표본에서 나온 결과입니다.
RTX 2060에서 측정한 결과
RTX 2060 6GB, llama.cpp, Q4_K_M 모델로 입력 시나리오를 재생했습니다. Qwen3-4B는 실시간으로 입력한 산수 문제 24개에서 평균 대기 시간이 12.2초에서 3.2초로 줄었고 두 방식 모두 24개를 맞혔습니다. 중앙값은 10.7초에서 2.9초로 감소했습니다. 미리 수행한 추론은 평균 662토큰이었고 Enter 이후 남은 추론은 244토큰이었습니다. 14B는 VRAM을 넘어 CPU를 함께 사용하며, 문제 6개에서 평균 대기 시간이 108초에서 47초로 감소했습니다. 두 방식 모두 6개를 맞혔지만 저자는 실행 편차가 커서 대략적인 수준을 보여주는 표본이라고 밝혔습니다.
앱과 한계
GUI와 터미널 UI를 제공하고 Qwen3, Llama 3, Gemma 3, Mistral, Phi-4 모델을 지원합니다. llama.cpp 설치와 하드웨어별 모델 속도 추정도 앱에서 처리합니다. 읽기 선행은 llama.cpp가 실행할 수 있는 모델에서 작동하지만, 추론 선행은 Qwen3에서만 측정했습니다. Linux는 미검증이며 macOS와 AMD GPU 지원은 계획 단계입니다. GPU가 입력 중 다른 작업을 처리한다면 선행 계산이 추가 부하를 만듭니다.
Reddit 반응
- @daniellenton — 입력 중
12를 바탕으로3 × 12 = 36을 노트에 쓴 뒤 사용자가15로 고치면, 기존 노트에서12가 사라졌다고 모델에 알리는 부분이 코드에 없어 잘못된 답을 낼 수 있다고 지적했습니다.- @Oxygenne_ — 지적이 맞으며 기존 노트에 숫자가 바뀌었다는 안내는 없다고 답했습니다. 원래 24개 문제는 수정 없이 입력했으며, 수정 사례를 새로 시험해 9개 모두 맞혔지만 이 부분은 취약점이라고 밝혔습니다.
- @daniellenton — 해당 시험을 해줘서 고맙다고 했습니다. 이전 값이 새 값으로 바뀌었다고 노트에 명시하는 방법을 제안했고, 노트가 이미 결론에 도달한 뒤 숫자를 고치는 경우도 시험해 볼 만하다고 덧붙였습니다.
- @NickNau — 추론 선행은 품질을 예측하기 어렵게 떨어뜨릴 수 있다고 우려했습니다. 24개 정답은 일반적인 품질 저하 위험을 증명하거나 배제할 수 없으므로 비정확한 기능임을 표시하고 위험도 알려야 한다고 했습니다.
- @Oxygenne_ — 읽기 선행과 달리 추론 선행은 비정확한 부분이라고 인정했습니다. 열린 질문에서는 아직 측정하지 않았으며 해당 기능은 설정에서 끌 수 있다고 답했습니다.
- @saposmak — 입력 중 문장을 계속 고쳐 쓰는 사람에게 이 방식이 계산 낭비를 키우지 않는지 물었습니다.
- @Oxygenne_ — 수정하면 바뀐 첫 토큰 뒤부터 다시 계산하므로 문장 끝을 고치는 일은 부담이 적고, 긴 입력의 앞부분을 수정하면 비용이 커진다고 설명했습니다. 추가 비용은 GPU 작업량이며 대기 시간은 아니라고 덧붙였습니다.
- @plainbounds59 — 중간 수정에도 KV 캐시를 유지하는 점과 14B 결과를 높이 평가했습니다. 다만 주제에서 벗어난 노트가 17~26% 남는 점이 최종 답에 영향을 주는지 물었고 Linux 측정도 궁금하다고 했습니다.
- @Inquisitive_idiot — 사용자가 바쁜 시스템에서 입력 중 불필요한 계산이 늘 수 있다고 지적했습니다.
- @Oxygenne_ — 입력 중 쉬는 시간에 계산량이 커지며, 로컬 GPU가 바쁜 경우 추가 부하가 생긴다고 답했습니다. 추론 토큰 수 제한이 있고 설정에서 추론 선행을 끄면 읽기 선행만 사용할 수 있다고 설명했습니다.
원문: GitHub / Reddit / 번역·요약: Trawling