TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 24 READS

토큰 확률로 이미지를 분류한다: LLM을 단일 함수로 감싼 실험

토큰 확률로 이미지를 분류한다: LLM을 단일 함수로 감싼 실험
SOURCE IMAGE · HACKER NEWS

대형 언어 모델(LLM)을 다룰 때 우리는 보통 모델이 내놓는 '문장'에만 주목한다. 그러나 모델 내부에서는 다음에 올 토큰마다 확률 분포가 계산되고, 최종적으로 그중 하나가 선택된다. 이 확률값(logprobs)을 직접 읽어내면 모델을 단순한 텍스트 생성기가 아니라 확률 기반 분류기로 활용할 수 있다. 한 개발자가 자신의 블로그에 공개한 실험은 바로 이 아이디어를 최소한의 코드로 정리하고, 나아가 이미지를 다루는 비전 모델까지 확장한 사례다.

출발점은 Jev라는 프로젝트와 그 주변에서 등장한 자체 호스팅 구현들(OpenJev, SemIf)이었다. 저자는 이들을 살펴보다가 토큰 확률을 읽는 기법을 처음 접했다고 밝힌다. 사실 이 방식은 OpenAI가 공개한 logprobs 쿡북 등에서 오래전부터 소개된, 일부 실무자에게는 익숙한 기법이다. 하지만 널리 알려진 관행이라고 보기는 어렵고, 대다수 애플리케이션은 여전히 모델의 최종 답변 문자열만 파싱한다는 점에서 다시 조명할 가치가 있다.

한 글자만 생성시키는 이유

핵심 절차는 단순하다. 객관식 형태의 질문 프롬프트를 만들고, Chat Completions 요청에 확률 관련 JSON 파라미터 몇 개를 추가한다. 그러면 API는 모델이 고른 글자 하나와 함께, 그 자리에 올 수 있었던 대안 토큰들의 로그 확률을 돌려준다. 답변을 단 한 토큰으로 강제하는 것이 이 방식의 요령이다. 장황한 문장을 생성하지 않으니 응답이 매우 빠르고, 정답 여부뿐 아니라 모델이 그 판단에 얼마나 확신하는지까지 확률값으로 읽어낼 수 있다.

물론 출력이 한 토큰이라고 해서 비용이 0이 되는 것은 아니다. 입력 프롬프트를 처리하는 시간은 그대로 든다. 다만 여러 질문이 동일한 상태(state) 프리픽스를 공유한다면, 백엔드가 지원하는 경우 그 부분을 KV 캐시로 재사용해 반복 비용을 줄일 수 있다. 같은 이미지나 같은 맥락에 대해 여러 조건을 연달아 물어야 하는 상황이라면 이 캐싱이 실질적인 처리량 차이를 만든다.

비전 모델로의 확장

흥미로운 지점은 이 기법이 비전 모델에서도 그대로 작동한다는 것이다. Jev가 문서화한 요청 형식은 현재 텍스트와 JSON 상태만 다루지만, 저자는 로컬 실험을 위해 이미지를 담는 attachments 필드를 직접 추가했다. 예제 스크립트는 웹캠 프레임을 캡처해 base64 JPEG로 전송한 뒤, 세 가지 질문에 대한 답을 표로 출력한다. 사람이 보이는가, 실내인가 실외인가, 장면이 얼마나 밝은가 하는 조건들이다. 여기서 OpenCV는 웹캠 접근을 위한 도구일 뿐, 실제 판별은 전적으로 LLM이 담당한다.

성능은 환경에 따라 갈렸다. RTX 3090에서 llama.cpp로 구동한 Gemma 4 12B(QAT)의 경우 프레임당 세 질문을 처리하며 초당 약 1프레임을 얻었다. 반면 OpenAI의 gpt-6-luna로 같은 작업을 돌렸을 때는 초당 약 0.2프레임에 그쳤는데, 저자는 프레임마다 질문마다 별도 연결을 맺는 비용을 줄이려는 최적화를 하지 않았기 때문이라고 설명한다. 참고로 스크립트는 API 방식의 차이도 흡수하는데, llama.cpp는 Chat Completions를, OpenAI는 대안 토큰을 얻기 위해 Responses를 사용한다.

실무적 의미와 한계

이 접근의 매력은 속도나 정확도 자체가 아니라 유연성에 있다. 전용 컴퓨터 비전 모델이 같은 분류 작업을 훨씬 효율적으로 처리한다는 점은 저자도 인정한다. 그럼에도 '실내/실외' 같은 조건을 별도 데이터셋과 학습 없이 자연어 한 줄로 정의하고, 필요할 때 문장만 바꿔 판별 기준을 즉시 교체할 수 있다는 점은 프로토타이핑이나 규칙이 자주 바뀌는 상황에서 분명한 이점이다.

다만 실무 적용 전에 따져볼 지점도 있다. 초당 한 프레임 수준의 처리량은 실시간 영상 분석보다는 간헐적 판별이나 배치 처리에 적합하며, 클라우드 API를 쓸 경우 프레임·질문 수만큼 요청 비용과 지연이 누적된다. 무엇보다 확률값이 곧 정답의 신뢰도를 보장하지는 않는다는 점을 유념해야 한다. 모델은 틀린 답에도 높은 확률을 부여할 수 있으므로, logprobs는 판단의 근거가 아니라 어디까지나 참고 신호로 다루는 편이 안전하다. 결국 이 실험이 보여주는 것은 완성된 제품이라기보다, 로컬 LLM과 확률 출력만으로도 가벼운 분류 파이프라인을 얼마나 빠르게 조립할 수 있는지에 대한 실용적 스케치에 가깝다.

SOURCE · HACKER NEWS
원문 전체 보기 → http://allanrbo.blogspot.com/2026/09/a-jev-like-wrapper-for-...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기 →
처리 중...