MP3ファイルをダウンロード

内容紹介

Groundhog Day for AI agents: Prompt caching patterns for using OpenAI models on Amazon Bedrock Amazon Web Services、How NVIDIA Minerva Turns Telemetry Chaos Into Peak GPU Yield、Fixing Tool-Call Accuracy in vLLM、コンピューターサイエンス分野において「霧雨魔理沙」の名義で論文を出してる人を発見、冗談みたいな名前だが経歴見るとガッチガチの模様

出演者

ずんだもん

youtube版(スライド付き)

関連リンク

• Groundhog Day for AI agents: Prompt caching patterns for using OpenAI models on Amazon Bedrock Amazon Web Services

この記事では、Amazon Bedrock上のOpenAIモデルを用いてAIエージェントを構築・運用する際、マルチターン処理で課題となるコストとレイテンシの増大を防ぐための「プロンプトキャッシュ設計パターン」について詳しく解説しています。

AIエージェントはターンが進むごとに、ツール定義、システム指示、過去のやり取りやツール実行結果の全履歴を毎回モデルに送信し直す必要があります。これが原因でコストや処理時間が肥大化しますが、プロンプトキャッシュを活用することで、静的なプレフィックスや成長する会話履歴を効率的に再利用し、インプットコストを大幅に削減できます。

主な設計パターンと重要なポイントは以下の通りです。

1. キャッシュの基本とモードの使い分け
   • プリフィル処理時に構築されるKVベクトル（作業状態）をキャッシュし、後続のリクエストでは新規部分のみを処理します。
   • 暗黙的（implicit）モード: Amazon Bedrockが自動的に会話の成長に合わせてキャッシュ境界を管理します。成長する会話履歴に向いています。
   • 明示的（explicit）モード: prompt_cache_breakpoint を使用して保存ポイント（ツールや指示など）をコードで明示的に指定します。
   • ハイブリッド活用: 安定した静的プレフィックス（指示やツール）には明示的モードを使い、会話の成長には暗黙的モードを組み合わせることで、再利用可能な開始点を維持しつつ会話の自動管理が可能です。再利用には最低1,024トークンが必要となります。
2. 会話履歴とツール結果のキャッシュ
   • ターンが進むにつれて増加するツール実行結果は、暗黙的モードまたはローリングブレークポイントを用いて効率的にキャッシュします。
   • ツールの追加や変更を行う際は、初期のツールカタログを安定させつつ、additional_tools を用いて既存のキャッシュプレフィックスを無効化せずに新しいツールを追加できます。また、allowed_tools を使うことでキャッシュ定義を変えずに呼び出し制限が可能です。
3. サブエージェントとファンアウト（並行処理）
   • 複数のヘルパーやサブエージェントを立ち上げる際は、最初に通常のウォームアップリクエストを完了させて共有プレフィックスをキャッシュ（ウォーム）してから並行処理でファンアウトさせます。これにより、各ヘルパーが同じ背景情報を再読み込みするコストを防ぎます。
4. キャッシュキーの管理とベストプラクティス
   • セッション間でキャッシュを共有するには、モデル、AWSアカウント、リージョンが同一であることに加え、安定した prompt_cache_key を使用する必要があります（ハッシュ値を用いた動的生成などが有効）。
   • キャッシュのTTL（有効期限）は最低30分で、再利用により更新されます。
   • Amazon CloudWatchのメトリクスやAWS Cost Explorerを活用して、キャッシュ読み込み・書き込みのトークン数やコストをモニタリングし、費用対効果を測定することが重要です。

新人エンジニアにとっても、AIエージェントの実装時におけるAPIコスト最適化の具体的なアプローチやPythonコード例が網羅されており、実務で直面するパフォーマンス課題を解決するための実践的な学びが得られる内容となっています。

引用元: https://aws.amazon.com/blogs/machine-learning/groundhog-day-for-ai-agents-prompt-caching-patterns-for-using-openai-models-on-amazon-bedrock/

• How NVIDIA Minerva Turns Telemetry Chaos Into Peak GPU Yield

