巨大MoEローカル推論にKTransformersが選ばれる理由

DeepSeek-R1 や Kimi K2、Qwen3、GLM-5 のように、オープンウェイトで公開される大規模 MoE（Mixture-of-Experts）モデルが急速に増えています。「クラウド API のコストを抑えたい」「機密データを外に出せない」といった理由から、手元の GPU サーバで動かしたいと考えるエンジニアも多いのではないでしょうか。

一方で、671B パラメータ級の MoE モデルを従来の推論エンジンで動かそうとすると、H100 を 8 枚並べる構成が現実的で、事業会社の一チームや個人が用意できる規模とは大きくかけ離れています。「単一 GPU で DeepSeek-R1 671B が動く」という話題を目にして KTransformers に興味を持ったものの、「本当に動くのか」「llama.cpp や vLLM とどう違うのか」「開発は健全に続いているのか」を短時間で判断できず、選定を保留している方も少なくないはずです。

本記事では、清華大学 MADSys Lab を中心に開発されている OSS KTransformers（GitHub リポジトリ）について、公式 README・公式ドキュメント・SOSP'25 論文の一次情報のみを根拠に、次の 3 点を整理します。

1. なぜ単一 GPU でも巨大 MoE モデルが動くのか、その技術アーキテクチャ
2. 対応モデル・ハードウェア要件・公表されているベンチマーク数値
3. llama.cpp・ik_llama.cpp・vLLM・SGLang との棲み分けと、KTransformers を採用すべきユースケース

なお本記事は動作検証を伴わないドキュメントベースの解説であり、実行手順の再現性は公式ドキュメントに委ねます。あくまで採用可否の一次判断のための情報整理と位置づけてお読みください。

清華大学発のCPU-GPU異種計算OSS「KTransformers」とは

KTransformers は、GitHub の kvcache-ai/ktransformers で公開されている OSS で、公式 description には次のように記されています。

A Flexible Framework for Experiencing Heterogeneous LLM Inference/Fine-tune Optimizations

（出典: https://github.com/kvcache-ai/ktransformers、リポジトリ description）

一言で言えば、CPU と GPU を組み合わせた「異種計算（Heterogeneous Computing）」によって、巨大 LLM の推論・ファインチューニングを限られた GPU 資源で実行するためのフレームワークです。

主な基本情報は以下のとおりです。数値は本稿執筆時点で gh api /repos/kvcache-ai/ktransformers から取得したものです。

（出典: リポジトリメタデータ gh api /repos/kvcache-ai/ktransformers、および 公式サイト の About セクション）

補足として、archived=false かつ fork=false の本家リポジトリであり、直近も継続的にコミットが行われている点は、初見のエンジニアが「メンテナンス状況が健全か」を判断するうえで重要な材料です。学術的な裏付けとして、SOSP'25（システム分野のトップカンファレンス）にも「KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models」が採録されており、単なる実装プロジェクトではなくアーキテクチャ研究としての正当性も持ち合わせています。

なぜ巨大MoEモデルは単一GPUで動かしにくいのか

KTransformers の設計思想を理解するには、まず「なぜ従来手法では巨大 MoE を単一 GPU で動かしにくいのか」を押さえておく必要があります。

従来アプローチ（フル GPU 常駐）の限界

vLLM や TensorRT-LLM のような本番向け推論エンジンは、原則としてモデルの重み全体を GPU VRAM に常駐させる設計です。この設計は、複数ユーザからのリクエストを高速にさばくためには理にかなっていますが、モデルサイズが大きくなるほど GPU コストが線形以上に跳ね上がります。

たとえば DeepSeek-R1 671B パラメータのモデルを FP8 で保持するだけでも数百 GB の VRAM が必要になり、80GB VRAM の H100/H200 を 8 枚並べる、あるいはさらに多くの GPU を用意するのが現実解になります。個人開発者やスタートアップにとっては手が届きにくく、事業会社でも POC の段階で数千万円の GPU 投資は正当化しにくいのが実情ではないでしょうか。

