비전 모델까지 지원하는 단일 함수 Jev 스타일 래퍼

AI 요약

Jev와 이를 직접 호스팅하는 OpenJev, SemIf를 살펴보다가 토큰별 확률을 읽는 방법을 알게 된 작성자가 단일 함수 형태의 Jev 스타일 래퍼와 웹캠 예제를 공개합니다. 이 방식은 모델에게 긴 답변을 만들게 하는 대신, 여러 선택지 가운데 가장 적절한 항목을 한 글자로 고르게 합니다. API가 반환하는 토큰 로그 확률을 읽어 선택지별 점수로 활용합니다.

한 토큰 답변과 로그 확률

예를 들어 배송 중 파손된 주문의 환불 담당 팀을 묻고, billing·shipping·returns를 각각 A·B·C로 표시합니다. 프롬프트 끝에는 가장 적절한 선택지의 글자만 답하라고 지시합니다. 호환되는 Chat Completions API에는 max_completion_tokens를 1로 설정하고 logprobs를 활성화한 뒤 top_logprobs로 대안 토큰을 요청합니다. 출력 토큰 하나만 생성하므로 답변을 길게 받지 않으며, 입력을 처리하는 시간은 여전히 듭니다. 백엔드가 KV 캐시를 지원한다면 질문마다 반복되는 공통 상태 부분을 재사용할 수 있습니다.

코드는 질문 유형을 선택형(choice), 참거짓형(noul), 순서형 점수(score)로 나눕니다. 선택형은 항목을 A부터 차례로 대응시키고, 참거짓형은 true와 false를 선택지로 둡니다. 점수형은 기준 목록의 순번을 선택지로 사용합니다. 유형마다 후보가 2~20개인지 확인한 다음, API가 반환한 각 글자의 로그 확률을 지수화하고 정규화해 확률로 바꿉니다. 빠진 후보 토큰의 확률이 무시할 수준인지도 검사합니다. 선택형은 확률이 가장 높은 항목을 반환하고, 참거짓형은 true의 확률을 반환하며, 점수형은 항목 순번에 확률을 곱해 기대 점수를 계산합니다.

이미지와 웹캠에 적용

작성자는 Jev 문서의 요청 형식에 이미지 첨부 필드가 없어, 이미지 파일 경로나 base64 데이터 URL을 받는 attachments 필드를 실험용으로 추가했습니다. 예제는 OpenCV로 웹캠 프레임을 읽고 JPEG로 인코딩해 모델에 보냅니다. OpenCV는 카메라 접근에만 쓰며 이미지 자체를 분석하지 않습니다. 모델은 사람이나 식물이 보이는지, 장면이 실내인지 실외인지, 밝기가 어느 정도인지 답합니다.

작성자가 Linux와 RTX 3090에서 llama.cpp로 Gemma 4 12B QAT를 실행했을 때 세 가지 질문을 처리하며 초당 약 1프레임을 얻었습니다. OpenAI gpt-6-luna를 사용했을 때는 약 0.2 FPS였습니다. 질문마다 별도 연결을 보내는 비용을 줄이려는 시도는 하지 않았다고 덧붙입니다. 특화된 컴퓨터 비전 모델이 더 효율적일 수 있지만, 조건을 자연어로 바꿔 유연하게 실험할 수 있다는 점을 장점으로 꼽습니다.

예제 코드는 API 차이도 처리합니다. llama.cpp에는 Chat Completions를 사용하고, OpenAI에서는 대안 토큰 로그 확률을 얻기 위해 Responses API를 호출합니다. OpenAI 요청에는 top_p를 1로 설정하고 출력 토큰 로그 확률을 포함하도록 지정합니다. 로컬 실행을 위해서는 약 7GB 모델 파일과 약 175MB 멀티모달 프로젝터를 받고, llama.cpp 서버를 띄운 뒤 Python 스크립트를 실행합니다.

Hacker News 반응

• @Havoc — 문법 제약 기능을 제대로 지원하는 Fireworks AI에서 더 잘 작동할 것 같습니다.
  • @allanrbo — 알겠습니다. 시험해 보겠습니다. 감사합니다.
