요청이 너무 김: 400 대 413, 컨텍스트 윈도와 max_tokens

채팅이 40턴 동안 잘 돌아가다가 갑자기 모든 요청이 실패하기 시작했습니다. 짧게 말하면, "request too long"은 서로 다른 두 가지 한도를 숨기고 있습니다. 413은 요청이 바이트 기준으로 너무 커서 어떤 모델도 보기 전에 거부되었다는 뜻입니다. 오류가 토큰 길이를 문제 삼는다면(보통 400 계열의 잘못된 요청), 입력과 요청한 답변이 컨텍스트 윈도에 들어가지 않는다는 뜻입니다. 어느 쪽인지 확인하려면 error.message를 읽어 보세요. 해결책은 측정한 다음 줄이는 것입니다.

이 가이드는 두 가지를 구분하는 방법, 보내기 전에 계산을 확인하는 방법, 요청을 줄이는 네 가지 방법을 보여 줍니다. 이 용어가 처음이라면 컨텍스트 윈도란 무엇인가에서 쉬운 말로 설명합니다.

두 가지 한도, 두 가지 오류#

413은 우체국이 너무 큰 소포를 거부하는 것이고, 토큰 오류는 모델이 편지가 자신의 읽기 창에 들어가지 않는다고 말하는 것입니다. 실패하는 지점이 다르고 해결책도 다릅니다.

Anthropic의 API 오류 페이지(2026년 10월 29일 확인)는 413 request_too_large를 최대 바이트 수를 초과한 요청으로 설명합니다. Messages API는 128 MB, Batch API는 256 MB, Files API는 500 MB입니다. 400 invalid_request_error는 요청의 형식이나 내용 문제를 다룹니다. 이는 Anthropic의 한도입니다. 해당 페이지에는 토큰 수 메시지가 나와 있지 않고 OpenAI의 오류 코드 가이드에도 없으므로, 포럼 스레드에서 본 정확한 문구에 로직을 의존하지 마세요.

실제로는 텍스트만 쓰는 채팅은 바이트보다 토큰이 먼저 늘어나는 경우가 많습니다. 바이트는 base64 이미지나 문서 전체를 첨부할 때 문제가 됩니다. 토큰은 히스토리가 늘어날 때 문제가 되며, 이것이 흔한 경우입니다.

오류 본문은 최상위 type: error, 자체 type와 message를 가진 error 객체, 그리고 요청 id로 이루어진 JSON입니다. error.message를 읽고 요청 id를 보관하세요. 공식 SDK를 쓴다면 문자열을 비교하는 대신 타입이 지정된 예외를 잡으세요.

보내기 전에 계산을 확인하세요#

가장 많은 시간을 아껴 주는 습관은 오류를 기다리지 않는 것입니다. 매 호출 전에 세 가지를 더하고 윈도와 비교하세요.

1. 메시지의 토큰(시스템 프롬프트, 히스토리, 새 질문).
2. 요청하는 max_tokens.
3. 모델의 컨텍스트 윈도.

입력과 요청한 답변의 합을 윈도 안에 유지하세요. CheapTokens의 윈도는 GLM-5.3-Flash가 390K, DeepSeek-V4-Flash가 380K, MiniMax-M2.7이 180K이며, 답변은 GLM과 MiniMax에서 최대 8,192 토큰, DeepSeek-V4-Flash에서 최대 32,768 토큰입니다. 최신 목록은 가격 및 모델 페이지에서 확인하세요.

에이전트가 100K 토큰 히스토리를 보내고 4,000 토큰의 답변을 요청한다고 해 봅시다. 100,000 + 4,000 = 104,000 토큰으로 세 모델 어디서든 여유가 있습니다. 이제 같은 에이전트가 50단계를 더 거친 뒤에는 400K입니다. max_tokens를 무엇으로 설정하든 목록의 어떤 윈도에도 들어가지 않습니다. 바로 그 순간 오류가 나타나며, 매 턴마다 히스토리가 조금씩 늘었기 때문에 갑작스러워 보일 뿐입니다.

가드용으로는 대략적인 카운터로 충분합니다. 영어 텍스트는 토큰당 평균 약 4자이고, 코드와 비영어 텍스트는 문자당 토큰을 더 쓰므로 여유를 두세요.

import os
from openai import OpenAI

client = OpenAI(
    base_url='https://api.cheaptokens.dev/v1',
    api_key=os.environ['CHEAPTOKENS_API_KEY'],
)

CONTEXT = 380_000      # DeepSeek-V4-Flash window
MAX_OUT = 4_000        # the answer you ask for
MARGIN = 0.85          # rough counter, keep 15% spare

