ghfind satte MiniCPM-V 4.7 bakom sina GitHub-roasts – och dess egen dokumentation går isär om vad det förändrar

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.

Det är historien som är värd att skriva, för ytversionen – "en GitHub-roastsajt bytte modeller" – är ett pressmeddelande. Versionen under ytan handlar om en poängsättningsprodukt som måste övertyga folk om att dess siffra inte är vibbar, samtidigt som den inför en språkmodell.

Vad sidan faktiskt visar, och vad den inte visar

Sponsorremsan är verklig och synlig på den offentliga engelska startsidan. Den står bredvid två andra kontroller: ett alternativ för att använda din egen modell / API-nyckel, och tomma logotypplatser märkta Din logotyp här. Så strukturen som ghfind annonserar är inte "vår modell, obligatorisk" – det är en standardsponsor plus en utväg där man tar med sin egen nyckel, vilket är en rimlig design för en produkt som gör av med modellkredit på varje 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.

Så det korrekta påståendet är snävt och mer intressant än det breda: i den hostade produkten är MiniCPM den namngivna modellsponsorn. I den öppna koden är den inte standard. Det är olika påståenden och endast det första stöds av vad en läsare kan se.

Produkten, före modellen

ghfind är en Next.js-applikation, AGPL-3.0, cirka 260 stjärnor på GitHub, med kontinuerliga pushes under veckan då detta skrevs. Dess kärna är inte en LLM alls. En deterministisk TypeScript-motor – portad rad för rad från en Python-skill med öppen källkod som heter github-account-value, med paritetstester som låser samman de två implementationerna – läser offentliga GitHub-data och producerar en poäng över sex viktade dimensioner: kontots mognad, originalprojektets kvalitet, bidragskvalitet, ekosystempåverkan, communityinflytande och aktivitetsautenticitet. Tio röda flaggor för farmingbeteende dras av från detta, viktade mot signaler som är dyra att fejka, som pull requests som slagits samman i repon som kontot inte äger, och bort från signaler som är billiga att köpa, som stjärnor och följare.

Hela poängen med den designen är spårbarhet. Med samma GitHub-konto och samma insamlingsdatum ska numret vara samma nummer varje gång, för alla. Det är det som gör en poäng användbar för något som att triagera en ärendekö, vilket ghfind också gör via en GitHub App som märker inkommande ärenden med författarens band.

Det är nedströms som modellen kommer in: att förvandla ett fastställt resultat till en rostningsrad, en uppsättning taggar och en skriftlig rapport. Det är den delen som användare tar skärmdump på och delar, och det är den delen som en sponsring naturligt skulle knyta an till.

Motsägelsen som är värd att lägga märke till

Här skiljer sig de två dokumenten åt.

Repositoryts README beskriver två separata LLM-genomgångar: en faktabaserad bedömare får tillämpa en begränsad ±10-kalibrering, sedan omvandlar en skribent det fastställda resultatet till taggar, den främsta roast-repliken och rapporten. Skribenten kan inte ändra poängen. Läs den meningen två gånger. Skribenten är uttryckligen förbjuden att flytta siffran, och bedömaren är uttryckligen tillåten att flytta den med upp till tio poäng — på en hundragradig skala är det en tiondel av hela intervallet.

Webbplatsens egen llms.txt, skriven för agenter och maskiner, säger något starkare: en helt deterministisk motor … Samma indata ger alltid samma poäng; ingen LLM rör talet.

Båda kan inte vara sanna samtidigt. Antingen finns domarpasset i standardvägen och ±10-gränsen är verklig, i vilket fall poängen är deterministisk upp till en modellberoende kalibrering – eller så finns domaren inte i standardvägen och README beskriver ett valfritt läge. Det som inte är omtvistat är att repots egen text förutser att en modell har begränsat inflytande över siffran, medan den utåtriktade maskinläsbara beskrivningen säger att den inte har något.

