동료 Llama 여러분, 짧게 공유하겠습니다.

저희는 방금 AMD Ryzen AI MAX+ 395 iGPU (gfx1151, Strix Halo, 128 GiB 통합 메모리)를 위한 DFlash 및 PFlash 지원을 출시했습니다. 몇 주 전 RTX 3090 포스트에서 사용된 것과 동일한 Luce DFlash 스택이며, 이제 소비자용 AMD APU 급에서 실행됩니다.

Repo: https://github.com/Luce-Org/lucebox-hub (MIT)

요약 (TL;DR)

Luce Q8_0 DFlash drafter를 사용한 Qwen3.6-27B Q4_K_M의 엔드 투 엔드 (End-to-end) 결과: 26.85 tok/s 디코딩 (decode) 및 16K 컨텍스트 (context)에서 20.2초 프리필 (prefill).

이는 동일한 실리콘에서 llama.cpp HIP 대비 디코딩은 2.23배, 프리필은 3.05배 더 빠릅니다. 16K 프롬프트 + 1K 생성 워크로드에서 총 실제 소요 시간(wall clock)이 147초에서 58초로 단축되어, 엔드 투 엔드 성능이 2.5배 향상되었습니다.

동일한 128 GiB 시스템에서 최대 ~100 GiB 크기의 체크포인트를 호스팅할 수 있으며, 이는 24 GiB 소비자용 GPU로는 접근할 수 없는 모델 급입니다 (Qwen3.5-122B-A10B, MiniMax-M2.7-REAP 139B-A10B, full BF16 27B).

수치 (The numbers)

하드웨어 (Hardware): Ryzen AI MAX+ 395, Radeon 8060S iGPU (gfx1151), 128 GiB LPDDR5X-8000, ROCm 7.2.2
대상 (Target): Qwen3.6-27B Q4_K_M (15.65 GiB)
Drafter: Lucebox/Qwen3.6-27B-DFlash-GGUF Q8_0 (설정: DFLASH27B_DRAFT_SWA=2048)
벤치마크 (Bench): 10-prompt HumanEval 스타일, --n-gen 128 --ddtree-budget 22 --fast-rollback

디코딩 (Decode) (Qwen3.6-27B Q4_K_M, tok/s):

프리필 (Prefill) (Qwen3.6-27B, 16K tokens):

속도 향상은 컨텍스트가 커질수록 증가합니다: PFlash 압축은 O(S)인 반면, AR 프리필은 O(S^2)입니다. NIAH (Needle In A Haystack) 검색은 16K에서도 여전히 통과합니다.

튜닝 노트 (Tuning note): --ddtree-budget=22는 gfx1151의 최적값입니다. 예산(budget)을 높이면 스텝당 더 많은 토큰을 수용할 수 있지만, LPDDR5X 상에서 각 스텝의 비용이 더 커집니다. 타일 활용도(tile utilization)가 이득을 보기 전에 대역폭(bandwidth)이 이점을 제한합니다. budget=8이 승리하는 gfx1100 (7900 XTX, GDDR6 936 GB/s)과 대조적이며, 여기서는 실행 분할 상쇄(launch amortization)보다 타일 낭비(tile waste)가 더 중요합니다. 기본 배포 버전은 아키텍처를 인식하도록 설계되었습니다.

재현 (Reproduce)

bash

# 1. gfx1151용 PR #119 빌드
git clone https://github.com/Luce-Org/lucebox-hub.git
cd lucebox-hub
git fetch origin pull/119/head:pr119 && git checkout pr119
git submodule update --init --recursive
cd dflash
cmake -B build -S . \
  -DCMAKE_BUILD_TYPE=Release \
  -DDFLASH27B_GPU_BACKEND=hip \
  -DDFLASH27B_HIP_ARCHITECTURES=gfx1151 \
  -DDFLASH27B_HIP_SM80_EQUIV=ON
cmake --build build --target test_dflash -j

# 2. 모델: Qwen3.6-27B 타겟 + Lucebox Q8_0 DFlash drafter
mkdir -p models/draft
hf download unsloth/Qwen3.6-27B-GGUF Qwen3.6-27B-Q4_K_M.gguf --local-dir models/
hf download Lucebox/Qwen3.6-27B-DFlash-GGUF dflash-draft-3.6-q8_0.gguf --local-dir models/draft/

# 3. 벤치마크 (DFlash 디코딩 + PFlash 롱 컨텍스트 프리필)
LD_LIBRARY_PATH=/opt/rocm/lib:$LD_LIBRARY_PATH \
DFLASH_BIN=$PWD/build/test_dflash \
DFLASH_TARGET=$PWD/models/Qwen3.6-27B-Q4_K_M.gguf \
DFLASH_DRAFT=$PWD/models/draft/dflash-draft-3.6-q8_0.gguf \
DFLASH27B_DRAFT_SWA=2048 \
DFLASH27B_PREFILL_UBATCH=512 \
  python3 scripts/bench_he.py --n-gen 128 --ddtree-budget 22

DFLASH27B_PREFILL_UBATCH=512는 PR #119 위에 PR #159 수정 사항을 적용한 것입니다. #159가 머지(merge)되면, 이것이 데몬(daemon)의 기본값이 됩니다.

아직 누락된 사항 (What is still missing)

• HIP 상의 BSA scoring kernel. drafter의 compress-score 경로는 CUDA에서 BSA (block-sparse attention)를 사용합니다. PR #119는 HIP에서 이를 비활성화하고 ggml의 flash_attn_ext로 폴백(fallback)하도록 설정되어 있는데, 데몬(daemon) 자체 경고에 따르면 이 방식은 약 3.4배 더 느립니다. rocWMMA 네이티브 sparse-FA 커널이 이 격차를 해소합니다. 이 기능이 반영되면, 16K 컨텍스트에서의 PFlash TTFT(Time To First Token)가 27.6초에서 약 8초로 단축됩니다. 128K 컨텍스트에서는 llama.cpp AR(Autoregressive) 대비 7~10배의 성능 향상이 예상됩니다.
• Multi-row q4_K decode GEMV. drafter의 포워드(forward)를 위한 RDNA 네이티브 멀티 로우(multi-row) 패턴(활성화 레지스터 상태를 공유하는 R=4-8 출력 행)으로, 현재 긴 컨텍스트에서 compress 시간의 30%를 차지합니다.
• gfx1151을 위한 Phase 2 타일 형태(tile shape) 튜닝. 현재 rocWMMA flashprefill 타일은 gfx1100에 맞춰 튜닝되어 있습니다. Strix Halo는 다른 LDS 및 VGPR 특성을 가집니다.
• 70B+ MoE 타겟. 27B 모델에서는 128 GiB의 여유 공간이 낭비됩니다. Qwen3.5-122B-A10B와 MiniMax-M2.7-REAP 139B-A10B 모두 구동 가능합니다. DFlash는 MoE로 깔끔하게 이식되지만, 전문가 라우팅(expert-routed) 포워드를 spec verify 루프에 연결하는 큰 작업이 남아 있습니다.

제약 사항 (Constraints)

ROCm 7.2.2+ 이상, gfx1151 최적화 (arch-aware 기본 설정을 통해 gfx1100도 지원), greedy verify만 지원, 현재 이 경로에서는 Vulkan / Metal / multi-GPU를 지원하지 않음.

저희는 이를 위해 열심히 노력하고 있지만, 개선해야 할 점이 많다는 것을 알고 있습니다.

피드백은 언제나 환영합니다 :)