LLM-y lokalnie na macOS: Ollama, LM Studio, MLX, llama.cpp

Viacheslav Dubrov

2025-05-10 · Zaktualizowano 2026-08-10 · 6 min · Inżynieria modeli · Narzędzia programistyczne

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Inżynierowie uruchamiający lokalne modele na Macu z Apple Silicon muszą oszacować cały workload, a nie tylko wybrać model, który da się pobrać. Apple Silicon może obsługiwać codzienne prompty bez zdalnego API, ponieważ CPU i GPU współdzielą ujednoliconą pulę pamięci, ale wagi modelu konkurują o nią z KV cache, obszarem roboczym runtime’u i systemem macOS.

Gdy docelowy model, kontekst i zapas pamięci mieszczą się w dostępnych zasobach, wybierz interfejs sterowania odpowiadający workflow: Ollama jako zarządzana usługa lokalna, LM Studio do inspekcji modeli na desktopie, llama.cpp do bezpośredniego uruchamiania GGUF albo MLX-LM do pracy z Pythonem natywnym dla Apple. Dzięki temu testowanie jakości modelu pozostaje oddzielone od wyboru narzędzia, a benchmark stosu, którego będziesz używać, uwzględnia rzeczywiste ograniczenia pamięci.

TL;DR. Użyj Ollama jako zarządzanej usługi lokalnej, LM Studio do eksplorowania modeli na desktopie i korzystania z lokalnych API, llama.cpp do bezpośredniej kontroli wykonywania GGUF, a MLX-LM do eksperymentów z Pythonem natywnym dla Apple. Żadne z tych narzędzi nie jest uniwersalnie najszybsze. Zbadaj benchmarkiem dokładny model, kwantyzację, kontekst i workload, pozostawiając zapas pamięci.

Zwięzłą tabelę decyzyjną znajdziesz w Local LLM Tools on macOS in 2026.

Zacznij od budżetu pamięci

Rozmiar skwantyzowanych wag to dopiero pierwszy składnik:

peak memory ≈ model weights
            + KV cache
            + runtime workspace
            + multimodal components
            + application and OS memory

Długość kontekstu, typ danych cache, liczba równoległych żądań i architektura modelu zmieniają wynik. Nominalnie czterobitowy model 7B lub 8B może nadal działać niekomfortowo na Macu z 8 GB pamięci, ponieważ system operacyjny nie może udostępnić runtime’owi całej zainstalowanej pamięci.

Podczas testów korzystaj z Monitora aktywności albo własnych metryk runtime’u. Apple definiuje presję pamięci na podstawie wolnej pamięci, szybkości użycia swapu, pamięci wired i plików w cache. Pozostaw wystarczający zapas, aby uniknąć ciągłego użycia swapu; model, który się ładuje, ale doprowadza system do presji pamięci, nie jest dobrym wyborem do interaktywnej pracy.

Rozdziel też lokalną inferencję od pracy offline. Prompty mogą pozostawać na komputerze, podczas gdy aplikacja nadal łączy się z siecią w celu pobierania modeli, aktualizacji lub obsługi opcjonalnych funkcji. Ollama opisuje lokalne wykonywanie, pobieranie modeli i opcjonalne funkcje chmurowe osobno w swoim FAQ. Traktuj pracę offline jako wymaganie workflow, które trzeba zweryfikować dla każdej aplikacji: najpierw pobierz artefakty, odłącz sieć i przetestuj kompletny workflow.

Cztery narzędzia rozwiązują różne problemy workflow

To tabela odpowiedzialności, a nie ranking szybkości. Kilka narzędzi może korzystać z powiązanych kerneli lub formatów, a wydajność zmienia się wraz ze wsparciem dla modeli i kolejnymi wydaniami.

Ollama: zarządzana usługa lokalna

Ollama zarządza pobieraniem modeli, szablonami, cyklem życia procesów i API na localhost. Jest przydatna, gdy kod aplikacji powinien korzystać ze stabilnej usługi lokalnej, zamiast samodzielnie zarządzać flagami inferencji.