NVIDIA Minervaは、数万基規模のGPUクラスタを運用する巨大なAIファクトリー向けに設計された、AIネイティブのAIOps（IT運用のための人工知能）およびオブザーバビリティプラットフォームです。AIの分散学習では、最も処理の遅いランクやノードのペースに全体が同期するため、わずかなハードウェアの劣化やネットワークの遅延が全体の処理時間を大きくロスさせます。従来の静的なしきい値やルールベースの監視では、コンポーネント単体では正常に見えるが負荷時に問題が起きる「グレー故障」の検知や、1つの故障から派生する大量の警告（アラートストーム）の相関分析が困難でした。NVIDIA Minervaは、GPU、ネットワークファブリック（Spectrum-X、NVLink）、SuperNIC、ストレージ、スケジューラ、AIワークロードからテレメトリデータを収集し、動的な知識グラフ（ナレッジグラフ）を用いてインフラストラクチャとアクティブなジョブをリアルタイムにマッピングします。これにより、障害が発生した際に関連するジョブや物理トポロジを横断して即座に特定できます。機械学習モデルを活用した異常検知では、教師あり学習による既知のエラーパターンの検出だけでなく、教師なし学習によるピア比較（同等コンポーネント同士の挙動の比較）や、NLPを用いたログの異常検知を行い、静なしきい値では見逃される微妙な劣化を捉えます。また、トポロジ認識型の相関エンジンにより、関連する数多くのイベントや警告を1つの「実用的なインシデント」に集約し、ノイズを大幅に削減します。さらに、内蔵されたAIエージェント「Sherlock」やMCPサーバーにより、エンジニアは自然言語を用いてライブのテレメトリや知識グラフに問い合せ、根本原因の解析やトラブルシューティング、修復の推奨事項を得ることが可能です。これにより、障害のトリアージにかかる時間を数時間から数分へと短縮し、GPUの稼働率（グッドプット）を最大化します。今後は「DSX OS」との統合も進められ、テレメトリ基盤のオープンソース化も予定されています。新人エンジニアにとっても、大規模分散システムにおける複雑な障害解析やオブザーバビリティの重要性を理解する上で非常に参考になるアーキテクチャとなっています。

引用元: https://developer.nvidia.com/blog/how-nvidia-minerva-turns-telemetry-chaos-into-peak-gpu-yield/

• Fixing Tool-Call Accuracy in vLLM

オープンウェイトLLMをエージェントワークロードなどで実運用する際、モデルが生成するTool Call（関数呼び出し）の精度低下は深刻な問題となります。例えば、vLLMを使用して「Kimi K2.6」などのモデルをサービングした際、デフォルトの状態ではスキーマに完全一致しない不正な形式のTool Callが一定割合で発生し、コンテキストの汚濁やエラーの連鎖、コストの増大を引き起こすケースがあります。こうした問題の主な原因は、LLMが確率的にトークンをサンプリングする仕組み上、学習データやプロンプトの影響を受けて存在しないパラメータ名や誤った構文を生成してしまうことにあります。

この課題を根本的に解決する実用的な手法として、「制約付きデコード（Constrained Decoding）」があります。vLLMのバージョン0.31などでサポートされたこの機能は、XGrammarライブラリなどの構造的タグを利用し、生成されるトークンを動的に制限する仕組みです。推論時にツール定義のJSONスキーマや構文ルールに基づいて有効なトークンのみを許可し、無効なパスやトークンをGPU上で効率的にマスクします。これにより、Tool Callの構文精度をベストエフォートから100%保証されたランタイムへと引き上げることが可能です。

ただし、vLLMのようなモデル非依存の汎用推論エンジンでは、制約付きデコードをデフォルトで有効にすると、一部のモデルで出力が不自然になったり、グラマ翻訳のバグやスペックラティブデコードなどの他機能との競合によってリクエスト失敗を引き起こしたりするリスクがあります。そのため、vLLMの標準動作ではこれがデフォルトでオフに調整されており、ユーザー自身がサーバー側のフラグ等で明示的に厳格化レベルを設定する必要があります。特定のオープンウェイトモデルを高精度で運用したいエンジニアにとって、この制約付きデコードを適切に有効化・設定することは、モデル本来の性能を引き出すために極めて重要なアプローチとなります。

引用元: https://www.ubicloud.com/blog/fixing-tool-call-accuracy-in-vllm

• コンピューターサイエンス分野において「霧雨魔理沙」の名義で論文を出してる人を発見、冗談みたいな名前だが経歴見るとガッチガチの模様

コンピューターサイエンスの学術データベース上に、人気ゲーム「東方Project」のキャラクター名である「霧雨魔理沙」という名義で多数の論文を発表している実在の研究者がいることが話題になっている。この人物はユタ大学の博士課程に在籍する経歴を持ち、ICLRなどの著名な国際会議で主著として論文を発表するなど、被引用数も数百に上るなど極めて優秀な実績を残している。SNS上では、その硬派な研究実績とアニメチックな名前のギャップや、東方Projectの作風に絡めたユーモア溢れるコメントが多数寄せられ、エンジニアたちの間でちょっとした息抜きネタとして盛り上がりを見せている。

引用元: https://togetter.com/li/2763116

• お便り投稿フォーム

（株式会社ずんだもんは架空の登場組織です）