실행 프로그램과 확장
Qwen으로 로컬 Jev 비슷하게 만들기: SemIf·Simple Jev·openjev-sglang
GitHub에서 Jev를 검색하면 작은 Qwen부터 B200 서버까지 서로 다른 구현이 한꺼번에 나옵니다. 이름만 보면 모두 같은 일을 하는 것 같지만, 어떤 것은 다음 토큰 점수만 읽고 어떤 것은 전용 헤드를 학습하며 어떤 것은 API 모양만 맞춥니다. 내 컴퓨터에서 시험할 프로젝트와 서버 처리량을 보여주려는 프로젝트를 같은 표에 놓으면 판단이 흐려집니다. 실제 차이를 실행 방식부터 나눠보겠습니다.
가장 단순한 출발점은 다음 토큰 점수입니다
선택지를 A, B, C처럼 짧은 토큰에 연결하고 모델이 다음 위치에서 각 토큰에 준 로짓을 읽을 수 있습니다. softmax를 적용하면 후보 안에서의 상대 확률이 나옵니다. 완성 문장을 생성하지 않으므로 디코드 반복은 거의 사라지고 JSON은 서버 코드가 조립합니다. 다만 모델이 선택지 표현을 제대로 이해하는지, 한 토큰으로 분리되는지와 확률이 실제 정답률에 맞게 보정됐는지는 별도 문제입니다. 이 방식은 Jev와 같은 모델을 얻는 방법이 아니라 비교 가능한 첫 기준선을 만드는 방법입니다.
SemIf는 4B 모델로 재현 가능한 기준선을 만듭니다
SemIf는 예전 OpenJev 저장소가 이름을 바꾼 프로젝트로, Qwen3.5-4B의 후보 로짓을 직접 읽습니다. 같은 상태를 여러 질문에 쓸 때 공통 프리필을 재사용하고 질문을 병렬로 나누는 경로를 제공합니다. CUDA에서는 RTX 3090 실험 결과와 원시 기록을 공개했고, Apple Silicon에는 MLX 백엔드를 추가했습니다. 공개 결과에서도 빠른 재사용 경로가 기본 점수화와 일부 판단이 달라진 사례가 있으므로 속도만 남기지 말고 결과 일치 여부를 같이 봐야 합니다. 장비를 사기 전에는 내 업무 질문 열 개로 fresh와 shared 경로를 나란히 확인하세요.
Simple Jev는 작은 모델로 API부터 확인합니다
Simple Jev는 별도 분류 헤드를 학습하지 않고 Transformers와 PyTorch에서 공개 모델의 로짓을 읽습니다. 예제는 Qwen3.5-0.8B를 CPU로 시작할 수 있어 고성능 GPU 없이 요청 형식과 결과 구조를 살펴보기 좋습니다. 작은 모델은 업무 판단 품질이 부족할 수 있으므로 실행 성공을 곧바로 자동화 가능성으로 해석하면 안 됩니다. 먼저 선택지가 두세 개인 짧은 분류에서 작동을 확인하고, 틀린 사례를 모은 뒤 4B나 다른 모델로 올립니다. API 호환성이 필요할 때는 `/v1/classifier`와 `/v1/systemone`이 같은 구현을 부르는지도 클라이언트에서 확인할 수 있습니다.
openjev-sglang은 개인 PC보다 서버 처리량을 봅니다
openjev-sglang은 Qwen3.6-35B-A3B의 NVFP4 체크포인트를 SGLang에 올리고 radix cache와 병렬 요청을 사용하는 구현입니다. 공개 기본 환경은 B200 한 장이므로 단일 소비자 GPU용 설치법으로 읽으면 안 됩니다. 이 프로젝트에서 볼 부분은 큰 모델 이름보다 공통 접두사를 보존해 여러 질문의 프리필을 재사용하는 서버 설계입니다. 질문 64개를 빠르게 처리했다는 공개 수치도 해당 가속기, 입력 길이와 동시성 조건에 묶여 있습니다. 집에서 한 요청을 빠르게 끝내는 목표라면 4B 직접 점수화부터 시작하는 편이 설치와 검증이 쉽습니다.
학습형 구현은 확률의 의미까지 바꾸려 합니다
kev는 Qwen2.5-0.5B 위에 LoRA와 작은 판독 헤드를 붙여 문서와 여러 질문을 한 시퀀스에서 처리합니다. qwen-rlcd는 Qwen3.5-0.8B를 Choice, Score와 Noul 형태의 판단에 맞게 학습합니다. 이런 프로젝트는 기존 모델의 로짓을 그대로 읽는 기준선보다 Jev형 구조에 더 가까이 가려 하지만, 학습 데이터와 평가 범위에 따라 강점이 좁을 수 있습니다. 다운로드 크기와 한 번의 지연만 보고 고르지 말고, 내가 필요한 선택지 수와 문장 변화에 결과가 안정적인지 확인하세요. 공개 프로젝트가 많아진 것은 좋은 출발이지만 아직 하나의 표준 로컬 Jev가 정해진 단계는 아닙니다.
