ghfind ha messo MiniCPM-V 4.7 dietro i suoi roast su GitHub — e la sua stessa documentazione non concorda su cosa cambi

Scroll to the bottom of ghfind.com and there is a small line that did not used to be there: Model sponsor, a MiniCPM mark, and a link out to modelbest.cn. The model behind that mark is MiniCPM-V 4.7, OpenBMB's vision-language release from October 12, 2026. For a product whose entire pitch is a reproducible 0–100 "value and trust" score for any GitHub account, a model sponsorship is not a cosmetic detail — it is a question about what the model is allowed to touch. And ghfind's own documentation gives two different answers to that question. The documented AI failures and agent incidents behind releases like this one are collected in the OrcaRouter AI Incident Archive where each entry carries its own sources, severity, confidence grade and disputed flag.

Questa è la storia che vale la pena scrivere, perché la versione superficiale — «un sito di roast su GitHub ha cambiato modello» — è un comunicato stampa. La versione sotto riguarda un prodotto di scoring che deve convincere le persone che il suo numero non è frutto di sensazioni, adottando allo stesso tempo un modello linguistico.

Quello che la pagina mostra davvero, e quello che non mostra

La striscia degli sponsor è reale e visibile sulla homepage pubblica in inglese. Si trova accanto ad altri due controlli: un'opzione Usa il tuo modello / la tua chiave API, e slot vuoti per logo contrassegnati da Il tuo logo qui. Quindi la struttura che ghfind sta pubblicizzando non è "il nostro modello, obbligatorio" — è uno sponsor predefinito più una via di fuga bring-your-own-key, che è un design ragionevole per un prodotto che spende credito del modello a ogni roast.

Three things that get repeated about this change are not on the page. First, ghfind publishes no traffic figure anywhere on the site, so any number describing its daily visits is coming from somewhere other than ghfind. Second, the phrase "main model" is not ghfind's — the page says Model sponsor. Third, and most usefully, the open-source repository still ships a different default entirely: its .env.example configures the roast LLM against StepFun's step-3.7-flash, with a D​eepSeek fallback for the case where the primary provider drops or rate-limits before any text streams. Anyone self-hosting ghfind from source gets that configuration, not a MiniCPM endpoint.

Quindi l'affermazione accurata è più ristretta e più interessante di quella ampia: sul prodotto ospitato, MiniCPM è lo sponsor del modello indicato per nome. Nel codice aperto, non è quello predefinito. Sono affermazioni diverse e solo la prima è supportata da ciò che un lettore può vedere.

Il prodotto, prima del modello

ghfind è un'applicazione Next.js, AGPL-3.0, con circa 260 stelle su GitHub e push continui nel corso della settimana in cui è stato scritto questo articolo. Il suo nucleo non è affatto un LLM. Un motore TypeScript deterministico — portato riga per riga da una skill Python open source chiamata github-account-value, con test di parità che vincolano le due implementazioni l'una all'altra — legge dati pubblici di GitHub e produce un punteggio lungo sei dimensioni ponderate: maturità dell'account, qualità dei progetti originali, qualità dei contributi, impatto sull'ecosistema, influenza sulla community e autenticità dell'attività. Dieci red flag per comportamenti di farming sottraggono da quel punteggio, con un peso maggiore sui segnali costosi da falsificare, come le pull request unite in repository non di proprietà dell'account, e un peso minore sui segnali economici da acquistare, come stelle e follower.

Il punto centrale di quel design è l'auditabilità. Dato lo stesso account GitHub e la stessa data di raccolta, il numero dovrebbe essere sempre lo stesso, per chiunque. È ciò che rende un punteggio utilizzabile per qualcosa come il triage di una coda di issue, cosa che ghfind fa anche tramite una GitHub App che etichetta le issue in arrivo con la fascia dell'autore.

Il punto in cui entra il modello è a valle: trasformare un risultato fisso in una battuta di roast, una serie di tag e un report scritto. È la parte che gli utenti catturano con uno screenshot e condividono, ed è la parte a cui una sponsorizzazione si collegherebbe naturalmente.

La contraddizione degna di nota

È qui che i due documenti si separano.

Il README del repository descrive due passaggi LLM separati: un giudice fattuale può applicare una calibrazione limitata di ±10, poi un redattore trasforma il risultato fisso in tag, nella riga di roast principale e nel report. Il redattore non può modificare il punteggio. Rileggi quella frase due volte. Al redattore è esplicitamente vietato spostare il numero, mentre al giudice è esplicitamente consentito spostarlo fino a dieci punti — su una scala di cento punti, cioè un decimo dell'intero intervallo.

