긴 입력에서는 로컬 LLM 속도 순위가 뒤집힐 수 있습니다

우리가 빨리 끝내고 싶은 것은 무엇일까요?

가령 퇴근 후 긴 회의록을 정리하려고 장비를 알아보고 있다고 해봅시다. 낮에는 시간이 없어서 미뤄 두었던 일입니다. 문서에서 결정된 내용과 아직 남은 일만 추려 주면 됩니다. 긴 답변도 필요 없습니다. 내일 아침에 다시 읽을 몇 문단이면 충분합니다.

이때 필요한 것은 화면에 글자가 가장 빠르게 쏟아지는 컴퓨터일까요? 아니면 문서를 넣고 얼마 지나지 않아 필요한 정리를 내놓는 컴퓨터일까요? 비슷해 보이지만, 장비를 비교할 때는 다른 질문입니다.

성능표에는 우리가 처리할 회의록도, 내일 아침까지 정리해야 하는 사정도 없습니다. 주어진 조건에서 측정한 숫자가 있을 뿐입니다. 그 숫자를 내 상황에 맞게 읽는 일은 아직 남아 있습니다. 비싼 쪽을 고르기 전에 이 차이부터 확인해 보겠습니다.

먼저 짧은 질문을 보내 보겠습니다

이 글의 A와 B는 원리를 설명하기 위한 가상 장비입니다. 특정 제품의 실측값은 아닙니다. 같은 모델로 같은 질문에 약 300토큰짜리 답변을 만든다고 가정하겠습니다.

A는 첫 토큰까지 4초를 기다린 뒤 초당 60토큰을 씁니다. 답변을 이어 쓰는 데 약 5초가 더 걸리니 전체는 약 9초입니다. B는 첫 토큰까지 6초, 이후 초당 30토큰이므로 전체는 약 16초입니다.

이 조건에서는 A가 먼저 끝납니다. 다만 토큰 생성 속도는 두 배여도, 전체 시간이 정확히 절반인 것은 아닙니다. 답변 전의 기다림이 따로 있기 때문입니다.

여기서 60 tok/s와 30 tok/s는 답변이 시작된 뒤의 생성 속도, 즉 디코드 속도입니다. 첫 토큰까지 걸린 시간은 따로 더했습니다. 계산은 이해를 돕기 위해 반올림한 근삿값입니다. 표에서 흔히 보는 큰 숫자 하나가 아니라, 사용자가 기다린 시간을 처음부터 끝까지 세어 본 것입니다.

질문 대신 긴 문서를 넣으면 어떨까요?

이번에는 두 장비에 같은 긴 문서를 넣고, 답변 길이는 아까와 같은 약 300토큰으로 맞춰 봅시다. 문서를 처리한 결과 A의 첫 토큰이 40초 뒤에, B의 첫 토큰이 10초 뒤에 나온다고 가정하겠습니다. 답변이 시작된 뒤의 속도는 그대로입니다.

A는 약 40초를 기다리고 5초 동안 답하므로 총 45초가 걸립니다. B는 10초를 기다리고 10초 동안 답하므로 총 20초입니다. 토큰을 쓰는 속도는 여전히 A가 빠른데, 작업은 B가 먼저 끝났습니다.

장비 성능이 갑자기 바뀐 것은 아닙니다. 우리가 시킨 일이 달라진 겁니다. 짧은 질문에서는 잘 드러나지 않던 입력 처리 시간이 긴 문서에서 큰 비중을 차지합니다.

긴 입력을 처리하는 단계를 프리필이라고 합니다. 첫 토큰까지의 시간에는 이 단계 외에도 요청 대기나 실행 준비가 들어갈 수 있습니다. 여기서는 그 시간을 모두 합쳐 비교했습니다. 실제 장비에서도 늘 B가 유리하다는 이야기가 아니라, 같은 디코드 순위만으로 다른 작업의 결과까지 알 수는 없다는 뜻입니다.

그렇다면 첫 토큰이 빠른 장비가 더 좋을까요?

이번에도 답변 길이를 봐야 합니다. 문서에서 날짜 하나만 찾는다면 답변이 짧으니 첫 토큰까지의 기다림이 중요합니다. 반대로 긴 초안을 써 달라고 하면 답변을 이어 쓰는 시간이 커집니다.

즉, 첫 토큰과 디코드 중 하나만 고르면 같은 문제가 반복됩니다. 내가 자주 넣는 입력의 길이와 받고 싶은 답변의 길이를 함께 맞춰야 합니다. 앞의 가상 예도 다른 길이로 바꾸면 차이가 달라집니다.

