Vai al contenuto

llama.cpp b12180 aggiunge Kimi K3.1 Pro solo testuale: vision tower e mm_projector esclusi. Requisiti reali e prestazioni restano da misurare.

L’ANALISI

Kimi K3.1 Pro su llama.cpp: supporto solo testuale

llama.cpp b12180 aggiunge Kimi K3.1 Pro solo testuale: vision tower e mm_projector esclusi. Requisiti reali e prestazioni restano da misurare.

4 min di letturaFatti, limiti e fonti primarie
Release ufficiale llama.cpp b12180 con supporto testuale a Kimi K3.1 Pro
La prerelease ufficiale llama.cpp b12180 su GitHub: il nuovo percorso Kimi è dichiarato solo testuale.

In breve: Kimi K3.1 Pro ha un nuovo percorso testuale in llama.cpp dalla build b12180. La release non include la parte visiva ed è classificata prerelease. Per chi aveva già valutato i pesi, cambia la compatibilità del runtime; prima di parlare di uso locale pratico servono misure del modello completo. llama.cpp: prerelease b12180 e confine del supporto.

Verifica documentale del 7 novembre 2026: release REST b12180, PR 31779 e file modificati. Le prove riportate dagli sviluppatori non sono test di Francesco. Non sono stati scaricati o convertiti i pesi e non è stata eseguita inferenza del modello completo.

Che cosa aggiunge davvero la build b12180?

La release introduce architettura e conversione per il modello testuale e riusa componenti del percorso K3 aggiungendo l’indicizzatore DSA. La distinzione editoriale è fra disponibilità dei pesi e compatibilità di uno specifico software: l’una non implica automaticamente l’altra. Il fatto nuovo da verificare è quindi il caricamento di un checkpoint attraverso questo runtime. Non è corretto ripresentare Kimi come appena annunciato né dedurre dalla presenza di una build che qualunque file già scaricato sia subito compatibile.

llama.cpp: prerelease b12180 e confine del supporto · Diff della PR 31779: conversione e runtime.

Quali modalità restano escluse?

Le note dichiarano che vision tower e mm_projector vengono saltati: il percorso è testuale. Una valutazione dovrebbe restare entro quel confine, senza trasferire al runtime capacità multimodali attribuite al modello originale. Anche il suffisso Pro nel nome pubblico non coincide con tutte le stringhe interne di architettura. Nel registro della prova annoterei quindi modello, revisione, formato e modalità richiesta, così da distinguere un problema di identificazione da una funzione non implementata.

llama.cpp: prerelease b12180 e confine del supporto · PR 31779: supporto testuale a Kimi K3.1 Pro.

Che valore hanno le prove descritte dagli sviluppatori?

La release riporta controlli su una porzione di otto layer e test dell’architettura; l’autore della PR descrive anche proprie prove di conversione e uso. Sono evidenze tecniche del progetto con scopi diversi, non un benchmark riprodotto su questa macchina. Per una decisione di adozione chiederei un log del modello completo, con hardware, parametri e carico rappresentativo. Un test parziale utile a verificare i tensori non misura da solo velocità, memoria di picco o affidabilità di un servizio.

llama.cpp: prerelease b12180 e confine del supporto · PR 31779: supporto testuale a Kimi K3.1 Pro.

Quale procedura usare prima di impegnare risorse?

Proporrei prima un controllo dei file e della capacità disponibile, poi un avvio isolato con una richiesta testuale breve. Solo dopo un esito riproducibile aumenterei contesto e concorrenza, registrando tempi, memoria ed errori. Il budget di download e calcolo va deciso prima di avviare un checkpoint grande. Conservare il runtime precedente permette un confronto senza trasformare una verifica in migrazione irreversibile. Questa pagina indica il protocollo e il confine del supporto, non promette che la prova sia già riuscita.

llama.cpp: prerelease b12180 e confine del supporto · Diff della PR 31779: conversione e runtime.

Condizioni e limitazioni

Build marcata prerelease e supporto solo testuale. Non sono state misurate qui memoria, latenza o qualità del modello completo: il supporto del loader non dimostra che l’esecuzione sia sostenibile su un normale PC.

Checklist pratica

  • Leggere lo stato prerelease di b12180 e fissare tag o commit, senza trattarlo come una release stabile.
  • Verificare modello, revisione, formato e licenza del checkpoint che si intende usare.
  • Stimare spazio e memoria prima del download; non confondere parametri attivi e peso totale.
  • Provare solo input testuali e annotare che vision tower e mm_projector non sono inclusi.
  • Registrare log, hardware, memoria, latenza e contesto del modello completo; mantenere una via di ritorno al runtime precedente.

Fonti primarie

Radar AI · a cura di Francesco Gruner

Chiedi al sito.

Assistente OpenAI

Le domande vengono inviate a OpenAI. Non inserire dati personali o riservati. Privacy.

Verifica le risposte nelle fonti. 16 messaggi al giorno per rete.

Cosa cerchi? Ti indico le pagine utili.