Jev vs Laya: värdbaserat besluts-API vs lokal modell med öppen källkod (2026)

Jev och Laya utgår från nästan samma idé: många AI-arbetsflöden behöver inte ännu en modell som genererar text. De behöver ett snabbt svar på en avgränsad fråga som Vilket alternativ?, Hur stark är den här signalen? eller Ska det här arbetsflödet fortsätta?

Den största skillnaden handlar inte om riktmärkestesternas träffsäkerhet. Jev ger utvecklare en hanterad beslutstjänst. Laya ger dem öppna vikter som de själva kan köra, låsa och finjustera. Det påverkar integritet, svarstid, infrastruktur och var beslutslagret placeras i en AI-agent.

Om själva modellkategorin är obekant förklarar vår guide till arkitekturen för Jevs beslutsmodell varför typade beslut skiljer sig från vanlig LLM-generering. Den här jämförelsen fokuserar på den svårare frågan: vilken distributionsmodell passar din agent?

Jev jämfört med Laya: det korta svaret

För en molnansluten agent där du vill ha typade beslut utan att underhålla inferensinfrastruktur är Jev den enklare arkitekturen.

För privata lokala arbetsflöden, offlineagenter, domänspecifik finjustering eller tillämpningar där du behöver styra exakt vilken kontrollpunkt som används, ger Laya tillgång till en större del av stacken.

Frågan handlar därför mindre om vilken modell som är universellt bättre och mer om vem som ska äga beslutslagret.

Jev och Laya löser samma typ av problem

TypeSafe beskriver Jev som en System One-modell: programvara skickar tillstånd och en strukturerad fråga och får ett typat sannolikhetsbaserat beslut i stället för fritt formulerad text.

Den offentliga TypeSafe-introduktionen till Jev fokuserar på tre beslutsmönster: att välja mellan alternativ, poängsätta på en ordnad skala och utvärdera påståenden av typen ja eller nej.

Laya har medvetet stöd för ett liknande gränssnitt:

tillstånd
  ↓
inmatad fråga
  ↓
beslutsmodell
  ↓
sannolikhet / valt alternativ
  ↓
applikationspolicy
  ↓
åtgärd

Applikationen definierar åtgärdsutrymmet före inferensen. Då slipper man be en LLM för allmänna ändamål att skriva en förklaring och sedan tolka förklaringen till en maskinåtgärd.

Men strukturerade utdata gör inte någon av modellerna ofelbar. En beslutsmodell kan fortfarande välja fel alternativ, göra en felaktig bedömning av ett obekant fall eller lämna en dåligt kalibrerad konfidensnivå.

Ingen fri textgenerering är inte detsamma som inga modellfel.

Om du vill se exempel på hur utvecklare redan använder den här typen av beslutslager hittar du dirigering, webbläsarautomatisering, utvärdering och andra konkreta mönster i samlingen av verkliga användningsfall för Jev-agenter.

Den största skillnaden: Jev är en tjänst, Laya är en modell du äger

Jev når för närvarande utvecklare via TypeSafes värdtjänstbaserade API. Applikationen skickar strukturerat tillstånd och frågor till tjänsten och använder sedan de returnerade sannolikheterna och besluten.

din applikation
      ↓
valt tillstånd
      ↓
Jev API
      ↓
typat beslut
      ↓
applikationspolicy

Laya har motsatt inställning. Laya-projektet publicerar sina kontrollpunkter och sin körmiljö under Apache 2.0-licensen, vilket gör att själva beslutssteget kan köras på maskinvara som du kontrollerar.

din applikation
      ↓
valt tillstånd
      ↓
lokala Laya
      ↓
typat beslut
      ↓
applikationspolicy

Gränssnitten liknar varandra. Ägandemodellen gör det inte.

Jev ber dig att lägga ut inferensen på en extern tjänst. Laya ber dig att sköta inferensen själv.

Lokal AI: Laya förändrar integritetsgränsen

