Jev 대안, LLM 토큰 확률만 뽑아 A/B/C 분류하는 단일 함수 래퍼 등장
- Jev 같은 빠른 분류 전용 모델 없이도, 일반 LLM 출력에서 보기 토큰(A/B/C 등)의 확률만 뽑아 상대 비율로 답을 정하는 단일 함수 래퍼가 공개됨. 실제 답변 문구는 생성되지 않고 첫 토큰 전에 끊김.
- HN 논의에서 Jev는 약 30B 파라미터 모델로 알려졌고, 비슷한 크기 모델 대비 입력 가격이 크게 낮다는 설명. 제작사는 수요가 공급을 넘는다고 밝혀 비용 보조 여지는 낮다는 지적이 나옴.
- Grammar-Based Decoding으로 JSON 응답을 강제하는 방식과의 차이를 묻는 댓글이 있었고, 확률 추출 방식은 출력 문구를 만들어내지 않는다는 설명이 뒤따름. 보기 밖 토큰은 아무리 확률이 높아도 무시됨.
- Mushroom-Systems/lichen 프로젝트가 Jev 벤치마크 대비 정확도와 속도에서 앞서고 가격은 비슷하다고 주장. 다만 Jev는 이미지를 지원하지 않아 직접 비교는 어렵다는 단서가 붙음.
- 문장 종료 판정 같은 실시간 태스크에서는 꼬리 지연시간 측정이 남아 있고, 같은 프롬프트의 일반 LLM이 Jev보다 느리고 머뭇거렸다는 사용 사례가 보고됨. 또 Jev를 OpenAI 호환 엔드포인트로 감싼 jevper 프로젝트도 등장함.
Hacker News opinions
Fireworks AI가 문법 제약을 제대로 지원해서 거기에 올리면 더 잘 될 듯함. 한번 시도해 봐야겠네.
Jev는 그냥 API 개방한 것 때문만은 아닐 거임. 소문엔 30B 모델이고 비슷한 크기 대비 입력 가격이 훨씬 싸대. 제작사가 수익성에 집중하는데 비용을 보조해줄 리 없고, 수요가 공급을 넘는다고도 하더라.
근데 질문은 그거임. grammar 기반으로 JSON 응답을 강제하는 것과 뭐가 구체적으로 다르냐는 거. 이렇게 치면 나도 이미 쓰고 있던 방법인데.
Jev보다 당연히 몇 배는 비싸고 느릴 텐데? 아 근데 Jev는 이미지를 지원 안 해서 직접 비교는 어렵고, lichen이라는 프로젝트가 Jev 벤치마크에서 정확도랑 속도로 앞서고 가격은 비슷하다고 주장하더라.
일반 LLM은 RLHF 학습을 엔지전트처럼 받았으니 Jev보다 확률 보정이 안 좋을 거라 봄. 엄청 큰 모델은 더 초반 레이어에서 결정할 테고, Jev의 RLCD(RLCD)가 가중치에서 정확한 확률 뽑게 훈련하는 게 나아 보임.
스타트렉 자동문 같은 거 이런 걸로 만들면 좋지 않냐는 얘긴데, 실제론 반대임. 근접센서처럼 확실하게 동작하는 문이 사람이 더 편해하고, 매 센서 이벤트마다 클라우드 호출하면 지연이 생기고 데이터센터 터지면 아작남.
자동문에서 의도 판정하려면 정지 이미지나 상태 설명으로는 안 되고 영상 이해가 필요함. V-JEPA2가 그걸 맥북에서 몇 FPS로 돌리고 로컬 학습도 되는데, 이걸이랑 Jev를 체이닝하면 잘 굴러갈 듯함.
A/B/C 중에 하나만 써라 했는데 걔가 D나 '추가 정보 필요'라고 출력하면 어쩔 거냐는 지적은 사실 무의미함. 우리가 건드리는 토큰들의 확률만 뽑아서 상대 비율을 구하고 실제 문구는 아예 생성을 안 함. 첫 토큰 나오기 전에 끊어버려서 걔가 뭘 하고 싶어도 못 함.
나는 Jev를 OpenAI 호환 엔드포인트로 감싼 jevper를 만들어봄. 리포: zhulinchng/jevper.
정확도 말고 이제 볼 건 꼬리 지연시간임. 우리가 문장 끝났는지 판정하는 실시간 태스크에선 같은 프롬프트 쓴 일반 LLM이 Jev보다 느리고 머뭇거렸는데, 둘 다 가격은 거의 같았음.