ガイド

著者 Matt Connor 2026-08-03 ・更新日 2026-08-26

Kimi K3のセルフホストに必要なGPUとVRAM

Kimi K3は2.8兆パラメーター、MXFP4でも重みだけで約{{q:k3_weight_math:weights_tb@2}} TBです。KVキャッシュの計算と、32 GPUクラスターなしで動かす現実的な3つの方法を解説します。

Kimi K3 をセルフホストするために必要なもの

Kimi K3 のセルフホストには、2.8 兆個のパラメーターを格納できる容量が必要です。Moonshot はオープンウェイトを MXFP4 で公開しました。1 ウェイトあたり約 0.5 バイトなので、キャッシュに 1 トークン分も割り当てる前に、ウェイトだけで約 1.4 TB になります。現在販売されているアクセラレーターで、これを単体で保持できるものはありません。K3 はマルチノードモデルです。1 台のサーバーで運用する答えは「不可能」です。

これが結論です。以下では、その根拠となる計算を示します。この計算は、次のリリースでも再利用できます。2026 年 7 月 17 日の発表後数週間で、複数のインフラストラクチャベンダーが K3 のデプロイガイドを公開しました。しかし、どのガイドも、すでにクラスターを所有していることを前提にしていました。このページでは逆の順序で説明します。必要な費用、代わりに実行できるもの、そして自分がそのどちらに該当するかを判断する方法を扱います。

総パラメータ数とアクティブパラメータ数は同じではありません

K3 は Mixture of Experts モデルです。MoE（Mixture of Experts）はネットワークを多数のサブネットワークに分割し、トークンごとにルーターがその一部を選択します。モデルカードには、総パラメータ数が 2.8T、トークンごとのアクティブパラメータ数が 104B と記載されています。これは、93 層にまたがる 896 個のルーティング対象エキスパートのうち、各トークンで 16 個が選択される構成に基づきます。

この 2 つのパラメータ数は異なる問いに答えるものであり、「これを実行できるか」という議論で最もよくある間違いは、この 2 つを取り違えることです。

アクティブパラメータ数が計算コストを決めます。 1 トークンは約 104B 個のパラメータを通過するため、期待できるスループットは 2.8T の密モデルではなく、104B の密モデルに近くなります。MoE を構築する理由はここにあります。

総パラメータ数がメモリコストを決めます。 ルーターはどのトークンでも任意のエキスパートを選択できるため、最初のリクエストを受ける前にすべてのエキスパートをメモリ上に常駐させる必要があります。104B だけを VRAM に保持し、残りを必要に応じて取得することはできません。取得処理をマイクロ秒単位で完了させる必要がある一方、PCIe リンクの転送速度は毎秒数十ギガバイトにすぎないためです。実際に試す人はいます。NVMe からエキスパートをストリーミングすると、本来は毎秒数十トークンを出力できるモデルが、数秒に 1 トークンしか出力できないモデルになります。

つまり、計算コストは低く、格納コストは高いモデルです。ハードウェアは 2.8T を基準に選定してください。速度の期待値は 104B を基準にしてください。

重みあたりのバイト数と、テラバイトになる理由

パラメータ数に、重みあたりのバイト数を掛けます。重みについては、計算式はこれだけです。

ChartWeight footprint of 2.8 trillion parameters, by precision

label

bytes_per_weight

weights_tb

bf16

5.6

fp8

2.8

4-bit (MXFP4, as shipped)

0.5

1.4

2-bit

0.25

0.7

The data behind this chart

[
  {
    "label": "bf16",
    "bytes_per_weight": 2,
    "weights_tb": 5.6
  },
  {
    "label": "fp8",
    "bytes_per_weight": 1,
    "weights_tb": 2.8
  },
  {
    "label": "4-bit (MXFP4, as shipped)",
    "bytes_per_weight": 0.5,
    "weights_tb": 1.4
  },
  {
    "label": "2-bit",
    "bytes_per_weight": 0.25,
    "weights_tb": 0.7
  }
]

K3 は量子化を考慮して学習され、MXFP4 の重みと MXFP8 のアクティベーションでリリースされています。そのため、4-bit の行が実際の構成です。その上の行は比較用です。bf16 では、同じモデルに 5.6 TB の容量が必要になります。MXFP4 では、32 個の重みごとに共有 8-bit スケールも 1 つ保存するため、約 6 パーセントが加わります。そのため、公開されているリポジトリの容量は、単純計算の 1.4 TB よりも 1.5 TB 前後になります。

