r/LocalLLaMA 벤치마크: 단일 RTX 5080에서 80B MoE 프리필 3,324 tok/s를 보고한 <code>Krasis</code>

게시글 핵심: prefill 병목을 겨냥한 runtime 설계

r/LocalLLaMA의 원문 게시글은 수집 시점 기준 점수 180, 댓글 53을 기록했다. 작성자는 Krasis를 “대형 MoE 모델용 하이브리드 CPU/GPU runtime”으로 소개하며, GPU가 prefill(입력 읽기)을 담당하고 CPU가 decode(출력 생성)를 담당하는 분업 구조를 제시했다. 목표는 단순하다. VRAM에 모델 전체가 올라가지 않는 환경에서도 긴 입력 처리 속도를 실사용 가능한 수준으로 끌어올리는 것이다.

공개된 수치와 테스트 조건

게시글에 제시된 대표 수치는 RTX 5080 16GB 단일 카드 환경에서 Qwen3-Coder-Next (80B, Q4) prefill 3,324 tok/s, 35K context 기준 TTFT 9.7s, decode 14.9 tok/s다. 추가로 EPYC 7742 + RTX 2000 Ada 16GB 조합에서도 Q4/Q8 결과가 제시됐고, Qwen3.5-35B-A3B, Qwen3-235B-A22B, DeepSeek V2-Lite 등 여러 모델의 비교 표가 포함됐다.

작성자 설명에 따르면 prefill 측정은 10K-50K prompt 구간에서 수행하고, decode는 64-token 생성 평균으로 제시했다. 숫자 자체보다 중요한 부분은 긴 컨텍스트에서 “읽기 단계”를 GPU 중심으로 밀어 올렸다는 설계 의도다.

왜 이 접근이 주목받는가

• IDE나 agent 워크플로우에서 입력 prompt가 길어질수록 prefill 지연이 체감 병목이 된다.
• 기존 offload 방식은 CPU 구간이 길어져 “첫 토큰까지 대기”가 길어지기 쉽다.
• RAM을 더 쓰더라도 prefill을 가속하면 체감 반응성이 개선될 수 있다.

트레이드오프와 검증 포인트

게시글과 저장소 설명은 비용도 명확히 적는다. 시스템 RAM 요구량이 크고(작성자 설명 기준 대략 quantized model size의 2.5배 수준), NVIDIA 의존성, 첫 실행 전처리 시간, 큰 디스크 캐시 등이 필요하다. 또한 dense model보다 MoE에 최적화되어 있어 범용 runtime 대체를 바로 주장하기는 어렵다.

그럼에도 이 사례는 “VRAM이 충분하지 않아도 긴 컨텍스트 처리 품질을 유지할 수 있는가”라는 실무 질문에 구체적 수치로 답하려는 시도라는 점에서 의미가 있다. 커뮤니티가 추적해야 할 다음 단계는 재현성, 다중 사용자 부하 시 성능, 그리고 더 큰 모델 구간에서의 안정성 검증이다.

출처: Reddit 원문, Krasis GitHub