[기획: AI 트렌드] 8,192칸마다 처음부터 센 동률 개수, vLLM의 빠른 top-p 경로가 후보 토큰을 더 남겼다

10월 17일에 머지된 PR 두 건

10월 17일, vLLM에 PR 두 건이 머지됐습니다. vLLM은 AI 모델을 서버에서 돌려 사용자 요청에 답하게 해 주는 오픈소스 프로그램입니다. PR은 코드 수정 요청이고, 그 요청을 본 코드에 합치는 일이 머지입니다. 버그 수정 한 건과 속도 개선 한 건이 고친 곳은 같은 코드, top-p 샘플링의 빠른 경로입니다.

모델은 글을 토큰 단위로 이어 씁니다. 토큰은 모델이 글을 잘게 자른 조각입니다. 다음 토큰을 낼 때마다 모델은 후보 토큰 전부에 확률을 매기고, vLLM은 그 확률에 따라 하나를 고릅니다. 이 고르기가 샘플링입니다. 이번 이슈와 새 테스트의 측정에서 후보 토큰은 15만 개 남짓이었습니다.

top-p는 고르기 전에 후보를 줄이는 규칙입니다. 확률이 높은 순으로 후보를 세우고 확률을 차례로 더해, 합이 처음으로 p 이상이 되는 후보까지만 남기고 그 안에서 고릅니다. 득표 순으로 줄을 세워, 누적 득표가 기준선에 닿는 데까지만 결선에 올리는 것과 같습니다. 마지막으로 남는 후보의 확률을 경계 확률이라고 합니다.

빠른 경로는 9월 3일 vLLM에 들어온 별도의 GPU 커널입니다. GPU는 AI 계산을 맡는 칩이고, 커널은 GPU에서 도는 계산 프로그램입니다. 한 번에 묶어 처리하는 확률 목록들을 배치, 그 목록 하나를 행이라고 합니다. top-k는 확률 상위 k개만 남기는 다른 규칙입니다. 빠른 경로는 배치가 64행 이하일 때, 그 안에서 top-k 없이 top-p만 쓰는 행을 맡습니다. top-k를 함께 쓰는 행은 기존 커널이 처리합니다. NVIDIA GPU에서 vLLM은 FlashInfer라는 별도 라이브러리로 샘플링하는데, 이것을 끄거나 요청마다 난수 생성기를 따로 쓰는 경우 등에 빠른 경로를 탑니다. AMD GPU 일부도 이 경로를 탑니다. vLLM을 쓰는 사람 누구나 지나는 길은 아닙니다.

8,192칸마다 처음부터 센 개수

빠른 경로는 행 하나의 후보 목록을 몇 토막으로 나눠 GPU의 여러 SM에 함께 맡깁니다. SM은 GPU 안에서 각자 계산을 돌리는 연산 단위입니다. 토막을 맡은 프로그램은 그 토막을 다시 후보 8,192칸짜리 블록으로 끊어 하나씩 차례로 훑습니다. 블록과 블록이 맞닿는 곳이 이음매입니다.

확률이 경계 확률과 정확히 같은 후보가 여럿일 때가 있습니다. 이런 후보들이 동률입니다. 합이 p에 닿는 데 동률 가운데 몇 개만 있으면 되므로, 앞 번호부터 그 개수만큼만 남깁니다. 그래서 커널은 동률 후보를 몇 개 지났는지 세면서 이음매를 넘어가야 합니다.

고치기 전 코드는 이 개수를 블록이 바뀔 때마다 처음부터 다시 셌습니다. 예를 들어 동률을 다섯 개만 남겨야 하는데 그 동률이 한 토막 안의 블록 세 곳에 흩어져 있으면, 블록마다 최대 다섯 개씩, 모두 합쳐 최대 열다섯 개까지 남길 수 있는 셈입니다(우리가 든 예). 그래서 이 결함은 후보를 더 남기는 쪽으로만 났고, 토막 하나가 블록 하나보다 클 때만 났습니다. 고친 코드는 앞 블록까지 센 개수를 다음 블록으로 넘겨 이어 셉니다. 행을 나누지 않고 처리하는 기존 커널이 이미 하던 방식입니다.

버그를 알린 이슈(공개 버그 게시글)에는 합성 재현이 실려 있습니다. 경계 동률 수천 개를 여러 블록에 흩어 놓자, 고치기 전 커널은 정답 1,913개 대신 4,160개를 남겼습니다. 남긴 후보의 확률 합은 정답이 70%, 고치기 전 커널이 99.4%였습니다. 이 합성 행에서는 동률을 사실상 모두 남겨, 확률로 따지면 거의 잘라 내지 못했습니다(우리 판단). 넘치는 확률은 많아야 동률 묶음 전체의 확률만큼입니다. 고친 뒤에는 정답과 같아졌습니다. 이 수치는 작성자가 잰 후보 개수이고, 응답 품질을 잰 것이 아닙니다.

작은 테스트에는 이음매가 없었다

동률 처리를 확인하는 테스트는 이미 있었습니다. 그 테스트로는 이 버그가 드러나지 않았습니다. 배치가 네 행뿐이면 행 하나를 32토막으로 잘게 나눠, 토막 하나가 4,008칸으로 블록 하나에 다 들어갔습니다. 토막 안에 이음매가 아예 없었습니다. 동률이 한 블록 안에 있으면 고치기 전 코드도 정답을 냈습니다. 개수를 다시 셀 이음매가 없으니 틀릴 일도 없었습니다(우리 판단).

