Baseten joey-1, 모든 AI 결정에 큰 모델이 필요할까?

‘이 문의는 어느 팀에서 처리해야 할까?’라는 질문에 다섯 문단짜리 답변이 필요한 경우는 드뭅니다. 유효한 몇 가지 목적지 중 하나, 책임 있게 선택할 만한 신뢰도, 어느 곳에도 맞지 않을 때 도움을 요청할 방법이 필요합니다.

Baseten은 이런 작업을 위해 2026년 10월 29일 joey-1을 공개했습니다. Base Labs 연구팀이 만든 모델로, elephant-1·mammoth-1과 함께 구성한 의사결정 모델 제품군에서 작은 규모를 맡습니다. 매력은 좁게 정한 출력 형식에 있습니다. 앱이 해석해야 하는 설명문 대신 결정과 확률을 내놓습니다. Baseten의 발표가 출시 내용을 소개합니다.

실무 기회는 분업 방식을 바꾸는 데 있습니다. 잘 정의되고 반복되는 결정은 작은 모델에 맡기고 불확실한 나머지에 더 많은 자원을 쓰는 것이죠. 이 글은 가격 계산, 세 가지 가상 활용 사례, 이런 라우팅 전략을 유용하게 만드는 점검 사항을 설명합니다.

Baseten의 공식 joey-1 모델 카드 배너입니다. 이미지: Base Labs / Baseten. MIT 라이선스를 명시한 모델 저장소에서 가져왔으며 여백을 추가하고 크기를 조정했습니다. 이미지 출처 · 라이선스·이미지 설명.

의사결정 모델은 앱이 받아들일 수 있는 선택지에서 시작한다

범용 언어 모델도 ‘요금 문의’라고 쓰거나, JSON을 반환하거나, 환불해야 하는 이유를 설명하며 요청을 분류할 수 있습니다. 각 인터페이스에는 쓰임이 있습니다. 전용 의사결정 모델은 제공된 답 중 하나를 고르고 확률을 구조화된 형태로 반환하는 데 집중합니다.

그만큼 추론 전에 할 일이 달라집니다. 정확한 질문과 의미 있는 조치를 나타내는 선택지가 필요합니다. ‘무엇을 해야 할까?’는 조건이 느슨합니다. ‘요금, 기술 지원, 사기 대응 중 어느 팀이 이 건을 받아야 할까?’는 더 좁지만 여러 팀에 해당하거나 어디에도 맞지 않는 요청을 위한 정책은 여전히 필요합니다.

11월 2일 확인한 Baseten의 joey-1 모델 라이브러리 페이지는 /v1/systemone을 통한 텍스트·이미지 입력, 선택형 질문, 예/아니요 판단, 순서가 있는 척도 평가를 문서화합니다. 결과는 프로그램에서 사용하기 위한 것입니다. 사용자에게 설명이나 답변이 필요하다면 이를 만드는 별도 생성기를 대신하지는 않습니다.

작은 모델을 접수·분류 창구라고 생각해 보세요. 일상적인 일은 올바른 곳으로 보내고 특이한 사례는 더 많은 권한이나 맥락을 가진 담당자에게 넘기는 것이 가치입니다. 어려운 사례를 확신하며 잘못 보내면 추론이 저렴해도 뒤에서 처리할 일이 늘어납니다.

그래서 앱은 불확실성을 보존해야 합니다. 라우팅 시스템은 임시 분류를 기록하거나, 추가 질문을 하거나, 사람에게 넘길 수 있습니다. 모든 확률 분포를 즉각적인 업무 조치로 바꿀 필요는 없습니다.

1센트는 일정 횟수의 결정이 아니라 입력 토큰의 가격이다

2026년 11월 2일 확인한 공식 가격 항목은 입력 토큰 100만 개당 $0.01이며, 캐시 입력과 출력은 $0.00로 표기합니다. ‘1센트’는 이 토큰 단위를 가리킵니다. 긴 이력을 담은 요청은 짧고 범위를 잘 정한 요청보다 입력 처리 비용이 큽니다.

다음은 공개 입력 요율로 계산한 예시입니다. 세금, 다른 서비스, 상업 조건을 적용하기 전이며 캐시되지 않은 입력과 가격 유지를 가정합니다. 청구액 견적이 아니라 계획용 계산입니다.

공식은 전체 입력 토큰을 100만으로 나누고 $0.01을 곱하면 됩니다. 운영 비용의 계산 범위는 더 넓습니다. 상위 처리로 넘기는 비용, 데이터 준비, 재시도, 모니터링, 수동 수정까지 포함해야 합니다.

