/batches

/batches

Batches, Files를 다룹니다.

기능	지원	비고
지원 프로바이더	OpenAI, Azure, Vertex, Bedrock, Mistral, vLLM
비용 추적 (Cost Tracking)	✅	LiteLLM Enterprise 전용
로깅 (Logging)	✅	모든 로깅 통합에서 동작

프록시에 구성된 가드레일은 배치 입력 파일이 업로드될 때 파일 안의 레코드에 적용돼요. Batch API Guardrails 참고.

빠른 시작

• 배치 컴플리션용 파일 만들기
• 배치 요청 만들기
• 배치 나열하기
• 특정 배치와 파일 콘텐츠 가져오기
• LiteLLM PROXY Server SDK

$ export OPENAI_API_KEY="sk-..."

$ litellm

# RUNNING on http://0.0.0.0:4000

배치 컴플리션용 파일 만들기

curl http://localhost:4000/v1/files \
  -H "Authorization: Bearer ***" \
  -F purpose="batch" \
  -F file="@mydata.jsonl"

배치 요청 만들기

curl http://localhost:4000/v1/batches \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-abc123",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h"
  }'

특정 배치 가져오기

curl http://localhost:4000/v1/batches/batch_abc123 \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \

배치 나열하기

curl http://localhost:4000/v1/batches \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \

배치 컴플리션용 파일 만들기 (SDK)

import litellm
import os
import asyncio

os.environ["OPENAI_API_KEY"] = "sk-.."

file_name = "openai_batch_completions.jsonl"
_current_dir = os.path.dirname(os.path.abspath(__file__))
file_path = os.path.join(_current_dir, file_name)

file_obj = await litellm.acreate_file(
    file=open(file_path, "rb"),
    purpose="batch",
    custom_llm_provider="openai",
)
print("Response from creating file=", file_obj)

배치 요청 만들기 (SDK)

import litellm
import os
import asyncio

create_batch_response = await litellm.acreate_batch(
    completion_window="24h",
    endpoint="/v1/chat/completions",
    input_file_id=batch_input_file_id,
    custom_llm_provider="openai",
    metadata={
        "key1": "value1",
        "key2": "value2"
    },
)
print("response from litellm.create_batch=", create_batch_response)

특정 배치와 파일 콘텐츠 가져오기 (SDK, 폴링)

# Maximum wait time before we give up
MAX_WAIT_TIME = 300
# Time to wait between each status check
POLL_INTERVAL = 5
# Time waited till now
waited = 0

# Wait for the batch to finish processing before trying to retrieve output
# This loop checks the batch status every few seconds (polling)
while True:
    retrieved_batch = await litellm.aretrieve_batch(
        batch_id=create_batch_response.id,
        custom_llm_provider="openai",
    )
    status = retrieved_batch.status
    print(f"⏳ Batch status: {status}")
    if status == "completed" and retrieved_batch.output_file_id:
        print("✅ Batch complete. Output file ID:", retrieved_batch.output_file_id)
        break
    elif status in ["failed", "cancelled", "expired"]:
        raise RuntimeError(f"❌ Batch failed with status: {status}")
    await asyncio.sleep(POLL_INTERVAL)
    waited += POLL_INTERVAL
    if waited > MAX_WAIT_TIME:
        raise TimeoutError("❌ Timed out waiting for batch to complete.")

print("retrieved batch=", retrieved_batch)
# just assert that we retrieved a non None batch
assert retrieved_batch.id == create_batch_response.id

다중 계정 / 모델 기반 라우팅

config.yaml의 모델별 자격 증명을 사용해 배치 작업을 다른 프로바이더 계정으로 라우팅해요. 이렇게 하면 환경 변수가 필요 없어지고 멀티 테넌트 배치 처리가 가능해집니다.

동작 방식

우선순위 순서:

1. 인코딩된 배치/파일 ID (최우선) - ID에 포함된 모델 정보
2. 모델 파라미터 - 헤더(x-litellm-model), query 파라미터, 또는 요청 본문을 통해서
3. 커스텀 프로바이더 (폴백) - 환경 변수 사용

구성

