Kimi K3.1 Pro を API で使う前に押さえる5点：推論強度・reasoning_content・価格・セルフホスト

Posted at 2026-11-07

title: "Kimi K3.1 Pro を API で使う前に押さえる5点：推論強度・reasoning_content・価格・セルフホスト"
tags:
  - AI
  - LLM
  - Kimi
  - MoE
  - Python
private: false

この記事でやること

Kimi K3.1 Pro の重みが Hugging Face で公開されました。Zenn の記事では構成とベンチマークを整理しました。この記事は実践寄りで、API で使い始めるときに押さえる点を5つに絞ります。

最初に注意があります。Kimi K3.1 Pro の API 呼び出しと、セルフホストの起動は、筆者は実行していません（API キーと大規模 GPU がないため）。実行して確認できたのは、次の節のツール呼び出しループを、疑似クライアントで動かした部分だけです。それ以外は、モデルカードと記事の記載を整理したものです。

全体像

項目	内容
モデル	2.8T MoE（活性 104B）、テキストと画像入力、1M コンテキスト
重み	Hugging Face の moonshotai/Kimi-K3.1-Pro※1
API	platform.kimi.ai、モデル名は kimi-k3.1-pro※1
互換性	OpenAI 互換と Anthropic 互換のインターフェース※1
価格	入力 $2.00・出力 $10.00（100万トークンあたり）※2

1. 推論強度は reasoning_effort で選ぶ

推論強度は reasoning_effort で low・high・max から選びます。既定は max です※1。

既定が最大なので、何も指定しないと思考トークンが多くなり、出力コストと待ち時間が増えます。出力は $10/100万トークンなので、定型の抽出やルーティングでは low から試すのが安全です。

OpenAI 互換のクライアントでは、独自パラメータを extra_body で渡すのが一般的です。ただし、このパラメータの渡し方が公式にどう書かれているかは、確認できた資料にありませんでした。使う前に platform.kimi.ai のドキュメントで確認してください。

2. マルチターンでは reasoning_content を戻す

モデルカードには、マルチターンとツール利用では、reasoning_content と tool_calls を含む assistant メッセージ全体を次のリクエストに渡すと書かれています※1。content だけを履歴に積む実装は、よくあるパターンですが、この指示には反します。

次のコードは、ツール呼び出しループで assistant メッセージ全体を履歴に積む例です。

# Python 3.11 / 標準ライブラリのみ。クライアントは OpenAI 互換のものを渡す
import json
from types import SimpleNamespace as NS

def get_weather(city: str) -> str:
    return json.dumps({"city": city, "temp_c": 18})

TOOLS = [{"type": "function", "function": {
    "name": "get_weather", "description": "都市の気温を返す",
    "parameters": {"type": "object",
                   "properties": {"city": {"type": "string"}},
                   "required": ["city"]}}}]

def assistant_to_dict(msg):
    d = {"role": "assistant", "content": msg.content or ""}
    rc = getattr(msg, "reasoning_content", None)
    if rc:
        d["reasoning_content"] = rc          # 次のリクエストへ必ず戻す
    if msg.tool_calls:
        d["tool_calls"] = [{"id": t.id, "type": "function",
            "function": {"name": t.function.name,
                         "arguments": t.function.arguments}}
            for t in msg.tool_calls]
    return d

def run(client, model, user_text, max_turns=5):
    messages = [{"role": "user", "content": user_text}]
    for _ in range(max_turns):
        res = client.chat.completions.create(
            model=model, messages=messages, tools=TOOLS,
            extra_body={"reasoning_effort": "high"})
        msg = res.choices[0].message
        messages.append(assistant_to_dict(msg))
        if not msg.tool_calls:
            return msg.content, messages
        for t in msg.tool_calls:
            args = json.loads(t.function.arguments)
            messages.append({"role": "tool", "tool_call_id": t.id,
                             "content": get_weather(**args)})
    raise RuntimeError("max_turns exceeded")

疑似クライアントでの確認結果

実際の API は呼べないので、ネットワークなしで動く疑似クライアントを作り、2回目のリクエストに reasoning_content が含まれるかを確かめました。

環境：Python 3.11.2、実施日 2026-11-06
結果：東京は18度です が返り、OK: 2回目のリクエストに reasoning_content が含まれる と表示されました。

これは履歴の組み立てロジックの確認であり、Kimi のサーバーの挙動の確認ではありません。本物の API で、reasoning_content を落とすと何が起きるかは、未検証です。

3. 通常版と highspeed 版を使い分ける

