Vercelがついに追いついた

ソフトウェア開発・プログラミング
この記事は約62分で読めます。

この動画は、Vercelが長らく待ち望まれていた重要な機能群を一挙にリリースしたことを解説する内容である。特にActive CPU課金、コードサンドボックス機能、キューシステム、Botプロテクション、AIゲートウェイなど、AI時代の開発者ニーズに応える機能が中心となっている。話者のTheoは自身のT3 chatサービスの運営経験を交えながら、これらの新機能がいかに開発者の課題を解決し、コスト削減と開発体験の向上をもたらすかを詳細に分析している。

Vercel Finally Caught Up
Vercel just shipped. A lot. Queues, better pricing, captchas, and more. This is a big one...Thank you WorkOS for sponsor...
www.youtube.com

Vercelが遂に大型アップデートを実施

実際に起こりました。Vercelが遂に出荷したのです。Vercelが一度にこれほど多くの機能をリリースしたのは何年ぶりかという感じですね。ここ数年間、直近の2回のNext.jsカンファレンスは、NextとVercel両方にとって比較的新機能が少ないものでした。

しかし今日、それが変わりました。彼らは私が個人的に永遠に待ち続けていた大量の機能をリリースしたのです。新しい料金モデルからキュー機能、ユーザーから隔離されたサンドボックス環境でコードを実行する方法、さらには適切なキャプチャ処理まで、私がしばらく必要としていた機能がこれほど大量に出てきたのは驚きです。

まるで彼らが私のTwitterを見て、最近私が悩んでいたすべての項目のチェックボックスを埋めてくれたかのようです。

とはいえ、Vercelは長い間私にお金を払ってくれていません。実際はその逆で、特にT3 chatの成功により、最近は彼らに多額のお金を支払っています。今日の費用は誰かが負担しなければなりませんが、正直なところ、それは彼らではありえません。

まずは今日のスポンサーからの簡単なメッセージをお聞きして、その後Verselが出荷したすべてについて私の考えを詳しく説明します。

Work OSによる企業認証の解決

AIによる最も大きな変化の一つは、大企業が小さなチームや会社のツールを採用する意欲です。T3 Chatのような私の小さなビジネスが、はるかに大きな企業からの関心を得ているのを見るのは驚きです。

しかし、正しく行うのが困難な重要なことが一つあります。いいえ、AIはこの問題を解決してくれません。これらの大企業が使用し、採用し、システムに統合することを望むような方法でOAuthを設定することは、最悪の敵にも願わないような作業です。

だからこそ、今日のスポンサーであるWork OSにとても興奮しているのです。彼らは、アプリケーション、そして最も重要なのは認証を企業採用に対応させることを大幅に簡単にしました。

私の言葉を信じることもできますし、CursorからOpenAI、Vercel、Carta、Vantaなど、すでに使用しているソフトウェアの企業の膨大な数が、実際に移行したことを見ることもできます。Cursorダッシュボードを開いてWork OSのようなOAuthサインインを見ると、いつも少し微笑んでしまいます。彼らが私たちが毎日使っているのと同じツールを使っているのを知るのは素晴らしいことです。

GMOとWork OSのようなプラットフォームについて個人的に話をしたことがありますが、彼は本当に早い段階で、もっと早く採用しなかったことを後悔していると言いました。「Work OSともっと早くパートナーシップを組んでいれば、さらに多くのビジネスができたと思います。これは信じられないほど好評でした。」私も完全に同感です。

彼らは、これらのITチームが統合するための企業対応と、フルスタックTypeScript開発者である私たちにとって実際に使いやすいものとの素晴らしいバランスを見つけました。彼らがこのバランスを見つけたのは素晴らしく、そのためにますます多くの人々が採用しているのを見ています。

OAuthについて考えるのに疲れて、ただ出荷する準備ができている方は、soyv.link/workosで今日Work OSをチェックしてください。

新機能の概要

それでは詳しく見ていきましょう。軌道に乗るために、彼らが変更した項目の簡単な概要を説明します。

私が個人的に最も興奮しているのはActive CPU課金です。これについて話すのが本当に楽しみで、特になぜそれが重要なのかについてです。

AIが生成したコード、またはより重要なのはユーザーが提出したコードに対するコード実行のサンドボックス機能を追加しました。

ついにキュー機能が実装されました。

そして、実際に非常に魅力的に見えるキャプチャキラーソリューションがあります。彼らがキャプチャについて私が不満を言ってきたことから、すべての正しい教訓を学んだようです。私のキャプチャ動画をまだ見ていない方は、偏見はありますが私が作ったからです、でも今まで作った中で最高の動画の一つだと思うので、ぜひチェックしてください。サービスでキャプチャとレート制限を適切に設定する方法について、非常に実用的で適用可能な情報を提供しています。

また、AIゲートウェイも正式にリリースしました。これはOpen Routerのような代替手段です。実際かなり魅力的に見えます。これについても詳しく説明します。

Active CPU課金の革命

Active CPU課金から始めましょう。これについて本当に興奮しています。繰り返しになりますが、これが私のコストを大幅に節約してくれるので、私は偏見があります。

これを理解するために、サーバーがどのように構築されているかを理解する必要があります。1つのサーバーがあり、月額10ドルかかるとしましょう。このサーバーは単一のサーバーです。ユーザーが0人でも、1,000人でも、100万人でも、固定料金は月額10ドルです。

しかし、このサーバーが同時に最大500ユーザーしか処理できない場合はどうでしょうか？その場合、より多くのサーバーを立ち上げる必要があります。月全体でそれらを稼働させ続ける必要があるかもしれませんし、動的にスピンアップ/ダウンさせるかもしれません。

そうすると、私たちが皆見てきて、私がよく冗談にしてきた素晴らしいKubernetesの地獄に陥ることになります。より多くのサーバーをスピンアップし、それらをスピンダウンすることを忘れずに、スピンアップを待ち、その時間にトラフィックを失う可能性があります。楽しくありません。

だからこそ、世界はサーバーレスモデルに向かい始めました。特に、ほとんどのWebアプリが持つ短期的なコンピュート需要に対してです。なぜなら、ほとんどのユーザーは多くのリクエストを作成するか、時には1つのリクエストだけを作成し、大量のDBを実行してから、しばらく何もしないからです。

サーバーレスのアイデアは、サーバーがないということではありません。明らかにあなたのコードはサーバー上で動作します。要点は、実際に持っているサーバーの設定、つまりプロビジョニングされたサーバーの数が、現在リクエストを作成しているユーザーの数を直接反映しているということです。

従来のサーバーレスの課題

以前、世界の動作方法は、1つのサーバーがあり、すべてのリクエストがそこに送られるというものでした。さまざまなユーザーからのさまざまなリクエストが同じサーバーに送られ、必要な時間だけかかってから、反対側のユーザーに応答を送信します。

しかし、このサーバーが処理できる以上のリクエストが必要になった場合、それが問題になります。手動でサーバーをスピンアップし、準備ができるまでこれらのリクエストを保持するか、他の何かを行う必要がありました。

サーバーレスは、この動的を完全に反転させることを目標としていました。月額10ドルのサーバーではなく、ギガバイト時間で課金されるのが通常の表現です。ギガバイト時間とは、何ギガバイトのRAMを何時間使用するかということです。

これで、これらの各リクエストは独自のサーバーを持つのではなく、それぞれが独自の個別のインスタンスを持ち、リクエストが必要とする限り生存し、その後すぐに死にます。これらの各リクエストが非常に短時間で解決される場合、100から200ミリ秒程度でDBリクエストを完了し、HTMLを生成してユーザーに送信するなら、これは非常に理にかなっています。

これらの各リクエストが100ミリ秒かかると考えると、それを縮小すれば、このモデルは非常に理にかなっています。そして、ますます多くのコンピュートがこの方法で動作するようになったため、このようなものを多く構築した人として言えば、このモデルは実際にWebアプリケーション、クラウドアプリ、eコマースなどに対して本当に、本当に良いものでした。

ユーザーに十分なサーバーを用意することを心配する必要がなく、ユーザーは非常に短いリクエストを作成するため、これらのミリ秒時間をすべて合計しても、そんなに多くのお金はかかりません。したがって、ダウンタイム中にサーバーをプロビジョニングしておく必要がないため、多くの場合、十分に大きなサーバーをプロビジョニングするよりもかなり安くなります。リクエストに費やされた時間にのみ支払うのです。

AI時代の新しい課題

問題は何でしょうか？これら4つのリクエストが、サインアップ時に使用したメールアドレスやT3 chatでのチャット履歴など、ユーザーデータを要求している場合を考えてみましょう。これらはすべて本当に迅速に発生します。それはすべて良いです。

しかし、OpenAIからの応答を生成し始めるとどうなるでしょうか？これは100ミリ秒ではなく、20秒になります。

多くのユーザーが常にこれを行っていることを想像してください。今度は100ミリ秒×4を合計するのではなく、20秒を合計することになり、これらの各リクエストに対して個別のサーバーを実行することは、考慮しなければならない2番目の次元があるため、突然うまくいかなくなります。

2つの軸を描いてみましょう。軸1は持続時間 – これはリクエストの実行にかかる時間です。軸2は強度 – これはこのリクエスト中に実際に使用されるCPUの量です。