MoE モデルのスパース性が生む最適化の余地

一方で、DeepSeek-V3 / R1 や Kimi K2、Qwen3 の MoE 系モデルには「1 トークンごとに全パラメータを使うわけではない」という特性があります。各層に多数のエキスパート（feed-forward サブネットワーク）が存在し、ルータが各トークンに対して上位 K 個（top-k）だけを選択して計算します。つまり、総パラメータのうち実際にアクティブになるのは一部というスパース性を持っているのが MoE の本質です。

このスパース性を素直に生かせば、「よく使われるエキスパートだけを GPU に常駐させ、残りは CPU 側メモリに置いて必要時のみ計算する」という異種計算スケジューリングが理論的には成立します。KTransformers はまさにこの発想を、AMX や NUMA といったハードウェア機能まで踏み込んで体系的に実装した OSS です。次章でその中身を見ていきます。

KTransformersの技術アーキテクチャ

KTransformers が「単一 GPU + 大容量 RAM」で巨大 MoE を実行できるのは、単一のトリックではなく複数のレイヤの最適化が組み合わさっているためです。SOSP'25 論文（KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models — MADSys Lab）によれば、既存システムと比較して prefill で 4.62〜19.74×、decode で 1.25〜4.09× のスピードアップが報告されています。

以下、公式 README とサブモジュール kt-kernel の README から要点を整理します。

ホット/コールドエキスパートの CPU-GPU 分割配置

KTransformers は、MoE 層のエキスパートを利用頻度に応じて「ホット」「コールド」に分類し、ホット側を GPU、コールド側を CPU に配置します。GPU 側にはアテンション計算と高頻度エキスパートを、CPU 側には低頻度エキスパートを常駐させ、それらをレイヤ単位で協調させる設計です。

これにより、モデル全体を GPU VRAM に載せる必要がなくなり、RTX 4090（24GB VRAM）+ 大容量 DDR5 RAM のような構成でも DeepSeek-R1 671B クラスの推論が成立します（出典: TechNode「Tsinghua University's KTransformers enables full-powered DeepSeek-R1 with low-cost graphics card」）。

AMX / AVX512 / AVX2 最適化カーネル

CPU 側でエキスパート計算を担わせる以上、CPU 側のスループットが性能の律速になります。KTransformers はこれに対して、CPU 世代ごとに最適な SIMD 命令セットを使い分けるカーネルを用意しています。

• Intel Sapphire Rapids 以降: AMX（Advanced Matrix Extensions）
• 2020 年以降の Intel CPU: AVX512 + BF16
• 2013 年以降の広範な CPU: AVX2
• AMD EPYC 系: BLIS（AMD の高性能 BLAS 実装）
• Ascend NPU 向け: KML

サブモジュール kt-kernel の README には、これらのバックエンドが単一 API から選択できる仕組みが説明されています。

NUMA 対応スレッドプールと非同期スケジューリング

大容量 RAM を積んだサーバは NUMA（Non-Uniform Memory Access）構成のことが多く、無配慮にスレッドを走らせるとリモート NUMA ノードへのメモリアクセスで大幅な性能低下が起こります。KTransformers は NUMA トポロジを認識するスレッドプールを持ち、エキスパートごとに適切なノードでスレッドを実行することでこの問題を回避します（出典: kt-kernel README）。

さらに GPU と CPU の計算・通信を非同期にオーバーラップさせるスケジューリングを備えており、片方が待たされる時間を最小化する設計になっています。

3 層 KV キャッシュ（GPU-CPU-Disk）

長いプロンプトや、システムプロンプトを共有する複数リクエストの処理では、KV キャッシュの再利用が推論効率を大きく左右します。KTransformers は KV キャッシュを GPU → CPU → Disk の 3 層で階層管理し、GPU 上のキャッシュから溢れた分を CPU メモリに、さらに Disk（NVMe）に段階的にオフロードします（出典: 公式 README）。これにより、プレフィックスキャッシュの再利用範囲が大きく広がります。