これで、よくある回避策は使えません。「量子化すればよい」とはならないからです。公開済みのチェックポイントは、すでに 4-bit です。2-bit まで下げれば重みは 0.7 TB になりますが、このチェックポイントでどの程度精度が低下するかは測定されていません。それでも、単一のカードの容量を大幅に超えます。

Kimi K3 には何台の GPU が必要か

ChartGPUs required to hold 1.4 TB of weights, before any KV cache

config

hbm_per_gpu_gb

gpus_for_weights

H100 80GB

H200 141GB

141

B200 192GB

192

GB300 288GB

288

The data behind this chart

[
  {
    "config": "H100 80GB",
    "hbm_per_gpu_gb": 80,
    "gpus_for_weights": 18
  },
  {
    "config": "H200 141GB",
    "hbm_per_gpu_gb": 141,
    "gpus_for_weights": 10
  },
  {
    "config": "B200 192GB",
    "hbm_per_gpu_gb": 192,
    "gpus_for_weights": 8
  },
  {
    "config": "GB300 288GB",
    "hbm_per_gpu_gb": 288,
    "gpus_for_weights": 5
  }
]

これらは目標値ではなく、下限値として捉えてください。重みだけを数えており、KV cache、activation buffer、allocator の断片化、2 件目の同時リクエストを処理する余裕は含まれていません。また、93 層と 896 個の expert を常に均等に分割できることも前提にしていますが、実際にはそうならない場合があります。

公開されている推奨値は、この下限を大きく上回ります。2026 年 8 月時点で、Moonshot は 64 台以上の accelerator で構成する supernode を推奨しています。また、SGLang cookbook には、8 GPU ノードを 4 台使用する H100 構成が掲載されています。この構成は、合計 32 GPU、2,560 GB のメモリで、18 枚のカードという下限に対するものです。この差は無駄ではありません。KV cache、activation memory、そしてサーバーが多数のリクエストを同時にバッチ処理するための余裕に充てられます。最も条件のよい行である 5 GB300 class のカードでさえ、単一の SKU としてレンタルできるプロバイダーがほとんどない構成を示しています。

KV キャッシュが意外な負担になる理由

重みのメモリ使用量は固定です。一方、KV（key-value）キャッシュは固定ではありません。コンテキスト長に応じて増加し、同時接続ユーザー数が増えるたびにも増加します。通常の attention では、計算式は bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element です。さらに、これにコンテキスト長と同時実行数を掛けます。

具体例を示します。ただし、これはあくまで例です。レイヤー数 64、KV ヘッド数 8、ヘッド次元 128、fp8 とします。計算結果は 2 64 8 128 1 = 131,072 bytes なので、1 トークンあたり 128 KiB です。

ChartKV cache per user in the worked example, at 128 KiB per token

label

kv_gib_per_user

8k context

32k context

128k context

1M context

128

The data behind this chart

[
  {
    "label": "8k context",
    "kv_gib_per_user": 1
  },
  {
    "label": "32k context",
    "kv_gib_per_user": 4
  },
  {
    "label": "128k context",
    "kv_gib_per_user": 16
  },
  {
    "label": "1M context",
    "kv_gib_per_user": 128
  }
]

コンテキスト長 128k で 1 ユーザーが使用する容量は 16 GiB です。最大の 100 万トークンを使用すると、1 ユーザーだけでも 128 GiB になります。これは、1 枚のカードに搭載できる容量を超えています。

K3 は通常の attention を使用していません。最後の数値が、その理由です。K3 の 93 レイヤーは、KDA（Kimi Delta Attention）レイヤー 69 個と、Gated MLA（multi-head latent attention）レイヤー 24 個で構成されています。KDA は、トークンごとに増加するキャッシュではなく、サイズが固定された再帰状態を保持します。MLA は key と value を 1 つの低ランク latent vector に圧縮します。そのため、実際の 1 トークンあたりのコストは、先ほどの例を大きく下回ります。Moonshot は latent の次元数を公開していないため、K3 自体のユーザーあたりの容量は示しません。代わりに、自分の環境で測定してください。小さい --max-model-len を指定してサーバーを起動し、nvidia-smi でメモリを監視します。その後、割り当てに失敗するまで上限を引き上げます。

この考え方は、次のリリースでも変わりません。モデルが 100 万トークンのコンテキストを宣伝しているのに、attention の設計について何も説明していない場合は、別の根拠が示されるまで、キャッシュが制約要因だと考えてください。