Next.jsアプリのような場合、DBリクエストを作成するときはそれほど多くのCPUを使用しませんが、そのJSONをHTMLに変換してユーザーに送信するときは、かなりのCPUを使用します。または、T3 chatの部分的な画像生成のために追加しているような、PNGをAVIFなどに再エンコードする画像エンコーディングのようなことを行っている場合、それらはかなりのCPUを必要とし、DBレスポンスを待っているだけの数千のユーザーよりも、サーバー上で画像を再エンコードしている10人のユーザーの方がはるかに多くのコンピュートを使用することを意味します。

したがって、実際のCPU使用量を持続時間に対して注意を払うことが重要です。

新しいワークロードの出現

これが異なるワークロードが興味深くなる場所です。Next.jsアプリのレンダリングのようなものは、中程度の使用量、低持続時間と言えるでしょう。SSRは中程度の使用量、低持続時間です。

画像再エンコーディング、画像エンコーディングのようなものは高使用量、中持続時間です。

そして興味深いのは、ここの角に高持続時間、低使用量のエリアがあることです。これは本当に珍しいことでした。しばらくの間、必要がなかったため、この角にはあまり革新がありませんでした。

歴史的に目標は、リクエストの持続時間をどのように短縮するかでした。Vercelのような企業が投入したほぼすべての作業、これらのデータベース企業が投入したすべての作業は、物事をより速く発生させる方法、ユーザーがWeb上でより速く、より良い体験を得ることができるように、持続時間チェーンをどのように下げるかに焦点を当てています。

問題は、私が少しほのめかしてきた、この角に本当によく合う新しいワークロードがあることです：LM生成リクエストです。

明確にしておきますが、私は入力を受け取って新しいトークンを作成してユーザーに送信するモデルの実際の実行について言っているのではありません。私が指しているのは、ユーザーのリクエストを受け取り、メタデータや記憶などを添付し、それをサービスのAPIキーでOpenAI APIに送信し、そのストリームを受信してユーザーにストリーミングするエンドポイントです。

これは本当に高い持続時間と非常に低いCPUコストになってしまい、その比率は非常に奇妙です。ほとんどのこれらのサービスが構築されたものではありません。

ただし、Cloudflareは例外です。Cloudflareのインフラ、特にCloudflare workerプロダクトは、実際にCPUパフォーマンスが非常に低いのです。

Cloudflareとの比較

特定のサーバーレンダリングタスクを取って、VercelやLambdaのnodeで実行し、次に全く同じコードをworkersで実行すると、CPUを測定している場合、実際に応答を得るのに2〜4倍の時間がかかります。

何らかのJSONを取ってReactとNext.jsでHTMLに変換する場合、CloudflareではCPUが弱く、仮想化レイヤーが異なるため、4倍の時間がかかります。対して、Vercel、Lambda、または従来のサーバーでは、専用のCPU割り当てと実際のカーネル上で実際のLinuxが実際のnodeを実行している場合、それは大幅に高速になります。

Lambdaのような場合、必要に応じてより多くのコンピュートを持つようにプロビジョニングを上げることもできます。

これが興味深くなる場所です。なぜなら、Cloudflareのインフラは歴史的にSSRワークロードには悪かったのですが、私が世界で最も高度なswitch文と呼んでいるものには本当に良かったからです。

効果的にCloudflareを使ってリクエストを解決し、正しい方向に向け、基本的な変更を加えるなら、Cloudflareは本当に良かったのです。Cloudflareのモデルを特別にしているものの一つは、ネットCPU課金です。

ネットCPU課金の優位性

再び描き直しましょう。なぜなら、気にする数字が2つあるからです。持続時間と実際のCPU使用量があります。

ユーザーがメタデータを要求している場合を考えてみましょう。データベースが十分に高速であれば、このリクエストはおそらく100ミリ秒ほどで非常に高速になるでしょう。このリクエストは、CPU使用量の観点から、そんなに多くを必要としないでしょう。それを簡単にするために、ミリ秒でも測定してみましょう。10ミリ秒のネットCPUだとしましょう。

それに応じて縮小すると、実際にはもう少し少なくなります。スケールに合わせてこれを作ると、アイデアは伝わります。

100ミリ秒のウォールクロック時間の要求が、そのほとんどの時間をDBを待っているのに費やしている場合、そんなに多くのCPUを使用することはありません。これを文字通り拡張して、もう少し明確にしましょう。赤は課金されている時、空洞は課金されていない時です。なぜなら他の何かが起こっているからです。

ここのその小さな赤いセクションで、私たちはDBからリクエストしています。それは非常に短時間です。その後、DB応答を85ミリ秒ほど待ちます。最後に、DB応答を取って、JSONまたは任意の形式で再エンコードし、ユーザーに送信するための少しのコンピュートがあります。

この100ミリ秒のクロック時間で、私たちはおそらく最大でも15ミリ秒のCPUを実際に実行しています。

Fluid Computeの改善

この箱の内部にいて、どのくらいのCPU使用率を使用しているかを見ると、約100%、次に5%未満、おそらく箱で起こっている他のことの量に応じて1〜0、その後短時間100%に戻り、データがユーザーにダウンロードされるのを見るでしょう。

過去に何度もカバーしたVercelのFluid Computeを本当にクールにしたのは、これが起こったときに効果的に他の人のリクエストを詰め込むことができたことです。

ここでこのCPUが何もしていないので、別のユーザーのリクエストを詰め込みます。CPUを使用して作業を行い、これが解決されるのを待っている間に、別のものと別のものを持つことができます。今、この全体のウィンドウに対して課金されています。

これが150ミリ秒の総コンピュートになるとしましょう。今、400ミリ秒のリクエストを150ミリ秒のウィンドウに詰め込みました。400ミリ秒に対して課金されるのではなく、150ミリ秒に対して課金されます。それは本当にクールです。

もっとクールなことを知っていますか？私たちが言ったように、これらの各々が15になることを覚えていますか？少し丸めて、これらの各々が10だとしましょう。つまり、20ミリ秒のコンピュートで150ミリ秒の合計です。20 40 60 80。これらのすべてを取ると、これらの各々が約10であることを覚えておいてください、これは私たちが最終的に支払ったものよりもかなり短いことがわかります。実際にははるかに半分未満です。実際、この場合、技術的には少し半分以上だと思います。

要点は、ここに何も起こらなかった多くの死んだエリアがあるためにそれが起こるということです。青色を使ってそれらの死んだエリアを示します。ここからここまで何も起こらなかった、そこにも別の死んだゾーンがあります。

AI推論の課題

これらの死んだエリアにはまだ課金されています。なぜなら、これらのリクエストが完了するのを待っているサーバーをスピンアップしておく必要があるからです。

データベースから何かを取得するような100ミリ秒のリクエストを見ている場合、これはかなり悪く見えます。ユーザーページを要求するような、もう少し現実的なサーバーレンダリングロードでは、最後により多くのCPUが必要になる場合があります。

150ミリ秒に変更し、データベースからの応答を得た後に実際にページをレンダリングするために多くのコンピュートが必要だとします。このようなものは、実際の作業に費やされる時間の割合が非常に高いため、Vercelがfluid computeで持っていたモデルから多くの恩恵を受けるでしょう。

しかし、私たちが以前に話していたことはどうでしょうか？これらの恐ろしい20秒から時には8分の長いリクエストです。これらがどのくらいのコンピュートを使用していると思いますか？

20秒のウォールクロック生成を取ってみましょう。最初にこの最初のブロックがあり、ユーザーとそのデータを検証しています。ユーザーを検証し、リクエストをOpenAIまたは他のAPIに送信し、その後待機し、待機し続け、待機し続け、最終的に最後近くで完全な応答を得て、それをユーザーに送信します。データベースに永続化するかもしれませんし、取得したトークンを送り返すかもしれません。これは非常に一般的です。

これらの各々は文字通り2サイクルのCPUを取るため、ランダムに散らばった超、超、信じられないほど薄い線がたくさんあり、そこで極小のCPUが使用されます。この20秒のウォールクロック時間で、数秒のCPUを使用していないだけでなく、ミリ秒も使用していません。通常、AI LM生成コールはナノ秒のCPU使用量で測定できます。

20秒のウォールクロック時間のような狂ったものでさえ、100ナノ秒のコンピュートと同じくらい低い可能性があります。

それが問題です。その比率は狂気じみています。リクエストにかかった時間に対してどのくらいのコンピュートが使用されたかを見ると、そこで価格設定が本当に厳しくなります。

Cloudflareのnet CPU課金の優位性

今、この20秒のランタイムがあるため、そのほとんどの間ほとんどCPUを使用していないにもかかわらず、課金されています。

正直な推測では、ますます多くのこれらのAIワークロードがVercelに現れ始めたとき、彼らの平均CPUの使用率とリクエスト中にCPUが利用された割合は、おそらく60から80%から5%未満に下がったでしょう。

私たちのボックスのCPU使用率、特にfluidをオフにした場合のCPU使用率を見ると、ゼロに非常に近いので面白いです。応答を待っているときは、そこに座っていなければならないからです。

fluidで以前に示したことを行い、多くのものを同じラムダリクエストに強制すると、それは役立ちますが、十分ではありません。なぜなら、繰り返しになりますが、CloudflareはネットCPUで課金しているからです。

