llmfit – jak dobrać lokalny model LLM do sprzętu

Uruchamianie dużych modeli językowych lokalnie staje się coraz popularniejsze, ale dobór właściwego modelu do konkretnej konfiguracji sprzętowej nie jest trywialny. Narzędzie llmfit rozwiązuje ten problem, automatycznie analizując zasoby RAM, CPU i GPU oraz podpowiadając, które modele faktycznie uruchomią się sensownie na danym komputerze.

Co to jest llmfit i po co powstał?

llmfit to otwartoźródłowe narzędzie terminalowe (CLI + TUI), napisane głównie w Rust, które „right-sizuje” modele LLM do konkretnego sprzętu użytkownika. Jego głównym celem jest odpowiedź na praktyczne pytanie: które modele z Hugging Face i innych źródeł warto próbować uruchamiać lokalnie na danym PC, a które są po prostu za duże.

Narzędzie wykrywa parametry systemu (RAM, liczba rdzeni CPU, obecność i typ GPU, ilość VRAM), ładuje bazę metadanych modeli i wylicza kilka wskaźników jakościowych – m.in. dopasowanie do pamięci, szacowaną szybkość generacji, jakość oraz możliwości kontekstowe. Dzięki temu zamiast ręcznie zgadywać, czy np. Llama 3.1 8B w wersji Q4 będzie działać na laptopie z 16 GB RAM, można uruchomić llmfit i od razu zobaczyć ranking modeli oraz ich „fit” względem posiadanego sprzętu.

Instalacja i podstawowe sposoby uruchomienia

llmfit jest dystrybuowane w wielu formach: jako gotowe binaria, pakiet Python, kontener Docker oraz źródła kompilowane przez Cargo. Na Windows najprostsza instalacja odbywa się przez Scoop, na macOS i Linuksie – przez Homebrew lub szybki skrypt instalacyjny z curl, który pobiera najnowszy release i umieszcza binarium w katalogu systemowym lub w ~/.local/bin bez potrzeby użycia sudo.

Dostępna jest także integracja z uv/pip, gdzie llmfit funkcjonuje jako narzędzie Pythonowe, uruchamiane np. przez uvx bez stałej instalacji. Dla środowisk kontenerowych przewidziano obraz w rejestrze ghcr.io, który po uruchomieniu domyślnie wykonuje rekomendacje i wypisuje JSON, gotowy do dalszej obróbki np. narzędziem jq.

• Windows: scoop install llmfit – instalacja z repozytorium Scoop.
• macOS/Linux: brew install llmfit lub skrypt curl -fsSL ... | sh.
  
• Docker/Podman: docker run ghcr.io/alexsjones/llmfit z opcjonalną flagą --tui do uruchomienia interfejsu tekstowego.
• Kompilacja ze źródeł: cargo build --release po sklonowaniu repozytorium.

Interfejs TUI – serce llmfit

Domyślnym sposobem pracy jest interaktywny interfejs TUI, uruchamiany po prostu komendą llmfit. U góry ekranu wyświetlane są wykryte parametry systemu (CPU, RAM, nazwa GPU, ilość VRAM, wykryty backend), poniżej zaś przewijana lista modeli z punktacją i szacowanymi parametrami pracy.

Każdy wiersz zawiera m.in. nazwę modelu, łączny wynik (score), tok/s, najlepszą dobraną kwantyzację, tryb uruchomienia (GPU, CPU+GPU, CPU, MoE), procent wykorzystania pamięci, rozmiar kontekstu oraz kategorię zastosowania (chat, coding, reasoning itd.). Nawigacja jest inspirowana Vim-em – poruszanie się strzałkami lub klawiszami j/k, filtracja po dopasowaniu (f), sortowanie po kolumnach (s), wybór tematu kolorystycznego (t) oraz wejście w tryb planowania (p).

Plan Mode i symulacja sprzętu

Plan Mode odwraca typowe pytanie „co uruchomi się na moim sprzęcie?” na „jakiego sprzętu potrzebuję, żeby uruchomić ten konkretny model w wybranej konfiguracji?”. Po wciśnięciu p na wybranym wierszu można edytować m.in. docelową długość kontekstu, rodzaj kwantyzacji i docelowe tokens per second, a llmfit wyliczy wymagania minimalne oraz rekomendowane dla VRAM, RAM i liczby rdzeni CPU.

Tryb symulacji sprzętu (klawisz S) pozwala z kolei „zasymulować” inne konfiguracje – np. docelową stację roboczą z 48 GB VRAM lub serwer z 128 GB RAM – i zobaczyć, jak zmieni się lista modeli możliwych do uruchomienia. Zmiana wartości RAM, VRAM i liczby rdzeni jest natychmiast uwzględniana w rankingach oraz ocenach „fit”, a aktywną symulację oznacza widoczne oznaczenie SIM w pasku statusu.

Jak llmfit liczy „fit”, szybkość i jakość

Mechanika działania llmfit opiera się na kilku krokach: najpierw wykrywany jest sprzęt (RAM, CPU, GPU/VRAM, backend), następnie ładowana jest baza modeli z Hugging Face, a na koniec każdy model jest oceniany pod kątem pamięci, szybkości, jakości i kontekstu. Bazę stanowi wygenerowany skryptem plik JSON z setkami modeli różnych producentów – Meta Llama, Mistral, Qwen, Gemma, Phi, DeepSeek, Granite, OLMo, Grok i wielu innych – wraz z informacjami o liczbie parametrów, kontekście i dostępnych wariantach kwantyzacji.

