llama.cpp 0.8.0: nowe modele, głos w czasie rzeczywistym i lokalne funkcje AI

llama.cpp v0.8.0 to istotna aktualizacja lokalnej AI, zwłaszcza wnioskowania multimodalnego. Wydana 28 października 2026 r. wprowadza obsługę rodziny LFM3 firmy Liquid AI, nowych architektur modeli, w tym DeepSeek V4.1 Flash, oraz eksperymentalne możliwości przetwarzania dźwięku w czasie rzeczywistym za pośrednictwem /v1/realtime i syntezę mowy za pośrednictwem POST /tts. Ulepszono również zarządzanie modelami, narzędzia serwera i kilka ścieżek zarządzania pamięcią. Nie oznacza to jednak, że każda nowo wymieniona architektura lub procedura przetwarzania dźwięku jest gotowa do produkcyjnego użycia na każdym urządzeniu.

W przypadku serwera domowego najprzydatniej jest najpierw przypiąć wersję, uruchomić jeden sprawdzony model GGUF, odnotować szczytowe zużycie pamięci i opóźnienie oraz zadbać o prywatność API. Dopiero potem warto testować wizję lub dźwięk. Nowy punkt końcowy serwera nie zastępuje zgodnego modelu mowy, interfejsu multimedialnego, toru mikrofonowego, kontroli dostępu ani odpowiedniej mocy GPU/CPU.

Co tak naprawdę nowego w llama.cpp 0.8.0?

Oficjalne informacje o wydaniu v0.8.0 grupują zmiany w kategorie: zgodność modeli, multimodalność, aktualizacje API i serwera, zarządzanie pamięcią podstawową oraz optymalizacje backendu. Najlepiej zrozumieć to wydanie, oddzielając funkcje dostępne od razu dla użytkowników lokalnych od zaawansowanych funkcji wymagających określonego sprzętu lub nowego kodu integracyjnego.

Wyjaśnienie aktualizacji DeepSeek V4.1 Flash pomaga odróżnić aktualizację modelu od możliwości załadowania modelu przez środowisko uruchomieniowe. Informacja o „obsłudze” w informacjach o wydaniu nie gwarantuje konkretnej kwantyzacji, konfiguracji GPU ani jakości działania w czasie rzeczywistym.

Jak działa głos w czasie rzeczywistym i zamiana tekstu na mowę w tym wydaniu?

Wcześniej wiele domowych asystentów głosowych łączyło osobne komponenty: przechwytywanie dźwięku z mikrofonu, zamianę mowy na tekst, zapytanie do LLM i syntezę mowy. Wersja 0.8.0 wprowadza eksperymentalną ścieżkę strumieniowego przesyłania przychodzącego audio w interfejsie multimodalnym (mtmd) i udostępnia punkt końcowy serwera czasu rzeczywistego korzystający z protokołu realtime w stylu OpenAI. Serwer ma też osobny punkt końcowy POST /tts dla kompatybilnych modeli.

To odrębne możliwości. /v1/realtime to punkt wejścia dla procesów konwersacji lub transkrypcji z przesyłaniem strumieniowym audio; /tts generuje mowę z tekstu za pomocą kompatybilnego modelu mowy. Żaden z tych punktów sam w sobie nie tworzy asystenta stale nasłuchującego ani nie gwarantuje konkretnego języka, opóźnienia całej wymiany, formatu wyjściowego audio czy integracji z platformą bez przetestowania danego checkpointu.

W praktycznym teście audio sprawdź uprawnienia do mikrofonu, częstotliwość próbkowania, konwersję kodeka, obsługę niepełnych ramek, wykrywanie końca wypowiedzi, anulowanie i obsługę limitu czasu sieci. Nagrania audio i transkrypcje przechowuj zgodnie z jasno określoną polityką retencji. Jeśli aplikacja użytkownika działa na innym komputerze, wnioskowanie na serwerze NAS nie oznacza, że dźwięk nigdy nie przechodzi przez sieć.

Dlaczego zmiany dotyczące pamięci i MoE mają znaczenie?