Detta är viktigare, inte mindre, eftersom en modellsponsor nu anges vid namn på sidan. Om en modell kan förändra ett resultat med tio poäng, är vilken modell som utför bedömningen en fråga som en användare har rätt att ställa — inte för att någon fuskar, utan för att påståenden om reproducerbarhet bara är så starka som deras svagaste dokumenterade undantag. En produkt som publicerar en metodiksida är skyldig sina läsare en mening som avgör vilken av dess två beskrivningar som är aktuell.

Varför en visionsmodell för en textprodukt?

Valet av en multimodell för en sajt för GitHub-poängsättning verkar märkligt tills man ser vad modellen faktiskt får. MiniCPM-V 4.7 ombeds inte läsa repon; den ombeds läsa en prompt. Språk- och visionsmodeller används alltmer som billiga allmänna domare eftersom de tränas på interfolierade indata och tenderar att följa instruktioner för strukturerad utdata väl, och eftersom en enda modell som också kan ta emot en skärmbild är användbar i samma stund som en användare klistrar in en skärmbild av en profil i ett supportflöde.

Det finns också en kostnadslogik. 35B-A3B-varianten aktiverar ungefär tre miljarder parametrar per token i en expertblandning med 256 experter, och 1B-varianten är en tät modell som är liten nog att köras på en telefon. För en produkt där rostningspasset utlöses vid varje profilskanning är en modell som man billigt kan serva – eller köra själv – en annan ekonomisk kalkyl än ett API-anrop till en frontier-modell per rostning. Det är samma anledning till att webbplatsen erbjuder en bring-your-own-key-väg: modellräkningen skalar med trafiken, och trafiken är det som en poängsättningssajt försöker få att växa.

Om du bygger den typen av pipeline själv – en deterministisk kärna med ett modellbaserat berättarlager ovanpå – är den operativa frågan hur många leverantörer du vill hålla nycklar för. OrcaRouter placerar över 200 hostade modeller bakom en enda OpenAI-kompatibel endpoint med 0 % påslag, med varje leverantörs listpris som skickas rakt igenom och automatisk redundansväxling när en leverantör försämras; dess routing-DSL kan skicka den billiga bedömningsomgången och den dyrare skrivaromgången till olika modeller inom ett och samma anrop. En ärlig begränsning: MiniCPM-V 4.7 finns inte i vår katalog, så om det är modellen du vill ha får du gå till OpenBMB:s egen plattform för den. Routern är den del som håller en reservväg varm när en enda sponsrad endpoint är det enda som står mellan dig och en tom rostlåda.

Vad MiniCPM-V 4.7 faktiskt är, från och med den här veckan

Modelsidan förtjänar samma precision. OpenBMB:s repository innehåller en nyhetspost daterad 2026-10-12 med texten "MiniCPM-V 4.7 släppt", och Hugging Face-repositorierna skapades dagarna före det – 6 oktober för 1B och 7 oktober för 35B-A3B – vilket är precis hur en stegvis uppladdning av vikter ser ut. Modellkortet följde. En andra nyhetspost den 2026-10-15 aviserade DSpark speculative-decoding-huvuden i BF16 och GGUF för båda storlekarna.

• Storlekar — 35B-A3B gles expertblandning med 35,21 miljarder parametrar totalt, samt en 1B tät variant med 1,55 miljarder

• Licens — Apache 2.0 för båda, vikterna går att ladda ner, ingen åtkomstspärr

• Kontext — 262 144 tokens i båda varianterna

• Arkitektur – 256 experter med 8 aktiva per token i 35B; ett 3:1-mönster med linjär kontra full uppmärksamhet över 40 lager; visionstorn med 1152 dold bredd och 980-pixels ingångsplattor

• Kvantisering — GGUF, bitsandbytes, AWQ, GPTQ, FP8 och int4-byggen publicerade tillsammans med BF16-vikterna

• Servering — SGLang, vLLM, llama.cpp och Ollama listas som stödda; Ollama har en förstapartspost

• Leverantörens uppgifter – 13+ tokens per sekund med cirka 3 GB minne på en iPhone 17 Pro Max, och en 5× hastighetsökning på enheten från Lookahead Expert Scheduling

• Distribution — ungefär 95 000 månatliga nedladdningar på 35B-A3B-förvaret och 46 000 på 1B, med cirka 1 079 och 398 gillningar

