Laya 대 Kev: 로컬 의사결정 모델을 위한 두 가지 레시피

Laya 대 Kev 비교에서 가장 유용한 숫자는 영수증 하나다. Jared Palmer는 Modal에서 H100 시간으로 약 95달러, 평가 데이터를 위한 API 호출에 약 3센트를 들여 Kev 패밀리를 학습시켰고, 그 레시피를 가중치와 함께 공개했다. Convai Innovations는 Laya로 다른 길을 택했다: 2026년 9월 18일 공개, TypeSafe AI의 Jev보다 사흘 뒤였고, Apache 2.0, Hugging Face에 가중치, pip install laya 진입점, 그리고 학습 파이프라인은 없다 — 421M 규모의 ModernBERT-large 영어 체크포인트, 322M 규모의 mmBERT-base 다국어 체크포인트, 그리고 둘 사이에서 고르는 라우터다. Kev는 0.8B, 4B, 9B의 소형 모델 세 개로 이루어진 패밀리로, 각각 동결된 베이스에 rank-16 LoRA 어댑터와 작은 포인터 헤드를 얹은 것이다. 둘 다 한 번의 순전파로 타입이 지정된 질문에 답하며, 어느 쪽도 텍스트를 생성하지 않는다. 둘 중 무엇을 고르느냐는 결국 어떤 산출물을 소유하고 싶으냐에 대한 결정이다: 체크포인트냐, 레시피냐.

각 프로젝트가 실제로 출시하는 것

Laya는 추론을 제공합니다. 영어 체크포인트는 512토큰 창을 가진 양방향 인코더이고, 다국어 체크포인트는 1,024토큰 창으로 100개 이상의 언어를 지원하며 약 두 배 더 빠르게 실행됩니다. 라우터는 0.5밀리초 미만으로 문자 체계를 감지합니다. 이것이 답하는 것은 선택, 점수 그리고 noul — 목록에서 하나를 고르는 것, 정렬된 평가 기준에서의 예상 수준, 그리고 주장이 참일 보정된 확률입니다. 세 번째 체크포인트인 laya-typed-decisions는 typed-decisions 벤치마크의 훈련 분할에서 미세 조정된 동일한 421M 백본입니다. Convai 자체 모델 카드에는 모든 Laya 수치를 읽는 방식을 좌우해야 하는 문장이 담겨 있습니다: "Laya는 특화하기 위한 빠른 기반이지, 제로샷 의사결정 엔진이 아닙니다."

Kev는 하나의 방법을 제공한다. 저장소에는 decision-v7이 문서화되어 있다: 10개의 공개 데이터셋에서 추출한 10,000개 예제, 896개의 생성된 정책 예제, 60개의 생성된 규칙 구조로 만든 1,680개 예제에 대한 두 에포크. 헤드는 제공된 각 옵션을 질문의 decide 토큰과 비교해 점수를 매기고 그 결과에 소프트맥스를 적용한다. Qwen3.5 체크포인트는 어텐션 마스크를 무시하는 순환 Gated DeltaNet 레이어와 어텐션을 혼합하기 때문에, 각 질문은 자체 행으로 실행되고 공유 상태는 한 번 계산되어 캐시된다 — 이것이 모델이 질문마다 새로운 프리필 비용을 치르지 않으면서 질문들을 서로 격리된 상태로 유지하는 방식이다. Kev는 TypeSafe의 공개 /v1/systemone 계약을 그대로 따르므로, 기존 TypeSafe SDK 클라이언트는 기본 URL만 변경하여 로컬 Kev 서버를 가리킬 수 있다. README에는 훈련에 Jev 출력이 사용되지 않았다고 명시되어 있다.

두 가지 실패 모드는 서로 다르며, 바로 그게 진짜 이야기다.

두 모델 모두 지식이 필요한 작업에서는 Jev에게 지지만, 서로 다른 완화책이 필요한 방식으로 진다.

