GLM-5.3-Flash를 Jev식 의사결정 모델로 만들기

AI 요약

Privatemode 팀은 범용 언어 모델을 별도 파인튜닝 없이 Jev 같은 의사결정 모델로 쓰는 방법을 제시합니다. 입력 상태와 선택지를 주고, 모델이 선택지별 확률을 반환하게 하는 방식입니다. GLM-5.3-Flash를 vLLM에서 실행해 공개 데이터셋 29개를 평가했으며, 텍스트 데이터셋 28개에서는 Jev와 비슷한 정확도를 기록했습니다. 이미지 입력도 처리해 Jev와 Laya가 다루지 못하는 스캔 문서 분류까지 지원합니다.

JSON 전체를 생성하지 않고 선택지 토큰만 평가합니다

일반적인 LLM 분류는 답을 JSON으로 출력하게 한 뒤 결과를 파싱합니다. 모델이 JSON을 만들고, 경우에 따라 답을 내기 전 수백 토큰을 추론하므로 처리량이 많은 서비스에서는 지연과 비용이 부담이 됩니다. 답변을 따로 요청하지 않으면 선택에 대한 확신도도 알기 어렵습니다.

이 방식은 프롬프트에 상태와 질문, 번호를 붙인 선택지를 JSON으로 넣고 끝을 choice_index:로 마칩니다. 미리 채운 어시스턴트 응답을 이어 쓰게 해 첫 출력 위치에서 선택지 번호를 예측하게 합니다. 실제로 읽는 값은 생성된 토큰이 아니라 그 위치에서 각 선택지 번호에 부여한 로그 확률입니다. 선택지에 해당하는 값만 정규화하면 각 답의 확률 분포가 나옵니다. 모델은 한 번의 forward pass만 수행하고 JSON 전체를 생성하지 않습니다.

구현은 vLLM의 OpenAI 호환 /chat/completions 기능인 continue_final_message와 add_generation_prompt: false를 사용합니다. allowed_token_ids로 출력 토큰을 선택지 번호에 제한하지만, 저자들은 이를 필수 조건이 아닌 안전장치로 설명합니다. top_logprobs만으로는 부족합니다. 제한을 적용하기 전 분포를 반환하므로 앞에 붙는 공백 같은 토큰이 상위 결과를 차지해 일부 선택지가 빠질 수 있습니다. 요청한 토큰 ID 각각의 로그 확률을 돌려주는 logprob_token_ids를 사용하면 이 문제를 피합니다. 토크나이저도 라이브러리에 고정하지 않고 서버에 프롬프트를 보내 실제 서비스 모델의 토큰 ID를 확인합니다.

Jev와 비슷한 정확도, 환경에 따라 다른 속도와 비용

비교 대상은 Privatemode에서 실행한 GLM-5.3-Flash, TypeSafe의 Jev, 로컬에서 실행한 Convai의 Laya입니다. 세 시스템에 같은 상태와 선택지 이름, 순서, 지시문을 전달했습니다. 데이터셋은 의도 분류, 감성 분석, 주제 분류, 조정, 함의 판별, 질의응답, 법률 텍스트, 스캔 문서 등을 포함하며 영어와 독일어가 섞여 있습니다. Jev와 Laya는 기본 설정을 사용했고, 평가 데이터에 맞춰 프롬프트를 조정하지 않았습니다.

텍스트 데이터셋 28개에서 GLM-5.3-Flash와 Jev는 각각 10개 데이터셋에서 더 높은 정확도를 보였습니다. 나머지 8개에서는 정확도 차이가 1%포인트 이내였습니다. Jev가 중앙값 기준 0.7%포인트 앞섰지만 통계적으로 유의한 차이는 아니었습니다(p=0.64). Laya는 대부분의 데이터셋에서 두 모델보다 낮았고, 중앙값 격차는 13~15%포인트였습니다(p<0.001). 저자들은 temperature 0에서도 GLM-5.3-Flash와 Jev가 같은 실행을 반복할 때 답이 최대 3.5% 달라졌다고 덧붙입니다. 서버 배치 처리와 부동소수점 연산 때문에 결과가 완전히 재현되지 않을 수 있어, 작은 차이는 잡음으로 취급했습니다.