彼らはこれらの赤いボックスに対してのみ課金しています。CPUが動いているときにのみ課金しています。なぜなら、各開発者のために新しいカーネルをスピンアップする必要がないからです。

Vercelにデプロイしている開発者と私がVercelにデプロイしている開発者である場合、私たちは両方とも独自のコードを持っており、両方ともデプロイしています。fluidでも、一度に複数のことを行うためにnodeを共有する場合でも、それは特定のユーザーの特定のコードバイナリ間でのみ共有されるため、私のラムダが実行されているときにあなたのコードは私のラムダで実行できません。

Cloudflareでは、抽象化はカーネルやfirecrackerやラムダレベルではありません。抽象化はより高いレベル、V8、彼らが構築した実際のエンジンにあります。worker isolateレイヤーにより、基本的にイベントループが共有されることができます。

Cloudflareのイベントループ共有の革新

JavaScriptイベントループのように、リクエストが作成され、関数がキューに入れられ、実行され、データがそのように流れる場合、Cloudflareの動作方法は、効果的にイベントループに何もない場合、準備ができているものがキューに何もない場合、他の誰かが同じインスタンスで実行されている独自のコードに対してリクエストを持っているということです。

Cloudflareのものがとても強力だったのは、彼らのイベントシステムは、あなたのコードが実行されて何もしていないときに、彼らに何のコストもかからないことを意味するからです。なぜなら、同じV8インスタンスが同時に他の人々の独自の別々のコードで他の人々のリクエストを解決できるからです。

ここには4つのオプションがあります：

  • 従来のサーバー
  • リクエストごとに1つのインスタンスのサーバーレス
  • Vercelが行ったfluid compute、1つのnodeが複数のユーザーリクエストを解決できるが、1つのバイナリ、1つのコードしか実行していないもの
  • Cloudflareソリューション、同じボックス上で多くの異なる開発者のコードが同時に実行され、関数呼び出しレベルで抽象化している

価格が大幅に異なると言うとき、私は本当にそう意味しています。ここで見るように、CloudflareはCPU時間、ネットCPUコスト、CPUが実際に呼び出されている時間に対して課金します。これらのリクエストが取る時間がナノ秒やミリ秒で測定され、他のプラットフォームのように秒や分ではないため、100万CPUミリ秒あたり2セントで課金します。

呼び出しあたり最大5分のCPU時間がありますが、それはCPU時間です。実際のリクエストには持続時間の制限がないため、その時間にCPUで何もしていない限り、解決に2日かかってもかまいません。本当にクールです。

Vercelの新しいActive CPU課金

Vercelは最終的にそれに合わせることにしました。これは私にとって興奮することです。なぜなら、実際に彼らとこれについて何度も議論したことがあるからです。なぜなら、FluidでのうちI数字を、サーバーレスでのうちの数字を、Cloudflare workersを使っている友人の数字と比較したところ、コンピュートのコストの面でかなり厳しいギャップがあったからです。

私たちよりも多くの推論を行っていて、コンピュートのために私たちの100分の1のような請求書を持っている人たちを知っています。何千ものリクエストを30秒のウィンドウに詰め込むことができても、代替案がリクエストあたり1ミリ秒で課金されることなら、それは関係ありません。

これらの数字の詳細には立ち入れません。私が知っているものは非常にNDAの下にあるからですが、100倍の差があることをお伝えできます。そして、ここの図を考えれば、その差を見るのはかなり簡単です。

80秒かかるリクエストがあり、これらの80秒リクエストの1つが通常よりも高い5ミリ秒のCPUを使用する場合、最良の場合、約100のものをfluid computeインスタンスに詰め込むことができます。

100リクエスト、80秒、5ミリ秒のCPUに一致する100のリクエストがある場合：

  • 通常のサーバー：サーバーコストを支払うだけ（測定が困難）
  • サーバーレス：80秒×100 = 8,000秒
  • Fluid：すべてを詰め込んで80秒×1 = 80秒（1回の呼び出しのみ）
  • ネットCPU課金：5ミリ秒×100 = 500ミリ秒 = 0.5秒

これは今の実際のダッシュボードからの実際の数字ではありませんが、私の経験から、これは正確で、私が見たものと一致していることをお伝えできます。

ギャップは狂気じみています。なぜなら、これらの推論タスクに使用されるCPUの量は比較的低く、80対5ミリ秒の比率のようなものだからです。これが注意を払うべき数字です。80秒かかるリクエストは、わずか5ミリ秒のCPUを使用できます。

この数字を支払う価値にするためにできることは何もありません。代わりにこの数字に課金する方法を見つける必要があります。Cloudflareと競争したいなら。

そして、これがVercelが今発表したことです。彼らは今、これの代わりにこれに課金するつもりです。そして、それは彼らがどのようにプロビジョニングしているかによって、バックグラウンドで彼らに大金を費やすことになるでしょう。

Vercelの新しいActive CPU価格設定の詳細

Cloudflareがこれに課金できる理由は、その80秒の間に、彼らは同じノード上で他の誰かのコードを実行できるからです。Vercelでは、独自のカーネル、独自のnodeインスタンスを実行しているため、それはできません。私が何もしていないとき、彼らは同じボックスや同じインスタンス上で他の誰かのコードをスピンアップできません。

彼らが何をしたか、どのように実装したかを読んでみましょう。

Active CPU価格設定の導入。もちろん、彼らは独自の名前を付けなければなりませんでした。

Fluid computeは新しいクラスのワークロードに存在します：AI推論、エージェント、MCPサーバー、そして瞬時にスケールする必要があるが、操作の間はしばしばアイドル状態のもの。この「瞬時にスケール」の部分は、トラフィックの急増にとってとても有用ですが、誰かがPRをファイルしたときにプレビューデプロイメントをスピンアップするような反対側にとっても同様に有用です。

そのようにオンデマンドで瞬時にスピンアップ/ダウンできるものは、私のスタックのすべての異なる層にとって非常に有用です。

これらのワークロードは従来の迅速なリクエスト-レスポンスパターンに従いません。繰り返しになりますが、これはVercelが歴史的に最適化してきたものです。データをサーバーに近づける方法、より速くデータをフォーマットしてより少ない時間を生成に費やす方法、コンピュートレイヤーを完全にスキップするためにものをキャッシュする方法、リクエストの解決時間を減らすために何ができるか。

それは初日からVercelの目標でした。それはAIの世界では機能しません。これらは長時間実行される予測不可能なワークロードであり、新しい方法でクラウドリソースを使用します。

Fluidは、関数内同時実行のような最適化により最大85%のコスト削減でチームを支援し、Vercel上のデフォルトのコンピュートモデルにすぐになりました。今日、私たちは新しい価格設定モデルでより効率的でコスト節約を進めています。コードが積極的にCPUを使用しているときにのみCPU料金を支払います。巨大です。

サーバーからサーバーレス、そしてFluidへ

クラウドコンピューティングの初期において、チームは長寿命のサーバーを実行していました。プロビジョニングの管理、スケーリングの処理などを行う必要がありました。

サーバーレスがそれを変えました。インフラ構成を抽象化し、自動スケーリングを導入しました。各リクエストが独自の分離されたインスタンスをトリガーしました。私が言ったとおりです。

ここで、それが大量のコンピュートから始まり、しばらく何もせず、その後終了し、その全時間に対して支払っているのを見ます。

サーバーレスからFluidへ。ここに違いがあります。今度は、それらをすべて1つのFluidノードに詰め込むことができます。以前に85%と言いませんでしたか？今は最大90%と言っています。私の経験では85から90%だったので、私が見た2つの数字の両方がダッシュボードとFluidからのものなので、面白いです。

FluidからActive CPUへ。Fluidはパフォーマンスとコストを改善しましたが、まだ最適化の余地がありました。高い同時実行性があっても、すべての呼び出しが外部リソースを待っていて、コードが積極的に実行されていない瞬間がまだある可能性がありました。

これらのアイドル期間中、関数はメモリに留まり、作業をしないが、それでもCPUコストが発生しています。このようにそれを見ると、CPUが動作している部分にのみ支払いたいのです。

これは実際の使用量と一致します。コンピュートコストは、関数が生きている時間だけでなく、実際の作業とスケールします。

ここで面白いのは、私たちの画像変換のようなものは、ノードがすでに実行されていて、CPUが支払われているため、CPU コスト的には効果的に無料だということです。それを使うかもしれません。

今度は実際にそのコンピュートに対して支払うので、それはより高価に感じられるでしょう。以前は効果的に支払っていませんでしたが、私たちのワークロードのほとんどは時間の大部分でCPUを使用していないため、私たちの請求書は全体的にはるかに、はるかに安くなるでしょう。

Active CPU価格設定モデルの詳細

Active CPU価格設定モデル。Fluid computeは現在、3つの主要なメトリックに基づいて課金されます：

Active CPU：コードが仮想CPU上で積極的に実行しているコンピュート時間を反映し、ミリ秒で測定され、割り当てられたvCPUの数にそれらが積極的に使用されている時間を掛けて計算されます。時間あたり0.128ドルから開始します。

数学を簡単に計算してみましょう。私の特徴はご存知でしょう、私は具体的な数字を知りたいのです。Verselはこれを時間あたりで表示しています。ミリ秒では、100万CPUミリ秒あたり2セントです。これらの数字が互換性がないため、面倒な計算になります。これは両当事者にとって間違いなく意図的です。