MODEL=llama3.2
ollama pull "$MODEL"
ollama run "$MODEL" "Explain unified memory."

curl http://localhost:11434/api/chat \
    -H 'Content-Type: application/json' \
    -d '{
      "model": "'"$MODEL"'",
      "messages": [{"role": "user", "content": "Explain unified memory."}],
      "stream": false
    }'

Sprawdzaj manifest modelu i konfigurację kontekstu, zamiast zakładać, że krótka nazwa w bibliotece identyfikuje niezmienny checkpoint. Na potrzeby ewaluacji przypinaj dokładny artefakt albo go zapisuj.

Ollama poświęca część widoczności niskopoziomowej na rzecz wygody zarządzania cyklem życia. Przejdź do llama.cpp lub innego runtime’u, gdy potrzebujesz bezpośredniej kontroli nad plikiem GGUF, szablonem czatu, ustawieniem cache albo nową funkcją backendu.

LM Studio: eksploracja na desktopie i lokalne API

LM Studio jest przydatne, gdy wyszukiwanie modeli, konfiguracja ładowania, inspekcja rozmów i porównywanie modeli przez człowieka należą do jednego workflow. Obecnie udostępnia natywne SDKs dla Pythona i TypeScriptu, endpointy zgodne z OpenAI, ustrukturyzowane dane wyjściowe, korzystanie z narzędzi oraz bezgłowego daemona, więc nie jest już wyłącznie desktopowym GUI.

Bieżący Python SDK łączy się z wcześniej pobranym modelem:

import lmstudio as lms

MODEL_KEY = "ibm/granite-4-micro"

with lms.Client() as client:
    model = client.llm.model(MODEL_KEY)
    response = model.respond("Write one sentence about local inference.")
    print(response)

Uruchom lokalne API z karty Developer albo poleceniem:

lms server start

LM Studio może serwować na localhost lub w lokalnej sieci i obsługuje tokeny API w swoich ustawieniach uwierzytelniania API. Pozostaw usługę na loopbacku, chyba że zdalny dostęp jest zamierzony. Jeśli udostępniasz ją w sieci LAN, wymagaj udokumentowanej opcji tokenów API, zastosuj regułę zapory hosta i przejrzyj dostęp do narzędzi oraz integracji.

llama.cpp: bezpośrednie wykonywanie GGUF

llama.cpp jest właściwym wyborem referencyjnym, gdy artefaktem jest GGUF i chcesz bezpośrednio obserwować granicę runtime’u. Obsługuje Apple Metal, a także CPU i inne backendy sprzętowe.

brew install llama.cpp

# Download through the Hugging Face integration and select a quantization.
MODEL_REPO=ggml-org/gemma-3-1b-it-GGUF
QUANT=Q4_K_M
llama-cli -hf "$MODEL_REPO:$QUANT"

# Or start an OpenAI-compatible local server.
llama-server -hf "$MODEL_REPO:$QUANT"

Bieżąca ścieżka -hf w repozytorium może pobrać pasujący projektor multimodalny, jeśli jest dostępny. Wsparcie dla modeli, szablony i flagi CLI szybko się zmieniają, dlatego przypnij znaną wersję buildu i zachowaj polecenie uruchomieniowe razem z rekordem ewaluacji.

Wybierz llama.cpp, gdy celem jest bezpośrednia kontrola, a nie dlatego, że „niższy poziom” automatycznie oznacza większą szybkość. Zarządzane narzędzie może dobierać dobre wartości domyślne; bezpośrednie flagi również mogą pogorszyć wydajność.

MLX-LM: praca w Pythonie natywnym dla Apple

MLX-LM bazuje na tablicowym frameworku MLX firmy Apple. Obsługuje generowanie, czat, konwersję, kwantyzację i parameter-efficient fine-tuning dla zgodnych modeli.

MODEL=mlx-community/Llama-3.2-3B-Instruct-4bit
uv add mlx-lm
uv run mlx_lm.generate \
    --model "$MODEL" \
    --prompt "Explain Metal acceleration in one paragraph."

