[기획: AI 트렌드] 「아직 지원하지 않는다」던 검사 4줄, vLLM에서 GLM-5.3에 CUDA 그래프가 허용되자 한 구성의 출력 처리량이 약 2.6배

10월 19일, 4줄짜리 PR

10월 19일, vLLM에 PR #62377이 머지됐습니다. vLLM은 AI 모델을 서버에서 돌려 요청에 답하게 하는 오픈소스 프로그램입니다. PR은 코드 수정 요청이고, 이를 본 코드에 합치는 일이 머지입니다. LucasWilkinson이 쓰고 mgoin이 머지한 이 PR로, AI 모델 GLM-5.2·5.3과 DeepSeek-V3.2는 특정 병렬 구성에서 CUDA 그래프라는 실행 방식을 쓸 수 있게 됐습니다.

프리필은 질문 전체를 한꺼번에 읽는 단계, 디코드는 답을 토큰 하나씩 이어 쓰는 단계입니다. 토큰은 모델이 글을 잘게 자른 조각입니다.

CUDA 그래프는 GPU(AI 계산을 맡는 칩)에 시킬 일 묶음을 한 번 녹화해 둔 기록입니다. 녹화한 뒤에는 그 묶음을 한 번의 호출로 몇 번이든 다시 틀 수 있습니다. 주문을 하나씩 불러 주는 대신 미리 적은 주문서 한 장을 건네는 것과 같습니다. 주된 이득은 CPU가 GPU에 일을 하나씩 넘기던 부담이 크게 줄어드는 데 있습니다.

vLLM의 NONE 모드는 그래프를 끈 상태입니다. 조각 그래프(PIECEWISE)는 어텐션처럼 그래프에 넣기 어려운 연산만 그때그때 실행하고, 나머지를 토막토막 그래프로 묶습니다. 어텐션은 모델이 앞 내용 중 어디를 참고할지 계산하는 연산입니다. FULL_AND_PIECEWISE는 디코드만 모인 묶음을 통째 그래프 하나로 돌리고, 나머지는 조각 그래프로 돌립니다.

「아직 지원하지 않는다」던 검사

대상 모델 셋은 희소 어텐션을 씁니다. 앞 내용 전부가 아니라 골라낸 일부만 참고하는 어텐션이고, 고르는 모듈을 인덱서라고 부릅니다.

허용은 vLLM의 새 모델 러너(MRV2)에서 쓰는 병렬 구성 하나에 한정됩니다. 프리필 컨텍스트 병렬(PCP)은 긴 입력을 토막 내 GPU마다 한 토막씩 계산해, 첫 토큰이 나오기까지의 시간을 줄이는 방식입니다. 디코드 컨텍스트 병렬(DCP)은 KV 캐시, 즉 모델이 앞 내용을 계산해 기억해 둔 중간 결과를 여러 GPU에 나눠 두는 방식입니다.

대상 구성은 PCP를 쓰고 DCP를 1로 둔 경우입니다. DCP가 1이면 KV 캐시를 나누지 않고 GPU마다 통째로 둡니다. 이때 디코드 요청은 하나씩 GPU들에 차례로 배정되고, 요청 하나는 GPU 하나가 맡습니다.

전에는 이 구성에서 희소 어텐션 모델에 그래프를 켜면 오류가 났습니다. 문구는 「아직 CUDA 그래프를 지원하지 않는다」였고, 그래프 모드를 NONE으로 두라는 안내가 붙었습니다. 조각 그래프까지 포함해 모든 그래프 모드가 막혀 있었습니다. DCP를 2 이상으로 두는 구성은 9월 12일에 이미 FULL_AND_PIECEWISE까지 허용됐습니다.

이번 변경은 파일 하나에서 4줄을 더하고 2줄을 지운 것입니다. 검사 조건에 모델 유형 예외를 넣어, DeepSeek-V3.2 유형과 GLM 희소 어텐션 유형만 검사를 통과하게 했습니다. 작성자는 이를 DeepSeek-V3.2와 GLM-5.2·5.3이라고 적었습니다. 이렇게 검사를 통과시키는 모델 유형 목록이 허용 목록입니다. 이 구성에서 희소 어텐션을 쓰는 다른 모델은 전처럼 오류가 납니다.

새 실행 경로는 없습니다. 작성자는 #53867의 디코드 전용 그래프 경로가 「이미 이 모델들을 처리한다」고 적었습니다. #53867은 9월 15일 머지된, PCP에서도 디코드 전용 통째 그래프를 쓰게 한 변경입니다. 시험 모델은 GLM-4.7-Flash였고, 수치로 낸 것은 정확도뿐이었습니다. 10월 2일에는 이 구성의 디코드 방식 자체가 바뀌었습니다. 그 전에는 모든 GPU가 같은 디코드 요청을 중복 실행했습니다. 이번 허용은 그 17일 뒤입니다.

