著者 Kimi K3のセルフホストに必要なVRAMと構成
Kimi K3は2.8Tパラメーターです。MXFP4の重みだけで約1.4 TB、KVキャッシュまで含めたVRAM計算と、32 GPUクラスターなしで動かす現実的な3つの方法を解説します。
Kimi K3 のセルフホストに必要なもの
Kimi K3 をセルフホストするには、2.8 兆パラメーターを収容できる環境が必要です。Moonshot はオープンウェイトを MXFP4 で公開しました。これは 1 ウェイトあたり約 0.5 バイトに相当するため、キャッシュ用に 1 トークン分も割り当てる前の段階で、ウェイトだけでおよそ 1.4 TB になります。現在販売されているアクセラレーターで、単体でこれを収容できるものはありません。GPU 1 基では不可能です。サーバー 1 台なら、2 つの構成で可能です。1 つ目は、アクセラレーター 1 基あたり 288 GB のメモリを備えた 8-GPU node です。これは、公開されているマルチユーザー向けサービング手順で使用されている最小構成です。2 つ目は、合計約 1.6 TB の RAM と VRAM を備えた 1 台のマシンで、GPU の有無にかかわらず、Unsloth のロスレス Q8 GGUF を llama.cpp で実行し、一度に 1 ユーザーへ提供する構成です。
これが結論です。以下では、その根拠となる計算を示します。計算方法は、次のリリースでも再利用できる部分です。16 July 2026 の発表から数週間のうちに、複数のインフラストラクチャベンダーが K3 のデプロイガイドを公開しました。しかし、どのガイドも、すでにクラスターを所有していることを前提にしていました。このページでは逆の観点から説明します。必要なコスト、代わりに実行できる構成、そして自分がその 2 つのどちらに該当するかを判断する方法を扱います。
総パラメータ数とアクティブパラメータ数は同じではありません
K3 は Mixture of Experts モデルです。MoE（Mixture of Experts）はネットワークを多数のサブネットワークに分割し、ルーターがトークンごとにその一部を選択します。モデルカードには、総パラメータ数として 2.8T、トークンごとのアクティブパラメータ数として 104B と記載されています。これは、93 層にわたる 896 個のルーティング対象エキスパートのうち、各トークンで 16 個が実行される構成です。
この 2 つのパラメータ数は異なる問いに答えるものです。これらを取り違えることが、「このモデルを実行できるか」という議論で最もよくある間違いです。
アクティブパラメータ数が計算コストを決めます。 1 トークンは約 104B 個のパラメータを通過するため、期待できるスループットは 2.8T の密モデルではなく、104B の密モデルに近くなります。MoE を構築する理由は、まさにこの点にあります。
総パラメータ数がメモリコストを決めます。 ルーターはどのトークンでも任意のエキスパートを選択する可能性があるため、最初のリクエストを受ける前に、すべてのエキスパートを高速にアクセスできる場所へ保存しておく必要があります。使用頻度の高いエキスパートだけを VRAM に保持し、残りを必要に応じて取得する構成も可能です。llama.cpp の --moe-cache-mib は、システム RAM に置かれたエキスパート用の GPU キャッシュを保持し、ルーターが選択した際に不足しているエキスパートをアップロードします。ただし、総量が小さくなるわけではありません。残りのエキスパートも RAM 上に置く必要があります。また、PCIe リンクの転送速度は毎秒数十 GB であり、毎秒数 TB の HBM より遅いため、キャッシュミスのたびに時間がかかります。モデルが RAM に収まらず、NVMe からエキスパートをストリーミングする場合はさらに遅くなります。Unsloth の K3 ガイドでも、ディスクへのオフロードは大幅に遅くなると説明されています。
つまり、計算コストは低い一方で、保存コストは高くなります。ハードウェアは 2.8T を基準に選定してください。速度の期待値は 104B を基準にしてください。
重みあたりのバイト数と、テラバイトの内訳
パラメータ数に、重みあたりのバイト数を掛けます。重みについては、計算式はこれだけです。
このグラフのデータ
[
{
"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 パーセント増えます。また、Moonshot の設定では、アテンション、共有エキスパート、ビジョンタワーが 4-bit 形式の対象外です。そのため、チェックポイント全体は単純な 1.4 TB ではなく、Unsloth の計算で約 1.56 TB になります。
これにより、よくある回避策の余地は狭まりますが、なくなるわけではありません。リリース済みのチェックポイントはすでに 4-bit なので、容易に削減できる部分は対応済みです。それでも、さらに低ビット化すれば容量は減ります。2026 年 10 月 27 日時点で、Unsloth が測定した K3 の動的 GGUF 量子化は、2-bit の UD-Q2_K_XL の 861.3 GB から、1-bit の UD-IQ1_S の 594 GB まであります。Unsloth は、その代償も公開しています。フルモデルに対する top-1 トークン一致率は、UD-Q2_K_XL で 90.390 パーセント、711.1 GB の UD-IQ2_XXS で 84.127 パーセント、UD-IQ1_S で 78.875 パーセントです。Hugging Face のリポジトリには、さらに小さい 1-bit ファイルもあり、UD-Q1_0 では 466 GB まで下がります。ただし、これらには一致率が併記されていません。これは測定された精度低下です。最小のファイルでも、単体の最大容量カードの約 1.6 倍あります。
Kimi K3 には GPU が何台必要か
このグラフのデータ
[
{
"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 件目の同時リクエスト用の余裕は含まれていません。分割数は均等である必要もありません。vLLM の pipeline parallelism はモデルをレイヤー単位で分割し、不均等な分割にも対応しています。また、SGLang の K3 prefill レシピでは、93 レイヤーに対して 8 段階および 16 段階の pipeline を実行します。
公開されている推奨構成は、この最低ラインを上回ります。Moonshot のローンチ時のガイダンスでは、64 基以上の accelerator を搭載した supernode が推奨されていました。2026 年 10 月 27 日時点で、SGLang の cookbook には、8-GPU ノード 4 台で構成した H100 構成が掲載されています。GPU は 32 基、合計メモリは 2,560 GB で、最低ラインは 18 枚です。また、8-GPU の B300 ノード 1 台、および 8-GPU の MI350X または MI355X ノード 1 台を使う単一ノード構成も掲載されています。後者は、1 枚あたり 288 GB、合計 2,304 GB です。最低ラインを上回る分は無駄ではありません。KV cache、activation memory、そしてサーバーが多数のリクエストを同時にバッチ処理するための余裕に使われます。最も導入しやすい 5 GB300 クラスのカード構成も、実運用では同じ種類の 8-GPU ノードに切り上げられます。これは、複数ユーザー向けの K3 serving recipe が公開されている最小規模のマシンです。
KV cache が多くの人を驚かせる理由
Weights は固定コストです。一方、KV（key value）cache は固定ではありません。context length に応じて増加し、同時接続するユーザー数に応じても増加します。通常の attention の式は bytes per token = 2 * layers * kv_heads * head_dim * bytes_per_element です。これに context length と同時実行数を掛けます。
計算例を示します。あくまで一例です。64 layers、8 KV heads、head dimension 128、fp8 とします。計算結果は 2 64 8 128 1 = 131,072 bytes となるため、1 token あたり 128 KiB です。
このグラフのデータ
[
{
"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
}
]context 128k のユーザー 1 人には 16 GiB 必要です。最大の 1 million token では、ユーザー 1 人に 128 GiB 必要になります。これは 1 つの会話だけで 288 GB のカードのほぼ半分を消費します。Weights を 1 つも読み込んでいない段階での計算です。
K3 は通常の attention を使用しません。先ほどの数値がその理由です。93 layers の内訳は、69 の KDA（Kimi Delta Attention）layers と 24 の Gated MLA（multi-head latent attention）layers です。KDA は token ごとに増加する cache の代わりに、サイズが固定された recurrent state を保持します。MLA は key と value を 1 つの low rank latent vector に圧縮するため、実際の 1 token あたりのコストは先ほどの計算例を大きく下回ります。Moonshot が公開している config.json では、この latent のサイズは kv_lora_rank 512 に、幅 64 の rotary key（qk_rope_head_dim）を加えたものです。したがって、MLA layer 1 層あたり 1 token につき 576 values です。24 layers、1 value あたり 2 bytes で計算すると 27,648 bytes になり、1 token あたり約 27 KiB です。最大の 1,048,576 token の会話では、固定サイズの KDA state を除いて、およそ 27 GiB になります。ただし、これは測定値ではなく推定値として扱ってください。engine によって cache の padding と配置方法が異なり、8-bit cache ではおよそ半分になります。
独自の deployment が保持する内容を確認するには、--max-model-len を増やしている間、nvidia-smi を監視しないでください。vLLM は、--gpu-memory-utilization（現在の docs ではデフォルト 0.92）または明示的な GPU ごとの cache budget に基づいてサイズを決め、KV cache pool を事前確保します。そのため、GPU memory の合計値には 1 つの会話ではなく pool が表示されます。代わりに startup log を確認してください。vLLM はそこに、KV cache の token 数と、指定した context length における最大 concurrency を出力します。
この考え方は次の release でも変わりません。モデルが 1 million token の context を掲げていて、attention の設計について何も説明していない場合は、誰かが別の根拠を示すまで cache がボトルネックになると考えてください。
Tier 1: クラスターを時間単位で借りる
これは、K3 をリリース時の精度で同時に多くのユーザーへ提供する層です。十分な RAM を搭載した 1 台のマシンであれば、Unsloth の Q8 GGUF を使って K3 をリリース時の精度で実行することもできます。Unsloth はこれを完全精度で損失なしと表記しています。ただし、この方法は一度に 1 ユーザーしか処理できず、tier 2 で扱います。ここではハードウェアを購入しません。必要な時間だけ借り、使用後に停止します。
このグラフのデータ
[
{
"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"
}
]料金は見積もりではなく、仮定値です。オンデマンド料金はプロバイダーや GPU 世代によって大きく異なります。単一ノードのレシピで必要になる 288 GB の部品は、H100 よりも 1 時間あたりの料金が高く、予約容量はより安価です。実際の料金をプロバイダーから取得し、GPU 数 × 時間 × 料金で計算し直してください。グラフが示すのは比率です。8 GPU のノードを 1 日 4 時間稼働させると、1 か月あたり 2,400 USD かかります。一方、SGLang 用の 32 GPU H100 構成を常時稼働させると 57,600 USD かかります。
主要なサーバーはいずれも、モデルカードに起動コマンドを掲載しています。
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、パイプライン並列に --pp-size、エキスパート並列に --ep-size を指定します。テンソル並列数とパイプライン並列数の積は、実際に使用する GPU 数と一致する必要があります。エキスパート並列はそのグループ内でエキスパートを分割します。そのため、32 GPU H100 のレシピでは --tp-size 32 と --ep-size 32 の両方を設定しています。
実際のトラフィックを送る前に、サーバーが起動したことを確認してください。
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 の形式の行が表示されることです。ビルドにこれらのレイヤーを実行するコードが含まれていないため、設定を変更しても解決しません。その後状況は変わりました。2026 年 10 月 27 日現在、SGLang は v0.5.17 以降のリリースで K3 をサポートしており、最新は v0.5.22 です。また、vLLM の v0.28.0 から v0.32.0 までのリリースノートには、いずれも K3 に関する変更が含まれています。現在のリリースをインストールしてください。Blackwell 向けの SGLang の NVFP4 ビルドなど、ハードウェア固有の経路では専用イメージが指定されている場合があります。使用するカードのレシピを確認してください。
見落とされやすい料金上の注意点があります。課金メーターは、モデルの準備が完了した時点ではなく、インスタンスの起動時点で開始します。1.56 TB のダウンロードを 1 GB/s で行う場合、最初のトークンを取得する前にクラスター時間を約 26 分消費します。インスタンスより長く存続するボリュームに重みを配置してください。2 回目の実行は数分で開始できます。
Tier 2: 1 台のアクセラレーターで小さいモデルを実行する
この Tier では K3 を実行しません。開始前に、その点を明確にしてください。「K3 をローカルで実行する」方法を議論するスレッドの多くは、これを認めないままここで終わります。
適合条件は、同じ式を小規模に適用します。パラメーター数に重みあたりのバイト数を掛け、KV キャッシュと約 2 GB のランタイムオーバーヘッドを加えた値が、VRAM に収まる必要があります。4-bit では、これはおおよそパラメーター 1 個あたり 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
上記の組み合わせは、いずれも 1 回に 1 つのリクエストを処理する場合を前提としています。2 人目がプロンプトを送信した時点で、同時実行する各スロットに専用の KV キャッシュが必要になります。Ollama の NUM_PARALLEL と MAX_QUEUE の設定は、並列スロット数、キューに入れるリクエスト数、残っている VRAM の間で、このトレードオフを調整します。
単一の大規模マシンで K3 自体を実行する方法も 1 つあります。これはこの Tier と最後の Tier の中間に位置します。Unsloth は llama.cpp で K3 の GGUF ビルドを文書化しています。1-bit と 2-bit の量子化から UD-Q8_K_XL までがあり、UD-Q8_K_XL は完全精度でロスレスと説明されています。また、これらを実行できるハードウェアとして NVIDIA DGX Station を挙げています。目安は、RAM と VRAM の合計を量子化サイズとほぼ同じにすることです。必要量は 1-bit の UD-IQ1_S ビルドで約 610 GB、Q8 では約 1.6 TB です。これを下回るとモデルがディスクへ退避し、速度が大幅に低下します。GPU は必須ではありません。Unsloth のビルド手順には、「GPU がない場合、または CPU 推論を行いたい場合」に CUDA を無効にする手順があります。1-bit と 2-bit のビルドは K3 を大幅に量子化したものであり、前述のとおり精度が低下します。Q8 ビルドはリリース時の精度の K3 を、RAM の速度で 1 ユーザーに提供します。どちらも小さいモデルではありません。
Ollama は、GPU を接続した VPSで動作するサーバーを構築する最短の方法です。
curl -fsSL https://ollama.com/install.sh | sh
ollama run qwen3:14bollama 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 とセルフホスト型オーケストレーション
このグラフのデータ
[
{
"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 互換なので、base 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 が正しく、有効期限切れや無効化になっていないことを確認し、ヘッダーが Authorization: Bearer に続けて key を指定する形式になっているか確認してください。モデルが見つからないというエラーは、通常 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 を保持してクライアントに渡さない gateway、リクエストとレスポンスのログ、リトライ、レート制限、ユーザーごとの予算管理です。これらは GPU なしの小規模な VPS で実行できます。同じ分離はクローズドな重みにも適用できます。モデルレベルで Claude のセルフホスト はできず、自分で管理できるのはオーケストレーションだけだからです。
どの推論サーバーがどのティアに該当するか
vLLM と SGLang クラスのサーバーは、ティア 1 に該当します。これらは、連続バッチ処理とページ化 KV キャッシュを使用して、多数のリクエストを同時に処理するために作られています。さらに、複数のノードにまたがるテンソル並列処理とエキスパート並列処理にも対応します。データセンター向けアクセラレーターと、それらの間の高速インターコネクトを前提としています。コンシューマー向けカード 1 枚で使う場合は、インストールが難しくなり、実際に効果を実感できる機能もほとんどありません。
llama.cpp と Ollama は、ティア 2 に該当します。1 台のマシン、GGUF 量子化、モデルが収まらない場合の CPU オフロード、低い同時実行数を対象としています。llama.cpp は、エキスパートの重みをシステム RAM（--cpu-moe または --n-cpu-moe）に保持することで巨大な MoE を読み込めます。また、--moe-cache-mib を使用すると、利用するエキスパートを GPU にキャッシュできます。Unsloth の K3 GGUF ビルドが 1 台のマシンで動作する仕組みもこれです。速度は RAM の帯域幅と、ルーターがキャッシュを外す頻度に左右されます。ファイルが RAM と VRAM の合計より大きい場合は、ディスクに退避されます。1 人のユーザーが使う構成としては実用的です。しかし、多数のユーザーを載せられるサービスではありません。完全な比較は Ollama と vLLM の比較 にあります。モデルが変わってもこの点は変わりません。共有ハードウェアで多数のユーザーにサービスを提供するのか、自分の環境で 1 人のユーザーが使うのかが、常に判断基準になります。
このチェックポイントを超えても変わらない4つの数値
- 総パラメーター数に重み1つ当たりのバイト数を掛けると、必要メモリの下限が分かります。提供時の精度では、これを下回って動作することはありません。4-bit リリースよりさらに量子化しても、得られる削減効果は最大で約70パーセントです。精度を犠牲にしても、桁違いの削減にはなりません。
- アクティブパラメーター数がスループットのクラスを決めます。アクティブパラメーター数が104Bの2.8T MoEは、104Bモデルと同程度の計算量になります。
- トークン当たりのKVキャッシュにコンテキスト長と同時実行数を掛けた値が、重みのメモリを確保した後も増え続けるコストです。
- 1ドル当たりの1秒間のトークン数だけが、選択すべきティアを決めます。ここまでの数値はすべて、その入力です。
この4つをどのリリースにも適用すれば、ベンダーガイドを開く前に正しい判断ができます。次のリリースはすでに発表されています。Moonshotは、追加のポストトレーニングを施したK3ベースのK3.1 Proを、2026年10月23日にKimi Codeで提供開始しました。API quickstartによると、完全な重みは11月4日までにリリースされます。そのため、記録するすべての数値に日付を付けてください。K3のローンチ後2週間の間に、価格と対応アーキテクチャの一覧はどちらも変更されました。このページのローンチ時の数値は2026年7月に公開されたもので、サービング手順、ランタイムのリリース、量子化の数値は2026年10月27日に再確認しています。
FAQ
1 枚の GPU で Kimi K3 を実行できますか？
いいえ。Moonshot が提供する MXFP4 精度では、重みだけで約 1.4 TB あります。K3 で公開されている最小の量子化でも、Unsloth の 466 GB UD-Q1_0 ファイルは、広く入手できる最大クラスのアクセラレーターに搭載された 288 GB の約 1.6 倍です。llama.cpp はエキスパートをシステム RAM に置き、アクティブなエキスパートを GPU にキャッシュできます。ただし、その場合も量子化後のサイズと同程度の RAM に加えて VRAM が必要です。それを下回ると、モデルはディスクへ退避し、実行速度が大幅に低下します。公開されている最小のサービング構成は、B300 または MI350X/MI355X カードを 8 枚搭載した 1 ノードです。H100 の構成では 32 枚を使用します。
Kimi K3 にはどの程度の VRAM が必要ですか？
重みだけで 1.4 TB を見積もってください。これは 18 枚の H100 80GB カード、または 5 枚の GB300 クラスのカードに相当します。これに KV キャッシュとアクティベーション用メモリが加わります。Moonshot の公開時の指針では、64 枚以上のアクセラレーターが推奨されていました。2026 年 10 月 27 日時点で、SGLang の cookbook には、B300 または MI350X/MI355X を 8 枚使用する単一ノード構成（合計 2,304 GB）と、H100 GPU を 32 枚使用する構成（合計 2,560 GB）が掲載されています。そのため、重みの容量は必要量ではなく、下限として扱ってください。
量子化すれば Kimi K3 は 1 ノードに収まりますか？
出荷時の 4-bit checkpoint は、288 GB のカードを 8 枚搭載したノードであれば収まります。SGLang の B300 および MI355X の構成はこの構成です。また、Unsloth の lossless Q8 GGUF を使えば、VRAM を含めて約 1.6 TB の RAM を搭載した 1 台のマシンでも実行できます。さらに低いビット数にすれば、より小規模なマシンでも実行しやすくなります。Unsloth の測定済み dynamic GGUF ビルドは、2-bit の 861.3 GB から 1-bit の 594 GB まであります。リポジトリには、約 1.56 TB の lossless 版に対して、466 GB まで小さくした 1-bit ファイルも掲載されています。精度への影響も測定されています。フルモデルとの top-1 一致率は、UD-Q2_K_XL で 90.390 percent、UD-IQ1_S で 78.875 percent まで低下します。いずれも 1 枚のカードには収まりません。
Kimi K3 API より GPU を借りるほうが安価ですか？
利用量が多く、安定している場合に限ります。GPU 1 時間あたり 2.50 USD と仮定すると、GPU 8 枚のノードを常時稼働させた場合の費用は 1 か月あたり 14,400 USD です。同じ金額で、公開料金 15.00 USD/100 万出力トークンなら、約 9 億 6,000 万出力トークンを購入できます。さらに、アイドル時間、重みのダウンロード、クラスターを稼働し続ける担当者の費用も発生します。バースト用途では時間単位で借り、推測ではなく自分で測定したトークン量と比較してください。
104B のアクティブパラメーターは速度に何を意味しますか？
1 トークンあたりの演算量が 104B モデル相当になるという意味です。そのため、スループットは 2.8T クラスではなく、104B クラスになります。これはメモリ容量を示すものではありません。ルーターは任意のトークンで任意のエキスパートを呼び出せるため、2.8T 個のパラメーターすべてを常駐させる必要があります。1 秒あたりのトークン数を予測するにはアクティブパラメーター数を使い、VRAM 容量を決めるには総パラメーター数を使ってください。