Jev vs Laya: T4에서 33밀리초, 그리고 랜덤 베이스라인

Laya의 모델 카드에는 이 비교를 결정짓는 문장이 담겨 있으며, 그것은 Laya를 만든 사람들이 직접 쓴 것이다. "Laya는 특화를 위한 빠른 베이스이지, 제로샷 의사결정 엔진이 아니다." Convai Innovations는 2026년 9월 18일, TypeSafe AI가 Jev를 출시한 지 3일 후에 Laya를 Apache 2.0으로 공개했고, Hugging Face에 가중치를 올렸으며 pip install laya 진입점을 제공했다. Laya는 토큰 단위 디코딩 없이 단일 포워드 패스로 입력된 질문에 답하며, 이는 Jev가 택한 것과 동일한 아키텍처적 승부수다. 대표적인 주장은 Tesla T4에서 결정당 p50 지연 시간 32.8밀리초로, 호스팅 API를 통한 Jev의 공개 수치인 p50 236~276ms보다 약 7.8배 빠르다는 것이다. 이 주장은 사실이며, 동시에 서로 다른 두 가지를 측정하고 있다 — 로컬 GPU 대 네트워크 호출 — 그리고 그 아래에 깔린 정확도 그림이야말로 이 모델을 다운로드할지 결정해야 하는 부분이다. 제로샷에서 Laya는 TypeSafe의 typed-decisions 벤치마크에서 0.362점을 기록한다. 무작위 추측은 0.318점이다. 다수 클래스 기준선은 0.461점이다. Laya는 기본 설정 그대로 무작위에 더 가깝고, 사소한 기준선과는 거리가 멀다.

Laya가 실제로 무엇인지

Laya는 각 입력을 알맞은 쪽으로 전달하는 내장 라우터 뒤에 두 개의 체크포인트로 제공됩니다. 영어 체크포인트는 421M 파라미터에 512토큰 문맥을 가진 ModernBERT-large입니다. 다국어 변형은 322M 파라미터에 100개 이상 언어를 아우르는 1,024토큰 창을 가진 mmBERT-base입니다. 둘 다 비자기회귀 방식입니다. 단일 순전파가 답을 반환하므로 디코딩 루프도, 파싱할 JSON도, 선언된 타입 밖의 텍스트를 출력할 여지도 없습니다. 이 마지막 속성은 Jev가 제공하는 것과 동일한 구조적 보장을 다른 방향에서 도달한 것이며, 가끔 중괄호 닫기를 잊어버리는 모델을 둘러싼 재시도 로직을 작성해 본 사람이라면 누구에게나 진정으로 가치 있는 특성입니다.

Jev는 폐쇄형 대응 모델입니다: TypeSafe AI의 첫 번째 System One 모델로, 2026년 9월 15일에 출시되었으며, 호스팅 및 얼리 액세스 방식으로 제공되고, 세 가지 타입 지정 프리미티브를 갖추고 있습니다 — 사용자가 제공하는 목록에서의 Choice, 정렬된 루브릭에 대한 Score, 그리고 보정된 확률을 가진 예/아니오 주장인 Noul입니다. 모든 질문은 상태에 대한 하나의 공유된 판독값을 기준으로 병렬 평가되며, 출력 토큰이 없기 때문에 출력은 무료이고, 입력은 백만 토큰당 $0.042입니다. 아키텍처, 파라미터 수, 학습 컴퓨트는 공개되지 않았으며, TypeSafe는 세부 사항을 비밀로 유지하고 있고 추후 논문이 나올 수도 있다고 말했습니다.

지연 시간 주장, 제대로 측정하기

Laya가 T4에서 기록한 32.8ms p50은 실제 수치이며 좋은 수치입니다. Jev의 236–276ms에 대비한 7.8배 비교가 주의가 필요한 지점인데, Laya 자체 카드는 그 이유에 대해 이례적으로 솔직합니다. Jev 수치는 Convai가 직접 측정한 적 없는 제3자 공개 수치이며, 이 비교는 로컬 GPU 포워드 패스를 네트워크 왕복과 큐잉을 포함하는 호스티드 API 호출과 맞세우고 있습니다. 네트워크를 빼고 보면 아키텍처 비교는 두 단일 패스 모델, 즉 421M 파라미터 모델과 TypeSafe가 한 번도 공개한 적 없는 미공개 규모의 모델 사이의 비교입니다.