선택지 개수는 모델 선택만큼 정확도에 영향을 줍니다. 같은 질문을 거친 분류와 세분된 분류로 각각 평가한 TREC에서는 선택지가 6개에서 42개로 늘자 Jev가 92.1%에서 85.6%로, GLM-5.3-Flash가 91.2%에서 79.6%로, Laya가 88.4%에서 51.2%로 내려갔습니다. 다만 MASSIVE에서는 18개 시나리오에서 59개 인텐트로 늘렸을 때 Jev와 GLM-5.3-Flash의 점수가 두 언어 모두 상승했습니다. 선택지 수만으로 과제의 난도를 판단할 수 없다는 설명입니다.

독일에서 한 번에 요청 하나씩 측정했을 때 Privatemode는 180ms, 미국에 호스팅된 Jev는 264ms였습니다. 미국에서는 결과가 반대로 Jev가 164ms, Privatemode가 299ms였습니다. 비용은 Jev가 낮습니다. 목록 가격 기준 결정 100만 건에 GLM-5.3-Flash는 약 62유로, Jev는 약 16유로입니다. GLM-5.3-Flash 프롬프트는 고정 오버헤드가 약 55토큰이고 선택지마다 약 20토큰을 추가합니다. Jev는 고정 오버헤드 약 270토큰에 선택지마다 약 10토큰을 더합니다. 선택지가 약 21개보다 적으면 GLM-5.3-Flash가 보내는 토큰이 더 적고, 그보다 많으면 Jev보다 많아집니다.

이미지 입력과 선택지 상한

GLM-5.3-Flash는 비전 모델이므로 텍스트와 함께 이미지를 입력할 수 있습니다. RVL-CDIP의 스캔된 업무 문서 1,600건, 16개 분류에서 정확도 70.2%를 기록했습니다. Jev는 텍스트만 처리하고 Laya도 텍스트 인코더라 이 비교에 참여하지 못했습니다. 이미지가 입력 토큰 약 1,350개를 더하므로 문서 분류 100만 건에는 약 270유로가 듭니다.

선택지 수가 많으면 구현 한계도 생깁니다. vLLM의 logprob_token_ids는 최대 128개 항목을 반환하지만, allowed_token_ids에는 모든 선택지를 지정할 수 있습니다. CLINC150처럼 선택지가 151개인 경우 라이브러리는 같은 질문을 두 번 보내 첫 응답에서 128개, 다음 응답에서 나머지 23개의 확률을 읽고 합칩니다. CLINC150에서 GLM-5.3-Flash는 이 방식으로 87.5%를 기록해 Jev의 78.4%보다 높았습니다. 두 번째 요청과 긴 선택지 목록 때문에 응답 시간은 719ms로 Jev의 249ms보다 길었습니다. 단일 토큰으로 표기 가능한 선택지 번호는 최대 191개라고 설명합니다.

같은 GLM-5.3-Flash가 답변 전에 추론하도록 한 비교에서는 모든 선택지 수 구간에서 정확도가 올라갔습니다. 선택지가 2개인 구간은 85.5%에서 89.9%로, 21~80개인 구간은 79.2%에서 82.0%로 상승했습니다. 대신 결정마다 수백 토큰을 생성해 100만 건 비용이 약 350유로로 늘었습니다. 추론 없이 한 토큰으로 답하는 설정의 비용은 약 62유로입니다. 저자들은 옵션 이름을 동의어로 바꾸는 실험도 했습니다. BoolQ에서 true와 false를 correct와 wrong으로 바꾸자 GLM-5.3-Flash의 정확도는 20%포인트 하락했고, Jev와 Laya의 하락 폭은 3%포인트 미만이었습니다. 다만 질문의 의미도 함께 달라져 이 결과만으로 모델의 암기를 분리해 판단할 수는 없다고 밝혔습니다.

구현과 재현 자료

Python 라이브러리와 벤치마크 코드는 GitHub 저장소에 공개했습니다. 라이브러리는 vLLM 기반 엔드포인트에서 동작하며, 벤치마크 저장소에는 방법론, 데이터셋 사양, 실행 도구, 집계 방식과 원시 실행 결과가 있습니다. 저자들은 공개 데이터셋에서 프롬프트를 조정하지 않았다고 밝히고, 다른 설정이나 데이터셋, 시스템을 추가하는 기여도 요청합니다. Privatemode 배포에서는 confidential computing으로 처리 중 메모리의 데이터를 암호화하고, 클라이언트가 데이터를 보내기 전에 배포 attestation 보고서를 검증한다고 덧붙입니다.