モデル	入力	出力	キャッシュ入力
kimi-k3.1-pro	$2.00	$10.00	$0.20
kimi-k3.1-pro-highspeed	$4.00	$20.00	$0.20

highspeed 版は価格が 2 倍で、速度は約 2〜3 倍と Moonshot が主張しています※2。Artificial Analysis の測定では、通常版の出力速度が 52.2 トークン/秒で、Opus 5.5 の 96.8 より遅いと記載されています※2。

対話 UI のように待ち時間が効く用途は highspeed を、夜間のバッチなら通常版を選ぶのが素直です。highspeed の速度は Moonshot の主張値で、筆者は測っていません。

キャッシュ入力は $0.20 と、通常入力の 10 分の 1 です。キャッシュ書き込みは 5 分 TTL で $2.00、1 時間 TTL で $4.00 です※2。長いシステムプロンプトを繰り返し使う構成なら、キャッシュが効きます。

4. セルフホストは「できる」が軽くはない

モデルカードに載っている起動方法は3つです※1。

# vLLM（port 8000 で OpenAI 互換）
pip install vllm
vllm serve "moonshotai/Kimi-K3.1-Pro"

# SGLang（port 30000）
python3 -m sglang.launch_server --model-path "moonshotai/Kimi-K3.1-Pro"

# Docker Model Runner
docker model run hf.co/moonshotai/Kimi-K3.1-Pro

ここで押さえる点は3つです。

総パラメータが 2.8T で、MXFP4 の重みでも複数 GPU の環境が前提です※2。必要な GPU 台数は、確認した資料に書かれていません。
Transformers のサンプルは trust_remote_code=True を要求します。外部コードを実行することになるため、リビジョンを固定して中身を読んでから使ってください。
サンプルは AutoModelForSeq2SeqLM を使っていますが、画像とテキストを扱う生成モデルには合わない可能性があります。そのまま写さないでください。

自社で重みを置く必要がなければ、まず API を使うほうが現実的です。

5. ライセンスと用途の確認

重みは標準的な OSS ライセンスではなく、独自の「Kimi K3.1 Pro License」で配布されています※1。前世代の K3 も独自ライセンスでした※2。商用利用や再配布の条件は、LICENSE ファイルで確認が必要です。ここでは条件の中身は確認していません。

もう1点、公開モデルはサイバー関連データを除いた調整が入っています※2。Moonshot の社内ベンチ xdev-bench-hard（pass@3）は、除去前が 90.5%、公開モデルが 81.0%、K3 が 33.3% です。脆弱性調査やセキュリティ用途の評価では、攻撃的な能力が意図的に抑えられている前提で、自社のテストを組んでください。

ハマりそうな点

reasoning_effort の既定が max で、コストが想定より膨らみやすいです。
content だけを履歴に積むと、モデルカードの指示から外れます。
ベンチマークは自社測定が中心です。Terminal-Bench-Science は Kimi が 38.1 で、Opus 5.5 の 63.3 より大きく低い値でした※2。科学系のタスクは、先に小さく試してください。
重みの公開日がモデルカードに書かれていません。API の公開日は 2026-10-23 と記載されています※2。

評価

使い始めるなら、次の順序がおすすめです。

API で、low と high を自分のタスクで比べる。
履歴に reasoning_content を戻す実装にする。
コストと速度が合えば、通常版と highspeed 版を選ぶ。
重みを自社に置く要件があるときだけ、セルフホストを検討する。

筆者は API もセルフホストも実行していないため、品質の評価はしていません。数字はすべて公開情報の整理です。

まとめ

推論強度は reasoning_effort で選び、既定が max である点に注意する。
マルチターンでは、reasoning_content と tool_calls を含む assistant メッセージを戻す。
価格は入力 $2・出力 $10 で、highspeed は 2 倍。
セルフホストは可能だが、大規模 GPU が前提。
ライセンスは独自で、公開モデルはサイバー関連が弱めに調整されている。

※本記事の記載内容は筆者個人の見解であり、所属する会社や組織の立場や方針とは一切関係ありません。

筆者情報

【Tomcat-zhou】｜AI/AX/AIセキュリティ専門家

AI戦略洞察、AI駆動開発の方法論設計と現場で回る仕組みづくりをしています。
noteで戦略洞察 / Zenn・Qiitaで技術・方法論を書いています。
AIセキュリティ・AIコンサル・AIエージェント開発・AI活用・AI駆動開発教育、AI人材育成サービスを一体で提供。

X: @ZY20240528
LinkedIn: Tomcat-zhou
Facebook: zhou yi
note: Tomcat-zhou
zenn: Tomcat-zhou