홈랩 AI 성능 비교: Jetson Nano와 구형 GPU 벤치마크

홈랩 AI 성능이 궁금해서 장비를 하나씩 꺼내 비교해보신 적 있으신가요? 저도 홈랩에 굴러다니던 Jetson Nano와 예전에 쓰던 구형 GPU 장비를 다시 올려서 AI 추론(Inference, 학습이 아니라 이미 학습된 모델을 실행하는 과정) 성능을 비교해봤습니다. 처음엔 “둘 다 오래된 장비인데 큰 차이 있겠어?” 싶었는데, 막상 돌려보면 체감 포인트가 꽤 다르더라고요. 특히 로컬 LLM(Local LLM, 인터넷 없이 내 장비에서 직접 돌리는 언어 모델) 쪽은 숫자 하나보다 메모리, 전력, 드라이버, 발열이 훨씬 중요했습니다.

이 글은 막연한 감상문이 아니라, 홈랩에서 재현 가능한 기준으로 Jetson Nano와 구형 GPU를 어떻게 비교하면 되는지 정리한 글입니다. 직접 삽질하면서 느낀 점도 담았고, 어떤 항목을 봐야 실제 운영에 도움이 되는지도 같이 풀어보겠습니다. 집에서 소형 AI 노드 하나 만들어보려는 분이라면 꽤 실용적으로 보실 수 있을 거예요.

Jetson Nano, 구형 GPU 데스크톱, NAS 또는 측정용 노트북이 함께 연결된 홈랩 AI 벤치마크 구성 예시입니다.

왜 홈랩 AI 성능 비교에서 Jetson Nano와 구형 GPU를 같이 봐야 할까

쉽게 말해 둘은 출발점이 다릅니다. Jetson Nano는 소형 엣지 장비(edge device)라 전력과 크기에서 강점이 있고, 구형 GPU는 데스크톱이나 워크스테이션에 꽂아 순간 성능을 끌어올리는 쪽에 가깝습니다. 그래서 같은 AI 추론이라도 쓰임새가 달라집니다. 장비 하나만 보고 결론 내리면 생각보다 자주 틀립니다.

• Jetson Nano: 저전력, 작은 크기, GPIO 같은 확장성, 카메라 연동이 편합니다.
• 구형 GPU: 절대 성능이 더 잘 나오는 경우가 많고, 로컬 개발 환경을 맞추기 쉽습니다.
• 로컬 LLM: 둘 다 시도는 가능하지만, Jetson Nano는 모델 크기와 메모리 제약을 아주 강하게 탑니다.
• 비용 관점: 이미 가지고 있는 장비를 재활용하면 가성비가 좋아집니다.

여기서 중요한 포인트가 하나 있습니다. 벤치마크는 단순히 “누가 더 빠르냐”가 아닙니다. 홈랩에서는 보통 아래 네 가지를 같이 봐야 해요.

홈랩 AI 성능 비교에서 꼭 맞춰야 하는 기준

처음에는 장비마다 되는 모델을 그냥 올려서 돌렸거든요. 그런데 그렇게 하면 결과가 사실상 의미가 없습니다. 벤치마크(Benchmark, 성능 비교 테스트)는 조건을 맞춰야 비교가 됩니다. 이 부분을 대충 넘기면 로그는 많이 남는데 결론은 흐려지더라고요.

1. 가능하면 같은 모델을 씁니다.
2. 같은 양자화(Quantization, 모델을 더 작은 정밀도로 압축하는 방식) 옵션을 씁니다.
3. 입력 길이와 스레드 수를 고정합니다.
4. 첫 실행과 반복 실행을 구분합니다.
5. 속도뿐 아니라 메모리와 발열도 기록합니다.

특히 로컬 LLM은 첫 토큰 시간(Time To First Token)과 초당 토큰 수(tokens per second)를 같이 봐야 합니다. 반면 이미지 분류나 객체 탐지처럼 전형적인 엣지 AI 워크로드는 지연 시간(latency)과 초당 처리량(throughput)이 더 중요하죠. 그래서 저는 홈랩에서 보통 두 갈래로 나눠 봅니다.

• LLM 계열: 응답 생성 속도, 메모리 사용량, 프롬프트 길이 영향
• 비전 계열: 프레임 처리 속도, 추론 지연, 장시간 안정성

이번 글에서는 제목에 맞춰 AI 추론과 로컬 LLM 기준으로 설명하되, Jetson Nano의 특성을 고려해서 “무리한 대형 모델” 대신 “경량 모델 또는 CPU 기준 테스트” 중심으로 접근하겠습니다. Jetson Nano는 실사용 자체는 가능하지만, 최신 데스크톱 GPU처럼 여유 있게 돌리는 그림과는 거리가 있습니다.

