SubQ Snap 1.1 vs Granite 4.2 3B: 토큰당 가격은 잘못된 청구서다

IBM의 Granite 4.2 3B는 입력 토큰 100만 개당 $0.03에 책정되어 있습니다. SubQ Snap 1.1는 $0.04에 책정되어 있습니다. 토큰당 요율이 곧 청구서라면, 30억 개 매개변수를 가진 Apache-2.0 모델이 Artificial Analysis Decision Index v1.0에서 공동 1위를 차지한 의사결정 모델을 앞서게 될 것이고, 이 글은 짧았을 것이다. 요율은 청구서가 아니다. 토큰이 아니라 의사결정을 기준으로 가격을 매기면 — 각 모델이 하나의 의사결정을 내기 위해 무엇을 출력해야 하는지까지 포함하여 — 순위는 뒤집히고, 단일 구성 설정에 따라 다시 뒤집히며, 어느 공급업체도 광고하지 않는 어딘가에서 끝난다.

Granite 4.2 3B는 IBM의 소형 dense 추론 모델로, 2026년 8월 25일 8B 및 30B 형제 모델과 함께 이례적으로 요란한 발표 없이 공개되었습니다. 출시 행사 대신 기술 블로그 게시물이었죠. Snap 1.1은 Subquadratic의 의사결정 모델로, 2026년 10월 22일부터 서비스 중이며, 텍스트를 생성하는 대신 고정된 답변 집합에서 하나를 선택해 반환합니다. 두 모델은 정확히 하나의 워크로드에서만 겹칩니다. 바로 텍스트 일부를 받아 그것이 무엇인지 판단하는 작업입니다. 그 외의 모든 것은 다릅니다. '저렴하다'는 말의 의미까지도요.

먼저, 두 모델이 실제로 무엇인지부터

Granite 4.2 3B는 Granite-4.1-3B-Base를 기반으로 구축된 30억 파라미터 규모의 dense 디코더입니다. 이는 세 가지 모드를 갖춘 추론 모델입니다. 사고 연쇄를 출력하는 사고 모드, 낮은 노력 모드, 그리고 직접 답변하는 비사고 모드입니다. IBM은 AIME 2025에서 78.33, GPQA에서 54.80, LiveCodeBench v6에서 69.71, MMLU-Pro에서 67.84, IFBench에서 74.3, τ³-Bench에서 45.8을 보고했습니다 — 모두 벤더 수치이며, 독립적으로 재현된 것은 없습니다. 긴 컨텍스트에서는 64K에서 RULER 67.52, 128K에서 55.30을 보고합니다. Artificial Analysis는 이 모델의 Intelligence Index를 9로 평가했는데, 이는 절대적 기준으로는 눈에 띄지 않지만 해당 크기 등급의 중앙값보다 높습니다.

하드웨어 이야기가 흥미로운 부분입니다. bf16에서 6~8GB, 양자화하면 2GB 미만으로 실행되므로 노트북, 단일 소비자용 GPU, 또는 충분한 RAM을 갖춘 CPU에서도 돌아갑니다. 텍스트 전용이며 12개 언어를 지원하고, OpenAI 호환 도구 호출을 지원하며, vLLM, SGLang, Transformers, GGUF, llama.cpp, MLX, Ollama로 제공됩니다. 제약이 "내가 통제하는 곳에서 실행되어야 한다"라면, 이 모델은 그 조건을 충족합니다.

SubQ Snap 1.1은 거의 모든 차원에서 정반대 유형의 제품이다. 가중치가 없다. Subquadratic의 API를 통해서만 실행된다. 최대 384K 토큰의 텍스트와 이미지, 그리고 2~255개의 대안으로 구성된 답안 세트를 입력받아 보정된 확률과 함께 하나의 선택을 반환한다. 문장을 쓸 수 없는데, 바로 그게 핵심이다: 파싱할 출력도, 비용을 지불할 출력도 없다.

출력 토큰의 함정

토큰당 비교가 숨기는 계산은 이렇습니다. 100만 건의 라우팅 결정을 생각해 보십시오. 각 결정이 티켓 텍스트 6,000토큰을 읽는다면 — 중간 규모 지원 운영의 한 달치로 그럴듯한 분량이거나, 대형 운영의 바쁜 오후 한나절 분량입니다. 이는 60억 입력 토큰입니다.

• 비사고 모드의 Granite 4.2 3B — 60억 입력 토큰을 $0.03/M로 계산하면 $180이고, 여기에 결정당 대략 5개의 출력 토큰, 즉 500만 출력 토큰을 $0.12/M로 계산한 $0.60을 더하면 됩니다. 합계: 약 $180.60.