알아둘 만한 배칭 수치도 있습니다: 배치 10개 기준으로 Laya는 질문당 7.2ms를 보고합니다. 이것이 이 제품의 형태입니다. Laya는 로컬에서 대량으로 실행되도록 만들어졌으며, laya-mlx 같은 온디바이스 커뮤니티 포팅은 이를 Apple Silicon까지 확장합니다. 'Jev보다 50배 빠르다'는 바이럴 주장은 프로젝트가 직접 공개한 벤치마크로는 뒷받침되지 않으며, 정직한 표현은 로컬 대 클라우드의 큰 격차인데, 이는 일부는 아키텍처 때문이고 일부는 단지 당신의 GPU와 다른 누군가의 API 사이의 차이일 뿐입니다.

정확도 수치가 말해주는 것, 순서대로

바로 여기서부터 그 비교는 더 이상 듣기 좋지 않게 되며, 순서가 중요하므로 차례대로 짚어볼 가치가 있다.

• TypeSafe의 typed-decisions 벤치마크에서 제로샷 — Laya 0.362, 랜덤 0.318, 다수 클래스 0.461, Jev 0.727. Laya는 우연 수준보다 높고 자명한 베이스라인보다 낮다.

• 벤치마크 자체의 훈련 분할로 미세 조정됨 — Laya 0.766 대 Jev 0.727. Laya가 이겼고, 이 승리는 벤치마크의 훈련 데이터를 학습한 체크포인트에서 나온 것이므로, 이는 미세 조정에 관한 진술이지 기본 모델에 관한 진술이 아니다.

• Banking77 의도 분류는 선택지 집합이 큰 경우인데 — Laya 0.425 대 Jev의 0.870입니다. Laya는 선택지가 대략 20개를 넘어가면 급격히 저하되며, Jev의 Choice 필드는 2단계 스코어링 패턴이 필요하기 전까지 최대 255개까지 처리하는 것으로 문서화되어 있습니다.

• 보정 — Laya는 평균 기대 보정 오차 0.466으로 제공되며, 질문 유형별 온도 재적합 후에만 0.081로 개선됩니다. Jev는 TypeSafe가 RLCD(보정된 결정을 위한 강화 학습)라고 부르는 방법으로 훈련되었으며, 모든 답변에 확률 분포를 함께 제공합니다. 하지만 TypeSafe는 또한 사용자에게 자체 레이블이 지정된 데이터로 임계값을 검증하라고 안내하며, 한 독립 감사에서는 Jev의 보정이 작업에 따라 급격히 달라진다는 사실을 발견했습니다.

이 패턴은 명확하다. Laya는 미세 조정에 강한 기반이자 제로샷 결정 엔진으로는 약하며, 스스로도 그렇게 말한다. Jev는 강력한 제로샷 결정 엔진이지만 배포할 때마다 캘리브레이션을 여전히 확인해야 한다. 이들은 서로 다른 가격 구조를 지닌 서로 다른 제품이며, 둘 중 무엇을 선택할지는 대체로 레이블이 지정된 데이터와 훈련 루프가 있느냐의 문제다.

비용 계산은 Jev의 것과 같은 형태가 아니다.

Jev는 입력 토큰 100만 개당 $0.042이고 출력은 무료이며, 이는 10억 개당 $42에 해당합니다. 문서에 명시된 약 32,000토큰 요청 예산에서 최대 규모 호출 비용은 1센트를 훨씬 밑돕니다. Every의 독립 테스트에서는 37개 문서에 걸친 777건의 판단에 약 4분의 1센트가 들었습니다.

Laya의 호출당 비용은 한계적으로는 0이고 총합적으로는 0이 아니며, 그 총합은 작지 않다. T4에서 421M 파라미터 모델을 실행하는 것은 저렴하고 여전히 GPU 하나를 차지한다. 그리고 Laya를 경쟁력 있게 만드는 파인튜닝 단계가 바로 실제 지출이 일어나는 곳이다 — 데이터 라벨링, 학습 실행, 평가 하네스, 그리고 캘리브레이션 오류를 0.466에서 0.081로 낮추는 질문 유형별 temperature 재적합. 절대 바뀌지 않는 고정된 분류 체계라면, 이는 대량 사용 시 회수되는 일회성 비용이다. 분류 체계가 변동한다면, 이는 반복 비용이며, Jev의 0.727 제로샷 기준선이 훨씬 더 나은 선택이 된다.