실전 비교 환경 설계: 이렇게 맞추면 덜 틀립니다

실제로 써보니까 결과를 망치는 건 코드보다 환경 차이였습니다. 그래서 저는 아래처럼 아주 보수적으로 기준을 잡습니다. 조금 답답할 정도로 조건을 고정해두면 나중에 표를 볼 때 훨씬 덜 헷갈려요.

비교 대상 예시

• Jetson Nano: JetPack 기반 Ubuntu 환경
• 구형 GPU 시스템: 리눅스 데스크톱 또는 서버
• 동일 저장소: 같은 커밋의 벤치마크 도구 사용

측정 항목

• 응답 속도: 초당 토큰 수 또는 평균 지연 시간
• 메모리 사용량: OOM(Out Of Memory, 메모리 부족) 발생 여부 포함
• 전력과 발열: 장시간 운영 가능성 확인
• 재현성: 3회 이상 반복 후 편차 체크

여기서 팁 하나 드리면, Jetson Nano는 “된다/안 된다”의 경계가 생각보다 명확합니다. 모델이 조금만 커져도 스와핑(swapping, 메모리를 디스크로 넘기는 현상) 때문에 체감 성능이 급격히 무너집니다. 반대로 구형 GPU는 드라이버만 잘 맞으면 의외로 꽤 버텨줍니다. 그래서 홈랩 AI 성능을 볼 때는 최고점보다 지속 가능한 설정을 찾는 게 더 중요합니다.

동일 모델, 동일 프롬프트 길이, 반복 횟수, 메모리 기록 항목을 정리한 벤치마크 설계 화면 예시입니다.

실전 구현 1: 벤치마크 도구 준비

재현성과 단순함 때문에 저는 llama.cpp 계열 도구를 기준점으로 잡는 편입니다. 공식 저장소에서 <code>llama-cli와 llama-bench를 함께 쓸 수 있어서 비교 작업이 단순하거든요. 물론 Jetson Nano에서 최신 대형 모델을 기대하면 실망하기 쉽습니다. 여기서는 작은 GGUF 양자화 모델을 기준으로 “돌아가는지, 얼마나 버티는지”를 보는 쪽이 현실적입니다.

1. 공통 패키지 설치

sudo apt update
sudo apt install -y git build-essential cmake python3 python3-pip htop

기본 빌드 도구와 모니터링 도구만 먼저 맞춰둡니다. 여기서 패키지 버전을 과하게 올리기보다, 두 장비에서 공통으로 무리 없이 깔리는 구성이 더 낫더라고요.

2. 저장소 받기

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp

예전에는 다른 저장소 경로를 기억하시는 분도 있는데, 현재는 ggml-org/llama.cpp 기준으로 보는 편이 안전합니다.

3. Jetson Nano에서 CPU 기준 빌드

cmake -B build
cmake --build build -j

Jetson Nano는 GPU 오프로딩보다 우선 CPU 기준선부터 확보하는 게 좋습니다. 빌드가 단순해야 비교도 단순해지거든요.

4. 구형 NVIDIA GPU 시스템에서 CUDA 사용 가능 시 빌드

cmake -B build -DGGML_CUDA=ON
cmake --build build -j

여기서 주의하실 점이 있습니다. 구형 GPU는 CUDA 지원 범위가 카드 세대와 드라이버 조합에 따라 갈립니다. 그래서 “CUDA 빌드가 되느냐” 자체가 1차 체크포인트예요. 안 되면 억지로 붙잡지 말고 CPU 기준선부터 확보하세요. 저도 처음엔 드라이버만 붙잡고 시간 꽤 날렸습니다.

5. 시스템 상태 확인

uname -a
free -h
htop

Jetson Nano에서는 가능하면 별도 터미널에서 리소스를 같이 보는 게 좋습니다. tegrastats는 Jetson Linux에서 기본 제공되는 모니터링 도구라 실사용할 때 꽤 편합니다.

tegrastats

구형 NVIDIA GPU 시스템에서는 아래 명령으로 GPU 상태를 같이 확인합니다.

nvidia-smi

실전 구현 2: 벤치마크 실행과 기록 자동화

실제 비교는 손으로 돌리면 금방 꼬입니다. 입력 길이 하나 바뀌고, 스레드 하나 바뀌면 결과가 달라지거든요. 그래서 아주 단순한 기록 스크립트라도 두는 편이 낫습니다. 복잡한 자동화보다 조건 고정이 먼저예요.

mkdir -p ~/bench-results
MODEL_PATH=/path/to/model.gguf
THREADS=4
PROMPT="홈랩에서 로컬 LLM을 운영할 때 가장 중요한 자원은 무엇인가요?"

