로컬 LLM 응답 속도는 모델 자체보다 실행 설정, GPU 메모리, 프롬프트 길이에 따라 크게 달라집니다. 이 글은 로컬 LLM 서버가 이미 설치되어 있고, 스트리밍 응답을 확인할 수 있는 환경을 전제로 합니다.
목차
응답 시간을 두 구간으로 나누기
먼저 프롬프트 처리와 답변 생성을 분리해야 합니다. 프롬프트 처리는 입력 내용을 모델이 읽고 첫 토큰을 준비하는 과정이며, 생성은 이후 답변 토큰을 하나씩 만드는 과정입니다. 긴 문서나 대화 기록을 입력했을 때는 생성 속도보다 첫 응답까지 걸리는 시간이 더 크게 늘 수 있습니다.
측정할 때는 전체 시간만 보지 말고 첫 토큰까지의 시간과 생성 속도를 따로 기록하세요. 첫 토큰까지의 시간은 TTFT(Time to First Token)라고 하며, 생성 속도는 초당 생성 토큰 수로 확인합니다. 서버 로그나 API의 스트리밍 통계에서 입력 토큰 수, 출력 토큰 수, 전체 시간을 확인하면 원인을 구분하기 쉽습니다. llama.cpp 계열은 `–verbose` 옵션으로, vLLM 같은 서빙 프레임워크는 자체 메트릭 엔드포인트로 TTFT와 초당 생성 토큰 수를 직접 확인할 수 있습니다.
GPU 메모리와 오프로딩 확인
GPU 메모리가 부족하면 모델 일부가 CPU 메모리로 이동하는 오프로딩이 발생할 수 있습니다. 이 경우 GPU만 사용할 때보다 응답이 크게 느려질 수 있으므로, 실행 로그에서 GPU에 적재된 레이어 수와 CPU로 넘어간 레이어가 있는지 확인해야 합니다.
운영체제의 GPU 모니터링 도구로 실행 중 메모리 사용량도 함께 확인하세요. 모델 실행 후 GPU 메모리가 한계에 가까운 상태에서 CPU 오프로딩이 발생하거나 메모리 부족이 확인된다면, 컨텍스트 길이를 줄이거나 더 가벼운 양자화 모델을 선택하는 방법을 우선 검토하세요.
양자화 수준과 컨텍스트 길이 점검
양자화는 모델 숫자 데이터를 더 적은 비트로 저장해 메모리 사용량을 줄이는 방식입니다. 높은 비트의 양자화는 일반적으로 모델 품질 유지에 유리하지만 메모리 사용량이 커집니다. 하드웨어 메모리를 초과하면 오프로딩이 발생해 오히려 느려질 수 있습니다. 낮은 비트 양자화는 메모리 사용량을 줄이는 데 유리하지만 모델 품질이나 출력 특성이 달라질 수 있으므로, 같은 프롬프트로 속도와 품질을 함께 비교해야 합니다.
컨텍스트 길이는 모델이 한 번에 참고하는 입력 범위입니다. 대화 기록, 시스템 지침, 첨부 문서가 계속 누적되면 프롬프트 처리 시간이 증가하고 메모리 여유도 줄어듭니다. 불필요한 대화는 요약하거나 삭제하고, 필요한 문서만 검색해 넣는 방식으로 입력 크기를 줄여 보세요.
순서대로 원인 좁히기
같은 모델과 짧은 질문으로 기준 속도를 먼저 측정한 뒤, 프롬프트 길이와 양자화 설정을 하나씩 바꿔 비교하세요. 기준 상태에서도 느리면 GPU 사용 여부와 오프로딩을 먼저 확인하고, 짧은 질문은 빠르지만 긴 입력만 느리다면 컨텍스트와 프롬프트 처리 구간을 점검하면 됩니다.
로컬 LLM의 속도 측정값은 하드웨어, 실행 엔진, 샘플링 설정에 따라 달라집니다. 따라서 다른 사람의 초당 토큰 수보다 여러분의 환경에서 동일한 조건으로 측정한 변화량을 기준으로 판단하는 편이 정확합니다.
결론
첫 토큰 시간과 생성 속도를 나누어 측정하고, GPU 메모리·오프로딩·양자화·컨텍스트 길이를 순서대로 확인하면 느린 원인을 빠르게 좁힐 수 있습니다.