3주 뒤 다시 잰 Qwen3.8, llama.cpp 업데이트로 prefill 최대 61% 향상
ROCm 버전을 올려서는 나지 않던 향상이 llama.cpp 코드 업데이트로 나왔습니다. upstream 비교, 실제 문맥 32/64/96K 측정, 128K+vision 검증, HIP와 Vulkan 비교를 정리했습니다.
처음 쟀을 때 ROCm 7.14에서 10으로 올려도 이 모델은 빨라지지 않았습니다. 3주 뒤에는 런타임이 아니라 llama.cpp 코드가 바뀌었습니다. RMS fusion, HC 연산, RDNA3.5 MoE heuristic이 upstream에 병합됐고, 같은 EVO-X2(gfx1151)에서 다시 재 보니 prefill이 최대 61% 빨라졌습니다.
코드만 바꿔서 비교
같은 UD-Q4_K_XL과 ROCm 10에서 8월의 90c26fc와 9월의 7ceed873를 따로 빌드해 비교했습니다. 각 3회, Q8 K/V, MTP off입니다.
| 시험 | 기존 | 최신 | 변화 |
|---|---|---|---|
| pp512 | 337.56 tok/s | 449.39 tok/s | +33.1% |
| pp4096 | 314.41 tok/s | 465.52 tok/s | +48.1% |
| pp16384 | 257.59 tok/s | 415.58 tok/s | +61.3% |
| tg256 | 20.54 tok/s | 22.02 tok/s | +7.2% |
| 32K API 전체 요청 | 134.45초 | 83.98초 | -37.5% |
한 달 전에 "ROCm 10은 이 모델에서 빨라지지 않는다"고 적었는데, 이번 향상은 ROCm이 아니라 그 사이 병합된 MoE와 fusion 최적화에서 나왔습니다. 성능 수치는 어느 커밋에서 잰 것인지와 함께 봐야 합니다. 다른 모델이나 하드웨어에서 보고된 개선율을 이 조합에 그대로 적용할 수 없는 것도 같은 이유입니다.
한국어 요약, 코드 생성(문법 확인과 3가지 실행), 산술, 대화 기억, 도구 호출 JSON, 32K prefix cache를 모두 통과했습니다.
실제 문맥 길이별 생성 속도
최대 슬롯은 128K로 고정하고 실제로 넣는 입력 길이만 바꿨습니다. 각 길이에서 표식을 찾아 답하는지와 캐시를 재사용하는지 확인했고, 256토큰 고정 생성을 두 번씩 쟀습니다.
| 실제 문맥 | 첫 입력 처리 | 고정 256 생성 |
|---|---|---|
| 약 32K | 92.5초 | 16.52 tok/s |
| 약 64K | 230.5초 | 11.04 tok/s |
| 약 96K | 411.9초 | 8.59 tok/s |
컨텍스트를 128K로 설정해서 느려지는 것이 아니라, 실제로 채운 길이만큼 느려집니다. 최대 128K로 설정해도 실제 입력이 32K면 16.5 tok/s가 나왔습니다. 일상적인 대화와 코딩은 32K 안팎, 긴 문서는 64K 정도가 적당하고, 96K 이상은 속도를 포기하고 분량을 담는 쪽입니다.
같은 요청을 다시 보내면 3만~9만 토큰의 캐시를 그대로 쓰고 새 토큰 4개만 처리해서 0.15~0.22초 만에 끝났습니다.
128K에 이미지와 reasoning을 켜도 통과
최신 빌드에 기존 F16 projector를 붙여 128K 슬롯, reasoning on으로 확인했습니다. 이미지 한 장의 도형·색·문자·개수, 두 이미지의 차이, 한국어 설명을 모두 맞혔고, 약 129K토큰을 채운 상태에서 이미지를 두고 한 후속 질문도 맞혔습니다.
HIP와 Vulkan
Vulkan에도 이 모델용 최적화(MoE row-id, HC 연산)가 들어와서 같은 가중치로 비교할 수 있게 됐습니다. 각 3회입니다.
| 항목 | 기준 HIP | 최신 HIP | Vulkan |
|---|---|---|---|
| pp4096 | 488.12 | 489.62 | 456.47 |
| pp16384 | 437.25 | 433.64 | 413.96 |
| tg256 | 22.15 | 22.13 | 26.32 |
| 32K API (단일 사례) | 80.94초 | 85.63초 | 73.02초 |
Vulkan은 짧은 생성이 18.9% 빨랐고 prefill은 5~7% 느렸습니다. 32K API 한 건에서는 Vulkan이 가장 빨랐지만 한 번 잰 값이라 결론으로 쓰지 않았습니다. Vulkan으로 32K 요청을 끝낼 무렵 swap이 최대 약 1.34GiB 늘었는데 원인을 아직 가려내지 못해서, 운영은 HIP로 유지했습니다. Vulkan에서 128K, 이미지, reasoning on 조합도 아직 확인하지 않았습니다.
생성이 많은 작업이면 Vulkan이, 긴 입력을 처리하는 작업이면 HIP가 유리합니다. 저희는 확인해 둔 범위가 넓은 HIP를 계속 씁니다.
이 글은 128GB 미니PC 로컬 AI 시리즈의 후속입니다. 같은 업데이트로 고쳐진 버그 이야기는 별도 글에 있습니다.