Proxmox LLM Ollama 환경에서 LLM 추론 성능 측정 방법론

Proxmox LLM Ollama 조합으로 홈랩 AI 서버를 굴리다 보면, 제일 먼저 막히는 지점이 성능 자체보다 성능 해석이더라고요. 응답이 느릴 때 GPU 가속 경로가 문제인지, 모델 파일을 읽어오는 스토리지가 문제인지, 아니면 VM의 CPU 배치와 메모리 상태가 흔들리는지 한 번에 안 보입니다. 저도 처음엔 모델만 바꿔 가며 체감으로 판단했는데, 그 방식은 기록이 안 남고 원인 분리도 어렵더라고요. 이 글은 Proxmox + Ollama 조합에서 재현 가능한 LLM 성능 측정 방법을 만드는 데 집중합니다.

핵심은 단순합니다. 총 응답 시간만 보면 거의 항상 잘못된 결론으로 갑니다. Ollama가 내려주는 load_duration, prompt_eval_duration, eval_duration을 분리하고, 같은 시점의 CPU, 메모리, 디스크, GPU 상태를 같이 봐야 합니다. 홈랩에서는 특히 이 구분이 중요합니다. 같은 하드웨어라도 다른 VM의 백업 작업, 메모리 ballooning, 스토리지 캐시 상태 때문에 결과가 꽤 쉽게 흔들리거든요.

Proxmox 호스트와 게스트 VM, GPU 패스스루, Ollama API, 모니터링 명령 흐름을 한눈에 보는 구성도입니다.

왜 Proxmox LLM Ollama 환경은 따로 측정해야 할까요?

베어메탈에서 잘 나오던 수치가 Proxmox VM에서는 다르게 나오는 이유는 단순히 가상화 오버헤드 한 줄로 끝나지 않습니다. 실제로는 가상화 계층이 병목을 숨기거나 증폭하는 방식이 더 문제예요. 예를 들어 GPU 패스스루가 붙어 있어도 VM의 CPU affinity나 NUMA 배치가 어긋나면 생성 구간이 늘어질 수 있고, 모델 파일이 느린 스토리지에 있으면 첫 호출만 유난히 길어집니다. 이걸 분리하지 않으면 괜히 GPU만 탓하게 됩니다.

• GPU Passthrough 상태: 장치가 VM에 보이는 것과 실제로 추론 가속에 쓰이는 건 다릅니다.
• CPU affinity와 NUMA 배치: vCPU가 불리한 코어 배치에 놓이면 토큰 생성 지연이 출렁일 수 있습니다.
• 스토리지 지연시간: 모델 교체가 잦을수록 첫 로딩 시간이 과장되기 쉽습니다.
• ballooning, swap, 메모리 압박: 평소엔 티가 안 나다가 긴 프롬프트에서 갑자기 드러납니다.
• Ollama 메트릭 해석 실수: 로딩 시간과 생성 시간을 한 덩어리로 보면 튜닝 방향이 엇나갑니다.

제가 기준으로 삼는 문장은 하나입니다. 벤치마크는 순위를 매기는 작업이 아니라, 손해가 나는 구간을 특정하는 작업입니다. 이 관점으로 가면 Proxmox 위 LLM 성능 측정이 훨씬 덜 꼬입니다.

LLM 성능 측정에서 반드시 분리해야 할 항목

Ollama는 API 응답에 꽤 유용한 타이밍 필드를 포함합니다. 문제는 이 숫자를 읽는 방식입니다. 저는 최소한 아래 네 축을 분리하지 않으면 비교값으로 잘 안 봅니다.

여기서 많이 놓치는 포인트가 하나 있습니다. 짧은 프롬프트에서 빠른 모델이 실제 운영 워크로드에서도 빠르다는 보장은 없습니다. 특히 홈랩에서 RAG를 붙이거나 시스템 프롬프트가 길어지면 prompt_eval_duration이 병목으로 튀어나오는 경우가 적지 않았습니다. 그래서 저는 측정 목적을 먼저 나눕니다. 장비 비교인지, 실제 응답 대기시간 확인인지, GPU 패스스루 검증인지에 따라 봐야 할 값이 달라집니다.

