エージェントを強化：Workers AIが大規模モデルの実行を開始、まずはKimi K2.5から | Cloudflare

claudejamodel: claude-sonnet-4-20250514

エージェントを支える力：Workers AIが大規模モデルの実行を開始、Kimi K2.5から始動

2026-03-19
Michelle Chen、Kevin Flansburg、Ashish Datta、Kevin Jain
7分で読める

Cloudflareをエージェントの構築とデプロイに最適な場所にしています。しかし、信頼性の高いエージェントはプロンプトだけでは構築できません。堅牢で協調的な基盤プリミティブのインフラストラクチャが必要です。Cloudflareでは、これらのプリミティブを何年もかけて構築してきました：状態の永続化のためのDurable Objects、長時間実行タスクのためのWorkflows、安全な実行のためのDynamic WorkersやSandboxコンテナなどです。Agents SDKのような強力な抽象化は、CloudflareのDeveloper Platform上でエージェントを構築するのに役立つよう設計されています。

しかし、これらのプリミティブは実行環境のみを提供していました。エージェントには、それを動かすことができるモデルが依然として必要でした。

本日より、Workers AIは正式に大規模モデルの分野に参入します。AI推論プラットフォームで最先端のオープンソースモデルを提供開始します。まず、Moonshot AIのKimi K2.5モデルをWorkers AIでリリースします。完全な256kコンテキストウィンドウと、マルチターンツール呼び出し、ビジョン入力、構造化出力のサポートにより、Kimi K2.5モデルはあらゆる種類のエージェントタスクに優れています。

最先端規模のモデルをCloudflare Developer Platformに直接導入することで、単一の統合プラットフォーム上でエージェントのライフサイクル全体を実行することが可能になります。エージェントの心臓部は、それを動かすAIモデルであり、そのモデルは高い推論能力と大きなコンテキストウィンドウを持つ、スマートなものである必要があります。Workers AIは今、そのようなモデルを実行します。

価格性能の最適点

私たちは過去数週間、内部開発ツールのエンジンとしてKimi K2.5をテストしてきました。OpenCode環境内で、Cloudflareのエンジニアは日常的にKimiをエージェントコーディングタスクのメインドライバーとして使用しています。また、自動コードレビューパイプラインにもモデルを統合しており、CloudflareのGitHubリポジトリで公開コードレビューエージェントのBonkを通じて実際の動作を確認できます。

本番環境では、このモデルは品質を犠牲にすることなく、より大きなプロプライエタリモデルに対する高速で効率的な代替手段であることが証明されています。Kimi K2.5の提供は実験として始まりましたが、モデルの性能とコスト効率を検証した後、すぐに重要なものとなりました。

例として：Cloudflareのコードベースのセキュリティレビューを行うエージェントがあります。このエージェントは1日あたり70億トークン以上を処理し、Kimiを使用して、単一のコードベースで15以上の確認済み問題を発見しました。大まかな計算をすると、このエージェントを中級のプロプライエタリモデルで実行していた場合、この単一のユースケース、単一のコードベースに対して年間240万ドルを費やしていたでしょう。このエージェントをKimi K2.5で実行するコストはその一部に過ぎませんでした：Workers AIに切り替えるだけで、コストを77%削減しました。

AI採用が増加するにつれ、エンジニアリングチームの運営方法だけでなく、個人の運営方法にも根本的な変化が見られます。OpenClawのような個人エージェントを24時間365日稼働させることがますます一般的になっています。推論の量は急激に増加しています。

個人およびコーディングエージェントのこの新たな台頭は、コストがもはや二次的な懸念ではなく、スケーリングの主要な障壁であることを意味します。すべての従業員が1時間あたり数十万トークンを処理する複数のエージェントを持つ場合、プロプライエタリモデルの計算は成り立たなくなります。企業は、プロプライエタリな価格タグなしに最先端レベルの推論を提供するオープンソースモデルへの移行を検討するでしょう。Workers AIは、個人エージェント用のサーバーレスエンドポイントから組織全体の自律エージェントを動かす専用インスタンスまで、すべてを提供してこの移行を促進するためにここにあります。

大規模モデル推論スタック

