GPT-6 루나: 고용량 API 워크로드 실제 요청량 기준 비용 분석

모든 백엔드 팀은 언어 모델을 사용하면 훨씬 더 나아질 것이 분명하지만 아무도 출시하지 않은 작업 목록을 가지고 있습니다. 하루에 5백만 건의 지원 이벤트를 분류하고, 천2백만 행의 카탈로그를 풍부하게 하며, 모든 인바운드 웹훅이 대기열에 도달하기 전에 점수를 매기는 등의 작업 말입니다. 그 이유는 항상 동일합니다. 요청당 비용에 실제 요청 수를 곱하면 그 숫자가 반올림 오차가 아니게 되는 시점이 옵니다.

2026년 9월 22일 발표된 GPT-6 Luna는 입력 토큰 백만 개당 0.10달러, 출력 토큰 백만 개당 0.50달러이며, 1,000,000 토큰의 컨텍스트 창을 제공하고 캐시된 입력 읽기에 90% 할인을 적용합니다. 이는 보류되었던 여러 작업을 실현 가능하게 만들 만큼 저렴하며, 사람들이 계산을 멈추게 만들 만큼 충분히 저렴합니다. 이것이 바로 다섯 자리 숫자의 청구서에 대해 설명하게 되는 이유입니다.

다음은 계산 결과입니다. 세 가지 현실적인 워크로드 형태, 각 형태의 백만 요청당 비용, 그리고 정가보다 훨씬 먼저 청구서에 영향을 미치는 세 가지 변수입니다.

적용되는 요금

Sol 및 Luna의 캐시된 읽기 열은 별도로 게시된 숫자가 아니라 입력 요금에 적용되는 게시된 90% 할인율입니다. Anthropic은 캐시된 읽기 요금을 직접 게시하며 캐시를 작성하는 데 백만 개당 5.00달러를 청구하는데, 이는 볼륨에 따라 중요합니다. 접두사 변화가 많은 워크로드는 이 쓰기 비용을 반복적으로 지불하게 됩니다.

숫자를 보기 전에 한 가지 관점 수정입니다. OpenAI는 Sol과 Luna가 GPT-5.6 프로모션 가격보다 50% 저렴하다고 설명합니다. '프로모션'은 OpenAI의 자체 용어이며 실제 의미가 있습니다. 즉, GPT-5.6이 출시되었을 때의 요금이 아닌 할인된 요금과 비교하는 것입니다. 출시 보도에서 문서화된 GPT-5.6 Luna의 정가인 입력 1달러, 출력 6달러와 비교했을 때, GPT-6 Luna는 입력에서 90%, 출력에서 92%의 비용 절감 효과가 있습니다.

워크로드 A: 높은 QPS 분류

대부분의 팀이 먼저 고려하는 형태입니다. 안정적인 시스템 프롬프트, 도구 스키마 및 분류 체계, 그리고 작은 가변 페이로드를 사용하여 짧고 구조화된 결과를 반환합니다. 안정적인 접두사 1,500 토큰, 가변 페이로드 500 토큰, 출력 토큰 120개, 하루 5,000,000 요청을 가정합니다.

하루 5,000,000 요청 기준으로, 따뜻한 접두사를 사용하는 Luna에서는 월 약 18,750달러에 해당하는 하루 625달러입니다. 캐싱 없이 Sol에서 동일한 트래픽은 하루 26,000달러이며, Astra에서는 130,000달러입니다.

이 표에서 두 가지 사실을 알 수 있습니다. 캐싱 할인은 워크로드에 아무런 변화가 없었음에도 불구하고 이 청구서를 52% 절감합니다. 유일한 차이점은 선행 1,500 토큰이 호출 간에 바이트 단위로 동일하게 유지되었는지 여부입니다. 그리고 볼륨에서의 티어 간격은 백분율이 아니라 자릿수 차이입니다. 여기서 Sol보다 Luna를 선택하는 것은 비용 절감이 아니라 20배의 결정입니다.

워크로드 B: 대규모 컨텍스트 검색

여기서 Luna의 1,000,000 토큰 창은 더 이상 사양표의 한 줄이 아닙니다. 호출 간에 안정적으로 유지되는 200,000 토큰 지식 팩, 2,000 토큰 쿼리, 600 출력 토큰, 하루 50,000 요청을 가정합니다.

여기서 캐싱은 워크로드 A의 52%에 비해 Luna 청구서에서 88%를 절감합니다. 이 격차가 핵심입니다. 할인은 안정적인 접두사와 새로운 토큰의 비율에 따라 달라집니다. 하루 50,000번 재읽기되는 200,000 토큰 접두사는 프롬프트 캐싱이 가장 큰 효과를 발휘하는 형태입니다.

