llmfit: 로컬 LLM 모델을 내려받기 전, 내 하드웨어에서의 생성 속도(tok/s)가 얼마 정도일지 추정하는 도구

9bow · 9월 16, 2026, 3:00오전

llmfit 소개

로컬에서 대규모 언어 모델(Large Language Model, LLM)을 직접 실행해 보려는 사람이 가장 먼저 부딪히는 질문은 내 컴퓨터에서 어떤 모델이 실제로 실행 가능한지에 대한 것입니다. 모델 크기(파라미터 수)와 양자화(Quantization) 포맷, 컨텍스트 길이, GPU의 VRAM과 시스템 RAM 등, 여러가지 요구 조건과 제약들을 따져봐야 하기 때문에 모델 카드만 보고 메모리 요구량을 짐작하기가 쉽지 않습니다. 그래서 수 GB짜리 GGUF 파일을 먼저 내려받아 실행해 본 뒤에야 메모리가 모자라거나 초당 토큰 수가 쓸 만한 수준이 아니라는 사실을 알게 되는 경우도 흔하게 발생합니다.

사용해보려고 하는 후보 모델이 늘어날수록 이러한 시행착오의 횟수도 함께 늘어나고, 어느 양자화 단계까지 내려가야 메모리에 들어가는지는 결국 하나씩 다운로드 받아 실행하며 확인하게 됩니다. 이번에 소개하는 llmfit은 이러한 확인 작업을 줄이는 것을 목표로 하는 프로젝트로, 지금 사용하는 컴퓨터에서 어떤 모델이 얼마나 빠르게 토큰을 생성(tok/s)할 수 있을지를 추정하는 터미널 도구입니다.

llmfit은 실행하는 즉시 CPU 코어 수와 시스템 RAM, GPU와 VRAM, 가속 백엔드 등을 자동으로 확인한 다음, 내장 카탈로그에 담긴 수백 개 모델을 품질과 속도, 적합도, 컨텍스트라는 네 가지 기준으로 점수를 매겨 표로 정리합니다. 각 행에는 그 모델이 지금 이 컴퓨터에서 어떤 양자화로 실행 가능한지, 예상 속도가 몇 tok/s인지, 메모리를 몇 퍼센트나 쓰는지가 함께 표시됩니다. 여기에 더해 llmfit은 그 속도 숫자가 공식으로 계산한 추정치인지 누군가 같은 하드웨어에서 실제로 측정한 값인지를 등급으로 구분해 표시합니다. 실제로 측정한 처리량과 공식으로 계산한 값이 모두 tok/s라는 같은 단위로 표시되기 때문입니다.

llmfit의 터미널 화면에서 모델 목록이 점수와 속도, 양자화, 적합도 순으로 정렬되는 모습

llmfit은 Rust로 작성하였으며, 실행 모드 시 의존성이 필요 없는 가벼운 대화형 터미널 UI(TUI)를 기본으로 제공합니다. 필요 시 외부 스크립트와 에이전트와 연동하기 좋은 전통적인 CLI 모드와 JSON 출력도 함께 제공합니다. 특히, 모델 목록을 보여주는 데 그치지 않고 Ollama, llama.cpp, MLX, Docker Model Runner, LM Studio ( [GN⁺] LM Studio - LLM을 로컬에서 쉽게 실행하게 해주는 도구)와 같은 로컬 런타임(Runtime) 제공자를 자동으로 감지해, 이미 설치된 모델을 표시하고 새 모델을 그 자리에서 내려받는 것까지 이어지는 것이 특징입니다. 클러스터 스케줄러나 대시보드에서 노드별 정보를 읽어 갈 수 있도록 llmfit serve 명령으로 REST API 서버도 실행할 수 있도록 지원합니다.

기존의 로컬 모델을 고르는 방식 vs. llmfit

하드웨어에 맞는 로컬 모델을 고르는 방법은 크게 세 가지로 나뉩니다:

직접 계산해 보고 받아서 확인하는 방법
llm-checker와 같은 도구를 사용하여 실제로 모델을 실행해 보고 확인하는 방법
llmfit과 같은 도구를 사용하여 스펙으로부터 추정한 뒤 필요할 때만 실측으로 보정하는 방법