KV キャッシュ再利用の別アプローチとして、プレフィックス／セッション横断のキャッシュ共有を推論エンジンから独立した基盤として提供する LMCache（KV キャッシュ再利用に特化した OSS） もあります。LMCache が「KV キャッシュ層そのものを共有基盤化する」方向に振っているのに対し、KTransformers は「メモリ階層をまたいだオフロードで実行時スループットを担保する」方向に振っている、と整理すると住み分けが理解しやすいでしょう。

量子化・データ型サポート（INT4 / INT8 / FP8 / BF16 / GGUF / RAWINT4）

対応するデータ型・量子化形式も広く、モデル配布形式や CPU 能力に応じて選択できます。

• BF16: Native 精度
• FP8: 主に DeepSeek 系 FP8 モデル向け
• INT8 / INT4: AMX 向けに変換して利用
• GGUF: llama.cpp エコシステムの GGUF フォーマットを LLAMAFILE バックエンド経由で利用
• RAWINT4: Kimi 系モデル向けの独自量子化

（出典: kt-kernel README）

GGUF が読める点は、llama.cpp 向けにコミュニティ配布されている量子化済みモデルをそのまま資産として持ち込める意味で実用上大きなポイントです。

対応モデルとハードウェア要件

技術的な魅力を確認したうえで気になるのは「自分の環境で本当に使えるか」だと思います。公式 README ベースで対応モデルとハードウェア要件を整理します。

対応する主要 LLM 一覧

公式 README の対応モデル一覧から、意思決定でよく候補になる主要ファミリーを抜粋します。

（出典: kvcache-ai/ktransformers README）

最新の MoE モデル、とくに中国語圏で先行するモデル群のフォローが早い点が特徴です。「今動かしたい最新モデル」が対応対象に入っているかは、必ず公式 README の最新情報で確認してください。

推奨されるハードウェア構成（CPU / GPU / RAM）

サブモジュール kt-kernel の README に記載されている基本要件は次のとおりです。

• OS: Linux x86-64（Windows Native は WSL 経由や一部対応にとどまる）
• Python: 3.10 〜 3.12
• ビルド依存: cmake / libhwloc-dev / pkg-config
• GPU: CUDA Compute Capability 8.0 以上（Ampere 世代以降）
• CPU 最適化ターゲット: AVX2（2013 年以降）／ AVX512 + BF16（2020 年以降）／ AMX（Intel Sapphire Rapids 以降）／ AMD BLIS
• バックエンド: CUDA を中心に、Intel Arc、AMD ROCm、Ascend NPU にも対応

DeepSeek-R1 671B を GGUF 量子化で動かす場合、最低で 16GB+ VRAM の CUDA GPU と 64GB RAM、推奨は 256〜768GB の高帯域 RAM とされています（出典: kt-kernel README）。GPU を絞る代わりに、RAM 容量と帯域が最終的な性能に強く効くアーキテクチャである点は押さえておきたいポイントです。

実測ベンチマーク（推論スループット）

公表されている代表的な推論ベンチマーク数値を集約すると以下のとおりです（数値・条件はすべて公式 README または関連記事の記載に基づく）。SFT（学習）側の数値は次章の「ファインチューニング（SFT）機能」で扱います。

「単一 4090 で 671B が動く」というインパクトのある数値は事実ですが、そのためには 500GB クラスの RAM が事実上前提であり、単純に「GPU 1 枚あれば十分」ではない点は誤解しないほうがよいでしょう。

基本的な使い方（kt-kernelでの推論）

ここでは公式 README とサブモジュール kt-kernel の README に記載されているインストール手順と API を、公式コードの引用として整理します。実行手順の詳細・トラブルシュートは必ず公式ドキュメントを参照してください。