model_list:
  - model_name: gpt-4o-account-1
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: «redacted:sk-…»
      api_base: https://api.openai.com/v1
  
  - model_name: gpt-4o-account-2
    litellm_params:
      model: openai/gpt-5.6-terra
      api_key: «redacted:sk-…»
      api_base: https://api.openai.com/v1
  
  - model_name: azure-batches
    litellm_params:
      model: azure/gpt-5.6-terra
      api_key: azure-key-123
      api_base: https://my-resource.openai.azure.com
      api_version: "2024-02-01"

사용 예시

시나리오 1: 모델이 있는 인코딩된 파일 ID

모델 파라미터로 파일을 업로드하면, LiteLLM은 파일 ID에 모델 정보를 인코딩합니다. 이후 모든 작업은 자동으로 그 자격 증명을 사용합니다.

# Step 1: Upload file with model
curl http://localhost:4000/v1/files \
  -H "Authorization: Bearer ***" \
  -H "x-litellm-model: gpt-4o-account-1" \
  -F purpose="batch" \
  -F file="@batch.jsonl"

# Response includes encoded file ID:
# {
#   "id": "file-bGl0ZWxsbTpmaWxlLUxkaUwzaVYxNGZRVlpYcU5KVEdkSjk7bW9kZWwsZ3B0LTRvLWFjY291bnQtMQ",
#   ...
# }

# Step 2: Create batch - automatically routes to gpt-4o-account-1
curl http://localhost:4000/v1/batches \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-bGl0ZWxsbTpmaWxlLUxkaUwzaVYxNGZRVlpYcU5KVEdkSjk7bW9kZWwsZ3B0LTRvLWFjY291bnQtMQ",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h"
  }'

# Batch ID is also encoded with model:
# {
#   "id": "batch_bGl0ZWxsbTpiYXRjaF82OTIwM2IzNjg0MDQ4MTkwYTA3ODQ5NDY3YTFjMDJkYTttb2RlbCxncHQtNG8tYWNjb3VudC0x",
#   "input_file_id": "file-bGl0ZWxsbTpmaWxlLUxkaUwzaVYxNGZRVlpYcU5KVEdkSjk7bW9kZWwsZ3B0LTRvLWFjY291bnQtMQ",
#   ...
# }

# Step 3: Retrieve batch - automatically routes to gpt-4o-account-1
curl http://localhost:4000/v1/batches/batch_bGl0ZWxsbTpiYXRjaF82OTIwM2IzNjg0MDQ4MTkwYTA3ODQ5NDY3YTFjMDJkYTttb2RlbCxncHQtNG8tYWNjb3VudC0x \
  -H "Authorization: Bearer ***"

✅ 이점:

• 매 요청에 모델을 지정할 필요 없음
• 파일/배치 ID가 어떤 계정이 만들었는지 "기억"
• 조회, 취소, 파일 콘텐츠 작업에 자동 라우팅

시나리오 2: 헤더/쿼리 파라미터로 모델 지정

ID에 인코딩하지 않고 각 요청의 모델을 지정해요.

# Create batch with model header
curl http://localhost:4000/v1/batches \
  -H "Authorization: Bearer ***" \
  -H "x-litellm-model: gpt-4o-account-2" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-abc123",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h"
  }'

# Or use query parameter
curl "http://localhost:4000/v1/batches?model=gpt-4o-account-2" \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-abc123",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h"
  }'

# List batches for specific model
curl "http://localhost:4000/v1/batches?model=gpt-4o-account-2" \
  -H "Authorization: Bearer ***"

✅ 사용 사례:

• 일회성 배치 작업
• 작업마다 다른 모델
• 라우팅의 명시적 제어

시나리오 3: 환경 변수 (폴백)

모델이 지정되지 않았을 때 환경 변수를 사용하는 전통적인 접근 방식이에요.

export OPENAI_API_KEY="sk-env-key"

curl http://localhost:4000/v1/batches \
  -H "Authorization: Bearer ***" \
  -H "Content-Type: application/json" \
  -d '{
    "input_file_id": "file-abc123",
    "endpoint": "/v1/chat/completions",
    "completion_window": "24h"
  }'

✅ 사용 사례:

• 하위 호환성
• 단순한 단일 계정 설정
• 빠른 프로토타이핑

완전한 다중 계정 예시

# Upload file to Account 1
FILE_1=$(curl -s http://localhost:4000/v1/files \
  -H "x-litellm-model: gpt-4o-account-1" \
  -F purpose="batch" \
  -F file="@batch1.jsonl" | jq -r '.id')