Tier 1: クラスターを時間単位で借りる

K3 自体を実行するのは、この Tier だけです。ハードウェアを購入する必要はありません。必要な時間だけ借り、使用後に停止します。

ChartMonthly cost at an assumed 2.50 USD per GPU hour, 30 day month

label

gpu_hours

usd_cost

1 GPU, always on

720

1,800

8 GPUs, 4 hours a day

960

2,400

8 GPUs, always on

5760

14,400

32 GPUs, always on

23040

57,600

The data behind this chart

[
  {
    "label": "1 GPU, always on",
    "gpu_hours": 720,
    "usd_cost": "1,800"
  },
  {
    "label": "8 GPUs, 4 hours a day",
    "gpu_hours": 960,
    "usd_cost": "2,400"
  },
  {
    "label": "8 GPUs, always on",
    "gpu_hours": 5760,
    "usd_cost": "14,400"
  },
  {
    "label": "32 GPUs, always on",
    "gpu_hours": 23040,
    "usd_cost": "57,600"
  }
]

料金は見積もりではなく、仮定の値です。2026 年を通じて、データセンター向けアクセラレーターのオンデマンド料金は GPU 1 時間あたりおよそ 2 ～ 5 USD で推移し、予約容量はそれより安価でした。実際のプロバイダーの料金を使い、GPU 数 × 時間 × 料金で計算し直してください。このグラフの目的は比率を示すことです。8 GPU のノードを 1 日 4 時間だけバースト利用すると、月額 2,400 USD です。一方、SGLang 用にサイズ設定した 32 GPU 構成を稼働させ続けると、57,600 USD かかります。

主要な 2 つのサーバーは、どちらもモデルカードに起動コマンドを掲載しています。

pip install vllm
vllm serve "moonshotai/Kimi-K3"

pip install sglang
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3" --host 0.0.0.0 --port 30000

ただし、どちらのコマンドも実際のクラスターでそのまま実行するものではありません。ハードウェアに合わせた並列化フラグを追加してください。SGLang ではテンソル並列に --tp-size、エキスパート並列に --ep-size を使用します。これらの積は、実際に使用する GPU 数と一致する必要があります。

実際のトラフィックを送る前に、サーバーが起動したことを確認してください。

curl http://127.0.0.1:30000/v1/models

正常なサーバーは、model id を列挙した JSON オブジェクトを返します。Connection refused の場合、プロセスがまだ重みを読み込んでいるか、すでに終了しています。再試行する前にサーバーログを確認してください。

初日に起きやすい障害は、モデルに対してランタイムが古いことです。K3 は KDA と新しい MoE レイヤーを搭載してリリースされましたが、安定版の vLLM と SGLang にはリリース時点でその実装が含まれていませんでした。症状として、起動中にサーバーが Model architectures [...] are not supported for now の形式の行を出力して終了します。ビルドにそのレイヤーを実行するコードがないため、設定を変更しても解決しません。モデルカードに記載された nightly 版をインストールするか、その実装を含むリリースを待ってください。

コストについて、見落とされやすい点が 1 つあります。課金メーターはモデルの準備が完了した時点ではなく、インスタンスの起動時点で始まります。1.5 TB のダウンロードに 1 GB/s で約 25 分かかるため、最初のトークンを生成する前にクラスター時間を約 25 分消費します。インスタンスより長く存続するボリュームに重みを配置してください。2 回目の実行は数分で開始できます。

Tier 2: 1 台のアクセラレーターで小型モデルを実行する

この Tier では K3 を実行しません。開始する前に、この点を明確にしてください。多くの「K3 をローカルで実行する」スレッドは、これを認めないままここで終わります。

適合条件は、同じ式を小規模に適用します。パラメーター数に重みあたりのバイト数を掛けた値に、KV cache と約 2 GB のランタイムオーバーヘッドを加えた合計が、VRAM に収まる必要があります。4-bit ではパラメーターあたりおよそ 0.5 byte なので、次の組み合わせなら余裕があります。

16 GB のカード: 4-bit の 7B モデル。長いコンテキスト用の余裕もあります
24 GB のカード: 4-bit の 14B モデル
48 GB のカード: 4-bit の 32B モデル
80 GB のカード: 4-bit の 70B モデル、または 8-bit の 30B クラスの MoE

