Reddit에서 화제 · github.com · 6일전

Massive B70 spec-decoding improvement - Intel XMX matrix engines refactored by budiony · Pull Request #29864 · ggml-org/llama.cpp

OIYO 한국어 요약

llama.cpp SYCL 백엔드에 Intel XMX 행렬 엔진을 쓰는 다중 열 mul_mat_vec_q 커널을 넣는 PR이에요. Intel Arc Pro B70에서 추측 디코딩 검증 구간이 크게 빨라져, Qwen3.8 27B Q2_K의 종단 속도가 30.2에서 60.0 tok/s로 올랐대요.

원문을 읽지 못해 Reddit 소개글을 바탕으로 요약했어요.

본문 번역

원문 일부를 옮겼어요. 전체 내용은 원문에서 확인해 주세요. · Grok Bot · 2026-10-23

GitHub PR 설명의 앞부분(목적, 배경, 측정 결과, 검증 방법 시작)을 기준으로 옮겼어요. 이후 구현 세부와 리뷰 토론은 읽지 못했어요. Reddit 스레드 대신 링크된 원문 PR을 읽었어요.

무엇을 바꾸나요

llama.cpp의 SYCL 백엔드에서, 재정렬된 K-quant와 Q8_0 가중치에 대해 Intel XMX 행렬 엔진(int8 DPAS, ESIMD)을 쓰는 **다중 열(활성화 열 2~80개) mul_mat_vec_q** 커널을 추가해요. 목표는 두 가지예요.

  • 추측 디코딩(speculative decoding) 검증: 한 단계에 2~8토큰
  • 짧은 프롬프트 배치: 9~80토큰

Q2_K, Q3_K, Q8_0 세 형식은 열이 하나일 때도 이 커널을 써요.

왜 필요했나요

기존 다중 열 dp4a 커널은 열마다 가중치 언팩과 스케일 계산을 다시 해서, 배치가 커질수록 비용이 늘었어요(열 하나 추가마다 dp4a당 약 5개 레인 연산). 프로파일링해 보니 Q6_K 모델에서 4토큰 단계가 1토큰보다 46% 오래 걸렸고, Q3_K는 훨씬 나빴대요. 1토큰 디코드는 메모리 대역폭에 묶이지만 추측 검증은 그렇지 않아서, 이 차이가 중요하다는 설명이에요.

측정 환경

Intel Arc Pro B70(32GB), Windows 10, oneAPI 2026.1, Level Zero 드라이버, GGML_SYCL_F16=ON, 그래프 사용. 모델은 모두 Qwen3.8 27B 변형이고 "이전"은 GGML_SYCL_ENABLE_XMX=0으로 끈 같은 빌드예요.

결과 (tok/s, 이전 → 이후 일부)

| 모델 | tg1 | pp4 | pp8 | pp16 | |---|---|---|---|---| | Q8_0 | 15.9 → 18.0 | 58.4 → 70.7 | 108.8 → 133 | 32.4 → 241 | | Q4_K_S | 26.5 → 26.5 | 67.7 → 90 | 82.7 → 131 | 50.3 → 308 | | Q3_K_S | 28.9 → 33.1 | 44.7 → 115 | 66.6 → 192 | 36.2 → 243 | | Q2_K | 33.4 → 37.6 | 50.8 → 121 | 71.9 → 169 | 46.6 → 235 |

추측 디코딩 종단 측정(draft-mtp, n-max 4, 400토큰 프롬프트 5개 평균)에서는 이래요.

  • Q8_0: 32.4 → 40.3 (어휘 축소 옵션까지 켜면 43.1)
  • Q4_K_S: 38.7 → 47.6 (51.0)
  • Q3_K_S: 28.6 → 53.6 (57.2)
  • Q2_K: 30.2 → 60.0 (63.9)

샘플링 때문에 실행마다 1~3 tok/s 정도 오차가 있대요. 정확성은 실제 모델 텐서에서 기존 dp4a 커널과 1·2·4·7·8열로 비교해 정규화 MSE가 약 1e-14(부동소수 합산 순서 차이 수준)였다고 해요.

출처: github.com

원문 읽기 Reddit 토론 같은 날 모아보기

OIYO는 원문을 그대로 옮기지 않아요. 요약과 본문 번역은 큐레이션 목적이며, 사실·인용은 원문 출처를 따라요.