로컬 LLM 초당 토큰 처리량 측정 및 비용 효율성 계산법

초당 토큰 처리량이 GPU 비용 효율성을 결정하는 이유

초당 토큰 처리량(tokens per second)은 서버가 출력 텍스트를 생성하는 속도이며, GPU를 대여하는 것이 API 토큰당 비용을 지불하는 것보다 저렴한지 결정하는 기준입니다. GPU 박스는 사용 중이든 유휴 상태든 시간 단위로 요금이 청구됩니다. 반면 호스팅된 API는 토큰 단위로 요금이 청구됩니다. 따라서 GPU가 비용 효율적이려면 비용을 지불하는 시간 대부분 동안 충분히 높은 출력 속도를 유지해야 합니다.

즉, 어딘가에서 읽은 수치가 아니라 직접 측정한 데이터가 필요합니다. 이 페이지에서는 기록할 가치가 있는 4가지 수치를 정의하고, 해당 수치를 산출하는 명령어와 이를 바탕으로 의사결정을 내리는 계산식을 설명합니다.

공개된 초당 토큰 처리량 수치가 실제 사용자의 수치가 아닌 이유

DigitalOcean은 2026년 7월, vLLM 환경에서 FP8(8비트 부동 소수점)로 구동되는 단일 NVIDIA H200의 llama3.3-70b-instruct 처리량 수치를 발표했습니다. 이 수치는 유용하지만, 사용자의 실제 환경과는 다릅니다.

[
  {
    "config": "H200, one stream",
    "tok_s": "47"
  },
  {
    "config": "H100, saturated",
    "tok_s": "236"
  },
  {
    "config": "H200, saturated",
    "tok_s": "2,036"
  },
  {
    "config": "H200, saturated, in+out",
    "tok_s": "4,071.6"
  }
]

위 표의 모든 행은 해당 페이지에서 인용되었으며, 그중 두 개는 제시된 범위의 하한값이므로 이를 최솟값으로 이해해야 합니다. 이 차트의 어떤 수치도 우리가 직접 측정한 것이 아닙니다.

마지막 두 행부터 살펴보겠습니다. 헤드라인 수치는 4,071.6 tok/s이며, 출력 전용 속도는 2,036 tok/s입니다. 헤드라인 수치는 입력 토큰과 출력 토큰을 합산한 결과입니다. 해당 테스트는 1,024개의 입력 토큰과 1,024개의 출력 토큰을 사용했으므로, 헤드라인 수치의 거의 절반이 출력에 해당합니다. 이 구분이 중요한 이유는 출력은 비용이 청구되는 절반이자, 더 느린 절반이기 때문입니다. 프리필(프롬프트 읽기)은 모든 입력 토큰을 한 번에 처리합니다. 디코드(답변 작성)는 한 번에 하나의 토큰을 생성합니다. 총 처리량 헤드라인은 저렴한 수치와 비싼 수치를 평균 낸 값입니다.

이제 첫 번째 행을 보겠습니다. 동일한 H200이 한 번에 하나의 요청을 처리할 때는 47 tok/s를 생성하므로, 포화 상태의 수치는 동일한 하드웨어에서 40배 이상 높습니다. 이러한 격차가 발생하는 이유는 단일 디코드 단계에서 GPU가 대부분의 시간을 메모리 대기 상태로 보내기 때문이며, 동시 요청이 그 유휴 시간을 채워주기 때문입니다. 두 번째 행인 236 tok/s는 동일한 모델을 구동하는 단일 H100의 수치로, KV 캐시(키 및 값 캐시, 서비스 중인 대화가 카드에 유지하는 요청별 메모리)에 의해 제한됩니다. 80 GB 카드는 70B 모델에 대해 더 적은 수의 동시 요청을 수용하므로, 포화 지점이 더 낮습니다.

모델을 변경하거나 입력 대 출력 비율을 바꾸면 위의 모든 수치는 변합니다. 공개된 수치는 기대치를 설정하기 위한 것이지 예산을 결정하기 위한 것이 아니며, 이는 VPS의 디스크 및 네트워크 성능을 정직하게 벤치마킹하는 것과 동일한 원칙이 적용됩니다.

중요한 4가지 지표

