pplx-decider vs Kev: 이미 가져올 수 있는 두 시스템 하나의 모델들

이번 맞대결의 유용한 우연은 오늘 오후 여러분의 자체 하드웨어에서 결판을 낼 수 있다는 점이다. Perplexity의 27B 결정 모델인 pplx-decider는 2026-10-01에 별도 발표 없이 등장했고, 2026-10-05에는 v1.1 개정판이 나왔으며, 둘 다 Ollama 라이브러리에 있다. Jared Palmer의 재현 라인인 Kev는 v2가 2026-09-30에 등장한 이후 Ollama에 있었고 0.5B부터 27B까지 아우른다. 둘은 동일한 호출 형태를 사용한다 — 상태 하나와 이름이 지정된 질문 목록, 한 번의 순전파, 확률 반환, 생성된 텍스트 없음 — 따라서 동일한 하네스로 둘 다 실행할 수 있다. 차이는 그 아래의 모든 것에 있다: 출력이 생성되는 방식, 작성자들이 문서화한 내용, 그리고 필요한 GPU 양이다.

애초에 비교 평가를 가능하게 만드는 것부터 시작하세요. 두 모델 모두 텍스트를 작성하지 않습니다. 문서를 넘기고 이름으로 질문을 던지면, 각 질문은 답변 유형을 명시합니다. 2~255개의 레이블이 지정된 선택지 중 하나를 고르는 선택, 예/아니오/알 수 없음 판독값, 또는 설명된 2~10개 수준에 걸친 점수입니다. 답변은 확률로, 질문한 순서대로 도착합니다. 질문 60개가 담긴 티켓은 모델을 한 번 거치는 것이지, 60번 호출하는 것이 아닙니다.

각 모델에서 실제로 결정을 내리는 부분은 얼마나 되는가

Kev의 카드는 내부 문서 밖에서는 보기 드문 방식으로 자체 구성에 대해 명시하고 있으며, 여기서 나온 수치를 믿기 전에 그 세부 내용을 읽어볼 가치가 있습니다. 27B 체크포인트는 Qwen/Qwen3.8-27B에 대한 전체 가중치 지도 미세 조정이며, 그다음 fp32에서 새 모델의 0.85와 v1의 0.15를 혼합한 가중치 평균입니다. 더 작은 크기인 0.8B부터 9B까지는 전체 체크포인트가 아니라 Qwen3.5 기반 위의 LoRA 어댑터로 제공됩니다.

출력이 어떤 형태로 나올지 결정하는 부분은 언어 백본과 별개입니다. Kev는 포인터 헤드를 갖고 있습니다 — fp32로 약 2.6M개의 파라미터로, 25.6B 백본 위에 얹혀 26B를 이루죠 — 이것이 은닉 상태를 사용자가 지정한 옵션에 대한 확률로 바꿉니다. pplx-decider는 공개된 [255, 5120] 리드아웃 헤드로 같은 일을 합니다: bf16으로, 5,120 너비의 은닉 상태에 대해 255개 옵션을 다룹니다.

두 아키텍처, 하나의 아이디어: 언어 모델은 읽고, 작은 헤드가 결정한다. 그래서 둘 다 산문을 생성하지 않으며, 또한 둘 모두 동일한 참조 모델을 기준으로 인용되더라도 한쪽의 벤치마크 점수가 다른 쪽으로 전이되지 않는 이유이기도 하다.

기록상 유일한 맞대결, 그리고 그것을 왜 빼놓을 수 없는지

두 프로젝트 모두 Jev를 기준으로 보고되기 때문에, 이 둘을 나란히 놓고 비교하고 싶은 유혹이 생긴다. 그러지 마라.

Kev의 자체 카드에는 Kev-27B v2를 52.3, v1을 50.2, Jev를 54.0, AutoJev-27B를 50.0으로 기록하는 Decision Index 0.2 행이 있습니다. 이는 깔끔한 동일 스위트, 동일 버전 비교이며, Kev v2가 약 2점 향상되었고 여전히 Jev에 뒤처진다는 것을 보여줍니다.