놓치기 쉬운 세 번째 비용이 있습니다: Laya의 영어 체크포인트는 512토큰 컨텍스트 창을 갖고 있습니다. 그것은 컨텍스트 예산이 작은 결정 모델이 아니라, 한 문단 크기에 맞춰진 결정 모델입니다. Jev의 약 32,000토큰 요청 예산은 60배 더 크며, 그조차도 두 모델이 가격을 견주는 생성 모델들보다 한 자릿수(약 10배) 낮은 수준입니다. 당신의 상태가 지원 메시지가 아니라 지원 스레드라면, 어느 모델의 창도 당신이 최적화해야 할 제약은 아닙니다.

배포 문제가 진짜 차이점이다

Laya의 가장 강력한 주장은 지연 시간이 아닙니다. 그것은 Hugging Face에 있는 Apache 2.0 가중치 덕분에 결정이 결코 귀하의 인프라를 벗어나지 않고 엔드포인트에 속도 제한이 결코 적용되지 않는다는 점입니다. 의료 기록, 법률 문서 또는 고객의 계정 이력에 대해 내려지는 라우팅 결정이라면, 이는 선호 사항이 아니라 결정적 요인이며, 어떤 가격의 호스팅 엔드포인트도 그 주장을 이길 수 없습니다. TypeSafe의 Jev는 얼리 액세스 및 대기자 명단 상태이며, 자체 문서에서도 속도 제한이 예고 없이 변경될 수 있다고 명시하고 있습니다.

반론은 바로 당신이 포기하게 되는 부분이다. Jev의 비공개된 더 큰 아키텍처는 Laya의 421M 파라미터가 할 수 없는 일을 해내고 있다: 0.727 대 0.362의 제로샷 격차와 0.870 대 0.425의 Banking77 격차는 모두 학습시키기 전에 모델 내부에 얼마나 많은 지식이 들어 있는지를 측정한 것이다. Laya의 답은 파인튜닝을 통해 그 지식을 직접 공급하라는 것이며, 좁고 고정된 도메인에서는 그 답이 통한다 — 0.766이라는 파인튜닝 결과가 그 증거다.

실제 스택에서 의사결정 계층이 자리하는 위치

어느 모델도 텍스트를 생성하지 않으므로, 어느 쪽도 어떤 워크플로의 전부가 아닙니다. 두 모델이 함께 설계된 패턴은 두 개의 모델입니다. 즉, 타입이 지정된 호출을 수행하는 결정 계층과, 산문이나 코드, 설명이 필요한 부분을 처리하는 생성 모델입니다. OrcaRouter는 Jev나 Laya를 제공하지 않습니다 — Jev는 TypeSafe의 얼리 액세스 엔드포인트이고 Laya는 직접 실행하는 가중치입니다 — 하지만 그 패턴의 생성 절반이 바로 우리가 다루는 부분입니다. 하나의 OpenAI 호환 키 뒤에 200개 이상의 모델을 공급자 정가를 0% 마크업으로 그대로 전달, 따라서 공급업체 가격이 바뀌면 같은 날 우리 쪽에도 반영됩니다. 이중 모델 아키텍처는 두 번째 공급업체 계약 없이도 테스트할 수 있으며, 자동 페일오버 덕분에 저렴한 결정 계층을 자동화에 활용할 만큼 충분히 보정했는지 판단하는 동안에도 생성 경로가 단일 장애점이 되지 않습니다.

판결

고정적이고 좁은 분류 체계, 레이블이 지정된 예시, 그리고 호스팅 API를 배제하는 프라이버시 또는 지연 시간 요구 사항이 있다면, Laya는 더 방어 가능한 선택이며 미세 조정된 수치가 이를 뒷받침합니다. 결정이 별도 설정 없이 바로 작동하기를 원한다면, 옵션 집합이 20개 범주를 넘어간다면, 또는 상태가 한 문단보다 길다면, Laya 자체의 모델 카드는 그것이 그 작업에 맞는 제품이 아니라고 말해 줍니다 — 그리고 누군가 7.8배 지연 시간 수치를 당신에게 인용할 때 계속 염두에 두어야 할 숫자는 다수결 기준선 0.461에 대비한 제로샷 점수 0.362입니다.

두 대상의 공통점은 이들을 갈라놓는 점보다 더 유용하다. 둘 다 출력 형식에서 비롯되는 오류 부류는 제거하지만, 판단에서 비롯되는 부류에는 아무것도 하지 않는다. 둘 다 확률을 제공하지만, 어느 쪽도 확인하지 않고 신뢰할 수 있는 공개된 신뢰도 다이어그램을 갖고 있지 않다. 어느 쪽에든 자동화를 적용하기 전에 직접 라벨을 붙인 사례에서 보정을 시험하라 — 지연 시간은 이미 상품화되었고, 신뢰도 값은 배포마다 획득해야 하는 부분이다.