Workers AIは2年前のローンチ以来、LLMを含むモデルを提供してきましたが、これまでは小さなモデルを優先してきました。その理由の一部は、しばらくの間、オープンソースLLMが最先端モデルラボのモデルに大きく遅れをとっていたことです。これはKimi K2.5のようなモデルで変わりましたが、この種の非常に大きなLLMを提供するために、推論スタックに変更を加える必要がありました。

Kimiのようなモデルをサポートするために舞台裏で行われていることの一部を共有したいと思います。私たちは、独自のInfire推論エンジン上に構築されたKimi K2.5のモデル提供方法を最適化するためのカスタムカーネルに取り組んできました。カスタムカーネルはモデルの性能とGPU利用率を向上させ、モデルをそのまま実行するだけでは得られない利益を解放します。

大規模モデルを提供するために活用できる複数の技術とハードウェア構成もあります。開発者は通常、モデル性能を最適化するためにデータ、テンソル、エキスパート並列化技術の組み合わせを使用します。分離プリフィルのような戦略も重要で、より良いスループットやより高いGPU利用率を得るために、プリフィルと生成段階を異なるマシンに分離します。

これらの技術を実装し、推論スタックに組み込むには、正しく行うための多くの専門的な経験が必要です。Workers AIは既に、Kimi K2.5で優れたスループットを実現するための提供技術の実験を行っています。これらの多くは、オープンソースモデルを自己ホストする際にはすぐには利用できません。Workers AIのようなプラットフォームを使用する利点は、ホストに必要な最適化を行うために機械学習エンジニア、DevOpsエキスパート、サイト信頼性エンジニアである必要がないことです：私たちが既に困難な部分を行っており、あなたはAPIを呼び出すだけで済みます。

モデルを超えて — エージェントワークロードのためのプラットフォーム改善

このローンチと併せて、プラットフォームも改善し、より良いエージェントを構築するのに役立つ複数の新機能をリリースしています。

プレフィックスキャッシュとキャッシュされたトークンの表示

エージェントを扱う際、コンテキストの一部として大量の入力トークンを送信する可能性があります：これには詳細なシステムプロンプト、ツール定義、MCPサーバーツール、または完全なコードベースが含まれる可能性があります。入力はモデルコンテキストウィンドウと同じ大きさになる可能性があるため、理論的には、ほぼ256k入力トークンでリクエストを送信することができます。それは多くのトークンです。

LLMがリクエストを処理する際、リクエストは2つの段階に分解されます：プリフィル段階は入力トークンを処理し、出力段階は出力トークンを生成します。これらの段階は通常順次的で、出力トークンを生成する前に入力トークンを完全に処理する必要があります。これは、モデルがプリフィルを行っている間、GPUが完全に利用されない場合があることを意味します。

マルチターン会話では、新しいプロンプトを送信する際、クライアントはセッションからの以前のすべてのプロンプト、ツール、コンテキストもモデルに送信します。連続するリクエスト間のデルタは通常、わずか数行の新しい入力です；他のすべてのコンテキストは、以前のリクエスト中に既にプリフィル段階を通過しています。

ここでプレフィックスキャッシュが役立ちます。リクエスト全体でプリフィルを行う代わりに、以前のリクエストからの入力テンソルをキャッシュし、新しい入力トークンでのみプリフィルを行うことができます。これにより、プリフィル段階から多くの時間と計算を節約でき、より高速なTime to First Token（TTFT）とより高いTokens Per Second（TPS）スループットを実現できます。プリフィルでブロックされることがないためです。

Workers AIは常にプレフィックスキャッシュを行ってきましたが、現在はキャッシュされたトークンを使用メトリックとして表示し、入力トークンと比較してキャッシュされたトークンに割引を提供しています。（価格はモデルページで確認できます。）また、より高いプレフィックスキャッシュヒット率を活用してコストを削減するための新しい技術もあります。

より高いキャッシュヒット率のための新しいセッションアフィニティヘッダー

同じモデルインスタンスにルーティングし、プレフィックスキャッシュを活用するために、新しいx-session-affinityヘッダーを使用します。このヘッダーを送信すると、キャッシュヒット率が向上し、より多くのキャッシュされたトークンと、その結果としてより高速なTTFT、TPS、より低い推論コストにつながります。

