TTFT와 초당 토큰 수로 보는 LLM 응답 속도 측정법

초당 토큰 수는 무엇을 측정하며, TTFT와 어떻게 다를까요?

출력 속도를 나타내는 초당 토큰 수는 첫 토큰이 도착한 뒤 LLM이 생성한 토큰을 얼마나 빠르게 전달하는지 측정합니다. 대규모 언어 모델인 LLM은 텍스트를 토큰 단위로 처리합니다. 토큰은 단어 하나일 수도 있고, 단어의 일부나 문장 부호일 수도 있습니다. 따라서 토큰 수를 어떤 경우에나 통하는 단어 수로 볼 수는 없습니다. Cerebras의 정의에서도 이 차이를 분명히 설명합니다.

도서관에 들어가 필요한 책을 차례로 받는 상황을 생각해 보겠습니다. 문이 열리기를 기다리는 시간과 책을 건네받는 속도는 서로 다릅니다. 그리고 두 가지 모두 필요한 책을 전부 챙겨 나올 수 있는 시점에 영향을 줍니다. 책을 아무리 빨리 건네받아도 문밖에서 오래 기다렸던 시간이 사라지지는 않습니다.

애플리케이션에서는 다음 지표를 구분해 측정해야 합니다.

측정 구간은 Artificial Analysis의 지표 정의를 따릅니다. 첫 추론 토큰이 첫 답변 토큰보다 먼저 도착할 수 있으므로, 두 시간을 구분해서 불러야 합니다.

애플리케이션의 종단 간 지연 시간은 사용자가 행동을 시작한 순간부터 유용한 결과를 얻는 순간까지입니다. 음성 어시스턴트라면 실제로 음성이 들리는 시점, 에이전트라면 동작이 완료되는 시점이 될 수 있습니다. 정보 검색, 툴 실행, 음성 합성, 인터페이스 갱신은 모델 요청 구간 밖에서 이뤄지기도 합니다. 이 전체 과정에도 측정 지점을 마련해야 합니다.

모델 내부의 기본 처리 단계는 프롬프트를 처리하는 **프리필(prefill)**과 이어질 내용을 생성하는 **디코드(decode)**입니다. LLM 추론 해설에서는 서빙 시스템 안에서 이 작업이 어떻게 진행되는지 살펴봅니다.

속도 수치 하나만 보면 왜 판단을 잘못할까요?

속도 측정값은 특정 엔드포인트가 특정 워크로드를 처리한 결과입니다. 어떤 조건에서도 성립하는 모델 고유의 특성이 아닙니다. 작업이나 서빙 조건이 달라지면 비교 대상 자체가 달라집니다.

프롬프트 길이와 컨텍스트 캐시

짧은 질문만 담긴 고객 상담 채팅과 긴 대화 이력에 검색한 정책 문서까지 담긴 채팅은 서로 다릅니다. 입력이 늘어나면 답변 전 처리해야 할 작업도 달라집니다. Groq는 지연 시간 최적화 가이드에서 입력 크기를 TTFT에 영향을 주는 요인으로 꼽습니다.

테스트 기록에는 프롬프트 길이와 캐시 상태를 남겨야 합니다. KV 캐시 해설은 생성 과정에서 재사용하는 어텐션 상태와 프롬프트 재사용이 캐싱과 맺는 관계를 설명합니다. 캐시가 준비된 상태에서 같은 프롬프트를 반복한 결과를 별다른 설명 없이 새로운 고객 대화의 성능으로 제시해서는 안 됩니다.

답변에 앞서 진행되는 추론

추론 모델은 답변을 내놓기 전에 중간 토큰을 생성할 수 있습니다. 생성 속도가 빠르다는 사실만으로 추론을 얼마나 오래 할지는 알 수 없습니다. 발표된 속도에 추론 스트림이 포함되는지, 첫 토큰 타이머가 추론 텍스트와 답변 텍스트 중 어디에서 멈추는지 확인해야 합니다.

