일상적인 인앱 작업을 위한 ScaleDown의 소형 모델: 분류, 추출, 요약

2026년 10월 13일, ScaleDown은 하나의 아이디어로 판매하고 있는 세 가지 작은 작업 특화 모델의 베일을 벗겼다: Classify, Extract, Summarize. 각각은 대화를 위한 것이 아니라 프로덕션 LLM 호출을 둘러싼 반복 작업을 위해 만들어졌다. 세 모델 모두 1M 토큰 입력을 받고, 텍스트나 이미지를 받아들이며, ScaleDown 자체 API를 통해 접근할 수 있다 — 바로 이 지점에서 가격 책정 문제가 흥미로워지는데, 세 모델의 비용 구조가 완전히 다르기 때문이다. 패밀리의 네 번째 모델인 ScaleDown Compress는 공급업체 문서에서 새로 나온 세 모델 중 하나가 아니라 컨텍스트 트리밍 도구로 기재되어 있다. 다음은 공급업체가 문서화한 내용이며, 아직 아무도 재현하지 못한 내용과는 분리해 둔다.

10월 13일에 실제로 무엇이 출시되었습니까?

ScaleDown은 얼마 동안 Decisions 엔드포인트를 운영해 왔다 — 상태 객체와 타입이 지정된 질문들의 맵을 받아 보정된 확률을 반환하는 구조화된 스코어링 인터페이스다. 10월 13일 발표는 이 회사가 기반 모델들을 하나의 엔드포인트가 아니라 그 자체로 제품으로 판매하기 시작하고, 이를 인앱 작업을 위한 범용 구성 요소로 설명하기 시작한 시점이다.

공급업체가 문서화한 대로의 세 가지 모델과 그 계약:

• ScaleDown Classify — 호출자가 제공하는 레이블 집합에 텍스트를 할당합니다. 각 레이블은 이름과 루브릭을 가지며, 문서에서는 이를 "모델이 레이블을 채점하는 데 사용하는 예/아니요 질문"이라고 부르고, 요청에서 가장 중요한 부분이라고 설명합니다. 단일 레이블 모드에서는 합이 1.0이 되는 소프트맥스 분포와 최상위 레이블을 반환하고, 다중 레이블 모드에서는 호출자가 설정한 임계값을 기준으로 각 레이블을 독립적으로 채점합니다.

• ScaleDown Extract — 비정형 텍스트에서 구조화된 필드를 추출합니다. 이 제품군의 문서에서 이 모델은 문서를 코드가 인덱싱할 수 있는 레코드로 바꿔 주는 모델입니다.

• ScaleDown Summarize — 긴 입력을 짧게 추상 요약하는 기능으로, 1M 토큰 창이 가장 분명하게 겨냥하는 작업입니다.

세 가지 모두에 공통으로 적용되는 계약이 바로 기록해 둘 만한 부분이다. 요청당 100만 토큰의 입력은 주류 중형 API가 받아들이는 양보다 대략 한 자릿수나 더 크며, 바로 이 숫자 덕분에 Summarize와 Extract가 청킹 계층 없이 문서 전체를 다루는 작업에 현실성 있게 쓰일 수 있다. 텍스트 또는 이미지 입력은 특히 Extract에서 중요하다. 스캔한 인보이스나 양식 스크린샷을 넣으면 필드가 나오고, 그 사이에 OCR 단계가 끼어들지 않는다. 세 가지 모두 ScaleDown 자체 API에서 제공되며, 문서에서는 기본 URL을 span>api.scaledown.xyz/span>로 제시하고 span>api.scaledown.ai/span>는 API 호스트가 아니라고 분명히 밝히고 있다.

다른 것들과 다른 단 하나의 숫자

가격 책정은 이 세 가지가 더 이상 서로 바꿔 쓸 수 없게 되는 지점입니다. Classify는 백만 입력 토큰당 0.05달러, 백만 출력 토큰당 0달러로 등록되어 있으며, 제3자 카탈로그에 등록된 모델 정보에는 때때로 프로모션 할인이 적용된 동일한 요율이 표시됩니다. 이 할인은 ScaleDown의 약속이 아니므로 이를 전제로 계획해서는 안 됩니다. 출력 가격이 0인 것은 마케팅 속임수가 아닙니다. 루브릭 점수 기반 분류기는 생성된 텍스트가 아니라 레이블과 확률을 출력하므로 청구할 대상이 없습니다. Extract와 Summarize는 실제로 출력을 생성하므로 비용 구조가 Classify와 비교할 수 없으며, 분류기의 요율에서 추정하기보다 공급업체로부터 직접 가격을 책정해야 합니다.

