Google의 Decisions API, 1,000개 질문에 답하고 출력에는 과금하지 않는다

의 가장 저렴한 부분은 Gemini Decision 1존재하지 않는 부분입니다. Google은 새로운 Gemini Decisions API 뒤에 이 모델을 2026년 11월 11일에 공개했고, 가격 페이지에는 출력 비용이 0으로 표시됩니다 — 저렴한 것도, 할인된 것도 아니라 아예 없습니다. POST /v1beta/decisions에는 생성할 산문이 없기 때문입니다. 공유 입력 블록 하나와 최대 1,000개의 타입이 지정된 질문을 보내면, 질문당 보정된 답변 하나만 돌아오고 그 외에는 아무것도 없습니다. 리더보드 숫자는 출시 당일 주목을 받았습니다. 청구서 항목이야말로 여러분이 만드는 것을 바꾸는 부분이며, 누군가의 아키텍처 다이어그램을 복사하기 전에 계산을 해볼 가치가 있습니다.

지난 2년 동안 내린 다른 모든 모델 결정은 서로 반대 방향으로 당기는 두 가지 비용에 의해 형성되었습니다. 한 번만 보내고 싶은 입력과 짧게 유지하고 싶은 출력입니다. 이 엔드포인트는 두 번째 긴장을 완전히 없애고, 단일 요청 내부에 존재하는 다른 긴장으로 대체합니다. 새로운 긴장이 어디에 자리하는지 보고 나면, API 설계의 나머지 부분—질문 상한, 공유 컨텍스트, 캐싱 부재—은 더 이상 임의적으로 보이지 않습니다.

zero output tokens가 산술 연산에 미치는 영향

현실적인 문서 채점 작업을 가정해 보세요. 40,000토큰 분량의 정책서나 계약서가 있고, 여기에 대해 답을 얻고 싶은 질문이 1,000개 있습니다. Decisions API에 한 번 요청하면 40,000개의 입력 토큰이 백만 토큰당 $0.10로 한 번만 청구되며, 이는 1센트의 10분의 4인 0.4센트 — 1,000개의 답변 전체에 $0.004입니다.

이제 1주일 전에 질문했을 방식 그대로 같은 1,000개의 질문을 1,000개의 개별 generate-content 호출로 해 보세요. 각 호출은 문서를 함께 전달해야 합니다. 채팅 엔드포인트는 호출 간에 문서를 유지할 방법이 없기 때문입니다. 그러면 입력 토큰이 4,000만 개가 되고, 동일한 토큰당 요율로 계산하면 $4.00이며, 각 호출이 생성했을 출력 토큰까지 더하면 격차는 더 벌어집니다. envelope는 편의 기능이 아닙니다. 같은 작업에 대해 1,000배의 비용 차이이며, 이는 단 하나의 설계 선택에서 비롯됩니다: 질문은 왕복 한 번당 하나씩이 아니라 한 번의 처리로 하나의 공유 컨텍스트에 대해 평가됩니다.

그 계산은 이 모델이 원하는 작업량의 형태도 알려줍니다. 하나의 큰 객체에 대한 여러 질문을 함께 답하는 것입니다. 질문이 1,000개의 서로 다른 객체에 관한 것이라면, 1,000개의 요청이 생기고 절감 효과는 전혀 없습니다.

엔벨로프: 262,144 토큰, 공유되며 최대 1,000개의 질문으로 제한됩니다

컨텍스트 창은 공유 입력과 요청 내 모든 질문을 합쳐 262,144토큰을 포괄합니다. 그 예산 안에서 1개에서 1,000개 사이의 질문을 제시할 수 있습니다. 중요한 숫자는 상한입니다. 한 번의 호출에서 1,000개 질문은 분류기가 감당할 영역이 아니라, 한 번의 처리로 압축된 규칙 엔진 한 대 분량의 판단입니다. 지원 티켓은 40개의 정책 조항과 대조해 확인할 수 있고, 대출 파일은 모든 대출 심사 규칙과 한 번에 검사할 수 있습니다.

