This is a viewer only at the moment see the article on how this works.
To update the preview hit Ctrl-Alt-R (or ⌘-Alt-R on Mac) or Enter to refresh. The Save icon lets you save the markdown file to disk
This is a preview from the server running through my markdig pipeline
Sunday, 28 December 2025
I LLMs piccoli e locali sono spesso inquadrati come l'alternativa economica ai modelli di frontiera. Quell'inquadratura è sbagliata. Non sono una versione degradata della stessa cosa. Sono una scelta architettonica diversa, selezionata per controllo, prevedibilità, e modalità di guasto sopravvivebile.
Sono colpevole come chiunque altro per aver spinto la narrazione 'sono liberi'... come se fosse l'unico fattore decisivo. Ma come scegliere una piattaforma di database / hosting per un sistema che devi capire Che compromessi stai facendo?.
Utilizzando un piccolo modello via OllamaCity name (optional, probably does not need a translation), LM Studio, ONNX Runtime, o simili non è (solo) di risparmiare denaro. Si tratta di scegliere dove il non-determinismo è consentito di esistere.
I grandi modelli di frontiera sono più ampi e fluenti. Essi densificano più della logica umana espressa, abbracciano più domini, e producono tracce di ragionamento più convincenti. più pericoloso nei sistemi che richiedono garanzie.
I modelli Frontier hanno senso quando l'ampiezza è richiesta e le uscite sono consultive dal design - stesura creativa, esplorazione aperta, o sintesi in domini sconosciuti. Ma non è la maggior parte dei sistemi di produzione.
I loro fallimenti sono semantico piuttosto che strutturale. Questo è l'errore di categoria: trattando una componente probabilistica come se fosse un limite di sistema. Generano uscite dall'aspetto valido che sono sbagliate in modi sottili. Questi fallimenti sono:
I piccoli modelli falliscono in modo diverso.
Quando un piccolo modello è confuso, tende a:
Questi sono fallimenti a buon mercato. Sono rilevabili con semplice validazione. Attivano ritriti o ripiegamenti immediatamente. Non avanzano silenziosamente stato.
Questa non e' una debolezza, e' una caratteristica.
Questa intuizione non è teoria astratta - è il fondamento della Dieci comandamenti di utilizzo di LLM. Il principio fondamentale:
I LLM interpretano la realtà e non devono mai essere autorizzati a definirla.
Quando si segue questo principio, si scopre qualcosa di sorprendente: smetti di aver bisogno di modelli costosi. Un modello di parametro 7B che funziona localmente può classificare, riassumere e generare ipotesi semplicemente bene - perché i sistemi deterministici intorno a esso gestiscono tutto ciò che effettivamente deve essere corretto.
I piccoli modelli non sono "deboli" - sono spesso sufficiente perché il problema è già stato ridotto nel momento in cui li raggiunge.
I modelli di frontiera stanno vendendo l'affidabilità si dovrebbe costruire te stesso.
Proprio come DuckDB non è "a buon mercato SQL" e Postgres non è "peggiore Azure SQL," piccoli LLM occupano un punto diverso nello spazio di progettazione. Li scegli quando:
| Presupposto | Vantaggio per il modello piccolo |
|---|---|
| Località | Corre sul vostro hardware, la vostra rete, la vostra giurisdizione |
| Verificabilità | Ogni inferenza è registrata, riproducibile, ispezionabile |
| Raggio di scoppio | I guasti sono contenuti, non propagati attraverso catene API |
| Applicazione della correttezza | La convalida avviene al di fuori del modello |
| Non-determinismo confinato | L'incertezza è strettamente limitata |
Questo non è ipotetico. I miei progetti dimostrano questo schema ripetutamente:
La mia implementazione di GraphRAG offre tre modalità:
| Modo | Chiamate LLM | Migliore per |
|---|---|---|
| Euristico | 0 per pezzo | Determinismo puro via IDF + struttura |
| Ibrido | 1 per documento | Il modello piccolo convalida i candidati |
| LLM | 2 per pezzo | Qualità massima quando necessario |
La modalità ibrida è il punto dolce: l'estrazione euristica trova candidati (deterministic), poi un piccolo modello locale li convalida e li arricchisce. Una chiamata LLM per documento, non per pezzo.
Con Ollama in esecuzione localmente, il costo è di $0. Ma non è per questo che lo uso - risparmi di costo sono un effetto collaterale di corretta astrazione, non l'obiettivo. Io lo uso perché i fallimenti sono economici e ovvi.
Ricerca semantica con ONNX e Qdrant mostra un altro modello: alcune attività non hanno bisogno di un LLM. BERT embeddings via ONNX Runtime dare:
Per ricerca ibridaIl LLM appare solo al momento della sintesi - e anche allora, un piccolo modello locale funziona bene perché è spiegazione struttura che i sistemi deterministici hanno già convalidato.
DocSummarizer Incarna questa filosofia:
La LLM è la ultimo passo, lavorando su contenuti pre-convalidati e pre-strutturati. Può fallire - e quando lo fa, il fallimento è evidente perché la struttura è già corretta.
TinyLLMCity name (optional, probably does not need a translation) dimostra l'utilizzo locale di LLM in un'app desktop Windows. Supporta:
L'interfaccia chat è probabilistica. La memoria, la gestione dei file e la gestione dello stato sono deterministiche. Il fallimento in uno non corrompe l'altro.
I modelli Frontier sono strumenti potenti quando utilizzati deliberatamente, ma aumentano la potenza espressiva più velocemente di quanto riducano il rischio. I modelli piccoli, quando incorporati all'interno di sistemi deterministici, danno sufficiente incertezza da esplorare - senza oscurare la verità o la responsabilità.
La domanda giusta non è "quale modello è migliore?"
È:
Se la risposta comporta stato, effetti collaterali, denaro, politica, o garanzie - il modello non dovrebbe mai essere responsabile. E se il modello è solo lì per classificare, riassumere, rango, o proporre ipotesi, un piccolo modello locale è spesso il scelta correttaNon quella economica.
Questa è l'architettura che funziona:
┌─────────────────────────────────────────────────────┐
│ DETERMINISTIC LAYER │
│ State machines, queues, validation, storage │
│ (DuckDB, Postgres, Redis, file systems) │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ INTERFACE LAYER │
│ Schema validation, retries, fallbacks │
│ (Polly, FluentValidation, custom guards) │
└─────────────────────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────┐
│ PROBABILISTIC LAYER │
│ Classification, summarisation, hypothesis gen │
│ (Ollama, ONNX, small local models) │
└─────────────────────────────────────────────────────┘
L'LLM è al fondo, non la parte superiore. Si propone; gli strati deterministici si disfano.
Tutte e tre le prospettive - le domande, il modello, e questo principio finale - riducono alla stessa regola:
Affidabilità è di scegliere i fallimenti si può sopravvivere.
Con i LLM, ciò significa gestire il non-determinismo attraverso pratiche deterministiche:
Piccoli modelli rendono questo più facile perché i loro fallimenti sono forte. JSON non valido. Produzione troncata. Violazioni dello schema. Questi sono regali - ti dicono immediatamente che qualcosa è andato storto.
I fallimenti del modello di frontiera sono tranquillo- Sciocchezze incredibili, allucinazioni sicure, deriva semantica che diventa visibile solo quando un cliente si lamenta o un audit fallisce.
Prendero' ogni volta dei forti fallimenti.
© 2026 Scott Galloway — Unlicense — All content and source code on this site is free to use, copy, modify, and sell.