지난 주는 TypeSafe Jev로 뜨거웠습니다. 기존 LLM이 일련의 문장 답변을 생성하는 것이라면 Jev는 답변 항목별 확률을 제공합니다. Jev는 첫 대답에 이어지는 다음 추론이나 행동 루트를 빠르게 결정하는데 더 적합합니다. 아직 Jev의 Open Weight 모델들이 나오지는 않고 있지만 Laya(Geeknews – Laya – 직접 실행하고 학습할 수 있는 Jev의 오픈소스 대안)와 같은 Open Source가 나오고 있긴 합니다.

원래 Colibri는 VRAM, RAM, NVME/SSD 모두를 이용해서 대용량 AI 모델 실행하기 위한 추론 엔진입니다. 기존 사용할 수 있는 자원을 모두 활용해서 대용량 모델을 Local 실행하고 싶은 욕구를 충족해 줍니다. 물론, VRAM>RAM>NVME/SSD(PCIe)로 갈 수록 낮은 데이터 전송 속도로 인해 실사용 성능이 충분히 나오지 않는 수준이긴 합니다. 어쨌든 Colibri 1.12.0 버전에는 Jev에서 영감을 얻은 Brio mode가 포함되었다 합니다.

AD

다음은 brio mode에 대한 설명 내용을 요약 번역한 것입니다. 상세한 내용은 원 출처를 확인하시기 바랍니다.

===

닫힌 선택지 결정(단일 질문)

  • 모델에게 미리 정의한 옵션 집합을 주고 각 옵션의 확률을 반환받아 결정함.
    예: PR 심사에서 “merge / request changes / close” 중 하나 선택. completion_tokens는 0이고, 답변은 옵션 목록 밖으로 나올 수 없음.
  • 결과에 엔트로피가 따라와서 불확실도를 수치로 판단 가능(임계값 기반 자동화/휴먼 라우팅).


같은 문서(상태)에 대해 여러 질문(다수의 Q)

  • 문서를 한 번만 읽고(스냅샷) 여러 질문을 연속으로 처리하여 비용과 지연을 크게 줄임.
    예: 하나의 PR 텍스트를 읽고 “어떤 조치?”, “테스트가 필요한가?”, “리스크 수준은?” 등 다수 질문을 처리.
  • 페이지 측정치: 같은 상태에서 여러 질문일 때 채팅 대비 큰 비용 절감(예: 약 5.7배 절감 사례 언급).


JSON 객체 채우기(스키마 기반 구조화)

  • 서버에 필드별 허용값 목록을 주면, 서버가 순서대로 각 필드에 대해 하나의 값을 선택해 완성된 JSON을 반환.
  • 각 필드에 대해 선택된 값, 그 값의 확률/로그확률/엔트로피를 함께 제공.
    예: { decision: [merge, request changes, close], needs_tests: [yes, no], risk: [high, medium, low], area: [engine, gateway, docs] } 형태로 채움. 필드 이름은 클라이언트가 제공하므로 모델이 임의의 필드명을 생성 불가.

핵심 동작·제약·설정

  • 서버 상주 필요: 스냅샷(photograph/pin)을 만들어 상태를 메모리에 보관하고 이후 질문들이 빠르게 처리되도록 함.
    요청 구조
  • model, state 또는 messages(대화 이력), question(선택적), options(2~64개의 비어있지 않은 고유 문자열), 또는 schema(객체 필드별 배열) 등.
  • questions 배열로 최대 64개의 질문을 한 번에 보낼 수 있음; 각 질문은 2~64 옵션.


출력

  • completion_tokens: 항상 0(무언가를 생성하지 않음).
  • 각 답변은 선택된 option, 옵션별 확률/로그확률/mean_logprob(또는 sum), 토큰 수, 그리고 entropy(0..1으로 정규화) 제공.


엔트로피 해석

  • 0.0~0.4: 모델이 자신있음
  • 0.4~0.8: 불확실
  • 0.8: 사실상 모름(사람 개입 권장)

비용/성능

  • 많은 질문을 같은 상태에 대해 처리할 때 비용 우위가 뚜렷.
  • 문서가 길고 반복질문이 많을수록 brio의 이점 커짐.
  • 디스크 스트리밍 엔진의 경우 프리필(prefill) 비용이 크므로 스냅샷 재사용이 중요함.

주의사항·한계

  • 옵션이 동일하게 토크나이즈(tokenize)되면 구분 불가.
  • 옵션 목록을 state(프롬프트 텍스트)에 넣지 말 것 — 옵션은 별도 필드로 전달해야 편향과 불필요한 비용을 줄임.
  • 서버 재시작 시 스냅샷 소실: 첫 요청이 다시 전체 비용을 지불.
  • KV 슬롯(스냅샷 슬롯) 수가 적으면 상호 간섭(스냅샷 퇴출)이 발생할 수 있음(한 슬롯이면 동시 대화 1개).
  • mean이나 sum 중 어느 것이 옳은지는 작업에 따라 다름.

추천 활용 예

  • 자동 라우팅: 고객 문의 티켓 분류(예: billing / bugs / sales) — 확률이 낮으면 사람에게 전달.
  • 코드 리뷰 보조: PR 텍스트에 대해 merge/request changes/close 판단과 리스크/테스트 필요성 평가.
  • 대시보드/워크플로 자동화: 여러 필드를 안전하게 채워야 하는 폼을 brio 스키마로 처리(필드 값이 사전에 제한된 경우).
  • 다중 질문 분석: 하나의 정책 문서나 정책 변경에 대해 여러 항목(위험도, 우선순위, 필요한 조치)을 연속으로 묻는 경우.

 

 

 

※ 지난 게시글:

※ 출처: r/LocalLLM, r/openclaw, r/unsloth, r/opencode, r/claude

AD

RELATED ARTICLESMORE FROM AUTHOR

LEAVE A REPLY

Please enter your comment!
Please enter your name here