Laya의 공개된 약점은 입력의 형태에 관한 것이다. TypeSafe의 typed-decisions 벤치마크에서 Laya는 제로샷으로 0.362점을 기록했는데, 이는 무작위 추측의 0.318, 다수 클래스 기준선의 0.461과 비교된다 — 자명한 답보다는 우연에 더 가깝다. 대략 스무 개 선택지를 넘어서면 무너진다: Banking77에서 0.425로, Jev의 0.870에 대비된다. 순서 민감성이 충분히 커서 한 제3자 테스트에서는 선택지 순서를 단순히 뒤집기만 했는데도 정확도가 13.75포인트 하락해 동일 답변률이 42.5%로 남았다. 그리고 배포된 체크포인트는 유효하지 않은 temperature와 함께 제공된다 — 라이브러리가 임포트 시 경고하는데, 이는 카드에 적힌 보정 수치인 기대 보정 오차 0.466이 재적합하기 전에 실제로 얻는 값이라는 뜻이다. 질문 유형별로 재적합하면 0.081로 내려가지만, 그것은 사용자가 하는 작업이지 다운로드가 하는 작업이 아니다. 전체를 읽을 가치가 있는 공개된 다국어 실패 사례가 있다: 비라틴 문자 체계에서 영어 체크포인트는 치명적으로 과신하며, 크메르어 예시에서는 평균 신뢰도 0.952에서 정확도 0.000을 보였다.

Kev의 공개된 약점은 지식과 산술에 관한 것이다. Kev-9B는 자체 잠금 신규 소스 테스트에서 0.837점을 기록했고 — 4B는 0.832, 0.8B는 0.668 — dev 분할에서 도메인 외 약 0.822로 Jev의 0.857과 맞선다. 격차는 세계 지식이 요구되는 곳에서 벌어진다: MMLU 약 70% 대 Jev의 90%, MMLU-Pro 0.515 대 0.840, 일 단위 정밀도 날짜 산술 60% 대 93%. 좁은 고정 라벨 라우팅 세트에서는 승리한다 — 지원 티켓 라우팅 평가에서 Kev-9B는 0.952로 Jev의 0.897을 앞섰다 — 그러나 저자는 이것이 자신의 자체 하네스이며, Jev의 학습 데이터는 공개되지 않았고, 따라서 통제된 비교는 구성할 수 없다고 명시한다. Kev는 또한 새 소스에서 과신을 유지한다; KEV_TEMPERATURE=2.0을 설정하면 프로젝트 자체 테스트에서 확신에 찬 오류가 8.7%에서 4.4%로 줄었는데, 이는 기본값이 안전한 설정이 아님을 보여준다.

실용적인 번역: Laya의 실패는 당신의 옵션 세트와 프롬프트 포맷팅에 의해 유발되며, 파인튜닝과 리피팅으로 고칩니다. Kev의 실패는 사실이 필요한 질문에 의해 유발되며, 모델을 라우팅과 분류로 범위를 한정하고 지식 의존적인 호출은 다른 곳에 두어 고칩니다. 어느 수정도 구성 플래그가 아닙니다.

그들을 섬기는 데 필요한 것

• 하드웨어 — Laya: 421M/322M 인코더, 낮은 처리량에서는 CPU에서도 신뢰할 만하고 Apple 실리콘의 MLX 포팅에서는 1GB 미만으로 상주합니다. Kev: 0.8B~9B, 9B에는 BF16 CUDA GPU가 필요하며, Qwen3.5 아키텍처는 flash-linear-attention을 CUDA 및 ROCm에서 요구합니다.

• 지연 시간 — Laya: Tesla T4에서 결정당 p50 32.8ms, 배치 10에서 질문당 7.2ms. Kev: 32GB Mac에서 bf16으로 4B 모델을 사용해 다섯 개의 입력 질문에 약 300ms, H100에서는 대략 40ms.

• 상한 — Laya: 영어 512토큰 창, 다국어 1,024토큰. Kev: 1–255개 옵션 중 선택, 2–255개 레벨에 대한 점수, 384개 훈련 상태 토큰, 서빙 시 8,192개.

• 서버 — Laya: 인프로세스 Python, 그리고 커뮤니티 ONNX, Go 및 Apple MLX 포팅. Kev: 인증 없이 127.0.0.1에 바인딩된 로컬 서버, npm SDK, 그리고 LangChain 및 LlamaIndex 어댑터.

• 라이선스 — 둘 모두 Apache 2.0.

