16GB급 GPU용 NInfer 4080 제작기
요약
작성자는 RTX 4080 (16GB) GPU 환경에서 ISTA-DASLab-Qwen-3.8-27B-GSQ 모델을 100k 컨텍스트로 구동하기 위해 NInfer 4080을 직접 제작했습니다. 이 커스텀 엔진은 하드웨어의 잠재력을 극대화하여 높은 프리필 및 생성 속도를 달성했으며, 이를 통해 일반적인 LLM 추론 성능 향상을 공유합니다.
핵심 포인트
- RTX 4080 (16GB) 환경에 최적화된 NInfer 커스텀 엔진 제작
- 100k 컨텍스트 구동을 통한 높은 프리필 및 생성 속도 달성
- llama.cpp나 vllm 대비 하드웨어 활용도를 높여 성능 향상
- GPU 커널 개발 경험 없이 제품 책임자 관점에서 접근하여 성공적인 프로젝트 수행
안녕하세요 여러분,
요약하자면:
저는 RTX 4080 16GB GPU에서 ISTA-DASLab-Qwen-3.8-27B-GSQ 모델을 100k 컨텍스트로 구동하기 위해 NInfer 4080을 제작했습니다. 이 과정에서 하드웨어의 능력을 훨씬 더 많이 활용할 수 있었으며 (최대 전체: 2720 tok/s 프리필, 262 tok/s 생성), 이제 커뮤니티와 공유하여 다른 분들도 이러한 혜택을 누릴 수 있도록 했습니다.
https://github.com/roofkid/ninfer-4080
전체 버전:
커뮤니티에서 NInfer 5090, 4090, 3090 등 놀라운 작업들을 많이 본 후, 저의 RTX 4080에 메모리가 단지 16GB밖에 없다는 이유로 그 어떤 것도 사용할 수 없을 것 같아 조금 아쉬웠습니다. DeepSeek 플랫폼에는 제가 얼마나 많은 사용량을 가져갈지 예상하지 못해서 약 $13 크레딧이 유휴 상태로 남아 있었습니다.
참고로 저는 소프트웨어 엔지니어링 및 아키텍처 분야에서 20년 이상의 경력을 가지고 있지만, GPU 커널 개발 경험은 전혀 없습니다. 그래서 이것은 저에게 전문적인 경험 측면에서도 매우 흥미로운 취미 프로젝트였습니다. 주로 C++을 읽고 이해할 수는 있었지만 실제 커널 코드를 판단할 수는 없었기 때문에, 저는 오직 제품 책임자(product owner) 및 요구사항 관점('requirements perspective')에서 접근했고, 좋은 소프트웨어 엔지니어링 관행이 지켜지도록 했으며, 오로지 '비즈니스 결정'만 내렸습니다.
저는 지난 2~3년 동안 로컬 LLM 커뮤니티를 적극적으로 팔로우해 왔고, 그동안 가능한 모든 모델을 시도해 보았으며 여러분들처럼 놀라움 속에서 진행 상황을 지켜봐 왔습니다.
지침 원칙
RTX 4080 16GB GPU에 맞추기
ISTA-DASLab-Qwen-3.8-27B-GSQ 사용 -> 추론(Reasoning)은 ByteShape 기사에서 볼 수 있으며, 크기에 비해 매우 좋고 훨씬 큰 Unsloth UD 양자화 모델보다 더 나은 정확도를 주장합니다: https://byteshape.com/blogs/Qwen3.8-27B/#96-gb-rtx-pro-6000 저 역시 개인적으로 사용 경험이 매우 좋으며, 일상적인 주력 모델로 사용하고 있습니다
DFlash2 추측 디코딩(speculative decoding) 사용
100k+ 컨텍스트 도달
일반 목적의 추론 엔진인 llama.cpp나 vllm보다 하드웨어를 더 잘 활용하기 위해 프리필(prefill) 및 토큰 생성 속도를 크게 향상
변경 후에도 정확도가 유지되는지 측정했으며, 비교를 위해 M4 48GB도 사용 가능하지만 물론 속도는 훨씬 느립니다
비용 효율성을 위해 DeepSeek V4.1 Flash로 작업 수행
Pi를 하네스(harness)로 사용 (비-코스메틱 확장 기능만 포함: hashline edit pro, 자체 작성 스킬을 통해 로컬 SearXNG에서 ketch를 이용한 인터넷 검색)
런타임은 Docker 이미지로도 제공되어 사람들이 실행하기 쉽습니다
결과
깊이 프리필(Depth Prefill) t/s (DFlash2) MTP3 디코드 t/s DFlash2 K=7 디코드 t/s
8K 2719.9 151.2 (100%) 166.7 (54.0%)
32K 2424.9 141.7 (100%) 262.3 (100%)
64K 2125.5 130.7 (100%) 239.1 (100%)
98K 1895.1 122.3 (100%) 212.7 (98.2%)
실제 작업에서는 프롬프트가 충분히 길 경우 높은 프리필 수치(2k+)를 정말 많이 볼 수 있으며, 코딩의 경우 시간당 약 150-200 속도, 산문은 시간당 약 100 정도의 디코드 속도를 보입니다. 주관적으로는 동일한 벤치마크 결과임에도 불구하고 이전 주력 모델이었던 beellama보다 훨씬 빠르다고 느낍니다. 저는 주로 MBPP와 HumanEval을 사용했는데, 비교적 빠르게(~30분) 실행할 수 있는 것이 필요했기 때문입니다. MBPP는 90-92% 영역에 머물고 HumanEval은 95-96%를 기록합니다. 현실적으로 기대하되 측정 노이즈 내의 미세한 성능 저하가 있음을 예상하십시오. 이는 주로 KV 양자화(KV quantization)에서 발생하며, 필요하다면 스위칭을 통해 컨텍스트와 정확도 간의 트레이드오프를 항상 할 수 있습니다.
배운 점
범용 엔진을 사용함으로써 얼마나 많은 성능이 손실되는지 정말 놀랍습니다. 전체적으로 볼 때, 광범위한 지원과 성능 사이의 트레이드오프(trade-off)라는 것은 충분히 이해가 됩니다. 다만 이렇게까지 많이 부족할 줄은 예상하지 못했습니다. 처음에 메모리 처리량 측정치가 200 GB/s 범위에 있었고, 장치에서 이론적 최대치가 720 GB/s인데도 불구하고, 제가 처음 시작했을 때의 낮은 효율성을 보고는 입이 다물어지지 않았습니다.
커뮤니티에서는 우리 모두가 더 전문화된 추론 엔진(inference engine)들이 상당한 성능 개선을 가능하게 하는 것을 보았다고 생각합니다. R9700용 vllm-radiance, CUDA용 NInfer 변형 모델들, Metal용 Splash 등 소프트웨어 제작 비용이 점점 저렴해지면서, 저는 우리 '만지는' 그룹(tinkerer group)으로부터 더 많은 것들이 나올 것이라고 기대합니다.
단돈 $13으로 이 작업을 위해 약 20억 토큰을 사용한 것은 정말 미친 일입니다 (오프-아워 기준). 에이전트 기반 작업에서 낮은 캐시 읽기 토큰 비용은 제가 예상했던 것보다 훨씬 더 중요합니다. 이것은 LLM이 어떻게 작동하는지 인지적으로 완전히 이해하는 것과 실제 대규모 데이터 결과를 보는 것 사이의 전형적인 차이입니다. 현실적으로는 그런 가격 책정이라면, 같은 양의 토큰을 얻기 위해 전기 요금을 더 많이 지불할 것 같습니다.
xhigh로 돌아가 Qwen 3.8 27B에 대해 생각했는데, 속도가 너무 빨라서 별로 신경 쓰지 않았습니다. 또한 더 이상 따라갈 수 없어서 다시 사고 과정(thinking blocks)을 숨겼습니다.
프리필 속도(prefill speed)는 저를 정말 놀라게 했습니다. 첫 번째 큰 개선 작업들을 마친 후 Pi에서 이를 시도했을 때, 즉시 토큰 스트리밍으로 답변이 오는 것을 보고 크게 감명받았습니다. 저는 캐싱된 시스템 프롬프트 없이 5~10초 동안 기다리는 것에 너무 익숙했었습니다. 이것이 사용자 경험(user experience)에 얼마나 중요한지 심각하게 과소평가했습니다. 이제는 클라우드 엔드포인트처럼 느껴집니다.
이러한 높은 프리필 속도(prefill speeds)에서는 컨텍스트 창(context window)이 40초 만에 가득 차는 것을 경험했습니다. 처음 이 현상을 겪었을 때 정말 '세상에'라는 생각이 들었습니다.
100k의 컨텍스트를 달성한다는 것은 상당한 KV 압축(KV compression)을 의미합니다. Qwen 3.8 27B 모델에서 전체 256k 컨텍스트 F16은 정확히 16GB의 VRAM이 필요합니다. 저는 '높은' (4비트 스타일) KV 압축에 대해 너무 두려움을 느꼈습니다. 이 분야에는 정말 많은 발전이 있었습니다. 원래는 Q8_0 이하로는 내려가지 않았는데, 이후 beellama에서 kvarn5/kvarn5를 사용해 본 후 벤치마킹을 했지만, 지금 여기서 사용하는 rk4v4-e8 변형과 비교했을 때 눈에 띄는 차이를 측정할 수 없었습니다. 저는 좋은 소프트웨어 엔지니어링 관행(software engineering practices)이 훨씬 더 중요하며, 이로 인해 발생할 수 있는 문제들을 잡아낸다고 생각합니다. 또한 주관적으로 볼 때 여기서는 '빠른 가비지(fast garbage)' 현상을 경험하지 못했습니다.
결론 (Conclusion)
저에게는 이것이 좋은 버전 1이며, Qwen 3.8 27B에 대해 여기에 많은 노력을 기울일 생각은 없습니다. 이미 파레토 최적점(pareto 80% state)에 도달했기 때문입니다. 저는 그저 지금 행복하게 사용하고 그 보상을 누리고 싶을 뿐입니다. 여러분도 그러기를 바랍니다! 물론 곧 Qwen 4 27B가 나오면 다시 확인해 볼 것입니다.
만약 다른 16GB RTX 4xxx 카드를 가지고 계시다면, 그것들에서도 작동하는지 그리고 어떤 속도가 나오는지 알고 싶습니다. 솔직히 이것이 RTX 4080 하드웨어에 얼마나 의존적인지 판단할 수가 없습니다. 만약 4080을 가지고 있다면 즐기세요 :)
감사 인사 (Shoutouts)
저보다 먼저 NInfer를 개발한 모든 분들께, 여러분은 정말 대단했고 제가 포크(fork) 할 수 있는 안정적인 기반을 제공해 주셨습니다.
NInfer-4090을 만든 sergiuszm에게 특별히 경의를 표합니다. SM_89에 대한 무거운 작업을 이미 다 해주신 것 같습니다.
GSQ 작업과 이를 위한 safetensor 체크포인트(checkpoint)를 제공해 준 ISTA-DASlab에게! 독일에서 오스트리아에 건배를 보냅니다 :) EU로부터 커뮤니티에 중요한 기여가 이루어지는 것을 보는 것이 좋습니다.
제출자 /u/roofkid [링크] [댓글]
AI 자동 생성 콘텐츠
본 콘텐츠는 r/LocalLLaMA의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기