メインコンテンツへスキップ

概要

Kimi K3.1 Proは、ソフトウェア開発、複雑な推論、複数ステップのツールワークフロー向けのMoonshot AIの推論モデルです。APIYIでは、公式リレーのモデルkimi-k3.1-proとkimi-k3.1-pro-highspeedを提供しています。どちらも同じリクエスト形式を使用し、modelを変更することで切り替えられます。
**まずProを使い、ワークフローでより低いレイテンシが必要な場合はHighspeedを選択してください。**どちらのモデルも常に推論を使用し、その深さはreasoning_effortで制御します。Highspeedは入力、出力、キャッシュ書き込みの料金が高くなります。
**1時間のキャッシュは今回のテスト実行で合格しなかったため、検証済みの機能として記載していません。**基本的なチャット、ストリーミング、ツール呼び出しはテストに合格しました。公式パラメータとテスト上の制限については、キャッシュのセクションを参照してください。

クイックスタート

OpenAI SDKまたはHTTPを使用してChat Completionsを呼び出します。

モデルと料金

キャッシュ料金を含めて、ProとHighspeedを比較します。

推論とツール

推論の強度を選択し、ツール呼び出しの履歴を保持します。

コンテキストキャッシュ

公式のキャッシュパラメータと、APIYIのテストの制限を確認します。

モデルの選択と料金

どちらのモデルも実際のtoken使用量に基づいて課金され、APIYIの現在の設定料金は公式価格と一致しています。以下の料金はすべて100万tokenあたりのUSDです。通常の入力料金と出力料金は確認済みです。キャッシュ料金は設定価格であり、このテスト実行で確認したキャッシュ課金額ではありません。
モデル料金は公式プロバイダーの価格に準じており、変更される場合があります。この表は参考情報です。上部ナビゲーションのモデル料金タブが正式な情報です:モデル料金。

チャージボーナス適用時の実質コスト

20%ボーナスキャンペーンの対象となるチャージでは、支払額1単位につき利用可能なクレジットが1.2単位付与されます。そのため、実質コストは表示価格の1 ÷ 1.2 ≈ 83.33%になります。 ボーナスによって利用可能なクレジットは増えますが、モデルの表示価格は変わりません。対象条件、ボーナス率、現在の利用規約については、キャンペーンページをご確認ください。

基本機能のテスト

APIYIは**2026-10-25 (UTC+8)**に、両方のモデルで以下の基本ケースを検証しました。 このガイドでは主にChat Completionsを使用します。既存のResponses連携でもPOST /v1/responsesを使用できます。画像テストではBase64データを使用しました。 POST /v1/messagesへの基本リクエストも合格しました。デフォルトのサンプリングパラメータ変換によるエラーを避けるため、top_p: 0.95とtemperature: 1を明示的に設定してください。
これらのテストでは、基本リクエスト、意味的な結果、通常入力および出力の課金を確認しました。すべてのパラメータ、最大コンテキスト、または長時間実行時の動作を網羅するものではありません。キャッシュの有効期間と課金については、以下の説明に沿って別途確認が必要です。

クイックスタート

APIYIのトークンを使用してPOST /v1/chat/completionsを呼び出します。まずreasoning_effort: "low"から始め、より深い推論が必要なタスクでは値を大きくしてください。
設定ではモデル名をそのまま使用してください。高速版を使用するには、モデル名をkimi-k3.1-pro-highspeedに変更し、残りのインテグレーションはそのまま再利用します。

推論と主要パラメータ

両モデルは常に推論を使用します。reasoning_effortで深度を調整してください。Kimi K2.5のenable_thinkingスイッチを引き継がないでください。
推論と回答に十分なmax_completion_tokensを確保してください。推論で上限を使い切ると、最終回答が空または不完全になる場合があります。finish_reasonを確認し、必要に応じて上限を引き上げてください。
公式のサンプリング値はtemperature=1、top_p=0.95、n=1、presence_penalty=0、frequency_penalty=0に固定されています。チャット補完の例ではこれらを省略しています。Messagesでは、上記の説明に従ってサンプリングパラメータを明示的に設定してください。別のモデルの互換性のない設定を引き継がないでください。

レスポンスの読み方

最終回答はchoices[0].message.contentにあります。推論はchoices[0].message.reasoning_contentに返されます。回答はcontentを参照し、インターフェースに表示される場合はreasoning_contentを別途処理してください。 推論のtokenは出力レートで課金されます。目に見える回答の長さではなく、レスポンスusageとコンソールログからコストを見積もってください。

ストリーミング

推論と回答テキストは、それぞれdelta.reasoning_contentとdelta.contentに届きます。最終の使用量チャンクではchoices配列が空の場合があるため、選択肢を読み取る前にchunk.usageを確認してください。

ツール呼び出し

モデルは関数名と引数を生成し、アプリケーションがそれらを実行します。モデルがtool_callsを返したら、reasoning_contentとtool_callsを含む完全なアシスタントメッセージを履歴に追加します。次に、一致するtool_call_idを付けて各ツール結果を追加し、次のリクエストを送信します。
ツール呼び出しのラウンドでは、アシスタントメッセージ全体を保持してください。reasoning_contentやtool_callsを削除すると、後続の推論やツール結果の照合に支障をきたす可能性があります。要求された操作を実行する前に、ツール名、引数、実行権限を検証してください。

