LLM Latency vs Throughput: API 구매자가 속도를 측정하는 방법

최근 테스트에서 첫 번째 가시적 토큰(first visible token)을 가장 빨리 보여준 모델이 완료까지는 가장 느렸습니다. 2026년 10월 3일, 우리는 4개의 모델을 통해 하나의 프롬프트를 스트리밍했습니다. claude-sonnet-5-5는 첫 번째 가시적 토큰(2,981ms)에서 앞섰지만, 총 소요 시간(12,384ms)에서는 뒤처졌습니다. 이 격차가 바로 LLM Latency(지연 시간)와 Throughput(처리량)의 핵심입니다. 하나의 수치는 사용자가 텍스트를 보기까지 얼마나 기다리는지를 나타내고, 다른 수치는 작업이 얼마나 빨리 완료되는지를 나타냅니다. 이 글에서는 각 지표를 정의하고, 자체적으로 수행한 소규모 측정 결과와 그 한계를 보여주며, TokenLab API를 대상으로 실행할 수 있는 측정 도구(harness)를 제공합니다.

핵심 요약

• 세 가지 수치, 세 가지 역할. 첫 번째 토큰까지의 시간(TTFT), 총 소요 시간, 초당 출력 토큰 수는 각각 다른 질문에 답합니다. 채팅, 에이전트, 배치 작업은 각각 다른 지표에 의존합니다.
• 첫 번째 이벤트와 첫 번째 가시적 토큰을 구분하세요. deepseek-v4.1-flash의 경우 두 중앙값의 차이는 2,334ms와 3,925ms였습니다. 추론 델타(Reasoning delta)는 가시적인 텍스트가 나타나기 훨씬 전에 도착할 수 있습니다.
• 추론 토큰은 max_tokens 예산을 소모합니다. max_tokens를 400으로 설정했을 때, deepseek-v4.1-flash는 약 0개의 가시적 토큰을, gemini-3.8-flash는 약 14개를 반환했습니다. 2000으로 설정했을 때는 둘 다 전체 답변을 제공했습니다.
• 토큰 수는 usage 청크에서 읽으세요. 문자 수로 추정하지 마십시오.
• 모델 속도가 요청 제한을 높여주지는 않습니다. 속도 제한(Rate limits), 토큰 제한, 모델 속도는 별개의 제약 사항입니다.
• 표본이 작습니다. 모델당 5회 실행, 단일 클라이언트, 단일 프롬프트, 하루 동안의 측정입니다. 이 글은 측정 방법을 보여주기 위한 것이며, 누가 가장 빠른지를 증명하는 것이 아닙니다.

세 가지 속도 수치: LLM Latency vs Throughput 실전

"속도"를 구성 요소별로 나누어 보세요. 각 요소는 네트워크, 모델, 그리고 사용자의 큐(queue) 등 서로 다른 주체가 담당합니다.

send request
  -> first stream event          (모든 SSE 청크; 추론 델타일 수 있음)
  -> first visible content token (비어 있지 않은 첫 번째 delta.content)
  -> last token + final usage chunk

Time to first token (TTFT)은 요청을 보낸 시점부터 첫 번째 토큰이 도착할 때까지의 시간입니다. 우리는 두 가지 버전을 기록합니다. 첫 번째 스트림 이벤트(first stream event)는 모든 종류의 첫 번째 SSE 청크입니다. 첫 번째 가시적 콘텐츠 토큰(first visible content token)은 choices[0].delta.content가 비어 있지 않은 첫 번째 청크입니다. 답변하기 전에 추론하는 모델의 경우, 첫 번째 이벤트는 가시적인 텍스트보다 훨씬 먼저 도착하는 추론 델타(delta.reasoning_content)일 수 있습니다. delta.content만 감시하는 도구는 첫 번째 바이트까지의 시간이 아니라 첫 번째 가시적 토큰까지의 시간을 측정합니다. 사용자가 체감하는 것은 가시적인 토큰입니다.

총 소요 시간(Total time)은 요청을 보낸 시점부터 스트림이 끝날 때까지입니다. 여기에는 추론, 네트워크 시간, 그리고 추가한 재시도 대기 시간이 포함됩니다.

