llama.cpp 속도를 개선하기 위해 뭔가 조치를 취해야 한다. exllamav3 같은 CPU/GPU 엔진을 포함해 다른 어떤 엔진에 비해서도 너무 늦게 들어오는 지원을 PR로 공유하는 게 무슨 의미인지 모르겠다.

가장 큰 문제는 프리필 속도로, exllamav3에 비하면 완전히 처참한 수준이다. RAM과 VRAM에 분산해 돌리는 MoE 모델은 llama.cpp에서 민망할 정도로 느리다. 적어도 TR 3960x, DDR4 256GB, 3090 2장 같은 구형 하드웨어에서는 콜드 상태로 약 2만 5천~3만 토큰을 처리할 때 GLM 5.3 IQ3_S/IQ3_XXS는 TTFT 900초에 디코딩 4 t/s, GLM 5.3 EXL3 3.0 bpw는 TTFT 120초에 디코딩 3 t/s였다. 물론 극단적인 사례지만 'Flash' 모델이라고 비교해 나은 것도 아니다. llama.cpp에서 ubatch를 조정하더라도(EXL3는 더 효율적이라 더 큰 청크 크기가 가능하다) 그 대가로

지금까지 만들어진 어떤 하드웨어에서든 어떤 모델이든 실행하려 하면 할 수 있는 데에는 한계가 있다. 그래도 여전히 중요한 레퍼런스 구현이다.

llama.cpp와 strix-llama.cpp를 보면 초집중 최적화를 하지 않는 데는 이유가 있을 것이다. 코드베이스가 하드웨어별 최적화에 우호적이지 않아 업스트림에서 리베이스할 때마다 고통스럽고 필연적으로 무한한 'if' 문제가 생긴다. 이것을 최적화하면 저것이 깨지는 상황에서는 유지보수성 높은 코드베이스를 위해 커스텀 엔진이 더 나은 해법일 것이다.

모델별 커널 최적화를 플러그인으로 붙일 수 있는 기능은 모든 추론 엔진의 핵심 아키텍처 특성이어야 한다. LLM이 이렇게 좋아진 지금 vllm, sglang, llama.cpp 등이 플러그인으로 끼워 쓰는 모델별 레퍼런스 메가 커널이 없을 이유가 없다. 어느 면에서 ML 분야에서 일하는 이들이 깊이 경험 많은 소프트웨어 엔지니어가 아니라는 점이 드러난다. 이는 수십 년 전부터 해결된 문제들(API를 통한 디커플링으로 모듈화)인데도 모두가 유기적으로 자라난 단일 메인라인 방식을 무계획적으로 고수하다 결국