로컬 AI 하드웨어 기초, VRAM과 통합 메모리와 대역폭

🤔 메모리가 24GB인데 17GB 모델이 안 올라갈 때

모델 파일이 17GB이고 컴퓨터 메모리가 24GB면 7GB가 남으니 될 것 같은데, 실제로 올려 보면 GPU가 아니라 CPU에서 실행되어 한 문장에 몇 분씩 걸리는 일이 있습니다. 반대로 메모리가 128GB나 되는 장비를 샀는데 32GB짜리 그래픽카드보다 답이 느리게 나오기도 합니다.

파일 크기와 총 메모리만 비교하면 이런 차이를 설명하기 어렵습니다. 로컬 AI에서 메모리 용량과 메모리 대역폭과 연산 성능이 각각 어떤 영향을 주는지, 그래픽카드와 통합 메모리 구조가 어떻게 다른지를 정리했습니다.

🔑 로컬 AI 하드웨어의 세 가지 숫자

로컬 AI에서는 메모리 용량과 대역폭 및 연산 성능을 함께 봅니다. 실행 도구와 모델 구조 및 입력 길이에 따라 어느 부분이 한계가 되는지는 달라집니다.

사양표에서 볼 숫자는 셋입니다.

세 가지 가운데 먼저 보는 것은 용량입니다. GPU에 전부 올려 실행하려면 가중치와 추가 작업 공간이 그 메모리에 들어가야 합니다. CPU로만 실행하거나 CPU와 GPU에 나누는 방법도 있으므로 공간 부족이 항상 실행 불가를 뜻하지는 않습니다. 다만 처리 속도가 달라지거나 도구에 따라 오류가 날 수 있습니다.

🎮 그래픽카드의 VRAM과 통합 메모리의 차이

GPU가 쓰는 메모리는 컴퓨터 구조에 따라 두 가지로 나뉩니다.

• 그래픽카드 방식: 카드에 붙은 전용 메모리인 VRAM(Video RAM)이 한도입니다. 본체 메모리 64GB가 카드의 VRAM 64GB로 바뀌지는 않습니다. GPU에 전부 올릴 수 있는지는 전용 VRAM을 기준으로 봅니다. 소비자용 카드 가운데 큰 편인 RTX 5090이 32GB이고, 워크스테이션용 RTX PRO 6000 Blackwell Workstation Edition은 96GB입니다.
• 통합 메모리 방식: CPU와 GPU가 메모리 하나를 나눠 씁니다. 애플 실리콘 맥과 엔비디아 DGX 스파크와 RTX 스파크가 이 구조입니다. CPU와 GPU가 같은 물리 메모리를 공유하지만 운영체제와 다른 앱도 그 공간을 사용합니다.

통합 메모리라고 해서 사양표의 용량을 모델이 다 쓰는 것은 아닙니다. GPU가 사용할 수 있는 양은 기기와 운영체제 및 실행 도구에서 확인합니다. 모든 맥에 75%, 모든 통합 메모리 장비에 80% 같은 비율을 적용하지 않습니다.

메모리가 부족할 때 모든 기기가 모델 전체를 CPU로 옮기는 것은 아닙니다. 실행 도구에 따라 모델 일부만 CPU에 나눠 실행하거나 오류를 내고 멈춥니다. DGX 스파크의 구조는 DGX 스파크에서, 맥에서 확인할 순서는 아래 맥에서 로컬 AI를 돌릴 때 확인할 것에서 이어집니다.

전용 메모리와 통합 메모리를 비교하는 개념도입니다. 용량 비율을 표현하지 않으며 실제 GPU 사용 가능량은 장비와 설정에서 확인해야 합니다.

🍎 맥에서 로컬 AI를 돌릴 때 확인할 것

애플 실리콘 맥은 별도 그래픽카드가 없어도 칩 안에 GPU가 있어 로컬 AI를 실행할 수 있습니다. M 시리즈 칩의 CPU와 GPU는 통합 메모리 하나를 함께 쓰고, 운영체제와 브라우저 같은 다른 앱도 같은 메모리를 씁니다. 그래서 맥에서는 그래픽카드가 있는지보다 두 가지를 먼저 확인합니다. 모델과 다른 앱이 함께 쓸 메모리가 충분한지, 그리고 실행 도구가 내 맥의 칩과 macOS 버전을 지원하는지입니다.