# Upload file to Account 2
FILE_2=$(curl -s http://localhost:4000/v1/files \
  -H "x-litellm-model: gpt-4o-account-2" \
  -F purpose="batch" \
  -F file="@batch2.jsonl" | jq -r '.id')

# Create batch on Account 1 (auto-routed via encoded file ID)
BATCH_1=$(curl -s http://localhost:4000/v1/batches \
  -d "{\"input_file_id\": \"$FILE_1\", \"endpoint\": \"/v1/chat/completions\", \"completion_window\": \"24h\"}" | jq -r '.id')

# Create batch on Account 2 (auto-routed via encoded file ID)
BATCH_2=$(curl -s http://localhost:4000/v1/batches \
  -d "{\"input_file_id\": \"$FILE_2\", \"endpoint\": \"/v1/chat/completions\", \"completion_window\": \"24h\"}" | jq -r '.id')

# Retrieve both batches (auto-routed to correct accounts)
curl http://localhost:4000/v1/batches/$BATCH_1
curl http://localhost:4000/v1/batches/$BATCH_2

# List batches per account
curl "http://localhost:4000/v1/batches?model=gpt-4o-account-1"
curl "http://localhost:4000/v1/batches?model=gpt-4o-account-2"

모델 라우팅과 함께 SDK 사용

import litellm
import asyncio

# Upload file with model routing
file_obj = await litellm.acreate_file(
    file=open("batch.jsonl", "rb"),
    purpose="batch",
    model="gpt-4o-account-1",  # Route to specific account
)

print(f"File ID: {file_obj.id}")
# File ID is encoded with model info

# Create batch - automatically uses gpt-4o-account-1 credentials
batch = await litellm.acreate_batch(
    completion_window="24h",
    endpoint="/v1/chat/completions",
    input_file_id=file_obj.id,  # Model info embedded in ID
)

print(f"Batch ID: {batch.id}")
# Batch ID is also encoded

# Retrieve batch - automatically routes to correct account
retrieved = await litellm.aretrieve_batch(
    batch_id=batch.id,  # Model info embedded in ID
)

print(f"Batch status: {retrieved.status}")

# Or explicitly specify model
batch2 = await litellm.acreate_batch(
    completion_window="24h",
    endpoint="/v1/chat/completions",
    input_file_id="file-regular-id",
    model="gpt-4o-account-2",  # Explicit routing
)

ID 인코딩 동작 방식

LiteLLM은 base64로 파일/배치 ID에 모델 정보를 인코딩합니다:

Original:  file-abc123
Encoded:   file-bGl0ZWxsbTpmaWxlLWFiYzEyMzttb2RlbCxncHQtNG8tdGVzdA
           └─┬─┘ └──────────────────┬──────────────────────┘
          prefix      base64(litellm:file-abc123;model,gpt-4o-test)

Original:  batch_xyz789
Encoded:   batch_bGl0ZWxsbTpiYXRjaF94eXo3ODk7bW9kZWwsZ3B0LTRvLXRlc3Q
           └──┬──┘ └──────────────────┬──────────────────────┘
           prefix       base64(litellm:batch_xyz789;model,gpt-4o-test)

인코딩의 특성:

• ✅ OpenAI 호환 접두사(file-, batch_) 보존
• ✅ 클라이언트에 투명
• ✅ 추가 파라미터 없이 자동 라우팅 가능
• ✅ 모든 배치/파일 엔드포인트에서 동작

지원 엔드포인트

모든 배치/파일 엔드포인트가 모델 기반 라우팅을 지원합니다:

엔드포인트	메서드	모델 라우팅
/v1/files	POST	✅ 헤더/쿼리/본문 경유
/v1/files/{file_id}	GET	✅ 인코딩된 ID + 헤더/쿼리에서 자동
/v1/files/{file_id}/content	GET	✅ 인코딩된 ID + 헤더/쿼리에서 자동
/v1/files/{file_id}	DELETE	✅ 인코딩된 ID에서 자동
/v1/batches	POST	✅ 파일 ID + 헤더/쿼리/본문에서 자동
/v1/batches	GET	✅ 헤더/쿼리 경유
/v1/batches/{batch_id}	GET	✅ 인코딩된 ID에서 자동
/v1/batches/{batch_id}/cancel	POST	✅ 인코딩된 ID에서 자동

지원 프로바이더

