Che cosa rende diverso Dory 1.0 4B
Il modello Dory 1.0 4B, sviluppato dai Nemotron Labs di NVIDIA, è descritto come un piccolo modello di ragionamento la cui architettura interna consente di applicare più volte lo stesso blocco centrale per ogni token. Il risultato, secondo il tutorial di MarkTechPost, è un unico checkpoint capace di operare a quattro diversi budget di calcolo: da un solo passaggio fino a quattro, senza aggiungere parametri né richiedere un nuovo addestramento.
Il punto centrale è che il costo aggiuntivo non riguarda la dimensione del modello ma il calcolo per token. Ogni passaggio in più comporta più lavoro computazionale, mentre i pesi restano gli stessi. La fonte presenta questa proprietà come una sorta di impostazione scelta al momento del caricamento, più che un iperparametro da definire durante l'addestramento.
Un fork e un file con vincoli precisi
Il supporto a Dory in llama.cpp non è ancora disponibile in una versione rilasciata: il materiale lo descrive come una pull request ancora in bozza. Per questo la guida costruisce llama-server dal commit esatto del fork indicato nella model card di NVIDIA, verificando che il checkout corrisponda a quello previsto. Su Mac vengono usati i flag Metal della scheda, su Colab i kernel CUDA compilati per la GPU disponibile.
Anche il modello ha vincoli operativi. Il file GGUF Q5_K_M, da circa 3,7 GB, è scaricato da Hugging Face a una revisione fissa e verificato tramite hash SHA-256. La fonte segnala una discrepanza pratica: i comandi della model card chiamano il file dory-q5_k_m.gguf, mentre il repository lo nomina diversamente, per cui copiare il comando alla lettera fallisce. Viene inoltre rilevato che l'intestazione GGUF contiene un conteggio di loop predefinito pari a 4, mentre la scheda raccomanda 2: senza override esplicito il server partirebbe silenziosamente con l'impostazione più costosa.
Misure e verifiche, con limiti dichiarati
La guida legge l'architettura direttamente dal file: 72 livelli si dividono in un gruppo di input da 16, un blocco ricorrente condiviso da 40 e un gruppo di output da 16, con un layer di attenzione completa ogni tre a finestra scorrevole. Da questi dati vengono stimate le risorse: quattro loop applicano circa 2,51 volte i parametri di uno solo e leggono circa 2,28 volte i byte dei pesi. La cache KV, con contesto di 4.096 token, passa da 306 MiB a un loop a 816 MiB a quattro nel modo per_loop, mentre il modo last_loop resta a 306 MiB.
Le previsioni vengono confrontate con il server reale in sette configurazioni, misurando memoria, velocità di decodifica e coerenza tra esecuzione accelerata e percorso CPU. Viene poi condotta una valutazione appaiata su un campione di domande GSM8K, con intervalli di Wilson, test di McNemar e bootstrap sui conteggi di token. La fonte precisa però che trenta domande appaiate non bastano a stabilire piccole differenze di accuratezza: il notebook è costruito per dire che cosa il campione può e non può mostrare. Restano non testati, secondo il materiale, la tabella comparativa della model card, il contesto da 256K e il pre-addestramento NVFP4.