초당 출력 토큰 수(Output tokens per second)는 출력 토큰 수를 총 소요 시간으로 나눈 값입니다. 토큰 수는 추론 토큰을 포함하는 usage.completion_tokens에서 가져옵니다. 우리는 가시적인 윈도우가 아닌 총 소요 시간으로 나눕니다. 우리 표본의 일부 모델은 가시적인 텍스트를 몇 개의 큰 청크로 전달했기 때문에, 윈도우 기반의 속도 측정은 오해를 불러일으킬 수 있습니다.

워크로드	우선 확인 지표	다음 확인 지표	이유
채팅	첫 번째 가시적 토큰	총 소요 시간	사용자는 가시적인 텍스트가 나타날 때까지 빈 상자를 보고 있기 때문입니다.
에이전트	총 소요 시간	첫 번째 가시적 토큰	각 단계는 보통 이전 단계를 기다리므로, 단계별 총합이 중요합니다.
배치 추출 또는 요약	초당 출력 토큰 수 및 작업당 비용	요청 제한 여유분	첫 번째 토큰을 확인하는 사람은 없으며, 계정의 요청 제한이 작업 제출 속도를 결정하기 때문입니다.

구조화된 JSON 추출과 같은 비스트리밍 호출은 총 소요 시간만 노출합니다. 분할 측정을 원한다면 테스트 시 스트리밍을 사용하세요.

2026년 10월 3일 측정 결과

방법. 이는 2026년 10월 3일, POST https://api.tokenlab.sh/v1/chat/completions (소스)를 대상으로 수행한 TokenLab 자체 측정입니다. 각 요청은 stream=true 및 stream_options.include_usage=true를 사용했습니다. 동아시아의 단일 클라이언트에서 Node 24 fetch를 사용하여 모델당 5회 순차적으로 실행했습니다. 프롬프트는 "Explain how HTTP keep-alive reduces latency for API clients. Write about 200 words."였습니다. 모든 모델은 기본 추론 설정을 사용했습니다. 시간은 클라이언트 측 벽시계 기준이며, 아래의 모든 행에 대해 5회 실행 모두 성공했습니다.

모델 (max_tokens 2000)	첫 스트림 이벤트 중앙값	첫 가시적 토큰 중앙값	총 소요 시간 중앙값	완료 토큰 중앙값 (추론)	추정 토큰/초
deepseek-v4.1-flash	2,334 ms	3,925 ms	5,204 ms	453 (225)	87
gemini-3.8-flash	6,892 ms	6,892 ms	8,626 ms	826 (528)	96
claude-sonnet-5-5	2,981 ms	2,981 ms	12,384 ms	418 (미보고)	34
gpt-5.6-luna	3,262 ms	3,262 ms	8,183 ms	313 (42)	38

토큰/초 열은 자체 추정치입니다: 완료 토큰 중앙값을 총 초 중앙값으로 나눈 값(예: 453 ÷ 5.204 ≈ 87). 이는 중앙값들의 비율이지, 실행별 속도의 중앙값이 아닙니다.

수치가 보여주는 점:

• 첫 번째 가시적 토큰 기준 순서(claude-sonnet-5-5, gpt-5.6-luna, deepseek-v4.1-flash, gemini-3.8-flash)는 총 소요 시간 기준 순서(deepseek-v4.1-flash, gpt-5.6-luna, gemini-3.8-flash, claude-sonnet-5-5)와 다릅니다. 하나의 지표가 다른 지표를 대신할 수 없습니다.
• deepseek-v4.1-flash는 첫 번째 이벤트와 첫 번째 가시적 토큰 사이에 1,591ms의 간격이 있었습니다. 가시적 출력 중앙값은 약 228토큰이었으며, 1,304ms 동안 87개의 이벤트로 전달되었습니다.
• gemini-3.8-flash의 경우 첫 번째 이벤트와 첫 번째 가시적 토큰의 중앙값이 6,892ms로 동일합니다. 가시적 텍스트는 1,734ms 동안 11개의 이벤트로 전달되었으므로, 스트림이 토큰 단위가 아닌 덩어리 단위로 이루어졌음을 알 수 있습니다.
• claude-sonnet-5-5는 9,186ms 동안 371개의 이벤트를, gpt-5.6-luna는 4,901ms 동안 265개의 이벤트를 보냈습니다.

비용은 속도와 함께 고려해야 합니다. 아래 가격은 2026년 10월 3일 기준 TokenLab 모델 API에서 확인되었으며, 2026년 10월 2일 16:53:30.068Z에 업데이트되었습니다. 마지막 열은 추정치입니다: 완료 토큰 중앙값에 출력 단가를 곱한 값(출력 측만 해당). 실제 청구 금액은 사용 기록을 확인하십시오.