llmfit에서 정리한, 위 3가지 각 방법의 차이는 다음과 같습니다:

방식	판정 근거	모델을 먼저 받아야 하는가	MoE 구조 반영	속도 수치
직접 계산하고 받아 보기	사람이 모델 카드와 VRAM을 대조	확인하려면 받아야 함	사람이 직접 계산	실행해 봐야 알 수 있음
llm-checker	하드웨어 스캔 + Ollama로 실제 실행	벤치마크하려면 받아야 함	반영하되 메모리는 전체 파라미터 기준	실제 실행 결과
llmfit	하드웨어 감지 + 내장 카탈로그 대조	받기 전에 순위를 확인	활성 파라미터로 계산	추정값, 실측 시 대체

llmfit은 빠르지만 정확하지 않을 수 있기에 대안으로 llm-checker도 함께 소개하고 있습니다. 다만, llmfit과 llm-checker는 MoE 모델에서 각 전문가 오프로딩 적용 여부에 따라 다소 달라질 수 있으니, 이를 감안하여 확인해야 합니다.

llmfit을 사용하면 좋을 사용자

GPU를 갖춘 Linux 환경이나 Apple Silicon 맥에서 여러 모델을 바꿔 가며 쓰는 사람에게 llmfit이 가장 잘 맞습니다. llmfit이 플랫폼 지원 문서에서 완전 지원으로 분류한 환경은 이 둘뿐이고, 대역폭 조회 표도 NVIDIA와 AMD, Apple Silicon 계열을 합쳐 약 80종을 담고 있어 표에 실린 카드라면 속도 추정이 백엔드 상수 대신 실제 대역폭을 근거로 나옵니다. GPU를 새로 사기 전에 후보 하드웨어에서 어떤 모델이 실행될지 미리 보고 싶은 경우에도 하드웨어 프로파일 기능이 그 용도에 맞습니다.

반대로 Windows나 Intel 맥에서 AMD 또는 Intel GPU를 쓰는 사람에게는 llmfit이 아직 적절한 선택지가 아닙니다. llmfit은 두 환경에서 RAM과 CPU 감지는 동작하지만 GPU 감지는 nvidia-smi가 설치된 NVIDIA 카드에 한정된다고 명시하고 있고, Android의 Termux와 PRoot 환경에서는 모바일 GPU가 아예 감지되지 않는다고 적어 두었습니다. 이 경우에는 --memory로 메모리를 직접 지정해 점수만 받아 보는 우회 경로가 남지만, llmfit 스스로 이것이 추천과 점수 계산용 임시 방편이라고 밝히고 있습니다.

llmfit의 동작 원리

llmfit이 모델 하나에 점수를 매기기까지는 하드웨어 감지에서 시작해 결과 출력까지 네 단계를 거칩니다. 전체 흐름은 다음과 같습니다:

하드웨어 감지와 모델 카탈로그

llmfit은 sysinfo로 전체 RAM과 가용 RAM, CPU 코어 수를 읽고, GPU는 벤더마다 다른 경로를 씁니다. NVIDIA는 nvidia-smi로 여러 장의 VRAM을 합산하고 보고에 실패하면 GPU 모델명에서 VRAM을 추정하며, AMD는 rocm-smi, Intel Arc는 외장이면 sysfs, 내장이면 lspci, Apple Silicon은 system_profiler로 통합 메모리를 읽습니다. Apple Silicon에서는 VRAM을 시스템 RAM과 같은 값으로 잡는데, 실제로 메모리 풀을 공유하기 때문입니다. 이 과정에서 가속 백엔드가 CUDA인지 Metal인지 ROCm인지도 함께 판별되며, 뒤에서 살펴볼 속도 추정이 이 값을 씁니다.

모델 목록은 Hugging Face API에서 모델 정보를 수집하는 scripts/scrape_hf_models.py가 만들어 llmfit-core/data/hf_models.json에 넣고, 이 파일은 컴파일 시점에 바이너리 안으로 들어갑니다. 여기서 실사용상 중요한 결과가 하나 따라옵니다. 모델 목록을 갱신하려면 llmfit 자체를 새 버전으로 올려야 한다는 것입니다. 수집기는 모델 설정의 num_local_experts와 num_experts_per_tok 값을 보고 MoE 구조를 자동으로 판별해 기록하며, 전체 목록은 저장소의 MODELS.md에 정리되어 있습니다.