실행 도구 가운데 llama.cpp는 애플 GPU로 계산하게 하는 Metal을 지원합니다. Ollama 문서는 macOS 14 Sonoma 이상을 요구하고, 애플 실리콘 맥에서는 CPU와 GPU를, 인텔 맥에서는 CPU만 사용한다고 안내합니다.

내 맥에서는 아래 순서로 확인합니다.

1. 애플 메뉴의 이 Mac에 관하여에서 칩 종류, 메모리 용량, macOS 버전을 적습니다.
2. Spotlight 검색으로 활성 상태 보기 앱을 열고 메모리 탭 아래쪽의 메모리 압력 그래프를 봅니다. 애플 설명으로 초록은 메모리를 효율적으로 쓰는 상태, 노랑은 곧 메모리가 더 필요할 수 있는 상태, 빨강은 메모리가 더 필요한 상태입니다. 메모리 압력은 맥 전체의 상태이며 모델 하나의 사용량은 아닙니다.
3. Ollama로 작은 모델에 질문한 직후 터미널에 ollama ps를 입력하고 PROCESSOR 열을 봅니다. 100% GPU는 모델이 GPU 쪽에 올라갔다는 뜻이고, 100% CPU는 모델 전체가 CPU에서 실행되고 있다는 뜻입니다.

준이아빠블로그의 24GB 맥미니 M4 프로와 Qwen3.8 27B 실행 기록에서는 PROCESSOR가 100% CPU로 표시됐습니다. 기록에 남은 질문은 1+1은? 하나였고, 전체 시간은 218.2초, 생성 속도는 초당 약 0.08토큰이었습니다. 당시의 macOS 버전, 도구 설정과 여유 메모리에서 나온 결과이므로 같은 메모리를 단 다른 맥의 결과로 옮기지 않습니다.

맥 스튜디오 M5 Max와 M5 Ultra처럼 메모리가 큰 맥은 더 큰 모델을 담을 수 있지만, 같은 모델을 더 빨리 처리하는지는 따로 봐야 합니다. 두 기기의 메모리와 대역폭은 아래 대역폭 표에 함께 적었습니다.

AI 모델을 만들고 실행하는 파이썬 라이브러리인 PyTorch로 만든 이미지나 음성 모델은 PyTorch의 맥 GPU 기능(MPS)으로 맥 GPU를 씁니다. 엔비디아 GPU용 CUDA 코드는 장치 이름만 mps로 바꾼다고 모두 동작하지는 않으므로, 모델 설명에서 맥 지원 여부와 설치 조건을 확인합니다.

📐 모델에 필요한 메모리를 어림하는 방법

가중치 저장량은 파라미터 수와 정밀도로 어림할 수 있습니다. 파라미터는 모델이 학습하면서 맞춰 둔 숫자 하나하나이고, B는 10억 단위이므로 27B는 약 270억 개를 뜻합니다. 모델 이름은 반올림된 표시일 수 있어 정확한 파라미터 수는 모델 설명을 확인합니다. 정밀도는 숫자 하나를 몇 비트로 저장하는지이고, 개인 장비에서는 대개 4비트로 압축해서 씁니다. 이 압축을 양자화라고 부르며 바로 다음 절에서 설명합니다.

4비트는 0.5바이트이므로 파라미터 수에 0.5를 곱하면 가중치만의 단순 저장량이 됩니다. 실제 양자화 파일에는 보조 정보가 있고 일부 값은 더 높은 정밀도로 저장되기도 합니다. 아래 GB는 십진 단위이며 운영체제가 표시하는 GiB와 수치가 다를 수 있습니다.

실행 메모리는 이 표보다 더 필요합니다. 대화 처리 중 재사용할 값을 저장하는 KV 캐시, 연산용 버퍼와 실행 도구의 사용량을 확인합니다. 입력 길이와 동시 요청 수가 커지면 추가 공간도 달라집니다. 실제 파일이 17GB였다는 관찰은 총 실행 메모리가 17GB라는 뜻이 아닙니다.