모델	입력(1M당)	출력(1M당)	최대 출력 토큰	출력 측 추정치, 중앙값 실행	소스
deepseek-v4.1-flash	$0.15(비피크), $0.30(피크)	$0.60(비피크), $1.20(피크)	384,000	453 × $0.60 / 1M ≈ $0.00027(비피크), ≈ $0.00054(피크)	모델 API
gemini-3.8-flash	$0.375	$1.875	65,536	826 × $1.875 / 1M ≈ $0.00155	모델 API
claude-sonnet-5-5	$0.60	$3	128,000	418 × $3 / 1M ≈ $0.00125	모델 API
gpt-5.6-luna	$0.06	$0.36	128,000	313 × $0.36 / 1M ≈ $0.00011	모델 API

gpt-5.6-luna의 경우, 입력이 최대 272K 토큰일 때 해당 요금이 적용됩니다. 그 이상일 경우 전체 요청에 대해 2배의 입력 요금과 1.5배의 출력 요금이 적용됩니다.

본 표본의 한계. 동아시아의 단일 클라이언트에서 수행한 5회의 순차적 실행은 매우 좁은 범위입니다. 프롬프트가 짧은 에세이 요청 하나였으므로, 결과는 지역, 시간대, 프롬프트, 출력 길이에 따라 달라질 것입니다. 동시성 테스트는 수행하지 않았으므로 부하 상태에서의 결과는 알 수 없습니다. 이 표를 실제 운영 환경과 동일한 지역에서 실행할 자체 테스트를 위한 템플릿으로 활용하십시오. 모델에 대한 더 넓은 시야를 원하신다면 TokenLab LLM API 개발자 리더보드를 참고하십시오. 신뢰하기 전에 방법론과 날짜를 확인하십시오. 모델을 임의로 교체하지 마십시오. 2026년 10월 3일 기준 신뢰성 가이드에 따르면, 모델 교체는 품질, 가격, 컨텍스트 길이, 도구 사용에 영향을 줄 수 있습니다.

추론 토큰과 max_tokens: 400에서 거의 아무것도 반환되지 않은 이유

max_tokens를 400으로 설정하고 동일한 프롬프트로 테스트를 수행했습니다. 동일한 방법, 동일한 5회 실행, 동일한 날짜(소스).

모델 (max_tokens 400)	완료 토큰 중앙값	추론 토큰 중앙값	가시적 출력 (근사치)	첫 가시적 토큰 중앙값	총 소요 시간 중앙값
deepseek-v4.1-flash	400	400	0 토큰	3,795 ms	4,693 ms
gemini-3.8-flash	396	382	14 토큰	4,199 ms	4,240 ms
claude-sonnet-5-5	400	미보고	400 토큰	3,088 ms	11,078 ms
gpt-5.6-luna	317	42	275 토큰	3,040 ms	8,083 ms

중앙값은 열별로 계산되므로, 한 행의 열들이 단일 실행을 설명할 필요는 없습니다. 이것이 deepseek-v4.1-flash가 가시적 출력 중앙값이 0임에도 첫 가시적 토큰 시간을 보여주는 이유입니다.

결과는 명확합니다. deepseek-v4.1-flash와 gemini-3.8-flash는 400토큰 예산의 거의 전부를 추론에 사용했으며 가시적인 텍스트는 거의 반환하지 않았습니다. max_tokens를 2000으로 올리자 완전한 답변이 생성되었습니다. 추론 토큰은 usage.completion_tokens 내에 포함됩니다. 이들은 usage.completion_tokens_details.reasoning_tokens에 별도로 보고됩니다.

400토큰 결과를 확인했을 때, 실패는 예산 문제가 아닌 빈 답변처럼 보였습니다. 다음 세 가지 확인을 통해 원인을 파악할 수 있습니다:

1. stream_options={"include_usage": True}로 활성화된 최종 usage 청크를 읽으십시오. reasoning_tokens가 completion_tokens와 비슷하고 텍스트가 비어 있다면, 예산이 추론에 사용된 것입니다.
2. finish_reason을 확인하십시오. 2026년 10월 3일 기준 스트리밍 가이드는 토큰 제한에 도달했을 때 length 값을 반환한다고 명시합니다.
3. 모델의 최대 출력과 비교하십시오. 예를 들어 모델 API는 deepseek-v4.1-flash에 대해 384,000, gemini-3.8-flash에 대해 65,536을 나열하므로 400은 모델 허용량의 아주 작은 일부였습니다.