동적 양자화 선택과 네 가지 차원 점수

llmfit은 양자화 포맷을 하나로 고정하지 않고 Q8_0에서 Q2_K까지 이어지는 계층을 위에서부터 차례로 확인하며, 가용 메모리에 들어가는 것 중 품질이 가장 좋은 단계를 고릅니다. 전체 컨텍스트 길이로는 아무것도 들어가지 않으면 컨텍스트를 절반으로 줄여 한 번 더 시도합니다. 이렇게 고른 조합을 놓고 모델마다 0에서 100 사이의 점수를 네 가지 차원으로 계산합니다:

차원	무엇을 재는가
품질(Quality)	파라미터 수, 모델 계열의 평판, 양자화 손실, 과제 정합도
속도(Speed)	백엔드와 파라미터 수, 양자화에 기반한 예상 초당 토큰 수
적합도(Fit)	메모리 활용 효율, 가용 메모리의 50~80% 구간이 가장 좋음
컨텍스트(Context)	용도가 요구하는 길이 대비 모델의 컨텍스트 창

네 점수는 가중 합산되어 하나의 종합 점수가 되는데, 가중치는 용도 카테고리마다 다릅니다. 예를 들어 Chat은 속도에 0.35를 주고 Reasoning은 품질에 0.55를 줍니다. 품질 차원 안의 과제 정합도는 공개된 코딩과 추론(reasoning), 대화 리더보드를 모아 만든 use_case_benchmarks.json 표를 참조하므로, --use-case coding으로 조회하면 파라미터가 더 적은 코딩 특화 모델이 덩치 큰 범용 모델보다 위에 올 수 있습니다. 표에 항목이 없는 계열에는 이름 기반 휴리스틱을 적용하며, llmfit 관리자는 이 표를 고치는 PR을 환영한다고 밝히고 있습니다.

속도 추정 공식

토큰 생성은 토큰 하나마다 모델 가중치 전체를 VRAM에서 한 번 읽어야 하므로 메모리 대역폭의 제약을 받습니다. llmfit은 GPU 모델명을 알아본 경우 그 카드의 실제 대역폭으로 처리량을 추정합니다:

(bandwidth_GB_s / model_size_GB) × efficiency_factor

기본 효율 계수는 0.55이며, 커널 오버헤드와 KV 캐시 읽기, 메모리 컨트롤러 효과를 감안한 값이라고 설명되어 있습니다. 이 계수와 실행 모드별 속도 배수는 TUI에서 A를 눌러 여는 고급 설정 창에서 바로 조정할 수 있고, 값을 바꾸면 표 전체가 다시 계산됩니다. 대역폭 조회 표는 NVIDIA 소비자용과 데이터센터용, AMD의 RDNA와 CDNA, Apple Silicon 계열을 합쳐 약 80종의 GPU를 담고 있습니다. 표에 없는 카드에는 아래 백엔드별 상수를 씁니다:

백엔드	속도 상수
CUDA	220
Metal	160
ROCm	180
SYCL	100
CPU (ARM)	90
CPU (x86)	70
NPU (Ascend)	390

MoE 모델은 전체 파라미터가 아니라 활성 파라미터를 기준으로 추정합니다. 예를 들어 Mixtral 8x7B는 총 46.7B 파라미터 중 토큰당 약 12.9B만 활성화되므로, 전문가 오프로딩을 적용하면 VRAM 요구량이 23.9GB에서 약 6.6GB로 내려갑니다. 아키텍처 메타데이터가 충분하면 양자화에 따라 크기가 변하는 전문가 피드포워드 신경망(FFN) 가중치와 그렇지 않은 어텐션 및 임베딩 가중치를 나눠 계산하고, 그렇지 않으면 아키텍처별 효율과 오버헤드 쌍으로 보정합니다. llmfit은 이 보정이 없을 때 전문가 수가 128개를 넘는 최신 희소 모델에서 오차가 크다고 밝히면서, gpt-oss-120b가 약 2.6배 낮게 추정되던 사례를 들고 있습니다.

