llama.cppベンチマークにおけるTurboQuant

GoogleのTurboQuantの研究を、ただしllama.cpp経由で、自分で自己テストしてみたかったんです。最初の画像は、llama.cppのPRに対するAryan Kapoorのもの、そして2枚目は、Apple SiliconでMetalを使ってこの手法をいじってみた自分の結果です。KVを管理（抑制）できる状態を保ちつつ、この方法が機能することが、見て取れるほどはっきりしています。たぶんどこかで間違えたんだと思うのですが、MetalでのTPSがf16より約50%も低いんです。理由がよく分かりません。

CUDAマシンでいくつかのカーネルを動かそうとする試みもしましたが、出力が完全にひどいものでした。同じようにKVの節約幅は他の人たちと同程度だったのに、それでも自分は何かミスをしてしまったんだと思います。そこは専門家に任せます。

とはいえ、これはローカルモデルを動かしている人たちにとって、大きな追い風に見えます。参考までに私はAnythingLLMをビルドしましたが、ほとんどの人は、せいぜい8〜12GBのVRAM、あるいは16〜32GBのRAMといった構成で、この仕組みによって「より賢い」モデルを現実的なコンテキスト付きで動かせるようになるはずです。GPUに余裕のある人なら、さらに伸ばして250K〜1Mまで作業を広げることもできます。

正直、この件にはワクワクしています。というのも、今は一般向けのハードウェアが良くなってきている一方で、「16Kに制限される」ことで、デバイス上の他のアプリのために最低限の余白を確保できる……という発想は、ローカルモデルでは、たとえ控えめな会話でも、ツール呼び出しのインジェクションや注入されたコンテキストでも、かなり足かせになっています。

私にとっては、これはRAGが死ぬことを意味するわけでは、まだないと思います。むしろ、タスクの面で「デバイス上で現実的にできること」の範囲において、段階的に大きく進む（ステップ関数的な）変化が見られるはずだと考えています。いまはそこそこ複雑なタスク、あるいは連結されたツール呼び出しを行うだけで、ほとんどのウィンドウを使い切ってしまいます。これによって、ローカルで実行できるタスクの数がかなり増える可能性があります。

また、MLXのPRと、VLLMのものもあります。個人的なテストを試したい人はどうぞ。エコシステム全体で見ると開発の初期段階なので、そこには多少の摩擦があるはずです。

一部の人は、これによってクラウドのモデルのトークンコストが下がると思っています。正直なところ、私はそういう差分は（あるいはすでにNVIDIAのnvfp4などで）このやり方をして、マージンとして残すだけになるんじゃないかと予想しています。まあ、誰にも分からないですけどね。