インストール（pip / ソースビルド）

pip で公開されている kt-kernel パッケージを直接インストールする方法と、GitHub リポジトリからソースビルドする方法があります。

# pip 推奨
pip install kt-kernel

# ソースビルド
git submodule update --init --recursive
conda create -n kt-kernel python=3.11
./install.sh

（出典: kt-kernel README）

AMX や CUDA 向けの最適化を有効にするには追加ビルドオプションが必要になる場合があるため、対象 GPU 世代・CPU 世代を確認したうえで公式手順に従ってください。

CLI での実行

kt-kernel は簡易な CLI を提供しています。代表的なサブコマンドは次のとおりです。

• kt run <model>: 指定モデルで推論サーバを起動
• kt chat: 対話モードでのチャット
• kt doctor: 環境診断（依存ライブラリや GPU/CPU の状態確認）

（出典: kt-kernel README）

軽く検証したい段階では、まず kt doctor で環境要件を満たしているかを確認し、そのうえで kt run で対象モデルを起動する流れが素直です。

Python API での組み込み

自作アプリケーションから MoE 推論を組み込みたい場合は、KTMoEWrapper を経由するのが基本です。README には次のような例が示されています。

from kt_kernel import KTMoEWrapper
wrapper = KTMoEWrapper(
    layer_idx=0, num_experts=8,
    method="AMXINT8",
    weight_path="/path/to/weights"
)
output = wrapper.forward(hidden_states, topk_ids, topk_weights, cuda_stream)

（出典: kt-kernel README）

method に "AMXINT8" のような量子化タイプを渡し、weight_path で対象エキスパートの重みを指定します。CUDA ストリームを受け取っているとおり、GPU 側の計算とパイプライン化する前提の API 設計になっている点が特徴です。

ファインチューニング（SFT）機能

KTransformers は推論エンジンとしての側面が語られがちですが、公式 README には教師あり微調整（SFT）の系統も明示されています。

• LLaMA-Factory との統合により、KTransformers のカーネルを SFT パイプラインから利用可能
• CPU/GPU 混合 SFT、および INT8 / INT4 量子化下での SFT に対応
• 超大規模 MoE 対応として、DPO 学習や Native 精度（BF16 / FP8）での学習にも言及
• 公式ドキュメント上、条件によっては ZeRO-Offload 比で 6〜12 倍高速と記載

（出典: kvcache-ai/ktransformers README / 公式ドキュメントサイト）

SFT の代表的な学習速度ベンチマークは公式 README に以下のように記載されています。これらは推論スループットではなく SFT 学習のイテレーション速度である点に注意してください。

推論から始めて後々ファインチューニングも同じ基盤で行いたいチームにとっては、選定時の加点材料になりうるでしょう。ただし SFT 側の成熟度は推論側ほど広く事例が共有されていない印象があり、本番導入前には公式ドキュメントのモデル別ガイドで対応状況を確認することをおすすめします。

類似OSSとの比較｜llama.cpp・ik_llama.cpp・vLLM・SGLang

多くのエンジニアがもっとも知りたいのは、「結局 llama.cpp や vLLM とどう違い、どう使い分けるべきか」だと思います。ここでは主要な類似 OSS との差分を整理します。

llama.cpp / ik_llama.cpp との違い

• ggml-org/llama.cpp は、ローカル LLM 推論のデファクトスタンダードと言える C++ 実装です。GGUF フォーマットを中心に、Windows / macOS Metal を含む広範なプラットフォームで動作します
• 派生プロジェクトの ikawrakow/ik_llama.cpp は、SOTA の IQ 系量子化などを追加しています
• llama.cpp も MoE のエキスパートオフロードは -ot / tensor override を通じて実装済みで、CPU 側にエキスパートを配置する運用は可能です（出典: Hugging Face Blog「Performant local mixture-of-experts CPU inference with GPU acceleration in llama.cpp」）

