Laya förklarad: En beslutsmodell som svarar utan att skriva en enda token

Det mest intressanta med Laya är inte dess hastighet. Det är att varje alternativ du erbjuder den poängsätts vid sin egen [MASK]-token, och sannolikheterna softmaxas sedan över alternativen för just den frågan. Convai Innovations publicerade Layas vikter på Hugging Face den 18 september 2026, under Apache 2.0 – tre checkpoints, ett repository, 421M parametrar för den engelska modellen. Det finns inga utdatatokens. Det finns ingen avkodningsloop, ingen JSON att tolka, ingen klammerparentes att glömma att stänga. Du ger den ett tillstånd och en uppsättning typade frågor, och efter en enda framåtpassning får du ett val bland namngivna alternativ, en ordinalscore med en förväntad nivå, eller en sannolikhet att ett påstående är sant. Den designen har en konsekvens som folk missar: eftersom svarsutrymmet sätts samman per förfrågan i stället för att bakas in i ett vokabulärhuvud, behöver ett schema som du hittar på i eftermiddag inte tränas om. Det har också en gräns, och projektet säger det rakt ut på sitt eget modellkort: bascheckpointarna får 0,362 på benchmarken för typade beslut, mot 0,318 för slumpmässig gissning och 0,461 för att alltid svara med majoritetsklassen. ConvaIs egen mening är den du bör hålla i huvudet – "Laya är en snabb bas att specialisera, inte en zero-shot-beslutsmotor." Den uppenbara jämförelsepunkten är TypeSafe AIs Jev, en hostad System One-modell utan publicerade vikter, utan publicerat parameterantal och utan publicerad basmodell. Laya är svaret med öppna vikter på den. Huruvida det svaret är användbart för dig beror nästan helt på vilken halva av pipelinen du försöker ersätta.

Vad Laya faktiskt är, och vad det inte är

Börja med det negativa, för det är där de flesta beskrivningar går fel. Laya är inte en LLM. Den är icke-autoregressiv: en enda framåtpassning producerar svaret, och modellen avger aldrig text. Att jämföra dess latens med en chattmodells tokens per sekund är att jämföra två olika operationer – den ena klassificerar, den andra genererar. Om du behöver ett stycke, en sammanfattning, en plan eller en resonemangskedja kan Laya inte ge dig något sådant och försöker inte göra det.

Vad det är: en dubbelriktad encoder med ett beslutshuvud påmonterat ovanpå. Den engelska checkpointen är ModernBERT-large – 395M parametrar, fullt finjusterad – plus ett huvud tränat från grunden som består av två transformerlager, en option-marker-scorer och ett act/escalate-huvud, totalt 421M. Den flerspråkiga checkpointen byter ut backbone mot mmBERT-base, 22 lager och en vokabulär på 256k, totalt 322M. Tre checkpoints medföljer i samma repository, och endast den du begär laddas ner:

• convaiinnovations/laya — ModernBERT-large, 421M parametrar, kontext på 512 tokens, engelska, cirka 808 MB på disk.

• convaiinnovations/laya-multilingual — mmBERT-base, 322M parametrar, 1 024-tokenkontext (kodaren stöder upp till 8 192 med RoPE), 100+ språk, ungefär 2,2x snabbare, ungefär 647 MB.

• convaiinnovations/laya-typed-decisions — ModernBERT-large, 421M parametrar, kontext på 1 024 tokens, och den enda av de tre som bär siffran 0,766 som du kommer att se citerad överallt.

En Router sitter längst fram och väljer checkpoint per begäran genom att upptäcka skriftsystem och språk på under en halv millisekund, i ren Python, innan någon forward pass sker. Det är inte en bekvämlighetsfunktion. Det är en korrekthetsfunktion, och projektets egna bevis visar varför: den engelska checkpointen får 0,000 i noggrannhet på khmer medan den rapporterar 0,952 i konfidens. En modell som förblir självsäker medan den är helt fel är precis det fall där konfidensstyrning inte kan rädda dig, så routningsbeslutet måste fattas innan modellen ser indata. I ett svep över 51 språk gjorde routern 45 av 51 språk användbara — definierat som att överträffa tre gånger slumpen — mot 23 av 51 för enbart den engelska checkpointen.

Det designfaktum som är värt att förstå: en [MASK]-token per alternativ