모델 크기를 고를 때는 가장 큰 모델부터 시도하지 않습니다. 내 메모리에 가중치와 추가 공간이 여유 있게 들어가는 후보를 두세 개 고르고, 같은 질문 묶음으로 정확성과 걸린 시간을 비교합니다. 70B 모델이라도 메모리에 다 올라가지 않아 CPU로 실행되면 한 번 답하는 데 몇 분씩 걸릴 수 있습니다. 8B 같은 작은 모델이 내 작업의 질문을 정확히 맞힌다면 그 모델로 충분합니다.

🗜️ 양자화 뜻과 GGUF, Q4_K_M 이름 읽기

양자화(quantization)는 모델의 가중치를 더 적은 비트로 저장해 파일 크기와 필요한 메모리를 줄이는 방법입니다. 학습을 마친 모델은 숫자 하나를 보통 16비트로 저장합니다. 숫자 하나를 8비트나 4비트로 줄여 저장하면 파일이 그만큼 작아집니다. 사진을 압축해 저장하면 용량이 줄고 확대했을 때 조금 뭉개지듯, 숫자를 거칠게 저장하면 답의 정확도가 달라질 수 있습니다. 얼마나 달라지는지는 모델, 양자화 방식과 질문에 따라 다르므로 고정된 손실 비율은 없습니다.

비트는 정보를 저장하는 단위이고 8비트가 1바이트입니다. 아래는 모든 가중치를 같은 비트로 저장하고 보조 정보를 뺀 단순 계산입니다.

Ollama나 허깅페이스에서 모델을 고르면 같은 모델 이름 뒤에 q4_K_M, q8_0, bf16 같은 꼬리표가 붙어 있습니다. 2026년 10월 24일 Ollama 라이브러리에서 Qwen3.8 27B는 27b-q4_K_M이 18GB, 27b-q8_0이 30GB, 27b-bf16이 56GB로 표시됐습니다. 위 표의 단순 계산보다 큰 이유는 실제 파일에 보조 정보와 더 높은 정밀도로 남긴 부분이 들어 있기 때문입니다. 표시 크기도 총 실행 메모리는 아닙니다.

GGUF는 파일 형식, Q4_K_M은 양자화 방식

GGUF는 가중치와 모델 정보를 한 파일에 담는 형식이고, Q4_K_M은 그 파일 안의 가중치를 줄여 저장하는 양자화 방식입니다. GGUF는 llama.cpp 계열 도구가 읽는 형식이며 Ollama와 LM Studio도 이 형식을 읽습니다. GGUF는 가중치를 담는 형식일 뿐이므로 같은 GGUF라도 4비트, 8비트, 16비트 파일이 따로 있고, 실행 도구가 그 모델 구조와 양자화 방식까지 지원해야 실행됩니다.

K 계열은 가중치를 묶음으로 나눠 배율 같은 보조 정보를 함께 저장합니다. 그래서 Q4_K_M 파일 크기를 파라미터 수에 정확히 0.5바이트를 곱한 값으로 계산할 수 없습니다. 이름의 M은 여러 정밀도를 섞는 정도를 나타내는 구성 이름이며 모델 크기나 컨텍스트 길이가 아닙니다.

처음 고를 때는 실행 도구가 지원하는 4비트판을 후보로 보고, 메모리에 여유가 있는데 중요한 정보가 틀리면 8비트판과 비교합니다. 4비트판도 메모리에 맞지 않으면 더 작은 모델을 후보에 넣습니다.

양자화로 줄지 않는 것과 증류와의 차이

양자화는 가중치 파일만 줄입니다. 대화 처리 중 값을 다시 쓰려고 저장하는 KV 캐시와 연산용 작업 공간은 가중치를 4비트로 바꿔도 따로 필요합니다.

비슷하게 들리는 말로 증류(distillation)가 있습니다. 양자화는 같은 모델의 숫자를 더 거칠게 저장하는 것이라 파라미터 수가 그대로입니다. 27B를 4비트로 줄여도 여전히 27B 모델입니다. 증류는 큰 모델의 출력을 활용해 다른 모델을 학습시키는 방법이라, 그 결과는 원래 모델과 다른 별도 모델입니다.

🚰 대역폭이 답하는 속도에 영향을 주는 이유

