Skip to Content
デザイン大型パイプフレーム処理の計測

大型パイプフレーム処理の計測

概要

本PRは、大型の qwen serve ACPパイプフレームに対する計測および設計のステップです。パイプのペイロード、フレーム制限、EventBusの動作、SDKの動作、公開プロトコルフィールド、CLIフラグ、HTTPクエリパラメータ、または公開される機能（capabilities）の変更は行いません。

当面の目標は、過剰に大きなNDJSONパイプメッセージに対して低カーディナリティの属性（attribution）を収集し、次のサイドカー設計で推測された閾値ではなく、実際の pipe.message_bytes 分布を利用できるようにすることです。

現在の制限

現在、ACP子パイプには単一フレームのバイト数上限がありません。既存のデーモンメトリクスは pipe.message_bytes を direction 属性のみで記録します。これは意図的に低カーディナリティにしていますが、どのペイロードファミリーが大型フレームを引き起こしているかを説明できません。

SDK SSEリーダーはすでに、ブラウザ/イベントストリーム配信用に別の16 MiBバッファ上限を持っています。この上限はデーモンから子パイプへのフレームサイズを制限するものではなく、パイプフレームの送信元を説明するものでもありません。

バルクセッションリプレイには現在、10,000件のアップデートという件数上限があります。バイト数上限はないため、上限内の多数の大型アップデートが大きなレスポンスフレームを生成する可能性があります。

計測の形状

新しい内部NDJSONオブザーバーは、メッセージがパイプから正常に読み取られた後、またはパイプに正常に書き込まれた後に { direction, bytes, message } を受け取ります。既存のバイトフックは引き続き bytes のみを受け取り、現在のメトリクスパスを維持します。

デーモンは、すべてのフレームに対して既存のパイプカウント、合計、最大値、ヒストグラムメトリクス、およびステータスフィールドを記録します。大型フレームの属性収集は、bytes >= 256 * 1024 の場合にのみ実行されます。

大型フレームログは、デーモンプロセスごとに60秒あたり50レコードのウィンドウでサンプリングされます。抑制されたサンプルカウントは、次に記録される大型フレームログに付加されます。

ログに記録されるフィールドは、低機密の属性に制限されています。direction、バイトサイズ、閾値、JSON-RPCメッセージの種類、メソッド、ソースクラス、アップデート数、上限に達した際の要約アップデート数と戦略、セッションアップデートタイプ、混合セッションアップデートマーカー、ツール名、ツールの出所、生出力（raw output）の種類、コンテンツと生出力の浅いテキストバイト最大値、上限付きの概算非文字列生出力バイト数と上限マーカー、およびレート制限抑制カウンターです。ペイロード、セッションID、クライアントID、ファイルパス、プロンプト、およびツールの生出力はログに記録されません。

ヒストグラムは低カーディナリティを維持し、direction のみを保持します。メソッド、ツール名、セッションアップデート、ソースクラスなどのフィールドはメトリクス属性として追加されません。

ソースクラス

オブザーバーは、フレーム形状から証明可能なソースクラスのみを使用します。

  • session_update_notification: params.update を含む session/update 通知。
  • load_session_bulk_replay_response: _meta["qwen.session.loadReplay"] を含むJSON-RPCレスポンス。
  • load_updates_response: result.updates とロードアップデートレスポンスマーカーを含むJSON-RPCレスポンス。
  • jsonrpc_request: メソッドを持つその他のJSON-RPCリクエストまたは通知。
  • jsonrpc_response: その他のJSON-RPCレスポンス。
  • unknown: その他すべて。

パイプレイヤーは、ライブの session/update フレームとリプレイされたフレームを確実に区別できないため、この計測では live または replay の属性フィールドを出力しません。

次のフェーズに向けたサイドカーの候補

想定されるサイドカーの対象は、tool_call_update によって運ばれる大型のツール出力、特に content[] と rawOutput 内のテキストです。今後の実装では、アップデート内に小さなワイヤプレビューまたはスタブを保持し、本体全体をデーモン管理のサイドカーに配置する必要があります。

メタデータは _meta を介して送信されるべきです。これにより、古いクライアントはそれを無視し、新しいクライアントはサイドカーコンテンツの解決をオプトインできます。サイドカーの契約（contract）では、実装前にライフサイクル、アクセス制御、クリーンアップ、バイト閾値、フォールバック動作、およびクライアントUXを定義する必要があります。

バルクリプレイと qwen/session/loadUpdates は、多数の中型アップデートまたは少数の大型アップデートによってレスポンスが大きくなる可能性があるため、個別の処理が必要です。計測フィールドには、無制限のアップデート配列を走査したり、大型の非文字列生出力を具体化したりせずに、それらのケースを分離するための updateCount、summarizedUpdateCount、summarizedUpdateStrategy、maxContentTextBytes、maxRawOutputTextBytes、maxRawOutputApproxBytes、および maxRawOutputApproxBytesCapped が含まれています。アップデート配列が要約予算を超えた場合、最大フィールドはフルスキャンではなく、決定論的なプレフィックスプラスサフィックスサンプルから計算されます。

対象外

本PRでは、サイドカーストレージ、一時ファイル転送、フレーム上限、リプレイリングのバイト上限、コンパクショントリミング、EventBusのバイト上限、またはACP HTTPバインディングバッファのバイト上限の実装は行いません。

本PRでは、?maxFrameBytes または ?maxQueuedBytes クエリパラメータ、CLIフラグ、SDKオプション、または機能（capability）の追加は行いません。デーモンのメモリおよびトランスポート予算は、任意のクライアントによって引き上げられるべきではありません。

本PRでは、公開イベントスキーマの変更は行いません。将来のサイドカープロトコルはすべて追加的なものであり、別途レビューされる必要があります。

Last updated on
Channel P0 Identity と Task Lifecycle の設計セッション開始プロファイラー