• @bicsi — 당연히 작동합니다. Jev는 API의 돌파구일 뿐입니다.
  • @dist-epoch — Jev는 30B 모델이라는 소문이 있고, 입력 가격은 비슷한 크기의 모델보다 훨씬 저렴합니다. 제작자는 수익성 있는 제품에 집중하며 감당할 수 있는 양보다 수요가 많다고 말했으니, 비용을 보조하고 있을 가능성은 낮습니다.
  • @jampekka — Gemma 4 26B A4B의 입력 토큰 가격도 100만 토큰당 0.042달러로 같습니다. GPT-5 nano도 0.05달러라 크게 비싸지 않습니다.
  • @imtringued — 공통 접두부를 공유하는 배치를 보내면 실제로는 시퀀스 길이 차이에 해당하는 만큼만 비용을 내게 됩니다. 출력 토큰을 만들 때 메모리 대역폭을 조금 더 쓰기는 하지만, 예를 들어 메시지 16개를 한 번에 처리하면 자동회귀 패스를 여러 번 거쳐도 Jev보다 크게 느려지지 않습니다.
• @prathje — 좋네요. 이미지에도 쓰고 싶습니다. 그런데 JSON 응답에 Grammar-Based Decoding을 쓰는 것과 같은 방식 아닌가요? Jev가 캐싱을 편하게 해주는 정도인가요? 그렇다면 이미 쓰고 있던 방식입니다.
  • @ulam2 — 저도 궁금합니다. 잘 아는 분이 설명해 주시면 좋겠습니다.
• @arcticbull — 좋네요. Jev보다 몇 자릿수나 비싸고 느린 것 같습니다.
  • @jampekka — Jev는 이미지를 지원하지 않으니 직접 비교하기 어렵습니다. 하지만 전반적으로 이 방식은 자체 벤치마크에서 Jev보다 정확하고 빠르며 가격은 비슷합니다.
• @frabcus — 일반 LLM은 RLHF와 에이전트 훈련을 거쳤으니 Jev보다 훨씬 못할 것 같습니다. 큰 모델일수록 더 이른 레이어에서 답을 정할 것이라고 예상합니다. Jev의 RLCD(Reinforcement Learning for Calibrated Decisions)가 모델 가중치에서 정확한 확률을 내도록 더 잘 훈련하기를 바랍니다.
  • @jampekka — 경험적으로 이 방식이 더 정확하고 빠르며 가격은 Jev와 비슷합니다.
• @CROON_tv — 정확도와 함께 꼬리 지연 시간도 보고 싶습니다. 실제 사용에서 말하는 문장이 끝났는지 판단할 때, 같은 프롬프트를 쓴 일반 LLM은 비용이 비슷한데도 Jev보다 느리고 망설임이 많았습니다.
• @roger_ — “가장 적절한 선택지의 글자만 답하세요”라고 해도 D라고 답하면 어떡하나요? “추가 정보가 필요합니다”라고 답하면요? 보정 문제도 있습니다.
• @TeMPOraL — 이런 방식이 언젠가 자동문 같은 스타트렉의 기술을 실현할 수 있습니다. 문에서 10미터 안에 있을 때 카메라로 의도를 분류하고, 문을 지나가려는 의도가 확실할 때만 열면 됩니다. 핵심은 주변 상황을 파악하고 의도를 추론하는 것입니다.
  • @moregrist — 스타트렉의 장치는 의도를 완벽하게 알아맞히는 것처럼 보입니다. 진지하게 말하면, 의도를 추측하는 자동문보다 일관되게 작동하는 문이 더 낫습니다. 현실에서는 사람의 행동과 의도 모두 모호합니다. 근접 센서 문이 어떻게 움직일지 알기 어렵지 않습니다. 블랙박스 분류기를 추가한다고 사람들이 더 좋아할지는 모르겠습니다. 개인정보 문제는 물론이고, 센서 이벤트마다 클라우드에 요청하면 지연과 데이터센터 장애라는 큰 실패 지점도 생깁니다.
  • @ricardobeat — 이걸 하려면 정지 이미지나 상태 설명이 아니라 영상과 움직임을 이해해야 합니다. 2025년 중반부터 V-JEPA2가 있었고, 맥북에서 초당 몇 프레임을 처리하며 로컬 훈련도 가능합니다. 이를 Jev와 연결해 의사결정에 쓰면 잘 작동할 것 같습니다.

원문: Allan R. B. 블로그 / 번역·요약: Trawling