セッションまたはエージェントごとに一意の文字列で、以下のように新しいヘッダーを渡すことができます。OpenCodeのような一部のクライアントは、これを自動的にすぐに実装します。Agents SDKスターターも、これを行うための配線を既に設定しています。

curl -X POST \
  "https://api.cloudflare.com/client/v4/accounts/{ACCOUNT_ID}/ai/run/@cf/moonshotai/kimi-k2.5" \
  -H "Authorization: Bearer {API_TOKEN}" \
  -H "Content-Type: application/json" \
  -H "x-session-affinity: ses_12345678" \
  -d '{
    "messages": [
      {
        "role": "system",
        "content": "You are a helpful assistant."
      },
      {
        "role": "user",
        "content": "What is prefix caching and why does it matter?"
      }
    ],
    "max_tokens": 2400,
    "stream": true
  }'

再設計された非同期API

サーバーレス推論は本当に困難です。トークンごとの支払いビジネスモデルでは、リクエストを処理するために完全なGPUに支払う必要がないため、単一リクエストベースではより安価です。しかし、トレードオフがあります：他の人のトラフィックと容量制約に対処する必要があり、リクエストが処理されるという厳密な保証はありません。これはWorkers AIに固有のものではありません — 過負荷プロバイダーとサービス中断の頻繁なニュース報告を考えると、サーバーレスモデルプロバイダー全体で明らかにそうです。

私たちは常にリクエストを処理するよう努力し、組み込みの自動スケーリングと再バランシングを構築していますが、これを困難にするハードな制限（ハードウェアなど）があります。

同期レート制限を超えるリクエスト量については、非同期で完了する推論のバッチを送信できます。改良された非同期APIを導入しており、これは非同期ユースケースでは、Out of Capacityエラーに遭遇することがなく、推論がある時点で確実に実行されることを意味します。

私たちの非同期APIは、バッチAPIよりもフレックス処理のように見え、モデルインスタンスに余裕がある限り、非同期キューのリクエストを処理します。内部テストでは、非同期リクエストは通常5分以内に実行されますが、これはライブトラフィックの状況によって異なります。Kimiを一般に公開する際、それに応じてスケーリングを調整しますが、非同期APIは持続的なワークフローで容量エラーに遭遇しないことを確実にする最良の方法です。

これは、コードスキャニングエージェントや研究エージェントなど、リアルタイムでないユースケースに最適です。

Workers AIには以前から非同期APIがありましたが、最近システムの内部を改良しました。現在は、従来のプッシュベースシステムに対してプルベースシステムに依存しており、容量ができ次第、キューに入れられたリクエストをプルできます。また、非同期リクエストのスループットを調整するためのより良いコントロールを追加し、GPU利用率をリアルタイムで監視し、利用率が低い時に非同期リクエストをプルすることで、重要な同期リクエストが優先されながら、非同期リクエストも効率的に処理されます。

非同期APIを使用するには、以下のようにリクエストを送信します。また、ポーリングの代わりに推論が完了したことを知ることができるよう、イベント通知を設定する方法もあります。

// (1.) キューにリクエストをプッシュ
// queueRequest: true を渡す
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  "requests": [{
    "messages": [{
      "role": "user",
      "content": "Tell me a joke"
    }]
  }, {
    "messages": [{
      "role": "user",
      "content": "Explain the Pythagoras theorem"
    }]
  },
  ...{/* バッチでより多くのリクエストを追加 */}
  ];
}, {
  queueRequest: true,
});

// (2.) リクエストIDを取得
let request_id;
if(res && res.request_id){
  request_id = res.request_id;
}

// (3.) ステータスをポーリング
let res = await env.AI.run("@cf/moonshotai/kimi-k2.5", {
  request_id: request_id
});

if(res && res.status === "queued" || res.status === "running") {
  // 再度ポーリングして再試行
  ...
} else return Response.json(res); // これは最終的な完了レスポンスを含む

今日から試してみる

今日からWorkers AIでKimi K2.5を始めましょう。開発者ドキュメントを読んで詳細を確認できます

Powering the agents: Workers AI now runs large models, starting with Kimi K2.5

要約

Summary

Key Points

翻訳