Kimi K3.1 Pro を自前で動かす条件と API との使い分け

Moonshot AI が 2026 年 10 月 23 日に Kimi K3.1 Pro を公開し、重みも 11 月 4 日までに公開すると予告しました。重みが出れば手元の機材で動かす道が開けますが、3T 級のモデルにはどれくらいの機材が要るのでしょうか。先に重みが出た Kimi K3 の数字を目安に、API で使う場合と比べます。情報は 2026 年 10 月 25 日時点のものです。

この記事の要点

• 重みはまだ公開されていません。K3 の GGUF は最も小さい量子化でも 466GB あり、500GB 前後のメモリを 1 台に積んだ機材がスタートラインです。
• メモリ 512GB の Mac Studio で K3 を枝刈りして動かした事例があります。ただ英語とコードだけを手がかりに削っているので、日本語で使うなら避けたほうが無難です。
• API は OpenAI 互換で、回答の前の推論（thinking）は切れず、reasoning_effort のデフォルトは max です。単価は Simon Willison などによると 100 万トークンあたり入力 $2.00、出力 $10 ですが、公式の価格表ではまだ確かめられていません。

Kimi K3.1 Pro とは

Kimi K3.1 Pro は、Kimi K3 をはるかに多い計算量で後学習（事前学習のあとの追加の学習）したモデルです。コンテキストは 1M トークンで、2〜3 倍速いとされる Highspeed 版も同時に出ました。

元になった K3 は、混合エキスパート（MoE）という作りです。K3 の公式ブログでは総パラメータが 2.8T で、896 の expert のうち 16 を使います。K3.1 Pro の公式ブログには「3T-class」とあるだけなので、同じ構成かは重みの公開後にわかります。

MoE は、大きな総合病院に例えられます。病院には専門の違う医師が大勢いますが、1 人の患者を診るのはそのうちのごく一部ですよね。MoE では文章の 1 語 1 語（トークン）が患者にあたり、診察の段階（層）ごとに、どの医師（expert）を呼ぶかが変わります。誰が呼ばれるかは患者が来るまでわからないので、医師は全員そろっていないといけないんです。手元で動かすときに重みを丸ごとメモリに載せるのは、このためです。

手元で動かすのに要るメモリ

K3.1 Pro の GGUF（llama.cpp などで使うモデルファイルの形式）はまだ無いので、Unsloth が配っている K3 の GGUF を目安にしました。

いちばん小さくても 466GB です。私の手元の M1 Max の Mac も、Radeon RX 9070 XT（VRAM 16GB）の Windows の PC もメモリ（RAM）は 64GB なので、7 倍以上の開きがあります。足りない分を SSD で補う手もありますが、次の節の Zenn の記事によると、1bit の量子化を SSD に逃がして動かすと、試したリクエスト 1 件に 3 時間かかったそうです。K3 の数字から考えると、500GB 前後のメモリを積んだ機材がスタートラインです。

枝刈りして 441GB にした K3 の事例

2026 年 8 月 2 日の Zenn の記事に、K3 を Mac Studio（M3 Ultra、メモリ 512GB）1 台で動かした個人の事例があります。REAP という手法で各層の expert を減らし、1bit 級の量子化と組み合わせて、512GB のメモリに収まる大きさにしたものです。

decode が 3 tok/s だと、1,000 トークンの回答に 5 分以上かかります。対話より、寝かせておける処理向きの速さです。

気を付けたいのは日本語です。病院の例えで言えば、英語とコードの患者だけで忙しさを測り、出番の少なかった医師を帰してしまったようなものです。実際この事例では、英語とコードだけの約 26 万トークンを手がかりに、残す expert を決めています。同じ記事が引く別の実測では、中国語と日本語でよく選ばれる expert の重なりは 42.8% しかなく、英語とコードだけで削ると中国語が壊れたそうです。日本語でも崩れる可能性が高いので、私なら日本語の用途には使いません。

API で使うときの仕様

API は OpenAI 互換で、base_url を変えれば openai のライブラリからそのまま呼べます。https://platform.kimi.ai/ でキーを作り、$1 以上をトップアップすると使えるようになります。

import os
from openai import OpenAI

client = OpenAI(api_key=os.environ["MOONSHOT_API_KEY"], base_url="https://api.moonshot.ai/v1")
response = client.chat.completions.create(
    model="kimi-k3.1-pro",
    reasoning_effort="high",
    messages=[{"role": "user", "content": "..."}],
)

ほかのモデルと同じつもりで使うと、引っかかる点があります。

何も指定しないと max で考え続けて遅く高くなりがちなので、reasoning_effort は明示しておくのがおすすめです。

料金は、Simon Willison と Artificial Analysis によると 100 万トークンあたり入力 $2.00、出力 $10 で、Simon はこれを Claude Opus 5.5 の半額としています。公式の価格ページでは、単価をまだ確かめられていません。

使いどころと注意点

API とローカルのどちらを選ぶかは、次の順番で考えるとすっきりします。

多くの人には API が現実的です。API では Zero Data Retention（入出力を保持しない扱い）も使えるので、社内の規程によってはこれで足ります。ローカルが候補になるのは、データを外に出せず、500GB 級の機材もある場合に限られそうです。

公式は長いコーディングの社内ベンチを強調しているので、コーディングエージェントのモデルを差し替えて比べるのが合いそうです。既存のツールの接続先を変えて試すなら、ツールが reasoning_content を返せるかと、固定のパラメータを送らないかを確かめてください。

ローカルを考えているなら、重みが出た時点で、model card のパラメータ数、重みの形式、ライセンス、ファイルサイズ、推論エンジンの対応をまとめて確かめ直すのが先です。1bit の量子化や枝刈りで動かした版の品質は、公式の数字とは別物です。日本語の性能は公式に数字が無いので、日本語の業務なら API で品質を見てからローカルを検討する順番が無難だと思います。

llama-server -m <gguf> -ngl 99 -c 131072 --jinja --cache-reuse 0 --temp 1.0 --top-p 0.95