2026년 10월 3일 기준 Create Chat Completion 참조는 max_completion_tokens와 reasoning_effort도 나열합니다. 지원되는 값은 모델에 따라 다르므로 설정하기 전에 모델 페이지를 읽으십시오. 우리는 이를 테스트하지 않았으며 모든 행을 기본 추론 설정으로 실행했습니다. 프롬프트에 맞춰 제한을 설정하십시오. 우리 테스트에서 200단어 답변은 약 228~418개의 가시적 토큰을 생성했으며, 추가로 최대 528개의 추론 토큰이 사용되었습니다.

TokenLab 기본 URL을 위한 측정 도구

이 스크립트는 TokenLab 기본 URL을 사용하고, usage 청크에서 토큰 수를 읽으며, 첫 번째 스트림 이벤트와 첫 번째 가시적 콘텐츠 토큰을 별도로 기록합니다. 또한 나중에 디버깅할 수 있도록 응답 헤더를 보관합니다. SDK가 타이밍에 숨겨진 재시도를 추가하지 않도록 문서의 클라이언트 설정(timeout=30.0, max_retries=0)을 따릅니다. 모델 ID는 우리가 측정한 것이며, 허용된 요청 형식에 openai_chat_completions가 포함된 ID로 교체하여 사용하십시오.

import json
import os
import statistics
import time

from openai import OpenAI

client = OpenAI(
    api_key=os.environ["TOKENLAB_API_KEY"],
    base_url="https://api.tokenlab.sh/v1",
    timeout=30.0,
    max_retries=0,
)

PROMPT = "Explain how HTTP keep-alive reduces latency for API clients. Write about 200 words."

def measure(model: str, max_tokens: int = 2000) -> dict:
    start = time.perf_counter()
    raw = client.chat.completions.with_raw_response.create(
        model=model,
        messages=[{"role": "user", "content": PROMPT}],
        max_tokens=max_tokens,
        stream=True,
        stream_options={"include_usage": True},
    )
    headers = raw.headers
    first_event = first_visible = None
    visible_events = 0
    usage = None
    finish_reason = None

    for chunk in raw.parse():
        now = time.perf_counter() - start
        if first_event is None:
            first_event = now
        if chunk.usage is not None:
            usage = chunk.usage
        if not chunk.choices:
            continue
        choice = chunk.choices[0]
        if choice.delta.content:
            visible_events += 1
            if first_visible is None:
                first_visible = now
        if choice.finish_reason:
            finish_reason = choice.finish_reason

    total = time.perf_counter() - start
    details = getattr(usage, "completion_tokens_details", None)
    completion = usage.completion_tokens if usage else None
    return {
        "model": model,
        "request_id": headers.get("x-request-id"),
        "routing_time_ms": headers.get("x-routing-time-ms"),
        "first_event_s": first_event,
        "first_visible_s": first_visible,
        "total_s": total,
        "completion_tokens": completion,
        "reasoning_tokens": getattr(details, "reasoning_tokens", None),
        "visible_events": visible_events,
        "finish_reason": finish_reason,
        "tokens_per_s": completion / total if completion else None,
    }

if __name__ == "__main__":
    runs = [measure("gemini-3.8-flash") for _ in range(5)]
    print(json.dumps(runs[0], indent=2))
    print("median total_s:", statistics.median(r["total_s"] for r in runs))

출력 읽기에 대한 참고 사항:

• first_event_s는 역할 전용 청크나 추론 청크를 포함한 모든 청크에서 발생합니다. first_visible_s는 비어 있지 않은 delta.content에서만 발생합니다. 두 값이 초 단위로 차이가 난다면, 모델이 답변하기 전에 추론하고 있는 것입니다.
• 토큰 수는 최종 usage 청크에서 가져옵니다. 해당 청크는 choices 목록이 비어 있으므로 루프에서 건너뛰기 전에 chunk.usage를 확인합니다.
• 5회 이상 실행하고 지역을 기록하며, 표본 크기와 함께 중앙값을 보고하십시오.
• openai_responses를 나열하는 모델의 경우, 스트리밍 가이드는 response.output_text.delta 및 response.completed 이벤트로 스트리밍되는 응답을 보여줍니다. 동일한 분할 방식이 적용됩니다: 첫 번째 이벤트 시간을 측정하고, 그 다음 첫 번째 텍스트 델타를 측정하십시오.
• response.completed 또는 stop 완료 이유 이전에 닫히는 스트림은 빠른 성공이 아니라 불완전한 것으로 간주하십시오.