측정 전에 Proxmox 쪽에서 먼저 고정할 것들

게스트 VM 안에서만 계측을 정교하게 해도, Proxmox 설정이 흔들리면 결과는 들쭉날쭉해집니다. 측정 전에 아래 조건부터 고정해두는 편이 낫습니다.

1. 같은 모델 태그, 같은 프롬프트, 같은 출력 길이 조건으로 반복합니다.
2. 테스트 시간대에는 다른 VM의 백업, 미디어 인덱싱, 대용량 복사 같은 잡음을 줄입니다.
3. GPU 패스스루를 쓴다면 항상 같은 VM, 같은 게스트 커널 상태에서만 비교합니다.
4. ballooning target, swap 개입 여부를 먼저 확인하고, 가능하면 벤치 구간에서는 메모리 조건을 고정합니다.
5. 모델 파일 위치가 로컬 SSD인지, 네트워크 스토리지인지, ZFS ARC나 페이지 캐시 영향이 있는지 기록합니다.

여기서 실전적으로 중요한 구분이 cold run과 warm run입니다. 첫 요청은 적재 비용이 섞이고, 두 번째부터는 메모리 상주 효과가 붙습니다. 둘을 한 표에 섞어두면 얼핏 데이터가 많아 보여도 해석에는 별 도움이 안 됩니다.

Proxmox 쪽에서 제가 특히 먼저 확인하는 건 세 가지입니다. CPU affinity, NUMA 사용 여부, ballooning 조건 고정 여부입니다. CPU 배치가 계속 흔들리면 짧은 벤치에서는 티가 덜 나도 반복 측정 편차가 커집니다. ballooning도 운영 효율에는 도움이 되지만, 추론 성능 비교에는 변수로 끼어들 수 있습니다. 홈랩에서는 운영 효율과 벤치 재현성이 종종 충돌하는데, 벤치 시간에는 재현성을 우선하는 편이 낫더라고요.

실전 구현 1: Ollama API로 응답 시간과 토큰 생성 속도 수집

CLI 체감은 참고용으로는 괜찮지만, 기록용 벤치마크에는 조금 아쉽습니다. 반복 측정과 후처리를 생각하면 Ollama API의 원본 메트릭을 그대로 저장하는 편이 훨씬 낫습니다. 아래처럼 한 번 호출해서 핵심 필드를 바로 계산해보면 감이 빨리 옵니다.

curl -s http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d '{
    "model": "llama3:8b",
    "prompt": "Explain the difference between CPU bottleneck and GPU bottleneck in one short paragraph.",
    "stream": false,
    "options": {
      "temperature": 0,
      "num_predict": 128
    }
  }' | jq '{
    model,
    created_at,
    total_duration_ns: .total_duration,
    load_duration_ns: .load_duration,
    prompt_eval_count,
    prompt_eval_duration_ns: .prompt_eval_duration,
    eval_count,
    eval_duration_ns: .eval_duration,
    tokens_per_second: (if .eval_duration > 0 then (.eval_count / (.eval_duration / 1000000000)) else 0 end)
  }'

여기서 temperature를 0으로 두는 이유는 성능 측정에서 출력 다양성을 줄이기 위해서입니다. num_predict를 고정하는 이유도 같고요. 벤치마크에서 가장 흔한 실수가 출력 길이를 매번 다르게 두는 건데, 그렇게 되면 eval_count가 흔들리고 결국 토큰/초 비교도 흐려집니다.

반복 측정은 최소 5회 정도는 권합니다. 평균만 보지 말고 최솟값, 최댓값, 편차까지 같이 남겨야 합니다. 홈랩에서는 한 번 빠르게 나온 결과보다 얼마나 덜 흔들리는지가 더 중요할 때가 많거든요.