프롬프트 처리 단계는 사정이 다릅니다. 프리필(Prefill)은 프롬프트 토큰당 대략 2 × active_parameters 만큼의 연산이 필요한 계산 병목 구간이라 메모리 대역폭으로는 설명되지 않습니다. 그래서 llmfit은 GPU의 fp16 연산 성능을 아는 경우에만 prefill_tps와 첫 토큰까지 걸리는 시간(TTFT)을 보고하고, 모르면 두 값을 null로 둡니다. llmfit은 이것이 0.0과 의도적으로 다른 값이라고 설명합니다. 0.0은 측정할 수 없을 만큼 느리다는 뜻으로 읽히지만 null은 추정하지 않았다는 뜻이기 때문입니다.

적합도 등급

메모리가 들어가느냐는 판정은 실행 모드의 메모리 풀을 얼마나 채우는지 하나로 결정됩니다:

풀 사용률	판정
60% 이하	Perfect
85% 이하	Good
98% 이하	Marginal
98% 초과	Too Tight

경계가 100%가 아니라 98%인 이유는 마지막 1%까지 채운 메모리 풀에는 할당자 여유나 단편화를 감당할 공간이 남지 않아 실제로 적재되지 않기 때문입니다. 여기에 실행 경로에 따른 상한이 하나 더 적용됩니다. GPU와 텐서 병렬 실행은 위 비율이 말하는 등급을 그대로 받지만, MoE 오프로딩과 CPU+GPU 분산, CPU 전용 실행은 Perfect 대신 Good을 최대 등급으로 받습니다. Perfect라는 표현이 여유 있게 들어가면서 동시에 GPU에서 돈다는 뜻이기 때문입니다. llmfit은 예전에 판정에 쓰던 recommended_ram_gb 휴리스틱을 제거한 이유도 함께 밝히고 있습니다. 24GB 카드에 23GB 모델을 적재해 풀을 96% 채우는데도 Perfect가 나오는 과대평가와, 16GB 카드에서 56%를 쓰는 9GB 모델이 Good에 그치는 과소평가가 같은 휴리스틱에서 동시에 나왔기 때문입니다.

llmfit이 추정과 실측을 구분하는 방법

앞에서 나온 속도 숫자는 모두 공식에서 나온 값입니다. 공식으로 계산한 값과 누군가 실제로 재본 값은 모두 tok/s라는 같은 단위로 표시되므로, llmfit은 각 결과에 estimate_confidence 등급을 붙여 둘을 구분합니다:

등급	의미
`measured_local`	이 컴퓨터에서 직접 `llmfit bench`로 측정한 값
`measured_community`	같은 하드웨어를 쓰는 다른 사용자가 측정한 값
`calibrated`	이 하드웨어에서 나온 측정값으로 보정한 공식 결과
`estimated`	측정 없이 공식만으로 계산한 값
`unsupported`	llmfit이 모델링할 수 없는 런타임이라 추정하지 않음

이 등급이 실제로 채워지려면 측정값이 필요하고, llmfit은 그 측정을 사용자에게서 모읍니다. llmfit bench는 실행 중인 런타임 제공자를 상대로 세 번의 실제 추론을 돌려 tok/s와 TTFT를 재고, 결과는 먼저 로컬에 저장됩니다. 여기에 --share를 붙이면 저장소를 포크하고 결과 파일을 커밋한 뒤 풀 리퀘스트까지 자동으로 엽니다. 이 과정에 gh CLI나 제3자 서비스 계정은 필요하지 않고, 인증은 GitHub 기기 흐름(Device Flow)으로 처리되며 GITHUB_TOKEN 환경변수가 있으면 브라우저 단계도 생략됩니다. 이렇게 모인 측정값은 TUI 안에서 바로 확인할 수 있습니다:

병합된 제출물은 다음 릴리스의 바이너리에 그대로 포함되므로, 같은 하드웨어를 쓰는 사람은 자기가 한 번도 벤치마크를 돌리지 않았어도 측정값을 먼저 보게 됩니다. TUI에서 b를 누르면 열리는 커뮤니티 리더보드가 그 결과를 모델별로 보여주고, H를 누르면 RTX 5090부터 Apple Silicon 계열과 AMD MI 시리즈까지 27종의 하드웨어 목록에서 다른 기기의 결과를 골라 볼 수 있습니다. 여기에 공개 벤치마크 데이터베이스인 localmaxxing.com의 결과가 보조 자료로 더해집니다. 값이 서로 어긋날 때 llmfit이 따르는 우선순위는 내가 직접 돌린 결과, 동일 하드웨어의 llmfit 커뮤니티 결과, localmaxxing 중앙값, 공식 추정값 순입니다.

