L’ANALISI
llama.cpp b10930: scaricare un GGUF senza liberare uno slot
Il router separa finalmente il download dalla capacità di inferenza: il file può entrare in cache mentre il modello attivo resta caricato.
In breve: Con b10930, POST /models può scaricare un nuovo GGUF anche se --models-max è già saturo. Il download resta nello stato DOWNLOADING, non occupa uno slot di inferenza e non espelle il modello residente.
Che cosa bloccava il download
In router mode il processo figlio usato per scaricare passava dallo stesso controllo di capacità previsto per il caricamento normale. Con models-max già raggiunto, il server rispondeva HTTP 500 prima che il file potesse entrare nella cache.
Come cambia il controllo degli slot
La correzione applica il controllo di capacità soltanto alle istanze normali. Le istanze di download restano nello stato DOWNLOADING, mentre il conteggio considera LOADED, LOADING e SLEEPING; al termine il processo figlio viene ripulito.
Cosa cambia nei flussi automatici
Un orchestratore può preparare il prossimo modello con POST /models senza fermare quello in uso. Questo riduce l’interruzione nei flussi di rotazione e aggiornamento, ma il modello scaricato dovrà comunque attendere uno slot libero per essere caricato.
Condizioni e limiti
Il delta riguarda llama-server in router mode e la pre-release b10930. Non aumenta memoria, velocità o capacità concorrente. La pull request documenta un test con models_max=1, ma prima dell’uso operativo conviene ripeterlo con cache, filesystem e modello reali.
Checklist di verifica
- Installare esattamente llama.cpp b10930 o una revisione successiva che contenga il commit 56381e4.
- Avviare llama-server in router mode con --models-max 1.
- Caricare un modello e verificare che occupi l’unico slot.
- Inviare POST /models per un secondo GGUF e registrare stato HTTP e log.
- Controllare che il file arrivi in cache e che il primo modello resti disponibile.
- Liberare lo slot, caricare il modello scaricato e ripetere la prova almeno tre volte.