모델이 답을 만드는 과정은 두 단계로 나뉩니다. 입력한 내용 전체를 한 번에 읽어 내부 상태를 만드는 프리필(prefill)과, 토큰을 하나씩 만들어 내는 디코드(decode)입니다. 밀집 모델은 매 단계에서 모델의 가중치 전반을 계산에 사용하는 구조입니다. 단일 요청의 밀집 모델이 주로 가중치 읽기에 제한된다는 단순 가정에서는 대역폭을 가중치 크기로 나눠 처리량을 어림할 수 있습니다. 배치, 캐시와 모델 구조 및 다른 연산을 생략한 계산이므로 실제 토큰 속도나 보편적 상한은 아닙니다.

4비트 27B 모델의 가중치 13.5GB를 기준으로 단순 계산값을 비교하면 이렇습니다.

오른쪽은 같은 가중치 13.5GB를 한 번 읽는 비용만 계산한 값입니다. 실제 속도 순위나 차이를 보장하지 않습니다. 같은 모델과 실행 도구, 입력 길이 및 배치에서 측정한 결과와 대조해야 합니다. 용량이 큰 기기가 더 큰 모델을 담을 수 있어도 같은 작업을 더 빨리 한다고 단정할 수 없습니다. 제조사 사양 확인일은 2026년 10월 3일이며, M5 Ultra의 512GB 구성은 10월 말 출시 예정입니다.

MoE(Mixture of Experts, 전문가 혼합) 구조의 모델에서는 두 값이 서로 다른 역할을 맡습니다. 파라미터를 잔뜩 갖춰 두되 토큰 하나를 처리할 때는 일부만 계산에 넣는 방식이라, 전체 가중치를 보관할 공간과 매 단계에 활성화되는 부분을 구분합니다. CPU 메모리로 나누는 등 배치 방법에 따라 필요한 GPU 공간은 달라집니다. 이름이 397B-A17B라면 전체 약 397B, 활성 약 17B를 뜻하지만 이 두 숫자만으로 메모리와 속도를 확정할 수는 없습니다. 메모리가 크고 대역폭이 낮은 장비에 활성 파라미터가 작은 MoE 모델이 상대적으로 맞는 이유가 여기에 있습니다.

⚙️ 긴 입력에서는 연산 성능도 확인합니다

대역폭만으로 전체 응답 시간을 설명할 수는 없습니다. 짧게 묻고 길게 답을 받는 대화라면 디코드가 대부분이지만, 저장소 전체를 읽히거나 긴 문서를 통째로 넣는 작업이라면 프리필이 시간을 잡아먹습니다. 프리필은 연산 성능의 영향을 크게 받을 수 있습니다. 일반적인 전체 어텐션 계산은 길이의 제곱에 비례하는 부분이 있지만 캐시와 모델 구조가 다르므로 입력이 두 배면 전체 시간이 네 배라는 뜻은 아닙니다.

사양표의 TOPS나 FLOPS는 초당 연산량을 나타냅니다. 숫자를 표현하는 정밀도와, 값이 0인 부분의 연산을 생략하는 희소성 적용 여부가 다르면 수치를 그대로 비교하지 않습니다. 작업 전체에서는 모델 로드, 입력 처리와 생성 및 다른 도구 대기 시간을 구분해 측정합니다.

⏱️ 로컬 AI 성능 직접 측정하기: --verbose와 llama-bench

로컬 AI 성능 측정은 같은 조건에서 입력 처리 속도와 생성 속도, 메모리 사용과 기기 상태를 기록해 비교하는 일입니다. 위에서 본 프리필과 디코드를 실제 숫자로 나눠 보는 단계입니다. 사양표의 계산값과 내 기기의 실제 속도가 얼마나 다른지도 여기서 확인합니다.

Ollama의 --verbose 결과 읽기

터미널에서 ollama run 모델이름 --verbose로 대화하면 답 뒤에 시간 기록이 붙습니다. 모델이름은 ollama list에 나온 설치된 모델 이름으로 바꿉니다.

자주 하는 착각은 전체 시간으로 생성 속도를 계산하는 것입니다. 예를 들어 답으로 100토큰을 만들었고 eval duration이 4초, total duration이 8초라면 생성 속도는 100 ÷ 4 = 초당 25토큰입니다. 100을 8로 나눈 12.5는 로드와 입력 처리 시간이 섞인 값입니다. 첫 요청에는 모델을 올리는 시간이 들어가므로, 모델이 이미 올라간 뒤의 요청과 따로 기록합니다.

