# Proof of work e inference: il costo come segnale, non come identità > L'inference non è proof of work. Distinguo due spese di compute: una regola per il consenso scarso, e un modello più un prompt per l'utilità. Published: 2026-10-02 Canonical: https://gianlucamazza.it/it/blog/pow-vs-inference Tags: Inference, Cost, Eval, LLM, Production ## Perché conta L'inference non è proof of work. Continuo a sentire i due nomi nella stessa frase, come se un forward pass costoso fosse un nuovo trucco di consenso. La rima c'è. L'identità no. Entrambe le spese bruciano compute che qualcun altro può verificare. Lo fanno per ragioni opposte, contro oggetti diversi, e falliscono in modi diversi. Se le schiaccio, ribattezzo una bolletta di utilità come protocollo e perdo di vista a che cosa serviva la spesa. Questo è un taglio didattico, non un claim di prodotto. Misuro i gate, registro i reject e conservo le ricevute del retrieval. Non tratto queste abitudini come un proof of work reinventato. Due spese di compute diverse: - **Proof of work** è lavoro costoso e verificabile contro una **regola**. Il lavoro è inutile di proposito. La scarsità è il punto: al consenso serve un biglietto difficile da coniare e economico da verificare. - **Inference** è lavoro costoso e verificabile contro un **modello e un prompt**, più una eval o un gate quando non sto indovinando. La spesa punta all'utilità: token e watt verso una risposta, non verso un biglietto della lotteria. L'asse comune è il costo come segnale. Il claim pubblico vietato è che le due cose siano la stessa. ## Che cosa è davvero il proof of work Il proof of work è un filtro su chi può appendere a un log condiviso. Un partecipante spende energia in una ricerca che non ha altro uso se non soddisfare una regola pubblica: trovare un nonce tale che l'hash dell'header del blocco cada sotto una soglia di difficoltà. Chiunque può rieseguire il controllo in millisecondi. Quasi nessuno può coniare un biglietto valido nuovo senza pagare di nuovo il costo della ricerca. Tre proprietà contano, e sono più strette di "sembra costoso, quindi è serio": 1. **Il controllo è contro una regola.** Il verificatore non chiede se il lavoro fosse acuto. Chiede se l'output soddisfa un predicato fissato in anticipo. 2. **Il lavoro è inutile di proposito.** Se la ricerca producesse un effetto collaterale di valore, un attaccante potrebbe raccogliere quell'effetto senza curarsi del consenso. Lo spreco è il modo in cui il protocollo impedisce al biglietto di essere un sottoprodotto del lavoro utile ordinario. 3. **Il costo compra consenso scarso, non una credibilità vaga.** Una proof valida ammette un blocco, oppure no. Non assegna un punteggio di reputazione o la sensazione che l'operatore "abbia pagato il dovuto". Si prende in prestito "proof of work" quando si intende "ho speso soldi, quindi fidati". Quello non è il protocollo. Un gesto costoso può essere un segnale e fallire comunque ogni proprietà di consenso: niente regola condivisa, niente controllo pubblico economico, niente accordo su che cosa ammette il biglietto. Il controllo è anche unilaterale in un modo che l'inference non è. Una volta soddisfatta la regola, il lavoro è finito. Non resta una seconda domanda su quanto fosse "buono" il nonce. La bontà è il predicato. ## Che cosa è davvero l'inference L'inference è un forward pass. Carico un modello, fornisco un prompt, spendo banda di memoria ed energia, e ricevo token. Se sto operando il sistema invece di guardare una demo, controllo poi l'output contro uno schema, un test set stabile, un gate di policy o una review umana. La spesa avviene prima di quel secondo controllo, che è ciò che la rende utile o sprecata. L'oggetto del controllo non è un puzzle. È un modello più un prompt, e poi qualunque gate metto dopo il decoder: - **Contro il modello e il prompt:** questo runtime, con questi pesi e questo contesto, ha prodotto questa sequenza? Quella parte è verificabile. Quell'abitudine la ho già scritta nelle [eval harness di livello bancario](/it/blog/bank-grade-agent-evals). - **Contro una eval o un gate:** la sequenza ha soddisfatto il mestiere? Quella parte può fallire dopo che i token sono già stati ordinati. Non eseguo inference per coniare un biglietto scarso. La eseguo perché voglio una risposta, una tool call, una patch, un paragrafo ancorato al retrieval. Il costo è reale. Lo scopo è l'utilità. Se la eval fallisce, ho comunque speso il compute. Il costo c'era; la risposta no. Per questo "l'inference è cara, quindi è proof of work" è un errore di categoria. Il prezzo non è un protocollo. Un biglietto della lotteria e un saggio di laboratorio possono costare lo stesso e restare due strumenti diversi. Un runtime GGUF locale e una API ospitata sono entrambi inference. Nessuno dei due diventa una regola di consenso perché posso citare un numero di throughput. Qui rifiuto tok/s non misurati di proposito. Se una cifra non sta in un artefatto pubblicato, in questo articolo non c'entra. ## Stesso asse, intento opposto La sovrapposizione utile sta in una tabella. La tengo visibile così la metafora non si allarga in silenzio. | | Proof of work | Inference | | ---------------------- | -------------------------------------------------------------------------------------- | ----------------------------------------------------------------------- | | Controllo contro | Una regola o un puzzle | Un modello e un prompt, poi una eval o un gate | | Intento | Lavoro inutile di proposito per un consenso scarso | Lavoro costoso che punta a una risposta utile | | Costo come segnale | Energia e compute comprano un biglietto difficile da coniare e economico da verificare | Energia e compute comprano un output candidato; il gate decide se conta | | Claim pubblico vietato | — | L'inference è proof of work | Stessa rima: lavoro scarso e verificabile. Intento opposto: spreco di proposito contro una risposta utile. Il costo come segnale è la parte che tengo. Se un passo è gratis, non so dire se qualcuno l'abbia eseguito. Se un passo ha un conto, posso chiedere che cosa ha comprato. Quella domanda è legittima in entrambe le immagini. Non rende uno stack LLM un protocollo di consenso. I failure mode si spezzano allo stesso modo. Un proof of work sbagliato è un biglietto invalido, quindi il log non si muove. Un'inference sbagliata può restare un decode valido: il modello ha prodotto quei token, e il gate poi dice che non fanno il mestiere. Ho pagato un candidato, e il candidato è fallito. ## Useful-PoW è un concetto, non un protocollo C'è un'idea-ponte, e voglio nominarla così non si insinua come prodotto. **Useful-PoW** è il pensiero che la stessa spesa verificabile possa anche fare un mestiere che qualcuno voleva comunque: lavoro verificabile che non è puro spreco. Resta un concetto. Non è un prodotto che spedisco, e non è un nome che metto su xllama, mklang o ragfs. Restano due limiti: 1. **Un effetto collaterale utile non inventa una regola di consenso.** Se non so dire che cosa ammette il biglietto, chi lo verifica, e che cosa succede quando due biglietti validi vanno in conflitto, ho un workload, non un protocollo. 2. **L'inference da sola non è un protocollo di consenso.** Un modello più un prompt può essere costoso e verificabile e non dire nulla su chi appende a un log condiviso. Una eval o un prezzo non chiudono quel vuoto. Uso il ponte per tenere due immagini in vista, non per saldarle. Una rima può essere esatta in un punto e vuota in un altro: l'[analogia della calcolatrice](/it/blog/llm-thinking-calculator) ha già fatto quel taglio. Il costo è il punto esatto. L'identità è quello vuoto. Non schiaccio questo in "l'inference è un proof of work reinventato". ## Pratica: onestà su costo, ledger e retrieval La pratica che posso sostenere è più stretta di un pitch Useful-PoW. Tengo tre libri onesti in artefatti pubblici: quanto è costato il forward pass, che cosa avevo già ordinato quando un gate rifiuta l'output, e che cosa ho davvero recuperato. ### xllama: misura il gate di costo, non lo rinominare [xllama](https://github.com/gianlucamazza/xllama) è il mio progetto di inference locale su hardware Xbox in developer mode: GGUF e ONNX Runtime GenAI, CPU o GPU scelte per workload, niente percorso verso lo store retail. Il [report sulla Xbox Series S](/it/blog/slm-on-xbox) è la ricevuta narrativa. Il [riassunto di benchmark generato](https://github.com/gianlucamazza/xllama/blob/main/docs/benchmarks.md) è la ricevuta a livello di comando, ciascuna cifra legata al comando che l'ha prodotta. Qui non ripeto un numero di tok/s. Quello che porto via da quel lavoro è il gate, non uno slogan. L'inference locale ha un conto in watt, memoria e tempo di esecuzione. Posso misurarlo e pubblicare il comando. Non posso trasformare quel conto in proof of work chiamando la misura un puzzle. Xbox è un marchio Microsoft. xllama è un progetto di ricerca indipendente, non un prodotto Microsoft e non affiliato a Microsoft. ### mklang: un reject non cancella i token che ho già ordinato [mklang](https://github.com/gianlucamazza/mklang) è un DSL dichiarativo per macchine a stati guidate da LLM. Lo uso su questo sito come runtime selettivo per i loop di proposta e riparazione; la decisione accettata è l'[ADR-0003](https://github.com/gianlucamazza/personal-website/blob/main/docs/adr/0003-mklang-content-runtime.md). La macchina può fermarsi, riparare o chiedere una review umana. I gate deterministici decidono comunque. Il [log di validazione live](https://github.com/gianlucamazza/personal-website/blob/main/docs/mklang-live-validation.md) registra i token di input e di output su quei run, compresa una riscrittura di copy-review poi marcata `corrected`. Questa è onestà di ledger, non un prodotto di addebito. Rifiutare un output sbagliato non cancella i token che ho già ordinato. La spesa è avvenuta prima del verdetto. La [scheda progetto mklang](/it/progetti#mklang) è l'indice pubblico del repository. Non chiamo mklang un prodotto Useful-PoW. ### ragfs: il retrieval ha un conto; le ricevute battono il "fidati" [RAGFS](https://github.com/Venere-Labs/ragfs) monta una directory indicizzata ed espone operazioni, risultati e undo attraverso il filesystem. Ho scritto la decisione di interfaccia in [Perché ho dato agli agenti un filesystem invece di un'altra API](/it/blog/agent-filesystem). La ricerca su quel mount esegue un modello di embedding locale e conserva i vettori in LanceDB. La prima query paga un download e un indice; le successive pagano il percorso descritto dalla [documentazione pubblica](https://venere-labs.github.io/ragfs/). Non ho pubblicato un benchmark di qualità del retrieval per questo setup, quindi non ne invento uno qui. Il retrieval non è una prefazione gratuita all'inference. Ha un conto, e ha un risultato che posso leggere: quale percorso ho chiesto, che cosa ha detto il JSON, se esiste un `undo_id`. Quella è una ricevuta. "Fidati, il contesto era pertinente" no. L'ordine diagnostico che uso quando il retrieval è debole resta [RAG in produzione](/it/blog/rag-systems-production). Niente di tutto questo è proof of work. È lavoro scarso e verificabile, con l'intento opposto. ## Il costo fa rima; l'equivalenza no Il costo fa rima. L'equivalenza no. Il proof of work spende compute contro una regola perché il consenso resti scarso. L'inference spende compute contro un modello e un prompt perché qualcuno possa usare l'output. Useful-PoW è il concetto che un giorno quelle due immagini possano condividere un workload. Non è un nome per un runtime locale, una macchina di copy-review o un mount FUSE. I post collegati che voglio accanto a questo sono le ricevute, non una scena: il [gate di costo sulla Xbox](/it/blog/slm-on-xbox), l'[interfaccia filesystem per il retrieval](/it/blog/agent-filesystem), l'[ordine diagnostico RAG](/it/blog/rag-systems-production) e l'[eval harness](/it/blog/bank-grade-agent-evals). Leggili come onestà su costo, ledger e retrieval. ## FAQ ### L'inference è una forma di proof of work? No. L'inference spende compute contro un modello e un prompt per una risposta utile. Il proof of work spende compute contro una regola per un consenso scarso, e il lavoro è inutile di proposito. Condividono una rima. Non sono lo stesso protocollo. ### Che cosa significa qui "costo come segnale"? Se un passo è gratis, non so dire se qualcuno l'abbia eseguito. Se un passo ha un conto, posso chiedere che cosa ha comprato e se un gate successivo ha accettato il risultato. Quel segnale non trasforma l'inference in proof of work. ### Che cos'è Useful-PoW in questo articolo? Solo un concetto: lavoro verificabile che fa anche un mestiere che qualcuno voleva. Non è un prodotto che spedisco, e non è un nome che metto su xllama, mklang o ragfs. L'inference da sola non è un protocollo di consenso. ### Perché cito xllama, mklang e ragfs? Sono ricevute pubbliche di tre abitudini di onestà: misurare il gate di costo locale, registrare i token già ordinati quando un gate rifiuta l'output, e tenere i risultati del retrieval al posto del contesto "fidati". ### Una eval fallita cancella il compute che ho speso? No. Il forward pass avviene prima del gate. Se la eval fallisce, il costo c'era e la risposta no. Questa è onestà di ledger, non un biglietto di proof of work.