llama.cpp --fitでLocalLLaMAがVRAMの壁を再計算
Original: Llama.cpp's auto fit works much better than I expected View original →
r/LocalLLaMAで伸びた投稿は、llama.cppの--fit optionが予想以上に効いたという実用報告だった。投稿者は32GB VRAMなら20GB前後のmodelが限界だと思っていたが、Qwen3.6 Q8と256k contextを試し、weightsがVRAMを超える状態でも5090とOculink構成で57 tokens/sを見たという。重要なのは単一の数字ではなく、「VRAMに全部入らなければ2 t/s」という感覚が崩れたことだ。
コメント欄はすぐにtuningの話になった。あるユーザーはKV cacheをQ8_0にquantizeすれば、256k contextをより多くVRAMに収めてtoken speedをさらに上げられるかもしれないと指摘した。別のユーザーはQwen3.6 35BがMoE architectureでactive parameterが約3Bである点を挙げ、dense 27B modelでは同じ結果にならない可能性を示した。さらに、Qwen3.6 35B quantで12 t/sから48 t/sに上がったという報告もあった。
--fitはmodelごとのmanual tensor split作業を減らせる可能性がある。- KV cache format、fit target、quantization、interconnectは依然として結果を左右する。
- MoEとdense modelを分けて考えないと、数字を誤って一般化しやすい。
community discussion noted that automatic placementが常に勝つわけではない。複数GPUや複数machineにまたがるbarely-fit modelでは、manual splitの方が安定するという反例も出た。それでもこのthreadの価値は大きい。local inferenceは単なるVRAM容量表ではなく、runtime placement、cache、quantizationを合わせて調整する領域になっている。小規模環境のユーザーほど、古い前提をもう一度試す理由がある。
元threadは r/LocalLLaMA にある。
Related Articles
最近のr/LocalLLaMA投稿は、Qwen3.5 27Bがqualityとdeployabilityのバランスに優れたlocal modelだと主張する。投稿者はRTX A6000 48GBとllama.cppで約19.7 tokens/secを報告し、commentsではdense 27BとMoEのVRAM economicsが詳しく議論された。
LocalLLaMAが反応したのは、大きなMoE modelを限られたVRAMで動かす時の痛点を現実的に突いていたからだ。投稿者はQwen3.5-122B-A10Bで、最近routeされたexpertを追跡してhotなものだけVRAM cacheに置くllama.cpp forkを試し、同程度の22GB台VRAM使用量でlayer-based offloadよりtoken generationが26.8%速いと共有した。
r/LocalLLaMAで、Qwen3.5-35B-A3Bを単一RTX 3090で運用したagentic coding検証が大きな反響を得た。投稿者は100+ tokens/sと実務的なコーディング課題の通過を報告したが、コメントではツール利用の安定性や量子化設定による再現差も指摘されている。