llmfit은 사용자의 RAM, CPU, GPU/VRAM, 가속 백엔드를 감지한 뒤 Hugging Face 기반 모델 데이터베이스와 로컬 런타임 상태를 결합해 모델별 실행 가능성, 예상 속도, 메모리 적합도, 품질 점수를 계산하는 터미널 중심 도구다.
핵심 질문은 단순하다.
“이 모델이 내 장비에서 돌아가는가?”를 넘어 “어떤 양자화와 어떤 런타임으로 돌리는 것이 가장 현실적인가?”를 빠르게 판단하게 해준다.
캡션: 기본 TUI 화면은 자동 감지된 CPU·RAM·GPU 정보, 런타임 제공자 상태, 모델별 점수, 예상 tok/s, 권장 quant, 실행 모드, 메모리 사용률, fit 등급을 한 화면에서 비교하도록 설계되어 있다.
Quick Links
- GitHub Repository: https://github.com/AlexsJones/llmfit
- 공식 웹 문서: https://www.llmfit.org/
- Releases: https://github.com/AlexsJones/llmfit/releases
- API 문서: https://github.com/AlexsJones/llmfit/blob/main/API.md
- 모델 카탈로그: https://github.com/AlexsJones/llmfit/blob/main/MODELS.md
- Discussions: https://github.com/AlexsJones/llmfit/discussions
- 논문 링크: 저장소와 공식 문서 기준으로 별도 논문 링크는 확인되지 않았다.
- Wiki: 별도 GitHub Wiki 문서보다는 README, API.md, MODELS.md, AGENTS.md 중심으로 프로젝트 문서가 구성되어 있다.
Key Features
1. 하드웨어 인식 기반 LLM 추천
llmfit의 가장 큰 차별점은 모델 목록을 단순히 나열하지 않고, 현재 장비의 실행 가능성을 기준으로 모델을 재정렬한다는 점이다.
sysinfo로 RAM과 CPU를 읽고, NVIDIA는 nvidia-smi, AMD는 rocm-smi와 sysfs, Windows는 WMI, Apple Silicon은 system_profiler, Ascend는 npu-smi, 기타 환경은 Vulkan fallback 등을 통해 GPU와 가속 백엔드를 추정한다.
여러 GPU가 있을 때는 VRAM 정보를 집계하고, Apple Silicon이나 일부 APU처럼 unified memory를 쓰는 장비는 RAM과 VRAM의 관계를 별도로 처리한다.
기술적으로는 llmfit-core/src/hardware.rs의 SystemSpecs::detect()가 이 입력층을 담당한다.
이 감지 결과가 모델 피팅 계산의 기준점이 되므로, llmfit은 “모델 벤치마크 도구”라기보다 “하드웨어 제약 조건을 반영한 모델 라우터”에 가깝다.
2. TUI와 CLI를 모두 지원하는 비교 인터페이스
기본 실행은 TUI다. 모델 테이블에서 검색, provider 필터, use-case 필터, capability 필터, license 필터, runtime 필터, sort 기준 변경, 다중 선택 비교, 상세 보기, 다운로드, 로컬 provider refresh 등을 키보드로 수행할 수 있다.
블로그 독자 입장에서 중요한 점은 이 UI가 단순한 데모가 아니라 실제 의사결정 흐름을 압축한다는 점이다.
모델명, provider, parameter 수, score, tok/s, quant, mode, memory %, context, release date, fit, use-case가 한 화면에 함께 노출된다.
캡션: 모델별 “Score / tok/s / Quant / Mode / Mem% / Fit”을 함께 보여주기 때문에, 단순히 파라미터 수가 큰 모델보다 현재 장비에서 효율적인 모델을 우선 탐색할 수 있다.
CLI 모드도 제공된다. --cli, system, fit, search, recommend, plan 같은 명령을 통해 자동화 스크립트나 CI 환경에서 사용할 수 있고, --json 옵션으로 구조화된 결과를 받을 수 있다.
이 점은 agent나 내부 도구가 llmfit을 하위 의사결정 엔진으로 호출하기 쉽게 만든다.
3. 동적 양자화 선택과 다차원 점수화
llmfit은 모델이 “메모리에 들어가는가”만 보지 않는다.
모델별 parameter count, context length, quantization hierarchy, runtime path, GPU/CPU bandwidth 추정치를 조합한다.
fit.rs는 FitLevel, RunMode, InferenceRuntime, ScoreComponents를 통해 다음 요소를 함께 계산한다.
- 품질: 모델 계열, parameter 규모, quantization penalty, task alignment
- 속도: 예상 tokens/sec를 정규화한 speed score
- 적합도: 메모리 사용률과 실행 모드 기준 fit score
- context: 모델 context window와 추정 context cap
양자화 관점에서는 Q8_0부터 Q2_K 계열까지, Apple MLX 계열에서는 MLX용 quant 선택이 반영된다.
즉, llmfit의 추천은 “원본 모델”이 아니라 “현재 장비에서 실행 가능한 모델 구성”에 가깝다.
4. Hardware Simulation: 구매 전 장비 가정 실험
TUI의 S 키 또는 CLI의 override 옵션을 이용하면 RAM, VRAM, CPU core 수를 가정해 모델 적합도를 다시 계산할 수 있다.
이 기능은 GPU 구매, 연구실 워크스테이션 증설, 온프레미스 inference 서버 설계 때 유용하다.
예를 들어 “24GB VRAM이면 30B 모델을 어느 quant로 돌릴 수 있는가?”, “64GB unified memory 장비와 128GB unified memory 장비의 차이가 무엇인가?” 같은 질문을 실제 모델 목록 기준으로 탐색할 수 있다.
캡션: Hardware Simulation 팝업은 RAM, VRAM, CPU core 값을 임의로 바꾸고, 그 즉시 모델별 fit 등급과 예상 성능을 재계산한다. Apple Silicon처럼 unified memory 환경에서는 RAM 변경이 VRAM 추정에도 영향을 준다.
5. 로컬 런타임 provider 연동과 모델 다운로드 흐름
llmfit은 Ollama, llama.cpp, MLX, Docker Model Runner, LM Studio 같은 로컬 provider를 인식한다.
provider가 감지되면 설치된 모델, 다운로드 가능 여부, provider별 호환성을 테이블에 반영한다.
TUI에서 d를 누르면 모델 다운로드 provider picker가 열리고, D로 다운로드 관리자와 히스토리를 확인할 수 있다.
이 구조는 “추천”과 “실행 준비” 사이의 간격을 줄인다.
특히 MLX는 Apple Silicon 환경의 캐시와 모델 mapping을, llama.cpp는 GGUF 다운로드와 Hugging Face cache 감지를, LM Studio는 로컬 REST API 기반 모델 관리와 연결된다.
6. Community Leaderboard와 실제 inference benchmark
예상 속도는 언제나 근사치다.
llmfit은 이 한계를 줄이기 위해 community leaderboard와 inference benchmark view를 제공한다.
README 기준으로 b 키는 community benchmark를 열어 실제 사용자들의 tok/s, TTFT, VRAM 사용량을 보여주며, hardware preset을 바꿔 장비별 측정치를 비교할 수 있다.
I 키는 로컬 모델에 대한 inference bench view로 연결된다.
캡션: Community Leaderboard 화면은 RTX 4090, RTX 5090, Apple M 계열 등 hardware preset별 실제 측정값을 보여준다. 추정 tok/s와 실제 벤치마크 사이의 차이를 보정하는 데 쓰인다.
7. REST API, JSON 출력, MCP/OpenClaw agent skill
llmfit serve는 REST API를 제공하고, recommend --json은 agent나 외부 스크립트가 읽기 쉬운 추천 결과를 반환한다.
저장소에는 skills/llmfit-advisor도 포함되어 있어 OpenClaw 같은 autonomous agent 환경에서 “현재 장비에 맞는 모델을 고르라”는 작업을 자동화할 수 있다.
이 기능은 단순한 편의 기능이 아니라, 로컬 LLM 운영에서 모델 선택을 동적으로 만들기 위한 기반이다.
agent가 하드웨어 상태와 모델 요구량을 읽고, 실행 가능한 모델을 골라 provider에 다운로드하거나 serving 계획을 세울 수 있기 때문이다.
Tech Stack
| 영역 | 기술 / 버전 | 역할 |
|---|---|---|
| Core language | Rust 2024 edition | 하드웨어 감지, 모델 DB 로딩, fit 계산, provider 연동의 핵심 구현 |
| Workspace | llmfit-core, llmfit-tui, llmfit-desktop / version 0.9.28 |
core library, CLI/TUI binary, Tauri desktop app으로 분리 |
| CLI | clap 4.6 |
명령행 인자, subcommand, 환경변수 기반 옵션 처리 |
| TUI | ratatui 0.30, crossterm 0.29 |
터미널 렌더링, 키보드 이벤트, Vim-like interaction |
| Serialization | serde 1.0, serde_json 1.0, serde_yml 0.0 |
모델 DB, JSON output, API 응답 직렬화 |
| System detection | sysinfo 0.38, which 8.0.2, platform commands |
RAM/CPU 감지, GPU 도구 탐색, backend 추론 |
| HTTP/API | ureq 3.2, axum 0.8, tokio 1.52 |
provider API 통신과 REST server 구현 |
| Table/terminal utility | tabled 0.20, colored 3.1, csv 1.4 |
CLI 테이블 렌더링과 CSV/색상 출력 |
| Agent/MCP | rmcp 1.6, optional async-nats 0.48 |
agent-facing server/tool integration 확장 |
| Web dashboard | React ^18.2.0, Vite ^5.4.12, Vitest ^2.1.8 |
웹 대시보드 UI와 테스트 환경 |
| Desktop | Tauri 2 |
macOS 중심 desktop application |
| Python package | Python >=3.8, Hatchling |
uvx llmfit, pip/uv 기반 배포 wrapper |
버전 관점에서 현재 release page와 workspace metadata는 0.9.28을 가리킨다. README의 일부 기능 설명과 AGENTS.md의 모델 수 설명은 시간차가 있을 수 있으므로, 모델 수·릴리스·provider 변화는 release page와 최신 README를 기준으로 확인하는 것이 안전하다.
Architecture
캡션: 저장소에는 별도 아키텍처 이미지 자산이 없어서, README, AGENTS.md, llmfit-core 모듈 구조를 기반으로 분석용 아키텍처 다이어그램을 작성했다. 핵심 흐름은 hardware probe와 model DB를 llmfit-core가 결합하고, TUI/CLI/API/provider/agent interface로 결과를 내보내는 구조다.
llmfit의 구조는 크게 네 층으로 이해할 수 있다.
1. 입력층: 하드웨어, 모델 데이터베이스, provider 상태
입력층은 세 종류의 신호를 수집한다.
첫째, 현재 장비의 RAM, CPU, GPU, VRAM, backend를 감지한다.
둘째, data/hf_models.json에 포함된 모델 메타데이터를 읽는다.
README 기준 이 모델 DB는 Hugging Face API 기반으로 수집되어 compile time에 embedded 된다.
셋째, Ollama, llama.cpp, MLX, Docker Model Runner, LM Studio 등 로컬 provider의 설치/캐시/다운로드 상태를 읽는다.
2. Core fitting engine: llmfit-core
핵심 계산은 llmfit-core에 모여 있다.
llmfit-core/
src/
hardware.rs # SystemSpecs, GPU/backend 감지
models.rs # LlmModel, ModelDatabase, quantization hierarchy
fit.rs # FitLevel, RunMode, runtime 선택, score, TPS 추정
plan.rs # 선택 모델 기준 hardware planning
providers.rs # Ollama, llama.cpp, MLX, LM Studio 등 provider 연결
bench.rs # inference benchmark 관련 로직
quality.rs # 품질 점수 보조 로직
update.rs # 모델 DB 업데이트 관련 로직
이 엔진은 모델별로 다음 순서의 판단을 수행한다.
- 현재 장비와 모델 요구량을 비교한다.
- 가능한 quantization 후보를 탐색한다.
- GPU, tensor parallel, MoE offload, CPU offload, CPU-only 같은 실행 경로를 고른다.
- llama.cpp, MLX, vLLM 같은 runtime을 선택하거나 override한다.
- 예상 memory usage, tok/s, fit level, weighted score를 계산한다.
- TUI/CLI/API가 읽을 수 있는
ModelFit형태로 결과를 반환한다.
3. Presentation layer: TUI, CLI, web, desktop
llmfit-tui는 ratatui와 crossterm을 사용해 터미널 UI를 만든다.
tui_app.rs는 state와 filter를, tui_ui.rs는 rendering을, tui_events.rs는 keyboard event mutation을 맡는다.
CLI path는 display.rs를 통해 classic table과 JSON output을 만든다.
웹 대시보드는 React/Vite, 데스크톱 앱은 Tauri 2 기반이다.
4. Automation layer: REST API와 agent-facing integration
serve 명령은 REST API를 열어 시스템 정보, 모델 목록, top models, 추천 결과를 외부에서 조회하게 한다.
recommend --json은 agent가 바로 파싱할 수 있는 형태라서, 다른 orchestration 도구와 연결하기 쉽다.
skills/llmfit-advisor는 OpenClaw용 hardware-aware model recommendation skill로, autonomous agent가 자체적으로 모델 선택을 수행하도록 돕는 역할을 한다.
Usage & Setup
설치
Windows에서는 Scoop을 사용한다.
scoop install llmfit
macOS와 Linux에서는 Homebrew, MacPorts, quick install script를 사용할 수 있다.
# Homebrew tap: prebuilt binary 중심
brew install AlexsJones/llmfit/llmfit
# homebrew-core formula
brew install llmfit
# MacPorts
port install llmfit
# Quick install
curl -fsSL https://llmfit.axjns.dev/install.sh | sh
# sudo 없이 ~/.local/bin 설치
curl -fsSL https://llmfit.axjns.dev/install.sh | sh -s -- --local
Python 도구 체인에서는 uv 또는 pip 흐름으로 설치할 수 있다.
# 설치 또는 업데이트
uv tool install -U llmfit
# 설치 없이 실행
uvx llmfit
컨테이너 실행도 가능하다.
docker run ghcr.io/alexsjones/llmfit
podman run ghcr.io/alexsjones/llmfit recommend --use-case coding | jq '.models[].name'
소스에서 직접 빌드하려면 Rust toolchain이 필요하다.
git clone https://github.com/AlexsJones/llmfit.git
cd llmfit
cargo build --release
# binary: target/release/llmfit기본 실행
# TUI 실행: 기본 모드
llmfit
# classic CLI table
llmfit --cli
# 시스템 사양 확인
llmfit system
llmfit --json system
# 모델 검색
llmfit search "llama 8b"
# 잘 맞는 모델 상위 5개
llmfit fit --perfect -n 5
# use-case 기준 추천 JSON
llmfit recommend --json --use-case coding --limit 3하드웨어 시뮬레이션과 context cap
# 24GB VRAM, 64GB RAM, 8 core CPU로 가정
llmfit --memory=24G --ram=64G --cpu-cores=8 fit
# TUI에도 동일 override 적용
llmfit --memory=24G --cli
# context length를 8192로 제한해 memory fit 추정
llmfit --max-context 8192 fit --perfect -n 5
llmfit --max-context 16384 recommend --json --limit 5REST API server
llmfit serve --host 0.0.0.0 --port 8787
curl http://localhost:8787/api/v1/system
curl "http://localhost:8787/api/v1/models/top?limit=5&min_fit=good&use_case=coding"
이 API는 내부 대시보드, agent workflow, 로컬 LLM 라우터에서 “현재 장비 기준으로 어떤 모델을 선택해야 하는가”를 자동화하는 데 사용할 수 있다.
Personal Insights
의료 AI 관점
의료 AI 환경에서는 모델 성능만큼 배포 제약이 중요하다.
병원 내부망, 폐쇄망, 연구용 GPU 서버, 개인 건강정보(PHI) 처리 환경에서는 cloud API보다 local inference가 필요한 경우가 많다.
llmfit은 어떤 모델이 특정 장비에서 실행 가능한지, 어느 quantization으로 타협해야 하는지, CPU offload가 필요한지 빠르게 가려낼 수 있다.
다만 fit score는 임상적 유효성이나 의료 정확도를 의미하지 않는다.
의료 QA, 임상 문서 요약, 영상 판독 보조, 약물 안전성 검토 같은 용도에서는 별도 validation dataset, hallucination 평가, 규제 검토, human-in-the-loop workflow가 필수다.
llmfit의 가치는 의료 모델의 “정확도 평가”가 아니라 “실행 가능성과 운영 비용을 줄이는 사전 필터”에 있다.
Bioinformatics 관점
Bioinformatics workflow는 대형 GPU 서버와 연구실 워크스테이션이 혼재하는 경우가 많다.
LLM은 pipeline 문서화, Snakemake/Nextflow 오류 해석, variant annotation 보조, 논문 triage, multi-omics 결과 설명 등에 쓰일 수 있지만, 실제로는 context length와 메모리 한계가 자주 병목이 된다.
llmfit의 context cap, model fit, use-case filtering은 bioinformatics 연구자가 장비별로 “코딩 보조에 적합한 모델”, “긴 문서 요약에 유리한 모델”, “작은 GPU에서도 돌아가는 모델”을 분리하는 데 도움이 된다.
특히 JSON output과 REST API는 HPC scheduler나 내부 포털에서 노드별 LLM 추천을 자동화하는 기반이 될 수 있다.
Autonomous Agent 개발 관점
Agent는 스스로 도구를 선택해야 한다.
그런데 local LLM agent에서 모델 선택은 대부분 정적으로 고정된다. llmfit은 이 부분을 동적으로 바꾼다.
agent가 llmfit recommend --json 또는 REST API를 호출해 현재 장비, provider 상태, 모델 fit, 예상 tok/s를 읽고, 그 결과에 따라 모델을 다운로드하거나 backend를 선택할 수 있다.
OpenClaw skill과 MCP 관련 의존성은 이 방향성을 잘 보여준다.
llmfit은 autonomous agent에게 “로컬 하드웨어 상태를 해석하고 실행 가능한 LLM을 고르는 perception/planning tool”로 쓰일 수 있다.
장기적으로는 agent가 작업 난이도, latency budget, context length 요구량, provider availability를 기반으로 모델 라우팅을 수행하는 구조와 잘 맞는다.
한계와 주의점
llmfit의 예상 tok/s는 하드웨어 bandwidth와 모델 크기 기반 추정치이므로 실제 throughput과 다를 수 있다.
Community Leaderboard와 local benchmark view가 이 간극을 줄여주지만, production deployment 전에는 직접 벤치마크가 필요하다.
또한 provider API, Hugging Face model naming, GGUF/MLX mapping은 빠르게 변할 수 있으므로 최신 release와 changelog를 확인해야 한다.
의료·바이오 영역에서는 “실행 가능성”과 “도메인 신뢰성”을 분리해야 한다.
llmfit이 잘 맞는 모델을 골라주더라도, 해당 모델이 임상적으로 안전하거나 생물정보학적 해석을 정확히 수행한다는 뜻은 아니다.
이 도구는 모델 운영의 첫 번째 필터로 사용하고, domain-specific benchmark와 감사 가능한 평가 체계를 반드시 별도로 두는 것이 바람직하다.
'AI 생성 글 정리 > tech_github' 카테고리의 다른 글
| MarkItDown — LLM을 위한 범용 파일→Markdown 변환 엔진 (0) | 2026.05.27 |
|---|---|
| Understand Anything — 코드베이스를 “배우는” 인터랙티브 지식 그래프로 바꾸는 멀티 에이전트 플러그인 (0) | 2026.05.27 |
| K9s: Kubernetes 운영을 터미널에서 빠르게 탐색·관찰·조작하는 TUI (0) | 2026.05.27 |
| CodeGraph — AI 코딩 에이전트를 위한 로컬 코드 지식 그래프 (0) | 2026.05.27 |
| Beszel — 가벼운 self-hosted 서버 모니터링 허브와 에이전트 (0) | 2026.05.27 |
