Llama.cpp koppelt API- en ABI-breuken aan major-versies

llama.cpp v1.0.0 koppelt incompatibele API- en ABI-wijzigingen voortaan aan major-version bumps, meldt ggml-org, zodat teams die de C/C++-bibliotheek in eigen lokale AI-producten bundelen de breuken vooraf herkennen.

Bij software waarin llama.cpp wordt meegeleverd, kan een upgrade aanpassing van broncode of een herbouw vragen. De API beschrijft de functies waartegen broncode wordt gebouwd; de ABI bepaalt of al gecompileerde onderdelen met een nieuwe bibliotheek blijven samenwerken. De major-versie geeft het team een zichtbaar moment om die wijziging in planning, compilatiecontroles en integratietests mee te nemen.

De nummering krijgt een contract

De nieuwe regels gelden voor llama.cpp en ggml, de onderliggende tensorbibliotheek. In de aankondiging staat een versie-indeling voor projecten van ggml-org die semantische versies volgen. Een MAJOR-bump markeert een breuk in de publieke C-API, een MINOR-bump is voor achterwaarts compatibele functies, backend-updates, modelondersteuning of API-toevoegingen. Een PATCH-bump is bedoeld voor bugfixes zonder API-wijziging. De aankondiging zegt breder dat zowel API- als ABI-incompatibiliteit voortaan met een major-versie zichtbaar wordt.

De release maakt die breuk concreet. llama.cpp verwijdert onder meer llama_set_warmup, 35 verouderde functies uit de publieke API en de instelling defrag_thold met de bijbehorende opdrachtregeloptie. De API voor speculatief decoderen, NextN, verhuist van llama-ext.h naar de publieke header llama.h; ook wordt llama_set_embd_state_src hernoemd naar llama_set_ctx_state_src. Voor een applicatie die een verwijderde functie aanroept, moet de code worden aangepast voordat die met de nieuwe headers bouwt. De release voegt tegelijk nieuwe mogelijkheden toe, waaronder FP8 KV-caches, een instelbaar aandeel CPU-geheugen voor de cache van Mixture-of-Experts-modellen en het OpenAI-compatibele /v1/audio/speech-eindpunt in llama-server.

Dezelfde dag verscheen ggml v1.0.0. Die release snoeit in de verouderde publieke API, verwijdert DIAG_MASK_INF en DIAG_MASK_ZERO en verhoogt de RPC-protocolversie om incompatibele peers af te wijzen. Dat raakt teams die de tensorbibliotheek los of over een netwerkverbinding inzetten: een versieverschil tussen componenten vraagt om controle van de communicatie tussen processen.

Een geplande opschoning wordt de nieuwe norm

De major-versie volgt op een expliciet opschoningsplan. Op 15 oktober stelde projectleider Georgi Gerganov voor om voor v1.0.0 vooral verouderde interfaces te verwijderen. De planning noemde tussentijdse releases v0.7, v0.8 en v0.9 vóór de stap naar 1.0.0. Op 11 november schreef hij dat eerdere API-breuken in de 0.x-periode niet steeds in het versienummer waren terug te zien. Hij verwachtte dat major-versies vanaf v1 waarschijnlijk vaker zouden verschijnen.

Dat maakt de onderhoudsverwachting belangrijk voor software die llama.cpp inbouwt. Een team dat updates wil blijven volgen voor modelondersteuning en bugfixes kan niet uitgaan van lange periodes zonder API-breuken. De major-bump maakt het risico herkenbaar. De organisatie die llama.cpp verpakt moet de eigen build- en integratietests op het moment van upgraden laten meelopen. Unite.AI beschrijft dat pakketbeheerders en applicatiebouwers major-version bumps kunnen gebruiken om integratierisico’s bij een upgrade te beoordelen.

Lokale AI heeft meer dan één grens

De API-versie is één onderdeel van een technische omgeving voor lokale AI. DeepSeek bracht DeepInfer onder Apache 2.0 uit voor offline-inferentie van V4.1-Flash; de officiële repository noemt NVIDIA SM100 en Huawei Ascend 950 als ondersteunde hardware. Daar ligt de grens bij model en accelerator; bij llama.cpp komt daar de stabiliteit van de bibliotheekinterface bij. Een team kan daardoor tegelijk afhankelijk zijn van de versie van de runtime, de ondersteunde modelarchitectuur en de beschikbare hardware.

Ook Google's LiteRT Tensor API laat ontwikkelaars modelgrafen in C++ bouwen en naar CPU, GPU of ondersteunde NPU’s sturen. Google positioneert die gedeelde grafen als route naar meerdere platforms en stelt dat code-first runtimes zoals llama.cpp per hardwaredoel moeten worden herschreven. Dat is Googles eigen productvergelijking, geen onafhankelijke meting van onderhoudslast. Een routerlaag tussen applicaties en modellen, met een model met open gewichten als uitwijkroute, is een andere manier om die afhankelijkheid te begrenzen; die architectuur houdt modelkeuzes achter één applicatie-interface.

Het versienummer maakt het werk planbaar

Een vergelijking met PyTorch laat zien welk deel van de belofte nog openstaat. De PyTorch-documentatie voor de LibTorch Stable ABI geeft uitbreidingen minstens twee jaar compatibiliteitsvenster voor de stabiele C-shim. De llama.cpp-aankondiging noemt major-versies als signaal voor incompatibiliteit, maar publiceert geen vergelijkbare onderhoudsduur voor oudere major-versies. Ook definieert de regelstabel de major-bump concreet voor de publieke C-API, terwijl de aankondiging ABI-breuken breder noemt. De precieze behandeling van ABI-wijzigingen staat daardoor minder uitgewerkt dan de C-API-regel.

Voor teams die llama.cpp bundelen, komt de verschuiving vooral in het releaseproces terecht. De concrete verwijderingen in v1.0.0 laten zien dat de controle ook bestaande toepassingen kan raken. De maintainers verwachten dat major-versies vaker kunnen voorkomen, zonder een termijn te noemen waarin eerdere versies ondersteund blijven. Het upgrade-ritme wordt daarmee een terugkerende ontwerp- en onderhoudskeuze zodra de bibliotheek onderdeel is van een product.