W wersji v0.8.0 wprowadzono dzieloną w proporcji 50/50 pamięć podręczną SLRU (segmented LRU) dla wag modeli typu mixture-of-experts przechowywanych w pamięci hosta. Celem jest lepsza obsługa ekspertów o różnych wzorcach ponownego użycia; rzeczywiste korzyści zależą od routingu ekspertów, rozkładu promptów i rezydencji w pamięci. W przypadku zwykłych, małych i gęstych modeli ta zmiana może mieć niewielki lub żaden wpływ.

Przebudowano też przetwarzanie z rzadką uwagą, a wydanie zawiera ulepszoną obsługę no_alloc, nowe operacje ggml i optymalizacje backendu. Mogą one wpływać na alokację pamięci lub przepustowość, ale nie zmieniają podstawowego równania dla obsługi modeli: zapotrzebowanie wag na pamięć + bufory środowiska uruchomieniowego + stan KV/kontekstu + tensory multimodalne + współbieżność + zapas zasobów na potrzeby systemu.

Model klasy 2B w kwantyzacji 4-bitowej może z łatwością działać tam, gdzie większy checkpoint się nie zmieści. Mimo to obsługa dłuższych promptów i wielu klientów może przeciążyć mały NAS. Nasz przewodnik po kierowaniu modeli według zapotrzebowania na pamięć wyjaśnia, dlaczego przy planowaniu zasobów należy uwzględniać całkowite szczytowe zużycie pamięci, a nie tylko rozmiar pobieranego pliku GGUF. Analiza ograniczeń wdrażania Kimi K3 pokazuje skrajnie odmienny przypadek: funkcje środowiska uruchomieniowego nie sprawią, że checkpoint z bilionem parametrów zmieści się w pamięci sprzętu konsumenckiego.

Które nowe modele można faktycznie wypróbować lokalnie?

Jeśli chcesz szybko przeprowadzić lokalny eksperyment z pomiarami, LFM3-1.7B GGUF będzie lepszym punktem wyjścia niż nietestowany, duży checkpoint multimodalny. Na oficjalnej karcie GGUF opisano zgodne użycie z llama.cpp. Sięgnij po LFM3-VL-2B, gdy potrzebujesz obsługi obrazów lub wideo, i przetestuj właściwy projektor oraz przetwarzanie wstępne. Obsługa audio i trybu omni wymaga osobnych integracji dostosowanych do danego modelu.

Więcej porównań lokalnych modeli pod względem rozmiaru i kwantyzacji znajdziesz w naszym przewodniku po modelach AI dla sprzętu konsumenckiego. Jeśli korzystasz ze sklepu z aplikacjami ZimaOS, wymagania sprzętowe Ollama przedstawiają inną opcję wdrożenia; pakiet Ollama i funkcje projektu llama.cpp nie są zamiennymi gwarancjami.

Jak zainstalować i zweryfikować llama.cpp v0.8.0 w systemie Linux?

Poniższy przepis służy do weryfikacji kompilacji ze źródeł, a nie stanowi niepotwierdzonego twierdzenia, że v0.8.0 jest już dostępne w sklepie z aplikacjami ZimaOS. Kompiluje serwer obsługujący CPU, przypina konkretny tag dla powtarzalności, korzysta z udokumentowanego modelu LFM3 GGUF i nasłuchuje wyłącznie na interfejsie loopback:

git clone https://github.com/ggml-org/llama.cpp.git
cd llama.cpp
git checkout v0.8.0
cmake -S . -B build
cmake --build build --config Release -j --target llama-server
./build/bin/llama-server \
  -hf LiquidAI/LFM3-1.7B-GGUF:Q4_K_M \
  -c 4096 --host 127.0.0.1 --port 8080

W drugim terminalu na tym samym hoście sprawdź, czy serwer rzeczywiście załadował model:

curl -s http://127.0.0.1:8080/v1/models
curl -s http://127.0.0.1:8080/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"local","messages":[{"role":"user","content":"Wymień dwie zalety lokalnego modelu GGUF."}],"max_tokens":128}'