예약 어시스턴트에서 의미 있는 시점은 활용 가능한 답변이나 툴 호출이 나오는 순간입니다. 화면의 ‘생각 중’ 표시는 요청을 받았다는 사실을 알려 줄 수 있지만, 예약을 완료해 주지는 않습니다.

배치 처리와 동시 요청 부하

배치 처리는 여러 작업을 묶어 하드웨어 활용도를 높입니다. 전체 처리량은 여러 요청의 출력을 합산하고, 사용자별 속도는 개별 요청에 전달되는 스트림을 나타냅니다. Cerebras는 배치 처리가 처리량을 높이는 동시에 대기 시간을 늘릴 수 있다고 설명합니다. 출처: Cerebras의 처리량 설명.

운영자가 확인해야 할 것은 다른 대화가 들어와도 각 대화의 응답이 계속 원활하게 이어지는지입니다. 실패한 요청과 재시도를 포함해 실제 사용 환경을 대표하는 동시 트래픽으로 측정해야 합니다. 다른 요청이 거의 없는 엔드포인트에서 좋은 결과가 나왔다는 것만으로는 이 질문에 답할 수 없습니다.

리전과 응답 전달 경로

애플리케이션과 서빙 엔드포인트의 위치는 네트워크 지연에 영향을 줍니다. Groq는 네트워크 분석 안내에서 서버 측 측정 시간과 클라이언트가 체감하는 지연을 구분합니다.

백엔드가 실행되는 리전에서 시간을 재야 합니다. 앱이 스트림을 프록시를 거쳐 브라우저로 전달한다면 브라우저에서도 측정해야 합니다. 그 사이의 버퍼링 때문에 상위 서버에서 매끄럽게 이어진 응답이 화면에는 덩어리째 나타날 수 있습니다. 이 전달 경로를 개선하는 일이 모델을 바꾸는 것보다 중요할 수도 있습니다.

GPU별 초당 토큰 수는 어떻게 비교해야 할까요?

추론을 실행하는 가속기인 GPU에는 모델과 워크로드에 관계없이 적용할 수 있는 단일 초당 토큰 수가 없습니다. 하드웨어를 비교하려면 결과와 함께 모델, 수치 정밀도, 컨텍스트, 서빙 설정, 동시 요청 부하를 제시해야 합니다.

양자화는 수치 정밀도를 낮춰 메모리를 절약합니다. 이때 속도와 품질 사이의 절충 관계는 구현 방식에 따라 달라집니다. Cerebras는 모델 압축 설명에서 이 차이를 다룹니다. 압축된 모델의 배포 구성을 비교할 때는 LLM 양자화 가이드를 참고하고, 시간 측정과 함께 답변 품질도 확인해야 합니다.

공급사가 발표하는 속도 수치는 어떻게 읽어야 할까요?

공개된 속도는 발표 주체, 모델, 확인 날짜가 붙은 주장으로 읽어야 합니다. 다음 공급사 페이지는 2026년 10월 24일에 확인했습니다. 아래 수치는 공급사가 제시한 값이며, 이 글을 위해 직접 측정한 결과가 아닙니다.

Cerebras: 공개 속도와 실제 배포 조건을 함께 봐야 합니다

추론 서비스 공급사 Cerebras는 Developer 표에서 OpenAI GPT-OSS 120B의 속도를 **“~3000 tokens/s”**로 제시합니다. 같은 페이지는 성능이 모델과 설정에 따라 달라지며, Developer 이용은 프로덕션보다 평가 용도를 위한 것이라고 설명합니다. 출처: Cerebras 요금 안내.

실제로 따져야 할 것은 구매 가능한 배포 구성이 내 워크로드를 필요한 응답성과 처리 용량으로 감당하는지입니다. 표만으로는 알 수 없습니다.

Groq의 초당 토큰 수는 해당 모델의 행에서 확인합니다