for i in 1 2 3 4 5; do
  curl -s http://127.0.0.1:11434/api/generate \
    -H 'Content-Type: application/json' \
    -d '{
      "model": "llama3:8b",
      "prompt": "Write exactly five bullet points about Linux memory pressure.",
      "stream": false,
      "options": {
        "temperature": 0,
        "num_predict": 96
      }
    }' | jq -r --arg run "$i" '[
      $run,
      .created_at,
      .total_duration,
      .load_duration,
      .prompt_eval_count,
      .prompt_eval_duration,
      .eval_count,
      .eval_duration,
      (if .eval_duration > 0 then (.eval_count / (.eval_duration / 1000000000)) else 0 end)
    ] | @csv'
done >> ollama-bench.csv

이 CSV 로그는 보기보다 강력합니다. 나중에 VM 설정을 바꿨을 때, 모델 파일 위치를 옮겼을 때, GPU를 교체했을 때 비교 기준이 그대로 남습니다. 저는 이 단계에서 대시보드부터 만들지 않는 편을 권합니다. 원본 로그가 안정적으로 쌓이는 체계가 먼저고, 시각화는 그 다음이더라고요.

하나 더요. 벤치마크 목적이라면 stream: false를 유지하는 편이 낫습니다. 스트리밍 출력은 체감 속도 확인에는 좋지만, 수집 포맷이 지저분해지고 메트릭 해석이 섞이기 쉽습니다. 체감용 테스트와 기록용 테스트를 분리해두면 나중에 덜 꼬입니다.

Ollama API 응답에서 어떤 필드를 뽑아 성능 지표로 쓰는지 설명하는 시각 자료입니다.

실전 구현 2: 시스템 자원 사용량을 같이 보세요

Ollama API 숫자만 보면 원인 추정이 자꾸 빗나갑니다. 같은 요청이라도 CPU 압박인지, 디스크 대기인지, GPU가 실제로 일하는지 구분이 안 되기 때문입니다. 저는 최소한 아래 세 축은 같이 봅니다.

vmstat 1

iostat -xz 1

nvidia-smi dmon -s pucm

읽는 기준은 단순하지만, 해석은 꽤 실전적입니다.

• vmstat 1: r가 계속 높고 si/so가 움직이면 CPU 경쟁이나 swap 개입을 먼저 의심합니다.
• iostat -xz 1: 모델 로딩 시점에 await와 %util이 튀면 load_duration 상승과 연결해서 봅니다.
• nvidia-smi dmon -s pucm: 생성 중에도 GPU 사용률과 메모리 사용량이 거의 반응하지 않으면 GPU 가속 경로를 다시 확인합니다.

제가 자주 보는 실패 패턴은 이겁니다. GPU는 VM에서 보이는데, 실제 생성 구간에서는 GPU가 거의 일하지 않는 경우예요. 이때는 패스스루 성공과 추론 가속 성공을 분리해서 봐야 합니다. 장치 인식 자체는 성공했지만 드라이버 상태, 메모리 부족, 런타임 제약 때문에 기대한 만큼 가속이 안 붙는 경우가 있습니다. 반대로 GPU 사용률이 높다고 바로 좋은 것도 아닙니다. 메모리 이동 비용이나 CPU 병목이 남아 있으면 eval_duration 개선이 생각보다 작을 수 있습니다.

재현 가능한 시나리오: cold run과 warm run 분리 측정

제가 홈랩에서 가장 자주 쓰는 측정 패턴은 cold run과 warm run을 아예 별도 시나리오로 나누는 방식입니다. 같은 모델, 같은 프롬프트여도 첫 요청과 반복 요청은 성격이 다릅니다. 이 둘을 분리하면 적어도 로딩 비용과 생성 비용은 꽤 깔끔하게 갈라집니다.

1. Ollama 서비스를 재시작하거나 충분히 유휴 상태를 만든 뒤 첫 요청을 보냅니다.
2. 첫 요청의 load_duration, total_duration을 기록합니다.
3. 같은 프롬프트를 3~5회 반복하고, 이 구간에서는 eval_duration과 토큰/초를 중심으로 봅니다.
4. 동시에 vmstat, iostat, nvidia-smi dmon의 변화를 같은 시각 기준으로 맞춰둡니다.