두 라우팅 설정의 모델 사용료가 몇 달러 차이 난다고 해 보겠습니다. 첫 설정은 검토로 넘기는 건수가 적지만 가끔 긴급 요청을 느린 대기열로 보냅니다. 두 번째는 더 많이 검토로 넘겨 그 오류를 피합니다. 올바른 선택은 가장 싼 토큰 청구액만이 아니라 오류 비용과 검토 인력의 처리 여력에 달려 있습니다.

추론이 저렴해질수록 이 논점은 더 중요해집니다. 모델 사용료가 전체 워크플로 비용의 작은 부분이면 보정이나 분류 기준의 작은 개선이 추가 토큰 가격 인하보다 중요할 수 있습니다. 저렴한 추론은 가능한 자동화의 범위를 넓히지만 결과의 가치를 따져야 할 필요를 없애지는 않습니다.

Baseten의 10월 29일 발표의 상위 처리 이관 방식에서 착안해 자체 제작한 라우팅 도표입니다. 임계값은 도입 앱이 정합니다.

분류별 담당자가 분명하면 문의 배정이 좋은 첫 과제다

고객 지원 흐름을 가정하면 joey-1이 들어온 메시지를 요금, 기술 지원, 계정 보안에 배정합니다. 별도의 예/아니요 질문으로 환불 요청인지 확인합니다. 순서가 있는 척도 점수로 얼마나 시급히 처리해야 하는지 나타냅니다.

관련된 질문이지만 분류 하나로 합쳐서는 안 됩니다. 요금 문의도 긴급할 수 있고 계정 보안 요청에 환불 요구가 포함될 수 있습니다. 결정을 나누면 각 팀이 받는 일과 특별 처리가 필요한 조합을 정의하기 쉽습니다.

대기열 담당자와 분류 기준부터 작성하세요. 과거에 의견이 갈린 사례도 넣습니다. 소프트웨어 버그로 결제가 실패했다는 메시지를 어떻게 처리할지 결정하세요. 조직이 정의하지 않은 조직 내 모호함을 모델이 해결할 수는 없습니다.

실제 업무를 자동 배정하기 전에 권고와 기존 결정을 비교하세요. 정책 모호함, 맥락 부족, 명백한 모델 오류, 잘못된 과거 분류처럼 불일치 원인을 나누어 검토합니다. 정확도 평균 하나로 보면 서로 다른 문제들이 숨습니다.

Baseten의 10월 29일 발표는 joey-1을 1차 처리 모델로 두고 불확실한 경우 더 큰 같은 계열 모델을 쓰도록 제안합니다. 업체의 실제 서비스 제공 조건에서 평균 2,000토큰 요청의 P50 전체 지연 시간이 20밀리초였다고 보고합니다. 특정 서비스 작업량에 대한 업체 측정이지 앱이나 하드웨어의 지연 시간 보장이 아닙니다. 출처: Baseten.

문서 라우터는 맞는 목적지가 없을 때도 알아야 한다

두 번째 가상 활용은 문서 접수입니다. 앱이 파일을 받아 청구서 처리, 경비 검토, 일반 기록 대기열 중 어디에 넣을지 판단합니다. 전달한 표현에 필요한 정보가 들어 있다면 텍스트와 선택적 이미지 입력으로 혼합 문서 자료를 다룰 수 있습니다.

실제 결정은 좁게 정의하세요. 페이지가 청구서처럼 보이는지 판단하는 것과 진짜인지, 법적으로 충분한지, 지급해도 되는지 검증하는 것은 다릅니다. 분류기는 지급 승인 권한 없이도 워크플로를 고르는 일을 도울 수 있습니다.

가장 가치 있는 시험 사례는 분류 체계 밖에 있을 수 있습니다. 계약서에 붙은 영수증, 읽기 어려울 정도로 흐린 이미지, 지원하지 않는 언어 같은 사례입니다. 앱이 목적지를 세 개만 제공한다면 부족한 증거와 낯선 내용을 위한 별도 장치가 필요합니다. 억지 추측보다 명시적인 검토 경로가 운영하기 쉽습니다.

들어오는 자료의 변화도 추적하세요. 평가 때 주로 짧은 국내 청구서를 보던 모델이 나중에는 여러 쪽 명세서와 스캔한 서신을 받을 수 있습니다. 최종 분류만 감시하면 변화를 놓칠 수 있습니다. 개인정보 보호에 맞는 수준에서 요청 길이, 입력 유형, 불확실성, 검토 결과를 기록하세요.

11월 2일 확인한 공개 모델 카드는 joey-1을 Qwen3.5-2B 기반으로 후속 학습한 20억 매개변수(2B) 모델로 설명하고 MIT 라이선스를 명시합니다. 이는 공개 가중치를 이용한 배포 선택지를 뒷받침합니다. 모든 환경의 메모리 요구량, CPU 성능, 발표의 모든 삽화를 재사용할 권한까지 입증하지는 않습니다.

