오류 참조

오류 참조 (Error Reference)

LiteLLM AI 게이트웨이를 통한 모든 실패한 요청은 OpenAI 호환 JSON 오류 본문과 HTTP 상태 코드를 반환해요. 이 페이지는 읽는 방법에 대한 참조예요: 페이로드에 무엇이 있는지, 게이트웨이 대 업스트림 제공자 중 어떤 쪽에서 오류가 오는지, 각 상태 코드와 오류 타입이 무엇을 의미하는지, 폴백 체인이 타깃을 소진하면 게이트웨이가 무엇을 반환하는지.

출처: 문서

본문

빠른 provider-대-gateway 규칙만 필요하면 Diagnosing Errors를 보세요. Python SDK 예외 클래스와 공급자별 매핑 테이블은 Exception Mapping을 보세요.

오류 페이로드 (The error payload)

LLM API 라우트(/chat/completions, /completions, /embeddings, /responses, 및 기타 OpenAI 형태 엔드포인트)에 대한 실패한 요청은 단일 최상위 error 객체를 반환해요:

{
  "error": {
    "message": "litellm.RateLimitError: RateLimitError: OpenAIException - Rate limit reached for gpt-5.6-luna in organization org-abc on requests per min (RPM): Limit 3, Used 3.",
    "type": "throttling_error",
    "param": null,
    "code": "429"
  }
}

필드	타입	설명
error.message	string	사람이 읽을 수 있는 설명. 공급자 실패의 경우 LiteLLM 예외 이름과 공급자 예외 이름을 모두 담는 전체 LiteLLM 예외 문자열. 오류를 귀속시키기 위해 파싱하는 필드.
error.type	string 또는 null	대략적 범주. 게이트웨이 발생 오류는 budget_exceeded나 key_model_access_denied 같은 LiteLLM 특화 값을 담고, 공급자 발생 오류는 throttling_error나 invalid_request_error 같은 OpenAI 스타일 값을 담으며 자주 null임. 힌트로 취급하고 기본 신호로는 삼지 말 것.
error.param	string 또는 null	게이트웨이가 식별할 수 있을 때 문제가 되는 요청 파라미터. 필수 필드 누락 시 messages, 모델 액세스 거부 시 model, 가상 키 문제 시 key.
error.code	string	거의 항상 HTTP 상태 코드 문자열 ("429"이지 429가 아님). 일부 공급자 오류에서는 대신 공급자 자체 오류 코드 문자열, 예: "invalid_api_key" 또는 "context_length_exceeded".
error.provider_specific_fields	object	선택. 공급자가 보존할 가치가 있는 구조화된 세부 정보를 반환했을 때만 존재. 가장 주목할 것은 Azure OpenAI의 innererror 콘텐츠 필터 분석. Exception Mapping 참고.

위와 다른 세 가지 형태를 알아두는 게 좋아요:

• 게이트웨이 내부의 처리되지 않은 예외는 내부 세부 정보가 호출자에게 절대 유출되지 않도록 param이나 code가 없는 의도적으로 최소화된 본문을 반환해요:

  {"error": {"message": "Internal server error", "type": "internal_server_error"}}
  

• 존재하지 않는 라우트에 대한 요청은 LiteLLM이 보기 전에 웹 프레임워크가 거부하고, 오류 봉투가 아니라 프레임워크 자체 형태를 반환해요. 이것을 받으면 보통 게이트웨이 결함이 아니라 잘못된 경로나 base URL을 의미해요:

  {"detail": "Not Found"}
  

