llama.cpp: Top-K più ripetibile su CUDA e Metal

In breve: llama.cpp b12208 integra la PR 31084: nel percorso radix Top-K di CUDA e Metal i pareggi alla soglia non devono più scegliere candidati diversi in base alla temporizzazione dei thread. La correzione riguarda la selezione degli indici dell’operatore, non il determinismo dell’intera generazione o l’identità dei risultati fra backend. Abbiamo verificato documenti e codice, senza eseguire test o inferenza. PR 31084: selezione deterministica dei pareggi nel Top-K radix CUDA e Metal.

Verifica documentale dell’8 novembre 2026 con nuove acquisizioni HTTP della release ufficiale b12208, da cui è stata risolta la PR 31084, della PR, del diff di quattro file, del commit e del tag. Il tag punta a 57d04820dfef7a3519aac276d018a6fd71251895. Merge alle 15:42:58 e pubblicazione della prerelease alle 16:47:03, ora italiana. Nessuna compilazione, suite di test, inferenza o misura prestazionale eseguita da noi.

Che cosa cambia quando più valori sono uguali?

Top-K sceglie gli indici dei k valori maggiori. Se alla soglia ci sono più candidati uguali dei posti disponibili, contatori atomici potevano far dipendere la scelta dalla temporizzazione dei thread. Il nuovo percorso radix CUDA assegna ai pareggi un ordine per colonna, mantenendo gli indici più bassi. Il diff Metal sostituisce a sua volta la compattazione atomica con un ranking deterministico.

PR 31084: selezione deterministica dei pareggi nel Top-K radix CUDA e Metal · Diff finale: CUDA, Metal e controllo di ripetibilità Top-K.

È deterministica tutta la generazione del modello?

No. La correzione stabilizza una scelta interna a un operatore e non dimostra che l’intera esecuzione abbia eliminato ogni altra fonte di variazione. Anche il test introdotto è più circoscritto: confronta gli insiemi di indici ottenuti ripetendo il calcolo sullo stesso backend, ordinandoli prima del confronto. Non richiede che CUDA e Metal restituiscano lo stesso ordine e non misura l’identità del testo generato.

Diff finale: CUDA, Metal e controllo di ripetibilità Top-K · Commit integrato della selezione Top-K a parità di valori.

Quali percorsi restano esclusi dalla garanzia?

Il sorgente CUDA fissato al merge conserva DeviceTopK per una o due righe quando CUB è disponibile; la chiamata richiede esplicitamente determinismo non garantito. Il nuovo controllo dei test è abilitato sui casi con pareggi per ROCm e, oltre due righe, per CUDA e MTL. Il commento esclude Vulkan e SYCL. Sono limiti del perimetro verificato, non prove di un difetto in ogni singola esecuzione esclusa.

PR 31084: selezione deterministica dei pareggi nel Top-K radix CUDA e Metal · Diff finale: CUDA, Metal e controllo di ripetibilità Top-K · CUDA Top-K fissato al merge: percorsi radix e DeviceTopK.

Che cosa documentano davvero i quattro file modificati?

Il diff finale comprende top-k.cu, il collegamento dell’operatore Metal, il kernel argsort.metal e test-backend-ops.cpp. Cambiano selezione e compattazione dei candidati e viene aggiunto il controllo di ripetibilità. Le note di release contengono anche passaggi intermedi e misure dei contributori: non li trattiamo come una promessa di accelerazione dell’intero modello e non abbiamo eseguito benchmark.

llama.cpp b12208: prerelease ufficiale e riferimento alla PR 31084 · Diff finale: CUDA, Metal e controllo di ripetibilità Top-K · Commit integrato della selezione Top-K a parità di valori.

Come preparare una verifica di ripetibilità pertinente?

Fissare revisione, backend, toolchain e forma del tensore, compreso il numero di righe. Preparare input con pareggi alla soglia e più candidati dei posti residui, poi confrontare nelle prove future gli insiemi di indici ottenuti sullo stesso backend. Tenere separati ordine degli indici, insieme selezionato e risultato dell’intera generazione. Questa procedura non è stata eseguita da noi e non sostituisce i test dell’applicazione.

Diff finale: CUDA, Metal e controllo di ripetibilità Top-K · Riferimento ufficiale del tag b12208 · CUDA Top-K fissato al merge: percorsi radix e DeviceTopK.

Condizioni e limitazioni

Il perimetro è la selezione Top-K nei percorsi modificati, non tutta l’inferenza. CUDA può ancora usare DeviceTopK per una o due righe e mantenere pareggi non deterministici. Il test confronta insiemi di indici sullo stesso backend, non identità universale dell’ordine o dei byte fra backend; Vulkan e SYCL restano fuori dal controllo. Nessun test locale eseguito.