ガイド

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

Kimi K3をセルフホストするには何が必要？

Kimi K3は2.8兆パラメータです。MXFP4の重み容量、VRAMとKV cacheの計算、32 GPUクラスターなしで動かす現実的な3つの方法を解説します。

Kimi K3 のセルフホストに必要なもの

Kimi K3 をセルフホストするには、2.8 trillion 個のパラメータを収容する必要があります。Moonshot は重みを MXFP4 で公開しました。これは重み 1 個あたり約半 byte です。そのため、キャッシュ用に 1 token 分も割り当てる前に、重みだけでおよそ 1.4 TB になります。現在販売されているアクセラレーターで、これを単体で保持できるものはありません。K3 はマルチノードモデルです。1 台のサーバーだけで運用することはできません。

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

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

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

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

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

総パラメータ数はメモリコストを決めます。 router はどのトークンでも任意の expert を選択する可能性があるため、最初のリクエストを受ける前にすべての expert をメモリ上に常駐させる必要があります。VRAM に 104B だけを保持し、残りを必要に応じて取得することはできません。取得処理はマイクロ秒単位で完了する必要がありますが、PCIe リンクの転送速度は毎秒数十ギガバイト程度だからです。実際に試す人もいます。しかし、NVMe から expert をストリーミングすると、本来は毎秒数十トークンを生成できるモデルが、数秒に 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 個のエキスパートを常に均等に分割できる並列構成も前提としていますが、実際にはそうできない場合があります。

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

KV キャッシュは意外に大きな負担になります

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

具体例を示します。ただし、あくまで一例です。64 layers、8 KV heads、head dimension 128、fp8 の場合、2 64 8 128 1 = 131,072 bytes です。つまり、1 token あたり 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 が必要です。最大の 1 million token では、ユーザー 1 人に 128 GiB が必要です。これは 1 枚のカードに収まる容量を超えるため、1 つの会話だけでも問題になります。

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

この考え方は、次の release でも変わりません。モデルが 1 million token のコンテキストを掲げ、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 年を通じて、データセンター向けアクセラレーターのオンデマンド料金は、1 GPU 時間あたりおよそ 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

正常なサーバーは、モデル 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 分消費します。インスタンスより長く存続するボリュームに重みをステージングしてください。2 回目の実行は数分で開始できます。

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

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

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

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

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 プレフィックスがないことを示します。通常、モデルが見つからないエラーは id が変更されたことを意味します。プロバイダーはチェックポイント間で id を廃止することがあるためです。

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

この Tier でセルフホストするのは、モデルの周辺機能全体です。具体的には、API key を保持してクライアントに渡さないゲートウェイ、リクエストとレスポンスのログ、リトライ、レート制限、ユーザー単位の予算管理です。これらは GPU をまったく必要としない小規模な VPS 上で実行できます。クローズドウェイトにも同じ分離を適用できます。この場合、モデルレベルでの Claude のセルフホストは不可能であり、自分で管理できるのはオーケストレーションだけです。

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

vLLM と SGLang 系のサーバーはティア 1 に該当します。これらは、連続バッチ処理とページ化 KV キャッシュにより、多数のリクエストを同時に処理するために使われます。複数のノードにまたがるテンソル並列処理とエキスパート並列処理にも対応します。データセンター向けアクセラレーターと、それらを接続する高速インターコネクトを前提としています。一般的なコンシューマー向けカード 1 枚では、インストールが重くなり、体感できる利点もほとんどありません。

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

このチェックポイントを超えて残る4つの数値

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

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

FAQ

単一の GPU で Kimi K3 を実行できますか？

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

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

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

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

実用上は収まりません。公開された checkpoint は、すでに quantisation-aware training を適用した 4-bit です。そのため、容易に得られる削減効果はすでに反映されています。さらに 2-bit まで半減させても、重みは 0.7 TB になります。これは最大のカードの容量の 2 倍を超えています。また、このモデルで 2-bit 化による精度への影響は測定されていません。

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

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

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

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

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