llama.cpp: 어떤 설정이 느리게 만드는지 직접 확인하려면

긴 기술 메모를 요약한다면 같은 GGUF 파일과 요청을 기준으로 삼아요. 짧은 요청으로 서버 응답을 확인한 뒤 메모 전체를 넣어보세요. 입력을 처리하는 시간과 답변을 생성하는 시간을 나누면, 어느 구간에서 기다리는지 알 수 있어요.

직접 실행하면 실행 파일, 드라이버, 업데이트와 명령도 관리해야 해요. 그 수고는 앱에서 확인할 수 없는 조건이 필요하거나 특정 빌드 문제를 재현할 때 의미가 있어요.

GPU 사용률이 낮다고 카드 고장으로 바로 판단하지 않아요. CPU⁵용 실행 파일은 GPU가 있어도 해당 backend를 쓰지 않아요. NVIDIA CUDA⁶, Apple Silicon Metal⁷, Vulkan은 준비 절차가 달라요. 시작 로그에서 감지 장치와 선택 backend를 봐요. 장치가 보이지 않으면 배치 옵션만 바꿔도 GPU 실행으로 전환되지 않아요.

GGUF는 배포 파일 형식이지 모든 모델 구조가 모든 빌드에서 지원된다는 보증은 아니에요. 새 구조를 쓰면 실행 파일의 모델 지원과 변환본의 원본을 확인해요. 이미지 입력도 필요하다면 멀티모달 구현과 추가 파일이 지원되는지 따로 살펴요. 텍스트 GGUF만으로 이미지 경로까지 준비되지는 않아요.

모델 파일을 준비한 뒤 예제의 ./models/model.gguf를 실제 경로로 바꿔요. 별칭 local-guide, 문맥 예산 4,096, 동시 슬롯 하나는 비교를 위한 기준값이에요. 문맥은 입력과 생성 답변이 함께 쓰므로 4,096을 메모 전체 입력에 다 쓸 수 있다는 뜻은 아니에요. 첫 로드 시간은 이후 요청과 분리해요.

GPU 층은 auto로 시작하고 실행 로그와 GPU별 메모리에서 실제 적재량을 확인해요. 옵션에 auto가 있다고 모델 전체가 GPU에 올라온 것은 아니에요. 실행 파일이 예상과 다르면 버전과 --help를 확인하고, 동작하는 최소 명령과 로그를 저장해요. 지원되지 않는 옵션을 뺀 결과는 원래 예제와 같은 조건이라고 부르지 않아요.

기준 기록에는 GGUF 파일명과 양자화⁸, 실행 파일 버전, backend, 문맥 4,096, 슬롯 하나를 남겨요. 모델과 실행 조건이 고정되어야 이후 배치나 GPU 적재를 한 항목씩 바꿔 비교할 수 있어요.

서버 프로세스가 뜬 뒤 /health가 준비 완료인지 확인하고 짧은 질문을 보내요. 첫 명령은 상태 확인, 둘째는 실제 텍스트 생성을 요청해요. 메모 전체를 보내기 전에 별칭과 기본 연결이 되는지 확인하면 로드·연결 문제를 먼저 분리할 수 있어요.

API⁹가 성공해도 클라이언트가 기대하는 템플릿이나 도구 호출¹⁰이 맞는지는 따로 봐요. 아래 curl은 응답 전체를 기다리므로 왕복 시간을 볼 수는 있어도 첫 토큰¹¹이나 프리필·디코드 속도를 각각 재지는 않아요.

긴 메모를 보낸 뒤 첫 답이 늦으면 입력을 처리하는 프리필이, 답이 시작된 뒤 토큰이 천천히 이어지면 디코드가 기다림의 원인일 수 있어요. 긴 입력은 문맥 메모리도 더 사용하므로, 문맥 4,096 기준 요청과 GPU 여유·KV 캐시¹²를 함께 확인해요.

프리필 배치를 키우면 긴 입력 처리에 도움이 될 수 있지만 디코드가 같은 비율로 빨라진다고 할 수 없어요. 동시 요청을 늘리면 서버 전체 처리량¹³은 달라져도 한 사용자의 답변 완료 시간이 짧아진다는 뜻은 아니에요. 개인 요약이 목적이면 동시 슬롯 하나를 기준으로 두고, 배치·문맥·GPU 적재 중 로그가 가리키는 관련 항목만 한 번에 하나씩 바꿔요.

