r/LocalLLaMA: 文書分類ワークロードでQwen 3.5 27Bが約2000 TPS

r/LocalLLaMAの高信号スレッドの一つが、かなり限定的なlocal inference use caseを実用的なtuning discussionへ変えた。crawl時点でこの投稿は203 upvotes、73 commentsだった。投稿者によれば、対象はmarkdown documentsの分類で、input tokenは多く、outputはごく少なく、文書ごとに内容が異なるためcache reuseもほとんどない。つまりこれは汎用benchmarkではなく、chat品質よりthroughputが重要なproduction-shaped workloadについてのfield reportだった。

その条件で、投稿者は10分間に320 documentsを処理し、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 image。さらに、速度に効いた設定として、vision用のmmprojを読み込まないこと、no-thinking mode、contextを含めた全体footprintをfree VRAMに収めること、context sizeを128kへ下げること、parallelismをbatch size 8に合わせることが挙げられていた。

このスレッドが実際に教えていること

• 投稿者自身が、これはworkload-specificな数値であって一般的な“27B on 5090”性能ではないと明示している。
• 8-way setupでは各requestが約16k contextを使い、より大きい文書は別経路へ回していた。
• commentではunified cacheの-kvuやcontinuous batchingの-cbが重要な調整点として議論された。

そのため、この投稿は単なる自慢のscreenshotよりずっと有用だ。local modelの議論はsingle-token decode speedに寄りがちだが、実運用ではこの例に近い仕事が多い。大きな文書を読み、分類し、短いstructured outputだけ返し、次のファイルへ進む。そうした領域ではconversationの見栄えより、batching、context budgeting、不要なmultimodal overheadの除去のほうが効くことがある。投稿の価値は、数値をはっきりしたworkload条件に結びつけて示した点にある。

subredditの反応もその方向性を映していた。r/LocalLLaMAはこれをbrag postではなく、他の実務家が調整・反証・再現できるoperational noteとして扱っていた。懐疑的なcommentですら、主張の境界条件を明確にするのに役立っていた。反復的なdocument pipelineへlocal modelを組み込みたいチームにとって、こうしたfield reportはpolished benchmark chartより実用的だ。

出典およびCommunity discussion: r/LocalLLaMA