上記の組み合わせは、すべて同時に 1 件のリクエストだけを処理する前提です。2 人目がプロンプトを送った時点で、同時実行スロットごとに専用の KV cache が必要になります。Ollama の NUM_PARALLEL と MAX_QUEUE の設定では、並列スロット数、キューに入るリクエスト数、残っている VRAM の間で、このトレードオフを設定します。

Ollama は、GPU を接続した VPSで動作するサーバーを構築する最短の方法です。

curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14b

ollama runは初回の使用時にモデルをダウンロードし、その後プロンプトを表示します。存在しないタグを指定すると Error: model "..." not found が返るため、記憶で入力せず、ライブラリページからタグをコピーしてください。systemd unit とリモートアクセスを含む完全な手順は、VPS で Ollama を実行するにあります。

llama.cpp を使うと、量子化とオフロードをより細かく制御できます。

git clone https://github.com/ggml-org/llama.cpp
cd llama.cpp
cmake -B build -DGGML_CUDA=ON
cmake --build build --config Release -j

./build/bin/llama-server -m model.gguf -c 8192 -ngl 99 --host 0.0.0.0 --port 8080

-ngl 99は、すべてのレイヤーを GPU に配置するよう指定します。ロードログを確認してください。オフロードされたレイヤー数が表示されます。システム RAM に収まらずあふれたレイヤーは、HBM ではなく RAM の帯域幅で実行されます。そのため、モデルが収まらなくなった時点で生成速度は桁違いに低下します。2 つのツールのトレードオフについては、Ollama と llama.cpp の比較で説明しています。

Tier 3: ホスト型 API、セルフホスト型オーケストレーション

ChartKimi K3 published API pricing, USD per million tokens, checked 17 July 2026

label

usd_per_million_tokens

Input, cache hit

0.30

Input, cache miss

3.00

Output

15.00

The data behind this chart

[
  {
    "label": "Input, cache hit",
    "usd_per_million_tokens": "0.30"
  },
  {
    "label": "Input, cache miss",
    "usd_per_million_tokens": "3.00"
  },
  {
    "label": "Output",
    "usd_per_million_tokens": "15.00"
  }
]

エンドポイントは OpenAI 互換のため、ベース URL を変更するだけで既存のクライアントを使用できます。

curl https://api.moonshot.ai/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $MOONSHOT_API_KEY" \
  -d '{"model": "kimi-k3", "messages": [{"role": "user", "content": "Say hello."}]}'

有効な key を使用すると、choices 配列を含む JSON オブジェクトが返されます。401 は、key が正しくないか、Bearer prefix がないことを示します。通常、model not found エラーは id が変更されたことを示します。プロバイダーはチェックポイント間で id を廃止することがあるためです。

ここで、上記で想定したレンタル料金を使って損益分岐点を計算します。常時稼働する 8 GPU ノードの月額料金は 14,400 USD です。出力トークン 100 万個あたり 15.00 USD なら、同じ金額で API から約 9 億 6000 万個の出力トークンを購入できます。コスト面で有利になるには、月に 10 億個近く、1 日あたり約 3000 万個の出力トークンを生成し、クラスターを常時稼働させる必要があります。GPU はアイドル状態でも稼働中と同じ料金が発生するためです。プロンプトの比重が大きいエージェントワークロードでは、損益分岐点はさらに遠のきます。繰り返されるコンテキストには、キャッシュミス時の 3.00 USD ではなく、キャッシュヒット率に応じて 100 万個あたり 0.30 USD が課金されるためです。

この Tier でセルフホストするのは、モデルの周辺機能すべてです。クライアントに API key が届かないよう保持する gateway、リクエストとレスポンスのログ、retry、rate limit、ユーザーごとの予算管理が該当します。これらは GPU をまったく搭載しない小規模な VPS で実行できます。クローズドな weights にも同じ分担が適用されます。Claude のセルフホスティングはモデルレベルでは不可能であり、所有できるのはオーケストレーションだけだからです。

どのサービングスタックがどの層に該当するか

vLLM と SGLang 系のサーバーは tier 1 に該当します。多数のリクエストを同時に処理するためのもので、continuous batching、paged KV cache、複数ノードにまたがる tensor parallelism と expert parallelism を備えています。データセンター向けアクセラレーターと、それらの間の高速なインターコネクトを前提としています。単一のコンシューマー向けカードでは、インストールが重くなり、体感できる利点もほとんどありません。