W razie potrzeby zastąp "local" dokładnym identyfikatorem modelu zwróconym przez /v1/models. W aktualnym użyciu CLI ta wersja wyraźnie wymaga argumentu modelu (--model lub -hf), więc stary skrypt uruchamiający, który nie zawiera żadnego z nich, może przestać działać. Informacje o obsługiwanych opcjach backendu CUDA, Vulkan, Metal i innych znajdziesz w instrukcjach kompilacji projektu źródłowego. Nie udostępniaj publicznie portu 8080, dopóki nie skonfigurujesz uwierzytelniania, TLS, limitów i granic zaufania dla klientów.

Na domowym serwerze opartym na kontenerach potrzebujesz również trwałego miejsca na modele, limitów zasobów, zgodności z możliwościami procesora CPU/GPU oraz sprawdzonego mapowania punktów montowania. Najlepszym kolejnym źródłem informacji jest wdrażanie lokalnego LLM bez zakłócania działania aplikacji NAS; zapoznaj się z nim, zanim przeniesiesz pobieranie modeli na współdzielony dysk rozruchowy.

Co należy przetestować przed modernizacją istniejącego serwera AI?

Bogata w funkcje aktualizacja upstream może zmienić działanie nawet wtedy, gdy serwer uruchamia się bez błędów. Zachowaj bieżący plik binarny lub obraz kontenera, skrót modelu, poprzednie flagi i co najmniej jedną poprawną odpowiedź jako punkt odniesienia na wypadek przywracania poprzedniej wersji. Następnie przeprowadź niewielki zestaw testów regresji:

1. Zgodność: zanotuj tag, nazwę pliku GGUF, sumę kontrolną, backend i szablon czatu; sprawdź ostrzeżenia podczas uruchamiania.
2. Opóźnienia: uruchom te same krótkie i długie prompty w obu wersjach i zanotuj czas przetwarzania wejścia, szybkość dekodowania oraz opóźnienie na poziomie 95. percentyla, nie zmieniając modelu ani kontekstu.
3. Pamięć: zanotuj szczytowe zużycie RAM hosta i VRAM, zachowanie przy zwalnianiu modelu z pamięci, obsługę równoczesnych żądań oraz to, czy inne aplikacje NAS nadal działają płynnie.
4. Audio: jeśli te funkcje są istotne, osobno sprawdź cykl życia połączenia w czasie rzeczywistym, transkrypcje, wynik TTS, anulowanie i ponowne nawiązywanie połączenia.
5. Bezpieczeństwo i przywracanie: sprawdź powiązanie z siecią, uprawnienia do plików, trwałe ścieżki, zachowanie po ponownym uruchomieniu oraz możliwość powrotu do poprzedniego pliku binarnego.

Skorzystaj z naszej listy kontrolnej weryfikacji ścieżek do plików modeli oraz omówienia oddzielania stanu środowiska uruchomieniowego od wag modeli. Jest to szczególnie ważne, gdy przeglądarka modeli ułatwia pobieranie: wygoda pobierania nie zastępuje sprawdzenia, gdzie faktycznie zapisano kilka gigabajtów danych.

FAQ

Czy llama.cpp v0.8.0 to to samo co LFM3?

Nie. llama.cpp to środowisko uruchomieniowe do inferencji. LFM3 to rodzina punktów kontrolnych modeli firmy Liquid AI. Wersja v0.8.0 dodaje obsługę integracji z LFM3, ale pliki modeli nadal trzeba wybrać i pobrać osobno.

Czy llama.cpp v0.8.0 pozwala rozmawiać w czasie rzeczywistym z dowolnym modelem GGUF?

Nie. Nowe ścieżki obsługi audio są eksperymentalne, a ich działanie zależy od modelu. Model obsługujący tylko tekst nie zyskuje możliwości przyjmowania i generowania mowy tylko dlatego, że serwer udostępnia /v1/realtime lub /tts.

Czy /v1/realtime to gotowy do produkcyjnego użycia interfejs API głosowy?