Skillnaden i driftsättning blir viktigare när tillståndet som klassificeras är känsligt.

En privat agent kan fatta beslut utifrån filmetadata, e-postmeddelanden, källkod, supportärenden, säkerhetsvarningar, hämtade dokument eller körningsspår.

Med Jev kan du minimera tillståndet som skickas till tjänsten, men den valda informationen passerar fortfarande inferensgränsen:

privata data
    ↓
lokal filtrering
    ↓
valt tillstånd
    ↓
Jev API
    ↓
beslut

Med Laya kan samma bedömning i det första steget göras lokalt:

privata data
    ↓
lokal filtrering
    ↓
lokala Laya
    ↓
beslut

Det här är det starkaste arkitektoniska skälet att utvärdera en öppen lokal beslutsmodell i stället för en värdtjänstbaserad slutpunkt.

Det gör inte automatiskt hela agenten privat. Ett senare steg kan fortfarande eskalera svåra fall till en molnbaserad LLM. Skillnaden är att rutinmässig filtrering, dirigering och poängsättning inte längre behöver lämna maskinen.

Jev tar bort modellhanteringen; Laya ger dig kontroll över den

Lokal inferens medför också ett operativt ansvar.

En Jev-integration är i första hand ett applikationsproblem:

definiera tillstånd
→ definiera fråga
→ anropa API
→ använd resultatet

En Laya-driftsättning kräver också att du hanterar modellens livscykel: val av kontrollpunkt, körningsberoenden, CPU- eller GPU-resurser, batchbearbetning, samtidighet, övervakning, modelluppgraderingar och eventuell anpassad finjustering.

Därför bör ”lokal” inte automatiskt betraktas som bättre.

Om din applikation fattar ett begränsat antal beslut och redan använder externa AI-API:er kan driften av ytterligare en inferensstack innebära mer komplexitet än nytta.

Om integritet, reproducerbarhet, offline-drift eller specialisering ingår i kraven blir den operativa kontrollen skälet till att själv vara värd för modellen.

Laya är en modellfamilj, inte en enda modell med 421 miljoner parametrar

Laya sammanfattas ofta som en beslutsmodell med 421 miljoner parametrar, men det aktuella projektet tillhandahåller tre olika kontrollpunkter.

Projektet tillhandahåller också en Router som kan välja mellan kontrollpunkter. Det skapar en viktig arkitektonisk poäng: att köra beslutslagret lokalt eliminerar inte modelldirigering; det kan flytta dirigeringen närmare arbetsbelastningen.

inkommande förfrågan
      ↓
lokal dirigering
   ↙    ↓     ↘
Engelska  Flerspråkig  Specialiserad
 Laya       Laya          Laya
   ↘        ↓        ↙
        beslut

Detta följer samma övergripande mönster som att använda en liten lokal modell för dirigering: rutinärenden hanteras i en billigare, avgränsad väg, medan osäkra ärenden kan eskaleras.

Jev- och Laya-riktmärken måste läsas noggrant

Den starkaste publicerade jämförelsen för Laya kommer från den specialiserade kontrollpunkten laya-typed-decisions.

Modellkortet rapporterar 400 testfall med 2 000 beslut inom observerbarhet för agentspår, kundtjänst, fakturahantering och säkerhetsincidenter.

Den första raden gör det frestande att säga att Laya slår Jev. Det är en alltför bred slutsats.

Dokumentationen för Laya-riktmärket anger uttryckligen att Laya-kontrollpunkten finjusterades för dessa arbetsflöden och att Jev-siffrorna är publicerade tredjepartsreferenser, inte mätningar som gjorts om under identiska förhållanden.

Baskontrollpunkten för Laya får bara 0.362 i träffsäkerhet på samma test av typade beslut, medan den specialiserade kontrollpunkten når 0.766. Det gör specialiseringen till ett av de viktigaste resultaten i tabellen.

