GPT Realtime API 가격: 말하기가 듣기보다 4배 비싸다（실측）

OpenAI Realtime API 로 음성 대화를 하면 사용자가 말하는 동안은 분당 $0.0192，모델이 대답하는 동안은 분당 $0.0768 이 든다。말하기 비용은 듣기의 정확히 4 배이고，음성 세션 요금의 대부분은 이 비율 하나로 설명된다。숫자에 들어가기 전에 이름 정리부터。“GPT Live” 는 ChatGPT 의 소비자용 기능이고 API 가 없다。그 뒤에 있는 API 제품은 gpt-realtime-2.1 과 gpt-realtime-2.1-mini 이며，이 글에서 측정하는 대상이 바로 이것들이다。

TL;DR

• gpt-realtime-2.1 은 사용자 발화 100 ms 당 audio token 1 개，모델 발화 50 ms 당 1 개를 정확히 청구한다。듣기는 분당 $0.0192，말하기는 분당 $0.0768 이다。
• server VAD 상태에서 60 초 동안 침묵하면 input token 청구는 0 이었다。
• 자동 캐싱은 turn 30 시점에 input 의 93% 를 커버했다。history 항목 하나를 지웠더니 한 turn 동안 정가 input 이 3 배로 늘었다。
• 긴 음성 답변을 2 초 시점에 취소했더니 audio 4 초 분이 청구됐다。
• gpt-realtime-2.1-mini 는 청구 방식이 동일하고 audio 가격만 3.2 배 낮다。

여기 나오는 모든 숫자는 2026-07-19 에 두 모델을 상대로 계측한 WebSocket 세션에서 나왔고，모든 server event 를 로깅했다。두 모델 모두 Synthorai 게이트웨이의 /v1/realtime 엔드포인트에서 동작 중이고，이 세션들도 거기서 돌렸다。프로토콜과 청구 방식은 OpenAI 에 직접 붙는 것과 같다。테스트 하네스는 stdlib 만 쓰는 단일 Python 파일이고，아래 각 수치는 원본 response.done usage 레코드까지 추적된다。

Realtime API 에는 어떻게 연결하나

텍스트 API 와 달리 Realtime 은 HTTP 위의 request/response 가 아니다。세션마다 WebSocket 하나를 열고 그 위로 JSON event 를 주고받는다。클라이언트는 마이크 audio 를 흘려보내고，서버는 음성 audio 를 되돌려 보낸다。연결 하나가 대화 전체를 담당한다。

import websocket, json

ws = websocket.create_connection(
    "wss://synthorai.io/v1/realtime?model=gpt-realtime-2.1",
    header=["Authorization: Bearer sk-..."])

ws.send(json.dumps({"type": "session.update", "session": {
    "type": "realtime", "output_modalities": ["audio"],
    "audio": {"input": {"format": {"type": "audio/pcm", "rate": 24000}}}}}))

# stream mic audio as base64 chunks: {"type": "input_audio_buffer.append", ...}
# then either let server VAD end the turn, or commit and ask for an answer:
ws.send(json.dumps({"type": "response.create"}))
# read events until "response.done": billing usage rides on that event

청구와 관련해서 중요한 세션 생명주기는 다음과 같다。session.update 는 instructions，voice，tools，turn detection 을 설정한다（이것이 캐시 가능한 prefix 가 된다）。input_audio_buffer.append / commit 은 사용자 audio 를 추가한다。response.create 는 응답을 유발한다。그리고 모든 response.done 이 해당 응답의 전체 usage 내역을 담아 온다。방언 하나 짚자면，GA API 는 output_modalities 와 중첩된 audio.input/audio.output 설정을 쓴다。beta 시절의 response.modalities 필드는 unknown_parameter 로 거부된다。

GPT Realtime는 분당 요금이 얼마인가?

공식 변환 요율은 토큰 단위까지 정확하게 맞아떨어진다. 30.0초 클립은 입력 오디오 토큰 300개(100ms당 1개)로, 4.5초짜리 음성 답변은 출력 오디오 토큰 90개(50ms당 1개)로 청구됐다. 이걸 토큰당 가격표에 대입하면 분당 요금 계산이 나온다.

표에 드러나지 않는 비용이 두 가지 있다. 첫째, 음성 답변은 텍스트 출력도 청구한다. 전사 텍스트와 reasoning 토큰이 여기 포함된다(gpt-realtime-2.1은 실제로 추론을 수행하며, 매 실행마다 output_token_details.reasoning_tokens가 0이 아닌 값으로 돌아왔다). 우리가 테스트한 짧은 답변에서는 오디오 토큰 위에 약 24%가 더 붙었고, 이건 텍스트 요율인 $24/M로 청구됐다.