Classify의 청구 세부 사항은 대표 요금보다 따져보기가 더 어렵다. 단일 레이블 모드에서는 모든 레이블과 그 루브릭이 하나의 모델 호출에 들어가므로, 추가하는 각 레이블마다 청구되는 입력 토큰이 늘어난다. 선택에 대한 한 문장 설명을 요청하면 이를 2배로 다시 전송하며, 문서에는 설명이 최상위 레이블이 확정된 후에 생성된다고 분명히 나와 있으므로 이는 답을 다시 의심하기보다는 정당화한다. 다중 레이블 모드에서는 각 레이블이 별도의 모델 호출이고, 각 청크는 별도로 채점된다. 따라서 추론이 켜진 60개 레이블 분류 체계는 독자가 가정하는 의미의 백만 토큰당 $0.05 작업이 아니다. 그것은 해당 요율에 레이블 집합을 곱한 값이며, 추론이 켜져 있으면 두 배가 된다. 문서화된 상한 — 요청당 레이블 20개, 다중 레이블 모드에서 16개, 배치당 청크 50개 — 은 설계 시 대비해야 할 실질적 제약이다.

이러한 상한보다 더 중요한 문서화된 동작이 하나 더 있습니다. 분류기는 레이블이 맞지 않을 때도 "항상 승자를 반환합니다." 신뢰도 필터링은 전적으로 호출자에게 맡겨집니다. 10개 레이블 요청에서 최고 점수 0.4가 여전히 정답일 수 있습니다. 점수는 절대값이 아니라 레이블 집합 내에서 상대적이기 때문입니다. 이 모델의 모든 프로덕션 사용에는 자체 임계값 정책이 필요하며, 포괄 레이블 — 문서에서 이름을 지정하라고 제안하는 span>other/span> — 은 실무에서 선택 사항이 아닙니다.

분류기에서 1M 토큰 윈도우가 흥미로운 부분인 이유

분류기 모델은 관례적으로 짧은 입력을 받습니다. 그 이유는 기계적입니다: 루브릭으로 채점되는 분류기는 전체 입력을 각 레이블의 예/아니오 질문에 견주어 판단해야 하며, 10만 토큰 문서를 20개의 루브릭에 대해 채점하는 비용은 해당 문서를 스무 번 완전히 훑는 것입니다. ScaleDown의 해법은 1M 창과 배칭 계층입니다 — 최대 50개의 청크를 단일 요청에서 하나의 공유 프로필에 대해 채점 — 그리고 벤더의 주장은 청크 하나를 보내든 50개를 보내든 청크별 보정은 동일하며, 유일한 차이는 공유 프로필이 요청당 한 번만 청구된다는 점입니다.

그 주장은 그 위에 구축하기 전에 테스트해야 할 주장이다. 또한 이 모델을 흥미롭게 만드는 주장이기도 하다: 엣지가 아니라 애플리케이션 내부에서 분류하는 이유는, 그 결정이 잘린 창이 아니라 전체 컨텍스트—전체 지원 스레드, 계약서 전체, 검색된 문서 전체—를 볼 수 있기 때문이다. 1M 창이 당신의 입력 크기에서 견딘다면, 아키텍처 질문("청킹 및 투표 방식이 필요한가?")은 거의 사라진다. 그렇지 않다면, 당신에게는 아주 저렴한 짧은 입력 분류기와 해결해야 할 두 번째 문제가 있다.

2차 소견이 필요한 청구 건

ScaleDown의 마케팅은 작업별 소형 언어 모델이 대량의 반복 작업에서 비용, 속도, 정확도 면에서 프론티어 모델을 능가한다고 주장하며, 약 5억 개 파라미터 모델이 단순 분류 작업에서 91.7%를 달성한 반면 720억 개 파라미터 모델은 88.6%를 기록했다는 수치 등을 인용합니다. 이는 벤더 자체의 수치이며 독립적으로 재현되지 않았습니다: ScaleDown Classify는 현재 공개 리더보드에서 점수가 매겨지지 않은 상태로, 제3자 벤치마크 행이 공개되지 않았습니다. 정확도 주장을 그럴듯한 메커니즘을 가진 가설로 취급하십시오 — 좁은 분류 체계에서 목적 훈련된 소형 모델과 범용 대형 모델 간의 샘플 효율성 격차는 실제이며 잘 문서화되어 있습니다 — 확립된 결과로 취급하지 마십시오.

