AMD용 추론 엔진 Hipfire, LocalLLaMA가 반긴 이유

LocalLLaMA에서 Hipfire가 바로 반응을 얻은 이유는 단순하다. AMD 사용자들은 오랫동안 로컬 LLM 생태계에서 늘 두 번째 순서였다. 대부분의 툴은 CUDA 중심으로 설계되고, RDNA 지원은 나중에 붙거나 아예 불완전했다. Hipfire는 여기서 출발점이 다르다. 프로젝트 README는 Rust와 HIP로 만든 AMD RDNA 전용 추론 엔진, 단일 바이너리, Ollama 스타일 UX, hot path에 Python 없음이라는 점을 전면에 내세운다.

더 중요한 건 지원 범위다. Hipfire는 RDNA1부터 RDNA4까지, 소비자용 카드와 Pro 카드, APU까지 한 가족으로 본다. “AMD에서도 돌아간다”가 아니라 “AMD를 처음부터 주인공으로 놓고 만들었다”는 메시지다. README의 수치도 강하다. 7900 XTX 기준 기본 설정에서 Qwen 3.5 0.8B는 391 tok/s, 4B는 180 tok/s, 9B는 132 tok/s, 27B는 47 tok/s를 제시한다. 여기에 DFlash speculative decode 경로에서는 특정 코드 benchmark에서 27B 218 tok/s, 9B 372 tok/s까지 적어두고 있다.

이 숫자가 스레드를 움직였다. 원글은 mq4 계열 quant와 외부 benchmark 사이트를 언급했지만, 댓글에서 더 설득력 있는 장면이 나왔다. RX 7900 XTX에서 9B 코드 프롬프트를 돌린 사용자가 baseline 106 tok/s 대비 306 tok/s 정도가 나왔고 출력 coherence도 괜찮았다고 적었다. LocalLLaMA가 이런 글에 반응하는 방식은 늘 비슷하다. 추상적인 홍보 문구보다 카드 이름, 모델 이름, 프롬프트 종류, 실제 속도 수치가 먼저 먹힌다.

물론 박수만 있던 건 아니다. GGUF를 바로 지원했으면 좋겠다는 반응이 많았고, 또 하나의 독자 quant 포맷이 생기면 생태계가 더 갈라진다는 걱정도 나왔다. 세대별 지원 범위, multi-GPU 계획, 아직 덜 다듬어진 그래픽 아키텍처 지원 상태를 묻는 질문도 이어졌다. 하지만 이런 반응은 오히려 긍정 신호다. 관심이 없으면 호환성 질문도 나오지 않는다.

결국 Hipfire가 건드린 핵심은 속도 그 자체보다 태도다. AMD 사용자를 사후 대응이 아니라 출발점으로 놓은 로컬 추론 엔진이 등장했다는 점, 그리고 실제 테스트가 그 약속을 어느 정도 뒷받침했다는 점이다. LocalLLaMA가 이 스레드에 열광한 이유도 거기에 있다.