コンテキストキャッシュ

公式のキャッシュ機構は、繰り返し使用する長いシステム指示、参照ドキュメント、コードコンテキストを対象としています。安定した内容を先に置き、変更される質問を最後に置いてください。
1時間のキャッシュは今回のテストで成功せず、APIYIで利用できることが確認された機能ではありません。 2つのモデルで、5分と1時間のポリシー用にそれぞれ異なる長いプレフィックスを使ってテストしました。リクエストは成功しましたが、有効なキャッシュ読み取り数またはキャッシュ書き込み数は返されませんでした。約5.5分後に繰り返した4件のリクエストにも、その後の短い間隔での繰り返しにも、キャッシュヒットはありませんでした。1時間のリクエストのログには、1時間のキャッシュ書き込み料金ではなく、通常の入力料金が記録されていました。
これらの結果は今回のテストに関するものであり、すべてのリクエストでキャッシュがサポートされていないことを示すものではありません。ご自身のリクエストでキャッシュの使用と対応する課金が確認できるまでは、通常の入力料金を見込んでください。以下のパラメーターと動作は、公式フォーマットを参照したものです。

キャッシュの有効期間を選択する

チャット補完では、prompt_cache_options トップレベルのリクエストフィールドを使用します。デフォルトの有効期間は5分です。1時間の有効期間を指定するには、次のようにします。
LONG_STABLE_CONTEXTは、再利用する長いテキストを表します。後続のリクエストでもこのプレフィックスを同一に保ち、最後の質問を置き換えてください。
最初のキャッシュ書き込みで有効期間が決まります。 既存の5分キャッシュに対してttl: "1h"を送信しても、1時間に延長されることはありません。キャッシュヒットが発生すると、元の有効期間が更新されます。ポリシーを比較する場合は、それぞれに異なる新しいプレフィックスを使用してください。

読み取りと書き込みの課金方法

  • キャッシュ読み取り: 再利用されたプレフィックスのtokenには、キャッシュ読み取り料金が適用されます。
  • キャッシュ書き込み: 新たにキャッシュされたプレフィックスのtokenには、選択した5分または1時間の書き込み料金が適用されます。
  • 通常の入力: キャッシュされた部分の外にある入力には、通常の入力料金が適用されます。
  • 出力: 推論と最終回答には、出力料金が適用されます。
これらは公式の課金カテゴリです。今回のテストでは通常の入力料金と出力料金が確認されましたが、キャッシュ読み取りまたはキャッシュ書き込みの精算は確認できませんでした。レスポンスのusage、キャッシュ読み取りとキャッシュ作成のフィールド、コンソールの課金ログを比較してください。パラメーターが受け付けられるだけでは不十分です。

技術仕様と統合のヒント

1

まずは低い推論レベルから始めます

長いコンテキストを追加する前に、短いリクエストを送信して、モデル名、トークン、レスポンスパーサーを検証します。
2

推論の予算を設定します

使用状況とfinish_reasonに基づいてmax_completion_tokensを調整します。より複雑なタスクではreasoning_effortを増やします。
3

長時間実行タスクをストリーミングします

推論テキストと回答テキストを分けて処理し、最終的な使用量を読み取り、クライアントとプロキシで十分なタイムアウトを設定します。
4

規模を拡大する前にキャッシュ使用量を検証します

固定の長いプレフィックスを使ってリクエストを繰り返し、キャッシュ使用量と課金ログを比較して、ワークフローでキャッシュヒットが発生していることを確認します。

FAQ

どちらのモデルも同じ統合形式を使用します。Highspeedは、token価格が高い代わりにレイテンシの低減を目指しています。実際の速度は、promptの長さ、推論の強度、出力の長さ、現在の負荷によって異なるため、実際のワークロードで評価してください。
K3.1 Proモデルでは常に推論が使用されます。古いenable_thinkingパラメーターを引き継ぐのではなく、reasoning_effort: "low"を選択してオーバーヘッドを調整してください。
出力の使用量には推論tokenが含まれます。画面に表示される回答の長さは、出力の総使用量を表すものではありません。応答usageとコンソールログを確認してください。
公式の仕組みでは、既存のキャッシュは初期の有効期間を維持するため、ttl: "1h"には新しいプレフィックスが必要です。APIYIのテストでは、1時間の保持や書き込み料金は検証されていません。パラメーターの受け付けに成功しても、サポートされている証拠にはなりません。
対象となるチャージでは、支払額の1.2倍のクレジットが付与されるため、実質コストは定価の1 ÷ 1.2 ≈ 83.33%になります。適用条件については、キャンペーン規約をご確認ください。

関連ドキュメント

公式リファレンス:platform.moonshot.ai/docs/guide/kimi-k3-1-pro-quickstart、platform.kimi.ai/docs/guide/context-caching、platform.moonshot.ai/docs/pricing/chat。