llama.cpp と Ollama は tier 2 に該当します。1 台のマシン、GGUF 量子化、モデルが収まらない場合の CPU オフロード、低い同時実行数を対象としています。llama.cpp は、ほとんどのレイヤーをシステム RAM に保持することで、非常に大きな MoE も技術的にはロードできます。ただし、2.8T モデルでは、その構成での処理速度は 1 トークンあたり数秒になります。ファイルを解析できることは確認できますが、ユーザー向けサービスとして運用できる構成ではありません。完全な比較は Ollama と vLLM の比較にあります。モデルが変わっても判断は変わりません。共有ハードウェアで多数のユーザーに提供するのか、自分の環境で 1 人のユーザーが使うのかが、常に判断基準です。

このチェックポイントを超えても変わらない4つの数値

総パラメータ数に重みあたりのバイト数を掛けると、必要メモリの下限になります。これを下回って実行することはできません。リリースがすでに4-bitの場合、量子化の工夫をしてもこの下限はほとんど下がりません。
アクティブパラメータ数がスループットのクラスを決めます。アクティブパラメータ数が104Bの2.8T MoEは、104Bモデルと同程度の計算量になります。
1トークンあたりのKV cacheにコンテキスト長と同時実行数を掛けた値が、重みのメモリを確保した後も増え続けるコストです。
1ドルあたりの1秒間のトークン数だけが、選択すべきティアを決める数値です。上記のすべては、その計算に使う入力です。

この4つをどのリリースにも適用すれば、ベンダーガイドを開く前に正しい答えを得られます。そのうえで、記録するすべての数値に日付を付けてください。K3の公開後2週間の間に、価格と対応アーキテクチャ一覧の両方が変わりました。このページにあるすべての数値は、2026年7月に公開されたものです。

FAQ

1 台の GPU で Kimi K3 を実行できますか？

いいえ。Moonshot が出荷する MXFP4 精度では、重みの容量が約 1.4 TB あり、市販されている最大の単一アクセラレーターでも 288 GB しか搭載できません。MoE モデルでは、非アクティブなエキスパートをディスクから実用的な速度でストリーミングできません。ルーターは任意のトークンで任意のエキスパートを選択する可能性があり、PCIe からの読み出しにはトークンの処理時間よりはるかに長い時間がかかるためです。K3 を現実的にデプロイする最小構成は複数 GPU のノードであり、公開されている構成例では 32 個以上のアクセラレーターを使用します。

Kimi K3 にはどの程度の VRAM が必要ですか？

まず、重みだけで 1.4 TB 必要です。これは 18 枚の H100 80GB カード、または 5 枚の GB300 クラスのカードに相当します。さらに KV cache とアクティベーション用メモリが必要です。2026 年 8 月時点で Moonshot は 64 個以上のアクセラレーターを推奨しています。また、SGLang の cookbook には、合計 2,560 GB の 32 GPU H100 構成が掲載されています。そのため、重みの容量は必要量ではなく、下限として扱ってください。

量子化すれば Kimi K3 を 1 台のノードに収められますか？

実用上は収まりません。公開された checkpoint はすでに量子化認識学習済みの 4-bit なので、容易に得られる削減余地は使い切られています。さらに 2-bit まで半減しても、重みは 0.7 TB になります。これは最大のカードの容量の 2 倍を超えています。また、2-bit による精度低下はこのモデルで測定されていません。

GPU をレンタルするほうが Kimi K3 API より安価ですか？

高い利用量が安定して続く場合に限ります。GPU 1 時間あたり 2.50 USD と仮定すると、8 GPU のノードを常時稼働させた場合の月額は 14,400 USD です。同じ金額で、公開料金の 15.00 USD / 100 万出力トークンに基づくと、約 9.6 億個の出力トークンを購入できます。さらに、アイドル時間、重みのダウンロード、クラスターを稼働状態に保つ担当者の費用もかかります。バースト的な利用では時間単位でレンタルし、推測値ではなく実測したトークン量と比較してください。

104B のアクティブパラメーターは速度について何を意味しますか？

トークンあたりの演算量が 104B モデル相当になるため、スループットも 2.8T クラスではなく 104B クラスになります。ただし、メモリ使用量については何も示しません。ルーターは任意のトークンで任意のエキスパートを呼び出せるため、2.8T 個のパラメーターはすべてメモリ上に常駐します。tokens per second の予測にはアクティブパラメーター数を使い、VRAM の容量計算には総パラメーター数を使ってください。

#kimi-k3#self-hosted-llm #gpu #vram #inference