AWS、Kimi K3.1 Pro HighspeedをAmazon Bedrockで提供開始

Amazon Web Servicesは2026年11月10日、Moonshot AIのKimi K3.1 Pro HighspeedをAmazon Bedrockで提供開始しました。グローバル、米国、インドの推論プロファイルを通じて、100万トークンのコンテキストウィンドウを利用できます。Moonshot AIによると、Highspeed版はK3.1 Proより2〜3倍速く出力を生成します。

基盤モデルの公開日は2026年11月4日で、今回のBedrockへの導入に先立つものでした。K3.1 ProはKimi K3に追加学習を施したバージョンで、3Tクラスのオープンウェイトアーキテクチャとコンテキストウィンドウを維持しつつ、追加学習に大幅に多くの計算リソースを使用しています。Moonshot AIによると、この追加学習は長期にわたるエージェント型の作業への対応と事実誤認の削減を目的としており、財務モデリング、オフィス文書、ゲームエンジンや3Dシーン、コンピューター支援設計（CAD）スクリプトのコーディング性能が向上しています。

エージェント型コーディングでは、1つのタスクで、ファイルの読み込み、変更計画の立案、コードの編集、テストの実行、失敗の修正といった処理のために、モデルを何度も順番に呼び出すことがあります。出力トークンの生成速度が上がれば、各ステップの生成にかかる時間を短縮できます。Bedrock上の既存のKimi K3実装は、モデルIDを変更するだけで切り替えられます。新モデルは、同じエンドポイントとAPIを通じて、ツール呼び出し、構造化出力、調整可能な推論、画像入力、ストリーミングに対応します。またAWSは、オープンソースのターミナル型コーディングエージェントであるOpenCodeを、Chat CompletionsとBedrock APIキーを使って接続する方法も紹介しています。

アクセスとデータの保管場所

開発者は、OpenAI互換のChat Completions APIとResponses API、またはBedrockのConverse APIとInvoke APIを通じてモデルを呼び出せます。AWSはChat Completionsを推奨しています。グローバルなクロスリージョン推論プロファイルでは、対応する商用AWSリージョンのいずれかにリクエストがルーティングされます。一方、米国とインドのプロファイルでは、データ保管場所の要件に応じて、ルーティング先をそれぞれの地域内に限定します。インドからのリクエストは、ムンバイとハイデラバードの間でルーティングされます。

AWSによると、推論データはAWSのデータ境界内にとどまり、Moonshot AIと共有されず、モデルの学習にも使用されません。推論リクエストでは常にゼロデータ保持が有効になっており、推論中にAWSの運用担当者がプロンプトや生成結果を閲覧することはできません。

料金とコスト管理

標準ティアの料金は、ルーティングプロファイルによって異なります。以下の料金はすべて、100万トークンあたりの金額です。

Bedrockの料金ページでは、先行モデルのKimi K3について、グローバル標準推論で入力トークン100万あたり3.00ドル、出力トークン100万あたり15.00ドルと記載されています。そのため、新モデルは入力・出力ともに料金が高くなりますが、グローバルのキャッシュ読み込み料金は、K3のトークン100万あたり0.30ドルより低く設定されています。

Flexでは、応答時間が長くなる可能性と引き換えに、標準料金の半額で推論を利用できます。一方、Priorityには75%の割増料金がかかります。ティアはリクエストごとに選択できるため、通常のトラフィックにはStandard、低遅延が不可欠な呼び出しにはPriority、評価、要約、バックグラウンドでのエージェント処理にはFlexを使うといった使い分けが可能です。

明示的なプロンプトキャッシュは、システム指示、ツール定義、リポジトリの規約など、繰り返し使われるコンテキストに対応します。各ブレークポイントの前には、少なくとも256トークン分の安定した内容が必要です。この機能はResponses、Chat Completions、Invokeで利用できますが、Converseには対応していません。キャッシュ読み込みは割引料金が適用され、入力トークン毎分の上限にも算入されません。一方、書き込み料金は通常の入力料金より高くなります。

推論設定と互換性の制限

モデルカードでは、推論設定としてnone、low、medium、high、xhigh、maxが用意されており、デフォルトはmaxです。noneに設定すると、そのリクエストでは推論が無効になります。推論の強度を下げると、タスクの性能と引き換えに、レイテンシとトークン消費を抑えられる場合があります。そのため、コスト重視のワークロードではデフォルト設定が重要な検討事項となります。

Converseには、明示的なキャッシュ機能がないこと以外にも制約があります。複数ターンのリクエストに前のターンの推論内容が含まれていると、内部サーバーエラーが発生する場合があり、デフォルト設定のLangChainやStrands Agentsなどのフレームワークにも影響します。AWSは、Converseで複数ターンのリクエストを行う際に、以前の推論ブロックを削除することを推奨しています。また、Converseは添付されたPDFやHTML文書を受け付けません。このモデルでは、Bedrockは動画入力にも対応していません。

出力トークン1つにつき、bedrock-runtimeエンドポイントで適用されるアカウントのクォータを10トークン分消費します。これは、トークンごとの料金とは別に考慮すべき容量上の制約です。

既存のK3ユーザーは、コードをほとんど変更せずに切り替えられますが、運用上のトレードオフは互換性だけにとどまりません。期待できる利点は、連続して行われるエージェント処理の完了が速くなることです。一方で、入力・出力料金の上昇、推論に伴うトークン消費、クォータの消費が負担となります。AWSが提供するFlex、キャッシュ、推論強度の設定を使うことで、こうした要件のバランスを調整できます。