AMD GPU용 Hipfire, LocalLLaMA가 본 건 "드디어 RDNA 차례"
Original: AMD Hipfire - a new inference engine optimized for AMD GPU's View original →
LocalLLaMA가 Hipfire에 붙은 이유는 단순하다. AMD 사용자는 늘 "언젠가 지원될 것"이라는 말보다, 당장 돌아가는 숫자를 더 원한다. Hipfire README는 이 지점을 정면으로 찌른다. Rust + HIP 기반 단일 바이너리, hot path에 Python 없음, OpenAI 호환 API를 11435 포트에 노출, 그리고 RDNA1부터 RDNA4까지 소비자 카드와 프로 카드, APU까지 노린다는 설명이 앞에 선다. ROCm에서 소비자 RDNA가 늘 2순위 취급을 받아온 커뮤니티에서는 이 한 줄만으로도 일단 클릭할 이유가 생긴다.
기술적인 주장도 꽤 구체적이다. README와 벤치마크 문서에 따르면 7900 XTX 기준 autoregressive decode 속도는 Qwen 3.5 0.8B에서 391 tok/s, 4B에서 180 tok/s, 9B에서 132 tok/s, 27B에서 47 tok/s다. 같은 환경 비교에서 Ollama/llama.cpp 대비 decode가 1.7배에서 2.1배 빠르다고 내세운다. 더 자극적인 숫자는 DFlash speculative decode에서 나온다. 코드 프롬프트 기준으로 9B는 최고 372.9 tok/s, 27B는 218 tok/s 피크까지 찍었다고 적혀 있다. 다만 prose 계열에서는 오히려 손해가 날 수 있어 기본값을 off로 둔 점도 문서가 숨기지 않는다. 이런 태도가 LocalLLaMA에서는 오히려 신뢰를 만든다.
정량화 방식도 흥미롭다. Hipfire는 Qwen 3.5 계열에 맞춘 MQ4 양자화를 전면에 내세우고, input 벡터를 회전시키는 FWHT 기반 방식으로 4비트 손실을 줄였다고 설명한다. 즉 "AMD에서도 된다" 수준이 아니라, 어떤 모델 계열에 어떤 포맷을 써야 하는지까지 설계 논리를 붙였다. 그래서 커뮤니티 반응도 막연한 응원에 머물지 않았다. 상단 댓글 중 하나는 RX 7900 XTX에서 코드 프롬프트 기준 9B 모델이 306.27 tok/s 대 106 tok/s로 약 2.86배 빨랐다고 적었고, 다른 사용자는 Strix Halo 테스트 값을 올렸다. 이 스레드가 재미있는 건 공식 벤치마크와 사용자 실측이 바로 맞물린다는 점이다.
물론 아직 축포를 터뜨릴 단계는 아니다. 포스트 작성자도 Hipfire가 AMD 공식 프로젝트는 아니라고 못 박았고, 일부 GPU는 아직 완전 지원이 아니라고 댓글이 달렸다. 양자화 품질이 얼마나 안정적인지 더 검증이 필요하다는 말도 나왔다. 그래도 스레드 분위기는 분명했다. 이 커뮤니티는 오랫동안 AMD 쪽 로컬 추론을 변명과 우회책으로 버텨왔다. Hipfire가 계속 숫자를 정직하게 내놓는다면, 처음으로 "어쩔 수 없어서 쓰는 대안"이 아니라 적극적으로 벤치마크해 보고 싶은 엔진이 될 수 있다.
Related Articles
LocalLLaMA가 Hipfire에 몰린 이유는 새 repo 하나가 아니라 RDNA 사용자들이 오래 기다린 “우리 쪽 최적화”에 가까웠기 때문이다. 댓글도 곧바로 실제 카드에서 나온 속도 수치와 호환성 질문으로 채워졌다.
LocalLLaMA를 흔든 건 단순한 Qwen 점수 상승이 아니었다. 같은 계열 로컬 모델이 scaffold 변경만으로 19%에서 45%, 다시 78.7%까지 올라갔다는 서사가 붙으면서, 벤치마크 비교 자체를 다시 봐야 한다는 분위기가 퍼졌다.
27B 모델이 Sonnet 4.6과 비빈다는 주장에 LocalLLaMA가 크게 들썩였지만, 댓글은 곧바로 벤치마크 과최적화와 실제 로컬 구동 조건으로 옮겨갔다.
Comments (0)
No comments yet. Be the first to comment!