Laya vs Nimble: 대조 데이터 대 더 빠른 인코더

Laya와 Nimble은 저자들이 자신들이 어떻게 만들어졌는지 설명하는 데 가장 공을 들인 두 오픈 웨이트 결정 모델이며, 그 설명들은 어려움이 어디에 있는지를 두고 서로 엇갈린다. Convai Innovations는 2026년 9월 18일 Apache 2.0으로 Laya를 공개했다 — 421M ModernBERT-large 영어 체크포인트, 100개 이상의 언어를 지원하는 322M mmBERT-base 다국어 체크포인트, 둘 사이의 서브밀리초 라우터, 그리고 Tesla T4에서 결정당 32.8ms p50라는 공개된 수치다. Bespoke Labs는 Nimble을 Qwen3.5-9B에 대한 LoRA 파인튜닝으로 만들었고, Apache 2.0이며, "오픈소스 Jev"라고 설명한다 — TypeSafe AI의 Jev에서 영감을 받았지만 그 가중치도, 아키텍처도, 출력의 증류도 사용하지 않았다. 정확도 문제에 대한 Convai의 답은 속도와 파인튜닝 가능한 베이스다. Bespoke의 답은 학습 데이터다. 그 차이는 헤드라인 표에 나타나는 3포인트 정확도 격차보다 더 주목할 가치가 있다.

각 프로젝트가 실제로 제기하고 있는 주장

Laya의 주장은 아키텍처에 관한 것입니다. 그것은 엄밀한 의미에서 비자기회귀적입니다 — 양방향 인코더, 디코딩 루프 없음, 파싱할 JSON 없음, 선언된 유형 외부에 텍스트를 출력할 여지가 없습니다. 그 구조적 보장은 Jev가 제공하는 것과 동일하며, 다른 방향에서 도달한 것이고, 가끔 중괄호 닫기를 잊어버리는 모델을 대상으로 재시도 로직을 작성해 본 사람이라면 누구에게나 진정으로 가치가 있습니다. 대가는 512토큰 창을 가진 421M 인코더가 생성적 사전 훈련의 뒷받침 없이 아는 것이 많지 않다는 점입니다. Convai는 모델 카드에서 이렇게 말합니다: "Laya는 특화하기 위한 빠른 기반이며, 제로샷 의사 결정 엔진이 아닙니다."

Nimble의 주장은 데이터에 관한 것이다. Bespoke의 방법은 대조적 큐레이션으로, 팀의 이전 Bespoke-MiniCheck 작업에서 응용한 것이다: 정답 레이블이 뒤집히도록, 하나의 "초점 사실"만 다른 거의 동일한 두 예시를 작성하는 것. 파이프라인은 네 가지 명시된 단계로 이루어진다 — 결정 규칙이 실제로 서로 다른 답으로 이어질 수 있는지 확인하고, 최대 여덟 단어를 바꾸어 쌍을 구성하고, 별도의 모델 호출과 각 문장 제거 점검으로 두 예시를 모두 검증하고, 코드에서 레이블을 생성하며 레이블이 실제로 다른 쌍만 남긴다. 목표는 더 많은 예시가 아니라 더 예리한 예시다: 어떤 근거가 결정을 바꾸어야 하는지 모델이 학습하도록 강제하는 것. 그것은 소형 의사결정 모델이 실패하는 이유에 대한 다른 이론이며, 또 하나의 정확도 수치보다 더 흥미로운 이론이다.

발표된 수치가 실제로 뒷받침하는 것

Nimble은 324개의 홀드아웃 샘플에서 참조 레이블과 90.12% 일치한다고 보고했으며, 이는 Jev의 93.21%, 튜닝되지 않은 Qwen3.5-9B 베이스의 66.36%, 튜닝되지 않은 27B Qwen3.8의 84.88%와 비교됩니다. H100에서는 중앙값 약 106ms, 64GB를 갖춘 M5 Pro에서는 중앙값 444ms를 보고합니다. 이는 Bespoke 자체 하네스 수치입니다. 324개 샘플 평가 세트가 신중하게 따져봐야 할 부분이며, 프로젝트 스스로 그 이유를 밝히고 있습니다. 샘플은 열 개의 학습 소스 패밀리 중 여섯 개에 걸쳐 있고, 인간 검토 없이 모델에 의해 생성되고 검증되었으며, 따라서 보지 못한 범주로의 일반화는 입증되지 않았습니다. 모델이 데이터 큐레이션 방법으로 학습된 다음, 바로 그 동일한 큐레이션된 분포의 홀드아웃 분할에서 평가될 때, 그 정확도 수치는 그 방법의 내적 일관성에 대한 진술일 뿐, 여러분의 트래픽에 대한 진술이 아닙니다.