./build/bin/llama-bench -m "$MODEL_PATH" | tee ~/bench-results/bench_cpu.txt
./build/bin/llama-cli -m "$MODEL_PATH" -t $THREADS -p "$PROMPT" -n 64 | tee ~/bench-results/run_cpu.txt

위 예시는 CPU 기준선 확인용입니다. 먼저 이 값을 잡아두면 나중에 GPU 오프로딩이나 다른 장비를 붙였을 때 비교가 훨씬 쉬워집니다.

MODEL_PATH=/path/to/model.gguf
THREADS=4
PROMPT="Jetson Nano와 구형 GPU의 추론 특성을 비교해 주세요."

./build/bin/llama-bench -m "$MODEL_PATH" | tee ~/bench-results/bench_gpu.txt
./build/bin/llama-cli -m "$MODEL_PATH" -t $THREADS -ngl 20 -p "$PROMPT" -n 64 | tee ~/bench-results/run_gpu.txt

-ngl처럼 GPU 레이어 오프로딩 옵션은 지원 카드와 빌드 방식에 따라 체감 차이가 큽니다. 그래서 GPU 시스템에서는 값을 조금씩 올려가며 확인하는 방식이 가장 현실적이었습니다. 한 번에 정답 값을 찾으려 하면 오히려 더 오래 걸리더라고요.

조금 더 정리된 로그를 남기고 싶다면 Python으로 타임스탬프만 붙여도 충분합니다.

import subprocess
import time
from pathlib import Path

out_dir = Path.home() / "bench-results"
out_dir.mkdir(exist_ok=True)
log_file = out_dir / "session.log"
cmd = [
    "./build/bin/llama-cli",
    "-m", "/path/to/model.gguf",
    "-t", "4",
    "-p", "홈랩 AI 성능 비교 테스트를 시작합니다.",
    "-n", "64",
]

start = time.time()
result = subprocess.run(cmd, capture_output=True, text=True)
elapsed = time.time() - start

with log_file.open("a", encoding="utf-8") as f:
    f.write(f"time={elapsed:.2f}s\n")
    f.write(result.stdout)
    f.write("\n---\n")

print(result.stdout)

이 정도만 해도 홈랩에서는 충분합니다. 핵심은 연구 논문처럼 정교한 계측보다, 같은 조건으로 반복 가능한지를 확보하는 데 있습니다. 이게 쌓이면 나중에 장비 교체할 때도 판단이 훨씬 빨라져요.

벤치마크 실행 중 리소스 사용량과 추론 로그를 동시에 관찰하는 실제 운영 화면을 표현한 이미지입니다.

실제 겪었던 문제와 해결 방법

이 파트는 정말 중요합니다. 스펙표보다 도움이 더 많이 됩니다. 직접 해보니 아래 네 가지에서 가장 많이 막혔습니다.

1. Jetson Nano에서 메모리 부족

증상: 실행은 되는데 엄청 느리거나, 아예 프로세스가 죽습니다.

원인: 모델 크기, 컨텍스트 길이(context length), 스레드 수가 장비 한계를 넘긴 경우가 많습니다.

해결:

• 더 작은 모델 또는 더 강한 양자화를 사용합니다.
• 생성 길이(-n)와 컨텍스트 길이를 줄입니다.
• 백그라운드 서비스부터 정리합니다.

2. 구형 GPU에서 CUDA 빌드는 되는데 속도가 애매함

증상: GPU를 쓰는데도 기대만큼 빠르지 않습니다.

원인: PCIe 대역폭, VRAM 한계, 오프로딩 비율이 맞지 않는 경우가 있습니다.

해결:

• -ngl 값을 여러 단계로 바꿔봅니다.
• GPU 메모리에 안 맞는 모델은 과감히 낮춥니다.
• CPU와 GPU 혼합 구성이 오히려 느릴 수 있다는 점을 염두에 둡니다.

3. 같은 모델인데 결과 편차가 큼

증상: 첫 실행과 두 번째 실행이 꽤 다릅니다.

원인: 캐시, 발열 스로틀링(thermal throttling, 온도 때문에 성능이 낮아지는 현상), 백그라운드 작업 영향입니다.

해결:

• 최소 3회 반복합니다.
• 첫 실행은 워밍업(warm-up)으로 분리합니다.
• 장비 온도가 안정된 뒤 다시 측정합니다.

4. 로컬 LLM이 되긴 되는데 체감이 나쁨

이건 성능 숫자와 사용 경험이 다를 때 생깁니다. 초당 토큰 수가 아주 나쁘지 않아도 첫 토큰이 늦으면 답답하거든요. 그래서 저는 벤치마크 결과를 볼 때 “총 처리량”보다 “대화가 가능한가”를 먼저 봅니다. 홈랩 장비는 특히 그렇습니다. 이 차이가 실제 만족도를 꽤 크게 갈라요.

