반응형 MTPLX3 로컬 LLM이 매번 입력을 처음부터 다시 읽을 때: prefix 캐시 확인하는 법 로컬 LLM 로컬 LLM이 매번 입력을 처음부터 다시 읽을 때: prefix 캐시 확인하는 법 대화가 길어질수록 첫 글자가 늦어진다면, 서버의 캐시가 실제로 쓰이고 있는지부터 본다 핵심 요약 대화나 에이전트 작업은 요청마다 앞부분이 같다. 서버가 그 앞부분의 계산을 기억해 두면(prefix 캐시) 새로 붙은 부분만 읽으면 된다. 이게 안 되면 대화가 길어질수록 첫 글자가 늦어진다. 캐시가 쓰이는지는 입력을 읽는 시간으로 안다. 대화가 길어져도 거의 일정하면 쓰이고 있고, 길이를 따라 늘면 안 쓰이고 있다. 안 쓰이는 흔한 이유는 셋이다. 서버가 같은 대화인지 모른다, 캐시 항목이 너무 커서 버려진다, 끝난 대화의 캐시가 자리를 차지하고 안 비워진다. 디스크에 캐시.. 2026. 9. 25. 32GB 맥에서 큰 로컬 LLM 돌릴 때 메모리 나누는 법: GPU 한도와 서버 캐시 로컬 LLM 32GB 맥에서 큰 로컬 LLM 돌릴 때 메모리 나누는 법: GPU 한도와 서버 캐시 모델은 올라가는데 스왑이 나고 긴 요청이 거부될 때, 메모리를 어디서부터 나눠야 하나 핵심 요약 맥은 CPU와 GPU가 메모리 하나를 나눠 쓴다. 그래도 macOS는 GPU가 쓸 수 있는 몫에 기본 상한을 둔다. 32GB 맥이면 대략 25GB다. 큰 모델이 안 올라가면 이 상한부터 확인한다. 모델 서버는 모델 말고도 메모리를 쓴다. 대화를 빨리 이어 가려고 지난 계산 결과를 보관하는 캐시가 대표적이다. 스왑의 원인은 이 캐시였다. 그래서 순서를 뒤집는다. OS와 다른 앱이 쓰는 몫을 먼저 떼고, 서버에는 그 나머지만 준다. 캐시에는 따로 상한을 건다. 서버의 메모리 .. 2026. 9. 25. 맥에서 로컬 LLM 속도 미리 가늠하기: 메모리 대역폭과 투기적 디코딩 로컬 LLM 맥에서 로컬 LLM 속도 미리 가늠하기: 메모리 대역폭과 투기적 디코딩 27B 모델이 내 맥에서 초당 몇 토큰을 낼지, 사기 전에 어림하고 느릴 때 원인을 가르는 법 핵심 요약 로컬 모델이 답을 만드는 속도는 칩의 연산 성능보다 메모리 대역폭이 정한다. 토큰 하나를 만들 때마다 모델 전체를 메모리에서 한 번 읽기 때문이다. 투기적 디코딩은 여기에 배수를 곱하는 기술이다. 같은 모델에서 대략 2~3배 빨라졌다. 다만 곱해지는 기본 속도가 느리면 결과도 느리다. 남이 올린 벤치마크를 볼 때는 투기적 디코딩을 끈 기본 속도를 찾아 비교한다. 최종 숫자만 보면 칩 차이와 기술 차이가 섞인다. 벤치마크는 대개 짧은 질문으로 잰다. 입력이 수만 토큰이면 첫 글자.. 2026. 9. 25. 이전 1 다음 반응형
