[기획: AI 트렌드] 짧은 호출에선 안 보이던 제곱 비용, vLLM의 도구 호출 파서가 모델마다 따로 고쳐졌다

10월 16일과 17일에 머지된 PR 두 건

10월 16일, vLLM에 PR 하나가 머지됐습니다. vLLM은 AI 모델을 서버에서 돌려 사용자 요청에 답하게 해 주는 오픈소스 프로그램입니다. PR은 코드 수정 요청이고, 그 요청을 본 코드에 합치는 일이 머지입니다.

이 PR이 고친 것은 MiniMax M2 모델의 도구 호출을 다루는 코드입니다. 도구 호출(툴콜)은 모델이 프로그램 기능을 불러 쓰려고 내놓는 출력입니다. 「이 파일에 이 내용을 써라」가 한 예입니다. 이때 함께 넘기는 파일 이름과 내용을 인자라고 합니다.

모델은 답을 한 번에 내놓지 않고 생기는 대로 조금씩 내놓습니다. vLLM은 이 출력을 그대로 흘려보내는 스트리밍 방식도 씁니다. 채팅 화면에 답이 몇 글자씩 이어 나오는 것이 그 예입니다. 한 번에 오는 한 토막을 이 글에서는 조각이라고 부릅니다(PR의 용어로는 델타). 모델이 조각으로 내놓은 글자를 프로그램이 쓸 수 있는 형식으로 풀어 주는 코드가 파서입니다. 도구 호출의 인자도 조각이 올 때마다 파서가 풀어서 내보냅니다.

PR 제목 끝에는 「16 KB 호출: 5.9초에서 26밀리초로」라는 수치가 붙어 있습니다. 이 시간은 사용자가 기다린 시간이 아닙니다. 호출 하나를 흘려보내는 동안 파서가 쓴 CPU 시간의 합입니다. CPU는 컴퓨터의 일반 계산을 맡는 칩이고, 밀리초는 천분의 일 초입니다. KB는 데이터 크기 단위로, 영문 글자 천 자 남짓이 1 KB입니다. 다음 날인 17일에는 같은 작성자가 Qwen3 모델의 파서에 같은 수정을 넣은 PR도 머지됐습니다.

조각마다 처음부터

MiniMax M2 PR이 적은 원인은 이렇습니다. 새 조각이 올 때마다 인자 전체를 처음부터 다시 처리했습니다. 인자 내용을 변환하는 코드도, 어디까지 내보내도 되는지 살피는 검사도 매번 전체를 훑었습니다.

받아쓰기에 빗대면, 한 단어를 받아 적을 때마다 공책 첫 줄부터 다시 읽는 셈입니다. 공책이 한 쪽일 때는 티가 나지 않습니다. 열 쪽이 되면 다시 읽는 시간이 받아 적는 시간을 훨씬 넘습니다.

같은 문제를 앞서 GLM 모델의 파서에서 고친 PR에 그 비용이 잡혀 있습니다. 인자가 25 KB까지 쌓이는 동안 조각 하나의 처리 시간은 평균 1밀리초대였고, 200 KB 근처에서는 12밀리초대였습니다. 고친 뒤에는 길이와 상관없이 거의 일정했습니다. 작성자가 Apple M4 Pro 칩에서 파서만 잰 시간입니다.

조각 하나의 비용이 그때까지 받은 길이를 따라 커지고, 조각 수도 길이만큼 늘어납니다. 그러면 호출 전체 비용은 길이의 제곱에 가깝게 커집니다(우리 계산). 길이가 두 배면 네 배, 열 배면 백 배입니다. PR도 이를 제곱으로 늘어나는 CPU 비용이라고 적었습니다.

MiniMax M2 PR의 측정에서도 이 곡선이 보입니다. 호출이 4 KB에서 16 KB로 네 배 길어지자 파서 CPU 시간의 합은 387밀리초에서 5.9초로 약 15배가 됐습니다(우리 계산). 16 KB에서 32 KB로 두 배 길어지자 22.6초로 약 3.8배가 됐습니다(우리 계산). 제곱이면 16배와 4배입니다. 작성자 측정이고, 하드웨어는 적혀 있지 않습니다.

짧을 때는 안 보였다

다음 날 머지된 Qwen3 PR에는 짧은 호출의 측정도 있습니다. 인자 항목이 셋뿐인 호출은 호출 전체로 고치기 전 338마이크로초, 고친 뒤 304마이크로초였습니다. 마이크로초는 밀리초의 천분의 일입니다. 거의 그대로입니다. 같은 PR의 12 KB 호출은 호출 전체로 2.1초에서 11밀리초가 됐습니다. 두 측정 모두 작성자가 Apple M5 칩에서 파서만 잰 시간입니다. 짧은 인자는 다시 훑을 앞부분도 짧아, 고치기 전에도 비용이 작았던 것입니다(우리 판단).

PR이 긴 인자의 예로 든 것은 파일 쓰기와 코드 수정입니다. 이런 호출에서는 파일에 들어갈 내용이 통째로 인자에 담깁니다(우리 판단). 에이전트, 즉 사람 대신 여러 단계를 이어 가며 일하는 AI 프로그램이 코드를 고칠 때 쓰는 호출입니다(우리 판단). 인자 항목 몇 개짜리 호출에서는 차이가 없던 처리가, 다른 PR의 16 KB 파일 쓰기 호출에서는 합해서 초 단위였습니다.

