Jev vs Flash LLM: 워크플로는 7배 저렴, 단일 분류는 동일

TypeSafe의 Jev가 Flash LLM보다 저렴한지는 작업 형태에 따라 달라진다. 고객 지원 대화마다 12개 질문을 던졌을 때 Jev의 비용은 thinking을 끈 GPT-5.6 Luna보다 7배 낮았고, 네트워크 시간을 뺀 처리 시간은 0.12초로 Luna의 1.66초보다 짧았다. 반면 77개 중 하나를 고르는 단일 분류에서는 Qwen3.8 Flash와 GLM 5.3 Flash의 비용과 같았다. Jev는 의사결정 모델이다. 텍스트를 생성하는 대신 사용자가 정의한 각 질문에 대해 선택지, 점수 또는 확률을 반환한다. 공개 데이터셋으로 만든 4개 테스트에서 Jev를 Flash급 채팅 모델 5종과 비교했다. 채팅 모델은 각각 가장 저렴한 설정과 기본 thinking 설정으로 실행했다. Jev는 모든 테스트에서 가장 빨랐지만, 정확도가 가장 높은 테스트는 하나도 없었다.

TL;DR

• 케이스당 질문이 12개일 때 Flash LLM은 Jev보다 4.8-37배 비쌌고 11-27배 느렸으며, 정확도는 비슷했다.
• 메시지당 분류 하나만 수행하면 thinking을 끈 Qwen3.8 Flash와 GLM 5.3 Flash의 비용은 Jev와 같았다.
• 기본 thinking 설정에서 Flash 모델의 단일 분류 비용은 Jev보다 1.5-26배 높았다.
• GPT-5.6 Luna는 prompt injection을 제외한 모든 테스트에서 Jev보다 정확했다.
• Jev가 0.99 이상의 확률로 답한 결과는 98%가 정확했다.

Jev는 무엇이며 LLM과 어떻게 다른가?

Jev는 TypeSafe의 “System One” 모델이다. 텍스트나 JSON 조각인 state를 읽고 타입이 지정된 질문에 답하며, 파싱해야 할 텍스트를 생성하지 않는다. 질문 유형은 3가지다.

요청에서는 질문을 이름으로 지정하고, 각 이름마다 답 하나를 받는다. 아래 요청은 TypeSafe가 문서화한 형식(API 레퍼런스)으로 짧은 고객 지원 대화에 대해 yes/no 질문 3개를 보낸다.

curl https://api.typesafe.ai/v1/systemone \
  -H "Authorization: Bearer $TYPESAFE_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "jev-latest",
    "state": {"transcript": "Customer: My card was declined twice today.\nAgent: One moment.\nCustomer: Also, how do I change my PIN?"},
    "questions": {
      "declined_card": {"type": "noul", "instructions": "In `transcript`, does the customer report a declined card payment?"},
      "change_pin":    {"type": "noul", "instructions": "In `transcript`, does the customer want to change a PIN?"},
      "lost_card":     {"type": "noul", "instructions": "In `transcript`, does the customer report a lost or stolen card?"}
    }
  }'

실행 결과는 다음과 같았다.

{
  "model": "jev-1.13.0",
  "answers": {
    "declined_card": {"type": "noul", "noul": 0.99},
    "change_pin":    {"type": "noul", "noul": 0.98},
    "lost_card":     {"type": "noul", "noul": 0.02}
  },
  "usage": {"input_tokens": 359, "output_tokens": 56}
}

코드는 일반 숫자를 비교하듯 answers.<question>.noul을 읽어 임계값과 비교하면 된다. model 필드는 응답한 버전을 나타낸다. TypeSafe가 새 버전을 출시하면 jev-latest가 가리키는 버전도 바뀌므로, 특정 버전에 맞춰 임계값을 조정했다면 jev-1.13.0으로 고정해야 한다.

TypeSafe는 질문을 병렬로 평가한다. Jev 1.13의 입력 토큰 가격은 100만 개당 $0.042이고 출력은 무료다(모델 목록). 입력 토큰당 가격은 Qwen3.8 Flash보다 3.6배, GPT-5.6 Luna보다 4.8배, Gemini 3.8 Flash보다 18배 낮다. 입력에는 호출당 약 300 token인 TypeSafe 자체 템플릿과 사용자가 정의한 모든 질문 및 선택지가 포함된다. 위 호출의 과금 대상은 입력 359 token으로 $0.000015였고, 출력 56 token은 무료였다. TypeSafe는 Jev가 약한 영역도 모델 특성 문서에 공개한다. 개수 세기, 산술, 날짜 비교, 여러 단계가 필요한 질문, 관련 없는 텍스트가 많이 포함된 긴 state가 여기에 해당한다.