요청 구조의 두 가지 속성은 놓치기 쉽고 나중에 발견하면 비용이 많이 드는 부분입니다. 질문은 독립적으로 평가됩니다 — 한 질문의 답변이 다음 질문의 조건이 되지 않으므로, 앞선 응답에 의존하는 후속 질문을 통해 추론을 연결할 수 없습니다. 또한 모델은 질문 키를 전혀 보지 못하고 작성한 지침 텍스트만 보므로, 키는 본인의 기록용이고 지침은 그 자체로 완결되어야 합니다.

세 가지 질문 형태, 그리고 각각에 숨은 함정

• 예/아니오 — noul 타입은 0.01에서 0.99 사이의 확률과 신뢰도 점수를 반환합니다. 이 경계는 양쪽 끝에서 클램프되므로, 라우팅 임계값을 0.995로 설정하면 모델이 아무리 확신하더라도 절대 발동하지 않습니다. API가 실제로 반환할 수 있는 범위 내에서 임계값을 선택하세요.

• Choice — 2~255개의 이름 있는 옵션으로, 승리한 옵션, 합이 1이 되는 각 옵션의 확률, 그리고 신뢰도를 반환합니다. 점수를 매기기 전에 API는 옵션 키를 UTF-8 바이트 순서에 따라 사전순으로 정렬합니다. 따라서 JSON 키 순서는 무관하며, 정확히 동점일 때는 먼저 정렬되는 키 쪽으로 결정됩니다. Google의 지침은 여기에서 비롯됩니다. 포괄 옵션의 이름을 other로 지정하세요. none_of_the_above 같은 이름은 대부분의 실제 범주보다 앞에 정렬되어, 지면 안 되는 동점 상황에서 이기기 때문입니다.

• 점수 — 2~255개의 순서가 있는 평가 기준 레벨이 있으며, 2~10개를 권장합니다. 반환 값은 확률 가중 기대 레벨이며, 기대값이 레이블이 아닌 배열 인덱스를 평균하기 때문에 1/10/100/1000으로 작성된 척도는 해당 척도에 없는 숫자를 산출합니다. 평가 기준을 인덱스 기준으로 균등한 간격으로 유지하거나, 기대 인덱스를 직접 레이블로 변환하세요.

문서에 사용할 수 없는 것으로 나열된 항목

이 공백은 모두 같은 방향을 가리킵니다. 바로 아무것도 감싸지 않은 단일 호출 엔드포인트라는 점입니다. 컨텍스트 캐싱이 없어서 여러 요청에 재사용되는 정책 문서도 매번 전체 금액이 다시 청구됩니다. Batch API가 없어서 작년 티켓을 반값으로 야간 일괄 처리하는 것도 불가능합니다. Flex 또는 Priority 등급도 없습니다. 이 모델은 v1beta 버전의 Gemini Developer API에서만 제공되며, Google이 배포한 문서에는 Vertex AI 목록이 없습니다. 이는 조달이 API 키가 아니라 클라우드 계약을 통해 이루어지는 경우에 중요한 세부 사항입니다.

미디어는 이례적으로 넓으면서도 동시에 이례적으로 제한되어 있습니다. 텍스트, 이미지, 비디오, 오디오, PDF가 모두 하나의 요청에 들어갑니다. 제한은 인라인 base64 100MB, PDF 50MB, 외부 HTTPS URL당 15MB입니다. YouTube 링크는 허용되지 않으며 gs:// URI도 허용되지 않습니다. 업로드된 파일 참조, 서명된 URL 또는 바이트를 전달합니다.

속도 제한은 무료 등급에서 분당 200회 요청 및 50,000토큰에서 시작하며, Tier 1에서는 1,500회 및 100만 토큰으로, Tier 2에서는 분당 5,000회 요청 및 400만 토큰에 도달하고 일일 요청 상한은 없습니다. 무료 등급은 무료이지만 Google 제품 개선에 사용된다고 문서화되어 있어, 기밀 유지 조항이 적용되는 어떤 용도에도 부적합합니다.

점수 한눈에