헤드라인 숫자에는 나타나지 않는 두 가지 운영상 참고 사항이 있습니다. Kev의 서버는 설계상 단일 요청만 처리하며 인증도 없습니다. 이는 로컬 사이드카이지, 외부에 노출할 대상이 아닙니다. 그리고 Kev의 Mac 지연 시간은 H100 지연 시간보다 실질적으로 더 나쁜데, 이는 빠른 DeltaNet 커널이 아직 MLX용으로 존재하지 않기 때문입니다. 이는 바로 "로컬에서 실행된다"는 주장을 "올바른 하드웨어에서 로컬로 실행된다"는 주장으로 바꾸는 종류의 세부 사항입니다.

패턴의 생성적 절반

이 두 모델은 모두 하나의 특정 호출, 즉 레이블이나 확률을 돌려받기 위해서만 수행하던 LLM 호출을 대체하기 위해 존재합니다. 실제로 산문이 필요한 호출을 대체하는 것은 아닙니다. Kev-9B를 사용해 티켓을 라우팅하는 지원 시스템도 여전히 스레드를 요약하고 답변 초안을 작성할 모델이 필요하며, 그 모델이 포인터 헤드를 가진 9B LoRA일 리는 없습니다.

그것이 바로 OrcaRouter가 자리 잡은 틈새이며, 이들 중 어느 하나를 호스팅한다는 주장이 아닙니다. Laya도 Kev도 우리 모델 목록에는 없습니다 — 그것들은 직접 다운로드하는 가중치입니다 — 그렇지 않은 것처럼 암시한다면 기사는 오해의 소지가 있을 것입니다. 목록에 있는 것은 하나의 OpenAI 호환 키 뒤에 있는 200개 이상의 생성 모델이 있으며, 공급자 정가가 0% 마크업으로 그대로 전달됩니다. 요청이 세 가지 요약 계층 중 어디에 속하는지 결정하기 위해 Kev를 사용하거나, 초안 답변이 수용 가능한지 점수화하기 위해 Laya를 사용한다면, 두 루프의 생성 측면은 두 번째 계약과 두 번째 SDK 대신 자동 장애 조치를 갖춘 하나의 엔드포인트입니다. 라우팅 DSL은 의사결정 모델 아키텍처에 가장 자연스럽게 맞는 부분입니다: 저렴한 모델과 비싼 모델을 단일 호출로 구성하고 의사결정 모델의 출력이 분기를 선택하게 하십시오.

다음에 볼 콘텐츠

증거의 격차는 둘 모두에게 동일하며, 어느 프로젝트도 이를 해소하지 못할 것이다. 아무도 Laya와 Kev를 바이트 단위로 동일한 입력, 동일한 프롬프트, 동일한 옵션 순서, 동일한 신뢰도 임계값 스윕으로 실행한 적이 없다. Laya의 대표적인 승리는 자체 하네스에서 나온 것이고, Kev의 거의 동등하다는 주장은 저자의 하네스에서 나온 것이다. Jev의 캘리브레이션이 과제에 따라 크게 달라진다는 것을 발견한 캘리브레이션 감사 — 숨겨진 정책 우선순위 과제에서 44.7% 정확도와 0.325 기대 캘리브레이션 오류 — 는 제3자가 수행한 것이며, Laya와 Kev 모두 그런 처리를 받은 적이 없다. 누군가 그것을 수행하기 전까지, 위의 숫자들은 이용 가능한 최선의 수치이며 서로 비교할 수 없다.

오늘 결정을 내려야 한다면: 이미 임대 중인 GPU에서 이번 주에 작동하는 라우팅 모델을 원한다면 Kev를 선택하고, 그것이 모든 것을 알지는 못한다는 점을 받아들이세요. 입력이 다국어이거나 하드웨어 예산이 노트북이라면 Laya를 선택하고, 파인튜닝을 나중의 최적화가 아니라 프로젝트의 일부로 예산에 넣으세요. 어느 쪽이든, 프로덕션 트래픽 앞에 신뢰도 임계값을 두기 전에 자체 라벨링된 데이터로 측정하세요 — 두 프로젝트 모두 자체 문서에서 그렇게 하라고 말합니다.