llmfit의 하드웨어 시뮬레이션과 프로파일

llmfit은 지금 쓰는 컴퓨터가 아닌 다른 하드웨어를 기준으로 점수를 다시 매기는 경로를 두 가지 제공합니다. 첫 번째는 용량만 바꾸는 방식으로, TUI에서 S를 눌러 RAM과 VRAM, CPU 코어 수를 입력하면 표 전체가 즉시 다시 계산되고 상단에 SIM 배지가 표시됩니다. CLI에서는 --memory, --ram, --cpu-cores 옵션이 같은 일을 합니다:

두 번째는 기기 전체를 기술하는 하드웨어 프로파일입니다. 용량 옵션만으로는 그 기기에서 얼마나 빠른지에 답할 수 없는데, 속도 추정에는 메모리 대역폭이 필요하기 때문입니다. 프로파일은 대역폭과 통합 메모리 여부, fp16 연산 성능까지 담은 작은 JSON 파일이고, 저장소에 몇 가지가 기본으로 들어 있어 llmfit hardware list로 확인할 수 있습니다:

llmfit hardware list
llmfit --profile nvidia-rtx-4090 recommend --json
llmfit --profile apple-m3-max-128gb fit -n 10

직접 만든 프로파일도 llmfit hardware path가 알려주는 디렉토리에 두거나 파일 경로를 --profile에 바로 넘겨 쓸 수 있습니다. 다만 llmfit이 현재 한계로 밝힌 항목이 세 가지 있습니다. 프로파일의 calibration[] 항목은 저장만 되고 추정에 반영되지 않으며, --profile은 --force-runtime과 함께 쓸 수 없고, 지금 이 컴퓨터를 진단하는 llmfit doctor는 --profile을 거부합니다.

llmfit 설치와 사용

llmfit은 주요 패키지 관리자에 모두 올라가 있어 운영체제에 맞는 명령 하나로 설치할 수 있습니다:

# Windows
scoop install llmfit

# macOS / Linux (Homebrew, 미리 빌드된 바이너리)
brew install AlexsJones/llmfit/llmfit

# macOS (MacPorts)
port install llmfit

# 설치 스크립트
curl -fsSL https://llmfit.axjns.dev/install.sh | sh

# 파이썬 패키지로 설치하거나 설치 없이 실행
uv tool install -U llmfit
uvx llmfit

미리 빌드된 바이너리를 GitHub Releases 페이지에서 직접 내려받거나, 저장소를 복제해 cargo build --release로 빌드하는 경로도 있습니다.

설치한 뒤 인자 없이 실행하면 대화형 TUI가 열리고, 서브커맨드를 붙이면 전통적인 표 출력과 JSON 출력을 쓸 수 있습니다:

llmfit                        # 대화형 TUI
llmfit fit                    # 적합도 순으로 정렬한 전체 모델 표
llmfit recommend --json       # 상위 추천 모델을 JSON으로 출력
llmfit info "<model>"         # 모델 하나의 적합도와 추정 근거, 검증 명령
llmfit bench                  # 실행 중인 제공자를 상대로 실제 tok/s와 TTFT 측정
llmfit doctor                 # 버그 리포트에 첨부할 하드웨어 감지 보고서
llmfit serve                  # REST API와 웹 대시보드 실행

llmfit serve로 실행하는 HTTP API는 /health로 생존 여부를, /api/v1/system으로 노드의 하드웨어 정보를, /api/v1/models/top으로 그 노드에서 잘 돌아갈 상위 모델을 돌려줍니다. 여러 노드의 결과를 모아 스케줄링에 쓰라는 용도로 만들어진 경로이고, 컨테이너 이미지도 ghcr.io/alexsjones/llmfit으로 함께 배포됩니다.