Szybkość generacji jest przybliżana na bazie przepustowości pamięci GPU – w uproszczeniu tok/s ≈ (bandwidth w GB/s / rozmiar modelu w GB) × współczynnik efektywności, modyfikowany przez typ kwantyzacji i tryb uruchomienia. Dla nierozpoznanych GPU stosowane są stałe dla backendów (np. CUDA, Metal, ROCm, CPU x86/ARM), co pozwala zachować sensowne szacunki także w mniej typowych konfiguracjach.

Każdy z tych wymiarów jest przeskalowany do zakresu 0–100 i złożony w wynik łączny, przy czym waga poszczególnych składników zależy od zastosowania – dla czatu większy nacisk jest na szybkość, dla rozumowania na jakość. Modele, które nie są w ogóle uruchamialne (Too Tight), trafiają zawsze na dół listy, a użytkownik może filtrować widok tylko do poziomów Perfect/Good/Marginal.

Integracja z providerami: Ollama, llama.cpp, MLX, LM Studio

llmfit nie jest samodzielnym silnikiem inferencyjnym – zamiast tego integruje się z lokalnymi providerami, takimi jak Ollama, llama.cpp, MLX, Docker Model Runner oraz LM Studio. Wykrywa zainstalowane modele, potrafi je pobierać z poziomu TUI, oznacza zainstalowane pozycje specjalnym znacznikiem i dobiera rekomendacje pod kątem dostępnych backendów.

Dla Ollama używany jest domyślny endpoint HTTP, konfigurowany zmienną OLLAMA_HOST, co pozwala łączyć się z instancją działającą na innym serwerze w sieci lokalnej. W przypadku llama.cpp llmfit zarządza katalogiem GGUF, mapuje nazwy modeli z Hugging Face na właściwe pliki GGUF, a pobieranie odbywa się bezpośrednio z repozytoriów na Hugging Face.

• Ollama: wykrywanie przez /api/tags, pobieranie przez /api/pull, obsługa remote przez OLLAMA_HOST.
• llama.cpp: integracja z llama-cli/llama-server, mapowanie nazw, zarządzanie cache GGUF.
• MLX: specjalne wsparcie dla Apple Silicon, korzystanie z mlx-community repozytoriów.
• Docker Model Runner i LM Studio: integracja z ich własnymi API do listowania i pobierania modeli.

Community Leaderboard i Inference Bench

Jednym z ciekawszych elementów llmfit jest powiązanie szacunków teoretycznych z rzeczywistymi pomiarami społeczności. Widok Community Leaderboard (klawisz b) pokazuje dane z localmaxxing.com – realnie zmierzone tok/s, TTFT i użycie VRAM dla konkretnych modeli, backendów i konfiguracji GPU.

Użytkownik może wybrać profil sprzętu z listy kilkudziesięciu popularnych GPU (od RTX 5090 po M1/M4 i karty serwerowe) i porównywać liczby przed decyzją o zakupie lub modernizacji. Inference Bench (klawisz I) z kolei uruchamia lokalne benchmarki na rzeczywiście działających providerach użytkownika, zapisuje wyniki w cache i pozwala je wykorzystać zarówno w TUI, jak i poprzez subkomendę llmfit bench w CLI.

Webowy dashboard i REST API

Po uruchomieniu llmfit w trybie nie-JSON startuje w tle prosty webowy dashboard na porcie domyślnym 8787, dostępny przez przeglądarkę jako panel do eksploracji rekomendacji. Host i port można skonfigurować przez zmienne środowiskowe, a dashboard da się wyłączyć globalną flagą --no-dashboard.

Ten sam mechanizm serwera jest udostępniony jako jawna komenda llmfit serve, która wystawia REST API. Endpoints takie jak /api/v1/models czy /api/v1/models/top zwracają listę modeli wraz z filtrami po „fit”, użyciu, runtime, kontekście, co czyni llmfit praktycznym komponentem do budowy schedulerów w klastrach – np. podejmowania decyzji, jaki model uruchomić na danym węźle.

Zastosowania praktyczne dla użytkowników i zespołów

Dla pojedynczego użytkownika llmfit jest głównie narzędziem do świadomego wyboru lokalnego modelu – można w kilka minut sprawdzić, które modele do czatu, kodowania czy rozumowania są realistyczne na posiadanym laptopie czy desktopie. Zamiast godzin eksperymentów z pobieraniem zbyt dużych modeli, wszystko sprowadza się do przejrzenia tabeli, ustawienia filtra „Runnable” i wybrania topowych pozycji.

W większych środowiskach, szczególnie tam gdzie istnieje wiele serwerów GPU, llmfit może pełnić rolę elementu „planowania zasobów” – API serve pozwala włączyć go do pipeline’u orkiestracji agentów, a integracja z OpenClaw jako skill „llmfit-advisor” umożliwia agentom automatyczne dobieranie modeli do sprzętu. Dodatkowo, Plan Mode oraz symulacja sprzętu są przydatne przy planowaniu zakupów – można zwiększyć np. VRAM w symulacji i natychmiast zobaczyć, jakich nowych modeli nie da się uruchomić bez tej rozbudowy.

Warto także odnotować, że llmfit uwzględnia architektury Mixture-of-Experts, gdzie faktycznie aktywnych parametrów jest mniej niż całkowita liczba parametrów – np. dla Mixtral 8x7B realne wymagania VRAM są istotnie niższe niż wskazywałaby suma parametrów. Dzięki temu rekomendacje dla modeli takich jak DeepSeek V2/V3 czy Mixtral są bliższe realnym możliwościom sprzętu, niż proste szacowanie po „surowej” liczbie parametrów.

Źródła

• GitHub – AlexsJones/llmfit
• llmfit – oficjalna strona projektu
• Gigazine – opis działania llmfit z przykładami