Przyjmij, że w momencie wydania funkcja ma charakter eksperymentalny. Przed uruchomieniem usługi bez nadzoru przetestuj wybrany model, kodowanie audio, zgodność z klientem, działanie funkcji przerywania oraz stabilność podczas oczekiwanych sesji.

Czy aktualizacja zmniejszy zużycie VRAM przez wszystkie moje modele?

Niekoniecznie. Zmiany w obsłudze pamięci i backendach mogą poprawić wydajność w określonych zastosowaniach, ale zapotrzebowanie na VRAM i RAM zależy od wag modelu, kontekstu, kwantyzacji, backendu urządzenia i liczby żądań. Przetestuj dokładnie swoją konfigurację, zamiast wyciągać wnioski na podstawie informacji o wydaniu.

Czy do uruchomienia llama.cpp potrzebuję karty NVIDIA?

Nie. Obsługuje wnioskowanie na CPU i wiele backendów GPU. Wydajność wyłącznie na CPU może być wystarczająca dla małych modeli, ale może być znacznie niższa niż przy dobrze dopasowanym przyspieszeniu. Najpierw sprawdź dostępną pamięć RAM i rozmiar modelu, a następnie wybierz backend.

Czy mogę zainstalować v0.8.0 bezpośrednio ze sklepu ZimaOS App Store?

Ten artykuł nie potwierdza wersji pakietu w ZimaOS App Store ani nie zawiera oficjalnej instalacji jednym kliknięciem. Przewodnik opisuje kompilację z przypiętej wersji kodu źródłowego projektu dla systemu Linux i podaje testy, które możesz dostosować do swojego sprzętu lub środowiska kontenerowego.

Czy moje stare polecenie llama-server nadal będzie działać bez zmian?

Sprawdź flagi i modele. Informacje o v0.8.0 wskazują, że obecne polecenia CLI wymagają --model lub -hf. Przypnij wersję, sprawdź dzienniki uruchamiania, przetestuj odpowiedzi API i zachowaj pliki umożliwiające przywrócenie poprzedniej wersji, zanim zmienisz działającą usługę.

Najważniejszy wniosek

llama.cpp v0.8.0 przydaje się przede wszystkim dzięki szerszej zgodności z modelami i bardziej zaawansowanemu serwerowi lokalnemu; obsługa głosu w czasie rzeczywistym to ekscytująca, ale wciąż eksperymentalna funkcja. Mały model LFM3 GGUF udostępniony przez prywatne API loopback to dobry cel na początkową weryfikację. Zapisz faktyczne zużycie pamięci i jakość wyników, zanim dodasz obrazy, strumienie audio lub wielu równoczesnych użytkowników.

Dla właścicieli NAS sprawdzona architektura pozostaje prosta: przechowywanie modeli na znanym woluminie, środowisko uruchomieniowe wnioskowania dopasowane do faktycznie dostępnej pamięci RAM/VRAM oraz chronione aplikacje korzystające z jego API. ZimaCube 2 może pełnić funkcję prywatnej platformy pamięci masowej i aplikacji; nie przedstawiaj go jako gwarantowanego węzła szybkiego wnioskowania multimodalnego bez pomiarów konkretnej konfiguracji sprzętu i backendu. Jeśli oceniasz nowo obsługiwaną rodzinę modeli, zapoznaj się z naszym przewodnikiem po lokalnym modelu LFM3 i sprzęcie oraz z informacjami o wydaniu używanego środowiska uruchomieniowego.

Źródła i zakres

Oficjalna dokumentacja sprawdzona 29 października 2026 r.: informacje o llama.cpp v0.8.0, przewodnik kompilacji projektu źródłowego, oficjalny GGUF LFM3-1.7B, oficjalny GGUF LFM3-VL oraz wyjaśnienie premiery od Liquid AI. Informacje o obsługiwanych funkcjach pochodzą z informacji o wydaniu projektu źródłowego; ZimaSpace nie przeprowadziło niezależnych testów wydajności tej wersji ani nie potwierdziło jej zgodności z konkretną kompilacją ZimaOS.

Obraz okładkowy: ggml-org/llama.cpp, oficjalna karta wydania v0.8.0 w serwisie GitHub.