RSI-Jev vs Jev 1.13: En du laddar ner, en du anropar

Ställ RSI-Jev v6.1-VL 4B och Jev 1.13 sida vid sida och det första en anropare lägger märke till är att de är samma begäran. Ge endera ett tillstånd och en uppsättning typade frågor – ja/nej, välj en av k, betygsätt enligt en bedömningsmall – och båda returnerar en kalibrerad sannolikhet för varje alternativ, i en enda framåtpassning, utan genererad text att tolka. Det är ingen slump: RSI-Jev är byggd för att medvetet tala Jevs wire-format, så en klient skriven mot TypeSafes API kan köras mot den genom att ändra en bas-URL. Det som inte är samma är allt runt anropet. Jev 1.13 är TypeSafes slutna kommersiella modell, som serveras från en slutpunkt som du mäter; RSI-Jev v6.1-VL är en checkpoint med 4,69B parametrar med vikter under Apache-2.0 som du laddar ner och serverar på din egen hårdvara. Ingen av dem är en rebranding av den andra, ingen av leverantörerna rekommenderar den andra, och nästan varje siffra i den här jämförelsen kommer från den part som producerade den.

Datumet i ämnesraden spelar roll, eftersom det här projektet släpper ungefär en release varje dag. RSI-Jev v6.1-VL 4B publicerades 2026-10-07 av tredjepartsprojektet Shanghua-Gao/RSI-Jev — en självförbättrande forskningsloop som tränar Jev-liknande beslutsmodeller och publicerar varje arm som misslyckades tillsammans med de som vann. Det är den åttonde releasen på tretton dagar i den serien, och den är ett viktat medelvärde av den föregående releasen med en andra finjustering av samma Qwen3.5-4B-Base. Jev 1.13 är TypeSafe AI:s modell, lanserad 2026-09-15 och har funnits i vår egen katalog sedan 2026-09-24. Båda datumen spelar roll nedan, eftersom en jämförelse mot ett projekt som rör sig dagligen har en hållbarhet som mäts i dagar.

Vad de två egentligen är, i en rad var

Jev 1.13 är en hostad beslutsmodell bakom en dedikerad slutpunkt – POST /v1/systemone, utan strömning, ungefär 64 000 tokens i indatabudget sammanlagt för tillståndet och alla dina frågor, prissatt till $0,042 per miljon indatatokens med utdata debiterad till noll eftersom det inte finns några utdatatokens. Dess arkitektur, parameterantal och beräkningskraft för träning är inte offentliggjorda; TypeSafe har sagt att detaljerna hålls hemliga och att en artikel kan följa. Du kör den inte. Du anropar den, och varje anrop är en nätverksbegäran som mäts.

RSI-Jev v6.1-VL är det andra upplägget i sin helhet. Det är ett Qwen3.5-4B-Base-torn som finjusterats från början till slut, med beslutshuvuden i lager 16, 20 och 32, och som serveras från en fristående checkpoint på 9,7 GB i bf16. Parameterantalet är 4,69B och det är värt att veta var det tar vägen: 3,57B i de 32 avkodarlagren, 0,64B i tokeninbäddningarna, 0,33B i visionstornet, 0,05B i det huvudsakliga beslutshuvudet och 0,10B i de två huvudena för tidig utgång. Det finns ingen mixture of experts och ingen andra modell. Du installerar den med ett pip-kommando från repot, kör dess server, och från den stunden lämnar beslutet aldrig din infrastruktur.

• Vem som kör det — en mätarbaserad hostad endpoint som du inte kontrollerar vs en 9,7 GB checkpoint på din egen GPU, Apple Silicon eller CPU.

• Prismodell — 0,042 USD per miljon indatatoken, utdata gratis, betalas per anrop kontra noll vid marginalen plus kostnaden för maskinen och driften.

• Indatabudget — cirka 64 000 tokens per begäran på den hostade modellen jämfört med 32 768 texttokens plus en bildbudget på checkpointen, där längre texter avvisas i stället för att trunkeras.

• Vikter och licens — sluten, oangiven storlek mot Apache-2.0-vikter, MIT-kod, 4,69 miljarder parametrar.

• Modalitet — text för Jevs kontrakt jämfört med text plus upp till fyra bilder per begäran i RSI-Jevs vision-släpp.

• Ägande — TypeSafe AI:s kommersiella modell kontra ett forskningsprojekt från tredje part som i sin egen licensrad anger att det "Inte är associerat med TypeSafe AI."

Poängen på RSI-Jevs egen resultattavla, och varför den bara är en halv jämförelse