실제로는 아래처럼 분리 저장해두면 후처리가 편합니다.

PROMPT='Explain why swap activity can distort LLM benchmark results in a VM.'
MODEL='llama3:8b'

# cold run
curl -s http://127.0.0.1:11434/api/generate \
  -H 'Content-Type: application/json' \
  -d "{\"model\":\"${MODEL}\",\"prompt\":\"${PROMPT}\",\"stream\":false,\"options\":{\"temperature\":0,\"num_predict\":120}}" \
  | jq -r '["cold", .total_duration, .load_duration, .prompt_eval_duration, .eval_duration, .eval_count] | @csv' \
  >> bench-split.csv

# warm runs
for i in 1 2 3; do
  curl -s http://127.0.0.1:11434/api/generate \
    -H 'Content-Type: application/json' \
    -d "{\"model\":\"${MODEL}\",\"prompt\":\"${PROMPT}\",\"stream\":false,\"options\":{\"temperature\":0,\"num_predict\":120}}" \
    | jq -r --arg run "warm-${i}" '[$run, .total_duration, .load_duration, .prompt_eval_duration, .eval_duration, .eval_count] | @csv' \
    >> bench-split.csv
done

이 방식의 장점은 단순한데 실용적입니다. 첫 요청만 느리면 적재 비용 성격, 반복 요청도 계속 느리면 생성 경로 병목으로 빠르게 가설을 세울 수 있습니다. 홈랩에서는 이 구분만 제대로 해도 괜히 GPU부터 바꾸는 일을 꽤 줄일 수 있더라고요.

cold run과 warm run을 비교하면서 시스템 자원 모니터링을 병행하는 실전 측정 화면 예시입니다.

VM, LXC, 베어메탈 중 무엇을 기준점으로 삼아야 할까요?

이 질문은 자주 나오는데, 저는 목적에 따라 답을 다르게 합니다. 무조건 하나가 낫다고 하기보다 무엇을 검증하려는지 먼저 정하는 편이 맞습니다.

제 판단 기준은 이렇습니다. 운영도 Proxmox VM에서 할 예정이면 VM에서 잰 수치를 기준으로 삼는 편이 맞습니다. 베어메탈 수치가 더 좋아도 실제 배포 환경과 다르면 의사결정에는 덜 도움이 됩니다. 반대로 이 하드웨어가 어디까지 나오는지 보고 싶다면 베어메탈 기준선을 한 번 찍어두는 게 좋습니다.

자주 겪는 문제와 해결 방법

이 부분은 공식 문서만 봐서는 감이 잘 안 오는 영역입니다. 실제로 벤치를 돌리면 아래처럼 삐끗하는 경우가 많습니다.

1. 프롬프트 길이가 매번 달라서 비교가 무너집니다

prompt_eval_duration은 입력 길이에 직접 반응합니다. 질문을 바꾸거나 출력 길이를 열어두면, 모델 자체보다 워크로드 차이가 더 크게 반영됩니다. 벤치 프롬프트는 고정, 출력 길이는 num_predict 등으로 제한하는 편이 낫습니다.

2. 스트리밍 체감 속도를 성능으로 착각합니다

터미널에 토큰이 빨리 흘러나오면 체감상 빨라 보입니다. 그런데 그건 계측 기준으로는 불안정합니다. 수집용 벤치는 stream: false로 고정하고, 체감 테스트는 별도로 분리하세요. 둘을 섞어두면 나중에 기록이 비교 불가능해집니다.

3. 디스크 병목이 숨어 있는데 GPU만 의심합니다

모델을 자주 바꾸며 테스트할 때 특히 그렇습니다. load_duration이 갑자기 커지고 같은 시점 iostat의 await가 치솟는다면, 그건 GPU보다 모델 적재 경로를 먼저 봐야 합니다. 홈랩에서는 NVMe, SATA SSD, 네트워크 스토리지 차이가 생각보다 크게 드러납니다.