어떻게 테스트했나?

2026-09-21과 2026-09-22에 4개 테스트를 각각 한 번씩 실행했다. Jev와 Flash 채팅 모델 5종인 GPT-5.6 Luna, Qwen3.8 Flash, GLM 5.3 Flash, DeepSeek V4.1 Flash, Gemini 3.8 Flash를 사용했다. 각 채팅 모델은 동작하는 설정 중 가장 저렴한 thinking 설정으로 실행했다. off를 지원하지 않으면 low를 사용했다. 3개 분류 테스트에서는 벤더 기본값으로도 다시 실행했다.

• 케이스당 질문 12개: Banking77 데이터셋(PolyAI, CC BY 4.0)의 메시지 1-6개를 조합해 정답이 알려진 고객 지원 대화 150개를 만들었다. 각 모델은 대화마다 yes/no 질문 12개(“고객이 카드 분실이나 도난을 신고하는가?”)에 각각 확률로 답했다. Jev에는 한 번의 호출로 Noul 질문 12개를 보냈고, 채팅 모델에는 하나의 JSON 객체를 요청했다. 그중 60개는 대화 앞에 3,000 token 및 12,000 token 분량의 참고 문서(은행 관련 Wikipedia 문서)를 추가해 다시 실행했다.
• 단일 분류: Banking77 메시지 308개로, 77개 intent에서 각각 4개씩 추출했다. Jev에는 77개 옵션이 있는 Choice 하나를 보냈고, 채팅 모델에는 같은 목록을 주고 intent를 반환하도록 했다.
• 28개 분류: GoEmotions 댓글 200개(Google, Apache 2.0)로, 가능한 감정은 각각 28개였다.
• Prompt injection: deepset prompt-injections 테스트셋(Apache 2.0)의 116개 행에 대해 각각 yes/no 질문 하나를 보냈다.

비용은 각 벤더의 정가에 과금된 token 수를 곱해 계산했다. 지연 시간은 연결을 유지한 상태에서 모델별로 40회 호출한 별도 실행에서 측정한 뒤, 네트워크 왕복 시간을 뺐다. 측정 방법은 속도 섹션에서 설명한다. GPT-5.6 Terra와 Seed 2.0 Mini도 3개 분류 테스트에서 실행했다. 결과는 표에는 포함했지만 차트에서는 제외했다.

Jev는 어떤 경우에 Flash LLM보다 저렴한가?

하나의 텍스트에 여러 질문을 던질 때, 텍스트가 길 때, 또는 채팅 모델이 thinking을 사용해야 할 때다. 짧은 텍스트 하나를 저렴한 모델로 분류하고 thinking을 끄면 Jev와 비용이 같다.

비용 배수는 3가지 요인에 따라 달라진다. 첫째는 질문 수다. 채팅 모델은 질문마다 답을 생성해야 하며, 출력이 더 비싸다. GPT-5.6 Luna는 출력 token 100만 개당 $1.20, 입력은 $0.20를 부과한다. 반면 Jev의 답은 무료이고 질문 하나를 추가할 때 입력 token이 약 17개 늘어난다. 둘째는 thinking이다. 벤더 기본 설정에서 채팅 모델은 분류 하나당 최대 중앙값 161개의 출력 token을 생성했지만, thinking을 끄면 3-8개였다. Jev 대비 비용 배수도 함께 커졌다. 셋째는 입력 길이다. 참고 문서가 12,000 token이면 고정 템플릿과 답변 비용의 영향이 작아지고, 비용 배수는 입력 가격 비율에 가까워진다. GLM 5.3 Flash는 3.5배, Gemini 3.8 Flash는 18.6배였으며, DeepSeek V4.1 Flash는 7.1배였다.

단일 분류 테스트에서는 가장 저렴한 모델과 비교했을 때 Jev의 비용 이점이 없었다. 77개 옵션이 호출마다 약 1,400 token을 추가하므로, 한 줄짜리 메시지에서도 Jev는 약 1,690개의 입력 token이 과금됐다. Qwen3.8 Flash는 440개였다.

Jev는 얼마나 빠른가?