이슈 작성자는 한 토막의 여러 블록에 동률을 흩은 테스트였다면 이 버그를 잡았을 것이라고 적었습니다. 수정 PR에는 블록마다 동률을 흩은 새 테스트가 들어갔습니다.

이슈 작성자는 실제 행에서도 경계 동률이 흔하다고 적었습니다. 그는 MiMo 모델이 추측 디코딩 검증 단계에서 낸 실제 행 1,424개를 B300 GPU에서 커널에 넣어 살폈습니다. p를 0.95로 잡자, 확률이 경계 확률과 같은 후보가 둘 이상인 행이 550개였고, 동률은 많아야 86개였습니다. 이 모델의 점수는 bf16이라는 거친 숫자 형식이라 같은 값이 자주 겹칩니다. 고친 효과도 쟀습니다. 64행 배치에서 top-p만 쓰는 1,386행 가운데, 남긴 개수가 틀린 행이 327개에서 8개로 줄었습니다. 정답은 더 정밀한 계산으로 따로 구했습니다. 남은 8행의 원인은 작성자도 밝히지 못했습니다.

같은 경로를 더 빠르게 한 사람이 찾았다

이 버그를 이슈로 올린 사람은 abmfy입니다. abmfy는 이슈에 「버그를 찾고 재현 코드를 쓰고 이 이슈의 초안을 잡는 데 AI 보조(Claude Code)를 썼다」고 밝혔습니다. 버그를 고친 PR은 다른 기여자인 cipheraxat이 썼습니다. 두 PR을 머지한 njhill은 이 빠른 경로를 들여온 9월 3일 PR의 작성자이고, 그 PR 본문에는 AI 모델 Kimi K3로 「바이브 코딩」했다는 문장이 있습니다.

버그 수정과 같은 날 머지된 속도 개선 PR의 저자도 abmfy입니다. 그 PR 본문은 동률 버그를 원래 있던 별개 버그로 적었습니다. 이 PR은 행이 많아지면 행마다 나눌 토막 수가 줄던 문제를 고쳤습니다. SM이 148개인 GPU에서는 38행부터 토막이 둘로 줄어 처리 시간이 약 두 배가 됐습니다. 이제 토막마다 후보가 충분히 남는 동안 토막을 계속 더 잘게 나누고, top-p만 쓰는 행이 없으면 이 경로를 건너뜁니다. 작성자는 토막이 짧아지면 동률 버그도 덜 드러난다고 적었지만, 줄었을 뿐 사라지지는 않았습니다.

작성자가 B300·H200 GPU에서 top-p만 쓰는 합성 행으로 이 커널만 따로 잰 결과, 배치 크기에 따라 최대 약 1.9배 빨라졌습니다. 서버 전체 측정에서는 요청마다 seed(난수 시작값)를 건 top-p 조건에서 토큰이 하나씩 나오는 간격의 중앙값이 약 5% 줄었습니다. Llama-3-8B 모델을 B300에서 동시 요청 48개로 돌린 결과입니다. seed를 걸지 않은 대조군과 다른 모델의 서버 전체 측정에서는 차이가 잡음 안이었습니다.

작성자는 경계에서 남는 후보 집합이 동률 처리와 확률을 더하는 순서에 따라 달라질 수 있다는 대가도 적었습니다. 새 건너뛰기 표시를 쓰지 않는 MRV1이라는 실행 구성에서, 모든 행이 top-k를 쓰는 배치는 0.90~0.98배로 오히려 느려졌습니다.

잰 것과 안 잰 것

수정 PR 작성자는 모델 평가로는 이 변경을 잴 수 없었다고 적었습니다. 평가에 쓴 수학 문제 설정(gsm8k)이 빠른 경로를 지나지 않았기 때문입니다. 우리가 연 원문 어디에도 이 결함이 응답 품질을 얼마나 바꿨는지 잰 결과는 없습니다.

빠른 경로가 이제 정확해졌다고 보기도 이릅니다. 동률 버그 이슈의 본문은 관련은 있지만 별개인 결함으로, 머지가 확인되지 않은 PR 세 건과 열린 이슈 한 건을 들었습니다. 머지 다음 날인 10월 18일 나온 새 릴리스(사용자가 내려받는 정식 판)의 노트에도 이 경로 이야기는 없어, 이번 수정이 실릴 릴리스는 아직 모릅니다.

앞선 글에서 우리는 답을 채점하는 테스트로 효율의 결함이 보이지 않는다고 봤는데답은 맞았고 GPU마다 전문가가 전부 실려 있었다, transformers에 그것을 확인하는 테스트가 추가됐다, 이번에는 반대로 빠른 경로의 작은 테스트로 정확성의 결함이 보이지 않았습니다. 앞으로 볼 것은 이 수정이 실릴 릴리스와, 같은 경로에 남은 결함 PR들의 머지입니다.

우리는 이번 일에서 결함의 크기보다 그것이 드러난 조건을 봅니다. 이번에 이음매를 넘는 입력을 만든 사람은 토막을 나누는 방식을 고치던 사람이었습니다. 속도를 위해 일을 블록으로 나누면, 이음매를 넘어 이어 가야 하는 개수가 생깁니다. 그 개수가 끊긴 결함은 이음매를 넘는 입력에서만 드러납니다. 블록 하나 안에서 끝나는 입력으로 통과한 테스트는 이음매를 시험하지 않은 것입니다(우리 판단).