llama-bench로 반복 측정하기

모델이나 양자화판 여러 개를 비교할 때는 llama.cpp에 들어 있는 llama-bench를 씁니다. 같은 측정을 여러 번 반복해 평균과 표준편차(측정값이 흩어진 정도)를 내 줍니다.

결과는 -o md, -o csv, -o json으로 표, 엑셀용 파일, 프로그램용 형식 가운데 골라 받습니다. 다른 사람이 올린 측정값은 기기와 양자화와 입력 길이가 다르므로 내 기기의 기준으로 쓰지 않습니다.

측정 조건 맞추기

측정값을 비교하려면 바꾼 조건이 하나뿐이어야 합니다.

1. 같은 모델 태그와 양자화판을 씁니다. q4_K_M과 q8_0은 다른 측정입니다.
2. 컨텍스트 길이와 동시 요청 수를 같게 둡니다. 둘 다 메모리 사용량을 바꿉니다.
3. 첫 요청과 이후 요청을 나눠 적습니다.
4. 같은 질문 묶음을 쓰고, 같은 질문을 반복하면 이미 처리한 입력이 캐시로 재사용될 수 있다는 점을 기록합니다.
5. 측정마다 ollama ps의 PROCESSOR와 CONTEXT 열을 함께 적습니다. CONTEXT는 실제로 잡힌 컨텍스트 길이입니다.

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

메모리와 온도 확인하기

맥에서는 앞의 맥 절에서 본 활성 상태 보기의 메모리 압력이 가장 빠른 지표입니다. 모델을 돌리는 동안 빨강이 되고 스왑(메모리 내용을 디스크로 옮긴 공간) 사용량이 늘면 맥 전체의 메모리 여유가 부족하다는 신호입니다. 열 상태는 터미널에서 관리자 권한으로 sudo powermetrics -s thermal -n 1을 실행해 봅니다. 이 명령은 맥의 현재 열 압력 단계를 보여 줍니다.

엔비디아 그래픽카드에서는 터미널에서 다음 명령으로 온도, 전력과 메모리를 5초마다 봅니다. 반복 조회는 Ctrl+C로 끝냅니다.

긴 작업 중에 속도가 떨어졌다면 ollama ps의 PROCESSOR 열부터 봅니다. PROCESSOR 열의 GPU 비율이 그대로라면 입력 길이, 캐시 사용, 다른 프로그램의 부하와 기기 온도를 차례로 확인합니다.

⚠️ 자주 하는 실수

• 파일 크기와 메모리 용량만 비교합니다: 모델이 쓸 수 있는 여유 공간은 사양표 용량보다 작을 수 있습니다. 비율 하나로 정하지 말고 모델과 도구의 요구 조건 및 현재 여유를 확인합니다.
• 메모리가 크면 빠를 것이라고 봅니다: 용량과 대역폭 및 연산 성능은 역할이 다르므로 같은 작업의 실제 시간을 봅니다.
• CPU 코어 수나 저장 장치 용량을 봅니다: CPU 실행, 분산 배치나 스왑이 발생하는 경우 CPU와 메모리 및 저장 장치도 영향을 줍니다. 저장 용량이 크다는 것과 읽는 속도가 빠르다는 것은 다릅니다.
• 총 파라미터로 속도를 짐작합니다: MoE의 활성량은 참고할 값이며 실제 속도는 전문가 선택과 배치 및 실행 도구에도 영향을 받습니다.

❓ 자주 묻는 질문

본체 메모리를 늘리면 그래픽카드에서 더 큰 모델이 돌아가나요?

본체 메모리가 늘어도 카드의 전용 VRAM 자체가 늘지는 않습니다. 다만 도구가 지원하면 모델 일부를 본체 메모리에 두는 방식으로 더 큰 모델을 실행할 수 있습니다. 이 경우 속도와 전송 부담이 달라지므로 실제 작업으로 비교합니다.

그래픽카드 두 장을 꽂으면 VRAM이 합쳐지나요?

실행 도구가 가중치를 두 장에 나눠 올리는 방식으로는 됩니다. 다만 RTX 5090은 카드끼리 직접 잇는 NVLink를 지원하지 않아 두 장 사이의 데이터가 메인보드의 PCIe를 거치고, 카드 두 장분의 전원과 케이스 공간이 필요합니다. 메모리는 단순 합계만으로 판단하지 않습니다. 가중치 분배와 추가 작업 공간 및 기기 간 전송을 포함해 확인합니다.