이 계산은 GPU(AI 계산을 맡는 칩)가 아니라 API 서버의 CPU에서 돕니다. API 서버는 요청을 받아 모델에 넘기고 결과를 돌려보내는 앞단 프로그램입니다. 그 서버는 이벤트 루프로 일합니다. 여러 요청의 일을 한 번에 하나씩 번갈아 처리하는 장치로, 하던 일이 끝나야 다음 일로 넘어갑니다. GLM PR은 이 계산이 그 이벤트 루프 안에서 돌기 때문에 같은 서버의 다른 요청도 늦춘다고 적었습니다. 막는 단위는 5.9초 전체가 아니라 조각 하나를 처리하는 시간입니다(우리 판단). 그 지연의 크기를 잰 수치는 우리가 연 PR들에 없습니다.

모델마다 한 번씩, 네 번

같은 수정은 한 번으로 끝나지 않았습니다. 우리가 확인한 첫 수정은 10월 12일 GLM 모델의 파서에 머지됐습니다. 이 PR은 조각마다 인자 전체를 다시 처리하지 않게 하는 장치를 새로 넣었습니다. 그 장치는 파서마다 따로 켜야 했고, 이 PR에서 켠 파서는 GLM 하나였습니다.

10월 14일에는 Gemma4 모델의 파서에 같은 수정이 머지됐습니다. 이때 다른 문제도 드러났습니다. 쉼표나 괄호 같은 구분 기호가 없는 인자 내용은 조금씩 나가지 않고, 그 내용이 끝나는 순간에야 한 덩어리로 도착했습니다.

앞의 MiniMax M2와 Qwen3 PR이 세 번째와 네 번째입니다. Qwen3 PR에는 MiMo 모델용 변형도 들어갔습니다. 네 건 모두 같은 사람(sfeng33)이 머지했습니다. 파서가 모델마다 따로 있고 새 장치도 파서마다 켜야 했으니, 같은 수정이 모델마다 반복된 것입니다(우리 판단).

대가도 있었습니다. Gemma4 PR은 파서 시간만 따로 재서 코드와 줄글(보통 문장으로 쓴 글)을 견줬습니다. 가장 긴 코드 인자의 파서 시간은 7초 남짓에서 0.15초로 줄었습니다. 같은 길이의 줄글은 28밀리초에서 87밀리초로 오히려 늘었습니다. 그 줄글 인자는 고치기 전 네 번에 나뉘어 나갔고, 고친 뒤에는 토큰마다 내보내 수천 번으로 나뉘었습니다. 토큰은 모델이 글을 잘게 자른 단위입니다. 고치기 전 줄글이 빨랐던 것은 조금씩 보내지 않고 끝에 몰아 보냈기 때문입니다(우리 판단). PR은 늘어난 시간이 여전히 작고 길이에 비례한다고 적었습니다.

MiniMax M2와 Qwen3 PR은 출력이 바뀌지 않았는지를 차분 테스트로 확인했습니다. 고치기 전과 후의 파서에 같은 무작위 호출을 넣고, 조각마다 결과를 맞대 보는 시험입니다. 두 PR 모두 수만 개의 무작위 호출에서 조각별 출력이 같았다고 적었습니다. Gemma4는 출력이 나뉘는 방식 자체를 바꾼 수정이라 이 시험과는 경우가 다릅니다(우리 판단).

잰 것과 안 잰 것

이 시리즈의 수치는 모두 작성자가 파서만 따로 돌려 잰 것입니다. Qwen3 PR 작성자는 GPU 서버 전체로는 돌려 보지 못했다고 적었습니다. 그 PR에는 모델을 GPU에 올려 요청부터 답까지 재는 시험이 없었다는 뜻입니다. GLM PR도 GPU 서빙 환경에서 끝까지 돌린 측정은 없다고 적었습니다.

MiniMax M2 PR을 머지한 sfeng33은 실제 모델로 성능 향상을 확인했다고 남겼습니다. 그 수치는 적혀 있지 않습니다. 그래서 사용자가 받는 답이 얼마나 빨라졌는지는 우리도 말할 수 없습니다(우리 판단).

수정이 들어간 모델이 모두 몇인지도 세지 못했습니다. 비슷한 PR을 찾는 검색에서 우리가 연 것은 앞부분 일부뿐입니다. vLLM과 같은 일을 하는 다른 프로그램은 확인하지 않았습니다. 이 시리즈가 실릴 릴리스, 즉 사용자가 내려받아 설치하는 정식 판도 확인하지 못했습니다. 가장 최근 릴리스는 이 시리즈보다 앞서 나왔습니다.

앞선 글에서 우리는 답을 채점하는 테스트로는 효율의 결함이 보이지 않는다고 봤습니다답은 맞았고 GPU마다 전문가가 전부 실려 있었다, transformers에 그것을 확인하는 테스트가 추가됐다. 이번 시리즈는 출력이 같은지는 차분 테스트로 확인하고, 비용은 따로 쟀습니다. 앞으로 볼 것은 이 수정이 실릴 릴리스와, 다른 모델의 파서에도 같은 수정이 들어가는지입니다.

우리는 이번 일에서 속도 수치보다 곡선을 봅니다. 짧은 호출 하나로 잰 속도는 고치기 전과 후가 거의 같았습니다. 같은 코드의 문제는 길이를 바꿔 가며 잰 측정에서 곡선으로 드러났습니다. 한 길이에서 잰 속도가 아니라, 길이에 따라 비용이 어떻게 늘어나는지를 봐야 이런 결함이 보입니다(우리 판단).