1M 토큰 입력 수치 역시 벤더가 밝힌 값이다. 해당 모델에 대한 제3자 카탈로그 목록에서는 100만 토큰이라는 숫자를 그대로 반영하기보다 컨텍스트 길이를 ‘해당 없음’으로 표시하는데, 이는 모순이라기보다 카탈로그상의 한계다. 다만 이는 해당 윈도가 ScaleDown의 문서 외부에서 입증되지 않았다는 뜻이기는 하다.

이미 파이프라인을 실행 중인 경우 이것이 어디에 해당하는지

이 세 모델이 겨냥하는 패턴은 단일 호출이 아니라 루프입니다. 문서를 검색하고, 분류하고, 필드를 추출하고, 요약한 다음, 그 요약을 응답을 작성하는 생성 모델에 넘기는 것이죠. 네 번째 단계는 토큰당 비용이 비싼 단계이며, 바로 OrcaRouter가 담당하는 단계입니다 — 하나의 OpenAI 호환 키 뒤에 200개 이상의 모델이 제공업체 정가를 0% 마크업으로 그대로 전달되며, 서빙 경로가 저하될 때 자동 페일오버가 작동합니다. 우리는 ScaleDown Classify, Extract, Summarize를 호스팅하지 않습니다. 이들은 우리 카탈로그에 없고 채팅 완성 대상도 아니며, 여기서 라우팅 계층은 채점 절반이 아니라 이 패턴의 생성 절반입니다.

그 구분은 분명히 말할 가치가 있습니다. 사람들이 흔히 꺼내들 비용 비교는 오해의 소지가 있기 때문입니다. 백만 입력 토큰당 몇 센트의 루브릭 채점 분류기와 백만 토큰당 몇 달러의 생성 모델은 경쟁 관계가 아닙니다. 그것들은 서로 다른 비용 항목이며, 분류 단계에 작은 모델을 배치하는 이유는 실제로 무언가를 작성하는 단계에 더 나은 모델을 쓸 여유를 갖게 해 주기 때문입니다.

이 평가를 바꿀 수 있는 것은 무엇입니까

전체 그림을 얼마나 바꿀 수 있는지 순서대로 세 가지가 있습니다. 공개 벤치마크에서 루브릭으로 채점된 분류 작업에 대한 독립적인 평가는 정확도 주장을 공급업체의 주장에서 하나의 데이터로 바꿔 놓을 것입니다. 공개된 지연 시간 수치 — 공급업체는 비용 요인은 문서화했지만 서빙 지연 시간은 문서화하지 않았습니다 — 는 1M 윈도우가 처리량 환경에서 사용 가능한지, 아니면 배치에서만 가능한지를 결정해 줄 것입니다. 그리고 청크별 캘리브레이션 주장에 대한 제3자 재현은 50청크 배치가 비용 최적화인지 아니면 다른 모델인지를 결정할 것입니다. 그중 적어도 하나가 실현될 때까지는, 솔직한 요약은 ScaleDown이 유난히 명확한 계약과 유난히 큰 입력 한도를 가진 세 가지 모델을, 임계값 기반 분류 단계를 고려할 만큼 저렴하게 만드는 가격으로 출시했으며, 그들을 뒷받침하는 숫자들은 공급업체 자체의 것이라는 점입니다.

간략 버전

대량 분류 또는 추출 단계가 있고 안정적인 분류 체계와 텍스트 또는 이미지 입력을 사용한다면, ScaleDown의 세 모델은 이번 주 자체 데이터로 벤치마크해 볼 가치가 있습니다. 계약이 단순하고 입력 한도가 넉넉하기 때문입니다. 분류 체계를 확정하기 전에 레이블 증식과 2배 추론 할증을 예산에 반영하고, 자체 신뢰도 임계값을 직접 작성해야 한다는 점도 예상하세요. 작업이 개방형 생성이라면, 이 중 어느 것도 당신을 위한 것이 아닙니다.

모델 선택은 또한 이전에 무엇이 잘못되었는지에 대한 문제이기도 합니다: 이 등급의 모델 뒤에 있는 문서화된 AI 사고와 에이전트 실패가 수집되어 있는 곳은 OrcaRouter AI Incident Archive이며, 각 항목은 자체 출처, 심각도, 신뢰도 등급 및 논란 플래그를 포함합니다.