llama.cpp v1.0.0. Stabilne API i nowe modele lokalne

Co oznacza wersja 1.0.0 llama.cpp

Przez 3,5 roku llama.cpp był wydawany jako ciąg numerowanych kompilacji (np. b12360), bez gwarancji, że interfejs biblioteki nie zmieni się z dnia na dzień. Autorzy piszą na blogu Hugging Face, że rosnąca liczba aplikacji zależnych od projektu wymaga stabilnego API. Zespół rozwijający llama.cpp, w tym twórca projektu Georgi Gerganov, pracuje dziś w Hugging Face.

Nowe zasady są proste. Zmiana niezgodna z publicznym API w katalogu include podnosi wersję główną, nowa funkcja, backend lub obsługa modelu wersję poboczną, a poprawka bez zmian w API ostatni numer. Dla firm budujących produkty na llama.cpp oznacza to łatwiejsze planowanie aktualizacji i mniej niespodzianek po zmianie wersji.

Najważniejsze zmiany w wydaniu

Lista zmian na GitHubie jest długa i w dużej części techniczna. Wybraliśmy te, które mają praktyczne znaczenie dla użytkowników i zespołów wdrażających lokalne modele.

• Pamięć podręczna FP8 dla kontekstu (KV cache) - mniejsze zużycie pamięci przy długich rozmowach.
• Pamięć podręczna ekspertów w modelach MoE (mixture of experts, modele złożone z wielu wyspecjalizowanych podsieci) z konfigurowalnym udziałem procesora CPU - duże modele łatwiej zmieścić na sprzęcie z ograniczoną pamięcią GPU.
• Szybsze ładowanie modeli w Windows, analogiczne do mechanizmu DirectIO w Linuksie.
• Przebudowany interfejs przeglądarkowy serwera z grupami czatów i edytorem Markdown.
• Endpoint /v1/audio/speech zgodny z API OpenAI, który pozwala podmienić chmurową syntezę mowy na lokalną bez zmiany aplikacji klienckiej.

Bezpieczniejszy serwer llama-server

Wiele firm uruchamia llama-server w sieci wewnętrznej jako lokalny zamiennik API modeli chmurowych. Wersja 1.0.0 utrudnia nadużycie takiego serwera. Dodano ochronę przed SSRF (wymuszeniem przez serwer zapytań do innych adresów), błędną konfiguracją CORS i atakiem DNS rebinding, a także anulowanie wywołań narzędzi MCP.

Dla administratorów to dobry powód do aktualizacji. Nawet po niej serwer z modelem nie powinien być wystawiony do internetu bez uwierzytelniania i zapory. Zalecenia CERT Polska dotyczące usług wystawionych publicznie obowiązują tu tak samo jak przy każdej innej aplikacji.

Co sprawdzić przed aktualizacją

Użytkownicy Ollamy, LM Studio i podobnych aplikacji nie muszą nic robić. Zmiany trafią do nich wraz z aktualizacją tych programów, a tempo zależy od ich twórców. Zespoły, które wbudowały llama.cpp bezpośrednio we własny kod, powinny przejrzeć listę usuniętych funkcji.

Przed wdrożeniem warto przetestować własne modele, w tym polskie modele w formacie GGUF, takie jak Bielik 3.1, na nowej wersji. Projekt nie publikuje testów jakości dla języka polskiego, a zmiany w obsłudze kwantyzacji i pamięci podręcznej mogą wpływać na szybkość i zużycie pamięci.

1. Sprawdź w kodzie wywołania funkcji oznaczonych wcześniej jako DEPRECATED w llama.h, w tym llama_set_warmup.
2. Zastąp parametr --defrag-thold, który został usunięty.
3. Zmień nazwę llama_set_embd_state_src na llama_set_ctx_state_src, jeśli korzystasz z API NextN.
4. Przypnij w zależnościach wersję 1.x, aby przyszła wersja 2.0 nie trafiła do produkcji automatycznie.
5. Porównaj szybkość i zużycie pamięci na własnym sprzęcie przed i po aktualizacji.

Znaczenie dla lokalnej AI w Polsce

Lokalne uruchamianie modeli pozwala przetwarzać dokumenty bez wysyłania ich do zewnętrznego dostawcy, co upraszcza ocenę zgodności z RODO i tajemnicą przedsiębiorstwa. Stabilne API obniża koszt utrzymania takich wdrożeń, bo aktualizacja biblioteki nie wymaga już śledzenia każdej kompilacji.

W naszej ocenie wersja 1.0.0 nie zmienia możliwości samych modeli, ale porządkuje podstawę, na której opiera się duża część rynku lokalnej AI. Z llama.cpp korzystają m.in. nowe modele opisywane przez dailyAI, jak Liquid AI LFM3 i Recursive Flint.