Laya의 수치는 반대쪽 끝에서 나온다. TypeSafe의 typed-decisions 벤치마크에서 제로샷 0.362를 기록한다. 무작위는 0.318, 다수 클래스 기준선은 0.461이다. 벤치마크 자체의 훈련 분할로 미세 조정했을 때는 0.766이다. Banking77, 77개 레이블에서는 Jev의 0.870에 대비해 0.425를 기록하는데, 이는 선택지가 많을 때의 한계를 가장 선명하게 보여준다. 레이블이 네 개인 AG News에서는 Jev의 0.910에 대비해 0.950을 기록하고, 레이블이 여섯 개인 DAIR Emotion에서는 0.480에 대비해 0.595를 기록한다. 캘리브레이션 오차는 0.466으로 출시되고, 질문 유형별 temperature 재적합 후 0.081로 떨어진다. 100개의 Mars-base 긴급 메시지에 대한 한 제3자 테스트에서 Jev는 100/100, Laya는 53/100이었다. 그리고 독립적인 에이전트 도구 호출 평가에서 Laya는 위험한 호출에 대해 100% 거부 재현율을 달성했지만, 이는 모든 것을 플래그 처리한 덕분일 뿐이며, 안전성 승리로 포장된 정밀도 실패다.

두 숫자 묶음을 나란히 놓고 보면, 정직한 해석은 그것들이 서로 다른 대상에서 측정되었다는 것이다. Nimble의 90.12%는 자체적으로 선별한 참조 라벨과의 일치율이다. Laya의 0.362는 Laya가 구축하지 않은 벤치마크다. 어느 숫자도 그대로 통용되지 않는다.

캘리브레이션: 두 프로젝트 모두 유난히 솔직해지는 유일한 지점

여기가 두 프로젝트가 정신적으로는 가장 가깝고 결과적으로는 가장 멀리 떨어져 있는 지점이다.

Bespoke의 README는 Nimble의 확률이 제공된 후보들에 대한 소프트맥스 정규화 로짓이며, 보정된 정답률이 아니라고 명시적으로 경고합니다 — 0.9가 90% 정확하다는 의미는 아닙니다. 이는 "해당 없음" 옵션을 추가할 것을 권장합니다. 왜냐하면 정답이 후보들 중에 없으면 그중 하나가 여전히 승리하기 때문입니다. 13개 하위 집합에 걸친 최신 3,880개 레코드 평가에서 Jev는 13개 하위 집합 중 11개에서 보고된 보정 오차가 더 낮았고, 13개 중 10개에서 더 낮은 브라이어 점수를 기록했습니다. 따라서 유사한 레이블 일치도가 유사한 확률 품질을 의미하지는 않으며, Bespoke도 그렇게 말합니다.

Convai의 공개 내용은 거울상이다: 0.466의 기대 캘리브레이션 오류가 모델 카드에 적혀 있고, 그 옆에는 질문 유형별 temperature 재적합이 산출하는 0.081이 있다. 두 프로젝트 모두 별도의 작업 없이 그 신뢰도를 의사결정에 활용할 수 있는 모델을 내놓지 않는다. 둘 다 이를 문서로 분명히 밝힌다. 신뢰도 임계값 — 0.95 초과는 자동 릴리스, 0.7 미만은 에스컬레이션 — 을 만들고 있다면, 두 저자의 문서는 같은 것을 말한다: 임계값을 먼저 자신의 라벨링된 데이터에 맞춰라.

차원별로 비교

• 백본 — Laya: ModernBERT-large 421M 인코더, 양방향, 생성 사전 학습 없음. Nimble: LoRA 파인튜닝이 적용된 Qwen3.5-9B, 생성 기반 유지됨.

• 언어 — Laya: 322M 다국어 체크포인트를 통해 100개 이상. Nimble: 영어.

• 프롬프트 예산 — Laya: 영어 512 토큰, 다국어 1,024 토큰. Nimble: 프롬프트당 최대 2,048 토큰, 플랫 스키마만, 열거형은 필드당 최대 26개 옵션으로 제한.

• 속도 — Laya: T4에서 p50 32.8ms, 10개씩 배치할 때 질문당 7.2ms. Nimble: H100에서 중앙값 약 106ms, M5 Pro 64GB에서 444ms.

• 하드웨어 — Laya: CPU, CUDA 및 Apple MPS; MLX 포트에서 상주 메모리 1GB 미만. Nimble: 제시된 수치를 위한 BF16 CUDA GPU, MLX 및 CUDA 경로 지원.

• 보고된 정확도 — Laya: 제로샷 0.362, 파인튜닝 0.766, Banking77에서 0.425. Nimble: 큐레이션된 홀드아웃 샘플 324개에 대해 90.12%로, Jev의 93.21%와 대비됨.

• 방법 — Laya: 아키텍처 우선, 배포별 파인튜닝. Nimble: 대조 기반 데이터 큐레이션, 레시피로 공개.

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