LiteLLM은 다음 프로바이더 네이티브 배치 API를 지원해요:

프로바이더	문서
Azure OpenAI	Azure OpenAI batches
OpenAI	Quick start
Google Vertex AI	Vertex AI batch APIs
Amazon Bedrock	Amazon Bedrock batch inference
Mistral AI	Mistral files and batches
vLLM	vLLM batches, 서버에 Files API가 없으면 LiteLLM이 실행

Amazon Bedrock이 배치 추론을 위한 지원되는 AWS 통합입니다.

배치 입력 파일 검증

LiteLLM은 업로드 시점에 배치 입력 파일을 검증해요. 클라이언트가 purpose="batch"로 POST /v1/files에 파일을 업로드하면, LiteLLM은 로컬에서 파일을 확인하고 프로바이더로 아무것도 전달하기 전에 잘못된 파일을 거부합니다. 검증은 files_settings로 구성된 프로바이더 라우팅 업로드와 target_model_names을 사용하는 LiteLLM 관리 파일 업로드를 포함한 모든 /v1/files 라우팅 경로에서 실행됩니다.

거부는 OpenAI 오류 형식(message, type, param, code 필드가 있는 오류 객체)을 사용하므로 기존 OpenAI SDK 오류 처리가 변경 없이 동작합니다.

배치 입력 파일 크기 제한

general_settings 아래 max_batch_file_size_mb 로 배치 입력 파일 크기를 제한해요. 값은 MB 단위의 정수입니다. 설정하지 않으면 크기 상한이 적용되지 않습니다.

general_settings:
  master_key: os.environ/LITELLM_MASTER_KEY
  max_batch_file_size_mb: 10

상한보다 큰 purpose="batch" 업로드는 HTTP 413으로 거부됩니다:

{
  "error": {
    "message": "Batch input file is 12.0 MB, which exceeds the configured max_batch_file_size_mb of 10 MB. The file was not forwarded to the provider.",
    "type": "invalid_request_error",
    "param": "file",
    "code": "413"
  }
}

max_batch_file_size_mb 는 배치 입력 파일 업로드에만 적용됩니다. 모든 프록시 라우트에 적용되는 max_request_size_mb 와는 별개예요.

콘텐츠 검증

LiteLLM은 항상 purpose="batch" 업로드의 콘텐츠를 검증합니다. 설정할 옵션은 없어요. 파일 이름은 대소문자 무시로 .jsonl로 끝나야 합니다. 파일에는 비어 있지 않은 줄이 최소 하나 있어야 해요. 모든 비어 있지 않은 줄은 유효한 JSON이어야 합니다. 모든 줄은 JSON 객체여야 합니다. 모든 객체는 custom_id, method, url, body 키를 포함해야 해요.

이 검사 중 하나라도 실패한 파일은 HTTP 400과 "type": "invalid_request_error"로 거부됩니다. param 필드는 문제 필드를 명명합니다: 잘못된 확장자, 빈 파일, 유효하지 않은 JSON이거나 JSON 객체가 아닌 줄에는 file입니다. 필수 키가 누락된 줄의 경우 param 은 누락된 키(예: method)입니다. 메시지는 관련된 1부터 시작하는 줄 번호를 포함합니다. 줄 번호는 빈 줄을 포함한 파일의 모든 줄을 셉니다.

프로바이더 배치 한도

각 프로바이더는 배치 입력 파일에 자체 한도를 적용합니다. max_batch_file_size_mb 값을 고를 때 사용하세요.

프로바이더	최대 입력 파일 크기	최대 요청
OpenAI	200 MB	배치당 50,000
Azure OpenAI	200 MB	파일당 100,000
Vertex AI	1 GB	작업당 200,000
Amazon Bedrock	파일당 1 GB	See AWS Service Quotas

Azure OpenAI는 bring-your-own Blob Storage로 파일 상한을 1 GB로 올립니다. Vertex AI 상한은 Cloud Storage 입력에 적용됩니다. Amazon Bedrock은 대부분 모델에서 총 작업 크기를 5 GB로 제한하기도 합니다. max_batch_file_size_mb 를 배치 트래픽을 라우팅하는 프로바이더의 최소 한도 이하로 설정하세요.

출처: 문서

Batches API 속도 제한 동작 방식

배치 속도 제한은 클라이언트가 POST /v1/batches를 호출할 때 적용되며, 입력 파일을 업로드할 때가 아니에요.