1時間に何ミリ秒あるか…それは360万ミリ秒なので、3.6倍多いことになります。0.02×3.6…約7.2セントになります。

つまり、Cloudflareは1時間のコンピュートに対して7.2セントを課金しています。他のCloudflareの数字は削除します。時間での課金の方が少し理にかなっていると思うからです。

Cloudflareはまだ時間あたり安いですが、そんなに大きなギャップではありません。50%未満の差です。

ただし、呼び出しあたりの課金もあるので、それについても説明します。Vercelにもあると思うからです。

プロビジョンメモリも課金されます。これは関数が実行中に生きているために必要なメモリをカバーし、ギガバイト時間で測定され、Active CPUのおかげで10%未満のはるかに低いレートで課金されます。Fluidの複数の同時実行間でメモリを再利用する能力のおかげです。ギガバイト時間あたり1セントから開始します。

Cloudflareはこれに課金しません。公平に言うと、Cloudflareはメモリに非常に厳しい制限があります。workersは実行できるJSの量に非常に制限があります – 実際のバイナリで10メガバイトで、JavaScriptには多く聞こえますが、特にサーバーサイドでスケールでは、そうではありません。

各workerは最大128メガバイトのメモリを使用できます。比較的に言えば、それは非常に低いです。そのためにアーキテクチャを組み、nodeAPIや重いものを使わなければ、それで十分ですが、そんなに多くのメモリではありません。

とはいえ、それはリクエストあたり128メガバイトのメモリで、Vercelでは、そのnodeに送られるすべてのリクエスト間でnodeが持っているRAMの量です。メモリの特性によりますが、それは10%未満だと言っているので、Vercelの請求書に10%を追加します。

リクエストコストについては、従来のサーバーレスでは、これらのプラットフォームで呼び出しに対して課金されるため、Vercelはまだこれを課金していると言っています。それは全体的な課金の一部のままです。100万リクエストあたり60セント。

Vercel：100万リクエストあたり60セント Cloudflare：追加100万あたり30セント

これらの数字を比較すると、Vercelは最悪の場合約2倍高いと推測します。それは最初から恐ろしく聞こえます。「VercelからCloudflareに切り替えてコストを半分にしよう」と言うように。

おそらく言うべきではない数字を投下しましょう。私たちのGeminiの請求書と私たちのVercelの請求書の比率は、今現在、これらの変更が行われる前で、1:40です。私たちのGeminiの請求書は、Verselのコンピュート請求書の40倍高いです。他のすべての推論を追加すると、180倍に近くなります。これはfluid computeコストです。

大きなギャップです。これらのワークロードは高価になる傾向がありますが、コンピュートだけでなく、これらの他のすべてのものに対してもそうなので、そのギャップはそれほど重要ではありません。ここでの2倍は本当に大きく感じるかもしれませんが、そうではありません。

なぜなら、私がネットCPUでは100倍の差だったと言ったのを覚えていますか？ここで同じギャップだとしましょう、50倍だとしましょう。私たちに何が起こるかというと、繰り返しになりますが、Geminiの請求書を見ると、50倍の差になります。私たちの請求書は今、Geminiの請求書ではなく、推論請求書の400分の1になります。

これらの変更が実装され、実行できるようになった後、実際にGemini、OpenAI、その他すべてに支払う推論請求書は、コンピュート請求書の400倍高くなると予想されます。Cloudflareに切り替えたとすれば、800倍も良くなる可能性がありますが、nodeの互換性、同じサーバーでの画像圧縮、Verselでの展開方法、実行方法、ドメインの管理方法、その他すべてのものの利便性を諦めることになります。

かなりの差があります。特に、RAMの制限がどれだけ高いか、コンピュートがどれだけ速いか、その他すべてのことを考えるとです。

引数はもはや、高価すぎるまでVercelを使用し、その後Cloudflareに移行するということではありません。今は、Vercelの利点が約2倍のギャップに値するかどうかです。

エッジワーカーとミドルウェアの変更

すべてに利点と欠点があります。どちらも非常に魅力的なオプションになっており、このコストギャップは、これが彼らの投稿で暗示しているように寛大に実装されている限り、Vercelのプラットフォームは以前ほど悪くありません。それは滑稽なほど悪くないです。

Vercelがミドルウェアとエッジ関連でどのように使用しているかについていくつかの憶測を見ましたが、彼らは今日、エッジワーカーをミドルウェアで正式に終了させました。まだミドルウェアファイルはありますが、Vercelのコンピュートエンジン上で実行されるだけです。

彼らはCloudflareのworker Dモデルのような、エッジで実行されるものと短期間遊んでいましたが、ほとんどのものがそうであるように、利点と欠点がありました。そして、彼らはゆっくりとそれから離れていきました。

それでも、彼らはより伝統的なコンピュートエンジン内でそのモデルの素晴らしい課金特性を複製することに成功しています。これは本当にクールです。

これを考える別の方法は、より高速なCPUと実際のnode互換性のために約2倍のプレミアムを支払っているということです。これには、開発者体験の勝利や、Vercelプラットフォームが行うクールなことも含まれていません。

以前は100倍の差に近かったため、それは良い変化です。

コードサンドボックス機能

次はコードサンドボックスです。これは本当に楽しいもので、面白いことにCloudflareも今日、これに対する彼らのソリューションを発表しました。彼らが投下したばかりのものが、これに対する彼らのソリューションだと発表しました。

コードサンドボックス – Vercel Sandboxで信頼できないコードを実行

Vercel SandboxはFluid computeによって支援される安全なクラウドリソースです。AIエージェントによって生成されたコードのような信頼できないコードを、分離された短命環境で実行するように設計されています。Vercelプラットフォーム以外を含む任意の環境から実行できるスタンドアロンSDKです。

これは実際に本当にクールです。Cloudflare、Heroku、従来のAWSで実行していて、生成されたコードやユーザー提出コードを実行するための安全で分離された、プラットフォーム上の他のものを台無しにしないサンドボックスをスピンアップする必要がある場合、これは面白いです。

チャットはすでにevalを落としているのを見ます。そう、evalが安全だったらのようなものです。これは本当にクールです。

CloudflareのNode互換性について始めないでください。彼らが行った進歩は素晴らしく、真のnodeではありませんが、特定のnode APIを十分に互換性のあるものでサポートしていますか？クールです。しかし、nodeが必要なら、ffmpegのようなプラットフォーム上でネイティブコードを実際に使用するものが必要なら、Cloudflareは全くそれを行うことができません。

Sharp をCloudflareでWomを通して実行しようとすることについて始めないでください。その10メガバイトの制限を覚えていますか？ffmpeg WomをCloudflareで？いいえ、それは物ではありません。人々はそれを行ったと主張しています。実際に動作するコードを共有してくれた人は誰もいません。すべて作り話です。

JavaScriptの実行よりも複雑なことを行う実際のワークロードをCloudflareで実行することはできません。できません。できるふりをするのはやめてください。できないのです。彼らはそれを知っているので、コンテナを出しました。

彼らは今、この問題を解決するためにコンテナを持っています。安くはありませんが、良いものです。彼らが今コンテナを持っているのは素晴らしいことですが、「いやwomで、Cloudflareがすべてできるようになったよ」と人々がふりをするのにうんざりしています。いいえ、できません。

コードサンドボックスの実装詳細

とにかく、信頼できないコード、彼らはそのためのSDKを持っています。Vercel Sandboxです。このように作成したサンドボックスに生成されたテキストを渡し、そこからバッファを作成し、そのサンドボックスでコマンドを実行するのが、SDKレベルで統合していることは本当にクールです。

コマンドnode arg script.js、標準出力と標準エラーをどこに渡すかを指定します。これは本当にクールです。

ここにサンドボックスのドキュメントがあります。それに対してコントロールできるもののタイプを見ることができます。以下のこのコードは、Node22ランタイムを使用する4つの仮想CPUを持つサンドボックスをセットアップし、以下のすべてを行います：

  • Next アプリのGitHubリポジトリをクローン
  • 依存関係をインストール
  • Nextサーバーを実行
  • ポート3000でリッスン
  • ブラウザでサンドボックスドメインを開く
  • ターミナルにログをストリーミング

設定した5分のタイムアウト後にサンドボックスが停止します。

ソース、これはプルしたいソース、タイプget、リソース、vCPUs 4です。おそらくメモリなども設定できるでしょう。

タイムアウトミリ秒5分。これは文字列をミリ秒に変換するための彼らの素敵なヘルパーですが、5分は300,000ミリ秒です。

ポート3000、ランタイムnode 22を開きます。その後、コマンドを実行します。npm installコマンドを実行し、stderr stdoutをinstall.に渡します。終了コードが0でない場合、失敗したことを意味し、失敗したことをログし、process.exitします。

開発サーバーを開始。sandbox.run command npm rundev、同じ取引、detachedをtrueに設定し、タイムアウトを設定、spawn open sandbox.domain:3000。

クールです。実際に本当に良いです。サンドボックスプラットフォームには大きな可能性があります。私は興奮しています。

先ほど言ったように、CloudflareはDockerイメージとコンテナをCloudflare上で実行する方法を発表し、今日、それを使ってCode Sandboxesを使用する方法についてのブログ投稿を急いで出したようです。似たような感じです。