def rough_tokens(messages):
    return sum(len(m['content']) // 4 + 4 for m in messages)

def trim(messages):
    budget = int(CONTEXT * MARGIN) - MAX_OUT
    system, rest = messages[:1], messages[1:]
    while rest and rough_tokens(system + rest) > budget:
        rest.pop(0)          # drop the oldest turn first
    return system + rest

history = [{'role': 'system', 'content': '...'}, {'role': 'user', 'content': '...'}]  # system first

reply = client.chat.completions.create(
    model='deepseek-ai/DeepSeek-V4-Flash-0731',
    messages=trim(history),
    max_tokens=MAX_OUT,
)
print(reply.usage.prompt_tokens, reply.choices[0].finish_reason)

마지막 줄이 보정 지점입니다. usage.prompt_tokens는 API가 실제로 센 값입니다. 몇 번 rough_tokens(...)와 비교해 보고 자신의 텍스트에 맞게 제수와 여유를 조정하세요.

요청을 줄이는 네 가지 방법#

이 순서대로 가장 저렴하게 통하는 해결책을 고르세요.

1. max_tokens를 낮추기. 필요한 답변만 요청하세요. 입력과 max_tokens의 합을 윈도 안에 유지해야 하며, 각 모델에는 답변 상한이 따로 있습니다(위에서 8,192 또는 32,768 토큰). max_tokens를 답변에 필요한 것보다 높게, 또는 모델의 답변 상한보다 높게 설정하지 마세요. 설정한 한도에서 답변이 멈추면 finish_reason: length로 끝나며, 이에는 별도의 해결책이 있습니다.

2. 히스토리 다듬기. 가장 오래된 턴을 버리고 시스템 프롬프트와 최근 몇 번의 주고받음은 유지하세요. 위의 trim 함수가 바로 이 일을 합니다. 에이전트라면 부피도 줄이세요. 5,000줄짜리 도구 출력은 에이전트가 사용한 뒤에는 전체를 유지할 필요가 거의 없습니다.

3. 버리는 대신 요약하기. 오래된 턴이 중요할 때는 모델에게 한 번 요약을 요청해 짧은 메모로 압축한 뒤, 오래된 메시지를 그 메모로 교체하세요. 호출 한 번을 더 지불하고 스레드는 유지합니다.

4. 더 큰 윈도로 전환하기. MiniMax-M2.7(180K)에서 GLM-5.3-Flash(390K)나 DeepSeek-V4-Flash(380K)로 옮기는 것은 모델 id 한 줄을 바꾸는 일입니다. 긴 답변도 필요하다면 DeepSeek-V4-Flash는 최대 32,768 출력 토큰을 허용하며, 세 모델 모두 하나의 잔액을 공유하므로 전환에 설정 비용이 들지 않습니다.

긴 히스토리의 비용#

다듬기는 오류만의 문제가 아닙니다. 에이전트의 각 단계는 히스토리 전체를 다시 보내므로, 비대해진 히스토리는 청구서에서 비싼 부분이기도 합니다. 매 단계가 약 100K 토큰을 보내고 약 1,500 토큰을 받는 30단계 작업을 생각해 봅시다.

표는 같은 작업을 각 모델에서 실시간 요율로 계산한 것입니다. 히스토리를 4분의 1로 줄이면 입력 쪽은 약 4분의 3이 줄어듭니다. 자신의 에이전트가 어디서 토큰을 쓰는지 보려면 Python에서 요청별 사용량 추적을 참고하세요. 원리는 에이전트가 토큰을 그렇게 많이 쓰는 이유에서 20단계 예시로 설명합니다.

DeepSeek-V4-Flash는 현재 100만 입력 토큰당 $0.015, 100만 출력 토큰당 $0.10이며, 시간대와 관계없이 하나의 가격입니다. 자신의 숫자로 시험해 보세요.

그래도 실패한다면#

느린 링크에서의 긴 요청에는 별도의 실패가 있습니다. Anthropic은 큰 max_tokens를 가진 긴 요청에는 스트리밍이나 Batch API를 권장합니다. 네트워크가 유휴 연결을 끊을 수 있고, 해당 SDK는 비스트리밍 요청이 10분 안에 끝나기를 기대하기 때문입니다. 오류가 400이 아니라 타임아웃이나 끊긴 연결이라면 연결 오류를 참고하고 stream=True를 설정하세요.

메시지가 401이나 404라면 문제는 대신 키, base URL 또는 모델 id입니다. API 401 또는 404 오류를 참고하세요. 정확한 base URL, 모델 id, 예시는 CheapTokens 문서를 여세요.