このドキュメントでは、Alibaba Cloud Model Studio にデプロイされた Kimi モデルの推論サービスを呼び出す方法について説明します。
kimi-k3.1-pro は、OpenAI Chat Completions、OpenAI Responses、Anthropic Messages、および DashScope ネイティブ API をサポートします。
サービスエンドポイントはリージョン固有です。ご利用のリージョンに合わせて正しいベース URL を設定してください。
- OpenAI 互換
- DashScope
- Anthropic 互換
base_url は、OpenAI Responses の呼び出しにも適用されます。HTTP リクエストでは、POST {base_url}/responses のように base_url の末尾に /responses を付加します。- 米国 (バージニア)
- ドイツ (フランクフルト)
- シンガポール
- 日本 (東京)
- 中国 (北京)
- 中国 (香港)
base_url は次のとおりです: https://{WorkspaceId}.us-east-1.maas.aliyuncs.com/compatible-mode/v1HTTP リクエスト URL: POST https://{WorkspaceId}.us-east-1.maas.aliyuncs.com/compatible-mode/v1/chat/completions{WorkspaceId} を実際の ワークスペース ID に置き換えます。
前提条件: API キーを取得し、環境変数として設定する必要があります。SDK を使用する場合は、SDK をインストールする必要があります。
クイックスタート
以下の例では、テキストのみの入力を使用します。マルチモーダルの例については、「マルチモーダル呼び出し」をご参照ください。
- OpenAI 互換
- DashScope
- Anthropic 互換
- Python
- Node.js
- HTTP
応答
マルチモーダル呼び出し
kimi-k3.1-pro、kimi-k3、kimi-k2.7-code、kimi-k2.6、kimi-k2.5 モデルは、マルチモーダル入力とテキスト出力をサポートします。kimi-k3.1-pro と kimi-k3 はテキストと画像の入力のみをサポートし、動画入力はサポートしません。kimi-k2.7-code、kimi-k2.6、kimi-k2.5 は、テキスト、画像、または動画を同時に処理できます。enable_thinking パラメーターを使用して、思考モードを有効にします。以下の例では、この機能の使用方法を示します。
思考モードの有効化または無効化
kimi-k2.6 と kimi-k2.5 はハイブリッド思考モデルです。これらのモデルは、思考してから返信するか、直接返信することができます。enable_thinking パラメーターを使用して、思考モードを有効にするかどうかをコントロールできます:
true:思考モードを有効にしますfalse(デフォルト):思考モードを無効にします
kimi-k2.7-code は思考専用モデルです。思考モードは常に有効であり (enable_thinking はデフォルトで true となり無効化できません)、preserve_thinking もデフォルトで true となります。
kimi-k3.1-pro と kimi-k3 は、デフォルトで思考が有効です (enable_thinking=true)。false に設定して無効にできますが、有効のままにすることを推奨します。kimi-k3.1-pro では、思考を無効にすると出力品質が大幅に低下するため、有効のままにすることを強く推奨します。両モデルは、クライアントから渡された過去の reasoning_content をデフォルトで保持します。複数ターンのリクエストでは、過去の assistant メッセージの完全な reasoning_content を渡すことを推奨します。
kimi-k2.6 では、preserve_thinking パラメーターを使用することで、マルチターン対話で思考プロセスを渡すことができます。 詳細については、「思考プロセスを渡す」をご参照ください。
以下の例では、画像 URL の使用方法と思考モードの有効化について説明します。主な例では単一画像入力を、コメントアウトされたコードでは複数画像入力の例を示します。
- OpenAI 互換
- DashScope
動画理解
- 動画ファイル
- 画像リスト
-
fps:フレーム抽出周波数をコントロールします。抽出されるフレーム間の間隔は
1/fps秒です。値は [0.1, 10] の範囲内である必要があります。デフォルト値は 2.0 です。- 動きの激しいシーンの場合:より多くの詳細をキャプチャするために、より高い fps 値を設定します。
- 静的な動画や長時間の動画の場合:処理効率を向上させるために、より低い fps 値を設定します。
-
max_frames:動画から抽出するフレームの最大数を指定します。デフォルトおよび最大値は 2000 です。
fps 値から計算されたフレーム数がこの制限を超えた場合、システムは
max_framesの制限内に収まるようにフレームを均等に自動抽出します。このパラメーターは、DashScope SDK を使用する場合にのみ使用できます。
- OpenAI 互換
- DashScope
OpenAI SDK または HTTP リクエストを使用してモデルに動画ファイルを渡す場合、ユーザーメッセージの"type"パラメーターを"video_url"に設定します。
ローカルファイルの受け渡し
以下の例では、ローカルファイルの受け渡し方法を示します。OpenAI 互換 API は Base64 エンコーディングのみをサポートしますが、DashScope は Base64 エンコーディングとファイルパスの両方をサポートします。
- OpenAI 互換
- DashScope
ファイルの制限
- 画像の制限
- 動画の制限
-
画像解像度:
- 最小サイズ:幅と高さはそれぞれ
10ピクセルを超える必要があります。 - アスペクト比:最も長い辺と最も短い辺の比率が
200:1を超えてはなりません。 - 最大解像度:推奨される最大解像度は
8K (7680x4320)です。解像度が高いと、ファイルサイズが大きくなったり、ネットワーク転送が遅くなったりして、API 呼び出しがタイムアウトする可能性があります。
- 最小サイズ:幅と高さはそれぞれ
-
サポートされている画像フォーマット
-
4K
(3840x2160)未満の解像度では、次のフォーマットがサポートされています:画像フォーマット
ファイル拡張子
MIME タイプ
BMP
.bmp
image/bmp
JPEG
.jpe, .jpeg, .jpg
image/jpeg
PNG
.png
image/png
TIFF
.tif, .tiff
image/tiff
WEBP
.webp
image/webp
HEIC
.heic
image/heic
-
4K (3840x2160)から8K (7680x4320)の解像度では、JPEG、JPG、PNG のみがサポートされています。
-
4K
-
画像サイズ:
- 公開 URL またはローカルパス経由で画像を提供する場合、そのサイズは
10 MBを超えてはなりません。 - Base64 エンコーディングを使用する場合、エンコードされた文字列は
10 MBを超えてはなりません。
ファイルを圧縮するには、「画像または動画を圧縮してサイズ制限を満たす方法」をご参照ください。
- 公開 URL またはローカルパス経由で画像を提供する場合、そのサイズは
- サポートされる画像の数:複数の画像を提供する場合、すべての画像とテキストの合計トークン数は、モデルの最大入力制限を超えてはなりません。
その他の機能
モデル | |||||||
|---|---|---|---|---|---|---|---|
kimi-k3.1-pro | サポート | サポート | サポート | サポート (JSON Mode) | サポート | 非サポート | サポート (暗黙的キャッシュ) |
kimi-k3 | サポート | サポート | サポート | サポート | サポート (Responses API) | サポート | サポート |
kimi-k2.7-code | サポート | サポート | サポート | 非サポート | 非サポート | 非サポート | サポート |
kimi-k2.6 | サポート | サポート | サポート | 非サポート | 非サポート | 非サポート | サポート |
kimi-k2.5 | サポート | サポート | サポート | 非サポート | 非サポート | 非サポート | サポート |
動的ツールロード
アプリケーションで多数のツールをマウントする必要がある場合、すべてのツール宣言を一度にリクエストのトップレベルの tools フィールドに含めると、ツール定義の肥大化 (Tool Definition Bloat) が発生します。すべてのリクエストにすべてのツールの説明とパラメータースキーマを含める必要があるため、トークン消費量が増加します。また、候補となるツールが多いほど、モデルが誤ったツールを選択したり、誤った呼び出し引数を構築したりする可能性が高くなります。
動的ツールロード (Dynamically Loaded Tools) を使用すると、対話中に必要に応じてツールを注入できます。最初は少数のコアツールのみをマウントし、対話が特定のツールを必要とする段階に達したときに、そのツールを messages に動的に挿入します。これにより、トークン消費量を削減し、ツール選択の精度を向上させることができます。
tokenization failed エラーが返されます。このセクションで説明する、system メッセージの tools フィールド (system.tools) を介して messages にツールを注入する形式とサンプルは、OpenAI Chat Completions API に適用されます。messages でのツール宣言の注入
role が system のメッセージを messages に挿入し、そのメッセージの tools フィールドでロードするツールを宣言します。形式はリクエストのトップレベルの tools フィールドと同じであり、完全なツール情報 (name、description、parameters) を指定する必要があります。
toolsを含むsystemメッセージは、通常のメッセージと同じ扱いになります。ツールは、そのメッセージがmessagesリスト内に現れる位置からモデルに認識されます。- 動的にロードされたツールは、リクエストのトップレベルの
toolsフィールドで宣言されたグローバルツールと共存します。モデルは両方の種類のツールを同時に認識できます。 - 動的に注入するツール宣言は、完全なツール定義である必要があります。ツール名のみを渡したり、グローバルに宣言されたツールを参照したりすることはできません。
toolsを含むsystemメッセージにcontentフィールドを同時に含めることはできません。含めた場合、リクエストは 400 エラーで失敗します。OpenAI SDK を使用する場合、toolsフィールドをmessages内でそのまま渡すことができます。
検索ツールと組み合わせたオンデマンドロード
専用のツール検索 API はありません。ツールが多い場合は、カスタム検索ツールと動的ツールロードを組み合わせて、必要に応じてツールをロードできます:
- セッションの開始時に、トップレベルの
toolsでは、アプリケーションのバックエンドで実装したsearch_toolsツール (キーワードに基づいて一致するツール名と概要を返す) と、毎ターン使用する可能性のある少数のコアツールのみを宣言します。 - システムプロンプトで検索可能なキーワード (ツールカタログやドメインタグなど) を宣言し、ツールが必要な場合はまず
search_toolsを呼び出すようモデルを誘導します。最初のリクエストでtool_choice: "required"を設定すると、少なくとも 1 回のツール呼び出しが保証されますが、search_toolsが最初に呼び出されることは保証されません。最初に検索することが必須の場合は、tool_choice: {"type": "function", "function": {"name": "search_tools"}}を明示的に設定し、検索後にtool_choiceを"auto"に戻します。tool_choiceを変更しても、プレフィックスキャッシュは無効になりません。 search_toolsが返した結果に基づいて、アプリケーションは対応するツールの完全な宣言を、toolsを含むsystemメッセージを介してmessagesに動的に挿入します。- モデルは、以降の生成において、新たにロードされたこれらのツールを直接呼び出すことができます。
注意事項
- 動的ツール宣言はリクエスト単位で有効になり、サーバー側では記憶されません。次のリクエストでも引き続き含めるかどうかは、インテグレーターが決定します。引き続き含める場合、ツールは利用可能なままとなります (プレフィックスキャッシュのヒットにも役立ちます)。含めるのをやめると宣言は失効し、そのツールが他の場所で宣言されていない場合、モデルはそのツールを呼び出せなくなります。また、変更箇所以降のプレフィックスキャッシュがミスする可能性があります。
messagesの末尾に動的ツール宣言を追加しても、既存のプレフィックスのキャッシュには影響しません。それ以前のツール宣言を削除または変更すると、変更箇所以降のキャッシュヒットに影響する可能性があります。リクエストのトップレベルのtoolsフィールドでグローバルツールを宣言しても、キャッシュヒットには影響しません。toolsを含むsystemメッセージもコンテキスト長を消費するため、現在の対話で本当に必要なツールのみを注入してください。- 動的ツール宣言はグローバルな
tools宣言とまったく同じ形式を使用するため、インテグレーターは 2 種類のスキーマを管理する必要はありません。
デフォルトパラメーター
モデル | enable_thinking | temperature | top_p | presence_penalty | fps | max_frames |
|---|---|---|---|---|---|---|
kimi-k3.1-pro | true (無効化可能。有効のままにすることを強く推奨) | 1.0 | 0.95 | 0.0 | - | - |
kimi-k3 | true (無効化可能。有効のままにすることを推奨) | 1.0 | 0.95 | 0.0 | - | - |
kimi-k2.7-code | true (思考モードのみ) | 1.0 | 0.95 | 0.0 | 2 | 2000 |
kimi-k2.6 | false | 思考モード:1.0 ノンシンキングモード:0.6 | 両モード:0.95 | 両モード:0.0 | 2 | 2000 |
kimi-k2.5 | false | 思考モード:1.0 ノンシンキングモード:0.6 | 両モード:0.95 | 両モード:0.0 | 2 | 2000 |
temperature=1.0、top_p=0.95、presence_penalty=0.0 に固定されています。これらのパラメーターにデフォルト以外の値を渡すと、エラーが返されます。
以下の推論エフォートレベルは kimi-k3.1-pro にのみ適用され、デフォルトは max です:
max(デフォルト):深い推論high:強化された推論medium:中程度の推論low:軽い推論
- OpenAI Chat Completions:トップレベルの
reasoning_effortフィールドを使用します。OpenAI Python SDK では、reasoning_effort="max"を直接渡します。 - DashScope:SDK の
reasoning_effortパラメーター、または HTTP リクエストのparameters.reasoning_effortを使用します。 - OpenAI Responses:
reasoning.effortを使用します。 - Anthropic Messages:
output_config.effortを使用します。
モデルと課金
Kimi シリーズは、Moonshot AI の大規模言語モデルです。
- kimi-k3.1-pro:テキストと画像の入力、テキスト出力、および動的ツールロードをサポートします。動画入力、Batch、ファインチューニングはサポートしません。
- kimi-k3:Kimi のフラッグシップモデルです。デフォルトで推論し、思考を保持します。テキストと画像の入力 (動画入力は非サポート)、対話、エージェントタスク、および動的ツールロードをサポートします。
- kimi-k2.7-code:コーディング向けの Kimi モデルです。長文コンテキストの命令により忠実に従い、プログラミングタスクでより高い成功率を達成します。テキスト、画像、動画入力、思考モード、対話、エージェントタスクをサポートします。
- kimi-k2.6:長期間のコーディング、命令追従、自己修正においてパフォーマンスが向上した Kimi シリーズのモデルです。テキスト、画像、動画入力、思考モードとノンシンキングモード、対話、エージェントタスクをサポートします。
- kimi-k2.5:エージェントタスク、コード生成、視覚理解、その他の一般的な知能タスクに関するオープンソースのベンチマークで最先端 (SOTA) のパフォーマンスを達成します。画像、動画、テキスト入力、思考モードとノンシンキングモード、対話、エージェントタスクをサポートします。
thinking_budget パラメーターをサポートしません。このパラメーターで思考の長さを制限することはできません。価格については、「モデル呼び出しの課金」をご参照ください。価格とコンテキストウィンドウの詳細については、Model Studio コンソールをご参照ください。 課金は、入力および出力トークン数に基づきます。
思考モードでは、思考の連鎖が出力トークンとしてカウントされます。