• TTFT (Time to first token). 요청을 보낸 시점부터 첫 번째 출력 토큰이 도착할 때까지의 지연 시간입니다. 프리필(prefill) 시간과 대기열(queue) 시간을 합친 값입니다. 사용자가 직접 체감하는 지표입니다.
• 스트림당 초당 출력 토큰 수 (Output tokens per second, per stream). 답변 생성이 시작된 후 얼마나 빠르게 작성되는지를 나타냅니다. 약 20 tok/s를 넘어가면 대부분의 사람이 읽는 속도보다 빠르므로, 그 이상의 속도는 큰 의미가 없습니다.
• 포화 상태의 총 출력 처리량 (Saturated total output throughput). 서버가 완전히 부하된 상태에서 모든 동시 스트림을 합친 처리량입니다. 이는 서버의 용량을 나타내는 수치이며, GPU 비용을 정당화하는 기준이 됩니다.
• 동시성 환경에서의 p50 및 p99 TTFT. p50은 중간값 요청을 의미합니다. p99는 100개의 요청 중 99개가 이 값 이내로 처리됨을 의미합니다. 대기열 지연은 항상 p99에서 가장 먼저 나타납니다.

앞의 두 지표는 서버가 한가할 때 개선됩니다. 세 번째 지표는 서버가 바쁠 때 개선됩니다. 이들은 서로 상충하는 관계에 있으므로, 단 하나의 수치만으로 서버의 성능을 설명할 수 없습니다.

측정 전 입력 및 출력 길이를 고정하십시오

처리량은 트래픽의 형태에 따라 달라집니다. 4,000 토큰의 프롬프트에 50 토큰의 답변이 나오는 작업은 프리필(prefill) 비중이 높습니다. 반면 200 토큰의 프롬프트에 2,000 토큰의 답변이 나오는 작업은 디코드(decode) 비중이 높습니다. 동일한 서버라도 이 두 경우의 초당 토큰 처리량(tokens per second)은 크게 다르므로, 하나의 비율을 선택하여 기록하는 모든 수치 옆에 명시하고 서로 다른 비율 간에는 비교하지 마십시오. 여러 벤더가 해당 비율로 성능을 공개하므로 1,024 토큰 입력에 1,024 토큰 출력을 기본값으로 사용하는 것이 합리적입니다. 실제 트래픽을 알고 있다면 그 값을 사용하십시오.

출력 길이도 강제로 고정해야 합니다. 60 토큰 만에 정지 토큰(stop token)에 도달하는 모델은 실행 시간이 짧아져 더 빠르게 보일 수 있는데, 이는 전체 시간에서 TTFT가 차지하는 비중이 커지기 때문입니다. vLLM 벤치마크 클라이언트의 --ignore-eos 플래그를 사용하면 모든 요청이 정확히 지정된 수만큼 생성되므로 두 번의 실행 결과를 비교할 수 있습니다. 어떤 플래그보다도 모델 선택이 이러한 수치에 더 큰 영향을 미칩니다. Qwen 3 모델을 단일 VPS GPU에 맞추기에서 해당 선택의 메모리 측면을 다룹니다.

단일 스트림 측정 우선

가장 단순한 사례부터 시작합니다. 이는 정상 작동 여부를 확인하는 검증 절차이자 성능의 상한선을 파악하는 과정입니다. Ollama는 자체적인 타이밍 정보를 출력합니다.

ollama run llama3.1:8b --verbose "Write 200 words about disk scheduling."

확인해야 할 항목은 eval rate으로, 초당 출력 토큰 수를 의미합니다. prompt eval rate는 프리필(prefill) 속도이며, load duration는 모델을 VRAM에 로드하는 데 소요된 시간입니다. 콜드 스타트 후 첫 번째 호출에서는 load duration 값이 크기 때문에 total duration 수치는 왜곡될 수 있습니다. 명령을 두 번 실행한 뒤 두 번째 결과를 확인하십시오. Ollama는 기본적으로 5분 동안 유휴 상태인 모델을 메모리에서 해제하므로, 실행 간격이 길어지면 다시 콜드 스타트 상태가 됩니다.

동일한 필드 정보는 API를 통해서도 얻을 수 있으며, 이 방식이 스크립트로 작성하기에 더 용이합니다.

curl -s http://127.0.0.1:11434/api/generate -d '{
  "model": "llama3.1:8b",
  "prompt": "Write 200 words about disk scheduling.",
  "stream": false
}' | jq '{eval_count, eval_duration,
         tok_s: (.eval_count / (.eval_duration / 1000000000))}'