여기서 미리 알아 둘 동작이 하나 있습니다. llmfit을 JSON 모드가 아닌 상태로 실행하면 웹 대시보드가 0.0.0.0:8787에서 자동으로 실행됩니다. 같은 네트워크의 다른 기기에서 브라우저로 열어 보라는 의도이지만, 공용 네트워크에서는 원하지 않는 노출이 될 수 있으므로 그럴 때는 --no-dashboard를 붙이거나 LLMFIT_DASHBOARD_HOST 환경변수로 바인딩 주소를 바꾸면 됩니다. llmfit은 이와 별개로 모델 내려받기나 런타임 조회, 커뮤니티 리더보드처럼 사용자가 해당 기능을 직접 쓸 때만 외부에 접속한다고 밝히고 있습니다.

Windows 바이너리를 쓴다면 코드 서명 조건도 확인하는 편이 좋습니다. llmfit은 SignPath.io를 통해 Windows 릴리스 바이너리에 Authenticode 서명을 붙이지만, 서명과 재패키징, 아티팩트 교체, 체크섬 업로드까지 포함한 sign-windows 작업이 전부 성공한 릴리스에만 서명이 적용됩니다. llmfit은 이 작업이 생략되거나 실패해도 서명 없는 아티팩트가 그대로 배포될 수 있으니 서명이 필요하면 직접 확인하라고 안내하고 있습니다.

llmfit의 라이선스

llmfit은 MIT 라이선스로 공개되어 있어 개인 및 상업적 목적으로 자유롭게 사용할 수 있습니다.

llmfit 공식 홈페이지 (설치 스크립트 안내 페이지)

llmfit의 점수 계산과 속도 추정 공식 문서

github.com/AlexsJones/llmfit

docs/how-it-works.md

main

# How llmfit Works

The scoring model, speed estimation, and the model database.

[← Back to README](../README.md)

## How it works

1. **Hardware detection** -- Reads total/available RAM via `sysinfo`, counts CPU cores, and probes for GPUs:
   - **NVIDIA** -- Multi-GPU support via `nvidia-smi`. Aggregates VRAM across all detected GPUs. Falls back to VRAM estimation from GPU model name if reporting fails.
   - **AMD** -- Detected via `rocm-smi`.
   - **Intel Arc** -- Discrete VRAM via sysfs, integrated via `lspci`.
   - **Apple Silicon** -- Unified memory via `system_profiler`. VRAM = system RAM.
   - **Ascend** -- Detected via `npu-smi`.
   - **Backend detection** -- Automatically identifies the acceleration backend (CUDA, Metal, ROCm, SYCL, CPU ARM, CPU x86, Ascend) for speed estimation.

2. **Model database** -- Hundreds models sourced from the HuggingFace API, stored in `llmfit-core/data/hf_models.json` and embedded at compile time. Memory requirements are computed from parameter counts across a quantization hierarchy (Q8_0 through Q2_K). VRAM is the primary constraint for GPU inference; system RAM is the fallback for CPU-only execution.

   **MoE support** -- Models with Mixture-of-Experts architectures (Mixtral, DeepSeek-V2/V3) are detected automatically. Only a subset of experts is active per token, so the effective VRAM requirement is much lower than total parameter count suggests. For example, Mixtral 8x7B has 46.7B total parameters but only activates ~12.9B per token, reducing VRAM from 23.9 GB to ~6.6 GB with expert offloading.

This file has been truncated. show original

llmfit 프로젝트 GitHub 저장소

더 읽어보기

이 글은 GPT 모델로 정리한 초안을 바탕으로 한 것으로, 원문의 내용 또는 의도와 다르게 정리된 내용이 있을 수 있습니다. 관심있는 내용이시라면 원문도 함께 참고해주세요! 읽으시면서 어색하거나 잘못된 내용을 발견하시면 댓글로 알려주시기를 부탁드립니다.

파이토치 한국 사용자 모임은 이런 글들을 한국어로 정리해 나누고 있습니다. 회원으로 가입하시면 주요 글들을 이메일로 보내드리고, 텔레그램(Telegram)과 Slack/Discord/Teams/Dooray/GoogleChat 등으로도 새 글 알림을 받으실 수 있습니다.

아래쪽에 좋아요를 눌러주시면 다음 글을 정리하는 데 힘이 됩니다~