# \#decision-model **URL:** https://discuss.pytorch.kr/tag/decision-model/9152.md [최신](https://discuss.pytorch.kr/latest.md) · [카테고리](https://discuss.pytorch.kr/categories.md) · [태그](https://discuss.pytorch.kr/tags.md) --- ## [\[2026/10/12 ~ 18\] 이번 주에 살펴볼 만한 AI/ML 논문 모음](https://discuss.pytorch.kr/t/2026-10-12-18-ai-ml/12236)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 18, 2026, 9:30오후 UTC](https://discuss.pytorch.kr/t/2026-10-12-18-ai-ml/12236 "2026-10-18T21:30:30Z")
PyTorchKR​:fire::south\_korea: :thinking::thought\_balloon: :one: 에이전트 실행 환경(Harness)의 자동 진화 및 명시적 상태 관리: 이번 주 선정된 논문들에서는 AI 에이전트의 능력을 극대화하기 위해 모델 자체뿐만 아니라 실행 환경인 하네스(Harness) 를 고도화하는 연구가 두드러졌습니다. Harness^2 와 Harmony Harness는 단일 목표 최적화를 넘어 다양한 환경에 적응할 수 있도록 하네스를 다중 목표로 스스로 진화시키는 방법론을 제안했습니다. 또한 LongHarness는 무한 탐색이나 상태 표류 문제를 방지하기 위해 획득한 증거와 결론의 상호작용을 명시적으로 관리하는 상태 기반 아키텍처를 선보였습니다. 이는 에이전트가 복잡한 작업을 수행할 때 발생하는 혼란을 시스템적으로 통제하고, 자율적인 성능 향상을 이끌어내기 위한 필수적인 발전 방향입니다. :two: 개방형 환경에서의 장기 작업(Long-horizon) 수행 및 자율성 확보: 사전에 정의된 짧은 작업을 넘어, 예측 불가능한 환경에서 장기간 자율적으로 목표를 달성하려는 에이전트 연구들도 핵심 트렌드입니다. 마인크래프트에서 엔더 드래곤을 물리친 Gemini 4 Argon 연구는 여러 에이전트가 사전 스크립트 없이 수천 개의 프로그램을 작성하고 협력하며 장기 계획을 완수할 수 있음을 증명했습니다. 구글의 Google Earth AI GRA는 복잡한 지리공간 분석을 다단계 워크플로우로 분해하여 스스로 계획하고 실행하며, VEPA는 이러한 자율적 에이전트가 돌이킬 수 없는 실수를 하지 않도록 형식적이고 동적으로 진화하는 안전 가드레일을 구축했습니다. 이는 AI가 통제된 실험실을 벗어나 실제 산업과 소프트웨어 공학 현장에 투입될 수 있는 강력한 자율성을 확보하고 있음을 시사합니다. :three: 자기회귀(Autoregressive) 생성의 한계 극복 및 아키텍처 효율화: 세 번째 트렌드는 기존 대규모 언어 모델이 가진 느린 순차적 생성 방식… --- ## [Bespoke Labs, 사실 하나만 바꾼 대조 데이터로 만든 9B 결정 모델 Nimble과 학습 레시피 공개](https://discuss.pytorch.kr/t/bespoke-labs-9b-nimble/12196)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 18, 2026, 10:30오전 UTC](https://discuss.pytorch.kr/t/bespoke-labs-9b-nimble/12196 "2026-10-18T10:30:19Z")
핵심 요약 Bespoke Labs가 Bespoke Nimble 저장소에 Jev식 결정 모델의 학습 데이터, 학습 레시피, 서빙 코드를 공개했습니다. 모델은 Qwen3.5-9B에 LoRA를 붙인 Bespoke-Nimble-9B이고, 답을 생성하지 않고 허용된 답 토큰의 로짓만 읽어 확률을 냅니다. 학습 데이터 2,676개는 거의 같은 두 예제에서 사실 하나만 바꿔 정답을 뒤집는 대조 데이터 큐레이션으로 만들었습니다. 라벨은 모두 모델이 검사한 합성 라벨이며, 사람이 검토하지 않았습니다. 자체 홀드아웃 324개에서 기준 라벨 일치율은 90.12%로, 기반 모델(66.36%)보다 높고 Jev 1.13.0(93.21%)보다 낮았습니다. 사람이 라벨을 단 공개 벤치마크 13개에서는 매크로 평균 74.8%로 Jev(76.0%)에 1.2%p 뒤졌습니다. 가중치 라이선스는 버전마다 다릅니다. 9B와 v2는 Apache 2.0, v3는 CC BY-NC 4.0(비상업)이고, 최신 v4와 v4-max는 가중치 없이 유료 API로만 제공됩니다. Bespoke Nimble 소개 Bespoke Nimble 은 텍스트와 질문 목록(스키마)을 받아, 질문마다 정해진 선택지 중 하나를 고르고 각 선택지의 확률을 돌려주는 결정 모델(Decision Model) 입니다. 추론 과정을 글로 쓰지 않고 한 단계로 답하므로, 라우팅, 정책 확인, 분류, 등급 매기기처럼 코드가 바로 받아 쓸 판단에 맞습니다. 이 형태는 TypeSafe가 9월 14일에 공개한 비공개 모델 Jev에서 왔습니다. Jev와 그 System One 방식은 Jev 소개 글에서 다뤘습니다. Jev가 가중치를 공개하지 않자 커뮤니티에서 재현 프로젝트가 수십 개 나왔습니다. Decision Index와 JevBench로 오픈 결정 모델을 비교한 글에서는 Nimble도 "학습한 헤드와 파인튜닝" 계열의 한 항목으로 짧게 소개했습니다. 이 글은 그 Nimble을 따로 다룹니다. Nimble을 만든 Bespoke Labs는 … --- ## [DigUp: EmbeddingGemma 2 모델로 사진, PDF, 녹음, 영상 속 내용을 문장으로 찾는 (macOS의 Spotlight와 같은) 로컬 파일 검색 앱 🔍](https://discuss.pytorch.kr/t/digup-embeddinggemma-2-pdf-macos-spotlight/12205)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 16, 2026, 8:30오전 UTC](https://discuss.pytorch.kr/t/digup-embeddinggemma-2-pdf-macos-spotlight/12205 "2026-10-16T08:30:40Z")
핵심 요약 DigUp은 Google DeepMind의 EmbeddingGemma 2 모델로 사진, PDF, 문서, 녹음, 영상, 코드를 한 색인에 넣는 데스크톱 앱입니다. 파일 이름 대신 내용을 설명하는 문장으로 파일을 찾습니다. 검색 결과를 열면 PDF는 해당 페이지, 녹음과 영상은 해당 시점, 코드는 편집기의 해당 줄로 이동합니다. 송장 번호나 오류 코드 같은 정확한 문자열은 별도의 키워드 색인으로 찾습니다. 모델(865MB)을 처음 한 번 내려받는 것과 하루 한 번의 업데이트 확인 외에는 네트워크를 쓰지 않으며, 계정과 원격 측정(Telemetry)이 없습니다. Apple Silicon Mac(macOS 14 이상)용이 정식 버전이고 Windows와 Linux용은 2026년 10월 14일에 공개된 베타입니다. 첫 릴리스가 10월 9일인 초기 프로젝트라 버그 보고와 기능 요청 이슈가 많이 열려 있습니다. DigUp 소개 팟캐스트에서 수면 이야기가 나온 대목이나 영상에서 얼룩말이 나온 장면을 다시 찾으려 할 때, 기억나는 것은 파일 이름이 아니라 내용인 경우가 많습니다. DigUp 개발자는 운영체제의 기본 검색인 Spotlight와 Windows Search가 파일을 이름, 텍스트, 메타데이터로 찾는다고 설명합니다. 녹음 속 대화나 영상 속 장면처럼 파일이 보여 주거나 들려주는 내용으로 찾고, 그 페이지나 시점까지 바로 여는 것이 DigUp이 기본 검색과 다른 점입니다. 이번에 소개하는 DigUp은 내 컴퓨터의 파일을 내용 기준으로 색인하는 로컬 검색 앱입니다. 찾고 싶은 것을 문장으로 설명하면 파일 종류와 상관없이 맞는 결과를 보여 줍니다. DigUp은 Google DeepMind가 2026년 10월 공개한 멀티모달 임베딩 모델 EmbeddingGemma 2를 사용합니다. 임베딩(Embedding) 모델은 입력을 고정 길이의 벡터로 바꾸고, 뜻이 가까운 입력끼리 벡터도 가깝게 놓는 모델입니다. EmbeddingGemma 2는 텍스트, 이미지, 오… --- ## [Unsloth, LLM을 Laya, Clef와 같인 Jev식 결정 모델을 미세조정하고 로컬에서 서빙하는 학습 가이드 공개](https://discuss.pytorch.kr/t/unsloth-llm-laya-clef-jev/12158)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 12, 2026, 11:00오후 UTC](https://discuss.pytorch.kr/t/unsloth-llm-laya-clef-jev/12158 "2026-10-12T23:00:58Z")
핵심 요약 Unsloth의 결정 모델 학습 가이드가 공개되었습니다. Qwen, Gemma, Llama 같은 LLM에 작은 결정 헤드를 붙여 LoRA로 학습하면, 문장 대신 선택지별 확률을 돌려주는 Jev식 결정 모델이 됩니다. 학습은 Unsloth 앱의 Train 탭에서 Train as를 Decision model로 바꾸거나, 파이썬에서 FastDecisionModel과 DecisionTrainer를 써서 진행합니다. 무료 Colab 및 Kaggle 노트북도 함께 제공됩니다. Unsloth가 공개한 결과에서 Qwen3.5-0.8B는 typed-decisions 정확도가 36%에서 73%로, BANKING77은 7%에서 74%로 올랐습니다. 다만 typed-decisions의 정답은 4B급 교사 모델이 매긴 것이고, 데이터셋 저자가 밝힌 상한은 0.735입니다. 로컬 서빙 문서에 따르면, 학습한 모델과 오픈 가중치 모델 Laya, Clef를 로컬 Jev 호환 API(/v1/systemone)로 서빙할 수 있습니다. 기존 typesafe-sdk 코드는 주소만 바꾸면 됩니다. 결정 모델 관련 코드는 unsloth 저장소에 있습니다. 저장소 핵심 패키지는 Apache 2.0이지만, 결정 모델 소스 파일 머리말에는 AGPL-3.0-only가 적혀 있습니다. Unsloth의 결정 모델 학습 기능 소개 Unsloth가 LLM을 결정 모델(Decision Model) 로 미세조정(Fine-tuning)하는 기능과, 그 모델을 로컬에서 Jev 호환 API로 서빙하는 기능을 추가했습니다. 결정 모델은 문장을 쓰는 대신, 입력을 읽고 미리 정한 선택지마다 확률을 돌려주는 모델입니다. 고객 문의 분류나 에이전트의 도구 호출 승인처럼 정해진 보기 중 하나를 고르는 판단에 쓰입니다. 이런 판단은 지금까지 주로 두 가지 방법으로 처리했습니다. 하나는 채팅 LLM에게 답을 문장이나 JSON으로 쓰게 한 뒤 파싱하는 방법입니다. 이 방법은 토큰을 생성하는 시간이 들고, 출력 형식… --- ## [Microsoft, Jev 호환 API의 결정 모델 Microsoft-Decision-1 출시 (입력 1M 토큰당 $0.042)](https://discuss.pytorch.kr/t/microsoft-jev-api-microsoft-decision-1-1m-0-042/12140)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 12, 2026, 10:00오전 UTC](https://discuss.pytorch.kr/t/microsoft-jev-api-microsoft-decision-1-1m-0-042/12140 "2026-10-12T10:00:16Z")
핵심 요약 Microsoft가 2026년 10월 9일 Microsoft-Decision-1 발표 글에서 문장 대신 선택지별 확률을 돌려주는 결정 모델을 정식(GA) 출시했습니다. Qwen3.5-9B를 후학습했고, 가중치는 배포하지 않습니다. 요청 형식은 Jev와 같습니다. state 와 questions 를 보내고, noul, choice, score 세 가지 질문 유형으로 답을 받습니다. 엔드포인트 경로도 /systemone 입니다. Microsoft가 고른 공개, 비공개 벤치마크 36개(147,137문항)에서 평균 정확도 83.5%로 1위였고, Jev 1.13.0은 82.3%였습니다. 보정(calibration) 점수는 92.2로 3위입니다. 반면 독립 리더보드 JevBench의 10월 10일 측정에서는 Jev급 비용, 지연 시간 상한 안에 드는 API 결정 모델 14개 중 7위(Capability 70.8)로, Jev(77.1)와 OpenAI Decisions(73.5)보다 낮았습니다. Microsoft Foundry와 OpenRouter에서 쓸 수 있고, 입력 100만 토큰당 $0.042이며 출력 토큰은 무료입니다. 입력은 텍스트만 받고, 컨텍스트는 32,768토큰입니다. Microsoft-Decision-1 소개 Microsoft-Decision-1 은 문장을 생성하지 않고, 정해진 선택지마다 확률을 매겨 돌려주는 결정 모델(Decision Model) 입니다. 분류, 라우팅, 우선순위 지정, 검증, 워크플로우 제어처럼 프로그램이 답을 바로 받아 다음 동작을 정하는 작업을 위해 만들어졌습니다. 이 부류의 모델은 2026년 9월 TypeSafe AI가 공개한 Jev에서 시작했습니다. 그 뒤 Liquid AI가 Jev 호환 API의 d1과 오픈 가중치 d1-3B를 내놓았습니다. 오픈소스 쪽에서도 재현 모델이 수십 개 나왔고, 이들은 Decision Index와 JevBench 비교 글에서 정리했습니다. OpenAI도 DevDay에서 Decisi… --- ## [Liquid AI, 엣지 기기에서 한 번의 순전파로 판단하는 결정 모델 d1-3B와 d1-omni-600M 공개](https://discuss.pytorch.kr/t/liquid-ai-d1-3b-d1-omni-600m/12130)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 9, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-d1-3b-d1-omni-600m/12130 "2026-10-09T06:30:14Z")
핵심 요약 Liquid AI가 Open d1 소개 글에서 결정 모델 두 종의 가중치를 공개했습니다. 디코더 기반 d1-3B는 텍스트와 이미지를, 인코더 기반 실험판 d1-omni-600M은 텍스트와 이미지 또는 텍스트와 음성을 받습니다. 두 모델 모두 문장을 생성하지 않고, 예/아니오(Noul), 선택(Choice), 점수(Score) 질문에 대한 확률을 순전파 한 번으로 돌려줍니다. Transformers와 llama.cpp로 로컬에서 실행할 수 있습니다. Liquid AI가 직접 잰 Decision Index 0.2.1에서 d1-3B는 48.57점으로 10B 미만 모델 중 가장 높았습니다. d1-omni-600M은 15.95점이며, Hugging Face 블로그 본문에는 이 점수가 빠져 있습니다. d1-3B는 Jetson AGX Thor에서 질문 하나에 16ms, Jetson Orin Nano에서 50ms가 걸렸습니다. d1-omni-600M의 속도는 공개하지 않았습니다. 라이선스는 LFM Open License v1.0입니다. 연 매출 1천만 달러 이상인 기업의 상업적 사용은 허가 범위 밖이어서, Liquid AI 블로그의 "제한 없이"라는 표현과 다릅니다. :information\_source: 이전 d1 글과 무엇이 다른가요? 이전 d1 글은 9월 말 출시된 호스팅 API d1을 다뤘고, 이 글은 가중치를 공개한 별도의 작은 모델 두 종을 다룹니다. 대상 모델: 이전 글은 가중치를 공개하지 않은 API d1, 이 글은 공개 가중치 d1-3B와 d1-omni-600M입니다. 이름은 같은 계열이지만 서로 다른 모델이고, Decision Index 자체 측정 점수도 약 60점 대 48.57점으로 다릅니다. 실행 방식: 이전 글은 Liquid API를 typesafe-sdk로 호출하는 방법을, 이 글은 Transformers, llama.cpp, Jetson에서 로컬로 실행하는 방법을 설명합니다. 다루는 내용: 이전 글은 질문 설계, confi… --- ## [Jeff-Code: 0.8B 결정 모델이 턴마다 사고 여부를 골라 Qwen3.8-27B의 작업당 시간을 32% 줄인 Pi 포크](https://discuss.pytorch.kr/t/jeff-code-0-8b-qwen3-8-27b-32-pi/12122)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 8, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/jeff-code-0-8b-qwen3-8-27b-32-pi/12122 "2026-10-08T06:30:36Z")
핵심 요약 Jeff-Code는 Pi 코딩 에이전트를 포크한 연구용 코드입니다. 0.8B 결정 모델 Jeff가 Qwen3.8-27B의 매 턴 앞에서 두 가지를 정합니다. 파일 읽기나 코드 검색 같은 정보 수집 단계를 자기가 먼저 실행할지, 이번 턴에 Qwen의 사고 모드를 켤지입니다. 6개 벤치마크에서 짝지은 과제 1,242개를 실행했습니다. 통과율은 62.8%와 62.4%로 차이가 확인되지 않았습니다(-0.2%p, 95% 구간 -2.6 ~ +2.1). 과제당 시간은 0.68배였고, JeffHub 소개 페이지의 "47% 빠름"은 이 값의 역수입니다. 전체 과제 시간의 합계는 0.86배로 덜 줄었습니다. 평가 로그를 보면 Qwen 턴의 74.1%가 사고 없이 돌았고, Qwen 턴 82,435번에 비해 Jeff가 대신 실행한 단계는 2,600번이었습니다. 사고를 모든 턴에서 끄면 더 빠르지만 통과율이 7.6%p 떨어졌습니다. 수치는 저장소 관리자가 낸 평가 보고서 기준이며, 보고서 머리에는 중간(INTERIM) 표시가 있습니다. 두 어댑터는 Qwen3.8-27B와 Jeff v1.3 베이스 조합에서만 측정되었고, Terminal-Bench 2.0에서는 속도 향상이 뚜렷하지 않았습니다. Jeff-Code 소개 Jeff-Code는 로컬에서 실행하는 27B 추론(reasoning) 모델 코딩 에이전트의 시간을 줄이려는 프로젝트입니다. 큰 모델이 매 턴마다 하던 판단 중 일부를 0.8B 결정 모델에게 넘기는 방식입니다. Qwen3.8-27B 같은 추론 모델은 행동 하나를 고르기 전에 사고(thinking) 토큰을 먼저 생성합니다. 그런데 코딩 에이전트의 턴 중 상당수는 파일 하나를 열거나 폴더 목록을 보는 일처럼 깊은 사고가 필요 없는 일입니다. Jeff-Code는 이런 턴을 골라내는 일을 작은 모델에게 맡깁니다. 여기서 판단을 맡는 모델이 Jeff입니다. Jeff는 Qwen3.5-0.8B를 미세조정(fine-tuning)한 결정 모델(Decision Model) … --- ## [Jev와 유사한 오픈소스 결정 모델에 대한 정리: Decision Index와 JevBench로 비교한 결정 모델 성능 비교](https://discuss.pytorch.kr/t/jev-decision-index-jevbench/12095)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 5, 2026, 11:30오후 UTC](https://discuss.pytorch.kr/t/jev-decision-index-jevbench/12095 "2026-10-05T23:30:32Z")
핵심 요약 Jev Decision Index는 Hugging Face의 ML 엔지니어 apolinário(multimodalart)가 운영하는 Space입니다. News 탭은 Jev 재현 산출물 66개를 모으고, Index 탭은 모델 70개를 같은 38개 벤치마크로 채점합니다. Decision Index 0.2.1에서 Jev는 57.91점이고, 가장 가까운 오픈 모델은 Surogate Rune 26B-A4B v3(57.44점)와 Gemma 4 31B에 디코딩 기법만 얹은 Decider chat(57.33점)입니다. Jev를 넘은 오픈 모델은 아직 없습니다. 비용과 속도까지 점수에 넣는 JevBench에서는 순위가 달라집니다. 공식 점수 1, 2위는 Cygnet(73.7)과 Winnow-12B Q8(73.2)이고, Jev는 72.1로 3위입니다. 이미지를 보고 결정하는 Image JevBench에는 Jev가 없습니다. Jev API가 이미지를 받지 않기 때문이며, 오픈 모델 중에서는 Imajev-4B가 종합 2위(76.39)입니다. 세 리더보드는 모두 영어 데이터로 채점합니다. 모델 카드에 한국어(ko)를 적은 모델은 Index의 70개 중 2개뿐이므로, 한국어 업무에 쓰려면 직접 검증이 필요합니다. 오픈소스 Jev 재현 모델과 Decision Index 소개 TypeSafe AI가 2026년 9월 중순에 공개한 Jev는 문장을 생성하지 않는 결정 모델(Decision Model) 입니다. 프로그램 상태와 질문을 넣으면, 선택지 하나(Choice), 점수(Score), 참과 거짓(Noul) 중 하나를 확률과 함께 돌려줍니다. TypeSafe는 모든 질문을 한 번에 병렬로 처리해 응답이 빠르고, 출력 형식이 정해져 있어 파싱 오류가 나지 않는다고 설명합니다. Jev의 설계와 학습 방법인 보정된 결정을 위한 강화학습(Reinforcement Learning for Calibrated Decisions, RLCD) 은 Jev 소개 글에서 자세히 다뤘습니다. … --- ## [Liquid AI, 문장 생성 대신 Jev 호환 API로 분류 / 라우팅 / 점수를 처리하는 결정 모델 d1 공개](https://discuss.pytorch.kr/t/liquid-ai-jev-api-d1/12063)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [10월 1, 2026, 6:30오전 UTC](https://discuss.pytorch.kr/t/liquid-ai-jev-api-d1/12063 "2026-10-01T06:30:20Z")
Liquid AI d1 소개 Liquid AI가 공개한 d1 은 문장을 생성하지 않고, 애플리케이션이 미리 정한 선택지에 대한 확률을 한 번의 호출로 돌려주는 이 회사의 첫 결정 모델(Decision Model) 입니다. 고객 문의를 어느 팀으로 보낼지, 이 메시지가 유해한지, 장애의 긴급도가 어느 단계인지처럼 답의 후보가 호출 전에 정해져 있는 판단을 겨냥하며, 응답의 output\_tokens 는 항상 0입니다. 가중치는 공개되지 않았고 Liquid API로만 제공됩니다. d1을 이해하려면 먼저 이 모델이 들어선 자리를 봐야 합니다. 2026년 9월 TypeSafe AI가 System One 모델 이라는 이름으로 Jev를 공개하면서, 토큰 대신 타입이 정해진 확률적 결정을 내놓는 모델이라는 범주가 생겼습니다. 이후 몇 주 사이에 Jev를 공개 가중치로 재현하려는 프로젝트가 쏟아졌습니다. PyTorchKR에서도 kev, vLLM Semantic Router 팀의 Decision 1.0, Laya를 소개했고, 1천여 개 프로젝트를 정리한 Jev 생태계 목록도 나왔습니다. d1은 LFM 시리즈로 소형 모델을 만들어 온 기존 모델 회사가 이 흐름에 자체 API로 합류한 사례입니다. d1에서 가장 먼저 눈에 띄는 점은 인터페이스가 Jev와 같다 는 것입니다. 질문 유형 이름(Noul, Choice, Score)이 같고, 공식 문서의 Python 예제는 TypeSafe가 배포하는 typesafe-sdk의 TypeSafeClient 에 base\_url="https://api.liquid.ai" 만 바꿔 넣어 호출합니다. 엔드포인트 경로도 /decisions/v1/systemone 입니다. 따라서 이미 Jev로 판단 로직을 짠 개발자라면 API 키, 주소, 모델 이름 세 가지만 바꿔 d1을 시험할 수 있습니다. 이 글은 Liquid AI가 공개한 결정 모델 문서, LLM 호출을 결정 모델로 옮기는 가이드, 실시간 레이싱 게임 예제인 Road Decider, 그리… --- ## [Laya: 텍스트 생성 없이 한 번의 순전파로 결정을 내리는 Jev 호환 오픈 가중치 모델과 로컬 실행 도구들](https://discuss.pytorch.kr/t/laya-jev/12027)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 28, 2026, 10:01오후 UTC](https://discuss.pytorch.kr/t/laya-jev/12027 "2026-09-28T22:01:00Z")
Laya 소개 문의 메일을 어느 팀에 배정할지, 이 프롬프트가 탈옥(jailbreak) 시도인지, 고객이 해지를 암시하는지처럼 소프트웨어가 짧게 내려야 하는 판단은 대부분 정해진 선택지 중 하나를 고르거나 확률 하나를 매기는 일입니다. 이런 판단을 대형 언어 모델(LLM)에 맡기면 답을 토큰 단위로 생성해야 하고, 생성된 문자열에서 레이블을 파싱해야 하며, 모델이 적어 낸 "confidence": 0.9 도 실제 정답 확률을 잰 값이 아니라 생성된 텍스트입니다. TypeSafe AI가 이 자리에 텍스트 대신 확률을 돌려주는 Jev (:pytorch::kr: Jev, 토큰 대신 확률적 결정을 내놓는 새로운 형태의 System One 모델 (feat. TypeSafe AI))를 호스팅 API로 내놓았고, 이번에 소개하는 Laya는 같은 방식의 결정 모델(Decision Model) 을 가중치까지 공개한 프로젝트입니다. Laya는 문서, 이메일, 티켓, JSON 같은 상태(state) 하나와 타입이 정해진 질문 여러 개를 받아, 인코더를 한 번 통과시키는 순전파(forward pass)로 모든 질문에 답합니다. 질문 유형은 선택지 중 하나를 고르는 choice, 순서가 있는 등급에 위치를 매기는 score, 명제가 참일 확률을 돌려주는 noul 세 가지이며, 출력은 문장이 아니라 선택지별 확률 분포입니다. 개발사는 텍스트를 생성하지 않으므로 파싱할 것도 환각(hallucination)이 끼어들 자리도 없다고 설명합니다. 속도는 Tesla T4 한 장에서 질문 하나에 32.8ms(다국어 체크포인트), 질문 10개를 묶으면 72.3ms입니다. Laya는 Convai Innovations가 개발했고, 대표인 Nandakishor가 저장소를 운영합니다. 영어용 ModernBERT-large와 100개 이상의 언어용 mmBERT-base를 인코더로 쓰는 체크포인트 세 개를 제공하고, 요청마다 언어를 감지해 체크포인트를 고르는 Router 를 함께 제공합니다. 저자는… --- ## [vLLM Semantic Router팀, Jev와 유사한 Decision 1.0 기능 및 6개 모델, Decision Studio 공개](https://discuss.pytorch.kr/t/vllm-semantic-router-jev-decision-1-0-6-decision-studio/12005)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 25, 2026, 1:30오전 UTC](https://discuss.pytorch.kr/t/vllm-semantic-router-jev-decision-1-0-6-decision-studio/12005 "2026-09-25T01:30:14Z")
Decision 1.0과 Decision Studio 소개 vLLM Semantic Router 팀이 공개한 Decision 1.0 은 문장을 생성하는 대신, 애플리케이션이 제시한 선택지와 판단 기준에 대해 확률을 반환하는 6개 공개 가중치 모델입니다. 사용자는 같은 고객 문의를 두고 담당 부서를 고르거나, 환불 요청이 있는지 확인하거나, 긴급도를 매기는 질문을 각각 정의할 수 있습니다. 모델의 출력은 다음 처리 단계에서 사용할 수 있는 선택 결과와 확률 분포입니다. 기존 라우터의 개요는 PyTorchKR의 vLLM Semantic Router 소개 글에서도 볼 수 있습니다. 기존의 대형 언어 모델도 이런 판단을 문장이나 JSON으로 표현할 수 있습니다. 하지만 실제 서비스에서는 허용된 선택지가 바뀌고, 판단 기준을 여러 질문에 반복 적용하며, 결과를 후속 규칙과 연결해야 합니다. Decision 1.0은 상태(state), 질문(question), 후보 또는 평가 기준(criteria) 을 입력으로 받아 이 판단 단계를 별도 모델 인터페이스로 다룹니다. 따라서 중요한 차이는 새 챗봇을 하나 더 만드는 데 있지 않고, 소프트웨어가 선택 가능한 결과를 직접 지정한다는 데 있습니다. Decision Studio는 이 6개 모델을 브라우저에서 시험하는 공간입니다. 블로그는 모델의 의도와 구조를 설명하고, Studio는 같은 질문을 여러 사례에 적용하거나 하나의 사례에 여러 질문을 던져 결과 확률을 살펴보게 합니다. 아래에서는 두 자료를 함께 읽되, 공개된 기능과 앞으로의 계획을 구분해 소개합니다. 문장 생성 대신 세 가지 형식으로 판단합니다 Decision 1.0의 입력은 판단할 자료인 상태와 이름을 붙인 질문들입니다. 모델은 사용자가 정의한 후보를 비교하고, 질문 유형에 맞는 확률을 냅니다. 후보는 고정된 학습 라벨만 쓸 필요가 없으며, 요청 시점에 이름과 설명을 전달할 수 있습니다. 예를 들어 배송 지연 문의에 대한 담당 부서 후보를 delivery,… --- ## [kev: 비공개 모델 Jev를 Qwen과 LoRA로 재현해 맥북에서 학습하고 실행하는 결정 모델](https://discuss.pytorch.kr/t/kev-jev-qwen-lora/11963)
**Author:** [@9bow](https://discuss.pytorch.kr/u/9bow)\ **댓글:** 0\ **마지막 업데이트:** [9월 20, 2026, 9:00오전 UTC](https://discuss.pytorch.kr/t/kev-jev-qwen-lora/11963 "2026-09-20T09:00:23Z")
kev 소개 소프트웨어가 사람 손을 거치지 않고 내리는 판단, 예를 들어 들어온 문의를 어느 팀으로 보낼지나 이 요청을 사람에게 넘길지 같은 결정을 대형 언어 모델(Large Language Model, LLM)에 맡기면 한 가지 문제가 남습니다. 모델은 "confidence": 0.9 라는 글자를 만들어 낼 뿐이고, 그 글자가 나올 확률과 답이 실제로 맞을 확률은 서로 다른 값입니다. 구조화된 출력(Structured Output)이나 함수 호출로 응답 형식을 강제해도 이 간극은 그대로 남고, 판단 하나를 위해 토큰을 한 개씩 생성하는 비용도 함께 남습니다. 이번에 소개하는 kev는 그 자리에 텍스트 생성 대신 확률 판독을 놓은 결정 모델(Decision Model) 을 Qwen 베이스 모델 위에 오픈소스로 재현한 프로젝트입니다. kev는 Qwen (:pytorch::kr: Qwen3: 더 깊게 사고하고, 더 빠르게 반응하는 대규모 언어 모델) 베이스 모델에 LoRA(Low-Rank Adaptation) 어댑터와 작은 포인터 판독 헤드(Pointer Readout Head)를 붙인 구조입니다. 문서 하나를 상태(state)로 한 번 읽은 뒤, 그 문서에 대한 여러 개의 타입이 정해진 질문을 한 번의 프리필(prefill) 패스에서 동시에 답합니다. 문서와 모든 질문은 하나의 토큰 시퀀스로 묶이고, 블록 인과 마스크(block-causal mask)가 각 질문이 문서는 볼 수 있지만 다른 질문은 볼 수 없도록 막습니다. 마지막에 포인터 헤드가 질문마다 선택지를 결정 토큰과 견주어 점수를 매기고 소프트맥스를 적용하며, 그렇게 나온 확률 분포가 곧 응답입니다. 디코딩 단계가 아예 없으므로 kev는 글자를 한 자도 생성하지 않습니다. kev가 재현 대상으로 삼은 Jev (:pytorch::kr: Jev, 토큰 대신 확률적 결정을 내놓는 새로운 형태의 System One 모델 (feat. TypeSafe AI))는 TypeSafe AI가 얼리 액세스로 …