LocalLLaMA, K=64 커널 패치로 Blackwell 워크스테이션의 Qwen3.5-397B 추론 개선 주장

커뮤니티가 붙잡고 있던 병목

2026년 3월 14일 r/LocalLLaMA에 올라온 글은 RTX PRO 6000 같은 SM120 Blackwell 워크스테이션 GPU에서 발생하던 구체적인 추론 병목을 다뤘다. 작성자 설명에 따르면 NVFP4 기반 MoE 모델에 필요한 block-scaled GEMM 경로가 이 하드웨어 계열에서 제대로 동작하지 않아, usable tile shape가 부족했고 결국 느린 fallback kernel로 밀려났다는 것이다. 결과적으로 Qwen3.5-397B-A17B-NVFP4 같은 대형 모델이 하드웨어 잠재력을 충분히 쓰지 못했다.

글에서 연결한 FlashInfer PR #2786는 해결 방향을 명확히 적고 있다. SM120용 K=64 tile shape를 추가하고, K=64에서 발생하던 scale-factor layout mismatch를 고쳐 block-scaled MoE GEMM이 컴파일·실행되도록 만드는 것이다. PR 요약은 이 변경으로 RTX PRO 6000 환경의 single-user decode throughput이 대략 2배 가까이 개선됐다고 주장한다.

숫자를 어떻게 읽어야 하나

Reddit 글은 경로별 수치도 함께 공개했다. WSL2에서는 55 tok/s, native Linux로 옮기면 119 tok/s, driver와 설정 최적화 후 142 tok/s, 그리고 custom K=64 kernel 적용 후 283 tok/s라는 흐름이다. 다만 작성자는 가장 높은 283 tok/s 수치가 short prompt와 thinking mode가 켜진 상태에서 측정된 값이라고 명시했다. Multi-Token Prediction이 예측하기 쉬운 <think> token에서 높은 acceptance를 보이기 때문에 수치가 부풀려질 수 있다는 설명이다. 실제 사용에 가까운 real prompt, thinking off 조건에서는 대략 130-136 tok/s가 더 현실적이라고 적었다.

이 구분이 중요하다. 핵심은 “워크스테이션 Blackwell이 갑자기 모든 datacenter benchmark를 따라잡았다”가 아니라, 커뮤니티 패치가 불필요한 커널 제약을 줄이고 실제 성능을 의미 있게 회복시킬 수 있다는 점이다.

왜 LocalLLaMA가 반응했나

이 사례는 LocalLLaMA가 좋아하는 전형적인 기술 토론이다. 단순한 “더 빨라졌다”가 아니라 shared memory 한계, CUTLASS tile 선택, upstream 가능성이 있는 patch라는 구체적 근거가 붙어 있기 때문이다. PR 본문도 99KB shared memory를 가진 SM120 GPU에 맞춰 K=64 block-scaled MoE GEMM 경로를 여는 것이 핵심이라고 설명한다. 만약 이 수정이 stack 전체로 퍼지면, local Blackwell 환경에서 Qwen3.5-397B나 DeepSeek 계열 MoE 모델을 돌리는 사용자에게 직접적인 영향이 있다.

물론 수치는 self-reported이고 PR도 아직 open 상태이므로, 보수적으로 보면 방향성 신호에 가깝다. 그래도 local AI 성능이 이제는 모델 weight보다 커널 성숙도와 시스템 통합에 더 크게 좌우될 수 있음을 보여준다는 점에서 충분히 가치 있는 커뮤니티 스토리다.

원문: FlashInfer PR #2786, CUTLASS issue #3096. 커뮤니티 반응: r/LocalLLaMA.