Om du bara tar med dig en enda sak från den här artikeln, låt det vara detta. I ett vanligt klassificeringshuvud är etikettuppsättningen fast vid träningstiden: det sista lagret har en utdata per klass, och att lägga till en klass innebär omträning. Laya gör inte så. Det renderar varje alternativ som text med en markör, och poängsättaren för alternativmarkören läser av en poäng från det alternativets egen [MASK]-position. Sedan softmaxar den över alternativen som hör till den frågan.

Svarsutrymmet definieras alltså vid förfrågningstillfället. Du skriver alternativen, modellen poängsätter dem. Ett nytt schema kräver ingen omskolning och ingen finjustering, eftersom det inte finns något i vikterna som kodar ”fakturering” eller ”teknik” som en klass – endast maskineriet för att jämföra ett renderat alternativ mot ett annat i kontexten av tillståndet.

Två budgetar styr hur väl det fungerar, och de delas. Varje sekvens delas upp i en budget för alternativprompt (head_max_len, 192 tokens på den engelska checkpointen och 256 på de andra två) och en dokumentbudget (det som återstår av max_len). Varje fråga i ett anrop besvaras i samma enda framåtpassning, så ett anrop med sex frågor är inte sex modellanrop. Men alternativ delar alternativbudgeten, vilket är anledningen till att en fråga med 77 alternativ som Banking77 tilldelar ungefär tre till fyra tokens per etikett och noggrannheten störtdyker — 0,425 mot Jevs publicerade 0,870. Åtgärden är dokumenterad i stället för dold: höj head_max_len och max_len, eller dela upp en stor uppsättning alternativ i ett tvåstegsval från grovt till fint.

De tre primitiverna

Allt som Laya gör är en av tre frågetyper, och var och en returnerar en annan form:

• val — en sannolikhet per namngivet alternativ, plus toppetiketten och en konfidens. Detta är primitiven för routing och intentklassificering.

• poäng — en fördelning över en ordnad bedömningsskala plus en förväntad nivå. Detta är den ordinala primitiven: brådska, frustration, allvarlighetsgrad.

• noul — en kalibrerad sannolikhet att ett påstående är sant, från 0,0 till 1,0. Nätfiske, kundbortfall, prompt-injektion.

Typerna är strikta på ett sätt som spelar roll operativt. En valfråga kan inte returnera ett alternativ som du inte angav, eftersom de enda alternativ den kan poängsätta är de du renderade. Det tar bort en hel klass av produktionsfel – det påhittade enumvärdet, den trunkerade JSON:en, återförsöksloopen runt en parser. Det tar inte bort semantiska fel. En modell som returnerar billing: 0.94 för ett ärende som borde ha gått till teknisk support har fel, och den har fel på ett självsäkert sätt. Typad utdata garanterar svarets form, aldrig dess korrekthet.

RLCD, eller varför sannolikheterna ska betyda något

De flesta klassificerare tränas för att ha rätt. Laya är tränad för att vara ärlig om hur rätt den har, och det är träningsreceptet som ligger bakom.

Metoden kallas RLCD – Reinforcement Learning for Calibrated Decisions. Policyn avger en fördelning i stället för ett argmax; utforskning lägger till gaussiskt brus med nollmedelvärde till logiterna; och belöningen är en strikt proper poängsättningsregel – logaritmisk plus sfärisk, med en ranked probability score tillagd för ordinala frågor. Det ordet ”proper” gör jobbet. En strikt proper poängsättningsregel maximeras i förväntan endast genom att man rapporterar sina sanna övertygelser; därför förlorar gardering eller överdrift belöning genom konstruktion i stället för genom instruktion. Uppdateringarna är REINFORCE med en gruppmedelvärdesbaslinje, i GRPO-stil, och flerturskonversationer använder TD(λ=1,0) över prefixskivor.

Den praktiska konsekvensen är att en konfidenströskel är något meningsfullt att bygga applikationslogik på — ett påstående som man inte kan göra om en softmax från en klassificerare tränad med korsentropi. Det är också ett påstående med ett förbehåll som projektet är öppet med: de levererade checkpointarna är överkonfidenta, och man förväntas återanpassa en temperatur på sina egna data innan man litar på siffrorna. Att återanpassa en temperatur per frågetyp och antal svarsalternativ flyttade medel-ECE från 0,466 till 0,081 på den engelska checkpointen och 0,314 till 0,106 på den flerspråkiga. Projektets föreslagna starttröskel för automatiskt godkännande kontra mänsklig granskning är omkring 0,85.