KTransformers との違いを整理すると、次のようになります。

• MoE 特化度合い: KTransformers は AMX / NUMA / 非同期スケジューリングまで含めて MoE 前提で作られており、体系的な最適化度合いが高い（llama.cpp Discussion #8721「Loads of interesting ideas in the 'ktransformers' report for mixed CPU/GPU inference」 でも「大規模 MoE 向けの興味深いアプローチ」として議論されています）
• 小〜中規模モデル: 小さめのモデルや短プロンプト用途では、operator fusion が効いた llama.cpp が有利なケースもある
• プラットフォーム範囲: llama.cpp はマルチプラットフォーム（Windows / macOS Metal / モバイル含む）に強く、KTransformers は Linux x86-64 中心
• コミュニティ規模: llama.cpp のコミュニティは圧倒的に大きく、モデル配布・チュートリアル・トラブルシュート情報が豊富

同じ「MoE を CPU/GPU に分ける」でも、llama.cpp は汎用推論エンジンに MoE オフロードを載せた形、KTransformers は最初から巨大 MoE 特化の異種計算エンジンとして設計された形、と理解しておくと選定時に迷いにくくなります。

vLLM との違い

• vllm-project/vllm は、PagedAttention・Continuous Batching・Tensor Parallelism を武器にした本番運用向けの高スループット推論サーバです
• OpenAI 互換 API を持ち、Kubernetes 上での運用事例も豊富です

KTransformers との違いは次のとおりです。

• 設計の前提: vLLM は「モデル重み全体を GPU VRAM に載せる」ことを前提にした NVIDIA GPU 中心の設計。DeepSeek-R1 671B のような巨大 MoE を高スループットで動かすには 8×H100 / H200 クラスが現実的
• KTransformers のスイートスポット: 「単一 24GB GPU + 大容量 RAM」で 671B クラスを動かすことに特化。GPU 予算を極限まで抑える構成向け
• 並列度: vLLM は複数ユーザ並列（バッチ）で圧倒的な総スループットを出せる一方、KTransformers は主にシングルユーザ・低予算構成が想定
• 対応モデルの幅: 一般的な dense モデル・小中規模モデルの幅は vLLM が広く、KTransformers は MoE 最新モデルへの追従が速い

（比較の一次情報として Red Hat Developer「llama.cpp vs. vLLM: Choosing the right local LLM inference engine」 や Lushbinary「Self-Host Kimi K2.6: vLLM, SGLang & KTransformers Guide」 が参考になります）

SGLang との関係（統合が進行中）

• sgl-project/sglang は、構造化生成やマルチターン向けの高性能推論エンジンです
• SGLang 側では KTransformers のカーネルを取り込む議論が Issue #11425 で進んでおり、両者は敵対関係ではなく棲み分けの方向にあります

「本番運用のマルチユーザ処理は SGLang / vLLM、単一ノードでの大規模 MoE 実行は KTransformers」というレイヤ分けを念頭に置くと、アーキテクチャ設計時の判断がしやすくなるでしょう。

選定マトリクス（ユースケース × 推奨エンジン）

ここまでの整理を、意思決定用のマトリクスとしてまとめます。あくまで公式情報・公表事例からの一次判断であり、実際の選定はワークロードでの検証と併せて行ってください。

KTransformers導入判断のポイント

以上を踏まえ、初見のエンジニアが「採用するか / 見送るか」を判断するためのポイントを整理します。

KTransformers が向く用途

• 単一ノード + 少数 GPU で巨大 MoE を動かしたい: DeepSeek-R1 671B、Kimi K2 系、GLM-5 系などを社内サーバや個人 GPU 環境で検証したい場合
• API コストを抑えたい / データを外に出せない: オンプレ・プライベート環境で最新 MoE モデルを回したいケース
• CPU 側リソースに余裕がある構成: 高帯域 DDR5 RAM を大量に積んだ Linux サーバや、AMX 対応の Xeon Sapphire Rapids 以降を保有している場合は、真価を発揮しやすい
• 推論だけでなく SFT も同じ基盤で行いたい: LLaMA-Factory 統合 SFT を将来使う可能性がある場合