1. 클라이언트가 POST /v1/files로 JSONL 입력 파일을 업로드합니다. 이 업로드는 배치 TPM 또는 RPM 허용량을 소비하지 않아요.
2. 클라이언트가 배치를 만들면, LiteLLM은 참조된 입력 파일을 다운로드해 평가합니다.
3. LiteLLM은 적용 가능한 모든 제한에 대해 전체 파일을 원자적으로 확인합니다.
4. 어떤 제한이라도 초과하면 LiteLLM은 429를 반환하고 프로바이더에 배치를 제출하지 않습니다. 그렇지 않으면 사용량을 기록하고 프로바이더 배치를 만듭니다.

이렇게 하면 LiteLLM이 프로바이더가 처리하기 전에 배치를 수락하거나 거부할 수 있어요.

LiteLLM이 세는 것

제한	배치 부과
RPM	각 JSONL 레코드에 대해 요청 하나.
TPM	각 레코드의 body.messages, body.prompt, 또는 body.input에서 찾은 입력 토큰.
Project ITPM	같은 입력 토큰 수, 각 레코드의 body.model로 그룹화.
Project OTPM	각 레코드의 출력 토큰 예약, body.model로 그룹화. LiteLLM은 max_tokens, max_completion_tokens 또는 max_output_tokens가 있으면 사용하고 n 또는 best_of를 계산합니다. 임베딩 레코드는 출력 토큰을 예약하지 않습니다. 출력 상한이 없으면 LiteLLM은 v3 리미터의 내장 추정치를 사용하며, 가장 작은 적용 가능한 OTPM 한도로 제한됩니다.

LiteLLM이 개별 레코드를 토큰화할 수 없으면 직렬화된 레코드 크기에 기반한 보수적 추정치를 사용합니다. 손상된 JSONL 줄도 요청 하나로 셉니다.

LITELLM_TPM_TOKEN_RESERVATION_ENABLED 는 배치 속도 제한을 제어하지 않습니다. 그 변수는 채팅 컴플리션 같은 실시간 요청에 대한 요청 전 예약을 제어합니다. 아래의 배치별 skip 설정 중 하나가 활성화되지 않는 한 POST /v1/batches 는 항상 여기에 설명된 배치 입력 파일 리미터를 사용합니다.

큐잉된 토큰 한도

분당 창은 배치에 잘 맞지 않아요: 배치는 몇 시간 동안 실행되지만 전체 입력 파일이 제출 시점의 단일 분에 부과됩니다. 미결 배치 작업으로 배치 제출을 통제하려면 키 또는 팀 metadata에 큐잉된 토큰 허용량(enqueued-token allowance)을 설정하세요:

curl -X POST 'http://localhost:4000/key/generate' \
  -H "Authorization: Bearer ***" \
  -H 'Content-Type: application/json' \
  -d '{"metadata": {"batch_enqueued_token_limit": 100000}}'

batch_enqueued_token_limit 은 팀 metadata에서도 동작합니다. 키와 팀 둘 다 설정하면, 배치는 두 허용량 모두에 맞아야 해요.

batch_enqueued_token_limit 을 설정하거나 변경할 수 있는 것은 프록시 관리자뿐입니다. 다른 역할의 키/팀 요청은 403으로 거부됩니다.

키나 팀에 큐잉된 토큰 한도가 있으면 배치 제출은 그 허용량에 의해서만 통제됩니다:

1. 클라이언트가 배치를 만들면, LiteLLM은 파일의 추정 토큰(입력 토큰 + 각 레코드의 출력 상한)을 허용량에 예약합니다.
2. 배치가 맞지 않으면, LiteLLM은 429로 큐잉된 토큰 한도를 명명하고 배치를 프로바이더에 제출하지 않습니다.
3. LiteLLM이 배치를 종결 상태(completed, failed, expired, cancelled)로 보여주는 응답을 제공하면 예약을 환불합니다. GET /v1/batches/{batch_id} 폴링과 POST /v1/batches/{batch_id}/cancel 취소 모두 자격이 됩니다.
4. 배치 제출은 분당 TPM/RPM 창에 부과되지 않으므로, 레코드 수가 키의 RPM을 초과하는 배치도 허용량에 맞으면 수락됩니다.