정확도는 그대로, 처리량은 한 구성에서 약 2.6배

이번 작성자는 속도도 쟀습니다. GLM-5.3의 NVFP4 판(숫자를 4비트로 줄여 담은 판)을 B300 GPU 네 장에서 PCP 4로 돌렸고, KV 캐시는 8비트 FP8 형식으로 두었습니다. 수학 문장제 모음 GSM8K의 1,319문항을 동시 요청 최대 64개로 보내며 NONE과 FULL_AND_PIECEWISE를 견줬습니다.

정확도는 그래프를 끈 쪽 0.9075, 켠 쪽 0.9083으로 사실상 같았습니다. 전체 문항을 끝내는 데 걸린 시간은 379.5초에서 145.9초로 줄었습니다. 처리량, 즉 초당 내놓은 출력 토큰 수는 330개에서 859개가 됐습니다. 그래프를 끈 상태 대비 약 2.6배이고, 작성자의 두 수치를 우리가 나눈 계산입니다.

이 배수는 디코드 통째 그래프와 나머지 조각 그래프를 함께 켠 효과입니다. 디코드 통째 그래프만의 몫은 따로 재지 않았습니다. 바탕 수치는 B300 한 구성에서 작성자가 잰 자기보고이고, 독립 재현이 아닙니다.

디코드 한 걸음은 요청마다 토큰 하나만 계산하므로, GPU가 맡는 일 하나하나가 짧습니다. 그만큼 CPU가 일을 넘기는 부담의 비중이 커지고, 그래프는 바로 그 부담을 줄입니다(우리 판단). 다른 구성에서도 같은 배수가 나온다고 볼 근거는 원문에 없습니다.

프리필까지 통째 그래프로 돌리는 FULL 모드는 여전히 거부돼, PCP 아래 프리필은 조각 그래프로 돕니다. 모델이 하는 계산은 그대로이고, 바뀐 것은 그 계산을 GPU에 넘기는 방식이었습니다(우리 판단).

DeepSeek-V3.2는 직접 돌려 보지 않고 허용됐다

예외에도 근거는 있습니다. 같은 문항으로 그래프를 끈 쪽과 켠 쪽의 정확도를 비교했고, 작성자는 단위 테스트 통과와 머지 전 자동 검사(CI) 96개 통과를 보고했습니다.

확인한 범위는 허용 목록보다 좁습니다. 실제로 돌린 모델은 GLM-5.3뿐이었습니다. DeepSeek-V3.2에 대해 작성자는 「GLM-5.3과 어텐션·인덱서 코드를 공유하지만 처음부터 끝까지 돌려 보지는 않았다」고 적었습니다. GLM-5.2를 직접 돌렸다는 기록도 원문에 없습니다.

MTP와 함께 쓰는 경우도 아직 검증하지 않았다고 적었습니다. MTP는 다음 토큰 여러 개를 함께 예측하게 하는 기능입니다. 인덱서를 쓰는 다른 모델, 예컨대 DeepSeek V4·V4.1과 MiniMax-M3는 모델별 작업이 필요해 여전히 그래프를 끄고 돌아야 합니다.

작성자는 이 PR에 AI 보조를 썼다고 밝혔고, 커밋(코드 변경 기록)에 Claude가 공동 작성자로 올라 있습니다.

미지원과 미확인 사이

앞선 글에서 우리는 답을 채점하는 테스트로 효율의 결함이 보이지 않는다고 봤는데답은 맞았고 GPU마다 전문가가 전부 실려 있었다, transformers에 그것을 확인하는 테스트가 추가됐다, 이번에는 정확도 확인이 거꾸로 효율 경로를 허용하는 근거가 됐습니다. 앞으로 볼 것은 DeepSeek-V3.2를 실제로 돌린 측정과, DeepSeek V4·MiniMax-M3 같은 모델의 허용 여부입니다.

우리는 이번 일에서 배수보다 오류 문구 하나를 봅니다. 같은 「아직 지원하지 않는다」가 두 모델 유형에는 작성자 설명대로라면 「아직 확인하지 않았다」였고, DeepSeek V4·MiniMax-M3에는 「아직 만들지 않았다」였습니다(우리 판단). 문구 하나가 미구현과 미확인을 가르지 않으니, 사용자는 오류만 보고 어느 쪽인지 알 수 없습니다(우리 판단). 확인이 허용의 근거라면 허용 목록은 확인한 범위만큼만 넓어야 합니다(우리 판단). 이번에는 작성자가 밝힌 것만 따져도, 허용이 확인보다 적어도 한 모델 넓었습니다.