VercelのサンドボックスとCloudflareのサンドボックスが3時間以内に出たのは面白いです。CloudflareとVercelの間の競争がこれほどタイトになったことはありません。これらの人たちは常に歯と爪で戦っています。

そして、最終的に最も恩恵を受けるのは私たちです。Vercelがこれほど安くなった理由はCloudflareです。Cloudflareがコンテナを手に入れた理由はVercelです。Vercelが今サンドボックスを持っている理由はAnthropicです。公平に言うと、CloudflareもAnthropicです。

私たちは、これらの2つのプラットフォームが非常に積極的に競争しているため、より良いものを手に入れ続けています。

Anthropicの新機能

そして、もちろん、先ほどほのめかしたように、Anthropicも今日、類似のものを投下しました。ClaudeでAI搭載アプリを構築・共有。Claudeチャットとそこで生成されるアーティファクトが独自の小さなアプリになって、他の人と共有できる能力を追加しました。

クールです。類似のものの上に構築されていますが、彼らのものはより高レベルなものです。おそらくここでは実際にCloudflareのソリューションを使用しているでしょう。彼らを知っているとVercelのものかもしれませんが、おそらくCloudflareのものです。

このようなソリューションを既に行った他のプラットフォームがあります。私はDaytonaをかなりよく知っています。T3 chatのために彼らを使うことを検討していますし、将来的にスポンサーの可能性についても話しています。完全な開示です、後で彼らと働くかもしれません。

Daytona SDKを呼び出し、特定の言語用のインスタンスを作成し、この場合はconsole.log hello worldコードを実行し、それを実行し、応答を得ることができるこれらのタイプのソリューションはたくさんあります。

これは、時間が経つにつれてますます興味深くなると予想されるスペースです。なぜなら、AIは実際の世界と本当に相互作用することはできませんが、それを行うコードを書くことは絶対にできるからです。したがって、これらのタイプのツールがもっと起こり始めることを期待し、VercelやCloudflareのようなプラットフォームがそれらをより重く押し始めることも期待します。

信頼しないコードが実行できるスペースをサンドボックス化できることは、これまで以上に重要になります。正直言って、Cloudflareにわずかに賭けています。なぜなら、彼らはゼロトラストの世界に深く関わっており、それは彼らの製品とプラットフォームの大きな部分だからです。信頼できないコードを実行するという考えは、彼らに非常によく合うと思います。

このブログ投稿が急いで出されたことも分かります。彼らは他のものにはスペースを入れましたが、ここには入れなかったからです。これは彼らがおそらく既に取り組んでいた発表でしたが、Verselの発表に追いつくためにこの投稿を急いで出したことは非常に明らかです。

キューシステムの実装

それがサンドボックスです。次はキューズです。実際に本当に興奮しています。面白いことに、これはNetlifyが本当に先を行っていたと思うことの一つです。この重要な作業の大ファンです。

特に、部分的なステップがない長い実行生成タスクに対して重要です。画像生成やディープリサーチのような、ただ長時間かかるものをやっている場合、その全時間でコンピュートを実行するのは面倒です。

Cloudflareでは、ネットCPUに対してのみ課金され、効果的に無限の期間実行できるため、それほど大きな問題ではありませんでした。何かをスピンアップしてしばらく座って待つだけです。

しかし、現在、o3 Proのような特定のモデルが実行に非常に長い時間がかかるという問題が実際にあります。T3 chatにはo3 Proをユーザーが使える機能としてありません。独自のAPIキーを持参する必要があります。非常に高価だからです。

私たちが見た問題は、一部のユーザーでタイムアウトすることです。私たちの関数は800秒しか実行されないため、タイムアウトしています。それは私たちがハードコードした値です。それをより高く上げることができ、新しいfluid computeの変更により、さらに高く上げることができると思います。

しかし、リクエストの解決に15分かかり、それに十分な期間がない場合、それは面倒です。アクションをキューに入れ、完了時にそれを永続化し、ユーザーに結果を表示するコードを実行できたら、はるかに良いでしょう。

キューはこれらのワークロードに本当に役立ちます。長時間待機し、文字通り何もしないものです。その時間でメモリ割り当てを扱う必要もありません。

これは限定ベータです。公平に言うと、これは初期の製品の一つで、Verselでの経験の一部の後、これは私を怖がらせます。これらの初期製品の一部は完全に洗練され、準備ができていますが、他のものは全くそうではありません。

通常、彼らとのガット感覚で試し、他の顧客が移行する前に自分の決定を下そうとします。

彼らが言っていることは以下の通りです：限定ベータのVercelアプリケーション用に構築されたメッセージキューサービス。スローオペレーションが完了するのをユーザーが待つ必要がないように、タスクをキューに送信することで作業をオフロードできます。アプリはより信頼性の高い方法で再試行と失敗を処理できます。

これはクラッシュプルーフコードのようなTemporalのようなものです。書くすべてのコードの周りにワークフローを作成し、何かの部分が失敗した場合、それを再実行できます。inflectエフェクトタイプのもののようです。

Ingestとも過去に作業しようとしました。当初は本当に良い製品に見えましたが、相互作用するのは最も簡単ではありませんでした。しかし、非常に有望なもので、本当に良いDX、当初はあまりタイプセーフではありませんでした。彼らがついにそれを修正したかもしれませんが、当時はそうではありませんでした。

しかし、これらは耐久性のあるワークフローと耐久性のあるワークロードプラットフォームであり、Verselがもうそれらの会社に投資する価値がないと決めたようです。代わりに独自のものを作りたいのです。これは完全に理解できます。それらの会社は奇妙で、今では代わりに独自のものを構築しています。

ああTriggerを忘れていました。これらの人たちは実際に素晴らしく、相互作用するのも素晴らしいです。ここでもTrigger.devを忘れ続ける必要があります。これらの人たちは本当に、本当に良く、素晴らしいです。

繰り返しになりますが、これは他の多くの場所が実装していたものですが、Verselは今プラットフォーム上に持っています。どのくらい時間がかかるかを見ることができるこれらの素敵なダッシュボードもあり、明らかにAIに傾倒しています。ビデオの転写、音声の転写、これらのタイプのものすべて、コンテンツの生成、それが実行され、ステップがあり、テキストを作成し、次に画像を作成し、結果を返します。

それを再試行したり、トレースしたり、さまざまなことを行うこともできます。cron のような良いユースケースもあります。アイデアは理解できます。

キューとワークフローとワークロード耐久性ソリューションは重要です。Verselに直接構築されているのを見るのはクールです。

内部では、Versel キューズは追加ログを使用してメッセージを保存し、AI動画処理、メール送信、外部サービスの更新などのタスクが永続化され、決して失われないことを保証します。

主要機能：

  • PubSub – 複数のコンシューマーグループを可能にするトピックベースのメッセージング
  • ストリーミングサポート – ペイロードをメモリに完全にロードすることなく処理
  • 合理化されたOAuth – 設定が面倒
  • 完全なタイプセーフティを持つTypeScript SDK

Triggerにはそれがあると思います。他の人はそれを持っていません。それは本当にクールなことです。

sendとreceiveは@vercel/Qから、sendトピックメッセージ、receiveトピックコンシューマーメッセージ、素晴らしいです。これがどのようにタイプセーフにされたのか分かりません。Mの形状が何かを知るために、これらのものがどのように定義されているかを見たいのですが、初期アクセスなので、詳細を見るにはVerselコミュニティにサインアップして興味を表明する必要があります。

クールなものです。高く推奨する前にもっと多くを見たいです。それまでは、個人的にはTriggerを推奨しますが、すべてのオプションはかなり良いです。

Bot ID – キャプチャキラーソリューション

それがキューズです。次は、私に合わせて作られたように感じるもう一つです：キャプチャキラーです。私の以前のキャプチャ動画は必須視聴とは言いませんが、見ていない場合は、かなり良い視聴だと思います。そのようなコンテンツを感謝する場合は、サブボタンを押してください。半分未満の方がそれを持っています。何もかからないので、そうすることもできます。

キャプチャキラー製品について、しばらく試してみるよう連絡を受けていました。しかし、彼らが私に試してもらうよう連絡してきた時までに、私は既にH Captureに移行していて、本当に幸せでした。

とはいえ、Turnstyle、reCAPTCHA、H Captureを含む主要なキャプチャソリューションのどれもnpmパッケージすら持っていません。現代的なフルスタックTypeScript開発者体験はもちろんのこと。

それらすべては、ランダムなスクリプトをページに埋め込み、すべてのデータと読み込み状態などを自分で管理することを期待しています。見えないものと見えるものの部分的な状態など、すべて。

キャプチャから特に欲しいものは以下です：

  • ほとんどの人がキャプチャを見ることもなく、誰もが実行していることを知らない良い見えないモードが欲しい
  • 偽陽性の低さ – 本当のユーザーまたは本当のブラウザ上の本当の人間である場合、失敗するユーザーをたくさん欲しくない。理想的には、本当のユーザーが失敗することは全くない
  • 良いDX – 特にReactが何であるかを知っているnpmパッケージが欲しい。reCAPTCHAのようなもののランダムなオープンソースパッケージについて始めないでください。それらはすべて完全に保守されておらず、ゴミです
  • タイプセーフティ、異なるエラー状態の処理。これはDXの一種ですが、一般的な希望でもあります
  • 失敗時の見えるキャプチャへの昇格