Python udostępnia model i tokenizer bezpośrednio:

from mlx_lm import generate, load

MODEL = "mlx-community/Llama-3.2-3B-Instruct-4bit"

model, tokenizer = load(MODEL)
messages = [{"role": "user", "content": "Give one local-LLM benchmark rule."}]
prompt = tokenizer.apply_chat_template(
    messages,
    tokenize=False,
    add_generation_prompt=True,
)
print(generate(model, tokenizer, prompt=prompt, max_tokens=80))

Serwer HTTP MLX-LM jest udokumentowany jako serwer deweloperski z podstawowymi kontrolami bezpieczeństwa, a nie jako usługa produkcyjna. Używaj go do lokalnych eksperymentów albo umieść przed nim zweryfikowaną granicę aplikacji.

Rzetelny benchmark zajmuje mniej czasu niż nieudane pobieranie

Testuj tę samą rodzinę checkpointów i porównywalną kwantyzację, jeśli formaty na to pozwalają. Użyj niewielkiego zestawu promptów zawierającego:

• jeden krótki prompt interaktywny
• jeden długi prompt zbliżony do docelowego kontekstu
• ustrukturyzowane dane wyjściowe lub wywołania narzędzi, jeśli aplikacja ich potrzebuje
• reprezentatywną długość generowania
• jedno powtórzone żądanie, aby odróżnić zimne ładowanie od ciepłej inferencji

Zapisuj:

Nie porównuj czterobitowego modelu w jednym narzędziu z modelem w pełnej precyzji w innym, a następnie nie przypisuj różnicy runtime’owi.

Lista kontrolna bezpieczeństwa i prywatności

1. Powiąż API z loopbackiem, chyba że dostęp sieciowy jest wymagany.
2. Jeśli dostęp LAN jest wymagany, użyj zapory hosta oraz uwierzytelniania udokumentowanego przez narzędzie albo uwierzytelnionego reverse proxy przed usługą. Obsługa tokenów API zależy od narzędzia: LM Studio dokumentuje tokeny API, natomiast udokumentowana ścieżka udostępniania Ollama korzysta z bindowania hosta i proxy.
3. Traktuj pliki modeli jako artefakty stron trzecich; zapisuj źródło, rewizję, licencję i hash.
4. Unikaj wykonywania niezweryfikowanego niestandardowego kodu modelu.
5. Sprawdź, czy opcjonalne funkcje dokumentów, narzędzi, aktualizacji lub analityki wykonują połączenia sieciowe.
6. Nie zakładaj, że lokalne generowanie sprawia, iż pobrane dokumenty, logi lub skutki uboczne narzędzi są bezpieczne.

Najważniejsze wnioski

1. Najpierw wybierz granicę workflow: zarządzana usługa, programowanie desktopowe i bezgłowe, bezpośrednia kontrola GGUF albo Python natywny dla Apple.
2. Zarówno Ollama, jak i LM Studio udostępniają lokalne API. Porównuj kontrolę cyklu życia, SDKs, ustrukturyzowane dane wyjściowe, narzędzia i widoczność runtime’u.
3. Wagi modelu stanowią tylko część budżetu pamięci. Uwzględnij KV cache, obszar roboczy, komponenty multimodalne, aplikację i zapas pamięci dla macOS.
4. Lokalna inferencja nie oznacza automatycznie pracy offline ani prywatności. Zweryfikuj połączenia sieciowe, bindowanie, uwierzytelnianie, artefakty, logi i skutki uboczne narzędzi.
5. Zanim przypiszesz wynik runtime’owi, zbadaj benchmarkiem to samo zadanie, tę samą rodzinę checkpointów, kontekst i porównywalną kwantyzację.

Materiały referencyjne

• Dokumentacja i kod źródłowy Ollama
• Dokumentacja deweloperska LM Studio oraz Python SDK
• Dokumentacja i kod źródłowy llama.cpp
• Dokumentacja i kod źródłowy MLX-LM
• Dokumentacja Apple MLX