Llama.cpp V1.0.0 wprowadza zasady stabilności API dla lokalnych narzędzi AI

ggml-org ogłosiło wydanie llama.cpp v1.0.0 13 listopada 2026 r., ustanawiając formalne zasady zgodności dla deweloperów korzystających z projektu w języku C/C++ do lokalnego wnioskowania AI. Bazująca na nim biblioteka tensorowa ggml również osiągnęła wersję v1.0.0. Zespół projektu informuje o obsłudze ponad 150 wariantów architektur modeli oraz wszystkich powszechnie stosowanych metod dekodowania spekulatywnego.

Wersjonowanie staje się publicznym zobowiązaniem

Oba projekty będą sygnalizować przyszłe niezgodności API na poziomie kodu źródłowego oraz ABI — interfejsu binarnego używanego przez skompilowane aplikacje — przez zwiększanie numeru wersji głównej. Niezgodne wsteczne zmiany w publicznym API C będą skutkować podniesieniem numeru wersji głównej. Funkcje zgodne wstecz, aktualizacje zaplecza, obsługa modeli i rozszerzenia API będą powodować podniesienie numeru wersji pobocznej, a poprawki błędów niewprowadzające zmian w API — podniesienie numeru poprawki.

Polityka ta jest następstwem 3,5 roku rozwoju i rosnącej zależności od interfejsów bibliotek projektu. llama.cpp umożliwia multimodalne wnioskowanie z użyciem LLM za pośrednictwem libllama, podczas gdy ggml zapewnia warstwę tensorową uczenia maszynowego za pośrednictwem libggml. Oprogramowanie wykorzystuje kwantyzację, zoptymalizowane zaplecza i przenośny kod C/C++, aby obsługiwać sprzęt od komputerów konsumenckich po serwery korporacyjne.

Dzięki temu opiekunowie pakietów i deweloperzy aplikacji mogą na podstawie numeru wersji ocenić, czy aktualizacja może zakłócić integrację. Omówienie procesu wydawniczego z 7 sierpnia 2026 r. przedstawione przez opiekunów projektu wprowadza dodatkowe zabezpieczenie: oficjalny tag wydania llama.cpp jest tworzony tylko wtedy, gdy wewnętrzna kopia ggml jest identyczna z wydaną kopią ggml. Warunek ten ma zapewnić zgodność kompilacji oznaczonych tagiem wydania z instalacją ggml dostępną w całym systemie — rozwiązaniem stosowanym w opisanych w dokumencie pakietach Debiana i Homebrew.

Zmiany w środowisku uruchomieniowym, modelach i serwerze

Informacje o wydaniu llama.cpp v1.0.0 uzupełniają te zasady o szeroko zakrojone porządki. Wydanie usuwa przestarzałe publiczne API, w tym 35 przestarzałych funkcji, a jednocześnie przenosi API dekodowania spekulatywnego NextN z llama-ext.h nagłówka rozszerzeń do publicznego llama.h nagłówka. Dzięki temu ten interfejs dekodowania spekulatywnego staje się częścią publicznego API objętego nowymi zasadami wersjonowania.

Nowe funkcje wnioskowania obejmują pamięci podręczne klucz-wartość w formacie zmiennoprzecinkowym 8-bitowym (FP8) zgodne ze standardem OCP, pamięć podręczną w pamięci hosta dla modeli typu mieszanka ekspertów (MoE) z możliwością konfiguracji udziału procesora oraz wczytywanie zewnętrznych danych PLE lub engramów z oddzielnych fragmentów GGUF. Wśród nowych modeli znalazły się architektury tekstowe Kimi-K3.1-Pro, Ripple i xing4_0, model zamieniający tekst na mowę drama-3 oraz obsługa obrazu w MageVL-Cowork i Kimi-K3.1.

W przypadku llama-server wydanie rozwiązuje problemy związane z fałszowaniem żądań po stronie serwera, współdzieleniem zasobów między różnymi domenami i atakami polegającymi na podmianie odpowiedzi DNS, a także ogranicza HF_TOKEN do hostów huggingface.co. Wywołania narzędzi MCP są anulowane, gdy klient się rozłączy lub upłynie limit czasu, a serwer MCP otrzymuje powiadomienie. Nowy zgodny z OpenAI /v1/audio/speech punkt końcowy rozszerza interfejs audio serwera.

Przeprojektowany interfejs internetowy zyskuje nazwane grupy czatów i edytor Markdown z podglądem na żywo. W układach mobilnych uwzględniono bezpieczne obszary ekranu urządzenia i okna dialogowe wyświetlane na pełnym ekranie, a edytor czatu na Androidzie może otwierać klawiaturę wirtualną.

Zaplecza sprzętowe i infrastruktura wydań

Równoległe wydanie ggml v1.0.0 usuwa przestarzałe API i starsze operacje DIAG_MASK, dodaje konfigurowalne obcinanie YaRN oraz obsługę FP8, a także eliminuje przesyłanie danych wejściowych harmonogramu, które nie są odczytywane. W CUDA i Metal dodano mnożenie skwantyzowanych macierzy z niewielką liczbą wierszy oraz prace nad fuzją MoE. Wśród innych zmian w zapleczach znalazły się: jądro FlashAttention do przetwarzania wstępnego w Intel Vulkan, harmonogram MoE działający po stronie urządzenia w SYCL, rozłożona na części implementacja FlashAttention dla Adreno w OpenCL, nowe jądra WebGPU oraz rozszerzona obsługa operacji Hexagon.

Każde zaplecze ggml można skompilować jako bibliotekę dynamiczną i opcjonalnie wczytywać w czasie działania programu, co pozwala instalacjom wybierać kod dostosowany do konkretnego sprzętu. Artefakty przedpremierowe obejmują systemy Linux, macOS, Windows, Android i iOS, a Docker, Debian, Homebrew, conda-forge, MacPorts, Winget i XCFramework zapewniają dodatkowe kanały dystrybucji, których zakres obsługiwanych platform jest różny.

Zespół informuje, że aby nadążyć za tempem rozwoju, zwiększa możliwości integracji ciągłej dzięki Hugging Face Buckets i Jobs dla zmian trafiających do gałęzi master. Obsługa sprzętu ze strony NVIDIA, AMD, Qualcomm, Arm, IBM i Intel umożliwia także korzystanie z większej liczby runnerów hostowanych samodzielnie na najważniejszych platformach sprzętowych. Opiekunowie projektu włączają również LLM-y do cyklu prac programistycznych, wskazując przy tym jako priorytety jakość kodu, kontrolę nad architekturą i zrozumienie szczegółów implementacji.

Dla projektów korzystających z tych bibliotek nowe wydanie sprawia, że zgodność staje się wyraźnym obowiązkiem w procesie rozwoju szybko zmieniającej się biblioteki open source. Zasady wersjonowania pozwalają sygnalizować niezgodności, a rozbudowany program integracji ciągłej i runnerów sprzętowych pomaga ustalić, czy regularne wydania pozostają niezawodne na różnych modelach i urządzeniach używanych przez te projekty.