AI 응답 속도, 첫 글자와 마지막 글자는 다른 문제다

AI 서비스가 빠르다는 말에는 여러 경험이 섞여 있습니다. 질문을 보낸 뒤 첫 글자가 빨리 보이는 것과, 긴 답변이 빨리 끝나는 것은 다릅니다. 많은 사용자가 동시에 쓸 때 서버가 처리하는 양도 또 다른 지표입니다.

성능 발표를 읽을 때는 첫 토큰까지의 시간, 토큰 생성 속도, 서버 전체 처리량 중 무엇을 측정했는지 먼저 확인하는 편이 좋습니다.

입력을 읽는 프리필, 답을 이어 쓰는 디코드

NVIDIA의 추론 최적화 문서는 LLM 추론을 프리필과 디코드로 나눕니다. 프리필은 입력 토큰을 처리하는 단계입니다. 디코드는 앞서 처리한 문맥과 생성 결과를 사용해 다음 출력 토큰을 순서대로 만드는 단계입니다.

문서는 프리필의 병렬 연산과 디코드의 데이터 이동 특성을 구분합니다. 또 이전 계산을 재사용하기 위한 KV 캐시를 설명합니다. 따라서 연산 성능 숫자 하나가 모든 응답 구간의 속도를 그대로 나타낸다고 보기는 어렵습니다.

이 구분은 기본적인 생성 과정을 설명하는 출발점입니다. 실제 서비스에는 요청 대기, 네트워크, 도구 호출, 캐시, 배칭 같은 조건이 함께 들어갑니다.

가상의 두 서비스는 어느 쪽이 빠를까

출력 200토큰을 만드는 두 서비스를 가정해 보겠습니다. A는 첫 토큰까지 1초, 이후 생성 속도는 초당 20토큰입니다. B는 첫 토큰까지 3초, 이후 속도는 초당 50토큰입니다. 일정한 속도로 나머지 199토큰을 만든다고 단순화합니다. 실제 서비스의 측정값이 아닙니다.

구분	첫 토큰까지	나머지 199토큰 생성	전체 시간
서비스 A	1초	약 9.95초	약 10.95초
서비스 B	3초	약 3.98초	약 6.98초

A는 먼저 쓰기 시작하지만, 이 조건에서 200토큰의 답변을 끝내는 것은 B가 빠릅니다. “빠르다”는 표현을 쓰기 전에 어떤 구간의 경험을 말하는지 정해야 하는 이유입니다.

사용자 한 명과 서버 전체의 기준

여러 요청을 함께 처리하는 배칭은 장치의 활용과 전체 처리량에 영향을 줍니다. 다만 서버가 초당 많은 토큰을 처리한다는 정보만으로, 개별 사용자가 항상 더 짧게 기다린다고 결론 낼 수는 없습니다. 요청 수와 대기 조건을 확인해야 합니다.

그래서 비교표를 만들 때는 모델, 입력 길이, 출력 길이, 동시 요청 수, 사용 장치와 정밀도 설정을 같은 칸에 기록하는 것이 좋습니다. 조건이 다른 두 결과에서 성능 배수만 가져오면 실제 사용에서 무엇이 개선됐는지 남지 않습니다.

비용까지 읽으려면 추가로 필요한 것

Finpost의 관점에서는 추론 최적화를 서비스 비용과 연결해 읽되, 성능 개선율을 비용 절감률로 곧바로 바꾸지 않는 것이 중요합니다. 장치 가격, 활용률, 운영 시간과 사용량이 함께 있어야 그 연결을 확인할 수 있기 때문입니다.

다음 성능 발표를 읽을 때는 “얼마나 빠른가”와 함께 “무엇을, 어떤 조건에서, 얼마나 기다리며 처리했는가”를 적어두겠습니다. 그래야 기술 설명과 사업 해석 사이의 빈칸이 보입니다.