4. Proxmox에서 다른 VM 부하가 끼어듭니다

백업 작업, 미디어 트랜스코딩, ZFS scrub, 테스트용 쿠버네티스 VM이 동시에 돌면 반복 측정 편차가 커집니다. 이런 경우 평균값보다 분산이 커지는 패턴이 먼저 나타납니다. 숫자가 안 예쁜 게 아니라, 측정 조건이 불안정한 겁니다.

5. GPU 사용률만 높고 성능 향상은 미미합니다

이건 대개 GPU 연산 자체보다 CPU 준비 단계, 메모리 이동, 컨텍스트 처리가 먼저 막히는 경우입니다. 그래서 저는 GPU utilization을 목표값으로 보지 않습니다. eval_duration이 실제로 줄었는지를 먼저 확인합니다.

6. 첫 요청이 계속 느린데 warm run처럼 해석합니다

메모리 압박이나 unload 정책 때문에 모델이 자주 내려가는 환경에서는 매번 사실상 cold run이 됩니다. 이때는 첫 요청만 느린 건 정상이라고 넘기면 안 됩니다. 반복 호출인데도 load_duration이 매번 크게 잡히는지를 꼭 확인해보세요. 그건 상주 실패일 가능성이 큽니다.

검증과 결과 해석: 숫자를 어떻게 읽어야 할까요?

숫자를 예쁘게 정리하는 것보다 중요한 건, 어떤 패턴에서 어떤 결론을 내릴지 미리 정해두는 겁니다. 저는 보통 아래처럼 읽습니다.

• load_duration만 크다: 모델 적재, 스토리지, 최초 호출 비용을 먼저 봅니다.
• prompt_eval_duration이 길다: 긴 프롬프트, 큰 컨텍스트, CPU 토큰 처리 경로를 의심합니다.
• eval_duration이 길다: 실제 생성 성능 문제입니다. GPU 가속 상태, CPU 할당, 모델 크기 적합성을 봐야 합니다.
• GPU 사용률이 낮고 CPU만 바쁘다: 패스스루 성공 여부보다 실제 추론 가속 경로를 재확인합니다.
• 반복 측정 편차가 크다: 다른 VM 간섭, 메모리 압박, 백그라운드 I/O를 먼저 정리합니다.

여기서 중요한 결정 포인트가 있습니다. 무엇을 최적화할지 먼저 정해야 수치 해석이 쉬워집니다. 사용자 체감 첫 응답을 줄이는 게 목표라면 total_duration과 load_duration이 더 중요합니다. 장비 비교가 목적이면 eval_duration과 토큰/초가 핵심이고요. 긴 컨텍스트 운영이 목표라면 prompt_eval_duration이 병목인지부터 봐야 합니다.

로그 포맷은 거창할 필요 없습니다. 다만 나중에 조건을 복원할 수 있을 만큼은 남겨두는 편이 좋습니다.

timestamp,host,vm,model,prompt_name,run_type,total_duration,load_duration,prompt_eval_count,prompt_eval_duration,eval_count,eval_duration

이 한 줄이 중요한 이유는 숫자와 환경을 같이 묶어두기 때문입니다. 벤치 결과만 남기고 VM 설정 이력을 빼먹으면 몇 주 뒤에는 왜 빨라졌는지, 왜 느려졌는지 복기가 잘 안 됩니다. 관련해서 Proxmox GPU 패스스루 설정 글이나 Ollama 설치 가이드를 같이 정리해두면 나중에 내부 링크 연결에도 꽤 유용합니다.

모델 로딩 시간과 실제 생성 시간을 분리해 해석하는 결과 대시보드 예시입니다.

운영 팁: 측정 환경을 문서화해야 나중에 안 꼬입니다

벤치마크는 숫자보다 맥락이 먼저입니다. 특히 홈랩 AI 서버는 장비를 자주 만지게 되니까, 어떤 조건에서 잰 수치인지 생각보다 빨리 잊어버립니다. 최소한 아래 항목은 같이 기록해두는 편이 좋습니다.

