이제 FastFlowLM을 통해 AMD NPU에서 Qwen 3.8 27B를 구동할 수 있음 (죽여주는 1 tps 디코딩 속도로)

농담은 제쳐두고, fastflowlm으로 배터리 환경에서 35B 모델을 돌리는 건 꽤 할만함. 1,000달러 미만으로 산 32GB DDR5 램에 Ryzen AI350 탑재된 레노버 노트북 쓰는데 충전기 없이 몇 시간은 버팀. NPU 덕분에 배터리 모드에서도 35B를 꽤 괜찮은 속도(최신 AMD 내장 그래픽으로 돌릴 때 기대하는 정도)로 돌릴 수 있고, 이 설정으로 몇 시간은 작업 가능함. 보조 배터리 쓰면 더 오래 가고. 진짜 내 엔비디아 게이밍 노트북보다 배터리 모드에서 LLM을 더 빨리 돌림.

그럼... 혹시 flash-next를 무려 4, 아니 5 tps로 돌릴 수 있다는 뜻인가?

NPU에 대해 너무 깊게 생각 안 하려고 했음, 그냥 보너스 서프라이즈 정도로만 생각했는데... 방금 전까지는 이런 생각 못 했거든. 혹시 fastflow에서 의사결정 모델을 돌릴 가능성을 탐구하는 사람 있음? 더 크거나 작은 모델 모두에게 속도와 효율성 면에서 완벽한 조합일 것 같은데... 어차피 소비자용 하드웨어에서 타겟팅하지 않는 거대한 규모를 제외하면, 모델이 100배 더 빠른데 NPU 속도 저하를 누가 신경이나 쓰겠음?

안녕 👋 gufo(https://github.com/gufo-org/gufo) 메인테이너 중 한 명인데, 우리도 이것저것 실험해 봤거든. 근데 NPU에 드래프트 모델을 올리는 것보다 그냥 풀 GPU 설정이 훨씬 훨씬 빠르다는 결론이 나옴. 우리 실험 내용 담긴 전용 브랜치 있으니까 한번 봐봐. hrx system( 좀 더 성숙해지면 작업을 계속할 생각임. 관련 브랜치도 따로 파놨는데 아직은 별 성과가 없네.

왜 가속기 전용 추론 엔진만 있는지 잘 모르겠음. NPU 전용이 배터리에 좋다는 건 임베디드 환경에선 타당한 이유긴 함.

근데 내 8845HS 미니 PC 같은 경우엔 NPU가 DRAM 대역폭을 다 못 써서, 디코딩을 NPU에만 맡기고 싶지 않음. 최대 토큰 생성 속도를 뽑으려면 GPU가 무조건 섞여야 하는데, NPU는 TOPS가 높으니까 프롬프트 처리할 때 GPU랑 NPU를 같이 쓰고 싶단 말이지!

그래서 llama.cpp에서 NPU+GPU 추론을 섞는 작업을 시작했는데, 큰 노력 없이도 성능 향상이 꽤 괜찮음. 지금은 matmul이랑 matmul_id NPU 커널만 구현했는데도 디코딩 속도 저하 없이 pp(프롬프트 처리) 속도가 두 배 빨라짐. FastFlowLM은 NPU용 연산을 전부 다시 구현해야 했던 거랑 대조적이지.

덤으로 ROCm을 프롬프트 프리필에 쓰고 Vulkan을 디코딩에 쓰는 llama.cpp도 만들어봄.

나도 gfx1150 쓰는데 ROCm에서는 prefill은 더 빨랐는데 decode에서 실패하더라. 반대로 vulkan은 반대고. 혹시 llamacpp 빌드 따로 있어?