• /v1/management/* 엔드포인트는 별도의 API 표면이며, 오류 봉투 대신 application/problem+json 콘텐츠 타입과 type, title, status, detail 멤버를 가진 RFC 9457 Problem Details를 반환해요. 여기 문서화된 LLM API 라우트는 영향을 받지 않아요.

반면 잘못된 형식의 본문은 표준 봉투로 정규화돼요. 파싱할 수 없는 JSON은 error.param이 request_body로 설정된 400을 반환하고, 잘 형성되었지만 잘못된 타입 필드가 있는 본문은 type이 invalid_request_error로 설정된 400을 반환해요.

note

error.code는 정수가 아니라 문자열이에요. 이는 OpenAI Python 라이브러리의 error 객체와 일치하므로, OpenAI SDK에 대해 작성된 클라이언트는 변경 없이 LiteLLM 오류를 역직렬화해요. "429"와 비교하거나 HTTP 상태 줄을 읽으세요.

응답 헤더 (Response headers)

실패한 응답의 헤더는 JSON 본문이 담지 않는 진단 컨텍스트를 담아요.

헤더	언제 존재	설명
x-litellm-call-id	인증 성공 후의 모든 실패	요청의 상관관계 id. 지원 티켓에 인용하고 로그에서 검색할 값. HTTP 응답을 게이트웨이의 로그 줄, 지출 로그 행, OpenTelemetry trace에 연결. call id가 할당되기 전에 거부되는 인증 실패에는 없음.
retry-after	게이트웨이 요율 제한 및 라우터 쿨다운	기다릴 초. 존재가 무엇을 의미하는지 아래 참고 참조.
rate_limit_type	게이트웨이 요율 제한	초과된 차원: requests, tokens, 또는 concurrent_requests
reset_at	게이트웨이 요율 제한	초과된 창이 리셋되는 UTC 타임스탬프
x-litellm-key-rpm-limit, x-litellm-key-max-budget, x-litellm-key-spend	인증 후 대부분의 실패	호출 키의 구성된 천장과 현재 지출. 키 자체가 제약인지 확인할 수 있음.
x-litellm-timeout	배포에 도달한 요청에서의 실패	호출에 적용된 타임아웃(초).

세 가지 헤더 계열은 성공적인 응답에만 나타나므로 실패 처리를 그 주변에 구축하지 마세요: llm_provider-*(업스트림 자체 응답 헤더, 접두사와 함께 그대로 전달), x-ratelimit-*(업스트림의 요율 제한 카운터), x-litellm-attempted-retries / x-litellm-attempted-fallbacks(성공에 걸린 재시도와 폴백 홉 수).

tip

retry-after는 강력한 구분 신호예요. 게이트웨이는 자체 요율 제한과 쿨다운에 이것을 설정하고, 제공자의 retry-after를 오류 응답에 전달하지 않아요. 그래서 retry-after가 있는 429는 게이트웨이의 한도이고, 없는 429는 제공자의 것이에요.

게이트웨이인가 제공자인가? (Is it the gateway or the provider?)

게이트웨이는 모든 업스트림 실패를 감싸고 두 계층을 error.message에 이름 붙여요. 바깥에서 안으로 읽으세요:

litellm.RateLimitError: RateLimitError: OpenAIException - Rate limit reached ...
^^^^^^^^^^^^^^^^^^^^^^                  ^^^^^^^^^^^^^^^
LiteLLM's normalized class              the provider that actually failed

<Provider>Exception 토큰의 존재는 요청이 게이트웨이를 떠나 제공자에 도달했고 제공자가 거부했음을 의미해요. 없음은 게이트웨이가 제공자를 호출하기 전에 또는 대신에 요청 자체를 거부했음을 의미해요.

응답의 신호	출처
message가 OpenAIException, AnthropicException, AzureException, BedrockException, VertexAIException 또는 다른 어떤 <Provider>Exception을 포함	업스트림 공급자
message에 공급자 이름이 없고 type이 budget_exceeded, expired_key, token_not_found_in_db, key_model_access_denied 같은 LiteLLM 값	LiteLLM 게이트웨이
message가 No deployments available for selected model 또는 There are no healthy deployments for this model로 시작	LiteLLM 게이트웨이 (라우팅)
retry-after, rate_limit_type, reset_at 헤더가 있는 429	LiteLLM 게이트웨이 (요율 제한)
그런 헤더가 없는 429	업스트림 공급자

작동 예시, 게이트웨이 출처. 가상 키가 누적 지출 아래로 캡되어 요청이 어떤 공급자에도 접촉되기 전에 거부돼요:

{
  "error": {
    "message": "Budget has been exceeded! Key=analytics-team (sk-...W8TA) Current cost: 0.06, Max budget: 0.05",
    "type": "budget_exceeded",
    "param": null,
    "code": "429"
  }
}

작동 예시, 제공자 출처. 같은 429 상태지만, 메시지가 제공자를 명명하고 페이로드에 게이트웨이의 요율 제한 헤더가 전혀 없어요:

{
  "error": {
    "message": "litellm.RateLimitError: RateLimitError: OpenAIException - Rate limit reached for gpt-5.6-luna in organization org-abc on requests per min (RPM): Limit 3, Used 3.",
    "type": "throttling_error",
    "param": null,
    "code": "429"
  }
}

HTTP 상태 코드 (HTTP status codes)

게이트웨이는 모든 것을 500으로 접는 대신 기저 실패의 상태 코드를 반환해요. 제공자 실패의 경우 이는 제공자 자체 상태이고, 게이트웨이 실패의 경우 게이트웨이가 선택한 상태예요.

상태	일반적 출처	의미	재시도?
400	둘 다	잘못된 형식의 요청, 알 수 없는 모델 이름, 컨텍스트 창 초과, 콘텐츠 정책 위반. 게이트웨이 측 400은 error.param에서 누락된 파라미터를 명명.	아니오, 요청 수정
401	둘 다	게이트웨이: 가상 키가 알 수 없거나 만료됨. 공급자: 배포에 구성된 자격 증명이 거부됨	아니오
403	게이트웨이	키, 팀, 사용자, 조직이 요청한 모델/도구/벡터 스토어를 사용할 수 없음	아니오
404	둘 다	요청된 모델이나 라우트가 존재하지 않음	아니오
408	둘 다	호출이 적용 중인 타임아웃을 초과. 메시지가 구성된 타임아웃과 경과 시간을 모두 보고	예, 백오프 포함
422	공급자	공급자가 요청의 형태는 받아들였지만 내용을 처리할 수 없음	아니오
429	둘 다	요율 제한 또는 예산 초과. Which 429 is this? 참고	예, retry-after 존중
499	클라이언트	클라이언트가 연결을 끊고 업스트림 호출이 취소됨	N/A
500	둘 다	게이트웨이: 처리되지 않은 내부 오류. 공급자: 네트워크 실패로 제공자에 도달하지 못한 것을 포함하는 공급자 측 오류(이는 InternalServerError ... Connection error로 표면화)	예, 백오프 포함
503	공급자	공급자가 스스로 사용 불가 또는 과부하를 보고	예, 백오프 포함

500과 503에 대한 참고. 제공자에 도달하지 못하는 연결(DNS 실패, 연결 거부, 잘못된 api_base)은 502나 503이 아니라 Connection error.를 메시지에 담은 500으로 보고돼요. 503은 제공자가 응답하고 사용 불가라고 말한 것을 의미해요.

게이트웨이 오류 타입 (Gateway error types)

이 error.type 값들은 게이트웨이 자체가 생성해요. 이 중 하나를 보는 것은 실패에 제공자가 관여하지 않았음을 의미해요.

error.type	상태	원인	무엇을 할까
token_not_found_in_db	401	가상 키가 존재하지 않음	/key/generate로 키 발급
expired_key	401	키의 expires 타임스탬프가 지남	새 키 발급, 또는 /key/update로 연장
auth_error	401	일반 인증 실패 (JWT 검증 실패 포함)	자격 증명 확인, JWT 인증은 issuer 구성 확인
auth_provider_unavailable	503	요청을 검증하는 데 필요한 ID 제공자(예: JWKS 엔드포인트)에 도달 불가	ID 제공자에 대한 네트워크 연결성 확인
key_model_access_denied	403	키의 models 목록에 요청한 모델이 없음	모델을 키에 추가, 또는 /v1/models 호출로 키가 무엇을 쓸 수 있는지 확인
team_model_access_denied, user_model_access_denied, org_model_access_denied, project_model_access_denied	403	같은 제한이 팀/사용자/조직/프로젝트 수준에 적용	타입이 명명한 객체에 액세스 부여
tool_access_denied	403	요청한 도구가 키/팀의 허용 도구 목록에 없음	도구를 허용 목록에 추가
key_vector_store_access_denied, team_vector_store_access_denied, org_vector_store_access_denied	403	호출자가 요청한 벡터 스토어를 사용할 수 없음	타입이 명명한 객체에 액세스 부여
team_member_permission_error	401	호출자가 이 관리 작업에 대한 팀 멤버 권한이 없음	팀 관리자에게 수행 또는 권한 부여 요청
budget_exceeded	429	키/팀/사용자/세션별 지출 캡 도달. 메시지가 현재 비용과 최대 예산 보고	예산 올리기, 또는 예산 창 리셋 대기
throttling_error	429	RPM, TPM, max-parallel-requests 천장 초과. 공급자 429에도 사용되므로 헤더로 구분할 것	retry-after 사용해 백오프
invalid_request_error	400	필수 파라미터 누락 또는 잘못된 형식. error.param이 명명	요청 본문 수정
bad_request_error	400	일반 게이트웨이 측 요청 거부	메시지 읽기
not_found_error	404	참조된 객체가 존재하지 않음	id 확인
no_db_connection	503	엔드포인트가 데이터베이스를 필요로 하고 게이트웨이가 도달할 수 없음	DATABASE_URL과 DB 상태 확인
internal_server_error	500	처리되지 않은 게이트웨이 예외	일치하는 x-litellm-call-id에 대해 게이트웨이 로그 확인

라우팅 실패는 현재 고유한 error.type을 설정하지 않으므로 메시지 접두사로 식별하세요:

메시지 접두사	상태	원인
No deployments available for selected model	429	반복 실패 후 모델 그룹의 모든 배포가 쿨다운. 메시지가 쿨다운 중인 배포 id와 남은 초를 나열
There are no healthy deployments for this model	400	모델 그룹에 요청을 서빙할 수 있는 배포가 없음
Not allowed to access model due to tags configuration	401	태그 기반 라우팅이 이 호출자에 대해 모든 배포를 제외
No deployments available - crossed budget	429	제공자 예산 라우팅이 모든 후보 배포의 예산을 소진

이것은 어떤 429인가? (Which 429 is this?)

429는 게이트웨이와 공급자가 모두 많이 사용하는 유일한 상태라서 별도 확인이 필요해요. 이 순서로 응답을 살펴보세요.

• 게이트웨이 요율 제한은 retry-after, rate_limit_type, reset_at을 설정하고 메시지가 맞은 한도를 명명해요:

  {
    "error": {
      "message": "Rate limit exceeded for api_key: b2f139a7... Limit type: requests. Current limit: 1, Remaining: 0. Limit resets at: 2026-08-27 00:15:18 UTC",
      "type": "throttling_error",
      "param": null,
      "code": "429"
    }
  }
  

• 게이트웨이 예산 캡은 type을 budget_exceeded로 설정하고 캡에 대한 지출을 보고해요. 라우팅 쿨다운은 retry-after를 설정하고 No deployments available for selected model로 시작해요.
• 메시지에 <Provider>Exception이 있는 그 밖의 것은 제공자 자체 스로틀이며, 게이트웨이는 반환하기 전에 이미 구성된 재시도와 폴백을 소진했어요.

Python SDK에서 이 분류는 문자열을 파싱하지 않고 사용 가능해요. 모든 litellm.RateLimitError는 RateLimitErrorCategory에서 가져온 category 속성과 RateLimitType에서 가져온 rate_limit_type 속성을 담아요:

import litellm
from litellm.exceptions import RateLimitErrorCategory

try:
    response = litellm.completion(model="gpt-5.6-luna", messages=[{"role": "user", "content": "hi"}])
except litellm.RateLimitError as e:
    if e.category == RateLimitErrorCategory.LITELLM_RATE_LIMIT:
        print(f"LiteLLM's own limiter: {e.rate_limit_type}")
    elif e.category == RateLimitErrorCategory.VENDOR_RATE_LIMIT:
        print("the upstream provider throttled us")

category는 litellm_rate_limit, vendor_rate_limit, litellm_batch_rate_limit, vendor_batch_rate_limit 중 하나예요. rate_limit_type는 requests, tokens, concurrent_requests, budget, max_iterations 중 하나예요. 둘 다 StandardLoggingPayload.error_information에도 기록되므로, 커스텀 콜백과 지표 파이프라인이 자유 텍스트를 파싱하지 않고 429를 원인별로 나눌 수 있어요.

재시도와 폴백 (Retries and fallbacks)

게이트웨이가 오류를 반환하기 전에 모델 그룹에 대해 구성된 재시도와 폴백 정책을 거쳐요. 재시도는 같은 모델 그룹을 다시 시도하고, 폴백은 다른 그룹으로 이동해요. 구성은 Fallbacks (Provider Failover) 참고.

전체 체인이 실패하면 게이트웨이는 원래 예외를 다시 발생시켜요. 받는 상태 코드, error.type, error.code는 마지막 폴백이 아니라 첫 번째 모델 그룹 실패의 것이에요. 프라이머리가 500으로 실패하고 폴백이 503으로 실패한 그룹은 500을 반환해요.

그런 다음 메시지가 폴백 시도 이력으로 확장돼요. 아래 예시를 읽으면: 프라이머리 mock-500이 InternalServerError로 실패했고, Available Model Group Fallbacks가 시도된 체인을 보여주며, Error doing the fallback이 마지막 홉이 반환한 것을 보고해요.

{
  "error": {
    "message": "litellm.InternalServerError: InternalServerError: OpenAIException - The server had an error while processing your request. Sorry about that!. Received Model Group=mock-500\nAvailable Model Group Fallbacks=['mock-503']\nError doing the fallback: litellm.ServiceUnavailableError: ServiceUnavailableError: OpenAIException - The engine is currently overloaded, please try again later.No fallback model group found for original model_group=mock-503. Fallbacks=[{'mock-500': ['mock-503']}]",
    "type": null,
    "param": null,
    "code": "500"
  }
}

이 설계의 세 가지 세부 사항:

• No fallback model group found for original model_group=<name>은 그 그룹에 폴백이 구성되지 않았으므로 프라이머리 오류가 그대로 반환됐음을 의미해요. 그 자체는 실패가 아니고, 게이트웨이가 왜 장애 조치하지 않았는지 설명하는 것이에요.
• 폴백 세부 정보는 기본적으로 켜져 있는 litellm.expose_router_debug_in_errors가 추가해요. False로 설정하면 구성된 폴백 타깃 이름을 포함한 라우팅 세부 정보가 호출자에게 반환되는 메시지에서 빠져요. 재시도 수는 별도로 추가되며 LiteLLM Retried: 2 times, LiteLLM Max Retries: 2로 읽어요.
• 성공한 폴백은 응답 본문에 보이지 않아요. 정상 200이에요. x-litellm-attempted-fallbacks 헤더에서 감지하고, 실제로 요청을 서빙한 그룹은 x-litellm-model-group에서 읽어요. 그 헤더들은 성공에서만 존재하므로 실패한 체인은 error.message 또는 게이트웨이 로그에서 재구성해야 해요.

스트리밍 오류 (Streaming errors)

스트리밍 요청은 실패가 언제 발생하는지에 따라 두 가지 방식 중 하나로 실패하며, 클라이언트는 둘 다 처리해야 해요.

• 첫 번째 청크 전에 실패하는 것은 비스트리밍 실패와 구별할 수 없어요. 응답은 평소 JSON 오류 본문과 함께 HTTP 오류 상태이고, 스트림은 열리지 않아요:

  HTTP/1.1 500 Internal Server Error
  content-type: application/json
  {"error":{"message":"litellm.InternalServerError: InternalServerError: OpenAIException - ...","type":null,"param":null,"code":"500"}}
  

• 스트리밍이 시작된 후 실패는 이미 200인 상태 코드를 바꿀 수 없어요. 게이트웨이는 같은 error 객체를 담은 마지막 SSE 이벤트로 오류를 출력해요:

  HTTP/1.1 200 OK
  content-type: text/event-stream
  data: {"id":"chatcmpl-...","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"role":"assistant","content":"Hel"}}]}
  data: {"id":"chatcmpl-...","object":"chat.completion.chunk","choices":[{"index":0,"delta":{"content":"lo"}}]}
  data: {"error": {"message": "litellm.APIConnectionError: APIConnectionError: OpenAIException - The server had an error while processing your request. Sorry about that!", "type": null, "param": null, "code": "500"}}
  

• 청크로 취급하기 전에 모든 SSE 페이로드에서 error 키를 확인하세요. HTTP 상태만 검사하는 클라이언트는 중간 스트림 실패를 잘린 completion을 가진 성공으로 기록해요.

예외 참조 (Exception reference)

Python SDK는 해당 OpenAI 예외 클래스에서 상속하는 타입화된 예외를 발생시키므로 기존 OpenAI 오류 처리가 변경 없이 동작해요. 전체 테이블(각 공급자가 어떤 예외를 발생시킬 수 있는지 포함)은 Exception Mapping에 있어요. 요약:

상태	예외	참고
400	BadRequestError
400	ContextWindowExceededError	BadRequestError의 서브클래스. 컨텍스트 창 폴백 활성화
400	ContentPolicyViolationError	BadRequestError의 서브클래스. 콘텐츠 정책 폴백 활성화
400	UnsupportedParamsError	BadRequestError의 서브클래스
401	AuthenticationError
403	PermissionDeniedError
404	NotFoundError	알 수 없는 모델 이름에 대해 발생
408	Timeout
422	UnprocessableEntityError
429	RateLimitError	category와 rate_limit_type 전달
429	BudgetExceededError	프록시 예산 캡. current_cost와 max_budget 전달
500	APIConnectionError	매핑되지 않은 오류의 기본 경우
500	APIError
503	ServiceUnavailableError
>=500	InternalServerError	매핑되지 않은 500급 제공자 응답

모든 LiteLLM 예외는 status_code, message, llm_provider를, 공급자가 구조화된 세부 정보를 제공하는 곳에는 provider_specific_fields를 담아요.

이러한 오류 재현하기 (Reproducing these errors)

오류 처리를 테스트하기 위해 실패하는 제공자는 필요 없어요. 배포를 원하는 상태를 반환하는 로컬 HTTP 서버로 지정한 다음 게이트웨이를 통해 호출하세요.

config.yaml:

model_list:
  - model_name: always-429
    litellm_params:
      model: openai/fail-429
      api_base: http://127.0.0.1:8199/v1
      api_key: sk-mock
  - model_name: unreachable
    litellm_params:
      model: openai/anything
      api_base: http://127.0.0.1:9/v1
      api_key: sk-mock

위 unreachable 배포는 목 서버가 전혀 필요 없어요. 포트 9가 연결을 거부하므로 500 Connection error. 경로를 재현해요. 게이트웨이 측 오류의 경우, 발동시키려는 제약이 있는 키를 생성하고 그것을 통해 호출하세요:

# 403 key_model_access_denied
curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer ***" \
  -H 'Content-Type: application/json' \
  -d '{"key_alias": "restricted", "models": ["gpt-5.6-luna"]}'

# 429 throttling_error, on the second call within the same minute
curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer ***" \
  -H 'Content-Type: application/json' \
  -d '{"key_alias": "capped", "rpm_limit": 1}'

# 429 budget_exceeded, once accrued spend passes the cap
curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer ***" \
  -H 'Content-Type: application/json' \
  -d '{"key_alias": "tiny-budget", "max_budget": 0.05}'

폴백 소진을 연습하려면 항상 실패하는 모델 그룹 하나에서 다른 그룹으로 폴백을 구성하고 프라이머리를 호출하세요. Fallbacks (Provider Failover) 참고.

문제 보고 (Reporting a problem)

실패한 응답의 x-litellm-call-id를 포함하세요. 이는 게이트웨이 로그, 지출 로그 행, 요청의 OpenTelemetry trace, Admin UI의 Logs 페이지를 가로지르는 조인 키이며 답을 얻는 가장 빠른 방법이에요.

그 옆에 전체 error 객체, HTTP 상태, 응답 헤더, 요청한 모델을 포함하세요. 메시지가 <Provider>Exception을 포함하면 먼저 공급자 자체 상태 페이지를 확인하세요. 게이트웨이가 실패를 보고했지 원인은 아니에요.

str(e)(Error code: 400 - {...})만 출력하는 클라이언트는 헤더를 버리므로, id를 오류 본문에 쓸 수도 있어요. general_settings.include_call_id_in_error_body: true를 설정하면 게이트웨이가 쓰는 모든 JSON 오류가 헤더와 같은 값을 담아요. 기본적으로 꺼져 있어 켤 때까지 오류 본문이 오늘과 바이트 동일하게 유지돼요.

general_settings:
  include_call_id_in_error_body: true

OpenAI 형태 라우트(/v1/chat/completions, /v1/responses, 스트리밍 첫 번째 청크 오류 포함)와 /v1/messages에서 id는 error 객체 안에 있으며, 이는 OpenAI SDK가 e.body로 유지하는 부분이에요:

{"error": {"message": "Invalid model name passed in model=gpt-nope", "type": "invalid_request_error", "param": "model", "code": "400", "litellm_call_id": "019b2c4d-e5f6-7890-abcd-ef1234567890"}}

{"type": "error", "error": {"type": "invalid_request_error", "message": "Invalid model name passed in model=gpt-nope", "litellm_call_id": "019b2c4d-e5f6-7890-abcd-ef1234567890"}}

패스스루 라우트는 제공자의 자체 오류 본문을 중계하므로 id가 최상위에 추가되고 제공자의 error 객체는 그대로 남아요:

{"type": "error", "error": {"type": "not_found_error", "message": "model: claude-nope"}, "litellm_call_id": "019b2c4d-e5f6-7890-abcd-ef1234567890"}

이 설정은 게이트웨이가 JSON 본문에 x-litellm-call-id 헤더를 이미 설정한 곳에만 id를 추가해요. 그래서 422 요청 검증 오류, id가 존재하기 전에 거부되는 인증 실패, 스트림 중간에 도착하는 오류, 비-JSON 패스스루 본문은 변경되지 않아요.

게이트웨이가 업스트림으로 보낸 정확한 요청을 보려면 --detailed_debug로 재시작하거나 LITELLM_LOG=DEBUG를 설정하거나, 단일 요청 본문에 "litellm_request_debug": true를 추가하세요. Debugging 참고.