Siffran som projektet lyfter fram är dess Decision Index 0.3-poäng: 50,98 för v6.1-VL 4B, upp från 46,23 för utgåvan före den. Det är en full körning av standardkonfigurationen – 140 178 anrop, täckning 1,0 – och på projektets egen offentliga resultattavla, daterad 2026-10-06, tangerar den den bästa 4B-modellen på den tavlan (50,98 mot ezjev 4B s2:s 50,82, vilket verktygssatsen betraktar som oavgjort vid 0,25) och ligger på 27:e plats av 113 totalt. På den äldre Decision Index 0.2.1 står den på 50,74 mot v6.0-VL:s 46,24. Dess svit på femton benchmarks, rapporterad utan open_jev_ood-uppgiften som visade sig överlappa träningsrader, är 0,793, och dess holdout-uppsättning är 0,729.

Vart och ett av dessa tal är RSI-Jevs eget, uppmätt i RSI-Jevs testbänk. Decision Index är en offentlig resultattavla för benchmarks, men det finns inget mätvärde för Jev 1.13 på den, eftersom projektets testsvit byggdes för att poängsätta öppna beslutscheckpoints och Jev är en sluten endpoint. Så frestelsen att ställa 50,98 mot Jevs 0,727 i benchmarken för typade beslut och utropa en vinnare är precis misstaget att undvika: dessa två tal kommer från olika testbänkar, olika urvalsstorlekar och olika data, och ingen har kört en och samma testbänk på båda modellerna.

Den enda direkta jämförelsen som finns är Layas, inte RSI-Jevs

Det finns en publicerad jämförelse som faktiskt ställer ett Jev-nummer bredvid en öppen checkpoint, och den utfördes inte av någon av parterna här. Convai Innovations, skaparna av beslutsmodellen Laya, tabellerade TypeSafes publicerade Jev 1.13.0-siffror mot sina egna och påpekade själva begränsningarna: Jev-numren är publicerade av tredje part och mättes aldrig av Convai, urvalsstorlekarna och prompterna skiljer sig, och leverantören listar inte sina egna riktmärken för modellen. Den tabellen är värd att läsa för kalibrering, inte för en dom — och den inkluderar inte RSI-Jev alls, eftersom RSI-Jev inte existerade när den publicerades.

Vad den faktiskt visar är formen på frågan om hostat kontra öppet som en läsare faktiskt överväger. Den hostade modellen leder där valmöjlighetsutrymmet är stort och modellen måste hålla en bred svarsuppsättning stabil; de öppna modellerna vinner på rå latens per anrop eftersom det inte finns något nätverk i vägen. Ingenting i det mönstret säger dig vilken av dessa två specifika modeller som är bättre på din uppgift, och den ärliga ståndpunkten är att svaret ännu inte finns offentligt.

Vad kontrollpunkten ger som slutpunkten inte kan

Det starkaste argumentet för RSI-Jev är inte en poäng. Det är att vikterna ligger på din disk. För ett routingbeslut som fattas utifrån en medicinsk journal, ett juridiskt dokument eller en kunds kontohistorik är ”datan lämnar aldrig byggnaden” inte en preferens du byter bort mot en benchmarkpoäng — det är ett hårt krav, och ingen hostad slutpunkt till något pris uppfyller det. Samma egenskap tar bort rate limiten: leverantörens egen dokumentation för den hostade modellen noterar att dess gränser justeras dynamiskt och kan ändras utan förvarning, och en självhostad checkpoint har inget sådant tak utöver din hårdvara.

Det andra som kontrollpunkten ger är djupkontroll, och det är ovanligt. Eftersom beslutshuvudena sitter på tre djup, en ansträngningsinställning väljer hur många lager en begäran får använda: låg stannar vid lager 16 vid cirka 23 ms median, medel vid 20 i 27 ms, hög vid 32 i ungefär 40 ms, och auto svarar vid den första utgången som är tillräckligt säker, i genomsnitt 19,5 av 32 lager i projektets svit. Dessa latenser är projektets egna siffror uppmätta på en H200 i bf16 och bör inte blandas med någon hostad siffra — en lokal framåtpassning och ett avgiftsbelagt API-anrop är inte samma mätning, och RSI-Jevs egen dokumentation är tydlig med att dess tidigare jämförelse mot Jevs publicerade latens ställde lokalt GPU-arbete mot en nätverksrundresa.