캐시도 확인해야 합니다. 이미 읽은 문서를 재사용한 결과와 처음 읽는 문서의 결과를 섞으면 장비 차이와 캐시 효과를 구분하기 어렵습니다.

기다릴 수 있는 시간도 작업마다 다릅니다

밤에 문서 수십 개를 맡겨 두고 아침에 결과를 받는다면 한 요청이 몇 초 늦게 시작하는 것은 큰 문제가 아닐 수 있습니다. 전체 작업이 제시간에 끝나고 중간에 실패하지 않는지가 더 중요할 겁니다.

반면 코드를 조금 고쳐 달라고 묻고, 결과를 보고, 다시 질문하는 작업은 다릅니다. 답변을 기다리는 동안 다음 판단도 멈춥니다. 한 번의 대기보다 그 대기를 하루에 몇 번 반복하는지가 장비 선택에 더 큰 영향을 줄 수 있습니다.

그렇다고 모두에게 통하는 합격선을 몇 초로 정하기는 어렵습니다. 읽으면서 따라가기에는 충분한 속도라도, 긴 결과를 복사해서 쓰려는 사람에게는 느릴 수 있습니다. 내가 괜찮다고 느끼는 지점을 먼저 알아야 성능표의 차이에 얼마를 더 낼지도 판단할 수 있습니다.

잠깐 신기해서 눌러 보는 도구와 다음 날에도 다시 여는 도구는 다를 수 있습니다. 구매 전에 확인하려는 것은 첫날의 감탄만이 아니라, 반복해서 쓸 때도 견딜 만한 기다림인지입니다.

내가 할 작업으로 두 번 비교해 보세요

먼저 짧은 질문에서 토큰 생성 속도만 비교합니다. 그다음 평소 넣을 문서에 가까운 길이로 바꾸고, 프리필을 포함해 다시 봅니다. 두 결과에서 같은 장비가 앞서는지 확인하세요.

이 사이트의 비교 화면에서는 입력 길이와 프리필 포함 여부를 바꿀 수 있습니다. 표시되는 것은 예상 체감이므로 실제 실행 기록과는 구분해야 하지만, 답변 전의 기다림을 포함했을 때 선택이 달라지는지 살펴볼 수 있습니다.

살 장비를 정할 때 필요한 질문은 ‘어느 쪽의 tok/s가 더 높은가’에서 끝나지 않습니다. ‘내가 자주 시킬 일을 어느 쪽이 더 빨리 끝내는가’까지 이어져야 합니다.

두 배 빠르다는 이유만으로 두 배를 쓸 필요는 없습니다

이제 처음의 속도표로 돌아가 봅시다. A가 초당 60토큰, B가 30토큰이라는 사실은 틀리지 않았습니다. 다만 회의록을 정리하려던 사람에게 그 사실만으로 구매 결론을 내리기에는 부족했습니다.

문서를 넣을 때의 기다림까지 비교했더니 저렴한 쪽이 내 작업에 충분할 수도 있습니다. 반대로 매번 긴 답변을 끝까지 기다려야 한다면 더 빠른 쪽에 비용을 쓰는 이유가 분명해질 수도 있습니다. 중요한 것은 어느 결론이 나오든, 내가 할 일로 확인했다는 점입니다.

답변의 내용도 빼놓을 수 없습니다. 빠르게 나온 요약이 중요한 결정을 빠뜨린다면 다시 원문을 읽어야 합니다. 속도를 비교할 때 같은 모델을 쓰는 이유이고, 장비를 정하기 전에 그 모델이 내 문서를 제대로 다루는지도 살펴봐야 하는 이유입니다.

우리가 처음 하려던 일은 가장 높은 숫자를 갖는 것이 아니라, 미뤄 둔 회의록을 정리하는 것이었습니다. 그 일을 충분히 잘 끝낼 수 있다면 더 비싼 장비를 사지 않아도 됩니다. 반대로 지금 가진 장비에서 막히는 구간을 찾았다면, 그때는 무엇을 바꾸기 위해 돈을 쓰는지 알 수 있습니다.

장비 두 대를 골라 같은 문서를 처리하는 상황으로 비교해 보세요. 결과가 생각보다 비슷하다면 그것도 도움이 되는 답입니다. 남는 예산을 굳이 성능표의 다음 칸에 쓸 이유는 없으니까요.