Clef vs MathForm-8B: Den ena svarar på din fråga, den andra skriver ett bevis

Anledningen till att ställa Cloudflare/clef bredvid openbmb/MathForm-8B är att de är de två sakerna som lättast förväxlas inom öppna vikter just nu, och att förväxla dem kostar en träningskörning. Båda är finjusterade modeller byggda på Qwen3.8-27B- respektive Qwen3-8B-checkpoints. Båda är Apache-2.0. Båda publicerades under de senaste tio veckorna. Båda är smala, ändamålsbyggda och beskrivs av sina skapare som specialiserade snarare än generella. Och de har absolut ingenting med varandra att göra, eftersom den ena producerar ett nummer valt från en lista du angav och den andra producerar Lean 4-källkod, token för token, för en bevisassistent att kontrollera.

Clef är Cloudflares multimodala beslutsmodell med 27 miljarder parametrar: du ger den ett tillstånd och ett schema av typade frågor, och den returnerar en kalibrerad sannolikhet för varje tillåtet svar i en enda icke-autoregressiv genomkörning, utan någon textgenerering någonstans i kedjan. MathForm-8B, från OpenBMB, är en autoformaliseringsmodell – ett matematiskt påstående i naturligt språk går in, Lean 4 kommer ut, och pipelinen som tränade den beskrivs i en arXiv-förprint som publicerades tillsammans med vikterna den 14 augusti 2026. Den ena modellens tak är storleken på din lista med alternativ. Den andras tak är styrkan i Leans typteori. Att fråga vilken som är bättre är ett kategorimisstag, och att båda är finjusterade modeller med öppna vikter under Apache-2.0 och mellan åtta och tjugosju miljarder parametrar är precis vad som gör misstaget lätt att begå.

Vad varje modells gränssnitt fysiskt förbjuder

Det snabbaste sättet att se uppdelningen är att läsa vad var och en kan returnera.

• Indata — Clef tar ett tillstånd (text, JSON, bilder eller videobildrutor) plus 1 till 64 namngivna typade frågor; MathForm-8B tar ett matematiskt påstående i naturligt språk.

• Utdata — Clef returnerar en sannolikhet per tillåtet alternativ, softmaxad per fråga. MathForm-8B returnerar Lean 4-källkod.

• Frågetyper — Clefs är noul (sant/falskt, med sannolikheten för sant), val (2 till 26 namngivna alternativ) och poäng (2 till 26 ordnade nivåer); MathForm-8B har inget frågekoncept alls.

• Kalibrering — Clef publicerar ett konfidensfält per svar; MathForm-8B publicerar Pass@8-frekvenser under syntax- och konsekvenskontroller.

• Servering — Clef serveras via en Jev/SystemOne-kompatibel POST /v1/systemone body, hostad eller självkörd; MathForm-8B levereras med instruktioner för Transformers, vLLM och SGLang, som alla exponerar en OpenAI-kompatibel completion-endpoint vid en kontext på 16 384 token med max_new_tokens satt till 16 384.

Den praktiska konsekvensen framgår omedelbart. Om du behöver ett ja/nej-omdöme om en text, är Clef den enda av de två som kan producera det – det finns inget sätt att ställa en fråga till MathForm-8B som inte är "skriv Lean 4 för detta." Om du behöver Lean 4 är Clef den enda av de två som kategoriskt inte kan producera det, och inte på grund av svaghet: att be en schemabunden bedömare att formalisera ett teorem passar inte i dess kontrakt, så begäran avvisas genom konstruktion snarare än besvaras dåligt.

Pipelinen där båda hör hemma

Det finns en verklig arkitektur där dessa två modeller ligger sida vid sida, och det är värt att gå igenom eftersom den gör uppdelningen konkret i stället för abstrakt. Tänk dig en tjänst som formaliserar matematik för forskare och studenter.

Påståenden anländer i naturligt språk, obegränsade till sin art. Innan något kan formaliseras måste något avgöra vad som har anlänt. Är detta ett teorem att bevisa, en definition att lägga till, en begäran att kontrollera ett befintligt bevis, eller en fråga som behöver klarläggas innan någon rör vid Lean? Är det fristående, eller bygger det på kontext som användaren inte har tillhandahållit? Är symbolerna konventionella, eller är notationen något som systemet aldrig har sett? Var och en av dessa är en avgränsad fråga med en liten uppsättning alternativ – Clefs exakta form – och den kalibrerade sannolikheten som är knuten till varje svar är det som gör att tjänsten kan göra något vettigt med de osäkra: skicka allt under ett tröskelvärde till en människa i stället för att gissa.

Det andra steget tillhör MathForm-8B. Ta ett påstående som redan har klassificerats som ett fristående teorem med känd notation och generera Lean 4. Det är ett genereringsproblem, och kvalitetsfrågan är hur ofta utdata kompilerar och hur ofta det betyder samma sak som originalet – vilket är precis vad leverantörens två utvärderingsaxlar mäter. Detta är det allmänna mönstret värt att extrahera från parkopplingen: en billig avgränsad klassificerare framför en dyr specialiserad generator är vanligtvis billigare och mer tillförlitlig än att prompta generatorn att avgöra om den överhuvudtaget borde köra.

Vad siffrorna på varje sida faktiskt mäter

