抄録
2025年2月10日シングルGPU(24GB RAM)/マルチGPUおよび382GB RAMでDeepseekR1およびV3をサポート。
KTransformersチーム(旧CPU/GPUハイブリッド推論オープンソース・プロジェクト・チーム、DeepSeek-V2で知られる)の皆さん、こんにちは。
Kトランスフォーマー チームはDeepSeek-R1/V3サポートの要望を受けており、ついにそれが実現したことを発表できることを大変嬉しく思っている!
お待たせしました、KTransformersチームが本当に素晴らしいものを作ってくれました!
本日、KTransformersチームは、以下のビデオにあるように、DeepSeek-R1/V3への対応だけでなく、KTransformersがDeepSeek-R1/V3をサポートすることを発表できることを誇りに思います:
https://github.com/user-attachments/assets/ebd70bfa-b2c1-4abb-ae3b-296ed38aa285
- [更新!!!!] ローカル671B DeepSeek-Coder-V3/R1。 Q4_K_Mバージョンは、14GBのビデオメモリと382GBのRAMでのみ動作する。
- プリフィル速度(トークン/秒)。
- KTransfermor: 54.21 (32コア) → 74.362 (デュアルパス、2×32コア) → 255.26 (最適化されたAMXベースのMoEカーネル、V0.3のみ) → 286.55 (6つのエキスパートを選択的に使用、V0.3のみ)
- とともに ラマ.cpp と比較して、2×32コアで最大10.31トークン/秒を達成した。 27.79倍加速.
- デコード速度(トークン/秒)。
- KTransfermor:8.73(32コア)→11.26(デュアル、2×32コア)→13.69(6エキスパート選択使用、V0.3のみ)
- 2×32コアでのllama.cppの4.51トークン/秒と比較すると、最大で次のようになる。 3.03倍加速.
- プリフィル速度(トークン/秒)。
KTransformersチームは、Intel AMXアクセラレーション・カーネルや選択的エキスパート活性化メソッドなど、今後の最適化についてもプレビューを行った。V0.3-previewでは、プリフィルは最大286トークン/sで、ネイティブ推論のllama.cppよりも高速だ! 28回.
バイナリの配布が開始され、ソースコードもできるだけ早く公開される予定だ!ホイールパッケージはこちら.
準備条件
KTransformersチームは、以下の構成で最高のパフォーマンステスト(V0.2)を実施した:
CPU: Intel (R) Xeon (R) Gold 6454S 1T RAM (2NUMAノード)
GPU:4090D 24Gビデオメモリー
メモリ:標準DDR5-4800サーバーメモリ(1 TB)
ベンチマーク結果
V0.2
セットアップ
- モデル:DeepseekV3-q4km (int4)
- CPU: cpu_model_name: Intel (R) Xeon (R) Gold 6454S、32コア/パス、2パス、2ヌマノード
- GPU:4090D 24Gビデオメモリー
- KTransformersチーム、ウォームアップを終えてテスト
メモリ消費。
- シングル:382G RAM、最低14GB VRAM
- デュアル:1T RAM、最低14GB VRAM
ベンチマーク結果
6人の専門家」シナリオはV0.3プレビューの一部です。
| プロンプト
(500 トークン) | デュアルKトランス(6人のエキスパート) | デュアルKトランス(8エキスパート) | シングルKtrans(6人の専門家) | シングルKtrans(8人の専門家) | llama.cpp(8人の専門家) |
---|---|---|---|---|---|
プレフィル・トークン/秒 | 97.32 | 82.94 | 65.14 | 54.21 | 10.31 |
デコード・トークン/秒 | 13.69 | 12.208 | 10.303 | 8.73 | 4.51 |
デコード速度を最大で 3.03倍プレフィルスピードの最大増加 9.44倍. KTransformersは、デコードの高速化という点ではプリポップドには及ばないようで、デコードの最適化にはまだ多くの余地がある。
V0.3-プレビュー
セットアップ
- モデル:DeepseekV3-BF16(オンラインではCPUをint8、GPUをint4として定量化)
- CPU: cpu_model_name: Intel (R) Xeon (R) Gold 6454S、32コア/パス、2パス、2ヌマノード
- GPU: (1~4)x 4090D 24GVRAM (プロンプトが長いほど、より多くのメモリが必要)
メモリ消費。
- 644GBのRAM、少なくとも14GBのグラフィックメモリ
ベンチマーク結果
プロンプトの長さ | 1K | 2K | 4K | 8K |
---|---|---|---|---|
KTrans (8 エキスパート) プレフィル・トークン/秒 | 185.96 | 255.26 | 252.58 | 195.62 |
KTrans (6人のエキスパート) プレフィル・トークン/秒 | 203.70 | 286.55 | 271.08 | 207.20 |
KTrans V0.3は、KTrans V0.2よりもプリフィリングが速い。 3.45倍llama.cppより速い。 27.79倍. このプリフィルのスピードアップは本当に印象的で、KTransformersはプリフィルの最適化に力を入れているようだ。
デコード速度はKTrans V0.2(6エキスパート版)と同じなので省略。 バージョンV0.3は、主にプレフィルのスピードの改善に重点を置いているようだ。
主な加速は以下からもたらされる。
- インテルAMX命令セットとKTransformersチームが設計したキャッシュフレンドリーなメモリレイアウト
- 領域外データのオフラインプロファイル結果に基づき、より少ないエキスパートを選択するエキスパート選択戦略
DeepSeekV2、DeepSeekV3、DeepSeekR1のKTransformersチームによると、次のようになります。
推論でアクティブにするエキスパートの数を少し減らすと
出力品質は変わらない。しかし、デコードとプリフィリングのスピードは変わる。
これは心強い。KTransformersチームのデモは、この発見を利用している。 スピードアップの鍵は「エキスパート選択戦略」にあるようだが、アウトプットの質をいかに落とさないようにするかは、もっと検証を重ねる必要がある。
仕組み
V0.2デモ
シングルパス版(32コア)
KTransformersチームの ローカルチャット
テストコマンドはこうだ:
git clone https://github.com/kvcache-ai/ktransformers.git
cd ktransformers
numactl -N 1 -m 1 python ./ktransformers/local_chat.py --model_path --gguf_path --prompt_file --cpu_infer 33 --。キャッシュレンズ 1536
。
は、ローカルパス、またはオンラインのハギングフェイスから設定されたパス(例:deepseek-ai/DeepSeek-V3)です。 オンライン接続に問題が発生した場合は、ミラー(hf-mirror.com)を使用してみてください。
はオンラインパスでも可能ですが、サイズが大きいので、KTransformersチームはそれをダウンロードし、モデルを希望するフォーマットに数値化することを推奨しています!
命令 numactl -N 1 -m 1
NUMAノード間のデータ転送を回避する設計
デュアルパス版(64コア)
インストールする前に(install.sh または dev_install を作る
)を通して 輸出 USE_NUMA=1
環境変数の設定 USE_NUMA=1
(すでにインストールされている場合は、この環境変数を設定して再インストールしてください)
KTransformersチームの ローカルチャット
テストコマンドはこうだ:
git clone https://github.com/kvcache-ai/ktransformers.git
cd ktransformers
export USE_NUMA=1
make dev_install # または sh ./install.sh
python ./ktransformers/local_chat.py --model_path --gguf_path --prompt_file --cpu_infer 65 --。キャッシュレンズ 1536
。
パラメータも同じ意味を持つ。しかし、KTransformersチームは双方向を使用しているため、以下のようになります。 cpu_infer
65に設定
V0.3デモ
デュアルパス版(64コア)
KTransformersチームの ローカルチャット
テストコマンドはこうだ:
wget https://github.com/kvcache-ai/ktransformers/releases/download/v0.1.4/ktransformers-0.3.0rc0+cu126torch26fancy-cp311-cp311-linux_x86_64.whl
pip install ./ktransformers-0.3.0rc0+cu126torch26fancy-cp311-cp311-linux_x86_64.whl
python -m ktransformers.local_chat --model_path --gguf_path --prompt_file -cpu_infer 65 -.- キャッシュレンズ 1536
-cpu_infer 65 - cache_lens 1536
パラメータの意味はV0.2と同じです。ただし、KTransformersチームはデュアルパスを使用しているため cpu_infer
65に設定
いくつかの説明
- KTransformersチームはまた、Xeon Gold CPUの2つのNUMAノードをさらに活用したいと考えていた。
ノード間のデータ転送のコストを回避するために、KTransformersチームは次のようにしている。
キーマトリクスは両ノードで「コピー」されるため、より多くのメモリを消費するが、プリポピュレーションとデコードのプロセスは高速化される。
ただし、この方法はメモリを大量に使い、ウエイトの読み込みに時間がかかるので、読み込み中はしばらくお待ちください!
KTransformersチームは、この膨大なメモリ・オーバーヘッドを最適化する予定です。KTransformersチームが今後何を考え出すか、楽しみにしています。 - コマンドパラメータ
--cpu_infer 65
使用するコア数を指定する(物理的なコア数より多くても構わない。
しかし、多ければいいというものではない。実際のコア数より少し少なくなるように調整してください) - なぜCPUとGPUのハイブリッド推論なのか?
ディープシーク MLAアルゴリズムは計算負荷が高い。CPUで完全に実行することも可能だが、重い計算をGPUにオフロードすることで、パフォーマンスを劇的に向上させることができる。CPUがエキスパート計算を処理し、GPUがMLA/KVCacheを処理することで、このハイブリッド推論戦略は、CPUとGPUの両方をフルに活用し、スマートに見える。 - スピードアップはどこから来るのか?
- エキスパート・オフロード: 従来のレイヤーまたはKVCacheベースのオフロード(llama.cppに見られる)とは異なり、KTransformersチームはエキスパート計算をCPUに、MLA/KVCacheをGPUにオフロードします。
- インテルAMX最適化 - KTransformersチームのAMXアクセラレーション・カーネルは、既存のllama.cpp実装よりも数倍高速に動作するように慎重に調整されている。KTransformersチームは、クリーンアップ後にこのカーネルをオープンソース化する予定であり、アップストリームのllama.cppにコードを提供することも検討している。AMX命令セットの追加は、KTransformersの高速化の重要な要因の1つであると思われる。
- なぜインテルCPUなのか?
インテルは現在、AMX命令のようなものをサポートしている唯一のCPUベンダーであり、AVXのみの代替よりもはるかに優れたパフォーマンスを提供している。KTransformersの最高のパフォーマンスを体験するには、インテルCPUが適しているようだ。