추론 서비스 공급사 Groq는 지원 모델 표의 OpenAI GPT-OSS 120B 행에서 “SPEED (T/SEC)” 항목을 **“500”**으로 표시합니다. 이는 Groq가 해당 행에 대해 공개한 수치입니다. 출처: Groq 지원 모델.

이 표들을 근거로 공급사 간 애플리케이션 속도가 몇 배 차이 난다고 말할 수는 없습니다. 그런 주장을 하려면 프롬프트, 추론 설정, 토큰 집계 방식, 부하, 측정 구간부터 맞춰야 합니다.

속도와 비용을 함께 판단하려면 Cerebras 요금 가이드와 Groq 요금 가이드를 참고해 성공적으로 끝난 작업당 비용과 필요한 처리 용량을 비교합니다.

독립적인 LLM 추론 속도 측정 결과는 어디서 볼 수 있을까요?

독립 벤치마크 서비스인 Artificial Analysis는 모델과 추론 서비스 공급사를 비교할 때 유용한 출발점입니다. 공급사 리더보드를 열어 보고, 각 결과에 사용된 엔드포인트와 워크로드를 확인합니다.

현재 성능 측정 방법론에 명시된 조건은 다음과 같습니다.

• 기본 워크로드는 약 10,000개의 입력 토큰과 최소 1,500개의 답변 토큰으로 구성됩니다.
• 일반적인 워크로드의 결과는 최근 72시간 동안의 중앙값으로 표시합니다.
• 주 테스트 서버는 Google Cloud의 us-central1-a 영역에 있습니다.
• 성능 측정에 쓰는 토큰 수는 모델별 고유 토크나이저 대신 **o200k_base**로 정규화합니다.

이는 공통된 비교 기준이지, 내 애플리케이션의 성능을 보장하는 약속은 아닙니다. 결과를 비교하기 전에 프롬프트 크기, 엔드포인트, 추론 모드, 날짜를 확인해야 합니다. 프롬프트가 길어지면 첫 토큰 지연과 출력 속도가 모두 달라질 수 있습니다.

추론 토큰 일부를 공개하지 않는 추론 모델의 경우, Artificial Analysis는 **답변 청크 중 마지막 80%**를 기준으로 출력 속도를 계산합니다. 아래의 간단한 스크립트는 그 방식이나 벤치마크의 전체 워크로드를 재현하지 않습니다. 클라이언트에서 관측한 텍스트 스트림을 측정하는 예제입니다.

실제 스트리밍 응답은 어떻게 측정할까요?

응답을 받는 클라이언트에서 측정하고, 스트리밍 이벤트가 아닌 텍스트 토큰을 세야 합니다. 이벤트에는 텍스트가 없을 수도 있고 여러 텍스트 조각이 한꺼번에 담길 수도 있습니다. 이벤트 수를 세면 초당 토큰 수가 아니라 초당 청크 수가 됩니다.

다음 Python 예제는 Groq 스트리밍 API와 텍스트 토크나이저인 tiktoken을 사용합니다. 첫 텍스트 청크 도착까지의 지연, 요청부터 마지막 텍스트까지 걸린 시간, 스트림 완료 시간, 정규화된 초당 출력 토큰 수의 추정치를 출력합니다.

필요한 패키지를 설치합니다.

python3 -m pip install groq tiktoken

환경 변수에 GROQ_API_KEY를 설정합니다. Groq 지원 모델 목록에서 자신의 계정으로 이용할 수 있는 비추론 텍스트 모델을 골라 GROQ_MODEL로 지정하고, 실제 애플리케이션을 대표하는 프롬프트를 prompt.txt에 넣습니다. 다음 코드를 measure_stream.py로 저장한 뒤 python3 measure_stream.py를 실행합니다.

import os
from pathlib import Path
from time import perf_counter

import tiktoken
from groq import Groq

