지난주 ScaleDown은 Constrained Decoding Models (CDMs)을 출시했습니다. 이 출시 게시물은 약 180만 건의 조회수를 기록했습니다. 핵심 아이디어는 간단합니다. 대부분의 프로덕션 LLM 호출에는 산문(prose)이 필요하지 않습니다. 라벨, 필드 또는 짧은 요약만 필요합니다. 따라서 일반 모델이 토큰 단위로 답변을 작성하는 대신, 각 CDM은 하나의 작업만을 수행하고, 입력 데이터를 한 번 읽은 후 유형화된 결과를 반환합니다. 가격은 입력 토큰당 100만 개에 $0.05이며 (OpenRouter는 20% 프로모션으로 $0.04를 제시), 출력은 무료입니다.
이 출시 게시물에서는 “프론티어 LLM API 대비 200배 빠르고, 467배 저렴하며” 그리고 “DecisionBench에서 77.2% 달성”이라는 큰 주장을 펼쳤습니다. 하지만 다음 날 Bitroot의 스레드가 이를 반박했습니다. 그들의 지적은 467배라는 수치에 명시된 기준선(baseline)이 없으며, DecisionBench에는 공개 출처가 없고, 아무도 분류기 결과를 몇백 개의 라벨링된 예제와 신뢰 구간 없이 신뢰해서는 안 된다는 것이었습니다. 이는 타당한 비판이었기에, 저는 이를 중심으로 테스트를 구축했습니다.
제가 실행한 내용, 유지된 부분, 그리고 실패한 부분을 소개합니다.
설정 (The setup)
저는 Lead SWE이므로, 이 모델들을 프로덕션 트래픽을 라우팅하기 전에 검증하는 방식대로 테스트했습니다. 즉, 공개 라벨링 데이터, 모든 엔진에 동일한 프롬프트 사용, 그리고 디스크에 저장된 원시 결과물입니다.
- 분류 (Classify): 300개의 CLINC150 테스트 발화(의도 10개 + 범위를 벗어난 경우 50개)와 110개의 Bitext 고객 지원 티켓을 11개 카테고리에서 사용했습니다.
- 추출 (Extract): 50개의 SROIE 영수증(회사, 날짜, 주소, 총액)과 30개의 LinkedIn 채용 공고(회사, 최고 급여 범위, 작업 유형을 열거형(enum)으로 지정)를 사용했습니다.
- 요약 (Summarize): 6개의 QMSum 회의록(4k~9k 토큰), 2개의 긴 문서(31k 토큰), 그리고 하나의 369k 토큰 스트레스 문서를 사용했습니다.
- 기준선 (Baseline): Ollama에서 로컬로 실행되는 Qwen3 1.7B 모델을 사용했으며, 동일한 지침과 JSON-schema 제약 출력 방식을 적용했습니다. 이 장비에는 프론티어 API 키가 없었기 때문에, 프론티어 모델의 경우 공식 가격 페이지(2026년 10월 22일 확인)를 기준으로 산술 계산을 했습니다.
모든 것은 하나의 OpenAI와 호환되는 기본 URL을 통해 처리됩니다. Classify는 Jev와 호환되는 Decisions 엔드포인트를 가지고 있으며, 제가 가장 많이 사용한 것이 바로 이 부분이었습니다:
httpx와 os를 가져옵니다.
r = httpx.post(
"https://api.scaledown.xyz/v1/scaledown",
...
각 응답에는 usage.cost 필드가 포함됩니다. 제 경우, 청구된 입력 토큰 백만 개당 정확히 $0.05로 계산되었습니다.
분류(Classify): 가장 강력한 결과
CLINC150 (n=300, 10 intents + out-of-scope) accuracy 95% CI OOS recall
ScaleDown Decisions (classify-1) 97.3% 94.8 - 98.6% 98%
ScaleDown /classify (rubrics) 96.7% 94.0 - 98.2% 100%
...
신뢰 구간(confidence intervals)은 두 세트 모두에서 작은 로컬 모델과 겹치지 않았습니다. CLINC150에서는 out-of-scope 처리 능력이 가장 인상적이었습니다. 총 50개의 out-of-scope 쿼리 중 49개를 정확하게 거부했으며, 오직 6개의 in-scope 쿼리만이 잘못 "oos"로 분류되었습니다. 이는 실제 라우터에서 치명적인 실패입니다.
저는 프롬프트 엔지니어링(prompt engineering)이 필요하지 않았습니다. 레이블당 일반 영어 문장 한 줄만 작성했고, 그것으로 충분했습니다.
지연 시간(Latency)은 인도에 있는 클라우드 박스에서 측정된 순차적 값입니다: Decisions의 경우 p50 162 ms, p95 397 ms였고, reasoning: false를 사용한 /classify는 p50 134 ms였습니다. 티켓 세트는 더 긴 꼬리(tail) 분포를 보였습니다 (p95 약 1.0 s).
추출(Extract)은 표준 response_format JSON 스키마를 사용합니다. 각 속성(property)의 description이 검색 기준이며, 모든 값은 신뢰 점수와 입력 내 문자 오프셋(character offsets)과 함께 반환됩니다.
schema = {"type": "object", "properties": {
"company": {"type": "string", "description": "채용 회사의 이름"},
"max_salary": {"type": "string", "description": "명시된 급여 또는 임금 범위의 최고액"},
...
field acc valid JSON spans verbatim p50 latency
Receipts (50 SROIE)
ScaleDown Extract 89.5% 100% 100% 1.43 s
...
영수증(receipts)의 각 필드에서 ScaleDown은 로컬 모델의 78%와 비교하여 총계 항목을 100% 맞혔습니다. 총계는 실제로 신경 써야 하는 필드입니다. 회사 이름에서는 상대적으로 약했습니다 (80% 대 88%).
ScaleDown이 반환한 모든 구문은 원본 텍스트에 문구 그대로(verbatim) 나타났습니다. 인용 표시는 장식이 아닙니다. 값의 출처를 정확하게 강조 표시할 수 있으며, 이것이 Bitroot가 확인하라고 말했던 내용입니다.
저는 놓친 모든 부분을 읽어보았는데, 대부분은 환각 현상(hallucinations)이라기보다는 판단에 따른 것들이었습니다:
- SROIE 골드 데이터의 "날짜"에는 종종 시간(
21 MAR 2018 17:59)이 포함됩니다. ScaleDown은 날짜만 반환했습니다.
- 레이블에 포함된 등록 번호 없이
KING'S CONFECTIONERY S/B를 반환했습니다.
- 구인 게시글의 경우, 브랜드 대신 모회사(parent company)를 반환하는 경우가 있었습니다(
Experis 게시물에 대해서는 ManpowerGroup, MountainView Hospital에 대해서는 HCA Healthcare).
- 실제 오류 사례: 제빵 제품 배달 영수증 한 건에서 판매자 정보가 아닌 구매자의 이름과 주소를 가져왔습니다. 이 양식은 제가 임의로 샘플링한 4번이나 나타났기 때문에, 이것만으로도 8개의 필드 점수를 차지했습니다.
유효한 JSON(Valid JSON)은 두 엔진 모두에서 100%였지만, 이는 부분적으로 제가 로컬 모델의 출력을 스키마(schema)로 제한했기 때문입니다. 더 큰 차이점은 ScaleDown이 추가 작업 없이 오프셋(offsets)과 신뢰도 점수(confidence score)를 반환한다는 것입니다.
요약: 빠르고 충실하지만, 쿼리 초점을 확인하세요
요약을 위해 저는 QMSum 쿼리를 시스템 지침으로, 녹취록을 사용자 메시지로 전달했습니다.
QMSum 미팅, 4k-9k 토큰 (n=6) p50 p95 ROUGE-L 환각 사실이 포함된 요약본
ScaleDown Summarize 0.65 s 0.89 s 0.230 6개 중 0개
Qwen3 1.7B local (CPU) 24.3 s 34.1 s 0.201 6개 중 2개
저는 각 요약본에 있는 모든 숫자와 이름을 녹취록과 대조하여 확인했습니다. ScaleDown은 평균 평점 2.39, 15유로에서 12.50유로로 하락한 점, 그리고 5천만 유로의 이익 목표 등 세부 사항을 포함하여 모두 원본에 있었습니다. 로컬 모델은 회의가 7점 만점 척도를 사용했는데도 평점을 "1부터 5까지"라고 언급했습니다. 또한 예산 초과 프로토타입을 "합리적인 가격"이라고 지칭하기도 했습니다.
두 가지 약점이 발견되었습니다:
- 질의 초점(Query focus). 회의에서 'PM이 무슨 질문을 했는지'에 답하기보다는 발표 내용을 요약하는 데 초점을 맞췄다. 두 개의 31k 토큰 스크립트 모두 정확한 질문 내용 대신 주변 부분을 요약했다. 즉, QA 모델이라기보다는 요약기가 먼저 작동한다.
- 1M 컨텍스트 주장(The 1M-context claim). 12개의 연결된 회의로 구성된 369k 토큰 문서를 보내 각 회의당 한두 문장을 요청했다. 시스템은 입력을 수락하고 14.2초 만에 반환했다. 하지만 요약 내용은 문서 내 두 개의 서로 다른 회의 시리즈 중 하나만 다루고 나머지 하나는 완전히 건너뛰었다. 따라서 이 정도 양을 처리할 수는 있지만, 그 길이에서의 커버리지(coverage)는 신뢰해서는 안 된다.
정말로 200배 빠를까?
내가 측정할 수 있는 어떤 것과 비교해서도 아니며, ScaleDown 자체 문서에 따르면도 아니다.
내 CPU에서 구동되는 1.7B 모델과 비교했을 때, 짧은 분류(classification)는 1.8배 빨랐고, 추출(extraction)은 2.5배에서 4.6배 사이였으며, CPU 프롬프트 처리가 지배적인 6k 토큰 요약의 경우 약 37배 빠르다. 하지만 로컬 CPU 모델은 최첨단 API는 아니다. ScaleDown 자체의 비교 벤치마크 페이지에 따르면, 각 제공업체의 평균(OpenAI 대비 2.4배, Anthropic 대비 3.8배)보다 2.2배에서 13.9배 빠르다고 보고한다. 이는 확실한 속도 향상이지만, 출시 게시물에서 주장하는 200배와는 한 자릿수 차이가 난다. "200배"가 무엇을 기준으로 측정되었는지 찾을 수 없었다.
정말로 467배 저렴할까?
가격은 실제다. 모든 호출에 대해 입력 토큰당 정확히 $0.05가 청구되었고 출력은 무료였다. 하지만 비율은 전적으로 기준선(baseline)에 달려 있으며, 함정이 있다: ScaleDown은 사용자의 원본 프롬프트보다 더 많은 입력 토큰을 청구한다. 레이블 기준(Label criteria), 스키마(schemas), 내부 프롬프트(internal prompts)가 계산된다. 나의 분류 호출은 약 481 토큰이 청구되었지만, 일반 LLM 프롬프트로 동일한 작업을 수행하는 것은 172 토큰이었다. 추출 호출은 571 토큰 대비 약 1,380 토큰이 청구되었다.
측정된 토큰 수를 사용하고 추론(reasoning) 토큰은 제외한 목록 가격 기준 1,000회 호출당 비용은 다음과 같다:
classify extract summarize (6k tok)
ScaleDown CDM $0.024 $0.069 $0.317
gpt-5-nano $0.012 $0.057 $0.333 (0.5x - 1.0x)
...
따라서 가장 저렴한 소형 모델들과 비교했을 때 ScaleDown의 비용은 비슷하며, 짧은 분류 작업에서는 gpt-5-nano가 실제로 절반 가격입니다. 플래그십 모델들(flagship models)과 비교하면 45배에서 200배까지 더 저렴합니다. 프론티어 모델이 호출당 수백 개의 추론 토큰(reasoning tokens)을 사용하는 경우에만 최대 467배의 절감 효과를 볼 수 있습니다. 예를 들어, gpt-5.5가 500개의 추론 토큰으로 분류하는 작업은 대략 670배로 계산됩니다. 이는 라우팅(routing) 작업을 수행하는 추론 모델에게는 현실적인 수치이지만, 출시 게시물 어디에도 명시되어 있지 않습니다. ScaleDown 자체 문서에서는 더 보수적입니다: OpenAI 평균보다 89배 저렴하고 Anthropic 평균보다 161배 저렴합니다.
/classify 엔드포인트(endpoint)는 요청당 최대 50개의 chunks를 허용하며, 레이블 세트(label set)에 대해서만 비용을 청구합니다. 대량으로 분류 작업을 수행하면 제가 측정한 토큰 오버헤드의 대부분이 제거됩니다.
제한 사항: 이번에는 Compress나 동시 부하(concurrent load)에 대한 벤치마크를 진행하지 않았습니다. 무료 크레딧이 약 1백만 개의 입력 토큰을 사용하고 소진되었기 때문입니다. (5천만 개 무료 토큰은 출시 기간 프로모션이었음). 그 이후에는 402 Insufficient credits 오류가 발생했으므로, 실제 평가를 진행하기 전에 추가 크레딧(top-up) 예산을 확보하시길 바랍니다.
Bitroot가 정확히 지적한 점
회의적인 의견을 제시했던 스레드에서 제가 확인할 수 있는 모든 지점에서 옳은 말을 했습니다:
- 467배라는 수치에는 명시된 기준선(baseline)이 없습니다. 저는 비싼 추론 모델을 가정해야만 이 수치를 재현할 수 있습니다.
- DecisionBench의 77.2%에 대한 공개 출처를 여전히 찾지 못했습니다.
- 가격은 검증하기 쉬운 부분이며, 이는 사실로 확인되었습니다.
그들의 주요 조언은 300개 이상의 레이블이 지정된 예제들로 테스트 세트를 구축하고 구간(interval)을 보고하는 것이었습니다. 그리고 그 조언 덕분에 이 테스트가 의미를 가질 수 있었습니다. n=300일 때, 97%와 91% 사이의 격차는 실제입니다. 하지만 n=30에서는 그렇지 않을 것입니다.
제 의견
오늘 저는 분류(classification) 트래픽을 ScaleDown으로 라우팅할 것입니다. 제가 테스트한 엔진 중 가장 정확했으며, 아웃 오브 스코프(out-of-scope) 처리가 깔끔하고, p50 지연 시간(latency)이 200ms 미만이며, 프롬프트 튜닝(prompt tuning)이 필요 없었습니다.
추출(Extract) 기능은 출처(provenance)가 필요한 경우 강력한 기본 옵션입니다. 왜냐하면 모든 값에 하이라이트할 수 있는 오프셋(offset)이 함께 제공되기 때문입니다. 요약(Summarize) 기능은 빠르고 제 샘플에서는 사실을 지어내지 않았지만, 자체 데이터에 대한 질의 초점(query focus)을 테스트하고, 300k 토큰 이상의 입력 커버리지(coverage)를 신뢰하지 마십시오.
마케팅 비율은 별개의 문제입니다. 이미 gpt-5-nano를 사용하고 있다면, 절약되는 금액이 많지 않을 것입니다. 라우팅 및 추출에 플래그십(flagship) 또는 추론 모델(reasoning model)을 사용한다면, 절약되는 금액은 크고 실질적입니다.
자체 데이터로 테스트해 보세요. 수백 개의 레이블링된(labelled) 예시가 저의 글을 포함하여 어떤 출시 게시물보다 더 많은 것을 알려줄 것입니다.