Riktmärket är starkare belägg för Layas potential vid finjustering än för en universell rangordning där Laya slår Jev.

Noggrannhet och kalibrering besvarar olika frågor

Beslutsmodeller returnerar sannolikheter, så noggrannhet ensam beskriver inte hur användbara de är.

Anta att en agent använder konfidensgränser:

≥ 0.90 → hantera automatiskt
0.60–0.90 → eskalera till en större modell
< 0.60 → begär mänsklig granskning

Nu påverkar sannolikhetskvaliteten arbetsflödet direkt.

I den publicerade jämförelsen av typade beslut har specialiserade Laya högre argmax-noggrannhet och bättre Brier-poäng, medan Jev har lägre rå ECE och högre mjuk noggrannhet.

De här måtten besvarar olika frågor. En modell kan oftare välja rätt alternativ och ändå återge osäkerhet mindre korrekt.

Det här spelar roll när sannolikheter avgör om en agent agerar, eskalerar eller avstår.

Svarstid: Lokal Laya och driftade Jev mäter olika förlopp

Laya rapporterar ungefär 33 ms för ett kort enskilt beslut och cirka 7,2 ms per fråga i en batched T4-konfiguration.

De här siffrorna är användbara för att förstå driftsättningsklassen, men de bör inte jämföras direkt med svarstiden för ett driftat API som om båda enbart mätte modellinferens.

En lokal lösning kan vara:

applikation
→ lokal inferens
→ resultat

En driftad lösning omfattar:

applikation
→ serialisering
→ nätverk
→ tjänst
→ inferens
→ nätverk
→ resultat

Den praktiska fördelen med lokal Laya är därför enkel: om ditt arbetsflöde fattar många små beslut tar samlokalisering av inferensen bort nätverksrundresor från den kritiska vägen.

För ett arbetsflöde med låg volym, där flera hundra millisekunder är acceptabelt, kan det vara viktigare att slippa den operativa bördan av att drifta tjänsten själv.

Finjustering är Layas största strukturella fördel

Öppna vikter är viktigast när ditt arbetsflöde upprepar samma snäva beslut tusentals eller miljontals gånger.

Tänk på:

supportärende
      ↓
fakturering / teknik / konto / missbruk

eller:

agentspår
      ↓
fortsätt / försök igen / eskalera / stoppa

Med en driftad beslutstjänst kan du förbättra tillståndsrepresentationen, kandidatlistan, tröskelvärdena och den omgivande policyn.

Med Laya kan du också anpassa vikterna:

baskontrollpunkt
      ↓
märkta domänspecifika beslut
      ↓
finjustering
      ↓
utvärdering på undanhållet material
      ↓
versionshanterad kontrollpunkt
      ↓
driftsättning

De publicerade resultaten för typade beslut visar varför den här skillnaden spelar roll. Den generiska kontrollpunkten är inte automatiskt bra på alla obekanta beslutsproblem; den största delen av den rapporterade förbättringen på det riktmärket verkar komma efter specialisering.

Det förändrar hur Laya bör utvärderas. Den är mindre intressant som en universell ersättare för Jev utan exempel än som en liten beslutsmodell som du kan anpassa till en stabil domän.

Öppna vikter gör det också möjligt att frysa beteendet

Finjustering är bara en av fördelarna med att äga kontrollpunkten.

Du kan också låsa en modellversion och testa uppgraderingar innan du ändrar beteendet i produktion.

Det spelar roll när en beslutsmodell används i automatisering. Ett system kan avgöra om ett dokument ska arkiveras, ett ärende eskaleras, en modellförfrågan dirigeras eller en händelse flaggas för granskning.

En lokal driftsättning låter dig frysa vikterna, körmiljön, tröskelvärdena och utvärderingssviten tillsammans.

En hanterad tjänst ger dig mindre kontroll över modellen, men i gengäld sköter leverantören driftsättning och förbättringar av modellen.