Il file del sito stesso llms.txt, scritto per agenti e macchine, dice qualcosa di più forte: un motore completamente deterministico … Gli stessi input producono sempre lo stesso punteggio; nessun LLM tocca il numero.

Entrambe non possono essere vere contemporaneamente. O il passaggio del giudice esiste nel percorso predefinito e il limite di ±10 è reale, nel qual caso il punteggio è deterministico a meno di una calibrazione dipendente dal modello — oppure il giudice non è nel percorso predefinito e il README descrive una modalità opzionale. Ciò che non è in discussione è che il testo stesso del repository contempla che un modello abbia un'influenza limitata sul numero, mentre la descrizione leggibile dalla macchina rivolta al pubblico dice che non ne ha alcuna.

Questo conta di più, non di meno, perché ora nella pagina è indicato uno sponsor del modello. Se un modello può spostare un punteggio di dieci punti, allora quale modello stia effettuando la valutazione è una domanda che un utente ha il diritto di porre — non perché qualcuno stia barando, ma perché le dichiarazioni di riproducibilità sono forti solo quanto la loro eccezione documentata più debole. Un prodotto che pubblica una pagina di metodologia deve ai propri lettori una frase che stabilisca quale delle sue due descrizioni sia quella attuale.

Perché un modello di visione, per un prodotto testuale

La scelta di un modello multimodale per un sito di scoring GitHub sembra strana finché non si guarda ciò che viene effettivamente fornito al modello. A MiniCPM-V 4.7 non viene chiesto di leggere repository; gli viene chiesto di leggere un prompt. I modelli visione-linguaggio sono sempre più usati come giudici generali economici perché sono addestrati su input interlacciati e tendono a seguire bene le istruzioni per output strutturati, e perché un singolo modello che può anche accettare uno screenshot è utile nel momento in cui un utente incolla una cattura del profilo in un flusso di supporto.

C'è anche una logica di costo. La variante 35B-A3B attiva circa tre miliardi di parametri per token in una mistura di 256 esperti, e la variante 1B è un modello denso abbastanza piccolo da girare su un telefono. Per un prodotto il cui passaggio di tostatura scatta a ogni scansione del profilo, un modello che puoi servire a basso costo — o eseguire tu stesso — è una proposta economica diversa da una chiamata API di frontiera per ogni tostatura. È lo stesso motivo per cui il sito offre un percorso bring-your-own-key: il conto del modello scala con il traffico, e il traffico è ciò che un sito di scoring cerca di far crescere.

Se stai costruendo tu stesso quel tipo di pipeline — un nucleo deterministico con sopra uno strato di narrazione supportato da modelli — la domanda operativa è per quanti provider vuoi detenere le chiavi. OrcaRouter mette oltre 200 modelli ospitati dietro un unico endpoint compatibile con OpenAI a markup 0%, con il prezzo di listino di ogni provider trasferito direttamente e failover automatico quando un provider peggiora; il suo DSL di routing può inviare il passaggio economico del giudice e il passaggio più costoso dello scrittore a modelli diversi all'interno di una singola chiamata. Un limite onesto: MiniCPM-V 4.7 non è nel nostro catalogo, quindi se è il modello che vuoi, devi andare sulla piattaforma di OpenBMB. Il router è la parte che mantiene caldo un percorso di fallback quando un singolo endpoint sponsorizzato è l'unica cosa tra te e un contenitore per arrosto vuoto.

Che cos’è realmente MiniCPM-V 4.7, a partire da questa settimana

Il lato del modello merita la stessa precisione. Il repository di OpenBMB presenta una voce News datata 2026-10-12 che recita «MiniCPM-V 4.7 rilasciato», e i repository Hugging Face sono stati creati nei giorni precedenti — il 6 ottobre per il 1B e il 7 ottobre per il 35B-A3B — che è l'aspetto di un caricamento scaglionato dei pesi. La model card seguì. Una seconda voce News il 2026-10-15 ha annunciato le teste di decodifica speculativa DSpark in BF16 e GGUF per entrambe le dimensioni.

• Dimensioni — mixture of experts sparsa 35B-A3B con 35,21 miliardi di parametri totali, e una variante densa 1B da 1,55 miliardi

• Licenza — Apache 2.0 su entrambi, pesi scaricabili, nessun gate

• Contesto — 262.144 token su entrambe le varianti

• Architettura — 256 esperti con 8 attivi per token nel modello da 35B; un pattern di attenzione da lineare a completa in rapporto 3:1 su 40 layer; torre visiva con larghezza hidden di 1152 e tile di input da 980 pixel

• Quantizzazione — build GGUF, bitsandbytes, AWQ, GPTQ, FP8 e int4 pubblicate insieme ai pesi BF16

