r/LocalLLaMA, ik_llama.cpp로 Qwen 3.5 prompt ingestion 26배 가속 보고

이 community benchmark는 generation보다 prompt ingestion에 초점을 맞췄다

March 22, 2026 UTC, r/LocalLLaMA에는 Lenovo ThinkStation P520, Xeon W-2295, 128GB DDR4 ECC, NVIDIA RTX PRO 4000 Blackwell 24GB 조합에서 나온 실측 수치가 올라왔다. 환경은 Qwen 3.5 27B Q4_K_M, context 131,072 tokens, KV cache q8_0/q4_0, 용도는 agentic coding이었다. 결과는 강렬했다. mainline llama.cpp b8457에서 ik_llama.cpp b4370으로 바꾸자 prompt evaluation은 약 43 tok/sec에서 1,122 tok/sec로, generation은 약 7.5 tok/sec에서 26 tok/sec로 올라갔다.

글의 요지는 model weights가 바뀐 것이 아니라 runtime이 바뀌었다는 점이다. benchmark 작성자에 따르면 mainline llama.cpp는 Qwen 3.5의 hybrid Gated Delta Network와 Mamba-style SSM path를 34개의 graph node로 쪼개 처리하면서 CPU 관여가 컸다. 반면 ik_llama.cpp fork는 fused GDN CUDA kernel을 사용해 graph splits를 34에서 2로 줄였고, CPU는 대부분 idle 상태가 되며 prompt processing이 사실상 GPU로 옮겨갔다.

왜 local agent workflow에 중요한가

이 discussion이 유용한 이유는 coding assistant와 agentic tool에서 숨어 있는 병목이 raw decode speed가 아니라 prompt ingestion인 경우가 많기 때문이다. 긴 context를 쓰는 local workflow는 codebase, plan, tool trace를 반복해서 다시 읽는다. 이때는 decode benchmark보다 prompt 처리 속도가 실제 체감에 더 크게 작용한다. 작성자도 131K context local agent work가 이제는 painfully slow가 아니라 practical하게 느껴진다고 설명했는데, 이는 짧은 synthetic benchmark보다 운영 관점에 가까운 지표다.

물론 caveat도 있다. Qwen 3.5의 recurrent architecture는 prompt가 바뀔 때마다 전체 prompt를 다시 처리하는 특성이 아직 남아 있는 것으로 보이며, 이는 llama.cpp issue #20225로 추적되고 있다. follow-up comment에서 작성자는 46K tokens 부근에서도 prompt ingestion이 950 tok/sec 이상 유지됐다고 했지만, generation은 10K tokens 근처의 26 tok/sec에서 46K tokens 부근의 약 20 tok/sec까지 떨어졌다고 적었다. 즉 이 fork는 큰 병목 하나를 줄여 주지만, long-session re-ingestion의 architectural cost 자체를 없애지는 않는다.

실무적인 takeaway

Qwen 3.5를 local로 돌리는 사람에게 r/LocalLLaMA thread가 주는 메시지는 단순하다. mainline llama.cpp 하나만 보고 model을 평가하면, 실제로는 model보다 runtime을 benchmark하고 있을 수 있다는 것이다. thread는 Thireus fork의 prebuilt Windows CUDA 12.8 binary를 가리키며, 같은 command-line argument와 같은 OpenAI-compatible API surface를 가진 drop-in replacement라고 설명한다.

출처: r/LocalLLaMA discussion. 관련 release: Thireus/ik_llama.cpp.