KVSplit - Appleシリコンで2〜3倍長いコンテキストを実行

 (github.com/dipampaul17)
1 ポイント 投稿者 GN⁺ 2025-05-18 | 1件のコメント | WhatsAppで共有
  • KVSplitは、Appleシリコン上で大規模LLMと長いコンテキストウィンドウを実行できるようにするオープンソースプロジェクト
  • キーと値を分離した精度割り当てにより、最大72%のメモリ削減と品質低下1%未満を達成
  • M1/M2/M3チップおよびMetalフレームワーク向けに最適化
  • 実行速度の改善とメモリ節約を、実測ベンチマークと可視化ツールで実証
  • 容易なインストール、ワンコマンド比較、さまざまなベンチマークおよび分析ツールを提供

紹介: なぜKVSplitが重要なのか

KVSplitは、KVキャッシュ内部のキーと値に異なる精度の量子化を適用することで、Appleシリコン（M1/M2/M3）環境で大規模LLMとはるかに長いコンテキストウィンドウの実行を可能にするオープンソースツール。既存プロジェクトがキーと値を同一に量子化していた限界を克服し、メモリ使用量を大幅に削減しながら、品質低下はほとんど体感できないレベルに抑えている。実際のベンチマーク、速度、品質指標がすべて公開されており信頼性が高く、Metal対応と直感的な比較・可視化ツールによって開発効率も高い。

同種プロジェクトと比べた主な利点は以下の通り。

  • キー・バリュー精度の分離による、より効率的なメモリ管理
  • Appleシリコン特化およびMetalフレームワークのフル最適化対応
  • ベンチマーク、パープレキシティ、メモリ/速度/品質の測定と可視化を統合提供
  • ワンコマンドインストール、モデル互換、llama.cpp統合
  • リアルタイムのメモリ削減可視化と各種比較テストツール

主な特徴とコア内容

概要

  • KVSplitを使うことで、従来よりはるかに大きなLLMと長いコンテキスト長をAppleシリコンで実行可能
  • キーと値それぞれに異なる量子化精度を割り当てることで、メモリ削減と速度改善を両立
  • 最大72%のメモリ節約および速度改善（5〜15%↑）、品質低下1%未満を確認
  • Metalを完全サポートし、Appleシリコンで最適な高速化を実現

主なベンチマーク結果

  • **K8V4（キー8ビット、値4ビット）**構成では
    • 59%のメモリ削減および0.86%の品質低下（パープレキシティ基準）
    • FP16比で5.7%の高速化
  • **K4V4（キー/値ともに4ビット）**構成では
    • 最大72%のメモリ削減
    • 品質は約6%低下。品質感度が低い用途に推奨

メモリ削減効果の比較

  • FP16基準で176MB（8Kトークン）の場合
    • K8V8（8ビットキー/値）: 93.5MB（47%）
    • K8V4（8ビットキー、4ビット値）: 71.5MB（41%）
    • K4V4（4ビットキー/値）: 49.5MB（28%）

主な機能

  • KVキャッシュのキー・値を個別量子化する機能
  • Appleシリコン・Metal完全最適化
  • ベンチマーク/品質（パープレキシティ）/メモリ使用量分析スクリプト
  • 可視化ツールと論文品質のグラフ生成
  • ワンコマンドセットアップとリアルタイム比較機能

プロジェクトフォルダ構成

  • llama.cpp: Metal最適化ビルドを含む
  • models: モデルファイルを保存
  • scripts: ベンチマーク/インストール/比較/可視化スクリプトを含む
  • results, plots: ベンチマーク結果および可視化ファイルを保存
  • README.md

科学的インサイトと実験結果

KVキャッシュの中核的な現象

  • キーベクトルは量子化感度が値ベクトルよりはるかに高い → 品質を維持するにはキーにより高い精度を割り当てる必要がある
  • K8V4がスイートスポット: キー8ビット/値4ビットの配分が、品質とメモリのトレードオフとして最適
    • メモリ59%削減、パープレキシティは0.86%のみ悪化、速度もFP16より高速
  • K4V8はK8V4と同じビット数にもかかわらず、7倍以上大きい品質低下が発生 → キー側精度の重要性を実証