encoder = tiktoken.get_encoding("o200k_base")
prompt = Path("prompt.txt").read_text(encoding="utf-8")
model = os.environ["GROQ_MODEL"]
parts = []
first = last = None

with Groq(max_retries=0) as client:
    start = perf_counter()
    stream = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
        stream=True,
    )
    for event in stream:
        now = perf_counter()
        if not event.choices:
            continue
        text = event.choices[0].delta.content or ""
        if not text:
            continue
        if first is None:
            first = now
        last = now
        parts.append(text)
    end = perf_counter()

if first is None:
    raise SystemExit("No text received; no text-speed measurement.")

# Tokenize after timing; never count events as tokens.
count = lambda text: len(encoder.encode(text, disallowed_special=()))
total_tokens = count("".join(parts))
post_first_tokens = total_tokens - count(parts[0])
span = last - first

print(f"First text chunk / TTFT estimate (s): {first - start:.3f}")
print(f"Request to last text (s): {last - start:.3f}")
print(f"Stream complete (s): {end - start:.3f}")
print(f"Normalized output tokens: {total_tokens}")
if span > 0 and post_first_tokens > 0:
    print(f"Post-first output tok/s (estimate): {post_first_tokens / span:.1f}")
else:
    print("Output tok/s unavailable: insufficient text delivery intervals.")

Groq SDK는 자동 재시도를 끌 수 있도록 지원합니다. 이 예제도 재시도를 비활성화합니다. 성공한 측정값에 재시도 대기 시간이 드러나지 않은 채 섞이는 것을 막기 위해서입니다. 실패한 요청은 실패로 기록해야 합니다.

속도를 계산할 때는 토큰 수와 전달 시간 양쪽에서 첫 텍스트 청크를 제외합니다. 이는 Artificial Analysis의 정의에 나온 청크 기반 계산식을 따릅니다. 마지막 텍스트가 도착한 시점을 찾을 때도 뒤따르는 메타데이터는 제외합니다.

이 예제는 일반 텍스트에 사용합니다. 추론 스트림, 툴 호출 인자, 오디오는 각각의 이벤트 유형을 별도로 처리하고, 유용한 첫 출력이 무엇인지 정의해야 합니다. 비교할 때는 프롬프트와 설정을 유지하고 출력 길이를 기록한 뒤, 배포 리전에서 실제 환경을 대표하는 부하를 걸어 반복 측정합니다. 일반적인 결과와 느린 결과를 모두 남겨야 합니다. 가장 빨랐던 측정값을 성능 보장처럼 제시해서는 안 됩니다.

초당 토큰 수 계산기와 시뮬레이터로 무엇을 알 수 있을까요?

계획을 돕는 툴은 가정한 시간이 어떤 결과로 이어지는지 보여 줄 수 있습니다. 하지만 내 엔드포인트의 실제 지연 시간을 알아내 주지는 못합니다.

초당 토큰 수 시뮬레이터는 어디에 쓸까요?

시뮬레이터를 활용하면 채팅 인터페이스가 텍스트를 도착하는 대로 보여 줘야 할지, 완성된 객체를 받을 때까지 기다려야 할지 논의할 수 있습니다. 그런 다음 실제 관측한 스트림으로 설계를 검증해야 합니다. 일정한 속도를 가정한 시뮬레이션만으로는 실제 응답이 중간에 멈추는지, 한꺼번에 몰려오는지, 툴 실행을 기다리는지 알 수 없습니다.

텍스트 응답이 완료된 경우 시간 관계는 단순합니다. 요청부터 마지막 텍스트까지의 시간은 초기 대기 시간과 첫 텍스트부터 마지막 텍스트까지의 시간을 더한 값입니다. 위 스크립트는 광고된 속도에서 이를 추정하는 대신, 두 구간을 각각 측정합니다.

초당 토큰 수는 어느 정도면 충분할까요?

적절한 목표는 해당 작업에서 어디에 대기가 생기는지에 따라 달라집니다. 만들고 있는 사용자 경험에 관한 다음 질문에 답하면서 기준을 정합니다.