Artificial Analysis Decision Index v2.1에서 이 모델은 66점(반올림 전 65.98)으로, 위원회가 순위를 매기는 18개 의사결정 모델 중 9위에 올랐습니다. 여섯 개 구성요소 중 두 가지인 AA-Omniscience-Decision v1.1과 HLE-MultiChoice v1.1에서 각각 15% 가중치로 단독 1위이며, 복합 점수의 대부분을 결정하는 구성요소인 AA-Paperclip에서는 30% 가중치로 중위권입니다. 측정 비용은 100만 작업당 345달러, 지연시간은 작업당 211밀리초로, 해당 분야 중앙값 209밀리초와 대비됩니다. 구글은 이번 릴리스와 함께 자체 벤치마크 표를 공개하지 않았으며, 여기 제시된 모든 성능 수치는 독립 위원회가 자체 하네스에서 산출한 것입니다. 66점의 산출 근거는 별개의 질문이자 별도의 기사에서 다룹니다.

이미 라우팅하는 파이프라인에 맞춰 통합하기

OrcaRouter는 gemini-decision-1을 지원하지 않으며, 그 이유는 상업적이라기보다 구조적입니다. 확률만 제공하는 엔드포인트는 chat-completions 대상이 아니므로, 우리 형태의 라우터가 하나의 키 뒤에 둘 것은 없습니다. 우리가 맡는 파이프라인의 절반은 나머지 절반입니다. 의사결정 서비스는 거의 항상 두 번의 호출로 이루어집니다. 무언가가 후보 답안, 루브릭 또는 후보 목록을 초안으로 만들고, 무언가가 그것을 채점합니다. 그리고 모델 선택이 실제로 경합되는 지점은 초안 작성 호출입니다.

그 호출은하나의 엔드포인트에서 200개 이상의 모델에 걸쳐 실행될 수 있으며,제공업체 정가가 0% 마크업으로 그대로 전달되는 가격으로, 공급업체가 가격을 인하하면 다음 청구 주기가 아니라 같은 날 우리 쪽에서 새 숫자가 적용됩니다. 모델 퓨전은 여기서 제 역할을 합니다 — 채팅 UI에서는 그렇지 않은 방식으로: 두 명의 초안 작성자가 경쟁하는 후보 답변을 생성하고, Decisions API는 단일 요청에서 동일한 평가 기준으로 둘 다 점수를 매기므로 A/B 테스트가 레코드별 결정으로 바뀝니다.

페일오버도 정확히 짚고 넘어갈 필요가 있습니다. 자동 페일오버는 생성 호출을 보호합니다 — 초안 작성 모델 뒤에 있는 제공자가 오류를 반환하면 요청이 다른 경로로 재라우팅되고 파이프라인은 계속 진행됩니다. 하지만 채점 호출은 보호할 수 없습니다. 보낼 곳이 정확히 한 곳뿐이기 때문입니다. 의사결정 엔드포인트가 다운되면 파이프라인도 다운되며, 라우팅을 아무리 바꿔도 이 사실은 달라지지 않습니다. 초안 작성 쪽은 복원력을 갖도록 설계하고, 채점 쪽은 의존성이라는 점을 받아들이십시오.

결론은

Decisions API를 도입할 가치가 있는 이유는 하나이며, 그것은 리더보드 순위가 아닙니다. 이 API는 수천 번의 왕복을 하나의 과금되는 입력으로 축소하며, 그로 인해 어떤 질문을 저렴하게 던질 수 있는지가 달라집니다. 여러분의 문제가 하나의 큰 객체—계약서, 청구 파일, 1시간 분량의 비디오—에 대한 많은 판단처럼 보인다면 그 위에 구축하세요. 그리고 프롬프트를 하나의 요청 안에 유지할 것으로 예상하세요. 이 API를 저렴하게 만드는 모든 일은 단일 호출의 첫 토큰과 마지막 토큰 사이에서 일어나기 때문입니다. 여러분의 문제가 천 개의 작은 객체에 대한 단 하나의 질문처럼 보인다면, 이 포장이 주는 이점은 없으며 입력 요율은 더 저렴한 의사결정 모델이 청구하는 금액의 단순히 세 배입니다.