네트워크 시간을 빼면 약 7-28배 빠르다. Jev의 중앙값은 0.11-0.12초였고, 채팅 모델은 0.79-3.25초였다.

모델과 작업 조합마다 연결을 유지한 채 40회를 순차로 호출하고, 같은 연결에서 모델 연산이 없는 요청으로 측정한 왕복 시간을 뺐다. 남는 것은 모델 자체의 시간과 프록시에서 각 제공업체까지의 경로이며, 그 경로는 모든 모델에서 동일하다.

thinking의 영향은 95번째 백분위수에서 두드러진다. 벤더 기본값에서 Qwen3.8 Flash 호출 20개 중 1개는 분류 하나에 21초 넘게 걸렸다. Jev는 가장 느린 호출도 약 0.2초에 머물렀다.

질문을 늘려도 Jev는 느려지지 않았다. 고객 지원 티켓 하나에 yes/no 질문을 1개에서 60개까지 늘려도 중앙값 변화는 0.1초 미만이었고, 60개 질문 호출은 1,371 token에 $0.000058가 과금됐다. 질문 20개를 보낸 호출은 5회 실행 모두 모든 답이 맞았다.

이 결과는 TypeSafe 자체 주장과 얼마나 일치하는가?

방향은 일치하지만 수치는 더 작았다. 비교 조건이 다르기 때문이다. TypeSafe의 출시 글은 multi-step workflow에서 reasoning을 사용하는 frontier 모델과 비교해 최대 444.6배 저렴하고 193.6배 빠르다고 설명한다. 이 수치를 “실제 환경에서 얻을 수 있는 개선 폭의 상단”이라고 명시했다(출시 글).

공개된 워크플로 평가에는 GPT-5.6 Luna도 포함된다. 케이스당 Jev는 정확도 67.8%, 비용 $0.0004, 처리 시간 0.4초였고, Luna는 정확도 66.8%, 비용 $0.0033, 처리 시간 12.9초였다. Jev가 약 8배 저렴하고 32배 빨랐다. 이번 12개 질문 테스트에서는 thinking을 끈 Luna가 Jev보다 비용은 7배, 네트워크 제외 시간은 14배 높았다. 같은 자릿수의 결과다. 가장 저렴한 Flash 모델로 단일 분류를 수행하면 비용 차이는 사라진다.

Jev는 Flash LLM만큼 정확한가?

워크플로 테스트에서는 비슷했고 분류 테스트에서는 뒤처졌으며, 어떤 테스트에서도 1위는 아니었다. 케이스당 질문 12개 테스트에서 Jev의 micro F1은 모든 채팅 모델의 결과 범위 안에 있었다. micro F1은 모든 질문의 yes와 no를 합쳐 평가하며 1.0이 완벽한 점수다. 정답과 오답을 확률순으로 구분하는 성능도 최고 모델들과 비슷했다.

AUC는 확률이 정답을 얼마나 잘 순위화하는지 측정한다. 1.0이면 실제 “yes”인 모든 항목이 모든 “no” 항목보다 높은 확률을 받았다는 뜻이다. 12,000-token 참고 문서를 앞에 추가해도 Jev의 정확도는 유지됐다. 동일한 대화 60개에서 참고 문서가 있을 때 F1은 0.914, 없을 때는 0.922였다.

분류 테스트에서는 채팅 모델이 앞섰으며, 특히 기본 thinking 설정에서 차이가 컸다.

GPT-5.6 Luna와 Terra는 injection 텍스트 116개 중 115개, 댓글 200개 중 199개에 답했다. 각 테스트에서 요청 하나씩 오류가 발생했으며, 정확도는 반환된 응답만으로 계산했다. yes 또는 no가 아닌 응답은 오답으로 처리했다. 감정 테스트에서 Jev는 yes를 지나치게 많이 반환했다. Jev가 0.80-0.95의 확률을 준 감정 중 실제 사람의 label에 포함된 비율은 15%뿐이었다. 감정 label은 희소하다. annotator가 댓글마다 하나 또는 두 개만 선택했기 때문에 모든 모델의 점수가 낮아지지만, 모든 모델에는 같은 지시문을 사용했다. Prompt injection에서는 Jev의 기본값인 0.5가 적절한 cut-off가 아니었다. 다음 섹션에서 자세히 다룬다.

Jev의 confidence를 신뢰할 수 있는가?

