커뮤니티 입장하기

로컬 AI 성능 측정과 모니터링 (토큰 속도, 메모리, 온도)

로컬 AI 성능 측정은 같은 조건에서 입력 처리 속도와 생성 속도, 메모리 사용과 기기 상태를 기록해 비교하는 일이고, 모니터링은 이 값을 작업 중에 계속 지켜보는 일입니다. 올라마의 --verbose와 ollama ps, llama-bench, 운영체제의 모니터링 도구를 함께 씁니다.

같은 말:올라마 verbose초당 토큰 측정llama-bench맥 메모리 압력nvidia-smi

새로 올라온 개념이에요. 먼저 읽어 보고 퀴즈도 풀어 보세요
Share
목차
  1. 🤔 같은 모델인데 어제보다 느린 것 같을 때
  2. 🔑 성능 측정과 모니터링의 정의
  3. ⏱️ 올라마 --verbose 결과 읽기
  4. 🧮 ollama ps로 메모리 배치 보기
  5. 🧪 llama-bench로 반복 측정하기
  6. 🎛️ 측정 조건을 맞추는 법
  7. 🍎 맥에서 메모리와 온도 보기
  8. 🟩 엔비디아 GPU에서는 nvidia-smi
  9. ⚠️ 자주 하는 실수
  10. ❓ 자주 묻는 질문
  11. 📋 3줄 요약

🤔 같은 모델인데 어제보다 느린 것 같을 때

로컬 모델을 쓰다 보면 "오늘은 좀 느린데" 싶은 때가 있습니다. 모델을 바꿨는지, 컨텍스트를 늘렸는지, 다른 프로그램이 메모리를 잡고 있는지, 기기가 뜨거워져 속도를 낮춘 것인지 원인은 여러 가지입니다. 느낌만으로는 어느 쪽인지 알 수 없고, 다른 기기와 비교할 때도 같은 기준이 필요합니다.

기기의 메모리 용량과 대역폭이 속도를 어떻게 정하는지는 1차 코스의 로컬 AI 하드웨어 기초에서 다뤘습니다. 지금부터는 실제로 속도를 측정하는 명령과 결과 읽는 법, 측정 조건을 맞추는 법, 작업 중에 메모리와 온도를 지켜보는 도구를 정리합니다. 명령과 항목 이름은 2026년 9월 28일 공식 문서와 소스 코드 기준입니다.

🔑 성능 측정과 모니터링의 정의

로컬 AI 성능 측정은 같은 조건에서 입력 처리 속도와 생성 속도, 메모리 사용과 기기 상태를 기록해 비교하는 일이고, 모니터링은 이 값을 작업 중에 계속 지켜보는 일입니다.

속도는 두 가지로 나눠 봐야 합니다. 입력한 글을 한꺼번에 읽는 입력 처리(프리필)는 연산 성능이 결정하고, 답을 한 토큰씩 만드는 생성(디코드)은 메모리 대역폭이 결정합니다. 긴 문서를 넣는 작업은 입력 처리가, 긴 답을 받는 작업은 생성이 먼저 걸립니다.

⏱️ 올라마 --verbose 결과 읽기

ollama run 모델이름 --verbose로 대화하면 답 뒤에 시간 기록이 붙습니다. 항목 이름은 올라마 소스 코드의 표기 그대로입니다.

항목뜻
total duration요청 전체에 걸린 시간
load duration모델을 메모리에 올리는 데 걸린 시간
prompt eval count / prompt eval duration입력 처리한 토큰 수와 시간
prompt eval rate입력 처리 속도 (초당 토큰)
eval count / eval duration생성한 토큰 수와 시간
eval rate생성 속도 (초당 토큰)

흔한 착각은 전체 시간을 생성 속도로 읽는 것입니다. 준이아빠블로그의 큐원 3.8 27B 맥 실측에서는 24GB 맥미니 M4 프로에서 27B 모델(Q4_K_M)이 전체 218.2초, 출력 10토큰, 생성 속도 초당 0.08토큰이 나왔습니다. 10토큰을 초당 0.08개로 만들면 약 125초이므로, 나머지 약 93초는 모델 로드와 입력 처리에 쓰였다고 계산할 수 있습니다. 첫 요청은 모델을 올리는 시간이 들어가니 성능 비교에서는 빼고 봅니다.

