llama.cpp Decision Models — /v1/systemone이 분류·라우팅을 확률로 응답합니다

SVIL - Singularity Visual Intelligence Lab 2026. 10. 03 9 min read

llama.cpp가 생성형 대화 모델과는 다른 ‘Decision Models’를 서버에서 제공하기 시작했어요. 새 /v1/systemone API는 상태와 질문, 고정된 선택지를 받아 각 선택지의 점수를 반환합니다. 모델이 자유문장을 만든 뒤 다시 읽어 분류하는 대신, 처음부터 분류·라우팅 같은 선택을 직접 평가하는 구조예요.

세 갈래 청록빛 선이 중앙으로 모이는 추상 이미지 — 분류 모델이 입력을 한 결과로 모으는 장면

발표에서 바뀐 것

llama.cpp 서버에 의사결정 모델을 위한 /v1/systemone 엔드포인트가 추가됐어요. 관련 모델도 GGUF로 공개돼 로컬 실행 흐름에 들어왔습니다.

Decision Model은 어떤 모델인가요

일반 대화 모델은 다음 토큰을 이어 쓰지만, 의사결정 모델은 미리 정한 답 후보에 점수를 매겨요. 출력이 선택지 안에 머물러 후처리에서 문장을 해석하는 부담을 줄입니다.

검은 기하학적 입체 사이를 잇는 청록빛 빔 — 요청이 적절한 업무 경로로 연결되는 모습

새 API가 받는 입력

요청에는 텍스트나 JSON, 이미지 같은 상태 정보와 하나 이상의 질문을 넣을 수 있어요. API는 각 질문에 대해 후보 답의 확률이나 점수를 돌려줍니다.

자유 생성과 무엇이 다른가요

대화 모델은 답변 문장을 만든 다음 애플리케이션이 그 안에서 ‘예/아니오’나 분류명을 찾아야 할 수 있어요. 의사결정 모델은 답 후보를 직접 지정하므로 결과 형식을 코드에서 다루기 쉽습니다.

밝기가 다른 청록색 입체들이 놓인 장면 — 후보 답에 서로 다른 확률을 부여하는 모델

한 번의 추론으로 여러 질문

llama.cpp 설명에 따르면 같은 상태에 대한 여러 질문을 한 요청에 묶을 수 있어요. 모델에 따라 입력을 한 번 처리하고 독립 질문에 각각 답하도록 설계됐습니다.

세 가지 질문 형식

문서는 Choice와 Score를 포함한 질문 형식을 설명해요. 애플리케이션은 고정 선택지 중 하나를 고르거나, 정해진 척도로 상태를 평가하는 구조를 만들 수 있습니다.

라우팅에 쓸 때

요청 내용을 청구, 배송, 기술 지원처럼 업무 큐에 연결할 수 있어요. 글의 예처럼 후보마다 설명을 붙이면 단순한 라벨만 제시할 때보다 질문의 맥락을 분명하게 전달할 수 있습니다.

모더레이션과 작업 확인

유해 콘텐츠 분류나 에이전트가 방금 한 단계가 성공했는지 확인하는 데도 적용할 수 있어요. 실제 도입에서는 오답 비용에 맞춰 확률 임계값을 정하고, 애매한 응답은 사람에게 넘기는 절차가 필요합니다.

여러 청록빛 선이 한 프레임을 통과하는 장면 — 한 번의 추론으로 입력을 처리하는 방식

공개된 모델 다섯 종

ggml-org 컬렉션에는 Julia-1, Laya, Kev-4B, lev, OpenJev가 소개돼요. 크기와 기반 모델, 지원 언어, 이미지 입력 여부가 서로 달라 작업 조건에 맞춰 골라야 합니다.

작은 모델의 응답 시간

게시물은 RTX PRO 6000에서 측정한 중앙 응답 시간을 모델별로 제시해요. Julia-1 3ms, Laya 5ms, Kev-4B 12ms 등으로 안내하지만 다른 GPU나 실제 서비스 부하에서 같은 속도를 보장하지 않습니다.

검은 표면 위 중앙에 형성된 청록색 격자 — 경량 분류 모델의 구조를 표현

모델 크기와 정확도의 교환

가벼운 분류 모델은 빠르게 돌아갈 수 있지만, 복잡한 맥락과 도메인 지식은 큰 모델이 더 유리할 수 있어요. 숫자만 보고 고르기보다 실제 질문과 후보 설명을 포함해 비교해야 합니다.

