sudoingX의 Ling-3.0-flash 벤치마크 그래픽에서 누락됐던 대조군이 드러났다. 앞선 표는 Ling의 무투기 기준선을 '측정 안 함'으로 남겨뒀지만, 이후의 코드/산문 그래픽이 이를 채웠다. 짧은 프롬프트 기준으로 드래프터 없이는 약 23 tok/s인 반면, MTP n=1 적용 시 코드에서 40.9, 산문에서 38.7 tok/s를 기록해 튜닝 주장을 검증하기가 한결 수월해졌다. 이후 그래픽은 짧은 코드 및 산문 워크로드를 드래프팅 유무별로 비교한다. 저장소의 별도 정정은 CUDA 그래프를 분리해 설명하는데, 앞선 '두 플래그' 결과는 그래프와 멀티토큰 예측(MTP)을 함께 변경했기 때문에 어느 변경이 이득을 냈는지 판별할 수 없었다. 128GB DGX Spark 한 대에서 공식 INT4 체크포인트와 벤더의 vLLM 포크를 사용해 수행한 8월 22일 정정 측정치는 다음과 같다. 짧은 코딩 작업에 대한 보고된 tok/s는 즉시 실행(eager)에 MTP off가 20.8, CUDA 그래프에 MTP off가 22.9, CUDA 그래프에 MTP n=1이 40.9였다. 이는 즉시 실행 기준선 대비 그래프로 약 10%의 처리량 증가, 그래프 기준선 대비 MTP로 약 79%의 추가 증가에 해당하며, 두 백분율은 분모가 서로 다르다.

다음은 올려두고 싶어지는 설정이다. 여기서 n은 num_speculative_tokens, 즉 단계당 제안되는 드래프트 토큰 수를 뜻한다. vLLM의 문서화된 수용 길이 지표는 검증 단계마다 보너스 토큰을 포함하므로 n=1에서도 평균이 1을 넘을 수 있다. 제작자는 벤더 포크에서 산출한 지표를 보고할 뿐 정확한 과거 계수 구현은 제공하지 않았다. MTP 설정별 결과를 보면 n=1, n=2, n=3에서 평균 수용 길이는 각각 1.87, 2.39, 2.77이었고, 산문 512토큰 출력 tok/s는 38.7, 34.8, 33.6, 산문 2,048토큰 출력 tok/s는 37.3, 33.6, 31.6이었다. 코드 처리량은 보고된 실행 간 변동 범위 내에서 거의 평탄했지만, 산문은 평균 수용 드래프트 길이가 늘어날수록 느려졌다. 수용 길이는 수용 백분율이 아니며 최적화 목표도 아니다.

sudoingX는 배포 스레드에서 구성을 설명했고 고정된 벤치마크 노트에 두 표가 모두 담겨 있다. 이는 작성자의 측정치로 여기서 독립적으로 재실행한 것은 아니다. 스윕은 스트리밍과 서버 측 토큰 수를 기술하지만 시간 측정 분모를 완전히 명시하지 않으므로 수치는 보고된 처리량으로 표기돼야 한다. 이 체크포인트와 이 워크로드에서는 n=1이 유용한 설정이었다. 전이 가능한 실험은 MTP 없는 기준선을 분리한 뒤 실제로 생성하는 출력 유형에 대해 드래프트 설정을 비교하는 것이다.