Laya vs Kev: Två recept för en lokal beslutsmodell

Den mest användbara siffran i jämförelsen mellan Laya och Kev är ett kvitto. Jared Palmer tränade Kev-familjen för ungefär 95 dollar i H100-tid på Modal, plus ungefär tre cent i API-anrop för utvärderingsdata, och publicerade receptet tillsammans med vikterna. Convai Innovations tog den andra vägen med Laya: släppt den 18 september 2026, tre dagar efter TypeSafe AI:s Jev, Apache 2.0, vikter på Hugging Face, en pip install laya ingångspunkt, och ingen träningspipeline – en engelskspråkig checkpoint på 421M av ModernBERT-large, en flerspråkig checkpoint på 322M av mmBERT-base, och en router som väljer mellan dem. Kev är en familj av tre små modeller på 0,8B, 4B och 9B, var och en en frusen bas plus en LoRA-adapter av rang 16 och ett litet pekarhuvud. Båda svarar på typade frågor i en framåtpassning och ingen av dem genererar text. Valet mellan dem är egentligen ett val om vilken artefakt du vill äga: en checkpoint eller ett recept.

Vad varje projekt faktiskt levererar

Laya levererar inferens. Den engelska checkpunkten är en dubbelriktad encoder med ett fönster på 512 tokens; den flerspråkiga täcker över 100 språk med ett fönster på 1 024 tokens och körs ungefär dubbelt så snabbt; routern identifierar skrift på under en halv millisekund. Den svarar på val, poäng och noul – ett val från en lista, en förväntad nivå på en ordnad bedömningsskala och en kalibrerad sannolikhet att ett påstående är sant. Det finns en tredje checkpunkt, laya-typed-decisions, som är samma 421M-stommme finjusterad på träningsdelen av typed-decisions-benchmarken. Convais eget modellkort innehåller meningen som bör styra hur du läser varje Laya-siffra: ”Laya är en snabb bas att specialisera, inte en nollskotts-beslutsmotor.”

Kev levererar en metod. Repositoriet dokumenterar decision-v7: två epoker över 10 000 exempel hämtade från tio offentliga datamängder, 896 genererade policyexempel och 1 680 exempel byggda från 60 genererade regelstrukturer. Huvudet poängsätter varje angivet alternativ mot frågans decide-token och softmaxar resultatet. Eftersom Qwen3.5-checkpointarna blandar attention med återkommande Gated DeltaNet-lager som ignorerar attention-masker, körs varje fråga som sin egen rad med det delade tillståndet beräknat en gång och cachelagrat — vilket är hur modellen håller frågor isolerade från varandra utan att betala för en ny prefill per fråga. Kev speglar TypeSafes offentliga /v1/systemone kontrakt, så en befintlig TypeSafe SDK-klient kan peka mot en lokal Kev-server genom att ändra bas-URL:en. README-filen anger att inga Jev-utdata användes i träningen.

De två fellägena är olika, och det är den verkliga historien.

Båda modellerna förlorar mot Jev på uppgifter som kräver att man vet saker, men de förlorar på sätt som kräver olika åtgärder.

Layas publicerade svagheter handlar om inputens form. På TypeSafe:s typed-decisions-benchmark får den 0,362 zero-shot, mot 0,318 för slumpmässig gissning och 0,461 för majoritetsklass-baslinjen — närmare slumpen än det triviala svaret. Bortom ungefär tjugo alternativ faller den samman: 0,425 på Banking77 mot Jevs 0,870. Den är tillräckligt ordningskänslig för att en ren omkastning av alternativordningen sänkte noggrannheten med 13,75 punkter i ett tredjepartstest, vilket lämnade en samma-svar-andel på 42,5 %. Och de levererade checkpoints kommer med ogiltiga temperaturer — biblioteket varnar vid import, vilket betyder att kalibreringssiffran på modellkortet, ett förväntat kalibreringsfel på 0,466, är det tal du faktiskt får innan du återanpassar. Återanpassning per frågetyp tar det till 0,081, men det är arbete du utför, inte arbete som nedladdningen utför. Det finns ett publicerat flerspråkigt fel som är värt att läsa i sin helhet: på icke-latinska skrifter är den engelska checkpointen katastrofalt överkonfident, med ett khmer-exempel som visar 0,000 noggrannhet vid 0,952 genomsnittlig konfidens.

Kevs publicerade svagheter handlar om kunskap och aritmetik. Kev-9B får 0.837 på sitt eget låsta test med nya källor — 0.832 för 4B och 0.668 för 0.8B — och omkring 0.822 utanför domänen på dev-spliten mot Jevs 0.857. Glappet öppnar sig där världskunskap krävs: MMLU omkring 70 % mot Jevs 90 %, MMLU-Pro 0.515 mot 0.840, och datumaritmetik med dagsprecision 60 % mot 93 %. På en smal routinguppsättning med fasta etiketter vinner den — en utvärdering av supportärenderoutning placerade Kev-9B på 0.952 mot Jevs 0.897 — men författaren är tydlig med att detta är hans egen testrigg, att Jevs träningsdata inte är offentliggjord och att ingen kontrollerad jämförelse därför kan konstrueras. Kev förblir också överdrivet självsäker på nya källor; att sätta KEV_TEMPERATURE=2.0 minskade självsäkra fel från 8,7 % till 4,4 % i projektets egen testning, vilket säger dig att standardinställningen inte är den säkra inställningen.