pplx-decider의 카드들은 v1.1에 대해 스위트 가중 종합 점수 61.56을 보고하는데, 이는 v1의 56.4와 Jev의 57.9에 맞선다. 그들 자체 수치로 보면 한 번의 개정으로 5점 넘게 상승한 것이고, Jev에 대해 3.5점 넘게 앞선 것이다.

그 두 문단은 서로를 빼서 상쇄할 수 없다. 서로 다른 스위트, 서로 다른 작업 구성, 서로 다른 가중치 — 그리고 어느 프로젝트도 가중치를 공개하지 않는다. 그래도 말할 수 있는 것은 더 좁지만 여전히 유용하다: 둘 다 같은 기간에 같은 방향으로 움직였고, 둘 다 백본을 교체하는 대신 리드아웃이 훈련되는 방식을 바꿔서 그렇게 했으며, pplx-decider가 Jev에 비해 주장하는 우위는 Kev의 측정된 결손보다 크다. 그것은 pplx-decider를 테스트할 이유이지, 그것을 믿을 이유는 아니다.

둘 중 오직 하나만이 독립적으로 재현된 수치를 하나라도 갖고 있다. Kev의 Ollama 태그는 태그별 JevBench 통과 수를 공개한다 — kev:27b-nvfp4의 경우 231개 중 205개, 하드 분할에서 111개 중 86개를 포함하며, kev:0.8b의 경우 231개 중 146개까지 내려간다 — 이 수치들은 이용할 수 없는 303개의 봉인 또는 심사위원 채점 과제를 제외하며 공식 리더보드 점수가 아니라는 명시적인 단서가 붙어 있다. 자체 실행이긴 하지만, 반복할 수 있는 자체 실행이다. pplx-decider에는 이에 필적할 만한 것이 아무것도 없다.

Kev가 문서화하지만 pplx-decider는 하지 않는 것

• 온도 — Kev는 T = 1.32, 90% 구간 [1.20, 1.45]로 제공되며 로드 시 적용되므로, 출력되는 확률은 이미 스케일링되어 있습니다. pplx-decider의 카드들은 온도를 전혀 공개하지 않는데, 이는 필요한 캘리브레이션을 직접 맞춰야 한다는 뜻입니다.

• 학습 기록 — Kev v2는 8× H200에서 129 GPU-시간이며, 145,840개 레코드와 337,130개 질문에 대해 1에포크를 수행했고, 레이블은 GLM-5.3, DeepSeek-V4-Pro, Inkling, Mistral Large 3, gpt-oss-120b 및 MiMo-V2.6-Pro가 생성했으며 Jev 출력은 사용되지 않았고, 오염 스크리닝을 통해 102개 평가 파티션 전반에서 6,388개 레코드를 제거했습니다. pplx-decider는 레코드 ID와 체크섬으로 고정된 벤치마크 하위 집합과 함께 Bespoke Labs의 Bespoke Nimble을 기반으로 구축된 파이프라인을 문서화하고, v1.1의 개선을 인과 마스크 제거와 추가 학습 데이터 덕분이라고 보지만, 레코드 수나 GPU-시간, 레이블러 목록은 공개하지 않습니다.

• 정직한 회귀 보고 — Kev의 카드는 자신의 실패를 스스로 기록한다: transfer-v4는 0.8포인트 하락을 기록했고, CUAD는 1.6 하락했으며, breadth-v1의 기대 캘리브레이션 오차는 0.015로 CUAD의 0.053과 대비되고 v1보다 2~4배 나쁘며, 자체 평가에서 선택 낙관주의를 지목한다. pplx-decider의 v1.1 표는 도구가 79.3에서 78.88로 하락하는 동안 다른 모든 범주는 상승함을 보여주지만, 카드에는 이에 대한 언급이 전혀 없다.

