この状況のすべてを頭に入れるのに苦労しています。私の目標は、フロンティアモデルを使うのと同じ環境（ハーネス）で、低複雑度のタスクを解くためのローカルエージェントです。つまり自然に大きなコンテキストウィンドウが必要になります。低複雑度というのは、ゼロから適当に何かを生成するというより、大きなコードベースに対して単純な修正をするだけ、という意味にもなり得るからです。
そこで最初は、（私はWindowsなので）Tom's turboquantにllama.cppのフォークを組み合わせ、Qwen 3.6のQ4およびIQ4モデルで、コンテキストウィンドウ200kにしました。ええ、動きました。こちらが与えたサンプルプロジェクト一式を読み取り、（できる範囲で）監査（オーディット）を作成できます。ですが、コンテキストウィンドウの深いところに入ると、速度がただただ悲しい感じで、10〜11 tps、あるいはそれ以下ですかね？
そこで、いろいろな投稿を掘ることになりました。どれも「単一の3090で、5 billion規模のコンテキストウィンドウ（だいたいそんな感じ）を使って、85〜100 tps出る」といった内容でした。私は、WSL2＋vLLMにMTPやGenesisパッチを入れて試しました。ええ、起動はするのですが、十分なコンテキストウィンドウにすると必ずOOMになります。また、ツールまわりの問題などもあるように見えます。
Luce DFlashの解決策も試しましたが、調べてみると、そもそも動作するサーバー解決策が用意されていなかったことが分かりました。大きなVRAM問題を直すPRを2つ出しましたが、その後、thinking（推論）のフォーマットが正しくできず、さらにツールをまったく使えないことが判明しました。まぁ、少なくとも「hi」のチャットでは速かったです。
今は別のllama.cppフォークをいくつか試し、それらにある明らかな問題を修正しようとしていますが、この時点で、正直全部を疑いたくなっています。
実タスクで、3090＋Qwen 3.6 27Bのtpsはどれくらい出ますか？適切なハーネスで、数千単位のコンテキストを含む実際のコーディングタスクのようなものです。私が読んだ限りでは、MTPやDFlashのような技術は、予測が正しくなるのが非常に難しくなるため、コンテキストが長くなると（とても、とても）急速に劣化します。予測モデルは常にコンテキストのごく一部しか見ないから、という理解で合っていますか？
ただ一方で、長いチャットでも30 tpsくらい維持できると主張する人もいます。その「チャット」が重要です。これらのベンチマークは、モデルに1つのプロンプトを与えることで得られる数値を示しています。これは、多段階のチャットよりもとにかくとても高速だからです。しかし実際のエージェント的な使い方では、往復のフィードバックが必要になることがよくあります。
そしてはい、私はthinkingが必要です。それはコーディングタスクでは重要ですが、thinkingが入ることで、予測システムの速度がさらに壊れる（もっと悪くなる）ように見えますが、それは本当なのでしょうか？
それで教えてください。これはスキルの問題ですか？それとも、これらの投稿が思わせるほど単純ではないのでしょうか？
[link] [comments]
