コスト・課金・運用2026年10月24日Flatkey Team

Kimi K3はローカルで動かせる？ハードウェア・GGUF・vLLMガイド（2026年）

Kimi K3はローカルで動かせますが、最小の1-bit GGUFでもRAMとVRAMの合計で約610GBが必要です。正確なハードウェア要件、llama.cppとvLLMのコマンド、ライセンス条件、GPUレンタルやAPIとのコスト比較をまとめました。

Kimi K3はローカルで動かせる？ハードウェア・GGUF・vLLMガイド（2026年）

はい、Moonshot AIがHugging Faceで重みを公開しているので、Kimi K3はローカルで実行できます。ただし2.8兆パラメータのモデルなので、「ローカル」といっても最小の1-bit GGUFでRAMとVRAMの合計約610GB、ネイティブの重みなら8 GPUのBlackwellノード1台が必要です。メモリが少ない単体のワークステーションでもディスクから読み込んで動きますが、非常に遅くなります。ほとんどの開発者にとっては、ハードウェアを購入するより、レンタルGPUでK3を動かすかAPI経由で呼び出すほうが安く済みます。

このガイドでは、2026年10月24日時点で自分のマシンでKimi K3を動かすために必要なことを解説します。ライセンス、量子化ごとの正確なメモリ要件、llama.cppとvLLMの手順付きコマンド、コードからローカルサーバーを呼び出す方法、そしてレンタルGPUやホスト型APIとのコスト比較です。数値はMoonshot AIのモデルカード、vLLMとSGLangの公式レシピ、Unslothのドキュメントに基づきます。独自に見積もった値には「推定」と明記しています。

Kimi K3の概要

項目	値
開発元	Moonshot AI
重み	Hugging Faceのmoonshotai/Kimi-K3
アーキテクチャ	Mixture of Experts：総パラメータ2.8T、トークンあたりのアクティブ104B
エキスパート	ルーティングされるエキスパート896個、トークンごとに16個を選択、共有エキスパート2個
レイヤー	93層（KDA線形アテンション層69層、ゲート付きMLA層24層）
コンテキストウィンドウ	1,048,576トークン
入力	テキストと画像（MoonViT-V2ビジョンエンコーダー、4億100万パラメータ）
ネイティブ精度	MXFP4の重みとMXFP8のアクティベーション（量子化を考慮した学習）
推論	思考は常にオン。`reasoning_effort` はlow、high、max（デフォルトはmax）
ライセンス	Kimi K3 License（修正版MIT）

出典：Kimi K3モデルカード、2026年10月24日確認。

始める前に2つ注意点があります。1つ目に、Moonshot AIは現在API上でKimi K3.1 Proを提供しており、K3を「前世代のフラッグシップ」と呼んでいます。しかし2026年10月24日時点でHugging Face上の最新のオープンウェイトは依然としてKimi K3なので、自分で動かせるのはK3です。2つ目に、K3は思考モードのみで動作します。モデルカードの説明どおり、マルチターンの会話ではクライアントが reasoning_content とツール呼び出しを返す必要があります。

Kimi K3は商用利用できる？

Hugging Face上のライセンスファイル（2026年10月）によると、Kimi K3 LicenseはMITスタイルのライセンスに2つの条件を加えたものです。

直近12か月の売上が2,000万ドルを超えるModel-as-a-ServiceビジネスとしてK3を提供する場合は、Moonshot AIとの個別契約が必要です。
製品の月間アクティブユーザーが1億人を超える、または月間売上が2,000万ドルを超える場合は、ユーザーインターフェースに「Kimi K3」と表示する必要があります。

社内での利用はこれらの条件の制限を受けません。ほとんどのスタートアップやチームにとって、ローカルまたはセルフホストでの利用は認められています。リリース前にライセンス全文を確認してください。

Kimi K3に必要なハードウェアは？

GGUF量子化（llama.cpp）

Unslothは動的GGUF量子化を公開しています。目安は、RAMとVRAMの合計が量子化ファイルのサイズ以上であること。そうでないとモデルがディスクにオフロードされ、大幅に遅くなります。

量子化	必要メモリ（RAM + VRAM）	備考
動的1-bit S（`UD-IQ1_S`）	約610GB	ファイルは594GB。Unslothが推奨するサイズと品質のバランス点で、top-1精度は約79%
動的1-bit M	約665GB
動的2-bit XXS	約726GB
動的2-bit XL	約880GB	Unslothは861GBの動的2-bitで約90%の精度を報告
Q8（`UD-Q8_K_XL`、ロスレス）	約1.6TB	ファイルは1.56TB。ネイティブのMXFP4重みと同等

Unslothによると、1-bit量子化がB200 GPUに収まる場合、生成速度は毎秒約20トークンです。重みの大半をシステムRAMに置くCPU中心のマシンでは、はるかに遅くなると考えてください。私たちは計測していないので、自分のハードウェアで試すまでは、目にする数値はすべて推定として扱ってください。