• 실패 모드 — Kev의 카드는 오염 스크리닝 범위와 공개된 수치가 산출된 조건을 나열한다. Decider 제품군, 즉 Mapika의 라인은 더 나아가 이를 깨뜨리는 구체적인 입력 형태를 명시한다; pplx-decider는 이 질문에 대해 침묵한다.

이 중 어느 것도 pplx-decider가 더 나쁘다고 말하지 않는다. 문서화는 역량이 아니다 — 출시 게시물을 초안으로 둔 연구소는 Hugging Face에 노트를 공개하는 개인과는 다른 동기를 가진다. 하지만 두 모델이 같은 종류의 결과를 주장하는데 그중 하나만 자신의 temperature를 알려준다면, 알려주는 쪽이 이번 달에 프로덕션에 투입할 수 있는 쪽이다.

컨텍스트 회계, 바로 여기서 둘이 가장 극명하게 갈린다

• Kev — 상태 토큰 65,536개, 질문당 최소 8,192개 추가, 학습은 최대 32,768개까지. 64k 상태에서 상주 메모리 사용량은 피크 시 약 87.1GB에 달하고, 모델 시간 9.4초, 캐시 적중 시 733ms, 단일 클라이언트에서 초당 21.1건 요청, 64개에서는 36.4건입니다.

• pplx-decider — 텍스트와 이미지를 합쳐 8,192 토큰이며, 너무 큰 입력은 잘라내지 않고 거부합니다. Ollama 빌드는 256K 컨텍스트 윈도우를 기재하는데, 저장소 어디에도 이에 대한 설명이 없고 카드 자체의 한도와도 부합하지 않습니다.

그 격차는 실제 워크로드에서 둘 사이의 가장 중대한 단일 차이입니다. Kev는 긴 상태와 그에 대한 많은 질문을 위해 만들어졌습니다. pplx-decider는 상대적으로 작은 입력 예산을 가진 27B 모델로, 이는 짧은 문서와 이미지, 그리고 수천 토큰 안에 들어가는 질문 쪽으로 밀어붙입니다.

• 언어 — 양쪽 모두 영어만, 양쪽 모두 제한 사항으로 명시됨.

• 비전 — pplx-decider는 텍스트, JSON, 이미지를 처리하며, 비전 토큰 비용은 대략 width × height / 1024이고 평가 설정은 512×512로 제한됩니다. Kev는 27B 라인에서 비전을 지원하지 않습니다.

• 서빙 최소 사양 — Kev-27B에는 80GB급 GPU가 필요합니다: bf16 가중치 51.3GB, 상주 약 65.5GB, 64k 상태에서 87.1GB이며, KEV_API_KEY가 설정되지 않으면 서버가 공개적으로 바인딩됩니다. pplx-decider의 bf16 가중치는 약 49GiB이므로 최소 사양은 비슷합니다. 양자화된 Ollama 빌드는 17GB로, 이는 매우 다른 머신입니다.

• 단계 — Kev는 0.5B, 0.6B, 0.8B, 4B, 8B, 9B, 27B에 걸쳐 있으며, 작은 크기들은 LoRA 어댑터입니다. pplx-decider는 하나의 크기이며, 두 번 개정되었습니다.

그것에 베팅하지 않고 베이크오프를 진행하기

두 모델 모두 로컬 가중치로 접근할 수 있으며, 이는 바로 라우팅 계층이 제값을 하는 상황입니다. OrcaRouter는 pplx-decider를 제공하지 않고 Kev도 제공하지 않습니다 — 둘 다 카탈로그에 없으며, 여기서 우리가 이들을 호스팅한다는 주장으로 읽혀서는 안 됩니다. 이 등급에서 우리가 실제로 제공하는 것은 typesafe/jev-1.13이며, 동일한 POST /v1/systemone 호출 형태로 백만 입력 토큰당 $0.042에 노출되며, 이는 자연스러운 대조군입니다: 동일한 인터페이스, 동일한 질문 유형, 자체 GPU는 필요 없습니다.