Vad det kostar att driva

Latenssiffrorna är projektets egna, uppmätta på en Tesla T4, där varje checkpoint besvarar byte-identiska frågor i samma körning:

• En fråga — 39,5 ms på laya, 32,8 ms på laya-multilingual.

• Fem frågor — 84,5 ms och 40,1 ms.

Tio frågor i en batch – 158,6 ms (15,9 ms per fråga) och 72,3 ms (7,2 ms per fråga).

• Femtio frågor – 771 ms och 337 ms, eller 6,8 ms per fråga på den flerspråkiga checkpointen.

• Batchad genomströmning på en enda T4 — 103 till 332 frågor per sekund.

Om du har sett ett påstående om "50x snabbare än Jev" som cirkulerar, är det inte projektets siffra och projektets egen benchmark stöder den inte. Convaïs publicerade jämförelse är 7,8x på p50-latens för en fråga: 32,8 ms mot 236–276 ms. Den jämförelsen är också den man bör läsa noga, eftersom Layas kort märker Jev-sidan som tredjepartspublicerade siffror som Convai aldrig mätte – det har ingen TypeSafe API-åtkomst – och eftersom den ställer en lokal GPU-forward-pass mot ett hostat API-anrop som inkluderar nätverksrundtur och köning. Den arkitektoniska delen av den skillnaden är verklig. Infrastrukturdelen av den är inte en egenskap hos modellen.

Minnesmässigt är fotavtrycket några hundra megabyte per checkpoint, och driftsättningstabellen är värd att känna till innan du dimensionerar en värd. Standardbeteendet med lat inläsning håller två checkpoints kvar i minnet (engelsk och flerspråkig, de enda två som routern automatiskt väljer mellan), så efter varje språks första inläsning kostar en växling endast detektion.Router(max_loaded=1) på en minnesbegränsad maskin laddar om vid varje språkväxling, uppmätt till 7,4 sekunder i median på CPU och 10,3 sekunder på en T4.Router(preload=True) är serverkonfigurationen: ingenting laddas om, och latensen per begäran är 32,8 ms på GPU eller 193–464 ms på CPU.

Den ärliga halvan

Det är här texten gör skäl för sig, för ytan runt Laya är högljudd och begränsningarna är specifika.

För det första är rubriksiffran ett finjusterat tal. Noggrannheten 0.766 tillhör laya-typed-decisions, den checkpoint som finjusterats på benchmarkens egen träningsdel. Bascheckpointarna får 0.362 och 0.342 zero-shot mot en slumpmässig baslinje på 0.318 och en majoritetsklassbaslinje på 0.461 — med andra ord under den triviala baslinjen. Projektet säger det självt i sin egen lista över begränsningar i stället för att begrava det, och den finjusterade checkpointen tar sig förbi taket på 0.735 för lärarnas självöverensstämmelse, vilket är ett genuint starkt resultat för en 421M-encoder på fyra snäva arbetsflöden (fakturahantering 0.804, säkerhetsincidenter 0.766, kundtjänst 0.764, observerbarhet för agentspår 0.730). Men det är ett resultat om specialisering, inte om basmodellen, och den som citerar 0.766 som en allmän förmåga misstolkar kortet.

För det andra är primitiverna inte lika bra. Mätt i noggrannhet på den finjusterade checkpointen: noul 0,857, choice 0,733, score 0,723. Projektet kallar ordinal score "den svagaste primitiven" rakt ut, med SST-5 på 0,372. Om din beslutsyta är en allvarlighetsbedömning från 1 till 5, är det den primitiven du har minst anledning att lita på direkt ur lådan.

För det tredje är två beteenden dokumenterade som buggar i projektets egen ärendehanterare, och båda kommer att bränna dig i produktion om du inte läser dem. action.act_probability bär ingen användbar signal ännu — issue #185 — eftersom decision-headens utdata är onormaliserad vid ungefär 300x encoderns skala, vilket mättar act-headen så att den visar 1.0 för nästan varje indata. Dess råa logits går emot korrekthet, med en AUROC på 0.30 på 396 märkta beslut. Grinda i stället på confidence, som når en AUROC på 0.77 på samma poster. Separat: noul kan följa sina egna alternativetiketter i stället för tillståndet — issue #156 — eftersom render_options hårdkodar en nouls etiketter till false: / true:, och det etikettparet kan dominera svaret och returnera ett självsäkert "nej" för tydligt positiv indata. Den dokumenterade lösningen är att ställa samma fråga som ett tvåalternativs choice med neutrala nycklar och din ja/nej-formulering som beskrivningarna.