実際にはどうなる？ 現実的なローカル構成の例：

構成	1-bit（610GB）は収まる？	見込み（推定）
ゲーミングPC：RTX 4090 1枚（24GB）+ RAM 128GB	いいえ	大量のディスクオフロードでしか動かず、非常に遅い。テスト用途のみ
ワークステーションまたはサーバー：GPU 1-2枚 + DDR5 768GB	はい	低速での単一ユーザー実験に使える
80-141GBのGPUを8枚搭載したマルチGPUサーバー	はい、VRAM内に収まる	1人または少人数でインタラクティブな速度
8x B300 / GB300クラスのノード	ネイティブMXFP4重み	vLLMやSGLangによる本番運用

ネイティブ重み（vLLMとSGLang）

公式の重みについては、Kimi K3向けvLLMレシピがGB300 GPUを最低8枚（AMD ROCmではMI355XまたはMI350Xを最低8枚）要求しており、CUDA 13とNVIDIAドライバーr580以降が必要な vllm/vllm-openai:kimi-k3 イメージを使います。SGLangクックブックはB300 1x8、GB300 2x4、B200 2x8、GB200 4x4、H200 2x8、H100 4x8、MI350X/MI355X 1x8といったノード構成を挙げていますが、2026年10月時点で検証済みとされているのはB300 1x8構成だけです。つまりH100でのデプロイには8 GPUノードが4台必要で、「ローカル」で動かそうとするほぼすべての人にとって手の届かない規模です。

サイジングの詳細は、LLMのGPUメモリ要件ガイドとvLLMエキスパート並列デプロイガイドをご覧ください。

llama.cpp（GGUF）でKimi K3をローカル実行する

以下の手順はUnslothのガイドに沿っています。K3の画像入力対応には現在、Unslothがフォークしたllama.cppが必要です。テキストのみの利用でも手順は同じです。

1. llama.cppをビルドする。 NVIDIA GPUがない場合は -DGGML_CUDA=OFF を使います。

git clone https://github.com/unslothai/llama.cpp
cd llama.cpp
git fetch origin pull/48/head:kimi-k3-fullsize-vision
git checkout kimi-k3-fullsize-vision
cd ..
cmake llama.cpp -B llama.cpp/build -DBUILD_SHARED_LIBS=OFF -DGGML_CUDA=ON
cmake --build llama.cpp/build --config Release -j --clean-first \
  --target llama-cli llama-mtmd-cli llama-server llama-gguf-split
cp llama.cpp/build/bin/llama-* llama.cpp

2. 1-bit量子化（約594GB）とビジョンプロジェクターをダウンロードする。 事前にディスクの空き容量を確認してください。

pip install -U huggingface_hub
df -h .   # need roughly 650 GB free
hf download unsloth/Kimi-K3-GGUF \
  --local-dir unsloth/Kimi-K3-GGUF \
  --include "*mmproj-BF16*" \
  --include "*UD-IQ1_S*"

3. ターミナルでチャットする。 Moonshot推奨のサンプリング設定（temperature 1.0、top_p 0.95。エージェント用途ではtop_p 1.0）を使います。