이미지 검사는 눈으로 확인 가능한 조건일 때 유용하다

세 번째 사례로 수동 카탈로그 검토 전에 제출된 제품 사진을 점검한다고 해 보겠습니다. 라벨이 보이는지, 요청한 물체가 있는지, 가려진 부분이 너무 많아 판단하기 어려운지 물을 수 있습니다. 각 질문은 제공된 이미지에서 관측 가능한 것을 지정해야 합니다.

좋지 않은 기준은 관측과 숨은 사실을 섞습니다. ‘믿을 만한 판매자인가?’는 제품 사진만으로 답할 수 없습니다. ‘요청한 일련번호 영역이 보이는가?’는 더 좁고, 다음 워크플로가 다른 사진을 요청할 구체적인 이유를 줍니다.

검토자가 이미 ‘사용 불가, 검토 필요, 사용 가능’ 같은 기준을 공유한다면 순서형 평가가 유용할 수 있습니다. 사람이 일관되게 적용할 수 있는 말로 기준을 적으세요. 이웃한 두 단계를 사람도 구분하지 못한다면 확률 분포가 분류 체계를 고쳐 주지는 않습니다.

자동 거부를 허용하기 전에 모델로 검토 우선순위를 정하세요. 제출 거부는 고객에게 직접 영향을 주며 오거부 비용이 자동화 절감을 넘을 수 있습니다. 검토 단계는 기준을 다듬고 입력 조건에 따라 성능이 달라지는지 확인할 예시도 제공합니다.

이것들은 실제 보고된 joey-1 도입 사례가 아니라 설계 예시입니다. 공통점은 범위가 한정된 질문 뒤에 되돌릴 수 있는 다음 단계가 있다는 것입니다. 자체 데이터에서 모델이 어떻게 동작하는지 배우기 좋은 출발점입니다.

확률을 행동으로 바꾸기 전에 정책이 필요하다

신뢰도는 권한 표시가 아닙니다. 앱이 0.90을 넘으면 조치하기로 정했다면 그 임계값은 결과를 측정해야 하는 설계 선택입니다. 특히 요청이 임계값을 정할 때 쓴 데이터와 다르면 높은 점수도 틀릴 수 있습니다.

오류마다 다른 정책이 필요합니다. 일반 질문을 잘못된 지원팀에 보내면 불편하지만 계정 탈취 신고를 일상 문의로 취급하면 훨씬 큰 비용이 들 수 있습니다. 같은 확률 임계값을 두 과제에 자동으로 적용해서는 안 됩니다.

자체 제작한 평가 틀입니다. 자동 처리 범위, 잘못된 조치의 비용, 상위 처리 이관의 품질은 앱의 지표이며, 측정한 joey-1 결과를 나타내지 않습니다.

대표적인 일반 사례, 어려운 사례, 범위 밖 입력으로 별도 평가 세트를 만드세요. 제안한 임계값마다 자동 처리 비율과 그 안의 오류를 살핍니다. 나머지가 어떻게 되는지도 봐야 합니다. 거의 모두를 상위 처리로 보내 오류를 피하는 모델이라면 워크플로가 실질적으로 달라지지 않을 수 있습니다.

단계형 시스템 전체를 큰 모델 단독 사용과 비교하세요. 작은 모델을 먼저 쓰면 고유한 실패 유형과 지연 시간이 있는 라우팅 단계가 추가됩니다. 첫 단계에서 충분한 요청을 적절히 처리하고, 이관 경로가 어려운 나머지의 결과를 개선할 때 이점이 있습니다.

호스팅 API로 시작하거나 자체 운영 비용을 따로 산정

Baseten은 호스팅 Model APIs, 전용 배포, 다운로드 가능한 가중치를 제공합니다. 맥락 길이와 서비스 조건은 경로별로 확인해야 합니다. 출시 글은 Model APIs의 16k 맥락과 전용 배포의 262k 옵션을 설명하지만, 모델 카드는 학습 시퀀스 길이 16,384토큰을 명시하고 학습 한도를 넘는 요청을 거부합니다. 모든 경로에 무분별하게 적용할 단일 최대값은 없습니다. 출시 포스트, 모델 카드.