Luna의 창은 Sol의 872,000 토큰보다 크므로 900,000 토큰 페이로드는 더 비싼 모델에는 맞지 않고 더 저렴한 모델에는 맞습니다. 이는 일반적인 "페이로드가 증가하면 더 큰 모델로 승격" 라우팅 규칙을 뒤집는 것입니다. 자세한 내용은 GPT-6 Luna의 실제 모습에서 다루고 있습니다.

워크로드 C: 일회성 백필

배치 작업은 새로운 가격 책정이 단순히 저렴한 것을 넘어 무엇이 가능한지 변화시키는 지점입니다. 1,200만 레코드 강화 작업을 가정합니다. 안정적인 지시 900 토큰, 레코드당 300 토큰, 출력 토큰 250개입니다.

천2백만 레코드 백필 작업이 3,000달러 미만이며, 지시 접두사가 유지되면 2,000달러 미만입니다. 이는 팀이 단일 메시지로 승인받을 수 있는 금액입니다. Sol에서 동일한 작업은 예산 협의가 필요합니다.

여기서 비율에 주목하십시오. 이제 출력이 청구서의 절반을 차지하며, 이는 실제 비용을 결정하는 요소로 직결됩니다.

청구서를 결정하는 세 가지 변수

1. 출력 토큰, 입력의 5배로 청구되기 때문

Luna의 출력 요율은 입력 요율의 5배입니다. 접두사가 캐시된 워크로드 A에서 입력 비용은 백만 요청당 65달러이고, 120개의 출력 토큰은 60달러입니다. 응답 형식을 400 토큰으로 완화하면 출력은 200달러로 증가하여 백만 요청당 총 비용이 125달러에서 265달러로 늘어납니다. 오후에 선택한 응답 스키마가 청구서를 두 배 이상 늘린 것입니다.

해결책은 지루하지만 효과적입니다. 출력을 제한하는 것입니다. 문장이 아닌 열거형을 반환하십시오. 설명이 아닌 점수를 반환하고, 사람이 검토하는 소수의 경우에만 설명을 가져오십시오. 모델이 패딩할 수 없도록 JSON 스키마로 형태를 고정하십시오.

{
  "model": "gpt-6-luna",
  "response_format": {
    "type": "json_schema",
    "json_schema": {
      "name": "triage",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "category": { "enum": ["billing", "outage", "how_to", "abuse"] },
          "severity": { "type": "integer", "minimum": 1, "maximum": 4 }
        },
        "required": ["category", "severity"],
        "additionalProperties": false
      }
    }
  }
}

이 형태를 기반으로 구축하기 전에 OpenAI의 현재 모델 참조와 매개변수 이름을 확인하십시오. 모델 ID `gpt-6-luna`는 출시 자료에서 확인된 부분입니다.

2. 캐시 적중률, 얻을 수 있는 유일한 50%에서 88%의 무료 절감이기 때문

위의 모든 내용은 접두사가 바이트 단위로 동일하게 유지된다고 가정합니다. 그러나 프로덕션 환경에서는 시스템 프롬프트에 요청 ID를 삽입하거나 프로세스 간에 키 순서가 뒤섞이는 사전에서 도구 배열을 구축하기 때문에 보통 그렇지 않습니다. 두 가지 고전적인 캐시 파괴 요인이 이제 목록에서 제외되었습니다. GPT-6에서는 추론 노력이나 도구 가용성 변경이 더 이상 캐시를 무효화하지 않으며, 명시적인 중단점으로 캐시된 접두사가 끝나는 지점을 결정할 수 있습니다. 프롬프트 캐싱 대시보드와 진단 도구를 통해 적중률을 가정이 아닌 측정 가능한 것으로 만들며, GitHub는 수십억 개의 요청에서 새로 처리해야 하는 프롬프트 토큰이 50% 이상 감소했다고 보고합니다. 작동 방식은 GPT-6 프롬프트 캐싱 가이드에서 다루고 있습니다.

볼륨이 큰 경우, 적중률을 프로덕션 SLI(서비스 수준 지표)로 취급하십시오. 95%의 적중률을 40%로 조용히 떨어뜨리는 접두사 리팩터링은 워크로드 A에 하루 약 400달러의 비용을 추가하며, 오류나 경고, 실패하는 테스트를 발생시키지 않습니다.

3. 재시도, 비용이 곱해지기 때문

워크로드 A에서 5%의 재시도율은 하루 약 31달러를 추가합니다. 이는 허용 가능한 수준입니다. 워크로드 B에서 동일한 5%는 재시도가 캐시를 놓치면 하루 50달러, 캐시에 적중하면 6달러의 비용이 들며, 이 차이는 재시도가 프롬프트를 처음부터 다시 구축하는지 여부에 전적으로 달려 있습니다. 접두사를 다시 생성하는 재시도는 가장 비싼 탄력성입니다. 정확히 동일한 요청 본문을 재사용하십시오.

높은 QPS에서의 지연 시간 함정