Hacker News 반응

• @m4y0u — 왜 Jev를 쓰지 않나요? 더 빠르고 저렴합니다.
  • @andrewchambers — 본문에서 답한 내용입니다. 속도는 비슷하고 이미지도 지원합니다. GLM은 오픈 웨이트라는 점도 있습니다.
  • @kouteiheika — 오픈 웨이트 모델을 쓰면 계속 접근할 수 있습니다. 한 제공업체가 접근을 막아도 다른 곳에서 쓰거나 직접 호스팅하면 됩니다. 단일 제공업체 API에 갇힌 독점 모델은 접근이 끊기면 곤란합니다.
  • @janalsncm — Jev의 아키텍처가 필요하지 않을 수 있다고 말하려면, 비슷한 지연 시간에서 품질도 비슷하다는 증거가 필요합니다. 지연 시간이 두 배이고 비용이 네 배인 상황에서 품질이 같다는 결과로는 부족합니다.
• @ricardobeat — 2만 3천 단어, 입력 토큰으로 약 3만 개에 이르는 책 일부를 문맥으로 넣었는데 Jev가 800ms, 때로는 500ms 만에 답했습니다. 보통 LLM에서는 불가능한 2만~5만 토큰/초 사전 채우기 속도에 가까워 보입니다.
  • @prometheus1992 — 답이 맞았나요? 제 용도에서 Jev를 써 봤는데 답이 형편없었습니다. Jev 팀은 질문을 더 단순하게 줄이라고 하더군요. 답을 제대로 얻으려고 질문을 얼마나 단순하게 만들어야 하는지 끝이 없습니다. 저는 일단 쓰지 않겠습니다. 입력 토큰 3만 개도 많습니다.
  • @Xorlev — 가능합니다. 질문들이 갈라지는 지점까지 문맥을 한 번 채운 뒤, 각 질문을 이어서 채우고 각 질문의 토큰을 병렬로 생성하면 됩니다. 같은 프롬프트 접두부를 공유하는 요청을 vLLM에 배치하면 블록 크기 정도의 오차를 두고 접두부를 중복 처리하지 않습니다.
• @ttoinou — 이건 당연한 것 아닌가요? Jev 같은 모델이 필요하다고 판단하기 전에 이런 시도를 했을 줄 알았습니다.
  • @petesergeant — 맞습니다. 열흘쯤 전에 비슷한 장난감 프로젝트를 만들려다가 이미 네 개가 있는 걸 발견해 대신 정리했습니다.
• @janalsncm — GLM은 autoregressive decoder를 쓰므로 Jev식이라고 할 수 없습니다. Jev가 가진 속도 이점을 잃습니다.
  • @yogthos — 본문은 요청 하나씩 측정했으며 독일에서 Privatemode가 180ms, Jev가 264ms였고 미국에서는 Jev가 164ms, Privatemode가 299ms였다고 합니다. 문맥을 채운 뒤 소수의 선택지 토큰만 평가하는 요령이 있습니다.
  • @janalsncm — 그렇다면 지연 시간이 두 배가 되고 사용자에게 실시간처럼 느껴지지 않을 겁니다.
• @Jabrov — 농담인가요? ‘Jev식’ 특성이라니요. 사람들은 오래전부터 LLM을 분류기나 순위 모델처럼 써 왔습니다.
  • @nazgul17 — Jev의 구체적인 아키텍처는 LLM보다 문맥을 더 빠르게 채울 수 있습니다.
• @prjkt — 로컬 실행에서 사전 채우기는 0.5%, 디코딩은 0.1%, 캐시가 99.4%이고 지연 시간이 20ms 미만인데, 로컬에서 돌릴 수 있다면 Jev가 어떻게 더 저렴한가요?
• @walrus01 — 충분히 똑똑한 LLM은 무엇이든 예/아니요 같은 결정 모델로 만들 수 있습니다. 저는 이미 두 문단짜리 상세한 프롬프트로 여러 페이지를 보내고 JSON 객체 7개만 반환하게 하는 작업 흐름을 씁니다. 그중 몇 개는 내용에 특정 항목이 있는지 묻는 예/아니요 질문입니다. 호스팅하기 아주 어렵지 않은 Qwen 3.6 35B A3B 변형이나 3.8 27B 같은 로컬 모델로도 됩니다.

원문: Privatemode / 번역·요약: Trawling