API로 요청했다면 응답의 마지막 조각에 같은 값이 eval_count, eval_duration 같은 필드로 들어오고, 시간 단위는 나노초입니다. 같은 입력을 반복하면 이미 처리한 부분은 캐시로 처리되어 prompt_eval_cached_count에 따로 잡히므로, 입력 처리 속도를 측정할 때는 매번 다른 입력을 씁니다.

🧮 ollama ps로 메모리 배치 보기

ollama ps는 지금 올라가 있는 모델과 메모리 배치를 보여 줍니다. 열 이름은 NAME, ID, SIZE, PROCESSOR, CONTEXT, UNTIL입니다.

  • PROCESSOR 100% GPU: 모델 전체가 GPU 메모리에 있습니다. 가장 빠른 상태입니다
  • PROCESSOR 100% CPU: 전부 시스템 메모리에서 CPU로 돌고 있습니다
  • PROCESSOR 48%/52% CPU/GPU: 두 곳에 나뉘어 올라가 속도가 크게 떨어집니다
  • CONTEXT: 실제로 잡힌 컨텍스트 길이입니다

속도가 갑자기 떨어졌다면 가장 먼저 이 열을 봅니다. 컨텍스트나 동시 요청 수를 늘리면 메모리가 늘어나 모델 일부가 CPU로 밀려날 수 있고, 이 관계는 로컬 모델 서빙 기초에서 다뤘습니다. 더 자세한 원인은 맥 기준 ~/.ollama/logs/server.log에 남고, OLLAMA_DEBUG=1로 서버를 띄우면 더 자세히 기록됩니다.

🧪 llama-bench로 반복 측정하기

모델이나 양자화판을 여러 개 비교할 때는 llama.cpp의 llama-bench가 편합니다. 공식 README 기준으로 측정은 세 종류입니다.

  • pp: 입력 처리 속도 (-p, 기본 512토큰)
  • tg: 생성 속도 (-n, 기본 128토큰)
  • pg: 둘을 이어서 측정 (-pg)

각 측정을 기본 5번(-r) 반복해 평균과 표준편차를 내고, -d로 대화가 이미 쌓인 상태를 흉내 내 측정할 수 있습니다. 결과는 -o md, -o csv, -o json으로 받습니다. README 예시에서 7B 모델(Q4_K_M, CUDA)은 pp512가 초당 7,340토큰, tg128이 초당 120.6토큰이었고, 대화가 512토큰 쌓인 상태에서는 두 값이 모두 줄었습니다. 이 수치는 특정 GPU에서 잰 예시일 뿐이라 내 기기의 기준으로 삼지 않습니다.

🎛️ 측정 조건을 맞추는 법

측정값을 비교하려면 바꾼 것 하나만 달라야 합니다. 공식 문서의 설정과 필드 정의에서 나오는 조건을 모으면 다음과 같습니다.

  1. 같은 모델 태그와 양자화판: Q4_K_M과 Q8_0은 다른 측정입니다
  2. 같은 컨텍스트, 동시 요청 수, KV 캐시 형식: 셋 다 메모리를 바꿉니다
  3. 첫 요청 빼기: 모델 로드 시간이 섞이므로 한 번 미리 올려 둔 뒤 측정합니다
  4. 매번 다른 입력: 같은 입력은 캐시로 입력 처리 시간이 짧아집니다
  5. 여러 번 반복: llama-bench처럼 평균과 편차를 봅니다
  6. PROCESSOR와 CONTEXT 기록: 측정마다 ollama ps 결과를 함께 적습니다

측정표에는 기기 이름, 메모리, 모델, 양자화, 컨텍스트, 날짜를 같이 적어 두면 한 달 뒤 다시 측정할 때도 비교할 수 있습니다.

🍎 맥에서 메모리와 온도 보기

맥은 활성 상태 보기 앱의 메모리 탭 아래쪽에 있는 메모리 압력 그래프가 가장 빠른 지표입니다. 애플 공식 설명의 색 뜻은 이렇습니다.

색뜻
초록메모리를 효율적으로 쓰고 있음
노랑곧 메모리가 더 필요할 수 있음
빨강메모리가 더 필요함

모델을 돌리는 동안 빨강이 되고 사용된 스왑이 늘어난다면 모델이 메모리에 다 들어가지 않은 것입니다. GPU 사용은 윈도 메뉴의 GPU 기록에서 봅니다. 맥의 통합 메모리 구조는 맥에서 로컬 AI 돌리기에서 다뤘습니다.