• Granite 4.2 3B의 사고 모드 — 입력 6B에 $180, 여기에 결정당 약 800개의 추론 토큰, 또는 $0.12/M로 800M 출력 토큰이면 $96. 합계: 약 $276.

• SubQ Snap 1.1 — $0.04/M 기준 6B 입력 토큰이면 $240이며, 출력 항목은 아예 없습니다.

그래서 정직한 답은 세 가지 서로 다른 답입니다. 직접 답하도록 구성하면 Granite는 Snap보다 25% 저렴하고, 기사는 정말 거기서 끝났을 겁니다. 생각하도록 구성하면 Granite는 Snap보다 15% 더 비쌉니다. 추론 토큰이 파이프라인에서 가장 비싼 요소인데 아무도 그 비용을 예산에 잡지 않기 때문입니다. Snap의 장점은 입력 단가가 아니었습니다 — Snap의 입력 단가는 Granite보다 33% 더 높습니다 — 장점은 그 아키텍처가 숙고에 토큰을 쓸 방법이 없다는 점입니다.

그것은 이론적인 위험이 아니다. Artificial Analysis의 Granite 4.2 3B에 대한 독립적인 프로파일은 이 모델을 "매우 장황하다"고 평가하며, Intelligence Index에서 평가되는 동안 9,200만 개의 출력 토큰을 생성했다고 기록하는데, 이는 비교 가능한 모델들의 중앙값 6,700만 개와 대비된다. 장황함은 추론 모드에서 이 모델의 측정된 속성이며, 토큰당 가격 우위가 라우팅 워크로드와 맞닥뜨렸을 때 살아남는지를 결정하는 속성이다.

그것은 또한 언뜻 보면 잘못된 것처럼 보이는 수치를 설명해 줍니다. Artificial Analysis는 Snap 1.1을 백만 작업당 약 $30로, Elephant 9B는 $8.4로 제시합니다. 백만 작업당 30달러는 평균 작업이 수천 토큰 정도로 매우 짧다는 것을 의미합니다. Decision Index의 벤치마크 구성은 짧습니다. 여러분의 티켓, 계약서, 로그는 그렇지 않으며, 비용은 거기서부터 입력 길이에 따라 선형으로 증가합니다. 작업당 수치는 견적이 아니라 벤치마크의 속성으로 취급하세요.

3B가 진정으로 앞서는 부분

더 저렴한 토큰은 그중 가장 작은 문제일 뿐입니다. Granite 4.2 3B는 Apache 2.0에 따라 자체 호스팅할 수 있으므로, 하드웨어 비용을 지불한 뒤에는 호출당 비용이 전혀 들지 않고, 데이터가 네트워크 밖으로 나가지 않으며, 속도 제한도 없고, 가격이나 모델을 이용자 모르게 바꿀 수 있는 공급업체도 없습니다. 규정 준수가 전제된 워크플로에서 이는 선호 사항이 아니라 필수 요건이며, Snap 1.1은 그 영역에 아예 들어설 수 없습니다.

그것은 더 많은 일도 한다. 라우팅 결정 후에 요약을 작성한다. 스키마를 사용하는 도구 호출을 처리한다. 다섯 번째 사전 학습 단계에서 추가된 512K까지의 옵트인 컨텍스트 확장을 지원하는데, 이는 서류상으로는 Snap의 384K보다 길지만, RULER 점수가 64K에서 67.52에서 128K에서 55.30으로 떨어지는 것은 그 윈도우 중 얼마나 많은 부분을 실제로 사용할 수 있는지에 대한 적절한 경고다. 그리고 애플리케이션 옆 컨테이너에서 엣지에서 실행할 수 있을 만큼 작아서 결정과 행동 사이에 네트워크 홉이 없다.

Snap 1.1이 진정으로 우위를 점하는 부분

3B 생성 모델이 구조적으로 잘하지 못하는 세 가지.

첫 번째는 캘리브레이션입니다. Snap 1.1은 기대 캘리브레이션 오차가 0.014로, 프리뷰의 0.108에서 낮아졌다고 보고하며, 답할 수 없는 질문에 대한 답변 보류율은 86%입니다 — 벤더의 프록시에서 자체 1.0 릴리스의 비환각 점수 0.7%와 대조됩니다. 이는 벤더 수치이므로 그렇게 읽어야 하지만, 답변 보류를 명시적 목표로 훈련된 모델을 설명합니다. 3B 추론 모델에는 그런 목표가 없습니다. 티켓에 답변할 수 있는지 물으면, 어느 쪽이든 그럴듯한 문장을 내놓을 것입니다.