Den tredje saken är bilderna. Jevs kontrakt är text in, strukturerad JSON ut. RSI-Jevs visionssläpp tar emot ett till fyra bilder per begäran som base64-data-URL:er, där tillståndet refererar till var och en med en markör, och v6.1-VL får 0,834 på projektets held-out-bildset. Om ditt beslut är "visar fotot synlig skada", är det en förmåga som det värdbaserade kontraktet inte erbjuder alls.

Det du avstår från är också verkligt, och projektet publicerar det. Kalibreringen blev sämre i den här versionen, inte bättre: det slutliga förväntade kalibreringsfelet är 0,048 vid lager 32 och 0,055 med auto, mot 0,036 och 0,024 för den föregående versionen. Den förvalda enskilda tröskeln på 0,95 levereras uttryckligen obekräftad – den är reservvalet i en urvalsregel vars eget val, 0,85, missade projektets djupgräns på hälften av dess utvecklingsdata. De tidiga utgångarna läser endast text, så alla frågor med en bild kör alla 32 lager oavsett ansträngning. Och fem av bildträningskällorna är icke-kommersiella eller endast för forskning, och projektet säger rakt ut att det inte är avgjort huruvida vikter tränade på icke-kommersiell data ärver dessa villkor.

Var man ska anropa den hostade, och var man inte ska

Detta är den del av jämförelsen som vi har ett intresse av, så det är värt att vara precis. Vi serverar TypeSafe:s kommersiella modell som typesafe/jev-1.13 på den dedikerade systemone-slutpunkten — en POST till /v1/systemone snarare än OpenAI chat-completions-formen, icke-strömmande, mot den 65 536-tokenkontext som vår katalog listar. Det är samma förfrågnings- och svarsform som RSI-Jev implementerar, från den modell vars kontrakt projektet kopierar. RSI-Jev självt är vi inte värd för; det finns inget rsi-jev-id och inget shgao-id i vår katalog, och en läsare som vill ha den modellen laddar ner den.

Anledningen till att den distinktionen spelar roll här är snäv och konkret. Ett beslutslager är sällan hela arbetsflödet – det ligger vanligtvis bredvid en generativ modell som skriver svaret, sammanfattningen eller koden. Det har historiskt inneburit två kontrakt. För den hostade halvan behöver det inte längre vara så: Jev 1.13 ligger på samma nyckel som 200+ andra modeller till leverantörens listpris vidarebefordrat med 0 % påslag, så om TypeSafe ändrar en taxa är ändringen live hos oss samma dag i stället för vid nästa faktureringscykel. Den självhostade halvan har aldrig haft det problemet, eftersom du är leverantören. Det renaste sättet att välja mellan dem är att först prova det kommersiella kontraktet på en handfull av dina egna märkta fall, se om beteendet direkt ur lådan är tillräckligt bra för att automatisera mot, och först därefter räkna ut om det är värt driftarbetet att köra en 4,69B-checkpoint själv.

Vilken du egentligen borde välja

Välj RSI-Jev v6.1-VL 4B om beslutet måste stanna inom din perimeter, om du behöver fatta beslut utifrån både bild och text, om dina alternativuppsättningar räknas i hundratal (checkpointen tillåter upp till 5 120 alternativ per fråga), eller om du vill finjustera djup och latens per begäran. Gå in i det med vetskapen att du adopterar ett projekt som flyttade åtta gånger på tretton dagar, att dess senaste utgåva bytte kalibrering mot noggrannhet, och att dess eget kort namnger de delar av exit-policyn som det inte kunde bekräfta.

Välj Jev 1.13 om du vill att beslutet ska fungera utan en serveringsstack, om du värdesätter en endpoint som någon annan håller igång, och om priset på $0,042 per miljon input – utan utdatatoken att mäta – är billigt i förhållande till din anropsvolym. Var medveten om att du anropar en sluten modell vars storlek inte är offentliggjord, vars hastighetsbegränsningar kan ändras utan förvarning, och vars publicerade benchmarks inte är något du kan köra om.

Det de båda har gemensamt är mer användbart än det som skiljer dem åt, och det är anledningen till att en jämförelse som denna överhuvudtaget är värd att skriva. Ingen av modellerna genererar text, så ingen av dem introducerar den typ av fel som uppstår från en modell som glömmer att stänga en klammerparentes eller hittar på ett fält. Båda returnerar sannolikheter, och i båda fallen är sannolikheten den del du måste validera på dina egna märkta data innan du automatiserar mot den — latensen är redan kommodifierad, och konfidensvärdet är det som måste förtjänas per driftsättning. Vilken sida av gränsen mellan nedladdning och anrop du än landar på, testa kalibreringen först.