KTransformers が向かない用途

• マルチユーザの本番運用でスループット最優先: 大規模バッチ処理は vLLM / SGLang のほうが素直
• Mac / Windows Native / モバイル環境が主戦場: 現状は Linux x86-64 中心のため、llama.cpp のほうが適合しやすい
• 小〜中規模の dense モデルが中心: MoE 特化最適化のメリットが得にくく、既存の汎用エンジンで十分な場合が多い
• CPU 側 RAM を潤沢に用意できない: 巨大 MoE の CPU オフロード運用は、事実上「大容量高帯域 RAM を積めるかどうか」が制約になる

メンテナンス状況とロードマップ

先ほどの基本情報のとおり、KTransformers は スター数 19,173 / フォーク数 1,506 と、OSS としては十分に注目を集めています。archived=false かつ fork=false の本家リポジトリで、pushed_at も 2026-08-04 と直近の日付になっており、開発は健全に継続していると判断できます。

DeepSeek-V4-Flash / GLM-5.2 / MiniMax-M3 といった新しいモデルへの追従も速く、モデル追加や機能拡張の議論はリポジトリの Issue・Discussion で追いかけられます。導入を検討する際は、まず 公式ドキュメントサイト のモデル別チュートリアルで自分が動かしたいモデルの手順を確認し、続いて kt-kernel README でハードウェア要件と API の詳細を押さえるのが効率的な入り口になるでしょう。

まとめ

本記事では KTransformers について、次のポイントを整理しました。

1. CPU-GPU 異種計算による MoE 特化フレームワーク: 清華大学 MADSys Lab を中心に開発され、SOSP'25 に採録されたアーキテクチャに基づく
2. 単一 GPU + 大容量 RAM で巨大 MoE を実行可能: ホット/コールドエキスパート分割、AMX / NUMA 最適化、3 層 KV キャッシュなどが組み合わさる
3. 数値上のインパクト: SOSP'25 論文で prefill 4.62〜19.74×、decode 1.25〜4.09×、DeepSeek-R1-0528（FP8）で 227.85 tokens/s といった値が公表されている
4. llama.cpp / vLLM とは棲み分け: 「単一ノード + 少数 GPU で巨大 MoE」は KTransformers、「マルチユーザ本番推論」は vLLM / SGLang、「幅広い環境の汎用推論」は llama.cpp
5. 健全な開発ステータス: スター 19,173、直近のプッシュあり、Apache-2.0 ライセンスで商用利用可

初見のエンジニアが「採用すべきか」を判断する材料としては、自チームのワークロードが本当に「単一ノードで巨大 MoE を動かす」ユースケースなのかを最初に確認することが、もっとも実務的な入り口だと言えます。

関連情報

自社データを外に出さずに LLM を活用したい、あるいは AI 推論基盤の設計・受託開発をご検討中の方は、お問い合わせフォーム からご相談ください。要件整理の段階からご相談いただけます。

参考リンク

• kvcache-ai/ktransformers（GitHub リポジトリ）
• kt-kernel README（推論エンジン仕様・API）
• KTransformers 公式ドキュメントサイト
• KTransformers 公式プロダクトサイト
• SOSP'25 論文「KTransformers: Unleashing the Full Potential of CPU/GPU Hybrid Inference for MoE Models」（清華大学 MADSys Lab）
• TechNode「Tsinghua University's KTransformers enables full-powered DeepSeek-R1 with low-cost graphics card」
• llama.cpp Discussion #8721
• Red Hat Developer「llama.cpp vs. vLLM: Choosing the right local LLM inference engine」
• Lushbinary「Self-Host Kimi K2.6: vLLM, SGLang & KTransformers Guide」