긴 컨텍스트 단일 패스 동작이 두 번째입니다. Snap은 한 번의 순방향 패스에서 384K 토큰을 처리하며, 토큰당 연산량은 일정합니다. 이것이 Subquadratic Sparse Attention을 사용하는 전적인 근거입니다. Granite의 RULER decay는 모델이 편안하게 처리할 수 있는 길이의 10배에서 dense 모델이 보이는 정상 동작입니다. 로그 번들의 200,000번째 위치에 묻혀 있는 무언가에 결정이 달려 있다면, 아키텍처 차이는 학문적인 문제가 아닙니다.

세 번째는 출력 형태의 결정성이며, 이는 과소평가되고 있다. Snap은 옵션 목록에서 숫자를 반환한다. Granite는 텍스트를 반환하고, 당신은 그것을 파싱해야 하며, 모든 파서는 잘못된 답변이 장애로 이어지는 지점이다. 제약 디코딩은 그 격차의 대부분을 메운다. 이는 언급할 가치가 있다 — 그것은 근본적인 이점이 아니라, 얼마나 많은 스캐폴딩을 작성하느냐의 차이다.

아무도 묻지 않는 설정 질문

Granite 4.2 3B를 라우터로 사용하고 있다면, 가장 가치 있는 단일 변경은 사고(thinking) 모드를 끄는 것입니다. IBM이 바로 이런 이유로 해당 모드를 제공하며, 위의 계산이 그 이유를 보여줍니다. 다섯 개 레이블 중 하나를 고르라는 요청을 받은 추론 모델은, 사고하지 않는 패스에서는 올바르게 판단할 결정을 정당화하는 데 종종 800토큰을 소비합니다. 사고 모드가 더 낫다고 가정하기 전에 자체 데이터로 두 모드를 벤치마크하세요. 정답 집합이 고정된 작업에서는 사고 모드가 더 나은 경우가 자주 없습니다.

Snap의 대응 수단은 정반대다. 선택지를 더 적고 더 날카롭게 주는 것이다. 그 API는 질문을 16개로, 질문당 선택지를 255개로 제한하며, Decision Index에서의 정확도는 20%로 d1-ultra의 32%보다 낮고, 지수 점수는 기권이 떠받친다. 답변 집합을 좁히면 정확도 문제는 줄어들고, 개방형 판단을 맡기면 그것은 올바르게, 그리고 자주 거절할 것이다.

내가 실제로 만들 것

상당한 볼륨의 고객 지원 또는 문서 파이프라인이라면, 가장 저렴하면서도 방어 가능한 설계는 2단계 설계입니다. Granite 4.2 3B는 비사고 모드로 실행되어 쉬운 다수를 대상으로 하는 1차 분류기 역할을 합니다. 즉 명백히 환불, 명백히 장애, 명백히 스팸인 티켓처럼 3B 모델이 정확하고 한계 비용이 들지 않는 경우입니다. Snap 1.1은 나머지를 처리합니다. 긴 스레드, 모호한 사례, 올바른 답이 "에스컬레이션"일 수 있고 자신 있는 추측이 거절보다 나쁜 경우입니다. 필요한 일부에만 100만 토큰당 $0.04를 지불하고, 보정이 중요한 바로 그 결정들에서 보정된 확률을 얻습니다.

두 공급업체 모두 그 설계를 판매하지 않습니다. 각 업체가 전체 레이어가 되기를 원하기 때문입니다. Granite 4.2 3B는 OrcaRouter의 카탈로그에 없습니다. Apache 2.0이므로 셀프 호스팅이 일반적인 경로이며, 여러 추론 제공업체에서도 제공합니다. Snap 1.1도 저희 것이 아닙니다. 이는 Subquadratic 자체 API를 통해 실행됩니다. 이런 설계에 OrcaRouter가 기여하는 것은 이를 뒷받침하는 생성 계층입니다: 하나의 키 뒤에 있는 200개 이상의 모델, 공급업체 정가를 0% 마크업으로 전달, 자동 장애 조치. 따라서 에스컬레이션 요약을 작성하는 모델이 에스컬레이션 여부를 결정하는 모델과 동일한 의존 대상이 아니게 됩니다.

주목해야 할 점은 다른 사람이 실행했을 때 Snap 1.1의 보정이 유지되는지 여부입니다. 20% 정확도는 자체 출시 자료에서 가장 약한 수치이며, 위의 2단계 설계가 보기보다 저렴한지를 결정하는 수치입니다. Snap이 답변을 보류하는 빈도가 높을수록, 실제로 답해야 하는 단계로 더 많은 작업이 되돌아갑니다.