• Serving — SGLang, vLLM, llama.cpp e Ollama sono elencati come supportati; Ollama dispone di una voce first-party

• Dichiarazioni del fornitore — oltre 13 token al secondo con circa 3 GB di memoria su un iPhone 17 Pro Max, e un'accelerazione di 5× sul dispositivo grazie a Lookahead Expert Scheduling

• Distribuzione — circa 95.000 download mensili sul repository 35B-A3B e 46.000 sul 1B, con circa 1.079 e 398 like

Tutto ciò che è presente in quell'elenco è verificabile dalla scheda e dal file di configurazione. Ciò che non è ancora disponibile è una valutazione indipendente. Il catalogo dei modelli di Artificial Analysis non contiene alcuna voce per nessuna delle due varianti di MiniCPM-V 4.7 al momento della stesura, quindi il valore di 13 token al secondo, l'accelerazione di 5× e l'affermazione secondo cui 35B-A3B «ottiene un punteggio complessivo più alto in meno tempo di inferenza rispetto a Qwen3.6 35B-A3B» sono tutti dati dichiarati dal fornitore e non riprodotti. È normale per un modello vecchio di otto giorni, ed è il motivo per cui lo spazio dello sponsor va considerato un segnale sulla struttura dei costi di ghfind piuttosto che sulla qualità del modello.

La parte che nessuno può ancora verificare

Il che ricongiunge le due metà di questa storia. La credibilità di ghfind si basa su un numero che dichiara essere riproducibile. La credibilità di MiniCPM-V 4.7 si basa su benchmark pubblicati dal suo fornitore una settimana fa. La sponsorizzazione le unisce senza alcuna prova pubblicata su come il modello si comporti come giudice: nessun tasso di accordo rispetto a valutatori umani, nessuna misurazione della deriva tra versioni del modello, nessuna dichiarazione sul fatto che cambiare lo sponsor modificherebbe il punteggio di qualcuno.

Sono tutte cose economiche da pubblicare e costose da sentirsi chiedere in seguito. La misurazione specifica che lo risolverebbe è un test di ri-punteggio: prendere un campione fisso di account, eseguire la pipeline con il passaggio del giudice abilitato e disabilitato, e riportare la distribuzione della differenza. Se si concentra sullo zero, il ±10 è una barriera di sicurezza che nessuno supera e la frase «nessun LLM tocca il numero» è di fatto vera. Se si disperde, la calibrazione sta facendo un lavoro concreto e la pagina della metodologia deve dirlo.

Fino ad allora, la lettura onesta è questa. ghfind è uno scorer deterministico ben costruito, con una separazione insolitamente netta tra il suo numero e la sua prosa, e ora ha uno sponsor del modello nominato il cui ruolo nella pipeline è documentato in modo incoerente tra i suoi stessi file. MiniCPM-V 4.7 è una release multimodale reale, con licenza Apache, davvero leggera in memoria, arrivata otto giorni fa con una model card, un follow-up DSpark e nessun benchmark indipendente. Nessuno dei due fatti è uno scandalo. Entrambi sono il genere di cose che noti solo quando leggi il repository invece della homepage — il che, per un prodotto che valuta il lavoro altrui, è il minimo che un lettore possa fare.

Come controllare il proprio punteggio, concretamente

Se hai un profilo sul sito, il percorso deterministico è quello da testare. ghfind espone un endpoint di punteggio che non richiede autenticazione né chiamate al modello, e la skill di scoring sottostante è open source, quindi il numero che ottieni dall'API e quello che ottieni dal sito dovrebbero coincidere. Se non coincidono, la differenza è dovuta o alla tempistica di raccolta — il sito mette in cache per un giorno — oppure al passaggio di calibrazione, e questi due casi si distinguono chiedendosi se lo scarto è stabile su esecuzioni ripetute.

Per chiunque costruisca uno strumento simile, la lezione architetturale di ghfind vale più delle notizie sul modello: tieni il numero nel codice, tieni la prosa in un modello e rendi il confine tra i due abbastanza esplicito che un lettore possa ispezionarlo. La modalità di fallimento non è usare un LLM. La modalità di fallimento è documentare il confine in due posti e lasciare che le due descrizioni divergano.

Cosa guardare dopo è un ambito ristretto. ghfind ha un changelog pubblico e un repository su cui si fa push quasi ogni giorno, quindi una nota metodologica che riconcili la calibrazione ±10 con la linea "no LLM" salterebbe fuori rapidamente. Sul fronte del modello, il primo benchmark indipendente di MiniCPM-V 4.7 — o il primo report su quanto costa per roast su larga scala — è il dato che trasformerebbe una sponsorizzazione in una discussione. Nessuno dei due esiste ancora. Entrambi distano una sola pubblicazione.