Den praktiska tolkningen: Layas misslyckande utlöses av din uppsättning alternativ och din promptformatering, och du åtgärdar det genom finjustering och omanpassning. Kevs misslyckande utlöses av frågor som kräver fakta, och du åtgärdar det genom att avgränsa modellen till routning och klassificering och lägga de kunskapsberoende anropen någon annanstans. Ingen av lösningarna är en konfigurationsflagga.

Vad som krävs för att tjäna dem

• Hårdvara — Laya: 421M/322M-kodare, trovärdig på CPU vid låg genomströmning och under en gigabyte i minne för MLX-porten på Apple silicon. Kev: 0,8B till 9B, kräver en BF16 CUDA-GPU för 9B, med Qwen3.5-arkitekturen som kräver flash-linear-attention på CUDA och ROCm.

• Latens — Laya: 32,8 ms p50 per beslut på en Tesla T4, 7,2 ms per fråga vid batch 10. Kev: cirka 300 ms för fem skrivna frågor från en 4B-modell på en 32 GB Mac i bf16, ungefär 40 ms på en H100.

• Tak — Laya: 512-tokens engelskt fönster, 1 024 flerspråkigt. Kev: val över 1–255 alternativ, poäng över 2–255 nivåer, 384 träningstillståndstoken med 8 192 vid servering.

• Server — Laya: in-process Python, plus community-portar för ONNX, Go och Apple MLX. Kev: en lokal server bunden till 127.0.0.1 utan autentisering, ett npm-SDK samt LangChain- och LlamaIndex-adaptrar.

• Licens — Apache 2.0 för båda.

Två operationella noteringar som inte syns i rubriksiffrorna. Kevs server tar emot en begäran i taget och är oautentiserad till sin konstruktion – det är en lokal sidecar, inte något man exponerar. Och Kevs Mac-latens är väsentligt sämre än dess H100-latens eftersom de snabba DeltaNet-kärnorna ännu inte finns för MLX, vilket är precis den typ av detalj som förvandlar ett "körs lokalt"-påstående till ett "körs lokalt på rätt hårdvara"-påstående.

Den generativa halvan av mönstret

Båda dessa modeller finns för att ersätta ett specifikt anrop: LLM-anropet du gjorde enbart för att få tillbaka en etikett eller en sannolikhet. De ersätter inte anropen där du faktiskt behöver prosa. Ett supportsystem som använder Kev-9B för att routa ett ärende behöver fortfarande en modell för att sammanfatta tråden och skriva svaret, och den modellen kommer inte att vara en 9B LoRA med ett pointer-head.

Det är den skarv som OrcaRouter sitter i, snarare än ett påstående om att vara värd för endera av dessa. Varken Laya eller Kev finns med på vår modelllista – de är vikter du laddar ner – och artikeln skulle vara vilseledande om den antydde något annat. Det som finns på listan är de 200+ generativa modellerna bakom en OpenAI-kompatibel nyckel till leverantörens listpris vidarebefordrat med 0 % påslag. Om du använder Kev för att avgöra vilken av tre sammanfattningsnivåer en begäran hör hemma i, eller använder Laya för att bedöma om ett svarsutkast är godtagbart, är den generativa sidan av båda looparna en enda slutpunkt med automatisk failover i stället för ett andra kontrakt och ett andra SDK. Routing-DSL är den del som passar mest naturligt i en beslutsmodellarkitektur: sätt samman en billig modell och en dyr till ett enda anrop och låt beslutsmodellens utdata välja grenen.

Vad du ska titta på härnäst

Luckan i bevisningen är densamma för båda, och den kommer inte att täppas igen av någotdera projektet. Ingen har kört Laya och Kev på byte-identiska indata med samma prompter, samma ordning på alternativen och samma svep över konfidenströsklar. Layas främsta framgångar kommer från dess eget testramverk; Kevs anspråk på nästan jämbördighet kommer från upphovspersonens testramverk; kalibreringsgranskningen som fann att Jevs kalibrering varierade kraftigt mellan uppgifter – 44,7 % träffsäkerhet och 0,325 förväntat kalibreringsfel på en prioriteringsuppgift med dold policy – var utförd av en tredje part, och varken Laya eller Kev har genomgått den behandlingen. Tills någon gör det är siffrorna ovan de bästa som finns att tillgå, och de är inte jämförbara med varandra.

Om du bestämmer dig i dag: välj Kev om du vill ha en fungerande routingmodell den här veckan på en GPU du redan hyr, och acceptera att den inte kommer att veta saker. Välj Laya om dina indata är flerspråkiga eller om din hårdvarubudget är en bärbar dator, och budgetera finjusteringen som en del av projektet i stället för som en senare optimering. Oavsett vilket: mät på dina egna märkta data innan du sätter en konfidenströskel framför produktionstrafiken — båda projekten säger i sin egen dokumentation att du ska göra det.