r/LocalLLaMA: 문서 분류 워크로드에서 Qwen 3.5 27B가 약 2000 TPS 기록

r/LocalLLaMA의 한 고신호 스레드는 아주 좁은 local inference use case를 실제 tuning discussion으로 바꿔 놓았다. 크롤링 시점 기준으로 이 글은 203 upvotes와 73 comments를 기록했다. 작성자는 작업이 markdown documents를 분류하는 것이며, input token은 많고 output은 매우 적고, 문서마다 내용이 달라 cache reuse도 거의 없다고 설명했다. 즉, 이것은 범용 benchmark를 주장하는 글이 아니라 chatbot 품질보다 throughput이 더 중요한 production-shaped workload에 관한 field report였다.

그 조건에서 작성자는 10분 동안 320개 문서를 처리하면서 1,214,072 input tokens와 815 output tokens를 다뤘고, 이를 대략 2,000 tokens per second라고 요약했다. 사용한 stack은 unsloth/Qwen3.5-27B-UD-Q5_K_XL.gguf와 공식 llama.cpp:server-cuda13 이미지였다. 또 속도에 크게 기여한 설정으로 vision용 mmproj를 아예 로드하지 않은 점, no-thinking mode, inference 중 context까지 포함해 전체 footprint를 free VRAM 안에 맞춘 점, context size를 128k로 낮춘 점, 그리고 parallelism을 batch size 8에 맞춘 점을 들었다.

이 스레드가 실제로 보여주는 것

• 작성자 스스로 결과가 workload-specific이라고 선을 그었다. 즉 “27B on 5090 일반 성능” 숫자가 아니다.
• 8-way setup에서는 각 요청이 약 16k context를 사용하고, 더 큰 문서는 별도 경로로 보내는 방식이었다.
• 댓글에서는 unified cache -kvu 테스트와 continuous batching -cb 여부가 중요한 최적화 포인트로 제시됐다.

그래서 이 글은 단순한 brag screenshot보다 훨씬 유용하다. local model 대화는 종종 single-token decode speed에만 매달리지만, 실제 업무는 이 사례와 더 비슷한 경우가 많다. 큰 문서를 읽고, 분류하고, 아주 짧은 structured output을 뱉고, 다음 파일로 넘어가는 형태다. 이런 구간에서는 conversational polish보다 batching, context budgeting, 불필요한 multimodal overhead 제거가 더 중요할 수 있다. 이 글의 가치는 성능 수치를 명확한 workload와 함께 제시했다는 데 있다.

subreddit 반응도 그 방향을 보여준다. r/LocalLLaMA는 이 글을 bragging이 아니라 다른 사용자가 보완하고 반박하고 재현할 수 있는 operational note로 다뤘다. 회의적인 댓글조차 claim의 경계를 더 분명하게 만들었다. 반복적인 document pipeline에 local model을 붙이는 팀에게는 이런 현장형 최적화 사례가 polished benchmark chart보다 더 실용적일 수 있다.

출처 및 커뮤니티 토론: r/LocalLLaMA