저렴하다고 빠르지는 않으며, 높은 QPS에서는 이 점이 문제가 됩니다. Artificial Analysis의 제3자 측정에 따르면 GPT-6 Luna는 초당 153.9개의 출력 토큰을 처리하며 첫 번째 토큰까지의 시간은 124.23초이고, GPT-6 Sol은 102.15초입니다. 두 가지 주의사항이 있으며 모두 중요합니다. 이들은 공급업체에서 게시한 수치가 아닌 제3자 수치이며, 사용 가능한 가장 느린 구성인 **최대** 추론 변형에서 측정되었습니다.

그럼에도 불구하고 방향성은 중요합니다. 첫 번째 토큰까지 2분이라는 시간은 기본 HTTP 클라이언트 타임아웃을 초과하고, 로드 밸런서를 유휴 상태로 만들며, 대부분의 서버리스 런타임에서 실행 제한을 초과할 것입니다. 높은 QPS 동기 경로는 스트리밍과 함께 낮은 노력에 속하며, 높은 노력은 소켓을 기다리지 않는 배치 작업 및 큐 작업자에 속합니다. 타임아웃은 가격이 아닌, 배포하는 노력 수준에서 측정된 지연 시간에 맞춰 설정하십시오.

품질 최저점

Luna는 제품군에서 가장 똑똑한 모델이 아니며 OpenAI도 그렇게 주장하지 않습니다. OpenAI의 말에 따르면 Astra는 "전반적으로 최고의 모델"로 남아 있습니다. OpenAI가 발표한 내용은 다음과 같습니다. Luna는 최대 노력 시 DeepSWE 1.1에서 66.6%를 기록했으며, 이는 Claude Opus 5 및 Claude Fable 5의 중간 노력과 비교할 만하며, Opus 5보다 작업당 비용이 93% 낮고 Fable 5보다 96% 낮습니다. AutomationBench 1.0.6에서 높은 노력 시 이전 버전보다 5.4점 높고 작업당 비용은 58% 낮습니다. OSWorld 2.0 오프라인에서 최대 노력 시 GPT-5.6 Sol의 중간 성능을 10분의 1 비용으로 능가합니다.

이 수치들은 Claude Opus 5(같은 날 출시된 Opus 5.5가 아님)를 기준으로 측정한 공급업체 수치이므로, 방향성 지표로만 취급해야 합니다. 운영상의 해석은 Luna가 잘 지정되고 검증 가능한 작업에 대한 기준을 충족하는 가장 저렴한 모델이며, "검증 가능"이라는 단어가 핵심이라는 것입니다.

비용 모델을 확정하기 전에 검증하십시오

스프레드시트 계산은 가설입니다. 실제 트래픽으로 테스트하십시오. 프로덕션 페이로드 500개 샘플을 가져와 Luna와 Sol이라는 두 환경에서 실행하고, 토큰 수, 지연 시간, 스키마 준수 여부를 기록하십시오.

Apidog에서는 모델 ID를 환경 변수로 사용하여 저장된 단일 엔드포인트를 실제 페이로드 데이터 파일에 대해 테스트 시나리오로 실행합니다. 세 가지 어설션(단언문)을 추가하면 이 스위트는 정확성 검사가 아닌 비용 보호 장치가 됩니다. 즉, 응답이 JSON 스키마와 일치하는지, `usage.completion_tokens`가 요청당 출력 예산 이하로 유지되는지, 그리고 `usage.prompt_tokens_details.cached_tokens`가 0이 아닌지 어설션하는 것입니다. 이를 통해 캐시 적중률을 저하시키는 접두사 리팩터링은 다음 달 청구서에 나타나는 대신 CI에서 실패하게 됩니다. 이러한 사용량 필드 이름은 어설션하기 전에 현재 API 참조와 비교하여 확인하십시오.

그 마지막 어설션은 아무도 작성하지 않지만 모두가 필요로 하는 것입니다. 고볼륨 LLM 워크로드의 실패 모드는 거의 서비스 중단이 아닙니다. 녹색 대시보드 뒤에 숨겨진 4배의 청구서입니다.

Luna의 가격이 GPT-6 Sol 및 Claude Opus 5.5와 비교하여 한 주 내내 어떻게 유지되는지는 2026년 9월 AI 모델 가격 전쟁 분석을 참조하십시오.

요약

고볼륨, 명확하게 지정되고 프로그램적으로 검증 가능한 작업을 Luna로 라우팅하고 프롬프트의 안정적인 부분을 바이트 단위로 동일하게 유지하십시오. 출력 토큰은 입력의 5배로 청구되므로 제한하십시오. 캐시 적중률을 생산 지표로 측정하십시오. 자체 트래픽에서 첫 번째 토큰 시간을 측정할 때까지는 높은 노력을 동기 경로에서 제외하십시오. 그렇게 하면 계산이 맞지 않아 출시되지 않았던 작업들을 이번 주에 다시 비용을 산정할 가치가 있습니다.