1. 결정 조건 하나를 고릅니다. 유효한 선택지와 뜻, 증거가 부족할 때 앱이 할 일을 정하세요.
2. 배포 경로를 고릅니다. 호스팅 파일럿은 모델의 API 안내를 열고 제공자 계정 화면에서 인증 정보를 만듭니다. 로컬 서비스는 모델 카드의 고정된 런타임 요구 사항을 따르세요.
3. 최소 요청을 보냅니다. 공식 API 예시는 https://inference.baseten.co/v1/systemone에 state, 타입이 지정된 questions, 모델 식별자 decision-models/baseten-joey-2b-latest를 사용합니다.
4. 구조화된 응답을 검증합니다. 잘못된 형식이나 사용할 수 없는 결과는 거부하고, 평가에 필요한 확률을 보존하며, 라우팅 정책은 앱에 둡니다.
5. 섀도 모드로 평가합니다. 자동 조치를 켜기 전에 권고와 검토한 결과를 비교하세요.
6. 상위 처리 이관을 추가하고 측정합니다. 불확실하거나 영향이 큰 사례를 더 큰 모델이나 사람에게 넘기고 전체 경로의 결과를 확인하세요.

모델 카드는 CUDA GPU와 고정된 서비스 환경이 필요한 자체 호스팅 구성을 문서화합니다. ‘2B’는 모델 규모이지 모든 노트북의 메모리가 충분하다는 약속이 아닙니다. 배포 용량을 정할 때 런타임 부가 비용, 이미지 처리, 동시 실행, 맥락 길이를 포함하세요.

API 파일럿으로 인프라 투자 전에 제품 적합성을 확인할 수 있습니다. 자체 호스팅은 통제력, 자원 활용률, 운영 노력, 총비용에 관한 별도 결정입니다. 공개 가중치는 선택을 가능하게 하지만 자동으로 경제적인 선택으로 만들지는 않습니다.

재실행 평가 세트는 모델이나 프롬프트가 바뀔 때 업무를 보호한다

첫 파일럿이 작동하면 검토한 요청 모음을 버전별로 관리하세요. 일반 사례, 비용이 큰 오류, 도움을 요청하는 것이 정답인 예를 포함합니다. 보존 권한이 있는 데이터로 기대 결과 옆에 질문 문구와 선택지 설명도 남기세요.

프롬프트, 임계값, 서비스 구성을 바꿀 때는 트래픽을 늘리기 전에 이 모음을 재실행하세요. 한 범주의 향상은 다른 범주의 퇴행을 가릴 수 있습니다. 예를 들어 더 과감한 배정은 검토량을 줄이면서 짧고 모호한 메시지의 오류를 늘릴 수 있습니다. 전체 평균만으로는 이 상충 관계를 설명할 수 없습니다.

평가에 실제로 쓴 모델 식별자와 서비스 경로를 기록하세요. 배포가 바뀔 수 있는 latest 식별자를 따른다면 행동 변화를 알아차리고 합격 여부를 다시 검토할 방법을 정해야 합니다. 앱 스키마가 안정적이라고 결정까지 영원히 같지는 않습니다.

서비스 실패도 시험하세요. 시간 초과, 모델 사용 불가, 잘못된 응답은 조용히 기본 팀을 고르는 대신 정해진 복구 경로로 가야 합니다. 기본값 자체가 업무 결정이며 민감한 요청에는 부적절할 수 있습니다. 신뢰할 수 있는 소형 모델 시스템은 확신하는 답뿐 아니라 답을 얻지 못한 경우도 의도적으로 다룹니다. 평소 요청 비용이 1센트보다 훨씬 작더라도 이 운영 원칙은 중요합니다.

작은 모델은 결정 경계의 품질을 더 선명하게 드러낸다

저희의 판단으로 joey-1이 가장 흥미로운 곳은 앱이 선택지를 이미 명확하게 정의한 영역입니다. 저렴하고 빠른 결정은 많은 일을 움직일 수 있지만, 잘못된 분류 체계는 실수를 더 빨리 보낼 뿐입니다.

가치 있는 질문은 알려진 범위 안에서 얼마나 많은 일을 올바르게 처리하고 나머지를 얼마나 잘 다루느냐입니다. 작은 모델은 상위 처리 이관 경로가 가격 뒤의 각주가 아니라 제품 일부일 때 제 역할을 합니다.

출처

• Baseten: 1센트의 의사결정, joey-1 소개, 2026년 10월 29일.
• Baseten joey-1 모델 라이브러리 및 API 예시, 2026년 11월 2일 확인.
• Base Labs joey-1 모델 카드, 2026년 11월 2일 확인. 벤치마크 항목은 게시자가 보고한 수치이며 Artificial Analysis 항목은 내부 재현 평가로 명시되어 있습니다.

검토 내용을 출처와 함께 남기기

Telli.sh는 사용 권한이 있는 자료와 기술 결정의 근거가 된 메모를 함께 보관하는 선택지입니다. 노트 작업 공간 만들기.