eval_duration은 나노초 단위이므로 1,000,000,000으로 나누면 초 단위가 됩니다. 이 나눗셈은 Ollama 공식 API 문서에서 초당 토큰 수를 계산하기 위해 권장하는 방식 그대로입니다. 서버가 아직 준비되지 않았다면 Ollama를 이용한 VPS 기반 LLM 셀프 호스팅 문서를 참조하여 설치 및 systemd 유닛 설정을 진행하십시오.

TTFT를 측정하려면 스트리밍 요청이 필요하며, curl 명령어를 사용하여 시간을 측정할 수 있습니다.

curl -s -o /dev/null -N \
  -w 'ttfb=%{time_starttransfer}s  total=%{time_total}s\n' \
  http://127.0.0.1:8000/v1/chat/completions \
  -H 'Content-Type: application/json' \
  -d '{"model":"Qwen/Qwen3-8B",
       "messages":[{"role":"user","content":"Write 200 words about disk scheduling."}],
       "stream":true,"max_tokens":256}'

time_starttransfer는 응답 본문의 첫 번째 바이트가 도착하는 시점입니다. 스트리밍 채팅 완료 요청에서 해당 바이트는 첫 번째 서버 전송 이벤트(SSE)에 해당하며, 이는 첫 번째 콘텐츠 토큰이거나 그 직전에 전송된 역할 정보 전용 델타입니다. 따라서 이 값을 오차 범위 내의 TTFT로 간주하십시오. 동일한 서버에서 두 번의 실행 결과를 비교하기에는 충분히 정확한 수치입니다.

단일 스트림 수치는 서버의 성능을 실제보다 높게 평가하게 만듭니다. TTFT는 앞서 대기 중인 요청이 없으므로 최상의 상태를 나타냅니다. 스트림당 속도 역시 전체 GPU 자원을 하나의 요청에만 사용하므로 최상의 수치가 나옵니다. 이 두 지표만으로는 서버가 감당할 수 있는 전체 부하를 판단할 수 없습니다.

동시성 스윕(concurrency sweep)은 어떻게 실행합니까?

스윕은 하나의 고정된 워크로드를 동시성을 높여가며 실행하고 각 단계에서 발생하는 결과를 기록합니다. vLLM은 이를 위한 클라이언트를 제공하며, 이 클라이언트는 OpenAI API를 사용하므로 Ollama를 비롯한 OpenAI 호환 서비스에서도 작동합니다.

vllm bench serve \
  --backend openai-chat \
  --base-url http://127.0.0.1:8000 \
  --endpoint /v1/chat/completions \
  --model Qwen/Qwen3-8B \
  --dataset-name random \
  --random-input-len 1024 \
  --random-output-len 1024 \
  --ignore-eos \
  --num-prompts 160 \
  --max-concurrency 16 \
  --percentile-metrics ttft,tpot,itl,e2el \
  --metric-percentiles 50,99

--max-concurrency은 진행 중인 요청 수를 제한하며, 스윕할 변수입니다. --num-prompts은 전송된 총 요청 수이므로, 안정적인 평균값을 얻으려면 동시성의 약 10배 정도로 유지하십시오. 요약 결과에는 Output token throughput (tok/s):와 Total token throughput (tok/s):이 출력되며, Time to First Token 헤더 아래에 Mean TTFT (ms):, Median TTFT (ms):, P99 TTFT (ms):이 표시됩니다.

출력 결과에 스트림당 속도는 포함되어 있지 않지만, 간단한 나눗셈으로 구할 수 있습니다. Mean TPOT (ms):은 첫 번째 토큰 이후의 토큰당 평균 처리 시간입니다. 예를 들어 토큰당 25 ms라면 스트림당 초당 40 토큰을 처리하는 것입니다. 전체 출력 처리량을 동시성으로 나누어도 같은 결과가 나옵니다.

그런 다음 루프를 사용하여 각 실행 결과를 저장하십시오.

for C in 1 4 16 32 64 128; do
  vllm bench serve \
    --backend openai-chat \
    --base-url http://127.0.0.1:8000 \
    --endpoint /v1/chat/completions \
    --model Qwen/Qwen3-8B \
    --dataset-name random \
    --random-input-len 1024 \
    --random-output-len 1024 \
    --ignore-eos \
    --num-prompts $(( C * 10 )) \
    --max-concurrency "$C" \
    --percentile-metrics ttft,tpot,itl,e2el \
    --metric-percentiles 50,99 \
    --save-result --result-filename "sweep-c$C.json"