För det fjärde, en kalibreringsdetalj som är lätt att missa och värd att ange exakt. Checkpointen levereras med en anpassad temperatur på 0,1006 för choice:11+ bucket, och laddaren begränsar varje temperatur till [0,5, 5,0]. Den begränsningen gör dig en tjänst. En så skarp temperatur skulle kunna ta en genuint delad fördelning och rapportera den som nära nog visshet; begränsningen innebär att värsta fallet är ett mjukare svar än anpassningen avsåg, och laddaren avger en varning som namnger den berörda bucketen och säger åt dig att behandla den konfidensen som okalibrerad. Läs varningarna vid inläsning i stället för att undertrycka dem.

För det femte, endast engelska i repo-roten, och felläget utanför engelska är inte graciöst — därav routern, och därav rekommendationen att använda laya-multilingual för allt som inte är engelsk prosa.

Den oberoende bilden, där den finns, är snävare än leverantörsbilden och motsäger den inte. En oberoende direktjämförelse – sysone-bench, 751 tillstånd över nio sviter, daterad 2026-09-21, körd på byte-identiska indata med frågehaschar verifierade som identiska före jämförelse – ligger Jev före inom triage, guardrails, moderering, banking77 och flerspråkig avsikt, och Laya ligger före på AG News (0,940 vs 0,910) och MNLI (0,983 vs 0,867). Dess resultat för konfidensgating är det jag faktiskt skulle planera utifrån: gating vid 0,85 konfidens behöll 58 % av Layas trafik vid 0,878 noggrannhet, mot 78 % av Jevs vid 0,917. Det är avvägningens karaktär – Laya automatiserar mindre av trafiken vid lägre noggrannhet på den del den behåller, och dess egen routerkörning höjer flerspråkig avsikt från 0,360 till 0,840.

Ytan runt den, som är ovanligt bred

För ett projekt vars vikter är några dagar gamla är integrationsytan det som förvånar. Allt detta finns i uppströms-repositoriet på NandhaKishorM/laya, som visade 19 871 stjärnor på GitHub när detta skrevs, och det är Apache 2.0 rakt igenom:

• laya-serve — en HTTP-server som tillgängliggör Router på samma request- och svarsformat för POST /v1/systemone som TypeSafe:s hostade Jev API, så en befintlig TypeSafe-klient migrerar genom att ändra sin bas-URL. Notera ärligt talat standardinställningen för säkerhet: den binder 0.0.0.0 utan autentisering om inte LAYA_API_KEY är satt, i vilket fall den kräver en bearer-token. Det finns en härdad NixOS-modulvariant som körs under en DynamicUser-systemd-enhet och skickar token via LoadCredential i stället för att lägga den i storen.

• En fullständig TypeScript-port i laya-ts/ för Node och webbläsaren, samt en ONNX-agentväg (laya.onnx_agent.ONNXAgent) för att köra en exporterad modell på ONNX Runtime utan PyTorch vid körtid.

• En MCP-server bakom ett valfritt tillägg, som exponerar laya_predict, laya_route, laya_preset och laya_status som verktyg.

• LangChain- och LangGraph-integrationer — LayaRouter för villkorsstyrd kantroutning med en förtroendetröskel och fallback, och LayaGuardrail.

• En Nix-flake med nix run .#laya-serve och en modul för services.laya-serve, fyra compose-filer, en Docker-image-sökväg med en dokumenterad snabbstart och en Kaggle-notebook som kör hela RLCD-finjusteringsloopen på kostnadsfria 2xT4-GPU:er på fyra till fem timmar över ungefär 30k frågor.

Apache 2.0 är den licensdetalj som avgör om du kan leverera detta i en produkt: den tillåter kommersiell användning, modifiering och vidaredistribution, och den kräver inte att du publicerar dina ändringar eller dina finjusterade vikter. Skyldigheten är den vanliga med attribuering och bevarande av meddelanden, plus den uttryckliga avsaknaden av ett beviljande av patent- eller varumärkesrättigheter utöver vad licensen anger. För ett beslutslager som sitter framför kundtrafik är det ett väsentligt annorlunda erbjudande än en hostad slutpunkt för tidig åtkomst, vars vikter, arkitektur och träningsrecept alla är hemlighållna — vilket är vad Jev är idag, till $0.042 per miljon indatatoken med gratis utdata och en indatayta för enbart text.