터미널에서는 sudo powermetrics -s gpu_power,thermal -i 1000 -n 5처럼 GPU 소비 전력과 열 압력 상태를 볼 수 있습니다. 관리자 권한이 필요하고, 매뉴얼은 전력 값이 추정치라 기기끼리 비교하지 말라고 적습니다. 애플 실리콘 맥에서 CPU와 GPU 온도 수치를 보는 애플 공식 방법은 찾지 못했고, powermetrics로 확인되는 것은 온도가 아니라 열 압력 단계입니다.

🟩 엔비디아 GPU에서는 nvidia-smi

엔비디아 GPU는 nvidia-smi로 온도와 전력, 메모리를 봅니다. 공식 문서 기준으로 자주 쓰는 형태는 다음과 같습니다.

nvidia-smi -q -d TEMPERATURE,POWER,MEMORY -l 5

-q -d로 볼 항목을 고르고, -l 5로 5초마다 반복합니다. 알아 둘 항목은 GPU 코어 온도, 지난 1초의 평균 전력, 성능 상태(P0이 최대, P12가 최소), 그리고 클럭을 낮춘 원인(Clocks Event Reasons)입니다. 긴 작업 중 속도가 떨어졌는데 클럭을 낮춘 원인에 온도나 전력 제한이 표시된다면 기기가 뜨거워져 속도를 낮춘 것입니다. 다만 공식 문서는 일반 지포스 카드에서 조회되는 정보가 제한적일 수 있다고 적습니다.

⚠️ 자주 하는 실수

  • 첫 요청의 속도로 판단합니다: 모델 로드 시간이 들어가 있습니다
  • 같은 질문을 반복해 입력 처리 속도를 측정합니다: 캐시 때문에 실제보다 빠르게 나옵니다
  • 다른 사람의 측정값을 내 기기의 기준으로 씁니다: 기기, 양자화, 컨텍스트가 다르면 비교할 수 없습니다
  • 메모리 압력은 보지 않고 사용량만 봅니다: 맥은 사용량이 높아도 압력이 초록이면 정상입니다

❓ 자주 묻는 질문

초당 몇 토큰이면 쓸 만한가요?

공식 기준은 없습니다. 대화용이라면 사람이 읽는 속도보다 빠르면 답답하지 않고, 에이전트처럼 요청을 여러 번 보내는 작업은 입력 처리 속도가 더 중요합니다. 내 작업 한 건에 걸리는 전체 시간으로 판단하는 편이 현실적입니다.

속도가 갑자기 반으로 줄었으면 무엇부터 보나요?

ollama ps의 PROCESSOR 열부터 봅니다. GPU 비율이 줄었다면 메모리 문제이고, 그대로라면 기기 온도나 다른 프로그램의 부하를 확인합니다.

DGX 스파크 같은 장비의 공개 측정값은 믿어도 되나요?

조건을 함께 봐야 합니다. 준이아빠블로그의 DGX와 RTX 비교에 실린 커뮤니티 실측도 모델, 양자화, 연결 방식이 제각각이라 같은 조건으로 다시 측정하기 전에는 참고치로만 봅니다.

📋 3줄 요약

  1. 올라마 --verbose의 prompt eval rate는 입력 처리 속도이고 eval rate는 생성 속도이며, total duration에는 모델 로드 시간까지 들어가 있어 따로 읽어야 합니다.

  2. ollama ps의 PROCESSOR 열이 100% GPU가 아니면 모델 일부가 시스템 메모리로 밀려난 것이고, llama-bench는 같은 측정을 기본 5번 반복해 평균과 표준편차를 냅니다.

  3. 맥은 활성 상태 보기의 메모리 압력 색으로 메모리 부족을 보고, 엔비디아 GPU는 nvidia-smi로 온도와 전력, 클럭을 낮춘 원인을 확인합니다.

Share

제대로 이해했는지 한 문제로 확인해 볼까요?

답을 고르면 바로 풀이가 나와요.

ollama run --verbose 결과가 total duration 218초, eval count 10, eval rate 초당 0.08토큰으로 나왔습니다. 올바른 해석은 무엇일까요?

8개념 / 클래스로컬 AI 보안과 백업 (원격 접속 잠금, 모델과 데이터 보관)