지연 시간 디버깅을 위해 기록해야 할 헤더 및 식별자

지연 시간만 기록했다면 느린 요청을 디버깅하기 어렵습니다. 2026년 10월 3일 기준 API 참조 및 문제 해결 가이드는 보관할 가치가 있는 식별자를 명시합니다.

식별자	위치	용도
X-Request-ID	응답 헤더 (가능한 경우)	단일 요청에 대한 지원 및 디버깅
request_id	오류 본문, 대시보드 로그, 사용 기록	요청 수준 지원 및 조정
X-Routing-Time-MS	응답 헤더 (가능한 경우)	생성 전 전달 선택에 소요된 시간
X-Task-ID, task_id, poll_url	비동기 생성 및 상태 응답	이미지, 비디오, 음악 및 3D 작업
X-Billing-Transaction-ID	최종 청구 후 헤더 (가능한 경우)	비용 조정
사용자 고유 작업 또는 사용자 ID	애플리케이션	사용자 불만 뒤에 있는 요청 찾기

각 호출에 대해 엔드포인트, 메서드, 모델, 상태 코드, 타임스탬프 및 지연 시간을 기록하십시오. 보낸 필드 이름(프롬프트 제외), 재시도 횟수, 재시도가 새 작업을 생성했는지 아니면 기존 작업을 재개했는지 여부를 추가하십시오. 우리의 도구는 usage 청크에서 분할 타이밍과 토큰 수를 추가합니다.

두 가지 주의 사항. 스트리밍 응답은 스트림이 종료된 후 정산될 수 있으므로 사용 기록이 나중에 기록되더라도 청구 헤더가 없을 수 있습니다. 청구 금액은 응답 토큰 수만 사용하지 말고 관리 API 사용 기록을 사용하십시오. 또한 X-TokenLab-Delivery-Policy 값을 설정했다면 기록하십시오. 참조에 따르면 auto, verified, official을 허용하며, 잘못된 값은 400을 반환하고, 사용할 수 없는 옵션은 code: delivery_tier_unavailable 및 retryable: true와 함께 503을 반환합니다. Authorization, API 키, 서명된 URL, 전체 프롬프트 또는 개인 정보는 절대 기록하지 마십시오.

콘솔 요청 세부 정보는 캡처 후 30일 동안 보관되므로 필요한 ID를 자신의 로그에 복사하십시오. 우리 파이프라인에서는 이러한 ID를 요청 보기와 대조합니다. TokenLab 요청 콘솔 게시물에서 해당 보기를 다룹니다.

속도 제한, 재시도 및 LLM Latency vs Throughput

스트림별 속도와 계정 처리량은 서로 다른 상한선입니다. 2026년 10월 3일 기준 속도 제한 가이드는 아래의 표준 티어 값을 나열합니다. 이는 활성 구성에 따라 변경될 수 있으며 API 키별로 적용됩니다.

티어	분당 요청 수
사용자	1,000
파트너	10,000
VIP	10,000

제한을 초과하면 API는 Retry-After 헤더와 함께 429 rate_limit_exceeded를 반환합니다. 가이드의 예제 본문은 "retryable": true 및 "retry_after": 8을 포함합니다. 가이드는 복사된 표보다 반환된 X-RateLimit-Limit 및 Retry-After 값을 신뢰하라고 명시합니다. 또한 더 빠른 모델이 계정의 요청 제한을 높여주지는 않는다고 합니다.

배치 작업을 위한 계산식입니다. 이는 위 중앙값에서 추정한 것이며 부하 테스트가 아닙니다. 동시 스트림은 대략 초당 요청 수 곱하기 요청당 초 수입니다. 분당 1,000개 요청(초당 약 16.7개)의 경우:

• deepseek-v4.1-flash의 총 소요 시간 중앙값 5.204초일 때, 약 87개의 스트림이 동시에 실행됩니다.
• claude-sonnet-5-5의 중앙값 12.384초일 때, 약 206개의 스트림이 동시에 실행됩니다.

스트림이 느릴수록 동일한 요청 속도를 달성하기 위해 더 많은 동시성이 필요합니다. 제한에 도달하면 생성 시간 위에 대기 시간이 추가됩니다. 토큰 제한은 우리가 사용한 페이지에서 다루지 않으므로 계정과 모델 페이지를 확인하십시오.

