내 노트북에서 3개의 로컬 LLM을 벤치마킹했다 — 실제 수치가 보여주는 결과

로컬 모델 선택 시 발생하는 문제

어떤 로컬 LLM이 가장 좋은지에 대해 모두가 각자의 의견을 가지고 있습니다.

"Llama를 사용하세요 — 가장 대중적입니다." "Mistral 7B가 품질이 가장 좋습니다." "Phi-3 Mini는 작고 효율적입니다."

하지만 이러한 주장 중 그 어떤 것도 수치를 동반하지 않습니다. 구체적으로 말하자면, 당신의 하드웨어에서, 당신의 워크로드(Workload)를 대상으로 한 당신의 수치가 아닙니다.

저는 이를 바꾸기 위해 벤치마킹 시스템을 구축했습니다. 세 가지 모델, 30개의 프롬프트, 전체 지연 시간 분포(Latency distribution), 추론 호출당 메모리 프로파일링(Memory profiling), 그리고 구조화된 출력(Structured output)의 신뢰성을 측정하기 위한 JSON 검증 레이어(Validation layer)를 포함했습니다.

제가 발견한 결과는 다음과 같으며, 이 결과가 로컬 모델을 프로덕션(Production) 환경에 배포하려는 모든 이들에게 왜 중요한지 설명하겠습니다.

설정 (The Setup)

테스트된 세 가지 모델:

• llama3.2:3b — 3B 파라미터, Q4_K_M 양자화(Quantization), 2 GB 다운로드
• phi3:mini — 3.8B 파라미터, Q4_K_M, 2.3 GB 다운로드
• mistral:7b — 7B 파라미터, Q4_K_M, 4.1 GB 다운로드

하드웨어: CPU 전용, GPU 가속 없음. 이는 최악의 경우를 가정한 베이스라인(Baseline)으로, 실제 지연 시간과 메모리 수치를 드러내는 시나리오입니다.

5개 카테고리에 걸친 30개의 테스트 프롬프트:

• 짧은 사실 관계 (10개): "프랑스의 수도는 어디인가요?"
• 추론 (8개): "하늘이 왜 파랗게 보이는지 설명하세요."
• 코드 생성 (5개): "문자열을 뒤집는 Python 함수를 작성하세요."
• 구조화된 출력 (5개): "이름과 사용 사례(use_case)를 포함하여 3개의 프레임워크를 JSON 형식으로 나열하세요."
• 다단계 (2개): 복잡한 체인형 추론(Chained reasoning) 작업.

아키텍처 (Architecture)

POST /query
  → Pydantic 검증(validation) → Ollama HTTP API → JSON 검증기(Validator) → QueryResponse

...

벤치마크는 프롬프트를 병렬이 아닌 순차적으로 실행합니다. 병렬로 실행할 경우 프롬프트당 메모리 측정값이 오염될 수 있기 때문입니다.

결과

Llama 3.2 3B (Q4_K_M)

avg_tokens_per_second: 42.3
p50_latency_ms: 1203
p95_latency_ms: 3847
...

해석: 1.2초의 P50은 매우 훌륭합니다. 3.8초의 P95는 3초 SLA (Service Level Agreement)를 충족하지 못하는데, 이는 다단계 작업(multi-step tasks)과 더 긴 코드 생성 작업에서 발생하는 이상치(outliers) 때문입니다. 메모리는 안정적입니다. 모델은 한 번 로드되면 요청 사이에도 계속 활성화된 상태를 유지합니다 (Ollama의 KV cache). 피크(peak)와 평균 사이의 차이는 111 MB에 불과합니다.

Phi-3 Mini (Q4_K_M)

avg_tokens_per_second: 4.7
p50_latency_ms: 29554
p95_latency_ms: 34127

해석: CPU에서 4.7 tok/s를 기록했습니다. 간단한 사실 질문 하나에 29초가 소요됩니다. 이는 CPU 아키텍처 문제입니다. Phi-3 Mini의 어텐션 메커니즘(attention mechanism)은 CPU 전용 추론(inference) 시 Llama보다 효율성이 떨어집니다. GPU를 사용한다면 이 수치들은 매우 다르게 나타날 것입니다. CPU 환경에서는 대화형 애플리케이션(interactive applications)으로 사용하기에 부적합합니다.

Mistral 7B (Q4_K_M)

avg_tokens_per_second: 28.1
p50_latency_ms: 2301
p95_latency_ms: 5912
...

해석: 최고의 출력 품질을 보여주지만, 메모리 사용량은 가장 높습니다. 14 GB의 피크 RSS(Resident Set Size)는 다른 모든 프로그램을 종료하지 않는 한 8 GB RAM을 가진 기기에는 이 모델이 들어가지 않음을 의미합니다. P95는 5.9초로, 모든 면에서 Llama 3.2 3B보다 느리며, 이는 CPU에서 7B 모델을 구동할 때 예상되는 결과입니다.

JSON 검증 레이어 (The JSON Validation Layer)

이 프로젝트의 핵심 기능 중 하나는 쿼리와 함께 JSON 스키마(schema)를 보내면 검증된 구조화된 출력(structured output)을 받는 것입니다.