これは大きな取引です。H captureにはこれがあります。彼らはそれを99.9%パッシブと呼んでいます。つまり、ほとんどのユーザーのほとんどの時間で、キャプチャを見ることはありませんが、前にトークンをあなたに渡す前に検証に失敗した場合、ユーザーがキャプチャチャレンジをポップアップして通過し、代わりにそれから生成された新しいトークンをあなたに与えます。

reCAPTCHAでこれをやりたい場合、見えないキャプチャを自分で実行し、それを別々に検証し、検証が失敗した場合、その状態をクライアントに送り返して、ユーザーのデバイスにhey、私たちのキャプチャチェックに失敗しました、見えるキャプチャでもう一度試すことができますか、と伝える必要があります。

これらの部分的な状態、やり取り、また、ボットがテストするのに本当に役立つものを誤って構築しないようにすることをすべて自分で管理する必要があります。

見えないから見えるに昇格する独自の漸進的キャプチャレイヤーを実装すると、キャプチャ回避ボットをテストするためのシステムを誤って作成してしまうかもしれません。楽しくありません。全くありません。キャプチャで体験しました。完了です。

それでは、Verselがどのようにスタックするかを見てみましょう。

Bot ID – 重要なルートのための見えないボットフィルタリングの導入。

現代の洗練されたボットはボットのようには見えません。JS を実行し、キャプションを解決し、本当のユーザーのようにインターフェースをナビゲートします。PlaywrightやPuppeteerのようなツールは、ページ読み込みからフォーム送信まで、人間のような動作をスクリプト化できます。

ヘッダーをチェックしたり、レート制限のような従来の防御は十分ではありません。設計によって混ざり込むボットは検出が困難で、無視するのに高価です。

ここで要点を強調するために、H capture価格設定、1000検証あたり1ドル。Write Data の H capture solver、最高ティアで1000解決あたり15ドル。開発者として私が1つ提供するのに支払うよりも、H captureを回避するのに5セント多く支払うのです。考えてみると本当に面白いです。

より弾力性のあるものを持つことはクールですが、各リクエストがどれだけ高価かによります。ボットによるリクエストが忍び込んだ場合、どれだけの価値を得て、どれだけのお金がかかるか。キャプチャを回避して1000リクエストあたり15ドル未満の価値を得ている場合、それは関係ありません。しかし、そうである場合、より厳しいものが必要かもしれません。

ここでBot IDが登場します。チェックアウト、ログイン、サインアップ、API、またはLLMを搭載したエンドポイントのような高価なバックエンド操作をトリガーするアクションのような、自動化された悪用が実際のコストを持つ重要なルートを保護するために構築された新しい保護レイヤーです。

そして、これがはるかに良いです。bot IDをチェック、isbot = await checkbot ID、isbotなら拒否。設定やチューニングは必要ありません。パッケージをインストールし、リライトを設定し、クライアントをマウントし、サーバーサイドでリクエストを検証します。

リライトの設定部分が何をするのかを見たいです。それについて読みましょう。

まず、Bot IDがどのように機能するかです。Bot IDは2つのモードで利用可能です：基本とディープ分析で、高度な検出チェックを追加します。

検出はセッションレベルで開始されます。Bot IDは、すべての読み込みで進化し、リプレイ、改ざん、静的分析に抵抗するように設計された軽量で難読化されたコードをリクエスト者の環境に注入します。

これはキャプチャやユーザー体験の変更なしに見えないように実行されます。これは面白いです。なぜなら、以前の例では「Verselで検証」のような小さなものがUIに現れていたからです。私がそれを嫌う理由を説明したので、他の人もそうしたと思うからです。なぜなら、これにはまったくUIがないようだからです。それはクールです。

従来の防御とは異なり、Bot IDは偽造しやすく、時代遅れになるユーザーエージェントヘッダーやIP範囲などの静的信号に依存しません。また、実際のユーザーを挫折させたりブロックしたりする可能性のあるキャプチャ、ヒューリスティクス、評判スコアなどの侵入的な方法も避けます。

代わりに、何千もの信号を静かに収集し、リバースエンジニアリングを防ぐためにすべての読み込みで検出ログを変異させ、スプーフィングを困難にし、攻撃パターンをグローバル機械学習ネットワークに打ち負かして、継続的に保護を改善する最も高度なボットに対抗します。

高速、信頼性、開発者向けに構築。サーバーサイド検証は単一の関数呼び出しを取ります。管理するAPIキーはありません。それは本当に良いです。チューニングするスコア閾値はありません。これもとても良いです。

H captureの私の好きなことの一つは、人間であるかどうかを自分で決める必要がないことです。reCAPTCHAダッシュボードには、どれだけ厳密にユーザーをフィルタリングしたいかのために左右に動かすことができる小さなチャートがあります。なぜなら、人間であるかどうかを判定するために0と1の間の数値を与える必要があるからです。

彼らは.7から.8を推薦しています。.3を超えると、5%以上のリクエストを失いました。つまり、ほぼ確実にいくつかのボットを入れていることを意味していましたが、reCAPTCHAは楽しくありませんでした。

ディープ分析、Casadaによって駆動。これは彼らが協力したパートナーです。繰り返しになりますが、Verselは第三者を引き込むことを躊躇しません。それが理にかなっている場合でも、小さな画面でレイアウトの方法を知らない第三者であってもです。

彼らは自動化脅威検出のようなコアプラットフォームです。私が見た限りでは、彼らは本当に良いとされていますが、設定が簡単ではなく、かなりクレイジーな契約にサインすることが期待されます。なぜなら、価格すら表示していないからです。

彼らは本当にあなたが彼ら自身でサイトでサインアップするのではなく、彼らと契約にサインすることを望んでいます。Verselが私たちのためにここでそのヒットを取り、そのパートナーシップを作り、そして透明度のはるかに高いレートで私たちにそれを与えてくれることはクールです。

別のサービスにサインアップする必要はありません、パッケージをインストールし、保護したいルートを定義し、デプロイするだけです。エンタープライズグレードの防御です。彼らはVzeroのようなもののためにしばらくそれを使っています。

従来の防御をすり抜ける標的自動化のあるチームのために利用可能です。すべてのチームで今利用可能です。

rewriteビットをどのように処理しているかを見たいです。なぜなら、それは私にとって非常に興味深かったからです。

私たちは自分のnext configをwith bot IDでラップする必要があります。ああ、これはアドブロッカーがスクリプト読み込みを壊さないようにするためです。これは私がアナリティクスなどのために行わなければならない回避策に似ています。または手動でリライトできます。

おお、これらのURLです。これらはブロックされ始めるでしょう。人々は怒るでしょう。アドブロックとのこの行き来は私も知っています、それは楽しいでしょう。

Bot ID クライアント、保護されたルート、API、センシティブ、チェックアウト、サインアップ、そして彼らが@bot ID/Clientから提供するコンポーネントがあります。保護したいルートでconfigを渡し、今度はこれらのルートへの任意のリクエストで適切なヘッダー情報を自動的に追加し、ユーザーを検証できることを知っています。

Bot IDクライアントコンポーネントで設定されているルートにない場合、またはコンポーネントに特定のルートがない場合、check bot IDは失敗します。理にかなっています。

ここで少し面倒なのは、有料ユーザーでは検証をスキップしたいが、無料ユーザーでは実行したい場合の粒度レベルの設定がないようだということです。なぜそうしないのかは理解できますが、それができればいいのにと思います。

そして、ルートでは、リクエストから取得してそれが必要とする他のすべてを処理するcheck bot IDを呼び出すだけです。

私の躊躇は、Vercelを使用していない場合、またはより重要なのは、nextを使用していない場合、これはリクエストデータを必要とするため、リクエストを渡す必要があり、彼らがそれを提供していないようなことです。これは非常にVercelに結び付いたソリューションです。

サーバーアクション、同じ取引、ただcheck bot IDを呼び出すだけです。

価格設定はここにあります：基本、すべてのプランで無料、ディープ分析、proとenterpriseで1000リクエストあたり1ドルのコストです。

基本チェックがすべての人に対して常に無料であることは興味深いです。これは実際にこれをはるかに魅力的にします。

私は彼らがここで何をしているかを見ていると思います。これを2つのモードとして表示していますが、これは実際には2つの製品です。基本はCloudflareのTurnstileカラーです。なぜなら、CloudflareはTurnstileに対して課金しません、少なくとも伝統的にはです。

特定の数のウィジェット、つまりウィジェットが使用を許可されている特定のサイトと設定を作成でき、どれだけの使用量を得ても課金されません。無料で安いサービスで、ユーザーから少しでもお金を稼がないが、悪用されないことを確認する必要がある場合、これによってTurnstileが本当に魅力的な選択になりました。

しかし、それはまた、狂気じみた偽陽性率も持っていました。特に非表示モードでは、基本的に使用できませんでした。非表示モードでは、本当のユーザーのリクエストが失敗する可能性が15%ありました。価値がない、無料でもです。

あなたがCloudflareのロゴをUIに表示してCloudflareに無料のブランディングとリーチを与えるか、本当のユーザーのリクエストが失敗する可能性が15%あるかのどちらかでした。

これが荒れていて、私はそれを推薦するのが困難だと感じました。我々が試した後に良くなったとされていますが、我々が試したときは非常に悪かったため、本当に無料が必要でない限り、良心的に推薦することはできません。