수치를 망치지 않고 재시도하는 방법:

• Retry-After가 있으면 준수하십시오. 그렇지 않으면 무작위 지터(jitter)와 엄격한 시도 횟수 제한을 갖춘 지수 백오프(exponential backoff)를 사용하십시오.
• SDK를 max_retries=0으로 설정하고 한 곳에서만 재시도하십시오. 그렇지 않으면 두 계층이 동일한 호출을 재시도하여 타이밍이 이중으로 계산됩니다.
• 유효성 검사, 인증, 잔액 또는 권한 오류는 절대 재시도하지 마십시오. 일시적인 5xx 응답은 짧은 백오프로 재시도하십시오.
• 첫 번째 이벤트가 도착한 후 중단된 스트림은 불완전하며 자동으로 다시 시작되지 않습니다. 요청을 반복하면 다른 출력이 생성되고 추가 요금이 발생할 수 있습니다.
• 재시도 횟수와 대기 시간을 모델 시간과 별도로 기록하여, 제한된 실행이 느린 모델처럼 보이지 않게 하십시오.

다음은 가이드의 제한된 재시도 패턴입니다:

import random
import time
from openai import RateLimitError

def chat_with_rate_limit_retry(client, model, messages, attempts=4):
    for attempt in range(attempts):
        try:
            return client.with_options(max_retries=0).chat.completions.create(
                model=model,
                messages=messages,
            )
        except RateLimitError as exc:
            if attempt == attempts - 1:
                raise
            header = exc.response.headers.get("Retry-After")
            wait = float(header) if header else min(30, 2 ** attempt + random.random())
            time.sleep(wait)

또한 분당 평균 요청 수뿐만 아니라 동시성도 제한하고 버스트를 큐에 넣으십시오. API 키별로 반복되는 429 응답을 추적하여 한 클라이언트가 애플리케이션의 나머지 부분을 방해하지 않도록 하십시오.

FAQ

초당 토큰 수가 높으면 항상 더 빠른 사용자 경험인가요?

아니요. 2026년 10월 3일 표본에서 claude-sonnet-5-5는 가장 빠른 첫 번째 가시적 토큰(2,981ms)을 보여주었지만 가장 긴 총 소요 시간(12,384ms)을 기록했습니다. deepseek-v4.1-flash는 가시적 텍스트를 더 늦게 시작(3,925ms)했지만 가장 먼저 완료(5,204ms)했습니다. 무엇이 더 빠르게 느껴지는지는 사용자가 스트림을 지켜보는지 아니면 전체 답변을 기다리는지에 따라 다릅니다. 단일 클라이언트에서의 5회 실행으로는 귀하의 워크로드에 대해 결론을 내릴 수 없습니다.

스트리밍 응답이 텍스트 없이 돌아온 이유는 무엇인가요?

아마도 예산을 추론에 모두 사용했을 것입니다. max_tokens 400에서 deepseek-v4.1-flash는 400개의 추론 토큰을 사용하고 약 0개의 가시적 토큰을 반환했습니다. 최종 usage 청크의 usage.completion_tokens_details.reasoning_tokens와 finish_reason을 확인하십시오. 그런 다음 제한을 높이십시오. 2000으로 설정했을 때 테스트한 두 추론 모델 모두 완전한 답변을 제공했습니다.

더 빠른 모델이 속도 제한을 높여주나요?

아니요. 속도 제한 가이드에 따르면 모델 속도, 토큰 제한, 계정 속도 제한은 별개의 제약 사항입니다. 더 빠른 스트림은 더 빨리 완료되어 동시성 슬롯을 비워주지만, 키당 요청 제한은 그대로 유지됩니다. 제한을 높여야 한다면 지원팀에 문의하십시오.

스트림이 느릴 때 지원팀에 어떤 ID를 보내야 하나요?

request_id(또는 X-Request-ID), 엔드포인트, 메서드, 모델, 타임스탬프 및 상태 코드를 보내십시오. 비동기 작업의 경우 task_id와 poll_url을, 있는 경우 billing_transaction_id를 추가하십시오. 분할 타이밍과 안전한 오류 본문을 포함하고, 키, 프롬프트, 개인 미디어는 먼저 삭제하십시오.

귀하의 프롬프트로 위 도구를 실행한 다음, 측정 결과를 TokenLab 모델 순위와 비교하십시오.