언어와 입력의 차이

모델마다 지원 언어가 다르고 이미지 입력도 일부에만 제공돼요. 다국어 고객 문의나 스크린샷 분류가 필요하다면 모델 카드의 조건부터 확인해야 합니다.

Choice와 Score 활용

Choice는 후보 중 하나를 고르는 분기 작업에, Score는 기준을 점수화하는 평가 작업에 맞을 수 있어요. 다만 업무 규칙이 질문 문구에 모호하게 남지 않도록 각 후보의 의미와 범위를 명시해야 합니다.

기존 클라이언트와의 관계

ggml-org는 TypeSafe의 System One 형식을 따르며 클라이언트에서는 베이스 URL을 바꾸는 방식으로 연결할 수 있다고 설명해요. 실제 호환 여부는 기존 클라이언트가 동일한 요청 구조와 필드 이름을 지원하는지 확인해야 합니다.

여러 어두운 빔이 한 청록색 초점으로 좁혀지는 장면 — 라우팅과 선택 과정

로컬 실행 경로

llama.cpp는 지원 모델을 서버 모드로 띄우고 API 요청을 보내는 빠른 시작 예를 제공합니다. 로컬 구동은 네트워크 경계를 줄이는 선택지가 될 수 있지만, 로그·캐시·접근 권한은 운영자가 따로 관리해야 해요.

오픈 웨이트와 라이선스

컬렉션에 소개된 모델은 라이선스와 사용 조건이 같지 않아요. 상업적 이용 여부, 가중치 재배포 조건, 기반 모델 요구사항을 모델별 카드에서 확인해야 합니다.

확률은 신뢰 점수와 같지 않아요

응답에 확률이 포함돼도 실제 정답률이 그 수치와 정확히 맞는다는 뜻은 아닙니다. 데이터 분포가 달라지면 점수의 보정 상태가 바뀔 수 있어 운영 자료로 다시 측정해야 합니다.

선택지를 잘 설계해야 합니다

후보가 겹치거나 누락되면 모델이 가장 가까운 답을 고르더라도 업무에서 쓸 수 없어요. ‘기타’나 ‘사람 검토’ 같은 안전한 분기를 두고 범주 간 경계를 테스트하는 편이 좋습니다.

에이전트의 권한은 별도 문제

작업 결과를 점수화해도 에이전트가 실행할 수 있는 권한을 자동으로 제한하지는 않아요. 위험한 동작을 막으려면 허용 목록과 승인 단계를 애플리케이션에서 유지해야 합니다.

벤치마크보다 업무 표본

게시된 속도는 특정 장비와 평가 조건에 따른 수치예요. 분류 정확도, 잘못된 자동 라우팅 비용, 인간 검토 비율을 실제 표본으로 측정해야 도입 효과를 판단할 수 있습니다.

여러 가는 선 가운데 하나가 밝아지는 장면 — 묶음 질문 중 하나를 선택하는 과정

지금 확인할 운영 항목

샘플 요청을 만들어 텍스트·JSON 입력, 여러 질문 묶음, 확률 임계값 동작을 확인할 수 있어요. 이후 각 모델의 메모리 사용량과 처리량을 현재 서버에서 따로 측정해야 합니다.

아직 남은 과제

이번 공개는 API와 모델 선택지를 넓혔지만, 도메인별 정확도나 장기 운영 안정성의 독립 비교까지 제공하는 것은 아니에요. 공개된 설명과 실제 서비스 평가를 구분해야 합니다.

이번 발표가 보여주는 방향

생성형 모델이 모든 판단 문제의 기본 도구일 필요는 없다는 점이 핵심이에요. 정해진 후보를 고르는 작업에서는 전문 모델과 명시적인 검토 임계값이 더 단순한 설계를 만들 수 있습니다.

핵심 정리와 다음 관전점

llama.cpp의 새 엔드포인트는 로컬 추론에서 분류·라우팅·평가 모델을 호출할 수 있게 합니다. 다음에는 모델별 실제 정확도, 확률 보정, 다국어 성능과 운영 비용이 비교될 필요가 있어요.

댓글로 나눠 주세요

이번 변화에서 가장 먼저 검증해야 할 점은 무엇일까요? 실제 업무에서 고려할 기준을 댓글로 들려주세요.

출처

협업문의 : kuroicode@gmail.com
블로그 : https://blog.svil.dev/
홈페이지 : https://svil.dev/