done

for f in sweep-c*.json; do
  jq -r --arg f "$f" \
    '[$f, .output_throughput, .total_token_throughput,
      .median_ttft_ms, .p99_ttft_ms] | @tsv' "$f"
done

동시성 스윕(concurrency sweep)은 실제로 무엇을 보여주는가?

[
  {
    "label": "1 stream",
    "per_stream_tok_s": 92,
    "total_tok_s": 92,
    "ttft_p50_ms": 48,
    "ttft_p99_ms": 61
  },
  {
    "label": "4 streams",
    "per_stream_tok_s": 88,
    "total_tok_s": 352,
    "ttft_p50_ms": 71,
    "ttft_p99_ms": 96
  },
  {
    "label": "16 streams",
    "per_stream_tok_s": 71,
    "total_tok_s": 1136,
    "ttft_p50_ms": 152,
    "ttft_p99_ms": 244
  },
  {
    "label": "32 streams",
    "per_stream_tok_s": 54,
    "total_tok_s": 1728,
    "ttft_p50_ms": 287,
    "ttft_p99_ms": 498
  },
  {
    "label": "64 streams",
    "per_stream_tok_s": 34,
    "total_tok_s": 2176,
    "ttft_p50_ms": 611,
    "ttft_p99_ms": 1240
  },
  {
    "label": "128 streams",
    "per_stream_tok_s": 18,
    "total_tok_s": 2304,
    "ttft_p50_ms": 1490,
    "ttft_p99_ms": 3820
  }
]

6개의 행은 소규모 대여 GPU 박스에서 스윕이 만들어내는 형태를 그럴듯한 자릿수로 예시한 것입니다. 이는 귀하의 서버를 측정한 결과가 아니며, 벤더가 제공하는 수치도 아닙니다. 위의 루프를 실행하여 귀하의 환경에 맞는 값으로 대체하십시오.

형태를 읽어내십시오. 일반화할 수 있는 것은 바로 그 형태이기 때문입니다. 1개의 스트림에서 전체 박스는 초당 92개의 토큰을 생성하며, p99 TTFT는 61 ms입니다. 128 streams에 도달하면 총 처리량은 25배 높은 초당 2304개의 토큰에 이르지만, 개별 스트림의 속도는 초당 18개의 토큰으로 떨어지고 p99 TTFT는 3820 ms가 됩니다. 배치 처리가 유휴 메모리 대기 시간을 유용한 작업으로 전환하기 때문에 총 처리량은 상승합니다. 동일한 연산 자원을 공유하게 되므로 스트림당 속도는 하락합니다.

마지막 두 배 증가 구간이 핵심입니다. 64개에서 128개 스트림으로 늘리면 총 처리량은 6퍼센트 미만으로 증가하는 반면, p99 TTFT는 대략 3배가 됩니다. 이는 KV 캐시가 가득 차서 요청이 실행되지 못하고 대기열에 쌓이고 있음을 의미합니다. 유용한 운영 지점은 그보다 앞선 구간입니다. 32개 스트림에서 해당 박스는 여전히 최대치의 75퍼센트인 초당 1728개의 토큰을 반환하며, 스트림당 초당 54개의 토큰과 p99 TTFT 498 ms를 기록합니다. 이 지점을 귀하의 용량으로 보고하십시오. 곡선의 정점은 실제 사용자에게 서비스를 제공할 수 있는 수치가 아닙니다.

Ollama와 vLLM은 동일한 지표를 측정하지 않습니다

기본 설정의 Ollama 서버를 대상으로 스윕(sweep)을 실행하면 전체 수치는 거의 변하지 않습니다. OLLAMA_NUM_PARALLEL의 기본값은 1이므로, 하나의 요청이 실행되는 동안 나머지는 대기하게 되며, 이 대기열로 인해 p99 TTFT는 상승하지만 전체 출력량은 일정하게 유지됩니다. 측정하기 전에 이 값을 높이십시오.

sudo systemctl edit ollama.service

[Service]
Environment="OLLAMA_NUM_PARALLEL=8"