そして今、VerselのBot IDの基本モードがすべてのプランで無料であることもできません。なぜなら、これははるかに良く統合されている破壊されたTurnstileオプションだからです。我々がT3 chatのキャプチャシステムを構築した時にこれが存在していたら、ほぼ確実にそれを使用していたでしょう。

ディープ分析はreCAPTCHAとH captureとwork OSがRadarで行っているようなより高度なソリューションと競争することを意図しており、1000リクエストあたり1ドルの価格は、H captureとreCAPTCHAに完全に一致しています。どちらもほぼ正確に同じコストです。

これは私たちのようなもののために非常に理にかなっています。ほとんどのルートで基本ティアを設定し、例えばチャット生成でディープ分析ティアを設定できることが想像できます。これは非常に理にかなっています。

コードレベルで、プロジェクトレベルでディープ分析をオンにする必要がある場所はありますか？Bot IDは基本またはディープ分析でオンにする必要があります。嫌いです、Versel、誰かが見ているか後で見るでしょう、それを修正してください。

実際にルートを定義しているこの設定で、ここで深いか通常かを選択できる能力を与えてください。もちろん、チェックボットIDコールでdeep: trueのようなものを置く必要があり、両側で間違った設定がある場合は大きなエラーを与える必要がありますが、それは比較的些細な変更だと思います。

ほとんどのルートで基本を使用でき、高価なものでディープ分析を使用できるようになり、これをはるかに魅力的にするでしょう。

良いもの、これは彼らが行った最も魅力的な変更の一つで、私は数年後には、キャプチャで経験しなければならなかった痛みが、大きなWebpack設定を設定することが今では面白く感じるのと同じように、時代遅れで間違っているように感じる未来に興奮しています。なぜなら、我々は業界としてその問題を乗り越えたからです。しかし、当時はとても現実的でした。

これは、人々がこのようなキャプチャについて考えて設定する必要がない未来の最も魅力的なものの一つです。我々がそこに到達することを待ちきれません。

私たちのリストを通り抜けると：

  • 良い非表示モード – 彼らは非表示モードしか持っていません
  • 低偽陽性 – 私が彼らと彼らのパートナーCasadaから見た数字によると、本当に良いようです
  • 良いDX – これまでに見た中で最高のDXに見えます
  • 異なるエラー状態の処理 – 私が望む方法では処理していない、エラーを自分で送り返して、ユーザーに表示する必要があると確信しています。それを簡単に処理できるようにしてくれればいいのにと思います
  • 可視キャプチャへの昇格が欲しい – なぜなら、VPNを使っている奇妙なOSの奇妙なブラウザのような、本当に可視キャプチャ検証が必要なユーザーの種類は常にあるからです。そのようなユーザーを制限したくありませんが、彼らに作業をしてもらいたいのです

ああ、Resendがサインインのためにcloudflare turnstileを削除しました、そしてそれはよりクリーンで、彼らのログインは2倍速いです。彼らがVerselが出したばかりの新しい機能に移行したのではないと驚かれるでしょう。

ええ、ここにあります。6時間前にVerselがこの新機能を発表し、彼らはそれを実装しました。同じボット保護、テスト、プッシュ、プロダクション。ログインを雑然とさせないだけでなく、ログイン時間を半分に短縮します。巨大です。

素晴らしいです。それはコードもはるかにシンプルにします。reCAPTCHA 2やreCAPTCHA 3さえ以前に実装したことがある場合、それらがどれほど荒いかを知っています。これは非常に魅力的です。

間違いなく、ほとんどのサービスの開発者にとって最も魅力的な彼らが起動したものです。本当にクールです。

AIゲートウェイ

そして今、私たちは最後の事に到達しました。Verselが投下したAIゲートウェイです。彼らはしばらくの間これについて話していましたが、今日ベータで正式に出荷されました。

AIゲートウェイとは何ですか？プロバイダー間でAIモデルの幅広い範囲にアクセスするための単一エンドポイント、より良いアップタイム、より速い応答、ロックインなし。現在ベータで、OpenAI、xAI、Anthropic、Googleなどのプロバイダーからのモデルを使用できます。

プロバイダーリストの価格からの使用量ベースの課金、独自のキーの持参、モデルごとの使用量、レイテンシ、エラーメトリックを含む改善された観測性、より信頼性の高い推論のための認証の簡素化とフォールバック、プロバイダールーティング、そしてより高いスループットとレート制限です。

Anthropicの開始は、Anthropicモデルを使用する最悪の方法です。これはどういう意味でしょうか？

モデルプロバイダーがあなたを失敗させる方法はいくつかあります。私が最も気にするものは信頼性 – リクエストが失敗する対成功する頻度、サービスが実際にダウンして完全に解決できなくなる頻度、ランダムな理由でエラーになる頻度など、planet scaleからneonまでのスケールでそれがどこに該当するかです。

そして、もう一つの本当に大きなものはレート制限です。どれほど困難で面倒なことか、Anthropicにレート制限を上げてもらうのは、どれだけ大きな顧客であっても、どれだけのコネクションを持っていても、それらのことは関係ありません。

彼らには、支払う金額によって定義される4つの顧客ティアがあり、特定のティアになるために内部で昇格してもらう必要があります。Claude Sonnet 4はベースティアで最大分間50リクエスト、これは分間20kトークンin、8,000トークンoutまで聞こえるかもしれませんが、一人のユーザーのリクエストが最大100,000トークンinまで可能なので、一人のユーザーが5分間一つのリクエストでこれを飽和させることができます。

実際のワークロードには完全に使用できないので、どこか使用可能な場所に到達するためにこのティアリストを上げる必要があります。それでも、ティア3でも分間最大80,000トークンです。

ティアは繰り返しになりますが、支払う金額に基づいており、ティア4の昇格を得るには月額5,000ドル以上を支払う必要があり、その後、彼らがあなたのためにこれらの制限を上げるかもしれないし、上げないかもしれないカスタムティアの下で強制されます。

Claude 3.7 Sonnetは、それがドロップしたときに私たちが大きなプロモーターの一人だったため、比較的高く上げてもらいました。YouTubeビデオを作り、すべてを行い、彼らにバグを出し、より高い割り当てをくれました。

その後Sonnet 4がドロップし、私たちは明らかにティア4にいます。200kトークンin、それは分間2リクエストです。分間4,000リクエストができても、入力トークン制限が200kで、2人が2つのメッセージで100kを打った場合、それは分間2メッセージです。それはひどい、それはひどいです。

私たちにとって完全に使用できません。私たちは定期的にティア4の制限を吹き飛ばし、カスタムになったら、エンタープライズプランに入り、セールスダンスを前後に行う必要があります。地獄です。悲惨です。誰にも願いません。

レート制限がこれほどひどく、彼らとの交渉がひどく、3つ目のポイント、これは本当に私を悩ませるのですが、コスト交渉です。何かで特定のレベルのスループットを行っているとき、通常はレートを交渉し、割引を受けることができます。

Anthropicとコミットすると、月額20Kのコミットした支出、つまり文字通り月額20K、クレジットだけに支払う場合、それ以上行けばもっと支払えますが、それに達しなくても、とにかくその金額を支払うことにコミットしている場合、年額240,000ドル、私たちが受ける割引は5%です。

ばかげたレベルの支出に同意するために5%の割引を受けます。

Anthropicでのすべてのこれらのことは最悪です。信頼性はゴミです、特に新しいモデルがドロップするとき、特にcursorが新機能を出荷するとき、レート制限は文字通り使用できなくし、コスト交渉は彼らが私が今話そうとしていることを防ぐ方法でない限り、本当の利益ではありません。

彼らがそれらを防ぐ方法は、交渉と彼らがそこで得ることができるレートをより友好的で簡単にすることですが、彼らは狂気じみているため、それをしないでしょう。

信頼性とレート制限の問題

ここで問題が始まります。信頼性は荒いです。私のスクリーンショットを見つけることはできませんが、Claude 4がドロップしたときの失敗率がどれほど悪かったかのスクリーンショットを持っていました。Opusは公式APIから15%の成功率でした。Sonnetは重くレート制限され、BedrockとVertexはまだそれをサポートしていませんでした。

ちょっと待って、BedrockとVertexって、これはClaudeモデルではないですか？Anthropicが行った本当に楽しいことの一つは、GoogleとAWSの両方と取引を結び、Anthropicと同じレートでモデルをホストできるようにしたことです。

Anthropicのモデルを本当にAWSやGCP内に保ちたい場合、すべての他の支出がそこにあるため、進めてそこでAnthropicのモデルを使用できます。Googleに代わりに支払うだけで、Googleは何らかのレベルの割引を受けると確信していますが、Anthropicを下回らないように同じレートを課金することが強制されています。

大いに理にかなっています。なぜ彼らがそれを行うのか理解できますが、信頼性とレート制限を見るときに興味深くなります。

本当に信頼性があり、レート制限をあまり気にしないものを知っていますか？AWSです。レート制限について知らないことを除いて、AI studioでの全体的な別の愚痴を除いて、種類の信頼性があり、本当にレート制限が何であるかを認識していないものを知っていますか？Google Cloudです。

これらすべての最良を使用できたらどうでしょう？Anthropicのサービスでアップしているときにanthropicモデルを使用でき、ダウンしているときに同じリクエストを取り、GoogleのインフラやAmazonのインフラで行うことができたらどうでしょう？