대역폭이 낮은 장비는 쓸모가 없나요?

처리할 작업과 모델 구조에 따라 다릅니다. 메모리 용량이 필요한 모델이나 활성 파라미터가 적은 MoE에서는 선택이 달라질 수 있습니다. 대역폭 수치 하나로 쓸모나 속도를 확정하지 않고 자신의 질문과 입력 길이로 비교합니다.

양자화한 모델은 원본보다 얼마나 나빠지나요?

모든 모델에 적용되는 고정된 비율은 없습니다. 같은 원본의 4비트판과 8비트판에 같은 질문 묶음을 넣고, 정답 여부와 빠진 내용, 지어낸 내용을 비교해야 내 작업에서의 차이를 알 수 있습니다. 숫자나 코드처럼 작은 오류가 중요한 작업은 그 업무의 확인 기준으로 따로 봅니다.

노트북으로도 로컬 AI가 되나요?

지원되는 모델과 도구, 충분한 자원이 있으면 가능합니다. 같은 메모리 용량이라도 GPU 사용 한도와 발열, 전력 설정이 다를 수 있습니다. 지금 있는 기기에서 짧은 입력과 작은 모델로 먼저 확인하고, 한 장비의 27B 실패 사례를 모든 노트북의 한도로 보지 않습니다.

가중치 용량과 추가 메모리를 나눠 계산하기

계산기에 가상 8B 모델의 4비트 가중치 저장량을 입력합니다. B는 10억, 4비트는 0.5바이트이므로 8 × 0.5 = 약 4GB입니다. 여기까지는 가중치만 계산한 값입니다.

이 연습은 CPU와 GPU가 총 16GB를 공유하는 통합 메모리 기기를 가정합니다. 연습을 위해 캐시 2GB, 작업 공간 1GB, 다른 프로그램 사용량 5GB라고 가정하면 합계는 12GB입니다. 이 추가값은 실제 모델의 요구 조건이 아닌 계산 연습용입니다. 총 메모리 16GB와 비교하면 4GB가 남지만 GPU 사용 가능량과 실행 도구 지원까지 확인해야 하므로 실행 성공을 확정하지 않습니다.

이번에는 캐시만 7GB로 바꿉니다. 합계는 17GB로 16GB를 넘습니다. 처음의 “가중치가 4GB이니 충분하다”라는 판단이 왜 부족했는지 설명해 봅니다. 실제로는 입력 길이를 줄이거나 작은 모델을 검토한 뒤 같은 조건으로 다시 측정합니다.

마지막으로 내 기기의 총 메모리와 GPU 메모리를 적습니다. 전용 VRAM과 본체 RAM을 무조건 더하지 않고, 통합 메모리라면 하나의 공유 공간임을 표시합니다. 모르는 값은 추정으로 채우지 말고 확인 필요로 남깁니다.

📋 3줄 요약

1. 메모리 용량과 대역폭 및 연산 성능은 역할이 다르며 모델과 도구의 호환성도 함께 확인합니다.

2. 4비트 가중치의 단순 저장량에 캐시와 작업 공간을 더해야 실행에 필요한 메모리를 판단할 수 있습니다.

3. 사양표의 계산값을 실제 속도로 단정하지 않고 같은 조건에서 정확성과 전체 작업 시간을 비교합니다.

참고 자료

• NVIDIA DGX Spark 사양
• NVIDIA RTX 50 시리즈 메모리 대역폭
• NVIDIA RTX PRO 6000 Blackwell 사양
• NVIDIA GeForce RTX 5090 사양
• NVIDIA RTX Spark 통합 메모리 구조
• Apple Mac Studio M5 Max와 M5 Ultra
• llama.cpp 지원 실행 방식
• Ollama macOS 요구 조건
• Apple 활성 상태 보기의 메모리 압력
• PyTorch MPS 백엔드
• GGUF 형식과 양자화 종류
• Ollama Qwen3.8 태그별 크기
• Ollama ps 실행 장치 표시
• llama-bench 옵션과 반복 측정
• NVIDIA nvidia-smi 항목 설명