sudo systemctl restart ollama 설정을 적용하여 재시작한 뒤, 모델이 여전히 메모리에 적재되는지 확인하십시오. 각 병렬 슬롯은 컨텍스트 윈도우의 일부를 점유하므로, Ollama 문서에 따르면 2K 컨텍스트에서 4개의 병렬 요청을 처리할 경우 8K의 메모리가 할당됩니다. 슬롯 수를 너무 많이 높이면 모델이 VRAM 밖으로 밀려납니다. ollama ps을 확인하십시오. PROCESSOR 열의 값이 48%/52% CPU/GPU과 같이 표시된다면 모델의 일부가 CPU에 올라와 있다는 의미이며, 이 경우 동시성을 높여도 처리량은 증가하지 않고 오히려 감소합니다. 병렬 슬롯을 초과한 요청은 기본값인 512개의 OLLAMA_MAX_QUEUE 대기열에 쌓이며, 이를 넘어서면 서버는 503 오류를 반환합니다.

vLLM은 연속 배치(continuous batching) 방식을 사용하므로 슬롯이 비는 즉시 새로운 요청을 실행 중인 배치에 포함하며, KV 캐시가 소진될 때까지 성능 곡선이 계속 상승합니다. Ollama는 단일 모델, 단일 머신, 낮은 설정 비용에 최적화되어 있습니다. 따라서 두 엔진은 동일한 스윕에 대해 서로 다른 결과를 도출하며, 이는 서빙 엔진으로서의 Ollama와 vLLM 비교에서 다루는 핵심 주제입니다. 모든 수치를 기록할 때는 어떤 엔진과 어떤 버전을 사용했는지 반드시 명시하십시오.

잘못된 지표를 측정하는 5가지 경우

• 클라이언트가 너무 멀리 있습니다. 인터넷을 통해 노트북에서 벤치마크를 수행하면 모든 TTFT에 왕복 지연 시간이 추가되므로, 결국 본인의 인터넷 연결 상태를 측정하게 됩니다. 클라이언트는 서버와 동일한 리전에서 실행하십시오.
• 모델이 준비되지 않았습니다(Cold). 첫 번째 요청은 가중치 로딩 비용을 발생시키며, vLLM의 경우 그래프 캡처 비용이 추가될 수 있습니다. 워밍업 배치를 먼저 보내고 그 결과는 폐기하십시오.
• 프리픽스 캐싱(Prefix caching)이 대신 응답했습니다. vLLM은 기본적으로 자동 프리픽스 캐싱을 활성화하므로, 동일한 프롬프트를 반복해서 보내면 프리필(prefill)이 아닌 캐시 성능을 측정하게 되어 TTFT가 실제 값보다 훨씬 낮게 나옵니다. --dataset-name random은 모든 프롬프트가 다르기 때문에 이러한 문제를 방지합니다. 확실하게 하려면 --no-enable-prefix-caching 옵션으로 서버를 시작하십시오.
• 출력 길이가 너무 짧습니다. 32토큰 정도의 답변만 사용하면 각 요청에서 TTFT가 지배적인 비중을 차지하게 되어, 초당 토큰 수(tokens per second) 지표가 사실상 프리필 성능만을 나타내게 됩니다. 현실적인 출력 길이를 설정하여 --ignore-eos를 사용하십시오.
• 동시성(concurrency)을 1로 보고했습니다. 이는 표에서 가장 보기 좋은 숫자일 뿐이며, 실제 비용과는 아무런 관련이 없습니다.

측정된 수치를 바탕으로 의사결정하기

단일 스트림 속도가 아닌 스윕(sweep)을 통해 얻은 포화 출력 처리량(saturated output throughput)을 토큰당 가격과 비교하십시오. 손익분기점은 다음 나눗셈으로 계산합니다.

break_even_tok_s = (price_per_hour / price_per_million_output_tokens) * 1000000 / 3600

DigitalOcean의 2026년 7월 가격을 예로 들어 계산해 보겠습니다. H200 전용 추론 엔드포인트는 시간당 $4.47였고, 서버리스 방식은 100만 토큰당 $0.65였습니다. 4.47을 0.65로 나누면 시간당 688만 토큰이 되며, 이를 3,600초로 나누면 초당 약 1,910개의 출력 토큰이 나옵니다. 가격은 해당 업체의 기준이며, 나눗셈은 직접 수행한 것입니다.