비교할 때는 GGUF와 양자화, 입력·출력 길이, backend, 동시 요청 수를 고정해요. 준비 실행 뒤 같은 요청을 세 번 이상 보내고, 모델이 메모리에 올라와 있는지와 KV cache 재사용 여부를 기록해요.

캐시를 비우지 못한 실행은 cold start라고 부를 수 없어요. 값 하나가 크게 튀어도 버리지 말고, 준비 상태와 백그라운드 부하를 확인한 뒤 중앙값으로 정리해요.

전체 응답 curl은 총 왕복 시간용이지 프리필과 디코드를 나눠 주는 벤치마크가 아니에요. 목표 작업이 안정적으로 완료되고 직접 관리할 이득이 있는지 본 뒤 Ollama나 LM Studio에 필요한 옵션이 있다면 그대로 써도 돼요.

llama.cpp b11413은 Vulkan에서 긴 문맥을 처리하는 일부 모델의 실행 경로를 개선했어요. Qwen3.8-Flash-Next의 QSA처럼 필요한 위치만 골라 읽는 sparse attention¹⁴ 모델이 대상이에요. 양자화한 K/V 캐시를 쓰면서도 선택한 위치만 읽어, 문맥 전체를 처리하던 부담을 줄여요.

PR 작성자의 Radeon R9700·RX 7900 XT 측정에서는 q8_0 KV 캐시를 사용한 64K 문맥의 토큰 생성이 평균 19%, 128K는 15% 빨라졌어요. 짧은 문맥에서는 효과가 작거나 느려질 수 있어 런타임¹⁵이 적용 경로를 선택해요. f16 캐시와 프리필에는 이 수치를 적용하지 않아요. 아래 명령은 Vulkan 빌드와 호환 모델을 준비한 뒤 사용할 수 있어요.

2026년 10월 5일 공개된 llama.cpp 0.6.0에는 선택값과 확률을 반환하는 /v1/systemone API가 들어갔어요. 문의를 담당 부서로 나누거나 문서 종류를 분류할 때 쓸 수 있죠. 지원 판단 모델을 선택하고 입력과 후보를 보내는 방법은 로컬 판단 모델 실행 예시에서 이어서 설명해요. 0.6.0 공식 릴리스

속도와 관련해서는 Qwen4Exp의 MTP¹⁶, Metal의 F16 KV Flash Attention, CUDA의 NVFP4¹⁷·MXFP4 연산 경로가 보강됐어요. 내 모델에 해당하는 기능을 골라 같은 질문으로 업데이트 전후를 비교하면 돼요. 기존 속도 기록에는 측정 당시 버전을 그대로 남겨, 새 버전의 기록과 함께 비교할 수 있도록 했어요.

llama.cpp b11507부터 CPU에 둔 MoE¹⁸ 전문가 가중치를 여러 GPU의 캐시에 나눠 보관할 수 있어요. 필요한 전문가를 GPU로 다시 옮기는 횟수를 줄이는 기능이에요. 큰 MoE 모델을 RAM¹⁹과 GPU에 나눠 실행하는 구성에서 시험해볼 만해요.

현재 --moe-cache-mib는 캐시 전체 용량을 MiB로 지정하고, 여러 GPU에서는 --tensor-split의 배분을 따라 나눠요. 기본값은 0으로 꺼져 있어요. 실행 전에 llama-server --help에서 옵션이 있는지 확인하고, 캐시를 켜기 전후에 같은 문서의 첫 답 대기와 토큰 생성 속도를 함께 비교하세요.

b11512에는 DFlash의 출력 헤드 공유 수정도 들어갔어요. DFlash를 쓰는 설정에서 업데이트할 때는 메인 모델과 초안 모델을 그대로 두고 같은 입력으로 답변이 끝까지 나오는지 확인하세요. b11507·b11512는 10월 8일의 롤링 빌드로, 고정 릴리스 0.6.0과 별도 업데이트 계열이에요.