음성 서비스를 만든다면: 통화 중인 사용자가 말을 마친 뒤 유용한 답변을 듣기까지 얼마나 기다리는지 확인합니다. 전체 답변이 작성되기 전에 음성 재생을 시작할 수 있습니까? 오디오 버퍼가 비는 순간이 있습니까? 사용자가 말을 끊고 끼어들 수 있습니까? 텍스트 출력이 시작되기 전의 침묵이 문제라면, 디코드 속도를 높여도 핵심 문제는 그대로일 수 있습니다.

채팅 서비스를 만든다면: 사용자가 기다리는 것은 처음으로 도움이 되는 문장입니까, 전체 설명입니까, 아니면 유효한 구조화 결과입니까? 인터페이스에서 일부 출력을 먼저 보여 줄 수 있습니까? 고객 문의 답변과 내보내기용 보고서는 완료 기준이 다릅니다. 인터페이스에 필요한 완료 시점을 측정해야 합니다.

에이전트를 운영한다면: 작업 시간 중 모델 생성과 툴 실행이 각각 얼마나 차지하는지 확인합니다. 응답이 빨라져도 툴 인자의 정확성과 작업 성공 여부가 유지됩니까? 다음 단계가 전체 출력을 기다립니까? 엉뚱한 구간을 개선하면 워크플로 전체 완료 시간은 거의 줄지 않을 수 있습니다.

추론 서비스를 도입한다면: 제안받은 배포 구성이 내 트래픽, 리전, 프롬프트 조건에서 필요한 사용자 경험을 유지할 수 있는지 확인합니다. 제시된 수치가 해당 배포 구성의 일반적인 결과입니까? 요청이 실패하거나 처리 용량이 부족해지면 어떻게 됩니까?

실행 추적 기록에서 사용자가 생성이나 첫 유효 답변을 기다리고 있다는 사실이 확인되면 개선에 착수합니다. 가장 큰 지연이 어디서 발생하는지 아직 분리해 내지 못했다면 공급사 이전은 미룹니다. 이미 마감 시간 안에 끝나는 백그라운드 작업이라면, 처리량이나 성공한 작업당 비용이 판단을 바꾸지 않는 한 더 빠른 공개 수치의 영향은 크지 않습니다.

LLM 속도에서 과장되는 부분은 무엇일까요?

가장 큰 과장은 출력 속도가 가장 높은 엔드포인트가 애플리케이션에도 가장 좋다는 주장입니다. 속도만으로 답변 품질, 출력의 유효성, 툴 사용의 성공 여부를 알 수는 없습니다.

아무리 빠른 엔드포인트라도 주변 애플리케이션의 한계에 부딪힙니다. 텍스트를 더 빨리 생성해도 느린 데이터베이스 호출, 불필요하게 긴 추론 과정, 검증에 실패하는 응답은 해결되지 않습니다. 반대로 첫 토큰 수치가 아무리 좋아도 사용자가 쓸 만한 결과를 받기 전에 스트림이 멈추는 문제를 가릴 수 있습니다.

속도는 계속 평가하되, 최종 기준은 정확하고 활용 가능한 결과를 얻었는지에 둡니다.

자주 묻는 질문

다음 개발 단계에서는 무엇을 해야 할까요?

다음 개선 작업에서는 실제 사용을 대표하는 음성 대화 한 차례, 채팅 프롬프트, 에이전트 작업을 골라 결과를 활용할 수 있게 되는 기준을 정합니다. 그 시점을 첫 출력과 스트림 완료 시점과 함께 측정합니다. 같은 작업으로 후보 엔드포인트를 비교하고, 실패 사례를 검토한 뒤, 사용자를 기다리게 하는 구간을 최적화합니다.

유용한 AI 애플리케이션을 만드는 실전 가이드를 받아 보려면 뉴스레터를 구독하세요.