채팅 컴플리션 같은 실시간 트래픽은 영향받지 않습니다: 종전과 똑같이 키의 TPM/RPM 한도를 소비합니다.

계획할 두 가지 세부 사항:

• disable_batch_input_file_rate_limiting 과 skip_batch_input_file_rate_limiting_for_providers 가 우선합니다. 적용되면 LiteLLM은 큐잉된 토큰 회계를 수행하지 않아요.
• LiteLLM이 종결 상태를 관찰하지 못한 배치(예: 프로바이더에 대해 직접만 폴링되는 배치)의 예약은 8일 후 만료됩니다.

운영 동작

동작	운영 영향
회계는 제출된 파일 기반	배치 TPM/RPM 카운터는 프로바이더의 최종 사용량과 조정되지 않습니다. 최종 비용 추적은 별개예요.
전체 파일을 다운로드하거나 평가할 수 없음	LiteLLM이 오류를 로그하고 TPM/RPM에 부과하지 않고 배치를 제출합니다. 엄격한 속도 제한 적용이 필요하면 이 오류를 모니터링하세요.
적용 가능한 속도 제한이 구성되지 않음	LiteLLM은 속도 제한 회계를 위해 파일을 다운로드하지 않고 배치를 제출합니다.
API 키에 모델 allowlist가 있음	LiteLLM은 파일을 읽고 제출 전에 모든 body.model을 검증합니다.

입력 파일 사전 읽기 건너뛰기

큰 JSONL 파일을 읽으면 배치 제출에 지연이 생길 수 있어요. 배치가 제출 시 TPM/RPM에 부과될 필요가 없다면 다음 옵션 중 하나를 구성하세요:

general_settings:
  # Apply to all batch submissions
  disable_batch_input_file_rate_limiting: true

  # Or apply only to batches routed to selected providers
  skip_batch_input_file_rate_limiting_for_providers:
    - bedrock

프로바이더별 옵션은 선택된 라우트에 구성된 프로바이더를 사용합니다. 클라이언트가 제공한 custom_llm_provider 값을 사용하지 않아요.

모델 allowlist가 있는 API 키의 경우, LiteLLM은 각 body.model 값을 검증하기 위해 여전히 파일을 읽어야 합니다. 이런 경우 위 설정은 TPM/RPM 카운터 업데이트를 건너뛰지만, 파일 다운로드나 모델 검증은 건너뛰지 않습니다.

지원되지 않는 옵션:

• skip_batch_input_file_rate_limiting_for_models 는 호환성을 위해 유지되지만 효과가 없어요. 구성되면 시작 시 경고를 로그합니다.
• 요청 metadata의 skip_batch_input_file_rate_limiting 플래그는 무시됩니다.

이 동작을 서버 수준에서 관리하려면 위의 전역 또는 프로바이더별 설정을 사용하세요.

Batches API 비용 추적 동작 방식

✨ Enterprise: 자동 배치 비용 추적에는 LiteLLM Enterprise 라이선스가 필요합니다.

관리(managed) 배치의 경우, LiteLLM은 백그라운드에서 프로바이더 작업을 모니터링합니다. 작업이 종결 상태에 도달하면 LiteLLM은:

1. 프로바이더의 출력 파일을 다운로드합니다.
2. 각 성공한 출력 레코드를 읽습니다.
3. 그 레코드들에 걸쳐 prompt, completion, total 토큰 사용량을 집계합니다.
4. 배포에 구성된 배치 가격으로 각 레코드의 비용을 계산합니다.
5. 배치를 만든 사용자, 키, 팀, 요청 태그에 결합된 사용량과 비용을 기록합니다.

실패한 출력 레코드는 집계에서 제외됩니다. 모든 레코드가 실패해 출력 파일이 없으면, LiteLLM은 0 사용량과 0 비용을 기록합니다.

초기 제출과 완료된 집계는 별도로 기록됩니다. 완료된 집계는 aretrieve_batch 레코드로 표준 지출 추적을 통해 방출되므로 Admin UI와 구성된 로깅 콜백에서 사용할 수 있어요.

배치 비용 추적은 제출 시 예약된 TPM/RPM 카운터를 변경하지 않습니다. 그 카운터는 위에서 설명한 입력 파일 계산에 기반합니다.

Swagger API Reference

더 알아보기 (Learn more)

• Files Endpoints
• Batch API Guardrails
• Swagger API Reference