홈랩 AI 성능 검증과 결과 해석: 숫자보다 중요한 것

이제 결과를 어떻게 읽을지 이야기해보겠습니다. 정확한 수치를 여기서 단정적으로 적지는 않겠습니다. 장비 상태, 모델 크기, 양자화, 드라이버 조합에 따라 차이가 꽤 크거든요. 대신 여러 번 비교하면서 거의 공통적으로 느낀 경향은 있습니다.

• Jetson Nano는 경량 추론이나 엣지 연동에서 매력이 큽니다.
• 구형 GPU는 전력과 소음은 불리해도, 로컬 실험용 추론 체감은 더 좋은 경우가 많습니다.
• 로컬 LLM은 Jetson Nano에서 “가능 여부”를 먼저 확인해야 하고, 구형 GPU는 “쓸 만한 응답 속도”가 나오는지 확인하면 됩니다.
• 홈랩 AI 성능은 절대 속도보다도 안정적으로 몇 시간 돌릴 수 있는지가 더 중요합니다.

제가 추천하는 결과 기록 방식은 아래처럼 아주 단순한 표입니다.

결론만 빨리 말씀드리면 이렇습니다. Jetson Nano는 “작고 오래 도는 노드”, 구형 GPU는 “실험이 빠른 노드”로 보는 게 맞았습니다. 둘 중 하나가 절대 우위라기보다 역할이 다르더라고요.

응답 속도, 메모리 사용량, 안정성 항목을 한눈에 비교하는 홈랩 AI 성능 결과 대시보드 이미지입니다.

어떤 장비를 고르면 좋을까

이 부분은 가장 많이들 궁금해하시는 대목이죠. 제 경험으로는 목적을 먼저 정하면 선택이 훨씬 쉬워집니다. 성능표보다 운영 방식이 더 중요할 때가 정말 많습니다.

1. 센서, 카메라, 경량 추론이 목적이면 Jetson Nano가 잘 맞습니다.
2. 로컬 LLM 체험과 빠른 반복 실험이 목적이면 구형 GPU가 유리합니다.
3. 24시간 홈랩 운영이 중요하면 전력과 발열부터 계산하세요.
4. 개발 생산성이 중요하면 드라이버와 빌드 편의성도 성능만큼 중요합니다.

홈랩은 “최신 장비가 답”인 분야가 아니었습니다. 남는 장비를 얼마나 목적에 맞게 배치하느냐가 훨씬 중요하더라고요. 저도 처음엔 큰 모델만 쫓아갔는데, 실제로는 작은 모델을 빠르고 안정적으로 돌리는 구성이 더 자주 쓰였습니다.

전력 효율, 추론 속도, 소음, 설치 난이도 기준으로 두 장비를 선택하는 요약 인포그래픽입니다.

정리와 다음 단계

이번 홈랩 AI 성능 비교에서 핵심은 단순했습니다. Jetson Nano와 구형 GPU는 같은 AI 추론 장비처럼 보여도 실제 운영 포인트가 다릅니다. Jetson Nano는 저전력 엣지 추론에, 구형 GPU는 로컬 LLM 실험과 반응성 확보에 더 어울립니다. 직접 해보니 숫자 하나보다 메모리 한계와 발열, 그리고 드라이버 삽질 시간이 결과를 더 크게 좌우했습니다.

다음 글에서는 실제로 홈랩에서 작은 모델을 올려 API 서버 형태로 붙이는 방법, 예를 들면 FastAPI 기반 추론 엔드포인트나 reverse proxy 구성까지 이어서 다뤄볼 예정입니다. 이전 글에서 다룬 홈서버 리소스 모니터링 구성과 함께 보시면 흐름이 더 잘 잡힐 거예요.

자주 묻는 질문

Jetson Nano로 로컬 LLM 운영이 가능할까요?

가능은 하지만 모델 크기와 양자화 수준에 따라 체감이 크게 달라집니다. 기대치를 낮추고 경량 구성부터 시작하는 편이 훨씬 낫습니다.

구형 GPU가 항상 더 좋은가요?

항상 그렇진 않습니다. 전력, 소음, 공간, 안정성까지 같이 보면 홈랩에서는 Jetson Nano가 더 좋은 선택일 때도 있습니다.

벤치마크에서 가장 먼저 기록할 값은 뭔가요?

첫 토큰 반응 시간, 반복 실행 안정성, 메모리 부족 여부부터 보시면 됩니다. 이 세 가지가 실제 체감과 가장 잘 연결됩니다.