Var detta faktiskt passar in: ett beslutshuvud framför, en routad LLM bakom

Mönstret som är värt att internalisera är inte "beslutsmodell i stället för LLM". Det är en tvåstegspipeline, och båda stegen finns eftersom det andra är dåligt på något.

Sätt Laya i fronten för den högvolymiga, smala, maskinkonsumerbara bedömningen: routa ärendet, klassificera avsikten, poängsätt brådskan, avgör om detta dokument är relevant för frågan, kontrollera om detta utkast bryter mot en policy. Dessa anrop har en fast svarsuppsättning, de sker tusentals gånger i timmen, och en lokal framåtpassning på 33 millisekunder med noll utdatatokens passar dem bättre än en generativ rundtur. Sätt sedan en generativ modell bakom Laya för de anrop som verkligen behöver prosa, syntes eller resonemang över en lång kontext – utkastskrivandet, förklaringen, eskaleringssammanfattningen.

Det är där OrcaRouter befinner sig, och det är värt att vara precis kring gränsen. Vi tillhandahåller inte Laya; det är en 421M-encoder som du kör själv, och hela poängen med den är att den körs där dina data redan finns. Vi tillhandahåller inte heller Jev – det är TypeSafes endpoint för tidig åtkomst. Det vi täcker är den generativa halvan av samma pipeline: 200+ modeller bakom en enda OpenAI-kompatibel nyckel, till leverantörens listpris vidarebefordrat med 0 % påslag, med automatisk failover mellan leverantörer. Den praktiska anledningen som är viktig här är sömmen mellan de två halvorna. I samma stund som du börjar dirigera beslut till en generativ modell för de fall där beslutsheaden avstod, har du en andra integration, en andra faktura och ett andra felläge. En nyckel för generationssidan, med failover om en leverantör försämras, innebär att beslutsdelens eskaleringsväg är en konfigurationsändring snarare än en andra leverantörsrelation. Det är ett litet påstående, och det är det sanna.

Vilka bör införa det, och vilka bör vänta?

Inför Laya nu om du har etiketterad data och en träningsloop, och en beslutsyta som är tillräckligt stabil för att vara värd att specialisera på. Kaggle-notebooken finns just för att finjusteringssteget inte ska vara ett forskningsprojekt, bascheckpointarna laddas på ungefär två sekunder på CPU, och licensen låter dig leverera resultatet kommersiellt utan att publicera dina vikter. De arbetsbelastningar som passar bäst är de som projektet redan har benchmarkat: ärendetriage, fakturahantering, klassificering av säkerhetsincidenter, guardrails och moderering, samt observerbarhet för agentspår. Håll flervalsfrågor under ungefär 20 alternativ, kalibrera en temperatur på dina egna håll-out-data innan du sätter en tröskel i produktion, och grinda på konfidens, aldrig på act_probability.

Vänta om ditt beslut måste vara rätt direkt ur lådan utan märkta data. En bas-checkpoint som ligger under baslinjen för majoritetsklassen i det benchmark som den publicerades mot är inte en zero-shot-motor, och den ärliga tolkningen av siffrorna från leverantören kontra oberoende är att ett välskött hostat besluts-API för närvarande är det starkare zero-shot-valet. Vänta också om dina alternativuppsättningar är stora och du inte är villig att justera head-budgeten, om din ordinala poängsättning måste vara tillförlitlig direkt, eller om du behöver indata i form av bild, ljud eller långa dokument – Laya hanterar endast text och dess kontextbudget är 512 till 1 024 tokens som standard, vilket är ett urval av underlag snarare än ett helt dokument.

Det som kommer att avgöra den här kategorin är inte latenssiffrorna, som redan är tillräckligt bra för att sluta vara argumentet. Det är huruvida en liten modell som rapporterar ärliga sannolikheter på en beslutsyta du har definierat, och som du kan träna om på dina egna etiketter, slår att anropa en stor generativ modell och tolka dess utdata. Laya är ett trovärdigt första seriöst försök till open-weights-versionen av den frågan – och den är som mest några dagar gammal, vilket är rätt sätt att läsa allt ovan. Basen är utgångspunkten, inte produkten.