総合的な示唆

  • メモリ効率の確保とモデル品質の維持を両立 → コンシューマ向けハードウェアでも、はるかに長いコンテキストと大きなモデル運用が可能

使用例と設定の推奨

さまざまな量子化精度での実行例

  • 基本（FP16）: ./llama.cpp/build/bin/llama-cli -m models/your-model.gguf -p "プロンプト" -t 8 --flash-attn
  • K8V4推奨: --kvq 8
  • K4V8（DEMO）: --kvq-key 4 --kvq-val 8
  • K4V4（最大削減）: --kvq 4

長いコンテキストの例

  • 32Kコンテキスト: FP16では約1.4GB必要だが、K8V4なら約400MBで実行可能

コマンドラインフラグの説明

  • -t 8: スレッド数、M1/M2/M3では8推奨
  • --flash-attn: Appleシリコン最適化
  • --kvq N: キー/値の両方をNビットに設定
  • --kvq-key, --kvq-val: 個別設定をサポート
  • -c N: コンテキストトークン数（長いほどKVSplitの効果が最大化）
  • -n N: 生成トークン数
  • -f FILE: 文書入力ファイル
  • -m MODEL: モデルパス

高度なベンチマーキングと可視化

  • benchmark_kvsplit.pyで、構成別・シーケンス長別のメモリ/速度/パープレキシティ/スケール特性を測定
  • visualize_results.pyで論文レベルのグラフを生成
  • 結果はCSV/JSONに自動保存され、要約も提供

Appleシリコン最適化とメモリ可視化

  • Metalフレームワークを完全活用
  • メモリ負荷の大きいM1/M2/M3機種で決定的な効果
  • capture_memory.shでリアルタイムのメモリ削減を可視化可能
  • カスタムページアライメントにより、実際の削減量は理論値とわずかに異なる場合がある

要約機能の整理

  • 独立したキー/値ビット精度とカスタム量子化
  • AppleシリコンおよびMetalの完全最適化
  • メモリ/速度/品質の総合ベンチマークを提供
  • 論文品質の可視化とリアルタイム比較、メモリキャプチャをサポート
  • 非常に簡単なインストール/利用インターフェース

引用および参考研究

  • "More for Keys, Less for Values: Adaptive KV Cache Quantization"（2024）
  • "Unifying KV Cache Compression for Large Language Models with LeanKV"（2025）
  • ベース実装: [llama.cpp]、テストモデル: [TinyLlama]

推奨設定と今後の計画

  • K8V4（キー8ビット/値4ビット）: 品質損失0.86%、メモリ59%削減、速度+5.7%で最適なバランス
  • K4V4: 最大のメモリ削減（72%）、品質は約6%低下。メモリ最優先の用途に適する
  • 長いコンテキスト実行に特に強く、2〜3倍長いコンテキスト運用が可能

今後のロードマップ

  • トークン重要度ベースの適応精度
  • レイヤー別の個別量子化
  • モデル別のカスタム最適化（Mistral、Phi-3など）
  • Webデモおよびモバイル（iOS/iPadOS）対応予定

ライセンスと貢献案内

  • MITライセンス
  • 開発者/AI研究者は誰でもIssueおよびPRで貢献可能

関連記事

