Cloudflare、70+ modelsを1つのAI Gateway APIに集約

CloudflareはAI Gatewayを単なるproxyからagent向けのinference layerへ押し上げた。開発者は1つのAPI経路で70+ models、12+ providersにアクセスできる。agent workflowはもはや単一modelで完結しにくい。customer support agentなら安いmodelで分類し、強いreasoning modelで計画し、小型modelで個別taskを実行することがある。1つのtaskに10回のinference callが連なるなら、latency、provider outage、cost reportingはbackendの細部ではなく製品体験そのものになる。

Cloudflareの4月16日のsource postによると、Workersの開発者はWorkers AIで使ってきたAI.run() bindingからthird-party modelsを呼べるようになった。Cloudflare-hosted modelからOpenAI、Anthropic、Alibaba Cloud、Google、Runway、Vidu、Recraft、MiniMax、InWorld、AssemblyAI、Pixverse、Bytedanceなどのmodelへ切り替える操作は、code上では1行の変更で済む。Workers以外の環境向けREST APIは今後数週間で提供予定だ。

今回の要点はmodel catalogの大きさだけではない。CloudflareはAI GatewayでproviderをまたいだAI spendを監視し、request metadataを付けてcustomer別やworkflow別のcostを追えるとしている。さらに同じmodelが複数providerから利用できる場合、障害時に別providerへ自動routingする。streaming inferenceではgatewayがresponseをbufferし、長時間動くagentが切断後に再接続しても、同じoutput tokensに二重課金されにくい構成を狙う。

Replicateとの距離も縮まる。CloudflareはReplicate modelsをAI Gatewayへ取り込み、Replicate上でhostされていたmodelをCloudflare infrastructureへ移していく方針を示した。custom model、managed open model、commercial APIを同時に使うteamにとって、これはagent appの下にあるorchestration layerをCloudflareが握りにいく動きだ。

注目点は新しい種類のlock-inだ。統合catalogはprovider変更を楽にするが、routing、observability、credits、reliability policyはCloudflare側に集まる。宣言どおりに安定すれば、production agentsの実用的なcontrol planeになり得る。逆にgateway自体が不安定なら、model independenceは絵に描いた利点で終わる。