그러면 3자 비교 평가를 저렴하게 준비할 수 있습니다. 로컬 pplx-decider와 로컬 Kev를 동일한 하네스 뒤에 두고 라우팅된 typesafe/jev-1.13에 맞서게 한 다음, 세 가지 모두를 자체 문서로 채점하고, 이들 사이의 불일치가 임계값이 실제로 어디에 있는지 알려주도록 하세요. 이러한 구성에서는 자동 페일오버가 평소보다 더 중요합니다. 단일 카드에서 돌아가는 로컬 27B는 체인에서 가장 신뢰할 수 없는 구성 요소이기 때문입니다. 폴백을 200개 이상의 모델을 위한 단일 API — 제공업체 정가가 0% 마크업으로 그대로 전달됨 — 로 라우팅하면 실험이 장애로 변하는 것을 막을 수 있습니다. 그리고 pplx-decider 같은 모델이 결국 호스팅 엔드포인트에 도달하면, 대조군을 실행하는 바로 그 키가 이를 실행하며, 별도의 계약도 코드 변경도 필요 없습니다.

답을 바꾸는 것은 무엇인가?

네 가지이며, 그 모두는 취향의 문제라기보다 확인 가능한 것입니다.

pplx-decider가 추론 제공자에 도달하면, 그 검증되지 않은 벤치마크 표는 가격 대 지연 문제가 되고, 문서 격차는 더 이상 중요하지 않게 된다 — 즉, 당신은 호스팅된 판독값에 비용을 지불하는 것이지, 그것을 유지 관리하는 것이 아니다. 독립적인 주체가 공개된 하네스에서 두 모델 중 하나의 JevBench 수치를 재현하면, 전체 비교는 서로 호환되지 않는 두 스위트가 아니라 단일 스위트로 좁혀진다.

CUAD에서 Kev의 문서화된 ECE 약점이 재학습이 아니라 재적합으로 고칠 수 있는 것으로 밝혀진다면, Kev에 반대하는 캘리브레이션 논거는 대부분 사라진다. Kev는 이미 temperature를 함께 제공하고 있고, 그 실패 모드들도 알려진 값이기 때문이다. 그리고 두 장이 아니라 한 장의 카드에서 의사결정 모델이 필요하다면, pplx-decider의 17 GB 양자화 빌드가 여기서 유일한 선택지다. 더 나아서가 아니라, bf16의 27B가 들어가지 못하는 곳에 들어가기 때문이다.

그중 하나가 실제로 일어나기 전까지는, 실무적인 해석은 별로 화려하지 않다. Kev는 오늘 당장 재현할 수 있는 숫자를 가진 쪽이고, 문서화되어 있다고 신뢰할 수 있는 보정을 가진 쪽이다. pplx-decider는 주장하는 상한은 더 높지만, 문서로 남은 근거는 더 빈약한 쪽이다. 이번 달에 출시한다면 첫 번째를 선택하라. 화려한 출시 발표 글을 기다리기보다 조용한 릴리스를 측정하는 편인 팀이라면, 두 번째를 같은 하네스로 끌어들여라.

폴백을 라우팅할 때 0% 마크업으로 그대로 전달된 공급자 정가를 사용하면, 로컬 체크포인트가 체인에서 가장 신뢰할 수 없는 구성 요소일 때 3자 비교 평가가 장애로 이어지는 것을 막아 줍니다.

3자 비교 평가(bake-off)는 이 범주에서 이미 무엇이 실패했는지 물어볼 만한 합리적인 시점이기도 합니다: 의사결정 모델과 관련된 문서화된 AI 사고와 에이전트 실패 사례는 OrcaRouter AI 사고 아카이브에 수집되어 있으며, 각 항목에는 자체 출처, 심각도, 신뢰 등급, 이의 제기 플래그가 함께 제공됩니다.