1件のコメント

 
GN⁺ 2025-05-18
Hacker Newsのコメント

  • 興味深いという反応。なぜこの現象が起きるのかという直感や、どうやって発見したのかへの質問。インストールスクリプトのパッチ適用段階が未完成である点や、git submodule の活用などユーザーフレンドリーな改善提案。また、さまざまな Python 環境を考慮して llama.cpp と Python 依存関係を分離すべきだという提案

    • 良い質問だという反応。主な違いはアテンションの中核的な役割に関係しているとの説明。キーはどのトークンに注目するかを決めてアテンションパターンを作り、値は与えられた情報だけを運ぶことを強調。キーベクトルの量子化が強すぎると、すべてのトークン相互作用に歪みが大きくなる一方、値ベクトルの誤差はそのトークンの情報にしか影響しないと比較。図書館の棚番号（キー）が間違っていれば、まったく見当違いの本を探してしまうという比喩。数学的にも、キーは softmax に入るため小さな誤差でも大きく増幅されるが、値は線形平均なので誤差が相殺されるという説明。本人も論文でこの非対称性を知り、Apple Silicon での影響を定量的に確認したかったという経緯。インストールに関するフィードバックと Python 依存関係の改善も約束
    • パッチが実際には llama.cpp に適用されていないと指摘。引数パースコードはすでに arg.cpp に移動しており意味がないこと、K/V 量子化オプションも 2023 年にすでに llama.cpp に追加されていたことを説明。パッチの存在意義に疑問を呈し、単にコマンドライン引数を変えただけに見えるという意見。この程度の簡単なパッチファイルのために、わざわざ新しいリポジトリの install.sh を実行するのは避けるべきだという強い勧告

  • このパッチが MLX でも可能かを尋ねる質問。MLX のほうが速度が出やすく、このアプローチが Mac ユーザーの実用的な速度での長文対話サポートに役立つのではという期待

    • おそらく可能性はあるが、まだ自分でも MLX を深く掘っている最中とのこと。フレームワーク自体はよく設計されているが、サンプルコードやベンチマーク情報が少なく、まだ未成熟に感じるという感想。むしろ Haskell バインディングに最も期待しているという個人的印象。lazy evaluation の特性が向いているかもしれず、純粋関数的なコンパイルグラフ構造とも相性が良い可能性があるとの見方。Haskell での ML も面白そうだという期待

  • --cache-type-k、--cache-type-v オプションとの実質的な違いがあるのかという質問

    • LLM が単に GitHub スターを集めようとしているだけに見え、実際には既存機能と変わらないという強い意見
    • MLX/MPS では 4 ビット対応がなく、8 ビットすら不十分だった記憶があるとのこと。bf16 対応も最近追加されたもので、以前は Apple GPU 上で type_k/v 方式では最低でも 16 ビット（f16/bf16）までしか使えなかったため、llama.cpp 内部の詳細は分からないが、少し異なるアプローチかもしれないという推測
    • 自分もその違いが気になるという簡潔な同意

  • コードを読んだ結果、このパッチは不要だと判断。該当機能はすでに 2023 年に llama.cpp に取り込まれていたことを PR リンクで確認したという指摘。わざわざ fork リポジトリではなくパッチ適用方式で install.sh を実行させようとしている点にも警戒が必要。リポジトリ内には複数のパッチファイルや重複コードがあり、パッチファイルを上書きするなど構造が混乱していると指摘。実際には --kvq オプションを追加しているだけだが、すでに個別の K/V 量子化オプションが存在する。著者がこうした既存機能を知らなかったはずがないのではと疑っている。複雑なスクリプトを提供するリポジトリのスクリプト実行は勧められない、という意見。HN 投稿や GitHub スター数は多いが内容には誤解を招く部分が多いとの批判。著者が質問を避け続けている点も懸念。加えて、リポジトリとスクリプトの両方が古い llama.cpp コードベースと混在しており、最新構成と合っていないため混乱を招くという結論

    • 自分も怪しい点はいくつも感じていたが、何か見落としているかもしれないので著者の説明を待っていたという言及。しかし危険信号がいくつもあり、GitHub の活動履歴を見ると LLM 生成コードで Popular プロジェクトを埋めている意図すら疑われるという指摘
    • ようやくまともなことを言う人が出てきたという反応。パッチを当てるのではなく、元プロジェクトを fork する構造であるべきだという一点だけでも信頼上のリスクがあると指摘。著者の GitHub 上の実在感そのものも怪しく、人気プロジェクトに LLM の残骸のような PR を大量投稿して自分をコントリビューターに見せかけている傾向があるとの見方。情報汚染、あるいは AI による信頼崩壊の始まりへの懸念も表明

  • すでに変換済みの .gguf 形式モデルにも、差別的 KV 量子化（K8V4 など）を適用できるのか、モデル種類やトークナイザー設定に制限はあるのかという質問

    • KVSplit の大きな利点は、まさに既存の .gguf モデルに特別な変換なしでそのまま使える点だという説明。量子化は実行時の KV キャッシュにのみ適用され、モデル重みとは無関係。--kvq-key と --kvq-val フラグでメモリ保存形式を指定するだけ。本人は LLaMA-3、Mistral、Phi-2/Phi-3、TinyLlama、Qwen などさまざまなモデルで成功を確認したとのこと。ただし llama.cpp の Metal バックエンド専用で、Flash Attention は現在カスタム KV キャッシュ形式をバイパスするため -fa 0 オプションが必要。それ以外は、アテンションを使う Transformer 構造であれば適用可能

  • 64GB、128GB など大容量 Apple Silicon では、このパッチはより速いのか、あるいはより有利なのかという質問。Apple Silicon でコンテキストウィンドウを広げると実際には遅いという話もあり、大容量メモリでどれほど意味があるのか知りたいという内容

    • KVSplit のメモリ削減効果はコンテキスト長に比例するため、大容量 Mac ほど絶対的な恩恵が大きいという説明。128GB の Mac Studio なら数十万トークン規模のコンテキストも扱えるとのこと。ただし根本的な計算速度を上げるものではなく、改善するのはメモリ効率。ベンチマークでは K8V4 設定で 14.5% のスループット向上が観測されたが、これはメモリアクセス効率によるもの。大型モデルでの「遅さ」は主に計算性能の限界によるため、RAM や KV キャッシュ最適化の有無とは別問題。つまり KVSplit はメモリ制約に当たる場面で有用で、実運用では 7B〜13B などの小型モデルにより大きなコンテキストウィンドウを割り当てる使い方が理想的。大型モデルと超長文ウィンドウの両方が必要なら、依然としてサーバー級 GPU が適しているが、Apple ハードウェアで可能な限界を広げる点に意義がある

  • 面白いという反応と、もう少し高い視点からの説明を求める声。2048 トークンモデルを 4〜6k ほどに拡張して使えるのか、128k コンテキストモデルを 256k+ に広げられるのか、ローカルモデルの理想的なユースケースは何かという質問

    • K8V4 構成では 59% のメモリ削減が可能で、最大コンテキスト長は 2.4 倍まで伸ばせるとの説明。つまり 2048 トークンモデルなら約 5000 トークン、8K モデルなら約 19.5K まで拡張可能。実際には、MacBook で本を丸ごと一度に処理したり、大規模コードベースを解析したり、対話アプリで長い会話履歴を保持したりといった用途があるという。メモリ節約効果はコンテキスト長に応じて線形に増加し、自身の経験では 8K コンテキストで KV キャッシュが 176MB から 72MB に減り、128k では節約量が GB 単位になったとのこと。入力長の上限で OOM が発生するケースに最も有効な解決策
    • メモリ削減効果によって特定モデルの必要リソースを下げられるので、用途に応じていろいろ応用できるという意見。ただしコンテキストウィンドウそのものを拡張するのは非専門家には簡単ではないため、より大きなウィンドウ向けに訓練されたモデルを使うほうがよいとの助言。ローカルモデルはオフライン、セキュリティ、実験用途など幅広く使え、多くはモデルチューニング実験のために使っているという話

  • とても良いアイデアと試みだという称賛。GPU にも適用できるのか、ほかの量子化手法と併用できるのかという追加質問

    • この方式はおそらく NVIDIA/AMD GPU にも同様に適用可能で、キーが値より高精度を必要とする原理はハードウェア非依存だという説明。llama.cpp の CUDA バックエンドもすでに --cache-type-k、--cache-type-v オプションで分離設定をサポートしている。現在のパッチは Metal 向けに特化しているが、原理自体はそのまま移植可能。他の量子化手法とも併用でき、KV キャッシュ量子化は実行中にのみ適用されるため、重み量子化とは衝突しない。変換パイプラインの別工程だからという説明。ただし vLLM、TensorRT-LLM など独自のキャッシュ構造を持つエンジンでは別実装が必要。GPU で最大の効果が出るのは FlashAttention 構造に直接統合した場合で、メモリ削減がそのまま速度向上につながる可能性がある

  • よく理解できない点があり、怪しさを感じるのでこのスクリプトの実行は避けるべきだと勧め、通報したと案内

  • 性能がどう変わるのか気になる、より長いコンテキストをメモリに載せても結局計算速度は同じではないかという質問

    • 実際、同じモデル・同じプロンプトで fp16、q8、q4 とキャッシュタイプを変えても、反復速度はほぼ同じに感じるという所感。内部動作は確認していないが、4〜8 ビット SIMD 一括処理でベクトルがパックされることを期待していたものの、実際にはパックされていないように見えるという印象