OpenBMB:s arXiv-sammandrag rapporterar att MathForm-8B uppnår genomsnittliga Pass@8-frekvenser på 88,06 % under Syntax Check och 72,37 % under Consistency Check över sex benchmarks, och att den på delmängderna FATE-H och FATE-X uppnår godkännandefrekvenser för konsistens på 63 % och 37 %, båda över de starkaste specialiserade baslinjerna som artikeln jämför mot. Träningspipelinen är den intressanta delen av påståendet: en hämtningsplanerare drar ut relevanta definitioner och befintliga formaliseringar ur Mathlib före generering, och genererade påståenden revideras sedan med hjälp av kompilatordiagnostik och återkoppling om semantisk konsistens, vilket är hur FormalVerse-datasetet med ungefär 367 000 verifierade Lean 4-exempel byggdes före övervakad finjustering och förstärkningsinlärning. Detta är leverantörsrapporterade siffror från en artikel och ett modellkort. Ingen oberoende part har kört om dem.

Clefs siffror mäter något helt annat och är inte jämförbara. Cloudflares Decision Index-körning rapporterar BANKING77 intent-macro-F1 på 94,2, CLINC150 med hantering av utanför-scope på 97,4, GPQA Diamond på 48,0 – där de äldre Jev-poängen är 78,3 – och en medianlatens för förfrågningar på 209,3 ms. Det är en tabell om klassificering och routning, framställd av leverantören på leverantörens egen svit, värd på leverantörens egen resultattavla, och oreproducerad.

Den enda ärliga mening man kan skriva om dessa två kolumner är att de inte delar någon benchmark, någon enhet eller någon utvärderingsfilosofi. MathForm-8B:s 37 % på en svår delmängd för formalisering och Clefs 97,4 på avsiktsigenkänning utanför tillämpningsområdet är båda verkliga påståenden från deras skapare om olika uppgifter, och en läsare som ställer dem bredvid varandra har inte lärt sig något annat än att båda talen finns.

Vad du skulle köra, och vad det kostar

Ingen av modellerna är en rutt på OrcaRouter, och den här artikeln gör inget anspråk på tillgänglighet – katalogen returnerar en 404 för cloudflare/clef och för MathForm-8B. MathForm-repositoriet upptar omkring 16,4 GB, och båda modellerna är Apache-2.0, så båda kan självhostas i morgon av vem som helst med hårdvaran.

• Clef på Cloudflare — 0,24 USD per miljon indatatoken på Workers AI, med den publicerade latensen mätt på en enda H200.

• MathForm-8B självhostad — ingen leverantörshosting, inget pris per token och en dokumenterad kontext på 16,384 token, vilket är en begränsning värd att uppmärksamma: ett långt avsnitt i en artikel får inte plats i en enda körning.

• Det routade alternativet för klassificerarhalvan — TypeSafe:s Jev 1.13 till $0.042 per miljon indatatokens över en kontext på 65 536 tokens, som serveras via samma POST /v1/systemone body som Clef använder, vilket gör det till en drop-in för det första steget i pipelinen ovan.

Det är där ett routinglager förtjänar sin plats i just den här kombinationen. Mönstret är en beslutsdel och en generator, och det är beslutsdelen som har en aktiv ersättning – en slutpunkt framför över 200 modeller, leverantörens listpris som förs vidare utan påslag per token, och automatisk redundansväxling så att en leverantörs dåliga eftermiddag inte blockerar ingången till din pipeline. Generatordelen är en artefakt på 16,4 GB som du kör själv, och ingen slutpunkt ändrar på det.

En sak till som storlekarna döljer

Parameterantalen inbjuder till en jämförelse som inte håller. Clef är 27B och MathForm-8B är 8B, så det är naturligt att anta att den större modellen är den mer kapabla och den mindre är specialisten. Det är det omvända till sin karaktär. Clef är stor eftersom den bär en fryst multimodal stomme som den behöver för att läsa skärmbilder och fakturor; den tränade delen ovanpå är ett litet schemahuvud med rank-256-adaptrar. MathForm-8B är liten eftersom Lean 4 är ett smalt mål och Qwen3-8B-basen räckte för att nå det, med det verkliga ingenjörsarbetet i hämtnings- och verifieringspipelinen som producerade dess träningsdata snarare än i dess parameterantal.

Storleken säger med andra ord vad varje modell var tvungen att bära, inte hur svårt problemet den löser är. En 27B som läser ett kvitto och returnerar "fakturering, 0,98" och en 8B som genererar kompilerbar Lean gör båda exakt det de byggdes för, och inramningen åtta miljarder mot tjugosju miljarder kommer att leda dig till fel modell ungefär hälften av gångerna.

Beslutet, och frågan som ingen av leverantörerna har besvarat

Om du har en pipeline som tar in obegränsat naturligt språk och behöver routa det innan du lägger beräkningskraft på det, är första draget en avgränsad klassificerare – Clef där dess multimodala indata spelar roll och dess siffror ser bra ut på dina data, eller Jev 1.13 där du vill ha samma form på förfrågan till ett lägre listpris och utan att binda din arkitektur till en leverantör vars utvärdering ingen har reproducerat. Andra draget är en specialiserad generator, och om den generatorn är Lean 4 är MathForm-8B den öppna modellen byggd för exakt det, med en publicerad pipeline och en korpus bakom sig.

Det som saknas på båda sidor är samma typ av bevis. Clefs Decision Index-körning är Cloudflares egen och har aldrig upprepats oberoende; MathForm-8B:s Pass@8-siffror kommer från dess egen artikel. Båda är ambitiösa påståenden inom ett område där det ärliga testet är billigt att beskriva och dyrt att köra – ta data som ingen av leverantörerna har tränat på, tillämpa samma pipeline och publicera resultatet. Tills någon gör det för någon av modellerna är det användbara som den här jämförelsen kan säga dig en form: en av dessa hör hemma i början av din pipeline och avgör vad som kommer in, och den andra hör hemma bakom den och gör det svåra, smala arbetet, och ingen av dem ersätter den andra oavsett antal parametrar.