Återigen handlar avvägningen om ägande, inte om en enkel kvalitetsrankning.

Flerspråkiga arbetsbelastningar påverkar valet av Laya

Layas flerspråkiga variant använder en separat kontrollpunkt baserad på mmBERT med 322 miljoner parametrar, ett kontextfönster på 1 024 token och stöd för mer än 100 språk.

Det här spelar roll eftersom man inte bör utgå från att den engelska modellen generaliserar lika bra till alla språk.

En flerspråkig lokal agent kan i stället dirigera ärenden utifrån arbetsbelastning:

Engelskt ärende
→ Laya Engelska

Japanskt ärende
→ Laya Flerspråkig

Tyskt ärende
→ Laya Flerspråkig

Känt specialiserat arbetsflöde
→ Laya Typade beslut

Tvetydigt fall med hög risk
→ större modell eller människa

Det övergripande mönstret är viktigt: flera små, specialiserade modeller kan ibland vara ett bättre system än att tvinga en modell att hantera alla fall.

Vad händer när Jev eller Laya har fel?

Skillnader i driftsättning och prestandatester spelar roll, men ingen av modellerna bör automatiskt få behörighet att agera.

Ett bristfälligt arbetsflöde för filhantering kan se ut så här:

dokument
   ↓
beslutsmodell: radera
   ↓
radera fil

En säkrare arkitektur skiljer bedömning från befogenhet:

dokument
   ↓
beslutsmodell
   ↓
sannolikhet + föreslagen åtgärd
   ↓
applikationspolicy
   ↓
kontroller av behörighet / risk / säkerhet
   ↓
utför, eskalera eller avvisa

Den här skillnaden är särskilt viktig vid radering, betalningar, ändringar i infrastrukturen, säkerhetsåtgärder, publicering och utgående kommunikation.

Vår guide till förtroendegränsen för verktygskörning beskriver den här uppdelningen mer ingående: modellens bedömning kan ligga till grund för en åtgärd utan att modellen får obegränsad befogenhet att utföra den.

Att köra Laya lokalt ändrar vem som ansvarar för inferensen. Det gör inte alla lokala beslut säkra.

Vilken arkitektur passar olika arbetsbelastningar?

Så utvärderar du Jev kontra Laya för din egen agent

Börja inte med en offentlig topplista. Skapa en liten utvärderingsuppsättning utifrån de beslut som din applikation faktiskt fattar.

En värdtjänstmodell med högre fördröjning från början till slut kan ändå vara det enklare tekniska valet om den gör att du slipper en inferensstack som du inte vill hantera.

En lokal modell med svagare generella nollskottsresultat kan bli mer användbar om du har tillräckligt många märkta exempel för att specialisera den för en stabil arbetsbelastning.

Benchmarken bör testa arkitekturen du planerar att driftsätta, inte ersätta arkitekturbeslutet.

Jev kontra Laya handlar i grunden om hanterad intelligens kontra lokal kontroll

Jev och Laya pekar mot samma större förändring i AI-arkitekturen: alla intelligenta steg behöver inte vara generativa.

Ett arbetsflöde kan kombinera deterministiska regler, en liten beslutsmodell, en större resonemangsmodell och en strikt exekveringspolicy:

deterministiska regler
       ↓
beslutsmodell
       ↓
resonemangsmodell / generativ modell
       ↓
applikationspolicy
       ↓
verktyg och exekvering

Jev gör beslutslagret tillgängligt som hanterad infrastruktur.

Laya gör ett liknande lager till något du kan ladda ner, köra lokalt, specialisera och versionshantera själv.

Så den användbara frågan är inte bara ”Är Jev bättre än Laya?”

Det är:

Var bör beslutslagret finnas, vem bör styra det och vad bör hända när det har fel?

För de flesta agentarkitekturer är svaren på de frågorna viktigare än att välja modellen med den högsta poängen i en benchmarktabell.