Allt i den listan går att kontrollera utifrån kortet och konfigurationsfilen. Det som ännu inte finns tillgängligt är en oberoende utvärdering. I Artificial Analysis modellkatalog finns ingen post för någon av MiniCPM-V 4.7-varianterna när detta skrivs, så siffran på 13 tokens per sekund, hastighetsökningen på 5× och påståendet att 35B-A3B "uppnår en högre totalpoäng på kortare inferenstid än Qwen3.6 35B-A3B" är alla leverantörsrapporterade och inte reproducerade. Det är normalt för en modell som är åtta dagar gammal, och det är anledningen till att betrakta sponsorplaceringen som en signal om ghfinds kostnadsstruktur snarare än som en signal om modellkvalitet.

Delen som ingen ännu kan verifiera

Vilket för samman de två halvorna av den här berättelsen. ghfinds trovärdighet vilar på en siffra som den uppger är reproducerbar. MiniCPM-V 4.7:s trovärdighet vilar på benchmarks som leverantören publicerade för en vecka sedan. Sponsringen förenar dem utan några publicerade bevis för hur modellen beter sig som domare – ingen överensstämmelsesgrad mot mänskliga bedömare, ingen driftmätning mellan modellversioner, inget uttalande om huruvida ett byte av sponsor skulle förändra någons poäng.

Det är allt billiga saker att publicera och dyra saker att få frågor om senare. Det specifika mått som skulle avgöra saken är ett ompoängsättningstest: ta ett fast urval av konton, kör pipelinen med domarpasset aktiverat och inaktiverat och rapportera fördelningen av skillnaden. Om den klumpar sig vid noll är ±10 en skyddsräls som ingen trampar på och raden "ingen LLM rör siffran" är i praktiken sann. Om den sprider ut sig gör kalibreringen verkligt arbete och metodsidan måste säga det.

Fram till dess är den ärliga tolkningen följande. ghfind är en välbyggd deterministisk poängsättare med en ovanligt tydlig separation mellan sitt tal och sin prosa, och den har nu en namngiven modellsponsor vars roll i pipeline dokumenteras inkonsekvent i dess egna filer. MiniCPM-V 4.7 är en verklig, Apache-licensierad, genuint minnessnål multimodell lansering som kom för åtta dagar sedan med ett modellkort, en DSpark-uppföljning och inga oberoende benchmarks. Inget av dessa faktum är en skandal. Båda är sådant man bara lägger märke till när man läser repot i stället för startsidan – vilket, för en produkt som betygsätter andras arbete, är det minsta en läsare kan göra.

Hur du konkret kontrollerar din egen poäng

Om du har en profil på webbplatsen är den deterministiska vägen den du bör testa. ghfind tillhandahåller en score-endpoint som inte kräver någon autentisering och inget modellanrop, och den underliggande poängsättningsfunktionen är öppen källkod, så siffran du får från API:t och siffran du får från webbplatsen bör stämma överens. Om de inte gör det är skillnaden antingen insamlingstidpunkten — webbplatsen cachar i en dag — eller kalibreringsomgången, och dessa går att skilja åt genom att fråga om gapet är stabilt över upprepade körningar.

För alla som bygger ett liknande verktyg är den arkitektoniska lärdomen från ghfind värd mer än modellnyheten: behåll siffran i koden, behåll prosan i en modell och gör gränsen mellan dem tillräckligt explicit för att en läsare ska kunna granska den. Felsättet är inte att använda en LLM. Felsättet är att dokumentera gränsen på två ställen och låta de två beskrivningarna glida isär.

Det som är värt att bevaka härnäst är begränsat. ghfind har en offentlig ändringslogg och ett repository som pushas de flesta dagar, så en metodnot som förenar ±10-kalibreringen med linjen "ingen LLM" skulle snabbt dyka upp. På modellsidan är den första oberoende benchmarken av MiniCPM-V 4.7 — eller den första rapporten om vad det kostar per rostning i volym — den siffra som skulle göra ett sponsoravtal till ett argument. Inget av det finns ännu. Båda ligger en publikation bort.