핵심 요약
llama.cpp 빌드 후 llama-cli에서는 100t/s의 속도가 나오지만 llama-server에서는 10t/s로 급감하는 성능 병목 현상에 대한 기술적 문의이다.
배경
사용자가 llama.cpp를 직접 빌드하여 Qwen 3.5 35B 모델을 테스트하던 중, CLI 도구와 서버 도구 간에 발생하는 10배의 성능 차이를 발견하고 원인을 파악하고자 글을 게시했다.
의미 / 영향
이 토론은 로컬 LLM 환경에서 동일한 바이너리 내에서도 실행 모드에 따라 성능 최적화 값이 다를 수 있음을 보여준다. 특히 서버 모드 배포 시에는 CLI 테스트 결과에 의존하지 말고 스레드와 GPU 할당을 명시적으로 관리해야 실서비스 성능을 확보할 수 있다.
커뮤니티 반응
사용자들은 주로 스레드 설정이나 GPU 가속 옵션의 명시적 선언 여부를 확인하라고 조언하는 분위기이다.
실용적 조언
- llama-server 실행 시 -ngl 또는 --n-gpu-layers 옵션을 통해 GPU 가속이 활성화되어 있는지 확인하십시오.
- -t 또는 --threads 옵션을 사용하여 CPU 코어 수에 맞는 적절한 스레드를 명시적으로 할당하십시오.
언급된 도구
LLM 추론을 위한 C++ 기반 프레임워크
Qwen 3.5 35B중립
Alibaba에서 공개한 고성능 언어 모델
섹션별 상세
사용자는 동일한 모델인 Qwen3.5-35B-A3B-GGUF와 동일한 파라미터를 사용하여 두 가지 실행 방식을 비교했다. llama-cli 환경에서는 약 100t/s라는 높은 성능을 기록했으나, llama-server로 전환하자마자 성능이 10t/s 수준으로 90% 가량 하락하는 현상이 발생했다. 이는 단순한 설정 오류를 넘어 서버 모드 특유의 오버헤드나 기본값 차이 가능성을 시사한다.
llama-server와 llama-cli는 내부적으로 동일한 백엔드를 공유하지만 요청 처리 방식과 기본 스레드 할당 전략에서 차이가 있을 수 있다. 특히 서버 모드에서는 HTTP 오버헤드나 병렬 요청 처리를 위한 큐잉 메커니즘이 활성화되는데, 단일 요청 테스트임에도 불구하고 이러한 성능 저하가 발생하는 것은 비정상적인 상황이다. 사용자는 호스트와 포트 설정 외에는 동일한 옵션을 부여했음을 강조하며 해결책을 구하고 있다.
커뮤니티에서는 일반적으로 이러한 현상의 원인으로 스레드 설정의 부재나 GPU 가속 옵션의 누락 여부를 지적한다. CLI 버전은 빌드 환경에 따라 최적의 스레드 수를 자동으로 잡는 경우가 많지만, 서버 버전은 명시적인 설정이 없으면 기본값으로 동작하여 CPU 추론으로 전환되거나 효율이 떨어질 수 있다. 또한 네트워크 스택을 통한 통신 과정에서 발생하는 지연 시간이 토큰 생성 속도 측정치에 영향을 주었을 가능성도 존재한다.
실무 Takeaway
- llama.cpp의 CLI 도구와 서버 도구 간에 동일 옵션 적용 시에도 심각한 성능 불일치가 발생할 수 있다.
- Qwen 3.5 35B 모델 기준 CLI에서는 100t/s가 나오지만 서버 모드에서는 10t/s로 떨어지는 현상이 보고됐다.
- 서버 모드 사용 시 스레드 수 설정이나 GPU 레이어 오프로딩 설정이 CLI와 다르게 적용되었을 가능성을 점검해야 한다.
AI 분석 전체 내용 보기
AI 요약 · 북마크 · 개인 피드 설정 — 무료