둘째, 음성 인식 부가 옵션은 별도의 청구 항목이다. 사용 기록은 {"type": "duration", "seconds": 30} 형태로 남는다. 토큰과 무관하게 분당 $0.017로 시간 기준 청구되며, 전사 텍스트는 모델 입력에 들어가지 않는다. 이 플래그 하나만 켜도 2.1에서는 입력 측 비용이 대략 두 배, mini에서는 거의 네 배로 늘어난다. 그러니 규정 준수나 제품 요구사항 때문에 텍스트가 실제로 필요한 경우에만 켜라.

무음, 중단, tool call에도 요금이 붙나?

무음은 요금이 붙지 않는다. server VAD를 켠 세션에 60초 동안 무음을 스트리밍한 뒤 질문을 던졌는데, 사용량은 오디오를 전혀 보내지 않은 대조 세션과 완전히 동일했다. VAD는 음성으로 감지한 오디오만 커밋하기 때문에, 대기 음악이나 고객이 서식을 읽는 소리, 그냥 열려 있는 유휴 회선은 입력 토큰이 0으로 청구된다. 다만 실제 배경 소음은 VAD를 오작동시킬 수 있다는 점은 주의해야 한다. 순수한 무음이 하한선일 뿐, 소음이 있는 통화까지 보장하지는 않는다.

중단은 사용자가 들은 지점이 아니라 생성이 진행된 지점까지 청구되며, 아직 생성되지 않은 나머지는 청구하지 않는다. 40까지 천천히 세는 음성을 요청한 뒤 2.0초를 듣고 취소했더니, 청구된 건 오디오 토큰 81개, 즉 4.0초였다. 2초의 초과분은 response.cancel이 도착하기 전까지 생성이 재생보다 앞서 나간 만큼이다. mini로 같은 실험을 했을 때는 6.3초가 청구됐는데, 더 작은 모델이 실시간보다 더 멀리 앞서 생성하기 때문이다. 실용적인 규칙은 이렇다. 클라이언트가 barge-in을 감지하는 즉시 response.cancel을 보내라. 취소가 도착할 때까지 계속 요금이 돌아간다.

tool call은 요금에 영향을 주지 않는다. function 정의 하나를 둔 세션에서 call을 내보내고, 주입된 결과를 받은 뒤 바로 다음 응답을 보니 입력의 99%가 캐시 요율로 청구됐다. function-call 항목과 그 출력은 다른 이력과 똑같이 캐시되며, tool 정의 자체는 두 번째 턴부터 캐시되는 정적 prefix에 들어간다.

캐싱은 어떻게 긴 세션 비용을 감당할 만하게 만드나

Realtime API 는 응답을 생성할 때마다 대화 전체를 입력으로 다시 읽는다. 그래서 세션이 길어질수록 턴당 입력이 선형으로 늘어난다. 이걸 감당할 만하게 만드는 게 자동 prefix 캐싱이다. 캐시된 오디오는 $32/M 이 아니라 $0.40/M 으로 재생되는데, 정가의 1/80 수준이다. 30 턴짜리 세션에서 캐시 비율은 꾸준히 올라 30 번째 턴에는 입력의 93% 에 도달했다.

캐시 분할 정보는 매 response.done 마다 보고된다.

"usage": {
  "input_tokens": 891,
  "input_token_details": {
    "text_tokens": 891, "audio_tokens": 0,
    "cached_tokens": 832,
    "cached_tokens_details": { "text_tokens": 832, "audio_tokens": 0 }
  }
}

공식 문서에 나와 있지 않지만 측정으로 확인한 스펙이 세 가지 있다. 캐싱은 prefix 가 대략 128 토큰일 때 걸린다(텍스트 API 의 문서상 최소치는 1,024 다). 캐시는 64 토큰 블록 단위로 진행된다. 그리고 정적 prefix 는 같은 key 라면 세션을 넘어 재사용된다. 마지막 항목은 60 분 세션 제한과 맞물려 중요하다. 새 세션의 첫 턴부터 instructions 는 이미 캐시 요율로 청구되므로, 세션을 교체할 때 정가를 내는 건 시스템 프롬프트가 아니라 대화 기록을 다시 읽는 부분뿐이다.

할인을 잃는 유일한 방법은 기록을 편집하는 것이고, 그 정확한 대가를 측정했다. 세션 도중 초기 항목 하나를 삭제하면 딱 한 턴 동안 캐시 비율이 무너지고, 그다음 턴에서 캐시가 다시 쌓였다.

측정으로 확인한 완화 요소가 하나 더 있다. 모델이 직접 말한 답변은 이후 입력에 오디오가 아니라 텍스트로 다시 들어간다. 8 턴짜리 음성 대화에서 입력 오디오는 매 턴마다 사용자 클립 크기만큼만 늘었고, assistant 쪽은 $4/M 요율의 transcript 토큰으로 다시 나타났다. 누적항에서 비싼 부분은 사용자 오디오뿐이다.