これがOpen Routerが行うことです。ここでClaude Sonetを探すと、Claude 4、彼らには実際にいくつかの異なるプロバイダーがあることがわかります。信じられないかもしれませんが、AnthropicのAPIよりも高速であるため、デフォルトでGoogle Vertex USになっています。ほぼ2倍高速です。

Open Routerに移行することはほぼ確実で、同じコストで2倍の速度改善と、他のものがダウンしたときに適切な場所にルーティングするより良い信頼性を得るからです。

Open Routerは既にこれらすべての異なるプロバイダーと交渉してレート制限を可能な限り最高にし、これらすべての異なるプロバイダー間でトラフィックを分散しているため、欲しいもののために独自のAPIキーを持参させ、すべてが一緒になってOpen Routerを本当に魅力的なプラットフォームにします。

Anthropicモデルを実行するために、代わりにOpen Routerを使用できるとき、AnthropicのAPIを使用することは推奨できません。なぜなら、同じ価格でより高速な応答、はるかに良い信頼性を得て、レート制限について心配する必要がないからです。

それは素晴らしい取引で、独自のAnthropicモデルのキーを持参し、その後AnthropicのAPIがダウンしたときに、Open Routerを通してクレジットを使用する代わりに、独自のAnthropicアカウントのAnthropicクレジットの代わりに、Googleにフォールバックするように設定できます。本当に良いです。

Open Routerのようなプラットフォームは世界で完全に理にかないます。長期的にこれらの人たちが勝つと予想します。なぜなら、Anthropic、Amazon、Googleは互いに競争するのに忙しすぎて、これを自分たちで行わないからです。

VerselやもちろんこのケースではOpen Routerのように、彼らのコンピュートの後ろにどのクラウドがあるかを気にしない人を知っていますか？彼らはGPUでサーバーファームをスピンアップしていないため、気にしません。したがって、VerselとこのケースのOpen Routerも、トラフィックがどこにルーティングされるかを心配する必要がありません。

そうでなければより低いレイテンシとより高いスループットで、より信頼性の高い応答を得る限り、彼らは気にしません。本当にクールです。大いに理にかなっています。

VercelのAIゲートウェイの展望

Verselはこの現実に目を覚まし、私たちがその中間になることができることに気づいたようです。なぜなら、Verselはモデルがホストされている場所を気にしないからです。彼らはモデルホストではありません。彼らにとっては関係ありません。

彼らは効果的に、AWSでCPUがIntelかAMDかその他何かを気にしないのと同じように、GPUが実行されている場所を商品化しています。抽象化は一層高いです。この抽象化も一層高いです。

Open Routerからも誰かがここにぶら下がっています。彼らにはいくつかのレート制限がありますが、99.99%のユーザーにとっては本質的にゼロで、それはAnthropicからのレート制限ですが、トラフィックを他の場所にもルーティングできるため、ほとんど関係ありません。

ユーザーごとのレート制限はありません。理論的には、十分な人々が同時にOpen Routerで大量のトラフィックを行っている場合、彼らのプロバイダーでレート制限に達する可能性がありますが、それは効果的に決して起こりません。そして、独自のAPIキーを持参すれば、それも回避できます。

それでは、Verselが何をしているかを見てみましょう。ええ、かなりOpen Routerが構築しているのと同じことです。

一般的に言って、複雑で多くの動く部分を持つほど複雑なことに完全に投入している会社と、副次的に同等のものをスピンアップしている会社がある場合、それに完全に焦点を当てているチームが勝つ傾向があります。

Vercel BlobとUpload Thingのようなものを見ることができます。VerselはNext.jsを構築し、良いTypeScript開発者体験のリーダーですが、Upload Thingははるかに良い体験で、Blobよりもはるかに幸せなユーザーを持っています。

また、より本番対応で、より良くスケールします。理由があってUpload Thingを構築しました。Verselがほぼ同時にblobを出したにもかかわらず、ソリューションに満足していなかったからです。私たちの方が良く、勝ちました。

これもここで起こると思います。Open Routerには、推論を最高の分散体験にするために本当に一生懸命働いている信じられないほど才能のある開発者のチームがあります。Verselは、UIでヒットできるチェックボックスとしてそれを持っており、そこで使用できます。

彼らのAIゲートウェイがOpen Routerを打ち負かす世界は見えませんが、起こる可能性があります。それに対してすべてで、Anthropic開発者体験の限界的恐喝である何かを回避するもう一つの方法を持つことです。

私はこの時点で、彼らのプラットフォームがあまりにも荒く、一緒に働くことであるため、お金をAnthropicに直接置く場所でなければどこでもお金を置くことは大丈夫です。

Claudeモデルを使用している場合は、Open Routerを使用するか、AIゲートウェイを使用するか、bedrockやGCPに直接デプロイすることをお勧めします。何に行くかは気にしません。APIを介してこれらのモデルを使用しようとするAnthropicの体験が、あなたのお尻を噛み、大いに噛むであろうことを知ってください。

その他の新機能

信じられないかもしれませんが、これらすべての後でも、実際にいくつかのことを逃しました。それらを非常に迅速に爆破して、まとめましょう。

ローリングリリース。これは素晴らしいです。以前は、アプリの新しいバージョンをユーザーの割合にスピンアップしたい場合、実際にはできませんでした。すべてかなしかの種類のものでした。

T3 chatベータ中にこれに多く遭遇し、最終的にユーザーに手でトラフィックを移動するためにベータバージョンを使用するよう言いました。異なるフロントエンドとバックエンドにトラフィックの割合をルーティングできたら本当に良かったでしょう。当時は本当に現実的ではありませんでした。

これは、大きなオーバーホールを行いたい私たちにとって非常に有用です。繰り返しになりますが、私が経験した痛みのポイントに基づいて多くのこれらを構築しているように感じます。

また、それは馴染みのあるプロフィール写真です。DimmitriはTypeScript Doomを行った人です。狂人です。このようなものに彼が現れるのを見るのはクールです。

次に、誰もが大好きなトピック、マイクロフロントエンドです。マイクロフロントエンドは、Verselが今大企業である証拠です。なぜなら、彼らはほぼ確実に自分たちでこれを必要としているからです。

マイクロフロントエンドの概念は、コンポーネントがコードベースのファイルであることを考える代わりに、パッケージのようなものと考えることです。特定のチームが所有する特定のコンポーネントを更新でき、すべてのJSを更新することなく製品の特定の部分を更新できることを意味します。

フレームワークの選択からビルドツールパイプラインまで、すべてを配布できるため、UIがチームに基づいて論理的な部分に分解されます。「あなたの組織図を出荷する」という句を聞いたことがある場合、マイクロフロントエンドはあなたの組織図を出荷することを可能にし、ほとんどのビジネスが最終的にその方向に行く必要があるため、大いに理にかなっています。

Twitchで絶対にマイクロフロントエンドを行う方法を見つけるべきでした。代わりに、作業するのが最悪の単一のpackage.jsonを持つ巨大なリポジトリになりました。これは規模でDXを良く維持するソリューションですが、誰かがその規模でパイパーを支払い、これらのDX体験を扱う必要があります。

マイクロフロントエンドは、カップルの人々がそれを維持し、ひどい体験を持つ必要があることを意味し、他の皆が自分のしたいことを行うことができます。正しく行えば、素晴らしいです。

Verselは今それを受け入れ、各チームが構築、テスト、デプロイできる小さな独立してデプロイ可能なユニットに大きなアプリを分割することを可能にしているようです。素晴らしいです。

この種のものを本当に気にする場合は、Zephyr Cloudをチェックアウトするべきです。これらの人たちはマイクロフロントエンドの神です。ホームページのコピーを手伝いました。これらの人たちを愛しています。彼らは初期のスポンサーでした。まだ常に彼らとチャットしています。良いクルーです。彼らはそれを理解しています。

本当にスケーラブルなフロントエンドを作りたい場合は、彼らとチャットしてください。

最後に、Versel agentsです。実際にこれが何であるかは全くアイデアがありません。Verselダッシュボードに組み込まれたAIアシスタント、アプリのパフォーマンスとセキュリティデータを分析し、観測性に焦点を当て、異常を要約し、可能性のある原因を特定し、特定の行動を推奨します。

これはあなたのVerselデプロイメントのすべてのデータを見て、インシデントから奇妙なパフォーマンス問題まで起こっていることに関して提案を行い、提案を行います。本当にクールです。見るのが良いです。どこに終わるか見るのに興奮しています。限定ベータなので、少しかかりますが、本当に有望に見えます。

本当に面白いです。Open Routerダッシュボードを開いたままにしていて、今アプリケーションサイドエラーがあります。コードを書くのは難しいことが判明しました。Versel agentがあれば、何が間違ったかを教えてくれたでしょう。

Verselの顧客にとって非常に良い日でした。これらのものが以前に存在していれば良かったのにと思います。今それらが存在して非常に幸せです。彼らは今後、私の時間とお金と多くの欲求不満を節約してくれるでしょう。

彼らのキャプチャソリューションがそれらのユーザーにとってより少ない欲求不満な瞬間を持っている場合、一部のユーザーを節約してくれるかもしれません。私はこれについて非常に興奮しています。

皆さんがどう思うか教えてください。

コメント

タイトルとURLをコピーしました