Jev의 확률은 정답과 오답을 잘 구분하지만, 일반적인 의미에서 calibration돼 있지는 않다. 따라서 작업마다 별도의 임계값이 필요하다. calibration됐다는 것은 0.8의 확률을 준 답이 실제로 80% 정확하다는 뜻이다. Banking77에서 Jev가 0.99 이상의 확률을 준 답은 98% 정확했지만, 0.8 미만에서는 정확도가 약 절반이었다.

Banking77 메시지의 거의 절반인 48%가 0.99 이상의 최상위 확률을 받았다. 이 결과만 바로 처리하고 나머지는 더 큰 모델로 보내는 pipeline을 구성하면, 전체 트래픽 중 해당 비율에서 98%의 정확도를 유지할 수 있다. Prompt injection은 반대 사례를 보여준다. 기본 cut-off인 0.5에서는 공격의 절반만 탐지했다. 나머지 절반의 확률은 0.03-0.5였다. 절대값은 낮지만, 중앙값이 0.02였던 정상 텍스트보다는 대부분 높았다. 확률순으로 정렬했을 때 공격과 정상 텍스트를 구분하는 AUC는 0.984였다.

이 임계값은 동일한 116개 텍스트에서 선택했으므로 상한선으로 봐야 한다. API가 token log-probabilities, 즉 모델이 생성한 각 token에 부여한 자체 확률을 반환한다면 채팅 모델에서도 확률을 얻을 수 있다. 이번에 사용한 채팅 모델 중 Qwen3.8 Flash와 Seed 2.0 Mini는 실행 시 해당 값을 반환했다. Qwen3.8 Flash가 “yes”에 부여한 확률로 injection 텍스트를 순위화했을 때 AUC는 0.977이었다.

Jev와 Flash LLM 중 무엇을 써야 하는가?

이번 실행에서 Jev를 가장 효과적으로 활용한 방식은 다음과 같았다. 하나의 결정을 같은 텍스트에 대한 여러 개의 좁은 질문으로 분해한다. 자체 label 데이터로 조정한 임계값을 넘는 답은 바로 처리하고, 나머지는 채팅 모델로 보낸다.

FAQ

TypeSafe Jev란 무엇인가? Jev는 TypeSafe의 의사결정 모델이다. 텍스트에 대해 타입이 지정된 질문(yes/no, 하나 선택, 척도 평가)에 답하며, 생성된 텍스트 대신 확률을 반환한다. 현재 버전은 Jev 1.13이고 jev-latest alias로 제공된다. 입력 token 100만 개당 $0.042이며 출력은 무료다.

Jev는 LLM보다 저렴한가? 작업에 따라 다르다. 고객 지원 대화마다 질문 12개를 던졌을 때 thinking을 끈 GPT-5.6 Luna는 Jev보다 7배, Gemini 3.8 Flash는 37배 비쌌다. 77개 중 하나를 고르는 단일 분류에서는 thinking을 끈 Qwen3.8 Flash와 GLM 5.3 Flash의 비용이 Jev와 같았다.

Jev는 GPT-5.6 Luna보다 정확한가? 이번 테스트에서는 아니었다. 케이스당 질문 12개 테스트에서 thinking을 끈 GPT-5.6 Luna의 micro F1은 0.933, Jev는 0.909였다. Banking77에서는 각각 85.1%와 80.2%였다. 단, 기본 임계값을 사용한 prompt injection 테스트에서는 Jev가 thinking을 끈 Luna보다 더 많은 공격을 탐지했다.

TypeSafe는 왜 Jev가 444배 저렴하다고 하는가? 이 수치는 multi-step workflow에서 reasoning을 사용하는 frontier 모델과 Jev를 비교한 결과다. TypeSafe도 개선 폭의 상단이라고 설명한다. 이번 Flash 모델 비교에서는 12개 질문 워크플로에서 Jev가 4.8-37배 저렴했고, 단일 분류에서는 비용이 거의 같았다.

Jev의 확률은 calibration돼 있는가? 일반적인 의미에서는 아니다. Banking77에서 Jev가 0.99 이상의 확률을 준 답은 98% 정확했지만, 0.8 미만에서는 정확도가 약 절반이었다. Prompt injection에서는 공격의 절반에 0.5 미만의 확률을 부여했다. 자체 label 데이터로 작업별 임계값을 조정해야 한다.

관련 글: 2026년 최고의 Flash LLM API, LLM structured output 비교, LLM thinking 제어, 사용 사례별 최고의 LLM.

← 블로그로 돌아가기