여기서 나오는 실전 지침은 짧다. 기록은 append-only 로 유지하고, instructions 와 tool 정의는 세션 전체에서(그리고 세션 간에도) 바이트 단위로 동일하게 유지하라. 동적인 내용은 prefix 가 아니라 가장 최근 user 메시지에 넣어라. 그리고 기록을 잘라내야 한다면 매 턴 조금씩 말고, 드물게 큰 폭으로 잘라내라. 여러 프로바이더에 걸친 일반적인 동작 원리는 prompt 캐싱 가이드와 캐시 최소치 측정 연구를 참고하라.

gpt-realtime-2.1 과 mini, 뭘 골라야 하나?

과금 방식은 두 모델이 완전히 같다. 변환율도, 64-token 캐시 양자화도, 곡선 모양도 동일하다. 차이가 나는 건 가격과 동작이다.

눈여겨볼 지점이 두 가지 있다. 캐시 재생 구간에서는 가격 차이가 거의 사라진다($0.40 대 $0.30). 그래서 캐시 적중률이 높은 긴 세션에서는 mini 의 이점이 조금 줄어들지만, 총비용은 여전히 fresh token 이 좌우한다. 그리고 mini 의 속도가 인터럽트에서는 오히려 불리하게 작용한다. 재생보다 더 앞서서 생성하기 때문에 barge-in 마다 버려지는 생성 오디오가 약 두 배다. 하지만 달러로 따지면 우리가 측정한 모든 시나리오에서 mini 가 이긴다. 3.2배의 가격 차이가 두 효과를 모두 흡수한다.

짧은 명령 위주의 어시스턴트, IVR, 고동시성 지원이라면 기본값으로 mini 를 골라라. 세션에 복잡한 tool 오케스트레이션이나 다단계 추론이 필요하면 2.1 을 골라라. OpenAI 는 2.1 을 지시 따르기(instruction following)의 플래그십으로 내세우는데, 우리 비용 측정 도구는 이 부분을 일부러 평가하지 않는다.

흔한 음성 시나리오의 실제 비용은?

인터럽트가 잦은 시나리오라면 상호작용당 계산에 barge-in 초과분을 더하라. 인터럽트마다 사용자가 들은 오디오에 생성 리드타임 몇 초 분량이 비용으로 붙는다.

FAQ

GPT Live 와 GPT Realtime API 는 같은 건가요？

아닙니다. GPT Live 는 ChatGPT 앱에 들어 있는 음성 기능이라 별도의 API 나 가격 페이지가 없습니다. 같은 경험을 코드로 구현하려는 개발자는 Realtime API 모델인 gpt-realtime-2.1 과 gpt-realtime-2.1-mini 를 쓰며, 이 글에서 측정한 가격이 바로 이 모델들의 가격입니다.

Realtime 세션은 얼마나 오래 유지할 수 있나요？

최대 60 분이 한계이고, 한 번 닫힌 세션은 다시 이어갈 수 없습니다. 텍스트 히스토리는 새 세션에 다시 주입할 수 있지만（정가로 한 번 과금되며 static prompt 는 캐시된 채 유지됩니다）， 어시스턴트 오디오는 다시 재생할 수 없습니다. 그래서 장시간 돌아가는 음성 제품이라면 60 분에 도달하기 전에 세션 로테이션 계획을 세워야 합니다.

턴 사이에 idle timeout 이 있나요？

문서화된 idle timeout 은 없고, 우리 측정에서는 server VAD 상태의 침묵 구간이 token 을 0 으로 과금합니다. 따라서 상호작용 사이에 라인을 열어 두어도 연결 자체를 유지하는 것 외에는 비용이 들지 않습니다. 사용 빈도가 낮은 제품에서는 상호작용마다 재연결하는 것보다 하나의 긴 세션을 유지하는 편이 더 싸고 빠릅니다. 세션 셋업이 약 2.5 초로 측정됐기 때문입니다.

API 는 어떤 오디오 포맷을 기대하나요？

입력과 출력 모두 24 kHz mono 의 PCM16 이 기본값이며, session.update 의 audio.input.format 과 audio.output.format 으로 설정합니다. 과금은 포맷과 무관합니다. 오디오 token 은 재생 시간에만 좌우되며, 입력은 100 ms 당 1 token, 출력은 50 ms 당 1 token 입니다.

60 분 한계를 안고 운영하기 위한 엔지니어링 패턴（로테이션， 히스토리 인계， 재연결 후 살아남는 것）은 그 자체로 별개의 주제이고, 이 글의 숫자들이 그 계산의 입력값이 됩니다. 텍스트 API 에서 과금 token 이 계열별로 어떻게 분해되는지는 함께 읽을 만한 token usage anatomy 글을 참고하세요.

← 블로그로 돌아가기