リリースされた重みでローカルにフルKimi K3を動かすことは可能ですが、実用的な展開にはクラスター規模のメモリ、アクセラレータ、インターコネクトが依然として必要です。
7月27日のオープンウェイトリリース後、チェックポイントの存在ではなく、システムがそれをダウンロード、ロード、実用的な速度でサーブできるかが問題です。公開リポジトリは96個のsafetensorシャードで約1.56TB、モデルは合計2.8兆パラメータを持ち、トークンごとに1040億を活性化します。これらの数字は通常のPC、Mac、家庭用NAS、単一GPUサーバーを実用的なフルモデル範囲外に置くため、以下のセクションではストレージ、メモリ、アクセラレータトポロジー、ランタイムサポート、現実的なフォールバックパスを分けて説明します。
| リリース後の確認 | 現在の回答 |
|---|---|
| フルウェイトは利用可能ですか? | はい。モデルリポジトリと技術レポートは公開されています。 |
| 通常のPC、Mac、または家庭用NASでフルモデルを実用的に動かせますか? | いいえ。実験的なオフロードはワークロードの一部を起動するかもしれませんが、インタラクティブなフルモデルサービングはクラスター規模の作業です。 |
| ダウンロード可能なリポジトリのサイズはどれくらいですか? | 追加の一時ストレージやランタイムデータを除くと、96個のsafetensorシャードで約1.56TB。 |
| 透明なウェイトオンリーフロアとは何ですか? | 約1.4TB、つまり4ビットあたり2.8兆パラメータから1.27TiB。 |
| 現在推奨されているサービングエンジンは何ですか? | vLLM、SGLang、TokenSpeedがKimi K3専用のデプロイメントパスを使用。 |
Kimi K3の重みがリリースされて今何が利用可能ですか?
Kimi K3オープンウェイトリリースには、完全なモデルチェックポイントと技術レポートが含まれています。公開されているモデルリポジトリは現在約1.56TBのファイルと96個の番号付きsafetensorシャードを示しています。この数字はダウンロードやディスク容量の計画に役立ちますが、最小VRAM仕様ではありません。
リリースされたモデルの概要によると、合計2.8兆パラメータ、1040億の活性化パラメータ、93層、69のKimiデルタアテンション層、24のゲート付きMLA層が確認されています。Stable LatentMoEルーティングは、トークンごとに896のルーティングされたエキスパートのうち16を選択し、さらに2つの共有エキスパートも使用します。重みはMXFP4、活性化はMXFP8で、最大コンテキスト長は1,048,576トークンとされています。
展開サポートはリリース前よりも具体的になっています。vLLM、SGLang、TokenSpeedが推奨推論エンジンとしてリストされていますが、それぞれK3対応のカーネル、モデルコード、シャーディング、メモリ設定が必要です。クライアントライブラリによる一般的なコマンドは、チェックポイントを消費者向けのローカルモデルに変えるものではありません。
なぜスパースMoEは依然として膨大なメモリを必要とするのか?
Kimi K3は各トークンに対して1040億の活性化パラメータで計算を行いますが、すべてのMoEエキスパートは依然としてストレージとサービングメモリを消費します。ルーターは次のトークンのために異なるエキスパートを選択できるため、完全な2.8兆の重みセットは展開のどこかでアクセス可能なままでなければなりません。
896人のルーティングされたエキスパートのうち16人を選択することは、1トークンあたりのエキスパート作業を減らします。これは、マシンが16人のエキスパートだけを保持し、残りを破棄してもリリースされたモデルを変更せずに実行できることを意味しません。エキスパートのプルーニング、蒸留、またはストリーミングは異なる運用トレードオフを生み、通常のスパース活性化と混同してはなりません。
したがって、1040億の活性化パラメータ数は計算スケールの説明であり、チェックポイントサイズを推定するための近道ではありません。1040億に4ビットを掛けてモデルが約52GBで済むと主張すると、非活性だが依然として必要なエキスパートの重み、密なコンポーネント、共有エキスパート、アテンション層、ビジョン重み、ランタイム状態を無視することになります。
| 公開された数値 | それが説明すること | それが意味しないこと |
|---|---|---|
| 合計2.8兆パラメータ | 保存およびアクセス可能にしなければならない完全な重みセット | すべてのパラメータがすべてのトークンに対して計算されること |
| 1040億の活性化パラメータ | 1トークンのフォワードパス中に使用されるおおよそのパラメータスケール | フルモデルが4ビットで52GBに収まること |
| 896人のルーティングされたエキスパートのうち16人 | トークンごとのスパースエキスパートルーティングパターン | ダウンロードまたはロードする必要があるのは16人のエキスパートだけであること |
最小の重みメモリ下限とは何か?
2.8兆パラメータの場合、最も単純な下限計算は、総パラメータ数にパラメータあたりの格納ビット数を掛けたものです。MXFP4は4ビットのペイロード下限を提供します:2.8T × 4ビットは約1.4TB、つまり生の重みペイロードだけで約1.27TiBになります。
公開されたリポジトリは約1.56 TBであり、サービングメモリが単純な重み計算を超える理由を示しています。チェックポイントのパッケージング、ブロックスケール、テンソルの整列、構成ファイル、トークナイザー資産、ビジョンコンポーネント、およびその他のモデルデータが、理論的な4ビット下限を超えて実際のダウンロードサイズを押し上げています。
4つの異なる予算を別々に計画する必要があります:永続的なダウンロードストレージ、一時的なステージングスペース、ホストRAM、およびアクセラレータのHBMまたはVRAM。稼働中のサービスはさらにKDA状態、MLA KVキャッシュ、アクティベーション、通信バッファ、カーネル、グラフキャプチャ、および障害時の余裕のためのスペースを必要とします。したがって、1.56 TBのリポジトリサイズは完全なRAM要件でも完全なGPUメモリ要件でもありません。
| 重みの表現 | おおよその重みのみのメモリ | この数値に含まれないもの |
|---|---|---|
| 16ビット相当 | 約5.6 TB | キャッシュ、アクティベーション、ランタイムバッファ、レプリカ、および通信作業領域 |
| 8ビット相当 | 約2.8 TB | 量子化メタデータとすべての非重みサービングオーバーヘッド |
| MXFP4理論的下限 | 約1.4 TB / 約1.27 TiB | ブロックスケール、パッケージング、キャッシュ、アクティベーション、および予備容量 |
| 現在の公開リポジトリ | 約1.56 TB | 一時的なダウンロードスペースとロード後に必要なすべてのメモリ |
実際にKimi K3をローカルで動作させられるハードウェアは何ですか?
完全なモデルに対する正直なコンシューマー向け最小GPUリストは存在しません。技術的にチェックポイントをマッピングまたはストリーミングできるシステムが、安定したインタラクティブなサービングを自動的に実行できるわけではありません。実用的なKimi K3ハードウェア要件は、重みの常駐、対応するMXFP4カーネル、インターコネクト帯域幅、キャッシュ容量、コンテキスト長、同時実行性、およびサービングエンジンに依存します。
公開されたday-zero Kimi K3サービングサポートは、現実的な開始クラスを8アクセラレータのエンタープライズノードに設定しています。現在のvLLM資料は、8つのGB300クラスまたはMI350X/MI355Xクラスのアクセラレータを開始ポイントとして説明しており、SGLangはB300 1×8、GB300 2×4、B200 2×8、H200 2×8、H100 4×8、MI350X/MI355X 1×8を含むトポロジー対応の例を公開しています。
これらは公開されたランタイムレシピと開始構成であり、すべてのワークロードに対する単一の認定最小値ではありません。古いまたは小型のアクセラレータは、より多くのノード、異なる量子化カーネル、コンテキストの削減、または追加の専門的な並列処理を必要とする場合があります。実運用のトラフィックでは、単にチェックポイントを一度収めるだけでなく、同時リクエスト、失敗したワーカー、パフォーマンスの余裕のための容量も必要です。
| ハードウェアクラス | 完全なKimi K3の実現可能性 | 主な境界 |
|---|---|---|
| 一般的なPC、Mac、家庭用NAS、または1つのコンシューマーGPU | 実用的ではありません | チェックポイントとサービングのオーバーヘッドが通常のローカルメモリ容量を超えています |
| 複数の消費者向けGPUとRAM/NVMeオフロード | 実験的のみ | PCIe、RAM、ストレージ帯域幅がエキスパートの移動を実用的でないほど遅くする可能性がある |
| 8カードの現世代アクセラレータノード | 公開された開始クラス | サポートされたカーネル、十分なHBM、ランタイムに適合したトポロジーが必要 |
| マルチノードアクセラレータクラスタ | 現実的なプロダクションクラス | RDMAまたは同等のファブリック、分散オーケストレーション、障害処理が必要 |
なぜ1台のワークステーションやNASは依然として誤ったトポロジーなのか?
単純な容量の分割は問題を過小評価しています。十分な総メモリが集まっても、エキスパート並列処理はルーティングをネットワークトラフィックに変えます。トークンは選択されたエキスパートを保持するアクセラレータに届き、モデルパイプラインの残りに戻らなければなりません。
エンタープライズアクセラレータノードはメモリ以上のものを提供します。高帯域幅GPUリンク、RDMA対応ネットワーク、集合通信ライブラリ、テンソル、エキスパート、データ、パイプライン並列処理向けのカーネルを組み合わせています。通常のPCIeやホームネットワークを介して接続された消費者向けGPUの集合は、名目上の容量は十分に見えても、有用なサービングには遅すぎたり脆弱すぎたりします。
NASはチェックポイントのシャード、ログ、データセット、検索インデックス、アプリケーションデータの保存に有用ですが、ネットワークストレージはアクセラレータのメモリ帯域幅に代わるものではありません。より良いホームサーバーの役割は、通常、プライベートデータと検索をユーザーの近くに保持し、最先端モデルの推論は適切なクラスタやホストされたエンドポイントに任せることです。その設計では、ホームサーバーはローカルデータ層を最先端推論から分離します。
KDA状態、MLA KVキャッシュ、およびコンテキスト長はどのように予算を増加させるのか?
Kimi K3は93層すべてにわたって均一なフルアテンションキャッシュを使用していません。69層のKDAと24層のゲーテッドMLAが、受け入れられたリクエスト用の固定モデルジオメトリを持つKDA状態プールと、保存されたトークンに応じて増加するページングされたMLA KVプールという、2つの異なるサービングメモリ需要を生み出します。
この分割により、KDAは従来のアテンションで見られる長いコンテキストの増加を抑制できますが、100万トークンのリクエストを無料にするわけではありません。KDA状態とMLA KVメモリはアクセラレータの容量を競合するため、KDA側は受け入れ可能なリクエスト数を制限し、MLA側はキャッシュされたトークンの総数を制限します。
バッチサイズ、同時実行数、平均プロンプト長、生成される推論長、マルチモーダル入力、キャッシュ精度、プリフィル/デコード戦略はすべて使用可能な容量を変化させます。1Mトークンの数値は最大モデル能力であり、推奨デフォルトではありません。最初のデプロイメントは、より短い最大コンテキスト、バッチサイズ1、低同時実行数で開始し、メモリ不足エラー、プリフィル時間、デコード速度、ノード間トラフィックを測定してください。
オープンウェイトリリース後にKimi K3をローカルで実行するには?
現在Kimi K3をローカルで実行するとは、リリースされたチェックポイントを中心に分散推論サービスを構築することであり、通常のデスクトップアプリケーションをインストールすることではありません。最も安全な手順は、ストレージ、ランタイムサポート、トポロジー、小さな動作点を検証してからコンテキストやトラフィックを増やすことです。
- ストレージを準備してください。約1.56TBのリポジトリフットプリントに加え、部分ダウンロード、キャッシュ、コンテナイメージ、ログ、一時ファイル用の余裕を確保します。
- サポートされているエンジンを選択してください。必要なモデルコード、カーネル、コンテナまたはブランチバージョンを備えたKimi K3専用のvLLM、SGLang、またはTokenSpeedのデプロイメントパスを使用します。
- トポロジーを合わせてください。十分なHBMとNVLink、MNNVL、またはRDMAパスを備えたエンタープライズのマルチGPUまたはマルチノードレイアウトを選択し、そのテンソルおよびエキスパート並列設定に対応させます。
- 見出しの制限以下で開始してください。最大モデル長、バッチサイズ、同時実行数を減らし、ロード、OOM動作、出力の正確さ、プリフィル速度、デコード速度、全ノード間トラフィックを検証します。
- 測定後にのみスケールしてください。コンテキスト、同時リクエスト、キャッシュ機能、マルチモーダル入力、または推測デコーディングを一度に一つずつ追加します。
次のようなコマンド vllm serve または sglang serve 対応する分散ランタイムの起動方法を説明していますが、ハードウェア要件を取り除くものではありません。必要なアクセラレータクラスが利用できない場合、現実的な選択肢はホストされたAPI、ファイルと取得をローカルに保持するハイブリッドアーキテクチャ、または家庭用サーバーの実際のメモリと信頼性予算に合った小型のローカルモデルです。
よくある質問
Kimi K3を通常のPC、Mac、または家庭用NASでローカルに実行できますか?
実用的なフルモデル速度ではありません。リポジトリはサービングオーバーヘッド前で約1.56TBあり、通常のローカルシステムは現在のランタイムが期待するアクセラレータメモリや高帯域幅トポロジーも欠いています。実験的なエキスパートストリーミングや重いオフロードにより起動が技術的に可能であることは証明されるかもしれませんが、それは応答性のあるまたは本番対応のサービングと同等ではありません。
Kimi K3にはどれくらいのストレージとメモリが必要ですか?
透明なMXFP4の重みペイロードの下限は約1.4TBであり、公開リポジトリは約1.56TBです。さらに追加のディスクスペース、ホストRAM、アクセラレータのHBMまたはVRAM、KDA状態、MLA KVキャッシュ、活性化、通信ワークスペース、運用の余裕が必要です。これらすべての層を表す単一の数値は存在しません。
Kimi K3の最小公開GPUセットアップは何ですか?
公開されている最小のデイゼロ構成は8カードのエンタープライズアクセラレーターノードであり、現在のvLLMおよびSGLangのパスはB300、GB300、またはMI350X/MI355Xクラスのハードウェアを中心にしています。これらをランタイムの出発点として扱い、普遍的な保証された最小構成とは見なさないでください。コンテキスト、同時実行、エンジンバージョン、生産目標によってはより多くのリソースが必要になることがあります。
Kimi K3はSSDやNASのオフロードから実行できますか?
SSDやNASストレージはチェックポイントのシャードを保持でき、実験的なランタイムはホストメモリを通じて重みをストリーミングすることがあります。制限となる問題は、専門家の重みと状態をストレージ、ネットワーク、RAM、PCIeリンクを通じて繰り返し移動させることです。これらの経路はアクセラレータのHBMや高速GPUファブリックよりはるかに遅いため、実験的な起動では使用に耐えないレイテンシが発生する可能性があります。
OllamaはKimi K3の全モデルをローカルで実行しますか?
現在のOllama Kimi K3エントリはkimi-k3:cloudタグを使用しています。ローカルのOllamaクライアントを実行しても、1.56TBのチェックポイントがローカルマシンにロードされているわけではなく、リストされたルートはクラウドバックアップされています。
最終的なまとめ
Kimi K3は現在、オープンウェイトモデルとして本当に利用可能になっているため、クラスタ運用者は事前リリースの推定に頼るのではなく、完全なチェックポイントをダウンロードして展開できます。このリリースは検証とツールの利用可能性を変えますが、2.8Tパラメータモデルの物理的な規模は変わりません。
最も有用なKimi K3のメモリ数値は異なる質問に答えます:約1.4TBは透明な4ビットの重みのみの下限、約1.56TBは現在のリポジトリのフットプリント、104Bはトークンごとの活性化された計算規模です。これらの数値のいずれも、稼働中のサービスに必要な完全なメモリを単独で表しているわけではありません。
ほとんどの個人やホームサーバーユーザーにとって、停止の境界は明確です。エンタープライズの8アクセラレーターノードや分散クラスタがない場合は、ホストされた推論を使用し、プライベートデータと検索レイヤーはローカルに保持するか、より小さいモデルを選択してください。これが、NAS、ワークステーション、または単一GPUを最先端モデルのスーパーノードとして扱わずにKimi K3の恩恵を受ける実用的な方法です。
テック&AIハブ
もっと読む

AIエージェントのプランナーが完了済みの手順を繰り返す原因は何ですか?
状態の永続化、完了の証拠、ツール結果の解析、コンテキストの保持、再試行、再計画、停止条件を通じて、プランナーの繰り返されるステップを追跡します。

AIエージェントのサブプロセス内でのみ権限エラーが発生する原因は何ですか?
サブプロセスでのみ発生する拒否を診断するため、親プロセスと子プロセスのアイデンティティ、ファイルシステムビュー、環境、ケイパビリティ、セキュリティポリシー、実行可能ファイルのパスを比較します。

ハードウェアトランスコードと動画AIを同時に実行するとCPUが飽和する原因は何ですか?
コーデックのオフロード、ピクセル変換、フレームコピー、AI前処理、オーディオ、字幕、ストレージ、プロセススケジューリング全体のCPU飽和状況を追跡します。