POST /query
{
  "prompt": "List 3 programming languages",
...

재시도(retry)가 없을 때: 첫 번째 시도에서 스키마와 일치하는 응답은 68%였습니다.

재시도 + 오류 주입(error injection) 시:

retry_prompt = (
    f"{original_prompt}\n\n"
    f"Your previous response was invalid JSON. "
...

재시도 시: 세 모델 모두에서 94%의 성공률을 기록했습니다.

중요한 것은 오류 주입입니다. 모델에게 정확히 무엇이 잘못되었는지 알려주는 것이 단순히 "다시 시도해봐"라고 말하는 것보다 훨씬 더 효과적입니다.

배운 점

1. P95가 평균이 아닌, 실제 프로덕션(production)에서 의미 있는 수치다.

Llama 3.2 3B의 평균 지연 시간(Average latency)은 약 1.4초입니다. P95는 3.8초입니다. 만약 평균값을 기준으로 3초의 SLA(Service Level Agreement)를 설정한다면, 5%의 확률로 이를 지키지 못하게 됩니다. 이는 20명 중 1명의 사용자가 타임아웃을 경험한다는 의미입니다. 중심값이 아닌 분포(distribution)를 측정하십시오.

2. Phi-3 Mini의 CPU 성능은 모델 카드(model card)의 내용과 다를 수 있다.

모델 카드는 강력한 벤치마크 점수를 광고합니다. 하지만 해당 점수들은 GPU에서 측정된 것입니다. CPU 전용 추론(inference) 시에는 4.7 tok/s의 속도가 나오며, 이는 대화형 애플리케이션(interactive applications)에서 사용하기에 부적합한 수준입니다. 항상 실제 사용하는 하드웨어에서 벤치마크를 수행하십시오.

3. 메모리 변화량(Memory delta)이 피크(peak) 수치보다 더 많은 것을 알려준다.

피크 RSS(Resident Set Size)에는 OS 오버헤드와 Ollama 자체의 사용량이 포함됩니다. 추론 전후의 메모리 변화량(delta)을 확인하면, 요청당 모델의 KV 캐시(KV cache)가 실제로 얼마나 증가하는지 알 수 있습니다. Llama 3.2 3B의 경우, 이 변화량은 약 111 MB였으며 프롬프트 유형에 관계없이 비교적 안정적이었습니다.

4. Q4_K_M이 적절한 기본값이다.

Ollama는 기본적으로 Q4_K_M을 사용합니다. 이는 K-평균 군집화(K-means clustering)를 적용한 4비트 양자화(quantization) 방식으로, 단순한 Q4_0 방식에 비해 품질을 어느 정도 회복합니다. 사실 관계 확인 및 코드 작업의 경우, FP16에서 Q4_K_M으로의 품질 저하는 미미합니다. 복잡한 추론(reasoning) 작업에서는 측정 가능한 수준의 성능 저하가 발생하지만, FP16은 메모리를 4배나 더 사용하기 때문에 일반 소비자용 하드웨어에서는 어차피 실용적이지 않습니다.

5. 순차적 벤치마킹(Sequential benchmarking)만이 유일하게 정확한 방법이다.

속도를 높이기 위해 벤치마크를 병렬화(parallelizing)해 보았습니다. 하지만 메모리 수치가 무의미해졌습니다. Ollama의 메모리 사용량이 동시 요청 간에 중첩되어 각 프롬프트별로 귀속시킬 수 없었기 때문입니다. 순차적 방식은 더 느리지만, 명확하고 귀속 가능한 측정값을 제공합니다.

한계점

GPU 측정값 없음. 모든 결과는 CPU 전용입니다. Phi-3 Mini의 저조한 CPU 성능은 GPU에서는 완전히 반전될 수 있습니다. 이 모델은 Apple Silicon 및 NVIDIA 가속에 최적화되어 설계되었기 때문입니다. GPU를 보유하고 있다면 직접 벤치마크를 실행해 보십시오.

단일 하드웨어 구성. 결과는 단 한 대의 기기에서 도출되었습니다. RAM 속도, CPU 세대, 사용 가능한 코어 수는 모두 추론 속도에 영향을 미칩니다. 이 수치들은 방향성을 제시할 뿐, 보편적인 값은 아닙니다.

품질 점수 산정(Quality scoring)은 수동으로 진행됩니다. 벤치마크는 지연 시간(Latency)과 처리량(Throughput)을 자동으로 측정합니다. 출력 품질은 주관적이며 여기서는 자동화되지 않았습니다. 이를 위해서는 골든 데이터셋(Golden dataset)과 LLM 판사(LLM judge, 별도의 프로젝트)가 필요합니다.

30개의 프롬프트는 통계적으로 견고하지 않습니다. 30개 샘플에서 얻은 P99 수치는 노이즈가 많습니다. 안정적인 백분위 추정치(Percentile estimates)를 얻으려면 프로덕션 벤치마크는 200개 이상의 프롬프트를 실행해야 합니다.

직접 시도해보기

GitHub: [https://github.com/ThinkWithOps/02-local-ai-assistant]
Youtube : [https://youtu.be/SMI-eIn-tuw]

git clone https://github.com/ThinkWithOps/02-local-ai-assistant.git
cd 02-local-ai-assistant
bash scripts/install_models.sh  # llama3.2:3b, phi3:mini, mistral:7b를 가져옵니다
...

여러분은 어떤 로컬 모델을 실행 중인가요? 그리고 여러분의 P95 지연 시간(Latency)은 얼마인가요? 댓글로 알려주세요.