FIRST=$(ls unsloth/Kimi-K3-GGUF/UD-IQ1_S/*00001-of-*.gguf | head -1)
./llama.cpp/llama-cli --model "$FIRST" \
  --mmproj unsloth/Kimi-K3-GGUF/mmproj-BF16.gguf \
  --temp 1.0 --top-p 0.95

4. OpenAI互換APIを提供する。 llama-server は /v1/chat/completions を公開します。コンテキストサイズを小さくするとKVキャッシュ用のメモリを節約できます。

./llama.cpp/llama-server --model "$FIRST" \
  --mmproj unsloth/Kimi-K3-GGUF/mmproj-BF16.gguf \
  --ctx-size 32768 --temp 1.0 --top-p 0.95 \
  --host 127.0.0.1 --port 8080

vLLMでKimi K3を提供する（フルノード）

対応する8 GPUノードを所有またはレンタルしているなら、vLLMで本番レベルのスループット、ツール呼び出し、1Mのフルコンテキストが得られます。公式レシピの基本コマンド：

docker run --gpus all --ipc=host -p 8000:8000 \
  -v ~/.cache/huggingface:/root/.cache/huggingface \
  vllm/vllm-openai:kimi-k3 \
  moonshotai/Kimi-K3 --trust-remote-code \
  --tensor-parallel-size 8 \
  --tool-call-parser kimi_k3 --reasoning-parser kimi_k3 \
  --enable-auto-tool-choice \
  --max-model-len 1048576 \
  --enable-prefix-caching --kv-cache-dtype fp8

レシピには、ツール呼び出しの形式がまれに崩れることも記載されています。ツール引数を検証し、パースに失敗したらリトライしてください。監視とチューニングについては、vLLMデプロイガイドとマルチGPU推論ガイドで解説しています。

ローカルのKimi K3サーバーを呼び出す

llama-server（上記のポート8080）もvLLM（ポート8000）もOpenAI APIに対応しているので、どのOpenAI SDKでも使えます。

curl

curl -s http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"moonshotai/Kimi-K3","temperature":1.0,"top_p":0.95,
       "messages":[{"role":"user","content":"Write a bash one-liner that finds the 5 largest files in a directory."}]}'

Python

from openai import OpenAI

# Local vLLM server; use base_url="http://127.0.0.1:8080/v1" for llama-server
client = OpenAI(base_url="http://127.0.0.1:8000/v1", api_key="local")

r = client.chat.completions.create(
    model="moonshotai/Kimi-K3",
    temperature=1.0, top_p=0.95,
    messages=[{"role": "user", "content": "Explain MoE routing in 3 sentences."}],
)
msg = r.choices[0].message
print(getattr(msg, "reasoning_content", None))  # thinking trace, when the server returns it
print(msg.content)

Node.js

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "http://127.0.0.1:8000/v1", apiKey: "local" });
const r = await client.chat.completions.create({
  model: "moonshotai/Kimi-K3",
  temperature: 1.0,
  top_p: 0.95,
  messages: [{ role: "user", content: "Give me a regex for ISO 8601 dates." }],
});
console.log(r.choices[0].message.content);

マルチターンのチャットでは、モデルカードの要求どおり、次のターンの前に reasoning_content と tool_calls を含むアシスタントメッセージを履歴に追加してください。

ローカル、GPUレンタル、API：Kimi K3のコストは？

GPUをレンタルする場合。 FlatkeyのGPU価格指数（2026年10月24日更新）のリアルタイム料金は、B200が1 GPU時間あたり7.49ドル、B300が7.34ドル、H200が3.60ドル、H100が2.48ドルです。したがって8x B200ノードは1時間あたり約59.92ドル、24時間365日稼働で月額約43,700ドルになります（推定：8 x 7.49ドル x 730時間）。

ホスト型APIの場合。 Moonshotの公式プラットフォームでは、Kimi K3は入力100万トークンあたり3.00ドル、キャッシュ入力0.30ドル、出力100万トークンあたり15.00ドルです。Flatkeyのモデルページでは、Kimi K3は100万トークンあたり入力1.80ドル、キャッシュ入力0.18ドル、出力9.00ドルで、コンテキストは同じく1,048,576トークンです（いずれも2026年10月24日確認）。

損益分岐点（推定）。 入力と出力の比率を3:1とすると、Flatkeyの料金はブレンドで100万トークンあたり約3.60ドルです。月額43,700ドルで約120億ブレンドトークン、つまり1日あたり約4億トークンを購入できます。この量を下回るなら、エンジニアリングの工数を除いても、専用の8x B200ノードよりAPIのほうが安くなります。

選択肢	初期費用	向いている用途
大容量RAMのワークステーションでローカル1-bit GGUF	自前のハードウェア	プライバシー重視の実験、オフライン作業、学習
レンタルした8 GPUノードでvLLMまたはSGLang	時間単位のレンタル	データ管理と本番スループットの両立、ファインチューニング研究
ホスト型API（MoonshotまたはFlatkey）	なし	ほとんどのアプリ、プロトタイプ、変動するトラフィック

上と同じコードで、ベースURLを変えるだけでホスト型モデルを呼び出せます。

import os
from openai import OpenAI

client = OpenAI(base_url="https://router.flatkey.ai/v1", api_key=os.environ["FLATKEY_API_KEY"])
r = client.chat.completions.create(model="kimi-k3",
    messages=[{"role": "user", "content": "Summarize the Kimi K3 license in two sentences."}])
print(r.choices[0].message.content)

詳しくは、セルフホストLLMの100万トークンあたりコストの分析、GPUクラウドとモデルAPIの比較、Kimi K3 APIアクセスガイドをご覧ください。

トラブルシューティング

問題	考えられる原因	対処法
生成が極端に遅い	モデルがRAM + VRAMに収まらず、ディスクから読み込んでいる	より小さい量子化を使う、RAMを増やす、またはGPUサーバーに移る
llama-server起動時に `out of memory`	KVキャッシュが大きすぎる	`--ctx-size` を下げる
画像入力が無視される	プロジェクターファイルがない、または上流版llama.cppを使用	`--mmproj` を渡し、Unslothのフォークをビルドする
vLLMイメージが起動しない	CUDAまたはドライバーが古い	CUDA 13とドライバーr580以降を使う
ツール呼び出しが壊れる	ツール呼び出し出力がまれに崩れる	引数を検証してリトライする
2ターン目の挙動がおかしい	思考内容が返されていない	履歴に `reasoning_content` を含める
ダウンロードが止まる	大容量の複数ファイル転送	`hf download` を再実行すれば再開される