이 결정의 핵심 단어는 지속성(sustained)입니다. 하루에 2시간 동안 포화 상태에서 초당 1,910 토큰을 처리한다고 해서 이를 초당 1,910 토큰의 지속적인 처리량이라고 할 수는 없습니다. 나머지 22시간에 대해서도 비용을 지불해야 하기 때문입니다. DigitalOcean의 시간당 $3.44 GPU Droplet을 기준으로 할 때 손익분기점은 72.2%의 지속적인 평균 사용률에서 발생하며, 이보다 낮으면 토큰당 가격 모델이 더 유리합니다. 자가 호스팅의 수익성을 떨어뜨리는 주된 요인은 토큰 처리 속도가 아니라 유휴 GPU 시간입니다.

따라서 의사결정에는 두 가지 입력값이 필요합니다. 스윕 결과는 처리량의 상한선을 제공합니다. 트래픽 패턴은 그 상한선 중 실제로 활용하는 비율을 결정합니다. 두 값을 곱한 뒤 그 결과를 GPU VPS와 토큰당 API 비용의 손익분기점에서 확인하여 귀하의 트래픽 규모에 맞는 답을 얻으십시오.

FAQ

자체 호스팅 LLM에서 적절한 초당 토큰(tokens per second) 처리량은 어느 정도입니까?

이 지표는 두 가지 역할을 하므로 답변도 두 가지입니다. 한 명의 사용자가 출력물을 읽는 경우, 스트림당 초당 약 20 토큰 이상이면 읽기 속도보다 빠르므로 그 이상의 속도는 의미가 없습니다. 비용 측면에서는 포화 상태의 총 출력 처리량이 중요하며, 손익분기점을 넘기는 수준이 적절합니다. 2026년 7월 가격 기준으로 시간당 $4.47인 서버에서 100만 토큰당 $0.65의 비용이 발생한다면, 지속적인 출력 처리량은 초당 약 1,910 토큰 이상이어야 합니다. 대규모 모델에서 단일 스트림으로는 이 수치에 도달할 수 없으며, 이것이 배칭(batching)이 존재하는 이유입니다.

동시 요청을 추가해도 왜 Ollama의 처리량이 그대로인가요?

OLLAMA_NUM_PARALLEL의 기본값은 1이므로, 서버는 모델당 한 번에 하나의 요청만 처리하고 나머지는 큐에 대기시킵니다. 대기열이 OLLAMA_MAX_QUEUE(기본값 512)에 도달하면 503 오류를 반환합니다. GPU가 바쁜 상태가 아니라 큐에 쌓여 있다는 신호로, 총 출력량은 그대로 유지되면서 p99 TTFT(Time To First Token)는 상승합니다. systemd 드롭인 파일에서 해당 변수를 설정하고 재시작하십시오. 그 후 ollama ps를 확인해야 합니다. 병렬 슬롯이 늘어날 때마다 할당된 컨텍스트가 곱해지며 모델의 일부가 CPU로 밀려날 수 있기 때문입니다.

첫 토큰 생성 시간(TTFT)과 초당 토큰 처리량 중 무엇을 측정해야 합니까?

둘 다 측정해야 합니다. 부하가 증가함에 따라 두 지표는 반대 방향으로 움직이기 때문입니다. TTFT는 사용자가 체감하는 성능이며, 포화 상태의 출력 처리량은 청구서 비용에 반영됩니다. 동시성 단계별로 p50 및 p99 TTFT를 기록한 뒤, p99 TTFT가 허용 가능한 범위 내에 있는 가장 높은 동시성을 선택하십시오. 해당 지점의 처리량을 시스템의 용량으로 보고해야 하며, 성능 곡선 최상단의 최대치를 용량으로 삼아서는 안 됩니다.

초당 토큰 처리량이 높으면 항상 토큰당 비용이 낮아집니까?

아닙니다. 토큰당 비용은 시간당 서버 비용을 해당 시간에 실제로 생성된 토큰 수로 나눈 값입니다. 따라서 속도가 빠른 서버라도 하루 중 대부분 유휴 상태라면 토큰당 비용은 높게 유지됩니다. 비용을 결정하는 것은 최대 속도가 아니라 가동률(utilisation)입니다. 단위도 주의 깊게 확인하십시오. 명시된 총 토큰 처리량은 입력 토큰을 포함하므로, 입력과 출력 비율이 1:1인 경우 실제 청구 대상인 출력 속도의 거의 두 배에 달할 수 있습니다.