Fluid compute: How we built serverless servers - Vercel

View on Vercel Blog

Fluid compute: サーバレスサーバー構築の舞台裏 - Vercel

この記事は、Vercelがどのようにしてより効率的なサーバレスコンピューティングを実現する「Fluid compute」を構築したか、その技術的詳細と利点について解説しています。

背景:

• Vercelは、リソースをより効率的に利用し、コールドスタートを最小限に抑え、コストを大幅に削減するサーバレスコンピューティングの新しいアプローチ「Fluid compute」を発表しました。
• Active CPU料金体系を導入し、Vercel上でのコンピューティングをさらにコスト効率良くしました。
• Fluid computeは、毎週450億件以上のリクエストを処理し、顧客のコストを最大95％削減し、アイドル時間に対してCPU料金を請求しないようにしました。

技術的な課題と解決策:

• ストリーミング応答の実現: AWS Lambdaでは、当初ストリーミング応答がサポートされていませんでした。そこで、Vercelは、Lambdaの外側に新しいセキュアなトランスポートを導入し、各インスタンスをインフラストラクチャに安全に接続する「トンネル」を構築しました。
  • これは、TCPベースのプロトコルを使用して、Lambdaからインフラストラクチャにパケットを送信することで実現されました。
  • これにより、HTTP応答をチャンクごとにクライアントにストリーミングできるようになりました。
• I/Oバウンドワークロードの効率化: Lambdaインスタンスは、I/O操作中にはアイドル状態になることが多く、リソースが浪費されていました。
  • Vercelは、既に開いているトンネルを再利用して、アイドル状態のLambdaインスタンスにさらにトラフィックを送信することを可能にしました。
  • そのために、compute-resolverサービスを構築し、リクエストをより効率的にルーティングするようにしました。
• リソース管理と負荷分散: Lambdaインスタンスに過剰なリクエストを送信しないように、Vercelは各インスタンスのCPUとメモリの使用状況を監視し、適切な負荷分散を行うシステムを構築しました。
  • Rustベースのコアを使用して、各Vercel Functionをラップし、メトリクスを継続的に送信することで、Vercel Function Routerが最適なリソース利用率を維持できるようにしました。
  • 必要に応じて、さらにトラフィックを送信するか、新しいインスタンスを起動するかを決定します。

Active CPU料金体系:

• Fluid computeのアーキテクチャを活用して、Active CPU料金体系を導入しました。
• これは、各インスタンスが使用する実際のCPU時間（ミリ秒単位）とプロビジョニングされたメモリ（GB-hrs単位）に対してのみ料金を請求するもので、I/Oバウンドワークロードに対してさらに90％以上のコスト削減を実現しました。

結果:

• 現在、Vercel Functionの呼び出しの75％以上がFluid computeを使用しており、最大95％のコスト削減を達成しています。
• Fluid computeは新しいプロジェクトのデフォルトであり、既存のプロジェクトでも有効化が推奨されています。

---

When Tool-Calling Becomes an Addiction: Debugging LLM Patterns in Koog | The JetBrains Blog

View on JetBrains Blog (Kotlin)

KoogにおけるLLMのパターン中毒：デバッグと解決策

この記事は、JetBrainsのAIエージェント構築フレームワークKoogを用いて、LLM（大規模言語モデル）がツール呼び出しに「中毒」し、意図しないパターンに陥る問題をデバッグし、その解決策を提示しています。

問題の核心:

著者は、Koog上で構築したエージェントをSWE-bench-Verifiedのタスクでテストしました。初期段階では順調に進みましたが、会話履歴が長くなるにつれて、LLMのコンテキストウィンドウ（処理できる情報量）の限界に直面しました。Koogは、会話履歴を要約して圧縮する機能を備えていますが、圧縮後にエージェントが「記憶喪失」のように最初からタスクをやり直すという問題が発生しました。

問題のデバッグ:

原因を調査したところ、以下の事実が判明しました。

• 誤ったツール呼び出し: 要約を要求しても、LLMは再びツール呼び出しを行いました。これは、LLMが過去のツール呼び出しと結果のパターンを学習し、そのパターンから抜け出せなくなったためです。
• 明示的な指示の無視: ツール呼び出しを禁止し、要約を促す指示を与えても、LLMは無視し続けました。
• パターン中毒: LLMは、過去の会話における「ツール呼び出し→ツール結果」のパターンを強烈に学習し、このパターンからの逸脱を許容しなくなりました。これは、少数の例（few-shot learning）によって、特定のパターンが強く学習されたためです。

解決策:

著者は、LLMのメッセージ境界を意識した構造的なアプローチで問題を解決しました。

1. メッセージパターンの打破:
   • すべてのメッセージをXMLライクなカスタムタグで囲んだ単一の文字列に統合し、LLMがメッセージ構造を認識できないようにしました。これにより、LLMは要約リクエストを「聞く」ことができ、パターンに固執しなくなりました。
2. コンテキストの復元:
   • 圧縮された情報（要約された事実）に加えて、エージェント自身に状況を説明させることで、継続性を確保しました。これにより、エージェントは会話履歴を失った理由を理解し、シームレスにタスクを再開できるようになりました。

結論と重要性:

この問題は、LLMがコンテキストを単なる記憶としてではなく、リアルタイムの学習データとして処理することを示唆しています。コンテキスト内のパターンが強すぎると、明示的な指示を上書きする可能性があります。

著者は、Koogの圧縮システムにこれらの修正を組み込みました。これにより、開発者はパターンに悩まされることなく、AIエージェントを構築し、長い会話履歴を管理できるようになりました。

---

レバテックフリーランスで当ブログを紹介いただきました - IK.AM

View on IK.AM

IK.AMブログがレバテックフリーランスの記事で紹介されました - 要約

IK.AMのブログが、レバテックフリーランスの記事「”できるエンジニア”と言われるために押さえたい！スキルアップブログ集」で紹介されました。紹介された記事のURLは、https://freelance.levtech.jp/guide/detail/151860/ です。