그 목록에 있는 두 가지 제약은 결정을 내리기 전에 두 번 읽어볼 가치가 있습니다. Nimble의 enum당 26개 옵션 상한과 2,048토큰 프롬프트 한도는 성능 저하가 아니라 엄격한 스키마 한계입니다 — 분류 체계에 라벨이 40개 있거나 프롬프트에 긴 문서가 포함되어 있다면, 정확도와 무관하게 Nimble은 잘못된 도구입니다. 그리고 Nimble은 각 필드를 독립적으로 채점하므로, "A가 참이면 B는 거짓이어야 한다" 같은 필드 간 일관성 규칙은 모델이 아니라 코드에 있어야 합니다.

데이터 레시피가 더 이식성 높은 산출물인 이유

다음은 정확도 표들이 놓치고 있는 Nimble을 위한 논거입니다. Bespoke는 가중치만이 아니라 큐레이션 파이프라인을 공개했습니다. 당신의 의사결정 문제에 고정된 분류 체계가 있고 규칙을 적어둘 수 있다면, 대조적 방법은 당신이 선호하는 어떤 기반 모델 위에서든 자신의 데이터와 자신의 포커스 팩트로 실행할 수 있는 것입니다. 9B LoRA는 제품인 것만큼이나 방법에 대한 시연입니다.

Laya의 이식성은 성격이 다르고 상호 보완적입니다. 크기가 작고, CPU에서 실행되며, ONNX와 MLX 포트가 존재하기 때문에 Laya는 GPU도 네트워크도 없는 프로세스 안에 넣을 수 있는 모델입니다. 제3자 브라우저 에이전트 벤치마크에서 Laya는 50개 작업 중 0개를 완료했고 33번의 시도에서 조기 완료를 선언했습니다. 하지만 벤치마크 저자들은 Laya가 탐색이 아니라 지원 티켓, 청구서, 에이전트 추적 검토 같은 판단 작업을 위해 훈련되었다고 지적합니다. 그 결과를 평결이라기보다 범위 선언으로 읽어야 하며, 이는 두 프로젝트의 프레이밍과도 일치합니다. 이것들은 범용 에이전트가 아니라 특정 부류의 결정을 위한 구성 요소입니다.

Laya와 Nimble은 모두 OrcaRouter에서 호스팅되는 모델이 아닙니다. 둘 다 직접 실행하는 가중치이며, 이 글의 어떤 내용도 우리가 이들을 제공한다는 주장으로 읽혀서는 안 됩니다. 라우팅 제품이 언급되는 이유는 여느 의사결정 모델 아키텍처에서 그러하듯, 의사결정 모델은 하나의 호출에 답하지만 그 주변의 애플리케이션에는 여전히 산문이 필요하기 때문입니다. Nimble로 초안이 규정을 준수하는지 점수를 매기고 Laya로 예외를 라우팅하는 파이프라인이라 해도, 초안을 작성할 생성 모델은 여전히 필요합니다. 그 생성 부분을 하나의 OpenAI 호환 엔드포인트에 유지하는 것 — 200개 이상의 모델, 0% 마크업으로 그대로 전달되는 공급자 정가 덕분에 공급업체의 가격 인하가 같은 날 반영되고, 공급자 간 자동 장애 조치가 이루어지며 — 생성 계층의 계약을 건드리지 않고도 의사결정 계층을 교체할 수 있다는 뜻입니다.

그 판결, 그리고 그것을 바꿀 실험

분류 체계가 고정되어 있고 좁으며, 입력이 영어이고 짧고, GPU가 있고, 모델만큼이나 데이터 레시피를 원한다면 Nimble을 선택하세요. 다국어 입력, 40ms 미만의 예산, 또는 GPU가 전혀 없는 프로세스가 필요하다면 Laya를 선택하세요 — 그리고 처음부터 파인튜닝 비용을 산정에 넣으세요. 제로샷 체크포인트가 단순 베이스라인보다 낮으며 모델 카드에도 그렇게 적혀 있기 때문입니다.

판가름할 실험은 실제 트래픽에 대한 짝지은 평가입니다: 동일한 입력, 동일한 옵션 세트, 동일한 신뢰도 임계값을 사용하고, 사람이 붙인 레이블을 기준으로 평가하며, 각각에 대한 신뢰도 다이어그램을 함께 제시합니다. Nimble 자체 문서는 그 확률이 정답률이 아니라고 경고하고, Laya의 카드는 재적합 전 보정 오차가 0.466이라고 보고하므로, 실제로 어떤 모델을 프로덕션 앞에 둘지 알려줄 산출물은 바로 그 다이어그램입니다. 두 프로젝트 모두 자체 다이어그램을 공개하지 않았고, 상대방의 다이어그램도 공개하지 않았습니다. 임계값을 설정하기 전에 자신의 데이터로 그것을 구축하십시오.