• 모델 이름과 태그
• 게스트 OS 종류와 커널 상태
• vCPU 개수, 메모리 크기
• GPU 패스스루 유무와 장치 종류
• 모델 파일 저장 위치
• 테스트 프롬프트 이름
• cold run인지 warm run인지

여기서 제 권장 방식은 단순합니다. 설정 변경이 있는 날에는 벤치마크를 다시 찍고, 변경 사유를 한 줄 메모로 남겨두세요. CPU affinity를 바꿨는지, 메모리를 늘렸는지, 모델 저장 위치를 옮겼는지 정도만 적어도 나중에 비교가 됩니다. 숫자만 예쁘게 모아두는 것보다 이게 훨씬 실용적이더라고요.

FAQ: 현장에서 많이 헷갈리는 부분

Q. Proxmox LLM 테스트는 VM이 낫나요, LXC가 낫나요?

GPU 패스스루 검증과 재현성을 우선하면 저는 VM 쪽을 더 자주 씁니다. 운영 편의만 보면 LXC가 가벼울 수 있지만, 벤치 기준점을 만들 때는 변수를 줄이기 쉬운 쪽이 VM이었습니다.

Q. Ollama 벤치마크는 CLI만으로 충분한가요?

단발성 확인은 가능합니다. 다만 반복 측정, CSV 저장, 후처리, cold/warm 구분까지 생각하면 API 기반 수집이 훨씬 낫습니다.

Q. 숫자는 좋은데 체감은 별로입니다

짧은 프롬프트 위주로만 재면 실제 운영 패턴과 어긋날 수 있습니다. 특히 RAG, 긴 시스템 프롬프트, 멀티턴 대화가 붙으면 prompt_eval_duration 비중이 커집니다. 운영 워크로드와 비슷한 입력으로 다시 재보는 게 맞습니다.

Q. 토큰/초가 높으면 무조건 좋은 건가요?

장비 비교에는 유용하지만, 첫 응답 대기시간이 중요한 환경에서는 부족합니다. 사용자가 느끼는 체감은 종종 load_duration과 prompt_eval_duration에 더 크게 좌우됩니다.

마지막으로: 이런 상황이면 이렇게 고르시면 됩니다

제가 실제로 추천하는 선택 기준은 아래처럼 명확합니다.

• 장비 비교가 목적: 같은 프롬프트와 같은 출력 길이로 고정하고 eval_duration과 토큰/초 중심으로 보세요.
• 첫 응답 체감이 중요: load_duration을 포함한 total_duration을 같이 봐야 합니다. 모델 상주 전략과 스토리지 위치가 더 중요해질 수 있습니다.
• GPU 튜닝이 목적: Ollama API 결과만 보지 말고 nvidia-smi dmon과 vmstat를 반드시 붙이세요.
• 운영 전 검증이 목적: CSV 형태로 누적 저장하고, cold run과 warm run을 분리 기록하세요.
• 결과가 자꾸 흔들린다: 모델을 바꾸기 전에 다른 VM 간섭, ballooning, swap, 스토리지 대기를 먼저 정리하세요.

조금 더 직설적으로 말하면 이렇습니다. 첫 응답만 느리면 스토리지와 적재 전략부터, 반복 응답도 느리면 CPU/GPU 경로부터, 숫자가 출렁이면 Proxmox 자원 간섭부터 보시면 됩니다. 이 순서가 실제로 가장 덜 돌아가는 편이었습니다.

제 경험상, Ollama 숫자만 보고 결론 내리면 절반은 빗나가고, Proxmox 호스트와 게스트의 시스템 지표까지 같이 보면 비로소 조정 포인트가 보입니다. Proxmox LLM Ollama 벤치마크는 장비 스펙보다 측정 설계가 더 중요할 때가 많습니다. 한 번만 잘 만들어두면, 그다음부터는 모델 교체든 VM 튜닝이든 훨씬 덜 감으로 움직이게 됩니다.

Proxmox 기반 Ollama 벤치마크 절차와 해석 기준을 요약한 인포그래픽입니다.